Вы видите, как кто-то объявляет инцидент второго уровня серьёзности (Sev-2), и недоумеваете: погодите, почему это вообще инцидент? Ничего не упало. Клиенты не пострадали. Просто менеджеру нужно было поднять проблему своей команды на вершину очереди приоритетов другой команды, а процесс управления инцидентами оказался надёжным способом этого добиться. Формально это не то, для чего инцидентный процесс существует, — но сработало, так что какой вред?
Проблема в том, что когда люди видят, что это работает, подобное начинает повторяться всё чаще. Продуктовый менеджер объявляет инцидент, потому что уведомление об инциденте — самый быстрый способ привлечь внимание руководства к проблеме, которая неделями пылится в бэклоге. Команда по работе с клиентами объявляет инцидент, потому что им нужна инженерная поддержка для большого демо важному потенциальному заказчику, а инцидентный процесс — самый простой способ выдернуть инженеров из спринта в короткие сроки. Инженер объявляет инцидент, потому что это проще, чем проходить официальную процедуру исключения в период заморозки деплоев.
Вред накапливается постепенно. Когда растущая доля объявленных «инцидентов» не является настоящими чрезвычайными ситуациями, сигнал срочности деградирует. Когда приходит настоящий Sev-1, люди реагируют с меньшей серьёзностью — их уже приучили ожидать очередной обходной манёвр. Стимулы усугубляют ситуацию: те, кто злоупотребляет системой, решают свои проблемы быстрее, а это учит всех остальных, что именно так и нужно действовать. Каждое отдельное объявление — понятное решение человека, которому нужно что-то сделать; разрушает процесс именно их совокупность.
Каждое такое псевдоинцидентное объявление несёт в себе все накладные расходы реального инцидента. Ответственные сотрудники бросают запланированную работу. Кто-то прерывает всё, чем занимался, чтобы стать командиром инцидента (incident commander). Стейкхолдеры переключают контекст, чтобы следить за происходящим. Когда подобных случаев накапливается достаточно много, команды тратят значительную часть времени в режиме аварии на то, что аварией не является, — и все косвенные издержки инцидентов (сорванные проекты, переключение контекста, время на восстановление) накапливаются ровно так же.
Здесь есть ирония: люди тянутся к инцидентному процессу именно потому, что он работает — они видят, что он надёжно обеспечивает координацию, расстановку приоритетов и срочность по требованию.
Инстинктивная реакция — неправильная
Когда компании замечают эту закономерность, инстинктивной реакцией нередко становится ужесточение критериев объявления инцидентов. Вводится контроль доступа: возможно, теперь нужно одобрение менеджера, чтобы объявить инцидент, или существует чек-лист, который нужно заполнить заранее, или кто-то проверяет после факта, было ли объявление «обоснованным». Намерение понятно. Реальный эффект — разрушительный.
Контроль над объявлением инцидентов контрпродуктивен. Каждый барьер, который вы выстраиваете, замедляет и настоящие инциденты. Человек, который колеблется с объявлением, потому что не уверен, достаточно ли серьёзна проблема, — уже типичный сбой в реагировании на инциденты. Добавление формального шага согласования или ретроспективной проверки обоснованности объявления усиливает это колебание, а не устраняет его.
Вы также упускаете то, о чём говорит злоупотребление процессом: люди, прибегающие к нему в обход, сигнализируют вам, что обычные процессы дают сбой. Если просто бороться со злоупотреблениями, вы подавляете симптом, ничему не научившись, — а глубинные проблемы никуда не деваются.
Исправляйте лазейки, а не тех, кто в них пролезает
Вместо этого посмотрите, какие побочные эффекты люди пытаются получить, объявляя сомнительные инциденты, и сделайте эти возможности доступными другими способами.
Если самый простой способ обойти заморозку деплоев — объявить инцидент, создайте неинцидентный процесс исключения для срочных изменений. Это не обязательно должно быть сложным: лёгкое согласование с назначенным релиз-менеджером и чёткий путь эскалации закрывают большинство случаев.
Если самый простой способ поднять вашу проблему в очереди приоритетов другой команды — объявить инцидент, создайте путь эскалации приоритизации, не требующий инцидента. Кросс-командная встреча по триажу, явный механизм запроса ускоренного рассмотрения или даже отдельный Slack-канал, за которым действительно следят нужные люди, способны снять большую часть давления. Порог не обязан быть таким же высоким, как «объявить чрезвычайную ситуацию» — он просто должен быть ниже, чем «ждать шесть недель до следующего цикла планирования».
Если самый простой способ быстро собрать кросс-функциональную команду — воспользоваться инцидентным процессом, создайте лёгкий механизм координации для неинцидентных ситуаций. В некоторых компаниях их называют «роями» (swarms), «тигровыми командами» (tiger teams) или «запросами на координацию» (coordination requests). Название не важно; важно, чтобы у людей был способ получить нужное им взаимодействие, не одалживая для этого инцидентный процесс.
Систематическое злоупотребление инцидентным процессом ради расстановки приоритетов ресурсов или кросс-функциональной координации — это не серия разовых обходных манёвров, а симптом системной проблемы, требующей системного ответа. SRE-организация Google выстроила специальные механизмы Code Yellow и Code Red именно для этого: структурированные способы мобилизовать ресурсы и повысить приоритет, когда проблема достаточно серьёзна, чтобы требовать кросс-функционального внимания, но инцидентом при этом не является.
Диагностический вопрос
Просмотрите последний десяток или около того инцидентов и для каждого спросите себя: этот инцидент был объявлен потому, что существовала чрезвычайная ситуация, или потому, что инцидентный процесс оказался более простым путём к тому, что было нужно команде?
Формальный аудит не нужен. Просто спросите нескольких опытных командиров инцидентов и дежурных инженеров — они уже знают, какие из них были настоящими, а какие нет. Затем поговорите с теми, кто объявлял сомнительные (в безоценочной манере, ориентированной на поиск фактов, разумеется). Они расскажут вам именно то, чего не хватает в обычных процессах, — если вы готовы слушать.
Злоупотребление инцидентным процессом — лишь симптом. Глубинная проблема, как правило, состоит в том, что обычные процессы слишком жёсткие, слишком медленные или слишком нечувствительные, а инцидентный процесс — путь наименьшего сопротивления. Устраните глубинную проблему — и злоупотребления прекратятся, потому что обходить станет нечего. Сигнал срочности инцидентов восстановится, команды перестанут сжигать циклы аварийного режима на то, что аварией не является, — и когда придёт настоящий Sev-1, люди отреагируют так, как будто это действительно важно.
И если вы сталкиваетесь с этим, найдите момент, чтобы оценить, что это говорит о вашем инцидентном процессе: люди берут его в долг, потому что он работает. Решение не в том, чтобы заставить его перестать работать. Решение в том, чтобы всё остальное работало так же хорошо.