Преузмите одговорност за сервис после постављања

Дефинишите сервис од ког корисници зависе

Постављање чини софтвер доступним. Оперативни рад га одржава корисним док се корисници, зависности, саобраћај и захтеви мењају. Генератор кода не уклања тај стални посао.

За измишљен извоз података о купцима, корисницима треба више од доступне странице. Потребни су им дозвољени записи у траженом формату и прихватљивом року. Такође им треба сервис који спречава приступ подацима друге организације.

Одредите одговорну особу пре објављивања. Забележите ко реагује ван редовног радног времена ако је то део обавезе сервиса. Добављач може да обавља део посла, али организацији и даље треба јасан пут за одлуке и комуникацију.

Изаберите сигнале који подржавају деловање

Показатељ нивоа сервиса, односно SLI, мери дефинисано својство понашања сервиса. Циљ нивоа сервиса, односно SLO, поставља циљ за тај показатељ током наведеног периода. Изаберите циљ према потребама корисника и оперативној способности.

Google SRE смернице објашњавају овај приступ и употребу буџета грешака за одлуке о поузданости. Немојте копирати циљ другог сервиса без провере његовог значења. SLO смернице, пример политике буџета грешака.

За извоз дефинишите шта се рачуна као успешан захтев који испуњава услове за обраду. Раздвојите очекивана одбијања од отказа система. Документујте изузимања тако да метрика не може да се побољша само скривањем тешких захтева.

Немојте бележити целе извозе у логове ради боље видљивости. Прикупите најмање података потребних за дијагнозу проблема и заштитите приступ њима.

Припремите одговор на инцидент

Одлучите ко координише, ко истражује и ко комуницира. У малом тиму ове улоге могу да се обједине, али одговорности морају да остану јасне. Водите евиденцију запажања и радњи.

Google смернице за одговор на инцидент наглашавају координацију и комуникацију уз техничко ублажавање последица. Технички исправна поправка и даље може да остави кориснике необавештеним или више учесника да праве сукобљене промене. Одговор на инцидент.

Агент може да сажме логове или упореди хипотезе у одобреним границама података. Не треба да добије неограничена овлашћења у продукцији зато што је инцидент хитан. Користите дефинисан пут ескалације за изузетан приступ.

Увежбајте опоравак и финансирајте одржавање

Тестирајте поступак опоравка са репрезентативним измишљеним подацима. Утврдите шта rollback кода не може да поништи, укључујући обрисане записе или већ послате поруке. Забележите време и информације потребне за враћање сервиса.

Доделите сталне послове: ажурирање зависности, прегледе приступа, обнављање сертификата где је применљиво, промене капацитета и исправке документације. Сервис без капацитета за одржавање наставља да гомила обавезе после истека буџета за покретање.

После инцидента изаберите побољшања која решавају уочене узроке. Повежите их са имплементацијом и провером. Тиме затварате животни циклус: оперативни докази мењају оно што тим следеће дефинише и гради.