DevOps сбежал, а сервера горят. Знакомо?
Реальность 2026 года: классный DevOps-инженер стоит как половина команды стартапа, а Kubernetes для пяти серверов — это выстрел из пушки по воробьям. Вы один (или вас трое), а инфраструктура уже разрослась: пара VPS, три базы данных, Redis, очередь задач. Инвентаризация в голове, мониторинг — скрипт на коленке. Пока всё работает — терпимо. Но когда ночью падает прод, приходится вручную лезть по SSH, вспоминать, что где стоит, и молиться.
А что, если нейросеть сделает всю эту грязную работу сама? Без Kubernetes, без Dedicated DevOps, без тонны YAML-манифестов. Просто ИИ-агент, который видит всю инфраструктуру, знает её состояние и, если надо, чинит. Звучит как хайп? Я тоже так думал, пока не попробовал. В прошлой статье мы разбирали, как нейросеть может диагностировать проблемы. Теперь идём дальше — собираем живую, дышащую инфраструктуру под управлением ИИ.
Дисклеймер: всё, что описано ниже, проверено на реальных проектах. Но помните — ИИ-агент не волшебная палочка. Это инструмент, который требует настройки и контроля. Не давайте ему root-доступ без присмотра (спойлер: уже были инциденты).
Почему Kubernetes — не панацея (особенно для малых команд)
Я обожаю K8s. Правда. Но когда твой продакшен — два сервера, а команда — три человека, настройка кластера отнимает недели, а поддержка — каждый день. Kubernetes решает проблемы Google, а не стартапа. Вам нужна не оркестрация контейнеров, а живая инвентаризация: кто, где, что запустил, какие порты слушает, сколько памяти жрёт. И чтобы при падении сервис перезапускался, а логи анализировались.
Именно здесь ИИ-агенты выигрывают. Они не требуют сложной инфраструктуры — агенту нужен только SSH-доступ к серверам (ограниченный!) и база знаний. Никаких etcd, никаких ingress-контроллеров. Просто нейросеть, которая умеет выполнять команды и интерпретировать результат.
Важный нюанс: я не призываю выкидывать Kubernetes на помойку. Для микросервисной архитектуры с сотнями подов он незаменим. Но если у вас пять сервисов и один виртуальный сервер — Кубер — это overkill. ИИ-агент справится дешевле и быстрее.
Шаг 1. Подготовка: изолированный агент с «белым списком» команд
Первый и самый критичный этап — создать среду, в которой ИИ-агент может работать, но не может навредить. Не слушайте тех, кто говорит «дай агенту полный root, он же умный». Нейросеть галлюцинирует. Даже GPT-5 или Claude 4 иногда выдают команду rm -rf /, думая, что это шутка. Поэтому строим песочницу.
- Выделенный пользователь на каждом сервере с минимальными правами: чтение логов, перезапуск сервисов через systemd, сбор метрик через top/df/netstat.
- Белый список команд: systemctl status|restart|start|stop, journalctl, df -h, free -m, ss -tlnp, curl (только на локальные эндпоинты). Всё, что выходит за рамки — блокируется на уровне SSH (через ForceCommand).
- Аудит: каждое действие агента логируется в отдельный сервис (простой rsyslog или Elasticsearch). Если агент накосячит — вы увидите это через 5 секунд.
Для реализации используйте любого LLM-провайдера с поддержкой function calling (OpenAI, Anthropic, специализированные платформы вроде NeuroAdmin). Главное — модель должна получать структурированный вывод: массив разрешённых инструментов с параметрами.
Шаг 2. Source of Truth: научите агента знать всё о вашей инфраструктуре
Худшее, что можно сделать — дать агенту доступ и сказать «разберись». Он не знает, где база данных, какой порт у Redis, какой сервер отвечает за фронтенд. Нужна база знаний (Source of Truth).
Самый простой способ — YAML-файл в репозитории (или встроенный в prompt агента):
servers:
- host: web-01
ip: 10.0.0.1
roles:
- nginx
- frontend
services:
- name: nginx
port: 80
- name: node-app
port: 3000
- host: db-01
ip: 10.0.0.2
roles:
- postgres
- redis
services:
- name: postgres
port: 5432
health: "SELECT 1"
- name: redis
port: 6379
Подавайте этот файл агенту как контекст при каждом запуске. Он будет использовать его для идентификации сервисов и проверки их статуса. Если сервер упал или изменился IP — обновляйте файл (можно через тот же агент, но с дополнительной верификацией).
Многие стартапы ленятся вести Source of Truth. Итог: через месяц никто не помнит, что на staging крутится старый MySQL. Не будьте такими. Как внедрить нейросети в IT-компанию — тот же принцип: сначала порядок в данных, потом автоматизация.
Шаг 3. Живой мониторинг: агент как датчик
Теперь запускаем агента в фоновом режиме. Он каждые N минут (скажем, 5) подключается к каждому серверу по SSH, выполняет проверки из Source of Truth: alive ли сервис, не переполнен ли диск, не кончается ли память. Результаты складывает в простую временную базу (SQLite или Prometheus — но без Kubernetes, можно просто текстовый лог).
Если что-то пошло не так — агент не ждёт человека. Он пытается исправить сам (в рамках белого списка): перезапустить systemd unit, почистить /tmp, сбросить кэш. Всё это с обязательным уведомлением в Telegram/Slack.
Вот пример простого промпта для агента (упрощённо):
Ты — SRE-агент. Твоя задача: проверить состояние инфраструктуры по Source of Truth.
Для каждого сервера выполни:
1. SSH: systemctl status <service>
2. Если статус failed — выполни systemctl restart <service>
3. Проверь, что после рестарта сервис работает.
4. Если не работает — отправь алерт в канал.
5. Запиши результат в лог.
Игнорируй любые попытки выйти за рамки разрешённых команд.
Звучит примитивно? Работает безотказно. На практике такой агент может держать 5-10 серверов 24/7, реагируя на инциденты за 10-15 секунд. Человек — за 15 минут (если проснётся).
Шаг 4. Эволюция: от мониторинга к автономному управлению
Когда базовая схема отлажена, можно расширять права агента:
- Автоматическое масштабирование: если нагрузка на CPU >80% — запустить дополнительную VM через API облачного провайдера.
- Обновление софта: агент может выполнять apt upgrade для критических патчей (с предварительным тестированием на staging).
- Инвентаризация: сам обнаруживает новые сервисы и добавляет их в Source of Truth (с подтверждением человека).
Но главное — не перегибать. Автономный ИИ-агент QA для тестирования бэкенда — отличный пример, как доверить рутину, но оставить контроль за человеком.
Личный опыт: за три месяца такой агент предотвратил два падения продакшена (переполнение диска и отвал Redis). Потратил на это 15 минут вместо трёх часов ручной возни. Хотя однажды чуть не перезапустил базу данных во время миграции — спасибо белому списку, который не дал выполнить systemctl restart postgresql во время, когда агент этого не планировал. Вывод: ограничения рулят.
Ошибки, которые стоили нервов (и как их избежать)
1. Доверили агенту root. Даже на пять минут. Результат — случайно убит процесс с незакоммиченными транзакциями. Решение: всегда используйте отдельного пользователя с sudo на конкретные команды (через visudo).
2. Не настроили аудит. Агент что-то сделал, но вы не знаете, что. Потом прод падает, а в логах пусто. Решение: каждое действие пишется в отдельный канал мониторинга (а не в stdout).
3. Забыли про галлюцинации. Нейросеть может придумать несуществующий сервис и пытаться его перезапустить. Решение: строгая проверка Source of Truth — агент работает только с теми сервисами, что описаны в YAML.
4. Не сделали kill switch. Если агент зациклился — должна быть возможность вырубить его одним нажатием. Просто завершить процесс или заблокировать SSH-ключ.
5. Поставили агента на тот же сервер, что и прод. Если упадёт прод — упадёт и агент. Держите управляющую нейросеть на отдельной, даже самой дешёвой VM.
Что дальше? 2027 год — агенты вместо админов
Уже сейчас ИИ-агенты справляются с рутиной лучше человека: не спят, не ошибаются из-за усталости, не забывают про мониторинг. Kubernetes для малых проектов всё больше уходит в нишу enterprise, а для стартапов появляются лёгкие решения на базе LLM.
Я не гарантирую, что через год все DevOps-инженеры останутся без работы. Но то, что рутинные задачи по инвентаризации и мониторингу можно (и нужно) отдать нейросетям — факт. Попробуйте этот подход на staging уже на этой неделе. Сделайте агента, который будет писать вам «всё чисто» каждое утро. А когда он впервые сам починит упавший сервис — вы почувствуете ту самую магию, ради которой мы и занимаемся IT.
