Инцидент - это проверка процесса, а не компетенций

Инцидент - это проверка процесса, а не компетенций

Инцидент почти всегда начинается одинаково. Срабатывает мониторинг, прилетает алерт, в чате уведомление об инциденте и через минуту там уже с десяток людей. Присутствующие пытаются помочь (или делают вид), все пишут, предлагают решения, в то же время кто-то уже шатает кластер, кто-то шевелит витую пару под стулом, другой бегает в панике с валидолом под языком… С виду - активная работа, все вовлечены. По факту - шум.

Опасность здесь даже не в потере времени, а потери будут и достаточно ощутимые. Но хуже другое. В хаосе начинаются параллельные правки и действия. Кто-то подкручивает конфиг, кто-то делает откат, кто-то деплоит «маленький фикс на всякий случай», кто-то добавляет правил на WAFе. Эти действия редко согласованы между собой, но почти всегда меняют состояние системы. В итоге локальный сбой легко превращается в более крупный непредсказуемый инцидент, уже с другим масштабом и последствиями. Где на постмортеме понять что было и как вышли из «штопора» тоже не понятно, но главное же, что сейчас все работает, да? нет.

В Site Reliability Engineering Google такие ситуации называют «авариями, вызванными процессом». Первопричина может быть в коде, но реальный урон возникает из-за несогласованных действий. Фокус размазывается, важные сигналы теряются, ответственность становится размытой.

Хаос появляется там, где нет фокуса. В момент инцидента фокус должен быть один - понять, что именно сломалось, и вернуть сервис в рабочее состояние. Для этого системе нужен порядок, даже если он очень простой.

Обычно достаточно явного разделения функций:

⚡️Fixer - человек, который занимается техническим расследованием и исправлением. Он не участвует в обсуждениях и не отвечает на вопросы, потому что любое отвлечение замедляет восстановление. Напр.: DevOps, DBA и тд.

⚡️Координатор - держит общую картину, фиксирует факты, формулирует рабочую гипотезу и следит, чтобы правки не делались хаотично. Напр.: тех. владелец подсистемы/сервиса.

⚡️Коммуникатор - берёт на себя внешний шум. Статусы, бизнес, поддержка. Коротко и без технических подробностей. Напр.: ПМ поддержки.

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

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

Инциденты редко проверяют уровень экспертизы команды. Гораздо чаще они показывают, есть ли у неё процесс и выдерживает ли он давление.

Кстати книжка по SRE от Байера, Джоунса и др. mast-read, есть ответы куда приложить лед, если часто подгорает, как от крыльев ростикс.