---
title: 'Приоритеты, SLA и эскалация'
description: 'Оценка severity, приоритета и бизнес-влияния, SLA-политики с календарями, таймерами и правилами паузы, а также автоматический механизм эскалации.'
section: 'Operations Center'
weight: 7
related:
  - operational-issues
  - execution-and-queue
---

import Alert from '@/components/docs/Alert.astro';

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

### Тяжесть (Severity)

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

| Уровень       | Значение                                                                          |
| ------------- | --------------------------------------------------------------------------------- |
| Critical      | непосредственный риск потери управления, учёта, безопасности или массового отказа |
| High          | существенное нарушение функции                                                    |
| Medium        | деградация без немедленного критического последствия                              |
| Low           | локальное отклонение или недостаток данных                                        |
| Informational | наблюдение, не требующее немедленного действия                                    |

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

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

| Приоритет | Типовой срок                                        |
| --------- | --------------------------------------------------- |
| P1        | немедленная реакция, устранение в пределах 24 часов |
| P2        | плановое устранение в пределах 5 дней               |
| P3        | устранение в пределах 20 дней                       |
| P4        | улучшение или низкоприоритетная корректировка       |

Severity и Priority не равны.

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

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

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

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

$$
I =
w_s S +
w_b B +
w_a A +
w_r R +
w_d D
$$

где:

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

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

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

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

<Alert type="info">
  Оценка бизнес-влияния не является бухгалтерским фактом, если она построена на оценочной модели. В
  интерфейсе всегда показывается источник, метод и уровень уверенности.
</Alert>

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

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

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

```mermaid
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 обеспечивает автоматическую передачу проблемы на более высокий уровень ответственности при нарушении установленных условий.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

| Время | Событие                     |
| ----- | --------------------------- |
| 09:10 | Issue создан                |
| 09:25 | предупреждение Response SLA |
| 09:40 | эскалация, уровень 1        |
| 10:30 | эскалация, уровень 2        |
| 13:00 | эскалация, уровень 3        |
| 13:10 | назначен директор           |

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