Важность реагирования на инциденты

  • 3 мин

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

Что такое инцидент?

Реагирование на инциденты связано с действиями, выполняемыми при возникновении инцидента, но что именно представляет собой инцидент? Ответ может быть субъективным; даже все инженеры не согласны с тем, что такое инцидент. Если задать вопрос в разных отраслях и организациях, вы получите множество различных ответов.

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

Что такое реагирование на инциденты?

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

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

Ваш подход реагирования на инциденты определяет эффективность:

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

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

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

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

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

Важно знать, насколько хорошо ваша организация обрабатывает реагирование на инциденты. Каждый год организация DevOps Research and Assessment (DORA) выпускает отчет state of DevOps. Некоторые ключевые выводы в докладе 2019 года сосредоточены на производительности реагирования на инциденты.

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

Разница между этими уровнями имеет значительное значение. Исследование показало, что элитные/высокопроизводительные команды восстанавливаются после инцидентов в 2604 раза быстрее, чем их «низкопроизводительные» коллеги. Ведущие исполнители также развёртываются в производственную среду в 208 раз чаще.

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

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