Ваш сервис растёт, но каждая пятница приносит падение — то нагрузка, то утечка памяти, то ошибка конфигурации. Один инцидент тянет за собой другой, разработчики теряют фокус, а ops бесконечно чинит одно и то же. Знакомая картина? SRE-практики созданы, чтобы разорвать этот круг.
Мы внедряем Site Reliability Engineering — не назначаем "инженера надёжности" с новым титулом, а строим инженерную систему контроля надёжности на основе данных. Начинаем с измерения: SLI, SLO, Error Budget. Это фундамент, который превращает "надо быть надёжнее" в конкретные метрики и действия. Вместо интуитивных решений — количественные цели. Вместо героических деплоев — баланс скорости и стабильности через Error Budget. Вместо рутины — автоматизация toil. Мы внедряем эти практики итеративно, от 2 недель до 3 месяцев, с прозрачными результатами на каждом этапе. Наш опыт показывает, что даже без полной трансформации первые результаты — снижение MTTR на 30-50% и экономия операционного бюджета — заметны уже через месяц.
Фундамент: SLI, SLO, Error Budget
SLI (Service Level Indicator) — конкретная метрика, которую мы измеряем. Не «сервис работает», а «процент успешных HTTP-запросов за 5-минутное окно».
# SLI для availability: ratio успешных ответов
sum(rate(http_requests_total{status!~"5.."}[5m])) / sum(rate(http_requests_total[5m]))
SLO (Service Level Objective) — целевое значение SLI. «99.9% запросов завершаются успешно» — это SLO. Это внутренняя цель, не обещание клиентам.
Error Budget — сколько «ошибок» допустимо за период. При SLO 99.9% за 30 дней error budget = 0.1% * 30 * 24 * 60 минут = 43.2 минуты простоя или эквивалентного числа ошибок. Это ключевая концепция: error budget — это ресурс, которым владеет продуктовая команда для рискованных деплоев.
Если error budget исчерпан — деплои останавливаются до следующего периода или до улучшения reliability.
Пример расчёта Error Budget для e-commerce
Для интернет-магазина с SLO 99.9% и месячным периодом error budget составляет 43 минуты. Каждый деплой "потребляет" часть этого бюджета: если релиз вызывает 5 минут ошибок, то при остатке < 5 минут деплой блокируется. Это позволяет балансировать скорость разработки и надёжность.Как определить правильный SLO?
Главная ошибка — брать SLO из воздуха («давайте 99.99%»). SLO определяется через три шага:
Шаг 1. Измерьте текущее состояние. Какой у вас реальный availability за последние 90 дней? Prometheus + recording rules дадут ответ. Нельзя ставить SLO выше текущего уровня без плана инвестиций в reliability.
Шаг 2. Проанализируйте пользовательский опыт. Какой уровень ошибок пользователи замечают? Для веб-сервисов — обычно 1% ошибок за 1 минуту становится заметен. Для платёжных систем порог ниже.
Шаг 3. Учтите бизнес-контекст. Какова стоимость downtime? Для e-commerce каждая минута простоя — прямые потери выручки. Для внутренних инструментов порог другой.
Типичный набор SLO для backend API:
- Availability: 99.9% успешных запросов (5xx не считаются успешными)
- Latency: 95-й перцентиль < 200ms, 99-й < 500ms
- Error rate: < 0.1% для критичных эндпоинтов
Почему toil — главный враг reliability?
Toil — это ручная, повторяющаяся операционная работа, которая не улучшает систему, а просто поддерживает её работу. Перезапуск сервиса раз в неделю, ручная очистка логов, регулярные тикеты на одно и то же.
Правило SRE: не более 50% рабочего времени должно уходить на toil. Остальное — engineering work: устранение причины утечки памяти, автоматизация очистки логов, устранение причины повторяющихся тикетов.
Измеряем toil: tracking категорий задач в течение 2-3 недель даёт картину. Типично обнаруживается, что 3-4 повторяющихся задачи занимают 60-70% операционного времени. Автоматизация toil снижает operational load в 2-3 раза и уменьшает стоимость эксплуатации.
Capacity planning
Проактивное планирование мощности — SRE практика, предотвращающая инциденты из-за исчерпания ресурсов. Это не «добавить ресурсов когда тормозит».
Метрики для capacity planning: CPU/memory utilization trends, request rate growth, storage growth rate. Прогноз на 3-6 месяцев вперёд на основе исторических данных. Karpenter в Kubernetes автоматизирует scaling нод, но не заменяет понимание, хватит ли лимитов облачного аккаунта.
Reliability testing
Chaos Engineering — не для всех и не сразу. Chaos Monkey, Litmus Chaos или просто kubectl delete pod на production pod имеет смысл только после того, как у вас есть SLO, измерение error budget и уверенность, что система восстанавливается автоматически.
Начинать имеет смысл с gameday: контролируемая симуляция сбоя в staging с участием всей команды. Это проверяет runbooks, коммуникацию и реальную скорость восстановления.
Как проходит внедрение
SRE-практики внедряются итеративно, от 2 недель до 3 месяцев:
| Фаза | Что делаем | Результат |
|---|---|---|
| Baseline | Определяем SLI/SLO, настраиваем измерение error budget | Знаем текущий уровень надёжности |
| Toil audit | Идентифицируем и начинаем автоматизировать toil | Высвобождаем инженерное время |
| Reliability engineering | Устраняем системные причины инцидентов | Снижение MTTR и Change Failure Rate |
| Chaos / Gameday | Проверяем устойчивость контролируемыми сбоями | Подтверждённая надёжность |
Что входит в работу
| Deliverable | Описание | Формат | Срок |
|---|---|---|---|
| Аудит состояния | Измерение SLI, SLO, error budget, toil | Отчёт с метриками | 1-2 недели |
| План автоматизации | Приоритезация toil и roadmap | Документ с этапами | 1 неделя |
| Настройка observability | Дашборды, алерты, recording rules | Prometheus/Grafana | 2-3 недели |
| Внедрение SLO и error budget | Процессы и инструментарий | Runbook, код | 2-4 недели |
| Обучение команды | Тренинг по SRE-практикам | Воркшоп, документация | 1 день |
Стоимость внедрения SRE-практик окупается за счёт сокращения простоев и toil. Минимальный горизонт для видимых результатов — 4-6 недель. Оцените ваш проект — напишите нам для аудита. Получите консультацию по SRE-практикам. Наша команда имеет 5+ лет опыта в SRE и провела более 30 внедрений. Снижение operational cost на 40-60% за счёт автоматизации — типичный результат.
