Стихийное появление множества участников реагирования может казаться помехой, которая рушит наши аккуратные представления об управлении инцидентами, — на самом деле это мощный ресурс. Такое поведение нужно поощрять и поддерживать, а не просто терпеть.
Большинство из нас представляет реагирование на инциденты примерно линейным: дежурный инженер получает оповещение, решает, что ситуация требует объявления инцидента, и вызывает командира инцидента (incident commander, IC). IC создаёт канал инцидента и добавляет ещё нескольких участников. Пока всё логично.
Что удивляет многих — уже через несколько минут в инцидент без всякого вызова начинают стягиваться дополнительные люди. Один руководитель в компании, где я работал, называл это «реакцией белых кровяных телец»: что-то идёт не так, и люди стихийно собираются, чтобы помочь чем могут.
Зачем они приходят? По разным причинам. Одни — инженеры, которые узнают симптомы по прошлому опыту или понимают, что затронуты их системы. Другие — из службы поддержки, отдела по работе с клиентами или продуктовой команды: они следят за ситуацией, чтобы понять, как она повлияет на их зону ответственности.
Многие из них приходят не расследовать, а наблюдать — и готовы подать голос, если им есть что добавить. В этом одно из преимуществ ведения инцидентов в Slack, а не в Zoom: люди могут следить за происходящим и высказываться, не мешая остальным. Им не нужно ждать паузы в разговоре или преодолевать себя, чтобы прервать кого-то. По моему опыту, именно это заставляет множество ценных наблюдений оставаться невысказанными.
Всех этих добровольцев объединяет одно: это занятые специалисты, которые решили, что инцидент заслуживает их внимания. Это организационный актив, который стоит признать, развивать и использовать.
Как же поддерживать и поощрять такое поведение? Начните с понимания того, как инциденты разворачиваются на самом деле.
Модель против реальности
Большинство процессов управления инцидентами строится вокруг аккуратной модели: что-то происходит, объявляется инцидент, командир инцидента вызывает нужных людей, те откликаются, и организованное реагирование идёт своим чередом. Это полезная модель, достаточно хорошо описывающая формальную структуру реагирования, но, как и любая модель, она имеет свои ограничения.
Реальные инциденты куда запутаннее. Люди узнают о проблемах самыми разными путями. Инженеры начинают расследование до того, как инцидент официально объявлен. Добровольцы появляются раньше, чем IC завершает первый круг вызовов. К тому моменту, когда формальное реагирование организовано, значительная часть фактического уже идёт — скоординированно или нет.
Нередко стая собирается вообще без каких-либо инструментов для управления инцидентами. Инженер, расследующий проблему, просит помощи у коллеги. Тот привлекает ещё одного. Вскоре импровизированная команда работает над срочной и серьёзной проблемой в каком попало месте — как правило, в рабочем канале команды, где это перемешивается с «куда идём обедать?» и сообщениями ботов о новых PR и деплоях. В конце концов кто-нибудь спрашивает: «Слушайте, а может, нам стоит оформить это как инцидент?» (Совет знатока: ответ на этот вопрос почти всегда однозначное «да!»)
Когда я руководил управлением инцидентами в Slack, мы держали постоянный канал #incident-next — готовый для всех, кто в нём нуждается. Любой, кто расследовал проблему, мог направить туда людей, чтобы начать совместную работу в сфокусированном пространстве, отдельном от командного канала, где всё и началось. При объявлении инцидента канал переименовывался в официальный инцидентный — с сохранением всего контекста, истории расследования и уже присутствующих участников, а новый пустой #incident-next создавался для следующего инцидента. Это простой механизм, который любая компания может внедрить прямо сегодня, и он напрямую поддерживает стихийный сбор: люди сходятся, начинают расследование, а формальное объявление инцидента догоняет то, что уже происходит. Реагирование идёт полным ходом ещё до того, как появляется структура, призванная его поддержать и упорядочить.
Большинство компаний проектируют свой процесс только для аккуратной модели и потом расстраиваются, когда реальность не совпадает с ней. Лучше проектировать процесс под то, как инциденты разворачиваются в действительности, — а значит, с учётом стихийного сбора как возможности или даже чего-то, что следует поощрять.
Почему это работает
В модели реагирования, целиком основанной на командах, кто-то должен разобраться, какие команды задействованы, вызвать нужных дежурных инженеров, дождаться их реакции, ввести в курс дела и раздать задачи. Будь то командир инцидента или технический лидер, каждый шаг узким местом проходит через знания и суждения одного человека. Если они вызвали команду по сети, а проблема оказалась в слое кеширования — время потеряно на перегруппировку и новый вызов. Экспертизу можно направить лишь настолько точно, насколько точна диагностика, а в первые минуты инцидента диагноз часто ошибочен.
Стихийный сбор обходит это узкое место. Люди с нужными знаниями сами приходят — нередко раньше, чем IC или техлид вообще осознаёт, что их экспертиза нужна. Инженер, который делал связанное изменение сегодня утром, тот, кто видел похожую картину отказа в прошлом месяце, тот, кто случайно знает, что слой кеширования вчера вёл себя странно — они появляются, потому что видят: что-то не так, и им есть что предложить. Никто из руководящих реагированием не смог бы так быстро вызвать всех нужных людей, потому что никто не знал бы, кто эти нужные люди.
При небольшом инциденте этого зачастую достаточно. Несколько знающих людей сходятся, естественным образом делят работу, и проблема решается быстро — иногда быстрее, чем успело бы организоваться формальное реагирование.
При крупных инцидентах стихийный сбор приводит нужных людей быстрее любого процесса вызовов. IC всё так же координирует реагирование, но вместо того чтобы сорок минут выяснять, кого звать, и ждать ответа, он организует людей, которые уже здесь и готовы работать. Это принципиально лучшая стартовая позиция. Фокус в том, чтобы пространство было готово принять собравшихся.
Когда это не так, тот же инстинкт, что движет стихийным сбором, порождает самодеятельность: люди расследуют проблему каждый сам по себе, без координации, потому что организованного реагирования просто не было. Те же мотивированные люди — совершенно другой результат.
Как поддержать стихийный сбор
Если стихийный сбор настолько эффективен, почему он хорошо работает не везде? Во-первых, люди должны чувствовать себя в безопасности, приходя незваными. В культуре, где добровольное участие в инциденте грозит обвинением, если что-то пойдёт не так, инстинкт самоорганизации подавляется в зародыше. Это более глубокая проблема, чем то, что можно решить дизайном процессов, — но её стоит назвать.
Если культура это поддерживает, два практических момента определяют, работает ли стихийный сбор:
Могут ли люди найти место реагирования? Когда кто-то узнаёт о проблеме — будь то упоминание коллеги о том, что оформление заказа сломано, оповещение в командном канале или всплеск ошибок на дашборде — узнают ли они заодно, что уже ведётся организованное реагирование?
Возможно, это канал #all-incidents, куда автоматически отправляется объявление о каждом объявленном инциденте со ссылкой на его канал. Активные инциденты, отображаемые на дашбордах, которые люди и так проверяют. Предсказуемое соглашение об именовании каналов инцидентов — чтобы любой мог ввести #inc- в Slack и с помощью автодополнения увидеть, что сейчас активно. Интеграция с платформой чата, чтобы люди, обсуждающие проблему в своих командных каналах, получали указатель на организованное реагирование.
Цель — сделать так, чтобы каждый, кто узнаёт о проблеме, как бы он о ней ни узнал, также узнавал, где собираются люди.
И могут ли они легко подключиться? Оказавшись в нужном канале, люди должны видеть понятный путь включения. Закреплённое сообщение с текущей ситуацией, ролями и направлениями расследования. Чёткое ожидание: новые участники представляются и обозначают свою экспертизу, затем самостоятельно вводят себя в курс дела — читают историю канала и последний ситуационный отчёт, прежде чем просить задачу. Достаточная структура, чтобы за несколько минут сориентироваться и начать вносить вклад, а не упираться в стену скроллбека без понятного способа подключиться.
Ничего сложного. Но всё это требует осознанного проектирования. Инстинкт стихийного сбора возникает сам по себе. Инфраструктура, делающая этот сбор продуктивным, — нет.
Вложитесь в инстинкт
Если ваша команда уже стихийно собирается на инциденты — у вас есть нечто бесценное: люди, которым не всё равно. Остальное — инфраструктура: сделать реагирование видимым, упростить вход в него и дать IC инструменты для организации растущей группы на ходу.
Этот инстинкт нельзя создать искусственно. Но можно сделать его значительно эффективнее.
Стихийный сбор — одна из тем, которые я подробно рассматриваю в своей готовящейся книге Incident Management for DevOps and SRE. Если хотите узнать о выходе книги, подпишитесь на im4ds.com. А если вашей компании прямо сейчас нужна помощь с управлением инцидентами, моя консалтинговая практика — greatcircle.com/im.