Close

Путь к успешному управлению инцидентами начинается здесь

Просмотр тем

Общие сведения об уровнях опасности инцидентов

Выявляйте инциденты и расставляйте приоритеты, чтобы быстрее устранять их

Существуют три главных аксиомы управления инцидентами.

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

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

Согласно третьей аксиоме, инциденты отличаются важностью. Потеря данных одной базы — не то же самое, что потеря всех баз данных. Отказ, затронувший 20 % пользователей, и отказ, затронувший 90 или даже 100 % пользователей, — кардинально разные инциденты. Восстановить систему после сбоя при пиковой нагрузке намного сложнее, чем когда большинство клиентов спит. Даже инциденты, которые на бумаге идентичны, по сути своей уникальны.

Логотип OpsGenie

Узнайте о подходе Atlassian к управлению инцидентами

Сегодня как никогда важен быстрый и простой процесс управления инцидентами.

Именно поэтому компании с надежными программами управления инцидентами устанавливают четкие уровни опасности инцидентов и понятные рекомендации по определению их приоритета.

Что такое уровни опасности?

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

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

Уровень опасности 2 — это «серьезный инцидент со значительными последствиями». Например, недоступность сервиса для части клиентов, отказ критически важной функции системы.

Уровень опасности 3 означает «несерьезный инцидент с незначительными последствиями». Это может быть неполадка системы, приводящая лишь к небольшому неудобству для клиентов.

В Atlassian работа над инцидентами уровня опасности 3 ведется днем (в рабочие часы). При возникновении инцидента уровня опасности 1 или 2 дежурные специалисты получают оповещение в любое время суток и сразу приступают к устранению.

Опасность Описание Примеры
1 Критически опасный инцидент с очень большими последствиями
  • Предназначенный для клиентов сервис, например Jira Cloud, не работает у всех клиентов.
  • Нарушена конфиденциальность или защита данных.
  • Потеряны данные клиентов.
2 Серьезный инцидент со значительными последствиями
  • Предназначенный для клиентов сервис недоступен части клиентов.
  • Есть существенное влияние на основные функциональные возможности (например, git push, создание задач).
3 Несерьезный инцидент с незначительными последствиями
  • Незначительные неудобства для клиентов; доступно обходное решение.
  • Снижение производительности, не препятствующее использованию сервиса.

Благодаря уровням опасности можно быстро оценить последствия и расставить приоритеты для команд ИТ и DevOps.

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

Когда и в каких случаях полезны уровни опасности?

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

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

Различия между опасностью и приоритетом

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

Однако на самом деле для большинства компаний все сложнее.

Опасность — это оценка воздействия инцидента. Как сильно инцидент влияет на пользователей? Из-за него отказала вся их система? Они не могут завершить критически важную задачу? Или он просто доставляет неудобства и усложняет работу пользователей?

Что касается приоритета — это оценка срочности. Как быстро нужно решить проблему? Какую проблему нужно решить в первую очередь?

Иногда обе оценки полностью совпадают. Инцидент высокого уровня опасности, из-за которого остановилась деятельность всей компании, скорее всего, имеет самый высокий приоритет для команд DevOps и ИТ.

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

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

Еще пример: инцидент, приводящий к сбою вашего приложения. Это инцидент высокого уровня опасности, потому что пользователи не могут делать то, что им необходимо. При этом, предположим, инцидент затрагивает лишь 0,05 % пользователей. Если параллельно возникли инциденты, которые затронули больше пользователей, приоритет первой проблемы можно понизить, хотя обычно слова «сбой системы» сигнализируют об аврале.

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

Знать приоритет на практике полезнее, чем уровень опасности, поэтому это основная оценка, которую компания Atlassian использует в Opsgenie. А поскольку уровень опасности часто является ключевым фактором, влияющим на приоритет, мы привели точные определения в нашем справочнике по инцидентам в рамках собственной методики управления инцидентами.

Определение уровней опасности инцидентов для организации

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

  • Размер технической команды
  • Расписания дежурств
  • Часы высокой и низкой нагрузки на сервис
  • Частота возникновения инцидентов

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

Например, в использовании приложения, обслуживающего местные рынки в одном часовом поясе, может наблюдаться длительный перерыв с 02:00 до 07:00. Поэтому уровень опасности отказа всей системы в 03:00 будет ниже, чем в часы пиковой нагрузки.

Что насчет небольшой команды стартапа, которая часто сталкивается с инцидентами уровня опасности 3? Стоит ли относить их к этой категории, а команде дать возможность самостоятельно распределять приоритеты при возникновении, скажем, сразу трех инцидентов? Или лучше дополнительно выделить уровни опасности 3, 4 и даже 5, чтобы разграничить частичный отказ функций клиентской системы, проблемы с производительностью и — еще более мелкая градация — например, ошибки, не влияющие на удобство использования системы, но так или иначе требующие устранения?

Главное — знать свою компанию и свою команду и определить уровни опасности и приоритеты наилучшим для себя образом.

3 уровня Atlassian 4 уровня 5 уровней
Уровень опасности 1

Критический инцидент с очень большими последствиями.

Пример: предназначенный для клиентов сервис, такой как Jira, отказал и недоступен для всех клиентов.

Уровень опасности 2

Серьезный инцидент со значительными последствиями.

Пример: предназначенный для клиентов сервис, такой как Jira, отказал и недоступен для части клиентов.

Уровень опасности 3 Несерьезный инцидент с незначительными последствиями.

Пример: ошибка в системе, приводящая к незначительным неудобствам для клиентов.

Инцидент, который может стать серьезным, если его быстро не устранить.

Пример: частичный отказ функций у небольшой части клиентов.

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

Незначительный инцидент, влияющий на удобство использования продукта, но не вызывающий отказ.

Пример: скорость загрузки ниже средней.

Уровень опасности 5

Ошибки или проблемы, не влияющие на удобство использования продукта.

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

продолжение темы
Cost of downtime