Нефункциональные требования: 5 ошибок, которые всплывут в проде

Tech Lead Сергей Прощаев опубликовал на Хабре разбор пяти NFR-ошибок, которые стабильно рвут прод через три недели после релиза. Сценарий до тошноты знакомый: приёмка пройдена, демо зелёное, маркетинг шлёт рассылку — p99 прыгает с 200 мс до 8 секунд, счёт за облако удваивается, а архитекторы выясняют, что «пережить ноябрьскую распродажу» стоит переписывания половины сервисов. Корень, по словам автора, не в коде — в требованиях, которые никто не удосужился записать цифрами.

Ошибка №1: НФТ как «потом разберёмся»

Классика. На дизайн-сессиях обсуждают сущности, API и экраны. Слово «нагрузка» звучит один раз, в формате «ну, потом посмотрим». Через полгода заказчик уточняет: «99,95% аптайма, пик 2000 RPS в чёрную пятницу» — и команда понимает, что монолит с общей БД это не вытянет.

Мотивация у бизнеса выглядит разумной: «сначала докажем ценность, оптимизируем по мере роста». Проблема в том, что НФТ — это не оптимизация. Это входные данные для выбора архитектуры. Монолит или микросервисы, REST или очереди, одна база или шардирование — всё это следствия НФТ, а не вкусовщина. А НФТ между собой всегда в конфликте: производительность тянет вверх стоимость, доступность добавляет сложности, безопасность съедает задержку. Проектирование — это выбор компромисса, который невозможно сделать осознанно, пока требования не названы цифрами.

Цена опоздания

Жестокая экономика. То, что на дизайн-сессии стоило часа спора у доски, в проде превращается в миграцию на месяцы. НФТ никуда не исчезают, если их не обсудили — они просто переезжают вправо по таймлайну, туда, где каждое изменение стоит на порядок дороже и затрагивает уже принятые архитектурные решения.

Как исправить: дизайн-сессия не считается завершённой, пока не заполнен короткий NFR-опросник — нагрузка в пике, допустимая задержка, доступность, RTO/RPO, бюджет на инфраструктуру, требования по данным (персональные? финансовые?). Одна страница, десять вопросов, заполняется вместе с заказчиком.

Что делать нам

В первой части материала подробно разобрана только ошибка №1. Оставшиеся четыре — с симптомами, причинами, ценой и исправлением — плюс сводную таблицу, чек-лист и практики команд на середину 2026 года автор обещал выложить следом. Ждём.

Пока — рабочий минимум. Откройте Jira, создайте тикет «NFR-опросник», повесьте блокером на архитектурное ревью. Это дешевле, чем полгода переезжать с монолита на шарды в три ночи под аккомпанемент алертов PagerDuty.

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

Бэкапы. Мониторинг. Сон. В таком порядке.