Опыт побед и ошибок: ИТ-директора крупнейших компаний рассказали, как управлять цифровой инфраструктурой

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

На секции «Оптимизация цифровой инфраструктуры» в рамках CNews FORUM «Кейсы: опыт ИТ-лидеров» участники обсуждали не столько выбор конкретных продуктов, сколько оверхед от неподготовленных внедрений. Тема для рынка тривиальна лишь на словах. На практике именно здесь рождаются дорогие, но бесполезные контуры — включая частные облака, распределённые системы и платформы с избыточной автоматизацией.

Инфраструктура — это не набор серверов

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

Логика простая, хотя на презентациях её обычно размывают. Если система не соответствует масштабу и задачам бизнеса, то её техническая корректность не спасает экономику проекта. Можно развернуть кластер, настроить мониторинг, обеспечить резервирование и получить нулевой полезный результат. Бенчмарк без целевого сценария — это декорация.

В качестве примеров Афанасьев привёл внедрение ИИ без финансового эффекта, мобильное приложение фэшн-бренда, в которое вложили более 7 млн рублей без продаж через этот канал, а также проект торговой компании, где стоимость разработки приложения выросла с 7 млн до 25 млн рублей. Отдельный кейс — предприятие, потратившее 50 млн рублей на инструменты информационной безопасности, но не защитившее весь контур.

Для Web3-команд вывод без романтики: наличие ноды, RPC, индексатора и набора смарт-контрактов не образует рабочую систему. Нужно заранее фиксировать, какой сервис критичен, где проходит граница доверия, кто владеет ключами, какие операции можно откатить, а какие — нет. Иначе архитектура будет выглядеть децентрализованной только в маркетинговой схеме.

Миграция без остановки — отдельный инженерный контур

Представители «Газпром нефть ИТО» и MIND Software обсуждали автоматизацию миграции виртуальных машин. У «Газпром нефти» — разветвлённый ИТ-ландшафт с высоконагруженными системами, включая 1С и KUMA, а также масштабная IaaS-инфраструктура. Задача состояла в переносе критичной инфраструктуры без прерывания сервисов.

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

На ручном этапе скорость переноса составляла около двух виртуальных машин в неделю. Это не аномалия, а нормальная цена отсутствия автоматизированного pipeline: инвентаризация, проверка зависимостей, перенос, валидация состояния, наблюдаемость после переключения. Каждый пропущенный шаг становится уязвимостью эксплуатации.

Для блокчейн-узлов и сервисов вокруг них ситуация жёстче. Виртуальную машину можно перенести; состояние сети, ключевой материал, конфигурацию валидатора и правила слэшинга нельзя обрабатывать как обычный набор файлов. Перед миграцией нужны репетиция на изолированном контуре, проверка совместимости версий клиента, план rollback и независимый мониторинг состояния после переключения. «Бесшовность» без наблюдаемой телеметрии — не свойство системы, а предположение.

Вердикт: сначала модель отказа, потом закупка

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

Внешняя экспертиза, о которой говорил Афанасьев, полезна не как замена собственной инженерной функции, а как независимый аудит допущений. Особенно там, где команда уже выбрала продукт и теперь пытается подогнать под него задачу.

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