IT

Регистрация и эскалация инцидентов

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

Бизнес-проблема

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

Что видят команды

  • Работа ожидает между получением инцидента и проверкой затронутой услуги.
  • Владельцы восстанавливают статус с помощью универсального веб-перехватчика и Jira.

Почему это происходит

  • Общее состояние не охватывает универсальный вебхук, Jira, Slack.
  • Правила принятия решений и исключения применяются непоследовательно.

Почему становится дорого

  • Мощность потребляется на координацию и доработку.
  • Поздние исключения ухудшают видимость и качество обслуживания.

Результаты бизнеса

  • Сокращение цикла создания задач после инцидента
  • Меньше исключений при передаче и недостающей информации
  • Освободите право собственности от получения инцидента для создания задачи после инцидента
  • Проверяемые решения и восстановление

Измеримые ключевые показатели эффективности

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

Как работает рабочий процесс

  1. Получить инцидент — Примите и определите причину возникновения инцидента и триггер эскалации. Общий вебхук
  2. Проверьте затронутую услугу — Выполните проверку затронутой услуги с проверенными выборочными данными и результатом, подлежащим аудиту. Общий вебхук
  3. Применить правила серьезности — Выполните правила применения правил серьезности с проверенными выборочными данными и результатом, поддающимся аудиту. Джира
  4. Назначить владельца инцидента — Выполните назначение владельца инцидента с проверенными выборочными данными и проверяемым результатом. Слабый
  5. Уведомить ответчиков — Выполните уведомление ответчиков с проверенными выборочными данными и проверяемым результатом. Общий вебхук
  6. Эскалация по времени — Выполняйте эскалацию по времени с проверенными выборочными данными и проверяемым результатом. Джира
  7. Разрешение записи — Выполните разрешение записей с проверенными данными выборки и проверяемым результатом. Слабый
  8. Создать задачу после инцидента — Выполните задачу создания после инцидента с проверенными выборочными данными и проверяемым результатом. Общий вебхук
  9. Обновление аудита и KPI — Сохраняйте результаты выполнения, факты аудита и события измерения рабочего процесса. Магазин исполнения SEIDO

Интеграции и владение

  • Общий вебхук: Предоставьте информацию о рабочем процессе
  • Джира: Контекст поиска и обновления
  • Слабый: Получите контролируемый результат

Человеческая ответственность: владелец ИТ-службы

Неудача и восстановление

Универсальный вебхук временно недоступен.

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

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

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

Событие триггера или поставщика доставляется более одного раза.

Верните существующее выполнение, определенное ключом идемпотентности, и не повторяйте последующие бизнес-действия.

Человеческое решение истекает до завершения.

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

Когда не стоит это строить

  • Ежемесячный объем слишком мал, чтобы оправдать интеграцию Generic webhook, Jira, Slack.
  • Существующая настроенная платформа уже обрабатывает прием и эскалацию инцидентов с адекватным владением и отчетностью.
  • Надежные исходные данные или поддерживаемый доступ к API недоступны.
  • Ни один владелец бизнеса не имеет полномочий определять правила принятия решений и исключений.

Связанные рабочие процессы