Краткий ответ

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

Исторический контекст

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

Однако надёжность сервиса определяется не только тем, что приложение успешно выполнило обработку. Для пользователя важен полный путь запроса — от клиента до сервера и обратно, поэтому одних серверных метрик недостаточно для корректного SLO.

Постановка проблемы

Запрос может не попасть в приложение из-за недоступного DNS, отказа балансировщика, исчерпания соединений на прокси или сетевого сбоя. Он также может быть обработан успешно, но ответ не дойдёт до клиента из-за разрыва соединения или превышения пользовательского тайм-аута.

В таких случаях серверные счётчики могут показывать высокий процент успешных ответов, а реальные пользователи — видеть ошибки или длительное ожидание. Если использовать только эти счётчики для SLO, команда рискует объявить сервис соответствующим цели, не замечая существенного отказа на внешнем участке пути.

Подробное решение

Нужно разделять как минимум серверную успешность и успешность с точки зрения клиента. Серверная метрика отвечает на вопрос: «Как часто приложение завершает обработку запроса успешно?». Клиентская — на вопрос: «Как часто пользователь получает приемлемый результат за допустимое время?». Это разные измерения с разными границами наблюдения.

Для внешней доступности применяют несколько источников данных:

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

При расчёте SLO важно явно определить область измерения, знаменатель и критерий успеха. Например, запрос, завершившийся тайм-аутом на клиенте, не должен автоматически считаться успешным лишь потому, что сервер позже закончил работу.

Есть существенные ограничения. Клиентские данные могут быть неполными из-за блокировщиков, отсутствия телеметрии или малого трафика, а синтетические проверки не покрывают всё разнообразие реальных сценариев. Поэтому источники следует сопоставлять, а не безусловно заменять один другим.

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

Ситуация из практики

После изменения маршрутизации пользователи из одного региона начали получать тайм-ауты. Серверная доступность оставалась выше 99,99%, потому что часть запросов вообще не достигала приложения, а дошедшие запросы обрабатывались нормально.

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

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

Что кандидаты часто упускают

1. Должен ли серверный ответ с кодом успеха всегда считаться успешным запросом?

Нет. Код успеха показывает, что сервер сформировал ответ согласно своей логике, но не доказывает, что клиент получил его и смог использовать результат. Кроме того, приложение может вернуть формально успешный ответ с неполными или непригодными данными. Для SLO нужно определить пользовательский критерий успеха, включая допустимую задержку и смысл результата.

2. Почему синтетическая проверка не заменяет клиентскую телеметрию?

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

3. Как не посчитать один отказ несколько раз при объединении метрик?

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