DevOps-ul este un fenomen tot mai întâlnit astăzi în mediul IT și reprezintă probabil viitorul modului în care ne organizăm munca în comunitățile noastre. Vom vedea în rândurile următoare de unde a apărut nevoia pentru el, cum se prezintă astăzi și de ce este considerat o cultură, nu o metodologie. La final, un exemplu concret ne va arăta cum este adoptat DevOps-ul într-o companie clujeană.
Domeniul IT a trecut de-a lungul timpului prin mai multe faze atât tehnologice cât și organizaționale. Fie că ne dăm seama sau nu, modul în care ne organizăm munca în cadrul echipelor a depins într-o oarecare măsură, de nivelul tehnologic de la momentul respectiv.
Modelul waterfall de dezvoltare software a apărut (ca faze, nu ca nume), în 1956, fiind probabil, primul mod de standardizare al acestui proces. El cuprinde în mare următoarele etape: analiză și design, implementare, testare și întreținere.
Limitările tehnologice au permis menținerea acestui proces o perioadă îndelungată de timp. Software-ul era rulat fie pe mainframe-uri la firma care crea software-ul, fie era livrat static clientului (CD, dischete etc).
De asemenea, au apărut roluri bine definite în organizații: dezvoltatori (programatori), administratori de sisteme, administratori baze de date, ingineri rețele etc. .
Dar, cu timpul, a apărut o problemă: clientul.
De multe ori părea să fie cam indecis și chiar ambiguu. Atât de ambiguu încât un coleg din firma noastră și-a scris lucrarea de doctorat având ca temă "Ambiguitatea în cerințele software". Dar mai gravă era indecizia. Aceasta genera mereu schimbări în cerințe, care duceau mai apoi la schimbări în design, implementare și așa mai departe.
Pentru că vechiul mecanism waterfall nu făcea față, de multe ori, mediului acesta dinamic, situația a fost salvată de metodologia Agile.
Agile-ul era un waterfall mai mic și mai scurt, repetat de mai multe ori, până când produsul era terminat sau clientul satisfăcut. Desigur, comparația aceasta e grosolană și suprasimplifică Agile-ul, tema fiind mult mai complexă și interesantă.
Ce ne interesează pe noi în cazul de față este că, în cadrul companiilor, împărțirea atribuțiilor a rămas aceeași: programatorii dezvoltă aplicația (iterativ, de data aceasta), iar ceilalți își văd în continuare de sistemele, bazele de date și rețelele lor.
Presiunea, însă, pe care o pune mediul online asupra echipelor implicate în dezvoltarea și întreținerea aplicațiilor contemporane, care sunt fie aplicații web, fie depend în mod intrinsic de web), au determinat unele organizații să facă un pas important: au dărâmat zidurile imaginare care s-au înălțat tot mai mult între echipe.
Au reușit să așeze un administrator între developer-i și, probabil surprinzător, au avut rezultate la care nici ei nu s-au așteptat: mai puține bug-uri, mai multe deploy-uri, mai puțin downtime și reveniri mai rapide în caz de probleme.
Datorită acestei apropieri între cele două echipe, mișcarea a primit numele de DevOps (în unele organizații partea de System Administration poartă și numele de Operations).
Nevoia de a apropia domeniile Development de Operations a generat mai multe abordări în cadrul organizațiilor IT.
Tot mai multe companii fac recrutări pe poziții de DevOps. Candidatul ideal, în cele mai multe din cazuri, este reprezentat de un administrator rockstar având competențe în administrarea de sisteme, deployment-uri de aplicații, baze de date, scripting, programare și, dacă se poate, puțin management. În alte situații companiile creează echipe noi DevOps care să stea între echipa clasică de developer-i și echipa de administratori.
Persoanele de tip "rockstar" pot ajuta o echipă, aducând un bagaj mai mare de cunoștințe și experiență de care să beneficieze toți membrii echipei, mai ales dacă aceste persoane știu să împartă informația. O denumire mai potrivită pentru acest angajat este full-stack developer.
Unele companii, ca Etsy, preferă totuși să-i evite, în favoarea unor angajați de nivel junior pe care să îi pregătească ei. Motivul pentru care preferă această abordare îl reprezintă faptul că, din experiența lor, administratorii rockstar nu lucrează în echipă la fel de bine ca ceilalți angajați. Ei preferă echipe bine închegate, care să funcționeze ca un tot unitar și care să nu depindă de o singură persoană.
Deși unii ar putea considera că Etsy face o generalizare prea simplistă, adevărul este că recrutarea unui full-stack developer este foarte dificilă, existând puține persoane pe piață cu aceste competențe. Pentru un proiect sau o companie, formarea de noi angajați care să lucreze bine împreună reprezintă o abordare mai eficientă economic și mai sustenabilă.
În privința celei de-a doua abordări, putem să presupunem că, pe termen lung, interpunerea unei echipe noi între două echipe care trebuie să comunice bine nu poate avea efectul scontat. Pe lângă faptul că mediul de comunicare se sparge în două (dev - devops - ops), trebuie găsită și o distribuire eficientă a responsabilităților.
Modelul care va fi prezentat în exemplul de la finalul articolului e un exemplu de apropiere treptată a echipelor, având ca scop crearea unei mentalități și a unui mod de a face lucrurile in spiritul DevOps.
Primul impuls al celor care încearcă să definească DevOps-ul este să afirme că este o metodologie.
Metodologia se referă, în general, la analiza teoretică a metodelor aplicate într-un domeniu. De exemplu, când discutăm despre metodologia Agile, ne referim la un set întreg de metode și bune practici pe care aceasta le propune, având în spate o argumentare teoretică și chiar practică.
DevOps-ul nu vine să înlocuiască Agile-ul ci, în cel mai bun caz, doar să-l completeze.
DevOps-ul propune doar ruperea barierelor care s-au format între partea de Dev (programatorii) și partea de Ops (administratorii) din spatele proiectelor software. Acest demers afectează întreaga dinamică din organizație, implicând toate nivelele ierarhice în acest proces. Astfel, în organizația care practică DevOps, există deja o cultură a comunicării și a rezolvării de probleme în echipe mixte.
Răspunsul la această întrebare îl oferă raportul "Puppet 2015 State of DevOps". Acest raport este pregătit anual de Puppetlabs şi reprezintă rezultatul statistic oferit de răspunsurile a peste 4900 de angajaţi în IT, de pe toate poziţiile şi din mai multe regiuni geografice. Concluziile acestui raport sunt că organizaţiile IT cu performanţe ridicate:
Fac deploy de 30 de ori mai des.
Au timpi de lead de 200 de ori mai scurţi (intervalul de la scrierea codului până când ajunge în producţie).
Au de 60 de ori mai puţine eşecuri în producţie.
Aceste numere reprezintă comparaţia între companiile cu cele mai ridicate performanţe şi cele mai slab performante.
Modul în care este definită performanţa unei organizații IT şi cum se măsoară aceasta sunt detaliate foarte explicit în documentul menţionat, împreună cu factorii care ajută la îmbunătăţirea ei. Vom enumera doar câțiva, invitând cititorul să parcurgă întregul raport:
Aplicarea principiilor de lean management și continuous delivery;
Implicarea managementului în procesul de schimbare în DevOps;
Povestea Yardi România a început în anul 2006 cu PropertyShark. Acesta este un produs destinat profesioniștilor în imobiliare din New York, oferind informații detaliate despre proprietăți.
Fiind o firmă relativ mică (maxim 40 de angajați), s-a mers pe un model organizațional în care toți angajații cunoșteau bine produsul, fiecare trecând, la un moment dat și pentru o perioadă scurtă de timp, pe la toate echipele. Acest lucru a dus la o mai bună înțelegere a nevoilor de business și a problemelor care pot să apară.
Deși administratorii lucrau separat de developer-i (în încăperi diferite), ei participau la toate ședințele care implicau produsul și luau parte la tot ce însemna decizie importantă. De asemenea, dacă situația o cerea, intrau chiar și în cod pentru a face modificările necesare ca totul să meargă bine.
În anul 2010, PropertyShark a fost achiziționat de Yardi. În timp, compania-mamă a asignat mai multe produse biroului din România. Fiecare produs avea propria echipă de dezvoltatori, însă echipa de administrare de sisteme a rămas una singură (cu un număr crescut de membri). Fiecare administrator făcea atât muncă de local IT cât și task-uri de produs. Și, pentru că aproape toți administratorii făceau parte din echipa on-call, era nevoie ca fiecare persoană să cunoască fiecare produs.
Acest sistem a funcționat bine o perioadă îndelungată de timp, însă, pe măsură ce se adăugau produse noi biroului din Cluj, devenea evident faptul că această soluție nu va scala.
Pentru rezolvarea problemei, s-a decis în primă fază asignarea a câte două persoane pentru fiecare produs și participarea lor la stand-up-urile zilnice ale developer-ilor. Astfel, pentru managerii respectivelor echipe era clar cine se ocupa de problemele lor pe partea de administrare de sisteme, iar administratorii participau activ la discuțiile și deciziile privind produsul.
După această modificare, feedbackul primit a fost unul încurajator: managerii au observat o îmbunătățire în rezolvarea task-urilor de la administratori, iar aceștia au fost mai concentrați pe produsele lor, nefiind nevoie să schimbe contextul între mai multe medii și produse.
Următoarea fază importantă a reprezentat-o un proiect nou, intern, la care managerul a cerut ca cei doi administratori asignați proiectului său să stea împreună cu restul echipei. După câteva săptămâni s-au și văzut rezultatele: echipa a funcționat ca un tot unitar cu roluri bine definite, dar interconectate bine.
Nivelul mare de eficiență obținut în cadrul acestul proiect a determinat mutarea și a celorlalți administratori lângă echipele pe care le deserveau. Această apropiere fizică a ajutat atât la întelegerea de către developer-i și manageri a problemelor apărute pe partea de administrare cât și la înțelegerea de către administratori a nevoilor developer-ilor. De asemenea, participarea tuturor părților la discuții a determinat depistarea unor probleme înainte să apară și rezolvarea altora la scurt timp după ce au apărut.
În continuare este nevoie ca echipa de on-call să cunoască toate produsele, dar nu la un nivel atât de avansat ca înainte. Problemele specifice produsului le rezolvă echipa specializată, care, mai apoi, notifică on-call-ul de schimbări.
Acest mod de lucru s-a dovedit eficient în cadrul companiei noastre, iar implementarea sa treptată a contribuit major la succesul său.
Probabil cel mai important lucru de reținut este faptul că DevOps-ul nu trebuie gândit ca un set de skill-uri pe care trebuie să le aibă angajații ori ca un set de tool-uri pe care trebuie să le folosim pentru a ne numi DevOps. Importantă este apropierea dintre echipe, iar skill-urile și tool-urile apar doar dacă apare o nevoie pentru ele.
Effective Devops - Jennifer Davis, Katherine Daniels; O'Reilly Media 2015
"We are all DevOps" presentation, Velocity Amsterdam 2015, https://speakerdeck.com/kdaniels/we-are-all-devops
"State of DevOps report 2015", Puppet Labs, https://puppetlabs.com/sites/default/files/2015-state-of-devops-report.pdf