сеньорчикОткрыть в Telegram
← вся теориятеория к собесу · ТЗ и документация

Нефункциональные требования

Нефункциональные требования

Любимая тема собеседующих: по требованиям к качеству сразу видно, работал ли человек с продом. Джун перечисляет группы по памяти, мидл формулирует проверяемо и знает цену каждой цифры.

Стержень: проверяемое требование к качеству складывается из трёх частей - показатель, условия замера, порог. Всё остальное в теме это техника вокруг этой формулы.

// Формулировки: «какие нефункциональные требования знаешь?», «сформулируй требование к производительности», «что не так с доступностью 99,999?»

Формула проверяемости

Три части нужны каждая по своей причине. Без показателя непонятно, что вообще мерить. Без условий замера - на какой нагрузке и в каком окружении, потому что на пустом стенде всё быстро. Без порога - когда считать выполненным.

Требование «время ответа страницы каталога не превышает 300 миллисекунд на 95-м перцентиле при 200 запросах в секунду в промышленной среде» содержит все три части. Поэтому под него можно спроектировать решение, заложить его в нагрузочный тест и по нему принять работу без единого спора.

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

// Рядом с перцентилем полезно зафиксировать и предельное значение: иначе один запрос может висеть минуту, формально не портя статистику по девяносто пятому перцентилю.

перцентиль
граница, ниже которой лежит заданная доля замеров. 95-й перцентиль - значение, которое не превышают 95 процентов запросов

Доступность стоит денег

Цифры доступности выглядят похоже и различаются на порядки. Посчитаем в минутах простоя за год. 99,9 процента - это около 526 минут, почти девять часов. 99,99 - около 53 минут. 99,999 - примерно пять минут за целый год.

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

Прежде чем считать архитектуру, договариваются о правиле замера, и это отдельный содержательный разговор. Что именно считается недоступностью - ошибки сервера, таймауты, деградация до неприемлемой скорости? На каком интервале усредняем? Учитываются ли плановые работы? Без ответов число теряет смысл, потому что мерить его можно четырьмя способами с разным результатом.

// Когда заказчик просит пять девяток, задача аналитика не спорить, а показать цену и переспросить про реальную потребность. Хороший вопрос: сколько бизнес теряет за час простоя? Часто оказывается, что дешевле пережить простой, чем платить за его отсутствие.

Забытые группы

Наблюдаемость забывают чаще всех остальных. Логи, метрики, сквозной идентификатор запроса, срок хранения всего этого - выглядит внутренним делом разработки, а вспоминают о ней при первом инциденте, когда причину сбоя просто не видно и разбор превращается в гадание.

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

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

// И главное правило темы: требования к качеству проверяют с первого релиза, а не перед сдачей. Скорость и отказоустойчивость закладываются в архитектуру, и поздняя правка означает смену хранилища или способа интеграции - то есть переписывание, а не доработку.

Как отвечать: «Сформулируй требование к производительности каталога»

Сначала выясню, где именно болит и что считается приемлемым для пользователя, потому что без этого любое число будет выдумкой - а выдуманное число потом кто-то будет реализовывать за деньги. Дальше сформулирую через три части. Показатель - время ответа страницы каталога. Условия замера - при двухстах запросах в секунду в промышленной среде. Порог - не более 300 миллисекунд на 95-м перцентиле. Перцентиль беру намеренно вместо среднего: среднее размывается быстрыми ответами и прячет медленный хвост, где как раз сидят уходящие пользователи. И рядом обязательно зафиксирую предельное значение, чтобы отдельные запросы не висели по минуте, формально не портя статистику.

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

На чём валятся

  • − Пишут требования к качеству словами без чисел: «быстрая», «надёжная», «удобная».
  • − Указывают «1000 пользователей», не уточнив, одновременные они, суточные или зарегистрированные.
  • − Берут среднее время ответа вместо перцентиля и не видят медленный хвост.
  • − Забывают наблюдаемость и остаются без данных в первый же инцидент.
  • − Проверяют требования к качеству перед сдачей, когда правка означает переделку архитектуры.

Проверьте себя

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

  1. #ana_doc_nfr1 / 5
    Почему для времени отклика чаще берут перцентиль, а не среднее?
    A)Перцентиль проще посчитать при большом объёме замеров
    B)Среднее сложнее собрать в мониторинге
    C)Среднее прячет хвост, где сидят самые медленные ответы
    D)Перцентиль требуется отраслевыми стандартами качества
    показать ответ и разбор
    +C)Среднее прячет хвост, где сидят самые медленные ответы

    // разбор: Среднее размывается быстрыми ответами: при среднем в 120 мс каждый двадцатый пользователь может ждать несколько секунд и уходить. Перцентиль фиксирует границу для доли запросов и потому описывает реальный опыт. Обычно берут p95 или p99, а вместе с ними и предельное значение.

  2. #ana_doc_nfr2 / 5
    Заказчик просит доступность 99,999%. Что сделает аналитик перед тем, как записать это в документ?
    A)Запишет как есть — это позиция заказчика
    B)Снизит цифру до достижимой на свой взгляд
    C)Уточнит у разработки, поддерживает ли платформа такой режим
    D)Покажет цену такого уровня и переспросит про реальную потребность
    показать ответ и разбор
    +D)Покажет цену такого уровня и переспросит про реальную потребность

    // разбор: Пять девяток — это около пяти минут простоя в год, то есть резервирование, автоматическое переключение, дежурство и регламент учений. Стоимость растёт на порядок по сравнению с 99,9%. Задача аналитика — показать эту цену и выяснить, действительно ли бизнес теряет столько при получасовом простое.

  3. #ana_doc_nfr3 / 5
    Какое НФТ чаще всего забывают, а вспоминают уже при инциденте?
    A)Требования к цветовой схеме интерфейса
    B)Требования к наблюдаемости и диагностике
    C)Требования к языку интерфейса
    D)Требования к формату экспорта отчётов
    показать ответ и разбор
    +B)Требования к наблюдаемости и диагностике

    // разбор: Логи, метрики и трассировка кажутся внутренним делом разработки, поэтому в документ не попадают. В итоге при первом же сбое выясняется, что причину не видно: нет идентификатора запроса, нет метрик по внешним вызовам, а логи не хранятся достаточно долго. Такие требования дешевле заложить заранее.

  4. #ana_doc_nfr4 / 5
    Два НФТ конфликтуют: шифровать всё и держать отклик под 100 мс. Как поступить?
    A)Оставить оба, разработка разберётся на месте
    B)Выбрать то, что записано в документе раньше
    C)Смягчить оба требования наполовину
    D)Вынести конфликт владельцам и зафиксировать приоритет
    показать ответ и разбор
    +D)Вынести конфликт владельцам и зафиксировать приоритет

    // разбор: Конфликты качества нормальны: безопасность, скорость и стоимость тянут в разные стороны. Аналитик не разрешает такой спор сам — он делает его видимым, показывает цену каждого варианта и добивается решения от тех, кто отвечает за риск. Решение фиксируется в документе вместе с обоснованием.

  5. #ana_doc_nfr5 / 5
    НФТ по нагрузке записано как «1000 пользователей». Почему этого мало?
    A)Не указано, одновременные это пользователи или всего
    B)Не указана марка оборудования для теста
    C)Не назван инструмент нагрузочного тестирования
    D)Не указана стоимость проведения испытаний
    показать ответ и разбор
    +A)Не указано, одновременные это пользователи или всего

    // разбор: Тысяча зарегистрированных, тысяча активных в сутки и тысяча одновременных в пике — это три разные системы с разницей в стоимости на порядок. К нагрузочному требованию нужны тип пользователей, профиль их поведения и характер пика, иначе спроектировать и проверить его невозможно.

дальше

Теорию прочитали. Навык ставится повторением

В Сеньорчике эта подтема идёт в ежедневных сессиях: движок возвращает её, пока ответы не станут уверенными, и ведёт прогресс отдельно по каждой подтеме. Теория внутри тоже бесплатна, лимит только на количество вопросов в день.