Post #521

В проектировании систем есть фундаментальная проблема: Закон Дырявых Абстракций: Все нетривиальные абстракции дырявы. (All non-trivial abstractions, to some degree, are leaky) Как бы мы не абстрагировались от всего, что ниже, мы не можем этого не учитывать. Ну, или немного можем, раз у нас есть разделение труда по уровням абстракции. Главное, четко провести границу. Вот, например, кэширование — кто про него должен думать? Я каждый раз задаю этот вопрос на тренингах — нет, аналитики про это не думают. И нагрузку на сервера не считают. Традиционно, все нефункциональные требования не в области интересов аналитиков. Это только потом выясняется, что каждое соединение расходует на сервере память и процессор, и они, вообще говоря, могут закончиться. А ещё бывают конкурирующие запросы — один клиент изменяет ресурс, а другие в этот момент его читают. А ещё внезапно оказывается, что запросы выполняются не мгновенно, и передача большого куска данных может идти довольно долго (а при случайном или намеренном сложном запросе может и вообще завесить ваш сервер, см. XML Bomb или Billion Laughs Attack). Вопрос границ ответственности в данном случае очень спорный. В общем случае аналитик не может быть глубоко погружен в технические детали. Пока абстракции не начали течь, и пока своими глазами не увидишь, как два почти идентичных запроса к БД выполняются за время, отличающееся в десятки раз, потому что запрошенные данные не попали на страницу, подгруженную в кэш СУБД (какой кэш? какие страницы? почему я вообще должен об этом думать?) Итого, ответ такой: про зоны ответственности лучше договориться заранее. Где мне остановиться и что не описывать в моем документе? Кэширование — это ещё мое, или нет? А обработка ошибок? А санитаризация ввода — об этом нужно писать? Я знаю, во многих компаниях есть соглашение о моделировании (бизнес-процессов, архитектуры). Почему-то гораздо реже встречается соглашение о содержании требований. Где останавливается БА, что добавляет СА, а что является технологической документацией, которую пишут разработчики/архитекторы или SRE? Заодно при составлении такого соглашения может выясниться, что у вас в команде недостает каких-то специальных компетенций (например, по тем же уязвимостям API или по оптимизации запросов к БД). Это риски, а системный анализ — он весь про риски. Лучше их выявить и принять меры. Ну а чтобы выявить и разобрать, что кому уходит, нужно представлять весь процесс в мельчайших деталях. И, к сожалению, на нескольких уровнях абстракции, вплоть до физического. До сих пор помню, как мы недели две искали плавающий баг — у части клиентов сервер регулярно отваливался на несколько секунд, и не принимал подключения. Вычистили пару реально странных мест в обработчиках соединений, нашли одну утечку памяти. Всё без толку. А оказалось — разъем на свитче разболтался, нужно было патчкорд поменять.