System Design: Как бизнес влияет на финальный вид ИТ-Системы и выбор технологий
- суббота, 5 июля 2025 г. в 00:00:06
Представьте, вам поступает задача спроектировать абсолютно новую ИТ-Систему, которую ранее не видел свет. Вам озвучивают сроки в которые нужно уложиться и вы наполненные энтузиазмом и решительностью, приступаете как и положено с выявления требований к этой системе. Далее происходит этап отрисовки верхнеуровнего дизайна, где вы намечаете основные компоненты системы и способы их взаимодействия. Далее после получения одобрения от своих коллег, технического сектора, вы переходите на этап детальной проработки архитектуры, разбиваете ее на модули. Далее вы с умом подходите к оптимизации вашей системы (Кэширование, ограничение нагрузки, балансировка, репликация БД и тд.). И вот потратив много времени и сил у вас в руках результаты ваших трудов. Вы довольный, ни о чем не подозревая идете защищать свое отказоустойчивое, масштабируемой, надежное решение c мгновенным откликом перед руководителями и бизнесом. Вы представляете им детальный план работ, со сроками и рисками и тут то вам и говорят, что система не соответствует бизнес ограничениям! В этот момент обычно руки сами опускаются. Вы делали все по науке и современным стандартам, а вам говорят, что в таком виде система не может быть представлена пользователям, так как какие-то бизнес ограничения не соблюдены.
Эта ситуация по настоящему пугающая, так как драгоценное время, потраченное на проработку системы казалось бы по всем правилам System Design, ушло. Скоро релиз и получается нужно в короткие сроки все переделывать. Команда разработки будет простаивать, так как согласованный финальный вид архитектуры является приреквизитом для старта разработки. Дальше в дело вступает ваш героизм и желание все исправить в короткие сроки, чтобы все таки реализация новой системы не отставала от графика.
Ясно, что для того, чтобы избежать нежелательных последствий в будущем, нам необходимо заранее все предусмотреть.
Сегодня мы обсудим, что такое Бизнес-ограничения, какие они бывают и что сделать чтобы избежать переделок вашей системы на поздних этапах и почему «идеального дизайна» не существует, ведь System Design — это не только про технологии, но и про компромиссы.
Бизнес-ограничения — это внешние или внутренние условия, которые накладывают рамки на проектирование и разработку IT-Системы. Они не связаны напрямую с технической реализацией, но критично влияют на архитектуру и выбор технологий.
Давайте поговорим о том, какие типы бизнес-ограничений встречаются:
Сколько денег можно потратить на инфраструктуру, разработку и поддержку.
Примеры:
1. Облачный бюджет — не более $5к/мес. Выбираем более дешевые инстансы AWS.
2. Нет денег на коммерческие СУБД. Используем PostgreSQL вместо Oracle.
Сроки выхода продукта или отдельных фич.
Примеры:
1. MVP должен быть готов за 3 месяца. Выбираем монолит вместо микросервисов.
2. Фича “Онлайн-оплата” нужна к Чёрной пятнице. Приоритезируем её над другими задачами.
Что должно быть выполнено обязательно.
Примеры:
1. При создание сервиса "Интернет магазин", обязательно должен быть умный поиск товаров с фильтрами и сортировкой. Их то мы и учитываем в нашей системе.
2. В MVP сервиса Бронирования отелей можно ограничиться только поиском отелей в ленте, бронированием и предоплатой. Может воспользоваться внешними системами для реализации оплаты.
Требования закона или отраслевых стандартов.
Примеры:
1. Система должна соответствовать закону о персональных данных. Добавляем механизм удаления персональных данных.
2. Платежи должны проходить сертификацию PCI DSS. Запрещаем хранение CVC-кодов.
Ожидания пользователей или особенности рынка.
Примеры:
1. В Китае заблокирован Google Cloud. Разворачиваем систему на Alibaba Cloud.
2. Пользователи Африки часто используют 2G. Оптимизируем трафик и размер страниц.
Пример 1: Бюджетное ограничение
Ограничение: Бюджет на сервера — $1к/мес.
Решение: Выбираем технологию, которая позволит уложиться в бюджет
Пример 2: Юридическое ограничение
Ограничение: Данные россиян должны храниться в РФ» (ФЗ-152).
Решение: Размещаем сервера только в дата-центрах Москвы. Не используем облачные хранилища расположенные за пределами страны.
Пример 3: Временное ограничение
Ограничение: Запуск через 2 месяца.
Решение: Выбираем low-code платформу вместо кастомной разработки или закупаем разработку у вендора (компания или организация, которая производит, разрабатывает и/или поставляет товары или услуги под собственной торговой маркой), который подготовит минимально жизнеспособный продукт, способный удовлетворить базовые потребности.
Давайте остановимся подробнее на 3х составляющих: Стоимость, Скорость, Объем работ и их влияние на наше конечное решение. В System Design эти три фактора образуют "Железный треугольник" (или "Тройное ограничение"), где изменение одного параметра влияет на остальные. Формула: "Хорошо, быстро, дёшево — выберите два":
Стоимость (Бюджет). Влияет на выбор технологий (облако vs свои серверы, open-source vs коммерческие решения), масштабируемость (дешёвое решение может не выдержать нагрузку), команду (опытные разработчики стоят дороже, поэтому выбирая технологию необходимо понимать, готовы ли к ней члены команды).
Скорость (Время потраченное на проработку решения). Влияет на архитектурные решения (микросервисы требуют больше времени, чем монолит), технологический стек (знакомые технологии ускоряют разработку), тестирование и деплой (CI/CD ускоряет выпуск фич, но требует настройки).
Объем работ (Что именно должно быть сделано в рамках проекта). Влияет на сложность системы (10 эндпоинтов vs 1000), количество интеграций (платёжные системы, аналитика, CRM), нефункциональные требования (нагрузка, безопасность, отказоустойчивость).
Как Стоимость (бюджет) влияет на остальное?
↑ Бюджет → ↑ Скорость (можно нанять больше сильных разработчиков, способных справиться с задачей любой сложности, купить готовые решение у вендора).
↑ Бюджет → ↑ Качество (можно получить лицензию на качественное ПО или закупить больше необходимого оборудования - это все на прямую будет валяться на конечный вид системы)
↓ Бюджет → ↑ Время или ↓ Качество (придётся делать всё самим и дольше, необходимо ужиматься, жертвуя компетентными разработчиками и качественным ПО).
Как Скорость влияют на остальное?
↑ Скорость → ↑ Стоимость или ↓ Качество (нанимаем больше людей или режем фичи, упрощая нашу финальную архитектуру).
↓ Скорость → ↓ Стоимость (но бизнес может упустить рынок, поэтому следует продумать архитектуру так, чтобы минимизировать время разработки при ограниченных ресурсах).
Как объём работ влияет на остальное?
↑ Объём → ↑ Стоимость или ↑ Время (больше кода, больше система → больше разработчиков чтобы уложиться в срок или оставляем все как есть и принимаем риск не успеть).
↓ Объём → можно сделать быстрее и дешевле (Упрощаем финальный вид системы, но рискуем не покрыть все сценарии, что в конечном счете может быть негативно воспринято пользователями).
Схематично обычно эти компромиссы представленный в виде треугольника, в который вписан круг - Качество, то есть то что мы получаем на выходе, после определения 3х величин.
Качество проекта не является независимой величиной. Оно определяется соотношением времени, стоимости и объема работ. Например, если заказчик хочет получить продукт быстро и дешево, то, скорее всего, придется пойти на компромисс в качестве. И наоборот, если заказчик хочет высокое качество и готов ждать, можно оптимизировать сроки и бюджет, чтобы достичь желаемого уровня.
Для успешного согласования своего технического решения необходимо четко определить, что понимается под качеством в данной конкретной задаче или проекте. Это может быть соответствие определенным стандартам, удовлетворенность клиентов, надежность и т.д. Менеджер проекта должен понимать, как соотносятся между собой время, стоимость, объем и качество, чтобы принимать обоснованные решения и управлять рисками. А технический социалист реализует оптимальное решение которое будет согласовываться с бизнес-ограничениями.
Для того, чтобы грамотно балансировать между бизнес ограничениями и потенциальной архитектурой вашего решения необходимо:
Определите Бизнес ограничения:
Если главное — скорость (стартап), жертвуем идеальным дизайном.
Если главное — надёжность (банк), увеличиваем бюджет и сроки, что позволяем более творчески и смелей подойти к проектированию системы.
Считайте нагрузку и стоимость вашего решения. В таком случае вы сами будете в состоянии оценить, вписываетесь вы в бюджет, сроки и объем работ или нет. Тут важно обратить внимание на потенциальный пользовательский и сетевой трафик.
Используйте MVP-подход: Сначала — самое важное, потом масштабируем. То есть первая версия системы может быть далека от идеала, но должен быть задел на будущее. Отсюда вытекает следующий пункт.
Закладывайте гибкость: Например, монолит → микросервисы, когда будет нужно.
Нет «идеального» дизайна — есть оптимальный для конкретного бизнеса. Прежде чем предлагать решение, до старта проектирования, задайте бизнесу следующие вопросы:
Какой бюджет?
Какие сроки?
Что умеет команда?
Есть ли регуляторные ограничения?
Как система будет зарабатывать?
Только после этого можно выбирать технологии.
Также предлагаю вам ознакомится со статьей: System Design: Чек-лист по сбору и фиксации требований на все случае жизни.
И еще,
если вы желаете познать все тонкости System Design, не только работу с Бизнес-ограничениями, но и хотите научиться по всем правилам проектировать надежные и масштабируемые системы как Google, Netflix, Яндекс, Amazon или вы готовитесь к собеседованию по System Design - смело записывайтесь на мой курс на Stepik: C нуля до проектирования систем уровня senior-инженера.. Специально для Хабра действует промокод 20% HABR20