SLA по-человечески: что значит «починим за 15 минут ночью»

В 03:14 Alertmanager поднимает дежурного инженера звонком: не письмом, не пушем в Telegram, который можно проспать. Звонком. Через две минуты инженер смотрит в Grafana. В 03:22 он пишет в чат клиенту: «Инцидент зафиксирован, работаем». Это и есть реакция от 15 минут, которую мы обещаем в SLA.

Но вопрос, который чаще всего задают на переговорах: «от 15 минут - это значит, что через 15 минут всё заработает?» Нет. И это принципиальная разница, о которой нужно говорить до подписания договора.

Реакция не равна решению

SLA в нашем договоре гарантирует реакцию - момент, когда дежурный инженер принял инцидент и начал работать. Не момент, когда сервис вернулся в строй. Это честно, и именно так устроены промышленные SLA везде, где их пишут без воды.

Почему так? Потому что время решения зависит от природы инцидента. Упавший процесс, который поднимается за 30 секунд - одно. Потеря кворума в кластере БД в результате сбоя питания на площадке - другое. Гарантировать единое время решения для обоих сценариев значит либо брать обязательства, которые невозможно выполнить в сложном случае, либо занижать планку в простом.

Что мы гарантируем:

• реакция: от 15 минут с момента оповещения в режиме 24/7;
• вы узнаёте об инциденте от нас, а не от своих пользователей;
• мы разбираем причину, а не перезапускаем сервис вслепую.

Последнее - не мелочь. Слепой перезапуск убирает симптом и оставляет причину. Через час или через неделю инцидент повторяется. Мы фиксируем корневую причину и устраняем её, поэтому в ежемесячном отчёте видно, что число инцидентов снижается, а не ходит по кругу.

Как устроены оповещения

Мониторинг - это не про графики, которые кто-то смотрит раз в день. Это про систему, которая умеет звать людей сама.

Стек: Prometheus собирает метрики, Alertmanager обрабатывает правила и маршрутизирует уведомления. Для P1 маршрут один: голосовой звонок дежурному инженеру. Не письмо, не Slack, не пуш-уведомление. Звонок, потому что всё остальное можно не заметить в 03:14.

У каждого оповещения - приоритет и порядок эскалации. Если дежурный не ответил за три минуты, звонок уходит следующему инженеру в смене. Смена работает именно сменами, а не по принципу «один человек всегда на связи». Это снимает точку отказа: болезнь, отпуск или просто разряженный телефон не создают дыру в покрытии.

Что такое P1 и P2 в нашем SLA

Граница между приоритетами - это не вкусовщина, а влияние на бизнес:

P1 (критический) - продакшн недоступен или деградирован настолько, что бизнес-операции остановлены. Сервис отвечает с ошибками большинству пользователей, транзакции не проходят, данные не записываются. Реакция: от 15 минут, 24/7.

P2 (высокий) - часть функциональности деградирована, есть обходной путь, бизнес продолжает работать. Медленные запросы у части пользователей, один из нескольких экземпляров в ошибке, предупреждения по дисковому пространству без немедленного риска. Реакция: в рабочее время или в рамках расширенного окна по договору.

Граница не всегда очевидна с первого взгляда, и это нормально. Часть настройки SLA - это разговор с клиентом о том, что для его бизнеса является P1. Для интернет-магазина это «корзина не оформляется». Для B2B-платформы: «API не отвечает». Для логистики: «трекинг грузов встал». Мы фиксируем критерии в договоре до старта, а не выясняем их в момент инцидента.

Ночной инцидент: тайминг по минутам

Чтобы не быть абстрактными: как это выглядит в реальности.

03:14 - Prometheus фиксирует рост доли ошибок выше порога. Alertmanager отправляет правило в очередь, ждёт подтверждения длительности (чтобы не поднимать по флапу).

03:16 - оповещение подтверждено, Alertmanager звонит дежурному инженеру.

03:17 - инженер принял звонок, открывает панель мониторинга. Видит: ошибки на уровне API-шлюза, серверная часть живая, база отвечает. Первая гипотеза: выкладка из ночного CI или сетевое.

03:21 - находит причину: в 02:50 прошла автоматическая ротация TLS-сертификата, новый сертификат не был принят nginx из-за прав доступа на директорию. Типичная нештатная эксплуатационная ситуация.

03:22 - пишет в чат клиента: «P1, работаем, причина установлена: сертификат». Клиент узнаёт об инциденте раньше, чем это замечают его пользователи на других часовых поясах.

03:31 - сертификат перевыпущен и применён, сервис восстановлен. Реакция от первого алерта до уведомления клиента: 6 минут. Восстановление: 17 минут.

К утру - разбор причин в трекере: что сломалось, почему, что исправлено и как предотвратить повтор. В данном случае: исправление в Ansible-роли ротации с тестом на права доступа.

Это не слепой рестарт. Это разбор причины с фиксом и задачей на предотвращение.

Доступность: 99,9% и 99,99%

Цифры доступности в нашем SLA - не маркетинговые: они фиксируются в договоре и означают конкретное плановое время простоя.

99,9% (ярус ADG.Инфра) - не более ~8,7 часа простоя в год. Подходит для большинства продакшн-контуров.

До 99,99% (ярус ADG.Enterprise) - не более ~52 минут простоя в год. Требует резервирования на уровне инфраструктуры: несколько площадок, отказоустойчивые кластеры, более строгие RTO/RPO. Параметры фиксируются под конкретный контур клиента.

Какой уровень нужен - это зависит от стоимости простоя для бизнеса. Мы обсуждаем это при постановке на эксплуатацию и прописываем в договоре.

Что зависит от клиента

Честный разговор о SLA включает и зону ответственности клиента. Без этого договор - это иллюзия.

Мы гарантируем реакцию и эксплуатацию инфраструктуры. Но:

• если инцидент вызван кодом приложения, который мы не сопровождаем: мы диагностируем и указываем на причину, но исправление кода на стороне клиента;
• если клиент вносит изменения в инфраструктуру без согласования с нами: мы не можем гарантировать время восстановления;
• если для восстановления нужен доступ, который клиент не выдал заранее (ключи, учётки внешних сервисов): это добавляет время.

Зоны ответственности мы разграничиваем явно в договоре. В 2004 году мы впервые написали такой договор для клиентов на сопровождение: тогда это было нестандартным шагом. Сейчас это основа любой договорённости: без явных границ SLA не работает ни для кого.

Честный компромисс

«15 минут» - это реакция, а не гарантия мгновенного исправления. Мы говорим об этом до подписания, потому что клиент, который понял это уже в момент инцидента, - это конфликт.

Что реально стоит за этой цифрой:

• дежурная смена 24/7 с голосовыми оповещениями;
• инженер, который знает ваш контур: не читает документацию с нуля в 03:16;
• разбор причины, а не перезапуск;
• разбор причин и задача на предотвращение после каждого P1.

Мы не перезапускаем сервис вслепую. Это занимает больше 15 минут. Зато инцидент не повторяется через неделю.

Если хотите разобрать, как SLA будет выглядеть для вашего продакшна: что войдёт в P1, какой уровень доступности реально нужен и что потребует резервирования - это разговор на этапе обследования. Подробнее об эксплуатации по SLA: страница DevOps-аутсорсинга.