Otázka „ako implementovať DevOps vo svojej firme“ sa neobjavila len nedávno, no kvalitných materiálov nie je veľa. Niekedy sa stávate obeťou reklamy nie veľmi inteligentných konzultantov, ktorí predávajú svoj čas bez ohľadu na to, ako. Niekedy sú to nevhodné, veľmi všeobecné slová o tom, ako veľké korporácie plávajú vesmírom. Vzniká otázka: a čo z toho máme my? Vážený autor, mohli by ste jasne zhrnúť svoje myšlienky v zozname?
Toto všetko vychádza z toho, že reálna prax a pochopenie výsledkov transformácie kultúry spoločnosti nie sú známe. Zmeny v kultúre sú procesy na dlhé trate, ktorých výsledky sa neprejavia za týždeň ani mesiac. Potrebujeme niekoho dosť starého, kto zažil, ako sa spoločnosti formovali a rozpadali v priebehu rokov.
John Willis je jedným zo zakladateľov DevOps. John má za sebou desiatky rokov práce s množstvom spoločností. V poslednom čase si John začal všímať špecifické vzory, ktoré sa objavujú v práci s každou z nich. Pomocou týchto archetypov vedie spoločnosti správnym smerom v DevOps transformácii. Viac o týchto archetypoch sa dozviete v preklade jeho prednášky z konferencie DevOops 2018.
O prednášajúcom:
Má viac ako 35 rokov skúseností v IT riadení, bol zapojený do vytvorenia predchodcu OpenCloud v Canonical, zúčastnil sa 10 startupov, z ktorých dva predal spoločnostiam Dell a Docker. Teraz je Vice President of DevOps and Digital Practices v SJ Technologies.
Nasleduje rozprávanie z pohľadu Johna.
Volám sa John Willis a najjednoduchšie ma nájdete na Twitteri, . Tento pseudonym mám aj na Gmaili a GitHube. A môžete nájsť videozáznamy mojich prednášok a prezentácie k nim.
Mám mnoho schôdzí s CIO rôznych veľkých spoločností. Veľmi často sa sťažujú, že nerozumejú, čo to vlastne DevOps je, a všetci, ktorí sa im to snažia vysvetliť, hovoria o niečom svojom. Ďalšia častá sťažnosť je, že DevOps nefunguje, aj keď sa zdá, že riaditelia robia všetko tak, ako im bolo vysvetlené. Hovoríme o veľkých spoločnostiach, ktoré majú viac ako sto rokov. Po rozhovoroch s nimi som dospel k záveru, že pre mnohé problémy sú najlepšie nie vysoké technológie, ale relatívne nízkotechnologické riešenia. Týždne som sa iba rozprával s ľuďmi z rôznych oddelení. To, čo vidíte na prvej fotke v príspevku — to je môj posledný projekt, miestnosť vyzerala takto po troch dňoch práce.
Čo je to DevOps?
Skutočne, ak sa opýtate 10 rôznych ľudí, dostanete 10 rôznych odpovedí. Ale zaujímavé je, že všetky tieto odpovede budú správne. Nesprávna odpoveď tu nie je. Venoval som sa DevOps celkom hlboko, asi 10 rokov, bol som prvým Američanom na prvom DevOpsDay. Nepoviem, že som múdrejší ako všetci, ktorí sa zaujímajú o DevOps, ale sotva by sa našiel niekto, kto by na to strávil toľko síl. Považujem DevOps za spojenie ľudského kapitálu a technológie. Často zabúdame na ľudský rozmer, aj keď hovoríme veľa o rôznych kultúrach.
Teraz máme k dispozícii množstvo údajov, päť rokov akademického výskumu, overenie teórií nastavené na priemyselnej úrovni. Tieto výskumy nám hovoria nasledovné: ak v organizačnej kultúre spojíme niektoré behaviorálne vzorce, môžeme dosiahnuť zrýchlenie o 2000-násobok. Tomu zrýchleniu zodpovedá rovnaké zlepšenie v odolnosti. Toto je kvantitatívne meranie výhody, ktorú môže DevOps poskytnúť akejkoľvek spoločnosti. Pred pár rokmi som o DevOps hovoril generálnemu riaditeľovi spoločnosti zo zoznamu Fortune 5000. Keď som sa pripravoval na prezentáciu, bol som veľmi nervózny, pretože som musel za 5 minút zhrnúť svoje mnohoročné skúsenosti.
Nakoniec som predstavil nasledovné definícia DevOps: je to súbor praktík a vzorcov, ktoré umožňujú transformovať ľudský kapitál na vysoko výkonný organizačný kapitál. Príklad — spôsob, akým Toyota funguje posledných 50 alebo 60 rokov.
(Tieto schémy sa uvádzajú nie len ako referenčný materiál, ale ako ilustrácia. Ich obsah sa bude líšiť pre každú novú spoločnosť. Napriek tomu si obrázok môžete samostatne pozrieť a zväčšiť
Jedna z najúspešnejších takýchto praktík je – mapovanie hodnotového toku. O tom bolo napísaných niekoľko dobrých kníh, autorom najúspešnejšej z nich je Karen Martin. Ale za posledný rok som dospel k názoru, že aj tento prístup je príliš technologicky náročný. Určite má množstvo výhod, sám som ich veľa využíval. Ale keď generálny riaditeľ sa ťa pýta, prečo jeho spoločnosť nemôže prejsť na nové koľaje, o mapovaní hodnotového toku je ešte priskoro hovoriť. Existuje množstvo zásadnejších otázok, na ktoré je potrebné predtým nájsť odpovede.
Myslím, že chybou mnohých mojich kolegov je, že jednoducho poskytnú spoločnosti päťbodový plán a potom sa po pol roku vrátia a pozrú, čo sa stalo. Aj s dobrým schémou, ako je mapovanie hodnotového toku, existujú povedzme mŕtve zóny (blind spots). Po stovkách rozhovorov s riaditeľmi rôznych spoločností som vytvoril určitý vzor, ktorý umožňuje rozložiť problém na zložky, a teraz si po poradí prejdeme každú z týchto zložiek. Predtým než aplikujem akékoľvek technologické riešenia, používam tento vzor, a výsledkom je, že všetky steny sú pokryté schémami. Nedávno som pracoval s jedným podielovým fondom a nakoniec som mal 100-150 takýchto schém.
Zlá kultúra zje dobré prístupy na raňajky
Hlavná myšlienka je taká: žiadne Lean, Agile, SAFE a DevOps nepomôžu, ak je zlá kultúra organizácie. Je to ako potápať sa do hĺbky bez dýchacej trubice alebo operovať bez röntgenového snímku. Inými slovami, parafrázujúc Druckera a Deminga: zlá organizačná kultúra pohltí každý dobrý systém a ani sa nezadusí.
Aby sme riešili tento hlavný problém, je potrebné podniknúť nasledujúce kroky:
- Zviditeľniť všetku prácu: musí sa urobiť všetka práca viditeľnou. Nie v tom zmysle, že by sa musela nutne zobraziť na nejakej obrazovke, ale v tom zmysle, že ju treba byť možné pozorovať.
- Konsolidovať systémy správy práce: je potrebné konsolidovať systémy manažmentu. V probléme „kmeňového“ poznania a poznania inštitucionálneho je v 9 z 10 prípadov úzkym miestom človek. V knihe problém bol v jednom jediným človeku, Brente, kvôli ktorému projekt meškal tri roky. A na takých „Brentoch“ narážam všade. Na odstránenie týchto úzkych miest používam nasledujúce dva body v našom zozname.
- Metodológia teórie obmedzení: teória obmedzení.
- Hacky spolupráce: hacky spolupráce.
- Toyota Kata (): o Toyota Kata nebudem príliš hovoriť. Ak vás to zaujíma, na mojom GitHube takmer na každú z týchto tém.
- Organizácia orientovaná na trh: orientovaná na trh organizácia.
- Audítori shift-left: audít na začiatku cyklu.
Začínam prácu s organizáciou veľmi jednoducho: idem do spoločnosti a rozprávam sa so zamestnancami. Ako vidíme, žiadne vysoké technológie. Všetko, čo potrebujem, je mať na čom písať. Zhromažďujem niekoľko tímov v jednej miestnosti a analyzujem to, čo mi povedia, z pohľadu mojich 7 archetypov. A potom im dám marker a požiadam ich, aby napísali na tabuľu všetko, čo doteraz hovorili nahlas. Zvyčajne na takýchto stretnutiach je jeden človek, ktorý všetko zapisuje, a v tom najlepšom prípade sa mu podarí zaznamenať 10% diskusie. Pri mojej metóde sa tento údaj podarí zvýšiť na asi 40%.
(Samostatne túto ilustráciu môžeme )
Môj prístup je založený na práci Williama Schneidera (William Schneider, ). V základe prístupu leží myšlienka, že akúkoľvek organizáciu možno rozdeliť na štyri štvorce. Táto schéma zvyčajne vychádza z práce s tými stovkami iných schém, ktoré vznikajú pri analýze organizácie. Predpokladajme, že máme organizáciu s vysokou úrovňou kontroly, ale s nízkou kompetenciou. To je veľmi nežiaduci variant: keď všetci chodia po šnúrkach, ale nikto nevie, čo má robiť.
Trochu lepšia možnosť s vysokou úrovňou kontroly a kompetencie. Ak má takáto spoločnosť zisk, možno, že DevOps ani nepotrebuje. Najzaujímavejšie je pracovať so spoločnosťou, ktorá má vysokú úroveň kontroly, nízku kompetenciu a spoluprácu, ale zároveň vysokú úroveň kultúry (cultivation). To znamená, že v spoločnosti je veľa ľudí, ktorí tam radi pracujú, a fluktuácia pracovníkov je nízka.
(Samostatne túto ilustráciu môžeme )
Myslím, že metódy so striktne predpísanými odporúčaniami v konečnom dôsledku bránia dosiahnuť pravdu. Konkrétne v value stream mapping je veľa pravidiel, ako treba štruktúrovať informácie. V počiatočných fázach práce, o ktorých hovorím, tieto pravidlá nikomu nie sú potrebné. Ak človek s fixkou v ruke popisuje na tabuli reálnu situáciu v spoločnosti — to je najlepší spôsob, ako pochopiť, ako to funguje. Takéto informácie sa nedostanú k riaditeľom. V tejto chvíli je hlúpe prerušiť človeka a povedať, že zle nakreslil nejakú šípku. V tomto štádiu je lepšie dodržiavať jednoduché pravidlá, napríklad: viacúrovňovú abstrakciu je možné vytvoriť jednoducho použitím farebných fixiek.
Opakujem, žiadne vysoké technológie. Čiernou fixkou sa zobrazuje objektívna realita, ako všetko funguje. Červenou fixkou ľudia označujú, čo im na existujúcom stave nevyhovuje. Dôležité je, že to píšu oni, nie ja. Keď po stretnutí idem za riaditeľom IT, nenavrhnem zoznam 10 vecí, ktoré treba opraviť. Snažím sa nájsť súvislosti medzi tým, čo hovoria ľudia zo spoločnosti, a existujúcimi overenými vzormi. Nakoniec, modrou fixkou sú navrhované možné riešenia problému.
(Samostatne túto ilustráciu môžeme )
Príklad takéhoto prístupu je zobrazený vyššie. Na začiatku tohto roka som pracoval s jednou bankou. Zamestnanci z oddelenia bezpečnosti boli presvedčení, že nemôžu prichádzať na kontroly požiadaviek a návrhu (design and requirement reviews).
(Samostatne túto ilustráciu môžeme )
Potom sme sa porozprávali s ľuďmi z iných oddelení a zistili sme, že asi pred 8 rokmi vývojári softvéru vylúčili zamestnancov bezpečnosti, pretože tí spomaľovali prácu. A potom sa to premenilo na zákaz, ktorý bol vnímaný ako fakt. Hoci v skutočnosti žiadny zákaz neexistoval.
Naša schôdzka prebiehala veľmi zložito: počas niečoho okolo troch hodín sa päť rôznych tímov nedokázalo dohodnúť, čo sa deje medzi kódom a zostavením. A to by sa zdalo, že je to najjednoduchšia vec. Väčšina konzultantov DevOps predpokladá, že je to už všetkým jasné.
Potom sa osoba zodpovedná za reguláciu IT (IT governance), ktorá predtým štyri hodiny mlčala, zrazu ožila, keď sme prešli na jeho tému, a zamestnala nás ešte na celkom dlhý čas. Na konci som sa ho spýtal, čo si myslí o stretnutí, a nikdy nezabudnem na jeho odpoveď. Povedal: „Predtým som si myslel, že v našej banke sú len dva spôsoby dodania softvéru, a teraz viem, že ich je dokonca päť, a o troch som ani netušil.“
(Samostatne túto ilustráciu môžeme )
Posledné stretnutie v tejto banke bolo s tímom, ktorý sa zaoberá softvérom pre investície. Práve s ním sa ukázalo, že je lepšie písať schémy fixkami na papieri ako na tabuli, a dokonca lepšie ako na smartboarde.
Fotografie, ktoré vidíte, sú z konferenčnej miestnosti hotela počas štvrtého dňa našej schôdzky. Tieto schémy sme používali na identifikáciu vzorcov, teda archetypov.
Takže kladiem otázky zamestnancom, zapisujú si odpovede fixkami troch farieb (čiernou, červenou a modrou). Ich odpovede analyzujem z hľadiska archetypov. Teraz si poďme prejsť všetky archetypy po poriadku.
1. Make All Work Visible: Sprístupniť všetku prácu
Vo väčšine spoločností, s ktorými pracujem, je veľmi vysoké percento neznámej práce. Napríklad, keď jeden zamestnanec príde k druhému a jednoducho ho požiada, aby niečo urobil. Vo veľkých organizáciách môže byť 60 % neplánovanej práce. A až 40 % práce nie je nijako zdokumentované. Keby to bol Boeing, tak by som sa nikdy viac nenastúpil do ich lietadla. Ak je zdokumentovaná len polovica práce, potom nie je jasné, či sa tá práca vykonáva správne alebo nie. Všetky ostatné metódy sa ukazujú ako zbytočné — nemá zmysel pokúšať sa o automatizáciu, pretože známych 50 % môže byť práve tou najkoordinovanejšou a najpresnejšou časťou práce, ktorej automatizácia neprinesie veľké výsledky, a všetko najhoršie je v neviditeľnej polovici. Pri absencii dokumentácie nie je možné nájsť rôzne hacky a skrytú prácu, nezhľadá sa úzke miesto, tzv. „Brentovia“, o ktorých som už hovoril. Existuje skvelá kniha od Dominiky De Grandis. . Odhaľuje päť rôznych „únikov času“ (thieves of time):
- Príliš veľa práce v procese (WIP)
- Neznáme závislosti
- Neplánovaná práca
- Konfliktné priority
- Zanedbaná práca
Je to veľmi cenná analýza a kniha je vynikajúca, ale všetky tieto rady sú zbytočné, ak sú viditeľné len 50 % údajov. Metódy navrhnuté Dominikou sa dajú aplikovať len v prípade, ak je dosiahnutá presnosť nad 90 %. Hovorím o situáciách, keď šéf dá podriadenému 15-minútovú úlohu a tá mu zaberie tri dni; šéf ale v skutočnosti nevie, že tento podriadený závisí ešte od štyroch alebo piatich iných ľudí.
Phoenix Project je úžasný príbeh o projekte, ktorý oneskorený o tri roky. Jednému z hrdinov hrozí prepustenie a stretáva sa s inou postavou, ktorá je predstavovaná ako akýsi Sókratés. Pomáha mu pochopiť, čo sa vlastne pokazilo. Zisťuje sa, že v spoločnosti existuje jeden administrátor, ktorého volajú Brent a všetka práca prechádza cez neho. Na jednom zo stretnutí sa jeden z podriadených pýta: prečo každá polhodinová úloha trvá týždeň? Odpoveďou je veľmi zjednodušené vysvetlenie teórie front a Littlovho zákona, pričom sa zistí, že pri 90% využití každá hodina práce trvá 9 hodín. Každá úloha musí byť poslaná siedmim ďalším ľuďom, a tak sa táto hodina pretvorí na 63 hodín, 7 krát 9. Hovorím to preto, že na to, aby sme použili Littlov zákon alebo akúkoľvek zložitú teóriu front, musíme mať aspoň dáta.
Preto, keď hovorím o viditeľnosti, nemyslím tým, že všetko musí byť na obrazovke, ale že je potrebné mať aspoň dáta. Keď sú, často sa zistí, že existuje veľmi veľký objem neplánovanej práce, ktorá nejako prichádza k Brentovi, aj keď to nie je potrebné. A Brent je skvelý chlap, nikdy nepovie „nie“, ale zároveň nikomu nepovie, ako robí svoju prácu.
Keď je práca viditeľná, dá sa starostlivo klasifikovať dáta (presne to, čím sa Dominika zaoberá na fotke), môžeme aplikovať abstrakciu piatich únikov času a automatizovať.
2. Konsolidácia systémov správy práce: Správa úloh
Archetypy, o ktorých hovorím, predstavujú akúsi pyramídu. Ak je prvý úspešne splnený, druhý sa stáva akousi nadstavbou. Mnohé z nich nefungujú pre startupy, mali by sa mať na pamäti v prípade veľkých spoločností, ako sú tie, ktoré sa dostanú na zoznam Fortune 5000. V poslednej spoločnosti, kde som pracoval, bolo 10 systémov na sledovanie chýb (ticketing system). V jednom tíme bol Remedy, iný si napísal nejaký vlastný systém, tretí používal Jira, niekto sa úplne obchádzal e-mailom. Rovnaký problém vzniká, ak má spoločnosť 30 rôznych pipeline, ale nemám čas diskutovať o všetkých takýchto prípadoch.
Hovorím s ľuďmi o tom, ako presne sa vytvárajú tikety, čo sa s nimi ďalej deje a ako ich obchádzajú. Najzaujímavejšie je, že ľudia na našich stretnutiach hovoria pomerne úprimne. Spýtal som sa, koľko ľudí označuje tikety ako „minor / no impact“, keď im v skutočnosti mali priradiť „major impact“. Zistilo sa, že to robí takmer každý. Nezabývam sa udalostmi a snažím sa neodhalovať jednotlivcov. Keď mi niekto úprimne niečo prizná, neprezradím ho. Ale keď takmer všetci obchádzajú systém, znamená to, že celá bezpečnosť je v podstate dekorácia. Preto z údajov tohto systému nemožno robiť žiadne závery.
Aby sa vyriešil problém s tiketmi, je potrebné vybrať jeden hlavný systém. Ak používate Jira, nech to zostane len Jira. Ak existuje nejaká alternatíva, nech je len tá. Podstatou je, že tikety treba považovať za ďalšiu fázu vývojového procesu. Každá činnosť by mala mať tiket, ktorý musí prechádzať pracovným procesom vývoja. Tikety sú zasielané tímu, ktorý ich umiestňuje na storyboard a následne za ne zodpovedá.
Týka sa to všetkých oddelení, vrátane infraštruktúrneho a operačného. V takom prípade je možné zostaviť akokoľvek presné zobrazenie stavu vecí. Keď je tento proces zabehnutý, zrazu zistíme, že ľahko vieme určiť, kto nesie zodpovednosť za každú aplikáciu. Pretože teraz získavame nie 50%, ale 98% nových služieb. Ak tento základný proces funguje, tak presnosť sa zvyšuje v celom systéme.
Pipeline služieb
Toto sa opäť týka iba veľkých korporácií. Ak ste nová spoločnosť v novej oblasti — zrollujte si rukávy a pracujte so svojím Travis CI alebo CircleCI. Čo sa týka spoločností Fortune 5000, zaujímavý je prípad, ktorý sa stal v banke, kde som pracoval. Prišli k nim z Googlu a ukázali im grafy so starými systémami IBM. Chlapci z Googlu sa pýtali — kde je zdrojový kód? A žiaden zdrojový kód neexistuje, nie je tam ani GUI. To je realita, s ktorou sa musia vyrovnávať veľké organizácie: 40-ročné bankové záznamy na archaickom mainframe. Jeden z mojich klientov používa kontajnery Kubernetes s obvodmi Circuit Breaker, plus Chaos Monkey, to všetko pre aplikáciu KeyBank. Ale tieto kontajnery sa nakoniec pripájajú k aplikácii napísanej v COBOL.
Chlapci z Googlu boli presvedčení, že vyriešia všetky problémy môjho klienta, a potom začali klásť otázky: čo je to IBM datapipe? Odpovedajú im: to je konektor. K čomu sa pripája? K systému Sperry. A čo to je? A tak ďalej. Na prvý pohľad sa zdá, že tu nemôže byť DevOps? Ale v skutočnosti je to možné. Existujú dodávateľské systémy, ktoré umožňujú prenášať pracovný tok tímom zameraným na dodanie.
3. Teória obmedzení: Teória obmedzení
Prejdime k tretiemu archetypu: inštitucionálne / „kmenové“ poznanie. Vo väčšine organizácií existuje niekoľko ľudí, ktorí vedia všetko a vedú ostatných. Sú to tí, ktorí sú v organizácii najdlhšie a poznajú všetky obchádzkové cesty.
Keď sa to objaví na grafe, ja špeciálne obkresľujem týchto ľudí zvýrazňovačom: napríklad sa ukazuje, že nejaký Lou je na všetkých stretnutiach. A pre mňa je jasné: toto je miestny Brent. Keď riaditeľ informačných technológií zvažuje medzi mnou v tričku a teniskách a oblečeným v obleku chlapíkom z IBM, vyberajú si mňa, pretože im môžem povedať veci, ktoré ten druhý chalan im nepovie a o ktorých môže byť pre nich nepríjemné počuť. Hovorím im, že v ich spoločnosti je úzke miesto, je to niekto menom Fred a niekto menom Lou. Toto úzke miesto je potrebné uvoľniť, ich vedomosti je potrebné nejako od nich získať.
Aby ste vyriešili tento typ problému, môžem napríklad navrhnúť používanie Slacku. Inteligentný riaditeľ sa opýta — prečo? Zvyčajne v takýchto prípadoch konzultanti pre DevOps odpovedajú: lebo to robia všetci. Ak je riaditeľ naozaj inteligentný, povie: a čo z toho. A tým sa dialóg skončí. Ja na to odpovedám: lebo v spoločnosti sú štyri úzke miesta, Fred, Lou, Suzy a Jane. Aby sa ich vedomosti stali inštitucionalizovanými, je potrebné predovšetkým zaviesť Slack. Všetky vaše wikipédie sú úplná hlúposť, pretože nikto nevie o ich existencii. Ak sa tím inžinierov zaoberá vonkajším a vnútorným vývojom, všetci by mali vedieť, že sa môžu obrátiť na tím vonkajšieho vývoja alebo tím infraštruktúry s otázkami. A práve vtedy pravdepodobne Lou alebo Fred nájdu čas na to, aby sa pripojili k wikipédii. A potom sa v Slacku niekto môže opýtať, prečo nefunguje, povedzme, krok 5. A potom Lou alebo Fred opraví pokyny na wikipédii. Ak sa tento proces nastaví, ďalej sa veľmi veľa samo od seba dostane na svoje miesto.
V tom je moja hlavná myšlienka: aby ste odporučili akékoľvek pokročilé technológie, musíte najskôr usporiadať základy pre ne, a to sa dá dosiahnuť práve tými práve opísanými nízkotechnologickými riešeniami. Ak začnete s pokročilými technológiami a nevysvetlíte, na čo sú potrebné, zvyčajne to neskončí ničím dobrým. Jeden z našich klientov používa Azure ML, veľmi lacné a jednoduché riešenie. Približne 30% otázok už zodpovedala sama samoučiaca sa mašina. A túto vec napísali operátori, ktorí sa nezaoberali data science, štatistikou ani matematikou. To je ukážkové. Náklady na toto riešenie sú minimálne.
4. Hacking spolupráce: Hacky spolupráce
Štvrtý archetyp spočíva v boji proti izolácii. Väčšina ľudí to už vie: izolácia vyvoláva nepriateľstvo. Ak je každý oddelenie na svojom poschodí a ľudia sa navzájom nestretávajú, okrem ako v výťahu, nepriateľstvo medzi nimi sa veľmi ľahko rodí. Naopak, ak sú ľudia v jednej miestnosti, nepriateľstvo sa rýchlo vytratí. Keď niekto hodí nejaké spoločné obvinenie, napríklad, že takýto rozhranie nikdy nefunguje - nie je nič jednoduchšie ako toto obvinenie dekonštruovať. Programátorom, ktorí napísali rozhranie, stačí začať klásť konkrétne otázky a čoskoro sa ukáže, že napríklad používateľ jednoducho nesprávne používal nástroj.
Existuje mnoho spôsobov, ako prekonať izoláciu. Raz ma požiadali, aby som radil banke v Austrálii, ale odmietol som to, pretože mám dve deti a manželku. Všetko, čím som im mohol pomôcť - odporučil som im графические рассказы. To je vec, ktorá sa osvedčila. Ďalším zaujímavým spôsobom sú stretnutia vo formáte lean coffee. V veľkej organizácii je to skvelá voľba na šírenie vedomostí. Okrem toho, môžete organizovať vnútorné devops dni, hackatony a tak ďalej.
5. Coaching Kata
Ako som už varoval na začiatku, dnes o tom nebudem hovoriť. Ak vás to zaujíma, môžete sa pozrieť .
Existuje tiež dobrá prednáška na túto tému od Mike Rothera:
6. Market Oriented: organizácia orientovaná na trh
Existujú tu rôzne problémy. Napríklad, ľudia "I", ľudia "T" a ľudia "E". Ľudia "I" sú tí, ktorí sa zaoberajú iba jednou vecou. Zvyčajne existujú práve v organizáciách s izolovanými oddeleniami. "T" - to je ak človek dobre pozná niečo jedno, ale zároveň sa mu darí aj v niektorých iných veciach. "E" alebo dokonca " hrebeň" - to je, keď má človek mnoho zručností.
Tu funguje Conwayov zákon (), ktorý v maximálne zjednodušenej forme môžeme vyjadriť takto: ak tri tímy pracujú na kompilátore, nakoniec vznikne kompilátor z troch častí. Preto ak je vo vnútri organizácie vysoká úroveň izolácie, tak aj Kubernetes, Circuit breaker, API extensibility a ďalšie módne veci v tejto organizácii budú usporiadané tak, ako je samotná organizácia. Presne podľa Conwaye a na zlosť všetkým vám, mladým geekom.
Riešenie tohto problému bolo mnohokrát opísané. Existujú napríklad organizačné archetypy, ktoré popísal Fernando Fernandez. Problémová architektúra, o ktorej som práve hovoril, s izoláciou — to je funkčne orientovaná architektúra. Druhý typ — najhorší, maticová architektúra, tam je neporiadok z dvoch ďalších. Tretí — to, čo sa pozoruje vo väčšine startupov, a veľké spoločnosti sa tiež snažia tomuto typu prispôsobiť. Je to organizácia zameraná na trh. Tu ide o optimalizáciu na dosiahnutie najrýchlejšej odozvy na požiadavky zákazníkov. Niekedy sa to nazýva plochá organizácia.
Túto štruktúru mnohí opisujú rôzne, mne sa páči formulácia build/run teams, v Amazone to nazývajú two pizza teams. V tejto štruktúre sa všetci ľudia typu „I“ zhromažďujú okolo jedného služby a postupne sa stávajú bližšími typu „T“, a ak je nastavený správny manažment, môžu sa stať dokonca „E“. Prvý kontrargument je, že v takejto štruktúre sú zbytočné elementy. Aký zmysel má mať testera v každom oddelení, ak môže existovať špeciálny testovací oddel? Na čo odpovedám: zbytočné náklady v tomto prípade sú cenou za to, aby sa v budúcnosti celá organizácia stala typom „E“. V takejto štruktúre sa tester postupne dozvedá o sieťach, architektúre, dizajne atď. Nakoniec je každý účastník organizácie úplne informovaný o všetkom, čo sa v organizácii deje. Ak chcete vedieť, ako táto schéma funguje v priemysle, prečítajte si .
7. Shift-left auditors: audit v skorých fázach cyklu. Dodržiavanie pravidiel bezpečnosti napohľad
To je, keď vaše kroky, povedzme, neprejdú kontrolou. Ľudia, ktorí na vás pracujú, nie sú hlúpi. Ak, ako v uvedenom príklade, všade označovali minor/no impact, to trvalo tri roky a nikto si ničoho nevšimol, všetci dobre vedia, že systém nefunguje. Alebo iný príklad — rada pre zmeny, kam každú, povedzme, stredu treba predložiť správy. Tam pracuje skupina ľudí (mimochodom, neprimerane platených), ktorí by teoreticky mali vedieť, ako systém funguje v celku. A za posledných päť rokov ste si asi všimli, že naše systémy sú mimoriadne zložité. A piati-šesť ľudí by malo prijať rozhodnutie o zmene, ktorú sami nezrealizovali a o ktorej nič nevedia.
Samozrejme, takýto prístup nefunguje. Musím sa zbavovať takýchto vecí, pretože títo ľudia nechránia systém. Rozhodnutie by mala prijímať sama tím, pretože tím musí byť zodpovedný za to. Inak vzniká paradoxná situácia, keď manažér, ktorý nikdy v živote nenapísal kód, hovorí programátorovi, koľko času by malo trvať napísanie kódu. V jednej firme, kde som pracoval, bolo 7 rôznych rád, ktoré posudzovali každú zmenu, vrátane architektonickej rady, produktovej a podobne. Existoval dokonca povinný čakací čas, aj keď mi jeden zamestnanec povedal, že za desať rokov práce nikto nikdy počas tohto povinného obdobia nezamietol zmeny, ktoré tento človek navrhol.
Audítorov je potrebné prizvať k sebe, a nie sa ich zbavovať. Povedzte im, že píšete nemenné binárne kontajnery, ktoré, ak prejdú všetkými testami, zostanú nezmenené navždy. Povedzte im, že máte pipeline as code, a vysvetlite, čo to znamená. Ukážte im nasledujúci diagram: nemenný binárny iba na čítanie v kontajneri, ktorý prešiel všetkými testami na zraniteľnosti; a potom sa k nemu nikto nedotkne — nikto sa nedotkne ani systému, ktorý vytvára pipeline, keďže sa tiež vytvára dynamicky. Mám klientov, Capital One, ktorí pomocou Vault vytvárajú niečo ako blockchain. Audítorovi netreba ukazovať „recepty“ z Chef, stačí ukázať blockchain, z ktorého je jasné, čo sa stalo so žiadosťou Jira v produkcii a kto za ňu zodpovedá.
Podľa , vytvoreného v roku 2018 Sonatype, v roku 2017 bolo 87 miliárd žiadostí na stiahnutie OSS.
Straty spôsobené zraniteľnosťami sú neúmerne vysoké. A čísla, ktoré teraz vidíte vyššie, nezahŕňajú alternatívne náklady. V skratke o tom, čo je DevSecOps. Hneď chcem povedať, že sa ma nezaujímajú diskusie o tom, ako vhodne je toto meno. Zmysel spočíva v tom, že pokiaľ DevOps boli veľmi úspešné, je potrebné skúsiť pridať k tomuto pipeline bezpečnosť.
Príklad takejto sekvencie:
Nie je to odporúčanie určitých produktov, hoci ja ich všetky mám rád. Uviedol som ich ako príklad, aby som ukázal, že DevOps, založené pôvodne na paradigme organizácie v priemysle, umožňuje automatizovať každý krok práce na produkte.
A nie je žiadny dôvod, prečo by sme nemohli aplikovať rovnaký prístup k bezpečnosti.
Záver
Na záver vám poskytnem niekoľko rád pre DevSecOps. Je potrebné zahrnúť auditorov do procesu vytvárania vašich systémov a venovať čas ich vzdelávaniu. S auditormi je potrebné spolupracovať. ďalej je potrebné neúprosne bojovať proti falošným poplachom. Aj s najdrahším nástrojom na skenovanie zraniteľností sa môžu vytvoriť veľmi škodlivé návyky u vašich vývojárov, ak neviete, aký je pomer signálu k šumu. Vývojári budú preťažení udalosťami a len ich budú mazať. Ak ste počuli o príbehu s Equifaxom, práve toto sa tam stalo, tam bol ignorovaný signál najvyššej úrovne nebezpečenstva. Okrem toho je potrebné zraniteľnosti vysvetliť tak, aby bolo jasné, ako ovplyvňujú podnikanie. Napríklad je možné povedať, že to je tá istá zraniteľnosť, ktorá bola v príbehu s Equifaxom. Zraniteľnosti týkajúce sa bezpečnosti by sa mali považovať rovnako ako ostatné softvérové problémy, teda by sa mali zahrnúť do celkového procesu DevOps. Je potrebné s nimi pracovať cez Jira, Kanban a podobne. Vývojári by nemali mať pocit, že sa o to postará niekto iný — naopak, mali by sa na tom podieľať všetci. Nakoniec je potrebné vynaložiť úsilie na školenie ľudí.
Užitočné odkazy
Tu sú niektoré prezentácie z konferencie DevOops, ktoré by vám mohli byť užitočné:
- Sergej Berdnikov, Artem Kaličkin — Príbeh úspechu, alebo „Dev+DevOps+Ops“ (, )
- Baruch Sadogursky, Leonid Igolnik — DevOps v mierke: grécka tragédia v troch aktoch (, )
- Alexander Titov, Kirill Tolkachev —
- Timothy Lister —
Pozrite sa do DevOops 2020 Moscow — aj tam je množstvo zaujímavého obsahu.
Zdroj: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish