Zodpovedajte za službu aj po nasadení

Definujte službu, od ktorej závisia používatelia

Nasadenie sprístupňuje softvér. Prevádzka ho udržiava užitočným pri zmenách používateľov, závislostí, záťaže a požiadaviek. Generátor kódu túto priebežnú prácu neodstraňuje.

Pri fiktívnom exporte zákazníkov potrebujú používatelia viac než dostupnú stránku. Potrebujú povolené záznamy v požadovanom formáte za prijateľný čas. Služba musí tiež zabrániť prístupu k údajom inej organizácie.

Pred vydaním určte zodpovednú osobu. Zaznamenajte, kto reaguje mimo bežného pracovného času, ak je to súčasťou záväzku služby. Dodávateľ môže vykonávať časť práce, ale organizácia stále potrebuje jasný postup rozhodovania a komunikácie.

Vyberte signály, ktoré podporujú konanie

Service-level indicator, alebo SLI, meria definovanú vlastnosť správania služby. Service-level objective, alebo SLO, stanovuje cieľ pre tento ukazovateľ za uvedené obdobie. Cieľ vyberte podľa potrieb používateľov a prevádzkových možností.

Odporúčania Google SRE vysvetľujú tento prístup a použitie rozpočtu chýb pri rozhodovaní o spoľahlivosti. Nekopírujte cieľ inej služby bez overenia jeho významu. Odporúčania pre SLO, príklad politiky rozpočtu chýb.

Pri exporte definujte, čo sa považuje za úspešnú oprávnenú požiadavku. Oddeľte očakávané zamietnutia od zlyhaní systému. Zdokumentujte výnimky, aby sa metrika nemohla zlepšiť iba skrytím náročných požiadaviek.

Nezapisujte celé exporty do logov na zlepšenie prehľadu. Zbierajte minimum informácií potrebných na diagnostiku problému a chráňte prístup k nim.

Pripravte reagovanie na incidenty

Rozhodnite, kto koordinuje, kto skúma a kto komunikuje. V malom tíme sa tieto roly môžu spájať, ale zodpovednosti musia zostať jasné. Uchovávajte záznam pozorovaní a akcií.

Odporúčania Googlu na reagovanie na incidenty zdôrazňujú koordináciu a komunikáciu popri technickom zmiernení následkov. Aj technicky správna oprava môže nechať používateľov bez informácií alebo viesť viacerých zasahujúcich k protichodným zmenám. Reagovanie na incidenty.

Agent môže sumarizovať logy alebo porovnávať hypotézy v schválených hraniciach údajov. Naliehavosť incidentu mu nemá udeliť neobmedzené produkčné oprávnenia. Pre mimoriadny prístup použite definovaný postup eskalácie.

Precvičujte obnovu a financujte údržbu

Otestujte postup obnovy s reprezentatívnymi vymyslenými údajmi. Určte, čo rollback kódu nedokáže vrátiť, vrátane odstránených záznamov alebo už odoslaných správ. Zaznamenajte čas a informácie potrebné na obnovenie služby.

Prideľte priebežnú prácu: aktualizácie závislostí, kontroly prístupov, prípadné obnovovanie certifikátov, zmeny kapacity a opravy dokumentácie. Službe bez kapacity na údržbu sa povinnosti hromadia aj po vyčerpaní rozpočtu na spustenie.

Po incidente vyberte zlepšenia, ktoré riešia pozorované príčiny. Prepojte ich s implementáciou a overením. Takto sa uzatvára životný cyklus: prevádzkové dôkazy menia to, čo tím ďalej špecifikuje a vytvára.