od 12f-2
Na konci dubna, když White Walkers obléhali Zimohrad, se nám stalo něco zajímavějšího: provedli jsme neobvyklý rollout. V zásadě neustále zavádíme nové funkce do výroby (jako každý jiný). Ale tenhle byl jiný. Rozsah byl takový, že jakékoli potenciální chyby, kterých bychom se mohli dopustit, by ovlivnily všechny naše služby a uživatele. Výsledkem bylo, že jsme vše spustili podle plánu, v plánovaném a ohlášeném období odstávky, bez následků na prodej. Článek je o tom, jak jsme toho dosáhli a jak si to může každý zopakovat doma.
Nebudu nyní popisovat architektonická a technická rozhodnutí, která jsme učinili, ani vyprávět, jak to celé funguje. To jsou spíše poznámky na okraj o tom, jak probíhal jeden z nejtěžších rolloutů, který jsem pozoroval a na kterém jsem byl přímo zapojen. Nenárokuji si úplnost ani technické detaily, snad se objeví v jiném článku.
Pozadí + co je to za funkci?
Budujeme cloudovou platformu (MCS), kde pracuji jako technický ředitel. A nyní je čas přidat do naší platformy IAM (Identity and Access Management), která poskytuje jednotnou správu všech uživatelských účtů, uživatelů, hesel, rolí, služeb a dalších. Proč je potřeba v cloudu, je zřejmá otázka: jsou v něm uloženy všechny uživatelské informace.
Obvykle se takové věci začínají stavět na samém začátku jakýchkoli projektů. Ale historicky byly věci v MCS trochu jiné. MCS byl postaven ve dvou částech:
- Openstack s vlastním autorizačním modulem Keystone,
- Hotbox (úložiště S3) založené na projektu Mail.ru Cloud,
kolem kterých se pak objevily nové služby.
V podstatě se jednalo o dva různé typy oprávnění. Navíc jsme použili několik samostatných vylepšení Mail.ru, například obecné úložiště hesel Mail.ru a také samostatně psaný openid konektor, díky kterému bylo na panelu Horizon poskytováno SSO (end-to-end autorizace). virtuálních strojů (nativní uživatelské rozhraní OpenStack).
Vytvořit IAM pro nás znamenalo propojit vše do jediného systému, zcela našeho vlastního. Zároveň tím neztratíme žádnou funkcionalitu, ale vytvoříme základ pro budoucnost, který nám umožní transparentně ji zdokonalovat bez refaktoringu a škálovat z hlediska funkčnosti. Na začátku měli uživatelé také vzor pro přístup ke službám (centrální RBAC, řízení přístupu na základě rolí) a některé další drobnosti.
Ukázalo se, že tento úkol není triviální: python a perl, několik backendů, nezávisle psané služby, několik vývojových týmů a správců. A co je nejdůležitější, na bojovém produkčním systému jsou tisíce živých uživatelů. To vše se muselo napsat a hlavně odvalit bez obětí na životech.
Co chystáme?
Velmi zhruba řečeno, za cca 4 měsíce jsme připravili následující:
- Vytvořili jsme několik nových démonů, které agregovaly funkce, které dříve fungovaly v různých částech infrastruktury. Zbytek služeb měl předepsaný nový backend v podobě těchto démonů.
- Napsali jsme vlastní centrální úložiště hesel a klíčů, dostupné pro všechny naše služby, které lze libovolně upravovat, jak potřebujeme.
- Napsali jsme 4 nové backendy pro Keystone od nuly (uživatelé, projekty, role, přiřazení rolí), které ve skutečnosti nahradily jeho databázi a nyní fungují jako jediné úložiště pro naše uživatelská hesla.
- Naučili jsme všechny naše služby Openstack, aby pro své zásady přecházely do služby zásad třetích stran, místo abychom tyto zásady četly lokálně z každého serveru (ano, tak Openstack ve výchozím nastavení funguje!)
Taková velká přepracování vyžaduje velké, složité a hlavně synchronní změny v několika systémech napsaných různými vývojovými týmy. Po sestavení by měl celý systém fungovat.
Jak takové změny rozjet a nepodělat to? Nejprve jsme se rozhodli podívat se trochu do budoucnosti.
Strategie zavádění
- Produkt by bylo možné zavést v několika fázích, ale doba vývoje by se prodloužila trojnásobně. Navíc bychom nějakou dobu měli kompletní desynchronizaci dat v databázích. Museli byste si napsat vlastní synchronizační nástroje a žít s více datovými úložišti po dlouhou dobu. A to vytváří širokou škálu rizik.
- Vše, co bylo možné pro uživatele transparentně připravit, bylo provedeno předem. Trvalo to 2 měsíce.
- Dovolili jsme si několik hodin odstávky – pouze pro uživatelské operace k vytvoření a změně zdrojů.
- Pro provoz všech již vytvořených zdrojů byly prostoje nepřijatelné. Plánovali jsme, že během zavádění by zdroje měly fungovat bez prostojů a dopadů na klienty.
- Abychom snížili dopad na naše zákazníky, pokud se něco pokazí, rozhodli jsme se spustit v neděli večer. Méně zákazníků spravuje virtuální stroje v noci.
- Varovali jsme všechny naše klienty, že během období vybraného pro zavedení nebude správa služeb dostupná.
Odbočka: co je zavedení?
<opatrnost, filozofie>
Každý IT specialista může snadno odpovědět, co je to rollout. Nainstalujete CI/CD a vše je automaticky doručeno do obchodu. 🙂
To je samozřejmě pravda. Potíž je však v tom, že s moderními nástroji pro automatizaci doručování kódu se ztrácí pochopení samotného zavádění. Jak při pohledu na moderní dopravu zapomínáte na epičnost vynálezu kola. Vše je tak automatizované, že zavádění často probíhá bez pochopení celého obrazu.
A celý obrázek je takový. Zavádění se skládá ze čtyř hlavních aspektů:
- Dodání kódu včetně úpravy dat. Například jejich migrace.
- Vrácení kódu je schopnost vrátit se, pokud se něco pokazí. Například prostřednictvím vytváření záloh.
- Čas každé operace rollout/rollback. Musíte pochopit načasování jakékoli operace prvních dvou bodů.
- Dotčená funkčnost. Je nutné vyhodnotit jak očekávané pozitivní, tak možné negativní efekty.
Všechny tyto aspekty je třeba vzít v úvahu pro úspěšné zavedení. Obvykle se posuzuje pouze první, nebo v lepším případě druhý bod, a poté je zavedení považováno za úspěšné. Ale třetí a čtvrtý jsou ještě důležitější. Kterému uživateli by se líbilo, kdyby zavedení trvalo 3 hodiny místo minuty? Nebo pokud se během zavádění dotkne něco zbytečného? Nebo výpadek jedné služby povede k nepředvídatelným následkům?
Akt 1..n, příprava na propuštění
Nejprve mě napadlo stručně popsat naše setkání: celý tým, jeho části, hromady diskuzí u kávových bodů, argumenty, testy, brainstormingy. Pak jsem si myslel, že to bude zbytečné. Čtyři měsíce vývoje se vždy skládají z toho, zvláště když nepíšete něco, co lze dodávat neustále, ale jednu velkou funkci pro živý systém. Což se týká všech služeb, ale pro uživatele by se nemělo nic změnit kromě „jednoho tlačítka ve webovém rozhraní“.
Naše chápání toho, jak se zavést, se s každou novou schůzkou měnilo, a to poměrně výrazně. Například jsme se chystali aktualizovat celou naši fakturační databázi. Ale spočítali jsme čas a uvědomili jsme si, že to není možné udělat v rozumném čase zavedení. Skartovat a archivovat fakturační databázi nám trvalo téměř týden navíc. A když očekávaná rychlost rolloutu stále nebyla uspokojivá, objednali jsme další, výkonnější hardware, kam se táhl celý základ. Není to tak, že bychom to nechtěli udělat dříve, ale současná potřeba zavedení nám nezanechala žádné možnosti.
Když jeden z nás pochyboval, že by zavedení mohlo ovlivnit dostupnost našich virtuálních strojů, strávili jsme týden prováděním testů, experimentů, analýzou kódu a dostali jsme jasné pochopení, že se to v naší produkci nestane, a dokonce i ti nejpochybnější lidé souhlasili. s tím.
Mezitím kluci z technické podpory provedli své vlastní nezávislé experimenty, aby sepsali pokyny pro klienty o způsobech připojení, které se měly po rolloutu změnit. Pracovali na uživatelském UX, připravovali návody a poskytovali osobní konzultace.
Automatizovali jsme všechny možné operace zavádění. Každá operace, i ta nejjednodušší, byla naskriptována a neustále probíhaly testy. Dohadovali se o nejlepším způsobu, jak službu vypnout – vynechat démona nebo zablokovat přístup ke službě firewallem. Vytvořili jsme kontrolní seznam týmů pro každou fázi zavádění a neustále jej aktualizovali. Nakreslili jsme a neustále aktualizovali Ganttův diagram pro všechny práce na zavádění s načasováním.
A tak…
Poslední dějství před vyjetím
...je čas vyjet.
Jak se říká, umělecké dílo nelze dokončit, pouze dokončit práci na něm. Musíte vyvinout úsilí vůle, pochopit, že nenajdete vše, ale věřit, že jste učinili všechny rozumné předpoklady, zajistili všechny možné případy, odstranili všechny kritické chyby a všichni účastníci udělali vše, co mohli. Čím více kódu zavedete, tím těžší je se o tom přesvědčit (kromě toho každý chápe, že není možné předvídat všechno).
Rozhodli jsme se, že jsme připraveni zavést, když jsme byli přesvědčeni, že jsme udělali vše pro to, abychom pokryli všechna rizika pro naše uživatele spojená s neočekávanými dopady a prostoji. To znamená, že se může pokazit cokoliv kromě:
- ovlivnit (pro nás posvátnou, nejcennější) uživatelskou infrastrukturu,
- Funkčnost: používání naší služby po zavedení by mělo být stejné jako před ním.
Rolování
Dvě role, 8 nepřekážejí
U všech požadavků od uživatelů trváme odstávku na 7 hodin. V tuto chvíli máme plán zavedení i plán vrácení.
- Samotné spuštění trvá přibližně 3 hodiny.
- 2 hodiny na testování.
- 2 hodiny - rezerva pro případné vrácení změn.
Pro každou akci byl sestaven Ganttův diagram, jak dlouho to trvá, co se děje postupně, co se dělá paralelně.
Část zaváděcího Ganttova diagramu, jedné z prvních verzí (bez paralelního provádění). Nejcennější synchronizační nástroj
Všichni účastníci mají určenou svou roli při zavádění, jaké úkoly dělají a za co jsou zodpovědní. Snažíme se přivést každou fázi k automatizaci, rozvinout ji, vrátit zpět, získat zpětnou vazbu a znovu ji spustit.
Kronika událostí
Takže v neděli 15. dubna ve 29 hodin přišlo do práce 10 lidí. Kromě klíčových účastníků přišli někteří prostě podpořit tým, za což jim patří zvláštní poděkování.
Za zmínku také stojí, že náš klíčový tester je na dovolené. Není možné zavést bez testování, zkoumáme možnosti. Kolegyně souhlasí, že nás otestuje z dovolené, za což se jí dostává nesmírného vděku celého týmu.
00:00. Stop
Zastavíme požadavky uživatelů, vyvěsíme ceduli s nápisem Technická práce. Monitorování křičí, ale vše je normální. Kontrolujeme, že nespadlo nic jiného, než co spadnout mělo. A začínáme pracovat na migraci.
Každý má vytištěný plán rozjezdu bod po bodu, každý ví, kdo co dělá a v kterou chvíli. Po každé akci kontrolujeme načasování, abychom je nepřekročili, a vše jde podle plánu. Ti, kteří se v aktuální fázi zavádění přímo neúčastní, se připravují spuštěním online hračky (Xonotic, kvákadla typu 3), aby nerušili své kolegy. 🙂
02:00. Rozbaleno
Příjemné překvapení - rollout končíme o hodinu dříve, kvůli optimalizaci našich databází a migračních skriptů. Všeobecný výkřik, "vyvaleno!" Všechny nové funkce jsou ve výrobě, ale zatím je můžeme vidět pouze my v rozhraní. Všichni přejdou do testovacího režimu, roztřídí je do skupin a začnou zjišťovat, co se nakonec stalo.
Nedopadlo to moc dobře, uvědomujeme si to po 10 minutách, kdy v projektech členů týmu nic není připojeno a nepracuje. Rychlá synchronizace, vyjádříme své problémy, stanovíme priority, rozdělíme se do týmů a pustíme se do ladění.
02:30. Dva velké problémy versus čtyři oči
Nacházíme dva velké problémy. Uvědomili jsme si, že zákazníci neuvidí některé propojené služby a nastanou problémy s partnerskými účty. Obojí je způsobeno nedokonalými migračními skripty pro některé okrajové případy. Musíme to teď napravit.
Píšeme dotazy, které to zaznamenávají, alespoň 4 očima. Testujeme je během předprodukce, abychom se ujistili, že fungují a nic nerozbijí. Můžeš pokračovat. Zároveň provádíme naše pravidelné integrační testování, které odhaluje několik dalších problémů. Všechny jsou malé, ale také potřebují opravit.
03:00. -2 problémy +2 problémy
Dva předchozí velké problémy byly opraveny a téměř všechny menší také. Všichni, kdo nejsou zaměstnáni v opravách, aktivně pracují na svých účtech a hlásí, co najdou. Určujeme priority, rozdělujeme mezi týmy a nekritické položky necháváme na ráno.
Znovu spustíme testy, objeví se dva nové velké problémy. Ne všechny zásady služeb dorazily správně, takže některé požadavky uživatelů neprojdou autorizací. Plus nový problém s partnerskými účty. Spěcháme se podívat.
03:20. Nouzová synchronizace
Opraven jeden nový problém. Za druhé organizujeme nouzovou synchronizaci. Chápeme, co se děje: předchozí oprava vyřešila jeden problém, ale vytvořila další. Dáváme si pauzu, abychom přišli na to, jak to udělat správně a bez následků.
03:30. Šest očí
Chápeme, jaký by měl být konečný stav základny, aby vše proběhlo v pořádku pro všechny partnery. Napíšeme poptávku se 6 očima, vyrolujeme v předvýrobě, otestujeme, vyrolujeme do výroby.
04:00. Všechno funguje
Všechny testy prošly, nejsou viditelné žádné kritické problémy. Čas od času někomu něco v týmu nefunguje, reagujeme pohotově. Nejčastěji je poplach falešný. Někdy ale něco nedorazí nebo nefunguje samostatná stránka. Sedíme, opravujeme, opravujeme, opravujeme. Samostatný tým spouští poslední velkou funkci – fakturaci.
04:30. Bod odkud není návratu
Blíží se bod, ze kterého není návratu, tedy doba, kdy, pokud se začneme vracet, nestíháme prostoje, které nám byly dány. Problémy jsou s vyúčtováním, které vše ví a eviduje, ale peníze od klientů tvrdošíjně odmítá odepisovat. Na jednotlivých stránkách, akcích a stavech je několik chyb. Hlavní funkčnost funguje, všechny testy projdou úspěšně. Rozhodneme se, že k rolloutu došlo, nebudeme se vracet zpět.
06:00. Otevřeno pro všechny v uživatelském rozhraní
Chyby opraveny. Některé, které uživatele neosloví, jsou ponechány na později. Rozhraní otevíráme všem. Nadále pracujeme na fakturaci, čekáme na zpětnou vazbu od uživatelů a sledujeme výsledky.
07:00. Problémy s načítáním API
Je jasné, že jsme trochu špatně naplánovali zatížení našeho API a testovali jsme toto zatížení, které nemohlo identifikovat problém. Výsledkem je, že ≈5 % požadavků selže. Zmobilizujme se a hledejme důvod.
Fakturace je tvrdohlavá a taky nechce fungovat. Rozhodneme se to odložit na později, abychom změny provedli v klidu. To znamená, že se v něm kumulují všechny zdroje, ale neprocházejí odpisy od klientů. To je samozřejmě problém, ale ve srovnání s obecným zavedením se to zdá nedůležité.
08:00. Opravit API
Zavedli jsme opravu nákladu, poruchy zmizely. Začínáme se vracet domů.
10:00. Všechno
Vše je opraveno. V monitorování je klid a u zákazníků se tým postupně ukládá ke spánku. Vyúčtování zůstává, zítra ho obnovíme.
Pak během dne došlo k zavedení, které opravilo protokoly, upozornění, návratové kódy a přizpůsobení pro některé z našich klientů.
Takže zavedení bylo úspěšné! Mohlo by to být samozřejmě lepší, ale vyvodili jsme závěry, co nám k dokonalosti nestačilo.
Celkem
Během 2 měsíců aktivní přípravy na rollout bylo dokončeno 43 úkolů, které trvaly od několika hodin až po několik dní.
Během zavádění:
- noví a změnění démoni - 5 kusů, nahrazujících 2 monolity;
- změny v databázích - všech 6 našich databází s uživatelskými údaji bylo ovlivněno, byla provedena stahování ze tří starých databází do jedné nové;
- kompletně přepracovaný frontend;
- množství staženého kódu - 33 tisíc řádků nového kódu, ≈ 3 tisíce řádků kódu v testech, ≈ 5 tisíc řádků migračního kódu;
- všechna data jsou nedotčená, nebyl poškozen virtuální stroj jediného zákazníka. 🙂
Dobré postupy pro dobré zavádění
Vedli nás v této těžké situaci. Ale obecně řečeno, je užitečné je dodržovat při každém zavádění. Ale čím složitější je zavádění, tím větší roli hrají.
- První věc, kterou musíte udělat, je pochopit, jak zavedení může nebo ovlivní uživatele. Budou prostoje? Pokud ano, jaká je prostoj? Jak to ovlivní uživatele? Jaké jsou možné nejlepší a nejhorší scénáře? A pokrýt rizika.
- Všechno plánujte. V každé fázi musíte porozumět všem aspektům zavádění:
- doručení kódu;
- vrácení kódu;
- čas každé operace;
- ovlivněná funkčnost.
- Projděte si scénáře, dokud nebudou zřejmé všechny fáze zavádění a také rizika v každém z nich. Pokud máte nějaké pochybnosti, můžete si dát pauzu a zkoumat spornou fázi samostatně.
- Každá fáze může a měla by být vylepšena, pokud pomáhá našim uživatelům. Například sníží prostoje nebo odstraní některá rizika.
- Rollback testování je mnohem důležitější než testování doručení kódu. Je nutné zkontrolovat, že se v důsledku rollbacku systém vrátí do původního stavu, a potvrdit to testy.
- Vše, co lze automatizovat, by mělo být automatizováno. Vše, co nelze zautomatizovat, by mělo být předem napsáno na cheat sheet.
- Zaznamenejte kritérium úspěšnosti. Jaké funkce by měly být dostupné a v jakém čase? Pokud se tak nestane, spusťte plán vrácení.
- A hlavně – lidé. Každý by si měl být vědom toho, co dělá, proč a co závisí na jeho akcích v procesu zavádění.
A jednou větou, s dobrým plánováním a propracováním můžete uvést na trh cokoli, co chcete, aniž by to mělo důsledky pro prodej. I něco, co ovlivní všechny vaše služby ve výrobě.
Zdroj: www.habr.com