Лекция «Надёжность в цифрах: SLA, SLO и бюджет ошибок»

Около 70 минут на 20 тем. Прогресс сохраняется, поэтому лекцию можно проходить частями и возвращаться к ней позже.

Начало — да: первые 1 тема открыты сразу, без регистрации. После бесплатной регистрации откроются темы до 2-й — вместе с частью из 59 тестов и монетами за верные ответы. Полная лекция — 99 ₽ навсегда, либо подписка на все лекции платформы от 499 ₽ в месяц.

Двадцать тем о том, как обещание надёжности становится числом, за которым следуют действия. Первая часть — арифметика: допустимый простой равен (1 − цель) × длительность окна, откуда 43 минуты 12 секунд для цели 99,9% на тридцати днях, 52,56 минуты в год для 99,99% (число названо прямо в SRE Book) и 25,9 секунды для пяти девяток на месяце. Здесь же показано, что окно — половина определения: та же цель даёт 40 мин 19 с на скользящих четырёх неделях и 44 мин 38 с в январе, разброс больше десяти процентов бюджета при неизменном поведении системы. И здесь же разведены два законных определения доступности: коэффициент готовности по ГОСТ 27.002-2015 (п. 3.6.6.1, вероятность работоспособного состояния, с примечанием об исключении планируемых периодов) против доли успешных запросов, которую SRE Book предпочитает для распределённых систем, потому что такой сервис «at least partially "up" at all times». Вторая часть — как индикатор собирается: каноническая форма «хорошие события / все валидные», и вся работа в знаменателе, где решения о нагрузочных тестах, пентестерах, ботах и 4xx двигают итог; четыре точки замера, дающие четыре разных числа на одних данных, и правило «сервер, который лежит, не пишет в свой журнал о том, что он лежит»; счёт по запросам против счёта по окнам с прямо названным ограничением оконного способа — он прячет всплески и уравнивает интервалы с разной активностью, плюс техническое требование DELTA или CUMULATIVE вместо GAUGE. Третья часть переводит бюджет из минут в события: 1000 ошибок при 99,9% и миллионе запросов за четыре недели, три одновременные цели рабочего примера с бюджетами 109 897, 366 325 и 36 632, и расчёт по модели, показывающий, что одни и те же пятнадцать минут отказа стоят 37% месячного бюджета в средний час, весь бюджет в пиковый и 7,4% ночью — разница в двадцать пять раз, которой счёт в минутах не видит. Дальше скорость сжигания: таблица 5-4 (1 / 2 / 10 / 1000 и 30 дней / 15 дней / 3 дня / 43 минуты), конфигурация 14,4 / 6 / 1 из таблицы 5-8 с выводом порогов по формуле «скорость × окно / период», правило короткого окна в одну двенадцатую длинного и отдельная тема про низкий трафик, где десять запросов в час дают бюджет в семь отказов за месяц, один отказ съедает 13,9%, а цель в четыре девятки не измерима в принципе. Четвёртая часть — потолки: произведение доступностей жёстких зависимостей (0,999⁵ = 99,501%, 0,999¹⁰ = 99,004%) с оговоркой, что мягкие зависимости в произведение не входят, и с явным указанием, что правила «зависимость на порядок надёжнее» в главе «Embracing Risk» нет; гарантия платформы ТАЙМВЭБ.КЛАУД по редакции от 11.08.2026 — 99,8% и 99,5% годовых, то есть 17 ч 31 мин и 43 ч 48 мин; и отдельная тема о том, что договорный знаменатель другой — из него исключены аварийные работы и всё время после выдачи обходного решения, а компенсация за семичасовой простой сервера за 3 000 ₽ в месяц составляет около 100 ₽. Пятая часть — почему сто процентов неверная цель: слабое звено находится у пользователя, «a user on a 99% reliable smartphone cannot tell the difference between 99.99% and 99.999%», фон ошибок канала — диапазон 0,01–1%, а не одно число, и нелинейная цена девятки, где переход с 99,9% на 99,99% при выручке в миллион долларов стоит ровно 900 долларов выгоды. Шестая часть — документ: разделы политики бюджета ошибок, подписи продуктового менеджера, разработки и SRE, условие «не подписывают — значит цель выбрана неверно», формулировка заморозки с двумя исключениями, перечень случаев, когда надёжность обязательна и когда можно продолжать функции, пороги в 20% бюджета, обязывающие к разбору, эскалация спора о расчёте до CTO — и масштаб: отказ AWS в us-east-1 19–21 октября 2025 года длительностью 14 часов 32 минуты, то есть двадцать месячных бюджетов цели 99,9%. Финальная тема собирает тринадцать красных линий, включая цифры, которые нельзя переносить на свою систему без пересчёта.

Почти наверняка в точке замера или в знаменателе, и проверяются они именно в таком порядке. Доступность, посчитанная по журналам сервера приложений, завышена всегда: сервер, который лежит, не пишет в свой журнал о том, что он лежит, и запросы, не дошедшие до бэкенда, в счёт не попадают. Рабочий пример SRE Workbook поэтому и выбирает метрики балансировщика — они «provide SLIs that are closer to the user's experience than those from the application server's logs», а следующий шаг улучшения индикатора — перенести замер в клиент. Второе место — знаменатель: если из него вычеркнуты 4xx целиком, то сломанная ссылка в вашей же рассылке, протухший токен после выката и изменившийся контракт API перестают быть вашими отказами, хотя пользователь видит именно их. Третье место, которое проверяется последним, — окно и способ счёта: оконный индикатор прячет всплески, потому что интервал с полным провалом весит столько же, сколько интервал с одной лишней ошибкой, а ночной интервал с тремя запросами весит столько же, сколько пиковый с тридцатью тысячами.

Разговаривать поздно — договариваться надо было до. Именно поэтому политика бюджета ошибок является документом с подписями продуктового менеджера, команды разработки и SRE, а не решением дежурного в моменте: «Getting the error budget policy approved by all key stakeholders». Если документ есть, разговор короткий: заморожено всё, кроме задач нулевого приоритета и исправлений безопасности, до возвращения сервиса в цель. Если документа нет, у вас не спор о надёжности, а соревнование авторитетов, и выиграет его тот, кто громче. Но перед тем как настаивать на заморозке, проверьте перечень случаев, когда работа над функциями продолжается: общекорпоративный сетевой сбой, вина другой команды, которая уже заморозила свои релизы, расход бюджета пользователями вне области цели вроде нагрузочных тестов и пентестеров, а также неверно классифицированные ошибки, списавшие бюджет без реального влияния на пользователя. Заморозка не наказание: раздел Non-Goals примера политики говорит прямо, что останавливать изменения нежелательно и политика лишь даёт команде право заняться надёжностью, когда данные показывают, что сейчас она важнее функций. И последнее: у спора о том, как посчитан бюджет, должна быть названная заранее конечная инстанция — в примере это CTO.

Таблицу девяток — да, это чистая арифметика: (1 − цель) × длительность окна, она верна везде. Пороги — нет. Конфигурация 14,4 / 6 / 1 рассчитана для цели 99,9% и окна в тридцать дней, и получена она не опытом, а решением уравнения: доля израсходованного бюджета равна скорости сжигания, умноженной на окно оповещения и делённой на период. Проверьте сами: 14,4 × 1 / 720 = 2%, 6 × 6 / 720 = 5%, 1 × 72 / 720 = 10%. Значение 14,4 выведено из требования потратить не больше двух процентов тридцатидневного бюджета за час; хотите мягче — скорость 36 соответствует пяти процентам за тот же час. При другой цели те же скорости означают другую долю ошибок и другое время до исчерпания, так что перенос без пересчёта даёт либо молчание, либо непрерывный вой. Из той же категории ещё три числа, которые переносить нельзя: «70% отказов из-за изменений» — наблюдение практики Google из раздела Background примера политики, на вашей системе не измеренное; гарантия площадки — условие конкретного провайдера в конкретной редакции документа, которую меняют приказом; фоновая доля ошибок канала — диапазон 0,01–1% с оговоркой о различиях между провайдерами и протоколами, а не одно удобное значение.