Runbook

Příklady z praxe

1. 01

   Výpadek platebního API

   Platební API začne vracet chyby 503 a monitoring spustí alarm pro vysokou chybovost. Runbook navede službu konajícího inženýra ke kontrole dashboardu, ověření závislé databáze, bezpečnému restartu deploymentu a potvrzení, že health check znovu prochází. Výsledkem je zásah se stejným pořadím kroků bez ohledu na to, kdo má službu právě na telefonu.

   kubectl -n payments rollout restart deployment/payment-api
   kubectl -n payments rollout status deployment/payment-api
   curl -fsS https://status.example.com/health/payments

2. 02

   Rollback po neúspěšném nasazení

   E-shop zaznamená po nočním deployi výrazně více neúspěšných objednávek. Release runbook určí hranici pro rollback, osobu oprávněnou změnu schválit, komunikační kanál pro podporu a kontrolu objednávek po návratu staré verze. Výsledkem je rychlé obnovení provozu a jasný záznam, proč se změna vrátila.

Časté omyly

MýtusRunbook je jen dokumentace pro juniory.

Ve skutečnostiRunbook používají i seniorní lidé, protože při incidentu snižuje kognitivní zátěž a sjednocuje reakci týmu. Senior často lépe ví, proč krok existuje, ale i senior může pod tlakem přeskočit kontrolu nebo zapomenout eskalaci.

MýtusKdyž máme monitoring, runbook už nepotřebujeme.

Ve skutečnostiMonitoring upozorní, že se něco děje, ale sám neurčí bezpečný postup nápravy. Runbook propojuje signál z monitoringu s diagnostikou, rozhodnutím, opravou a kontrolou výsledku.

Časté dotazy

Kdy má smysl napsat runbook?

Runbook se vyplatí vytvořit ve chvíli, kdy se stejný zásah může opakovat, má dopad na zákazníky nebo vyžaduje koordinaci více lidí. Typickým kandidátem je incident s databází, výpadek externí služby, ruční rollback, obnova certifikátu nebo reakce na bezpečnostní upozornění. Jednorázový experiment runbook nepotřebuje, ale opakovaný noční zásah bez dokumentace je signál, že provozní návod chybí.

Čím se runbook liší od postmortemu?

Runbook popisuje konkrétní provozní postup pro známou situaci, zatímco postmortem zpětně analyzuje incident a hledá příčiny, dopad a zlepšení. Runbook se používá během zásahu, protože říká, co udělat a jak ověřit výsledek. Postmortem se píše po události a často vede k úpravě runbooku, pokud tým zjistí, že některý krok chyběl nebo byl zavádějící.

Kdo má runbook udržovat aktuální?

Runbook může patřit týmu, který vlastní službu, ne jednotlivci, který postup kdysi napsal. Prakticky to znamená jasného vlastníka, revizi při změnách architektury a kontrolu po každém větším incidentu. Pokud runbook nemá vlastníka, rychle zastará. Zastaralý návod je horší než žádný, protože dává operátorovi falešnou jistotu v kritické situaci.

Jak podrobný má být runbook?

Runbook má být dost přesný na provedení bez dlouhého dohledávání, ale nemá zakrývat rizika slepým seznamem příkazů. U kritických kroků je vhodné uvést očekávaný výstup, kontrolní metriku a okamžik, kdy má operátor zastavit a eskalovat. Příliš obecný runbook nepomůže juniorovi, příliš mechanický runbook může navést člověka ke škodlivé změně v nevhodném kontextu.

Zdroje

1. Azure Automation runbook types(otevře se v novém okně)Microsoft
2. Google Cloud Architecture Framework(otevře se v novém okně)Google Cloud
3. Debugging Kubernetes(otevře se v novém okně)Kubernetes
4. AWS Well-Architected(otevře se v novém okně)Amazon Web Services

Související pojmy

• MonitoringMonitoring je soustavné sledování stavu systému pomocí metrik, logů, událostí, trace záznamů a alertů. V softwaru a provozu ukazuje, zda aplikace, infrastruktura nebo služba plní očekávání, pomáhá rychle odhalit poruchu a poskytuje data pro rozhodnutí o kapacitě, výkonu i bezpečnosti.
• RollbackRollback je návrat systému do posledního známého konzistentního stavu poté, co změna selhala nebo způsobila problém. V databázi ruší všechny zápisy rozpracované transakce, v nasazení vrací aplikaci na předchozí verzi. Cílem je odstranit následky neúspěšné operace bez ručního dohledávání toho, co se stihlo změnit.
• 3-D Secure3-D Secure je protokol, který u online platby kartou ověří, že platí skutečně její držitel, typicky potvrzením v bankovní aplikaci. Při úspěšném ověření se zároveň přenáší odpovědnost za podvodnou transakci z obchodníka na vydavatele karty.
• ACIDACID je sada čtyř vlastností databázové transakce: atomicity, consistency, isolation a durability. Zaručuje, že skupina zápisů proběhne jako jeden celek, neporuší definovaná pravidla databáze, nebude se nebezpečně míchat s jinými transakcemi a po potvrzení přežije pád systému, například při převodu peněz.
• Adaptive IconAdaptivní ikona je formát ikony aplikace na Androidu, který se místo jedné hotové bitmapy skládá z oddělených vrstev: pozadí a popředí. Systém výsledný tvar sám ořízne podle masky výrobce zařízení a může vrstvy animovat nebo přebarvit. Vývojář tak dodá jeden zdroj a launcher z něj vytvoří kruh, čtverec i squircle.
• Adresa v pamětiAdresa v paměti je číslo, kterým procesor jednoznačně označuje konkrétní buňku operační paměti, obvykle jeden bajt. Program pomocí adresy říká, odkud má data načíst nebo kam je zapsat. Adresy tvoří souvislý číselný rozsah, jehož velikost určuje šířka adresní sběrnice a architektura, typicky 32 nebo 64 bitů.
• AI agentAI agent je softwarový systém, který pomocí modelu umělé inteligence vnímá zadaný kontext, plánuje další kroky a samostatně volá nástroje nebo služby k dosažení cíle. Na rozdíl od jednorázového promptu udržuje stav úlohy, vyhodnocuje výsledky akcí a může opakovat postup, dokud nesplní zadání nebo nenarazí na limit.
• AndroidAndroid je operační systém postavený nad linuxovým jádrem, který vyvíjí Google a otevřeně uvolňuje jako projekt AOSP. Android pohání převážnou většinu chytrých telefonů, dále tablety, televize, hodinky i palubní systémy aut. Aplikace se pro něj píší hlavně v Kotlinu nebo Javě a distribuují přes Google Play i alternativní obchody.