o 12f-2
Na konci apríla, keď White Walkers obliehali Zimohrad, sa nám stalo niečo zaujímavejšie: urobili sme nezvyčajný rollout. V zásade neustále zavádzame nové funkcie do výroby (ako každý iný). Ale tento bol iný. Rozsah bol taký, že akékoľvek potenciálne chyby, ktoré by sme mohli urobiť, by ovplyvnili všetky naše služby a používateľov. Vďaka tomu sme všetko rozbehli podľa plánu, v rámci plánovaného a ohláseného odstávkového obdobia, bez následkov na predaj. Článok je o tom, ako sme to dosiahli a ako si to môže každý zopakovať aj doma.
Nebudem teraz popisovať architektonické a technické rozhodnutia, ktoré sme urobili, ani rozprávať, ako to celé funguje. Sú to skôr poznámky na okraj o tom, ako prebiehal jeden z najťažších rolloutov, ktorý som pozoroval a na ktorom som sa priamo podieľal. Nenárokujem si úplnosť ani technické detaily, možno sa objavia v inom článku.
Pozadie + aká je to funkcia?
Budujeme cloudovú platformu (MCS), kde pôsobím ako technický riaditeľ. A teraz je čas pridať do našej platformy IAM (Identity and Access Management), ktorá poskytuje jednotnú správu všetkých používateľských účtov, používateľov, hesiel, rolí, služieb a ďalších. Prečo je to potrebné v cloude, je zrejmá otázka: všetky informácie o používateľovi sú uložené v ňom.
Zvyčajne sa takéto veci začínajú stavať na samom začiatku akýchkoľvek projektov. Ale historicky boli veci v MCS trochu iné. MCS bol postavený v dvoch častiach:
- Openstack s vlastným autorizačným modulom Keystone,
- Hotbox (úložisko S3) založené na projekte Mail.ru Cloud,
okolo ktorých sa potom objavili nové služby.
V podstate išlo o dva rôzne typy autorizácie. Navyše sme použili niekoľko samostatných vývojov na Mail.ru, napríklad všeobecné úložisko hesiel Mail.ru, ako aj samostatne písaný openid konektor, vďaka ktorému bolo na paneli Horizon poskytnuté SSO (end-to-end autorizácia). virtuálnych strojov (natívne používateľské rozhranie OpenStack).
Vytvoriť IAM pre nás znamenalo spojiť to všetko do jediného systému, úplne nášho vlastného. Zároveň neprídeme o žiadnu funkcionalitu, ale vytvoríme základ pre budúcnosť, ktorý nám umožní transparentne ju vylepšiť bez refaktorovania a škálovať z hľadiska funkčnosti. Na začiatku mali používatelia tiež vzor pre prístup k službám (centrálny RBAC, riadenie prístupu na základe rolí) a niektoré ďalšie drobnosti.
Ukázalo sa, že táto úloha nie je triviálna: python a perl, niekoľko backendov, nezávisle písané služby, niekoľko vývojových tímov a správcov. A čo je najdôležitejšie, na bojovom produkčnom systéme sú tisíce živých používateľov. Toto všetko bolo treba napísať a hlavne odvaliť bez obetí.
Čo sa chystáme spustiť?
Veľmi zhruba povedané, za približne 4 mesiace sme pripravili nasledovné:
- Vytvorili sme niekoľko nových démonov, ktoré agregovali funkcie, ktoré predtým fungovali v rôznych častiach infraštruktúry. Zvyšným službám bol predpísaný nový backend v podobe týchto démonov.
- Napísali sme vlastné centrálne úložisko hesiel a kľúčov, dostupné pre všetky naše služby, ktoré je možné ľubovoľne upravovať podľa potreby.
- Napísali sme 4 nové backendy pre Keystone od nuly (používatelia, projekty, roly, priradenia rolí), ktoré v skutočnosti nahradili jeho databázu a teraz fungujú ako jediné úložisko pre naše používateľské heslá.
- Naučili sme všetky naše služby Openstack, aby pre svoje zásady využívali služby zásad tretích strán namiesto čítania týchto zásad lokálne z každého servera (áno, tak Openstack štandardne funguje!)
Takéto veľké prepracovanie si vyžaduje veľké, zložité a hlavne synchrónne zmeny vo viacerých systémoch napísaných rôznymi vývojovými tímami. Po zložení by mal celý systém fungovať.
Ako rozbehnúť takéto zmeny a nepokaziť to? Najprv sme sa rozhodli pozrieť trochu do budúcnosti.
Stratégia zavádzania
- Produkt by bolo možné uviesť na trh v niekoľkých fázach, čo by však trojnásobne predĺžilo čas vývoja. Navyše, nejaký čas by sme mali úplnú desynchronizáciu dát v databázach. Museli by ste si napísať vlastné synchronizačné nástroje a dlho žiť s viacerými dátovými úložiskami. A to vytvára širokú škálu rizík.
- Všetko, čo sa dalo pre užívateľa transparentne pripraviť, bolo urobené vopred. Trvalo to 2 mesiace.
- Dovolili sme si niekoľkohodinový výpadok – iba na vytváranie a zmenu zdrojov používateľských operácií.
- Pre prevádzku všetkých už vytvorených zdrojov boli prestoje neprijateľné. Plánovali sme, že počas zavádzania by zdroje mali fungovať bez výpadkov a vplyvu na klientov.
- Aby sme znížili dopad na našich zákazníkov, ak sa niečo pokazí, rozhodli sme sa spustiť v nedeľu večer. Menej zákazníkov spravuje virtuálne stroje v noci.
- Všetkých našich klientov sme upozornili, že počas obdobia vybraného na zavádzanie bude správa služieb nedostupná.
Odbočka: čo je zavádzanie?
<opatrnosť, filozofia>
Každý IT špecialista môže ľahko odpovedať, čo je rollout. Nainštalujete CI/CD a všetko sa automaticky doručí do obchodu. 🙂
Samozrejme je to pravda. Problémom však je, že s modernými nástrojmi na automatizáciu doručovania kódu sa stráca pochopenie samotného zavádzania. Ako zabudnete na epickosť vynálezu kolesa pri pohľade na modernú dopravu. Všetko je tak automatizované, že zavádzanie sa často vykonáva bez pochopenia celého obrazu.
A celý obrázok je takýto. Zavedenie pozostáva zo štyroch hlavných aspektov:
- Dodanie kódu vrátane úpravy údajov. Napríklad ich migrácie.
- Vrátenie kódu je schopnosť vrátiť sa späť, ak sa niečo pokazí. Napríklad prostredníctvom vytvárania záloh.
- Čas každej operácie zavedenia/vrátenia späť. Musíte pochopiť načasovanie akejkoľvek operácie prvých dvoch bodov.
- Ovplyvnená funkčnosť. Je potrebné vyhodnotiť očakávané pozitívne aj možné negatívne vplyvy.
Všetky tieto aspekty je potrebné vziať do úvahy pre úspešné zavedenie. Zvyčajne sa posudzuje iba prvý alebo v lepšom prípade druhý bod a potom sa zavedenie považuje za úspešné. Ale tretí a štvrtý sú ešte dôležitejšie. Ktorému používateľovi by sa páčilo, keby zavedenie trvalo 3 hodiny namiesto minúty? Alebo ak sa počas zavádzania ovplyvní niečo zbytočné? Alebo výpadok jednej služby povedie k nepredvídateľným následkom?
Akt 1..n, príprava na prepustenie
Najprv ma napadlo stručne opísať naše stretnutia: celý tím, jeho časti, kopy diskusií pri kávičkách, hádky, testy, brainstormingy. Potom som si myslel, že to bude zbytočné. Štyri mesiace vývoja vždy pozostávajú z toho, najmä keď nepíšete niečo, čo sa dá neustále dodávať, ale jednu veľkú funkciu pre živý systém. Čo ovplyvňuje všetky služby, ale pre používateľov by sa nemalo zmeniť nič okrem „jedného tlačidla vo webovom rozhraní“.
Naše chápanie toho, ako začať, sa s každým novým stretnutím zmenilo, a to dosť výrazne. Napríklad sme sa chystali aktualizovať celú databázu fakturácií. Vypočítali sme však čas a uvedomili sme si, že to nebolo možné urobiť v primeranom čase. Trvalo nám takmer týždeň navyše, kým sme skartovali a archivovali fakturačnú databázu. A keď očakávaná rýchlosť rolloutu stále nebola uspokojivá, objednali sme ďalší, výkonnejší hardvér, kde sa ťahal celý základ. Nie je to tak, že by sme to nechceli urobiť skôr, ale aktuálna potreba zavedenia nám nedala žiadne možnosti.
Keď jeden z nás pochyboval, že by zavedenie mohlo ovplyvniť dostupnosť našich virtuálnych strojov, strávili sme týždeň vykonávaním testov, experimentov, analýzy kódu a dostali sme jasné pochopenie, že sa to v našej produkcii nestane, a dokonca aj tí najpochybnejší ľudia súhlasili. s tým.
Chlapci z technickej podpory medzitým uskutočnili svoje vlastné nezávislé experimenty s cieľom napísať pokyny pre klientov o spôsoboch pripojenia, ktoré sa mali po zavedení zmeniť. Pracovali na používateľskom UX, pripravovali návody a poskytovali osobné konzultácie.
Zautomatizovali sme všetky možné operácie zavádzania. Každá operácia, aj tá najjednoduchšia, bola naskriptovaná a neustále prebiehali testy. Dohadovali sa o najlepšom spôsobe vypnutia služby – vynechať démona alebo zablokovať prístup k službe firewallom. Vytvorili sme kontrolný zoznam tímov pre každú fázu zavádzania a neustále sme ho aktualizovali. Nakreslili sme a neustále aktualizovali Ganttov diagram pre všetky práce na zavádzaní s načasovaním.
A tak…
Záverečné dejstvo pred spustením
...je čas vyraziť.
Ako sa hovorí, umelecké dielo sa nedá dokončiť, iba dokončiť. Musíte sa snažiť vôľou, chápať, že nenájdete všetko, ale veriť, že ste urobili všetky rozumné predpoklady, zabezpečili všetky možné prípady, odstránili všetky kritické chyby a všetci účastníci urobili všetko, čo mohli. Čím viac kódu zavediete, tým ťažšie je presvedčiť sa o tom (okrem toho každý chápe, že nie je možné predvídať všetko).
Rozhodli sme sa, že sme pripravení spustiť, keď sme boli presvedčení, že sme urobili všetko, čo bolo v našich silách, aby sme pokryli všetky riziká pre našich používateľov spojené s neočakávanými vplyvmi a prestojmi. To znamená, že sa môže pokaziť čokoľvek okrem:
- Ovplyvniť (pre nás posvätnú, najcennejšiu) používateľskú infraštruktúru,
- Funkčnosť: používanie našej služby po zavedení by malo byť rovnaké ako pred ním.
Vyvaľovanie
Dva rolky, 8 neprekážajú
Odstávky pre všetky žiadosti od používateľov trváme 7 hodín. V súčasnosti máme plán zavádzania aj plán vrátenia.
- Samotné spustenie trvá približne 3 hodiny.
- 2 hodiny na testovanie.
- 2 hodiny - rezerva na prípadné vrátenie zmien.
Pre každú akciu bol zostavený Ganttov diagram, ako dlho to trvá, čo sa deje postupne, čo sa robí paralelne.
Kúsok zavedeného Ganttovho diagramu, jednej z prvých verzií (bez paralelného vykonávania). Najhodnotnejší synchronizačný nástroj
Všetci účastníci majú určenú svoju úlohu pri zavádzaní, aké úlohy vykonávajú a za čo sú zodpovední. Snažíme sa priviesť každú fázu k automatizácii, rozvinúť ju, vrátiť späť, získať spätnú väzbu a znova ju spustiť.
Kronika udalostí
V nedeľu 15. apríla o 29. hodine teda prišlo do práce 10 ľudí. Okrem kľúčových účastníkov prišli niektorí jednoducho podporiť tím, za čo im patrí mimoriadna vďaka.
Za zmienku tiež stojí, že náš kľúčový tester je na dovolenke. Nie je možné spustiť bez testovania, skúmame možnosti. Kolegyňa súhlasí s tým, že nás otestuje z dovolenky, za čo jej patrí nesmierna vďaka od celého kolektívu.
00:00. Stop
Zastavíme požiadavky používateľov, zavesíme tabuľu s nápisom Technická práca. Monitorovanie kričí, ale všetko je normálne. Kontrolujeme, či nespadlo nič iné, ako spadnúť malo. A začíname pracovať na migrácii.
Každý má vytlačený plán zavádzania bod po bode, každý vie, kto čo robí a v akom momente. Po každej akcii skontrolujeme načasovanie, aby sme sa uistili, že ich neprekročíme, a všetko ide podľa plánu. Tí, ktorí sa v aktuálnej fáze nezúčastňujú priamo na zavádzaní, sa pripravujú spustením online hračky (Xonotic, kvákadlá typu 3), aby nerušili svojich kolegov. 🙂
02:00. Vyrolovať
Príjemné prekvapenie - zavádzanie končíme o hodinu skôr, kvôli optimalizácii našich databáz a migračných skriptov. Všeobecný výkrik, "vyvalené!" Všetky nové funkcie sú vo výrobe, no zatiaľ ich môžeme vidieť iba my v rozhraní. Každý prejde do testovacieho režimu, roztriedi ich do skupín a začne vidieť, čo sa nakoniec stalo.
Nedopadlo to veľmi dobre, uvedomujeme si to po 10 minútach, keď v projektoch členov tímu nič nie je prepojené a nepracuje. Rýchla synchronizácia, vyjadrujeme svoje problémy, stanovujeme priority, rozdeľujeme sa do tímov a ideme do ladenia.
02:30. Dva veľké problémy verzus štyri oči
Nájdeme dva veľké problémy. Uvedomili sme si, že zákazníci neuvidia niektoré prepojené služby a nastanú problémy s partnerskými účtami. Obe sú spôsobené nedokonalými migračnými skriptami pre niektoré okrajové prípady. Musíme to teraz napraviť.
Dopyty, ktoré to zaznamenávajú, píšeme aspoň 4 očami. Testujeme ich počas predprodukcie, aby sme sa uistili, že fungujú a nič nepokazia. Môžete sa valiť ďalej. Zároveň spúšťame naše pravidelné integračné testovanie, ktoré odhaľuje niekoľko ďalších problémov. Všetky sú malé, ale tiež ich treba opraviť.
03:00. -2 problémy + 2 problémy
Dva predchádzajúce veľké problémy boli opravené a tiež takmer všetky menšie. Všetci, ktorí nie sú obsadení v opravách, aktívne pracujú na svojich účtoch a hlásia, čo našli. Určujeme priority, rozdeľujeme medzi tímy a nekritické položky nechávame na ráno.
Spustíme testy znova, objavia dva nové veľké problémy. Nie všetky pravidlá služby prišli správne, takže niektoré požiadavky používateľov neprejdú autorizáciou. Plus nový problém s partnerskými účtami. Ponáhľajme sa pozrieť.
03:20. Núdzová synchronizácia
Opravený jeden nový problém. Po druhé organizujeme núdzovú synchronizáciu. Chápeme, čo sa deje: predchádzajúca oprava vyriešila jeden problém, no vytvorila ďalší. Dávame si prestávku, aby sme prišli na to, ako to urobiť správne a bez následkov.
03:30. Šesť očí
Rozumieme, aký by mal byť konečný stav základne, aby všetko prebehlo v poriadku pre všetkých partnerov. Napíšeme požiadavku so 6 očami, vyvaľkáme v predvýrobe, otestujeme, vyvaľkáme do výroby.
04:00. Všetko funguje
Všetky testy prešli, nie sú viditeľné žiadne kritické problémy. Z času na čas niekomu v tíme niečo nefunguje, reagujeme pohotovo. Najčastejšie je poplach falošný. Niekedy však niečo nedorazí alebo nefunguje samostatná stránka. Sedíme, opravujeme, opravujeme, opravujeme. Samostatný tím spúšťa poslednú veľkú funkciu – fakturáciu.
04:30. Bod z ktorého niet návratu
Blíži sa bod, odkiaľ niet návratu, teda čas, keď, ak sa začneme vracať späť, nesplníme prestoje, ktoré nám boli dané. Problémy sú s účtovaním, ktoré všetko vie a eviduje, no peniaze od klientov tvrdohlavo odmieta odpisovať. Na jednotlivých stránkach, akciách a stavoch je niekoľko chýb. Hlavná funkčnosť funguje, všetky testy úspešne prejdú. Rozhodneme sa, že rollout prebehol, nebudeme sa vracať späť.
06:00. Otvorené pre všetkých v používateľskom rozhraní
Chyby opravené. Niektoré, ktoré používateľov neoslovia, si nechajú na neskôr. Rozhranie otvárame všetkým. Naďalej pracujeme na fakturácii, čakáme na spätnú väzbu od používateľov a výsledky monitorovania.
07:00. Problémy s načítaním API
Je zrejmé, že sme mierne nesprávne naplánovali zaťaženie nášho API a testovali sme toto zaťaženie, ktoré nedokázalo identifikovať problém. Výsledkom je, že ≈5 % žiadostí zlyhá. Zmobilizujme sa a hľadajme príčinu.
Fakturácia je tvrdohlavá a tiež nechce pracovať. Rozhodneme sa to odložiť na neskôr, aby sme zmeny vykonali pokojne. To znamená, že sú v ňom nahromadené všetky zdroje, ale odpisy od klientov neprechádzajú. Samozrejme, je to problém, ale v porovnaní so všeobecným zavádzaním sa to zdá nedôležité.
08:00. Opraviť API
Zaviedli sme opravu nákladu, poruchy zmizli. Začíname ísť domov.
10:00. Všetky
Všetko je opravené. V monitorovaní je ticho a u zákazníkov tím postupne zaspáva. Vyúčtovanie zostáva, zajtra ho obnovíme.
Potom počas dňa došlo k zavedeniu, ktoré opravilo protokoly, upozornenia, návratové kódy a prispôsobenia pre niektorých našich klientov.
Takže zavedenie bolo úspešné! Mohlo by to byť, samozrejme, lepšie, ale vyvodili sme závery, čo nám na dokonalosť nestačilo.
Celkom
Počas 2 mesiacov aktívnej prípravy na rollout bolo dokončených 43 úloh v trvaní od niekoľkých hodín až po niekoľko dní.
Počas zavádzania:
- noví a zmenení démoni - 5 kusov, nahradzujúcich 2 monolity;
- zmeny v rámci databáz - bolo ovplyvnených všetkých 6 našich databáz s používateľskými údajmi, boli stiahnuté z troch starých databáz do jednej novej;
- kompletne prerobený frontend;
- množstvo stiahnutého kódu - 33 tisíc riadkov nového kódu, ≈ 3 tisíc riadkov kódu v testoch, ≈ 5 tisíc riadkov migračného kódu;
- všetky údaje sú nedotknuté, virtuálny stroj jedného zákazníka nebol poškodený. 🙂
Osvedčené postupy pre dobré zavádzanie
Usmernili nás v tejto ťažkej situácii. Vo všeobecnosti je však užitočné ich dodržiavať počas akéhokoľvek zavádzania. Ale čím je zavádzanie zložitejšie, tým väčšiu úlohu zohrávajú.
- Prvá vec, ktorú musíte urobiť, je pochopiť, ako zavedenie môže alebo ovplyvní používateľov. Budú prestoje? Ak áno, aký je prestoj? Ako to ovplyvní používateľov? Aké sú možné najlepšie a najhoršie scenáre? A pokryť riziká.
- Všetko si naplánujte. V každej fáze musíte pochopiť všetky aspekty zavádzania:
- doručenie kódu;
- vrátenie kódu;
- čas každej operácie;
- ovplyvnená funkčnosť.
- Prehrajte si scenáre, kým nebudú zrejmé všetky fázy zavádzania, ako aj riziká v každom z nich. Ak máte nejaké pochybnosti, môžete si dať prestávku a preskúmať spornú fázu samostatne.
- Každá fáza môže a mala by sa zlepšiť, ak pomôže našim používateľom. Napríklad zníži prestoje alebo odstráni niektoré riziká.
- Testovanie vrátenia je oveľa dôležitejšie ako testovanie doručenia kódu. Je potrebné skontrolovať, či sa v dôsledku rollbacku systém vráti do pôvodného stavu a potvrdiť to testami.
- Všetko, čo sa dá automatizovať, by sa malo automatizovať. Všetko, čo sa nedá zautomatizovať, by malo byť vopred napísané na cheat sheet.
- Zaznamenajte kritérium úspešnosti. Aké funkcie by mali byť dostupné a v akom čase? Ak sa tak nestane, spustite plán vrátenia.
- A čo je najdôležitejšie – ľudia. Každý by si mal byť vedomý toho, čo robí, prečo a čo závisí od jeho činností v procese zavádzania.
A jednou vetou, pri dobrom plánovaní a vypracovaní môžete zaviesť čokoľvek, čo chcete, bez následkov na predaj. Dokonca aj niečo, čo ovplyvní všetky vaše služby vo výrobe.
Zdroj: hab.com