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

Пріоритет, Severity та бізнес-вплив

Тяжкість (Severity)

Severity відображає технічну тяжкість поточного стану.

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

Priority відображає порядок виконання робіт.

Severity і Priority — не одне й те саме.

Наприклад, Issue може мати Severity = High і водночас Priority = P3.

Такий випадок можливий, коли проблема технічно серйозна, але зачіпає резервний актив без поточного впливу на експлуатацію.

Інтегральна оцінка (Impact Score)

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

де:

• $S$ — тяжкість;
• $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 призначається автоматично на основі Canon, критичності та категорії об’єкта.

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

Система підтримує:

• 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.