Вы находитесь здесь:
Менеджер инцидентов координирует крупный инцидент
Помогите менеджеру инцидентов распознать критический сбой и передать квалифицированного кандидата для скоординированного реагирования на крупные инциденты и восстановления обслуживания.
Быстрое использование
Персона: Менеджер инцидентов, работающий с основными группами менеджера инцидентов и исполнителя
Предстоящая работа: Расширение бизнес-инцидентов, создание общего оперативного контекста, координация работы по решению проблем и информирование заинтересованных лиц
Начальная точка: Высокоэффективный инцидент в службе ИТ-служб Agentic, требующий более широкого внимания и координации
Успешный результат: Инцидент классифицируется надлежащим образом, группы, отвечающие за решение, восстанавливают и проверяют обслуживание, заинтересованные лица получают четкие обновления, а последующая работа переходит в управление проблемами.
Этот сценарий использования следует за критическим инцидентом от расширения до восстановления. Он не заменяет канонические процедуры для предложения, проверки, продвижения или закрытия крупных инцидентов. Вместо этого отображается, как менеджер инцидентов и менеджер основных инцидентов используют одну запись для принятия решений, согласования респондентов и сохранения подотчетной временной шкалы.
Заполнители могут предложить инцидент в качестве основного инцидента для проверки. Пользователи с повышенными полномочиями на крупные инциденты могут продвигать инцидент напрямую из записи инцидента без утверждения. Для понижения рейтинга крупного инцидента необходимо полномочие «Менеджер основных инцидентов». Различайте пути предложения и прямой рекламной акции. См. разделы «Управление основными инцидентами для ИТ-служб», «Просмотр основных инцидентов для ИТ-служб» и «Понижение уровня основных инцидентов для ИТ-служб».
Определение сбоя
Начните с бизнес-влияния, а не только с приоритета инцидента. Крупный инцидент влияет на нескольких пользователей или требует немедленного ответа, поскольку несколько бизнес-систем недоступны. Подтвердите задействованные службы и пользователей, оперативность, известные зависимости и доказательства из связанных инцидентов, прежде чем расширять.
| Сигнал | Вопрос координации | Решение |
|---|---|---|
| Область | Затрагиваются ли несколько пользователей, рабочих групп, расположений или служб? | Продолжите стандартную обработку или начните определение серьезных инцидентов. |
| Влияние на бизнес | Недоступна ли или серьезно ли ухудшена критическая бизнес-операция? | Задокументируйте влияние и привлеките ответственного менеджера. |
| Срочность | Увеличивает ли задержка восстановления операционный, финансовый риск или риск соответствия? | Ускорьте ответ и установите каденцию обновления. |
| Связанные инциденты | Обозначают ли похожие отчеты один общий сбой? | Свяжите соответствующие записи и консолидируйте контекст расследования. |
| Сложность восстановления | Требует ли восстановление нескольких групп решающих устройств или управляемого изменения? | Установите скоординированную ответственность и соответствующий путь восстановления. |
Используйте путь предложения, если сбой требует проверки. Пользователи с повышенным полномочием на крупные инциденты могут использовать путь прямой рекламной акции при настройке этого полномочия. Квалификацию и масштабы процессов см. в разделе «Управление основными инцидентами для ИТ-служб».
Создание записи крупного инцидента
Запишите краткое обоснование, объясняющее влияние, срочность и причину более широкой координации. Предложение отправляется на проверку, когда пользователь с обязательным полномочием утверждает или отклоняет его. Прямое продвижение пропускает процесс проверки. Понижение возвращает основной инцидент к стандартной обработке инцидентов.
Жизненный цикл классификации основных инцидентов следует отделить от статуса оперативного инцидента. Предложение, утверждение или отклонение, прямое повышение и понижение являются действиями классификации. Значения статуса работы, например, «Создать», «Выполняется», «Решено» и «Закрыто», описывают прогресс инцидента в восстановлении и завершении. Используйте точные метки состояния жизненного цикла, задокументированные в разделе «Жизненный цикл основных инцидентов для ИТ-служб».
Используйте комментарии статуса крупного инцидента для записи причины при понижении рейтинга крупного инцидента. Запишите обновления расследования инцидента посредством ленты, связанных списков и статуса операции. Каноническое состояние и алгоритм поля см. в разделе «Жизненный цикл основных инцидентов для ИТ-служб». Путь проверки и дополнительное создание проблемы см. в разделе «Просмотр основных инцидентов для ИТ-служб».
Координация восстановления и связи
После классификации используйте запись инцидента в качестве общедоступного оперативного источника. Определите ответственного за каждое действие восстановления, добавьте требуемые группы средств решения, отслеживайте решения и зависимости и убедитесь, что связанные инциденты представляют одинаковые сбои.
Для сложной работы начните настроенную групповую обработку, чтобы эксперты сотрудничали в одном канале. Храните материальные решения и доказательства решения в записи инцидента, а не оставляйте журнал диагностики только в чате. Agentforce может суммировать групповую обработку Slack и опубликовать сводку в ленту записи. См. Групповая обработка инцидентов в Slack для ИТ-служб для получения канонических параметров сотрудничества.
Отправляйте обновления заинтересованным лицам при значимых изменениях, например, подтверждение, подтвержденная область, ход восстановления, восстановление и закрытие. Отделите подтвержденные факты от рабочих гипотез, укажите следующее ожидаемое обновление и избегайте обещания времени восстановления без доказательств. Настроенные уведомления могут предоставлять обновления по электронной почте, внутрипрограммным каналам, Slack или группам Microsoft. См. Уведомления для ИТ-служб.
Восстановление, закрытие и переход
Убедитесь, что обслуживание восстановлено для задействованных пользователей и систем, прежде чем менять инцидент на «Решено». Запишите действие восстановления, доказательства проверки, оставшийся риск и любое временное решение в резюмировании. Переместите инцидент в «Закрыто», когда жизненный цикл будет завершен в процессе рабочей группы.
Классификация основных инцидентов не заменяет дополнительное расследование. Передайте событие в управление проблемами для анализа первопричин и профилактической работы. Автоматическое создание проблемы происходит только при включении соответствующего параметра основного инцидента; в противном случае создайте или свяжите нужную проблему посредством процесса рабочей группы.
Контрольная точка внедрения наступает, когда рабочая группа переходит от фрагментированного ответа к одной скоординированной записи: квалифицированная классификация, подотчетная работа по восстановлению, последовательные коммуникации, проверенное восстановление и явный ответственный за последующие действия. Каноническое решение инцидентов и алгоритм связывания см. в разделе «Управление инцидентами для ИТ-служб».
Подтвердите готовность управления крупными инцидентами
Прежде чем использовать это путешествие в качестве тестирования принятия, убедитесь, что управление инцидентами включено, группа утверждения настроена и у пользователей есть полномочия, необходимые для их назначенных задач. Убедитесь, что исполнители могут предлагать инциденты для проверки, что авторизованные пользователи могут просматривать или напрямую продвигать их и что пользователи, понижающие рейтинг основных инцидентов, имеют полномочие «Менеджер крупных инцидентов». См. Настройка параметров для основных инцидентов для ИТ-служб для получения канонической настройки.
