o cale practică spre maturitatea DevOps

orice metodologie agilă este inutilă fără practici DevOps reale. Cuvântul cheie a fost folosit greșit în multe organizații. Dacă spui că ai maturizat Echipe agile și ai un inginer DevOps sau o echipă DevOps, care probabil nu merg în direcția cea bună. DevOps este mai degrabă o cultură decât un nume sau denumire de echipă. Luând un indiciu de la CMM (Capability Maturity Model) această încercare este de a ajuta o organizație să știe unde se află într-o călătorie DevOps și o cale de urmat. Cu unele brainstorming între echipele de dezvoltare și Ops, acest lucru poate fi extins și personalizat la nevoile organizației.

niciun număr nu este rău pentru că ajută o persoană sau o organizație să crească.

client fericit

spre deosebire de CMM, acesta nu este un model pe care trebuie să-l dovediți oricărei organizații de certificare. Singurul certificat pe care îl obțineți este de la clienții dvs. fericiți sau partenerii de afaceri. Este un model pentru a reflecta de sine și și de a ajuta de afaceri să crească. Scopul oricărei echipe IT este de a crea valoare prin realizarea unei livrări durabile și previzibile cu calitate.

acesta este un model simplu care de la dezvoltator la CxO poate înțelege și se referă.

înainte de a discuta despre model. Trebuie să înțelegem necesitatea acestui model. Cu mulți ani în urmă, Melvin Conway în lucrarea Sa „cum inventează comitetele?”a venit cu teza care a devenit faimos ca Legea lui Conway.

orice organizație care proiectează un sistem (definit în linii mari) va produce un design a cărui structură este o copie a structurii de comunicare a organizației.

legea se bazează pe raționamentul că, pentru ca modulele software să funcționeze, mai multe persoane trebuie să comunice frecvent între ele. Prin urmare, structura interfeței software a unui sistem va reflecta limitele sociale ale organizației(organizațiilor) care l-au produs, peste care comunicarea este mai dificilă.

să ne uităm la modul în care funcționează acest lucru în dezvoltarea de software cu un scenariu real. Radha construiește un ecran frontal care arată atributele detaliate ale unui produs. Spuneți că acest produs este un telefon mobil. Puține detalii comune despre produs sunt culoarea, prețul, dimensiunile, evaluările etc. Un nou regulament a venit pentru a afișa valoarea SAR a telefonului. Ecranul pe care l-a proiectat funcționează cu micro service call. A vorbit cu Sunil, care lucrează în echipa data. El a spus că pot trimite date numai în fișier plat. Există o deconectare clară între două module. Acesta este un scenariu pe care fiecare echipă IT îl întâlnește, dacă nu toate 100% ori, dar de cele mai multe ori. Aceasta este doar o problemă de proiectare. Problema este mai largă. Ce se întâmplă dacă prioritățile celeilalte echipe sunt foarte diferite de ceea ce face echipa ta? Cerințele dumneavoastră poate fi cea mai mică prioritate pentru ei în timp ce părțile interesate se execută în spatele tău.

primul pas spre implementarea cu succes a DevOps este să fii deschis cu schimbările organizației.

schimbări de organizare

permiteți-mi să discut 5 niveluri de maturitate:

  1. inițial: în această fază, echipele lucrează în silozuri și există doar o colaborare bazată pe nevoie. Într-o întâlnire cu toate echipele împreună, dacă întrebați Cine deține „produsul”, nu veți avea nici o ridicare a mâinilor. Timpul de piață este de obicei mai lung, mergând la Luni și uneori ani. Prioritățile sunt stabilite la nivel de echipă, dar nu la nivel de produs. Acest lucru va face ca fiecare echipă să aibă propriile priorități. Deoarece nu există un proces definit, fiecare încercare este ca reinventarea roții. Acest lucru va duce la probleme de calitate și termene mai lungi. Echipa face cea mai mare parte implementări manuale și intervenții manuale. Ei bine.. aceasta nu este o stare rea. Așa ar începe cea mai mare parte a dezvoltării.

2. Repetabil: echipele încă lucrează în silozuri. Există un anumit nivel de automatizare în cadrul echipei. Atunci când o criză hit-uri, echipa definește propriul proces și urmează până la sfârșitul crizei. Numai vestea bună este că unele dintre acestea pot deveni procese repetabile atunci când criza lovește din nou.

3. Definit: acesta este un bun punct de plecare pentru însămânțarea culturii DevOps cu o echipă centralizată. Această echipă înțelege diverse tehnologii pe care le folosesc echipele Dev, iar instrumentele se bazează pe nevoia actuală. Fiind o echipă centralizată, nu este ușor să monitorizezi ceea ce face fiecare echipă și astfel unele decizii sunt lăsate echipelor să experimenteze. Echipa centrală este formată de obicei din experți, iar echipele dev vor avea unii oameni cu înțelegere și cunoștințe de bază.

4. Gestionat: pe măsură ce echipa centrală DevOps înțelege peisajul instrumentelor de organizare, sunt testate mai multe medii și instrumente. Procesele consecvente și repetabile sunt urmate de mai multe echipe. Lanțul de instrumente este selectat pe baza cazurilor de utilizare, mai degrabă decât a alegerilor personale. Instrumentele de monitorizare pentru toate procesele sunt introduse și utilizate intens de echipe pentru a lua decizii.

5. Optimizat:

succesul unui lider bun este definit de a nu avea adepți, ci de capacitatea de a crea lideri mari.

etapa finală a maturității DevOps este de a face echipa DevOps să dispară. Acest lucru ar putea arata ca contra intuitiv. În acest stadiu, DevOps face parte din echipa de dezvoltare a produsului, mai degrabă decât o entitate separată. Utilizarea infrastructurii ca cod, containere, orchestrare etc. se realizează implementarea tactilă zero. Acum, dacă sunați pe toți cei care lucrează la un produs și întrebați Cine deține produsul, veți avea niște mâini încrezătoare care ridică fără nici o ezitare. Datele din instrumentele de monitorizare sunt utilizate pentru a selecta un nou set de instrumente (inclusiv infrastructură, limbaje de programare, tehnici). Deciziile se bazează mai degrabă pe date decât pe preferințe personale. Echipa de produse este gata să implementeze codul în orice zi și în orice moment. Ei iubesc „valoarea afacerii” și o tratează ca pe un animal de companie. Orice altceva este tratat ca bovine.

Modelul De Maturitate DevOps.

Lasă un răspuns

Adresa ta de email nu va fi publicată.