Сегодня расскажу про то, как мы ведём разбор полётов по техническим происшествиям.
Разбор полётов
"Разборы полётов" (дебрифинги, постмортемы и т.п.) — это инженерные документы, где чётко фиксируются:
- хронология проблем и событий, возникших в ходе эксплуатации инфраструктуры, конкретного сервиса или ПО,
- гипотезы причин возникновения проблем и инцидентов,
- планы работ по их устранению,
- рекомендации и шаги возможных улучшений, чтобы не допустить повторения проблем.
Разборы полётов используются инженерами для того, чтобы в будущем спокойно проанализировать событие, выявить слабые места инфраструктуры, продумать и зафиксировать в виде задач конкретные действия, или предусмотреть дополнительную автоматизацию и тестирование, чтобы проблема вновь не возникла.
Рекомендуется заранее подготовить шаблон документа для разбора полётов, чтобы во время активной работы над устранением проблемы ваши инженеры не тратили на него лишнее время. Далее рассмотрим пример, как может выглядеть такой шаблон, из каких блоков может состоять документ.
I. Заголовок
В заголовке странички с разбором полётов укажите начальную дату и запишите кратко: суть проблемы, сервис и количество часов простоя
Проблема: здесь более подробно опишите проблему, с какими сервисами она произошла, к чему это привело.
Основная причина: здесь укажите основную причину, которая привела к проблеме.
Полезные ссылки и инструкции: подготовьте для шаблона свой список полезных ссылок на внутренние документы и регламенты, чтобы во время работы над инцидентом инженер не тратил время на их поиски.
Пример заполнения области заголовка:
2020-02-03 — Отказ инфраструктуры сборочных серверов из-за проблем с обновлением, простой ~4 часа
Проблема: после обновления ОС на сборочных серверах сборочная инфраструктура была недоступна ~4 часа.
Основная причина: служба CI-агента не запустилась после перезагрузки. Обновление было проведено не по регламенту, не согласовано с продуктовыми командами, не был предусмотрен план обновления и отката.
Полезные ссылки и инструкции:
- System Operation Manual — что инженер по инфраструктуре должен сделать в первую очередь (в каждой компании свой регламент).
- Инструкции по снятию типовых показаний и метрик с исследуемых систем (в каждой компании своя специфика и свои метрики для критических показателей).
II. Хронология проблем и событий
Тут пишем простую последовательность событий, в свободной форме: что случилось, что произошло, что было сделано инженерами, к чему это привело, прикладываем переписку, логи и тексты оповещений. С сервисных ВМ нужно прикладывать логи аудита и значения метрик ОС. Хронологию проще всего вести в табличной форме.
Пример заполнения хронологии:
Хронология проблем и событий
| N | Дата и время события | Событие или проблема |
|---|---|---|
| 1 | 2020-06-17 12:00 MSK | Производились работы по обновлению Windows Server на сборочных агентах |
| 2 | 2020-06-17 13:00 MSK | После обновления агенты не запустились из-за проблем с учёткой. Логи приложены. |
| 3 | 2020-06-17 13:30 MSK | Оповестили разработчиков о проблеме. Служебное письмо приложено. |
| 4 | 2020-06-17 13:40 MSK | Начали процедуры отката... |
| ... | 2020-06-17 14:00 MSK | ... прочие действия ... логи ... метрики ... служебная переписка ... |
| N | 2020-06-17 16:00 MSK | Разослали оповещение о восстановлении сборочных пулов агентов. Копия приложена. |
III. Гипотезы причин возникновения проблем
Если сходу причины проблем установить не удалось, фиксируются все возможные варианты и последовательно выполняется их проверка. Этот раздел можно изобразить также в виде обычной таблицы.
Пример заполнения таблицы с гипотезами:
Гипотезы причин возникновения проблем
| N | Гипотеза | Подтверждается или опровергнута | Как проверяли гипотезу |
|---|---|---|---|
| 1 | Перезатёрлись ключи авторизации | нет | Зашли в админку, проверили ... |
| 2 | Не запустилась служба агента | да | Служба агента - был ручной запуск |
| ... | ... прочие варианты ... | ... | ... |
IV. План работ
Тут пишем запланированные виды работ для устранения причин проблемы. Если по какой-то причине её устранение затруднено, также сообщаем об этом.
Пример заполнения плана работ:
План работ
| N | Виды работ для устранения проблемы | Ответственные | Трудности и ограничения | Выполнено |
|---|---|---|---|---|
| 1 | Установить сервис на автозапуск | Иванов И.И. | нет | да |
| 2 | Поставить службу на мониторинг | Петров П.П. | нужно настроить item-ы Zabbix-а | нет |
| ... | ... прочие работы ... | Сидоров С.С. | ... | нет |
V. Возможные улучшения
В этом разделе описываем по шагам, какие действия нужно предпринять, чтобы избежать этой проблемы в будущем. Это могут быть как технические, так и улучшения существующих регламентов.
Пример заполнения:
Возможные улучшения
- В сценарии установки CI-агентов добавить скрипты для автоматического включения сервиса при перезагрузке ОС.
- При начальной установке и настройке CI-агента сразу добавлять службу на мониторинг.
- Написать регламенты обновления ОС и CI-агентов.
- Внести в регламенты работ на инфраструктуре пункт согласования обновлений с продуктовыми командами.
- Составить operational manual для задач обновления ОС и CI-агентов, включающий в себя план обновления и отката инфраструктуры.
- ... прочие возможные улучшения ...
