COE Review в Amazon

В продолжении к посту: https://t.me/faangmaster/217

После серьезного инцидента, как правило, пишется документ под названием COE Review. Серьезность инцидента зависит от того, какой был impact, какой сервис был заафекчен, какая функциональность перестала работать и т.д. Обычно это делается для инцидентов уровня LSE (Large Scale Event), Sev0, Sev1, Sev2, Sev3. Sev0 - это, обычно, значит, что перестала работать функциональность, которая непосредственно влияет на конечного пользователя (Tier0 сервис). Sev3 - непосредственно влияния на конечного пользователя нет, но могут быть отсроченные небольшие эффекты на пользователя или небольшие потери для бизнеса.
На написание и ревью документа отводится ограниченное количество дней. У документа есть owner, который работает над документом, но ему могут помогать и другие люди.
Основная цель документа - понять, что и почему произошло и что можно сделать, чтобы это не произошло в будущем (prevention).
Из чего состоит документ:

1) Into. Краткое summary. Описывается на абзац, что произошло, какой impact в цифрах (например, сервис был offline 2 часа, что привело к потере ~40 миллионов долларов прибыли), как обнаружили, как замитигировалли, какой root cause.

2) Impact. Более детально описывается влияние данного инцидента. Приводится расчет убытков, приводятся метрики, графики с детальным анализом, запросы и т.д.

3) Timeline. Описывается последовательность событий с временем, что происходило, какие были предприняты меры. Когда случился сбой, когда он был обнаружен, когда стало понятно как митигировать, какие шаги по митигации были предприняты и т.д.

4) Detection. Описывается как было обнаружено, что что-то не так. Какие метрики, alarms позволили это обнаружить. С какой задержкой это было обнаружено.

5) Mitigation. Какие шаги были предприняты, чтобы замитигировать проблему (stop the bleeding). Сколько это заняло времени и почему.

6) Five whys. Позволяют ответить на вопрос, что послужило реальной причиной (root cause).

7) Monitoring/Detection Improvement. Что можно сделать, чтобы быстрее в следующий раз обнаружить подобную проблему (улучшить метрики, алармы, добавить независимые методы детектирования и т.д.)

8) Mitigation Improvement. Что можно улучшить, чтобы быстрее митигировать проблему (улучшить или добавить автоматические системы, которые задетектируют проблему и автоматически сделают rollback, улучшить качество runbooks, добавить метрик, dashboard’ов и т.д.)

9) Root Cause Fix. Что нужно сделать, чтобы починить root cause.

10) Prevention. Какие шаги нужно предпринять, чтобы это не случилось в будущем.

Все это описывается, проходит цепочка ревью (внутри команды, внутри организации, в целом в компании), происходит публикация. Другие люди, могут найти этот документ в общей системе по ключевым словам и прочитать то, что произошло и как это можно починить, чтобы использовать в своих целях. Далее все эти action items реализуются разработчиками. В Amazon этому уделяется серьезное внимание, но и процесс очень сложный и бюрократический. В Facebook он намного более легковесный.