Начните с исходных данных, а не с процента
Зелёный показатель «SLA выполнен на 98%» сам по себе не объясняет, почему склад не отгружал товар. Он может честно отражать скорость ответа на заявки, но ничего не говорить о восстановлении работы. Проверять нужно не оформление отчёта, а путь от договорного правила до конкретного события и его последствий.
Запросите договор с приложениями, выгрузку заявок с историей статусов и приоритетов, настройки SLA-календарей, журнал мониторинга и подтверждения восстановления. В выгрузке нужны ID обращения и связанного инцидента, сервис, время регистрации, первого ответа, каждой паузы, восстановления и закрытия. Часовой пояс должен быть единым.
Уточните знаменатель: отчёт учитывает поступившие, закрытые или все действовавшие за месяц заявки? Где незакрытые просроченные обращения и переходящий остаток? Какие категории исключены? Сверьте итоговые количества с выгрузкой. Иначе закрытие простых задач улучшит процент, пока сложные останутся за границами отчёта.
1. Отделите реакцию от восстановления
Для каждого показателя выпишите три условия: что запускает отсчёт, что его приостанавливает и что останавливает. Например, в [Jira Service Management эти условия настраиваются отдельно](https://support.atlassian.com/jira-service-management-cloud/docs/set-up-sla-conditions/). Название «время решения» ещё не гарантирует, что таймер остановился после проверки результата.
Реакция — событие, определённое договором: ответ специалиста, принятие в работу или другое действие. Проверьте, не засчитывается ли автоматическое уведомление. Восстановление — возвращение согласованной функции сервиса. Закрытие — административный статус заявки. Это разные отметки времени.
Для 1С подтверждением может быть успешное проведение контрольной реализации и возможность продолжить отгрузку, а не только запуск службы на сервере. Если применён обходной путь, отдельно зафиксируйте ограничения и задачу на устранение причины. Допустимость такого восстановления должна следовать из согласованных критериев, а не из удобства отчётности.
2. Пересчитайте паузы и часы покрытия
По длинным инцидентам восстановите хронологию: статус, начало и конец интервала, основание остановки таймера, ответственный и подтверждающее сообщение. «Ожидание клиента» проверяйте по содержанию: что именно запросили, когда и действительно ли без этого нельзя было продолжать работы.
Ожидание поставщика, запасной части или согласования не становится допустимой паузой автоматически. Сопоставьте его с договором. Правомерное исключение из SLA не отменяет фактический простой бизнеса: в отчёте должны оставаться обе длительности — зачтённая по договору и полная.
Проверьте рабочие дни, праздники, часовой пояс и покрытие каждого приоритета. [Atlassian отдельно описывает остановку SLA вне часов календаря](https://support.atlassian.com/jira/kb/understanding-why-an-sla-is-paused-in-a-jira-service-management-ticket/). Если поддержка работает по будням, а склад — в выходные, отсутствие нарушения может быть корректным, но сама модель не защищает нужный бизнес-процесс. Это основание пересмотреть покрытие, а не объявить подрядчика виновным задним числом.
Учебный пример: 98% и пять часов простоя
Это условный отчёт, не клиентский кейс. В месяце 100 обращений; по всем завершён отсчёт реакции, 98 получили ответ в договорный срок. Общий показатель реакции: 98 / 100 × 100% = 98%. Одна из своевременно принятых заявок связана с полной остановкой отгрузки.
Один инцидент — два способа считать время
Пауза исключена из договорного таймера, но не из времени, когда склад не мог работать.
Условия примера: покрытие 09:00–17:00 по рабочим дням, реакция — до 15 минут, восстановление — до 4 часов. Сбой произошёл в рабочий день; пауза на предоставление доступа разрешена договором и подтверждена. Полное время: 14:00 − 09:00 = 300 минут. Пауза: 120 минут. По SLA: 300 − 120 = 180 минут, или 3 часа. Оба срока выдержаны, хотя отгрузка стояла 5 часов.
Если в условном месяце 22 рабочих дня по 8 часов, других остановок нет, а отгрузка нужна всё это время, её доступность по времени составит (1 − 300 / 10 560) × 100% ≈ 97,16%. Это отдельный операционный показатель, не те же 98% реакции и не автоматическое доказательство нарушения договора. При недопустимой паузе пересчёт даст 5 часов вместо 3 — вывод о выполнении срока восстановления изменится.
3. Найдите повторные заявки и скрытый простой
Сгруппируйте обращения по сервису, симптому и связанному инциденту. Проверьте повторные открытия и новые номера после формального закрытия. Несколько жалоб пользователей на один непрерывный сбой — не несколько отдельных восстановлений. Если работа не возобновлялась, простой нельзя обнулить сменой ID.
Общую причину повторов подтверждают журнал изменений и разбор инцидента. После реального восстановления учитывайте новые интервалы отдельно. Пересекающиеся интервалы простоя одного сервиса объединяйте, а не складывайте.
Выделите критичные сервисы отдельным блоком: отгрузка в 1С, кассовые операции, доступ филиала. Покажите начало и конец влияния, затронутые площадки, ограничения и способ проверки. «Сервер доступен» не равно «операция выполняется». Этот подход соответствует [рекомендации Google SRE измерять важные пользовательские действия](https://sre.google/workbook/implementing-slos/). Частичную деградацию описывайте отдельно от полной остановки; не выдавайте расчёт трудозатрат сотрудников за простой сервиса.
4. Проверьте, сработала ли эскалация
У критичного инцидента должны быть владелец, условие привлечения следующего уровня и порядок информирования бизнеса. Сверьте не только наличие регламента, но и фактические отметки: когда повысили приоритет, кому передали проблему, кто принял координацию и когда сообщили следующий статус. Эскалация нужна при риске нарушения или росте влияния, а не только после истечения срока.
В [руководстве Google по реагированию на инциденты](https://sre.google/workbook/incident-response/) разделены восстановление сервиса и координация участников. Для аудита это практичный вопрос: кто вёл общий инцидент, пока специалисты по сети, серверу и 1С разбирали свои части? Запись «передано провайдеру» не отвечает на него.
Что должно остаться после проверки
- Пересчитанные показатели. Реакция и восстановление раздельно, с периодом, знаменателем, исключениями и открытыми просрочками.
- Реестр расхождений. ID, спорный интервал, пункт договора, подтверждение и влияние на итог — без обвинений на основании одного процента.
- Картина для бизнеса. Простой каждого критичного сервиса, повторы, ограничения обходных решений и фактические эскалации.
- План изменений. Кто и к какому сроку исправляет отчёт, причину повторов, покрытие или критерии восстановления; как проверяется результат.
Начните со всех критичных инцидентов и самых длинных пауз за месяц. Добавьте выборку обычных заявок, чтобы проверить расчёт массового показателя. Цель — различить ошибку учёта, нарушение обязательства и недостаточное условие договора: решения у этих проблем разные.
WeProf · ИТ-аутсорсинг по SLA
Связать отчёт с работой бизнеса
Обсудите с WeProf критичные сервисы, формат отчётности и правила эскалации. ИТ-аутсорсинг — Санкт-Петербург и Ленинградская область, с выездным и удалённым форматом. Состав работ, часы покрытия и сроки закрепляются в договорном SLA под ваш контур.
[Обсудить отчёт и SLA](#contact) [Условия сервиса ↗](https://weprof.ru/it-outsourcing-sla)
Источники и полезные материалы
- [Atlassian: условия запуска, паузы и остановки SLA](https://support.atlassian.com/jira-service-management-cloud/docs/set-up-sla-conditions/)
- [Atlassian: паузы и рабочие календари SLA](https://support.atlassian.com/jira/kb/understanding-why-an-sla-is-paused-in-a-jira-service-management-ticket/)
- [Google SRE: показатели надёжности и пользовательские сценарии](https://sre.google/workbook/implementing-slos/)
- [Google SRE: роли и координация при инцидентах](https://sre.google/workbook/incident-response/)
- [WeProf: аудит ИТ-инфраструктуры](https://weprof.ru/it-infrastructure-audit)
По теме статьи
Связать отчёт с работой бизнеса
Обсудите с WeProf критичные сервисы, формат отчётности и правила эскалации. ИТ-аутсорсинг — Санкт-Петербург и Ленинградская область, с выездным и удалённым форматом. Состав работ, часы покрытия и сроки закрепляются в договорном SLA под ваш контур.