Управление сбоями и инцидентами
Сбой не «теряется» между письмом, звонком и таблицей на общем диске: он проходит один и тот же маршрут — регистрация, двойное подтверждение ИТ-службой, автоматическое порождение инцидента операционной надёжности, классификация с проверкой весов, отчётность перед Банком России. Каждый шаг — статус со своим владельцем, и ни один шаг нельзя пропустить молча.
- 8статусов сбоя — от «Создан» до передачи менеджеру ИТ
- 10статусов инцидента операционной надёжности
- 13осей классификации инцидента с проверкой суммы весов
- 24дня без движения — и зависший инцидент уходит в эскалацию
Жизненный цикл: от сбоя до инцидента
Карточка сбоя не превращается в инцидент сама по себе и не создаётся инцидентом «на глаз»: система проводит сбой через подтверждение и сама порождает инцидент операционной надёжности на нужном шаге, перенося в него даты, объекты и расчёт простоя.
Схема листается вбок — она шире экрана.
Двойное ИТ-подтверждение
Один сотрудник не может тихо признать сбой несущественным и закрыть вопрос: карточка обязана пройти двух разных людей — ИТ-валидатора и ИТ-менеджера, — и если подтверждение информационной системы не проставлено, система не оставляет карточку висеть в неопределённости: она автоматически возвращает сбой в работу с пометкой «Сбой ИТ системы не подтвержден».
Маршрут статусов: Создан → На подтверждении ИТ валидатора → Подтвержден ИТ валидатором → На подтверждении ИТ менеджера → Подтвержден ИТ менеджером. Возврат на любом шаге — статус Возвращенный с обязательным комментарием; для системы, ответственность за которую не подтверждена, предусмотрена Вторичная оценка ИТ валидатором.
Прежде чем ИТ-валидатор сможет верифицировать сбой
Всего обязательных полей, осталось отметить .
Все обязательные поля заполнены — карточка готова к передаче ИТ-валидатору.
Автоматическое порождение инцидента
На переходе «Подтвержден ИТ менеджером» система не ждёт, пока кто-то заведёт инцидент вручную и перепечатает в него даты и описание из сбоя: инцидент операционной надёжности создаётся сам, полями сбоя заполняется автоматически, а простой и деградация технологического процесса — считаются, а не вводятся на глаз.
Есть два пути создания: если у крупного события заполнен технологический процесс, инцидент создаётся или пополняется по техпроцессу — с расчётом фактического и планового количества операций, суммарного времени простоя и процента деградации; если техпроцесс не задан, инцидент создаётся по бизнес-линии верхнего процесса.
| Поле сбоя | Поле инцидента | Что происходит |
|---|---|---|
| Дата регистрации | Дата регистрации | переносится без изменений |
| Переход в «На подтверждении ИТ менеджера» (из журнала статусов) | Дата выявления | берётся не с клавиатуры, а из журнала смены статусов сбоя |
| Дата и время начала простоя | Дата возникновения | переносится без изменений |
| Описание и обоснование отсутствия ИТ-риска | Описание | объединяются в одно поле |
| Подтверждение сбоя информационной системы | Признак «ИТ подтверждён» | переносится флагом, не текстом |
| — | Суммарное время простоя, процент деградации | рассчитываются системой заново |
Связь с исходным сбоем, задействованными объектами инфраструктуры и процессами создаётся автоматически — карточка инцидента не начинается с чистого листа. При вторичной оценке ИТ-валидатором система требует дату восстановления оказания услуг в полном объёме: без неё дальнейшее согласование карточки невозможно.
Классификация инцидента и сверка весов
Инцидент распределяется по классификаторам с указанием доли в процентах по каждой оси — так посчитанное распределение нельзя спрятать за одной галочкой «применимо».
- Бизнес-линияbusinessLine
- Тип событияeventType
- Вид рискаriskType
- Категория рискаriskCategory
- Источник рискаriskSource, riskSrcCategory
- Исходная системаsourceSystem
- ИБ-классификаторib
- Бизнес-процессbprocess, operTehProcess
- Подразделение и вид деятельностиstructureHistorical, activityOrg
Сумма долей по каждой оси обязана быть равна 100 %
Пока распределение не сходится, система показывает предупреждение и не даёт выдать классификацию за завершённую. Рядом с классификацией фиксируются и денежные, и нематериальные последствия инцидента — фактические и косвенные потери, потери качества, сумма в валюте инцидента и в пересчёте.
Статусные модели сбоя и инцидента
У сбоя и у инцидента — разные статусные модели: то, что для сбоя уже «Подтвержден ИТ менеджером», для родившегося из него инцидента — только «Создан».
| Статус | Что означает |
|---|---|
| Создан | карточка зарегистрирована, верификация не начата |
| На подтверждении ИТ валидатора | передан на первичную проверку |
| Подтвержден ИТ валидатором | первая линия подтверждения пройдена |
| Вторичная оценка ИТ валидатором | системы, за которую пользователь не отвечает — требуется повторная проверка |
| На подтверждении ИТ менеджера | вторая линия подтверждения |
| Подтвержден ИТ менеджером | точка порождения инцидента операционной надёжности |
| Возвращенный | возврат с обязательным комментарием на любом шаге проверки |
| Архив | закрыт без создания инцидента, с комментарием |
| Статус | Что означает |
|---|---|
| Создан | инцидент зарегистрирован — вручную или автоматически из сбоя |
| Подана первичная форма | первичные показания по операциям поданы |
| На подтверждении ИТ валидатора | первая линия проверки инцидента |
| На подтверждении ИТ менеджера | вторая линия проверки инцидента |
| Подтвержден ИТ менеджером | инцидент подтверждён окончательно |
| Закрыт | работа по инциденту завершена |
| Возвращенный | возврат с комментарием на первой линии |
| Возвращенный ИТ валидатору | возврат с комментарием на второй линии |
| Архив | закрыт без дальнейшего движения, с комментарием |
| Передано в СУОР | классификация и последствия переданы в модуль операционного риска |
Эскалация зависших инцидентов
Инцидент, забытый на согласовании, не остаётся незамеченным до квартального отчёта: фоновая проверка сама находит зависшие карточки и поднимает тревогу.
24 дня без движения — и уходит уведомление
Инциденты в статусах «На подтверждении ИТ валидатора» и «Возвращенный ИТ валидатору», которым с даты создания исполнилось больше 24 дней, автоматически попадают в письмо и push-уведомление ИТ-валидаторам ответственной системы, ИТ-менеджерам и ИТ риск-менеджерам. Полный состав каналов и получателей — на странице «Сроки и уведомления».
Аудиторский след: история статусов
У каждой карточки — сбоя, инцидента, объекта инфраструктуры, поставщика — есть вкладка «История изменений», построенная на одном и том же журнале смены статусов: кто перевёл карточку, когда и в какой статус.
Журнал ведётся движком статусных моделей самого модуля, а не приложением поверх него: переходы, требующие комментария, без него не проходят, и сам комментарий остаётся в истории вместе с датой и автором.
Что это даёт ИТ-директору. Журнал статусов — не надстройка конкретной карточки, а часть общего движка модуля: он одинаково работает для сбоя, инцидента, объекта инфраструктуры и поставщика, и его нельзя отключить точечно. Модуль регистрируется в общей модели безопасности платформы отдельным разделом и ведёт собственный журнал действий по своему контуру администрирования — подробнее на странице «Права доступа».
Передача в СУОР
Операционная надёжность и операционный риск — разные модули с разной отчётностью, но карточку не заводят дважды: из инцидента операционной надёжности можно создать связанный инцидент операционного риска, не перепечатывая классификацию заново.
При передаче в СУОР переносятся классификации по технологическим процессам с уже распределёнными процентами и классификация по источнику риска; интерфейс подтверждает создание сообщением «Инцидент СУОР создан». Если признак операционной надёжности с карточки снимается при наличии связанного инцидента СУОР, статус инцидента переходит в «Передано в СУОР» — иначе он возвращается в «Создан», а признак подтверждения ОН сбрасывается, чтобы карточка не осталась в противоречивом состоянии.
Показать карточку сбоя и инцидента на вашем стенде
Двойное подтверждение, автоматический расчёт простоя, эскалация зависших карточек — на данных, приближенных к вашей инфраструктуре.