Бюджеты ошибок
Что это такое
Бюджет ошибок — это объём отказов, который допускает цель: ориентир в 99,9 процента за тридцать дней допускает около сорока трёх минут недоступности, и этот допуск и есть бюджет. Его тратят инциденты, развёртывания и эксперименты. Когда он исчерпан, приоритет команды смещается с выпуска функций на восстановление надёжности, и правило согласовано заранее, а не обсуждается во время сбоя.
Почему это важно
Бюджет — это то, что превращает ориентир надёжности из утверждения в механизм управления. Он даёт продукту и эксплуатации общее число для рассуждений и разрешает повторяющийся спор — сколько надёжности достаточно — никому не требуя победы. Он делает и риск осознанным: команда может потратить бюджет на рискованную миграцию сознательно, а не делать вид, что риска нет. Альтернатива — знакомая петля: давление функций до сбоя, затем заморозка и чрезмерная коррекция.
Ключевые идеи
Бюджет — это скорость, а не запас
Бюджет пополняется по мере скольжения окна. Команда, потратившая его за первую неделю, получает спокойный остаток, а та, что не потратила ничего, не обязательно молодец — возможно, она ничего не тратит, потому что ничего не выпускает. Полезно читать тенденцию и скорость траты, а не одно сегодняшнее число.
цель 99,9% за 30 дней -> около 43 минут
потратили 30 минут за неделю -> притормозите, пока окно не сдвинется
Исчерпание меняет приоритет, а не назначает виноватого
Правило такое: когда бюджет кончился, работа над надёжностью имеет приоритет над новыми функциями, пока он не восстановлен. Это политическое решение, принятое пока все спокойны. Применённое во время инцидента, оно становится обвинением — поэтому политика должна существовать до момента, когда её применяют.
Каждое развёртывание тратит немного бюджета
Релиз добавляет риск; именно поэтому бюджет существует, а не чтобы его избегали. Команда может потратить его сознательно на изменение, которое, скорее всего, что-то сломает, в обмен на то, чтобы не тратить в другом месте. Измерение отказов, связанных с развёртыванием, против бюджета — так цена рискованного изменения становится видна до его совершения.
Заморозка — не то же самое, что исправление
Когда бюджет кончается, задача — найти и устранить причину траты, а не просто перестать развёртывать. Заморозка, которая ничего не чинит, оставляет систему ровно такой же хрупкой и откладывает следующий релиз. Ценность бюджета в том, чтобы направлять эту работу, поэтому заморозка без причины — потерянный квартал.
Бюджет определяет пороги оповещений
Если цель допускает небольшую долю ошибок за длинное окно, оповещение не должно срабатывать на долю внутри бюджета. И наоборот, быстрое выгорание, которое исчерпало бы бюджет за часы, заслуживает вызова. Здесь цель становится практичной: порог оповещения выводится из скорости выгорания бюджета, а не из формы вчерашнего графика.
Нужен владелец, который может менять цель
Бюджет без владельца — это число, которому никто не подчиняется. Кто-то должен отвечать и за его применение, и за пересмотр, когда меняется бизнес. Если цель нельзя ни поднять, ни опустить, механизм превращается в ловушку, а не в договорённость.
Практика
Посчитайте бюджет и его выгорание
Для сервиса с заявленной целью вычислите допустимое время отказов в тридцатидневном окне, затем назовите долю ошибок, которая исчерпала бы его за шесть часов.
Готово, когда: вы можете назвать долю, которая оправдывает вызов, и долю, которая не оправдывает.
Напишите политику исчерпания
Запишите, что команда делает, когда бюджет исчерпан: кто решает, какая работа получает приоритет и как бюджет восстанавливается.
Готово, когда: политика называет решающего и конкретное первое действие, и она была написана до того, как бюджет потратили.
Частые ошибки
- Относиться к бюджету как к запасу, который копят — не тратить ничего значит ничего не выпускать; исправить: тратьте его сознательно на изменения, несущие риск.
- Применять политику как обвинение — спор становится личным, а правило забрасывают; исправить: согласуйте политику заранее и применяйте автоматически.
- Замораживать, ничего не исправляя — после заморозки система ровно так же хрупка; исправить: используйте исчерпание бюджета, чтобы направить работу над надёжностью.
- Игнорировать бюджет при настройке оповещений — оповещения срабатывают внутри допустимой доли отказов и теряют доверие; исправить: выводите пороги из скорости выгорания.
- Оставлять бюджет без владельца — его никто не применяет и не пересматривает; исправить: назовите владельца, отвечающего за цель и политику.
Что читать дальше
- Цели уровня обслуживания (06-cloud-devops/23-site-reliability-engineering/01-service-level-objectives) — ориентир, недостачу которого измеряет этот бюджет.
- Обеспечение надёжности сайтов (06-cloud-devops/23-site-reliability-engineering) — практика, которой управляет бюджет.
- Дашборды и оповещения (06-cloud-devops/18-monitoring-observability-prometheus-grafana/02-dashboards-and-alerting) — где скорость выгорания бюджета становится оповещением, на которое стоит реагировать.