Надёжность, SRE и эксплуатация

01SLI, SLO, SLA и error budget'ы

Service Level Indicator (SLI) — это измерение пользовательского опыта, например доля успешных запросов или доля запросов, обслуженных быстрее 300 мс. Service Level Objective (SLO) — цель для этого показателя на определённом окне: 99.9 процента запросов оформления заказа успешны за 30 дней. Service Level Agreement (SLA) — договор с последствиями, обычно с компенсациями, и он должен быть мягче вашего внутреннего SLO, чтобы у вас было предупреждение до его нарушения. Error budget — разрыв между идеалом и SLO: 99.9 процента допускают около 43 минут сбоев за 30 дней. Пока бюджет есть, выпускайте фичи; когда он израсходован, приоритет — работе над надёжностью. Измеряйте SLI там, где их чувствуют пользователи (на load balancer'е или синтетическими проверками), и алертите на быстрое сгорание бюджета, а не на каждый всплеск CPU.

1groups:
2  - name: api-slo
3    rules:
4      - alert: ApiErrorBudgetFastBurn
5        # 99.9% SLO: page if errors burn the budget 14.4x too fast
6        expr: |
7          (sum(rate(http_requests_total{job="api",status=~"5.."}[1h]))
8            / sum(rate(http_requests_total{job="api"}[1h]))) > (14.4 * 0.001)
9          and
10          (sum(rate(http_requests_total{job="api",status=~"5.."}[5m]))
11            / sum(rate(http_requests_total{job="api"}[5m]))) > (14.4 * 0.001)
12        for: 2m
13        labels:
14          severity: page
15        annotations:
16          summary: "API is burning its 30-day error budget too fast"

02Дежурства и реагирование на инциденты

Дежурство означает, что кто-то отвечает за реакцию, когда ломается продакшен, — с понятной ротацией, путём эскалации и достаточным отдыхом. Это работает, только если по алертам можно действовать: каждый вызов должен означать проблему, видимую пользователям, которой прямо сейчас нужен человек, со ссылкой на дашборд и runbook. Всё остальное — в очередь тикетов. Когда начинается инцидент, следуйте простой последовательности. Подтвердите алерт. Оцените влияние и объявите уровень серьёзности. Распределите роли: incident commander, который координирует, кто-то, кто работает руками, кто-то, кто общается с пользователями и заинтересованными людьми. Сначала смягчите последствия: откатите деплой, переключитесь на резерв, выключите feature flag, добавьте мощности или заблокируйте вредоносный трафик. Первопричину ищите, только когда пользователи в безопасности. По ходу ведите хронологию в одном канале и публикуйте обновления статуса в регулярном ритме, даже если ничего не изменилось.

• Обнаружить, подтвердить, оценить серьёзность, распределить роли.
• Сначала смягчить, потом диагностировать: откат часто — самое быстрое исправление.
• Сообщать по графику: молчание делает инциденты страшнее.
• Закрывать с проверкой, затем назначать postmortem.

03Runbook'и и blameless postmortem'ы

Runbook — короткое практическое руководство для известной ситуации: «диск заполнен больше чем на 90 процентов», «растёт хвост очереди», «восстановить базу на момент времени». В нём перечислены симптомы, дашборды для проверки, безопасные диагностические команды, исправление и момент, когда нужно эскалировать. Хорошие runbook'и позволяют уставшему инженеру в 3 часа ночи действовать правильно, и они — первый шаг к автоматизации исправления. После любого значимого инцидента пишите postmortem: что произошло, хронология, влияние, как обнаружили и устранили, сопутствующие факторы и конкретные последующие действия с ответственными и сроками. Делайте его blameless: спрашивайте, почему система допустила ошибку, а не кто её совершил, потому что люди скрывают информацию, когда боятся обвинений. Следите за последующими действиями до их выполнения: postmortem без выполненных действий — просто рассказ.

04Высокая доступность и восстановление после аварий: RPO и RTO

Высокая доступность (HA) сохраняет работу сервиса при отказе компонента: несколько инстансов приложения, реплика базы, готовая к failover, резервные load balancer'ы, health check'и, которые обходят сбои. Восстановление после аварий (DR) — о возвращении после того, что HA не может поглотить: падение региона, повреждение данных, ransomware, случайный DROP TABLE, который мгновенно реплицируется на все реплики. DR определяют два числа. Recovery Point Objective (RPO) — сколько данных вы можете позволить себе потерять, в единицах времени: ежечасные бэкапы означают потерю до часа. Recovery Time Objective (RTO) — сколько вы можете простаивать, пока идёт восстановление. Меньшие числа стоят дороже: непрерывное архивирование WAL и point-in-time recovery — для малого RPO, тёплый резерв инфраструктуры — для малого RTO. Храните бэкапы вне сервера, зашифрованными и версионированными, и восстанавливайтесь из них по расписанию.

• Реплики защищают от отказа железа, но не от плохих записей; от них защищают бэкапы.
• Следуйте идее 3-2-1: три копии, два носителя, одна вне площадки.
• Учение по восстановлению измеряет ваш реальный RTO.

05Chaos-тестирование и повседневная эксплуатация

Chaos-тестирование — это намеренное внесение сбоев, чтобы проверить, что система и команда ведут себя как ожидалось. Начинайте с малого и безопасного: на staging убейте инстанс приложения, остановите Redis, добавьте задержку в мок платёжного API, заполните диск — и смотрите, срабатывают ли алерты, правильно ли ведут себя повторы и плавно ли деградирует сервис. Game day — то же самое, но с людьми: отрепетируйте восстановление базы или failover с runbook'ом в руках. Повседневная эксплуатация менее драматична, но важнее: просмотр дашбордов и алертов, установка обновлений безопасности, ротация сертификатов и секретов, наблюдение за ростом диска и базы, проверка задач бэкапа и тестов восстановления, чистка логов и старых сборок, тюнинг медленных запросов и поддержание зависимостей в актуальном состоянии. Отслеживайте toil — повторяющуюся ручную работу — и автоматизируйте то, что возвращается каждую неделю.

06Алертинг по нескольким окнам и нескольким burn rate

Burn rate показывает, как быстро вы тратите error budget относительно плана: burn rate 1 расходует ровно весь бюджет за окно SLO, а 14.4 — 30-дневный бюджет примерно за два дня. SRE Workbook рекомендует сочетать несколько порогов, каждый из которых проверяется на длинном и коротком окне. Будите дежурного, когда за час сожжено 2 процента месячного бюджета (burn rate 14.4, подтверждено за 5 минут) или 5 процентов за шесть часов (burn rate 6, подтверждено за 30 минут). Заводите тикет, когда 10 процентов сожжено за три дня (burn rate 1, подтверждено за 6 часов). Длинное окно даёт значимость, чтобы короткие всплески не будили людей; короткое окно позволяет алерту быстро погаснуть после исправления проблемы. Используйте recording rules, чтобы заранее считать долю ошибок для каждого окна, — так вычисление алертов остаётся дешёвым.

1groups:
2  - name: api-slo-recordings
3    rules:
4      - record: job:slo_errors:ratio_rate5m
5        expr: sum(rate(http_requests_total{job="api",status=~"5.."}[5m])) / sum(rate(http_requests_total{job="api"}[5m]))
6      - record: job:slo_errors:ratio_rate1h
7        expr: sum(rate(http_requests_total{job="api",status=~"5.."}[1h])) / sum(rate(http_requests_total{job="api"}[1h]))
8      - record: job:slo_errors:ratio_rate30m
9        expr: sum(rate(http_requests_total{job="api",status=~"5.."}[30m])) / sum(rate(http_requests_total{job="api"}[30m]))
10      - record: job:slo_errors:ratio_rate6h
11        expr: sum(rate(http_requests_total{job="api",status=~"5.."}[6h])) / sum(rate(http_requests_total{job="api"}[6h]))
12  # Page: (1h > 14.4*0.001 and 5m > 14.4*0.001) or (6h > 6*0.001 and 30m > 6*0.001)

07Правильный выбор SLI: гистограммы latency и зависимости

Хорошие SLI — это отношение хороших событий к валидным, измеренное как можно ближе к пользователям. Для latency используйте гистограммы с границами бакетов на ваших порогах и определяйте SLI как долю запросов быстрее, скажем, 300 ms; перцентили, усреднённые по инстансам, математически неверны, а счётчики бакетов корректно складываются. Исключайте то, что не является вашим сбоем (клиентские ошибки 4xx, health check), но будьте строги к тому, что является: ответ 200 со страницей ошибки — это сбой. Учитывайте зависимости: если вашему сервису синхронно нужны три других по 99.9 процента каждый, достижимая доступность ниже 99.9 процента, если не добавить резервирование, кэширование или graceful degradation. Ваш SLO должен быть слабее произведения жёстких зависимостей, иначе часть из них нужно убрать с критического пути.

• SLI = хорошие события / валидные события в скользящем окне.
• SLI по latency — из бакетов гистограммы, а не из усреднённых перцентилей.
• Жёсткие зависимости ограничивают достижимый SLO.

08Безопасные изменения: progressive delivery и быстрый откат

Большинство инцидентов вызваны изменениями: деплоями, обновлениями конфигурации, миграциями, правками сертификатов или DNS. Уменьшайте радиус поражения каждого изменения. Деплойте постепенно: сначала один инстанс или небольшой процент трафика (canary), сравните его error rate и latency с остальными, затем расширяйте. Отделяйте деплой кода от релиза фич с помощью флагов, чтобы плохую фичу можно было выключить без передеплоя. Делайте миграции базы обратно совместимыми, чтобы предыдущая версия приложения продолжала работать после изменения схемы, — это сохраняет возможность отката. Где можно, автоматизируйте откат при провале canary. Замораживайте рискованные изменения вокруг пиковых бизнес-событий. Отслеживайте change failure rate и время восстановления: они показывают, становится ли доставка безопаснее, и большая часть выигрыша в надёжности приходит отсюда, а не от дополнительного железа.

09Бэкапы, которые восстанавливаются: PITR, неизменяемость и учения

Для PostgreSQL point-in-time recovery сочетает периодический base backup с непрерывным архивированием сегментов WAL, поэтому можно восстановиться на любой момент, например за минуту до случайного DELETE. Инструменты вроде pgBackRest и WAL-G берут на себя сжатие, шифрование, retention и параллельное восстановление из object storage. Защищайте бэкапы от тех же угроз, что и продакшен: используйте отдельные учётные данные, которых нет на серверах приложения, включите versioning или object lock, чтобы ransomware или скомпрометированный сервер не смогли их удалить, и копируйте во второй регион или к другому провайдеру. Затем измеряйте. Плановые учения восстанавливают последний бэкап на новый сервер, запускают проверки целостности и несколько запросов приложения и фиксируют, сколько это заняло. Эта длительность — ваш реальный RTO; возраст самых свежих восстановимых данных — ваш реальный RPO.

1# pgBackRest: full backup weekly, differential daily, WAL archived continuously
2pgbackrest --stanza=main --type=full backup
3pgbackrest --stanza=main --type=diff backup
4pgbackrest --stanza=main info
5 
6# Restore to just before a bad DELETE (run on a fresh server)
7pgbackrest --stanza=main --delta \
8  --type=time "--target=2026-11-05 14:31:00+00" \
9  --target-action=promote restore