SLA/SLO без enterprise-overkill: как задать реалистичную надёжность

Многие команды повторяют одну и ту же ошибку: пытаются скопировать SRE-практики больших корпораций в продукт на 3–8 человек. В итоге — красивые таблицы, но ноль влияния на стабильность.

Нормальный подход проще: фиксируем бизнес-критичные сценарии, задаём SLO на них, считаем error budget и связываем это с релизами.

Проще говоря

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

1) Сначала не SLO, а бизнес-реальность

Если у вас нет ответа на вопрос «что для нас реально больно при падении», любые проценты бесполезны.

Минимум, который нужен:

• какие 2–3 пользовательских сценария приносят выручку,
• сколько денег/репутации теряется за час деградации,
• какой максимум простоя команда и бизнес готовы принять.

2) Определи SLI без фанатизма

SLI — это метрика, которая отражает качество сервиса глазами пользователя.

Для большинства веб-продуктов хватает базового набора:

1. Availability SLI: доля успешных запросов (без 5xx/таймаутов).
2. Latency SLI: p95/p99 для ключевых endpoints.
3. Freshness SLI (если есть данные/ленты): допустимая задержка обновления.

Важно: не измеряй всё подряд. Лучше 2–4 качественных SLI, чем 20 «для галочки».

3) SLO должен быть достижимым

Частая ошибка: ставить 99.99% там, где инфраструктура и процессы тянут максимум 99.5–99.9%.

Ориентир:

• 99.9% в месяц ≈ 43 минуты простоя,
• 99.5% в месяц ≈ 3ч 39м,
• 99.95% в месяц ≈ 21.5 минуты.

Если у вас нет on-call, авто-откат и зрелого мониторинга — 99.95% обычно самообман.

4) Error budget = инструмент принятия решений

Error budget — сколько «ошибок/простоя» вы можете себе позволить за период.

Практика, которая реально работает:

• budget в норме → релизим активно,
• budget на грани → замедляем поэтапный запуск,
• budget сожжён → freeze на фичи, фокус на стабильность.

5) Минимальный набор артефактов

Для маленькой команды не нужен тяжёлый RFC-процесс.

Достаточно:

• 1 страница с SLI/SLO по критичным сценариям,
• dashboard с p95/error-rate/uptime,
• правило по error budget,
• короткий шаблон postmortem.

Короткая история из команды

Ключевой прогресс начался, когда обсуждение перестали вести «в общем», а привязали к конкретным инцидентам и метрикам после релиза.

Вывод

Выигрывают не те, у кого «самые модные SRE-термины», а те, кто сделал простую, измеримую и дисциплинированную систему.

SLA/SLO должны помогать принимать решения, а не украшать Confluence.

Практический сценарий внедрения

Если внедрять подход поэтапно, лучше идти от самого болезненного потока: выбрать один критичный user-journey, зафиксировать текущие метрики и применить изменения только на этом участке. Такой подход снижает риск и даёт быстрый доказуемый эффект для команды.

Метрики, которые важно отслеживать

• p95/p99 latency для ключевых операций,
• error rate и доля retry/резервный сценарий,
• время восстановления после сбоев,
• стоимость обработки запроса/события,
• доля регрессий после релизов.

Без метрик даже сильные архитектурные решения быстро превращаются в набор гипотез.

Что обычно идёт не так

1. Команда пытается внедрить всё сразу вместо поэтапного поэтапный запуск.
2. Нет владельца архитектурного решения и контроль расслаивается.
3. Решение есть в документации, но не встроено в CI/CD и runbook.
4. После внедрения нет регулярного review, и качество снова деградирует.

Пошаговый план на 30 дней

• Неделя 1: базовый уровень, ограничения, целевые KPI.
• Неделя 2: внедрение в одном потоке + алерты.
• Неделя 3: стабилизация, фиксы edge-cases.
• Неделя 4: масштабирование на соседние модули и обновление стандартов команды.

Термины простыми словами

• SLA/SLI/SLO — договорённость о качестве сервиса: что измеряем, какой целевой уровень и какие последствия при деградации.
• Политика повторов — правила повторных попыток (когда, сколько раз и с каким backoff), чтобы не усилить сбой.

Этот блок нужен, чтобы статью можно было читать без предварительного контекста по всем терминам.

Почему это часто проваливается на практике

На бумаге архитектурное решение выглядит логично, но в проде мешают сроки, кросс-командные зависимости и отсутствие явного владельца. Когда решение не встроено в CI, мониторинг и ревью, оно быстро деградирует до «локальной договорённости».

Чтобы этого не было, нужно заранее решить три вещи: кто отвечает за стандарт, как проверяется соблюдение, и в какой момент команда пересматривает подход. Без этого даже сильная архитектурная идея через пару релизов теряет форму.