Převezměte odpovědnost za službu po nasazení

Definujte službu, na které uživatelé závisejí

Nasazení software zpřístupní. Provoz jej udržuje užitečný při změnách uživatelů, závislostí, zátěže a požadavků. Generátor kódu tuto průběžnou práci neodstraňuje.

U fiktivního exportu zákazníků uživatelé potřebují více než dosažitelnou stránku. Potřebují povolené záznamy v požadovaném formátu a v přijatelném čase. Potřebují také, aby služba bránila přístupu k datům jiné organizace.

Odpovědnou osobu určete před vydáním. Pokud to patří k závazku služby, zaznamenejte, kdo reaguje mimo běžnou pracovní dobu. Část práce může provádět dodavatel, ale organizace stále potřebuje jasný postup rozhodování a komunikace.

Volte signály, které podporují jednání

Service-level indicator neboli SLI měří definovanou vlastnost chování služby. Service-level objective neboli SLO stanovuje cíl tohoto ukazatele za dané období. Cíl zvolte podle potřeb uživatelů a provozních schopností.

Pokyny Google SRE vysvětlují tento přístup i využití error budgetu při rozhodování o spolehlivosti. Nekopírujte cíl jiné služby bez ověření jeho významu. Pokyny k SLO, příklad pravidel error budgetu.

U exportu definujte, co se počítá jako úspěšný oprávněný požadavek. Oddělte očekávaná zamítnutí od selhání systému. Zdokumentujte výjimky z měření, aby se metrika nemohla zlepšit pouhým skrytím obtížných požadavků.

Pro lepší přehled neukládejte celé exporty do logů. Sbírejte minimum informací potřebných k diagnóze a chraňte přístup k nim.

Připravte reakci na incident

Rozhodněte, kdo koordinuje, kdo vyšetřuje a kdo komunikuje. V malém týmu lze role spojit, ale odpovědnosti musí zůstat jasné. Uchovávejte záznam pozorování a akcí.

Pokyny Googlu k reakci na incidenty vedle technického zmírnění zdůrazňují koordinaci a komunikaci. I technicky správná oprava může ponechat uživatele bez informací nebo více řešitelů provádějících protichůdné změny. Reakce na incidenty.

Agent může shrnovat logy nebo porovnávat hypotézy ve schválených hranicích dat. Nemá dostat neomezené produkční pravomoci jen kvůli naléhavosti incidentu. Pro mimořádný přístup použijte definovaný eskalační postup.

Procvičujte obnovu a financujte údržbu

Postup obnovy testujte s reprezentativními fiktivními daty. Určete, co rollback kódu nevrátí, včetně smazaných záznamů nebo již odeslaných zpráv. Zaznamenejte čas a informace potřebné k obnově služby.

Přiřaďte průběžnou práci: aktualizace závislostí, kontroly přístupů, případné obnovování certifikátů, změny kapacity a opravy dokumentace. Službě bez kapacity údržby se hromadí povinnosti i po vyčerpání rozpočtu na spuštění.

Po incidentu vyberte zlepšení, která řeší pozorované příčiny. Propojte je s implementací a ověřením. Tím se životní cyklus uzavírá: provozní důkazy mění to, co tým specifikuje a vytváří dál.