Еще несколько лет назад ответ на этот вопрос не вызывал сомнений, все понимали, что инфраструктурой управляют люди. Администраторы, инженеры и DevOps-команды сами подключались к серверам, вносили изменения, настраивали сервисы и разбирались со сбоями. Каждый опирался на свой опыт и понимание системы.
Затем началась эпоха автоматизации: скрипты, сценарии, пайплайны, которые вынесли значительную часть операций из ручного режима в код. Изменения стали выполняться быстрее, появилась воспроизводимость, снизилась зависимость от конкретных специалистов. На этом этапе казалось, что вопрос управления инфраструктурой закрыт, просто теперь им занимается не человек напрямую, а код.
Однако к 2026 году стало очевидно, что ни человек, ни пайплайн по отдельности уже не справляются с этой задачей. Причина не в недостатке инструментов, а в том, что сама инфраструктура стала слишком сложной, динамичной и распределенной, чтобы управлять ею по-старому.
Когда автоматизация перестает означать управляемость
Сегодня в большинстве компаний автоматизация так или иначе уже внедрена: используют Terraform, Ansible или собственные внутренние инструменты. Кстати, Ansible остается самой распространенной технологией автоматизации как в мире, так и в России, что подтверждается в исследовании State of DevOps Russia от 2025 года и во многом объясняется его простотой, agentless-подходом и огромной экосистемой готовых модулей.
Но наличие автоматизации не означает, что инфраструктура действительно находится под контролем. На практике часто складывается другая картина. Появляются десятки репозиториев и сотни сценариев, а разные команды решают задачи настройки и поддержки по собственному усмотрению. Один и тот же сервер может быть приведен к нужному состоянию разными способами, и итоговая конфигурация зависит от того, какой сценарий запускался последним и в каком контексте.
В результате автоматизация начинает играть двойственную роль. С одной стороны, она ускоряет изменения и упрощает масштабирование, а с другой, без единой модели управления она усиливает вариативность и усложняет понимание того, что происходит в системе прямо сейчас.
Почему пайплайны не становятся системой управления
Логичным шагом стало внедрение пайплайнов. Изменения начали проходить через CI/CD, появились этапы проверки, согласования и контроль версий. Это действительно повысило дисциплину и снизило количество хаотичных правок, но не решило ключевую проблему.
Пайплайн отвечает на вопросы о том, как выполнить изменение и в каком порядке его применить. При этом он почти не дает ответа на то, каким должно быть состояние инфраструктуры в любой момент времени и соответствует ли оно заданным требованиям.
Если изменения были внесены вне пайплайна, система может об этом даже не узнать. Если конфигурация постепенно начинает расходиться с эталоном, это не всегда фиксируется автоматически. Пайплайн управляет процессом доставки изменений, но не управляет самим состоянием инфраструктуры и не обеспечивает его постоянное соответствие целевой модели.
Политики как новый уровень управления
Именно здесь появляется третий уровень, который постепенно выходит на первый план. Речь идет об управлении через политики. В данном контексте политика представляет собой не регламент и не документ, а формализованное правило, которое система способна применять автоматически и без участия человека.
Это уже не просто рекомендации вроде «желательно настроить аудит» или «нужно использовать определенные параметры безопасности». Политика задает строгие правила, по которым на всех серверах обязан работать аудит, доступы должны соответствовать заданной модели, а конфигурация — всегда быть в определенном состоянии. Если возникает любое отклонение, система должна самостоятельно его обнаружить и исправить.
Такая постановка задачи принципиально меняет подход. Вместо того чтобы пытаться контролировать каждое изменение вручную или через процессы, компания задает целевое состояние и обеспечивает его соблюдение на уровне системы.
Роль Ansible и эволюция подхода к автоматизации
В этом контексте привычные инструменты автоматизации начинают использоваться иначе. Ansible, который долгое время воспринимался как удобный способ выполнения сценариев настройки, становится основой для описания целевого состояния инфраструктуры и механизма его поддержания.
Playbook в таком подходе используется не только для первоначальной настройки, но и как средство регулярной проверки и приведения системы к нужному состоянию. Однако сам по себе сценарий не решает задачу управления. Его необходимо встроить в систему, которая понимает, когда и зачем этот сценарий должен запускаться.
Необходима надстройка, которая объединяет несколько ключевых функций: хранение и управление политиками, понимание текущего состояния инфраструктуры, автоматический запуск сценариев и, что особенно важно, реакцию на события в реальном времени.
Событийная модель: от реакции к управлению
Инфраструктура по своей природе событийна. В ней постоянно создаются новые виртуальные машины, изменяются настройки, обновляются пакеты и появляются новые зависимости. В традиционной модели такие события либо обрабатываются вручную, либо учитываются с задержкой, например, при плановых проверках.
Более зрелый подход предполагает, что каждое событие становится триггером для автоматической реакции. Если появляется новый сервер, к нему автоматически применяются базовые политики конфигурации и безопасности. Если в системе происходит изменение, которое может повлиять на стабильность или соответствие требованиям, система сразу проверяет его и при необходимости запускает корректирующие действия.
Таким образом, управление перестает быть реактивным и становится непрерывным. Теперь инфраструктура постоянно поддерживается в целевом состоянии без необходимости ручного вмешательства в каждом отдельном случае.
Как меняется роль человека
На этом этапе меняется и роль инженера. Если раньше он был непосредственным исполнителем изменений, то теперь его задача смещается в сторону определения правил и логики работы системы.
DevOps-инженер или архитектор больше не должны подключаться к каждому серверу, чтобы исправить конфигурацию. Их задача – описать, каким должно быть состояние инфраструктуры, задать политики и определить, как система должна реагировать на те или иные события.
Пайплайны при этом остаются важной частью процесса и обеспечивают доставку изменений, интеграцию с разработкой, контроль версий. Но они перестают быть единственным инструментом управления, уступая эту роль системе, которая обеспечивает соблюдение заданных правил.
Новая реальность управления инфраструктурой
Особенно отчетливо этот переход заметен в крупных и гибридных инфраструктурах, где одновременно используются облачные сервисы, собственные дата-центры и различные платформенные решения. В таких условиях полагаться только на дисциплину команд или регламенты уже невозможно, т. к. слишком много участников, слишком высокая скорость изменений, слишком велик риск отклонений.
Без централизованной модели управления и автоматического контроля соответствия инфраструктура начинает терять предсказуемость, а любые изменения могут приводить к цепочке непредвиденных последствий.
Поэтому ответ на вопрос о том, кто управляет инфраструктурой, сегодня выглядит иначе. Человек определяет правила и архитектуру. Пайплайн обеспечивает внедрение изменений. Но реальное управление берет на себя система, которая контролирует состояние инфраструктуры, применяет политики и автоматически реагирует на отклонения.
И именно способность выстроить такую систему становится ключевым фактором устойчивости и управляемости в современных ИТ-ландшафтах.