Otázka „jak zavést DevOps“ se diskutuje už několik let, ale dobrých materiálů není příliš. Někdy se stanete obětí reklamy méně chytrých consultantů, kteří potřebují prodat svůj čas, ať už to dopadne jakkoliv. Někdy to jsou mlhavá, velmi obecná slova o tom, jak megakorporace plují vesmírem. Vzniká otázka: co z toho pro nás? Vážení autore, můžete srozumitelně sepsat své myšlenky?
To vše vyplývá z toho, že reálné praxe a porozumění výsledkům transformace firemní kultury není tak moc. Změny v kultuře jsou dlouhodobé záležitosti, jejichž výsledky se neprojeví za týden nebo měsíc. Potřebujeme někoho dostatečně zkušeného, kdo zažil, jak se firmy zakládaly a rozpadaly v průběhu mnoha let.
John Willis — jeden ze zakladatelů DevOps. John má za sebou desítky let práce s velkým množstvím firem. V poslední době si John začal všímat specifických vzorců, které se v práci s každou z nich objevují. Používající tyto archetypy, John nasměrovává firmy na správnou cestu DevOps transformace. Více o těchto archetypech naleznete v překladu jeho přednášky z konference DevOops 2018.
O přednášejícím:
Více než 35 let v IT managementu, podílel se na zakládání předchůdce OpenCloud v Canonical, zúčastnil se 10 startupů, z nichž dva prodal Dell a Docker. Nyní je Vice President of DevOps and Digital Practices ve SJ Technologies.
Dále — vyprávění z pohledu Johna.
Jmenuji se John Willis a nejlépe mě najdete na Twitteru, . Ten samý pseudonym mám na Gmailu a GitHubu. A můžete najít videonahrávky mých přednášek a k nim prezentace.
Mám mnoho schůzek s CIO různých velkých společností. Velmi často si stěžují, že nechápou, co je to DevOps, a ti, kdo se to snaží vysvětlit, mluví o něčem svém. Další častou stížností je, že DevOps nefunguje, i když ředitelé údajně dělají vše, jak bylo vysvětleno. Jedná se o velké společnosti, které existují více než sto let. Po rozhovorech s nimi jsem dospěl k závěru, že pro mnoho problémů jsou lepší nevysoce technologická, ale relativně nízkotехнологická řešení. Měsíce jsem se prostě bavil s lidmi z různých oddělení. To, co vidíte na první obrázku v příspěvku, je můj poslední projekt, místnost tak vypadala po třech dnech práce.
Co je DevOps?
Opravdu, pokud se zeptáte 10 různých lidí, dají vám 10 různých odpovědí. Ale co je zajímavé: všechny tyto odpovědi budou správné. Nesprávná odpověď zde neexistuje. DevOps se věnuji poměrně hluboce, asi 10 let, byl jsem prvním Američanem na prvním DevOpsDays. Neřeknu, že jsem chytřejší než ti, kdo se zabývají DevOps, ale stěží existuje někdo, kdo na to vynaložil tolik úsilí. Domnívám se, že DevOps vzniká, když se spojí lidský kapitál a technologie. Často zapomínáme na lidský rozměr, i když mluvíme o různých kulturách.
Nyní máme mnoho dat, pět let akademického výzkumu, teorie ověřené v průmyslových měřítkách. Tento výzkum nám říká následující: pokud v organizační kultuře spojíte určité behaviorální vzory, můžete dosáhnout zrychlení až 2000krát. Tomu zrychlení odpovídá stejné zlepšení v odolnosti. To je kvantitativní měření výhody, kterou může DevOps poskytnout jakékoli společnosti. Před několika lety jsem vyprávěl o DevOps generálnímu řediteli společnosti z seznamu Fortune 5000. Když jsem se připravoval na prezentaci, byl jsem velmi nervózní, protože jsem potřeboval během 5 minut shrnout své mnohaleté zkušenosti.
Nakonec jsem uvedl následující definici DevOps: je to soubor praktik a vzorů, které umožňují proměnit lidský kapitál v vysoce výkonný organizační kapitál. Příkladem je to, jak posledních 50 nebo 60 let funguje Toyota.
(Tyto schémata jsou uváděna ne jako referenční materiál, ale jako ilustrace. Jejich obsah se bude lišit pro každou novou společnost. Nicméně obrázek si lze prohlédnout a zvětšit)
Jedna z nejúspěšnějších takových praktik — mapování hodnotového toku. O tom bylo napsáno několik dobrých knih, autorem nejúspěšnější z nich je Karen Martin. Ale za poslední rok jsem dospěl k závěru, že i tento přístup je příliš vysoce technologický. Určitě má spoustu výhod, hodně jsem jich používal. Ale když se generální ředitel ptá, proč jeho společnost nemůže přejít na nové koleje, o mapování hodnotového toku je ještě brzy mluvit. Existuje spousta podstatně fundamentálnějších otázek, na které je třeba nejprve najít odpovědi.
Myslím, že chybou mnoha mých kolegů je, že prostě dají společnosti návod v pěti bodech a pak se vrátí za šest měsíců a podívají se, co se stalo. I dobré schéma jako mapování hodnotového toku má, řekněme, mrtvé zóny (blind spots). Po stovkách rozhovorů s řediteli různých společností jsem si vytvořil určitý vzor, který umožňuje rozložit problém na součásti, a nyní si postupně probereme každou z těchto součástí. Než použiji jakákoli technologická řešení, použiji tento vzor, a výsledkem je, že mám všechny stěny pokryté schématy. Nedávno jsem pracoval s jedním vzájemným fondem, a měl jsem nakonec 100-150 takových schémat.
Špatná kultura sní dobré přístupy k snídani
Hlavní myšlenka je taková: žádné Lean, Agile, SAFE a DevOps nepomohou, pokud je sama kultura organizace špatná. Je to jako potápět se do hloubky bez kyslíkového přístroje nebo provádět operaci bez rentgenového snímku. Jinými slovy, parafrázujíce Druckera a Deminga: špatná organizační kultura pohltí jakýkoli dobrý systém a nezadusí se.
Abychom vyřešili tento hlavní problém, je třeba podniknout následující kroky:
- Zviditelněte veškerou práci: je třeba učinit veškerou práci viditelnou. Ne v tom smyslu, že by se nutně musela zobrazovat na nějaké obrazovce, ale v tom smyslu, že by měla být pozorovatelná.
- Konsolidujte systémy řízení práce: je nutné konsolidovat systémy managementu. V problému „kmenových“ znalostí a institucionálních znalostí je v 9 případech z 10 úzkým místem lidský faktor. V knize byl problém v jednom jediném člověku, Brentu, kvůli kterému projekt zaostával o tři roky. A na takové „Brenty“ narážím všude. K řešení těchto úzkých míst používám následující dva body ze našeho seznamu.
- Metodologie Teorie omezení: teorie omezení.
- Zlepšení spolupráce: hacky spolupráce.
- Toyota Kata (): o Toyota Kata nebudu dlouze hovořit. Pokud vás to zajímá, na mém githubu téměř o každém z těchto témat.
- Organizace orientovaná na trh: tržně orientovaná organizace.
- Shift-left auditoři: audit v raných fázích cyklu.
Práci s organizací začínám velmi jednoduše: jdu do společnosti a rozhoduji se s zaměstnanci. Jak vidíme, žádné vysoké technologie. Vše, co potřebujete, je mít na čem psát. Shromažďuji několik týmů v jedné místnosti a analyzuji to, co mi říkají, z pohledu svých 7 archetypů. A pak jim dám sami fixu a požádám je, aby v kostce napsali na tabuli vše, co dosud říkali nahlas. Obvykle na takových schůzkách je jeden člověk, který vše zapisuje, a v tom nejlepším případě se mu podaří zapsat 10 % diskuze. Při mé metodě se tento údaj podaří zvýšit na cca 40%.
(Tento obrázek si lze )
Můj přístup je založen na práci Williama Schneidera (William Schneider, ). Základem přístupu je myšlenka, že jakoukoli organizaci lze rozložit na čtyři čtverce. Tato schéma bývá obvykle výsledkem práce s těmi stovkami dalších schémat, které se objeví při analýze organizace. Představme si organizaci s vysokou úrovní kontroly, ale s nízkou kompetencí. To je krajně nežádoucí varianta: když všichni chodí jako ve struně, ale nikdo neví, co má dělat.
O něco lepší varianta s vysokou úrovní kontroly a kompetence. Pokud má taková společnost zisk, možná DevOps ani nepotřebuje. Nejdůležitější je spolupracovat se společností, která má vysokou úroveň kontroly, nízkou kompetenci a spolupráci, ale zároveň vysokou úroveň kultury (cultivation). To znamená, že ve společnosti je mnoho lidí, kterým se tam líbí pracovat, a fluktuace pracovní síly je nízká.
(Tento obrázek si lze )
Myslím si, že metody s pevně stanovenými doporučeními nakonec brání dosáhnout pravdy. Zejména ve value stream mappingu existuje mnoho pravidel o tom, jak by měly být informace strukturovány. V raných fázích práce, o kterých teď mluvím, tato pravidla nikomu nejsou potřeba. Pokud člověk s markerem v ruce popisuje na tabuli skutečnou situaci ve firmě — to je nejlepší způsob, jak se dostat do obrazu. Takové informace se k ředitelům nedostanou. V tuto chvíli je hloupé přerušovat člověka a říkat mu, že špatně nakreslil nějakou šipku. V této fázi je lepší dodržovat jednoduchá pravidla, například: vícestupňovou abstrakci lze vytvořit prostým použitím různobarevných markerů.
Opakuji, žádné vysoké technologie. Černým markerem se znázorňuje objektivní realita, jak to všechno funguje. Červeným markerem lidé označují, co se jim na současném stavu nelíbí. Důležité je, že to píší oni, a ne já. Když po schůzi jdu za ředitelem IT, nenavrhuji seznam 10 věcí, které je třeba opravit. Snažím se najít souvislosti mezi tím, co říkají lidé ve firmě, a existujícími ověřenými vzorci. Nakonec modrým markerem navrhuji možná řešení problému.
(Tento obrázek si lze )
Příklad takového přístupu je nyní znázorněn výše. Na začátku tohoto roku jsem pracoval s jednou bankou. Zaměstnanci oddělení bezpečnosti byli přesvědčeni, že nemohou přicházet na kontroly požadavků a návrhů (design and requirement reviews).
(Tento obrázek si lze )
A pak jsme mluvili s lidmi z jiných oddělení a zjistili jsme, že přibližně před 8 lety vyhodili pracovníky bezpečnosti, protože zpomalovali práci. A pak se to změnilo v zákaz, který byl vnímán jako danost. Ačkoli ve skutečnosti žádný zákaz neexistoval.
Naše setkání probíhalo velmi zmateně: během asi tří hodin pět různých týmů nebylo schopno mi vysvětlit, co se děje mezi kódem a sestavením. A to se zdá být ta nejjednodušší věc. Většina konzultantů DevOps předpokládá, že je to již všem známo.
Pak se člověk zodpovědný za IT governance, který mlčel čtyři hodiny, najednou ožil, když jsme přišli na jeho téma, a zabrali nám ještě na velmi dlouhou dobu. Na konci jsem se ho zeptal, co si o setkání myslí, a nikdy nezapomenu na jeho odpověď. Řekl: „Dříve jsem si myslel, že v naší bance jsou pouze dva způsoby dodání softwaru, a teď vím, že jich je celkem pět, a o třech jsem ani nepředpokládal.“
(Tento obrázek si lze )
Poslední setkání v této bance bylo s týmem, který se zabývá softwarem pro investice. Právě s ním se ukázalo, že je lepší psát schémata fixem na papír než na tabuli, a dokonce lépe než na smartboardu.
Fotografie, které vidíte, ukazují, jak vypadala konferenční místnost hotelu čtvrtý den našeho setkání. A tato schémata jsme používali k vyhledávání vzorců, tedy archetypů.
Takže pokládám otázky zaměstnancům, oni zapisují odpovědi fixy třech barev (černé, červené a modré). Jejich odpovědi analyzuji z hlediska archetypů. Teď si pojďme probrat všechny archetypy postupně.
1. Make All Work Visible: Udělejte práci viditelnou
Ve většině firem, se kterými pracuji, je velmi vysoké procento neznámé práce. Například když jeden zaměstnanec přijde k druhému a prostě požádá o něco udělat. V velkých organizacích může být až 60 % neplánované práce. A až 40 % práce není nijak zdokumentováno. Kdyby to byl Boeing, nikdy bych se znovu nenastoupil do jejich letadla. Pokud je zdokumentována pouze polovina prací, není jasné, zda je tato práce vykonávána správně či nikoli. Všechny ostatní metody se ukazují jako zbytečné — nemá žádný smysl se pokoušet něco automatizovat, protože známých 50 % může být právě tou nejorganizovanější a nejpřehlednější částí práce, jejíž automatizace nepřinese velké výsledky, zatímco to nejhorší je v neviditelné části. Bez dokumentace není možné najít různé hacks a skrytou práci, nenaleznou se úzká místa, ti „Brentové“, o kterých jsem již mluvil. Existuje skvělá kniha od Dominiky De Grandis. . Ta odhaluje pět různých „úniků času“ (thieves of time):
- Příliš mnoho práce v procesu (WIP)
- Neznámé závislosti
- Neplánovaná práce
- Konfliktní priority
- Ponechaná práce
Je to velmi cenná analýza a kniha je skvělá, ale všechny tyto rady jsou k ničemu, pokud jsou viditelné pouze 50 % dat. Použití metod navržených Dominikou je možné pouze tehdy, pokud je dosaženo přesnosti nad 90 %. Mluvím o situacích, kdy šéf dá podřízenému úkol na 15 minut, ale ten trvá tři dny; ale šéf ve skutečnosti neví, že tento podřízený závisí ještě na čtyřech nebo pěti dalších lidech.
Phoenix Project — je skvělý příběh o projektu, který přišel o tři roky. Jednomu z hrdinů hrozí propuštění, a tak se setkává s jinou postavou, která je představena jako jakýsi Sokrates. Tento mu pomáhá pochopit, co přesně se pokazilo. Zjišťuje se, že ve firmě je jeden administrátor, kterého jmenují Brent, a veškerá práce tak či onak prochází přes něj. Na jednom ze setkání se jeden z podřízených ptá: proč každá půlhodinová úloha trvá týden? Odpověď obsahuje velmi zjednodušené vysvětlení teorie front a Littlova zákona, a v tomto vysvětlení vychází najevo, že při obsazenosti 90 % každý hodinový úkol trvá 9 hodin. Každý úkol je třeba poslat sedmi dalším lidem, takže se tato hodina promění v 63 hodin, 7 krát 9. Říkám to proto, že abyste mohli používat Littlův zákon nebo jakoukoli složitější teorii front, potřebujete alespoň mít data.
Když tedy mluvím o viditelnosti, nemám na mysli, aby všechno bylo na obrazovce, ale to, že alespoň musíte mít data. Když jsou k dispozici, často se zjistí, že je zde velmi velké množství neplánované práce, která nějakým způsobem směřuje k Brentovi, přestože to není vůbec potřeba. A Brent je skvělý kluk, nikdy neřekne „ne“, ale nikomu neříká, jak svou práci dělá.
Když je práce viditelná, můžete pečlivě klasifikovat data (to je přesně to, co Dominika dělá na fotografii), můžete aplikovat abstrakci pěti úniků času a automatizovat.
2. Konsolidovat systémy správy práce: Správa úkolů
Archtypy, o kterých mluvím, představují jakousi pyramidu. Pokud je první splněn správně, druhý je již jakousi nadstavbou. Mnoho z nich nefunguje pro startupy, měli byste je mít na paměti v případě velkých společností, které se dostanou na seznam Fortune 5000. V poslední firmě, kde jsem pracoval, bylo 10 systémů pro sledování chyb (ticketing system). V jednom týmu byl Remedy, jiný napsal nějaký vlastní systém, třetí používal Jira, někdo se zcela obešel bez e-mailu. Stejný problém nastává, pokud má firma 30 různých pipeline, ale nemám čas na to, abych probral všechny takové případy.
Diskutuji s lidmi o tom, jak se ticket vytvářejí, co se s nimi dále děje a jak se obcházejí. Nejzajímavější je, že lidé na našich setkáních mluví docela upřímně. Zeptal jsem se, kolik lidí uvádí 'menší / žádný dopad' u ticketů, kterým by se ve skutečnosti mělo přiřadit 'významný dopad'. Ukázalo se, že to dělá téměř každý. Nezabývám se donášením a snažím se nijak neodhalovat jednotlivce. Když mi někdo otevřeně něco přizná, nezradím ho. Ale když téměř každý obchází systém, znamená to, že celá bezpečnost je v podstatě jen fasádou. Proto nelze z dat tohoto systému činit žádné závěry.
Abychom vyřešili problém s tickety, musíme zvolit jeden hlavní systém. Pokud používáte Jira, ať je to jen Jira. Pokud existuje nějaká alternativa, ať je to jen ta. Jde o to, že tickety je třeba považovat za další fázi vývojového procesu. Každá činnost by měla mít ticket, který prochází pracovním tokem vývoje. Tickety jsou zasílány týmu, který je umisťuje na storyboard a poté nese za ně odpovědnost.
To se týká všech oddělení, včetně infrastruktury a operací. V takovém případě je možné vytvořit jakékoli proklamativní zobrazení situace. Když je tento proces zaveden, najednou zjistíme, že lze snadno určit, kdo je odpovědný za každou aplikaci. Protože nyní máme ne 50%, ale 98% nových služeb. Pokud tento základní proces funguje, zvyšuje se přesnost v celém systému.
Pipeline služeb
Tohoto se to týká pouze velkých korporací. Pokud jste nová společnost v novém oboru, vyhrňte si rukávy a pracujte se svým Travis CI nebo CircleCI. Co se týče společností Fortune 5000, je výstižný případ, který se stal v bance, kde jsem pracoval. Přišli k nim z Googlu a ukázali jim grafy se starými systémy IBM. Kluci z Googlu se zmateně ptali – a kde je pro to zdrojový kód? Žádný zdrojový kód není, není ani žádné GUI. To je realita, se kterou musí velké organizace pracovat: 40leté bankovní záznamy na archaickém mainframu. Jeden z mých klientů používá kontejnery Kubernetes s vzory Circuit Breaker, plus Chaos Monkey, to vše pro aplikaci KeyBank. Ale tyto kontejnery nakonec připojují k aplikaci napsané v COBOL.
Kluci z Googlu byli naprosto přesvědčeni, že vyřeší všechny problémy mého klienta, a pak začali klást otázky: co je to IBM datapipe? Odpověděli: je to konektor. K čemu se připojuje? K systému Sperry. A co to je? A tak dále. Na první pohled se to zdá jako – kde tady může být DevOps? Ale ve skutečnosti to možné je. Existují dodávkové systémy, které umožňují předat pracovní proces týmům zabývajícím se dodávkou.
3. Teorie omezení: Theory of Constraints
Přejděme k třetímu archetypu: institucionální / „kmenové“ znalosti. Obecně platí, že v jakékoli organizaci existuje několik lidí, kteří vědí všechno a všemu velí. To jsou ti, kdo jsou v organizaci nejdéle a kteří znají všechny zkratky.
Když se to na diagramu objeví, speciálně takové lidi vyznačuji zvýrazňovačem: například se zjistí, že nějaký Lou je přítomen na všech schůzkách. A pro mě je jasné: to je místní Brent. Když se ředitel informačních technologií rozhoduje mezi mnou v tričku a teniskách a chlapem z IBM oblečeném v obleku, vybírají si mě, protože jim mohu říct věci, které ten druhý chlapec neřekne a o kterých by pro ředitele mohlo být nepříjemné slyšet. Říkám jim, že v jejich společnosti je úzké místo, a to někdo jménem Fred a někdo jménem Lou. Tento úzký bod je třeba uvolnit, jejich znalosti je třeba získat jinak.
Aby vyřešil tento typ problému, mohu například navrhnout použití Slacku. Důvtipný ředitel se zeptá — proč? Obvykle na takové otázky odpovídají konzultanti v oblasti DevOps: protože to tak dělají všichni. Pokud je ředitel skutečně důvtipný, řekne: a co jako. A tím skončí dialog. A já na to odpovídám: protože ve společnosti jsou čtyři úzká místa, Fred, Lou, Suzi a Jane. Aby se jejich znalosti institucionalizovaly, je třeba nejprve zavést Slack. Všechny vaše wiki jsou úplný nesmysl, protože nikdo neví o jejich existenci. Pokud se inženýrský tým zabývá externím a interním vývojem a všichni by měli vědět, že se mohou obrátit na tým externího vývoje nebo tým infrastruktury s dotazy. Právě tehdy pravděpodobně Lou nebo Fred najdou čas, aby se připojili k wiki. A pak se někdo ve Slacku může zeptat, proč nefunguje, řekněme, krok 5. A potom Lou nebo Fred opraví návod na wiki. Pokud se tento proces zorganizuje, mnohé další se pak samy podaří vyřešit.
To je má hlavní myšlenka: abyste doporučili nějaké vysoce technologické řešení, musíte nejprve uspořádat základ, a to lze provést právě popsanými nízkotechnologickými řešeními. Pokud začnete s vysoce technologickými nástroji a nevysvětlíte, proč jsou potřebné, obvykle to nekončí ničím dobrým. Jeden z našich klientů používá Azure ML, což je velmi levné a jednoduché řešení. Přibližně 30 % otázek vyřešila sama samoobslužná mašina. A tato věc byla vytvořena operátory, kteří se nezabývali datovou vědou, statistikou nebo matematikou. To je ilustrativní. Náklady na takové řešení jsou minimální.
4. Hacks spolupráce: Haky spolupráce
Čtvrtý archetyp spočívá v tom, že je třeba bojovat proti izolaci. Většina lidí to už ví: izolace vyvolává nepřátelství. Pokud jsou jednotlivé oddělení na svém patře a lidé se navzájem nesetkávají, kromě výtahu, pak je velmi snadné, aby mezi nimi vzniklo nepřátelství. A pokud jsou naopak lidé v jedné místnosti, to okamžitě mizí. Když někdo hodí nějakým obecným obviněním, například že jakékoliv rozhraní nikdy nefunguje – není nic jednoduššího, než takové obvinění dekonstruovat. Programátorům, kteří napsali rozhraní, stačí začít pokládat konkrétní otázky a brzy se ukáže, že například uživatel nástroj jen špatně používá.
Existuje mnoho způsobů, jak překonat izolaci. Jednou mě požádali, abych poradil bance v Austrálii, odmítl jsem to, protože mám dvě děti a manželku. Všechno, čím jsem jim mohl pomoci, byla doporučení na grafické storytellingy. To je něco, co prokazatelně funguje. Další zajímavý způsob – setkání formátu lean coffee. Ve velké organizaci je to skvělá možnost šíření znalostí. Kromě toho lze pořádat interní devopsdays, hackatony a podobně.
5. Coaching Kata
Jak jsem již varoval na začátku, dnes o tom nebudu mluvit. Pokud vás to zajímá, můžete se podívat na .
Existuje také dobrá přednáška na toto téma od Mike Rothera:
6. Market Oriented: tržně orientovaná organizace
Zde jsou různé problémy. Například lidé "I", lidé "T" a lidé "E". Lidé "I" jsou ti, kteří se zabývají pouze jednou věcí. Obvykle existují právě v organizacích s izolovanými odděleními. "T" je, když člověk ví dobře něco jednoho, ale také se vyzná v některých dalších věcech. "E" nebo dokonce "hřeben" znamená, když má člověk mnoho dovedností.
Zde funguje Conwayův zákon (), který lze v maximálně zjednodušené formě shrnout takto: pokud tři týmy pracují na kompilátoru, nakonec vznikne kompilátor ze tří částí. Tudíž pokud je uvnitř organizace vysoká úroveň izolace, pak i Kubernetes, Circuit breaker, API extensibility a další módní věci v této organizaci budou uspořádány tak, jako je samotná organizace. Přesně podle Conwaye, a proti vám, mladí geekové.
Řešení tohoto problému bylo popsáno mnohokrát. Například organizační archetypy popsané Fernandem Fernándezem. Ta problémová architektura, o které jsem právě mluvil, s izolací — to je funkčně orientovaná architektura. Druhý typ — ten horší, matriční architektura, kde se mísí dva jiné. Třetí typ — to, co je pozorováno ve většině startupů, a velké společnosti se také snaží tomuto typu přizpůsobit. Je to organizace orientovaná na trh. Zde dochází k optimalizaci pro dosažení nejrychlejší reakce na požadavky zákazníků. Někdy se to nazývá plochou organizací.
Tuto strukturu mnoho lidí popisuje různě, já mám rád formulaci build/run teams, v Amazonu se tomu říká two pizza teams. V této struktuře se všichni lidé typu „I“ skupinují kolem jednoho servisu a postupně se stávají bližšími typu „T“, a pokud je zaveden správný management, mohou se stát dokonce „E“. První protiargument tady je, že v takové struktuře jsou zbytečné prvky. Proč mít testera v každém oddělení, pokud může být specializované oddělení testerů? Na to odpovídám: zbytečné náklady v tomto případě jsou cenou za to, aby v budoucnu celá organizace se stala typu „E“. V takové struktuře tester postupně poznává sítě, architekturu, projektování atd. Nakonec každý účastník organizace je plně informován o všem, co se v organizaci děje. Pokud chcete vědět, jak tato schéma funguje v průmyslu, přečtěte si .
7. Shift-left auditors: audit v raných fázích cyklu. Dodržování pravidel bezpečnosti na první pohled.
To je, když vaše kroky neprojdou takzvanou zkouškou na pach. Lidé, kteří pro vás pracují, nejsou hloupí. Pokud, jak bylo uvedeno výše, všude uváděli minor/no impact, trvalo to tři roky a nikdo si ničeho nevšiml, tak si všichni dobře uvědomují, že systém nefunguje. Nebo další příklad — poradní výbor pro změny, kam je třeba každou středu podávat zprávy. Pracuje tam skupina lidí (mimochodem, placených ne příliš štědře), kteří by teoreticky měli vědět, jak systém funguje jako celek. A za posledních pět let jste si asi všimli, že naše systémy jsou extrémně složité. A pět nebo šest lidí musí rozhodnout o změně, kterou sami nezavedli a o které nic nevědí.
Samozřejmě, takový přístup nefunguje. Z takových věcí se snažím zbavit, protože tito lidé nechrání systém. Rozhodnutí by měla přijímat sama tým, protože tým by měl nést odpovědnost za něj. Jinak vzniká paradoxní situace, kdy manažer, který v životě nenapsal kód, říká programátorovi, kolik času by mělo trvat napsání kódu. V jedné firmě, ve které jsem pracoval, bylo 7 různých rad, které posuzovaly každou změnu, včetně architektonické rady, rady pro produkty atd. Dokonce existovalo i povinné čekací období, ačkoli mi jeden zaměstnanec řekl, že za deset let práce nikdo nikdy v tomto povinném období neodmítl změny, které tento člověk provedl.
Auditory je třeba zval k sobě, nikoli se jich zbavovat. Řekněte jim, že píšete neměnné binární kontejnery, které, pokud projdou všemi testy, zůstávají neměnné navždy. Řekněte jim, že máte pipeline jako kód a vysvětlete, co to znamená. Ukážte jim následující schéma: neměnný binární soubor pouze pro čtení v kontejneru, který projde všemi testy na zranitelnosti; a dál se k němu nikdo nedotýká — dokonce se nedotýká ani systému, který vytváří pipeline, protože ten je také vytvářen dynamicky. Mám klienty, jako je Capital One, kteří pomocí Vault vytvářejí něco jako blockchain. Auditorovi nemusíte ukazovat „recepty“ z Chefa, stačí ukázat blockchain, z něhož je jasné, co se stalo s ticketem Jira v produkci a kdo je za něj odpovědný.
Podle , vytvořenému v roce 2018 Sonatype, v roce 2017 bylo 87 miliard požadavků na stažení OSS.
Ztráty způsobené zranitelnostmi jsou nesmírně vysoké. A čísla, která nyní vidíte výše, nezahrnují alternativní náklady. Ve zkratce o tom, co je DevSecOps. Hned chci říct, že mě nezajímají debaty o tom, jak úspěšné je toto názvosloví. Podstata je, že pokud byli DevOps velmi úspěšní, je třeba se pokusit přidat k této pipeline bezpečnost.
Příklad takové sekvence:
To není doporučení určitých produktů, i když se mi všechny líbí. Uvedl jsem je jako příklad, abych ukázal, že DevOps, který byl původně založen na paradigmatickém uspořádání v průmyslu, umožňuje automatizovat každý krok práce na produktu.
A není žádný důvod, proč bychom nemohli použít stejný přístup k bezpečnosti.
Výsledek
Na závěr poskytnu několik rad pro DevSecOps. Je potřeba zapojit auditory do procesu vytváření vašich systémů a věnovat čas jejich vzdělávání. S auditory je třeba spolupracovat. Dále je nutné vést naprosto neúprosný boj proti falešným poplachům. I s nejdražším skenerem na zranitelnosti můžete nakonec vytvořit velmi škodlivé zvyky u vašich vývojářů, pokud nevíte, jaký je poměr signálu k šumu. Vývojáři budou přehlceni událostmi a budou je prostě mazat. Pokud jste slyšeli o případu Equifax, přesně to se tam stalo, byl ignorován signál nejvyšší úrovně nebezpečí. Kromě toho je třeba zranitelnosti vysvětlovat tak, aby bylo jasné, jak ovlivňují podnikání. Například, můžete říct, že to je ta samá zranitelnost, jako v příběhu s Equifax. Zranitelnosti v oblasti bezpečnosti by měly být považovány stejně jako jiné softwarové problémy, tj. měly by být zahrnuty do celého procesu DevOps. Jejich řešení by mělo probíhat skrze Jira, Kanban atd. Vývojáři by si neměli myslet, že se o to postará někdo jiný – naopak, měl by se tím zabývat každý. Nakonec je potřebné investovat úsilí do vzdělávání lidí.
Užitečné odkazy
Tady je několik přednášek z konference DevOops, které by vám mohly přijít vhod:
- Sergej Berdnikov, Arťom Kaličkin — Příběh úspěchu, nebo „Dev+DevOps+Ops“ (, )
- Baruch Sadogursky, Leonid Igolnik — DevOps v měřítku: řecká tragédie ve třech aktech (, )
- Alexandr Titov, Kirill Tolkachov —
- Timothy Lister —
Podívejte se na DevOops 2020 Moscow — i tam bylo spoustu zajímavého.
Zdroj: habr.com
