Скорость разрешения IT-инцидентов

Скорость восстановления работы сотрудника при IT-инциденте и отсутствие «висящих» тикетов. Прямо отвечает на обещание Product Sysadmin: «бесперебойная IT-инфраструктура». Отвечает на вопрос: быстро ли восстанавливается работа сотрудников, или тикеты копятся?

Источник: ICT User Support (). Композит из двух показателей.

Показатель A — Соблюдение SLA по приоритетам: Доля инцидентов, разрешённых в SLA-окне по Priority: — Critical — 4 часа — High — 1 рабочий день — Medium — 3 рабочих дня — Low — 7 рабочих дней SQL: «разрешён» = Status='Done'. Время разрешения = last_edited_time при смене статуса на 'Done' минус Submission time. Нужен разрез по Priority и проверка ·время разрешения ≤ SLA-окно·. Метрика = COUNT(в SLA) / COUNT(разрешёно за период) × 100%.

Показатель Б — Старые незакрытые тикеты: SQL: COUNT(WHERE Status NOT IN ('Done','Cancelled') AND Submission time < today − 14 дней). Должно быть = 0 (инцидент старше 2 недель без решения — сигнал зависания либо отсутствия явного Cancel).

Семантическая оговорка: Resolved — это промежуточный статус «починил, ждём подтверждения», Done — финальный. В SLA-метрике используется Done. On Hold в счёт времени не идёт (вычитается из SLA-окна).

Период: ежемесячно.

Критерии общего статуса («худший из двух»): 🟢 A ≥ 90% И Б = 0 🟡 A 75–90% ИЛИ Б = 1–3 🔴 A < 75% ИЛИ Б ≥ 4

ИНФРАСТРУКТУРА К РАЗРАБОТКЕ: Поле Priority — multi_select; в SQL расчёте брать первый элемент. last_edited_time как время разрешения — прокси (любое позднее редактирование сдвинет дату). Для точности лучше добавить явное поле Resolved Date.