Codex CLI в DevOps: как автоматизация с ИИ экономит время администратора

ИИ в DevOps: как я перестал заниматься копипастой и начал реально экономить время

Приветствую, уважаемые читатели.

Давно не публиковал статьи на нашем ресурсе, но вот наконец появился действительно хороший повод. Хочу поделиться новым практическим опытом из мира ИТ и ИИ.

ИИ уже давно вошёл в нашу повседневную жизнь и помогает решать ежедневные задачи в самых разных направлениях. У меня сейчас много DevOps- и админских задач, и большую их часть я, конечно же, поручаю ChatGPT.

Хотя слово «поручаю» здесь, конечно, слишком громкое.

Когда ИИ вроде бы помогает, но на деле ты просто занимаешься копипастой

Думаю, у многих процесс выглядит примерно так же.

Поступает тикет от мониторинга или от пользователя. Идёшь расследовать инцидент на сервере. Находишь проблему, копируешь текст ошибки, вставляешь в ChatGPT, получаешь рекомендации. Дальше копируешь команды, выполняешь их на сервере, получаешь новую ошибку, снова копируешь её в чат — и всё повторяется по кругу.

Иногда таких итераций бывает под 30.

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

Что изменилось после появления Codex CLI

Через несколько месяцев такой работы появился Codex CLI — и всё стало выглядеть уже совсем иначе.

По сути, это тот же ChatGPT, только прямо в консоли, с возможностью выполнять те действия, которые раньше ты делал вручную сам. То есть больше не нужно копировать команды из браузера в терминал и обратно.

Codex CLI сам предлагает действия, сам их выполняет, сам анализирует результат, сам корректирует следующую попытку и снова пробует.

Именно на этом этапе ИИ начинает не просто «советовать», а реально экономить время.

Вопрос, который возникает сразу: а как же безопасность и полномочия?

У Codex CLI есть разные режимы запуска. По умолчанию он работает максимально осторожно и спрашивает подтверждение почти на всё. Причём не только на изменения, но даже на обычное чтение конфигов.

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

У меня для этого сделаны алиасы.

Полностью без вопросов:

alias cx='codex -s danger-full-access -a never'

С вопросами только в чувствительных случаях:

alias cxy='codex --dangerously-bypass-approvals-and-sandbox'

Важно понимать, что параметры у Codex CLI меняются довольно часто. Эти примеры актуальны на момент написания статьи для версии 5.4.

А как работать с удалёнными серверами?

С удалёнными машинами пока всё не так красиво, как хотелось бы. Решение, по сути, костыльное, но рабочее: Codex CLI выполняет команды через SSH и затем анализирует результат выполнения.

Например, это может выглядеть так:

ssh -i /Users/@username/.ssh/@key -p 22 @username@ 'nl -ba /opt/..../devops_orchestrator.sh | sed -n "1,120p"; echo ---; nl -ba /opt/..../devops_orchestrator.sh | sed -n "420,560p"'

Разумеется, тут постоянно всплывают нюансы с экранированием, кавычками и сложными командами. Иногда ему приходится подбирать правильный вариант по 3–5 попыток. Это тратит и токены, и время, и нервы.

Но даже в таком виде это уже работает.

Я очень рассчитываю, что со временем появится нормальная клиент-серверная схема: локальный Codex будет просто передавать задачи агентам на удалённых хостах по внутреннему протоколу.

Следующий шаг: как дать ИИ понимание всей инфраструктуры

Когда локальная работа налажена и доступ к удалённым машинам уже есть, возникает следующий вопрос: как дать Codex понимание всего парка серверов?

Я пришёл к тому, что нужно создать некое ядро инфраструктуры — каталог серверов. Это стартовая точка, от которой Codex отталкивается при каждой задаче.

Для каждого сервера я сделал отдельную папку с набором файлов:

• meta.md
• access.md
• os.md
• software.md
• configs.md
• network.md
• storage.md
• monitoring.md
• changes.md
• notes.md

Разбиение на множество файлов сделано специально. Так ИИ проще искать нужную информацию по контексту задачи.

Если ему нужно подключение — он идёт в access.md. Если нужна сеть — в network.md. Если нужны сервисы — в software.md.

Как я наполнял этот каталог

По каждому серверу процесс был примерно таким:

1. Добавить на сервер ключ для Codex.
2. Проверить вход по новому ключу.
3. Убедиться, что для нужной учётки есть NOPASSWD: в sudoers.
4. Дать Codex доступ и рассказать всё, что я сам знаю об этом сервере.
5. Попросить его собрать недостающую информацию и разложить её по нужным файлам.

То есть часть знаний он получает из моих пояснений, а часть — уже сам вытаскивает с сервера. При этом технические детали он раскладывает по профильным файлам, а бизнес-контекст и смысл системы — в notes.md.

Да, это заняло немало времени. Но в итоге я описал практически весь свой парк Linux-серверов, а потом и часть Windows-систем.

И это закрыло одну очень большую проблему: критически важные знания больше не находятся только в головах сотрудников.

Формально эту задачу всегда должна решать документация. Но на практике её актуальность даже в больших компаниях часто оставляет желать лучшего.

Как Codex использует этот каталог в работе

У Codex можно задать стартовый промпт, который он читает перед началом работы. Можно сделать один большой промпт, а можно построить многоуровневую схему.

У меня в итоге получилось несколько логических этапов:

• анализ задачи;
• планирование;
• выполнение;
• проверка;
• документация.

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

Как это выглядит на практике

Представим пользовательскую заявку:

У меня перестал работать софтфон в call-центре. Мой номер 788.

Я не называю ни сервер, ни адрес, ни конкретную систему. Codex сам должен понять контекст.

Он анализирует описание и делает вывод, что речь идёт о телефонии. Видит, что это call-центр, значит, вероятно, нужен не любой телефонный сервер, а конкретный контур для call-центра. Находит нужный access.md, подключается, проводит анализ, определяет причину, составляет план решения и затем выполняет его.

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

Если всё подтверждается, дальше вносится документация: что было, что исправили, почему это произошло.

Когда такие промпты уже хорошо отточены, весь цикл можно запускать почти автоматически.

Как использовать это в команде

Когда работаешь не один, всё это тоже можно довольно просто организовать.

Я завёл проект в GitLab и загрузил туда весь каталог серверов. В стартовом промпте у меня и у коллег прописано: в начале подтянуть изменения из Git, а в конце, после документирования, отправить обновления обратно.

За счёт этого у всех всегда актуальное состояние инфраструктурного каталога. Не нужно отдельно вести журнал изменений, писать длинные объяснения коллегам или пересказывать, что и где поменялось.

Даже если записи в changes.md недостаточно, всегда можно спросить у самого Codex: он прочитает notes.md и объяснит контекст.

Единственное, о чём важно помнить, — разрастание такого каталога. Всё, что может бесконтрольно расти, вроде notes.md или changes.md, должно ротироваться. Иначе растёт не только цена обработки, но и падает качество рекомендаций.

Что в итоге получилось

На выходе получается уже не просто чат с советами, а полноценный ассистент, который:

• принимает задачи;
• выполняет работу по этапам;
• сам себя проверяет;
• документирует результат.

На мой взгляд, это уже совсем другой уровень полезности ИИ в администрировании и DevOps.

Моё личное впечатление от качества работы

Возможно, это субъективно, но у меня сложилось впечатление, что Codex CLI сейчас использует самую сильную модель OpenAI именно для практической технической работы.

По моему опыту, одинаковое название модели в API, вебе или других интерфейсах ещё не означает одинаковое реальное поведение. Раньше самой сильной для меня казалась веб-версия. Сейчас по практической пользе для DevOps-задач Codex CLI вышел для меня на первое место.

За всё время использования я всерьёз спорил с ним буквально несколько раз. И, что забавно, во всех этих случаях прав в итоге оказывался он.

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

Вместо заключения

Думаю, это только начало.

В следующих статьях хочу отдельно рассказать про переход к более полной автоматизации и про создание ИИ-ассистентов и ботов для решения ИТ-задач.

Комментарии к статье живые, читаются. Готов ответить на ваши вопросы.

Более детальное описание данного подхода вы можете найти в обновлении этой статьи или в нашем телеграм-канале https://t.me/devchlog

Вступайте в Telegram канал проекта NetworkGuru, чтобы не пропустить интересные статьи и вебинары.

Появились вопросы или нужна консультация? Обращайтесь!

Вечный параноик, Антон Кочуков.

Классификация запросов клиентов с помощью ChatGPT

Подбор оборудования руками ИИ (ChatGPT)

Используем ChatGPT для Text to SQL: анализ заказа клиента