Постмортем как неотъемлемая часть работы инженера

Разберемся что такое постмортем и как отделять мух от котлет работу от текучки


Инженерная работа vs операционная текучка

Невзирая на особенности организационной структуры и ежедневной рутины, каждая команда имеет свой набор обязанностей по отношению к обслуживающему сервису.
Любая инженерная команда всегда отвечает за:
• доступность
• время отклика
• производительность
• эффективность
• управление изменениями
• мониторинг
• реагирование в аварийных и предаварийных ситуациях
• планирование производительности для своих сервисов.
Рабочее окружение инженерной команды это не только промышленная среда, но и команды разработки, тестирования, нередко и сами пользователи. Только после осознания этого факта ощущается разница между инженерными задачами и текучкой.

Хорошо, когда инженер тратит не более 50% своего времени на обработку запросов на обслуживание и сопровождение внедрений. В таком случае, остальное время используется для работы над проектами. А проекты — это отличный плацдарм для прокачивания своих hard skills.
Этого показателя можно достичь на практике путем наблюдения за количеством операционной работы, выполняемой командой инженеров. Все, что выходит за рамки 50% — перенаправлять на команды разработки заранее согласованным и утвержденным маршрутом для последующей автоматизации, желательно без ручного участия. Этот способ обеспечивает эффективную обратную связь, ориентируя разработчиков на создание систем, не требующих человеческого вмешательства. Чтобы такой подход работал, все команды внутри компании должны понимать почему это ограничение существует.

Постмортем

Опираясь на опыт работы наших самых больших коллег, оптимальное число критических событий для обработки не должно достигать более трех за 8-часовую смену на дежурстве. В таком случае, инженеру точно удастся обработать событие и восстановить сервис, а затем проанализировать первопричину произошедшего. Если событий больше чем три, то у инженеров не получится предотвратить аналогичные ошибки в будущем.
Стоит обратить внимание на то, что если инженер стабильно получает меньше критических событий за дежурство, то нельзя считать его работу на месте дежурного пустой тратой времени. Есть легенда, что в крупных зарубежных компаниях инженерам, отвечающим за стабильность сервисов, платят щедрые бонусы, когда все сервисы в зоне их ответственности показывают пресловутые «пять девяток» доступности (если это не так, то дайте знать).

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

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

#engineering #sre #management