惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

J
Java Code Geeks
Martin Fowler
Martin Fowler
B
Blog RSS Feed
D
DataBreaches.Net
L
LangChain Blog
月光博客
月光博客
S
SegmentFault 最新的问题
阮一峰的网络日志
阮一峰的网络日志
V
Visual Studio Blog
美团技术团队
Jina AI
Jina AI
博客园 - 司徒正美
雷峰网
雷峰网
Last Week in AI
Last Week in AI
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
IT之家
IT之家
博客园 - 三生石上(FineUI控件)
WordPress大学
WordPress大学
小众软件
小众软件
罗磊的独立博客
博客园_首页
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
A
About on SuperTechFans
Engineering at Meta
Engineering at Meta

Все публикации подряд на Хабре

Ловим музу за клавиатуру: как айтишнику стать автором Что умеет Midjourney в 2026? Мой немного грустный разбор этого шикарного инструмента Никто не любит писать тесты, но ИИ может исправить это IPv8 выглядит как мечта. Поэтому почти наверняка не взлетит Производители вернули в продажу материнки с DDR3. Что происходит? Управление агентом с телефона через Telegram теперь в KodaCode От координации к лидерству: как меняется роль руководителя разработки Я сделала родителям бизнес вместо пенсии: зарабатываем 70 тысяч, мама не даёт продать В три раза быстрее приемка товара и оптимизация трудозатрат на 73%: как «РСТ-Инвент» помог Gulliver Group ИИ-шечный мир победил? О влиянии искусственного интеллекта на игропром Кремль снижает давление на Телеграмм пока Европа строит интернет по паспорту Как CEO, CTO и CIO за 8 часов собрали ИИ-директора, который умеет держать позицию под давлением Как (не) потерять домен за выходные Вместо 8 разных VPS: как я организовал практику студентам на одном сервере Почему твой Open Source проект не замечают? R&D: искусство управления неопределенностью в разработке AI-дефляция: вакансий для разработчиков больше, а рост зарплат — худший за 15 лет Мы отдали управление роботами OpenClaw. Что из этого вышло Галактический ID: система идентификации для всех форм разумной жизни Шесть основ бизнес-анализа: начинаем с вопроса «Кто в игре?» Код-ревью, в котором дело не в коде Данные переехали. Команда — нет Системной подход к сдаче OSWE в 2025 Почему комната управления реактором покрашена в цвет морской пены 4 YAML-файла вместо PySpark: как аналитикам строить пайплайны без разработчиков LLM-агент для поиска свободных доменов: автоматизируем подбор Когда, зачем и как правильно начинать новую сессию в Claude Code? Как я заставил нейросеть писать макросы для FreeCAD Анатомия ИИ‑агента для подбора персонала. От тысячи резюме к топ‑10 за минуты Опыт разработчика как экономика внимания
SLI/SLO. Что такое Error Budget Burn Rate на самом деле
r3code · 2026-04-27 · via Все публикации подряд на Хабре

Привет, меня зовут Дмитрий Синявский. Я инженер по надёжности сервиса в Ви.Tech и одна из моих любимых тем SLI/SLO. Сегодня разберемся с "скоростью расхода бюджета ошибок".

Недавно я провел опрос в канале сообщества ALLSLO, в котором спрашивал вызывает ли понимание термина Error budget burn rate сложности. В опросе верный ответ отсутствовал и был вариант "нет верного ответа", однако более 40% выбрало неверный ответ. Потому давайте разберемся, что же это такое Error budget burn rate.

SLI/SLO/Error budget

SLI - это service level indicator, показатель уровня сервиса. Тут мы договариваемся, что считаем за error: определенные события или минуты. Чаще всего вы увидите формулу SLI=1-(errors/total). Углубляться тут не будем - детали есть в Google SRE Book.

SLO - это service level objective, целевой уровень сервиса. Обычно мы это задаем, например, как доступность API 99% за 30 дней (контрольное окно SLO).

Error budget - это наш запас на ошибки, считаем по формуле 100-SLO, т.е. Error budget = 100 - 99 = 1%. Если у нас было 100 000 запросов в месяц, то мы могли спокойно проводить 1000 из них. Или мы могли бы иметь 43.2 плохил минут, т.к. в месяце 43200 минут.

Error budget burn rate появляется на сцене только в момент, когда вам нужны алерты по SLO и служит основным показателем расчёта условий срабатывания алерта для метода Multi Window Multi-Burn Rates Alerting описанном в https://sre.google/workbook/alerting-on-slos/.

Сложности перевода и стереотипы

Переводя дословно Error budget burn rate (EBBR) как «скорость расхода бюджета ошибок» мы попадаем в ловушку наших знаний и понятий.

Прикол в том, что со школы мы знаем - скорость = расстояние делить на время (км/ч). И очень сложно себя переубедить в другом.

Однако, как правильно написал Анатолий в комментарии к опросу:

burn rate это безразмерное отношение, а не скорость с размерностью "ошибок в час" или "% в минуту". это же ratio, отсюда и rate. в данном случае это точно не скорость, а скорее коэффициент. или ставка, как например salary rate

Если же мы считали бы это "скоростью", то это действительно могло бы быть % расхода бюджета в минуту, но это не так - это сложнее.

Разбираемся с базой для расчета

Так отношение чего к чему показывает нам EBBR?

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

Допустимая средняя скорость расхода (average error rate, допустимый уровень ошибок) - это та часть бюджета, которая допустимо терять в день, час, минуту на протяжении всего контрольного периода (окно SLO),. Например, допустимый уровень ошибок в окне 30 дней и бюджете в 1% = 1%/30д = 0,033% / день, или 1%/(30*24)=0,01388% / ч. Но это все еще не безразмерный коэффициент. Это константа - та "скорость" при которой бюджет полностью будет израсходован концу 30 дней.

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

Я для примера возьму конфетную фабрику, а не IT-сервис. Т.к. это очень похоже, но думать про это вкуснее ).

Если у нас план 1 млн конфет в 30 дней и брак допустим до 1%, значит 10 000 это наш Error budget. Значит мы можем иметь допустимый уровень ошибок ( average error rate ) не более 10000×(30×24) = 13.88 конфет / час.

Error budget burn rate

На нашей конфетной фабрике мы контролируем количество брака раз в час и раз в 5 минут. И вот в прошлом часу у нас было в среднем конфет плохих 2, а в этом часу 28 - х2 от допустимого. Смотрим среднее за последние 5 минут - там такое же отношение х2, т.е. лучше не становится. Мы договорились, что такой случай это уже явные долгие проблемы, а не разовый сбой - пора обратить внимание.

Вот этот коэффициент - отношение реальной скорости расхода к и есть Error budget burn rate, т.е. он показывает во сколько раз быстрее мы расходуем бюджет по отношению к допустимой скорости расхода.

Я называю у нас Error budget burn rate - кратность превышения уровня ошибок. Главное слово тут "кратность", которое само по себе говорит о наличии базы.

Что говорит нам кратность 10 - то что при сохранении этой частоты ошибок в приложении мы израсходуем бюджет в 3 дня, а не в 30.

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

P.S. если для вас загадка, как вычислить время срабатывания алерта на SLO по MWMBR методике, то посмотрите этот калькулятор https://burnrate.netlify.app