Допустим, у вас есть сервис, который должен работать 99.9% времени. Это значит, что 0.1% времени он может лежать – и это нормально.
Но что делает большинство разработчиков и менеджеров? Паникует при каждом сбое и бросается чинить баги любой ценой. И вот тут SRE-инженеры говорят: «Стоп! Давайте посчитаем Error Budget».
Это запас «разрешённых» сбоев, который закладывается в SLO (Service Level Objective). Например, если ваш SLA — 99.9% аптайма в месяц, значит, вы можете позволить себе до 43 минут простоя. Подробнее о сути и различиях SLO и SLA, писали тут.
Почему иногда баги лучше не чинить?
Как использовать Error Budget?
— Если бюджет заканчивается раньше срока → замедляем релизы, усиливаем тестирование.
— Если бюджет не исчерпан → можно делать более агрессивные изменения и не бояться экспериментов.
— Если сервис часто выходит за рамки бюджета → нужно пересматривать архитектуру, мониторинг и процессы.
Вывод:
Error Budget — это не просто цифры, а инструмент управления балансом между скоростью и надёжностью. Иногда лучше оставить баг в покое и не ломать систему ради фикса.
Но что делает большинство разработчиков и менеджеров? Паникует при каждом сбое и бросается чинить баги любой ценой. И вот тут SRE-инженеры говорят: «Стоп! Давайте посчитаем Error Budget».
Что такое Error Budget?
Это запас «разрешённых» сбоев, который закладывается в SLO (Service Level Objective). Например, если ваш SLA — 99.9% аптайма в месяц, значит, вы можете позволить себе до 43 минут простоя. Подробнее о сути и различиях SLO и SLA, писали тут.
Почему иногда баги лучше не чинить?
- Фикс может сломать что-то ещё — исправление одного бага может породить новые инциденты.
- Релизная гонка — если Error Budget не исчерпан, лучше сфокусироваться на фичах, а не на «перестраховке».
- Приоритеты бизнеса — иногда баг мешает 1% пользователей, а новая фича увеличит доход на 10%.
Как использовать Error Budget?
— Если бюджет заканчивается раньше срока → замедляем релизы, усиливаем тестирование.
— Если бюджет не исчерпан → можно делать более агрессивные изменения и не бояться экспериментов.
— Если сервис часто выходит за рамки бюджета → нужно пересматривать архитектуру, мониторинг и процессы.
Вывод:
Error Budget — это не просто цифры, а инструмент управления балансом между скоростью и надёжностью. Иногда лучше оставить баг в покое и не ломать систему ради фикса.
