[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"question-arkhitektura-prilozheniy-chto-takoe-nefunktsionalnye-trebovaniya-nfr":3},{"id":4,"slug":5,"topicId":6,"topicSlug":7,"topicName":8,"topicEmoji":9,"question":10,"answer":11,"codeLang":12,"codeSrc":12,"important":12,"commonMistakes":12,"modernUsage":12,"difficulty":13,"tags":14,"related":19,"progress":20,"seo":21},141,"chto-takoe-nefunktsionalnye-trebovaniya-nfr",3,"arkhitektura-prilozheniy","Архитектура приложений","🏗️","Что такое нефункциональные требования (NFR)?","Нефункциональные требования (Non-Functional Requirements, NFR) -- требования, описывающие как система должна работать (качество), а не что она должна делать (функции). NFR определяют архитектуру не меньше, чем бизнес-требования.\n\n### Основные категории NFR\n\n### 1. Производительность (Performance)\n\n- Время отклика (Response Time): \"API-метод должен отвечать за \u003C 200 мс (P95)\".\n- Пропускная способность (Throughput): \"Система должна обрабатывать 1000 платежей в секунду\".\n- Задержка (Latency): \"End-to-end задержка \u003C 500 мс\".\n\n### 2. Доступность (Availability)\n\n- SLA: \"99.95% uptime = не более 4.38 часов простоя в год\".\n- RTO (Recovery Time Objective): максимальное время восстановления после сбоя.\n- RPO (Recovery Point Objective): максимально допустимый объём потерянных данных (измеряется во времени).\n\n### 3. Масштабируемость (Scalability)\n\n- \"Система должна выдерживать 10-кратный рост нагрузки за 6 месяцев\".\n- Горизонтальное масштабирование без архитектурных изменений.\n\n### 4. Безопасность (Security)\n\n- Аутентификация и авторизация (OAuth2, JWT).\n- Шифрование данных at rest и in transit (TLS).\n- Соответствие стандартам (PCI DSS для карточных данных, GDPR для персональных данных).\n- Журналирование всех критичных операций (audit log).\n\n### 5. Надёжность (Reliability)\n\n- Отказоустойчивость -- работа при сбое отдельных компонентов.\n- Консистентность данных -- отсутствие потерь транзакций.\n\n### 6. Наблюдаемость (Observability)\n\n- Логирование (ELK stack).\n- Метрики (Prometheus + Grafana).\n- Трассировка (Jaeger, Zipkin).\n\n### 7. Сопровождаемость (Maintainability)\n\n- Читаемость кода, покрытие тестами.\n- Документация API и архитектурных решений.\n\n### Как фиксировать NFR\n\nКаждое нефункциональное требование должно быть измеримым. Расплывчатое \"система должна быть быстрой\" бесполезно. Вместо этого:\n\n```\nТребование: Время отклика API создания платежа\nМетрика: P95 \u003C 300 мс при нагрузке 500 RPS\nИзмерение: JMeter \u002F Gatling нагрузочные тесты\nМониторинг: Prometheus histogram + Grafana dashboard\n```\n\n### Итог\n\nNFR определяют архитектурные решения. Требование \"99.99% uptime\" диктует резервирование, мультизональный деплой, автоматический failover. Требование \"обработка 10 000 RPS\" диктует горизонтальное масштабирование и асинхронную обработку. Без явно зафиксированных NFR архитектура строится на догадках.\n\n> **На собеседовании:** Интервьюер ожидает, что вы назовёте конкретные измеримые примеры NFR (P95 latency, SLA в процентах), а не абстрактные \"быстро и надёжно\". Частая ошибка -- забывать про наблюдаемость и сопровождаемость, сосредотачиваясь только на производительности.","","middle",[15,16,17,18],"requirements","quality-attributes","nfr","architecture",[],null,{"title":22,"description":23,"ogTitle":22,"ogDescription":24,"keywords":25,"schemaAnswer":35,"featuredSnippetReady":36},"Нефункциональные требования (NFR): категории и метрики — Gymterview","Что такое нефункциональные требования? Производительность, доступность, масштабируемость, безопасность, надёжность, наблюдаемость. SLA, RTO, RPO и метрики.","Обзор нефункциональных требований: производительность, доступность, безопасность, наблюдаемость. Как фиксировать и измерять NFR.",[26,27,28,29,30,31,32,33,34],"нефункциональные требования","NFR","SLA","RTO","RPO","производительность","доступность","масштабируемость","безопасность","Нефункциональные требования (NFR) описывают, как система должна работать (качество), а не что она должна делать (функции). Основные категории: производительность (время отклика, пропускная способность), доступность (SLA, RTO, RPO), масштабируемость, безопасность (OAuth2, TLS, PCI DSS), надёжность, наблюдаемость (логирование, метрики, трассировка) и сопровождаемость. Каждое требование должно быть измеримым — с конкретной метрикой, способом измерения и мониторинга.",true]