Что не учитывают при обновлении ИТ-инфраструктуры

Михаил Гилязов, директор по развитию бизнеса Скала^р (Группа Rubytech), объясняет, откуда берутся дополнительные расходы и что необходимо проверить до начала работ.

Модернизация устаревшей ИТ‑инфраструктуры — это не просто «обновить железо и софт», а перестройка фундамента, на котором держится операционная модель компании. И именно здесь бизнес чаще всего попадает в ловушку: на практике это выглядит как серия «тихих» рисков, которые не видны на этапе презентации вендора, но дают о себе знать уже в первые месяцы эксплуатации.

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

Вторая слепая зона — непрерывность бизнеса и реальные RPO/RTO. Например, репликация данных, которая выглядит простой на бумаге, на практике требует выделения отдельных каналов связи, синхронизации по времени, резервирования вычислительных мощностей и дополнительных лицензий. Если это не просчитано заранее, в момент аварии выясняется, что восстановление займет не 15 минут, а несколько часов (и это еще оптимистичный прогоноз), а стоимость владения оказывается заметно выше ожидаемой.

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

Еще один часто упускаемый фактор — производительность под реальной нагрузкой. Пилотные тесты обычно проводят в упрощенных (небоевых) сценариях: ограниченный объем данных, небольшое число пользователей, типовые запросы. В промышленной эксплуатации картина резко меняется: появляются пиковые нагрузки, сложные аналитические запросы, одновременная работа множества интеграций. В результате система начинает «тормозить», а попытки «дожать» производительность приводят к необходимости докупать оборудование или менять архитектуру уже после запуска.

Проверка до внедрения

Чтобы заранее оценить реальные возможности решения, имеет смысл опираться на ИТ-полигоны (например, ИЦК «Финансы»), где тестирование идет в условиях, максимально приближенных к боевым: с реальными объемами данных, типовыми индустриальными интеграциями и имитацией пиковых нагрузок. Такой подход позволяет еще на этапе пилота понять, как система справляется с отраслевой спецификой, и сразу заложить в проект необходимые мощности и архитектурные решения. В итоге бизнес получает предсказуемые SLA и избегает незапланированных расходов на донастройку инфраструктуры.

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

С точки зрения экономики, все эти недооцененные факторы выливаются в рост совокупной стоимости владения (TCO) и снижение возврата на инвестиции (ROI). По нашим наблюдениям, в проектах модернизации до 30–40% дополнительных расходов приходится именно на устранение последствий таких слепых зон. Поэтому мы рекомендуем начинать не с выбора технологий, а с аудита текущего ландшафта и фиксации требований: какие бизнес‑процессы критичны, какие показатели непрерывности и безопасности обязательны, какие интеграции нельзя разрывать, и как будет управляться новая инфраструктура. Только после этого имеет смысл переходить к архитектуре и выбору решений. Такой подход позволяет заранее увидеть узкие места, снизить риски и сделать бюджет и сроки предсказуемыми.