Метрики без насилия 99,99% availability не всегда лучше 99,9%

Хотим availability 99,99%.

Звучит очевидно: чем больше девяток, тем надёжнее система. Тогда почему бы сразу не потребовать 99,99999%?

Потому что каждая следующая девятка стоит денег, времени и инженерных ограничений.

Она требует больше резервирования, более сложного мониторинга, быстрых механизмов восстановления и осторожных релизов. Иногда это оправданно. Иногда мы просто строим космический корабль для поездки в соседний магазин.

Надёжность должна определяться требованиями продукта, а не инженерным перфекционизмом.

Для этого обычно используют три понятия.

SLI — что именно измеряем.

Например, долю запросов, завершившихся успешно.

SLO — какой уровень хотим обеспечить.

Например: 99,9% успешных запросов за 30 дней.

Error budget — сколько ошибок можем допустить, не нарушив SLO.

Для SLO по времени доступности разница хорошо видна на цифрах:

— 99,9% оставляет около 43 минут недоступности за 30 дней; — 99,99% — около 4 минут; — 99,999% — примерно 26 секунд.

Перейти от 43 минут к четырём — не просто поправить число в документе. Системе может понадобиться другая архитектура, другой процесс релизов и совсем другая стоимость эксплуатации.

Но самое полезное в error budget даже не расчёт допустимых отказов.

Он связывает две конфликтующие силы.

Разработка хочет быстрее выпускать изменения, экспериментировать и проверять гипотезы.

Reliability требует стабильности, дополнительных проверок и меньшего количества рискованных изменений.

Без общей метрики спор быстро превращается в:

— Нам надо быстрее. — Нам надо надёжнее.

С error budget появляется измеримая договорённость.

Если бюджет почти не расходуется, команда может позволить себе больше изменений.

Если он быстро сгорает, уменьшаем риск: замедляем релизы, разбираемся с причинами отказов и вкладываемся в восстановление.

Важное ограничение: error budget нельзя превращать в KPI разработчика.

Его задача — не найти человека, который «потратил наши минуты недоступности». Это не табель инженерной виновности.

Error budget ограничивает всю систему delivery: архитектуру, тестирование, релизы, мониторинг и восстановление после сбоев.

Надёжность тоже имеет стоимость.

Поэтому правильный вопрос звучит не так:

«Как сделать систему максимально надёжной?»

А так:

«Какой уровень надёжности нужен бизнесу и какой риск он готов принять?»