Întrebarea „cum să implementăm DevOps” există de câțiva ani, dar nu sunt multe materiale bune. Uneori, devii victima publicității unor consultanți nu foarte inteligenți, care trebuie să își vândă timpul, indiferent de modalitate. Uneori, sunt cuvinte vagi, extrem de generale despre cum navele mega-corporațiilor navighează prin vastitatea universului. Se ridică întrebarea: care este beneficiul pentru noi? Stimate autor, ne puteți prezenta clar ideile dumneavoastră sub formă de listă?
Toate acestea decurg din faptul că experiența reală și înțelegerea rezultatelor transformărilor culturii organizatorice s-au acumulat nu atât de mult. Schimbările culturale sunt procese de durată, ale căror rezultate nu vor apărea peste o săptămână și nici peste o lună. Avem nevoie de cineva suficient de experimentat, care să fi văzut cum s-au creat și distrus companii de-a lungul anilor.
John Willis — unul dintre părinții DevOps. John are în spate zeci de ani de lucru cu un număr mare de companii. Recent, John a început să observe tipare specifice care se manifestă în colaborarea cu fiecare dintre acestea. Folosind aceste arhetipuri, John îndrumă companiile pe calea adevăratei transformări DevOps. Mai multe despre aceste arhetipuri — în traducerea discursului său de la conferința DevOops 2018.
Despre vorbitor:
Peste 35 de ani în management IT, a participat la crearea predecesorului OpenCloud la Canonical, a fost implicat în 10 startup-uri, două dintre acestea fiind vândute Dell și Docker. În prezent, este Vicepreședinte pentru DevOps și Practici Digitale la SJ Technologies.
Mai departe — povestea din perspectiva lui John.
Mă numesc John Willis, și mă puteți găsi cel mai ușor pe Twitter, . Același pseudonim îl folosesc și pe Gmail și GitHub. Și puteți găsi înregistrări video ale discursurilor mele și prezentările acestora.
Am multe întâlniri cu CIO-uri din diverse mari companii. Adesea, ei se plâng că nu înțeleg ce este DevOps, iar toți cei care încearcă să le explice vorbesc despre lucruri personale. O altă plângere frecventă este că DevOps nu funcționează, deși, aparent, directorii fac tot ce le-a fost explicat. Este vorba despre mari companii, cu peste o sută de ani vechime. După ce am discutat cu ei, am ajuns la concluzia că, în multe dintre aceste probleme, soluțiile de tehnologie joasă sunt mai adecvate decât cele de înaltă tehnologizare. Timp de săptămâni, am dialogat pur și simplu cu oameni din departamente diferite. Ceea ce vedeți în prima imagine din postare este ultimul meu proiect, camera arăta așa după trei zile de muncă.
Ce este DevOps?
Adevărat, dacă întrebi 10 persoane diferite, acestea îți vor oferi 10 răspunsuri diferite. Dar iată ce este interesant: toate aceste zece răspunsuri vor fi corecte. Nu există un răspuns greșit aici. M-am ocupat destul de profund de DevOps, timp de aproximativ 10 ani, fiind primul american la primul DevOpsDay. Nu aș spune că sunt mai deștept decât toți cei care se ocupa de DevOps, dar e puțin probabil să existe cineva care a investit la fel de mult efort. Consider că DevOps apare atunci când capitalul uman se îmbină cu tehnologia. Adesea uităm de dimensiunea umană, deși vorbim mult despre diverse culturi.
În prezent, avem multe date, cinci ani de cercetări academice, și verificarea teoriilor este desfășurată la scară industrială. Aceste cercetări ne spun următoarele: dacă în cultura organizațională se combină anumite tipare comportamentale, se poate obține o accelerare de 2000 de ori. Această accelerare corespunde cu o îmbunătățire similară în reziliență. Aceasta este o măsurare cantitativă a avantajului pe care DevOps îl poate aduce oricărei companii. Cu câțiva ani în urmă, am vorbit despre DevOps cu directorul general al unei companii din lista Fortune 5000. Când m-am pregătit pentru prezentare, eram foarte emoționat, deoarece trebuia să sintetizez experiența mea de mulți ani în 5 minute.
În final, am dat următoarea definiție DevOps: este un set de practici și tipare care permit transformarea capitalului uman în capital organizațional de înaltă performanță. Un exemplu poate fi modul în care Toyota a funcționat în ultimii 50 sau 60 de ani.
(Aici și mai departe, aceste scheme nu sunt prezentate ca material de referință, ci ca ilustrație. Conținutul lor va varia pentru fiecare companie nouă. Cu toate acestea, imaginea poate fi vizualizată și mărită separat
Una dintre cele mai de succes astfel de practici este mappingul fluxului de valoare. Despre aceasta s-au scris câteva cărți bune, autorul celei mai de succes fiind Karen Martin. Dar în ultimul an, am ajuns la concluzia că chiar și acest abordare este prea tehnologică. Are, fără îndoială, multe avantaje, de care m-am folosit mult. Dar atunci când directorul executiv te întreabă de ce compania sa nu poate trece la noi căi, despre mappingul fluxului de valoare este prea devreme să discutăm. Există multe întrebări fundamental mai importante la care trebuie să găsim răspunsuri preliminare.
Mi se pare că greșeala multor colegi este că pur și simplu oferă companiei un ghid în cinci puncte și apoi se întorc după șase luni pentru a vedea ce s-a întâmplat. Chiar și o schemă bună, precum mappingul fluxului de valoare, are, așa-zisele, zone moarte (blind spots). După sute de interviuri cu directorii diferitelor companii, am dezvoltat un anumit model care permite descompunerea problemei în elementele sale de bază, iar acum vom discuta sistematic fiecare din aceste componente. Înainte de a aplica orice soluții tehnologice, folosesc acest model și, ca urmare, toate pereții mei ajung să fie plini de scheme. Recent, am lucrat cu un fond mutual și, în cele din urmă, am avut 100-150 astfel de scheme.
O cultură proastă devorează bunele abordări la micul dejun
Ideea principală este următoarea: nici Lean, Agile, SAFE și DevOps nu vor ajuta dacă cultura organizației este proastă. Este la fel ca și cum ai sări în adâncime fără echipament de scufundare sau ai opera fără o radiografie. Cu alte cuvinte, parafrazându-i pe Drucker și Deming: o cultură organizațională proastă va înghiți orice sistem bun și nu se va vedea.
Pentru a rezolva această problemă principală, este necesar să întreprindem următorii pași:
- Faceți toată munca vizibilă: este nevoie să facem toată munca vizibilă. Nu în sensul că trebuie să fie neapărat afișată pe un ecran, ci în sensul că trebuie să fie observabilă.
- Consolidați sistemele de management al muncii: este necesar să consolidăm sistemele de management. În problema cunoștințelor „tribale” și cunoștințelor instituționale, în 9 cazuri din 10, blocajele sunt cauzate de oameni. În cartea problema a fost un singur om, Brent, care a întârziat proiectul cu trei ani. Și pe astfel de „Brenturi” dau peste tot. Pentru a rezolva aceste blocaje, folosesc următoarele două puncte din lista noastră.
- Teoria constrângerilor: teoria constrângerilor.
- Trucuri de colaborare: hack-uri de colaborare.
- Toyota Kata (): nu voi vorbi prea mult despre Toyota Kata. Dacă ești interesat, pe GitHub-ul meu aproape pe fiecare dintre aceste teme.
- Organizație orientată pe piață: organizație orientată pe piață.
- Auditori shift-left: auditori în etapele anterioare ale ciclului.
Încep lucrul cu organizația foarte simplu: mă duc în companie și discut cu angajații. După cum vedem, nu sunt tehnologii de vârf. Tot ce este necesar este să am cu ce scrie. Adun câteva echipe într-o cameră și analizez ceea ce îmi spun din perspectiva celor 7 arhetipuri ale mele. Apoi, le dau un marker și îi rog să formuleze pe tablă tot ceea ce au spus până acum cu voce tare. De obicei, la astfel de întâlniri este o persoană care notează totul, iar în cel mai bun caz reușește să consemneze 10% din discuție. Folosind metoda mea, acest procentaj se poate ridica la aproximativ 40%.
(Această ilustrație poate fi )
Abordarea mea se bazează pe lucrările lui William Schneider (William Schneider, ). La baza acestei abordări stă ideea că orice organizație poate fi descompusă în patru pătrate. Această schemă de obicei rezultă din munca cu sutele de alte scheme care apar în analiza organizației. Să presupunem că avem o organizație cu un nivel mare de control, dar cu o competență scăzută. Acesta este un scenariu extrem de nedorit: când toată lumea respectă regulile, dar nimeni nu știe ce trebuie să facă.
O variantă ușor superioară, cu un nivel înalt atât de control, cât și de competență. Dacă o astfel de companie este profitabilă, atunci poate că DevOps nu-i este necesară. Cel mai interesant este să lucrezi cu o companie care are un nivel ridicat de control, o competență scăzută și colaborare, dar în același timp o cultură organizațională ridicată. Asta înseamnă că în companie sunt mulți oameni care le place să lucreze acolo, iar rotația personalului este mică.
(Această ilustrație poate fi )
Mi se pare că metodele cu recomandări strict definite în cele din urmă împiedică atingerea adevărului. În special, în value stream mapping există multe reguli privind modul în care ar trebui să fie structurată informația. În fazele incipiente de lucru, despre care discut acum, aceste reguli nu sunt necesare. Dacă o persoană cu un marker în mână descrie pe o tablă situația reală din companie - acesta este cel mai bun mod de a înțelege situația. Această informație nu ajunge la directori. În acel moment, este prostesc să oprești persoana și să-i spui că a desenat o săgeată greșită. În această etapă, este mai bine să folosești reguli simple; de exemplu, poți crea o abstracție multi-nivel utilizând doar markere colorate.
Repet, fără tehnologii avansate. Cu markerul negru se ilustrează realitatea obiectivă, cum funcționează totul. Cu markerul roșu, oamenii notează ce nu le place în situația existentă. Este important că ei scriu asta, nu eu. Când după întâlnire mă îndrept spre directorul IT, nu-i propun o listă de 10 lucruri pe care să le corecteze. Încerc să găsesc legături între ceea ce spun oamenii din companie și modelele validate existente. În cele din urmă, cu markerul albastru se propun soluții posibile pentru problemă.
(Această ilustrație poate fi )
Un exemplu al acestei abordări este prezentat mai sus. La începutul acestui an am lucrat cu o bancă. Angajații din departamentul de securitate erau convinși că nu trebuie să vină la verificările cerințelor și proiectării (design and requirement reviews).
(Această ilustrație poate fi )
Apoi am vorbit cu oameni din alte departamente și am aflat că cu aproximativ 8 ani în urmă, dezvoltatorii de software i-au exclus pe angajații de securitate, deoarece aceștia încetineau munca. Apoi, acest lucru s-a transformat într-o interdicție care era percepută ca o dată. Cu toate acestea, de fapt, nu exista nicio interdicție.
Întâlnirea noastră a avut un parcurs extrem de complicat: timp de aproape trei ore, cinci echipe diferite nu au reușit să-mi explice ce se întâmplă între cod și compilare. Iar aceasta ar părea a fi cel mai simplu lucru. Majoritatea consultantilor DevOps presupun dinainte că toată lumea știe deja acest lucru.
Apoi, persoana responsabilă de reglementarea IT (IT governance), care a tăcut timp de patru ore, a prins viață brusc atunci când am ajuns la subiectul său și ne-a ocupat timp de încă o perioadă destul de lungă. La final, l-am întrebat ce părere are despre întâlnire și nu voi uita niciodată răspunsul său. A spus: „În trecut, credeam că banca noastră are doar două modalități de livrare a software-ului, iar acum știu că acestea sunt cinci, și despre trei dintre ele nici nu aveam idee”.
(Această ilustrație poate fi )
Ultima întâlnire în această bancă a fost cu echipa care se ocupă de software-ul pentru investiții. Cu ea am aflat că este mai bine să scrii scheme cu un marker pe o foaie decât pe o tablă, și chiar mai bine decât pe un smartboard.
Fotografiile pe care le vedeți arată cum a arătat sala de conferințe a hotelului în a patra zi a întâlnirii noastre. Aceste scheme le-am folosit pentru a căuta tipare, adică arhetipuri.
Așadar, pun întrebări angajaților, iar ei notează răspunsurile cu markere de trei culori (negru, roșu și albastru). Analizez răspunsurile lor căutând arhetipuri. Acum haideți să discutăm toate arhetipurile în ordine.
1. Make All Work Visible: Fă ca toată munca să fie vizibilă
În majoritatea companiilor cu care colaborez, există un procent foarte ridicat de muncă neidentificată. De exemplu, când un angajat se apropie de altul și îi cere pur și simplu să facă ceva. În organizații mari, poate fi vorba de 60% din muncă neplanificată. Și până la 40% din muncă nu este documentată în niciun fel. Dacă ar fi fost Boeing, nu m-aș fi mai urcat niciodată în avionul lor. Dacă doar jumătate din muncă este documentată, nu se știe dacă acea muncă este realizată corect sau nu. Toate celelalte metode devin inutile - nu are sens să încerci să automatizezi ceva, pentru că cele 50% cunoscute pot fi tocmai partea cea mai organizată și precisă a muncii, a cărei automatizare nu va aduce rezultate mari, iar tot ce este mai terifiant se află în jumătatea nevăzută. În absența documentației, nu este posibil să găsim tot felul de hack-uri și muncă ascunsă, să identificăm blocajele, acei „Brent” despre care am vorbit deja. Există o carte excelentă scrisă de Dominica DeGrandis. . Ea identifică cinci tipuri diferite de „pierderi de timp” (thieves of time):
- Prea multă muncă în proces (WIP)
- Dependințe necunoscute
- Muncă neplanificată
- Priorități conflictuale
- Munca neglijată
Este o analiză foarte valoroasă, iar cartea este minunată, dar toate aceste sfaturi sunt inutile dacă doar 50% din date sunt vizibile. Metodele propuse de Dominica pot fi aplicate doar dacă se atinge o precizie de peste 90%. Vorbesc despre situații în care șeful îi dă subordonatului o sarcină de 15 minute, dar aceasta durează trei zile; dar șeful nu știe de fapt că acest subordonat depinde de alți patru sau cinci oameni.
Phoenix Project — este o poveste fascinantă despre un proiect care a întârziat cu trei ani. Unul dintre eroi riscă să fie dat afară din cauza acestui lucru și se întâlnește cu un alt personaj, care este prezentat ca o adevărată variantă a lui Socrate. Acesta îl ajută să înțeleagă ce anume a mers prost. Se descoperă că în companie există un administrator de sistem pe nume Brent, iar toată munca trece, într-un fel sau altul, prin el. La una dintre întâlniri, unul dintre subordonați întreabă: de ce fiecare sarcină de o jumătate de oră durează o săptămână? Răspunsul conține o prezentare foarte simplificată a teoriei cozilor și a legii lui Little, iar în această prezentare se arată că, cu o ocupare de 90%, fiecare oră de lucru ocupă 9 ore. Fiecare sarcină trebuie trimisă altor șapte persoane, așa că această oră devine 63 de ore, 7 înmulțit cu 9. O spun pentru a sublinia că, pentru a folosi legea lui Little sau o teorie complicată a cozilor, trebuie mai întâi să ai datele.
Așadar, când vorbesc despre vizibilitate, nu mă refer la a avea totul pe ecran, ci la necesitatea de a avea date. Când acestea există, se dovedește adesea că există un volum foarte mare de muncă neplanificată care somehow ajunge la Brent, deși nu e nicio nevoie. Brent este un tip grozav, niciodată nu va spune „nu”, dar în același timp nu le spune celorlalți cum își face munca.
Când munca este vizibilă, putem clasifica cu atenție datele (exact asta face Dominika în fotografie), putem aplica abstractizarea celor cinci scurgeri de timp și putem automatiza.
2. Consolidarea Sistemelor de Management al Lucrărilor: Managementul Sarcinilor
Arhetipurile despre care vorbesc reprezintă o formă de piramidă. Dacă primul este realizat corect, al doilea devine o formă de suprastructură. Multe dintre ele nu funcționează pentru startup-uri, trebuie avute în vedere pentru companii mari, precum cele incluse în lista Fortune 5000. La ultima companie la care am lucrat, existau 10 sisteme de urmărire a erorilor (sistem de ticketing). Într-o echipă se folosea Remedy, o alta a scris un sistem propriu, a treia utiliza Jira, iar cineva pur și simplu folosea email-ul. Aceeași problemă apare dacă în companie sunt 30 de pipeline-uri diferite, dar nu am timp să discut despre toate aceste cazuri.
Discut cu oamenii despre cum se creează tichetele, ce se întâmplă ulterior cu ele, cum sunt ocolite. Cel mai interesant este că oamenii de la întâlnirile noastre vorbesc destul de sincer. Am întrebat câți oameni etichetează tichetele cu „minor / fără impact” pentru cele care ar fi trebuit să primească „impact major”. S-a dovedit că aproape toți fac asta. Nu mă ocup cu raportarea și încerc din toate puterile să nu identific oamenii. Când cineva îmi mărturisește ceva sincer, nu dezvălui persoana. Dar când aproape toată lumea ocolește sistemul, înseamnă că întreaga securitate este, în esență, o decorație. Așadar, nu putem trasa nicio concluzie din datele acestui sistem.
Pentru a rezolva problema tichetele, este necesar să alegem un singur sistem principal. Dacă folosiți Jira, să fie doar Jira. Dacă există o alternativă, să fie doar aceea. Ideea este că tichetele trebuie să fie considerate ca o etapă suplimentară în procesul de dezvoltare. Fiecare acțiune ar trebui să aibă un tichet, care trebuie să treacă prin fluxul de lucru al dezvoltării. Tichetele sunt trimise echipei care le plasează pe storyboard și apoi își asumă responsabilitatea pentru ele.
Aceasta se aplică tuturor departamentelor, inclusiv celui infrastructural și operațional. În acest mod, se poate crea o imagine cât de cât credibilă asupra stării lucrurilor. Când acest proces este bine pus la punct, se dovedește că este ușor să stabilim cine este responsabil pentru fiecare aplicație. Pentru că acum primim nu 50%, ci 98% din noile servicii. Dacă acest proces principal funcționează, atunci precizia crește în întreaga sistem.
Pipeline de servicii
Aceasta se referă din nou doar la marile corporații. Dacă ești o companie nouă într-un domeniu nou – își suflecă mânecile și lucrează cu Travis CI sau CircleCI. În ceea ce privește companiile din Fortune 5000, există un caz remarcabil care s-a întâmplat cu banca la care am lucrat. Au fost contactați de Google, care le-au arătat diagrame cu vechile sisteme IBM. Oamenii de la Google, cu neînțelegere, au întrebat – unde este codul sursă pentru asta? Și nu există cod sursă, nu există nici măcar un GUI. Aceasta este realitatea cu care trebuie să se confrunte organizațiile mari: înregistrări bancare de 40 de ani pe un mainframe vechi. Unul dintre clienții mei folosește containere Kubernetes cu pattern-uri Circuit Breaker, plus Chaos Monkey, toate acestea pentru aplicația KeyBank. Dar aceste containere se conectează, în cele din urmă, la o aplicație scrisă în COBOL.
Oamenii de la Google erau complet convinși că vor rezolva toate problemele clientului meu, apoi au început să pună întrebări: ce este IBM datapipe? Răspunsul a fost: este un conector. La ce se conectează? La sistemul Sperry. Și acesta ce este? Și așa mai departe. La prima vedere pare: ce rol are DevOps aici? Dar de fapt, este posibil. Există sisteme de livrare care permit transferul fluxului de lucru echipelor care se ocupă de livrare.
3. Teoria constrângerilor: Teoria constrângerilor
Să trecem la al treilea arhetip: cunoașterea instituțională / «tribală». De obicei, în orice organizație există câțiva oameni care știu totul și conduc pe toți. Aceștia sunt cei care au cel mai mult timp în organizație și care cunosc toate scurtăturile.
Când acest lucru devine evident pe diagramă, subliniez special acești oameni cu un marker: de exemplu, se constată că un anume Lou este prezent la toate întâlnirile. Și pentru mine este clar: acesta este Brent local. Când directorul de tehnologia informației alege între mine, în tricou și teniși, și un tip îmbrăcat în costum de la IBM, mă aleg pe mine deoarece pot să-i spun directorului lucruri pe care celălalt tip nu le va spune și despre care directorul ar putea fi neplăcut impresionat. Le spun că în compania lor există un punct slab, este cineva numit Fred și cineva numit Lou. Acest punct slab trebuie desfăcut, cunoștințele lor trebuie obținute într-un fel sau altul.
Pentru a rezolva o astfel de problemă, pot, de exemplu, sugera utilizarea Slack. Un director isteț ar întreba – de ce? De obicei, în astfel de cazuri, consultanții în DevOps răspund: pentru că toată lumea face așa. Dacă directorul este într-adevăr isteț, va spune: ei bine și ce. Și astfel, dialogul se va termina. Iar eu răspund: pentru că în companie există patru puncte critice, Fred, Lou, Suzi și Jane. Pentru a transforma cunoștințele lor în ceva instituționalizat, trebuie, mai întâi, să introducem Slack. Toate wiki-urile voastre sunt o prostie completă, pentru că nimeni nu știe că există. Dacă echipa de ingineri lucrează atât la dezvoltarea internă cât și externă și toată lumea ar trebui să știe că poate contacta echipa de dezvoltare externă sau echipa de infrastructură cu întrebări. Tocmai atunci, probabil Lou sau Fred vor avea timp să se conecteze la wiki. Apoi, în Slack, cineva poate întreba de ce nu funcționează, să zicem, pasul 5. Și atunci Lou sau Fred vor corecta instrucțiunile din wiki. Dacă stabilizăm acest proces, multe lucruri se vor aranja de la sine.
Aceasta este ideea mea principală: pentru a recomanda tehnologii avansate, trebuie mai întâi să ne punem în ordine fundamentul pentru acestea, iar acest lucru poate fi realizat cu soluțiile de tehnologie joasă descrise anterior. Dacă începem cu tehnologii avansate și nu explicăm de ce sunt necesare, de obicei, asta nu se termină cu nimic bun. Unul dintre clienții noștri folosește Azure ML, o soluție foarte ieftină și simplă. Aproximativ 30% din întrebări au fost deja răspunse de mașina auto-învățată. Și acest lucru a fost realizat de operatori care nu se ocupă cu data science, statistică sau matematică. Este semnificativ. Costul unei astfel de soluții este minim.
4. Hacks de colaborare: Hack-uri pentru colaborare
Al patrulea arhetip constă în faptul că este necesar să luptăm împotriva izolării. Marea majoritate a oamenilor știe deja acest lucru: izolarea generează dușmănie. Dacă fiecare departament se află pe propriul etaj și oamenii nu se întâlnesc decât în lift, dușmănia între ei se naște foarte ușor. Însă, dacă, dimpotrivă, oamenii se află într-o aceeași încăpere, aceasta dispare imediat. Când cineva face o acuzație comună, de exemplu, că un anumit interfață nu funcționează niciodată — nu este nimic mai simplu decât a deconstrui o astfel de acuzație. Programatorilor care au scris interfața le este suficient să înceapă să pună întrebări concrete și curând se va dovedi că, de exemplu, utilizatorul pur și simplu a folosit greșit instrumentul.
Există multe modalități de a depăși izolarea. Odată, am fost solicitat să ofer consultanță unei bănci din Australia, însă am refuzat să o fac, pentru că am doi copii și o soție. Tot ce am putut să le recomand a fost storytelling grafic. Este o metodă care functionează dovedit. O altă modalitate interesantă sunt întâlnirile de tip lean coffee. Într-o organizație mare, aceasta este o opțiune excelentă pentru răspândirea cunoștințelor. În plus, pot fi organizate devopsdays interne, hackathoane și așa mai departe.
5. Coaching Kata
După cum am menționat la început, astăzi nu voi vorbi despre asta. Dacă sunteți interesați, puteți viziona .
Există, de asemenea, o prezentare bună pe această temă de la Mike Rother:
6. Market Oriented: organizație orientată pe piață
Aici există diferite probleme. De exemplu, oamenii „I”, oamenii „T” și oamenii „E”. Oamenii „I” sunt aceia care se ocupă doar de un singur lucru. De obicei, ei există în organizații cu departamente izolate. „T” este atunci când o persoană cunoaște bine ceva unic, dar excelează și în alte câteva lucruri. „E” sau chiar „piaptăn” — acesta este când o persoană are multe abilități.
Aici se aplică legea lui Conway (), care poate fi exprimată în cea mai simplificată formă astfel: dacă trei echipe lucrează la un compilator, atunci în cele din urmă se va obține un compilator din trei părți. Prin urmare, dacă în interiorul unei organizații există un nivel înalt de izolare, chiar și Kubernetes, Circuit breaker, API extensibility și alte lucruri de ultimă modă în această organizație vor fi structurate la fel ca și organizația însăși. Strict conform lui Conway și în ciuda tuturor vouă, tineri geeki.
Această problemă a fost discutată de multe ori. Există, de exemplu, arhetipuri organizaționale descrise de Fernando Fernandez. Această arhitectură problematică, despre care tocmai am vorbit, cu izolare — este o arhitectură orientată funcțional. Al doilea tip — cel mai rău, arhitectura matricială, care este un amestec al celor două anterioare. Al treilea — este ceea ce se observă în majoritatea startup-urilor, iar companiile mari încearcă de asemenea să se conformeze acestui tip. Aceasta este o organizație orientată pe piață. Aici se face optimizarea pentru a obține cel mai rapid răspuns la cerințele clienților. Uneori, aceasta este numită organizație plată.
Această structură este descrisă de mulți în mod diferit, mie îmi place formularea equipe de construcție / execuție, la Amazon se numește echipe de două pizza. În această structură, toate persoanele de tip „I” sunt grupate în jurul unui singur serviciu, iar treptat ajung să se apropie de tipul „T”, iar dacă managementul este bine organizat, pot deveni chiar „E”. Primul contraargument aici este că în această structură există elemente inutile. De ce ar fi nevoie de un tester în fiecare departament, când se poate avea un departament specializat de testeri? La care eu răspund: costurile inutile în acest caz sunt prețul pentru ca în viitor întreaga organizație să devină de tip „E”. În această structură, testerul învață treptat despre rețele, arhitectură, proiectare etc. În cele din urmă, fiecare participant al organizației devine complet informat despre tot ceea ce se întâmplă în organizație. Dacă doriți să știți cum funcționează acest schemă în industrie, citiți .
7. Auditori shift-left: audituri în etapele timpurii ale ciclului. Respectarea regulilor de securitate în mod vizibil
Este este momentul în care acțiunile tale nu trec, așa zis, testul de miros. Oamenii care lucrează pentru tine nu sunt proști. Dacă, ca în exemplul de mai sus, au marcat peste tot impact minor / fără impact, a continuat timp de trei ani și nimeni nu a observat nimic, atunci toată lumea știe perfect că sistemul nu funcționează. Sau un alt exemplu — consiliul pentru modificări, unde trebuie să se trimită rapoarte în fiecare miercuri. Acolo lucrează un grup de oameni (de altfel, plătiți nu foarte bine), care în teorie ar trebui să știe cum funcționează sistemul în ansamblu. Iar în ultimii cinci ani, probabil că ai observat că sistemele noastre sunt extrem de complexe. Și cinci-șase persoane trebuie să ia o decizie cu privire la o modificare pe care nu au propus-o și despre care nu știu nimic.
Desigur, o astfel de abordare nu funcționează. Trebuie să mă debaraszez de astfel de lucruri, pentru că acești oameni nu protejează sistemul. Decizia trebuie să fie luată de echipă însăși, pentru că echipa trebuie să fie responsabilă de aceasta. Altfel, apare o situație paradoxală, în care un manager, care nu a scris niciodată un cod în viața lui, îi spune programatorului cât timp ar trebui să dureze scrierea codului. Într-o companie cu care am lucrat, erau 7 consilii diferite care examinau fiecare modificare, inclusiv consiliul pentru arhitectură, pentru produse etc. Există chiar și o perioadă de așteptare obligatorie, deși un angajat mi-a spus că în zece ani de muncă nimeni nu a respins vreo modificare propusă de acea persoană în această perioadă obligatorie.
Auditorii trebuie să fie invitați, nu îndepărtați. Spuneți-le că dezvoltați containere binare imutabile care, dacă trec toate testele, rămân neschimbate pentru totdeauna. Explicați-le că aveți un pipeline as code și explicați ce înseamnă asta. Arătați-le următorul schemă: binarul imutabil, doar citit, într-un container care trece toate teste de vulnerabilitate; și mai departe, nu doar că nimeni nu atinge acel container — nimeni nu atinge nici sistemul care creează pipeline-ul, deoarece acesta este de asemenea creat dinamic. Am clienți, Capital One, care folosesc Vault pentru a crea ceva asemeni unui blockchain. Auditorului nu trebuie să-i arătăm „rețetele” din Chef, e suficient să arătăm blockchain-ul, din care este clar ce s-a întâmplat cu tichetul Jira în producție și cine este responsabil pentru el.
Conform , creat în 2018 de Sonatype, în 2017 au fost 87 de miliarde de cereri de descărcare OSS.
Pierderile cauzate de vulnerabilități se dovedesc a fi extrem de mari. În plus, cifrele pe care le vedeți acum mai sus nu includ costurile alternative. În câteva cuvinte despre ce este DevSecOps. Vreau să spun clar că nu mă interesează discuțiile despre cât de reușit este acest nume. Ideea este că, având în vedere că DevOps a fost foarte reușit, ar trebui să încercăm să adăugăm securitate la acest pipeline.
Un exemplu de astfel de secvență:
Aceasta nu este o recomandare a unor produse specifice, deși îmi plac toate. Le-am adus ca exemplu pentru a arăta că DevOps, care a fost inițial bazat pe paradigma organizației în industrie, permite automatizarea fiecărei etape a muncii la produs.
Și nu există nicio motivare pentru care nu am putea aplica aceeași abordare în ceea ce privește securitatea.
Rezultatul
În concluzie, vreau să ofer câteva sfaturi pentru DevSecOps. Este important să implicați auditorii în procesul de dezvoltare a sistemelor dumneavoastră și să investiți timp în educația lor. Trebuie să colaborați cu auditorii. Ulterior, trebuie să înfruntați fără milă alertele false. Chiar și cu cel mai scump instrument de scanare a vulnerabilităților, puteți dezvolta obiceiuri extrem de dăunătoare pentru dezvoltatorii dumneavoastră dacă nu știți care este raportul semnal-zgomot. Dezvoltatorii se vor simți copleșiți de evenimente și vor ajunge să le șteargă. Dacă ați auzit despre cazul Equifax, cam asta s-a întâmplat acolo, a fost ignorat un semnal de nivel maxim de pericol. În plus, vulnerabilitățile trebuie explicate astfel încât să fie clar cum influențează business-ul. De exemplu, puteți spune că este aceeași vulnerabilitate cu cea din cazul Equifax. Vulnerabilitățile de securitate trebuie tratate la fel ca celelalte probleme ale software-ului, adică trebuie incluse în procesul general DevOps. Acestea trebuie gestionate prin intermediul Jira, Kanban etc. Dezvoltatorii nu ar trebui să creadă că altcineva se va ocupa de asta — dimpotrivă, toată lumea ar trebui să se implice. În cele din urmă, trebuie să depuneți eforturi pentru a educa oamenii.
Linkuri utile
Iată câteva prezentări de la conferința DevOops care ar putea fi utile pentru dumneavoastră:
- Sergey Berdnikov, Artyom Kalichkin — Povestea succesului, sau «Dev+DevOps+Ops» (, )
- Baruch Sadogursky, Leonid Igolnik — DevOps la scară: tragedia greacă în trei acte (, )
- Alexandr Titov, Kirill Tolkachev —
- Timothy Lister —
Aruncați o privire în DevOops 2020 Moscova — acolo sunt și multe alte lucruri interesante.
Sursa: habr.com
