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

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

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

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

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

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

Значение 99,9% за месяц допускает примерно 43 минуты простоя, но только при условии, что заранее определены месяц, часовой пояс и способ округления. Без этих условий заказчик и команда могут получить разные результаты проверки.

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

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

Требование следует уточнить по нескольким связанным параметрам:

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

После уточнения требование можно сформулировать, например, так: «Публичный API оформления заказа должен успешно обрабатывать не менее 99,9% синтетических проверок в течение каждого календарного месяца; проверка считается успешной при ответе за установленный предел времени; плановые работы в согласованном окне не учитываются».

Важно не смешивать доступность с производительностью. Если сервис отвечает ошибкой или превышает установленный предел времени, это может считаться недоступностью для конкретной проверки, но правило должно быть зафиксировано заранее.

Есть и компромисс: чем больше исключений и сложнее методика, тем труднее интерпретировать показатель. Слишком узкая проверка может скрыть реальные проблемы пользователей, а слишком широкая — включить зоны, за которые команда не отвечает.

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

Для сервиса оплаты потребовали доступность 99,95%. Первый вариант предлагал измерять только доступность серверов. Его плюс — простота, но он не обнаруживал ошибки авторизации, тайм-ауты платёжного шлюза и неработоспособность операции для пользователя.

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

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

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

1. Достаточно ли указать только период измерения, например «99,9% в месяц»?

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

2. Следует ли считать плановые технические работы недоступностью?

Универсального ответа нет. Исключение допустимо, если окно работ заранее согласовано, ограничено по времени и явно исключено из методики. Если команда может объявлять любое обслуживание исключением постфактум, показатель теряет проверяемость и доверие.

3. Чем доступность отличается от надёжности в таком требовании?

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