Какие нефункциональные требования предъявить к новому узлу системы
Что проверяют
Умеете ли вы превращать абстрактные «надёжно и быстро» в измеримые требования, которые можно проверить до запуска. Следом обычно спрашивают, как вы проверите каждое из них и что будет, если узел их не выдержит.
Как отвечать
Начните с контекста: какую нагрузку узел принимает, кто от него зависит, какие данные хранит. Потом пройдитесь по атрибутам качества (удобная опора это ISO/IEC 25010) и к каждому дайте число или проверяемое условие:
- производительность: латентность по перцентилям, например p99 до 300 мс при 500 RPS, а не «быстро». Проверяется нагрузочным тестом в Locust или k6;
- доступность: SLO вроде 99,9% в месяц, это около 43 минут простоя. Плюс RPO и RTO для данных;
- масштабируемость: сервис без состояния, чтобы добавлять реплики. Для Python это ещё число воркеров gunicorn или uvicorn, учёт GIL для CPU-задач и вынос тяжёлого в очередь;
- отказоустойчивость: таймаут на каждый внешний вызов, ретраи с экспоненциальной задержкой только для идемпотентных операций, circuit breaker, деградация вместо падения;
- наблюдаемость: метрики в Prometheus, структурные логи, трейсы через OpenTelemetry, проверки liveness и readiness для Kubernetes;
- безопасность: аутентификация между сервисами, TLS, секреты вне кода, а при персональных данных требования 152-ФЗ;
- совместимость: версионирование API, обратная совместимость контрактов, миграции схемы без простоя;
- ресурсы: лимиты CPU и памяти, бюджет на инфраструктуру.
Хорошо закончить приоритетами: 99,99% и p99 в 50 мс одновременно стоят дорого, и бизнес должен подтвердить, что готов за это платить.
Где спотыкаются
Перечисляют слова без чисел. «Высокая производительность» не требование: его нельзя ни проверить, ни провалить.
Забывают про наблюдаемость и эксплуатацию. Узел без метрик и health check формально работает, но сопровождать его невозможно.
Ставят ретраи на всё подряд. Повтор неидемпотентного POST без ключа идемпотентности создаёт дубли, а ретраи без ограничения добивают упавшую зависимость.