Продакшн-отказы SLO, самонаблюдаемость, безопасность и общая картина

Платформенная команда имеет MWMBR-алерты, Sloth-генерированные recording rules и подписанную error budget policy. Половина команд игнорирует SLO-алерты. Проблема не в инструментарии — в том, что SLI не коррелируют с болью пользователя, и policy так и не применялась.

Реальные продакшн-отказы

Четыре кейса, раскрывающие failure mode’ы:

Stripe 2022 — policy сработала: Checkout SLO на 99.99% был нарушен внутренне (инженеры заметили через burn rate), но внешнее SLA (99.9%) было выполнено. Предопределённая error budget policy команды автоматически заморозила новые деплои фич на 3 дня пока команда надёжности расследовала — предотвратив второй инцидент на всё ещё деградированном code path. Policy была активирована, применена, и заморозка держалась без исполнительного переопределения. Урок: когда policy подписана и команда считает её применимой, она работает именно так, как задумано. SLO поймал то, что ручной мониторинг мог пропустить.

GitHub 2023 — SLI был неверным: SLO-платформа GitHub неправильно считала фоновые job-отказы как user-facing события на протяжении квартала, поедая reliability-бюджет и запуская разговоры культуры обвинений. Команды наказывались за «инциденты», которых пользователи никогда не испытывали. Postmortem сбросил определение SLI только на journey-уровень (user-facing запуски GitHub Actions, не обработка внутренних очередей). Урок: определение SLI — самое важное решение — неверное отравляет данные целого квартала и может разрушить доверие к SLO-программе до её установления.

Coinbase 2024 — budget policy остановила рискованное расширение: Multi-region деплой нарушил 99.99% trading API SLO на 8 минут из-за неправильно настроенного load balancer. Error budget policy сработала в течение 24 часов, и команда поставила на паузу новые региональные запуски на неделю. Пауза позволила команде надёжности провести аудит инструментария multi-region деплоя и найти два дополнительных паттерна неправильной конфигурации до того, как они вызвали инциденты. Урок: заморозка — не наказание, а forcing function, направляющий инженерные усилия на хрупкость, только что проявившую себя.

Netflix 2024 — SLO намеренно ослабили: Внутренний SLO Netflix для воспроизведения видео был ослаблен с 99.99% до 99.95% после шестимесячного обзора, показавшего что пользователи не могут ощутить разницу при 99.95%, но инженерная стоимость поддержания лишней девятки была значительной. Урок: SLO — живые цели, эволюционирующие с системой и пользовательскими исследованиями. «Жёстче — всегда лучше» — ложь. Ежеквартальный обзор существует для проведения именно этого эксперимента.

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

Наблюдаемость для самих SLO

Мета-вопрос: как узнать что SLO-платформа работает?

Сигнал 1 — ratio_total никогда не должен быть NaN: Если SLI знаменатель равен нулю (нет трафика, граничный случай малого трафика, сброс счётчика), recording rule производит NaN. NaN burn rate невидим: алерт ни правильно срабатывает, ни правильно очищается. Мониторить sum(rate(http_request_total[5m])) == 0 и алертить на это отдельно — «у нас нет сигнала трафика» само по себе условие алерта.

Сигнал 2 — долгооконный burn rate должен быть стационарным: Построй 3д burn rate за 90 дней. Он должен осциллировать около 1x в среднем (точно выполняя SLO; некоторые недели выше, некоторые ниже). Устойчивое среднее 1.5x значит SLO-цель слишком жёсткая для текущей системы — постоянный стресс, постоянный риск заморозки. Устойчивое среднее 0.3x значит цель слишком свободная — сверхинжениринг надёжности, которая никому не нужна. Стационарность около 1x значит цель откалибрована.

Сигнал 3 — исходы policy должны соответствовать истории горения: Если история burn rate за 3 месяца показывает три периода ухода бюджета в минус без активированных заморозок, policy переопределяется. Либо policy не имеет реальных полномочий (нужна повторная подпись на уровне директора), либо команды не знают что она применима к ним (пробел коммуникации). SLO-мета-дашборд должен отслеживать: количество активных SLO, количество текущих горящих выше 1x, средний оставшийся бюджет, время последней заморозки на SLO.

Безопасность и SLO: два пересечения

Пересечение 1 — бот-трафик перекашивает SLI: Успешный но злонамеренный запрос считается «хорошим» в availability SLI — атака credential stuffing, возвращающая 200 OK, проходит SLO. Бот-трафик раздувает знаменатель и может маскировать реальные проблемы пользователей: 1000 бот-запросов в секунду могут разбавить 1% error rate на легитимном трафике до измеренного 0.01% error rate. Сениорный паттерн: считать SLO по фильтрованному трафику (отбрасывать известных ботов, rate-limited IP, сканерный трафик из тестирования безопасности). SLI должен отслеживать здоровье реальных пользователей, не всего трафика.

Пересечение 2 — SLO-горение как сигнал безопасности: Падение доступности без причины в инфре — нет деплоев, нет изменений конфигурации, нет деградации upstream — может быть первым симптомом DDoS или бэкенд-эксплойта. Несколько incident-response playbook’ов включают «проверить SLO burn rate» как шаг в чеклист security-инцидента, наряду с проверками аномалий логов и анализом сетевого трафика. Spike burn rate в 3 ночи в субботу без коррелированного infra-события заслуживает security-взгляда даже до нахождения инфраструктурного объяснения.

Общая картина

SLO — не число на дашборде. Это контракт, превращающий продуктовые решения в инженерную арифметику. Error budget — мост между «хотим шипить» и «хотим быть надёжными». MWMBR-алерт — мост между «бюджет тратится» и «разбудить инженера». Error budget policy — мост между алертом и org chart.

Почему команды бросают SLO:

• SLI не коррелирует с болью пользователя → алерты — шум → команда учится их игнорировать
• SLO-цель слишком жёсткая → постоянные заморозки → давление продукта переопределяет → policy теряет силу
• Policy никогда не подписана на уровне директора → «совещательные» SLO, на которые никто не реагирует
• Нет ежеквартального обзора → SLO дрейфует от реальных нужд пользователей → неверный сигнал два года

Почему команды преуспевают с SLO:

• Начинают с одного journey, валидируют SLI против реальных репортов пользователей
• Ставят консервативную начальную цель, ужесточают ежеквартально
• Проводят fire drill перед запуском
• Получают подпись директора до первого freeze-события (не во время него)
• Проводят ежеквартальный обзор с участием продукта