Ошибки в проектировании архитектуры: на что обращать внимание

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

Анализ нефункциональных требований;
Проектирование баз данных;
Исследование технологий, подходящих для реализации проекта (например выбор API или брокеров);
Анализ решений конкурентов и имеющегося опыта у сотрудников компании для определения подходящих шаблонов архитектуры, подходящих для реализации проекта;
Детализацию постановок задач на разработчиков, включающую описание алгоритмов, в которых указаны компоненты системы, отвечающие за выполнение шагов.

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

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

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

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

Пример:
Финансовая аналитическая система формирует отчет по торгам в среднем от 10 до 30 секунд. Но в момент завершения торгов, когда больше всего пользователей начинает запрашивать отчеты, система начиниет тормозить и выдавать ответ на запрос в течение 2-3 минут. Все остальные действия в ней выполняются дольше чем обычно.

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

Собирая требования от бизнеса и пользователей, проводите анализ рынка и уточняйте потенциальные варианты развития:
- Сколько пользователей планируется сейчас? Через год? Через 5 лет?
- У конкурентной системы есть "такая фича", планируете ли вы её поддержать в будущем?
- Какие возможности мы не будем поддерживать сейчас, но вы точно знаете, что они появятся в будущем?
Учитывайте потенциальный рост и изменения в требованиях при планировании архитектуры системы. Если знаете, что определенная функцинальность в ближайшем будущем будет под высокой нагрузкой от пользователей, то имеет смысл выделить её в отдельный сервис или микросервис сразу, а не держать в общем монолите.
Перед разработкой проведите исследование технологий, которые сейчас доступны на рынке и с которыми у вас уже был опыт, чтобы выбрать лучшие решения, которые смогут адаптироваться к изменяющимся потребностям системы в будущем.
Разрабатывайте систему модульно, даже если вы начинаете проект как монолит, чтобы отдельные части могли быть обновлены или заменены без влияния на всю систему.
Регулярно анализируйте производительность системы через системы мониторинга и логи, и планируйте улучшения, основываясь на собранных данных.

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

Разработка системы интернет-магазина для малого бизнеса, который продает всего несколько видов товаров. Вместо использования простой монолитной архитектуры или шаблонного "интернет-магазина из коробки", команда решила реализовать собственную систему на основе микросервисов, разделив каждую функцию (обработку заказов, управление каталогом товаров, обработку платежей) на отдельные сервисы.

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

Переоценка требований:
Команда может предполагать, что системе потребуется больше функциональности, чем на самом деле и стараться сделать идеальную архитектуру сразу.
Стремление к совершенству:
Желание использовать новейшие технологии или реализовать архитектурно "идеальное" решение без учета его практической целесообразности. Это ведет к сложностям с сопровождением.
Недостаточный опыт:
Неопытные разработчики могут внедрять сложные решения не зная простых и эффективных альтернатив.

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

Примеры угроз безопасности

Кража данных:
- Медицинские информационные системы с данными о пациентах.
- Онлайн-магазины с клиентскими базами.
- Системы продажи авиабилетов с паспортными данными и сведениями об авиаперелетах пассажиров.

Атаки типа "отказ в обслуживании" (DoS-атака) направлены на выведение из строя системы или ее компонентов, что делает ресурсы недоступными для реальных пользователей. Это может быть достигнуто путем перегрузки серверов большим количеством запросов или эксплуатацией программных уязвимостей.

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

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

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

Postman: Практическое руководство с примером тестирования открытого API

Введение

Почему так происходит:

Рекомендации:

Заключение