В любом процессе разработки, будь то программное обеспечение или любая другая технология, наиболее важным этапом является проектирование. Без выполнения этапа проектирования мы не можем перейти дальше к реализации решения, его сборке или тестированию. То же самое относится и к системе. Системное проектирование не только является жизненно важным шагом в разработке системы, но и обеспечивает основу для работы алгоритмов приложения, поскольку оно представляет собой бизнес‑логику программного обеспечения.

По сути, системное проектирование (System Design) — это процесс определения архитектуры, компонентов, модулей, интерфейсов и данных для системы, удовлетворяющих заданным требованиям. Оно включает в себя преобразование требований бизнеса в подробную схему, которая служит руководством на этапе внедрения. Другими словами, на этапе проектирования системы мы выполняем перевод с языка бизнеса на язык ИТ.

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

Посмотрим на шаги цикла Software Development Life Cycle. Здесь разработка дизайна идет сразу после планирования и анализа требований.

Таким образом, системный дизайн выступает в качестве основы, потому что независимо от того, насколько хорошо будут выполнены дальнейшие шаги — например, разработка, позже она может стать неуместной, если дизайн был проработан некачественно.

Цели системного проектирования

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

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

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

Здесь на самом деле все достаточно просто. У нас есть техническое задание, в соответствии с которым мы и реализуем нашу систему, и здесь важно на этапе анализа учесть в ТЗ все то, что нужно заказчику от приложения, как в функциональной, так и в других частях.

Конструкция системы должна быть такой, чтобы ее использование не приводило к чрезмерным затратам ресурсов и было достаточным, поскольку это приведет к низкой производительности и меньшему времени отклика.

Это одна из ключевых задач архитектора, разрабатывающего решение. Выбор компонентов для работы приложения должен быть таким, чтобы с одной стороны не выдвигалось избыточных требований к аппаратным ресурсам, так как это в свою очередь ведет к дополнительным затратам, будь то собственное оборудование или облачные сервисы. А с другой, чтобы компоненты приложения могли достаточно эффективно работать, без сбоев и проблем с производительностью.

Надежность является неотъемлемой частью дизайна любой системы. Спроектированная система должна удовлетворять требованиям RTO и RPO, и на них мы остановимся особо.

Целевой показатель времени восстановления (RTO) определяет период времени с момента возникновения сбоя до того момента, когда затронутый ресурс должен быть полностью работоспособен и готов к выполнению задач организации. По сути, мы определяем, сколько времени нам потребуется на восстановление.

Точка восстановления (RPO) особенно важна, когда речь заходит о резервном копировании и восстановлении данных. Данный показатель означает, что данные не должны сильно стареть с момента их последнего резервного копирования. То есть, если у нас RPO равно 1 час, то мы гарантируем, что в случае инцидента будут потеряны только данные за последний час, не больше.

Параметры RTO и RPO больше относятся к сопровождению внедренных систем, однако определиться с их значениями лучше на этапе разработки дизайна системы, так как эти значения являются одним из ключевых требований бизнеса, ведь каждая минута простоя бизнес-систем несет убытки.

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

И в завершение разговора о целях системного проектирования стоит упомянуть гибкость нашего решения. Выше мы уже говорили о том, что решения должны удовлетворять всем требованиям пользователей. Но никто не говорит, что эти требования будут всегда постоянными. Естественно, они будут постоянно меняться, так как технический прогресс не стоит на месте и все время возникают новые требования. Именно поэтому SDLC является цикличным процессом, и мы должны постоянно развивать свое решение, гибко подстраиваясь под нужды пользователей.

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

Преимущества системного проектирования

Дизайн решения включает в себя как проектирование фронтенда приложения, так и его бекэнд, структуру СУБД и дополнительных компонентов. Соответственно, уже на этапе разработки дизайна мы должны понимать, как будет осуществляться взаимодействие наших компонентов и как они будут построены.

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

Например, если вашему решению требуются вспомогательные контейнеры для журналирования, проксирования и других дополнительных активностей, то можно воспользоваться шаблоном Sidecar, для снижения нагрузки на основные компоненты системы.

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

Аналогичные шаблоны можно найти и для решения других задач.

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

System Design и CI/CD

Быстрый выпуск продуктов на рынок позволяет получить бОльшую прибыль. Так, на представленном ниже графике можно видеть стоимость потерянной прибыли для того, кто выпустил свой продукт позже (красный график).

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

Конечно, проверки библиотек должны делаться на этапе разработки и сборки в конвейере CI/CD, но лучше уже на этапе разработки дизайна понимать, какие зависимости мы будем использовать.

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

И давайте поговорим подробнее о конвейере CI/CD и дизайне. Конечно, при проектировании мы должны отталкиваться от тех задач, которые нам поставлены в ТЗ. Но, так как сроки тоже имеют большое значение, и в том или ином виде зафиксированы в том же ТЗ, то нам уже на этапе проектирования важно понимать, как мы будем реализовывать тот или иной функционал. Если у нас уже есть отлаженный механизм CI/CD, а еще лучше, если используется DevOps как культура в целом, то нам нужно знать, как мы будем собирать, отлаживать, тестировать компоненты нашего решения. Например, если система предполагает использование клиентов под мобильные платформы, то важно понимать, как данную часть разработки можно интегрировать в процесс CI/CD, какие компоненты придется для этого добавить в конвейер.

И здесь тоже не стоит забывать об информационной безопасности, так как соответствующие проверки должны быть встроены в конвейер CI/CD на всех этапах, будь то анализ исходного кода с помощью анализаторов SAST, анализ зависимостей SCA или тесты черным ящиком DAST.

Заключение

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

Научиться создавать архитектуру и структуры сложных систем можно на курсе "System Design". На странице курса можно ознакомиться с подробной программой, а также посмотреть записи открытых уроков.