Întrebarea „cum se implementează devops” există de ani de zile, dar nu există multe materiale bune. Uneori ești victima reclamelor de la consultanți nu atât de inteligenți care trebuie să-și vândă timpul, indiferent cum. Uneori, acestea sunt cuvinte vagi, extrem de generale, despre modul în care navele megacorporațiilor ară în întinderile universului. Se pune întrebarea: ce contează asta pentru noi? Dragă autor, poți să-ți formulezi clar ideile într-o listă?
Toate acestea rezultă din faptul că nu s-a acumulat prea multă practică și înțelegere reală a rezultatului transformărilor culturii companiei. Schimbările de cultură sunt lucruri pe termen lung, ale căror rezultate nu vor apărea peste o săptămână sau o lună. Avem nevoie de cineva suficient de în vârstă pentru a fi văzut cum companiile au fost construite și au eșuat de-a lungul anilor.
John Willis - unul dintre părinții DevOps. John are zeci de ani de experiență de lucru cu un număr mare de companii. Recent, John a început să observe tipare specifice care au loc atunci când lucrează cu fiecare dintre ele. Folosind aceste arhetipuri, John ghidează companiile pe adevărata cale a transformării DevOps. Citiți mai multe despre aceste arhetipuri în traducerea raportului 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 participat la 10 startup-uri, dintre care două au fost vândute către Dell și Docker. În prezent, este vicepreședinte al DevOps și al practicilor digitale la SJ Technologies.
Urmează povestea din punctul de vedere al lui John.
Numele meu este John Willis și cel mai ușor loc pentru a mă găsi este pe Twitter, . Am același alias pe Gmail și GitHub. A puteți găsi înregistrări video ale rapoartelor mele și prezentări pentru ele.
Am multe întâlniri cu CIO ai diferitelor companii mari. Foarte des se plâng că nu înțeleg ce este DevOps și toți cei care încearcă să le explice vorbesc despre ceva diferit. O altă plângere comună este că DevOps nu funcționează, deși se pare că directorii fac totul așa cum le-a fost explicat. Vorbim de companii mari care au peste o sută de ani. După ce am vorbit cu ei, am ajuns la concluzia că, pentru multe probleme, nu tehnologia înaltă este cea mai potrivită, ci soluțiile relativ low-tech. Timp de săptămâni am vorbit doar cu oameni din diferite departamente. Ceea ce vedeți în prima poză din postare este ultimul meu proiect, așa arăta camera după trei zile de muncă.
Ce este DevOps?
Într-adevăr, dacă întrebi 10 persoane diferite, ei vor da 10 răspunsuri diferite. Dar iată lucrul interesant: toate cele zece răspunsuri vor fi corecte. Nu există un răspuns greșit aici. Am fost destul de adânc în DevOps, timp de aproximativ 10 ani, și am fost primul american la prima DevOpsDay. Nu voi spune că sunt mai inteligent decât toți cei implicați în DevOps, dar aproape că nu există nimeni care să fi depus atât de mult efort pentru asta. Cred că DevOps are loc atunci când capitalul uman și tehnologia se unesc. Uităm adesea de dimensiunea umană, deși vorbim mult despre tot felul de culturi.
Acum avem o mulțime de date, cinci ani de cercetare academică, testarea teoriilor la scară industrială. Ceea ce ne spun aceste studii este că, dacă combinați unele modele de comportament într-o cultură organizațională, puteți obține o accelerare de 2000 de ori. Această accelerație este însoțită de o îmbunătățire egală a stabilității. Aceasta este o măsurare cantitativă a beneficiului pe care DevOps îl poate aduce oricărei companii. Acum câțiva ani, vorbeam despre DevOps cu CEO-ul unei companii din Fortune 5000. Când mă pregăteam pentru prezentare, eram foarte nervos pentru că a trebuit să-mi rezumam anii de experiență în 5 minute.
La final am dat următoarele Definiția DevOps: Este un set de practici și modele care permit transformarea capitalului uman în capital organizațional de înaltă performanță. Un exemplu este modul în care Toyota a funcționat în ultimii 50 sau 60 de ani.
(În continuare, astfel de diagrame sunt furnizate nu ca material de referință, ci ca ilustrații. Conținutul lor va fi diferit pentru fiecare companie nouă. Cu toate acestea, imaginea poate fi vizualizată separat și mărită
Una dintre cele mai de succes astfel de practici este cartografierea fluxului de valoare. S-au scris mai multe cărți bune despre asta, dintre care cele mai de succes sunt de Karen Martin. Dar în ultimul an, am ajuns la concluzia că chiar și această abordare este prea high-tech. Cu siguranță are multe avantaje și l-am folosit foarte mult. Dar când CEO-ul vă întreabă de ce compania lui nu poate trece la noi șine, este prea devreme să vorbim despre maparea fluxului de valoare. Există multe întrebări mult mai fundamentale la care trebuie să se răspundă mai întâi.
Cred că greșeala pe care o fac mulți dintre colegii mei este că pur și simplu oferă companiei un ghid în cinci puncte și apoi revin șase luni mai târziu și vad ce s-a întâmplat. Chiar și o schemă bună, cum ar fi maparea fluxului de valoare, are, să spunem, puncte moarte. După sute de interviuri cu directori ai diferitelor companii, am dezvoltat un anumit tipar care ne permite să împărțim problema în componentele sale, iar acum vom discuta fiecare dintre aceste componente în ordine. Înainte de a aplica orice soluție tehnologică, folosesc acest model și, ca urmare, toți pereții mei sunt acoperiți cu diagrame. Recent lucram cu un fond mutual și am ajuns cu 100-150 de astfel de scheme.
Cultura proastă mănâncă abordări bune pentru micul dejun
Ideea principală este următoarea: nicio cantitate de Lean, Agile, SAFE și DevOps nu va ajuta dacă cultura organizației în sine este proastă. Este ca și cum te-ai scufunda la adâncime fără echipament de scufundare sau că ai funcționa fără o radiografie. Cu alte cuvinte, pentru a-i parafraza pe Drucker și Deming: o cultură organizațională proastă va înghiți orice sistem bun fără a se sufoca cu el.
Pentru a rezolva această problemă principală, trebuie să urmați următorii pași:
- Faceți toate lucrările vizibile: trebuie să faceți toată munca vizibilă. Nu în sensul că trebuie neapărat afișat pe un anumit ecran, ci în sensul că trebuie să fie observabil.
- Sisteme consolidate de management al muncii: sistemele de management trebuie consolidate. În problema cunoștințelor „tribale” și a cunoștințelor instituționale, în 9 cazuri din 10 blocajul sunt oamenii. In carte problema a fost cu o singură persoană, Brent, care a făcut ca proiectul să fie cu trei ani în întârziere. Și dau peste acești „Brent” peste tot. Pentru a rezolva aceste blocaje, folosesc următoarele două elemente de pe lista noastră.
- Metodologia Teoria Constrângerilor: teoria constrângerilor.
- Hackuri de colaborare: hack-uri de colaborare.
- Toyota Kata (): Nu voi vorbi prea mult despre Toyota Kata. Dacă ești interesat, pe github-ul meu pe aproape fiecare dintre aceste subiecte.
- Organizație orientată pe piață: organizare orientată spre piaţă.
- Auditori la stânga: audit în primele etape ale ciclului.
Încep să lucrez cu o organizație foarte simplu: merg la companie și vorbesc cu angajații. După cum puteți vedea, fără tehnologie înaltă. Tot ce ai nevoie este ceva pe care să scrii. Adun mai multe echipe într-o singură cameră și analizez ceea ce îmi spun din perspectiva celor 7 arhetipuri ale mele. Și apoi le dau ei înșiși un marker și le rog să scrie pe tablă tot ce au spus cu voce tare până acum. De obicei, în aceste tipuri de întâlniri există o persoană care notează totul și, în cel mai bun caz, poate nota 10% din discuție. Cu metoda mea, această cifră poate fi crescută la aproximativ 40%.
(Această ilustrație poate fi vizualizată separat )
Abordarea mea se bazează pe opera lui William Schneider. ). Abordarea se bazează pe ideea că orice organizație poate fi împărțită în patru pătrate. Această schemă pentru mine este de obicei rezultatul lucrului cu acele sute de alte scheme care apar atunci când analizez o organizație. Să presupunem că avem o organizație cu un nivel ridicat de control, dar cu competență scăzută. Aceasta este o opțiune extrem de nedorită: atunci când toată lumea ține cont de linie, dar nimeni nu știe ce să facă.
O opțiune ceva mai bună este una cu un nivel ridicat de control și competență. Dacă o astfel de companie este profitabilă, atunci poate că nu are nevoie de DevOps. Cel mai interesant este să lucrezi cu o companie care are un nivel ridicat de control, competență și cooperare scăzute, dar în același timp un nivel ridicat de cultură (cultivare). Asta înseamnă că compania are foarte mulți oameni cărora le place să lucreze acolo și fluctuația forței de muncă este scăzută.
(Această ilustrație poate fi vizualizată separat )
Mi se pare că metodele cu linii directoare rigide ajung să stea în calea realizării adevărului. În special în maparea fluxului de valoare, există multe reguli cu privire la modul în care ar trebui să fie structurată informațiile. În primele etape ale muncii, despre care vorbesc acum, nimeni nu are nevoie de aceste reguli. Dacă o persoană cu un marker în mâini descrie situația reală din companie pe consiliu, acesta este cel mai bun mod de a înțelege starea lucrurilor. Astfel de informații nu ajung la directori. În acest moment, este o prostie să întrerupi persoana și să spui că a tras un fel de săgeată greșit. În această etapă, este mai bine să folosiți reguli simple, de exemplu: abstracția pe mai multe niveluri poate fi creată pur și simplu folosind markere multicolore.
Repet, fără tehnologie înaltă. Markerul negru descrie realitatea obiectivă a modului în care funcționează totul. Cu un marcator roșu, oamenii marchează ceea ce nu le place la situația actuală. Este important ca ei să scrie asta, nu eu. Când merg la CIO după o întâlnire, nu ofer o listă cu 10 lucruri care trebuie remediate. Mă străduiesc să găsesc legături între ceea ce spun oamenii din companie și modelele existente dovedite. În cele din urmă, un marker albastru sugerează posibile soluții la problemă.
(Această ilustrație poate fi vizualizată separat )
Un exemplu al acestei abordări este acum prezentat mai sus. La începutul acestui an am lucrat cu o singură bancă. Oamenii de securitate de acolo erau convinși că nu ar trebui să vină la revizuiri de design și cerințe.
(Această ilustrație poate fi vizualizată separat )
Și apoi am vorbit cu oameni din alte departamente și s-a dovedit că acum aproximativ 8 ani, dezvoltatorii de software au concediat lucrătorii de securitate pentru că încetineau munca. Și apoi s-a transformat într-o interdicție, care a fost luată de la sine înțeles. Deși în realitate nu a existat nicio interdicție.
Întâlnirea noastră s-a desfășurat într-o manieră extrem de confuză: timp de aproximativ trei ore, cinci echipe diferite nu mi-au putut explica ce se întâmplă între cod și asamblare. Și acesta ar părea a fi cel mai simplu lucru. Majoritatea consultanților DevOps presupun că toată lumea știe deja acest lucru.
Apoi, responsabilul cu guvernanța IT, care tăcuse patru ore, a prins brusc viață când am ajuns la subiectul lui și ne-a ocupat foarte mult timp. La final l-am întrebat ce părere are despre întâlnire și nu voi uita niciodată răspunsul lui. El a spus: „Obișnuiam să cred că banca noastră are doar două moduri de a furniza software, dar acum știu că sunt cinci dintre ele și nici măcar nu știam despre trei.”
(Această ilustrație poate fi vizualizată separat )
Ultima întâlnire la această bancă a fost cu echipa de software de investiții. Cu ea s-a dovedit că scrierea diagramelor cu un marker pe o foaie de hârtie este mai bună decât pe o tablă și chiar mai bine decât pe un smartboard.
Fotografiile pe care le vedeți sunt așa cum arăta sala de conferințe a hotelului în a patra zi a întâlnirii noastre. Și am folosit aceste scheme pentru a căuta modele, adică arhetipuri.
Deci, pun întrebări muncitorilor, ei notează răspunsurile cu markere de trei culori (negru, roșu și albastru). Le analizez răspunsurile pentru arhetipuri. Acum să discutăm toate arhetipurile în ordine.
1. Faceți toate lucrările vizibile: Faceți vizibilă munca
Majoritatea companiilor cu care lucrez au un procent foarte mare de muncă necunoscută. De exemplu, acesta este atunci când un angajat vine la altul și pur și simplu cere să facă ceva. În organizațiile mari, poate exista 60% muncă neplanificată. Și până la 40% din lucrări nu sunt documentate în niciun fel. Dacă ar fi fost Boeing, nu m-aș mai urca în avionul lor în viața mea. Dacă doar jumătate din lucrare este documentată, atunci nu se știe dacă această lucrare este efectuată corect sau nu. Toate celelalte metode se dovedesc a fi inutile - nu are rost să încerci să automatizezi ceva, deoarece 50% cunoscut poate fi cea mai coerentă și clară parte a muncii, a cărei automatizare nu va da rezultate grozave și tot mai rău. lucrurile sunt în jumătatea invizibilă. În lipsa documentației, este imposibil să găsești tot felul de hack-uri și lucrări ascunse, să nu găsești blocaje, tocmai acele „Brent-uri” despre care am vorbit deja. Există o carte minunată de Dominica DeGrandis . Ea dezvăluie cinci „scurgeri de timp” diferite (hotii de timp):
- Prea mult lucru în proces (WIP)
- Dependențe necunoscute
- Muncă neplanificată
- Priorități contradictorii
- Munca neglijată
Aceasta este o analiză foarte valoroasă și cartea este grozavă, dar toate aceste sfaturi sunt inutile dacă doar 50% din date sunt vizibile. Metodele propuse de Dominica pot fi utilizate dacă se obține o precizie de peste 90%. Vorbesc despre situații în care un șef îi dă unui subordonat o sarcină de 15 minute, dar îi ia trei zile; dar șeful nu prea știe că acest subordonat este dependent de încă patru-cinci persoane.
Proiectul Phoenix este o poveste minunată despre un proiect care a întârziat cu trei ani. Din această cauză, unul dintre personaje se confruntă cu demiterea și se întâlnește cu un alt personaj care este prezentat ca un fel de Socrate. El ajută să-și dea seama ce anume a mers prost. Se pare că compania are un administrator de sistem, al cărui nume este Brent, și toată munca trece cumva prin el. La una dintre întâlniri, unul dintre subalterni este întrebat: de ce fiecare sarcină de jumătate de oră durează o săptămână? Răspunsul este o prezentare foarte simplificată a teoriei cozilor și a legii lui Little, iar în această prezentare reiese că la o ocupare de 90%, fiecare oră de muncă durează 9 ore. Fiecare sarcină trebuie trimisă altor șapte persoane, astfel încât acea oră să devină 63 de ore, de 7 ori 9. Ceea ce spun este că, pentru a folosi Legea lui Little sau orice teorie complexă a cozii de așteptare, trebuie cel puțin să aveți date.
Deci, când vorbesc despre vizibilitate, nu mă refer la faptul că totul este pe ecran, ci că măcar ai date. Când o fac, se dovedește adesea că există o cantitate foarte mare de muncă neplanificată care este cumva trimisă la Brent atunci când nu este nevoie de ea. Și Brent este un tip grozav, nu va spune niciodată nu, dar nu spune nimănui cum își face treaba.
Când lucrarea este vizibilă, datele pot fi clasificate cu grijă (așa face Dominika în fotografie), se poate aplica abstractizarea celor cinci scurgeri de timp și poate fi aplicată automatizarea.
2. Consolidarea sistemelor de management al muncii: managementul sarcinilor
Arhetipurile despre care vorbesc sunt un fel de piramidă. Dacă primul este făcut corect, atunci al doilea este deja un fel de supliment. Multe dintre acestea nu funcționează pentru startup-uri, trebuie reținute pentru companii mai mari, cum ar fi Fortune 5000. Ultima companie pentru care am lucrat avea 10 sisteme de ticketing. O echipă a avut Remedy, alta a scris un fel de sistem propriu, o a treia a folosit Jira, iar unele s-au descurcat cu e-mailul. Aceeași problemă apare dacă compania are 30 de conducte diferite, dar nu am timp să discut toate astfel de cazuri.
Discutam cu oamenii exact cum sunt create biletele, ce se întâmplă cu ei în continuare și cum sunt ocolite. Cel mai interesant lucru este că oamenii de la întâlnirile noastre vorbesc destul de sincer. Am întrebat câți oameni pun „impact minor/nicio impact” pe bilete cărora ar trebui de fapt să li se acorde „impact major”. S-a dovedit că aproape toată lumea face asta. Nu mă angajez în denunț și încerc în toate modurile posibile să nu identific oamenii. Când îmi mărturisesc cu sinceritate ceva, nu dau persoana respectivă. Dar când aproape toată lumea ocolește sistemul, înseamnă că toată securitatea este, în esență, vitrine. Prin urmare, nu se pot trage concluzii din datele acestui sistem.
Pentru a rezolva problema biletului, trebuie să alegeți un sistem principal. Dacă folosești Jira, păstrează-l Jira. Dacă există vreo alternativă, să fie singura. Concluzia este că biletele ar trebui privite ca un alt pas în procesul de dezvoltare. Fiecare acțiune trebuie să aibă un bilet, care trebuie să curgă prin fluxul de lucru de dezvoltare. Biletele sunt trimise echipei, care le postează pe storyboard și apoi își asumă responsabilitatea pentru ele.
Acest lucru se aplică tuturor departamentelor, inclusiv infrastructurii și operațiunilor. În acest caz, este posibil să se formeze cel puțin o idee plauzibilă a stării de fapt. Odată ce acest proces este stabilit, devine brusc ușor de identificat cine este responsabil pentru fiecare aplicație. Pentru că acum primim nu 50%, ci 98% din noile servicii. Dacă acest proces de bază funcționează, atunci precizia se îmbunătățește în întregul sistem.
Conducta de servicii
Acest lucru se aplică din nou numai pentru marile corporații. Dacă sunteți o companie nouă într-un domeniu nou, suflecați-vă mânecile și lucrați cu Travis CI sau CircleCI. Când vine vorba de companiile din Fortune 5000, un caz concret care s-a întâmplat la banca în care lucram. Google a venit la ei și li s-au arătat diagrame ale vechilor sisteme IBM. Băieții de la Google au întrebat confuzi - unde este codul sursă pentru asta? Dar nu există cod sursă, nici măcar un GUI. Aceasta este realitatea cu care trebuie să se confrunte marile organizații: înregistrări bancare vechi de 40 de ani pe un mainframe străvechi. Unul dintre clienții mei folosește containere Kubernetes cu modele Circuit Breaker, plus Chaos Monkey, toate pentru aplicația KeyBank. Dar aceste containere se conectează în cele din urmă la o aplicație COBOL.
Băieții de la Google erau complet încrezători că vor rezolva toate problemele clientului meu și apoi au început să pună întrebări: ce este IBM datapipe? Li se spune: acesta este un conector. La ce se conectează? Spre sistemul Sperry. Si ce-i aia? Și așa mai departe. La prima vedere pare: ce fel de DevOps poate exista? Dar, de fapt, este posibil. Există sisteme de livrare care vă permit să predați fluxul de lucru către echipele de livrare.
3. Teoria constrângerilor: Teoria constrângerilor
Să trecem la al treilea arhetip: cunoașterea instituțională/„tribală”. De regulă, în orice organizație există mai mulți oameni care știu totul și gestionează totul. Aceștia sunt cei care au fost în organizație cel mai mult timp și care cunosc toate soluțiile.
Când acest lucru apare pe diagramă, încercuiesc în mod special astfel de oameni cu un marker: de exemplu, se dovedește că un anume Lou este prezent la toate întâlnirile. Și îmi este clar: acesta este Brent local. Când CIO alege între mine în tricou și adidași și tipul de la IBM într-un costum, sunt ales pentru că îi pot spune directorului lucruri pe care celălalt tip nu le va spune și pe care directorului ar putea să nu-i placă să le audă . Le spun că blocajul în compania lor este cineva pe nume Fred și cineva pe nume Lou. Acest blocaj trebuie dezlegat, cunoștințele lor trebuie obținute de la ei într-un fel sau altul.
Pentru a rezolva acest tip de problemă, pot, de exemplu, să sugerez utilizarea Slack. Un director inteligent va întreba - de ce? De obicei, în astfel de cazuri, consultanții DevOps răspund: pentru că toată lumea o face. Dacă regizorul este cu adevărat deștept, va spune: și ce. Și aici se termină dialogul. Și răspunsul meu la aceasta este: pentru că există patru blocaje în companie, Fred, Lou, Susie și Jane. Pentru a le instituționaliza cunoștințele, trebuie mai întâi să introduceți Slack. Toate wiki-urile tale sunt complet prostii pentru că nimeni nu știe despre existența lor. Dacă echipa de ingineri este implicată în dezvoltarea front-end și back-end și toată lumea trebuie să știe că poate contacta echipa de dezvoltare front-end sau echipa de infrastructură cu întrebări. Atunci Lou sau Fred vor avea probabil timp să se alăture wiki. Și apoi, în Slack, cineva s-ar putea întreba de ce, să zicem, pasul 5 nu funcționează. Și apoi Lou sau Fred vor corecta instrucțiunile de pe wiki. Dacă stabiliți acest proces, atunci o mulțime de lucruri se vor pune în aplicare de la sine.
Acesta este punctul meu principal: pentru a recomanda orice tehnologii înalte, trebuie mai întâi să le puneți în ordine fundația, iar acest lucru se poate face cu soluțiile low-tech tocmai descrise. Dacă începeți cu tehnologii înalte și nu explicați de ce sunt necesare, atunci, de regulă, acest lucru nu se termină bine. Unul dintre clienții noștri folosește Azure ML, o soluție foarte ieftină și simplă. Aproximativ 30% dintre întrebările lor au primit răspuns de la mașina de auto-învățare în sine. Și chestia asta a fost scrisă de operatori care nu erau implicați în știința datelor, statistică sau matematică. Acest lucru este semnificativ. Costul unei astfel de soluții este minim.
4. Hack-uri de colaborare: Hack-uri de colaborare
Al patrulea arhetip este nevoia de a combate izolarea. Majoritatea oamenilor știu deja acest lucru: izolarea generează ostilitate. Dacă fiecare departament se află la propriul etaj și oamenii nu se intersectează între ei în niciun fel, cu excepția liftului, atunci ostilitatea între ei apare foarte ușor. Dar dacă, dimpotrivă, oamenii sunt în aceeași cameră unii cu alții, ea pleacă imediat. Când cineva aruncă o acuzație generală, de exemplu, o astfel de interfață nu funcționează niciodată, nu este nimic mai ușor de deconstruit o astfel de acuzație. Programatorii care au scris interfața trebuie doar să înceapă să pună întrebări specifice și în curând va deveni clar că, de exemplu, utilizatorul folosea pur și simplu instrumentul incorect.
Există multe modalități de a depăși izolarea. Mi s-a cerut odată să consult pentru o bancă din Australia, dar am refuzat să o fac pentru că am doi copii și o soție. Tot ce puteam face pentru a-i ajuta a fost să recomand povestiri grafice. Acesta este ceva care s-a dovedit a funcționa. Un alt mod interesant sunt întâlnirile de cafea slabă. Într-o organizație mare, aceasta este o opțiune excelentă pentru diseminarea cunoștințelor. În plus, puteți desfășura zile de devops interne, hackathon-uri și așa mai departe.
5. Coaching Kata
După cum am avertizat chiar de la început, nu voi vorbi despre asta astăzi. Dacă ești interesat, poți arunca o privire .
Există, de asemenea, o discuție bună despre acest subiect de la Mike Rother:
6. Orientat pe piață: organizație orientată spre piață
Aici sunt probleme diferite. De exemplu, oamenii „I”, oamenii „T” și oamenii „E”. Oamenii „eu” sunt cei care fac un singur lucru. De obicei, acestea există în organizații cu departamente izolate. „T” este atunci când o persoană este bună la un lucru, dar și la alte lucruri. „E” sau chiar „pieptene” este atunci când o persoană are multe abilități.
Legea lui Conway funcționează aici (), care în cea mai simplificată formă poate fi afirmată după cum urmează: dacă trei echipe lucrează la compilator, atunci rezultatul va fi un compilator din trei părți. Prin urmare, dacă există un nivel ridicat de izolare în cadrul unei organizații, atunci chiar și Kubernetes, Circuit breaker, extensibilitatea API și alte lucruri de lux din această organizație vor fi aranjate în același mod ca organizația însăși. Strict conform lui Conway și pentru a vă ciudă pe toți tinerii tocilari.
Soluția la această problemă a fost descrisă de mai multe ori. Există, de exemplu, arhetipuri organizaționale descrise de Fernando Fernandez. Acea arhitectură problematică despre care tocmai am vorbit, cu izolare, este o arhitectură orientată pe funcție. Al doilea tip este cel mai prost, arhitectura matriceală, o mizerie din celelalte două. Al treilea este ceea ce se vede la majoritatea startup-urilor, iar companiile mari încearcă și ele să se potrivească cu acest tip. Este o organizație orientată spre piață. Aici ne optimizăm pentru a obține cel mai rapid răspuns la solicitările clienților. Aceasta se numește uneori o organizație plată.
Mulți oameni descriu această structură în moduri diferite, îmi place formularea construi/conduce echipe, la Amazon o numesc două echipe de pizza. În această structură, toți oamenii de tip „I” sunt grupați în jurul unui serviciu și treptat se apropie de tipul „T”, iar dacă există managementul corect, pot deveni chiar „E”. Primul contraargument aici este că o astfel de structură conține elemente inutile. De ce ai nevoie de un tester în fiecare departament dacă poți avea un departament special de testeri? La care răspund: costurile suplimentare în acest caz reprezintă prețul pentru ca întreaga organizație să devină tip „E” în viitor. În această structură, testerul învață treptat despre rețele, arhitectură, design etc. Ca rezultat, fiecare participant din organizație este pe deplin conștient de tot ceea ce se întâmplă în organizație. Dacă doriți să aflați cum funcționează această schemă în industrie, citiți .
7. Auditorii cu schimbarea la stânga: auditați la începutul ciclului. Respectarea regulilor de siguranță afișate
Acesta este momentul în care acțiunile tale nu trec testul de miros, ca să spunem așa. Oamenii care lucrează pentru tine nu sunt proști. Dacă, ca în exemplul de mai sus, au stabilit un impact minor/nicio impact peste tot, asta a durat trei ani, și nimeni nu a observat nimic, atunci toată lumea știe perfect că sistemul nu funcționează. Sau un alt exemplu - un consiliu consultativ pentru schimbare, unde rapoartele trebuie depuse în fiecare, să zicem, miercuri. Acolo lucrează un grup de oameni (nu foarte bine plătiți, de altfel) care, teoretic, ar trebui să știe cum funcționează sistemul în ansamblu. Și în ultimii cinci ani, probabil ați observat că sistemele noastre sunt incredibil de complexe. Și cinci sau șase oameni trebuie să ia o decizie cu privire la o schimbare pe care nu au făcut-o și despre care nu știu nimic.
Desigur, această abordare nu funcționează. Trebuie să scap de astfel de lucruri pentru că acești oameni nu protejează sistemul. Decizia trebuie luată chiar de echipă, pentru că echipa trebuie să fie responsabilă pentru aceasta. În caz contrar, apare o situație paradoxală când un manager care nu a scris cod în viața lui îi spune programatorului cât timp ar trebui să dureze pentru a scrie cod. O companie cu care am lucrat avea 7 consilii diferite care au revizuit fiecare modificare, inclusiv o placă de arhitectură, o placă de produs etc. A existat 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 vreodată o modificare făcută de această persoană în această perioadă obligatorie.
Auditorii trebuie să fie invitați să ni se alăture și să nu scape de ei. Spune-le că scrii containere binare imuabile care, dacă trec toate testele, rămân imuabile pentru totdeauna. Spune-le că ai o conductă ca cod și explică ce înseamnă asta. Arată-le următoarea schemă: un binar imuabil doar pentru citire într-un container care trece toate testele de vulnerabilitate; și atunci nu numai că nimeni nu îl atinge, ci nici măcar nu atinge sistemul care creează conducta, deoarece este și creat dinamic. Am clienți, Capital One, care folosesc Vault pentru a crea ceva ca un blockchain. Auditorul nu trebuie să arate „rețete” de la Chef; este suficient să arate blockchain-ul, din care se vede clar ce s-a întâmplat cu biletul Jira în producție și cine este responsabil pentru acesta.
În conformitate cu , creat în 2018 de Sonatype, au existat 2017 de miliarde de solicitări de descărcare OSS în 87.
Pierderile suferite din cauza vulnerabilităților sunt prohibitive. Mai mult, cifrele pe care le vedeți acum mai sus nu includ costurile de oportunitate. Ce este DevSecOps pe scurt? Permiteți-mi să spun imediat că nu mă interesează să vorbesc despre cât de succes are acest nume. Ideea este că, deoarece DevOps a avut atât de mult succes, ar trebui să încercăm să adăugăm securitate la această conductă.
Un exemplu al acestei secvențe:
Aceasta nu este o recomandare pentru anumite produse, deși îmi plac toate. Le-am citat ca exemplu pentru a arăta că DevOps, care s-a bazat inițial pe paradigma organizațională din industrie, vă permite să automatizați fiecare etapă de lucru asupra unui produs.
Și nu există niciun motiv pentru care să nu putem adopta aceeași abordare a securității.
Total
Ca o concluzie, voi oferi câteva sfaturi pentru DevSecOps. Trebuie să includeți auditori în procesul de creare a sistemelor dvs. și să petreceți timp educandu-i. Trebuie să cooperezi cu auditorii. În continuare, trebuie să duci o luptă absolut nemilos împotriva falselor pozitive. Chiar și cu cel mai scump instrument de scanare a vulnerabilităților, puteți ajunge să creați obiceiuri extrem de proaste în rândul dezvoltatorilor dvs. dacă nu știți care este raportul semnal-zgomot. Dezvoltatorii vor fi copleșiți de evenimente și le vor șterge pur și simplu. Dacă ați auzit despre povestea Equifax, cam așa s-a întâmplat acolo, unde cel mai înalt nivel de alertă a fost ignorat. În plus, vulnerabilitățile trebuie explicate într-un mod care să clarifice modul în care acestea influențează afacerea. De exemplu, ați putea spune că aceasta este aceeași vulnerabilitate ca în povestea Equifax. Vulnerabilitățile de securitate ar trebui tratate la fel ca și alte probleme de software, adică ar trebui incluse în procesul general DevOps. Trebuie să lucrați cu ei prin Jira, Kanban etc. Dezvoltatorii nu ar trebui să creadă că altcineva va face asta - dimpotrivă, toată lumea ar trebui să facă asta. În cele din urmă, trebuie să cheltuiți energie pentru formarea oamenilor.
Link-uri utile
Iată câteva discuții de la conferința DevOops pe care le puteți găsi utile:
- Sergey Berdnikov, Artyom Kalichkin - Povestea de succes sau „Dev+DevOps+Ops” (, )
- Baruch Sadogursky, Leonid Igolnik - DevOps la scară: o tragedie grecească în trei acte (, )
- Alexander Titov, Kirill Tolkachev -
- Timothy Lister -
Privește DevOops 2020 Moscova — există și o mulțime de lucruri interesante acolo.
Sursa: www.habr.com