Este dificil să înțelegi punctul principal atunci când vorbim despre DevOps? Am adunat pentru tine analogii vii, formulări izbitoare și sfaturi de la experți care îi vor ajuta chiar și pe cei care nu sunt specialiști să ajungă la obiect. La final, bonusul este DevOps-ul propriu al angajaților Red Hat.
Termenul DevOps a apărut acum 10 ani și a trecut de la un hashtag Twitter la o mișcare culturală puternică în lumea IT, o adevărată filozofie care încurajează dezvoltatorii să facă lucrurile mai repede, să experimenteze și să continue. DevOps a devenit indisolubil legat de conceptul de transformare digitală. Dar, așa cum se întâmplă adesea cu terminologia IT, în ultimii zece ani DevOps a dobândit multe definiții, interpretări și concepții greșite despre sine.
Prin urmare, puteți auzi adesea întrebări despre DevOps, cum ar fi, este același lucru cu Agile? Sau aceasta este o metodologie specială? Sau este doar un alt sinonim pentru cuvântul „colaborare”?
DevOps include multe concepte diferite (livrare continuă, integrare continuă, automatizare etc.), așa că distilarea a ceea ce este important poate fi o provocare, mai ales atunci când ești pasionat de subiect. Cu toate acestea, această abilitate este foarte utilă, indiferent dacă încercați să transmiteți ideile dvs. superiorilor sau pur și simplu spuneți cuiva din familia sau prietenii dvs. despre munca dvs. Prin urmare, să lăsăm deoparte nuanțele terminologice ale DevOps pentru moment și să ne concentrăm pe imaginea de ansamblu.
Ce este DevOps: 6 definiții și analogii
Le-am cerut experților să explice esența DevOps cât mai simplu și pe scurt posibil, astfel încât valoarea acestuia să devină clară pentru cititorii cu orice nivel de cunoștințe tehnice. Pe baza rezultatelor acestor conversații, am selectat cele mai izbitoare analogii și formulări izbitoare care vă vor ajuta să vă construiți povestea despre DevOps.
1. DevOps este o mișcare culturală
„DevOps este o mișcare culturală în care ambele părți (dezvoltatori de software și specialiști în operarea sistemelor IT) recunosc că software-ul nu aduce beneficii reale până când cineva nu începe să-l folosească: clienți, clienți, angajați, nu e rostul”, spune Eveline Oehrlich, senior research. analist la Institutul DevOps. „Prin urmare, ambele părți asigură împreună livrarea rapidă și de înaltă calitate a software-ului.”
2. DevOps este despre împuternicirea dezvoltatorilor.
„DevOps dă putere dezvoltatorilor să dețină aplicații, să le ruleze și să gestioneze livrarea de la început până la sfârșit.”
„De obicei, despre DevOps se vorbește ca o modalitate de a accelera livrarea aplicațiilor către producție prin construirea și implementarea proceselor automate”, spune Jai Schniepp, directorul platformelor DevOps la compania de asigurări Liberty Mutual. „Dar pentru mine este un lucru mult mai fundamental.” DevOps le permite dezvoltatorilor să dețină aplicații sau anumite componente de software, să le ruleze și să le gestioneze livrarea de la început până la sfârșit. DevOps elimină confuzia de responsabilitate și îndrumă pe toți cei implicați în crearea unei infrastructuri automatizate, conduse de dezvoltatori.”
3. DevOps se referă la colaborare în crearea și livrarea aplicațiilor.
„Mai simplu spus, DevOps este o abordare a producției și livrării de software în care toată lumea lucrează împreună”, spune Gur Staf, președinte și șef al departamentului de automatizare a afacerilor digitale la BMC.
4. DevOps este o conductă
„Asamblarea transportorului este posibilă numai dacă toate piesele se potrivesc împreună.”
„Aș compara DevOps cu o linie de asamblare de mașini”, continuă Gur Staff. – Ideea este de a proiecta și realiza toate piesele în avans, astfel încât acestea să poată fi apoi asamblate fără ajustare individuală. Asamblarea transportorului este posibilă numai dacă toate piesele se potrivesc împreună. Cei care proiectează și construiesc un motor trebuie să aibă în vedere cum să-l monteze pe caroserie sau pe cadru. Cei care fac frânele trebuie să se gândească la roți și așa mai departe. Același lucru ar trebui să fie valabil și cu software-ul.
Un dezvoltator care creează o logică de afaceri sau o interfață cu utilizatorul trebuie să se gândească la baza de date care stochează informații despre clienți, la măsurile de securitate pentru protejarea datelor utilizatorilor și la modul în care toate acestea vor funcționa atunci când serviciul începe să deservească un public mare, poate chiar de milioane de dolari. ."
„A face oamenii să colaboreze și să se gândească la părțile muncii pe care le fac alții, mai degrabă decât să se concentreze doar pe propriile sarcini, este cel mai mare obstacol de depășit. Dacă poți face asta, ai o șansă excelentă de transformare digitală”, adaugă Gur Staff.
5. DevOps este combinația potrivită de oameni, procese și automatizare
Jayne Groll, director executiv al Institutului DevOps, a oferit o analogie grozavă pentru a explica DevOps. În cuvintele ei, „DevOps este ca o rețetă cu trei categorii principale de ingrediente: oameni, proces și automatizare. Majoritatea acestor ingrediente pot fi preluate din alte domenii și surse: Lean, Agile, SRE, CI/CD, ITIL, leadership, cultură, instrumente. Secretul pentru DevOps, ca orice rețetă bună, este cum să obțineți proporțiile și amestecul potrivit ale acestor ingrediente pentru a crește viteza și eficiența creării și lansării aplicațiilor.”
6. DevOps este atunci când programatorii lucrează ca o echipă de Formula 1
„Cursa nu este planificată de la început până la sfârșit, ci dimpotrivă, de la sfârșit la început.”
„Când vorbesc despre ce să mă aștept de la o inițiativă DevOps, mă gândesc la o echipă de curse NASCAR sau Formula 1 ca exemplu”, spune Chris Short, senior manager de marketing al platformei cloud la Red Hat și editor al buletinului informativ al DevOps. – Liderul unei astfel de echipe are un singur scop: să ocupe cel mai înalt loc posibil la finalul cursei, ținând cont de resursele de care dispune echipa și de provocările care i-au întâmpinat. În acest caz, cursa este planificată nu de la început la sfârșit, ci dimpotrivă, de la sfârșit la început. În primul rând, se stabilește un obiectiv ambițios, apoi se stabilesc modalitățile de a-l atinge. Apoi sunt împărțiți în subsarcini și delegate membrilor echipei.”
„Echipa își petrece întreaga săptămână înainte de cursă perfecționând oprirea la boxe. Face antrenament de forță și cardio pentru a se menține în formă pentru o zi de cursă obositoare. Practică lucrul împreună pentru a rezolva orice probleme care pot apărea în timpul cursei. De asemenea, echipa de dezvoltare ar trebui să antreneze abilitățile de a lansa noi versiuni frecvent. Dacă aveți astfel de abilități și un sistem de securitate care funcționează bine, lansarea de noi versiuni în producție are loc și mai des. În această viziune asupra lumii, viteza crescută înseamnă siguranță sporită”, spune Short.
„Nu este vorba de a face „lucru corect””, adaugă Short, „este de a elimina cât mai multe lucruri care stau în calea rezultatului dorit. Colaborează și adaptează-te pe baza feedback-ului pe care îl primești în timp real. Fiți pregătiți pentru anomalii și lucrați pentru a îmbunătăți calitatea pentru a minimiza impactul acestora asupra progresului către obiectivul dvs. Acesta este ceea ce ne așteaptă în lumea DevOps.”
Cum să scalați DevOps: 10 sfaturi de la experți
Doar că DevOps și DevOps în masă sunt lucruri complet diferite. Vă vom spune cum să depășiți barierele pe drumul de la prima la a doua.
Pentru multe organizații, călătoria către DevOps începe ușor și plăcut. Se creează echipe mici pasionate, procesele vechi sunt înlocuite cu altele noi, iar primele succese nu întârzie să apară.
Din păcate, aceasta este doar o sclipire falsă, o iluzie a progresului, spune Ben Grinnell, director general și șeful departamentului digital la consultanța North Highland. Câștigurile timpurii sunt cu siguranță încurajatoare, dar nu ajută la atingerea obiectivului final de adoptare pe scară largă a DevOps în întreaga organizație.
Este ușor de observat că rezultatul este o cultură a diviziunii între „noi” și „ei”.
„Adesea, organizațiile lansează aceste proiecte de pionierat crezând că vor deschide calea pentru DevOps mainstream, fără să se gândească dacă alții vor fi capabili sau dispuși să urmeze această cale”, explică Ben Grinnell. – Echipele pentru implementarea unor astfel de proiecte sunt de obicei recrutate din „varani” încrezători, care au făcut deja ceva asemănător în alte locuri, dar sunt noi în organizația ta. În același timp, aceștia sunt încurajați să încalce și să distrugă regulile care rămân obligatorii pentru toți ceilalți. Este ușor de observat că rezultatul este o cultură a „noi” și „ei” care inhibă transferul de cunoștințe și abilități.”
„Și această problemă culturală este doar unul dintre motivele pentru care DevOps este greu de scalat. Echipele DevOps se confruntă cu provocări tehnice crescute, care sunt tipice companiilor IT cu creștere rapidă”, a declarat Steve Newman, fondator și președinte Scalyr.
„În lumea modernă, serviciile se schimbă de îndată ce este nevoie. Este grozav să implementezi și să implementezi în mod constant funcții noi, dar coordonarea acestui proces și eliminarea problemelor care apar este o adevărată bătaie de cap, adaugă Steve Newman. – În organizațiile cu creștere rapidă, inginerii din echipele interfuncționale se luptă să mențină vizibilitatea asupra schimbării și asupra efectelor în cascadă la nivel de dependență pe care le creează. Mai mult, inginerii nu sunt fericiți când sunt privați de această oportunitate și, ca urmare, le devine mai dificil să înțeleagă esența problemelor care apar.”
Cum să depășești aceste provocări descrise mai sus și să treci la adoptarea în masă a DevOps într-o organizație mare? Experții îndeamnă la răbdare, chiar dacă scopul tău final este să accelerezi ciclul de dezvoltare a software-ului și procesele de afaceri.
1. Amintiți-vă că schimbarea culturii necesită timp.
Jayne Groll, director executiv, Institutul DevOps: „După părerea mea, extinderea DevOps ar trebui să fie la fel de incrementală și iterativă ca și dezvoltarea agilă (și la fel de afectată de cultură). Agile și DevOps pun accent pe echipele mici. Dar, pe măsură ce aceste echipe cresc în număr și integrare, ajungem cu mai mulți oameni care adoptă noi moduri de lucru și, ca urmare, are loc o transformare culturală masivă.”
2. Petrece suficient timp planificând și alegând o platformă
Eran Kinsbruner, evanghelist tehnic principal la Perfecto: „Pentru a se extinde pentru a funcționa, echipele DevOps trebuie să învețe mai întâi să combine procesele, instrumentele și abilitățile tradiționale, apoi să cultive și să stabilizeze încet fiecare fază individuală a DevOps. Totul începe cu o planificare atentă a poveștilor utilizatorilor și a fluxurilor de valoare, urmată de scrierea de software și controlul versiunilor folosind dezvoltarea bazată pe trunchi sau alte abordări cele mai potrivite pentru ramificarea și îmbinarea codului.”
„Apoi vine etapa de integrare și testare, unde este deja necesară o platformă scalabilă pentru automatizare. Aici este important ca echipele DevOps să aleagă platforma potrivită care se potrivește nivelului lor de abilități și obiectivelor finale ale proiectului.
Următoarea fază este implementarea în producție și aceasta ar trebui să fie complet automatizată folosind instrumente și containere de orchestrare. Este important să aveți medii virtualizate în toate etapele DevOps (simulator de producție, mediu QA și mediu de producție real) și să folosiți întotdeauna doar cele mai recente date pentru teste pentru a obține concluzii relevante. Analytics trebuie să fie inteligent și capabil să prelucreze date mari cu feedback rapid și acționabil.”
3. Scoateți vinovăția din responsabilitate.
Gordon Haff, evanghelist RedHat: „Crearea unui sistem și a unei atmosfere care să permită și să încurajeze experimentarea permite ceea ce sunt cunoscute drept eșecuri de succes în dezvoltarea agilă a software-ului. Acest lucru nu înseamnă că nimeni altcineva nu este responsabil pentru eșecuri. De fapt, identificarea cine este responsabil devine și mai ușoară, deoarece „a fi responsabil” nu mai înseamnă „a provoca un accident”. Adică, esența responsabilității se schimbă calitativ. Patru factori devin critici: amploarea perturbării, abordările, procesele de producție și stimulentele.” (Puteți citi mai multe despre acești factori în articolul lui Gordon Huff „Lecții DevOps: 4 aspecte ale experimentelor sănătoase.”)
4. Goliți calea înainte
Ben Grinnell, director general și șeful departamentului digital la consultanța North Highland: „Pentru a atinge amploarea, recomand lansarea unui program de „curare a căii” împreună cu proiecte de pionierat. Scopul acestui program este de a curăța gunoiul pe care pionierii DevOps îl lasă în urmă, cum ar fi reguli învechite și lucruri de genul acesta, astfel încât calea de urmat să rămână clară.”
„Oferiți oamenilor sprijin organizațional și impuls printr-o comunicare care depășește cu mult grupul de pionier, celebrând pe scară largă succesele noilor moduri de lucru. Antrenează oamenii care sunt implicați în următorul val de proiecte DevOps și sunt nervoși în legătură cu utilizarea DevOps pentru prima dată. Și amintiți-vă că acești oameni sunt foarte diferiți de pionierii.”
5. Democratizează instrumentele
Steve Newman, fondator și președinte Scalyr: „Uneltele nu ar trebui să fie ascunse de oameni și ar trebui să fie relativ ușor de învățat pentru oricine dorește să pună timp. Dacă capacitatea de a interoga jurnalele este limitată la trei persoane „certificate” să folosească un instrument, veți avea întotdeauna maximum trei persoane disponibile pentru a gestiona problema, chiar dacă aveți un mediu de calcul foarte mare. Cu alte cuvinte, există un blocaj aici care poate duce la consecințe (de afaceri) grave.”
6. Creați condiții ideale pentru lucrul în echipă
Tom Clark, șeful platformei comune la ITV: „Poți face orice, dar nu totul deodată. Așadar, stabiliți obiective mari, începeți cu mici și mergeți mai departe în iterații rapide. De-a lungul timpului, îți vei dezvolta o reputație pentru a duce lucrurile la bun sfârșit, așa că și alții vor dori să folosească metodele tale. Și nu vă faceți griji pentru a construi o echipă extrem de eficientă. În schimb, oferiți oamenilor condiții ideale de muncă, iar eficiența va urma.”
7. Nu uitați de Legea lui Conway și de panourile Kanban
Logan Daigle, director de livrare de software și strategie DevOps la CollabNetVersionOne: „Este important să înțelegem consecințele Legii lui Conway. În parafraza mea liberă, această lege prevede că produsele pe care le creăm și procesele pe care le folosim pentru a face acest lucru, inclusiv DevOps, se dovedesc a fi structurate în același mod ca și organizația noastră.”
„Dacă există o mulțime de silozuri într-o organizație și controlul își schimbă mâinile de multe ori atunci când se planifica, se construiește și se lansează software, efectul scalarii va fi zero sau de scurtă durată. Dacă o organizație formează echipe interfuncționale în jurul produselor care sunt finanțate cu accent pe piață, atunci șansele de succes cresc dramatic.”
„Un alt aspect important al scalarii este afișarea tuturor lucrărilor în curs (WIP, workinprogress) pe panourile Kanban. Când o organizație are un loc unde oamenii pot vedea aceste lucruri, încurajează foarte mult colaborarea, care are un impact pozitiv asupra extinderii.”
8. Căutați cicatrici vechi
Manuel Pais, consultant DevOps și coautor al lucrării Team Topologies: „Luarea practicilor DevOps dincolo de Dev și Ops în sine și încercarea de a le aplica altor funcții nu este o abordare optimă. Acest lucru va avea cu siguranță un anumit impact (de exemplu, prin automatizarea controlului manual), dar se poate realiza mult mai mult dacă începem cu înțelegerea proceselor de livrare și feedback.”
„Dacă există cicatrici vechi în sistemul IT al unei organizații - proceduri și mecanisme de management care au fost implementate ca urmare a incidentelor din trecut, dar și-au pierdut relevanța (din cauza modificărilor produse, tehnologii sau procese) - atunci cu siguranță trebuie eliminate. sau netezite, mai degrabă decât automatizarea proceselor ineficiente sau inutile.”
9. Nu creați opțiuni DevOps
Anthony Edwards, director de operațiuni la Eggplant: „DevOps este un termen foarte vag, astfel încât fiecare echipă ajunge să aibă propria sa versiune de DevOps. Și nu este nimic mai rău atunci când o organizație are brusc 20 de soiuri de DevOps care nu se înțeleg prea bine împreună. Este imposibil ca fiecare dintre cele trei echipe de dezvoltare să aibă propria interfață specială între dezvoltare și managementul produsului. Nici produsele nu ar trebui să aibă propriile așteptări unice pentru gestionarea feedback-ului atunci când sunt transferate la un simulator de producție. Altfel, nu veți putea niciodată să scalați DevOps.”
10. Predicați valoarea de afaceri a DevOps
Steve Newman, fondator și președinte Scalyr: „Lucrați pentru a recunoaște valoarea DevOps. Învățați și simțiți-vă liber să vorbiți despre beneficiile a ceea ce faceți. DevOps este o economie incredibilă de timp și bani (doar gândiți-vă: mai puțin timp de nefuncționare, timp mediu mai scurt până la recuperare), iar echipele DevOps trebuie să sublinieze (și să predice) neobosit importanța acestor inițiative pentru succesul afacerii. Astfel puteți extinde cercul de aderenți și puteți crește influența DevOps în organizație.”
BONUS
Pe Propriul nostru DevOps va sosi pe 13 septembrie - da, Red Hat, ca producător de software, are propriile echipe și practici DevOps.
Inginerul nostru Mark Birger, care dezvoltă servicii de automatizare internă pentru alte grupuri din cadrul organizației, își va spune propria poveste în limba rusă pură - cum echipa Red Hat DevOps a migrat aplicațiile din mediile virtuale Hat Virtualization gestionate de Ansible la un format de container complet pe platforma OpenShift.
Dar asta nu este tot:
Odată ce organizațiile au mutat sarcinile de lucru în containere, este posibil ca metodele tradiționale de monitorizare a aplicațiilor să nu funcționeze. În a doua discuție vom explica motivația noastră pentru schimbarea modului în care ne logăm și vom arăta continuarea drumului care ne-a condus către metode moderne de logare și monitorizare.
Sursa: www.habr.com