Close

Управление инцидентами для высокоскоростных команд

Важность процесса разбора инцидентов

Инциденты случаются.

Такова данность. Когда увеличиваются масштаб и сложность систем, сбои и инциденты становятся неизбежными.

Но инциденты также предоставляют возможности для обучения.

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

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

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

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

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

Рисунок: цикл разбора инцидента

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

Преимущества разбора инцидента

У вас может возникнуть соблазн не проводить официальное собрание по разбору инцидента и не составлять письменный отчет, особенно если вы уверены, что знаете причину инцидента и что проблема исправлена.

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

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

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

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

Рекомендации по проведению разбора инцидента

Ваш подход к проведению разбора инцидента так же важен, как и план действий. На фоне инцидента обстановка может стать весьма напряженной. Чтобы люди могли активно участвовать в процессе и были готовы к решению сложной проблемы, необходимо дать им чувство психологической безопасности.

Установите культуру без поиска виновных

Бывший технический директор компании Etsy Джон Оллспоу написал знаковую статью о разборе инцидентов без поиска виновных. Если инцидент рассматривается в таком ключе, вовлеченные в него сотрудники могут рассказать обо всех своих действиях и их последствиях, а также о том, что и когда им было известно, не опасаясь наказания или возмездия.

Применяя этот подход, вы создаете условия для свободного обмена информацией между командами и выявления основной причины инцидента. Если человек боится упреков, он может утаить информацию или пытаться переложить вину на других. В таких ситуациях люди перестают доверять друг другу, а организация теряет возможность построить крепкие команды и отказоустойчивые системы. Чтобы избежать этих подводных камней, многие команды, в том числе в Atlassian и Google, взяли за правило проводить разборы инцидентов без поиска виновных.

Избегайте поиска виновных, придерживайтесь конструктивной критики

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

Чтобы разрешить инцидент, недостаточно просто обсудить его без обвинений и предвзятости. Важно также определить его основную причину. Для этого на собрании можно использовать метод пяти «почему». Сначала убедитесь, что все одинаково понимают, в чем заключается проблема. Затем спросите, почему эта проблема возникла, и к полученному ответу снова задайте вопрос «почему». Повторите этот вопрос по крайней мере пять раз, чтобы наверняка раскрыть все глубинные факторы, которые привели к проблеме. Следите, чтобы никто не закрывал глаза на неудобную правду и не пытался слишком легко добиться согласия. Подробнее о методе пяти «почему» можно прочитать в сценарии из нашего сборника.

Проверяйте каждый проведенный разбор. Сделайте это регулярной практикой

Если отчет о разборе инцидента не проверяется, то он не принесет пользы. После составления черновой версии отчета важно проверить его, чтобы дать ответ на все нерешенные вопросы и зафиксировать идеи на будущее. После этого у вас на руках будет окончательная версия отчета. Можно сказать, что без такой проверки инцидент не будет по-настоящему разрешен.

Как это организовать? Запланируйте с инженерами (и всеми заинтересованными сторонами, такими как служба поддержки клиентов и менеджеры по работе с клиентами) собрание, которое будет проводиться по крайней мере раз в месяц и на котором вы будете проверять отчеты по разбору инцидентов. Вы можете просматривать недавние и более ранние отчеты, чтобы изучать актуальные выводы.

Эффективный план разбора инцидента

Чтобы ретроспективы приносили результат и способствовали формированию культуры непрерывного совершенствования, нужен простой и воспроизводимый процесс, в котором каждый сможет принять участие. Реализация такого процесса будет зависеть от вашей культуры и команды. В компании Atlassian разработали собственный метод. Подробнее о нем можно прочитать в нашем справочнике по работе с инцидентами.

Вот несколько советов, которые помогут вам начать работу.

Совет 1. Задайте порог

Уровни опасности инцидентов в организации должны быть четкими и измеримыми. Они могут использоваться для инициирования процесса разбора инцидента. Например, любой инцидент уровня опасности 1 или выше инициирует процесс разбора, а для менее серьезных инцидентов разбор необязателен. При этом подумайте над тем, чтобы предоставить руководителям команды или компании возможность запрашивать проведение разбора для любого инцидента, который не соответствует заданному порогу.

Совет 2. Не медлите

После инцидента важно сделать перерыв и немного отдохнуть. Но не откладывайте написание разбора инцидента на слишком долгий период, иначе можно забыть или потерять важные сведения. В идеале он составляется сразу после собрания по разбору инцидента, которое проходит в течение 24–48 часов (но не более пяти рабочих дней) после разрешения инцидента.

Совет 3. Назначьте роли и владельцев

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

Совет 4. Работайте по шаблону

Шаблон поможет вам не упустить важные детали и поддержать единообразный вид всех разборов.

Совет 5. Добавьте хронологию

Хронология — это крайне полезный инструмент в документации по инциденту. Зачастую прежде всего на нее обращают внимание читатели, когда пытаются быстро определить масштаб произошедшего. Старайтесь использовать максимально понятные и точные формулировки. Например, пишите «11:14 по стандартному тихоокеанскому времени», а не «около 11». Указывая точное время, вы выстраиваете достоверную цепочку событий. С ее помощью вы сможете выявить области для улучшения. Так вы можете обнаружить, что промежуток между проявлением последствий инцидента и уведомлением клиентов был слишком долгим.

Вот важные события, которые необходимо отразить в хронологии.

  • Первое оповещение или заявка.
  • Первое объявление об инциденте (внутреннее и [или] внешнее).
  • Обновления страницы статусов.
  • Все попытки устранения проблемы (откаты кода и т. д.).
  • Время разрешения.

Совет 6. Подробности, подробности, подробности

Если вы поскупитесь на подробную информацию, скорее всего, ваш отчет о разборе инцидента окажется бесполезным и непонятным. Сообщайте как можно больше подробностей о произошедшем и предпринятых во время инцидента действиях. Не стоит писать «Затем было отправлено сообщение для информирования общественности». Сформулируйте фразу так: «Мы оставили первое сообщение для информирования общественности об инциденте на нашей публичной странице статусов и в Twitter».

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

Совет 7. Зафиксируйте показатели инцидента

Фиксируя показатели в отчете о разборе инцидента, вы подкрепляете описание проблем и их последствий объективными данными. Благодаря этим данным вы можете убедиться, что ваша команда движется в верном направлении, а также уменьшить количество инцидентов, понизить их уровень опасности и сократить продолжительность простоя. Когда показатели замеряются на систематической основе, можно сделать шаг назад и оценить динамику развития инцидента с течением времени.

Вот некоторые показатели, которые следует учитывать в разборе инцидента.

  • Продолжительность простоя в минутах. Отслеживая этот показатель, можно понять, увеличивается это значение или уменьшается.
  • Уровень опасности инцидента. С помощью этого показателя можно определить относительную надежность систем.
  • Среднее время разрешения (MTTR). По этому показателю можно понять, сколько в среднем времени нужно для разрешения инцидента с момента первого сообщения о нем.

И самый важный совет: не пропускайте ни один из этих шагов. Чтобы проводить разбор инцидентов с пользой для команды и систем, вам нужно разработать процесс и следовать ему.

Использование шаблона разбора инцидента для оптимизации процесса

Используйте стандартные списки задач и шаблоны, чтобы создать условия для формирования надлежащей культуры с проверкой разборов инцидентов. Благодаря им становится проще собирать информацию, планировать собрания и публиковать окончательный отчет. Воспроизводимый процесс — ключ к единообразию. Когда люди знают, чего им ожидать, они приходят на разбор инцидентов готовыми к плодотворной работе.

Так выглядит стандартный список задач для разбора инцидента.

Ниже перечислены необходимые собрания.

  • Собрание по сбору информации
  • Проверка отчета
  • Презентация отчета

Ниже приведена информация, которую нужно собрать заранее.

  • Стандартные повестки дня для каждого собрания
  • Участники, заинтересованные стороны, проверяющие
  • Шаблон отчета по разбору инцидента
продолжение темы
Template