Incident Management

Простой вопрос?

Вопрос с несколькими вариантами ответа?

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

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

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

Реагирование: - Первоначальная диагностика - в некоторых командах поддержка первой линии может отслеживать инцидент от диагностики до закрытия. Если это невозможно, то следующим шагом будет регистрация всей соответствующей информации и передача ее команде следующего уровня. - Эскалация - следующая команда берет зарегистрированные данные и продолжает процесс диагностики, и, если эта следующая команда не может диагностировать инцидент, она переходит к следующей команде. - Общение - команда регулярно делится обновлениями с затронутыми внутренними и внешними заинтересованными сторонами. - Расследование и диагностика - продолжается до тех пор, пока не будет установлена ​​природа инцидента. Иногда команды привлекают внешние ресурсы или других сотрудников отдела для консультаций и помощи в решении проблемы. - Разрешение и восстановление - на этом этапе команда ставит диагноз и выполняет необходимые действия для разрешения инцидента. - Восстановление просто подразумевает количество времени, которое может потребоваться для полного восстановления операций, поскольку некоторые исправления (например, исправления ошибок и т. д.) могут потребовать тестирования и развертывания даже после того, как правильное решение было определено. - Закрытие - если инцидент был эскалирован, он передается обратно в службу поддержки для закрытия. Для поддержания качества и обеспечения бесперебойного процесса только сотрудники службы поддержки могут закрывать инциденты, и владелец инцидента должен связаться с лицом, сообщившим об инциденте, чтобы подтвердить, что решение является удовлетворительным и инцидент действительно может быть закрыт;

Команда регулярно проводит анализ «всплесков» количества инцидентов, особенно после выкатки изменений в PROD-окружение.

Определен и зафиксирован процесс управления инцидентами

Определена и зафиксирована классификация инцидентов

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

Определены и зафиксированы роли и обязанности в процессе реагирования на инциденты

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

Определены и зафиксированы каналы внутри и вне компании для информирования об инциденте

Проводится post-mortem для анализа действий после каждого инцидента

Проводятся регулярные учения по реагированию на инциденты

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

Производится ли замер среднего времени восстановления системы(MTTR)

Определены и зафиксированы цели по времени реакции на инцидент(SLA)

команда не обладает инструментами мониторинга и алертинга - нет системы раннего оповещения об инциденте или вероятном его наступлении;

поступившие инциденты не регистрируются или это делается нерегулярно;

у команды нет согласованного перечня мер и шагов по диагностике проблемы, ее решению и устранению;

критичные инциденты остаются без указания корневой причины;

команда не соблюдает SLA, высокие инциденты не закрываются больше месяца;