ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 148
Numărul 147 Numărul 146 Numărul 145 Numărul 144 Numărul 143 Numărul 142 Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 89
Abonament PDF

Cum să-ți construiești o echipă DevOps ?

Iacob Nicolaev
DevOps Engineer @ msg systems Romania



PROGRAMARE


La începuturile sale, DevOpsul a declanșat mult entuziasm și bucurii. Însă după un timp, euforiei generale i-a urmat o relativă stare de haos, care a atras atenția asupra problematicii complexe pe care o presupune DevOpsul.

Prezentarea "10+ deploys per day" apreciată în istoria DevOpsului ca momentul care îi configurează direcția și specificul este realizată de John Allspaw, care atunci conducea grupul de Operations, și respectiv, Paul Hammond care coordona grupul de Engineering. Acești doi ingineri au făcut imposibilul la acel moment și au împărtășit aceste idei cu întreaga industrie IT. Colaborarea DevOps a fost creată și important de menționat este că acest lucru a fost posibil fără niciun inginer specializat în DevOps.

Timpul de Haos

De-a lungul timpului, domeniul DevOps a crescut mult, fără a avea la bază un fundament teoretic bine consolidat și instrumente specializate. Acestea s-au dezvoltat în timp. A fost o perioadă minunată, în care am experimentat și descoperit multe situații, lucruri noi și inedite. Ceea ce ne-a obligat să avem în echipe oameni specializați. Așa a început aventura căutării unui inginer DevOps. Într-adevăr, am ajuns să creăm specializarea DevOps Engineer.

Tipuri de echipe pe care le avem

În rândurile următoare prezentăm tipurile de specialități de care avem nevoie pentru a implementa practicele DevOps, cu toate elementele sale: Infrastructure as Code, Configuration Management, Automatic Deploys.

Cu timpul au fost dezvoltate câteva tipuri de echipe DevOps. Iată câteva dintre ele:

Cele mai bune

1.Un tip bine cunoscut este Site Reliability Engineering (SRE) pe care îl avem datorită companiei Google:

Echipa DevOps are în grija sa un environment live de producție. Ideea de bază este realizarea unei echipe SRE care să realizeze joncțiunea între departamentele de Dev și cel de Ops. O echipă care verifica siguranța și calitatea produsului livrat de specialiștii din development. De obicei, în echipe SRE sunt developeri care lucrează împreună cu echipa operațională. Datorită standardelor mari si cerințelor stricte de livrare echipa SRE este capabilă de a asigura o bună funcționare a produsului.

2.Echipa DevOps creată din membrii echipei Dev și ale echipei Ops:

Acesta este "Sfântul Graal" al DevOpsului. În acest model, developerii sunt conectați la maxim cu departamentul operațional. Echipele lucrează împreună pentru atingerea obiectivelor comune ale organizației. Cu toate că în acest model nu există o echipă specializată pentru DevOps, se manifestă cu siguranță cultura DevOps.

Eficiența acestui model este condiționată de prezența unei culturi a standardelor, precum și de o exprimare cât mai clară a obiectivelor.

Cele mai rele

1.Echipa de DevOps dedicată si cel mai des izolată:

Această tipologie apare atunci când un manager dorește ceva "DevOps" în companie și angajează DevOps Engineers care cel mai des știu "totul". Echipa DevOps se izolează și ține la distanță celelalte echipe implicate în procesul de development. Modul de gândire al echipei inclină spre negativ față de alte echipe, deoarece nu își doresc să lucreze cu 'clueless Devs' și 'dinosaur Ops'.

2.System Administratorii re-denumiți în DevOps:

Acest model este foarte apropiat de cel anterior. Când există un haos în organizație și conducerea dorește să remedieze lucrurile, managmentul dorește să facă la fel ca toată industria, adică să aibă și ei "DevOps". Atunci își califică administratorii de sistem cu sarcini DevOps. Acest aspect conduce la efecte negative la foarte multe probleme, câtă vreme sarcinile sunt făcute într-un mod prost, iar calitatea nu este pe primul plan.

Acestea sunt doar câteva exemple a topologiilor echipelor de DevOps. Mai multe exemple sunt descrise în cartea 'Team Topologies' de Matthew Skelton și Manuel Pais.

O rețetă perfectă (pentru mine)

În momentul în care cream o echipă DevOps la o companie locală, am avut o problemă foarte asemănătoare cu cea pe care o avem cu toții. Unde să găsim oameni? Nu-mi amintesc exact ziua în care mi-a venit ideea că nu am nevoie de ingineri specializați în DevOps pentru a face DevOps. Am angajat un developer, un inginer pe securitate și un administrator de sistem. Și cu această echipă am creat DevOpsul în această companie. Oamenii au fost integrați în fiecare proiect la nivel maxim. În orice moment, unul dintre noi putea vorbi pe aceeași limba fie cu echipa de dezvoltatori, fie cu echipa operațională. Au existat situații când am făcut parte din procesul de dezvoltare al produselor. Nu am găsit acest model în cartea menționată anterior, dar a fost un lucru de echipă minunat atât pentru noi cât și pentru întreaga companie.

După și înainte

Integrarea oamenilor între departamente și, de asemenea, faptul că în echipă erau trei sau patru tipuri de specializări diferite, ne-au adus încă un avantaj la care nu ne așteptam. Oamenii au început să cunoască mai bine produsele din toate punctele de vedere. Toți dezvoltatorii știau ce se întâmplă în departamentul Operațional și vice-versa. Inginerii noștri specializați în domeniul specific lor au adunat cunoștințe de la toți colegii. Toți cei de la noi au simțit un impuls în dezvoltarea personală si profesională.

Concluzie

Nu întotdeauna este necesar să angajăm anume specialitatea de DevOps Engineers pentru a putea crea cultura DevOps în organizația dumneavoastră. De ce nu începem să căutăm ingineri capabili de a rezolva problema și sarcina specifică pe care o avem. Cu ceva ajutor din partea celor experimentați în practicele DevOps, toți inginerii pot contribui la crearea DevOpsului. Cel mai important este să existe cineva care poate să ghideze, cineva care înțelege ce este DevOps și să poată gestiona o echipă. Cu acest tip de echipă ne putem atinge obiectivul.

Toată lumea ar trebui să fie puțin "DevOps".

LANSAREA NUMĂRULUI 148

Agile Craftsmanship

joi, 24 Octombrie, ora 18:30

Colors in Projects (București)

Facebook Meetup StreamEvent YouTube

Agile Leadership &
Ways of Working

miercuri, 30 Octombrie, ora 18:00

ING Hubs Romania (Cluj)

Facebook Meetup StreamEvent YouTube

Conferință TSM

NUMĂRUL 147 - Automotive

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Cognizant Softvision
  • Colors in projects