{"id":41818,"date":"2020-02-16T20:46:08","date_gmt":"2020-02-16T17:46:08","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/sem-arhetipov-prevrashheniya-po-princzipam-devops"},"modified":"2020-02-16T20:46:08","modified_gmt":"2020-02-16T17:46:08","slug":"sem-arhetipov-prevrashheniya-po-princzipam-devops","status":"publish","type":"post","link":"https:\/\/prohoster.info\/ro\/blog\/sem-arhetipov-prevrashheniya-po-princzipam-devops","title":{"rendered":"\u0218apte arhetipuri de transformare conform principiilor DevOps","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\u00centrebarea \u201ecum s\u0103 implement\u0103m DevOps\u201d exist\u0103 de c\u00e2\u021biva ani, dar nu sunt multe materiale bune. Uneori, devii victima publicit\u0103\u021bii unor consultan\u021bi nu foarte inteligen\u021bi, care trebuie s\u0103 \u00ee\u0219i v\u00e2nd\u0103 timpul, indiferent de modalitate. Uneori, sunt cuvinte vagi, extrem de generale despre cum navele mega-corpora\u021biilor navigheaz\u0103 prin vastitatea universului. Se ridic\u0103 \u00eentrebarea: care este beneficiul pentru noi? Stimate autor, ne pute\u021bi prezenta clar ideile dumneavoastr\u0103 sub form\u0103 de list\u0103?<\/p>\n

Toate acestea decurg din faptul c\u0103 experien\u021ba real\u0103 \u0219i \u00een\u021belegerea rezultatelor transform\u0103rilor culturii organizatorice s-au acumulat nu at\u00e2t de mult. Schimb\u0103rile culturale sunt procese de durat\u0103, ale c\u0103ror rezultate nu vor ap\u0103rea peste o s\u0103pt\u0103m\u00e2n\u0103 \u0219i nici peste o lun\u0103. Avem nevoie de cineva suficient de experimentat, care s\u0103 fi v\u0103zut cum s-au creat \u0219i distrus companii de-a lungul anilor.<\/p>\n

\"\u0218apte
\n
\nJohn Willis<\/b> \u2014 unul dintre p\u0103rin\u021bii DevOps. John are \u00een spate zeci de ani de lucru cu un num\u0103r mare de companii. Recent, John a \u00eenceput s\u0103 observe tipare specifice care se manifest\u0103 \u00een colaborarea cu fiecare dintre acestea. Folosind aceste arhetipuri, John \u00eendrum\u0103 companiile pe calea adev\u0103ratei transform\u0103ri DevOps. Mai multe despre aceste arhetipuri \u2014 \u00een traducerea discursului s\u0103u de la conferin\u021ba DevOops 2018.
\n<\/a><\/noindex>
\n

\r\n \"Reda\u021bi\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Despre vorbitor:<\/b><\/p>\n

Peste 35 de ani \u00een management IT, a participat la crearea predecesorului OpenCloud la Canonical, a fost implicat \u00een 10 startup-uri, dou\u0103 dintre acestea fiind v\u00e2ndute Dell \u0219i Docker. \u00cen prezent, este Vicepre\u0219edinte pentru DevOps \u0219i Practici Digitale la SJ Technologies.<\/p>\n

Mai departe \u2014 povestea din perspectiva lui John.<\/b><\/p>\n

M\u0103 numesc John Willis, \u0219i m\u0103 pute\u021bi g\u0103si cel mai u\u0219or pe Twitter, @botchagalupe<\/a><\/noindex>. Acela\u0219i pseudonim \u00eel folosesc \u0219i pe Gmail \u0219i GitHub. \u0218i la acest link<\/a><\/noindex> pute\u021bi g\u0103si \u00eenregistr\u0103ri video ale discursurilor mele \u0219i prezent\u0103rile acestora.<\/p>\n

Am multe \u00eent\u00e2lniri cu CIO-uri din diverse mari companii. Adesea, ei se pl\u00e2ng c\u0103 nu \u00een\u021beleg ce este DevOps, iar to\u021bi cei care \u00eencearc\u0103 s\u0103 le explice vorbesc despre lucruri personale. O alt\u0103 pl\u00e2ngere frecvent\u0103 este c\u0103 DevOps nu func\u021bioneaz\u0103, de\u0219i, aparent, directorii fac tot ce le-a fost explicat. Este vorba despre mari companii, cu peste o sut\u0103 de ani vechime. Dup\u0103 ce am discutat cu ei, am ajuns la concluzia c\u0103, \u00een multe dintre aceste probleme, solu\u021biile de tehnologie joas\u0103 sunt mai adecvate dec\u00e2t cele de \u00eenalt\u0103 tehnologizare. Timp de s\u0103pt\u0103m\u00e2ni, am dialogat pur \u0219i simplu cu oameni din departamente diferite. Ceea ce vede\u021bi \u00een prima imagine din postare este ultimul meu proiect, camera ar\u0103ta a\u0219a dup\u0103 trei zile de munc\u0103.<\/p>\n

Ce este DevOps?<\/h2>\n

\nAdev\u0103rat, dac\u0103 \u00eentrebi 10 persoane diferite, acestea \u00ee\u021bi vor oferi 10 r\u0103spunsuri diferite. Dar iat\u0103 ce este interesant: toate aceste zece r\u0103spunsuri vor fi corecte. Nu exist\u0103 un r\u0103spuns gre\u0219it aici. M-am ocupat destul de profund de DevOps, timp de aproximativ 10 ani, fiind primul american la primul DevOpsDay. Nu a\u0219 spune c\u0103 sunt mai de\u0219tept dec\u00e2t to\u021bi cei care se ocupa de DevOps, dar e pu\u021bin probabil s\u0103 existe cineva care a investit la fel de mult efort. Consider c\u0103 DevOps apare atunci c\u00e2nd capitalul uman se \u00eembin\u0103 cu tehnologia. Adesea uit\u0103m de dimensiunea uman\u0103, de\u0219i vorbim mult despre diverse culturi. <\/p>\n

\"\u0218apte
\n
\n\u00cen prezent, avem multe date, cinci ani de cercet\u0103ri academice, \u0219i verificarea teoriilor este desf\u0103\u0219urat\u0103 la scar\u0103 industrial\u0103. Aceste cercet\u0103ri ne spun urm\u0103toarele: dac\u0103 \u00een cultura organiza\u021bional\u0103 se combin\u0103 anumite tipare comportamentale, se poate ob\u021bine o accelerare de 2000 de ori. Aceast\u0103 accelerare corespunde cu o \u00eembun\u0103t\u0103\u021bire similar\u0103 \u00een rezilien\u021b\u0103. Aceasta este o m\u0103surare cantitativ\u0103 a avantajului pe care DevOps \u00eel poate aduce oric\u0103rei companii. Cu c\u00e2\u021biva ani \u00een urm\u0103, am vorbit despre DevOps cu directorul general al unei companii din lista Fortune 5000. C\u00e2nd m-am preg\u0103tit pentru prezentare, eram foarte emo\u021bionat, deoarece trebuia s\u0103 sintetizez experien\u021ba mea de mul\u021bi ani \u00een 5 minute. <\/p>\n

\u00cen final, am dat urm\u0103toarea defini\u021bie DevOps<\/b>: este un set de practici \u0219i tipare care permit transformarea capitalului uman \u00een capital organiza\u021bional de \u00eenalt\u0103 performan\u021b\u0103. Un exemplu poate fi modul \u00een care Toyota a func\u021bionat \u00een ultimii 50 sau 60 de ani.<\/p>\n

\"\u0218apte
\n
\n(Aici \u0219i mai departe, aceste scheme nu sunt prezentate ca material de referin\u021b\u0103, ci ca ilustra\u021bie. Con\u021binutul lor va varia pentru fiecare companie nou\u0103. Cu toate acestea, imaginea poate fi vizualizat\u0103 \u0219i m\u0103rit\u0103 separat la acest link.)<\/a><\/noindex><\/i><\/p>\n

Una dintre cele mai de succes astfel de practici este mappingul fluxului de valoare<\/b>. Despre aceasta s-au scris c\u00e2teva c\u0103r\u021bi bune, autorul celei mai de succes fiind Karen Martin. Dar \u00een ultimul an, am ajuns la concluzia c\u0103 chiar \u0219i acest abordare este prea tehnologic\u0103. Are, f\u0103r\u0103 \u00eendoial\u0103, multe avantaje, de care m-am folosit mult. Dar atunci c\u00e2nd directorul executiv te \u00eentreab\u0103 de ce compania sa nu poate trece la noi c\u0103i, despre mappingul fluxului de valoare este prea devreme s\u0103 discut\u0103m. Exist\u0103 multe \u00eentreb\u0103ri fundamental mai importante la care trebuie s\u0103 g\u0103sim r\u0103spunsuri preliminare. <\/p>\n

Mi se pare c\u0103 gre\u0219eala multor colegi este c\u0103 pur \u0219i simplu ofer\u0103 companiei un ghid \u00een cinci puncte \u0219i apoi se \u00eentorc dup\u0103 \u0219ase luni pentru a vedea ce s-a \u00eent\u00e2mplat. Chiar \u0219i o schem\u0103 bun\u0103, precum mappingul fluxului de valoare, are, a\u0219a-zisele, zone moarte (blind spots). Dup\u0103 sute de interviuri cu directorii diferitelor companii, am dezvoltat un anumit model care permite descompunerea problemei \u00een elementele sale de baz\u0103, iar acum vom discuta sistematic fiecare din aceste componente. \u00cenainte de a aplica orice solu\u021bii tehnologice, folosesc acest model \u0219i, ca urmare, toate pere\u021bii mei ajung s\u0103 fie plini de scheme. Recent, am lucrat cu un fond mutual \u0219i, \u00een cele din urm\u0103, am avut 100-150 astfel de scheme.<\/p>\n

O cultur\u0103 proast\u0103 devoreaz\u0103 bunele abord\u0103ri la micul dejun<\/h2>\n

\nIdeea principal\u0103 este urm\u0103toarea: nici Lean, Agile, SAFE \u0219i DevOps nu vor ajuta dac\u0103 cultura organiza\u021biei este proast\u0103. Este la fel ca \u0219i cum ai s\u0103ri \u00een ad\u00e2ncime f\u0103r\u0103 echipament de scufundare sau ai opera f\u0103r\u0103 o radiografie. Cu alte cuvinte, parafraz\u00e2ndu-i pe Drucker \u0219i Deming: o cultur\u0103 organiza\u021bional\u0103 proast\u0103 va \u00eenghi\u021bi orice sistem bun \u0219i nu se va vedea. <\/p>\n

Pentru a rezolva aceast\u0103 problem\u0103 principal\u0103, este necesar s\u0103 \u00eentreprindem urm\u0103torii pa\u0219i:<\/p>\n

    \n
  1. Face\u021bi toat\u0103 munca vizibil\u0103:<\/b> este nevoie s\u0103 facem toat\u0103 munca vizibil\u0103. Nu \u00een sensul c\u0103 trebuie s\u0103 fie neap\u0103rat afi\u0219at\u0103 pe un ecran, ci \u00een sensul c\u0103 trebuie s\u0103 fie observabil\u0103.<\/li>\n
  2. Consolida\u021bi sistemele de management al muncii:<\/b> este necesar s\u0103 consolid\u0103m sistemele de management. \u00cen problema cuno\u0219tin\u021belor \u201etribale\u201d \u0219i cuno\u0219tin\u021belor institu\u021bionale, \u00een 9 cazuri din 10, blocajele sunt cauzate de oameni. \u00cen cartea \u201ePhoenix Project\u201d<\/a><\/noindex> problema a fost un singur om, Brent, care a \u00eent\u00e2rziat proiectul cu trei ani. \u0218i pe astfel de \u201eBrenturi\u201d dau peste tot. Pentru a rezolva aceste blocaje, folosesc urm\u0103toarele dou\u0103 puncte din lista noastr\u0103. <\/li>\n
  3. Teoria constr\u00e2ngerilor:<\/b> teoria constr\u00e2ngerilor.<\/li>\n
  4. Trucuri de colaborare:<\/b> hack-uri de colaborare. <\/li>\n
  5. Toyota Kata (Coaching Kata<\/a><\/noindex>):<\/b> nu voi vorbi prea mult despre Toyota Kata. Dac\u0103 e\u0219ti interesat, pe GitHub-ul meu exist\u0103 prezent\u0103ri<\/a><\/noindex> aproape pe fiecare dintre aceste teme. <\/li>\n
  6. Organiza\u021bie orientat\u0103 pe pia\u021b\u0103:<\/b> organiza\u021bie orientat\u0103 pe pia\u021b\u0103.<\/li>\n
  7. Auditori shift-left:<\/b> auditori \u00een etapele anterioare ale ciclului.<\/li>\n<\/ol>\n

    \"\u0218apte
    \n
    \n\u00cencep lucrul cu organiza\u021bia foarte simplu: m\u0103 duc \u00een companie \u0219i discut cu angaja\u021bii. Dup\u0103 cum vedem, nu sunt tehnologii de v\u00e2rf. Tot ce este necesar este s\u0103 am cu ce scrie. Adun c\u00e2teva echipe \u00eentr-o camer\u0103 \u0219i analizez ceea ce \u00eemi spun din perspectiva celor 7 arhetipuri ale mele. Apoi, le dau un marker \u0219i \u00eei rog s\u0103 formuleze pe tabl\u0103 tot ceea ce au spus p\u00e2n\u0103 acum cu voce tare. De obicei, la astfel de \u00eent\u00e2lniri este o persoan\u0103 care noteaz\u0103 totul, iar \u00een cel mai bun caz reu\u0219e\u0219te s\u0103 consemneze 10% din discu\u021bie. Folosind metoda mea, acest procentaj se poate ridica la aproximativ 40%. <\/p>\n

    \"\u0218apte
    \n
    \n(Aceast\u0103 ilustra\u021bie poate fi     vizualizat\u0103 la link<\/a><\/noindex>)<\/i><\/p>\n

    Abordarea mea se bazeaz\u0103 pe lucr\u0103rile lui William Schneider (William Schneider, The Reengineering Alternative<\/a><\/noindex>). La baza acestei abord\u0103ri st\u0103 ideea c\u0103 orice organiza\u021bie poate fi descompus\u0103 \u00een patru p\u0103trate. Aceast\u0103 schem\u0103 de obicei rezult\u0103 din munca cu sutele de alte scheme care apar \u00een analiza organiza\u021biei. S\u0103 presupunem c\u0103 avem o organiza\u021bie cu un nivel mare de control, dar cu o competen\u021b\u0103 sc\u0103zut\u0103. Acesta este un scenariu extrem de nedorit: c\u00e2nd toat\u0103 lumea respect\u0103 regulile, dar nimeni nu \u0219tie ce trebuie s\u0103 fac\u0103. <\/p>\n

    O variant\u0103 u\u0219or superioar\u0103, cu un nivel \u00eenalt at\u00e2t de control, c\u00e2t \u0219i de competen\u021b\u0103. Dac\u0103 o astfel de companie este profitabil\u0103, atunci poate c\u0103 DevOps nu-i este necesar\u0103. Cel mai interesant este s\u0103 lucrezi cu o companie care are un nivel ridicat de control, o competen\u021b\u0103 sc\u0103zut\u0103 \u0219i colaborare, dar \u00een acela\u0219i timp o cultur\u0103 organiza\u021bional\u0103 ridicat\u0103. Asta \u00eenseamn\u0103 c\u0103 \u00een companie sunt mul\u021bi oameni care le place s\u0103 lucreze acolo, iar rota\u021bia personalului este mic\u0103. <\/p>\n

    \"\u0218apte
    \n
    \n(Aceast\u0103 ilustra\u021bie poate fi     vizualizat\u0103 la link<\/a><\/noindex>)<\/i><\/p>\n

    Mi se pare c\u0103 metodele cu recomand\u0103ri strict definite \u00een cele din urm\u0103 \u00eempiedic\u0103 atingerea adev\u0103rului. \u00cen special, \u00een value stream mapping exist\u0103 multe reguli privind modul \u00een care ar trebui s\u0103 fie structurat\u0103 informa\u021bia. \u00cen fazele incipiente de lucru, despre care discut acum, aceste reguli nu sunt necesare. Dac\u0103 o persoan\u0103 cu un marker \u00een m\u00e2n\u0103 descrie pe o tabl\u0103 situa\u021bia real\u0103 din companie - acesta este cel mai bun mod de a \u00een\u021belege situa\u021bia. Aceast\u0103 informa\u021bie nu ajunge la directori. \u00cen acel moment, este prostesc s\u0103 opre\u0219ti persoana \u0219i s\u0103-i spui c\u0103 a desenat o s\u0103geat\u0103 gre\u0219it\u0103. \u00cen aceast\u0103 etap\u0103, este mai bine s\u0103 folose\u0219ti reguli simple; de exemplu, po\u021bi crea o abstrac\u021bie multi-nivel utiliz\u00e2nd doar markere colorate. <\/p>\n

    Repet, f\u0103r\u0103 tehnologii avansate. Cu markerul negru se ilustreaz\u0103 realitatea obiectiv\u0103, cum func\u021bioneaz\u0103 totul. Cu markerul ro\u0219u, oamenii noteaz\u0103 ce nu le place \u00een situa\u021bia existent\u0103. Este important c\u0103 ei scriu asta, nu eu. C\u00e2nd dup\u0103 \u00eent\u00e2lnire m\u0103 \u00eendrept spre directorul IT, nu-i propun o list\u0103 de 10 lucruri pe care s\u0103 le corecteze. \u00cencerc s\u0103 g\u0103sesc leg\u0103turi \u00eentre ceea ce spun oamenii din companie \u0219i modelele validate existente. \u00cen cele din urm\u0103, cu markerul albastru se propun solu\u021bii posibile pentru problem\u0103. <\/p>\n

    \"\u0218apte
    \n
    \n(Aceast\u0103 ilustra\u021bie poate fi     vizualizat\u0103 la link<\/a><\/noindex>)<\/i><\/p>\n

    Un exemplu al acestei abord\u0103ri este prezentat mai sus. La \u00eenceputul acestui an am lucrat cu o banc\u0103. Angaja\u021bii din departamentul de securitate erau convin\u0219i c\u0103 nu trebuie s\u0103 vin\u0103 la verific\u0103rile cerin\u021belor \u0219i proiect\u0103rii (design and requirement reviews). <\/p>\n

    \"\u0218apte
    \n
    \n(Aceast\u0103 ilustra\u021bie poate fi     vizualizat\u0103 la link<\/a><\/noindex>)<\/i><\/p>\n

    Apoi am vorbit cu oameni din alte departamente \u0219i am aflat c\u0103 cu aproximativ 8 ani \u00een urm\u0103, dezvoltatorii de software i-au exclus pe angaja\u021bii de securitate, deoarece ace\u0219tia \u00eencetineau munca. Apoi, acest lucru s-a transformat \u00eentr-o interdic\u021bie care era perceput\u0103 ca o dat\u0103. Cu toate acestea, de fapt, nu exista nicio interdic\u021bie. <\/p>\n

    \u00cent\u00e2lnirea noastr\u0103 a avut un parcurs extrem de complicat: timp de aproape trei ore, cinci echipe diferite nu au reu\u0219it s\u0103-mi explice ce se \u00eent\u00e2mpl\u0103 \u00eentre cod \u0219i compilare. Iar aceasta ar p\u0103rea a fi cel mai simplu lucru. Majoritatea consultantilor DevOps presupun dinainte c\u0103 toat\u0103 lumea \u0219tie deja acest lucru. <\/p>\n

    Apoi, persoana responsabil\u0103 de reglementarea IT (IT governance), care a t\u0103cut timp de patru ore, a prins via\u021b\u0103 brusc atunci c\u00e2nd am ajuns la subiectul s\u0103u \u0219i ne-a ocupat timp de \u00eenc\u0103 o perioad\u0103 destul de lung\u0103. La final, l-am \u00eentrebat ce p\u0103rere are despre \u00eent\u00e2lnire \u0219i nu voi uita niciodat\u0103 r\u0103spunsul s\u0103u. A spus: \u201e\u00cen trecut, credeam c\u0103 banca noastr\u0103 are doar dou\u0103 modalit\u0103\u021bi de livrare a software-ului, iar acum \u0219tiu c\u0103 acestea sunt cinci, \u0219i despre trei dintre ele nici nu aveam idee\u201d. <\/p>\n

    \"\u0218apte
    \n
    \n(Aceast\u0103 ilustra\u021bie poate fi     vizualizat\u0103 la link<\/a><\/noindex>)<\/i><\/p>\n

    Ultima \u00eent\u00e2lnire \u00een aceast\u0103 banc\u0103 a fost cu echipa care se ocup\u0103 de software-ul pentru investi\u021bii. Cu ea am aflat c\u0103 este mai bine s\u0103 scrii scheme cu un marker pe o foaie dec\u00e2t pe o tabl\u0103, \u0219i chiar mai bine dec\u00e2t pe un smartboard. <\/p>\n

    \"\u0218apte
    \n
    \nFotografiile pe care le vede\u021bi arat\u0103 cum a ar\u0103tat sala de conferin\u021be a hotelului \u00een a patra zi a \u00eent\u00e2lnirii noastre. Aceste scheme le-am folosit pentru a c\u0103uta tipare, adic\u0103 arhetipuri. <\/p>\n

    A\u0219adar, pun \u00eentreb\u0103ri angaja\u021bilor, iar ei noteaz\u0103 r\u0103spunsurile cu markere de trei culori (negru, ro\u0219u \u0219i albastru). Analizez r\u0103spunsurile lor c\u0103ut\u00e2nd arhetipuri. Acum haide\u021bi s\u0103 discut\u0103m toate arhetipurile \u00een ordine. <\/p>\n

    1. Make All Work Visible: F\u0103 ca toat\u0103 munca s\u0103 fie vizibil\u0103<\/h3>\n

    \n\u00cen majoritatea companiilor cu care colaborez, exist\u0103 un procent foarte ridicat de munc\u0103 neidentificat\u0103. De exemplu, c\u00e2nd un angajat se apropie de altul \u0219i \u00eei cere pur \u0219i simplu s\u0103 fac\u0103 ceva. \u00cen organiza\u021bii mari, poate fi vorba de 60% din munc\u0103 neplanificat\u0103. \u0218i p\u00e2n\u0103 la 40% din munc\u0103 nu este documentat\u0103 \u00een niciun fel. Dac\u0103 ar fi fost Boeing, nu m-a\u0219 fi mai urcat niciodat\u0103 \u00een avionul lor. Dac\u0103 doar jum\u0103tate din munc\u0103 este documentat\u0103, nu se \u0219tie dac\u0103 acea munc\u0103 este realizat\u0103 corect sau nu. Toate celelalte metode devin inutile - nu are sens s\u0103 \u00eencerci s\u0103 automatizezi ceva, pentru c\u0103 cele 50% cunoscute pot fi tocmai partea cea mai organizat\u0103 \u0219i precis\u0103 a muncii, a c\u0103rei automatizare nu va aduce rezultate mari, iar tot ce este mai terifiant se afl\u0103 \u00een jum\u0103tatea nev\u0103zut\u0103. \u00cen absen\u021ba documenta\u021biei, nu este posibil s\u0103 g\u0103sim tot felul de hack-uri \u0219i munc\u0103 ascuns\u0103, s\u0103 identific\u0103m blocajele, acei \u201eBrent\u201d despre care am vorbit deja. Exist\u0103 o carte excelent\u0103 scris\u0103 de Dominica DeGrandis. \u201eMaking Work Visible\u201d<\/a><\/noindex>. Ea identific\u0103 cinci tipuri diferite de \u201epierderi de timp\u201d<\/b> (thieves of time):<\/p>\n