Prima dată, când am susținut o prelegere cu titlu de "Incursiunea DevOps in spațiul Enterprise", a fost la finalul anului 2014 în cadrul conferinței DevConFu. Ulterior, am susținut prelegerea cu mai multe ocazii pe parcursul anului 2015 la diferite conferințe din Europa. Un timp, am considerat-o o "temă închisă" și nu am fost interesat să o extind, până când mi s-a solicitat să o susțin din nou în anul 2016 și mai apoi în anul 2017.
Enterprise este o noțiune folosită excesiv. Majoritatea o asociază cu procese lente și ineficiente. Nimeni nu vrea să aibă de- a face cu așa ceva! În același timp, de fiecare dată când întreb publicul: "Câți dintre voi ați lucrat într-o companie Enterprise?" — peste 95% ridică mâna. Cumva, natura umană ne face să preferăm modelele simple ale lumii. A fi o companie start-up vs. a fi o companie enterprise, dezvoltarea cu microservicii vs. bătălia cu un monolit? Suntem oare majoritatea de partea nefastă/greșită? Probabil că nu.
Am auzit o mulțime de definiții ale DevOps și probabil că voi intra în contact cu mai multe în următorii ani, însă ceea ce am auzit cel mai des este faptul că DevOps este exclusiv corelat doar cu mediile start-up. Nu sunt de acord cu această afirmație. Cred cu tărie că start-upurile de succes vor intra (oarecum) automat în cultura DevOps pentru că reprezintă singura modalitate de a supraviețui și cuceri noi piețe, date fiind toate restricțiile de resurse sau timp. Așadar, nu este tocmai interesantă o discuție despre DevOps în cadrul start-upurilor, pentru că prin definiție prezintă o abordare diferită a afacerii (până când se dezvoltă suficient de mult și devin desigur enterprise).
DevOps abordează multe aspecte ale companiilor mici și mari implicate în industria IT, care este prezentă aproape peste tot. Introducerea principiilor DevOps în întreprinderi cu o evoluție lentă va duce la descoperirea de ineficiențe și va contribui la optimizarea proceselor și echipelor. Discuția despre DevOps în cadrul întreprinderii este mult mai importantă decât reflectarea asupra experiențelor dobândite prin unele începuturi ultraperformante.
Permiteți-mi să vă prezint povestea lui Jack, Administratorul de Sistem.
A fost o dată în cadrul întreprinderii:
Jack știe ce are de făcut. Jack începe să lucreze.
După câteva zile:
După alte câteva zile:
La final, a terminat și documentat, iar serverele sunt predate echipei de dezvoltare. Jack este fericit. Și-a făcut treaba bine! Cerințele sunt îndeplinite complet, documentele și formularele sunt completate corespunzător instrucțiunilor Departamentului de operațiuni. Toate e-mailurile sunt trimise, toate animalele sunt hrănite.
Dezvoltatorii nu știu cine este Jack și nici unde este biroul lui. Singura soluție prin care pot schimba ceva în medius (în sens "oficial") este de a raporta managerului, care va folosi un sistem de identificare a problemelor organizației pentru a depune un ticket la Departament de operațiuni, de unde Jack îl va ridica. Pentru a accelera procesul, managerul de proiect trimite un e-mail și lui Jack.
Jack trebuie să se supună și să implementeze solicitarea de modificare neclară așa cum înțelege să o facă. Ka-boom! Dezvoltatorii nu pot livra. Încep să se plângă. Jack trebuie să repare serverele. Lucrează toată noaptea.
Lucrurile se înrăutățesc în timp. Din ce în ce mai multe solicitări de modificare intră în sistem. Constatând că procesul de modificare a infrastructurii este lent, dezvoltatorii încep să efectueze personal unele modificări pentru a accelera lucrurile.
Infrastructura intră rapid în starea denumită NECUNOSCUT:
Într-o oarecare măsură, dezvoltatorii implementează întreaga funcționalitate și tipul de lucrări în mediul de dezvoltare (și "pe propriul meu calculator"). Este timpul să se treacă la etapa QA:
Și adăugăm mai multe medii:
Lucrurile se complică. Documentația nu mai deservește scopul. Nimeni nu știe cum să configureze bestia. Jack este copleșit de muncă. Nu reușește să facă față situației. Soluția? Să implicăm mai multe persoane:
Încă o dată, problema se soluționează. Nu permanent, dar pe moment. Se apropie data limită. Producția devine cel mai important mediu:
Producția ia foc. Monitorizarea nu ajută. Echipa de operațiuni monitorizează întregul proces ca întotdeauna: încărcarea CPU, disponibilitatea spațiului pe disc, încărcarea rețelei, însă le este străină metrica esențială a aplicației cum ar fi numărul solicitărilor clienților, câte sunt finalizate cu succes, câți clienți activi există în sistem, etc. . Astfel, tabloul de bord este verde mascând problema aplicației:
Managerii de proiect sunt contactați de client mult mai devreme de momentul în care echipa își dă seama că există o problemă în aplicație. Durează câteva ore sau zile pentru a se descoperi ce se întâmplă. Desigur, după câteva incidente, sistemul se repară și funcționează chiar mai bine într-o oarecare măsură. Sau poate că nu. În orice caz, se pierde încrederea clientului.
Finalul poveștii. Sau cel puțin a primului capitol.
Când mi-am întrebat publicul dacă povestea le sună cunoscut, am descoperit câteva persoane curajoase care au ridicat mâna și câteva care au dat din cap. Au fost și persoane care au strigat cu voce tare: "O, da!".
Problema nu este reprezentată de tehnologie, problema este lipsa de comunicare, lipsa de colaborare între departamentele de dezvoltare și operațiuni și gestionarea rolurilor de dezvoltare și operațiuni ca etape izolate ale aceluiași proces.
Este situația cea mai des întâlnită în multe întreprinderi: comunicarea este afectată și apare doar la nivelul ședințelor managementului sau sistemelor de identificare a problemei:
Aplicațiile noi sau actualizate sunt transmise ca atare de la departamentul de dezvoltare la cel de producție. Ciclul de informare este lent și/sau incomplet. În ce privește informațiile despre cât de ineficient este modelul aplicației sau cât de neconvenabil este să fie dezvoltată, configurată sau monitorizată aplicația respectivă, acestea nu ajung de fiecare dată înapoi la dezvoltatori sau sunt considerate lipsite de importanță. Dezvoltatorii continuă să producă acel cod care implică nopți și weekenduri de lucru prelungite pentru operatorii care trebuie să îl facă să ruleze.
Pe de altă parte, Departamentul de operațiuni ar putea prefera să se ascundă în spatele unor platforme "standard" și să-i oblige pe dezvoltatori să creeze noi aplicații folosind tehnologiile depășite. Dorința de standardizare poate ajunge la extremă și produce structuri destul de rigide. Așa arată aceste structuri unde împărțirea pe departamente atinge apogeul:
Desigur că atunci când cerințele de dezvoltare și capacitățile de operare nu sunt aliniate sau sunt aliniate foarte târziu în cadrul procesului, ajungem în situația nedorită de nimeni. Apar o serie de probleme neașteptate.
Acesta este momentul în care întreprinderile necesită transformarea DevOps, ceea ce nu implică instrumente și tehnologii (deși ajută), ci comunicare îmbunătățită, ciclu de informare scurtat și nivel mai ridicat de empatie.
Un model de comunicare pentru DevOps se va obține din două (sau mai multe) piramide cu discuții la nivelul superior așa cum se indică în următorul desen:
Imaginea de mai sus se aseamănă într-o oarecare măsură cu o echipă de fotbal. Cele două echipe au obiective care intră în conflict, însă respectă anumite reguli ale jocului. Dar adevăratul scop nu este de a învinge cealaltă echipă (deși aceasta implică beneficii pentru departamentul lor), ci de a aduce o bucurie spectatorilor jocului, care, în acest caz, sunt clienții. Nimeni nu este interesat să urmărească un joc, în care o echipă înscrie 20 de goluri iar cealaltă niciunul; nu mulți sunt cei interesați să urmărească un joc în care toți jucătorii sunt sancționați cu cartonașul roșu din cauza unei conduite necorespunzătoare. Atunci când rivalii cu un nivel aproape egal manifestă cele mai bune aptitudini și demonstrează fair-play și respect, jocul va rămâne în memoria spectatorilor ca ceva captivant și care merită văzut.
Analogia cu jocul de fotbal probabil că nu se aplică integral industriei IT, însă o parte din aspectele sale mi se par interesante.
Companii enterprise - divizați silozurile, investiti într-o mai bună comunicare, sporiți empatia! Dar nu înlocuiți transformarea DevOps cu selectarea unui instrument software.
de Mihai Varga
de Călin Diniș , Mihai Tentis
