Основы системного дизайна
Что такое системный дизайн: основы для тех и не очень
1. Проблема и зачем это нужно
Система работает — и это хорошо, пока не наступает чёрная пятница. Тогда за 40 минут количество заказов вырастает в 12 раз, база начинает отвечать за 800 миллисекунд вместо 30, а хранилище упирается в IOPS. Значит, систему не спроектировали: её собрали « чтобы работало», а под пик она не рассчитана.
Именно эту задачу закрывает системный дизайн — дисциплина, которая отвечает на вопрос «как построить систему так, чтобы она выдержала рост нагрузки, не развалилась при отказе узла и стоила столько, сколько вы готовы платить». Это не картинки с блоками на доске. Это инженерные решения с цифрами: сколько серверов, какого класса, какая СХД, какой запас по доступности.
Для заказчика и интегратора ценность простая: правильно спроектированная система дешевле в эксплуатации и предсказуемее при росте. Ошибка в проектировании всплывает поздно — на втором году, когда правки стоят дороже, чем изначальный расчёт. Вопрос «что такое системный дизайн» поэтому про деньги, а не про терминологию.
2. Что это и как работает
Системный дизайн — процесс превращения бизнес-задачи в состав ИТ-компонентов: серверы, СХД, сеть, база данных, приложение и слой интеграций. Ключевой момент — принципы, а не инструменты. Проектировщик работает не с «железом по прайсу», а с нагрузкой и требованиями по доступности.
Логика проектирования систем укладывается в четыре шага:
- Зафиксировать профиль нагрузки — сколько запросов в секунду, сколько одновременных пользователей, какой объём данных и как он растёт.
- Определить требования по доступности — допустим ли простой 15 минут в месяц или нужен практически бесперебойный контур.
- Выбрать архитектуру — монолит, микросервисы, очереди, кэш, репликация. Здесь решаются trade-off.
- Посчитать ресурсы — ядра, память, диски, IOPS, полоса сети, запас на рост и резервные копии.
Схематично: *нагрузка → расчёт → архитектура → железо → проверка на пике*. Петля, в которую возвращаются после каждого замера, потому что цифры меняются.
Практическое следствие: не бывает «хорошего сервера вообще». Бывает сервер под конкретную задачу. Одинаковая машина даёт разный результат в роли виртуализации и в роли базы данных — поэтому подбирают узел под профиль, а не «посильнее». Разобраться с подбором под роль помогает материал Как перейти на отечественное оборудование.
3. Основные понятия и термины
- Нагрузка (RPS) — число запросов в секунду. База для расчёта «сколько серверов нужно».
- SLA / SLO — обещанная и фактическая доступность. «Четыре девятки» — это 99,99% времени работы.
- Отказоустойчивость — способность продолжать работу при отказе одного компонента.
- Масштабирование вертикальное — добавить ресурсов в один узел (ядра, память, диски).
- Масштабирование горизонтальное — добавить узлов и распределить нагрузку между ними.
- Репликация — копирование данных на несколько узлов для надёжности и чтения.
- Частичный доступ — отказ в одном сегменте системы, без остановки всей.
- Ёмкость и производительность — сколько данных помещается (ТБ) и как быстро они отдаются (IOPS, МБ/с).
4. Плюсы и минусы системного дизайна
| Плюс | Минус | Противовес / решение |
|---|---|---|
| Предсказуемость при росте нагрузки | Требует времени и замеров на старте | Замерять «на глаз» нельзя — снимать метрики за неделю пиков |
| Оптимальный бюджет: не переплата за лишнее | Легко переоценить и заложить лишнее | Считать запас на рост, а не кратный «на всякий случай» |
| Понятные требования для закупки по 44-ФЗ/223-ФЗ | Нужен документ с характеристиками, а не «аналог Dell» | Оформить ТЗ с реестровыми требованиями и обоснованием |
| Ясный план эволюции системы | Чем сложнее архитектура, тем дороже поддержка | Выбирать микроуровень только там, где он окупается |
Главная ловушка — проектировать «под сегодня». Система живёт 5–7 лет, и то, что дешево сейчас, на третьем году становится узким местом. Закладывайте точку роста заранее.
5. Типовые ошибки при проектировании систем
| Ошибка | Причина | Решение |
|---|---|---|
| Считать «среднюю» нагрузку | Пики давят сильнее среднего | Брать пиковый RPS за неделю, а не среднее за месяц |
| Копить лишний запас «на всякий случай» | Желание подстраховаться | Закладывать запас на рост, а не кратный «от балды» |
| Подбирать железо по числу ядер | Ядра разных вендоров несравнимы | Оценивать по частоте, памяти и профилю нагрузки |
| Игнорировать IOPS, а не только объём | Ёмкость видна, производительность — нет | Считать IOPS и задержку дисков на 3 года вперёд |
| Проектировать «под сегодня» | Система живёт 5–7 лет | Закладывать точку роста и план эволюции |
| Брать аналог по бренду, а не по модели | Однобокий поиск «как у Dell» | Подбирать под роль, а не под название |
Отдельно — про закупку. Если вы проектируете систему под госзаказчика или компанию с госдолей, оборудование обязано быть в реестре Минпромторга, иначе конфигурацию не согласовать. Оформление закупки по 44-ФЗ/223-ФЗ и порядок действий разобраны в переходе на отечественное оборудование. То же касается ПО: реестровая линейка снимает часть вопросов при согласовании.
6. Как это сделать в вашей организации
- Снимите реальный профиль нагрузки. За неделю пиковых наблюдений соберите % CPU, объём и рост БД, IOPS и задержку дисков, сетевой трафик.
- Зафиксируйте требования по доступности. Формализуйте SLA в SLO: сколько минут простоя допустимо и окно обслуживания.
- Выберите архитектурный слой. Монолит или микросервисы, нужны ли очереди и кэш. Спорные места удобнее взвесить на примере — микросервисы против монолита.
- Посчитайте ресурсы и запас. На 3 года вперёд: чистый объём × коэффициент роста × 30–50% на снапшоты и копии.
- Спроектируйте железо под нагрузку, а не под прайс. Под ответственные системы смотрите серверы и СХД из реестра Минпромторга. Удобнее начинать с подбора: серверы и системы хранения данных.
После внедрения цикл не завершается — система постепенно упирается в новую границу. Когда нагрузка вырастает, на помощь приходят масштабирование и балансировка.
7. Вопросы и ответы
Системный дизайн и архитектура ПО — одно и то же? — Нет. Архитектура отвечает за устройство приложения (слои, сервисы, интерфейсы), системный дизайн — за всю систему: приложение + железо + сеть + хранение + требования по нагрузке.
Со скольки пользователей нужен системный дизайн? — Не с цифры, а с момента, когда ресурсов «на глаз» перестаёт хватать. Уже при 2–3 сутках простоя в год или при первом пике в 5 раз от среднего — время считать.
Можно ли спроектировать систему без замеров? — Только с большим запасом, а значит с переплатой. Замер за неделю пиков дешевле, чем лишние узлы на годы.
Обязателен ли реестр Минпромторга? — Для госзаказчика и компаний с госдолей — да. Для коммерческого сектора реестр даёт дисконт и преимущество в тендере.
Частые вопросы
Системный дизайн и архитектура ПО — одно и то же?
Нет. Архитектура отвечает за устройство приложения (слои, сервисы, интерфейсы), системный дизайн — за всю систему: приложение + железо + сеть + хранение + требования по нагрузке.
Со скольки пользователей нужен системный дизайн?
Не с цифры, а с момента, когда ресурсов «на глаз» перестаёт хватать. Уже при 2–3 сутках простоя в год или при первом пике в 5 раз от среднего — время считать.
Можно ли спроектировать систему без замеров?
Только с большим запасом, а значит с переплатой. Замер за неделю пиков дешевле, чем лишние узлы на годы.
Обязателен ли реестр Минпромторга?
Для госзаказчика и компаний с госдолей — да. Для коммерческого сектора реестр даёт дисконт и преимущество в тендере.