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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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