Este greu să apuci esența vorbind despre DevOps? Am adunat pentru tine analogii sugestive, formule expresive și sfaturi de la experți care te vor ajuta să ajungi la miezul problemei chiar și fără o pregătire tehnică. La final, un bonus – conceptul de DevOps al angajaților Red Hat.
Termenul DevOps a apărut acum 10 ani și a evoluat de la un hashtag pe Twitter la o mișcare culturală puternică în lumea IT, o adevărată filozofie care încurajează dezvoltatorii să obțină rezultate mai repede, să experimenteze și să progreseze prin iterații. DevOps s-a conectat indisolubil de conceptul de transformare digitală. Dar, așa cum se întâmplă adesea cu terminologia IT, în decurs de un deceniu DevOps a acumulat o mulțime de definiții, interpretări și confuzii.
De aceea, despre DevOps se aud frecvent întrebări precum: este același lucru cu agile? Sau este o metodologie specială? Sau este doar un alt sinonim pentru «colaborare»?
DevOps include multe concepte diferite (livrare continuă, integrare continuă, automatizare etc.), așa că a desprinde esența poate fi complicat, mai ales când ai o afecțiune pentru subiect. Totuși, această abilitate este foarte utilă, indiferent dacă încerci să îți comunici ideile superiorilor sau pur și simplu povestești despre munca ta cu cei dragi. Așadar, să lăsăm deoparte nuanțele terminologice ale DevOps și să ne concentrăm pe imaginea de ansamblu.
Ce este DevOps: 6 definiții și analogii
Am rugat specialiștii să explice esența DevOps cât mai simplu și concis, astfel încât valoarea acestuia să fie clară pentru cititorii cu orice nivel de pregătire tehnică. În urma acestor discuții, am selectat cele mai sugestive analogii și formule expresive care îți vor ajuta să îți construiești povestea despre DevOps.
1. DevOps – este o mișcare culturală
«DevOps este o mișcare culturală, în cadrul căreia ambele părți (dezvoltatorii de software și specialiștii în operarea sistemelor IT) recunosc că software-ul nu aduce beneficii reale până când nu începe cineva să îl folosească: clienți, clienți, angajați, nu contează», afirmă Eveline Oehrlich, analist senior la Institutul DevOps. – De aceea, ambele părți asigură împreună livrarea rapidă și de calitate a software-ului».
2. DevOps – este ceea ce împuternicește dezvoltatorii
«DevOps împuternicește dezvoltatorii să dețină aplicații, să le lanseze și să gestioneze livrarea de la început până la sfârșit»
«De obicei, se vorbește despre DevOps ca despre un mod de a accelera livrarea aplicațiilor în producție prin crearea și aplicarea unor procese automatizate», spune Jai Schniepp, director de platforme DevOps la compania de asigurări Liberty Mutual. – „Dar pentru mine, aceasta este o chestiune mult mai fundamentală. DevOps împuternicește dezvoltatorii să dețină aplicații sau anumite părți ale software-ului, să le lanseze și să gestioneze livrarea de la început până la sfârșit. DevOps elimină confuzia în responsabilități și îi ghidează pe toți participanții la proces spre crearea unei infrastructuri automate și controlate de dezvoltatori.”
3. DevOps – este colaborarea în crearea și livrarea aplicațiilor
«Pe scurt, DevOps este o abordare a producției și livrării software-ului în care toți lucrează împreună», subliniază Gur Staff, președintele și șeful departamentului de automatizare a afacerilor digitale la BMC.
4. DevOps – este un conveior
«Montajul pe conveior este posibil doar dacă toate piesele se potrivesc între ele».
«Aș compara DevOps cu un conveior de asamblare a automobilelor», continuă Gur Staff. – „Ideea este de a proiecta și construi toate piesele astfel încât să poată fi asamblate fără ajustări individuale. Montajul pe conveior este posibil doar dacă toate piesele se potrivesc între ele. Cei care proiectează și construiesc motorul trebuie să ia în considerare modul în care acesta va fi fixat la caroserie sau cadru. Cei care construiesc frânele trebuie să se gândească la roți, și așa mai departe. La fel trebuie să fie și cu software-ul.”
Dezvoltatorul care creează logica de afaceri sau interfața utilizatorului trebuie să se gândească la baza de date care stochează informații despre clienți, la măsurile de securitate pentru protecția datelor utilizatorilor și, de asemenea, la modul în care toate acestea vor funcționa atunci când serviciul va începe să deservească o audiență mare, posibil chiar multimilionară.
„Să facem astfel încât oamenii să colaboreze și să se gândească la părțile muncii care sunt realizate de alții, nu doar să se concentreze exclusiv pe sarcinile lor, este cea mai mare provocare de depășit. Dacă reușiți, aveți șanse excelente pentru transformarea digitală”, adaugă Gur Staff.
5. DevOps este combinația corectă de oameni, procese și automatizare
Jayne Groll, director executiv al Institutului DevOps, a oferit o analogie excelentă pentru a explica DevOps. Potrivit acesteia, „DevOps este ca o rețetă culinară, în care există trei categorii principale de ingrediente: oameni, procese și automatizare. Majoritatea acestor ingrediente pot fi preluate din alte domenii și surse: Lean, Agile, SRE, CI/CD, ITIL, leadership, cultură, instrumente. Secretul DevOps, la fel ca orice rețetă bună, este modul în care combinăm corect aceste ingrediente pentru a crește viteza și eficiența în dezvoltarea și livrarea aplicațiilor”.
6. DevOps este atunci când programatorii lucrează ca o echipă de Formula 1
„Cursele sunt planificate nu de la start la finis, ci invers, de la finis la start”.
„Vorbind despre ce să ne așteptăm de la inițiativa DevOps, dau exemplul unei echipe de curse NASCAR sau Formula 1”, spune Chris Short, managerul principal de marketing pentru platformele de cloud de la Red Hat și editor al newsletterului DevOps’ish. „Un lider al unei astfel de echipe are un singur obiectiv: să obțină cele mai bune rezultate în funcție de resursele echipei și provocările întâmpinate. În același timp, cursa este planificată nu de la start la finis, ci invers, de la finis la start. La început se stabilește un obiectiv ambițios, iar apoi se definesc modalitățile de a-l atinge. După aceea, acestea sunt împărțite în sub-sarcini și delegate membrilor echipei.”
„Pe parcursul întregii săptămâni înainte de cursă, echipa își perfecționează pit-stopurile. Se antrenează în forță și la cardio pentru a fi în formă într-o zi obositoare de curse. Lucrează împreună pentru a rezolva orice probleme care ar putea apărea pe parcursul cursei. La fel, echipa de dezvoltare trebuie să exerseze abilitățile de lansare frecventă a noilor versiuni. Cu astfel de abilități și un sistem de securitate bine pus la punct, lansarea noilor versiuni în producție devine, de asemenea, mai frecventă. Din această perspectivă, creșterea vitezei înseamnă creșterea securității”, spune Short.
„Nu este vorba despre a face „lucrurile corecte”, adaugă Short, „ci despre a elimina cât mai multe obstacole posibile care stau în calea rezultatului dorit. Colaborați și adaptați-vă în funcție de feedback-ul pe care îl primiți în timp real. Fiți pregătiți pentru anomalii și lucrați la îmbunătățirea calității pentru a minimiza impactul lor asupra progresului către obiectiv. Acesta este exact ceea ce ne așteaptă în lumea DevOps”.
Cum să scalați DevOps: 10 sfaturi de la experți
DevOps simplu și DevOps de masă sunt lucruri complet diferite. Vă vom explica cum să depășiți barierele pe calea de la unul la celălalt.
Pentru multe organizații, drumul către DevOps începe ușor și plăcut. Se formează echipe mici pasionate, procesele vechi sunt înlocuite cu unele noi, iar primele succese nu întârzie să apară.
Din păcate, aceasta este doar o strălucire falsă, o iluzie de progres, așa cum spune Ben Grinnell, director general și lider al domeniului tehnologiilor digitale la firma de consultanță North Highland. Primele victorii sunt desigur încurajatoare, dar nu ajută la atingerea obiectivului final, și anume utilizarea pe scară largă a DevOps în organizație.
Este ușor de văzut că, în urma acestui proces, se formează o cultură a divizării între „noi” și „ei”.
„Adesea, organizațiile lansează astfel de proiecte-pionier, crezând că acestea vor deschide calea pentru DevOps la scară largă, fără a se gândi dacă ceilalți vor dori sau vor putea să urmeze acest drum”, explică Ben Greennell. „Echipele care implementează astfel de proiecte sunt de obicei alcătuite din „vikingi” încrezători, care au mai realizat ceva similar în alte părți, dar care sunt novice în organizația dvs. În același timp, sunt încurajați să strice și să ignore regulile care rămân obligatorii pentru toți ceilalți. Este ușor de observat că, în rezultat, se formează o cultură a divizării între „noi” și „ei”, care împiedică transmiterea cunoștințelor și abilităților.”
„Și această problemă culturală este doar una dintre cauzele pentru care DevOps este greu de scalat. Echipele DevOps se confruntă cu creșterea dificultăților tehnice specifice companiilor în expansiune rapidă care s-au bazat pe tehnologiile IT”, afirmă Steve Newman, fondator și președinte al companiei Scalyr.
„În lumea modernă, serviciile se schimbă imediat ce apare o necesitate. Implementarea constantă și introducerea de noi funcționalități este, desigur, grozav, dar coordonarea acestui proces și soluționarea problemelor apărute reprezintă o adevărată bătaie de cap”, adaugă Steve Newman. „În organizațiile în decolare rapidă, inginerii din echipele cross-funcționale se luptă să își păstreze capacitatea de a urmări modificările și efectele în cascadă pe nivelurile de dependență. Mai mult, inginerilor nu le face plăcere când li se ia această posibilitate, iar în consecință devine mai greu să înțeleagă natura problemelor apărute.”
Cum putem depăși dificultățile menționate mai sus și transita către utilizarea pe scară largă a DevOps într-o organizație mare? Experții recomandă să aveți răbdare, chiar dacă scopul vostru final este să accelerați ciclul de dezvoltare a software-ului și procesele de afaceri.
1. Amintiți-vă că schimbările culturale necesită timp
Jane Groll, director executiv al Institutului DevOps: „În opinia mea, extinderea DevOps ar trebui să fie la fel de treptată și iterativă ca și dezvoltarea agile (și să implice în aceeași măsură cultura). În Agile și DevOps, accentul se pune pe echipe mici. Dar pe măsură ce numărul și integrarea acestor echipe cresc, avem din ce în ce mai mulți oameni care aplică noi metode de lucru, iar ca urmare, apare o transformare culturală de amploare.”
2. Acordați suficient timp pentru planificare și alegerea platformei
Eran Kinsbruner, evanghelist tehnic principal al companiei Perfecto: „Pentru ca scalarea să funcționeze, echipele DevOps trebuie mai întâi să învețe să combine procesele, instrumentele și abilitățile tradiționale, iar apoi să dezvolte treptat fiecare fază a DevOps și să o stabilizeze. Totul începe cu o planificare atentă a poveștilor utilizatorilor și a fluxurilor de creare a valorii, după care urmează etapa de scriere a software-ului și controlul versiunilor, utilizând dezvoltarea bazată pe trunk sau alte abordări mai potrivite pentru ramificarea și îmbinarea codului.”
„Apoi urmează etapa de integrare și testare, unde este necesară deja o platformă scalabilă pentru automatizare. Aici, echipele DevOps trebuie să aleagă platforma potrivită, care să corespundă nivelului lor de abilități și obiectivelor finale ale proiectului.”
Faza următoare este desfășurarea în mediu de producție, iar aceasta trebuie să fie complet automatizată cu instrumente de orchestrare și containere. Este important să existe medii virtualizate în toate etapele DevOps (simularea mediului de producție, mediu de control al calității și, de fapt, mediu de producție) și să se folosească întotdeauna cele mai recente date pentru teste, pentru a obține concluzii relevante. Analiza trebuie să fie inteligentă și capabilă să gestioneze date mari cu feedback rapid și eficient.”
3. Eliberați responsabilitatea de gustul vinovăției
Gordon Haff, evanghelist RedHat: „Crearea unui sistem și a unei atmosfere care să permită și să încurajeze experimentele permite realizarea a ceea ce se numește eșecuri de succes în dezvoltarea software-ului agile. Asta nu înseamnă că nimeni nu mai este responsabil pentru eșecuri. De fapt, stabilirea unui responsabil devine chiar mai simplă, deoarece „a fi responsabil” nu mai înseamnă „a fi vinovat de accident”. Cu alte cuvinte, esența responsabilității se schimbă calitativ. În acest sens, patru factori devin extrem de importanți: amploarea eșecului, abordările, procesele de producție și stimulentele.” (Mai multe despre acești factori puteți citi în articolul lui Gordon Huff „Lecții DevOps: 4 aspecte ale experimentelor sănătoase.”)
4. Eliberați drumul înainte
Ben Grinnell, director general și lider al departamentului de tehnologie digitală al firmei de consultanță North Highland: „Pentru a atinge scalabilitatea, recomand să desfășurați simultan cu proiectele de pionierat un program de „eliberare a căii”. Scopul acestui program este de a curăța resturile lăsate de pionierii DevOps, cum ar fi regulile depășite și alte lucruri similare, astfel încât drumul înainte să rămână liber.”
„Oferiți oamenilor suport organizațional și insuflați impuls prin comunicare, care să depășească cu mult grupul pionierilor, celebrând pe larg succesele noilor metode de lucru. Formați persoanele implicate în următoarea etapă a proiectelor DevOps și care sunt neliniștite pentru că utilizează DevOps pentru prima dată. Și amintiți-vă că acești oameni sunt foarte diferiți de pionieri.”
5. Faceți instrumentele mai democratice
Steve Newman, fondator și președinte al consiliului de administrație al companiei Scalyr: „Instrumentele nu ar trebui ascunse de oameni și ar trebui să fie relativ simple de învățat pentru oricine este dispus să investească timp în asta. Dacă oportunitatea de a solicita jurnale este oferită doar la trei persoane „certificate” pentru a lucra cu un anumit instrument, veți avea întotdeauna un maxim de trei persoane capabile să se ocupe de problema respectivă, chiar dacă aveți un mediu de calcul foarte mare. Cu alte cuvinte, aici apare o restricție, care poate avea consecințe grave (pentru afacere).
6. Creați condiții ideale pentru echipă
Tom Clark, liderul departamentului Common Platform la compania ITV: „Puteți face orice, dar nu totul deodată. Așa că stabiliți obiective mari, începeți cu pași mici și avansați rapid prin iterații. În timp, veți câștiga reputația unei echipe care reușește, ceea ce va determina și pe alții să dorească să utilizeze metodele dumneavoastră. Și nu urmăriți doar formarea unei echipe de înaltă performanță. În schimb, oferiți oamenilor condiții ideale de lucru și eficiența va veni de la sine.”
7. Nu uitați de legea Conway și tablourile Kanban
Logan Daigle, director de livrare software și strategie DevOps la CollabNetVersionOne: „Este important să conștientizăm consecințele legii Conway. Pe scurt, această lege spune că produsele pe care le creăm și procesele pe care le folosim, inclusiv DevOps, sunt organizate la fel ca organizația noastră.”
„Dacă în organizație există o mare fragmentare, iar la planificarea, crearea și lansarea software-ului managementul se transferă frecvent de la o persoană la alta, efectul scalării va fi zero sau de scurtă durată. Pe de altă parte, dacă organizația formează echipe interfuncționale în jurul produselor care sunt finanțate cu orientare pe piață, șansele de succes cresc brusc.”
„Un alt aspect important al scalării este să reflectăm pe tablourile Kanban toate lucrările aflate în desfășurare (WIP, work in progress). Atunci când apare un loc în organizație unde oamenii pot vedea aceste lucruri, acest lucru stimulează semnificativ colaborarea, ceea ce are un impact pozitiv asupra scalării.”
8. Căutați vechile cicatrici
Manuel Pais, consultant DevOps și coautor al cărții „Team Topologies”: „Extinderea practicilor DevOps dincolo de Dev și Ops și încercarea de a le aplica altor funcții nu poate fi considerată o abordare optimă. Cu siguranță, va avea un anumit efect (de exemplu, prin automatizarea managementului manual), dar se poate obține mult mai mult dacă începem cu înțelegerea proceselor de livrare și feedback.”
„Dacă în sistemul IT al organizației există cicatrici vechi – proceduri și mecanisme de gestionare, care au fost implementate în urma incidentelor anterioare, dar și-au pierdut relevanța (din cauza schimbării produselor, tehnologiilor sau proceselor), atunci acestea trebuie fără îndoială eliminate sau atenuate, nu automatizate procese ineficiente sau inutile.”
9. Nu creați variante de DevOps
Antony Edwards, director de producție la Eggplant: „DevOps este un termen foarte vag, prin urmare, fiecare echipă ajunge să aibă propria variantă de DevOps. Și nu există nimic mai rău decât atunci când în organizație apar simultan 20 de variante de DevOps, care nu coabitează bine împreună. Nu poate fiecare dintre cele trei echipe de dezvoltare să aibă propria interfață între dezvoltare și gestionarea produsului. La fel, produsele nu pot avea așteptări unice în ceea ce privește gestionarea feedback-ului când sunt transferate în simularea mediului de producție. În caz contrar, nu veți reuși niciodată să scalați DevOps.”
10. Promovați valoarea DevOps pentru afaceri
Steve Newman, fondator și președinte al consiliului de administrație al companiei Scalyr: „Lucrați la recunoașterea valorii DevOps. Învățați și nu ezitați să vorbiți despre beneficiile a ceea ce faceți. DevOps economisește incredibil de mult timp și bani (gândiți-vă: mai puțin timp de nefuncționare, un timp mediu de recuperare mai scurt), iar echipele DevOps trebuie să sublinieze (și să promoveze) constant importanța acestor inițiative pentru succesul afacerii. Astfel, veți putea extinde cercul susținătorilor și să creșteți influența DevOps în organizație.”
BONUS
Pe Pe 13 septembrie, va veni propriul nostru DevOps – da, Red Hat, ca furnizor de software, are propriile echipe și practici de DevOps.
Inginerul nostru, Mark Birger, care se ocupă de dezvoltarea serviciilor de automatizare internă pentru alte grupuri din întreaga organizație, va povesti în rusă despre propria sa experiență – cum echipa DevOps de la Red Hat a migrat aplicațiile din medii virtuale Hat Virtualization, gestionate de Ansible, într-un format complet containerizat pe platforma OpenShift.
Dar nici asta nu este tot:
După ce organizațiile au mutat sarcinile de lucru în containere, metodele tradiționale de monitorizare a aplicațiilor pot să nu mai funcționeze. În al doilea raport, ne vom explica motivația de a schimba modul de înregistrare și vom arăta continuarea căii care ne-a condus la metodele moderne de jurnalizare și monitorizare.
Sursa: habr.com
