Сервис может формально работать и одновременно мешать бизнесу. Страница открывается, но медленно. Почта принимает письма, но с задержкой. База отвечает, но операции выполняются в разы дольше. Если SLA учитывает только полный отказ, такие ситуации превращаются в спор: пользователи видят проблему, а отчет показывает, что сервис был доступен.
Деградацию нужно описывать не как настроение пользователей, а как изменение пользовательского пути, функций или качества сервиса. Тогда ее можно расследовать, приоритизировать и честно показывать в SLA-отчетности.
Что считать деградацией
Деградация - это ухудшение работы сервиса без полного простоя. Ее нельзя описывать только словом медленно. Нужны признаки: какой сценарий затронут, сколько пользователей страдает, какие операции не завершаются, насколько выросло время выполнения, есть ли обходной путь и какой бизнес-процесс затронут.
Например, файловый ресурс может открываться, но сохранение больших документов занимает минуты. CRM может отвечать, но поиск клиентов срывается по таймауту. Видеосистема может показывать часть камер, но архив за нужный период недоступен. Во всех примерах сервис не полностью выключен, но его ценность для пользователя снижена.
Почему бинарный статус вреден
Статус работает или не работает полезен для простых проверок, но он скрывает частичные сбои. Сервер может отвечать на ping, веб-страница может отдавать успешный код, а пользовательская операция все равно не проходить. Поэтому мониторинг и SLA должны различать доступность, производительность, свежесть данных, качество внешней зависимости и функциональную корректность там, где это важно.
Это не значит, что нужно вводить десятки сложных метрик для каждого сервиса. Достаточно определить несколько признаков, которые действительно отражают пользовательский путь. Для одного сервиса критично время ответа, для другого - доступность очереди заявок, для третьего - актуальность данных обмена.
Как назначать приоритет
| Фактор | Как влияет на приоритет |
|---|---|
| Критичность сервиса | Деградация основного бизнес-процесса важнее проблемы вспомогательной системы. |
| Затронутый путь | Сбой входа, оформления заказа или складской операции весит больше, чем неудобство в настройках. |
| Масштаб | Проблема у всех пользователей обычно требует более быстрой реакции, чем локальный случай. |
| Обходной путь | Если обход есть, приоритет может быть ниже, но риск повторения все равно фиксируется. |
| Повторяемость | Регулярная деградация требует не только реакции, но и постоянного исправления. |
Нельзя назначать приоритет только по проценту отказа. Небольшое замедление внутренней справочной системы и замедление склада в час отгрузки не равны по последствиям.
Что фиксировать в SLA-отчете
В отчете нужны доказательства и результат: период деградации, затронутый сервис, пользовательский симптом, сигналы мониторинга, время первой реакции, временное смягчение проблемы, критерий восстановления и дальнейшие действия. Если проблема решена временным обходом, это не всегда полное восстановление. Отдельно фиксируют постоянное исправление или риск повторения.
Такой отчет помогает спорить не о словах, а о фактах. Пользователь видит, что частичная проблема не потерялась. Поддержка видит, какие признаки сработали. Руководитель видит, где нужна архитектурная доработка, мониторинг или изменение регламента.
Как связать деградацию с SLA
SLA не обязан содержать произвольный универсальный порог для каждого сервиса. Лучше определить признаки деградации и правила приоритета для конкретных сервисов. Для одной системы критично время отклика, для другой - полнота обработки очереди, для третьей - доступность внешней интеграции. Соглашение должно описывать, как деградация принимается, эскалируется и закрывается.
В модели ответственного IT-подрядчика это часть управляемого сервиса: заявка фиксируется, мониторинг дает технические сигналы, приоритет определяется по последствиям, а отчет показывает не только зеленый или красный статус, но и качество работы сервиса для бизнеса. Подробнее эта логика раскрывается в услуге SLA в IT-поддержке.