Reducerea golurilor: importanța comunicării DevOps

Chiar dacă metodologia DevOps este cu noi de ceva timp, este încă centrul discuțiilor aprinse. Companiile o doresc, dar nu sunt sigure cum să o abordeze.

DevOps este peste tot. Și deși este o tendință interesantă, ar trebui să se potrivească cu produse, nu invers.

Dar unii oameni nu văd așa. Mi se pun adesea întrebări precum: „Credeți că ar trebui să începem să folosim Docker sau să trecem direct în Kubernetes?” Astfel de întrebări sunt lipsite de sens fără a ști măcar despre ce este vorba despre produs.

Toți acești termeni sofisticați — cloud, Kubernetes, containere, managementul configurației, Infrastructure-as-Code — promit unele îmbunătățiri. Dar ele sunt pentru DevOps la fel cum telescoapele sunt pentru astronomie. Ele pot fi utile, dar nu sunt necesare.

În esență, DevOps își propune să reducă decalajul dintre ceea ce a comandat clientul și ceea ce a livrat echipa de dezvoltare. Se pune accent pe ciclurile scurte de lansare, abordarea iterativă a proiectării și automatizarea pașilor repetitivi. Ce crezi că este cel mai important pentru a le aduce în realitate?

Dacă ai spus „o comunicare excelentă”, ai dreptate. Uneltele sunt toate bune. Dar merită banii investiți în ele doar atunci când îmbunătățesc comunicarea.

Un aspect al comunicării este să știi ce este necesar pentru a duce treaba la bun sfârșit. Și jobul nu înseamnă „codul este trimis în depozit”. Gândiți-vă la asta mai degrabă ca „clientul a văzut schimbarea în producție și a acceptat-o”.

De îndată ce acest prim pas este determinat și toată lumea știe ce trebuie să se întâmple, acesta este cel mai bun moment pentru a-l nota. Unde? Ei bine, sunt un mare susținător al menținerii unui README.md . Fiecare persoană dintr-o echipă poate oricând să arunce o privire în interiorul ei și să cunoască starea unui proiect, iar acesta este o alegere naturală pentru noii veniți în proiect.

Automatizarea, următorul pas după scrierea unui README, este opțională. Este, totuși, o consecință naturală a documentării procesului. Și da, automatizarea este ceea ce îți vine adesea în minte când te gândești la DevOps.

Stai puțin... automatizarea este opțională când vine vorba de DevOps? Nu este DevOps departamentul persoanei care face implementări?

Ceea ce oamenii înțeleg de obicei sub termenul „inginer DevOps” este fie un inginer de fiabilitate software, un inginer de platformă sau un inginer de automatizare a operațiunilor. Toate acestea sunt roluri valide care permit practicarea DevOps, dar utilizarea termenului colectiv „inginer DevOps” poate fi puțin ambiguă.

Deci, să aruncăm o privire mai atentă asupra DevOps în sine.

DevOps explicat

Mai întâi, permiteți-mi să vă arăt ce nu este DevOps:

1. Nu este doar un prefix pentru titlul postului
2. Nu este o echipă (dar „Dev” și „Ops” sunt)
3. Nu este o tehnologie
4. Nu înseamnă „un administrator de sistem care poate codifica”
5. Nu înseamnă „automatizarea lucrurilor”
6. Nu înseamnă „nu există nicio echipă de operațiuni acum”

Știind acest lucru, acum știți că nu puteți pur și simplu „angajați un inginer DevOps” sau „creați o echipă DevOps” într-o companie pentru a vă asigura că sunteți pregătit pentru viitor. DevOps este asemănător cu dezvoltarea Agile. Ați angaja un dezvoltator Agile ca atare ? Probabil ca nu. Fie dezvoltați produsul într-un mod Agil, fie nu.

Atunci cum poate fi descris DevOps? Este o metodologie. Sau poate o cultură. Poate chiar un spirit. Realizarea unui produs conform principiilor DevOps înseamnă că toată lumea – fie că este dezvoltator, inginer de operațiuni sau manager de produs – împărtășește o viziune comună, menținând-o prin comunicare. Într-o măsură mai mică, înseamnă, de asemenea, că toată lumea folosește aceleași instrumente. Aceste instrumente nu sunt menite să ajute niciun grup de oameni. Ele sunt menite să împingă produsul înainte.

A merge cu acest concept necesită o schimbare serioasă a mentalității, care este principalul obstacol. De ce este asta? Pentru că oamenii trebuie să iasă din zona lor de confort și să înceapă să colaboreze cu oameni care au competențe diferite. Dezvoltatorii trebuie să învețe brusc cum funcționează cloud-ul și să înceapă să-și implementeze propriul cod. Operatorii trebuie să renunțe la setările manuale și să înceapă codificarea. Toată lumea trebuie să învețe concepte noi. Toată lumea are noi responsabilități .

Acest lucru nu este ușor, dar cu o bună comunicare și un obiectiv comun, este destul de realizabil. Această comunicare implică stabilirea unei culturi, înființarea de procese ușoare și menținerea unei documentații adecvate.

Automatizarea DevOps este documentație

Probabil că nu te-ai gândit niciodată la asta. Dar cele mai multe dintre instrumentele asociate în mod obișnuit cu DevOps sunt instrumente de documentare :

• Scripturile de compilare scrise pentru lizibilitate servesc la documentarea procesului de construire
• Conductele de integrare continuă documentează procesul de integrare, de la construirea unor piese individuale până la un produs întreg
• Canalele de implementare continuă merg mai departe prin documentarea modului de implementare a unui produs pe care clientul dvs. îl poate folosi
• Fișierele de gestionare a configurației documentează procesul de instalare și configurare
• Specificațiile de infrastructură ca cod documentează infrastructura necesară (în mod destul de formal, de fapt!)
• Containerele vin cu propriile lor Dockerfile care documentează cum să construiți și să configurați un anumit microserviciu

Toate aceste concepte fanteziste fac practic un singur lucru: îi ajută pe membrii echipei să comunice mai bine prin documentarea proceselor. Aceste procese pot fi apoi rulate manual sau automatizate. Ceea ce este important este ca fiecare parte interesată dintr-un proiect să le poată urmări.

Documentarea proceselor dvs. ca cod are un mare avantaj față de manualele de instrucțiuni obișnuite. Codul poate fi verificat și se comportă predictiv. Având aceeași intrare, produce aceeași ieșire.

Cu instrucțiuni scrise, vei avea atâtea interpretări câte cititori există. Dacă scrieți o documentație ambiguă sau vagă, persoana care o citește va completa golurile. Ideea este că nu ai nici un control asupra a ceea ce intră în goluri.

Cu codul este mult mai simplu. Fără pași concreti, programul va înceta să ruleze. Acești pași concreti sunt un aspect cheie al comunicării DevOps.

Comunicarea DevOps: singura modalitate de a face o reducere a decalajului dintre dezvoltare și operațiuni

În cartea The Phoenix Project asistăm la problemele unui manager recent promovat însărcinat cu implementarea unui proiect mare. Cum nimeni nu știe ce se întâmplă, toată lumea se luptă cu incendiile fără prea multe progrese. Subtitlul cărții menționează că este o poveste despre DevOps. Sunt de acord cu asta.

Dar ceea ce este interesant este că pe parcursul cărții nu este introdus niciun instrument nou. Puteți obține o stare DevOps numai prin îmbunătățirea comunicării? Protagoniștii cărții au făcut-o, așa că există speranță și pentru tine!

Chiar dacă abordarea protagoniștilor poate fi considerată „vechea școală” (folosind carduri reale de hârtie în loc de un sistem adecvat de urmărire a erorilor), lucrurile încep să se schimbe în bine doar odată ce toate părțile implicate încep să vorbească între ele.

S-ar putea să credeți că este posibil să îmbunătățiți colaborarea între dezvoltare și operațiuni doar prin crearea de interfețe mai bune între ele, cum ar fi acorduri la nivel de serviciu sau întârzieri de incidente. Dar opusul este adevărat. Dărâmând interfețele și introducând empatie și o cauză comună, veți avea o echipă care lucrează pentru un obiectiv comun.

Structura echipei DevOps: cine face parte dintr-o echipă?

În mod ideal, fiecare produs ar trebui să aibă o singură echipă: echipa de produs.

Am fost odată într-o echipă de dezvoltare unde un obiectiv comun cu alte echipe era absent. Echipa de dezvoltare a vrut să impulsioneze cât mai multe schimbări posibil. Echipa de validare a fost însărcinată cu prevenirea introducerii defectelor. Au avut manageri diferiți și au fost evaluați individual.

Rezultatul? Dezvoltare și validare au jucat ping-pong cu rapoarte de defecte. Când Validation a găsit un test care nu va trece, Development a fost mai interesat să găsească defecte în codul de testare în sine decât să încerce să-și facă propriul cod fără erori.

Ciclul de lansare a crescut, desigur, deoarece a fost nevoie de o suprasarcină enormă pentru completarea corectă a rapoartelor, a contrarapoartelor și așa mai departe. Ceea ce majoritatea părea să nu recunoască a fost că în ceea ce privește produsul, ambele echipe ar trebui să împărtășească un obiectiv comun și să lucreze împreună pentru a-l atinge. Dar lipsa cooperării adecvate și a mentalității de siloz au făcut-o foarte greu de observat.

Combaterea deșeurilor este un efort comun

Mentalitatea de producție slabă care a inspirat Manifestul pentru Dezvoltarea Software Agilă (care, la rândul său, ne-a introdus în DevOps) a fost despre combaterea risipei. Prin deșeuri înțelegem tot ceea ce nu este direct relevant pentru ceea ce a comandat clientul. Lucrările în desfășurare acumulate sunt o risipă. Fiecare pas al unui proces care nu duce în mod clar la eliberare este o risipă.

Dar deșeurile pot fi văzute doar de la un nivel înalt. În sfera unei echipe, unele proceduri pot părea esențiale. Din perspectiva produsului, totuși, acestea pot fi inutile.

Pentru a vă da seama ce eforturi sunt irosite, trebuie să vă uniți forțele și să luați în considerare ciclul de viață al unui produs expediat. De asemenea, trebuie să gândiți din perspectiva clientului. Este această caracteristică ceva dorit de client? Dacă nu, ați putea la fel de bine să-l omiteți în acest moment. Sunt procesele tale simple și slabe? Aruncă o privire mai profundă, în special la cei care depășesc granițele echipei.

Vrei să te asiguri că dezvoltarea unui produs este cât se poate de eficientă? Invitați un străin să vadă cum lucrați. O persoană care nu face parte din echipa ta va fi capabilă să pună întrebări profunde și să identifice noi domenii de îmbunătățire.

Principii DevOps: Păstrați-vă CALMA(E)

CALMS este o descriere foarte precisă a modului în care ar trebui să practici DevOps:

• cultura
• O automatizare
• L ean
• Măsurare
• S haring

Observați că este format ca un sandviș. Cele trei valori medii sunt mai tehnice, în timp ce cele exterioare se referă la abilitățile soft. Dar baza oricărei culturi este comunicarea: ne schimbăm valorile și convingerile cu alți membri ai echipei până când ajungem la un consens asupra modului în care ar trebui să se comporte lucrurile.

Același lucru este valabil și cu partajarea. A împărtăși ceva de bază, cum ar fi mâncarea, nu necesită comunicare. Gestul în sine, însă, poate fi văzut și ca un act de comunicare. „Îmi pasă de tine, așa că împărtășesc cu tine.” Nu vrem să limităm domeniul de aplicare doar la comunicarea verbală.

Totuși, împărtășirea ideilor și a instrumentelor necesită comunicare. Cum ar trebui să le împărtășim? Unde să le punem? Sunt utile pentru fiecare persoană dintr-o echipă sau doar pentru un grup mai mic?

Dacă vă concentrați doar pe aspectele mai tehnice — Automatizare, Lean și Măsurare — pierdeți scopul DevOps. Ce este atât de bun în a avea un script de implementare automatizat pe care nimeni nu îl folosește niciodată în afară de autor? Dacă scenariul îi economisește ceva timp, atunci s-ar putea să fie justificat. Dar imaginați-vă cât de mult timp ar putea fi economisit dacă toată lumea ar împărtăși acest script. Asta spune ceva despre combaterea risipei!

DevOps aduce afacerile mai aproape de dezvoltare

Unii spun că DevOps aduce operațiunile mai aproape de dezvoltare. Acest lucru este adevărat, dar nu este tot adevărul. Când este făcut corect, DevOps aduce fiecare unitate mai aproape. Permite afacerilor și clienților să vadă ce face dezvoltarea, aproape în timp real.

Această buclă de feedback mai scurtă aduce beneficii tuturor părților interesate. Lucrarea este în general mai vizibilă, iar dezvoltatorii pot vedea cu ușurință cum folosesc clienții codul pe care îl produc. Cu implementarea tradițională, puteți aștepta câteva luni până când cineva observă erori sau cerințe ratate. Cu o implementare continuă, toată lumea poate reacționa la orice problemă pe măsură ce apar. Dezvoltatorii, operațiunile, afacerile și clienții pot sta într-o singură cameră și pot modifica aplicația de lucru în funcție de nevoile curente.

Instrumentele DevOps mai întâi? Mai gandeste-te

Desigur, este nevoie de toate instrumentele pentru a face acest lucru posibil.

Dar nicio cantitate de instrumente nu poate înlocui o bună comunicare și empatie în cadrul companiei. Am observat odată un produs în care procesul de construire era deținut de o echipă, în timp ce codul furnizat era deținut de o altă echipă.

Problemele cu sistemul de construcție erau frecvente. Dezvoltatorii nu erau siguri cum să-l folosească. S-a bazat pe instrumente standard, dar acestea au fost personalizate până la punctul în care fiecare documentație disponibilă pe web s-a dovedit inutilă.

Toată lumea dorea să îmbunătățească situația, dar nu a fost nicio înțelegere între cele două echipe. Aceasta a însemnat că ambele părți au introdus noi instrumente fără a se consulta cu cealaltă parte. Acest lucru nu a făcut decât să lărgească decalajul, în loc să-l închidă.

Dacă doriți să începeți o transformare DevOps în cadrul organizației dvs., începeți cu îmbunătățirea modului în care comunicați. Nu presupuneți pur și simplu o soluție: mai întâi faceți brainstorming cu mintea deschisă. Atunci s-ar putea să descoperiți că, de exemplu, suportul pentru scule este insuficient pentru nevoile dvs. Atunci vă puteți gândi să vă modificați instrumentele actuale sau să introduceți unele noi - altfel probabil veți adăuga la problema inițială.

Cel mai rapid mod de a stabili DevOps? Comunicare mai bună!

În introducere, am menționat întrebarea pe care mi-o pun adesea clienții: „Ar trebui să merg cu Docker sau ar trebui să trec direct la Kubernetes?” După ce ați citit acest articol, puteți vedea că la o astfel de întrebare se răspunde cel mai bine după ce ați făcut niște lucrări de pregătire, cu o mentalitate DevOps.

Dacă știți că echipa dvs. de produse înțelege beneficiile DevOps pentru sine și pentru client, echipa și clientul pot începe prin a-și stabili așteptările. Apoi inginerii își pot da seama de modelul de dezvoltare și implementare. În cele din urmă, puteți determina ce instrumente sunt necesare.

Odată ce toate cerințele sunt documentate, alegerile tehnologice sunt mult mai ușor de făcut.

Sunt un susținător al tuturor instrumentelor grozave de automatizare DevOps care ne fac munca mai ușoară și mai ușor de gestionat. Dar munca noastră de zi cu zi este să lucrăm cu oamenii . Să investim ceva timp pentru a îmbunătăți acest aspect al celor mai bune practici DevOps, în loc să obținem un alt certificat de tehnologie.