Прописываете ли требования к отказоустойчивости и масштабируемости в ТЗ?

Что проверяют

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

Как отвечать

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

Отказоустойчивость раскладывается на:

• целевую доступность и её цену: 99,9 процента это около 43 минут простоя в месяц, 99,99 уже около четырёх, и разница в расходах на резерв огромная;
• допустимую потерю данных и время восстановления после аварии;
• сценарии отказа: упал узел, недоступна база, замолчал внешний сервис. На каждый описано поведение: очередь, повтор, отключение части функций, честная ошибка пользователю;
• что в защиту не входит, например полная потеря площадки.

Масштабируемость превращается в профиль нагрузки: сколько пользователей и запросов в пике, какой рост ожидается за год, объём данных, время отклика по перцентилям при этой нагрузке, что делаем при превышении. Обязательно укажите способ приёмки: нагрузочный прогон по описанному сценарию, проверка отключением узла. В ТЗ по ГОСТ для этого есть раздел требований к надёжности, но важнее не форма, а измеримость.

Где спотыкаются

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

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

Считают, что архитектура решит вопрос сама, и записывают в ТЗ микросервисы. Дробление на сервисы добавляет сетевых отказов, а не убирает их, и поведение системы при отказе всё равно придётся описать словами.