Otázka „jak implementovat devops“ je tu už roky, ale dobrých materiálů není mnoho. Občas se stanete obětí inzerátů nepříliš chytrých poradců, kteří potřebují prodat svůj čas, ať už jakkoli. Někdy jsou to vágní, extrémně obecná slova o tom, jak lodě megakorporací brázdí rozlohy vesmíru. Nabízí se otázka: co nám na tom záleží? Vážený autore, dokážete jasně formulovat své myšlenky v seznamu?
To vše pramení z toho, že se nenashromáždilo mnoho reálné praxe a pochopení výsledků proměn firemní kultury. Změny v kultuře jsou dlouhodobé věci, jejichž výsledky se nedostaví za týden ani za měsíc. Potřebujeme někoho dost starého na to, aby viděl, jak se společnosti v průběhu let budovaly a zkrachovaly.
John Willis - jeden z otců DevOps. John má desítky let zkušeností se spoluprací s velkým množstvím společností. Nedávno si John začal všímat konkrétních vzorců, které se odehrávají při práci s každým z nich. Pomocí těchto archetypů John vede společnosti na skutečné cestě transformace DevOps. Přečtěte si více o těchto archetypech v překladu jeho zprávy z konference DevOops 2018.
O řečníkovi:
Více než 35 let v IT managementu, podílel se na vzniku předchůdce OpenCloud ve společnosti Canonical, podílel se na 10 startupech, z nichž dva byly prodány společnostem Dell a Docker. V současné době je viceprezidentem DevOps a digitálních praktik ve společnosti SJ Technologies.
Další je příběh z Johnova pohledu.
Jmenuji se John Willis a nejsnáze mě najdete na Twitteru, . Mám stejný alias na Gmailu a GitHubu. A najdete k nim videozáznamy mých reportáží a prezentací.
Mám mnoho schůzek s CIO různých velkých společností. Velmi často si stěžují, že nechápou, co je DevOps, a každý, kdo se jim to snaží vysvětlit, mluví o něčem jiném. Další častou stížností je, že DevOps nefunguje, ačkoli se zdá, že režiséři dělají vše tak, jak jim bylo vysvětleno. Hovoříme o velkých společnostech, které jsou staré více než sto let. Po rozhovoru s nimi jsem došel k závěru, že pro mnoho problémů není nejvhodnější špičková technologie, ale spíše relativně low-tech řešení. Celé týdny jsem jen mluvil s lidmi z různých oddělení. To, co vidíte na úplně prvním obrázku v příspěvku, je můj poslední projekt, takhle vypadal pokoj po třech dnech práce.
Co je DevOps?
Opravdu, když se zeptáte 10 různých lidí, dají 10 různých odpovědí. Ale tady je zajímavá věc: všech deset těchto odpovědí bude správných. Zde není špatná odpověď. Byl jsem docela hluboko v DevOps, asi 10 let, a byl jsem prvním Američanem na prvním DevOpsDay. Neříkám, že jsem chytřejší než všichni, kdo se podílejí na DevOps, ale sotva se najde někdo, kdo tomu věnoval tolik úsilí. Věřím, že k DevOps dochází, když se lidský kapitál a technologie spojí. Často zapomínáme na lidský rozměr, ačkoli se hodně bavíme o nejrůznějších kulturách.
Nyní máme spoustu dat, pět let akademického výzkumu, testování teorií v průmyslovém měřítku. Tyto studie nám říkají, že pokud zkombinujete některé vzorce chování v organizační kultuře, můžete dosáhnout 2000x zrychlení. Tomuto zrychlení odpovídá stejné zlepšení stability. Jedná se o kvantitativní měření přínosu, který může DevOps přinést jakékoli společnosti. Před pár lety jsem o DevOps mluvil s generálním ředitelem společnosti z Fortune 5000. Když jsem se připravoval na prezentaci, byl jsem velmi nervózní, protože jsem musel do 5 minut shrnout své letité zkušenosti.
Nakonec jsem dal následující Definice DevOps: Jde o soubor postupů a vzorců, které umožňují transformaci lidského kapitálu na vysoce výkonný organizační kapitál. Příkladem je způsob, jakým Toyota fungovala posledních 50 nebo 60 let.
(Tato schémata jsou dále uváděna nikoli jako referenční materiál, ale jako ilustrace. Jejich obsah se bude u každé nové společnosti lišit. Obrázek si však lze prohlédnout samostatně a zvětšit
Jednou z nejúspěšnějších takových praktik je mapování toku hodnot. Bylo o tom napsáno několik dobrých knih, z nichž nejúspěšnější jsou od Karen Martinové. Ale za poslední rok jsem došel k závěru, že i tento přístup je příliš high-tech. Určitě to má mnoho výhod a hodně jsem to používal. Ale když se vás generální ředitel zeptá, proč jeho společnost nemůže přejít na nové koleje, je příliš brzy mluvit o mapování hodnotového toku. Existuje mnoho mnohem zásadnějších otázek, které je třeba nejprve zodpovědět.
Myslím, že chybou mnoha mých kolegů je to, že jednoduše dají společnosti pětibodový návod a pak se vrátí o šest měsíců později a uvidí, co se stalo. Dokonce i dobré schéma, jako je mapování hodnotového toku, má, řekněme, slepá místa. Po stovkách rozhovorů s řediteli různých společností jsem vytvořil určitý vzorec, který nám umožňuje rozdělit problém na jeho složky a nyní probereme každou z těchto složek v pořadí. Před aplikací jakýchkoli technologických řešení používám tento vzor a v důsledku toho jsou všechny mé stěny pokryty schématy. Nedávno jsem pracoval s podílovým fondem a skončil jsem u 100-150 takových schémat.
Špatná kultura snídá dobré přístupy
Hlavní myšlenka je tato: žádné množství Lean, Agile, SAFE a DevOps nepomůže, pokud je samotná kultura organizace špatná. Je to jako potápět se do hlubin bez potápěčského vybavení nebo pracovat bez rentgenu. Jinými slovy, abychom parafrázovali Druckera a Deminga: špatná organizační kultura pohltí každý dobrý systém, aniž by se jím zadusila.
Chcete-li vyřešit tento hlavní problém, musíte provést následující kroky:
- Zviditelnit veškerou práci: musíte zviditelnit veškerou práci. Ne v tom smyslu, že musí být nutně zobrazen na nějaké obrazovce, ale v tom smyslu, že musí být pozorovatelný.
- Konsolidované systémy řízení práce: systémy řízení je třeba konsolidovat. V problému „kmenových“ znalostí a institucionálních znalostí jsou v 9 případech z 10 úzkým hrdlem lidé. V knize problém byl s jedním jediným člověkem, Brentem, který způsobil, že se projekt o tři roky opožďoval oproti plánu. A na tyhle „Brenty“ narážím všude. K vyřešení těchto úzkých míst používám následující dvě položky na našem seznamu.
- Metodologie teorie omezení: Teorie omezení.
- Hacky pro spolupráci: kolaborační hacky.
- Toyota Kata (): O Toyotě Kata moc mluvit nebudu. V případě zájmu na můj github na téměř každé z těchto témat.
- Tržně orientovaná organizace: tržně orientovaná organizace.
- Auditoři směny doleva: audit v raných fázích cyklu.
S organizací začínám pracovat velmi jednoduše: jdu do společnosti a mluvím se zaměstnanci. Jak vidíte, žádná špičková technologie. Vše, co potřebujete, je něco, na co můžete psát. Shromáždím několik týmů v jedné místnosti a analyzuji, co mi říkají, z pohledu mých 7 archetypů. A pak jim sám dám fix a požádám je, aby na tabuli zapsali vše, co dosud nahlas řekli. Obvykle na těchto typech schůzek je jeden člověk, který si vše zapisuje a v nejlepším případě dokáže zapsat 10 % diskuse. S mou metodou lze toto číslo zvýšit na přibližně 40 %.
(Tento obrázek si můžete prohlédnout samostatně )
Můj přístup vychází z práce Williama Schneidera. ). Tento přístup je založen na myšlence, že každou organizaci lze rozdělit do čtyř čtverců. Toto schéma je pro mě obvykle výsledkem práce se stovkami dalších schémat, které vznikají při analýze organizace. Předpokládejme, že máme organizaci s vysokou úrovní kontroly, ale s nízkou kompetencí. To je krajně nežádoucí varianta: když všichni tahají po lajně, ale nikdo neví, co dělat.
Poněkud lepší možností je varianta s vysokou úrovní kontroly i kompetencí. Pokud je taková společnost zisková, pak možná nepotřebuje DevOps. Nejzajímavější je pracovat s firmou, která má vysokou míru kontroly, nízkou kompetenci a spolupráci, ale zároveň vysokou kulturu (kultivovanost). To znamená, že firma má hodně lidí, kteří tam rádi pracují a fluktuace pracovních sil je nízká.
(Tento obrázek si můžete prohlédnout samostatně )
Zdá se mi, že metody s pevnými pokyny nakonec překážejí dosažení pravdy. Zejména v mapování hodnotového toku existuje mnoho pravidel ohledně toho, 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 nikdo nepotřebuje. Popisuje-li člověk s fixem v ruce na představenstvu reálnou situaci ve firmě, je to nejlepší způsob, jak pochopit stav věcí. Takové informace se k ředitelům nedostanou. V tuto chvíli je hloupé člověka přerušit a říct, že nakreslil nějakou šipku špatně. V této fázi je lepší použít jednoduchá pravidla, například: víceúrovňovou abstrakci lze vytvořit jednoduše pomocí vícebarevných fixů.
Opakuji, žádná špičková technologie. Černá fixa znázorňuje objektivní realitu toho, jak vše funguje. Červenou značkou lidé označují, co se jim na současném stavu nelíbí. Je důležité, aby to napsali oni, ne já. Když jdu po poradě za CIO, nenabízím seznam 10 věcí, které je potřeba opravit. Snažím se najít souvislosti mezi tím, co lidé ve firmě říkají, a existujícími osvědčenými vzory. Nakonec modrá značka naznačuje možná řešení problému.
(Tento obrázek si můžete prohlédnout samostatně )
Příklad tohoto přístupu je nyní znázorněn výše. Na začátku tohoto roku jsem spolupracoval s jednou bankou. Bezpečnostní lidé tam byli přesvědčeni, že by neměli přijít na kontrolu návrhu a požadavků.
(Tento obrázek si můžete prohlédnout samostatně )
A pak jsme mluvili s lidmi z jiných oddělení a ukázalo se, že asi před 8 lety vývojáři softwaru propustili bezpečnostní pracovníky, protože zpomalovali práci. A pak se to změnilo v zákaz, který byl považován za samozřejmost. I když ve skutečnosti žádný zákaz nebyl.
Naše setkání probíhalo extrémně zmateně: asi tři hodiny mi pět různých týmů nedokázalo vysvětlit, co se děje mezi kódem a shromážděním. A to se zdá být nejjednodušší. Většina konzultantů DevOps předem předpokládá, že to už každý ví.
Pak člověk, který měl na starosti IT governance, který čtyři hodiny mlčel, najednou ožil, když jsme se dostali k jeho tématu, a zaměstnal nás na hodně dlouho. Nakonec jsem se ho zeptal, co si o setkání myslí, a nikdy nezapomenu na jeho odpověď. Řekl: „Dřív jsem si myslel, že naše banka má pouze dva způsoby dodávání softwaru, ale teď vím, že jich je pět, a o třech jsem ani nevěděl.“
(Tento obrázek si můžete prohlédnout samostatně )
Poslední setkání v této bance bylo s týmem investičního softwaru. Právě s ní se ukázalo, že psát schémata fixem na list papíru je lepší než na tabuli a dokonce lepší než na smartboard.
Fotografie, které vidíte, ukazují, jak vypadala hotelová konferenční místnost čtvrtý den našeho setkání. A pomocí těchto schémat jsme hledali vzory, tedy archetypy.
Pokládám tedy pracovníkům otázky, oni si odpovědi zapisují fixami tří barev (černá, červená a modrá). Analyzuji jejich odpovědi na archetypy. Nyní si proberme všechny archetypy v pořadí.
1. Zviditelnit veškerou práci: Zviditelnění práce
Většina společností, se kterými pracuji, má velmi vysoké procento neznámé práce. Například to je, když jeden zaměstnanec přijde za druhým a jednoduše požádá, aby něco udělal. Ve velkých organizacích může být 60 % neplánované práce. A až 40 % práce není nijak zdokumentováno. Kdyby to byl Boeing, už bych nikdy v životě nenastoupil do jejich letadla. Pokud je zdokumentována pouze polovina práce, pak není známo, zda je tato práce prováděna správně nebo ne. Všechny ostatní metody se ukážou jako zbytečné – nemá smysl se snažit cokoliv automatizovat, protože těch známých 50 % může být nejsouvislejší a nejpřehlednější část práce, jejíž automatizace nepřinese skvělé výsledky, a všechno nejhorší věci jsou v neviditelné polovině. Bez dokumentace je nemožné najít nejrůznější hacky a skrytou práci, nenacházet úzká hrdla, právě ty „Brenty“, o kterých jsem již mluvil. Existuje nádherná kniha od Dominica DeGrandis . Ona odhaluje pět různých „časových úniků“ (zloději času):
- Příliš mnoho práce v procesu (WIP)
- Neznámé závislosti
- Neplánovaná práce
- Konfliktní priority
- Zanedbaná práce
To je velmi cenný rozbor a kniha je skvělá, ale všechny tyto rady jsou k ničemu, pokud je vidět jen 50 % údajů. Metody navržené Dominikou lze použít, pokud je dosaženo přesnosti nad 90 %. Mluvím o situacích, kdy šéf zadá podřízenému úkol na 15 minut, ale trvá mu to tři dny; ale šéf vlastně neví, že tento podřízený je závislý na čtyřech nebo pěti dalších lidech.
The Phoenix Project je úžasný příběh o projektu, který byl o tři roky později. Jedna z postav kvůli tomu čelí propuštění a setkává se s další postavou, která je prezentována jako jakýsi Sokrates. Pomáhá zjistit, co přesně se pokazilo. Ukáže se, že firma má jednoho správce systému, který se jmenuje Brent a veškerá práce jde tak nějak přes něj. Na jedné z porad je jeden z podřízených dotázán: proč každý půlhodinový úkol trvá týden? Odpovědí je velmi zjednodušená prezentace teorie front a Littleova zákona a v této prezentaci se ukazuje, že při 90% vytížení zabere každá hodina práce 9 hodin. Každý úkol je třeba poslat sedmi dalším lidem, takže z té hodiny bude 63 hodin, 7 krát 9. Chci říct, že abyste mohli použít Littleův zákon nebo jakoukoli složitou teorii řazení do fronty, musíte mít alespoň data.
Když tedy mluvím o viditelnosti, nemyslím tím, že je vše na obrazovce, ale že máte alespoň data. Když tak učiní, často se ukáže, že existuje velmi velké množství neplánované práce, která je nějakým způsobem posílána Brentovi, když to není potřeba. A Brent je skvělý chlap, nikdy neřekne ne, ale nikomu neříká, jak dělá svou práci.
Když je dílo vidět, lze data přehledně roztřídit (to dělá Dominika na fotce), aplikovat abstrakci pěti časových úniků a uplatnit automatizaci.
2. Konsolidujte systémy řízení práce: Řízení úkolů
Archetypy, o kterých mluvím, jsou jakési pyramidy. Pokud je první proveden správně, pak druhý je již jakýmsi doplňkem. Mnohé z nich pro startupy nefungují, je třeba je mít na paměti u větších společností, jako je Fortune 5000. Poslední společnost, pro kterou jsem pracoval, měla 10 ticketingových systémů. Jeden tým měl Remedy, další napsal nějaký svůj vlastní systém, třetí používal Jiru a někteří si vystačili s e-mailem. Stejný problém nastává, pokud má společnost 30 různých potrubí, ale nemám čas probírat všechny takové případy.
Diskutuji s lidmi, jak přesně vstupenky vznikají, co se s nimi děje dál a jak se obcházejí. Nejzajímavější je, že lidé na našich setkáních mluví zcela upřímně. Zeptal jsem se, kolik lidí uvedlo „malý / žádný dopad“ na lístky, které by ve skutečnosti měly mít „velký dopad“. Ukázalo se, že to dělá skoro každý. Nezapojuji se do odsuzování a snažím se všemi možnými způsoby neidentifikovat lidi. Když se mi k něčemu upřímně přiznají, toho člověka neprozradím. Ale když téměř každý obchází systém, znamená to, že veškeré zabezpečení je v podstatě úprava oken. Z dat tohoto systému tedy nelze vyvozovat žádné závěry.
Chcete-li vyřešit problém s jízdenkou, musíte zvolit jeden hlavní systém. Pokud používáte Jiru, nechte si to Jira. Pokud existuje nějaká alternativa, ať je jediná. Pointa by měla být považována za další krok v procesu vývoje. Každá akce musí mít lístek, který musí projít vývojovým workflow. Vstupenky jsou zaslány týmu, který je zveřejní na scénáři a poté za ně převezme odpovědnost.
To platí pro všechna oddělení, včetně infrastruktury a provozu. V tomto případě je možné si vytvořit alespoň nějakou přijatelnou představu o stavu věcí. Jakmile je tento proces zaveden, je najednou snadné určit, kdo je zodpovědný za každou aplikaci. Protože nyní dostáváme ne 50 %, ale 98 % nových služeb. Pokud tento základní proces funguje, zlepšuje se přesnost v celém systému.
Potrubí služeb
To platí opět pouze pro velké korporace. Pokud jste nová společnost v novém oboru, vyhrňte si rukávy a pracujte se svým Travis CI nebo CircleCI. Pokud jde o společnosti Fortune 5000, případ, který se stal v bance, kde jsem pracoval. Přišel k nim Google a ukázaly jim schémata starých systémů IBM. Kluci z Google se zmateně zeptali – kde je k tomu zdrojový kód? Ale neexistuje žádný zdrojový kód, dokonce ani GUI. Toto je realita, se kterou se velké organizace musí vypořádat: 40 let staré bankovní záznamy na starém sálovém počítači. Jeden z mých klientů používá kontejnery Kubernetes se vzory Circuit Breaker a Chaos Monkey, vše pro aplikaci KeyBank. Ale tyto kontejnery se nakonec připojí k aplikaci COBOL.
Kluci z Google byli naprosto přesvědčeni, že vyřeší všechny problémy mého klienta, a pak se začali ptát: co je IBM datapipe? Říká se jim: toto je konektor. K čemu se to připojuje? Do Sperryho systému. A co to je? A tak dále. Na první pohled to vypadá: jaký druh DevOps může existovat? Ale ve skutečnosti je to možné. Existují doručovací systémy, které vám umožňují předat pracovní postup doručovacím týmům.
3. Teorie omezení: Teorie omezení
Přejděme ke třetímu archetypu: institucionální/"kmenové" znalosti. V každé organizaci je zpravidla několik lidí, kteří vše vědí a vše řídí. To jsou ti, kteří jsou v organizaci nejdéle a znají všechna možná řešení.
Když se to objeví na diagramu, konkrétně takové lidi zakroužkuju fixou: například se ukáže, že na všech schůzkách je přítomen jistý Lou. A je mi to jasné: tohle je místní Brent. Když si CIO vybírá mezi mnou v tričku a teniskách a klukem z IBM v obleku, jsem vybrán, protože mohu režisérovi říct věci, které ten druhý neřekne a které by režisér možná nerad slyšel. . Říkám jim, že úzkým hrdlem v jejich společnosti je někdo jménem Fred a někdo jménem Lou. Toto úzké hrdlo je třeba rozvázat, jejich znalosti je třeba od nich tak či onak získat.
K vyřešení tohoto druhu problému mohu například navrhnout použití Slack. Chytrý režisér se zeptá – proč? V takových případech konzultanti DevOps obvykle odpovídají: protože to dělají všichni. Pokud je režisér opravdu chytrý, řekne: no a co. A tady dialog končí. A moje odpověď zní: protože ve společnosti jsou čtyři úzká hrdla, Fred, Lou, Susie a Jane. Aby bylo možné institucionalizovat jejich znalosti, musíme nejprve představit Slacka. Všechny vaše wiki jsou naprostý nesmysl, protože o jejich existenci nikdo neví. Pokud se inženýrský tým podílí na vývoji front-endu a back-endu a každý potřebuje vědět, že se může s dotazy obrátit na front-end vývojový tým nebo tým infrastruktury. Tehdy budou mít pravděpodobně Lou nebo Fred čas připojit se na wiki. A pak se ve Slacku může někdo zeptat, proč, řekněme, nefunguje krok 5. A pak Lou nebo Fred opraví pokyny na wiki. Pokud zavedete tento proces, pak spousta věcí zapadne samo od sebe.
Toto je můj hlavní bod: abyste mohli doporučit jakékoli špičkové technologie, musíte pro ně nejprve udělat pořádek, a to lze provést právě popsanými řešeními s nízkou technologií. Pokud začnete s vysokými technologiemi a nevysvětlíte, proč jsou potřebné, pak to zpravidla nekončí dobře. Jeden z našich klientů používá Azure ML, velmi levné a jednoduché řešení. Zhruba 30 % jejich dotazů zodpověděl samotný samoučící stroj. A tuto věc napsali operátoři, kteří se nezabývali datovou vědou, statistikou nebo matematicou. To je významné. Náklady na takové řešení jsou minimální.
4. Collaboration hacks: Collaboration hacks
Čtvrtým archetypem je potřeba bojovat s izolací. Většina lidí to už ví: izolace plodí nepřátelství. Pokud je každé oddělení ve svém patře a lidé se mezi sebou kromě výtahu nijak nekříží, pak mezi nimi velmi snadno vzniká nevraživost. Ale pokud jsou naopak lidé spolu v jedné místnosti, okamžitě odejde. Když někdo vyhodí nějaké obecné obvinění, třeba takové a takové rozhraní nikdy nefunguje, není nic jednoduššího takové obvinění dekonstruovat. Programátorům, kteří rozhraní napsali, stačí začít klást konkrétní otázky a brzy se ukáže, že například uživatel prostě používal nástroj nesprávně.
Existuje mnoho způsobů, jak překonat izolaci. Jednou mě požádali o konzultaci pro banku v Austrálii, ale odmítl jsem to udělat, protože mám dvě děti a manželku. Jediné, co jsem jim mohl pomoci, bylo doporučit grafické vyprávění. To je něco, co je prokázáno, že funguje. Dalším zajímavým způsobem jsou schůzky s libovou kávou. Ve velké organizaci je to vynikající možnost pro šíření znalostí. Kromě toho můžete provádět interní devopsdays, hackathony a tak dále.
5. Koučování Kata
Jak jsem varoval na samém začátku, dnes o tom nebudu mluvit. Pokud máte zájem, můžete se podívat .
Na toto téma je také dobrý rozhovor od Mika Rothera:
6. Tržně orientovaná: tržně orientovaná organizace
Jsou zde různé problémy. Například „I“ lidé, „T“ lidé a „E“ lidé. „Já“ lidé jsou ti, kteří dělají jen jednu věc. Obvykle existují v organizacích s izolovanými odděleními. "T" je, když je člověk dobrý v jedné věci, ale také dobrý v některých jiných věcech. "E" nebo dokonce "hřeben" je, když má člověk mnoho dovedností.
Zde funguje Conwayův zákon (), což lze v nejzjednodušenější podobě uvést takto: pokud na překladači pracují tři týmy, pak výsledkem bude překladač tří částí. Pokud je tedy v organizaci vysoká míra izolace, pak i Kubernetes, jistič, rozšiřitelnost API a další ozdobné věci v této organizaci budou uspořádány stejně jako organizace samotná. Přísně podle Conwaye a navzdory všem mladým geekům.
Řešení tohoto problému bylo již mnohokrát popsáno. Existují například organizační archetypy, které popsal Fernando Fernandez. Ta problematická architektura, o které jsem právě mluvil, s izolací, je funkčně orientovaná architektura. Druhý typ je nejhorší, maticová architektura, nepořádek ostatních dvou. Třetí je to, co je vidět u většiny startupů a tomuto typu se snaží vyrovnat i velké společnosti. Je to tržně orientovaná organizace. Zde provádíme optimalizaci, abychom dosáhli co nejrychlejší reakce na požadavky zákazníků. Někdy se tomu říká plochá organizace.
Mnoho lidí popisuje tuto strukturu různými způsoby, líbí se mi formulace sestavovat/spouštět týmy, na Amazonu tomu říkají dva týmy na pizzu. V této struktuře jsou všichni lidé typu „I“ seskupeni kolem jedné služby a postupně se přibližují typu „T“, a pokud je na místě správný management, mohou se stát i „E“. Prvním protiargumentem je, že taková struktura má zbytečné prvky. Proč potřebujete testera v každém oddělení, když můžete mít speciální oddělení testerů? Na to odpovídám: dodatečné náklady jsou v tomto případě cenou za to, že se celá organizace v budoucnu stane typem „E“. V této struktuře se tester postupně učí o sítích, architektuře, designu atp. Výsledkem je, že každý účastník organizace si je plně vědom všeho, co se v organizaci děje. Pokud chcete vědět, jak toto schéma funguje v průmyslu, čtěte .
7. Auditoři Shift-left: audit na začátku cyklu. Dodržování bezpečnostních pravidel na displeji
To je, když vaše činy takříkajíc neprojdou pachovým testem. Lidé, kteří pro vás pracují, nejsou hloupí. Pokud, jako ve výše uvedeném příkladu, všude nastavili menší/žádný dopad, toto trvalo tři roky a nikdo si ničeho nevšiml, pak všichni dobře vědí, že systém nefunguje. Nebo jiný příklad – poradní rada pro změny, kde je potřeba podávat zprávy řekněme každou středu. Pracuje tam skupina lidí (mimochodem nepříliš dobře placených), kteří by teoreticky měli vědět, jak systém jako celek funguje. A za posledních pět let jste si pravděpodobně všimli, že naše systémy jsou neuvěřitelně složité. A pět nebo šest lidí se musí rozhodnout o změně, kterou neudělali a o které nic neví.
Tento přístup samozřejmě nefunguje. Musím se takových věcí zbavit, protože tito lidé nechrání systém. Rozhodnutí musí udělat tým sám, protože tým za to musí nést odpovědnost. V opačném případě nastává paradoxní situace, kdy manažer, který v životě nepsal kód, řekne programátorovi, jak dlouho má psaní kódu trvat. Jedna společnost, se kterou jsem pracoval, měla 7 různých desek, které kontrolovaly každou změnu, včetně desky architektury, produktové desky atd. Existovala dokonce povinná karenční doba, i když mi jeden zaměstnanec řekl, že za deset odpracovaných let nikdo nikdy neodmítl změnu touto osobou v této povinné lhůtě.
Auditory je třeba pozvat, aby se k nám připojili, a ne se jich zbavovat. Řekněte jim, že píšete neměnné binární kontejnery, které, pokud projdou všemi testy, zůstanou neměnné navždy. Řekněte jim, že máte kanál jako kód, a vysvětlete, co to znamená. Ukažte jim následující schéma: neměnný binární soubor pouze pro čtení v kontejneru, který projde všemi testy zranitelnosti; a pak se toho nejen nikdo nedotkne, ale ani se nedotkne systému, který vytváří potrubí, protože je také vytvářen dynamicky. Mám klienty Capital One, kteří používají Vault k vytvoření něčeho jako blockchain. Auditor nemusí ukazovat „recepty“ od Chefa, stačí ukázat blockchain, ze kterého je jasné, co se stalo s tiketem Jira ve výrobě a kdo za to může.
Podle , vytvořený v roce 2018 společností Sonatype, v roce 2017 bylo 87 miliard žádostí o stažení OSS.
Ztráty způsobené zranitelností jsou neúměrné. Navíc čísla, která nyní vidíte výše, nezahrnují náklady příležitosti. Co je ve zkratce DevSecOps? Dovolte mi hned říci, že nemám zájem mluvit o tom, jak úspěšné je toto jméno. Jde o to, že protože DevOps byl tak úspěšný, měli bychom se pokusit přidat zabezpečení do tohoto kanálu.
Příklad této sekvence:
Toto není doporučení na konkrétní produkty, i když je mám ráda všechny. Uvedl jsem je jako příklad, abych ukázal, že DevOps, který byl původně založen na organizačním paradigmatu v průmyslu, vám umožňuje automatizovat každou fázi práce na produktu.
A není důvod, proč bychom nemohli zaujmout stejný přístup k bezpečnosti.
Celkový
Na závěr uvedu několik tipů pro DevSecOps. Do procesu vytváření vašich systémů musíte zapojit auditory a věnovat čas jejich vzdělávání. Musíte spolupracovat s auditory. Dále musíte vést naprosto nelítostný boj proti falešným poplachům. I s tím nejdražším nástrojem pro skenování zranitelnosti můžete mezi svými vývojáři vytvořit extrémně špatné návyky, pokud nevíte, jaký je váš poměr signálu k šumu. Vývojáři budou zahlceni událostmi a jednoduše je smažou. Pokud jste slyšeli o příběhu Equifax, přesně to se stalo tam, kde byl ignorován nejvyšší stupeň pohotovosti. Kromě toho je třeba zranitelnosti vysvětlit tak, aby bylo jasné, jaký mají dopad na podnikání. Dalo by se například říci, že se jedná o stejnou zranitelnost jako v příběhu Equifax. S chybami zabezpečení by se mělo zacházet stejně jako s jinými softwarovými problémy, to znamená, že by měly být zahrnuty do celkového procesu DevOps. Musíte s nimi pracovat přes Jira, Kanban atd. Vývojáři by si neměli myslet, že to udělá někdo jiný – naopak by to měli dělat všichni. Nakonec musíte vynaložit energii na školení lidí.
Užitečné odkazy
Zde je několik přednášek z konference DevOops, které by se vám mohly hodit:
- Sergey Berdnikov, Artyom Kalichkin - Příběh úspěchu nebo „Dev+DevOps+Ops“ (, )
- Baruch Sadogursky, Leonid Igolnik - DevOps v měřítku: řecká tragédie o třech jednáních (, )
- Alexander Titov, Kirill Tolkachev -
- Timothy Lister -
Podívejte se na Devoops 2020 Moskva — je tam také spousta zajímavých věcí.
Zdroj: www.habr.com