Долгое время корпоративная инфраструктура проектировалась как техническая основа бизнеса — надежная, масштабируемая и, по сути, вторичная по отношению к управленческим решениям. Архитектура строилась по рекомендациям вендоров, с запасом и без детального учета реальных профилей нагрузки.
Сегодня архитектурные решения — фактор финансовой устойчивости компании, формирующий стоимость владения ИТ-ландшафтом. Именно поэтому разговор о памяти, CPU и сайзинге все чаще выходит за пределы ИТ-департамента. В статье Виталий Попов, директор департамента реализации инфраструктурных проектов «Софтлайн Решения» (ГК Softline), рассказывает о том, как архитектура ИТ стала вопросом экономики бизнеса.
Как меняется экономика ИТ-инфраструктуры
По оценкам аналитиков, к концу 2025 года контрактные цены на DRAM выросли более чем в полтора раза по сравнению с прошлым годом — на фоне ограничения производственных мощностей и резкого роста спроса со стороны ИИ-проектов и облачных платформ. Для рынка это стало неприятным сюрпризом и поводом пересмотреть бюджеты и планы закупок на 2026 год. Инфраструктура, которая еще недавно воспринималась как относительно доступная и масштабируемая «на вырост», внезапно превратилась в ограниченный и дорогостоящий ресурс.
Важно понимать, что речь идет не просто о подорожании «железа». Меняется сама экономическая логика ИТ. Каждый гигабайт памяти, каждое CPU-ядро и каждый дополнительный узел инфраструктуры теперь имеют прямое финансовое выражение и требуют обоснования — не только технического, но и управленческого.
Динамика цен в текущих условиях
Рост цен на оперативную память и вычислительные ресурсы — не временный перекос и не рыночная аномалия. Он опирается сразу на несколько структурных факторов:
- Во-первых, рынок памяти физически не успевает реагировать на всплеск спроса. Производство DRAM — капиталоемкая и инерционная отрасль: на запуск новых фабрик и наращивание мощностей требуются не месяцы, а годы. Даже при масштабных инвестициях предложение не может оперативно вырасти вслед за спросом со стороны дата-центров, облачных платформ и ИИ-проектов.
- Во-вторых, сам спрос носит не спекулятивный, а инфраструктурный характер. Основные объемы памяти потребляют ИИ-кластеры, корпоративные ЦОД и облачные платформы, которые проектируются с долгосрочным горизонтом эксплуатации. Эти мощности не освобождаются при колебаниях рынка — они закладываются в базовую архитектуру цифровой экономики.
- В-третьих, производители памяти целенаправленно перераспределяют мощности в пользу наиболее маржинальных сегментов. Приоритет получают дата-центры и крупные корпоративные заказчики, тогда как потребительская электроника и менее доходные направления все чаще оказываются в очереди.
- Наконец, рост цен усиливается за счет условий среды эксплуатации: удорожания энергии, ужесточения требований к охлаждению и физических ограничений по размещению мощностей в ЦОД. Даже при временной стабилизации цен на сами чипы совокупная стоимость владения инфраструктурой продолжит расти.
Сложившуюся ситуацию не получится просто переждать. Рынок закрепляется в новой ценовой реальности, что закономерно приводит к пересмотру инфраструктурных подходов.
Когда привычная модель проектирования перестает работать
Исторически корпоративная инфраструктура проектировалась по простой, на первый взгляд, логике. Есть рекомендации вендора — их берут за основу, добавляют запас, умножают на коэффициент надежности и получают целевую конфигурацию. Такой подход десятилетиями считался безопасным — он снижал риски на этапе внедрения и фиксировал зону ответственности производителя.
Проблема в том, что вендорский сайзинг всегда рассчитывается для усредненного и худшего сценария, который в реальности может никогда не наступить. Он не учитывает конкретные профили нагрузки, пиковые и непиковые режимы работы, особенности интеграций и реальные кейсы использования системы. В результате инфраструктура проектируется не под бизнес-задачи компании, а под абстрактную модель максимальной нагрузки.
Избыточный сайзинг в дальнейшем становится частью эксплуатационных затрат, не всегда напрямую связанной с текущими бизнес-потребностями.
Пока вычислительные ресурсы были относительно доступными, эта избыточность оставалась незаметной. Компании могли позволить себе покупать серверы с запасом, устанавливать терабайты оперативной памяти и воспринимать это как плату за надежность. Однако в условиях роста стоимости оборудования и эксплуатации такой подход начинает генерировать постоянную переплату.
Архитектура формирует потребление
Во многих случаях причина избыточности лежит не в объемах нагрузки, а в архитектурных решениях, принятых на старте проекта.
На практике часто выясняется, что система потребляет память и процессорное время не потому, что этого требует бизнес-сценарий, а потому, что так устроена ее внутренняя логика. Где-то данные целиком загружаются в память вместо потоковой обработки. Где-то отсутствует контроль аллокаций. Где-то контейнеры работают без лимитов. Где-то масштабирование построено по принципу «добавим еще один узел», без учета необходимости оптимизировать потребление.
В итоге получается, что компания платит не за фактическую бизнес-нагрузку, а за выбранную архитектурную модель: за паттерны работы с данными, принятый способ масштабирования, избыточные абстракции. Эти решения редко пересматриваются, но именно они составляют основную часть эксплуатационных затрат.
В корпоративных ИТ-ландшафтах расходы формируются не только объемами данных, но и архитектурными решениями и выбранной моделью масштабирования. Эти решения могут закрепить избыточные затраты на годы вперед.
Так, вопросы памяти, CPU и сайзинга выходят за пределы инженерной повестки, поскольку они напрямую влияют на финансовые параметры инфраструктуры и требуют участия управленческих команд наряду с техническими.
Инженерная ответственность как новая норма
В течение многих лет рост производительности и снижение относительной стоимости железа позволяли компенсировать архитектурные ошибки экстенсивно — за счет добавления памяти, процессоров и новых узлов.
Сегодня рынок входит в фазу, когда инженерные решения требуют точного расчета. Не потому, что ресурсы физически исчезли, а потому, что их стоимость стала ощутимой для бизнеса. Архитектурные компромиссы имеют долгосрочные финансовые последствия, которые уже невозможно скрыть за разовой закупкой или увеличением бюджета.
В этом контексте невольно вспоминаются времена ассемблера, когда у разработчика было условных 32 бита и приходилось по-настоящему инженерно мыслить, чтобы программа вообще работала. Эта логика возвращается — но не на уровне технологий, а на уровне экономики.
Разработчикам приходится внимательнее относиться к тому, как код потребляет ресурсы: отслеживать использование памяти, контролировать аллокации, учитывать жизненный цикл компонентов. Избыточность больше не воспринимается как безобидный запас прочности — далеко не все заказчики готовы финансировать решения, требующие дополнительных дата-центров ради формальной отказоустойчивости.
Это отражается и на выборе языков, инструментов и архитектурных подходов: вводятся лимиты контейнеров, сокращается количество лишних абстракций, вместо полной загрузки данных применяются lazy loading, paging и стриминг. Эти приемы давно известны, но теперь без них все сложнее строить системы, оправданные с точки зрения эксплуатации.
Инженерная ответственность снова выходит на первый план, только теперь из-за экономических ограничений. И от того, насколько точно спроектирована система, зависит не только ее стабильность, но и то, сколько компания будет платить за ее работу в течение ближайших лет.