Представьте сервис с целевой доступностью 99,9%: как распределить бюджет недоступности между его зависимостями?
Сначала переводят целевую доступность в бюджет недоступности, затем распределяют его между собственными отказами сервиса и критическими зависимостями с учётом их роли в запросе. Распределение не должно быть механически равным: чем критичнее зависимость и чем больше вероятность коррелированного отказа, тем больший запас доступности ей нужен.
Для месяца длиной 30 дней доступность 99,9% допускает примерно 43 минуты 12 секунд недоступности. Этот бюджет нужно закрепить за компонентами, измерять отдельно и оставить резерв на неизвестные причины отказов.
В монолитной системе доступность часто оценивали как свойство одного приложения. В распределённой системе запрос проходит через несколько компонентов, поэтому надёжность становится совместным результатом их работы.
Понятие бюджета недоступности переводит абстрактное требование доступности в управляемые ограничения. Оно помогает решать, сколько отказов допустимо у самого сервиса, его базы данных, внешних API и инфраструктуры, не выдавая желаемую доступность за гарантированную.
Если целевой сервис имеет доступность 99,9%, а два обязательных компонента доступны только на 99,9% каждый, последовательная операция при независимых отказах будет доступна примерно на 99,8%. При коррелированных отказах, например при общей зоне сбоя, результат может быть ещё хуже.
Ошибка равного распределения бюджета приводит к тому, что некритичная зависимость получает избыточный запас, а единственная зависимость на критическом пути остаётся слабым звеном. Нельзя также считать бюджет точной физической квотой: измерения имеют погрешности, а аварии могут затронуть несколько компонентов одновременно.
Сначала фиксируют, что именно считается недоступностью: все ошибки или только ошибки для определённого набора критичных запросов, учитываются ли запланированные работы, какой период измерения используется. Без единого определения разные команды будут считать бюджет по-разному.
Затем строят критический путь запроса. Для последовательных зависимостей доступность приблизительно перемножается, а для альтернативных путей или резервирования зависит от правил переключения и независимости отказов. Поэтому при проектировании нельзя просто сложить проценты доступности.
Практическая схема распределения выглядит так:
Например, при цели 99,9% можно не требовать от двух зависимостей ровно 99,9% каждая. Если каждая из них должна быть доступна на 99,99%, а на собственные отказы сервиса остаётся запас, суммарный результат будет устойчивее целевого даже до учёта корреляции. Точные значения выбирают по стоимости повышения надёжности и по последствиям отказа, а не только по арифметике.
Важно различать SLO и SLA. SLO — внутренний измеримый ориентир, а SLA может быть внешним обязательством с юридическими или финансовыми последствиями; внутренние бюджеты обычно делают строже внешнего обещания.
Сервис оформления заказа зависел от каталога, сервиса расчёта доставки и платёжного провайдера. Команда поровну разделила допустимые 43 минуты недоступности между ними, но расчёт доставки был нужен только для предварительного показа, тогда как платёжный провайдер блокировал подтверждение заказа.
Рассматривались три варианта. Равное распределение было простым, но не учитывало критичность; требование максимальной доступности от всех зависимостей было надёжным, но дорогим; удаление второстепенных зависимостей с критического пути уменьшало требования, но требовало изменить пользовательский сценарий.
Выбрали третий вариант: стоимость доставки кэшировали на короткий период и разрешили оформить заказ с последующим уточнением, а платёжный путь снабдили отдельным запасом доступности и контролируемым резервным сценарием. В результате отказ расчёта доставки перестал делать оформление полностью недоступным, а бюджет критического платёжного пути стал измеримым отдельно.
Нет. Такое приближение применимо только к последовательно обязательным компонентам и предполагает независимые отказы. На практике нужно учитывать корреляцию: общую сеть, регион, систему идентификации, поставщика облачной инфраструктуры и общие лимиты. Для резервных путей дополнительно проверяют, действительно ли они независимы и автоматически ли работают при отказе основного пути.
Бюджет всё равно должен быть выражен в измеримом контракте: допустимая доля ошибок, задержка восстановления, период измерения и правила исключения плановых работ. Если поставщик не может обеспечить нужный SLO, сервис меняет архитектуру: добавляет кэш, деградацию, очередь, резервного поставщика или убирает зависимость с критического пути. Простое требование повысить доступность без изменения контракта и архитектуры не является планом.
Это сигнал остановить рискованные изменения и направить усилия на надёжность до фактического нарушения SLO. Error budget используется не только как отчёт о прошлом, но и как ограничение для релизов, миграций и экспериментов. Если бюджет восстанавливается, команда может снова принимать изменения; если нет, приоритет получают устранение причин отказов и снижение сложности критического пути.