Управление инцидентами для высокоскоростных команд
Общие сведения об уровнях опасности инцидентов
Выявляйте инциденты и расставляйте приоритеты, чтобы быстрее устранять их
Существуют три главных аксиомы управления инцидентами.
Согласно первой, инциденты неизбежны. Особенно в постоянно растущих компаниях, которые внедряют инновации.
Согласно второй аксиоме, эффективная методика управления инцидентами имеет решающее значение для благополучия компании (а неэффективная отнимает время у сотрудников, ведет к их неудовлетворенности и снижает доходы бизнеса).
Согласно третьей аксиоме, инциденты отличаются важностью. Потеря данных одной базы — не то же самое, что потеря всех баз данных. Отказ, затронувший 20 % пользователей, и отказ, затронувший 90 или даже 100 % пользователей, — кардинально разные инциденты. Восстановить систему после сбоя при пиковой нагрузке намного сложнее, чем когда большинство клиентов спит. Даже инциденты, которые на бумаге идентичны, по сути своей уникальны.
Управление инцидентами для высокоскоростных команд
Ускорьте обмен информацией между командами эксплуатации и разработки для реагирования на инциденты и восстановления систем с помощью Jira Service Management.
Именно поэтому компании с надежными программами управления инцидентами устанавливают четкие уровни опасности инцидентов и понятные рекомендации по определению их приоритета.
Что такое уровни опасности?
Уровни опасности измеряют влияние инцидента на компанию. Обычно чем меньше порядковый номер уровня, тем серьезнее последствия инцидента.
Например, в Atlassian уровень опасности 1 означает «критический инцидент с очень большими последствиями». К таким инцидентам можно отнести потерю данных клиента, нарушение безопасности или отказ сервиса и его недоступность никому из клиентов.
Уровень опасности 2 — это «серьезный инцидент со значительными последствиями». Например, недоступность сервиса для части клиентов, отказ критически важной функции системы.
Уровень опасности 3 означает «несерьезный инцидент с незначительными последствиями». Это может быть неполадка системы, приводящая лишь к небольшому неудобству для клиентов.
В Atlassian работа над инцидентами уровня опасности 3 ведется днем (в рабочие часы). При возникновении инцидента уровня опасности 1 или 2 дежурные специалисты получают оповещение в любое время суток и сразу приступают к устранению.
| Опасность | Описание | Примеры |
|---|---|---|
| 1 | Критически опасный инцидент с очень большими последствиями |
|
| 2 | Серьезный инцидент со значительными последствиями |
|
| 3 | Несерьезный инцидент с незначительными последствиями |
|
Благодаря уровням опасности можно быстро оценить последствия и расставить приоритеты для команд ИТ и DevOps.
Чем точнее уровни опасности, тем вероятнее, что участники команды будут в курсе происходящего и смогут быстро и правильно отреагировать на инцидент. Без четких уровней опасности высока вероятность впустую потратить ценное время на то, чтобы определить и обосновать срочность инцидента, когда можно было бы заняться его устранением.
Когда и в каких случаях полезны уровни опасности?
Главная ценность уровней опасности заключается в том, что они экономят время команд. Если команда знает уровни опасности и имеет понятную дорожную карту обработки инцидентов каждого уровня, она может сразу начать решать проблему. Не определив уровни опасности, команда, скорее всего, в первые решающие минуты серьезного инцидента будет пытаться понять, насколько он важен, кто должен им заняться и как его устранить.
Чем критичнее инцидент, тем важнее сэкономить как можно больше времени, предусмотрев не только способы его устранения и передачи информации о нем, но и четкие уровни опасности и приоритеты.
Различия между опасностью и приоритетом
На первый взгляд кажется: чем серьезнее инцидент, тем выше должен быть его приоритет. Логично ведь, что серьезным инцидентом с катастрофическими последствиями нужно заняться раньше, чем менее значительным.
Однако на самом деле для большинства компаний все сложнее.
Серьезность — это оценка воздействия инцидента. Как сильно инцидент влияет на пользователей? Отказала вся их система? Пользователи не могут выполнять критически важные задачи? Или проблема просто доставляет неудобства и усложняет работу?
С другой стороны, приоритет — это оценка срочности. Как быстро нужно исправить проблему? Какую проблему решать в первую очередь?
Иногда обе оценки совпадают. Инцидент высокого уровня серьезности, из-за которого остановилась деятельность всей компании, с большой вероятностью имеет для команд DevOps и ИТ наивысший приоритет.
Но порой приоритет и серьезность не совпадают. Предположим, в заголовке главной страницы веб-сайта нашлась опечатка. Эта проблема имеет низкий уровень серьезности, поскольку не влияет на функционирование веб-сайта. Пользователи по-прежнему могут решать свои задачи, равно как и сотрудники.
Но компания может дать исправлению опечатки высокий приоритет по соображениям стандартов бренда или потому, что ошибка создает путаницу или плохо влияет на имидж компании. Тогда уровень серьезности этого инцидента будет низким, а приоритет — высоким.
Другой пример — инцидент, приводящий к сбою приложения. Это инцидент высокого уровня серьезности, потому что пользователи не могут решать свои задачи. Однако проблема затрагивает, скажем, лишь 0,05 % пользователей. Если параллельно возникли инциденты, которые затронули больше пользователей, приоритет первой проблемы можно понизить, хотя обычно слова «сбой системы» сигнализируют об аврале.
В управлении инцидентами применяются обе оценки, однако важно понимать, когда они совпадают, а когда нет. Высокий уровень серьезности инцидента не означает, что его устранение автоматически становится первоочередной задачей. А приоритет номер один — не всегда восстановление отказавшей системы.
На практике полезнее знать приоритет, чем уровень серьезности, и это основная оценка, которую компания Atlassian использует в Opsgenie. А поскольку уровень серьезности часто является ключевым фактором, влияющим на приоритет, мы привели точные определения в нашем справочнике по работе с инцидентами в рамках собственной методики управления инцидентами.
Определение уровней опасности инцидентов для организации
Инциденты отличаются важностью, и не во всех организациях их обрабатывают одинаково. При формировании уровней опасности и процессов, а также своих ожиданий относительно них, помимо влияния инцидента, нужно учитывать следующие факторы.
- Размер технической команды
- Расписания дежурств
- Часы высокой и низкой нагрузки на сервис
- Частота возникновения инцидентов
Почему? Потому что каждый из факторов может повлиять на определение уровней опасности.
Например, в использовании приложения, обслуживающего местные рынки в одном часовом поясе, может наблюдаться длительный перерыв с 02:00 до 07:00. Поэтому уровень опасности отказа всей системы в 03:00 будет ниже, чем в часы пиковой нагрузки.
Что насчет небольшой команды стартапа, которая часто сталкивается с инцидентами уровня опасности 3? Стоит ли относить их к этой категории, а команде дать возможность самостоятельно распределять приоритеты при возникновении, скажем, сразу трех инцидентов? Или лучше дополнительно выделить уровни опасности 3, 4 и даже 5, чтобы разграничить частичный отказ функций клиентской системы, проблемы с производительностью и — еще более мелкая градация — например, ошибки, не влияющие на удобство использования системы, но так или иначе требующие устранения?
Главное — знать свою компанию и свою команду и определить уровни опасности и приоритеты наилучшим для себя образом.
| 3 уровня Atlassian | 4 уровня | 5 уровней | |
|---|---|---|---|
| Уровень опасности 1 | Критический инцидент с очень большими последствиями. | ||
| Уровень опасности 2 | Серьезный инцидент со значительными последствиями. | ||
| Уровень опасности 3 | Несерьезный инцидент с незначительными последствиями. Пример: ошибка в системе, приводящая к незначительным неудобствам для клиентов. | Инцидент, который может стать серьезным, если его быстро не устранить. | |
| Уровень опасности 4 | Запрос в службу поддержки о проблеме, доставляющей клиенту неудобства; функционирование системы в целом не затронуто. | Незначительный инцидент, влияющий на удобство использования продукта, но не вызывающий отказ. | |
| Уровень опасности 5 | Ошибки или проблемы, не влияющие на удобство использования продукта. | ||
Крайне важно иметь решение для управления инцидентами, чтобы эскалировать их и немедленно привлекать нужные команды к коллективному разрешению.
Ознакомьтесь со всеми возможностями Jira Service Management по управлению инцидентами, включая оповещения и расписания дежурств, средства совместной работы и мощные возможности по составлению отчетности и аналитике, с помощью которых команды могут реагировать на инциденты, разрешать их и делать по ним выводы.
Изучайте информирование об инцидентах с помощью Statuspage
В этом руководстве мы покажем, как использовать шаблоны инцидентов, чтобы наладить эффективную коммуникацию во время разрешения инцидента. Применимо ко многим видам технических сбоев.
Читать учебное руководствоШаблоны и примеры информирования об инцидентах
Во время реагирования на инциденты становится ясна ценность шаблонов сообщений. Загрузите шаблоны, которые использует наша команда, и познакомьтесь с другими примерами распространенных инцидентов.
Читать статью