Otázka „ako implementovať devops“ je tu už roky, ale nie je veľa dobrých materiálov. Niekedy sa stanete obeťou inzerátov od nie práve šikovných poradcov, ktorí potrebujú predať svoj čas, nech je akokoľvek. Niekedy sú to vágne, mimoriadne všeobecné slová o tom, ako lode megakorporácií brázdia priestory vesmíru. Vynára sa otázka: čo nám na tom záleží? Vážený autor, viete jasne sformulovať svoje myšlienky v zozname?
Toto všetko pramení z toho, že sa nenahromadilo veľa reálnej praxe a pochopenia výsledkov transformácií firemnej kultúry. Zmeny v kultúre sú dlhodobé veci, ktorých výsledky sa nedostavia za týždeň ani za mesiac. Potrebujeme niekoho dosť starého na to, aby videl, ako sa spoločnosti v priebehu rokov budovali a zlyhali.
John Willis - jeden z otcov DevOps. John má desaťročia skúseností s prácou s obrovským množstvom spoločností. Nedávno si John začal všímať špecifické vzorce, ktoré sa odohrávajú pri práci s každým z nich. Pomocou týchto archetypov vedie John spoločnosti na skutočnej ceste transformácie DevOps. Prečítajte si viac o týchto archetypoch v preklade jeho správy z konferencie DevOops 2018.
O rečníkovi:
Viac ako 35 rokov v IT manažmente, podieľal sa na vytvorení predchodcu OpenCloud v Canonical, podieľal sa na 10 startupoch, z ktorých dva boli predané spoločnostiam Dell a Docker. V súčasnosti je viceprezidentom DevOps a digitálnych praktík v SJ Technologies.
Nasleduje príbeh z Johnovho pohľadu.
Volám sa John Willis a najľahšie ma nájdete na Twitteri, . Mám rovnaký alias na Gmail a GitHub. A nájdete k nim videozáznamy mojich reportáží a prezentácií.
Mám veľa stretnutí s CIO rôznych veľkých spoločností. Veľmi často sa sťažujú, že nerozumejú, čo je DevOps, a každý, kto sa im to snaží vysvetliť, hovorí o niečom inom. Ďalšou častou sťažnosťou je, že DevOps nefunguje, hoci sa zdá, že režiséri robia všetko tak, ako im bolo vysvetlené. Hovoríme o veľkých firmách, ktoré majú viac ako sto rokov. Po rozhovore s nimi som dospel k záveru, že pre mnohé problémy nie je najvhodnejšia špičková technológia, ale skôr relatívne low-tech riešenia. Celé týždne som sa len rozprával s ľuďmi z rôznych oddelení. To čo vidíte na úplne prvom obrázku v príspevku je môj posledný projekt, takto vyzerala izba po troch dňoch práce.
Čo je DevOps?
Skutočne, ak sa spýtate 10 rôznych ľudí, dajú 10 rôznych odpovedí. Ale tu je zaujímavá vec: všetkých desať týchto odpovedí bude správnych. Tu neexistuje nesprávna odpoveď. Bol som dosť hlboko do DevOps, asi 10 rokov, a bol som prvým Američanom na prvom DevOpsDay. Nehovorím, že som múdrejší ako všetci, ktorí sa podieľajú na DevOps, ale sotva sa nájde niekto, kto na to vynaložil toľko úsilia. Verím, že DevOps nastane, keď sa ľudský kapitál a technológie spoja. Často zabúdame na ľudský rozmer, hoci veľa hovoríme o všemožných kultúrach.
Teraz máme veľa údajov, päť rokov akademického výskumu, testovanie teórií v priemyselnom meradle. Tieto štúdie nám hovoria, že ak skombinujete niektoré vzorce správania v organizačnej kultúre, môžete dosiahnuť 2000 5000-násobné zrýchlenie. Tomuto zrýchleniu zodpovedá rovnaké zlepšenie stability. Ide o kvantitatívne meranie prínosu, ktorý môže DevOps priniesť akejkoľvek spoločnosti. Pred pár rokmi som sa o DevOps rozprával s generálnym riaditeľom spoločnosti z rebríčka Fortune 5. Keď som sa pripravoval na prezentáciu, bol som veľmi nervózny, pretože som musel zhrnúť svoje dlhoročné skúsenosti do XNUMX minút.
Na záver som dal nasledovné Definícia DevOps: Ide o súbor praktík a vzorov, ktoré umožňujú transformáciu ľudského kapitálu na vysokovýkonný organizačný kapitál. Príkladom je spôsob, akým Toyota fungovala posledných 50 alebo 60 rokov.
(Tieto schémy nie sú uvedené ako referenčný materiál, ale ako ilustrácie. Ich obsah sa bude pre každú novú spoločnosť líšiť. Obrázok je však možné zobraziť samostatne a zväčšiť
Jednou z najúspešnejších takýchto praktík je mapovanie prúdových hodnôt. Bolo o tom napísaných niekoľko dobrých kníh, z ktorých najúspešnejšie sú od Karen Martinovej. Ale za posledný rok som dospel k záveru, že aj tento prístup je príliš high-tech. Určite má veľa výhod a veľa som ho používal. Ale keď sa vás generálny riaditeľ spýta, prečo jeho spoločnosť nemôže prejsť na nové koľajnice, je príliš skoro hovoriť o mapovaní toku hodnôt. Existuje mnoho oveľa zásadnejších otázok, na ktoré treba najprv odpovedať.
Myslím si, že chybou mnohých mojich kolegov je, že jednoducho dajú spoločnosti päťbodový návod a potom sa vrátia o šesť mesiacov neskôr a uvidia, čo sa stalo. Dokonca aj dobrá schéma, ako je mapovanie toku hodnôt, má, povedzme, slepé miesta. Po stovkách rozhovorov s riaditeľmi rôznych spoločností som vytvoril určitý vzorec, ktorý nám umožňuje rozložiť problém na jeho zložky a teraz si rozoberieme každú z týchto zložiek v poradí. Pred aplikáciou akýchkoľvek technologických riešení používam tento vzor a v dôsledku toho sú všetky moje steny pokryté schémami. Nedávno som pracoval s podielovým fondom a skončil som so 100-150 takýmito schémami.
Zlá kultúra raňajkuje dobré prístupy
Hlavnou myšlienkou je toto: žiadne množstvo Lean, Agile, SAFE a DevOps nepomôže, ak je samotná kultúra organizácie zlá. Je to ako potápať sa do hĺbky bez potápačského vybavenia alebo pracovať bez röntgenu. Inými slovami, aby sme parafrázovali Druckera a Deminga: zlá organizačná kultúra pohltí každý dobrý systém bez toho, aby sa ním zadusila.
Ak chcete vyriešiť tento hlavný problém, musíte vykonať nasledujúce kroky:
- Zviditeľniť všetku prácu: musíte zviditeľniť všetku prácu. Nie v tom zmysle, že musí byť nevyhnutne zobrazený na nejakej obrazovke, ale v tom zmysle, že musí byť pozorovateľný.
- Konsolidované systémy riadenia práce: je potrebné konsolidovať systémy riadenia. V probléme „kmeňových“ vedomostí a inštitucionálnych vedomostí sú v 9 prípadoch z 10 prekážkou ľudia. V knihe problém bol s jedným jediným človekom, Brentom, ktorý spôsobil, že projekt meškal tri roky oproti plánu. A na týchto „Brentov“ narážam všade. Na vyriešenie týchto prekážok používam nasledujúce dve položky v našom zozname.
- Metodológia teórie obmedzení: teória obmedzení.
- Hacky na spoluprácu: kolaboračné hacky.
- Toyota Kata (): Nebudem veľa hovoriť o Toyote Kata. V prípade záujmu na mojom githube takmer na každú z týchto tém.
- Trhovo orientovaná organizácia: trhovo orientovaná organizácia.
- Revízori posunu doľava: audit v počiatočných fázach cyklu.
S organizáciou začínam pracovať veľmi jednoducho: idem do firmy a rozprávam sa so zamestnancami. Ako vidíte, žiadna špičková technológia. Všetko, čo potrebujete, je niečo na písanie. Zhromažďujem niekoľko tímov v jednej miestnosti a analyzujem, čo mi hovoria z pohľadu mojich 7 archetypov. A potom im dám fixku a požiadam ich, aby napísali na tabuľu všetko, čo doteraz nahlas povedali. Väčšinou sa na takýchto stretnutiach nájde jeden človek, ktorý si všetko zapíše a prinajlepšom dokáže zapísať 10 % diskusie. S mojou metódou sa toto číslo môže zvýšiť na približne 40%.
(Tento obrázok je možné vidieť samostatne )
Môj prístup je založený na práci Williama Schneidera. ). Prístup je založený na myšlienke, že každú organizáciu možno rozdeliť na štyri štvorce. Táto schéma je pre mňa zvyčajne výsledkom práce so stovkami ďalší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. Toto je krajne nežiaduca možnosť: keď sa všetci držia, ale nikto nevie, čo má robiť.
O niečo lepšia možnosť je možnosť s vysokou úrovňou kontroly aj kompetencie. Ak je takáto spoločnosť zisková, potom možno nepotrebuje DevOps. Najzaujímavejšie je pracovať s firmou, ktorá má vysokú mieru kontroly, nízku kompetenciu a spoluprácu, no zároveň vysokú kultúrnosť (kultivovanosť). To znamená, že firma má veľa ľudí, ktorí tam radi pracujú a fluktuácia pracovnej sily je nízka.
(Tento obrázok je možné vidieť samostatne )
Zdá sa mi, že metódy s pevnými usmerneniami nakoniec bránia dosiahnutiu pravdy. Najmä v mapovaní toku hodnôt existuje veľa pravidiel týkajúcich sa toho, ako by mali byť informácie štruktúrované. V počiatočných fázach práce, o ktorej teraz hovorím, nikto nepotrebuje tieto pravidlá. Ak človek s fixkou v rukách na tabuli opisuje skutočnú situáciu vo firme, je to najlepší spôsob, ako pochopiť stav vecí. Takéto informácie sa k riaditeľom nedostanú. V tejto chvíli je hlúpe prerušiť osobu a povedať, že nakreslil nejaký druh šípky nesprávne. V tejto fáze je lepšie použiť jednoduché pravidlá, napríklad: viacúrovňovú abstrakciu je možné vytvoriť jednoducho pomocou viacfarebných značiek.
Opakujem, žiadna špičková technológia. Čierna fixka zobrazuje objektívnu realitu toho, ako všetko funguje. Červenou značkou ľudia označujú to, čo sa im na súčasnom stave nepáči. Je dôležité, aby to napísali oni, nie ja. Keď idem po porade za CIO, neponúkam zoznam 10 vecí, ktoré treba opraviť. Snažím sa nájsť súvislosti medzi tým, čo hovoria ľudia vo firme, a existujúcimi overenými vzormi. Nakoniec modrá značka naznačuje možné riešenia problému.
(Tento obrázok je možné vidieť samostatne )
Príklad tohto prístupu je teraz znázornený vyššie. Začiatkom tohto roka som spolupracoval s jednou bankou. Tamojší ľudia z bezpečnosti boli presvedčení, že by nemali prísť na kontrolu dizajnu a požiadaviek.
(Tento obrázok je možné vidieť samostatne )
A potom sme sa rozprávali s ľuďmi z iných oddelení a ukázalo sa, že asi pred 8 rokmi vývojári softvéru vyhodili bezpečnostných pracovníkov, pretože spomaľovali prácu. A potom sa to zmenilo na zákaz, ktorý sa považoval za samozrejmosť. Aj keď v skutočnosti zákaz neexistoval.
Naše stretnutie prebiehalo mimoriadne mätúco: asi tri hodiny mi päť rôznych tímov nevedelo vysvetliť, čo sa deje medzi kódexom a zhromaždením. A toto sa zdá byť najjednoduchšie. Väčšina konzultantov DevOps vopred predpokladá, že to už každý vie.
Potom človek zodpovedný za IT governance, ktorý bol štyri hodiny ticho, zrazu ožil, keď sme sa dostali k jeho téme, a zamestnával nás na veľmi dlhú dobu. Na konci som sa ho spýtal, čo si o stretnutí myslí, a nikdy nezabudnem na jeho odpoveď. Povedal: „Kedysi som si myslel, že naša banka má len dva spôsoby dodávania softvéru, ale teraz viem, že ich je päť a o troch som ani nevedel.“
(Tento obrázok je možné vidieť samostatne )
Posledné stretnutie v tejto banke bolo s tímom investičného softvéru. Práve s ňou sa ukázalo, že písanie diagramov fixkou na hárok papiera je lepšie ako na tabuľu a ešte lepšie ako na smartboard.
Fotografie, ktoré vidíte, ukazujú, ako vyzerala hotelová konferenčná miestnosť na štvrtý deň nášho stretnutia. A pomocou týchto schém sme hľadali vzory, teda archetypy.
Pýtam sa teda robotníkov, oni si odpovede zapisujú fixkami troch farieb (čierna, červená a modrá). Analyzujem ich odpovede na archetypy. Teraz poďme diskutovať o všetkých archetypoch v poradí.
1. Zviditeľnite všetku prácu: Zviditeľnite prácu
Väčšina spoločností, s ktorými spolupracujem, má veľmi vysoké percento neznámej práce. Napríklad, keď jeden zamestnanec príde za druhým 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ác nie je nijak zdokumentovaných. Keby to bol Boeing, už nikdy v živote by som nenastúpil do ich lietadla. Ak je zdokumentovaná len polovica práce, potom sa nevie, či sa táto práca vykonáva správne alebo nie. Všetky ostatné metódy sa ukážu ako zbytočné - nemá zmysel pokúšať sa čokoľvek automatizovať, pretože známych 50% môže byť najkoherentnejšou a najjasnejšou časťou práce, ktorej automatizácia neprinesie skvelé výsledky a všetko najhoršie veci sú v neviditeľnej polovici. Pri absencii dokumentácie je nemožné nájsť najrôznejšie hacky a skrytú prácu, nie nájsť úzke miesta, práve tie „Brenty“, o ktorých som už hovoril. Existuje nádherná kniha od Dominiky DeGrandisovej . Ona prezrádza päť rôznych „únikov času“ (zlodeji času):
- Príliš veľa práce v procese (WIP)
- Neznáme závislosti
- Neplánovaná práca
- Konfliktné priority
- Zanedbaná práca
Toto je veľmi cenná analýza a kniha je skvelá, ale všetky tieto rady sú zbytočné, ak je viditeľných iba 50% údajov. Metódy navrhnuté Dominikou možno použiť, ak sa dosiahne presnosť nad 90 %. Hovorím o situáciách, keď šéf zadá podriadenému 15-minútovú úlohu, no trvá mu to tri dni; ale šéf v skutočnosti nevie, že tento podriadený je závislý od štyroch alebo piatich ďalších ľudí.
The Phoenix Project je úžasný príbeh o projekte, ktorý meškal tri roky. Jedna z postáv kvôli tomu čelí prepusteniu a stretáva sa s ďalšou postavou, ktorá je prezentovaná ako akýsi Sokrates. Pomáha zistiť, čo presne sa pokazilo. Ukázalo sa, že spoločnosť má jedného správcu systému, ktorý sa volá Brent a všetka práca ide akosi cez neho. Na jednom zo stretnutí sa jedného z podriadených pýtajú: prečo každá polhodinová úloha trvá týždeň? Odpoveďou je veľmi zjednodušená prezentácia teórie radenia a Littleovho zákona a v tejto prezentácii sa ukazuje, že pri 90% obsadenosti trvá každá hodina práce 9 hodín. Každú úlohu treba poslať siedmim ďalším ľuďom, takže z tej hodiny bude 63 hodín, 7 krát 9. Chcem povedať, že na to, aby ste mohli použiť Littleov zákon alebo akúkoľvek komplexnú teóriu zaraďovania do radu, musíte mať aspoň údaje.
Takže keď hovorím o viditeľnosti, nemyslím tým, že všetko je na obrazovke, ale že máte aspoň dáta. Keď tak urobia, často sa ukáže, že existuje veľké množstvo neplánovanej práce, ktorá sa nejakým spôsobom posiela Brentovi, keď to nie je potrebné. A Brent je skvelý chlap, nikdy nepovie nie, no nikomu nepovie, ako robí svoju prácu.
Keď je práca viditeľná, dáta sa dajú prehľadne triediť (to robí Dominika na fotke), aplikovať abstrakciu piatich časových únikov a aplikovať automatizáciu.
2. Konsolidujte systémy riadenia práce: riadenie úloh
Archetypy, o ktorých hovorím, sú akési pyramídy. Ak je prvý urobený správne, potom druhý je už akýmsi doplnkom. Mnohé z nich nefungujú pre startupy, treba ich mať na pamäti pre väčšie spoločnosti ako Fortune 5000. Posledná spoločnosť, pre ktorú som pracoval, mala 10 ticketingových systémov. Jeden tím mal Remedy, ďalší napísal nejaký vlastný systém, tretí používal Jira a niektorí si vystačili s e-mailom. Rovnaký problém nastáva, ak má spoločnosť 30 rôznych potrubí, ale nemám čas rozoberať všetky takéto prípady.
Diskutujem s ľuďmi o tom, ako presne lístky vznikajú, čo sa s nimi ďalej deje a ako sa obchádzajú. Najzaujímavejšie je, že ľudia na našich stretnutiach hovoria celkom úprimne. Pýtal som sa, koľko ľudí dalo "malý / žiadny vplyv" na lístky, ktoré by mali mať skutočne "veľký vplyv". Ukázalo sa, že to robí takmer každý. Nezapájam sa do odsudzovania a snažím sa všetkými možnými spôsobmi neidentifikovať ľudí. Keď sa mi k niečomu úprimne priznajú, tak toho človeka neprezradím. Ale keď takmer každý obchádza systém, znamená to, že všetka bezpečnosť je v podstate úprava okien. Z údajov tohto systému preto nemožno vyvodzovať žiadne závery.
Ak chcete vyriešiť problém s lístkami, musíte si vybrať jeden hlavný systém. Ak používate Jira, nechajte si ho Jira. Ak existuje nejaká alternatíva, nech je jediná. Pointa je, že lístky by sa mali považovať za ďalší krok v procese vývoja. Každá akcia musí mať lístok, ktorý musí prejsť vývojovým workflow. Lístky sa posielajú tímu, ktorý ich uverejní na storyboarde a potom za ne prevezme zodpovednosť.
Týka sa to všetkých oddelení vrátane infraštruktúry a prevádzky. V tomto prípade je možné vytvoriť aspoň nejakú hodnovernú predstavu o stave vecí. Po zavedení tohto procesu je zrazu ľahké určiť, kto je zodpovedný za jednotlivé aplikácie. Pretože teraz dostávame nie 50 %, ale 98 % nových služieb. Ak tento základný proces funguje, presnosť sa zlepšuje v celom systéme.
Potrubie služieb
To platí opäť len pre veľké korporácie. Ak ste nová spoločnosť v novom odbore, vyhrňte si rukávy a pracujte s Travis CI alebo CircleCI. Pokiaľ ide o spoločnosti Fortune 5000, prípad, ktorý sa stal v banke, kde som pracoval. Prišiel k nim Google a ukázali im schémy starých systémov IBM. Chlapci z Google sa zmätene pýtali – kde je na to zdrojový kód? Ale neexistuje žiadny zdrojový kód, dokonca ani GUI. Toto je realita, s ktorou sa musia veľké organizácie vysporiadať: 40-ročné bankové záznamy na starom sálovom počítači. Jeden z mojich klientov používa kontajnery Kubernetes so vzormi ističov a Chaos Monkey, všetko pre aplikáciu KeyBank. Tieto kontajnery sa však nakoniec pripájajú k aplikácii COBOL.
Chlapci z Google boli úplne presvedčení, že vyriešia všetky problémy môjho klienta, a potom sa začali pýtať: čo je to IBM datapipe? Hovorí sa im: toto je konektor. S čím sa to spája? Do Sperryho systému. a čo to je? A tak ďalej. Na prvý pohľad sa zdá: aký druh DevOps môže existovať? Ale v skutočnosti je to možné. Existujú doručovacie systémy, ktoré vám umožňujú odovzdať pracovný postup doručovacím tímom.
3. Teória obmedzení: Teória obmedzení
Prejdime k tretiemu archetypu: inštitucionálne/"kmeňové" znalosti. V každej organizácii je spravidla niekoľko ľudí, ktorí všetko vedia a všetko riadia. To sú tí, ktorí sú v organizácii najdlhšie a poznajú všetky možné riešenia.
Keď sa to objaví na diagrame, špeciálne zakrúžkujem takýchto ľudí fixkou: napríklad sa ukáže, že na všetkých stretnutiach je prítomný istý Lou. A je mi to jasné: toto je miestny Brent. Keď si CIO vyberá medzi mnou v tričku a teniskách a chlapíkom z IBM v obleku, som vybraný, pretože môžem riaditeľovi povedať veci, ktoré ten druhý nepovie a ktoré by riaditeľ nemusel rád počuť. . Hovorím im, že prekážkou v ich spoločnosti je niekto menom Fred a niekto Lou. Toto úzke hrdlo treba rozviazať, ich vedomosti treba od nich tak či onak získať.
Na vyriešenie tohto druhu problému môžem napríklad navrhnúť použitie Slack. Inteligentný režisér sa opýta – prečo? V takýchto prípadoch konzultanti DevOps zvyčajne odpovedajú: pretože to robia všetci. Ak je riaditeľ naozaj šikovný, povie: no a čo. A tu sa dialóg končí. A moja odpoveď je: pretože v spoločnosti sú štyri úzke miesta, Fred, Lou, Susie a Jane. Na inštitucionalizáciu ich vedomostí je potrebné najprv predstaviť Slack. Všetky vaše wiki sú úplný nezmysel, pretože nikto nevie o ich existencii. Ak sa inžiniersky tím podieľa na vývoji front-end a back-end a každý potrebuje vedieť, že s otázkami môže kontaktovať front-end vývojový tím alebo tím infraštruktúry. Vtedy budú mať pravdepodobne Lou alebo Fred čas pripojiť sa na wiki. A potom sa v Slacku môže niekto opýtať, prečo nefunguje, povedzme, krok 5. A potom Lou alebo Fred opravia pokyny na wiki. Ak zavediete tento proces, veľa vecí zapadne samo.
Toto je moja hlavná myšlienka: ak chcete odporučiť akékoľvek špičkové technológie, musíte pre ne najprv urobiť poriadok, a to sa dá urobiť pomocou práve opísaných riešení nízkej úrovne. Ak začnete so špičkovými technológiami a nevysvetlíte, prečo sú potrebné, spravidla to nekončí dobre. Jeden z našich klientov používa Azure ML, veľmi lacné a jednoduché riešenie. Asi 30 % ich otázok zodpovedal samotný samoučiaci stroj. A túto vec napísali operátori, ktorí sa nezaoberali dátovou vedou, štatistikou alebo matematikou. Toto je významné. Náklady na takéto riešenie sú minimálne.
4. Collaboration hacks: Collaboration hacks
Štvrtým archetypom je potreba bojovať proti izolácii. Väčšina ľudí to už vie: izolácia plodí nepriateľstvo. Ak je každé oddelenie na vlastnom poschodí a ľudia sa okrem výťahu nijako navzájom nepretínajú, potom medzi nimi veľmi ľahko vzniká nevraživosť. Ale ak sú naopak ľudia spolu v jednej miestnosti, okamžite odíde. Keď niekto vyhodí nejaké všeobecné obvinenie, napríklad také a také rozhranie nikdy nefunguje, nie je nič jednoduchšie takéto obvinenie dekonštruovať. Programátorom, ktorí vytvorili rozhranie, stačí začať klásť konkrétne otázky a čoskoro sa ukáže, že napríklad používateľ jednoducho používal nástroj nesprávne.
Existuje mnoho spôsobov, ako prekonať izoláciu. Raz ma požiadali o konzultáciu pre banku v Austrálii, ale odmietol som to urobiť, pretože mám dve deti a manželku. Jediné, čo som im mohol pomôcť, bolo odporučiť grafické rozprávanie. Je to niečo, čo sa osvedčilo. Ďalším zaujímavým spôsobom sú stretnutia štíhlej kávy. Vo veľkej organizácii je to vynikajúca možnosť na šírenie vedomostí. Okrem toho môžete vykonávať interné devopsdays, hackathony atď.
5. Koučovanie Kata
Ako som varoval na začiatku, dnes o tom nebudem hovoriť. Ak máte záujem, môžete sa pozrieť .
Na túto tému je tiež dobrý rozhovor od Mikea Rothera:
6. Market Oriented: trhovo orientovaná organizácia
Sú tu rôzne problémy. Napríklad „I“ ľudia, „T“ ľudia a „E“ ľudia. „Ja“ ľudia sú tí, ktorí robia len jednu vec. Zvyčajne existujú v organizáciách s izolovanými oddeleniami. "T" je, keď je človek dobrý v jednej veci, ale je dobrý aj v niektorých iných veciach. "E" alebo dokonca "hrebeň" je, keď má človek veľa zručností.
Tu funguje Conwayov zákon (), čo v najjednoduchšej podobe možno uviesť takto: ak na kompilátore pracujú tri tímy, výsledkom bude kompilátor troch častí. Preto, ak je v organizácii vysoká miera izolácie, potom aj Kubernetes, istič, rozšíriteľnosť API a ďalšie ozdobné veci v tejto organizácii budú usporiadané rovnakým spôsobom ako samotná organizácia. Presne podľa Conwaya a napriek tomu vám všetkým mladým geekom.
Riešenie tohto problému bolo už mnohokrát popísané. Existujú napríklad organizačné archetypy, ktoré opísal Fernando Fernandez. Tá problematická architektúra, o ktorej som práve hovoril, s izoláciou, je funkčne orientovaná architektúra. Druhý typ je najhorší, maticová architektúra, neporiadok ostatných dvoch. Tretím je to, čo je vidieť vo väčšine startupov a tomuto typu sa snažia vyrovnať aj veľké spoločnosti. Je to trhovo orientovaná organizácia. Tu optimalizujeme, aby sme dosiahli čo najrýchlejšiu reakciu na požiadavky zákazníkov. Toto sa niekedy nazýva plochá organizácia.
Mnoho ľudí popisuje túto štruktúru rôznymi spôsobmi, páči sa mi to znenie budovať/riadiť tímy, v Amazone to nazývajú dva tímy na pizzu. V tejto štruktúre sú všetci ľudia typu „I“ zoskupení okolo jednej služby a postupne sa zbližujú s typom „T“ a ak je správny manažment, môžu sa stať aj „E“. Prvým protiargumentom je, že takáto štruktúra má zbytočné prvky. Prečo potrebujete testera v každom oddelení, ak môžete mať špeciálne oddelenie testerov? Na čo odpovedám: dodatočné náklady sú v tomto prípade cenou za to, že sa celá organizácia v budúcnosti stane typom „E“. V tejto štruktúre sa tester postupne učí o sieťach, architektúre, dizajne atď. Vďaka tomu si každý účastník organizácie plne uvedomuje všetko, čo sa v organizácii deje. Ak chcete vedieť, ako táto schéma funguje v priemysle, čítajte .
7. Audítori s posunom doľava: audit na začiatku cyklu. Súlad s bezpečnostnými pravidlami na displeji
Vtedy vaše činy takpovediac neprejdú pachovým testom. Ľudia, ktorí pre vás pracujú, nie sú hlúpi. Ak, ako vo vyššie uvedenom príklade, všade nastavili malý/žiadny vplyv, trvalo to tri roky a nikto si nič nevšimol, tak každý veľmi dobre vie, že systém nefunguje. Alebo iný príklad – poradňa zmeny, kde treba hlásenia podávať povedzme každú stredu. Pracuje tam skupina ľudí (mimochodom nie veľmi dobre platených), ktorí by teoreticky mali vedieť, ako systém ako celok funguje. A za posledných päť rokov ste si určite všimli, že naše systémy sú neuveriteľne zložité. A päť-šesť ľudí sa musí rozhodnúť o zmene, ktorú neurobili a o ktorej nič nevedia.
Samozrejme, tento prístup nefunguje. Musím sa takýchto vecí zbaviť, pretože títo ľudia nechránia systém. Rozhodnutie musí urobiť tím sám, pretože tím musí byť za to zodpovedný. V opačnom prípade nastáva paradoxná situácia, keď manažér, ktorý v živote nepísal kód, povie programátorovi, ako dlho má napísanie kódu trvať. Jedna spoločnosť, s ktorou som pracoval, mala 7 rôznych dosiek, ktoré preverovali každú zmenu, vrátane dosky architektúry, produktovej dosky atď. Bola tam dokonca aj povinná čakacia doba, hoci mi jedna zamestnankyňa povedala, že za desať odpracovaných rokov nikto nikdy neodmietol zmenu vykonanú touto osobou v tejto povinnej lehote.
Audítorov k nám treba pozvať a nie sa ich zbaviť. Povedzte im, že píšete nemenné binárne kontajnery, ktoré, ak prejdú všetkými testami, zostanú nemenné navždy. Povedzte im, že máte kanál ako kód a vysvetlite, čo to znamená. Ukážte im nasledujúcu schému: nemenný binárny súbor len na čítanie v kontajneri, ktorý prejde všetkými testami zraniteľnosti; a potom sa ho nielenže nikto nedotkne, ale ani sa nedotkne systému, ktorý vytvára potrubie, keďže sa tiež vytvára dynamicky. Mám klientov, Capital One, ktorí používajú Vault na vytvorenie niečoho ako blockchain. Audítor nemusí ukazovať „recepty“ od Chefa, stačí ukázať blockchain, z ktorého je jasné, čo sa stalo s tiketom Jira vo výrobe a kto je za to zodpovedný.
Podľa , vytvorený v roku 2018 spoločnosťou Sonatype, v roku 2017 bolo 87 miliárd žiadostí o stiahnutie OSS.
Straty spôsobené zraniteľnosťami sú neúmerné. Navyše čísla, ktoré teraz vidíte vyššie, nezahŕňajú alternatívne náklady. Čo je to v skratke DevSecOps? Dovoľte mi hneď povedať, že nemám záujem hovoriť o úspešnosti tohto názvu. Ide o to, že keďže DevOps bol taký úspešný, mali by sme sa pokúsiť pridať bezpečnosť do tohto potrubia.
Príklad tejto sekvencie:
Toto nie je odporúčanie na konkrétne produkty, aj keď sa mi páčia všetky. Uviedol som ich ako príklad, aby som ukázal, že DevOps, ktorý bol pôvodne založený na organizačnej paradigme v priemysle, vám umožňuje automatizovať každú fázu práce na produkte.
A nie je dôvod, prečo by sme nemohli zaujať rovnaký prístup k bezpečnosti.
Celkový
Na záver uvediem niekoľko tipov pre DevSecOps. Do procesu vytvárania vašich systémov musíte zapojiť audítorov a venovať im čas ich vzdelávaním. Musíte spolupracovať s audítormi. Ďalej musíte viesť absolútne nemilosrdný boj proti falošným pozitívam. Dokonca aj s najdrahším nástrojom na skenovanie zraniteľností môžete medzi svojimi vývojármi vytvoriť extrémne zlé návyky, ak neviete, aký je váš pomer signálu k šumu. Vývojári budú zahltení udalosťami a jednoducho ich vymažú. Ak ste počuli o príbehu Equifax, presne to sa stalo tam, kde bola ignorovaná najvyššia úroveň výstrahy. Okrem toho je potrebné zraniteľnosti vysvetliť tak, aby bolo jasné, ako ovplyvňujú podnikanie. Dalo by sa napríklad povedať, že ide o rovnakú zraniteľnosť ako v príbehu Equifax. S bezpečnostnými chybami by sa malo zaobchádzať rovnako ako s inými softvérovými problémami, to znamená, že by mali byť zahrnuté do celkového procesu DevOps. Musíte s nimi pracovať cez Jira, Kanban atď. Vývojári by si nemali myslieť, že to urobí niekto iný – práve naopak, mal by to urobiť každý. Nakoniec musíte minúť energiu na školenie ľudí.
Užitočné odkazy
Tu je niekoľko prednášok z konferencie DevOops, ktoré by sa vám mohli hodiť:
- Sergey Berdnikov, Artyom Kalichkin - Príbeh o úspechu alebo „Dev+DevOps+Ops“ (, )
- Baruch Sadogursky, Leonid Igolnik - DevOps v mierke: grécka tragédia v troch dejstvách (, )
- Alexander Titov, Kirill Tolkachev -
- Timothy Lister -
Pozrieť sa do Devoops 2020 Moskva — aj tam je veľa zaujímavých vecí.
Zdroj: hab.com