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

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

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

Реакция ≠ решение

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

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

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

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

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

Как устроен алертинг

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

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

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

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

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

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

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

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

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

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

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

03:16 — алерт подтверждён, Alertmanager звонит дежурному инженеру.

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

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

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

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

К утру — постмортем в трекере: что сломалось, почему, что исправлено и как предотвратить повтор. В данном случае — фикс в Ansible-роли ротейшна с тестом на permissions.

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

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

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

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

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

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

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

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

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

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

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

Честный trade-off

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

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

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

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

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