Шаблон разбора инцидента

Краткое описание инцидента

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

Пример:

В период <промежуток времени, который занимал инцидент, например с 15:45 до 16:35> <ДАТА> <КОЛИЧЕСТВО> клиентов сообщали о <СИМПТОМЫ СОБЫТИЯ>.

Событие было вызвано <ИЗМЕНЕНИЕ> в <ВРЕМЯ ИЗМЕНЕНИЯ, КОТОРОЕ ПРИВЕЛО К ИНЦИДЕНТУ>.

Суть <ИЗМЕНЕНИЕ> заключалась в <ОПИСАНИЕ ИЗМЕНЕНИЯ ИЛИ ПРИЧИНА ЕГО ВНЕСЕНИЯ, например изменение кода для обновления системы>.

Баг в этом участке кода вызвал <ОПИСАНИЕ ПРОБЛЕМЫ>.

Событие было обнаружено <СИСТЕМА МОНИТОРИНГА>. Команда начала реагировать на событие путем <ДЕЙСТВИЯ, ПРЕДПРИНЯТЫЕ ДЛЯ РЕШЕНИЯ ПРОБЛЕМЫ>.

Этот инцидент <УРОВЕНЬ ОПАСНОСТИ> затронул пользователей.

Этот инцидент имел дальнейшие последствия, которые были отмечены в <например, КОЛИЧЕСТВО ПОДАННЫХ ЗАЯВОК В СЛУЖБУ ПОДДЕРЖКИ, УПОМИНАНИЙ В СОЦИАЛЬНЫХ СЕТЯХ, ЗВОНКОВ МЕНЕДЖЕРАМ ПО РАБОТЕ С КЛИЕНТАМИ>.

Предшествующие события

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

Пример:

В <16:00> <ДД.ММ.ГГ> (<ВРЕМЯ ДО МОМЕНТА ПРОЯВЛЕНИЯ ПРОБЛЕМЫ У КЛИЕНТОВ, например за 10 дней до рассматриваемого инцидента>) в <ПРОДУКТ ИЛИ СЕРВИС> было внесено изменение, чтобы <ОПИСАНИЕ ИЗМЕНЕНИЙ, ПРИВЕДШИХ К ИНЦИДЕНТУ>.

Изменение привело к <ОПИСАНИЕ ПОСЛЕДСТВИЙ ИЗМЕНЕНИЙ>.

Сбой

Опишите, что во внедренном изменении не работало должным образом. Если возможно, прикрепите снимки экрана с наглядным представлением соответствующих данных о сбое.

Пример:

<КОЛИЧЕСТВО> ответов были некорректно отправлены на запросов. Это продолжалось в течение <ПЕРИОД ВРЕМЕНИ>.

Последствия

Опишите, что наблюдали внутренние и внешние пользователи во время инцидента. Укажите, сколько поступило заявок в службу поддержки.

Пример:

На протяжении между <ДД.ММ.ГГ> наши пользователи наблюдали <ОПИСАНИЕ ИНЦИДЕНТА>.

Этот инцидент затронул клиентов (X % ПОЛЬЗОВАТЕЛЕЙ <СИСТЕМА ИЛИ СЕРВИС>), которые наблюдали <ОПИСАНИЕ СИМПТОМОВ>.

Было отправлено <КОЛИЧЕСТВО ЗАЯВОК В СЛУЖБУ ПОДДЕРЖКИ И КОЛИЧЕСТВО ПУБЛИКАЦИЙ В СОЦИАЛЬНЫХ СЕТЯХ>.

Обнаружение

Когда команда обнаружила инцидент? Как они узнали о происходящем? Как мы можем ускорить обнаружение? Подумайте, как можно сократить это время вдвое?

Пример:

Инцидент был обнаружен, когда сработало <ТИП ОПОВЕЩЕНИЯ> и было отправлено сообщение <КОМАНДА ИЛИ ЧЕЛОВЕК>.

Затем было отправлено сообщение <ВТОРОЙ ЧЕЛОВЕК>, потому что <ПЕРВЫЙ ЧЕЛОВЕК> не отвечал за работу сервиса, осуществлявшего запись на диск, что вызвало задержку реагирования на .

<ОПИСАНИЕ УЛУЧШЕНИЯ> будет подготовлено <КОМАНДА, ОТВЕЧАЮЩАЯ ЗА УЛУЧШЕНИЕ> с целью <ОЖИДАЕМОЕ УЛУЧШЕНИЕ>.

Ответ

Кто отреагировал на инцидент? Когда они ответили и что делали? Отметьте любые задержки или барьеры, препятствующие устранению инцидента.

Пример:

После получения сообщения в <ДЕЖУРНЫЙ ИНЖЕНЕР> вышел в сеть в в <СИСТЕМА, В КОТОРОЙ ФИКСИРУЕТСЯ ИНФОРМАЦИЯ ОБ ИНЦИДЕНТЕ>.

Однако дежурный инженер не имел достаточного опыта работы с <ЗАТРОНУТАЯ СИСТЕМА>, поэтому в было отправлено второе оповещение <СЛЕДУЮЩИЙ В ЦЕПОЧКЕ ЭСКАЛАЦИЙ ДЕЖУРНЫЙ ИНЖЕНЕР>, который присоединился к чату в .

Восстановление

Опишите, как была восстановлена работа сервиса, а инцидент был признан завершенным. Подробно опишите, как вы поняли, какие шаги необходимо предпринять для восстановления.

В зависимости от сценария ответьте на следующие вопросы. Как можно было сократить время, прошедшее до смягчения последствий? Как можно было сократить это время вдвое?

Пример:

Для восстановления работы системы использовался трехсторонний подход.

<ОПИШИТЕ ДЕЙСТВИЕ, ПРЕДПРИНЯТОЕ ДЛЯ СМЯГЧЕНИЯ ПОСЛЕДСТВИЙ ПРОБЛЕМЫ, ПРИЧИНУ ЕГО ВЫБОРА И РЕЗУЛЬТАТ>

Пример. Увеличение размера BuildEng EC3 ASG с целью повысить количество доступных узлов для обслуживания рабочей нагрузки и сокращения вероятности планирования задач на перегруженных узлах.

• Отключение инструмента автомасштабирования Escalator, чтобы предотвратить активное масштабирование кластера в сторону уменьшения.
• Возврат планировщика Build Engineering к предыдущей версии.

График

Подробно опишите хронологию инцидента. Рекомендуется использовать время UTC для стандартизации часовых поясов.

Включите значимые предшествующие события, любые запуски процессов, время первого проявления последствий, а также эскалации. Запишите все принятые решения или внесенные изменения, время окончания инцидента, а также любые примечательные события, являющиеся следствием инцидента.

Пример:

Часовой пояс всех временных отметок: UTC.

11:48 — завершено обновление плоскости управления K8S 1.9.

12:46 — завершено обновление до версии 1.9, включая средство автомасштабирования кластера и экземпляр планировщика BuildEng.

14:20 — Build Engineering сообщает о проблеме инженеру KITT Disturbed.

14:27 — KITT Disturbed начинает изучение сбоев на конкретном экземпляре EC2 (IP-адрес: 203.153.8.204).

14:42 — KITT Disturbed блокирует узел.

14:49 — BuildEng сообщает, что проблема затрагивает несколько узлов. Обнаружено 86 проблемных экземпляров, что говорит о системном характере сбоев.

15:00 — KITT Disturbed предлагает переключиться на стандартный планировщик.

15:34 — BuildEng сообщает о сбое 200 подов.

16:00 — BuildEng принудительно завершает все неудачные сборки с отчетами OutOfCpu.

16:13 — BuildEng сообщает, что сбои не были временными и постоянно повторяются с новыми сборками.

16:30 — KITT определяет возникшие сбои как инцидент, и начинает обрабатывать их соответствующим образом.

16:36 — для облегчения проблемы KITT отключает инструмент автомасштабирования Escalator, чтобы предотвратить изъятие вычислительных ресурсов.

16:40 - KITT подтверждает, что состояние группы автомасштабирования стабилизировалось, загрузка кластера нормальная и последствия для клиентов устранены.

ШАБЛОН:

XX:XX UTC — СОБЫТИЕ ИНЦИДЕНТА; ПРЕДПРИНЯТОЕ ДЕЙСТВИЕ.

XX:XX UTC — СОБЫТИЕ ИНЦИДЕНТА; ПРЕДПРИНЯТОЕ ДЕЙСТВИЕ.

XX:XX UTC — СОБЫТИЕ ИНЦИДЕНТА; ПРЕДПРИНЯТОЕ ДЕЙСТВИЕ.

Определение основной причины: пять «почему»

Метод пяти «почему» помогает определить основную причину. Он применяется следующим образом.

• Сначала опишите последствия и спросите, почему это случилось.
• Запишите, какие последствия повлек за собой инцидент.
• Спросите, почему инцидент произошел и почему он повлек такие последствия.
• Затем продолжайте задавать вопросы «почему», пока не доберетесь до основной причины.

Перечислите эти «почему» в документации по разбору инцидентов.

Пример:

1. Сбой приложения произошел, потому что была заблокирована база данных.
2. База данных была заблокирована, потому что в ней проводилось слишком много операций записи.
3. Потому что мы внесли в сервис изменение и не ожидали увеличения активности.
4. Потому что в нашем процессе разработки не учитывается необходимость нагрузочного тестирования изменений.
5. Потому что нагрузочное тестирование не требовалось, пока мы не достигли такого уровня масштабирования.

Основная причина

Запишите конечную основную причину возникновения инцидента, ту вещь, которую необходимо изменить, чтобы предотвратить повторное возникновение подобных инцидентов.

Пример:

Баг <ПРИЧИНА БАГА ИЛИ СЕРВИС, ГДЕ ОН ОБНАРУЖИЛСЯ> в обработке пула подключений привел к разрыву подключений в условиях сбоя. Это наложилось на отсутствие возможности наблюдать за состоянием соединений.

Проверка бэклога

Просмотрите бэклог разработки. Может, если бы вы выполнили какие-то незапланированные задачи в нем, этот инцидент можно было предотвратить или, по крайней мере, его последствия были бы не такими тяжелыми.

Честная оценка бэклога поможет проверить принятые ранее решения по приоритетам и рискам.

Пример:

В бэклоге нет пунктов, которые могли бы улучшить работу этого сервиса. Есть примечание об улучшениях типизации контекста, и это были текущие задачи с действующими рабочими процессами.

Есть принятые заявки на улучшение интеграционных тестов, но попытки их реализации пока не завершились успехом.

Повторение

Теперь, когда вы знаете основную причину, оглянитесь назад и посмотрите, есть ли другие инциденты, которые могли бы возникнуть по этой же причине? Если да, обратите внимание на то, какие меры по смягчению последствий были предприняты в ходе работы над этими инцидентами, и спросите, почему этот инцидент произошел снова.

Пример:

Та же самая основная причина привела к инцидентам HOT-13432, HOT-14932 и HOT-19452.

Полученный опыт

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

Пример:

• Необходим юнит-тест, который проверял бы настройку ограничителя скорости для рабочей нагрузки.
• Необходима проверка рабочих нагрузок с пакетными операциями, нетипичными для нормальной работы.
• Пакетные операции должны запускаться постепенно и контролироваться. Наращивание операций должно происходить при номинальных значениях показателей сервиса.

Корректирующие действия

Опишите порядок корректирующих действий для предотвращения возникновения подобных инцидентов в будущем. Укажите ответственных за выполнение этой работы, сроки ее выполнения и инструмент для ее отслеживания.

Пример:

1. Временно ввести в действие ручное ограничение скорости автомасштабирования, чтобы уменьшить вероятность отказов.
2. Юнит-тестирование и повторная реализация ограничения скорости выполнения заданий.
3. Введение дополнительного механизма сбора информации о скорости распределения по кластеру для контроля последствий масштабирования.