Náš tím miluje experimentovanie. Každý Slurm nie je statické opakovanie predchádzajúceho, ale zamyslenie nad skúsenosťou a prechod od dobrého k lepšiemu. Ale s sme sa rozhodli aplikovať úplne nový formát — dať účastníkom podmienky, maximálne priblížené k "bojovým".
Ak by sme stručne načrtli, čomu sme sa na intenzívnom školení venovali: "Staviame, rozbíjame, opravujeme,
študujeme". SRE nemá veľkú hodnotu v holé teórii — iba prax, reálne riešenia, reálne problémy.
Účastníci boli rozdelení do tímov, aby živý súťažný duch nikoho nenechal zaspať alebo nespustil "Angry Birds" na iPhone ako napríklad Dmitrij Anatoljevič.
Problémy, chyby, bugy a úlohy zabezpečovali účastníkom štyria mentori. Ivan Kruglov, hlavným vývojárom v Booking.com (Holandsko). Ben Tyler, hlavným vývojárom v Booking.com (USA). Eduard Medvedev, CTO vo Tungsten Labs (Nemecko). Jevgenij Varavva, širokospektrálny vývojár v Google (San Francisco).
A ešte aj účastníci rozdelení do tímov — a súťažia navzájom. Zaujímavé?
Ivan, Ben, Eduard a Jevgenij s dobrou Leninovou pokorou pozerajú na chudákov účastníkov Slurm SRE pred začiatkom súťaže.
Takže úloha:
My, my postavíme nový svet...
Existuje webový agregátor lístkov do kina. Incidenty vymýšľajú mentori v vopred spracovanom scenári (aj keď nikto nevylučuje extra sofistikovanú a zložitú improvizáciu), funkčnosť webu je popisovaná rôznymi metrikami. Problémy môžu byť rôzne: lístky na divadelné predstavenie "Moulin Rouge" sa nenačítavajú do databázy; plagáty filmov a predstavení sa načítavajú do databázy dlhšie ako 10 sekúnd; popis jednotlivého filmu sa
zasekáva; 0,1% objednávok sa dostáva na už rezervované miesta; občas sa na sladké systém spracovania platieb odpojí na minútu-dve. A veľa, veľa nepríjemností, ktoré môže účastníkovi Slurma SRE spadnúť na jeho reálnu prácu.
Naša ťažko skúšaná stránka pozostáva z viacerých mikroservisov. Jej úlohou je agregácia údajov o sedeniach, cenách a voľných miestach zo všetkých kín; zobrazuje upútavky na filmy, umožňuje vybrať kino, sedenie, sálu a miesto, rezervovať a zaplatiť vstupenky. Skrátka, všetko, o čom divák len sníva. Lenže používateľ ani netuší, aký titánsky boj prebieha za stabilitu a dostupnosť stránky vo vnútri.
Pre stránku na intenzíve sme formulovali ukazovatele SLO, SLI, SLA, vyvinuli sme architektúru a infraštruktúru, nasadili sme stránku, nastavili monitoring a alerting. A začalo sa.
SLO, SLI, SLA
SLI — ukazovatele úrovne služieb. SLO — ciele úrovne služieb. SLA — zmluvy o úrovni služieb.
SLA — termín metodológie ITIL, označujúci formálnu zmluvu medzi zákazníkom služby a jej poskytovateľom, ktorá obsahuje popis služby, práva a povinnosti strán a, čo je najdôležitejšie, dohodnutú úroveň kvality poskytovanej služby.
SLO — cieľ úrovne služieb: cieľová hodnota alebo rozsah hodnôt pre úroveň služieb, ktorý meria SLI. Normálnou hodnotou pre SLO je "SLI ≤ cieľová hodnota" alebo "dolná hranica ≤ SLI ≤ horná hranica."
SLI je ukazovateľ úrovne služieb — starostlivo definované kvantitatívne meranie jedného z aspektov poskytovanej úrovne služieb. Pre väčšinu služieb sa ako kľúčový SLI považuje oneskorenie požiadavky — koľko času je potrebné na vrátenie odpovede na požiadavku. Iné bežné SLI zahrňujú frekvenciu chýb, často vyjadrenú ako podiel všetkých prijatých požiadaviek, a priepustnosť systému, zvyčajne meranú v požiadavkách za sekundu.
Najprv zničíme lietadlá, nuž a dievčatá, dievčatá potom...
Interné a externé faktory od prvých minút začali "kazit" SLO. Na hlavy administrátorov sa zosypalo všetko — a chyby vývojárov, a zlyhania infraštruktúry, a príliv návštevníkov, a DDoS útoky. Všetko, čo zhoršuje SLO.
"- Drahí účastníci, ponáhľam sa vás potešiť, ako prvé vám padá… všetko!"
Počas akcie prednášajúci rozoberali odolnosť, rozpočet chýb, prax testovania, riadenie prerušení a prevádzkovú záťaž.
Nie sme vykurovatelia, nie sme stolári...
Tu účastníci začali opravovať — hlavné je pochopiť, čo uchopiť ako prvé.
„- Bože, nikdy som nevidel, že by sa to pokazilo takto, v takom stave a v takej pozícii!“
Takže došlo k havárii. Služba spracovania platieb zlyhala. Ako postupovať, aby sme obnovili funkčnosť v minimálnom čase?
Odborníci s láskyplným pohľadom na účastníkov pripravujú ďalší trik.
Každý tím organizuje prácu skupiny na odstránenie havárie — zapája kolegov, informuje zainteresovaných (stakeholders). Zároveň sa stanovujú priority. Tak účastníci trénovali prácu pod tlakom v podmienkach extrémne obmedzeného času.
„- Čo je to za hrôzu, čo sa vyliahlo?!“
Vydýchli sme... a dokončili cvičenie.
Spolu s prednášajúcimi po každom vyriešenom probléme a dočasne stabilizovanej stránke tím študoval incidenty z pohľadu SRE. Detailne analyzovali problémy — príčiny vzniku, priebeh odstránenia. Potom tímovo aj kolektívne prijímali rozhodnutia o ich ďalšom predchádzaní: ako zlepšiť monitoring, ako správne zmeniť architektúru, ako upraviť prístup k vývoju a prevádzke, ako opraviť predpisy. Prednášajúci demonštrovali prax vykonávania post-mortem.
„- Kto chce ďalšie mučenie! — Ja!“
Na elektronickej tabuli sa striktne a jasne zaznamenávali úspechy tímov.
Za prvé miesta — odmena od stakeholderov.
Zdroj: habr.com
