{"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\/sl\/blog\/sem-arhetipov-prevrashheniya-po-princzipam-devops","title":{"rendered":"Sedem archetypov premeny pod\u013ea princ\u00edpov DevOps","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ot\u00e1zka \"ako zavies\u0165 devops\" sa rie\u0161i u\u017e nieko\u013eko rokov, ale dobr\u00fdch materi\u00e1lov nie je ve\u013ea. Niekedy sa stanete obe\u0165ou reklamy nie a\u017e tak inteligentn\u00fdch konzultantov, ktor\u00ed potrebuj\u00fa preda\u0165 svoj \u010das, bez oh\u013eadu na to, ako. Niekedy s\u00fa to nejasn\u00e9, ve\u013emi v\u0161eobecn\u00e9 slov\u00e1 o tom, ako lode megakorpor\u00e1ci\u00ed br\u00e1zdia nekone\u010dn\u00e9 moria. Vznik\u00e1 ot\u00e1zka: a \u010do n\u00e1m z toho vypl\u00fdva? V\u00e1\u017een\u00fd autor, m\u00f4\u017eete jasne formulova\u0165 svoje my\u0161lienky v zozname?<\/p>\n

V\u0161etko to poch\u00e1dza z toho, \u017ee skuto\u010dnej praxe a porozumenia v\u00fdsledku transform\u00e1cie kult\u00fary spolo\u010dnosti nazbieralo nie tak ve\u013ea. Zmeny v kult\u00fare s\u00fa dlhodob\u00e9 veci, ktor\u00fdch v\u00fdsledky sa neprejavia do t\u00fd\u017ed\u0148a \u010di do mesiaca. Potrebujeme niekoho dostato\u010dne sk\u00fasen\u00e9ho, kto videl, ako sa spolo\u010dnosti vytv\u00e1rali a rozpadali po\u010das mnoh\u00fdch rokov.<\/p>\n

\"Sedem
\n
\nJohn Willis<\/b> \u2014 jeden z otcov DevOps. Na pleciach Johna s\u00fa desiatky rokov pr\u00e1ce s obrovsk\u00fdm mno\u017estvom spolo\u010dnost\u00ed. V poslednej dobe sa John za\u010dal s\u00e1m tr\u00e1pi\u0165 \u0161pecifick\u00fdmi vzormi, ktor\u00e9 sa prejavuj\u00fa pri pr\u00e1ci s ka\u017edou z nich. Pou\u017e\u00edvan\u00edm t\u00fdchto archetypov John usmer\u0148uje spolo\u010dnosti na prav\u00fa cestu DevOps transform\u00e1cie. Podrobnej\u0161ie o t\u00fdchto archetypoch - v preklade jeho predn\u00e1\u0161ky z konferencie DevOops 2018.
\n<\/a><\/noindex>
\n

\r\n \"Predvajaj\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

O re\u010dn\u00edkovi:<\/b><\/p>\n

Viac ako 35 rokov v IT mana\u017emente, z\u00fa\u010dastnil sa na vytvoren\u00ed predchodcu OpenCloud v Canonical, podie\u013eal sa na 10 startupoch, z ktor\u00fdch dva predal spolo\u010dnostiam Dell a Docker. Teraz je viceprezidentom pre DevOps a digit\u00e1lne praktiky v SJ Technologies.<\/p>\n

\u010ealej - rozpr\u00e1vanie z poh\u013eadu Johna.<\/b><\/p>\n

Vol\u00e1m sa John Willis a najjednoduch\u0161ie ma n\u00e1jdete na Twitteri, @botchagalupe<\/a><\/noindex>. Ten ist\u00fd pseudonym m\u00e1m na Gmaile a GitHube. A na tej povezavi<\/a><\/noindex> m\u00f4\u017eete n\u00e1js\u0165 videonahr\u00e1vky mojich predn\u00e1\u0161ok a prezent\u00e1ci\u00ed k nim.<\/p>\n

Imam veliko sestankov z CIO-ji razli\u010dnih velikih podjetij. Pogosto se prito\u017eujejo, da ne razumejo, kaj je DevOps, in vsi, ki jim to posku\u0161ajo razlo\u017eiti, govorijo o ne\u010dem svojem. Druga pogosta prito\u017eba je, da DevOps ne deluje, \u010deprav se zdi, da direktorji vse delajo tako, kot so jih pou\u010dili. Govorimo o velikih podjetjih, starosti ve\u010d kot sto let. Po pogovorih z njimi sem pri\u0161el do zaklju\u010dka, da za mnoge te\u017eave bolj ustrezajo ne visoke tehnologije, ampak razmeroma nizkotehnolo\u0161ke re\u0161itve. Tedne sem se preprosto pogovarjal z ljudmi iz razli\u010dnih oddelkov. To, kar vidite na prvi sliki v objavi, je moj zadnji projekt; prostor je tako izgledal po treh dneh dela.<\/p>\n

Kaj je DevOps?<\/h2>\n

\nDejansko, \u010de vpra\u0161ate 10 razli\u010dnih ljudi, bodo dali 10 razli\u010dnih odgovorov. A kaj je zanimivo: vsi ti odgovori bodo pravilni. Napa\u010dnega odgovora tukaj ni. Dolgo sem se ukvarjal z DevOps, pribli\u017eno 10 let, in bil prvi Ameri\u010dan na prvem DevOpsDay. Ne bom rekel, da sem pametnej\u0161i od vseh, ki se ukvarjajo z DevOps, vendar verjetno ni nikogar, ki bi porabil toliko truda. Menim, da DevOps nastane, ko se zdru\u017eita \u010dlove\u0161ki kapital in tehnologija. Pogosto pozabimo na \u010dlove\u0161ki vidik, \u010deprav veliko govorimo o raznih kulturah. <\/p>\n

\"Sedem
\n
\nZdaj imamo na voljo veliko podatkov, pet let akademskih raziskav, preverjanje teorij pa je vzpostavljeno v industrijskem merilu. Te raziskave nam pravijo naslednje: \u010de v organizacijski kulturi zdru\u017eimo nekatere vedenjske vzorce, lahko dose\u017eemo pospe\u0161ek do 2000-krat. Ta pospe\u0161ek ustreza enakemu izbolj\u0161anju v odpornosti. To je kvantitativno merjenje tiste prednosti, ki jo lahko DevOps prinese kateremu koli podjetju. Pred nekaj leti sem govoril o DevOps generalnemu direktorju podjetja iz seznama Fortune 5000. Ko sem se pripravljal na predstavitev, sem bil zelo nervozen, ker sem moral v 5 minutah strniti svoje dolgoletne izku\u0161nje. <\/p>\n

Na koncu sem dal naslednjo definicijo DevOps<\/b>: to je niz praks in vzorcev, ki omogo\u010dajo pretvorbo \u010dlove\u0161kega kapitala v visoko u\u010dinkoviti organizacijski kapital. Primer: to, kako Toyota deluje zadnjih 50 ali 60 let.<\/p>\n

\"Sedem
\n
\n(Tukaj in nadalje so tak\u0161ne sheme predstavljene ne kot referen\u010dni material, temve\u010d kot ilustracija. Njihova vsebina se bo razlikovala za vsako novo podjetje. Kljub temu pa si je sliko mogo\u010de posebej ogledati in pove\u010dati na tej povezavi.)<\/a><\/noindex><\/i><\/p>\n

Ena izmed najbolj uspe\u0161nih takih praks je \u2014 mapiranje vrednostnega toka<\/b>. O tem je napisanih nekaj dobrih knjig, najbolj uspe\u0161na avtorica med njimi je Karen Martin. Vendar sem v preteklem letu pri\u0161el do zaklju\u010dka, da je tudi ta pristop preve\u010d visoko tehnolo\u0161ki. Ne glede na to, da ima \u0161tevilne prednosti, sem ga veliko uporabljal. Toda ko generalni direktor vpra\u0161a, zakaj njegovo podjetje ne more preiti na nove tirnice, o mapiranju vrednostnega toka \u0161e ni \u010das za pogovor. Obstaja veliko precej bolj temeljnih vpra\u0161anj, na katera je treba najprej najti odgovore. <\/p>\n

Zdi se mi, da je napaka mnogih mojih kolegov ta, da preprosto podajo podjetju vodnik s petimi to\u010dkami in se nato vrnejo \u010dez \u0161est mesecev in pogledajo, kaj se je zgodilo. Tudi dobra shema, kot je mapiranje vrednostnega toka, ima, recimo temu, mrtve cone (blind spots). Po stotinah intervjujev z razli\u010dnimi podjetni\u0161kimi direktorji sem razvil dolo\u010den vzorec, ki omogo\u010da razdelitev problema na sestavne dele, in zdaj bomo posebej obravnavali vsako od teh komponent. Preden uporabim kakr\u0161na koli tehnolo\u0161ka re\u0161itev, uporabljam ta vzorec, in rezultat so stene, polne shem. Nedavno sem delal z enim vzajemnim skladom, in na koncu sem imel 100-150 tak\u0161nih shem.<\/p>\n

Slaba kultura poje dobre pristope za zajtrk<\/h2>\n

\nGlavna misel je tak\u0161na: nobeni Lean, Agile, SAFE in DevOps ne bodo pomagali, \u010de je sama kultura organizacije slaba. To je tako, kot bi potapljal v globino brez jeklenke ali operiral brez rentgenskega posnetka. Z drugimi besedami, parafrazirajo\u010d Druckerja in Deminga: slaba poslovna kultura bo po\u017erla vsak dober sistem in se ne zadu\u0161ila. <\/p>\n

Da bi re\u0161ili ta glavni problem, je treba sprejeti naslednje korake:<\/p>\n

    \n
  1. Oscirajte vso delo:<\/b> je treba vso delo vidno. Ne v smislu, da mora biti nujno prikazano na kak\u0161nem ekranu, temve\u010d v smislu, da mora biti opazno.<\/li>\n
  2. Konsolidirajte sisteme upravljanja dela:<\/b> potrebno je konsolidirati menad\u017eerske sisteme. U problemu 'plemenskog' znanja i institucionalnog znanja u 9 od 10 slu\u010dajeva usko mesto su ljudi. U knjizi \u00abPhoenix Project\u00bb<\/a><\/noindex> problem je bio u jednom jedinom \u010doveku, Brentu, zbog koga je projekat bio u zaostatku od tri godine. I na takve 'Brente' nai\u0111em svuda. Za razre\u0161enje ovih uskih mesta koristim slede\u0107e dve ta\u010dke u na\u0161em spisku. <\/li>\n
  3. Theory of Constraints Methodology:<\/b> teorija ograni\u010denja.<\/li>\n
  4. Collaboration hacks:<\/b> hackovi saradnje. <\/li>\n
  5. Toyota Kata (Coaching Kata<\/a><\/noindex>):<\/b> o Toyota Kata ne\u0107u mnogo govoriti. Ako vas zanima, na mom GitHubu imaju prezentacije<\/a><\/noindex> gotovo o svakoj od ovih tema. <\/li>\n
  6. Market Oriented Organization:<\/b> organizacija orijentisana na tr\u017ei\u0161te.<\/li>\n
  7. Shift-left auditors:<\/b> audit u ranim fazama ciklusa.<\/li>\n<\/ol>\n

    \"Sedem
    \n
    \nPo\u010detak rada s organizacijom je veoma jednostavan: idem u kompaniju i razgovaram s zaposlenima. Kao \u0161to vidimo, nema visokih tehnologija. Sve \u0161to je potrebno je da imam na \u010demu da pi\u0161em. Okupljam nekoliko timova u jednoj sobi i analiziram ono \u0161to mi govore, iz perspektive mojih 7 arhetipova. Zatim im dajem marker i molim ih da izlo\u017ee na tabli sve \u0161to su do sada govorili naglas. Obi\u010dno naovakvim sastancima postoji jedna osoba koja sve bele\u017ei, i u najboljem slu\u010daju ona uspe da zabele\u017ei 10% diskusije. Mojom metodom ovaj procenat uspevam da podignem na otprilike 40%. <\/p>\n

    \"Sedem
    \n
    \n(Ovu ilustraciju mo\u017eete     videti na linku<\/a><\/noindex>)<\/i><\/p>\n

    Moj pristup se zasniva na radu Williama Schneidera (William Schneider, The Reengineering Alternative<\/a><\/noindex>). U osnovi pristupa je misao da svaku organizaciju mo\u017eemo razlo\u017eiti na \u010detiri kvadrata. Ova \u0161ema mi obi\u010dno predstavlja rezultat rada s onih stotinama drugih \u0161ema koje se javljaju prilikom analize organizacije. Pretpostavimo da imamo organizaciju s visokim nivoom kontrole, ali sa niskom kompetencijom. Ovo je izuzetno ne\u017eeljena situacija: kada svi hodaju po \u010deli\u010dnim \u017eicama, ali niko ne zna \u0161ta treba da radi. <\/p>\n

    Malce bolj\u0161a izbira s visokim nivojem nadzora in kompetenc. \u010ce ima podjetje dobi\u010dek, morda DevOps sploh ni potreben. Najbolj zanimivo je delati s podjetjem, ki ima visok nivo nadzora, nizko kompetenco in sodelovanje, ob tem pa visoko kulturo (cultivation). To pomeni, da je v podjetju veliko ljudi, ki radi delajo tam, fluktuacija delovne sile je nizka. <\/p>\n

    \"Sedem
    \n
    \n(Ovu ilustraciju mo\u017eete     videti na linku<\/a><\/noindex>)<\/i><\/p>\n

    Zdi se mi, da metode z strogimi priporo\u010dili na koncu ote\u017eijo dosego resnice. Zlasti pri vrednostnem toku je veliko pravil o tem, kako naj bo struktura informacij. V zgodnjih fazah dela, o katerih govorim, ta pravila nikomur niso potrebna. \u010ce oseba z markerjem v roki opisuje na tabli dejansko stanje v podjetju \u2013 to je najbolj\u0161i na\u010din, da razumemo polo\u017eaj. Te informacije ne pridejo do direktorjev. V tem trenutku je nesmiselno prekinjati osebo in re\u010di, da je narobe narisala pu\u0161\u010dico. V tej fazi je bolje uporabiti preprosta pravila, na primer: ve\u010dstopenjsko abstrakcijo lahko ustvarimo, preprosto z uporabo barvnih markerjev. <\/p>\n

    Ponovno ponavljam, nobenih visokih tehnologij. Z \u010drnim markerjem je prikazana objektivna realnost, kako vse deluje. Z rde\u010dim markerjem ljudje ozna\u010dujejo, kaj jim v obstoje\u010dem stanju ni v\u0161e\u010d. Pomembno je, da to pi\u0161ejo oni, ne jaz. Ko po sestanku grem k direktorju za informacijske tehnologije, ne ponujam seznama 10 stvari, ki jih je treba popraviti. Prizadevam si najti povezave med tem, kar govorijo ljudje iz podjetja, in obstoje\u010dimi potrjenimi vzorci. Kon\u010dno, z modrim markerjem predlagamo mo\u017ene re\u0161itve problema. <\/p>\n

    \"Sedem
    \n
    \n(Ovu ilustraciju mo\u017eete     videti na linku<\/a><\/noindex>)<\/i><\/p>\n

    Primer takega pristopa je prikazan zgoraj. Na za\u010detku tega leta sem delal z eno banko. Delavci iz oddelka za varnost so bili prepri\u010dani, da se ne smejo udele\u017eevati pregledov zahtev in oblikovanja (design and requirement reviews). <\/p>\n

    \"Sedem
    \n
    \n(Ovu ilustraciju mo\u017eete     videti na linku<\/a><\/noindex>)<\/i><\/p>\n

    Potem smo se pogovorili z ljudmi iz drugih oddelkov in ugotovili, da so pred pribli\u017eno 8 leti razvijalci programske opreme izlo\u010dili delavce za varnost, ker so upo\u010dasnjevali delo. In to se je spremenilo v prepoved, ki se je dojemala kot samoumevna. \u010ceprav v resnici ni bilo nobene prepovedi. <\/p>\n

    Na\u0161e sre\u010danje je potekalo zelo zapleteno: pribli\u017eno tri ure je pet razli\u010dnih ekip neuspe\u0161no posku\u0161alo pojasniti, kaj se dogaja med kodo in zgradbo. To bi se lahko zdelo najpreprostej\u0161a stvar. Ve\u010dina DevOps svetovalcev vnaprej predvideva, da je to \u017ee vsem znano. <\/p>\n

    Potem se je \u010dlovek, odgovoren za upravljanje IT (IT governance), ki je \u0161tiri ure mol\u010dal, nenadoma o\u017eivil, ko smo pri\u0161li do njegove teme, in nas zaposlitil \u0161e zelo dolgo. Na koncu sem ga vpra\u0161al, kaj meni o sre\u010danju, in nikoli ne bom pozabil njegovega odgovora. Rekel je: 'V\u010dasih sem mislil, da imava v na\u0161em banki samo dva na\u010dina dobave programske opreme, zdaj pa vem, da jih je kar pet, in za tri sploh nisem slutil.' <\/p>\n

    \"Sedem
    \n
    \n(Ovu ilustraciju mo\u017eete     videti na linku<\/a><\/noindex>)<\/i><\/p>\n

    Zadnje sre\u010danje v tej banki je bilo s ekipo, ki se ukvarja s programsko opremo za investicije. Ugotovili smo, da je bolj\u0161e pisati sheme z markerjem na papirju kot na tabli, in celo bolj\u0161e kot na pametni tablo. <\/p>\n

    \"Sedem
    \n
    \nFotografije, ki jih vidite, so to, kako je videti konferen\u010dna soba hotela \u010detrti dan na\u0161ega sre\u010danja. Te sheme smo uporabili za iskanje vzorcev, torej arhetipov. <\/p>\n

    Torej, postavljam vpra\u0161anja zaposlenim, oni zabele\u017eijo odgovore zmarkerji treh barv (\u010drna, rde\u010da in modra). Njihove odgovore analiziram z vidika arhetipov. Zdaj pa se pogovorimo o vseh arhetipih po vrsti. <\/p>\n

    1. Make All Work Visible: Naredite delo vidno<\/h3>\n

    \nV ve\u010dini podjetij, s katerimi delam, je zelo visok dele\u017e neznanega dela. Na primer, to se zgodi, ko en sodelavec pride do drugega in ga preprosto prosi, da nekaj naredi. V velikih organizacijah je lahko do 60 % nepovzetega dela. In do 40 % dela ni nikakor dokumentirano. \u010ce bi to bil Boeing, se nikoli ve\u010d ne bi usedel v njihov letalnik. \u010ce je dokumentirana le polovica dela, ni jasno, ali je to delo opravljeno pravilno. Vse druge metode se izka\u017eejo za neuporabne \u2014 ni smisla posku\u0161ati avtomatizirati, ker znanih 50 % morda predstavlja najusklajenej\u0161i in najjasnej\u0161i del dela, katerega avtomatizacija ne bo prinesla velikih rezultatov, medtem ko je vse najhuj\u0161e v nevidni polovici. Brez dokumentacije je nemogo\u010de najti razne hro\u0161\u010de in skrito delo, ne moremo najti ozkih grl, tistih Making Work Visible<\/a><\/noindex>. Ona razkriva pet razli\u010dnih \"uhanj \u010dasa\"<\/b> (thieves of time):<\/p>\n