Изменил формулу SLI — и сломал историю. Почему это ошибка и что делать вместо этого?

Привет, %username%! Пока я нахожусь в активном поиске работы, решил расписать подробно один тезис, который внезапно сформировался на прошедшем DevOpsConf 2026. Знакомая ситуация: измерял сервис одним способом, потом понял, что формула кривая, и просто поправил SLI. Кажется — исправил ошибку. На самом деле — создал новую, куда серьёзнее.

Когда меняется формула расчёта SLI, данные до и после этой точки описывают принципиально разные вещи. В статистике это называется structural break — и именно поэтому статистические агентства при смене методологии никогда не правят исторические ряды задним числом, а ведут два ряда параллельно.

В контексте SLO это особенно больно: error budget считается нарастающим итогом за 28–30 дней. Если SLI резко скакнул из-за смены формулы — error budget либо обнулится, либо станет «бесконечным», хотя реальная надёжность сервиса не изменилась ни на байт.

Что делать правильно:

- Aspirational SLO — запускаешь новый SLO параллельно старому без enforcement. Старый работает, новый наблюдается. Никто не "облажался", просто появился более точный взгляд — это паттерн из Google SRE Workbook;
- Новая метрика вместо изменения старой — именно так устроен мир Prometheus/OpenTelemetry: не переименовывай, а создавай новую и deprecate'ни старую по циклу, как это делает Kubernetes;
- Ретроактивная проверка — если меняешь только порог SLO (не формулу SLI!), можно проверить на исторических данных: поймал бы новый SLO реальные инциденты, нет ли false positives;

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

Кратко: изменение математики SLI — это не fix, это создание нового измерения. Старое не удаляй, запускай новое рядом, переходи через согласованный deprecation-цикл с явной датой и документацией.

Делитесь в комментариях — сталкивался ли ты с ситуацией, когда формулу SLI хотелось «подправить»? Как решал? Что больнее — series break в метриках или объяснение stakeholder'ам, почему error budget внезапно изменился?

PS: Еще у нас разгорелся холивар на тему надежность vs доступность — пиши в комментах, если интересны подробности.

#SRE #SLO #SLI #Reliability #ErrorBudget #Observability #DevOps #Metrics #SiteReliabilityEngineering #OnCall