В два часа ночи инфраструктура выглядит совсем не так, как на архитектурных диаграммах, которые любят показывать на внутренних демо и квартальных встречах. На схемах всё красиво и упорядоченно: Kubernetes-кластеры выстроены ровными прямоугольниками, CI/CD-пайплайны текут по аккуратным стрелкам, системы наблюдаемости заботливо собирают телеметрию, а процессы реагирования на инциденты расписаны настолько подробно, что остаётся лишь следовать инструкции. Реальность, как обычно, значительно менее фотогенична. Дежурный инженер открывает ноутбук, пытается одной рукой удержать кружку с давно остывшим кофе, а другой переключается между Prometheus, Grafana, терминалом, журналами приложений, корпоративным чатом и GitLab. Вкладок открыто столько, что даже браузер начинает вести себя как пассивно-агрессивный коллега, намекающий, что человеку давно пора спать.
Если повезёт, проблема окажется банальной. Кто-то допустил ошибку в конфигурации. Закончилось место на диске. Очередное обновление принесло несовместимость библиотек, которую никто не заметил на тестовом стенде. Если не повезёт, впереди несколько часов расследования, десятки гипотез и неприятное ощущение, что система ведёт себя неправильно, но почему именно - пока не понимает никто.
Именно поэтому происходящее сегодня вокруг искусственного интеллекта выглядит гораздо важнее очередной технологической моды. Впервые за долгое время в профессию приходит не новый инструмент, не очередной формат описания инфраструктуры и не ещё одна система автоматизации.
Рядом с инженером появляется цифровой исполнитель.
DevOps уже пережил десятки технологических революций. Но впервые мы наблюдаем появление не нового инструмента, а нового участника процесса.
Самое любопытное заключается в том, что индустрия почти не заметила этот момент перехода. Он не сопровождался громкими анонсами, обязательными сертификациями и многомесячными миграциями. Просто однажды системы, которые вчера умели отвечать на вопросы, начали самостоятельно выполнять часть работы. И именно тогда разговор о возможностях искусственного интеллекта превратился в разговор о будущем самой профессии.
Пятнадцать лет мы сами готовили для этого почву
Если посмотреть на историю DevOps без привычной романтики, окажется, что она представляет собой историю постепенного отказа от ручного труда. Когда-то автоматизация выглядела как набор Bash-скриптов, которые писал один особенно инициативный инженер. Потом этих скриптов становилось столько, что разобраться в них мог только автор, уже забывший, зачем половина конструкций вообще появилась в проекте. Затем пришёл Ansible и предложил описывать действия декларативно. Terraform позволил описывать инфраструктуру как код. Kubernetes взял на себя управление жизненным циклом приложений. GitOps предложил хранить желаемое состояние системы в Git и автоматически приводить реальность в соответствие с репозиторием.
Каждый раз происходило одно и то же. Мы передавали машинам часть повторяющейся работы. Освобождали время. Поднимались на новую ступень абстракции. А потом обнаруживали, что вместо старых проблем появляются новые, более сложные задачи.
При этом каждую такую трансформацию сопровождали разговоры о смерти профессии. Облачные платформы якобы должны были уничтожить системных администраторов. Kubernetes обещал сделать ненужными классические эксплуатационные команды. Platform Engineering предсказывали роль могильщика DevOps. Теперь аналогичные прогнозы звучат в отношении искусственного интеллекта.
Реальность, как обычно, оказалась значительно интереснее.
Агентный ИИ стал возможен не потому, что появились большие языковые модели. Он стал возможен потому, что DevOps десятилетиями превращал хаос в воспроизводимые процессы.
Мы стандартизировали собственную работу. Научились хранить изменения в Git. Привыкли к тому, что любое действие оставляет цифровой след. Построили наблюдаемость, способную рассказать о системе больше, чем иногда знают её создатели. И неожиданно обнаружили, что значительная часть инженерной деятельности представляет собой последовательность хорошо формализуемых операций.
Мы сами подготовили среду, в которой цифровые исполнители чувствуют себя удивительно комфортно.
Продолжим в следующей части: поговорим о том, почему агент принципиально отличается от обычной автоматизации и в какой момент "удобный помощник" превращается в коллегу, способного самостоятельно выполнять работу внутри SDLC.
Когда помощник превращается в исполнителя
Наверное, самое большое заблуждение вокруг агентного ИИ заключается в том, что многие до сих пор воспринимают его как слегка улучшенную версию поисковой строки. Такой подход был справедлив ещё совсем недавно. Мы задавали вопрос, получали ответ, копировали предложенный фрагмент кода, немного его правили и шли дальше заниматься своими делами. Даже первые массовые помощники для разработчиков выглядели именно так: очень быстрый коллега, который никогда не устаёт объяснять синтаксис регулярных выражений и способен за несколько секунд набросать Dockerfile.
Но между помощником и агентом существует принципиальная разница.
Помощник отвечает на вопрос.
Агент пытается достичь цели.
На первый взгляд различие кажется скорее философским, чем практическим. Однако именно оно меняет правила игры. Представьте инженера, которому говорят: "У нас перестал проходить пайплайн". Помощник объяснит возможные причины ошибки, предложит варианты исправлений и поможет интерпретировать сообщения об ошибках. Агент поступит иначе. Он изучит журналы выполнения, проверит недавние изменения, сопоставит их с историей аналогичных инцидентов, подготовит исправление, откроет merge request и, возможно, даже инициирует повторный запуск проверок.
Это уже не диалог.
Это поведение.
Именно поэтому мне кажется опасным привычное сравнение агентных систем с "очень умным поиском". Оно успокаивает. Создаёт ощущение, будто речь идёт всего лишь об очередном инструменте повышения продуктивности. На самом деле мы постепенно сталкиваемся с новой сущностью внутри SDLC - цифровым исполнителем, который способен не только рассуждать, но и действовать.
Я впервые по-настоящему ощутил это различие после разговора с коллегой из крупной продуктовой компании. Они экспериментировали с внутренним агентом, которому поручили довольно приземлённую задачу: анализировать неудачно завершившиеся пайплайны GitLab. Первые результаты никого особенно не впечатлили. Система собирала журналы, выделяла вероятные причины ошибок и формировала краткое описание проблемы. Удобно, но не революционно.
Через некоторое время агент научился готовить исправления.
Потом начал создавать merge request.
Затем стал автоматически запускать проверки в тестовых окружениях, если уровень уверенности превышал заранее установленный порог.
И именно тогда в команде возникло странное ощущение. Люди перестали обсуждать качество подсказок. Они начали обсуждать степень доверия.
Можно ли позволить агенту создавать изменения?
Стоит ли разрешать ему инициировать проверки?
А если исправление затрагивает критический сервис?
А если он ошибётся?
Самый интересный момент заключается в том, что подобные вопросы никогда не возникали в отношении Terraform, Ansible или GitOps. Никто не спрашивал, можно ли доверять Terraform принимать решения. Потому что Terraform решений не принимал. Он был исполнителем чужой воли. Вся ответственность за описание желаемого состояния лежала на человеке.
Теперь ситуация меняется.
Мы впервые начинаем обсуждать не надёжность инструмента, а степень самостоятельности цифрового участника процесса.
Автоматизация всегда отвечала на вопрос "как сделать". Агентный ИИ впервые начинает участвовать в выборе "что делать дальше".
Именно это вызывает у опытных инженеров одновременно интерес и внутреннее сопротивление. Дело не в страхе потерять работу. За последние двадцать лет ИТ-индустрия пережила столько "убийц профессий", что подобные прогнозы давно перестали производить впечатление. Скорее возникает профессиональный дискомфорт. Мы привыкли мыслить категориями предсказуемости. Хорошая автоматизация должна вести себя одинаково при одинаковых условиях. Она должна быть детерминированной. Воспроизводимой. Понятной.
Агентные системы устроены иначе.
Они работают с вероятностями.
Выбирают наиболее подходящий сценарий из нескольких возможных.
Уточняют гипотезы.
Корректируют собственные действия по мере появления новой информации.
Иными словами, они начинают вести себя не как скрипт.
Они начинают вести себя как младший инженер.
Это сравнение может показаться провокационным, но чем дольше наблюдаешь за развитием агентных систем, тем чаще оно приходит в голову. Хороший junior не обладает глубоким опытом. Он способен ошибаться. Иногда делает неожиданные выводы. Иногда действует излишне уверенно. Но он умеет работать с инструментами, задавать вопросы, собирать информацию и постепенно двигаться к поставленной цели.
Разумеется, у такого "цифрового коллеги" отсутствует множество качеств, которые мы считаем неотъемлемой частью профессиональной зрелости. У него нет воспоминаний о неудачных миграциях. Он не знает, что такое объяснять бизнесу последствия аварии. Он не чувствует тяжести решений, принятых в условиях дефицита времени и информации. Но отрицать сам факт появления нового типа исполнителя становится всё сложнее.
Именно поэтому, на мой взгляд, главный вопрос ближайших лет будет звучать не так:
Заменит ли ИИ DevOps-инженеров?
А значительно неприятнее:
Какие именно части нашей работы существуют только потому, что раньше их невозможно было делегировать машине?
Ответ на этот вопрос может оказаться довольно болезненным для всей отрасли. Потому что очень большая часть нашей повседневной деятельности состоит вовсе не из архитектурных озарений и героического спасения продакшена. Она состоит из последовательностей действий, которые десятилетиями выполнялись людьми исключительно потому, что никто другой не умел этого делать.
И если машины постепенно научатся брать эти последовательности на себя, нам придётся заново определить, где именно заканчивается автоматизация и начинается профессия.
Когда данных становится слишком много, а внимания - слишком мало
Если попытаться найти область, в которой агентные системы получили наиболее очевидное преимущество, то это будет вовсе не генерация кода. Не написание Dockerfile. Не подготовка Terraform-модулей. И даже не создание merge request.
Этой областью стала диагностика.
Возможно, это прозвучит неожиданно. Всё-таки публичный образ искусственного интеллекта до сих пор строится вокруг умения писать тексты и отвечать на вопросы. Но любой человек, который хотя бы несколько лет проработал в эксплуатации, знает простую истину: основная проблема современных инфраструктур заключается вовсе не в недостатке информации.
Проблема заключается в её избытке.
Когда-то мы отчаянно мечтали о наблюдаемости. Нам не хватало данных. Инженеры подключались к серверам по SSH и пытались по косвенным признакам понять, что именно происходит внутри системы. Потом появились централизованные журналы. Затем метрики. После этого - распределённые трассировки. Позже добавились события Kubernetes, аудит, телеметрия приложений, бизнес-показатели и десятки специализированных источников информации.
Мы получили именно то, о чём мечтали.
И очень быстро выяснилось, что человек физически не способен эффективно использовать весь этот объём данных.
Я однажды участвовал в расследовании инцидента, который до сих пор вспоминаю как один из самых показательных примеров современного DevOps. Пользователи начали жаловаться на нестабильную работу сервиса. Внешне всё выглядело почти нормально. Ошибки возникали редко. Средние значения задержек не выходили за пределы допустимых значений. Нагрузочное тестирование подобных проблем не показывало.
Команда начала привычный ритуал.
Сначала посмотрели Grafana.
Потом открыли Prometheus.
Изучили события Kubernetes.
Проверили ingress-контроллеры.
Начали анализировать трассировки.
Посмотрели недавние релизы.
Подняли журналы приложений.
Сравнили версии зависимостей.
Подключили разработчиков.
Спустя несколько часов выяснилось, что причиной стала утечка памяти, проявлявшаяся только при редком сочетании определённых пользовательских сценариев. Контейнер постепенно потреблял всё больше ресурсов, попадал под действие OOM Killer, перезапускался, некоторое время работал нормально, а затем цикл повторялся снова.
Когда всё закончилось, один из инженеров устало произнёс:
Забавно. Все данные у нас были уже через десять минут после начала расследования. Мы просто не смогли собрать их в единую картину.
Именно эта фраза, как мне кажется, лучше всего объясняет потенциал агентных систем.
Мы научились собирать практически всё. Дефицитом стало не количество данных, а человеческое внимание.
Это довольно неприятное осознание для профессии, которая долгое время воспринимала себя как область глубокого технического анализа. Нам хочется думать, что самые сложные инциденты требуют исключительно выдающейся инженерной интуиции. Иногда это действительно так. Но значительно чаще проблема заключается в необходимости удерживать в голове слишком много взаимосвязанных сигналов одновременно.
Человек в подобных условиях начинает упрощать картину мира.
Он формирует гипотезу и ищет подтверждения.
Отбрасывает часть информации как нерелевантную.
Устаёт.
Переключает контекст.
Совершает когнитивные ошибки.
И это совершенно нормально.
Мы не проектировались как системы обработки распределённой телеметрии.
Агенты же, напротив, чувствуют себя в подобной среде удивительно уверенно. Для них нет принципиальной разницы между анализом нескольких журналов и нескольких тысяч событий. Они не испытывают раздражения, открывая сотую запись аудита Kubernetes. Не теряют концентрацию после третьего часа расследования. Не начинают мысленно цепляться за первую правдоподобную гипотезу просто потому, что очень хочется наконец закончить инцидент.
Конечно, это не означает, что они всегда делают правильные выводы.
И здесь важно не впадать в противоположную крайность.
Я уже видел демонстрации, в которых поставщики AIOps-платформ обещали автоматическое определение первопричин практически любых проблем. Обычно подобные презентации сопровождались идеально подобранными сценариями и красивыми дашбордами. В реальной жизни всё оказывалось значительно сложнее. Система действительно находила интересные корреляции, но иногда уверенно указывала совершенно не туда. И если команда слепо доверяла этим выводам, расследование затягивалось ещё сильнее.
На инфраструктурном кладбище технологий уже достаточно подобных историй. Там покоятся системы, обещавшие автоматически устранять любые инциденты, магические платформы "самовосстанавливающейся инфраструктуры" и аналитические движки, которые должны были заменить инженеров первой линии поддержки. Большинство из них не выдержало столкновения с хаотичной и противоречивой реальностью настоящего бизнеса.
Поэтому здоровый скептицизм здесь не просто допустим.
Он необходим.
Но было бы ошибкой не замечать и другую сторону происходящего. Даже если агент ошибается в половине сложных расследований, оставшаяся половина может экономить часы человеческого времени. Даже если его гипотезы требуют обязательной проверки, они способны сократить пространство поиска. Даже если он не умеет находить истинную первопричину, он может взять на себя самую утомительную часть работы - сбор и первичную обработку информации.
Если честно, я подозреваю, что именно здесь произойдут первые по-настоящему массовые изменения. Не в архитектуре. Не в генерации инфраструктурного кода. Не в полностью автономных релизах.
А в исчезновении той части работы, которую никто особенно не любил, но которая отнимала огромную долю времени и энергии.
Парадоксально, но искусственный интеллект может не сделать инженеров гениальнее.
Зато он вполне способен сделать их менее уставшими.
И, возможно, именно это окажется одним из самых недооценённых эффектов всей нынешней трансформации. Потому что значительная часть ошибок в эксплуатации происходит не из-за недостатка квалификации. Они происходят тогда, когда очень умные люди пытаются принимать сложные решения после нескольких часов непрерывного переключения между десятками источников информации.
А если это действительно так, то следующий большой вопрос уже не связан с возможностями агентов.
Он связан с доверием.
Потому что одно дело - позволить машине собрать журналы и предложить гипотезу.
И совсем другое - позволить ей действовать от нашего имени, когда цена ошибки измеряется не только временем инженеров, но и репутацией бизнеса.
Доверие - это то, чего нельзя автоматизировать
В какой-то момент разговор об агентном ИИ неизбежно перестаёт быть разговором о технологиях и превращается в разговор о доверии. Причём не о доверии в абстрактном смысле, которое любят обсуждать на конференциях, а о вполне приземлённом инженерном доверии, имеющем очень конкретную цену.
Можно ли позволить агенту открыть merge request?
Наверное, да.
Можно ли разрешить ему обновлять зависимости в тестовом окружении?
Скорее всего.
Можно ли доверить ему подготовку отчётов по инцидентам?
Почему нет.
А можно ли позволить ему самостоятельно выполнять rollback критически важного сервиса в разгар рабочего дня?
Именно здесь разговор становится значительно менее комфортным.
Потому что впервые за долгое время мы обсуждаем не надёжность инструмента, а передачу права действовать от имени человека.
Если задуматься, инфраструктурная отрасль никогда раньше не сталкивалась с подобной дилеммой. Bash не принимал решений. Terraform не определял приоритеты. GitOps не выбирал между стабильностью и скоростью изменений. Все эти инструменты были продолжением инженерной воли. Они исполняли инструкции настолько точно, насколько им позволяли качество конфигураций и внимательность авторов.
Ответственность всегда имела конкретную фамилию.
Теперь всё становится сложнее.
Один мой знакомый, много лет отвечавший за эксплуатацию высоконагруженных систем, однажды сформулировал это очень просто:
Я не боюсь автоматизации. Я боюсь автоматизации, у которой нет воспоминаний о последствиях.
Мне кажется, это одна из самых точных характеристик текущего положения дел.
У опытных инженеров есть не только знания.
У них есть шрамы.
Есть миграция, после которой пришлось восстанавливать сервисы всю ночь.
Есть обновление, которое выглядело абсолютно безопасным, но неожиданно нарушило работу половины интеграций.
Есть резервные копии, которые однажды отказались восстанавливаться именно тогда, когда были нужны больше всего.
Есть разговор с руководством после инцидента, когда приходится объяснять, почему "почти невозможно" всё-таки произошло.
Все эти истории формируют профессиональную осторожность.
Именно поэтому зрелые инженеры так раздражают окружающих своими вопросами.
-
А откат мы проверяли?
-
А что будет, если внешний сервис недоступен?
-
Почему именно сейчас?
-
Кто будет дежурить во время изменений?
-
Как мы поймём, что ситуация ухудшается?
Со стороны это иногда выглядит как бюрократия или консерватизм.
На самом деле это накопленный опыт ошибок.
Профессиональная осторожность - это не страх изменений. Это память о стоимости предыдущих решений.
И здесь возникает фундаментальная проблема агентных систем.
Они не помнят последствий.
Можно сказать, что они знают о тысячах инцидентов. Но знание и опыт - не одно и то же. Агент способен прочитать постмортем, выделить основные причины и предложить корректирующие действия. Но он никогда не испытывал то неприятное чувство, когда понимаешь, что ошибка уже произошла, а пользователи продолжают сталкиваться с её последствиями.
Он не чувствовал тишину в переговорной комнате во время разбора серьёзного инцидента.
Не объяснял клиентам причины недоступности сервиса.
Не принимал решение между двумя одинаково плохими вариантами.
Можно возразить, что всё это эмоциональные категории и к инженерии они не имеют отношения. Но это будет неправдой.
Потому что инфраструктура давно перестала быть исключительно технической дисциплиной.
На одном из прошлых проектов мы обсуждали перенос критически важной системы на новую архитектуру. С технической точки зрения решение выглядело практически идеальным. Производительность выше. Поддержка проще. Стоимость эксплуатации ниже. Все проверки были пройдены. Архитектурный комитет одобрил инициативу.
И именно тогда один из самых спокойных инженеров в команде неожиданно сказал:
Я понимаю, что мы готовы технически. Но мне кажется, что организационно мы сейчас к этому не готовы.
Это вызвало раздражение.
Что значит "организационно"?
Как вообще измерить подобный риск?
Но если присмотреться внимательнее, его аргументы оказались вполне рациональными. Команда только что завершила тяжёлый проект. Несколько ключевых специалистов собирались в отпуск. Бизнес готовился к высокому сезону. Формально вероятность неудачи была минимальной. Но цена даже небольшого сбоя оказывалась непропорционально высокой.
Миграцию перенесли.
Спустя два месяца обнаружилась проблема совместимости, о которой поставщик платформы ещё не успел публично объявить.
Это не история о гениальной интуиции.
Это история о контексте.
О способности учитывать факторы, которые невозможно извлечь из логов, дашбордов и истории изменений.
Именно поэтому мне кажется, что ближайшие годы будут не эпохой полной автономии, а эпохой совместного принятия решений.
Агенты станут отличными аналитиками.
Прекрасными исполнителями.
Очень полезными помощниками.
Но человек останется последней инстанцией там, где приходится выбирать между скоростью и осторожностью, эффективностью и устойчивостью, технической правильностью и организационной зрелостью.
Возможно, именно поэтому наиболее удачной аналогией остаётся авиация.
Современный пассажирский самолёт умеет делать огромное количество вещей без участия пилота. Он способен удерживать курс, рассчитывать траектории, компенсировать внешние воздействия и выполнять действия, которые полвека назад считались вершиной человеческого мастерства.
Но с развитием автоматизации роль пилота не исчезла.
Она изменилась.
Он перестал быть исключительно оператором.
Он стал управляющим сложной системой, обязанным понимать не только то, как работает автоматика, но и когда ей не стоит доверять.
Чем совершеннее становится автоматизация, тем выше цена человеческой способности вовремя сказать: "Стоп. Давайте ещё раз подумаем".
Мне кажется, именно такой путь ждёт DevOps.
Не исчезновение.
Не триумфальное вытеснение людей агентами.
И не романтическое противостояние "человека и машины".
Нас ждёт значительно более сложный период, в котором придётся заново договариваться о границах доверия. Определять, какие решения можно делегировать. Где необходим второй взгляд. Какие действия требуют обязательного подтверждения. Как расследовать ошибки агентов и как проектировать системы таким образом, чтобы последствия их промахов оставались управляемыми.
И, если честно, именно эта работа кажется мне гораздо интереснее бесконечных дискуссий о том, сколько процентов кода сможет написать очередная модель.
Потому что код - это всего лишь инструмент.
А доверие всегда было и остаётся основой любой сложной инженерной системы.
Кто будет учить новых инженеров, если рутину заберут агенты
Есть ещё одна проблема, о которой пока говорят удивительно мало. Возможно, потому что на фоне дискуссий о производительности, автоматизации и сокращении издержек она кажется слишком приземлённой. Но если попытаться посмотреть на происходящее не глазами поставщика технологий, а глазами руководителя инфраструктурной команды, вопрос оказывается крайне неприятным.
Как вообще будут появляться новые senior-инженеры в мире, где большую часть рутины выполняют агенты?
Профессия DevOps, как и любая инженерная профессия, никогда не формировалась исключительно через чтение документации и прохождение курсов. Опыт накапливался через огромное количество повторяющихся действий. Ты обновлял системы. Настраивал пайплайны. Искал причины падения контейнеров. Разбирался с неудачными деплоями. Писал не самые элегантные Bash-скрипты, которые потом сам же и переписывал спустя полгода, удивляясь собственным архитектурным решениям.
Именно через эту рутину формировалась инженерная интуиция.
Она не появлялась мгновенно.
Не передавалась через презентации.
Не возникала после прочтения книги "Kubernetes за 24 часа".
Она медленно складывалась из десятков маленьких ошибок, неудачных предположений и ситуаций, когда приходилось признавать: "Я был уверен, что понимаю систему, а оказалось - нет".
Я до сих пор помню своего первого серьёзного инцидента. Сейчас он кажется почти анекдотичным. Тогда же это выглядело как катастрофа локального масштаба. Мы внесли изменение, которое казалось абсолютно безопасным. Все проверки были пройдены. План отката существовал. Мониторинг работал.
А потом оказалось, что никто не проверял один старый интеграционный сценарий, которым пользовались всего несколько клиентов.
Изменение пришлось откатывать.
Ночь закончилась плохо.
Утро началось ещё хуже.
Но именно после таких историй начинаешь иначе относиться к словам "небольшое изменение" и "минимальные риски".
Никакая книга не научила меня этому так эффективно.
Инженерная зрелость возникает не в момент, когда человек впервые всё делает правильно. Она возникает после того, как он понимает цену собственных ошибок.
И вот здесь агентный ИИ ставит перед отраслью очень неудобный вопрос.
Если агент собирает журналы, анализирует инциденты, предлагает исправления, обновляет зависимости и формирует документацию, где именно новый специалист будет получать свой первый опыт?
Через какие задачи он пройдёт путь от человека, который знает инструменты, до человека, который понимает последствия?
Проблема заключается в том, что обучение через наблюдение работает значительно хуже обучения через участие. Можно прочитать сотню постмортемов и выучить все классические ошибки эксплуатации. Но это совсем не то же самое, что лично принимать решение в условиях нехватки времени и информации, а потом жить с его результатами.
Мне кажется, именно поэтому в ближайшие годы нам придётся переосмыслить сам подход к развитию инженеров.
Сегодня многие компании уже сталкиваются с парадоксальной ситуацией. Они хотят нанимать опытных специалистов, но при этом всё меньше готовы инвестировать в выращивание собственной экспертизы. Бизнесу нужен senior-инженер с пятилетним опытом работы с конкретным стеком технологий. Желательно вчера. Желательно за разумные деньги. При этом путь, который раньше позволял людям постепенно становиться такими специалистами, начинает исчезать под натиском автоматизации.
Раньше младший инженер мог неделями сопровождать релизы и учиться на типовых инцидентах.
Теперь часть этих задач будет выполнять агент.
Раньше молодой специалист вручную разбирал журналы и искал закономерности.
Теперь ему предложат готовые гипотезы.
Раньше он самостоятельно готовил обновления.
Теперь merge request создаётся автоматически.
С точки зрения эффективности это прекрасно.
С точки зрения формирования профессионального опыта всё становится значительно сложнее.
Я подозреваю, что через несколько лет зрелые компании начнут сознательно проектировать образовательную среду внутри инфраструктурных команд. Почти так же, как это делают в авиации. Современные пилоты редко сталкиваются с критическими отказами в реальных полётах. Но они регулярно проходят тренировки на тренажёрах, где воспроизводятся самые неприятные сценарии.
Не потому, что автоматика плохая.
А потому, что однажды она может перестать справляться.
Возможно, нас ждёт появление внутренних инженерных "полигонов", где специалисты будут учиться расследовать инциденты без помощи агентов. Проходить симуляции отказов. Выполнять упражнения по аварийному восстановлению. Разбирать нестандартные ситуации, в которых привычные рекомендации интеллектуальных систем оказываются бесполезными.
И, если честно, мне кажется, что подобные практики давно были нам нужны независимо от появления ИИ.
Потому что инфраструктурная отрасль слишком долго романтизировала героизм и слишком мало инвестировала в подготовку к реальным кризисам.
Сколько компаний действительно проверяют процедуры восстановления?
Сколько регулярно моделируют отказ облачного региона?
Сколько обучают инженеров действиям в условиях частичной недоступности систем?
Ответы на эти вопросы обычно оказываются гораздо менее вдохновляющими, чем хотелось бы.
Агентный ИИ лишь делает существующую проблему более заметной.
Он не создаёт риск потери инженерной глубины.
Он усиливает тенденцию, которая существовала задолго до появления больших языковых моделей.
Каждое новое поколение инженеров наследует не только лучшие практики предыдущего поколения, но и его слепые зоны. Когда-то системные администраторы плохо понимали распределённые системы. Потом специалисты по облакам перестали глубоко разбираться в физической инфраструктуре. Затем инженеры Kubernetes начали терять понимание сетевых механизмов нижних уровней.
Теперь есть риск появления специалистов, которые великолепно умеют работать вместе с агентами, но испытывают серьёзные затруднения, когда приходится действовать самостоятельно.
И вот это, на мой взгляд, одна из самых недооценённых угроз ближайших лет.
Не потому, что она приведёт к исчезновению профессии.
А потому, что она способна изменить сам механизм передачи инженерного опыта.
И если мы не научимся выращивать специалистов в новой реальности, то однажды можем обнаружить удивительно эффективные инфраструктурные команды, окружённые армией цифровых помощников, но испытывающие острый дефицит людей, способных взять управление на себя именно в тот момент, когда все привычные механизмы перестают работать.
И тогда выяснится, что самый ценный ресурс эпохи агентного ИИ - вовсе не вычислительные мощности и не размер контекстного окна модели.
Самым дефицитным ресурсом останется человек, который уже однажды ошибался, пережил последствия своих решений и поэтому умеет сохранять спокойствие, когда готовых ответов больше не существует.
Кто будет управлять самими агентами
Есть одна ирония, которую инфраструктурная отрасль повторяет с завидной регулярностью. Мы создаём автоматизацию, чтобы избавиться от ручной работы, а затем обнаруживаем, что появилась совершенно новая категория задач, связанная уже с управлением самой автоматизацией.
История DevOps буквально состоит из подобных циклов.
Когда появились виртуальные машины, многие искренне верили, что проблемы эксплуатации останутся в прошлом. Больше не нужно будет ждать поставки серверов, согласовывать замену оборудования и переживать из-за очередного отказавшего диска. Вместо этого возникли целые команды, отвечающие за платформы виртуализации.
Когда пришёл Kubernetes, нам обещали упрощение эксплуатации распределённых приложений. Отчасти это оказалось правдой. Но одновременно родилась новая дисциплина, внутри которой появились специалисты по платформам, сетям контейнеров, безопасности кластеров и внутренним сервисам для разработчиков.
Теперь агентный ИИ обещает избавить нас от рутинной интеллектуальной работы.
И я почти уверен, что через несколько лет мы будем строить платформы уже не только для людей.
Мы будем строить платформы для агентов.
Сейчас это звучит немного абсурдно. Но давайте посмотрим на ситуацию без футуристического восторга.
Представим среднюю крупную компанию через несколько лет. Внутри неё работают несколько десятков специализированных агентов. Один анализирует инциденты и помогает дежурным инженерам быстрее находить вероятные причины сбоев. Другой следит за обновлениями зависимостей и регулярно предлагает изменения. Третий проверяет инфраструктурный код на соответствие политикам безопасности. Четвёртый помогает платформенной команде поддерживать внутреннюю документацию. Пятый занимается анализом затрат в облаке и предлагает варианты оптимизации.
В какой-то момент возникает очень простой вопрос.
А кто будет управлять всем этим хозяйством?
Кто определит, какие действия агент вообще имеет право выполнять?
Кто будет выдавать ему доступ к Kubernetes?
Кто согласует его полномочия в GitLab?
Кто решит, может ли он взаимодействовать с Vault?
Кто будет расследовать ошибки агента, если его действия привели к инциденту?
Кто окажется ответственным перед бизнесом?
Пока отрасль предпочитает не слишком подробно обсуждать эти вопросы. Они плохо продаются. Намного приятнее демонстрировать красивые сценарии, в которых агент за несколько минут устраняет проблему, автоматически обновляет компоненты и аккуратно пишет отчёт для руководства.
Но любая зрелая эксплуатационная команда знает: самое сложное начинается не тогда, когда технология впервые заработала.
Самое сложное начинается после того, как её решили использовать в продакшене.
Инфраструктура взрослеет не в момент появления новой технологии. Она взрослеет тогда, когда приходится отвечать за последствия её ошибок.
Мне кажется весьма показательным, что многие организации сегодня не способны однозначно ответить даже на гораздо более простой вопрос:
Кто именно имеет доступ к production?
Какие операции требуют обязательного подтверждения?
Кто может изменять политики безопасности?
Каким образом расследуются нарушения процедур?
Если компания не умеет уверенно отвечать на подобные вопросы применительно к людям, ожидать зрелого управления агентами было бы несколько самонадеянно.
Именно поэтому в ближайшие годы нас, вероятно, ждёт появление новых ролей и новых процессов.
Причём сами названия этих ролей пока могут выглядеть немного комично.
AI Reliability Engineer.
Инженер по надёжности агентных систем.
Специалист по аудиту решений агентов.
Архитектор агентных платформ.
Ответственный за политики взаимодействия между людьми и цифровыми исполнителями.
Несколько лет назад подобные должности вызвали бы улыбку.
Но, если честно, точно такую же улыбку когда-то вызывали слова "Kubernetes Security Engineer" или "Platform Engineer".
История инфраструктуры любит превращать вчерашнюю экзотику в сегодняшнюю рутину.
Однако за всей этой новой терминологией скрывается очень старая идея.
Контроль.
Потому что агент, обладающий доступом к Git, Kubernetes, системам наблюдаемости, внутренней документации и корпоративным сервисам, фактически становится сверхпривилегированным участником инфраструктуры.
Причём участником, принимающим решения на основании вероятностной модели.
Если такой агент будет скомпрометирован, последствия могут оказаться впечатляющими даже по меркам современных инцидентов.
Я уже представляю себе постмортемы будущего.
"В 14:32 агент оптимизации затрат принял решение сократить количество узлов кластера, руководствуясь историческими данными о нагрузке. К сожалению, он не обладал информацией о запланированной маркетинговой кампании, из-за чего система столкнулась с дефицитом ресурсов."
Или:
"Система автоматического обновления библиотек корректно определила наличие критической уязвимости и применила исправление. Побочным эффектом оказалась несовместимость со старой версией внутреннего сервиса, существование которого не было отражено в документации."
Смешно?
Немного.
Правдоподобно?
К сожалению, очень.
На кладбище инфраструктурных технологий уже стоят памятники системам, которые должны были избавить людей от необходимости думать. Там лежат самописные CMDB, которыми никто не пользовался. Корпоративные ESB, превратившиеся в монолиты национального масштаба. Порталы самообслуживания, оказавшиеся сложнее самой инфраструктуры. "Умные" платформы автоматической оптимизации, которые сначала экономили бюджеты, а потом неожиданно начинали экономить доступность.
Нет никаких причин считать, что эпоха агентного ИИ окажется принципиально иной.
Часть экспериментов провалится.
Часть решений окажется переоценённой.
Некоторые подходы будут вспоминать с лёгким смущением и фразой:
Тогда это казалось хорошей идеей.
Но именно через подобные ошибки индустрия обычно и взрослеет.
Именно поэтому мне кажется, что будущее DevOps определяется вовсе не вопросом о том, сколько задач сможет выполнять агент.
Куда важнее другой вопрос.
Сумеем ли мы построить вокруг этих цифровых исполнителей такие же зрелые процессы управления, какие когда-то научились строить вокруг людей?
Потому что технологии почти всегда развиваются быстрее, чем организационная культура.
И если агентный ИИ действительно станет полноправным участником SDLC, то нам придётся учиться не только работать вместе с ним.
Нам придётся научиться им управлять.
А это, как показывает вся история инфраструктуры, обычно оказывается значительно сложнее, чем написать очередной YAML-манифест или подключить ещё один инструмент к пайплайну.
Что останется от DevOps, когда исчезнет привычный DevOps
Если попытаться посмотреть на всю эту историю со стороны, становится очевидно, что вопрос "заменит ли ИИ DevOps-инженеров?" изначально сформулирован неправильно. Он предполагает, что профессия представляет собой фиксированный набор обязанностей, который можно взять и передать другому исполнителю. Но если история инфраструктуры чему-то и учит, так это тому, что профессии в нашей отрасли никогда не стоят на месте.
За последние двадцать лет DevOps уже несколько раз успел умереть.
По крайней мере, если верить заголовкам отраслевых изданий.
Сначала облака должны были сделать ненужными системных администраторов. Затем контейнеризация обещала устранить половину эксплуатационных проблем. Потом Kubernetes якобы должен был превратить инфраструктуру в "невидимый слой". Позже Platform Engineering объявили естественным наследником DevOps, который окончательно вытеснит старые подходы.
Каждый раз происходило одно и то же.
Исчезали не профессии.
Исчезали отдельные способы создавать ценность.
Именно поэтому мне кажется, что главный эффект агентного ИИ проявится не в сокращении количества инженеров, а в изменении того, за что именно им будут платить.
Раньше ценность специалиста во многом определялась его способностью помнить огромное количество технических деталей. Как правильно настроить определённую систему. Какими параметрами запускается конкретный инструмент. Как выглядит нужный синтаксис. Какой флаг отвечает за ту или иную функцию.
Потом часть этой ценности забрала документация.
Затем поисковые системы.
Позже - Stack Overflow.
Сегодня эту роль постепенно начинают брать на себя агенты.
И это, если честно, не выглядит трагедией.
Я ни разу в жизни не встречал инженера, который искренне мечтал построить карьеру на способности помнить точный синтаксис редко используемой команды или расположение параметров внутри очередного YAML-файла. Мы просто привыкли считать подобные вещи частью профессии, потому что альтернативы не существовало.
Теперь она появилась.
Но одновременно начинают дорожать совсем другие качества.
Умение проектировать системы.
Способность видеть скрытые зависимости.
Понимание организационных ограничений.
Навык объяснять сложные технические решения людям, далёким от инфраструктуры.
Способность принимать решения в условиях неопределённости.
И, пожалуй, самое важное качество - готовность брать ответственность.
Чем дешевле становится исполнение, тем дороже становится способность определить, что вообще стоит исполнять.
Я всё чаще замечаю, что лучшие инженеры отличаются не количеством известных технологий и даже не глубиной технической экспертизы. Они отличаются качеством своих вопросов.
Почему мы делаем это именно сейчас?
Как изменится ситуация через полгода?
Что произойдёт, если наша гипотеза окажется ошибочной?
Какие последствия этого решения проявятся не завтра, а через год?
Какой риск мы готовы принять сознательно?
Именно эти вопросы очень редко имеют объективно правильные ответы.
Они требуют понимания бизнеса, культуры организации, политического контекста и человеческой психологии. Они требуют способности признать собственную неуверенность и готовности пересматривать первоначальные предположения.
Если говорить совсем честно, то именно здесь и начинается зрелая инженерия.
Не в терминале.
Не в Kubernetes.
Не в GitLab.
И даже не в искусственном интеллекте.
Я вспоминаю один разговор с техническим директором довольно крупной компании. Мы обсуждали архитектурные изменения, и в какой-то момент он сказал вещь, которая тогда показалась мне слишком простой.
Знаешь, мне кажется, что работа опытного инженера заключается в том, чтобы снижать количество неприятных сюрпризов.
Чем дольше я работаю, тем сильнее убеждаюсь, что он был прав.
Вся инфраструктура, все процессы, все инструменты и все бесконечные дискуссии о технологиях в конечном итоге сводятся именно к этому.
Сделать будущее чуть менее неожиданным.
Уменьшить вероятность катастрофы.
Помочь организации принимать разумные решения.
Снизить стоимость ошибок.
Именно поэтому агентный ИИ выглядит не концом профессии, а очередным изменением её точки приложения.
Мы постепенно перестаём быть людьми, которые вручную выполняют работу.
Затем перестаём быть людьми, которые пишут автоматизацию.
После этого превращаемся в людей, которые управляют автоматизацией.
Теперь мы начинаем становиться людьми, которые управляют исполнителями, обладающими ограниченной самостоятельностью.
Уровень абстракции снова повышается.
И вместе с ним растут требования к зрелости.
Это, кстати, довольно неприятный вывод.
Потому что значительно проще изучить новый инструмент, чем научиться принимать сложные решения. Проще получить сертификат по очередной платформе, чем развить способность спокойно спорить с руководством, объясняя, почему технически возможное решение сейчас принимать нельзя. Проще написать отличный Terraform-модуль, чем взять на себя ответственность за последствия архитектурного выбора.
Но именно эти качества, вероятно, и станут главным дефицитом ближайшего десятилетия.
Агентный ИИ не отменяет потребность в опытных инженерах. Он повышает требования к тому, что вообще считать опытом.
И если попытаться сформулировать главный вывод этой статьи, он будет звучать одновременно обнадёживающе и немного тревожно.
Искусственный интеллект действительно изменит DevOps сильнее, чем многие предыдущие технологические волны. Он избавит нас от огромного количества скучной работы. Возьмёт на себя часть диагностики. Поможет сопровождать инфраструктуру. Станет участником SDLC, а не просто удобным интерфейсом к поиску информации.
Но вместе с этим он заставит профессию наконец признаться самой себе, чем она была всегда.
DevOps никогда не был про Docker.
Никогда не был про Kubernetes.
Никогда не был про Terraform, GitOps или модные практики конкретного десятилетия.
В своей основе это всегда была дисциплина управления сложностью. Попытка построить такие процессы и такие системы, внутри которых люди могут принимать разумные решения, несмотря на постоянный рост масштаба, скорости изменений и количества взаимосвязей.
Именно поэтому я не думаю, что через десять лет мы будем вспоминать агентный ИИ как технологию, уничтожившую профессию.
Скорее всего, мы будем вспоминать его как момент, когда DevOps окончательно перестал быть набором инструментов и превратился в нечто гораздо более важное.
В профессию людей, которые умеют жить в мире, где часть работы выполняют машины, но последствия их решений по-прежнему остаются глубоко человеческими.
И, возможно, именно тогда в три часа ночи дежурный инженер действительно откроет ноутбук и увидит, что цифровой коллега уже собрал журналы, проверил метрики, подготовил гипотезы и сформировал план действий.
Он внимательно прочитает этот отчёт.
Сделает глоток остывшего кофе.
Поднимет взгляд на часы.
И задаст вопрос, который в инфраструктуре пережил уже не одну технологическую революцию:
А что будет, если мы всё-таки ошибаемся?
Последняя неудобная мысль: возможно, мы слишком долго неправильно понимали DevOps
Есть одна причина, по которой разговоры о скорой смерти DevOps вызывают у меня не тревогу, а лёгкую профессиональную усталость. Я слышу их почти столько же, сколько работаю в этой отрасли.
Сначала нам рассказывали, что автоматизация убьёт системное администрирование. Потом объясняли, что облака сделают ненужными инфраструктурные команды. Затем пришёл Kubernetes и пообещал превратить эксплуатацию в набор декларативных описаний. Позже появились платформенные команды, и кто-то объявил, что теперь разработчики будут обслуживать себя самостоятельно, а DevOps окончательно растворится в Platform Engineering.
Теперь на сцену вышел искусственный интеллект.
И снова звучат знакомые формулировки.
"Последние годы профессии."
"Массовая замена инженеров."
"Скоро останутся только архитекторы."
Если честно, всякий раз, когда я слышу подобные прогнозы, мне хочется открыть архив корпоративных презентаций десятилетней давности. Там можно найти огромное количество технологий, которые должны были радикально изменить отрасль. Какие-то действительно изменили её. Какие-то тихо отправились на инфраструктурное кладбище, где уже стоят аккуратными рядами системы управления конфигурациями, корпоративные сервисные шины, универсальные порталы самообслуживания и продукты, обещавшие решить все проблемы эксплуатации одним нажатием кнопки.
Но есть одна деталь, которая объединяет все эти истории.
Ни одна из технологий не устранила фундаментальную проблему.
Сложность продолжала расти.
Бизнес продолжал требовать большей скорости.
Количество зависимостей увеличивалось.
Стоимость ошибок возрастала.
И кому-то всё равно приходилось удерживать всю эту конструкцию от превращения в дорогостоящий хаос.
Возможно, именно здесь и скрывается главный самообман нашей профессии.
Мы слишком долго определяли себя через инструменты.
Был период, когда хорошим специалистом считался человек, великолепно разбирающийся в Linux.
Потом - тот, кто лучше остальных владел средствами автоматизации.
Затем - тот, кто глубже понимал Kubernetes.
Позже - специалист по платформам.
Теперь возникает соблазн определить ценность инженера через умение работать с агентным ИИ.
Но если убрать все модные названия и посмотреть на профессию со стороны, останется удивительно простая картина.
Все эти годы DevOps занимался одной и той же задачей.
Он помогал организациям принимать разумные решения внутри систем, которые становятся слишком сложными для одного человека.
Возможно, DevOps никогда не был профессией про инструменты. Возможно, это всегда была профессия про управление последствиями сложных решений.
Именно поэтому мне кажется, что агентный ИИ не столько разрушает привычную картину мира, сколько делает её честнее.
Он отнимает у нас возможность прятаться за инструментами.
Если машина способна написать Terraform-модуль быстрее человека, значит ценность специалиста была не в самом модуле.
Если агент способен подготовить корректный merge request, значит смысл работы заключался не в механическом внесении изменений.
Если интеллектуальная система умеет анализировать журналы и строить гипотезы, значит дело было не в способности открыть Grafana и выполнить несколько команд kubectl.
Тогда в чём же?
Ответ, как ни странно, может оказаться довольно неудобным.
Потому что он связан не с технологиями, а с личной зрелостью.
Со способностью признавать неопределённость.
С умением брать ответственность.
С готовностью принимать непопулярные решения.
Со способностью сказать руководству:
Нет, мы не будем делать это сегодня.
Даже если технически всё выглядит идеально.
Даже если сроки поджимают.
Даже если все вокруг уверены, что рисков нет.
Я несколько раз видел ситуации, когда именно такие решения спасали компании от серьёзных проблем. Причём выглядело это не особенно героически. Никто не бросался под поезд ради продакшена. Никто не проводил двадцатичасовые аварийные работы.
Просто кто-то вовремя сказал:
Давайте подождём ещё неделю.
У команды не хватает ресурса.
Мы не понимаем одно из последствий.
Есть факторы, которые невозможно оценить количественно.
Технически мы готовы.
Организационно - нет.
Удивительно, но именно такие моменты редко попадают в постмортемы и конференционные доклады. О них сложно рассказывать. Они не выглядят как подвиг.
Но именно в них чаще всего и проявляется профессиональная зрелость.
Вместо эпилога
Если бы меня попросили описать ближайшие десять лет DevOps одной фразой, я бы сказал так: нас ждёт эпоха сосуществования людей и цифровых исполнителей.
Мы будем спорить с агентами.
Учиться им доверять.
Разочаровываться в слишком смелых обещаниях.
Перестраивать процессы.
Создавать новые роли.
Выращивать новое поколение инженеров, которое будет считать интеллектуальных помощников такой же естественной частью инфраструктуры, какой для нас стали CI/CD и Kubernetes.
Часть экспериментов окажется неудачной.
Некоторые продукты исчезнут.
Какие-то подходы мы будем вспоминать с улыбкой и лёгким стыдом.
Где-то появятся новые инфраструктурные байки в духе:
-
Помнишь, как агент оптимизации затрат сократил мощности перед запуском крупнейшей рекламной кампании года?
-
А как бот обновления зависимостей в пятницу вечером внезапно решил, что несовместимость библиотек - это проблема будущего?
-
Или как агент безопасности чуть не остановил половину внутренних сервисов, потому что впервые за три года кто-то наконец решил навести порядок в правах доступа?
У инфраструктуры отличная память на подобные истории.
Но, скорее всего, спустя годы мы будем помнить не их.
Мы будем помнить другое.
Именно в эпоху агентного ИИ DevOps окончательно перестал быть набором инструментов и методик. Он перестал быть профессией людей, которые знают правильный синтаксис YAML и умеют быстро писать пайплайны.
Он стал профессией людей, которые помогают организациям жить внутри сложности, не теряя способности принимать разумные решения.
Людей, которые понимают цену компромиссов.
Людей, которые умеют задавать неудобные вопросы.
Людей, которые знают, что даже самые совершенные технологии не отменяют неопределённости.
И людей, которые готовы отвечать за последствия, когда правильного ответа не существует.
Агентный ИИ может стать самым значительным изменением в истории DevOps. Но если он чему-то и научит нашу профессию, так это простой мысли: зрелая инженерия начинается не в момент, когда машина научилась действовать самостоятельно. Она начинается в момент, когда человек понимает, почему именно сейчас ей не стоит позволять этого делать.
Возможно, именно поэтому я не испытываю страха перед будущим профессии.
Скорее любопытство.
Потому что через десять лет где-нибудь глубоко внутри очередного инцидента дежурный инженер действительно откроет ноутбук и увидит, что цифровой коллега уже собрал данные, подготовил гипотезы, сформировал план действий и даже набросал черновик постмортема.
Он прочитает этот отчёт.
Сделает глоток уже традиционно остывшего кофе.
Посмотрит на часы, показывающие что-то около трёх ночи.
И задаст вопрос, который пережил Bash, виртуализацию, облака, Kubernetes, GitOps и, вероятно, переживёт агентный ИИ:
Хорошо. А что именно мы упускаем из виду?
И, возможно, именно в этом вопросе и заключается настоящая профессия DevOps. Потому что технологии меняются удивительно быстро. А ответственность за сложные системы по-прежнему остаётся глубоко человеческой.