Бюджеты ошибок — Примеры
Пример 1 — Превращение цели в порог оповещения
У команды есть цель и растущий набор оповещений, выбранных наугад. Выясните, что допускает цель за своё окно, и какая доля ошибок должна вызывать.
иллюстративные числа
цель checkout: 99,9 процента запросов успешно, скользящие 30 дней
вопрос сколько это отказов и какая доля ошибок должна вызывать?
Решение
окно 30 дней = 43 200 минут
допустимый отказ 0,1 процента окна = около 43 минут
бюджет — это скорость он пополняется по мере скольжения окна
вызов по выгоранию доля, которая израсходовала бы 43 минуты примерно за шесть часов
43 / 360 ≈ 12 процентов запросов, отказывающих непрерывно
не вызывать доля внутри бюджета, например 0,2 процента за пять минут
решение быстрое выгорание вызывает; медленное становится задачей
Теперь порог выводится из допуска, а не из вчерашнего графика, поэтому он переживёт рост трафика. Та же арифметика говорит, какие доли ошибок можно оставить в покое, — именно это сохраняет доверие к правилам вызова. Обычная ошибка — оповещать по самой маленькой доле, которая выглядит тревожно: правило срабатывает глубоко внутри бюджета, пока его не перестают читать.
Пример 2 — Заморозка, которая ничего не исправляет
Миграция прошла плохо, и большая часть месячного допуска была потрачена за неделю. Заморозку объявили как выговор, работы по исправлению никто не записал, поэтому та же миграция снова стоит в плане. Напишите политику, которую команде следовало согласовать заранее.
иллюстративные числа
цель checkout: 99,9 процента за 30 дней
трата за неделю 31 из 43 минут, из-за одной миграции
что произошло заморозка, объявленная в канале инцидента, названный виновник, ни одной задачи-продолжения
Решение
владелец руководитель команды checkout, названный в цели
условие скользящий 30-дневный допуск исчерпан
первое действие остановить выпуск функций и завести задачу надёжности с причиной траты
приоритет сначала работа над надёжностью, пока бюджет не восстановлен
вина нет; миграция была осознанным риском, а политика существовала до траты
восстановление исправление выходит обычным проверенным изменением
Исчерпание меняет порядок работы, а не положение людей, потративших бюджет, и оно работает, только если было согласовано, пока все спокойны. Требование найти причину — то, ради чего заморозку стоит затевать: остановка развёртываний без исправления оставляет систему такой же хрупкой, как раньше. Обычная ошибка — применить её посреди инцидента как обвинение, после чего её никто не соблюдает.