Цена компромисса. Когда экономия на архитектуре увеличивает TCO в три раза

Фраза «сделаем попроще, потом дорастим» звучит разумно на этапе согласования бюджета. Но в ИТ-инфраструктуре она часто означает одно: придётся платить дважды, а иногда трижды.

Разбираем, где именно компании экономят на старте — и как эта экономия превращается в аварии, ночные работы и срочные закупки.

Главная ошибка проектов при построении ИТ-инфраструктуры

Многие организации при выборе компонентов для ИТ считают только CAPEX первого года. Они перечисляют в смете серверы, СХД, коммутаторы, лицензии, а затем вычеркиваютвсё, что не выглядит обязательным прямо сейчас.

Но TCO (совокупная стоимость владения) — это не сумма разовой закупки. Это капитальные и операционные расходы, поддержка, простои, миграции, лицензии, ремонт и цена рисков. На длинном горизонте операционные расходы часто оказываются весомее, чем стартовые вложения.

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

Где чаще всего экономят

1. Сеть: прямые подключения
Аргумент звучит так: «У нас три сервера и одна СХД. Зачем два коммутатора? Потом добавим». На тестовом стенде это работает, но в продуктивном контуре становится проблемой.
Нормальная сеть — это отказоустойчивость, предсказуемая задержка, разделение трафика хранения, управления и репликации, понятные домены отказа и возможность обновлять компоненты без остановки всего и сразу. 

2. СХД: «ёмкость есть — значит, хватит»
Бизнес говорит: «Нам нужно 80 ТБ». Поставщик предлагает 100 ТБ. Все довольны.
Потом выясняется, что важно было учитывать не только терабайты, но и IOPS, задержки, профиль нагрузки и поведение системы при перегрузке. Особенно в смешанных контурах, когда 1С, базы данных, терминальные серверы, файловые ресурсы и бэкапы живут на одном массиве. 
В итоге неграмотный подбор СХД (системы хранения данных) редко заканчивается просто покупкой дисков. Чаще — миграцией данных, изменением политики бэкапов или покупкой второго массива.

3. Резервное копирование: «бэкапы есть» вместо «восстановление проверено»
Бэкап без регулярного теста восстановления — это не защита. В 2025–2026 годах вопрос стал острее из-за роста киберрисков на 45%, причём наиболее распространёнными инструментами остаются вредоносное ПО, социальная инженерия и эксплуатация уязвимостей.
Если архитектура бэкапов не отделена от основного контура, нет неизменяемых копий, не соблюдается правило 3-2-1, а RPO/RTO не подтверждены тестом, то после инцидентов компания теряет данные, время, деньги и репутацию.

4. Виртуализация: выбор только по цене лицензии
Смена гипервизора — это не просто замена платформы. Нужно учитывать совместимость с оборудованием, сетевую модель, работу с СХД, механизмы HA (высокая доступность), интеграцию с мониторингом, квалификацию команды и сценарий отката. Если выбрать платформу только по цене, дешёвая лицензия конвертируется в дорогую эксплуатацию на годы.

5. Мониторинг: «Поставим потом»
Мониторинг почти всегда проигрывает в спорах за бюджет. Его не видно пользователю, он не запускает новый процесс, не выглядит убедительно рядом с сервером или СХД. Без мониторинга инфраструктура управляется по жалобам, ИТ-отдел узнаёт о проблеме, когда бизнес уже пришёл с фразой «у нас всё лежит».

Как считать TCO корректно

TCO считается в пяти слоях.

1. Закупка: серверы, СХД, сеть, лицензии, монтаж, внедрение.
2. Эксплуатация: поддержка оборудования и ПО, администрирование, мониторинг, электричество, размещение, обновления.
3. Рост: дополнительные узлы, диски, порты, новые филиалы, новые сервисы, миграции.
4. Риски: простой, потеря данных, нарушение SLA, штрафы, зависимость от одного инженера, устаревание оборудования, несовместимость решений.
5. Работы: повторное проектирование, аудит, закупка недостающих компонентов, миграция, ночные работы, обучение команды.

Итоговая формула: 
Стоимость решения = стоимость внедрения + стоимость эксплуатации + стоимость риска + стоимость возврата к правильной архитектуре.

Пример расчёта

Типовой контур: 6 физических серверов виртуализации, одна СХД среднего класса, 80–120 виртуальных машин, 150–300 пользователей, ERP/1С, терминальные серверы, файловые сервисы, рост нагрузки 20–30% в год.

Теперь три года эксплуатации:

Итого: 16–20 млн рублей сверху. И это без крупной аварии, шифрования и штрафов.

Такой рост стоимости ИТ-инфраструктуры на горизонте трёх-пяти лет складывается из трёх накопленных слоёв.

• Стоимость переделки. Переделывать всегда дороже, чем спроектировать сразу. Когда инфраструктура в продуктиве, появляются ограничения: нельзя надолго остановить сервисы, нужны ночные окна и планы отката, приходится сохранять совместимость. То, что на этапе проекта стоит 1 млн рублей, после запуска вырастает до 3–5 млн.
• Стоимость эксплуатации. Плохая архитектура требует постоянной ручной работы. Инженеры живут в режиме «перезапусти», «перенеси ночью», «сделай временный VLAN», «не трогай этот сервер, на нём всё завязано». Это — OPEX. Сильный инженер вместо развития инфраструктуры налаживает старые архитектурные решения.
• Стоимость риска. Это самая неприятная часть, потому что её не видно до аварии. Нет DR, теста восстановления, изоляции бэкапов, мониторинга — всё это риск. По данным Uptime Institute, у 54% компаний последний серьёзный сбой стоил больше $100 тыс., у каждой пятой — больше $1 млн.

Семь признаков того, что экономия не там

1. Любое изменение требует «того самого инженера». Если инфраструктуру может безопасно обслуживать только один-два человека — это ежедневный риск.

2. Схема сети существует только в головах команды. Во время инцидента придётся для начала изучить собственную инфраструктуру.

3. Бэкапы есть, но RTO/RPO никто не подтверждал. «Примерно сутки» и «как получится» — это признак, что бизнес не знает, сколько данных и времени он готов потерять.

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

5. В инфраструктуре много «временных» решений. Все пережившее два квартала становится постоянным — только без документации и поддержки.

6. Нет разделения доменов отказа. Если один сбой может одновременно уронить вычисления, хранение, сеть управления и бэкапы — это слишком большой риск.

7. Обновления откладываются, потому что «страшно трогать». Если возникают такие эмоции, инфраструктурауже вышла из управляемого состояния.

Чек-лист: практический минимум для инфраструктуры, на которой строится бизнес

1. Карта критичности сервисов. Не все системы одинаково важны. Разделите хотя бы на три класса: критичный, важный и некритичный.
2. RTO/RPO, согласованные с бизнесом. Бизнес отвечает: сколько стоит час простоя, сколько данных можно потерять, какие обязательства нарушатся, какие штрафы возможны. После этого ИТ предлагает архитектуру.
3. Сеть, рассчитанная на рост. Минимум: резервирование коммутаторов, разделение трафика, запас портов, отказоустойчивые аплинки, документация, мониторинг ошибок и задержек, регламент изменений.
4. СХД, рассчитанная по профилю нагрузки. Считайте не только терабайты: задержки, пиковые окна, влияние бэкапов, снапшоты, требования приложений.
5. Бэкапы, которые реально восстанавливаются. Правило 3-2-1, защита от удаления и шифрования, регулярный тест восстановления, отдельные учётные записи и права.
6. Мониторинг. Доступность сервисов, загрузка CPU/RAM/storage/сеть, задержки, ошибки портов, заполнение хранилищ, состояние бэкапов и репликации, события ИБ.
7. Документация. Схема сети, размещения сервисов, матрица зависимостей, IP-план, VLAN/VRF, регламенты изменений, план восстановления, контакты и зоны ответственности.
8. План миграции с планом отката. Любое серьёзное изменение: окно работ, критерии успеха, критерии отката, ответственные, резервные копии, тестовый прогон, постпроверка. 

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

Если сейчас вы стоите перед выбором между «дешевле запуститься» и «правильно спроектировать» — начинайте с аудита ИТ-инфраструктуры. Заполните короткую форму – наши инженеры свяжутся с вами и помогут найти оптимальное решение, чтобы вам не пришлось расплачиваться за компромиссы.