Comments 18
Добрый день.
Спасибо за статью. Не первая, но хорошая. Заметно, что не за один час потратили :))))
Пара заметок из личного опыта. Не критика, просто делюсь.
Масштабируемость - не только и даже не столько рост базы и RPS. Ключевое здесь - возможность функционального развития системы (по крайней мере в энтерпрайзе). Если Вы на этапе проектирования заложили только 2 типа оплаты, "наличными" и "безналичными", от касс до управленки, Вы можете столкнуться с очень серьёзными переделками когда решите добавить "кредит". Это просто пример, их масса. Проектируя систему, особенно в момент системного анализа, стоит выяснять у бизнес-аналитика (или заказчика) а какие функции теоретически могут быть ещё, просто не вошли в рамки текущей задачи. И если уж не делать заранее закладки, то по крайней мере не строить стенки.
Законодательные и отраслевые требования
Это уровень концепта. Бизнес-ограничения. Работа бизнес-аналитика. Но если СА будет за этим приглядывать - конечно хорошо. В первую очередь для самого системного аналитика. Знание контекста очень хорошо прочищает :)))
Надёжность
На моей практике гораздо лучше и понятней формулировать не 99,999999999% (это лучше оставить для юридически значимого договора), а "максимально допустимое время простоя за период". Это намного понятнее админам. Да и бизнесу проще сформулировать "не более 2 минут, не чаще раза в месяц, в промежутке от 0.00 до 06.00 МСК". Это на их языке. Именно так Вы и сформулировали в опроснике кстати :)
Не обнаружил:
Наблюдаемость (логи, трассировки, дашборды) и Интегрируемость (не везде, но нужно. Вы похоже писали чисто под фронт)
Позвольте подушнить, но вы не правильно понимаете требования:
Масштабируемость - это как раз про увеличение нагрузки, а вы приводите пример про расширение функционала, это уже "Расширяемость" или "Гибкость" или "Устойчивость к изменениям"...
Законодательные и отраслевые требования - эти требования и стандарты напрямую влияют на систему, в том числе из таких требований часто вытекают и функциональные требования, поэтому это более чем обязательная зона ответственности системного аналитика, а не второстепенная, как вы ее пытаетесь представить. Хорошо если бизнес-аналитик сформирует вам их, но если нет, то системный аналитик должен это сделать сам.
Надёжность - пример типа "не более ... в такое-то время..." в 9-ках описывается требование по доступности, обычно оно не включает какие-то плановые простои, например на обслуживание, т.е. речь идет о сбоях, а их нельзя запланировать, поэтому указание промежутка времени здесь выглядит странно. Вы же скорее уже пытаетесь описать SLA.
Так как же всё-таки правильно формулировать требования к безопасности? Я не нашёл.
Ключевое - описать модель угроз. Дальше из неё вывести конкретные требования - и конкретику вроде "защита всех коммуникаций через mTLS", и описание необходимых процессов, которые требуется внедрить (безопасность - это в большей степени процесс).
защита всех коммуникаций через mTLS
разве это требование? больше похоже на решение уже
Я сторонник кратких и actionable документов. Если есть несколько приемлемых вариантов решения то стоит описать требования и дать возможность выбрать конкретное решение тому, кто будет его внедрять. Но в некоторых случаях реального выбора просто нет, либо потому, что удовлетворяющее требованиям решение ровно одно, либо потому, что для единообразия этот проект должен использовать те же решения, что и соседние проекты - и тут намного проще сразу указать нужное решение, а не использовать общие фразы, делая вид, что выбор есть.
Я понимаю ваш подход.
Но с другой стороны, очень часто вижу якобы «требования к ИБ» вида «длина пароля не менее 6 символов» и это очень похоже на типовое субоптимальное решение.
В большинстве проектов дока на нефункциональные требования отсутствует в принципе. Если она есть - это уже хорошо. Если она упоминает большинство указанных в статье разделов - это вообще прекрасно. Если её реально читают, пытаются выполнять и за этим кто-то реально следит - просто бомба. Если там явно сказано, что необходим контроль сложности пароля - не важно в каком виде - это однозначно плюс, а не минус, показывающий что об этом по крайней мере подумали. Может, конечно, в конкретном случае подумали не очень удачно - но сам факт что думали уже радует. Раз подумали и даже записали, значит вероятность что это требование в будущем будет улучшено сильно вырастает.
Какая нагрузка ожидается?
Сколько пользователей будет работать с системой одновременно в час пик?
Только сегодня обсуждали в чате архитекторов, что количество одновременно работающих пользователей ещё нужно перевести в RPS и это делается не одной операцией. Как это сделать — у вас не написано, хотя это и не rocket science.
Денис, добрый день.
При всём реально гигантском уважении к Вам и Вашему труду ...
Заучит как "мы тут в клубе корифеев обсудили, всё решили, но вам ничего не расскажем“. Откройте тайну то :)))
Не знаю, что там в чатике было, но могу сказать как считаю я.
Зависит от природы проекта. Бывают проекты, в которых один клик юзера в 99% превращается в один запрос GraphQL. А бывают, в которых один клик может привести к вызову десятка API (в худшем случае, если этот клик запускает тяжёлую операцию). В последнем случае для расчёта RPS обычно используются два подхода: либо считаем худший случай (тот самый десяток API на одного юзера), либо смотрим по метрикам средний RPS на живой системе и берём коэффициент из реальных данных. Но на этапе написания доки по нефункциональным требованиям обычно ещё нет живой системы с метриками, так что вариант остаётся один. А если на этапе написания этой доки нет понимания какой будет API и сколько там будет запросов на юзера - обычно использую коэффициент 5 на одного юзера.
Держите DAU 2 rps
Масштабируемость часто упускают из виду, пока не становится поздно. Система должна не только функционировать здесь и сейчас, но и иметь запас на рост. Например, выдерживать увеличение числа пользователей на 50%. Если этого не предусмотреть, в один прекрасный день ваш успешный сервис рухнет под большим rps.
Способность выдерживать увеличение числа пользователей без потерь качества — это elasticity уже: https://www.couchbase.com/blog/scalability-vs-elasticity/
А c потерями — robustness.
Это всё сильно зависит от природы проекта. В одном потеря качества вполне может быть допустима, в другом нет. Один должен быть резиновым-эластичным, а другой (игровой сервер, например) может иметь фиксированное значение максимального количества пользователей и отказывать в регистрациях/подключениях при превышении этого лимита. И термин масштабируемость для них будет означать очень разное - но в том или ином виде она есть везде. Можно, конечно, ввести уникальные термины для всех этих случаев, но тогда часть из этих терминов не будет иметь смысла во многих проектах. Даже сейчас многие путаются между доступностью и масштабируемостью (в этой статье доступность явно включили в надёжность, хотя это довольно разные вещи). Так что да, давайте ещё эластичность с робастностью сюда добавим, так сразу станет понятнее, ага.
видимо дело в том, что раньше Scalability была сугубо характеристикой Design-Time, а с появлением эластичности стала ещё и Run-Time
Нет, дело в том, что документ этот пишется для определённой целевой аудитории - и она должна понимать, о чём идёт речь. В случае нефункциональных требований ЦА - это бизнес (который должен понять документ чтобы заапрувить его) и разработчики/девопсы (которые будут всё это внедрять и проверять). Поэтому перегружать его богатой терминологией (пусть и более точной и формально корректной) - не лучшая идея.
> разработчики/девопсы
так, я не понял, а какая аудитория может быть ещё более техничной и компетентной, чем девопсы и разработчики?
В теории или на практике? :)
Да, они будут молча читать Ваши документы и делать вид, что всё поняли. Только это вообще ничего не значит, к сожалению.
У меня на предыдущем проекте был похожий случай. Я отвечал за команду бэка, и согласовывал с лидом фронта изменения API в виде swagger.yml. И он два года молча аппрувил предложенные изменения. А потом случайно выяснилось, что он понятия не имеет, что такое swagger.yml, и даже не считает необходимым для роли лида фронта в этом разбираться. (Ну и, разумеется, никакие кодгены по нашему swagger.yml фронт не использовал.)
Как правильно формулировать нефункциональные требования