Incident management в Amazon

В любых софтверных сервисах и продуктах случаются outages, полные или частичные. Когда сервис падает и становится недоступным или часть функционала перестает работать.
Как в Amazon реагируют на такие ситуации, как обнаруживают, что делают во время инцидента и после него?
В Amazon все разработчики без исключения участвуют в так называемом oncall. Т.е. по очереди дежурят в поддержке работы сервисов, которые они разрабатывают. Обычно это длится одну неделю раз в в 1.5 - 2 месяца. В течении этого времени они реагируют на тикеты и таски связанные с саппортом продукта и участвуют в их митигации (именно митигации, а не починке root cause). Все сервисы производят огромное число метрик, на которые созданы alarms, которые в случае проблем автоматически создают таски. Например, это может быть AWS Cloudwatch. Тикеты и таски имеют свой severity. Самые важные автоматически приходят на рабочий телефон и очень громко звенят(paging). В том числе это может произойти ночью. В таком случае нужно принять этот paging в течении короткого промежутка времени и надо начать смотреть тикет. Если это не сделать, то такой alarm начнет будить вашего менеджера, потом менеджера его менеджера. Вплоть до CEO если это очень серьезный инцидент и никто не реагирует.
Далее oncall смотрит тикет и принимает шаги по митигации (stop the bleeding, не починки). Например, делает rollback до последней стабильной версии, восстановление из backup, перезагрузку кластера и тому подобное.
При этом активно комментирует все свои действия в тикеты, т.к. часто это может повлиять на другие компоненты и сервисы, которые активно пишут, что они тоже заафекчены. Иногда перебои в Amazon приводят к outage в других продуктах. Например, однажды outage в AWS S3 привел к недоступности видео в Netflix. Иногда происходит мониторинг медиа типа twitter, на предмет жалоб на outage. Как только инцидент был замитигирован(stop bleeding) начинается формирование документа COE ревью, который призван помочь в предотвращении таких инцидентов в будущем. Одна из особенностей как митигации так и COE ревью - no blame culture. Т.е. не заниматься поиском виноватых людей, а поиском дыр в системе, процессах, которые позволили этому случиться. Про COE ревью детально напишу в следующих постах.