Опубликовано: 18 сентября 2026 · Источник: TAdviser
ВасилийКак за последние несколько лет изменилась задача управления корпоративной ИТ-инфраструктурой? Какие проблемы вышли на первый план?
Василий Александров: Еще недавно инфраструктуру крупной компании можно было держать в голове. Один сильный архитектор или главный администратор знал, что где стоит, как связано и что сломается, если тронуть. В некоторых компаниях такие суперэксперты есть до сих пор, но это уже исключение: инфраструктура растет быстрее, чем способность человека ее охватить.
Изменились две вещи. Во-первых, инфраструктура стала разнородной. Раньше это был парк однотипных серверов, теперь один фрагмент кода должен исполняться на GPU, другой на обычных процессорах, третий в контейнерах, а с приходом генеративных моделей к этому добавились свои требования к вычислениям, сети и хранению. Во-вторых, компании организованы так, что каждая команда отвечает за свой кусок: за железо, за операционные системы, за виртуализацию, за платформу, за приложения.
Каждая команда ведет свои системы учета и мониторинга, и хорошо, если по одной на команду. В итоге в компании просто нет места, где хранилось бы знание об инфраструктуре целиком: от аппаратных компонентов до полезной нагрузки. Оно живет частично в десятке инструментов, частично в документах, частично в головах.
При этом сбои не знают границ между доменами. Когда отлетает диск, это затрагивает все, что стоит выше: виртуальную машину, кластер, сервис, и в конце концов пользователя и деньги бизнеса. Инцидент почти никогда не остается в одном домене.
Поэтому при крупном инциденте инженерам приходится собираться на звонок на десять, а то и пятьдесят человек, чтобы сначала восстановить картину происходящего и только потом чинить. Это дорого по времени людей, долго по восстановлению и очень дорого по потерям за время простоя. С ростом команды время восстановления не падает, а растет.
То же самое в кибербезопасности. Служба ИБ защищает контур, границ которого не видит: нет единой точки правды о том, что вообще есть в компании и какого оно объема. Когда происходит проникновение, так же трудно понять, какая часть инфраструктуры оказалась затронута, потому что неизвестен исходный объем. В FinOps решения об оптимизации парка принимаются на ощущениях каждой конкретной команды, а не на картине сверху. Уход одного инженера уносит знание, которое нигде не записано, а новому нужно от трех до шести месяцев, чтобы это знание собрать заново.
Управление инфраструктурой перестало быть человекосоразмерной задачей. Ни один человек, включая CTO, не имеет о ней полного знания, и последствия изменений предугадать крайне трудно. Отсюда критические сбои при обновлениях и при уходе специалистов. Критически важные системы стали слишком сложными для понимания и по сути потеряли управляемость. Это нужно признать и пересмотреть подходы к управлению: не добавлять еще один инструмент к десятку существующих, а восстановить целостное знание об инфраструктуре.
Генеративный ИИ резко ускоряет разработку: код и новые сервисы можно создавать быстрее. Успевают ли инфраструктурные команды за этим ускорением?
Василий Александров: Не успевают и не могут успеть при нынешних подходах. Разрыв хорошо виден в исследовании State of DevOps Russia 2025 от компаний «Экспресс 42» и «Флант», в котором участвовало больше трех тысяч инженеров. Почти три четверти из них уже используют ИИ в работе. При этом 63% отмечают пользу в разработке кода, но только 26% в управлении инфраструктурой, 22% в эксплуатации и 12% в управлении инцидентами. То есть ИИ ускорил ровно ту часть конвейера, которая производит изменения, и почти не коснулся той, которая должна их принимать и держать в рабочем состоянии. Разница между лучшими и худшими командами по частоте релизов уже измеряется десятками раз, а инфраструктурные команды получают этот поток изменений в прежнем составе и с прежними инструментами.
Причина не в том, что инфраструктурные инженеры медленнее осваивают новые инструменты. Причина в природе задачи. Код можно изолировать в закрытом контуре, где он создается, проверяется и много раз тестируется. Значительную часть этих процессов можно отдать ИИ-агентам, выстроив процесс с точечным участием человека, и обеспечить хорошее качество даже для больших объемов кода. Это сравнительно дешево и безопасно, потому что до реального мира код доходит только после всех проверок.
ИТ-инфраструктура, наоборот, и есть зона соприкосновения с реальным миром. Никто не держит ее полный аналог в тестовом окружении, это слишком дорого. Но главное даже не это. Актуальное состояние инфраструктуры нигде полностью не описано. Есть масса противоречивых и неполных данных в десятках систем, а часть знаний вообще существует только в головах инженеров. Единого источника правды нет. И вот этот контекст в агента никак не поместить. Во-первых, он слишком большой и разнородный: даже попытка «прочитать» всю инфраструктуру потребует существенного расхода токенов. Во-вторых, работает старое правило «мусор на входе — мусор на выходе»: если агенту дать противоречивые данные из разных систем, он не восстановит из них истину, а уверенно выдаст ответ, в котором не учтено то, чего в данных не было. Для генерации кода это еще терпимо, ошибка отловится на тестах. Для инфраструктуры это означает, что агент может что-то сломать, только прикоснувшись, и обнаружится это уже на пользователях.
Это подтверждает и рынок в целом. По оценке Strategy Partners, ИИ внедряют 97% российских компаний, но до промышленной эксплуатации довели меньше 15%. Gartner ждет, что больше 40% проектов с ИИ-агентами будут свернуты к 2027 году из-за незрелого управления и растущих затрат. Технология готова, а данные и процессы под нее нет.
Поэтому узкое место сегодня не в модели, а в контексте. Пока у компании нет достоверного, целостного описания инфраструктуры, ответственность за нее нельзя передать агенту, и человеческого участия в эксплуатации приходится держать даже больше, чем хотелось бы. Чтобы инфраструктура догнала разработку, нужно сначала построить для агентов тот контекст, которого сейчас нет ни у них, ни у людей.
У крупных компаний уже есть CMDB, DCIM, системы мониторинга, observability-платформы, средства автоматизации и управления конфигурациями. Почему этого набора может оказаться недостаточно?
Василий Александров: Потому что проблема не в наборе. Каждая из этих систем хорошо делает свою работу и хранит знания своей предметной области: CMDB знает, что есть, мониторинг знает, что происходит, система управления конфигурациями знает, как должно быть настроено. Причем даже внутри одного домена система часто не одна: в крупной компании нередко живут несколько CMDB и несколько платформ наблюдаемости, доставшихся от разных команд и разных эпох.
Источник: TAdviser · Оригинал статьи: Василий Александров, «Прегель»: Управление инфраструктурой перестало быть человекосоразмерной задачей
