Приоритеты, SLA и эскалация

Приоритет, Severity и бизнес-влияние

Тяжесть (Severity)

Severity отражает техническую тяжесть текущего состояния.

Приоритет (Priority)

Priority отражает порядок выполнения работ.

Severity и Priority не равны.

Например, у Issue может быть Severity = High при Priority = P3.

Такой случай возможен, если проблема технически серьёзная, но затрагивает резервный актив без текущего влияния на операцию.

Интегральная оценка (Impact Score)

Для ранжирования может применяться интегральная оценка:

где:

• $S$ — severity;
• $B$ — бизнес-влияние;
• $A$ — число или критичность затронутых активов;
• $R$ — риск безопасности или регулирования;
• $D$ — длительность.

Бизнес-влияние (Business Impact)

OHM поддерживает структурированные поля влияния:

• число затронутых устройств;
• число потребителей или объектов;
• объём газа под риском;
• длительность деградации;
• потенциальная потеря данных;
• риск неверного коммерческого учёта;
• риск выезда;
• риск нарушения SLA;
• риск информационной безопасности;
• стоимость простоя;
• уровень репутационного влияния.

Управление уровнем сервиса (SLA)

OHM реализует полноценную модель управления SLA.

Контроль распространяется не только на устранение проблемы, но и на весь цикл её обработки.

flowchart TD
  A["Issue создан"] --> B["Response SLA"]
  B --> C["Acknowledgement SLA"]
  C --> D["Resolution SLA"]
  D --> E["Verification SLA"]
  E --> F["Closure SLA"]

Каждый этап имеет собственные правила расчёта.

SLA-политика

Политика SLA определяет:

• допустимое время реакции;
• срок подтверждения;
• срок устранения;
• срок проверки;
• правила эскалации;
• рабочий календарь;
• исключения.

SLA назначается автоматически на основании канона, критичности и категории объекта.

Рабочие календари

Система поддерживает:

• 24×7;
• 12×7;
• рабочие дни;
• региональные календари;
• праздничные дни;
• индивидуальные графики подразделений.

Время вне рабочего календаря не учитывается, если политика SLA не требует круглосуточного реагирования.

SLA-таймеры

Для каждого Issue одновременно рассчитываются несколько независимых таймеров.

Например:

• Time To Response;
• Time To Acknowledge;
• Time To Resolve;
• Time To Verify;
• Time To Close.

Каждый таймер может иметь собственные правила остановки.

Условия паузы

Течение SLA может быть приостановлено.

Например:

• ожидание поставщика;
• ожидание доступа;
• ожидание разрешения;
• сезонные ограничения;
• форс-мажор.

Причина паузы обязательно фиксируется.

Нарушение SLA

При нарушении SLA система автоматически:

• изменяет состояние;
• увеличивает уровень риска;
• запускает Escalation Engine;
• формирует запись аудита;
• отражает нарушение в KPI.

Механизм эскалации (Escalation Engine)

Escalation Engine обеспечивает автоматическую передачу проблемы на более высокий уровень ответственности при нарушении установленных условий.

Эскалация не зависит от действий пользователя и выполняется автоматически.

Уровни эскалации

Типовой сценарий:

flowchart TD
  P1["P1"] -->|"15 минут"| L1["Начальник смены"]
  L1 -->|"1 час"| L2["Региональный руководитель"]
  L2 -->|"4 часа"| L3["Директор по эксплуатации"]

Конкретные интервалы определяются политикой организации.

Триггеры эскалации

Основанием могут служить:

• нарушение Response SLA;
• нарушение Resolution SLA;
• отсутствие исполнителя;
• отсутствие подтверждения;
• повторное открытие;
• массовый характер;
• высокий Business Impact.

Действия при эскалации

При выполнении условия система может:

• уведомить руководителя;
• изменить владельца;
• повысить Priority;
• создать Massive Incident;
• создать внешнюю заявку;
• уведомить руководство;
• инициировать дополнительный анализ.

Все действия полностью журналируются.

История эскалаций

Карточка Issue содержит полный журнал:

История никогда не удаляется и используется при расчёте эксплуатационных KPI.