DevOps zkušenosti

Včera jsem měl vzácnou příležitost povídat po boku Ladislav Prskavec, Adam Surak a Lukáš Křečan o zkušenostech se zaváděním DevOps. Ačkoliv byly prezentace nezávislé, notovali jsme si ve všech stěžejních bodech bez ohledu na cloud, baremetal, velikost týmu nebo programovací jazyk. V tomhle článku nabízím své vlastní postřehy a zkušenosti okořeněné vstupy od výše uvedených nestorů DevOps.

Moje DevOps poprvé

Pamatuji si docela přesně, kdy jsem se DevOps poprvé setkal. O velikonocích 2011 došlo k masivnímu výpadku AWS regionu na Západním pobřeží USA, na kterém běžela kompletní produkce GoodData. Naší dva provozáci (opsíci) Vlasta Holer, Kosťa strávili non-stop několik dní v pokusech naší produkci migrovat a nebo oživit. Nápad s migrací do regionu na Východním pobřeží USA vypadal elegantně do té chvíle než jsme zjistili, že úplně stejný nápad měla většina firem. Pokud mě paměť neklame, bylo potřeba mašiny nahazovat a uvádět do provozu postupně. Tehdy s minimem automatizace a velmi omezenou podporou od vývojářů, protože to ostatně tehdy nebyla jejich starost. Vzpomínám si, že Vlasta míval na svém pracovním stole — hned vedle meče na taekwondo— obrovskou bílou dózu. Byla plná kofeinových kapslí a během těch velikonoc se povážlivě vyprázdnila. Kluci byli po tom několikadenním nonstop hašení požárů na dně a dokonce snad dali i výpověď. Byl to bod zlomu. Šéf engineeringu Jaroslav Gergic o pár týdnů nebo měsíců později bouchl do stolu a řekl, že budeme dělat DevOps.

Už si přesně nepamatuji jestli to někde vyčetl na blogu, navštívil konferenci nebo kde to sebral a je to asi i nepodstatné, ale rozhodně mu za to patří velký kredit. Tehdy to nebyla móda, ale nutnost, protože GoodData rostl počet zákazníků. Rostl objem a složitost dat s nároky na rychlost a to přímo úměrně sumě, kterou nám byli ochotní platit každý měsíc. Holt v Software As A Service a vaše zákazníky nezajímá, že cloud provider pod vámi má problémy. Vám platí a vy máte problém. SLA mají sílu páky, kterou použijí ve chvíli vyjednávání o obnově kontraktu.

S DevOps se dá začít dobře a nebo špatně. My jsme nezačali dobře nebo úplně šťastně. Řeklo se a od teď bude DevOps. Nikdo s tím neměl zkušenosti a tohle byl rovnou skok po hlavě do neznáma. Pro pro mě a Lukáš Křečan přišel první náraz do zdi, když jsme chtěli dostat MongoDB do produkce. Ptali jsme Jaroslav Gergic jak to máme v tom DevOps udělat a odpovědí bylo, že máme použít Puppet, který jsme tehdy začali používat na automatizaci infrastruktury. Já tehdy trochu rozuměl Jave a byl jsem odkojený na Windows. Jako uživatel samozřejmě. V daný moment jsem měl na Linuxu provozovat databázi a to všechno pomocí Puppetu, o kterém jsem maximálně věděl, že je napsaný v Ruby. Lukáš Křečan na tom nebyl o moc lépe, ale z nějakého vědeckého pojednání si alespoň přečetl co je to CAP. Že budeme provozovat vlastně distribuovaný systém, že bychom měli někam ukládat logy, že bychom to měli monitorovat. To nám došlo mnohem později. Jsou to přesně zkušenosti, které jako vývojáři obvykle nemáte, protože se o celý provoz stará někdo jiný. Jsem dodnes Jaroslav Gergic nesmírně vděčný a velebím ho za to, že jsem tyhle zkušenosti získal.

Dva světy, jedna synergie

Práce vývojářů a provozáků (říkáme jim někdy opsíci, odvozené od operations) jsou dva různé světy. Charakteristika a těžiště vědomostí leží někde jinde.

Opsíci obvykle nemají detailní představu o aplikaci, která běží na jimi provozované infrastruktuře a vývojáři obvykle nemají detailní představu o infrastruktuře, na které běží jimi vyvíjená aplikace.

Opsík

• Linux
• Kernel a jeho vnitřnosti
• Sítě, firewally, bezpečnost
• Monitoring, Nagios, Munin
• Ansible,Salt, Puppet, Chef či jiný nástroj pro config management

Vývojář

• Až na čestné výjimky Windows
• Java, PHP, JavaScript či jiný jazyk
• Design patterns
• Testy
• Relační databáze

Přirozeně vznikají sila (my vývojáři, oni operations) mezi, kterými se vyhloubí pořádně hluboký příkop. DevOps je zasypání toho příkopu a zrušení pomyslných bariér, které činí spolupráci Dev a Ops nefunkční. DevOps o hledání synergie mezi těmito dvěma světy a spojování jejich práce.

DevOps se dá implementovat různě a může nabývat různých podob. Nabízím pár postřehů co se nám osvědčilo a co naopak neosvědčilo.

No ops

Tým bez opsíků je jedna z věcí, kterou zmiňoval Lukáš Křečan jako výhodu Liftaga, dokonce svojí prezentaci nazval extrémní DevOps. V Zonky jsme před pár lety začínali podobně, infrastrukturu (VMka, jejich zálohu a základní monitoring) nám provozoval SiteOne a o zbytek se staralo těch pět vývojářů, které jsme měli. S růstem firmy se to ukázalo neudržitelné a přišel první operations člověk. Pokud se podíváte na charakteristiku obou rolí (Dev a Ops) zjistíte, že pro model No ops, byste museli mít extrémně zkušené vývojáře s hromadou operations zkušeností a i tak se to dá provozovat jenom do určité velikosti firmy, dat, zákazníků, vývojářů, infrastruktury či jiného zdroje operations práce. I s přechodem do cloudu — jsme AWS shop — máme velké množství práce kolem automatizace, monitoringu a infrastruktury, která by nám ubírala z vývojářské kapacity.

S Adam Surak jsme se shodli, že najít vývojáře se operations zkušenostmi je dost složité. Zatímco Adam se ptá během interview na to jak zhruba probíhá navázání HTTP spojení a co všechno se děje, já si operations zkušenosti testuji jednoduchou otázkou na to jak dostat telemetrii ze zdánlivě zaseklé JVM. Pokud už vývojář ví, že existuje něco jako thread dump, chce ho vyvolávat přes GUI nástroje, které nemá typicky k dispozici. O tom, že se existuje QUIT signál a kde hledat jeho výstup netuší více než 5% vývojářů, kteří mi kdy prošli rukami. V případě provozu distribuovaných systému, sdíleného stavu a různých split brain scénářů a konzistence vs. dostupnosti dat možná 1%.

Lukáš Křečan i Ladislav Prskavec poukázali na to, a já s nimi v podstatě souhlasím, že No ops funguje ve chvíli kdy si můžete dovolit nakoupít část infrastruktury jako službu. V Liftagu a Apiary takhle kupují MongoDB, RabbitMQ tedy distribuované systémy, které si opravdu nechcete provozovat sami, protože vás to neživí. Všichni jsme se shodli na tom, že budovat infrastrukturu, kterou můžete nakoupit za mrzký peníz, nedává žádný smysl. Padla celá řada služeb, které se prolínaly všemi firmami, namátkou PagerDuty, LaunchDarkly, Splunk/Papertrail, Datadog atd.

Všichni dělají všechno

Tohle je velice nešťastné. Když na skvělé vývojáře, ale nezkušené opsíky, hodíte všechnu tu těžkou operations práci, povede to jenom k jejich frustraci. DevOps rozhodně není o tom, že všichni dělají všechno. V GoodData jsme měli produktové týmy či týmy zodpovědné za služby, které měly dedikované ops inženýry. Ladislav Prskavec poukazoval na rozdílná charakter práce na ops úkolech a produktovým vývojem. Produktový vývoj je časově omezený, snažíme se vytvářet přibližně stejně složité story. V případě operations práce nedává úplně smysl sledovat přísně Scrumový postup, hlavně co se týká timeboxingu, a více to odpovídá Kanbanu. Naopak v Liftagu se daří operations práci dávat do sprintu, kdy si nechávají den až dva volnou kapacitu v každém sprintu. V Zonky máme dedikovanou kapacitu ve formě speciálního týmu, který řeší složité technické problémy např. přepis na Spring boot a zároveň SRE tým, který se stará o infrastrukturu.

Vývojáři na produkci

Bez překvapení jsme se shodli na nutnosti, aby vývojáři alespoň jednou za čas drželi pohotovost. Hlavní přínos spočívá v změně myšlení z “není to můj problém” na “už je to i můj problém, když mě ve dvě hodiny ráno budí pohotovost”. Vývojáři potom víc dbají na všechny aspekty nutné k lepší operovatelnosti a vhledu do aplikace, počínaje logováním, toolingem a nebo monitoringem. Adam Surak zmiňoval možnost vynechání z pohotovosti pokud má daný člověk například problém se spaním atp. S tím se dá jenom souhlasit. Na pohotovost je nutné vývojáře dobře připravit a vytrénovat. V Apiary to trvá 6–8 týdnů s tím, že by měla vždy existovat možnost eskalace na někoho zkušenějšího. Ne nutně musí člověk začínat v zákopu bojové linie, ale postupně se tam dopracovat.

V Apiary mají Runbooky, v Zonky máme Cookbooky, jedná se o sadu příkazů či návodů co dělat v případě konkrétního alertu nebo operační činnosti.

V Zonky je vývojář připraven přibližně po šesti měsících. Část operations práce je možné vyzkoušet na neprodukčních prostředích, které vývojáři podporují ve chvíli kdy plní roli takzvaného zametacího týmu. Vývojáři s pohotovostí pro daný týden (u nás trvá od pondělí 9:00 do pondělí 9:00) provádí pravidelné čtvrteční releasy. Ty si mohou nacvičit nanečisto na prostředí, které maximálně odpovídá produkci.

Posedlost daty

Ladislav Prskavec zmiňoval, že jeho SRE tým v Apiary měří například flakky testy. Prakticky všichni měříme trvání build a testovací fáze. Využití metrik pro odhalení manuální či neefektivní práce je standardem stejně tak velký důraz na automatizaci. Pokud nějaký manuální krok zabere pět minut, děláte ho pětkrát denně čtyři dny v týdnu, hodí vám to 100 minut za týden.

Ukázka Zonky monitorovacího reportu, který popsal Tomáš Vaněk v článku 500% zrychlení build procesu.

Řekl bych, že tahle lenost, která vás vede k automatizaci je něco co do DevOps přinášejí vývojáři.

Kultura a další střípky

Všichni jsme se shodli na nutnosti dělat post mortem po každém produkčním incidentu s cílem najít příčinu problému a definovat konkrétní kroky, které povedou k jeho úplnému odstranění či alespoň částečnému vyřešení.

Hodně se akcentovala kultura bezpečného prostředí, aby nebyl člověk paralyzovaný pocitem, že něco pokazí. Adam Surak zmiňoval, že během prvního měsíce v Algolia způsobil výpadek na největším zákazníkovi, které stál firmu mnohem více než byl jeho plat. Ten měsíc se mu to povedlo hned dvakrát.

Ve všech firmách testujeme na zákaznících. V Zonky používáme anonymizovanou produkční databázi, kterou automaticky nahráváme každý týden na testovací prostředí. Ušetří to spoustu práce s přípravou testovacích dat pro edge cases. Dále tuto databázi využíváme pro regresní testy např. během optimalizace napočítávání investorských poplatků. Liftago, Apiary i Zonky používá LaunchDarkly pro fázované rollouty, Algolia má vlastní řešení. Chyby byly, jsou, a budou a vy je často potkáte až na produkci. Sebelepší prevence nenahradí schopnost přežití, více si můžete přečíst v mém starším článku Neznámé neznámo.

Adam Surak měl celkem tři velmi tři trefné poznámky s ohledem na zavádění DevOps.

• Google řeší problémy Googlu. Až budete mít problémy Googlu, řešte to jako Google. Do té doby se koukejte jak to řeší firmy podobné té vaší. Ladislav Prskavec zmiňoval knihu Seeking SRE, ve které jsou popsané zkušenosti menších firem. Já osobně bych ještě vyzdvihl knihu Release It! Second edition.
• 90% automatizace je lepší než žádná automatizace. Lidé se často nepochopitelně zaseknou na tom, že když nedokážou danou věc zautomatizovat úplně, neudělají raději nic. Zavádění DevOps je sám o sobě iterativní proces, kdy se neustále učíme jak se zlepšit a být efektivnější s přihlédnutím k ceně, kterou za to zaplatíme.
• Chaos engineering dělejte až budete připravení. Do té doby stačí zkusit poslat pár inženýrů na dovolenou a sledovat co to udělá s vaší dostupností. Pod to se mohu podepsat a přikládám na tohle téma skvělý článek The Limitations of Chaos Engineering.

Během hodiny a půl toho zaznělo z našich úst mnohem více, proto doporučuji shlédnout videa na SlidesLive CZJUG kanále, která budou k dispozici na konci května. Pokud vás cokoliv ze Zonky DevOps zaujalo, rád vám o tom já nebo kolegové řekneme více.