Po spuštění začíná jiná práce
Aplikace může projít testy a přesto přestat vytvářet hodnotu po prvním výpadku databáze, neplatném certifikátu nebo chybné změně externího API. Provoz je soubor pravidelných rozhodnutí, která udržují službu použitelnou. Patří sem kontrola kritických uživatelských cest, vydávání změn, aktualizace závislostí, práce s incidenty, zálohy a komunikace. Není nutné pro každý web stavět rozsáhlou platformu. Je však nutné vědět, kdo vlastní jednotlivé kroky. Jediný VPS s Docker Compose může být přiměřený, pokud má projekt spolehlivou cestu obnovy a člověka, který ji umí použít.
Začněte tím, co uživatel očekává. U firemního webu může být důležitý formulář a dostupnost kontaktních informací. U interního systému jde třeba o vytvoření a dohledání případu. Pokud monitor sleduje jen odpověď úvodní stránky, nemusí zachytit, že hlavní funkce nepracuje. Zapište tři až pět kritických cest a jejich vlastníky. Pro každou stanovte, jak se pozná úspěch a co se stane při selhání. Teprve potom vybírejte nástroje. Technický stav kontejneru a obchodní stav služby jsou různé věci.
Odpovědnost se musí rozdělit po hranicích
Seznamte části, na nichž služba závisí: doména, DNS, certifikát, server, databáze, aplikace, e-mail, externí API a případně analytika. U každé napište, kdo má přístup, kdo platí a kdo reaguje na problém. Poskytovatel VPS odpovídá za určitou infrastrukturu podle smlouvy, ale zpravidla ne za konfiguraci aplikace na vašem stroji. Dodavatel kódu zase nemusí mít právo měnit DNS. Bez mapy odpovědností skončí incident přeposíláním zpráv mezi týmy. Provozní dokumentace má být čitelná i pro člověka, který nebyl u vývoje.
Odpovědnost zahrnuje rozhodovací pravomoc. Kdo může zastavit vydání, vypnout problematickou funkci nebo obnovit zálohu? Kdo informuje uživatele a kdo schvaluje přístup k citlivým datům během diagnostiky? U malé firmy může jedna osoba vykonávat více rolí, ale role nesmějí být nepojmenované. Zastupitelnost je důležitá i při jednoduchém webu. Pokud je jediný člověk na dovolené a klíč k serveru má jen on, plán podpory ve skutečnosti neexistuje. Přístupy ukládejte bezpečně a pravidelně zkoušejte, zda jsou stále použitelné.
Monitoring má ukázat problém, který lze řešit
Sledujte dostupnost z vnějšího pohledu, chybové odpovědi, kapacitu disku, zdraví databáze a fungování nejdůležitější akce. AWS Well-Architected doporučuje spojovat metriky, logy a stopy s konkrétními postupy pro známé události. Alert bez vlastníka a prvního kroku jen vyrábí hluk. Provozní tým musí vědět, zda se problém týká uživatelů, jak dlouho trvá a co může bezpečně udělat. Méně kvalitních signálů je lepší než mnoho upozornění, která nikdo nečte. Při malém systému může být užitečný jednoduchý externí test kontaktního formuláře, pokud je navržen tak, aby nevytvářel falešné zprávy.
Logy potřebují korelační identifikátory pro dohledání jednoho případu, ale ne kompletní tokeny, hesla či osobní údaje. Nastavte dobu uchování a oprávnění. Při ztrátě dostupnosti se nejdřív ptejte na dopad, pak na technickou příčinu. Dashboard může ukazovat zelené kontejnery, zatímco e-mailová služba odmítá všechny zprávy. Proto provozní přehled pravidelně srovnávejte se skutečnými výsledky. Po incidentu ověřte, zda monitor problém odhalil dříve než uživatel a zda přivedl tým ke správnému zásahu. Pokud ne, upravte signál nebo postup, ne jen jeho barvu.
Pohotovost je závazek lidí, ne vlastnost softwaru
Podpora v pracovní době a nepřetržitá pohotovost mají zásadně jinou cenu i organizační nároky. Stanovte časové pásmo, kanál hlášení, úrovně závažnosti a kdo je na řadě. Kritický incident posuzujte podle dopadu na uživatele, data a bezpečnost. Pětiminutové potvrzení hlášení není pětiminutová oprava. Když je služba závislá na třetí straně, vaše reakce může být rychlá, ale obnovení jejího systému neovládáte. V komunikaci oddělujte, co víte, co zjišťujete a kdy poskytnete další zprávu. Tak se udržuje důvěra i během nejistoty.
AWS rozlišuje runbook pro známý postup a playbook pro vyšetření méně jasné události. V malém týmu stačí stručný návod pro typické případy: plný disk, nefunkční databázi, neúspěšné nasazení a podezření na únik. Uveďte kontakt, přístup, první bezpečný krok a cestu eskalace. Návod otestujte cvičně. Při skutečném incidentu lidé nemají čas zjišťovat, kde je uložená jediná kopie hesla nebo zda poslední záloha obsahuje potřebné soubory. Po opravě doplňte do postupu to, co chybělo, a ověřte změnu při dalším cvičení.
Vydávání změn je součást provozního rizika
Každý release mění běžící systém. Potřebuje kontrolu kódu, automatické testy pro důležité scénáře, záznam verze, schválení a ověření po nasazení. Docker dokumentuje použití Compose v produkčním prostředí; pro malý projekt může být vhodný, pokud je proces opakovatelný. Nasazení nové verze kontejneru ale není celé vydání. Migrace databáze může znemožnit návrat staré aplikace. Připravte kompatibilní kroky nebo realistický plán obnovy dat. Tým musí vědět, od jaké chvíle je rollback složitější než vrácení obrazu.
Po vydání sledujte změnu chybovosti, hlavních uživatelských cest a zpráv podpory. Pokud se objeví problém, rozhodněte podle předem stanovené hranice, zda pokračovat, vypnout novou funkci nebo vrátit verzi. Upozornění „nasazení proběhlo“ neprokazuje, že formulář či platba funguje. Produkční změny konfigurace, tokenů a externích endpointů podléhají stejné evidenci jako změny kódu. U urgentní opravy postup zkraťte, ale ponechte záznam, test a následné vyhodnocení. Spěch nesmí odstranit schopnost zjistit, co se v systému vlastně změnilo.
Záloha musí přežít ztrátu původního serveru
Rozhodněte, jakou ztrátu dat lze přijmout a za jak dlouho se služba musí vrátit. Podle toho určete frekvenci záloh, jejich umístění a retenci. Databáze není jediný důležitý obsah; často je nutné uchovat nahrané soubory, konfiguraci a tajné údaje potřebné k obnově. Kopie na stejném disku neřeší selhání disku. Zálohy chraňte před neoprávněným přístupem a ověřte, že je lze získat bez původního stroje. Úspěšné vytvoření archivu je jen první krok, nikoli důkaz obnovitelnosti.
Cvičně obnovte systém do odděleného prostředí. Otevřete aplikaci, přihlaste se a najděte poslední očekávaný záznam. Měřte dobu potřebnou k celému procesu a zapište, co chybělo. U databázové migrace proveďte další kontrolu, protože návrat může vyžadovat více než starý obraz. Obnovu musí zvládnout člověk, který nebyl autorem zálohovacího skriptu. Pokud ne, dokumentace nebo přístupy nejsou připravené. Pravidelný test je přiměřený i pro jednoduché nasazení; složitá zálohovací služba bez ověřeného výsledku je slabší. V reportu uvádějte datum poslední úspěšné obnovy, ne jen poslední zálohy.
Report spojte s rozhodnutím o další práci
Google SRE doporučuje formulovat cíle kvality služby na základě indikátorů, které souvisejí s uživatelskou zkušeností. Při provozu proto sledujte, zda se podařilo dokončit důležité akce, ne jen dostupnost procesu. Krátký měsíční přehled může spojit incidenty, časy reakce, bezpečnostní aktualizace, test obnovy, změny závislostí a náklady. U každé významné odchylky napište návrh: opravit nyní, přijmout riziko, nebo odložit s datem revize. Report bez vlastníka a rozhodnutí se rychle stane administrativou. Jeho cílem je společné porozumění stavu služby.
Provozní dluh vzniká, když se opakovaně restartuje stejná chyba, zálohy se netestují nebo staré přístupy zůstávají aktivní. Vykazujte jej stejně poctivě jako nové funkce. EXCOIN může pomoci s návrhem provozu a předáním aplikace, ale nemá smysl slibovat konkrétní dostupnost bez skutečné konfigurace a odpovědností. První provozní milník může být prostý: mapa vlastníků, pět důležitých signálů, postup vydání, dvě cvičné poruchy a úspěšná obnova. Až měření ukáže potřebu, přidejte složitější infrastrukturu. Spolehlivost začíná tím, že tým ví, co dělá při běžném i nepříjemném dni.
Předání do správy ověřte praktickým cvičením. Nechte nového správce najít poslední vydání, určit aktuální verzi aplikace, otevřít výsledky monitoringu a obnovit zkušební databázi. Pokud potřebuje nezdokumentovanou pomoc původního vývojáře, předání ještě není dokončené. U každého zjištěného problému určete vlastníka opravy a termín. Stejný test zopakujte po větší změně infrastruktury nebo personálního obsazení. Díky tomu se provozní znalost nestane osobní pamětí jednotlivce a firma bude schopná službu udržovat i po změně dodavatele. Tento jednoduchý důkaz je lepší než dokument složený jen z obecných slibů.