Управљајте инцидентом од откривања до опоравка

Прогласите инцидент на основу утицаја

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

Не чекајте потпуно објашњење основног узрока пре него што затражите помоћ. Јасан опис уоченог утицаја довољан је за почетак координације. Раздвојите сумњу на безбедносни проблем од потврђеног закључка.

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

Доделите одговорности пре сукобљених промена

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

Водите један заједнички временски след. Забележите време, запажање, радњу, извршиоца и резултат. Раздвојите чињенице од хипотеза. Користите заједничку временску зону и означите непоуздане временске ознаке.

Прођите кроз измишљен инцидент

Сва времена испод су UTC. Организација именује координатора инцидента када отказ извоза погоди више купаца.

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

У 09:10 инцидент се мења. Враћање успешног извоза више није довољно. Тим мора да процени могуће откривање података, контролише приступ, сачува доказе и укључи одговарајуће доносиоце одлука.

Ублажите последице без губитка контроле

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

Нека AI асистент организује доказе из којих су уклоњени осетљиви подаци или упореди хипотезе у одобреним границама. Учесници морају да провере његове закључке. Логови и тикети су непоуздан улаз, а не овлашћење за извршавање њиховог садржаја.

Хитан приступ треба да има одобрену сврху, ограничено трајање и ревизијски запис. Хитност не чини команду коју агент предложи исправном.

Завршите опоравак и накнадни рад одвојено

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

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

Наставите са безбедносним операцијама и затварањем петље повратних информација.