У сервера uptime почти сто процентов, но пользователи не могут отправить форму. Процесс работает, балансировщик отвечает, графики CPU спокойны. Надёжность инфраструктуры и возможность закончить нужное действие оказались разными вещами.
SLO задаёт целевой уровень надёжности сервиса, а SLI — способ его измерить. В Google SRE эти понятия связывают с приоритизацией инженерной работы и бюджетом допустимых ошибок. Полезность начинается с согласованного определения результата, а не с красивого процента. Google SRE Workbook
Выбрать действие и границы
Возьмём учебный сервис записи на консультацию. Возможные действия пользователя — открыть расписание, создать запись и получить подтверждение. Для первого важны доступность и время ответа, для второго — сохранённая запись, для третьего — завершение фоновой доставки.
Если измерять только HTTP-ответ API, можно пропустить ситуацию «200 получен, запись не создана». Поэтому описание SLI должно отвечать на три вопроса: какие события считаем, как отличаем хороший результат и откуда узнаём об этом результате. Порог задержки и окно измерения тоже входят в определение.
Ошибки пользователя требуют явного правила. Неверно введённая дата и невозможность заполнить корректную форму из-за дефекта сервиса не должны автоматически попадать в одну корзину. Иначе показатель удастся улучшить переименованием ошибок, а не исправлением продукта.
Посчитать бюджет на понятном примере
Допустим, за выбранное учебное окно произошло 100 000 допустимых попыток записи. Цель — 99,9% успешных операций. Тогда бюджет составляет 100 неуспешных попыток. Если их 120, выбранная цель не выполнена: успешность равна 99,88%.
from fractions import Fraction
total = 100_000
failed = 120
target = Fraction(999, 1000)
budget = total * (1 - target)
actual = Fraction(total - failed, total)
assert budget == 100
assert actual == Fraction(9988, 10000)
assert actual < targetЭто арифметика вымышленного сценария, не рекомендуемая цель для любого сервиса. Отдельный малопосещаемый критичный маршрут может требовать собственного наблюдения: общий процент по миллиону дешёвых запросов легко скроет десяток неудачных важных операций.
Что делать с исчерпанным бюджетом
До возникновения инцидента полезно согласовать действия: при каком ухудшении команда меняет приоритеты, кто принимает решение и какие работы всё равно обязательны. Пример политики в SRE Workbook показывает бюджет ошибок как механизм согласования скорости изменений и надёжности, а не наказание команды. Google SRE: error budget policy
В учебном процессе можно договориться приостанавливать необязательные изменения, если риск новых сбоев стал выше ожидаемой пользы. Но исправление уязвимости или восстановление доступности не превращается в запрещённый релиз только потому, что бюджет закончился. Политика должна объяснять такие исключения заранее.
Не путать окно и скорость ухудшения
Один и тот же остаток бюджета может расходоваться медленно неделю или исчезнуть за час. Поэтому оповещение полезно связывать с темпом ухудшения и влиянием на пользователей. Уведомление лишь в момент окончательного нарушения цели может прийти слишком поздно.
При этом короткие окна шумят. Для нового SLI сначала проверяют качество исходных событий, отсутствие двойного счёта и поведение при пропаже телеметрии. «Данных нет» не должно молча превращаться в «ошибок нет».
Как принять первую версию
У показателя должны быть владелец, источник данных и воспроизводимый расчёт. На учебном наборе заранее размечают успешные операции, бизнес-отказы, системные ошибки и неизвестный результат. Затем проверяют, что формула даёт ожидаемые числитель и знаменатель.
После этого обсуждают цель с людьми, отвечающими за продукт и эксплуатацию. Слишком слабая цель не защищает пользователя, недостижимая превращается в постоянный красный фон. Рабочий SLO помогает принять конкретное решение: что улучшать следующим и чем подтвердить, что стало лучше.