Сроки и уведомления
Фоновый контроль зависших инцидентов
Никто не должен вручную проверять по утрам, не забыт ли инцидент на согласовании: за этим следит фоновое задание, которое сравнивает возраст карточки с порогом и само рассылает уведомления, если он превышен.
Проверка проходится по инцидентам в статусах «На подтверждении ИТ валидатора» и «Возвращенный ИТ валидатору» и находит те, что с даты создания не двигались больше 24 дней. Периодичность самого запуска проверки настраивается под инфраструктуру заказчика при внедрении — отдельно от порога в 24 дня, который задан в самом модуле.
Порог эскалации
24 дня — не рекомендация, а жёсткая граница, зашитая в проверку: как только инцидент её пересекает, уведомление уходит без дополнительного решения человека.
Состав статусов, участвующих в проверке, и сама величина порога — те же, что в реализации: отсчёт идёт от даты создания инцидента, а не от даты последнего изменения, поэтому карточку нельзя «сбросить таймер» техническим редактированием.
Каналы уведомлений: email и push
Уведомление уходит не в один канал: письмо и push-сообщение внутри системы дублируют друг друга, а тема письма сама показывает, что это СУОН, а не одно из соседних писем в почте.
Тема письма формируется как «СУОН <среда>» — получатель сразу видит источник и контур, из которого пришло уведомление. Рассылку в модуле ведут 25 разных классов — от карточки сбоя и инцидента до импорта и синхронизации планов непрерывности деятельности, так что уведомления приходят из самой точки события, а не из отдельного «модуля оповещений», который можно случайно отключить целиком.
- 34уведомления привязаны к инцидентам
- 28уведомления привязаны к сбоям
- 20уведомления привязаны к процессам
- 20уведомления привязаны к поставщикам
Получатели эскалации
Уведомление о зависшем инциденте получает не весь список рассылки, а три конкретные роли, которые действительно могут на это повлиять.
- ИТ-валидаторы объектаответственные за конкретную систему
- ИТ-менеджерывторая линия подтверждения
- ИТ риск-менеджерывидят эскалацию по всему контуру
Адресация умеет учитывать и более узкий случай: если сотрудник верифицирует систему, за которую отвечает не он, система не проводит верификацию молча, а сама предлагает отправить уведомление тем, кто за эту систему действительно отвечает.
Журнал отправленных уведомлений
«Мы же писали» перестаёт быть аргументом, который нечем подтвердить: у внутренних сообщений есть собственный экран с историей.
Помимо письма и push-уведомления, каждое сообщение попадает в собственный реестр внутренних уведомлений системы — его можно открыть и посмотреть, что и когда было отправлено по конкретной карточке, не поднимая почтовый архив.
Фоновые задачи и их расписание
В модуле работают два фоновых задания — оба видны и настраиваемы, ни одно не является скрытой логикой внутри приложения.
| Задача | Что делает | Периодичность |
|---|---|---|
| Контроль зависших инцидентов | эскалирует инциденты старше 24 дней в статусах подтверждения ИТ валидатором | задаётся внешней настройкой при внедрении |
| Закрытие зависших заявок импорта по таймауту | переводит зависшие заявки «Импорта по заявкам» в статус «Завершена по таймауту» и запускает следующую заявку из очереди | проверка раз в 60 секунд, таймаут заявки — 120 минут (значения по умолчанию, настраиваются) |
Показать эскалацию зависшего инцидента на вашем стенде
Порог в 24 дня, получатели по ролям и журнал отправленных уведомлений — на карточке инцидента, приближенной к вашему процессу и вашей оргструктуре.