Ce naiba este DevOps?

O scurtă istorie a timpului

Pentru a înțelege DevOps, trebuie să călătorim înapoi în timp până la bătrânețe când nu existau altceva decât programatori.

După cum ne învață Tao:

Programatorii de altădată erau misterioși și profundi. Nu putem înțelege gândurile lor, așa că tot ceea ce facem este să le descriem aspectul:

• Conștient, ca o vulpe care traversează apa
• Alertă, ca un general pe câmpul de luptă
• Amabilă, ca o gazdă care își salută oaspeții
• Simplu, ca niște blocuri de lemn necioplite
• Opace, ca niște bazine negre în peșteri întunecate

Programatorul a dat naștere limbajului mașină. Limbajul mașină a dat naștere asamblatorului. Asamblatorul a dat naștere compilatorului. Acum există mii de limbi. Fiecare limbă are scopul ei, oricât de umil. Fiecare limbă exprimă Yin-ul și Yang-ul software-ului. Fiecare limbă își are locul în cadrul software-ului.

La acea vreme, birourile de dezvoltare de software se numeau în mare parte laboratoare, iar programatorii erau oameni de știință. Pentru a crea o aplicație bună, programatorii au trebuit să înțeleagă pe deplin problema pe care o rezolvă aplicația. Ei trebuiau să știe unde va fi folosită aplicația și ce fel de sistem o va rula. În esență, programatorii știau totul despre aplicația lor, de la specificare, până la dezvoltare, până la implementare și asistență.

Și apoi natura umană a intervenit și am început să cerem mai mult. Mai multă viteză, mai multe funcții, mai mulți utilizatori, mai mult totul.

Fiind creaturi modeste, umile și pașnice, programatorii au avut foarte puține șanse să supraviețuiască unei astfel de explozii de utilizatori nevoiași care cer mereu mai mult. Cea mai bună șansă de a învinge a fost să începi să evoluezi în direcții diferite și să creezi caste. Curând, programatorii au dispărut ca strămoși ai noilor rase numite dezvoltatori, ingineri software, administratori de rețea, dezvoltatori de baze de date, dezvoltatori web, arhitecți de sistem, ingineri QA și multe altele. Evoluția rapidă și adaptarea la provocările din lumea exterioară au devenit parte din ADN-ul lor. Noua castă ar putea evolua în câteva săptămâni. Dezvoltatorii web au devenit dezvoltatori back-end, dezvoltatori front-end, dezvoltatori PHP, dezvoltatori Ruby, dezvoltatori Angular... totul se ducea naibii.

Curând, toți au uitat că provin de la același tată, un Programator. Un om de știință simplu și pașnic care a vrut doar să facă din lume un loc mai bun. Au început să se lupte între ei, susținând că fiecare dintre ei este un adevărat descendent al „Programatorului” și că sângele lor este mai curat decât alții.

Odată cu trecerea timpului, ei și-au redus interacțiunea la minimum și au vorbit unul cu celălalt doar atunci când chiar trebuia. Au încetat să sărbătorească succesul membrilor familiei lor îndepărtate și, în cele din urmă, au încetat chiar să trimită o carte poștală din când în când.

Dacă și-ar căuta doar sentimentele, ar descoperi că scânteia Programatorului era în inimile lor, așteptând să strălucească și să aducă pace în galaxie.

În cursa lor egoistă și egocentrică de a cuceri lumea, descendenții programatorilor au uitat însuși scopul muncii lor - rezolvarea problemelor clienților lor. Clienții au început să simtă durerea unui astfel de comportament, deoarece proiectele au fost întârziate, prea scumpe sau chiar au eșuat.

Din când în când, o stea strălucitoare strălucea și cineva avea o inspirație pentru a încerca să facă pace între Descendenți. Au venit cu Cascada. Aceasta a fost o idee genială, deoarece a folosit faptul că diferite grupuri de dezvoltatori comunicau doar atunci când era necesar. Când un grup și-a terminat partea din muncă, a comunicat cu următorul grup pentru a trimite munca în jos prin proces și nu s-a mai uitat la el.

Acest lucru a funcționat o vreme, dar, ca de obicei, oamenii (Clienții) și-au dorit din nou mai mult. Au vrut să ia parte mai activ la întregul proces de creare a software-ului, să-și spună mai des cu părerea și să ceară schimbări chiar și atunci când era prea târziu.

Proiectele software au devenit atât de predispuse la eșec încât a fost acceptat ca standard industrial. Statisticile au arătat că peste 50% dintre proiecte au eșuat și se pare că nu a fost nimic de făcut în acest sens (ZDNet, CNet)

Fiecare generație a avut câțiva indivizi cu mintea deschisă care știau că toate aceste grupuri de dezvoltatori trebuie să găsească o modalitate de a lucra împreună, de a comunica și de a fi flexibili pentru a se asigura că clienții lor vor primi cea mai bună soluție posibilă. Există urme ale acestor încercări încă din 1957, ale colegilor marelui John Von Neumann. Cu toate acestea, a trebuit să așteptăm până la începutul lui 2001 pentru a începe revoluția, când o duzină murdară a creat un Manifest Agile.

Manifestul Agile se bazează pe douăsprezece principii:

1. Satisfacția clienților prin livrarea timpurie și continuă a software-ului valoros
2. Bun venit cerințele în schimbare, chiar și în dezvoltarea târzie
3. Software-ul funcțional este livrat frecvent (în mai degrabă săptămâni decât luni)
4. Cooperare strânsă, zilnică, între oamenii de afaceri și dezvoltatori
5. Proiectele sunt construite în jurul unor indivizi motivați, în care ar trebui să aibă încredere
6. Conversația față în față este cea mai bună formă de comunicare (colocație)
7. Software-ul de lucru este principala măsură a progresului
8. Dezvoltare durabilă, capabilă să mențină un ritm constant
9. Atenție continuă pentru excelența tehnică și design bun
10. Simplitatea – arta de a maximiza cantitatea de muncă neefectuată – este esențială
11. Echipe de auto-organizare
12. Adaptare regulată la schimbarea circumstanțelor

Manifestul Agile a fost primul pas important în aducerea păcii în Galaxie și restabilirea echilibrului Forței. Pentru prima dată într-o perioadă foarte lungă de timp, conectarea tuturor părților interesate în procesul de dezvoltare a software-ului sa bazat pe modul cultural și „uman”, cât și pe o manieră procedurală și mecanizată. Oamenii au început să vorbească între ei, să se întâlnească în mod regulat și să facă schimb de idei și comentarii tot timpul. Au realizat că au mult mai multe în comun decât au crezut, iar clienții au devenit parte a echipei, nu doar un factor extern despre care se aștepta să trimită banii și să nu pună întrebări.

Mai erau câteva obstacole de depășit, dar viitorul părea mai luminos ca niciodată. A fi agil înseamnă a fi deschis și dispus să te adaptezi la schimbările constante. Cu toate acestea, cu prea multe schimbări, este dificil să rămâi concentrat pe obiectivul final și livrarea. Și așa a luat viață Lean Software Development.

Prinși de LSD (joc de cuvinte) și riscând să fie exilați și proscriși, unii dintre descendenți au căutat soluții în afara castei lor și a industriei software. Au găsit salvarea în lucrările unui mare producător de mașini. Toyota Production System a fost uimitor prin simplitatea sa și a fost atât de evident încât producția sa slabă poate fi aplicată cu ușurință în dezvoltarea de software.

Există 7 principii ale lean:

1. Eliminați deșeurile
2. Construiți calitatea în
3. Creați cunoștințe (amplificați învățarea)
4. Amânarea angajamentului (Decideți cât mai târziu posibil)
5. Livrați cât mai repede posibil
6. Respectați oamenii (împuterniciți echipa)
7. Optimizați întregul

Adăugate pe lângă Agile, principiile Lean au susținut mentalitatea și concentrarea pe a face lucrurile potrivite, fiind în același timp flexibile pe parcursul întregului proces.

Odată ce Agile și Lean au fost adoptate de echipele de dezvoltare software, a mai fost nevoie de un singur pas pentru a aplica întregul set de principii IT ca întreg - ceea ce ne-a adus în sfârșit la DevOps!

Intră în DevOps - Autostradă cu trei benzi

Viziunea veche a echipelor de dezvoltare software includea analiști de afaceri, arhitecți de sistem, dezvoltatori front-end, dezvoltatori back-end, testeri și așa mai departe. Optimizarea procesului de dezvoltare a software-ului, inclusiv principiile agile și lean, sa concentrat în mare parte pe acestea. Odată ce aplicația a fost „gata de producție”, a fost trimisă către „Operațiuni”, inclusiv ingineri de sisteme, ingineri de lansare, DBA, ingineri de rețea, profesioniști în securitate etc. Înlăturarea marelui zid dintre Dev și Ops este principala forță motrice a DevOps .

DevOps este rezultatul implementării principiilor lean în întregul flux de valoare IT. Fluxul de valoare IT extinde dezvoltarea în producție, combinând toate „rudele îndepărtate” care provin de la programatorul original.

Cea mai bună explicație a soluțiilor DevOps este dată de Gene Kim, iar dacă nu ați citit Proiectul Phoenix vă sugerez să vă faceți ceva timp și să o faceți.

Nu ar trebui să angajați un inginer DevOps, iar DevOps nu ar trebui să fie un departament nou în IT. DevOps este o cultură, o mentalitate și face parte din IT ca întreg. Nu există instrumente care să facă din IT o organizație DevOps și niciun nivel de automatizare nu va permite echipelor dumneavoastră să ofere valoare maximă clienților dumneavoastră.

DevOps este de obicei menționat ca metoda din trei căi, dar le văd ca pe trei benzi ale aceleiași autostrăzi. Începi pe banda unu, apoi accelerezi și treci pe banda a doua și, în cele din urmă, treci cu viteză pe a treia bandă.

• Banda unu - Performanța sistemului în ansamblu este punctul central principal și este accentuată asupra performanței oricărui element individual al sistemului

• Banda a doua - Asigurați-vă că există o buclă de feedback constantă trimisă în amonte și nu ignorată

• Banda a treia - Încurajează experimentele, îmbunătățirea constantă și eșuează rapid

Lane one - Trecerea la viteză

Înțelegerea importanței întregului sistem și prioritizarea corectă a elementelor de lucru este primul lucru pe care trebuie să-l învețe o organizație IT atunci când adoptă principiile DevOps. Nimănui din fluxul de valoare IT nu are voie să creeze un blocaj și să reducă fluxul de muncă.

Asigurarea fluxului de lucru neîntrerupt este scopul final pentru toți cei incluși în proces. Indiferent de rolul pe care îl are o persoană sau o echipă, este imperativ ca acestea să caute să obțină o înțelegere profundă a sistemului. Adoptarea acestui mod de gândire are un impact direct asupra calității, deoarece defectele nu sunt niciodată trimise în flux, deoarece ar cauza blocaje.

A se asigura că munca nu se blochează nu este suficient. O organizație productivă ar trebui să caute întotdeauna să crească fluxul. Există numeroase metodologii pentru a crește fluxul. Puteți găsi o soluție în Teoria constrângerilor, Six Sigma, Lean sau Toyota Production System. Simțiți-vă liber să alegeți oricare dintre acestea, să veniți cu ale dvs. sau să le combinați.

Principiilor DevOps nu le pasă de ce echipă faceți parte, dacă sunteți arhitect de sistem, DBA, QA sau administrator de rețea. Aceleași reguli se aplică tuturor și toți trebuie să urmeze două principii simple:

• Păstrați fluxul sistemului neîntrerupt
• Creșteți și optimizați fluxul de lucru în orice moment

Banda doi - Pregătiți-vă

Fluxul neîntrerupt al sistemului este unidirecțional și este de așteptat să treacă de la dezvoltare la operațiuni. Într-o lume ideală, aceasta înseamnă că software-ul este creat rapid, de înaltă calitate, implementat în producție și oferind valoare clienților.

Cu toate acestea, DevOps nu este utopie și, dacă livrarea unidirecțională ar fi posibilă, metoda cascadă ar fi suficientă. Evaluarea livrabilelor și comunicarea fluxului este foarte importantă pentru a asigura calitatea. Primul canal de comunicare „în amonte” care trebuie implementat este Ops to Dev.

Este ușor să-ți dai un mare cinci, dar a cere feedback și a oferi feedback este modalitatea de a vedea imaginea reală. Este imperativ ca fiecare pas mic în aval să fie urmat de o confirmare instantanee în amonte.

Nu contează modul în care stabiliți bucla de feedback. Puteți invita dezvoltatorii să se alăture reuniunilor echipei de asistență sau puteți aduce administratorul rețelei la planificarea săptămânală de sprint. Atâta timp cât feedback-ul dvs. este disponibil și comentariile sunt preluate și gestionate, organizația dvs. accelerează pe autostrada DevOps.

Banda trei - Warp 10

Calea rapidă DevOps nu este pentru cei slabi la minte. Pentru a intra pe calea rapidă DevOps, organizația dvs. trebuie să fie suficient de matură. Este vorba de asumarea riscurilor și de a învăța din eșec, de a experimenta continuu și de a accepta că repetiția și practica sunt condiția prealabilă pentru stăpânire. Destul de des veți auzi termenul Kata, iar acest lucru este pentru un motiv. Antrenamentul continuu și repetarea duce la stăpânire deoarece face ca mișcările complexe să devină o rutină.

Dar înainte de a începe să combinați mișcările, este imperativ să stăpâniți mai întâi fiecare pas individual.

„Ceea ce este potrivit pentru Maestrul nu este potrivit pentru novice. Trebuie să înțelegi Tao înainte de a transcende structura.”

DevOps Third Way/Fast Lane include alocarea de timp pentru experimentarea continuă în fiecare zi, recompensarea constantă a echipei pentru asumarea riscurilor și introducerea defecțiunilor în sistem pentru a crește rezistența.

Pentru a vă asigura că organizația dvs. nu va imploda atunci când implementați aceste tipuri de măsuri, trebuie să creați bucle frecvente de feedback între toate echipele, asigurându-vă în același timp că toate blocajele sunt clare și fluxul sistemului este neîntrerupt.

Implementarea acestor măsuri face ca organizația dumneavoastră să fie alertă în orice moment și capabilă să răspundă provocărilor rapid și eficient.

Rezumat - Lista de verificare a organizației DevOps

Iată o listă de verificare pe care o puteți folosi pentru a valida modul în care DevOps a activat organizația dvs. IT. Vă rugăm să nu ezitați să comentați articolul și să adăugați propriile puncte.

• Nu există niciun zid între echipa de dezvoltare și echipa de operațiuni. Ambele fac parte din același proces
• Munca care este trimisă de la o echipă la alta este întotdeauna verificată și de calitate superioară
• Nu există nicio „gândă” de muncă și toate blocajele sunt gestionate
• Echipa de dezvoltare nu folosește timpul de operațiuni pentru activitățile sale, deoarece implementarea și întreținerea fac parte din aceeași casetă de timp
• Echipa de dezvoltare nu livrează codul pentru implementare la ora 17:00 vineri, lăsând operațiunile pentru a-și curăța munca în weekend
• Mediile de dezvoltare sunt standardizate, iar operațiunile le pot reproduce și scala cu ușurință în producție
• Echipa de dezvoltare poate livra versiuni noi pe măsură ce consideră adecvate, iar operațiunile le pot implementa cu ușurință în producție
• Există linii de comunicare clare între toate echipele
• Toți membrii echipei au timp să experimenteze și să lucreze la îmbunătățirea sistemului
• Defectele sunt introduse (sau simulate) și tratate în sistem în mod regulat. Lecțiile învățate din fiecare experiment sunt documentate și împărtășite tuturor persoanelor relevante. Gestionarea incidentelor este o rutină și în mare parte este tratată într-un mod cunoscut

Concluzie

Folosirea instrumentelor DevOps moderne precum Chef, Docker, Ansible, Packer, Troposphere, Consul, Jenkins, SonarQube, AWS etc. nu înseamnă că aplicați principiile DevOps. DevOps este un mod de a gândi. Cu toții facem parte din același proces, împărțim același timp și oferim valoare împreună. Fiecare persoană care participă la procesul de livrare a software-ului poate accelera sau încetini întregul sistem. Un bug creat în timpul dezvoltării poate distruge sistemul, precum și configurația greșită a firewall-ului.

Toți oamenii fac parte din DevOps și, odată ce organizația dvs. înțelege acest lucru, instrumentele și tehnologia tehnologică care vă vor ajuta să o gestionați vor apărea în mod magic.