Как измерять доступность API

Для API-сервиса доступность — это не абстрактная метрика, а суть продукта. Когда ваш API встроен в чужие приложения, его сбой мгновенно становится сбоем десятков клиентских продуктов. При этом измерять доступность API сложнее, чем доступность обычного сайта: «работает или нет» здесь — слишком грубое приближение. API может отвечать, но медленно; возвращать ответы, но с ошибками; работать для одних эндпоинтов и падать для других.

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

Почему доступность API измерять сложнее

Обычный сайт чаще всего оценивают бинарно: открылся — работает, не открылся — нет. С API так не получается по нескольким причинам:

• Множество эндпоинтов. API — это набор методов, и они могут иметь разное состояние. Эндпоинт чтения работает, эндпоинт записи — нет.
• Корректность ответа важна не меньше факта ответа. API может вернуть HTTP 200, но с неверными данными или ошибкой в теле. Формально «ответил», фактически — не работает.
• Производительность критична. Для API задержка часто так же важна, как доступность. Ответ за 10 секунд для многих клиентов равносилен отказу.
• Разные клиенты, разные сценарии. Один и тот же API по-разному ведёт себя под разной нагрузкой и для разных паттернов использования.

Поэтому измерение доступности API — это не один показатель, а набор взаимодополняющих метрик.

Ключевые метрики доступности API

Доля успешных запросов (Success Rate)

Базовая метрика: отношение успешных запросов к общему числу. Но «успешный» нужно определить. Обычно это запросы, вернувшие корректный ответ без ошибки сервера (коды < 500). При этом важно правильно трактовать коды:

• 2xx — успех.
• 4xx — клиентские ошибки. Спорный случай: ошибка на стороне клиента (неверный запрос) обычно не считается недоступностью API. Но всплеск 4xx может сигнализировать о проблеме (например, сломанной авторизации).
• 5xx — серверные ошибки. Однозначно признак недоступности.

Доступность (%) = (Запросы без 5xx-ошибок / Все запросы) × 100%

Частота ошибок (Error Rate)

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

Латентность (Latency)

Время ответа — критическая метрика для API. Важно мерить не среднее (оно обманчиво), а перцентили:

• p50 (медиана) — типичный пользователь.
• p95, p99 — «хвост» распределения, где живут проблемы. p99 показывает, как плохо самым невезучим запросам.

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

Пропускная способность (Throughput)

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

Доступность против корректности

Важное различие: API может быть «доступен» (отвечает, быстро, без 5xx), но возвращать неверные данные. Формальные метрики этого не поймают. Поэтому продвинутое измерение включает проверки корректности — не только «ответил ли эндпоинт», но и «вернул ли он ожидаемый результат».

Это особенно важно для критичных операций: проверка не просто «эндпоинт оплаты ответил 200», а «тестовая транзакция прошла корректно от начала до конца».

Как организовать проверки

Синтетические проверки (Synthetic Monitoring)

Активные проверки: система регулярно отправляет тестовые запросы к API и оценивает ответы. Преимущества:

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

Хорошая практика — синтетические проверки ключевых эндпоинтов и критичных пользовательских сценариев (например, полный цикл авторизации → запрос → запись).

Мониторинг реального трафика (Real User / Passive Monitoring)

Измерение по фактическим запросам реальных клиентов. Преимущества:

• Отражает реальный опыт пользователей.
• Учитывает реальное распределение нагрузки и сценариев.

Недостаток: при низком трафике данных мало, а проблему вы видите уже тогда, когда она затронула клиентов.

Оптимально сочетать оба подхода: синтетика для раннего обнаружения и покрытия, реальный трафик для отражения фактического опыта.

Проверки из разных географических точек

API может быть доступен из одного региона и недоступен из другого. Проверки из нескольких локаций выявляют региональные и сетевые проблемы и отличают реальный сбой API от проблемы в одной точке.

Откуда измерять: важность внешней точки

Критичный нюанс: измерять доступность только изнутри своей инфраструктуры недостаточно. Изнутри API может выглядеть здоровым, тогда как для внешних клиентов он недоступен из-за проблем с сетью, балансировщиком, DNS или CDN. Внешние проверки из точек, близких к клиентам, дают честную картину того, что реально видят пользователи.

Как определить SLI для API

На основе метрик формулируются SLI (индикаторы уровня сервиса). Типичные SLI для API:

• Доступность: доля запросов без 5xx-ошибок ≥ X%.
• Латентность: доля запросов быстрее порога (например, 99% быстрее 300 мс).
• Корректность: доля запросов, вернувших корректный результат.

Эти SLI ложатся в основу SLO (целей) и, при необходимости, SLA (обязательств перед клиентами).

Связь со статус-страницей

Измеренные метрики доступности API имеют смысл, только если клиенты их видят. Для API-сервиса статус-страница — особенно важный инструмент, потому что аудитория техническая и требовательная к прозрачности. На статус-странице стоит:

• Показывать состояние ключевых компонентов API (или групп эндпоинтов).
• Публиковать метрики доступности и, при уместности, производительности.
• Вести историю инцидентов с точными таймстампами.

Платформы вроде StatusMate позволяют отражать доступность по компонентам и вести историю, превращая внутренние измерения в публичный, проверяемый показатель надёжности API — то, на что клиенты-разработчики смотрят при выборе и оценке сервиса.

Лучшие практики

• Меряйте несколько метрик, а не только «работает/нет»: success rate, error rate, латентность (перцентили), throughput.
• Различайте доступность и корректность. Ответ 200 с неверными данными — это не «работает».
• Используйте перцентили латентности (p95, p99), а не среднее.
• Сочетайте синтетику и реальный трафик. Первое — для раннего обнаружения, второе — для реального опыта.
• Измеряйте из внешних точек, близких к клиентам, а не только изнутри.
• Проверяйте критичные сценарии целиком, а не отдельные эндпоинты в вакууме.
• Делайте метрики публичными на статус-странице.

Частые ошибки

• Бинарное «работает/нет». Для API это слишком грубо: оно пропускает деградацию, частичные сбои и проблемы корректности.
• Опора на среднюю латентность. Среднее скрывает «хвост» — медленные ответы, которые видит часть клиентов. Нужны перцентили.
• Игнорирование корректности. Метрики кодов ответа не поймают ситуацию, когда API отвечает 200, но с неверными данными.
• Измерение только изнутри. Не отражает проблем сети, DNS, CDN, которые видят клиенты снаружи.
• Одна точка проверки. Скрывает региональные сбои и не отличает проблему API от локальной сетевой.
• Метрики без публикации. Для API-сервиса непрозрачность по доступности — конкурентный минус; клиенты-разработчики ценят открытость.

Часто задаваемые вопросы

Как правильно считать доступность API?
Базово — как долю запросов без серверных ошибок (5xx) от общего числа. Но полноценное измерение дополняется латентностью (перцентили), частотой ошибок и проверкой корректности ответов, а не только факта ответа.

Почему нельзя мерить API как обычный сайт?
Потому что API — это множество эндпоинтов с разным состоянием, где важны не только факт ответа, но и его корректность и скорость. Бинарное «работает/нет» пропускает деградацию и частичные сбои.

Зачем нужны перцентили латентности?
Среднее время ответа скрывает «хвост» распределения. Перцентили p95 и p99 показывают, как медленно отвечает API самым невезучим запросам — это часто скрытая проблема доступности для части клиентов.

В чём разница между синтетическим и реальным мониторингом?
Синтетика активно шлёт тестовые запросы и обнаруживает проблемы рано, даже при низком трафике. Реальный мониторинг измеряет по фактическим запросам клиентов и отражает настоящий опыт. Лучше сочетать оба.

Почему важно измерять доступность снаружи?
Изнутри API может выглядеть здоровым, тогда как для клиентов он недоступен из-за проблем сети, DNS, балансировщика или CDN. Внешние проверки дают честную картину того, что видят пользователи.

Нужно ли показывать метрики API на статус-странице?
Для API-сервиса — да. Аудитория техническая и ценит прозрачность; публичные метрики доступности служат проверяемым подтверждением надёжности и аргументом при выборе сервиса.

Заключение

Измерение доступности API — это не один показатель, а система взаимодополняющих метрик: доля успешных запросов, частота ошибок, латентность в перцентилях и пропускная способность, дополненные проверкой корректности ответов. Бинарного «работает или нет» для API недостаточно — оно пропускает деградацию, медленные ответы и ситуации, когда сервис отвечает, но неверно.

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