43 минуты в месяц. Как бюджет ошибок заканчивает спор о надёжности

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

Причина не в людях. Аргументы несопоставимые: одни говорят про риск, другие про выручку. Общей единицы нет. А пока её нет, спор решается голосом.

Перевести разговор в арифметику придумали в Google и описали в книгах про SRE. Инструмент называется бюджетом ошибок, и идея укладывается в строчку: стопроцентной надёжности не существует, значит у недоступности есть разрешённая норма, а норму можно посчитать в минутах и тратить как деньги.

Посчитайте свои минуты

Берём цель доступности, вычитаем из ста процентов, умножаем на длину окна. В месяце 43 200 минут, в году 525 600.

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

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

Другая архитектура, другие деньги, другой найм. Когда цифра названа вслух, желающих обычно не остаётся.

Откуда брать саму цифру

Таблица бесполезна, пока непонятно, что именно считать доступностью. Развилок три. Пройти их надо до первого расчёта.

Не аптайм, а доля запросов. Сервер живой. Отвечает за восемь секунд, по аптайму всё прекрасно, а пользователь уже ушёл. Считать надо долю успешных запросов, а для всего, где важна скорость, ещё и долю уложившихся в порог: например, 99,9% запросов быстрее 300 мс.

Брать эти числа удобнее всего из логов балансировщика или ингресса: там есть и коды ответов, и длительность, и они не зависят от того, дожил ли сервис до отправки метрики. Метрики приложения тоже годятся. Но у них неприятное свойство: во время настоящей аварии они перестают доезжать первыми.

Клиентские ошибки не считаются. Четырёхсотые коды это не ваш отказ, а неверный запрос, и включать их в бюджет значит наказывать себя за чужие кривые интеграции. Исключения бывают: 429 от вашего же лимитера или 404 на странице, которая должна существовать, вполне ваши. Список исключений пишется один раз и фиксируется вместе с целью.

Цель ставится на сценарий, а не на компонент. Доступность базы 99,99% не говорит ничего о том, может ли человек оплатить заказ: между ним и базой пять сервисов, очередь и внешний платёжный шлюз. Мерить надо оплату целиком, от запроса до ответа пользователю.

Что делать с чужими зависимостями

Возражение, которое прилетает первым: половина нашего простоя — это внешний шлюз, мы на него не влияем, зачем нам бюджет?

Бюджет тратится независимо от того, кто виноват. Пользователю всё равно, чей отказ он видит, и цель ставится на пользовательский сценарий, а не на вашу зону ответственности.

Польза при таком счёте только растёт. Через квартал у вас есть цифра: столько‑то минут бюджета сожжено чужим шлюзом. С такой цифрой можно идти на три разговора — к поставщику с требованием SLA, к бизнесу с предложением резервного провайдера, к себе с вопросом, почему отказ шлюза роняет всю оплату вместо деградации в отложенный платёж.

Разделить бюджет на свои и чужие отказы можно, но только вторым слоем, для разбора. Основной бюджет остаётся один, иначе у команды появляется удобная категория «это не мы», и она начинает расти.

Политика важнее метрики

Сам по себе бюджет это число на дашборде. Посмотрят и забудут. Работать он начинает, когда появляется политика: документ на страницу, где заранее написано, что происходит при разных уровнях расхода.

Минимальная рабочая версия, окно скользящее, 28 дней:

• Потрачено меньше 50% — фичи катятся как обычно, никаких ограничений.

• Потрачено больше 50% — рискованные изменения ждут, приоритет на устранение причин.

• Бюджет кончился — релизы фич останавливаются, команда работает на надёжность, пока окно не сдвинется.

Работать документ будет или ляжет в вики, решают три вещи.

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

2. У заморозки должно быть именное исключение. Один конкретный руководитель может её снять, письменно, с указанием причины. Не «по согласованию с руководством», а фамилия и дата. Исключения будут в любом случае, пусть у них будет автор.

3. И плановые работы тоже тратят бюджет. Миграция, уронившая сервис на двадцать минут, съедает те же минуты, что и авария. Без этого пункта очень быстро выясняется, что половина простоев была запланированной, а значит, как бы не считается.

Скорость расхода важнее остатка

Обычный алерт на доступность плох в обе стороны. Он звенит на каждом коротком всплеске, и его быстро начинают игнорировать. А еще он молчит при медленной деградации, которая спокойно съедает месячный бюджет за неделю по полпроцента в час.

Вместо порога по доступности смотрят на скорость сжигания: во сколько раз быстрее нормы уходит бюджет. Единица значит, что вы потратите его ровно к концу окна. Идёте по плану. Десятка значит, что уложитесь в три дня.

Канонический набор смотрит на два окна сразу, длинное и короткое, чтобы не будить людей из‑за секундных всплесков:

Константы привязаны к тридцатидневному окну. Для окна в 28 дней те же проценты дают 13,44 и 6,72, и пересчитывать надо честно, а не копировать цифры из чужого поста.

Заодно уходит старый шум. Алертов становится меньше в разы: большая часть прежних срабатываний не тратила заметной доли бюджета, а значит, и будить из‑за них было незачем.

Как может измениться разговор с продуктом

Было так: «Нам нужен спринт на техдолг, иначе всё развалится». Аргумент слабый, потому что «развалится» это прогноз, а прогнозам продукт верить не обязан.

Стало так: «За 28 дней мы сожгли 140% бюджета, из них 60% ушло на одну причину, вот список работ на неделю». Спорить не с чем. Цифра посчитана по прошлому, а не по страху.

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

Три способа получить бумагу вместо инструмента

• Цель назначена от балды, обычно завышена. Признак — бюджет не расходуется месяцами вообще.

• Заморозку отменили на второй раз. После этого политики больше нет, и ввести её заново тяжелее, чем с нуля.

• Никто не смотрит на бюджет между инцидентами. Цифра должна жить в канале и на общем дашборде, а не в квартальном отчёте.

К отмене стоит готовиться заранее: она случится, вопрос только в том, будет она исключением с фамилией или тихим звонком. Первое политику сохраняет, второе убивает.

Что можно сделать уже сейчас

Возьмите один сервис, который чаще других роняет прод, и выгрузите за прошлый квартал логи балансировщика по нему. Посчитайте долю ответов с кодами 5xx и долю ответов медленнее порога, который кажется вам разумным для пользователя.

Полученное число и есть ваша фактическая доступность. Цель ставьте чуть строже. Была 99,7% — ставьте 99,8%, а не 99,99%, иначе бюджет кончится в первую неделю и политику придётся отменять.

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

А у вас бюджет ошибок живёт как метрика или как правило с последствиями? Расскажите в комментариях, доходило ли до настоящей заморозки релизов и чем это кончилось.

Надёжность системы начинается с понимания того, что происходит внутри production: где возникают узкие места, какие сбои действительно влияют на пользователей и какие метрики помогают принимать решения.

На открытых уроках разберём инструменты и подходы, которые помогают строить наблюдаемые и отказоустойчивые системы:

• 23 сентября в 20:00. «eBPF: рентгеновское зрение для production». Записаться

• 23 сентября в 20:00. «Узнайте, как использовать Patroni для управления высокодоступными кластерами PostgreSQL». Записаться

• 20 октября в 20:00. «OpenTelemetry в.NET: от чёрного ящика к наблюдаемой системе». Записаться

Полный список бесплатных уроков сентября уже собрали в дайджесте.