SLA 99,9%: какой сбой может спрятаться внутри красивой цифры

Общий индикатор зелёный, а один способ оплаты не работает ни у кого. Такое возможно даже при правильно посчитанной доступности: редкий метод почти не влияет на среднее. Полезный SLA начинается с вопросов о том, чью проблему измеряет процент, какие события в него попадают и что команда делает раньше, чем закончится месяц.

Проверьте, кого скрывает знаменатель

Представим 100 000 подходящих запросов за окно. Основной метод дал 99 900 успешных технических результатов. На второй метод пришлись 100 запросов, и все завершились технической ошибкой. Общая доступность равна 99,9%, доступность второго метода — 0%. Это отдельный условный пример, не данные реального сервиса.

Такой отчёт может точно следовать общей формуле и всё равно оказаться недостаточным для бизнеса. Назовите критичные сегменты заранее: метод, страна, валюта или конкретный маршрут. Для малых выборок показывайте количество затронутых операций и последовательность ошибок; дробный процент с несколькими знаками создаёт впечатление точности, которой нет.

Не добавляйте сотни разрезов без владельцев. Выберите те, для которых команда действительно примет разное решение: проверит определённую интеграцию, предупредит поддержку или временно изменит предлагаемый клиенту сценарий в допустимых пределах. У показателя должен быть понятный адресат.

Сначала разделите три понятия

SLI обозначает измеряемый показатель, SLO задаёт его целевое значение, а SLA закрепляет соглашение и последствия нарушения. Google SRE также обращает внимание на распределение задержек: среднее значение способно скрыть небольшую долю очень медленных ответов. Источник: Google SRE, Service Level Objectives.

Для платёжной интеграции составьте отдельные описания трёх интервалов: от отправки запроса до ответа API, от создания операции до выбранного окончательного статуса и от возникновения события до получения уведомления вашей системой. У каждого интервала свои причины задержки. Время, которое пользователь тратит на подтверждение в приложении банка, следует показывать отдельно от времени обработки инфраструктурой.

Доступность тоже требует знаменателя

При временном определении 99,9% за условные 30 суток соответствует 43,2 минуты недоступности, если учтён весь период без исключений. При определении по запросам тот же процент означает другую вещь: из 100 000 подходящих запросов допустимый бюджет составляет 100 неуспешных. Переводить один подход в другой без данных о нагрузке нельзя. Десять минут простоя в часы пик могут затронуть больше операций, чем час ночью.

Google SRE Workbook предлагает строить многие показатели как отношение подходящих успешных событий ко всем учитываемым событиям. Практическая ценность такого подхода в явном определении числителя, знаменателя и порога. Источник: Google SRE Workbook, Implementing SLOs.

Для технической доступности корректно обработанный отказ банка может считаться успешным ответом сервиса. Для конверсии в оплату он успехом не будет. Разделите эти показатели в отчётности заранее. Также договоритесь, как учитывать тайм-ауты: если медленные запросы исчезают из выборки до регистрации длительности, график задержек может улучшиться именно во время сбоя.

Почему среднего времени недостаточно

Возьмём условные 1 000 запросов: 980 завершились за 0,2 секунды, остальные 20 за 10 секунд. Среднее равно 0,396 секунды. Эта цифра выглядит вполне спокойной, хотя двадцать пользователей столкнулись с заметным ожиданием. При расчёте методом ближайшего ранга p95 здесь равен 0,2 секунды, а p99 составляет 10 секунд.

Перцентиль p99 описывает границу примерно для 99% наблюдений в выбранной выборке. Он не задаёт максимальное время и не гарантирует результат следующего запроса. Всегда показывайте объём выборки и окно измерения. На редком платёжном методе небольшое число операций делает высокие перцентили нестабильными; рядом полезнее видеть абсолютное количество медленных случаев.

Не усредняйте p99 отдельных серверов или дней, чтобы получить общий p99. Prometheus прямо предупреждает, что готовые квантили нельзя таким образом агрегировать; гистограммы позволяют объединять распределения при соблюдении требований к их структуре. Источник: Prometheus, Histograms and summaries.

Договорный месяц слишком длинный для дежурного

Разделите отчёт о выполнении соглашения и сигнал для немедленного разбора. Месячная цифра нужна для договорной оценки; оператору важны последние ошибки, число ожидающих оплат и возраст самой старой неопределённой операции. Настройте внутренние пороги по своим наблюдениям и допустимому ущербу, не выдавая вымышленный универсальный порог за отраслевой стандарт.

Для обращения к провайдеру сохраняйте обезличенные идентификаторы, точное окно с часовым поясом, ожидаемый результат, фактические коды и объём затронутого потока. Укажите, как отбирались примеры. Пять проблемных платежей полезны для диагностики, но без общего количества нельзя оценить масштаб.

Отдельно определите действие при потере наблюдений. Если счётчик перестал обновляться, нулевая доля ошибок не даёт оснований объявлять восстановление. Сопоставьте независимые журналы и рабочие очереди. Закрывать инцидент разумно после подтверждённого восстановления нужного клиентского шага и разбора накопившихся неизвестных результатов: доступный API ещё не объясняет, что случилось с запросами во время сбоя.

Что должно быть определено до подписания

• Операция и границы измерения: конкретный API, платёжный метод, регион, статус результата.
• Окно расчёта, часовой пояс, источник данных и минимальный объём наблюдений.
• Правила учёта ошибок, тайм-аутов, повторов и исключённых событий.
• Пороговые значения для задержки и доступности, согласованные с реальным процессом.
• Порядок уведомления, эскалации, предоставления доказательств и рассмотрения нарушения.

Сохраните и общий пользовательский показатель сбоев, даже если договор исключает часть причин. Клиенту всё равно приходится ждать при проблеме внешнего участника. Юридическое распределение ответственности и диагностика клиентского опыта решают разные задачи и должны оставаться видимыми одновременно.

На следующем разборе возьмите самый проблемный метод и восстановите его путь от запроса до клиентского результата. Сопоставьте этот путь с тем, что реально покрывает SLA. Разница между ними покажет, какое наблюдение или условие соглашения нужно уточнить первым.