Когда мы впервые увидели AI-чаты, это выглядело впечатляюще. Они писали код, помогали с документацией, объясняли архитектурные решения.
Это было хорошо. Но довольно быстро стало понятно главное:
Для реальной работы этого недостаточно.
ИИ умеет говорить, но не видит, что происходит в системе
Любой DevOps или SRE знает: проблемы в продакшене почти никогда не решаются «в вакууме».
Всегда есть:
окружение,
кластера,
ноды,
сеть,
DNS,
секреты,
история предыдущих действий.
AI-чат может подсказать:
«Проверь логи»
«Посмотри events»
«Проверь memory limits»
Но:
логи нужно собрать,
events — отфильтровать,
вывод — интерпретировать,
и только потом принять решение, что делать дальше.
ИИ в этом процессе остаётся вне системы.
Мы поняли: ИИ должен видеть контекст сам
В какой-то момент мысль оформилась очень чётко:
Если ИИ не видит контекст — он бесполезен. А контекст для DevOps — это реальная система.
Контекст — это:
доступ к окружению,
выполнение команд,
анализ реального stdout/stderr,
понимание того, что изменилось после действий.
Так появилась идея:
ИИ должен не только рассуждать, но и уметь выполнять команды — под контролем человека.
Мы начали ещё до instruct-моделей
Важно понимать тайминг.
Мы начали эксперименты ещё на GPT-3.5 и ранних версиях GPT-4, когда:
не существовало tool calling,
не было structured outputs,
не было agent-фреймворков,
и сама идея «ИИ + SSH» выглядела крайне нестабильной.
Тогда это выглядело как странный и нестабильный эксперимент. Сейчас — как очевидный шаг, без которого execution невозможен.
Тем не менее нам удалось добиться стабильной работы с SSH и Jira задолго до появления instruct-моделей в привычном виде.
Свой instruct, когда этого ещё не было
Основная проблема ранних моделей была простой: они плохо держали роль и легко «уезжали» в рассуждения.
Поэтому вместо ожидания новых моделей мы сделали собственную instruct-обвязку:
жёсткое разделение ролей;
строгую фиксацию цели сессии;
явное разделение «рассуждение / действие»;
формализованный ввод и вывод;
контроль того, что считается выполнением команды.
По сути, мы вручную реализовали то,
что позже стало стандартным instruct-подходом.
Тогда это выглядело как набор костылей.
Сейчас понятно, что без этого шага execution был бы невозможен.
Так из эксперимента родился продукт
В какой-то момент стало ясно, что это уже не эксперимент.
ИИ:
видел контекст,
выполнял команды,
анализировал результат,
сохранял цепочку действий.
Так родился отдельный продукт, который мы внутри называем ExecAI.
Долгий R&D и ошибки, без которых идея бы не сложилась
Дальше был длинный и не самый приятный этап:
технические сложности,
месяцы R&D,
эксперименты,
огромное количество fine-tuning’а,
который, как позже выяснилось, на 90% был не нужен.
Но без этого этапа идея бы просто не оформилась.
Иногда, чтобы понять, что не нужно, приходится сначала это сделать.
Почему мы не взяли готовый агентский фреймворк
Когда вокруг начали появляться «потрясающие», «революционные» и «очень удобные» агентские фреймворки, логичный вопрос был простой: почему мы не используем их?
Короткий ответ — потому что они не решали нашу задачу.
Длинный — потому что почти все эти фреймворки:
хорошо работают в демо и ноутбуках;
красиво выглядят в презентациях;
-
но ломаются, как только ты пытаешься:
дать агенту реальные SSH-доступы,
работать с несколькими кластерами,
выполнять длинные цепочки действий,
контролировать, что именно ИИ делает и почему.
Нам был нужен не «чат с тулзами», а исполнитель:
который может планировать,
выполнять,
проверять результат,
и продолжать работу в одном живом контексте.
В итоге мы довольно быстро поняли неприятную вещь: готовых решений под такую задачу просто нет.
Поэтому мы сделали свой слой — то, что внутри мы называем AIHandler.
Это не «ещё один агентский фреймворк», а:
контроллер контекста,
диспетчер инструментов,
исполнитель команд,
и точка принятия решений в одном лице.
Он появился не потому, что «хотелось изобрести велосипед», а потому что без него ИИ либо не выполняет задачу, либо делает лишнее, либо делает опасное.
И да — большинство идей, которые позже появились в модных агентских фреймворках, у нас уже жили и работали — просто без красивых названий и хайпа.
Немного про инвесторов
Как и многие инженерные команды, мы пробовали общаться с инвесторами.
Опыт был разный, но один урок оказался важным. Один раз мы:
потратили время,
силы,
деньги,
сделали решение под конкретный запрос,
и на этом всё закончилось.
Без сделки. Без продолжения.
После этого правило стало простым:
либо понятные условия,
либо мы развиваем продукт дальше сами.
Это не про обиды. Это про устойчивость и контроль над результатом.
Архитектура: почему сразу микросервисы
Нас двое:
DevOps,
backend-разработчик.
И эта связка сильно повлияла на архитектуру.
Мы сразу понимали, что:
инструментов будет много,
execution-контуры должны быть изолированы,
модель не должна иметь доступа к секретам.
Поэтому продукт с самого начала проектировался как платформа:
20+ микросервисов,
Go, Python, немного C++,
Kubernetes-native,
MySQL как основная БД,
NATS и Redis для асинхронных задач.
Каждый инструмент — отдельный сервис:
SSH,
Jira,
Telegram,
browser / парсер.
ИИ:
не знает IP,
не видит ключи,
не понимает маршруты подключения,
получает только результат выполнения.
Безопасность и контроль
Так как речь идёт о реальной инфраструктуре, безопасность была критичной с самого начала.
Все креды хранятся зашифрованными.
Расшифровка происходит только в момент выполнения.
Поддерживается SSH через jump host.
Все действия логируются (audit trail).
Поведение ИИ управляется текстовыми инструкциями пользователя:
«read-only»,
«ничего не менять»,
«можно выполнять действия».
ИИ не принимает решений сам.
Он выполняет ровно то, что ему разрешено.
Dogfooding: мы используем систему в собственном проде
Важно сразу обозначить: мы не рассматриваем этот инструмент как эксперимент.
На текущий момент подавляющая часть нашей продакшн-инфраструктуры (порядка –75%) была развернута и эксплуатируется с использованием этой же системы.
Речь идёт о:
развёртывании и сопровождении Kubernetes-кластеров,
управлении вычислительными ресурсами и нодами,
настройке сетевых компонентов и ingress-контроллеров,
установке мониторинга и экспортеров,
диагностике и расследовании инцидентов в продакшене.
ИИ в этом процессе:
не действует автономно,
выполняет команды через SSH,
работает по явным инструкциям,
а результат каждого шага проверяется человеком.
По сути, система используется как операционный инструмент, который снимает рутину, ускоряет работу и помогает в расследовании ошибок, но не снимает ответственность с инженера.
Реальная работа, а не демо
На практике система:
диагностирует падения pod’ов (OOM, panic, events),
работает с kubectl, helm, cloud CLI,
анализирует nodegroups и instance lifecycle,
создаёт задачи в Jira по результатам инцидентов,
публикует отчёты и дайджесты в Telegram.
Это не автопилот и не «магия».
Это последовательное выполнение шагов с сохранением контекста.
Практический эффект
Ещё до того, как менеджмент начал учитывать ИИ в планировании,
мы увидели реальный эффект:
задачи на 1–2 рабочих дня
→ решались за 20–30 минут;снизилась когнитивная нагрузка;
ушла постоянная координация;
рабочий день из напряжённого
→ стал управляемым и спокойным.
В этот момент стало понятно:
это работает в проде, а не только на демо.
Почему это не продукт «для всех»
Этот инструмент:
не для новичков,
не для «нажать кнопку и всё само»,
не для экспериментов на чужом продакшене.
Он для людей, которые:
понимают ответственность,
знают инфраструктуру,
и хотят, чтобы ИИ помогал работать, а не создавал иллюзию работы.
Итог
Мы не считаем, что ИИ заменит DevOps.
Но мы уверены в другом:
ИИ может быть полноценным операционным инструментом, если он видит контекст и умеет выполнять реальные действия — под контролем человека.
Execution важнее советов.
Контекст важнее абстракций.
Ответственность важнее «умного чата».
Если вам близка эта идея — будем рады диалогу.
Мы продолжаем развивать эту систему и внимательно смотрим на обратную связь от инженеров, которым важен execution, а не демо.
Комментарии (16)
Wesha
26.12.2025 04:55Если можно сэкономить 5 минут своего времени, то почему бы и нет
Ну, например, потому что потом 5 часов надо прод восстанавливать?
Ares_ekb
26.12.2025 04:55Я согласен с этим. Но я думаю, что есть две крайности: 1) вообще ни для чего не использовать ИИ 2) использовать ИИ для всего, например, поручить ИИ агенту продать квартиру и на все деньги торговать акциями. Это конечно очень скучная и банальная позиция, но используемые инструменты должны быть соразмерны рискам. Для таких критичных задач не то что на ИИ, но и на людей нельзя полагаться независимо от их квалификации, для этого и есть ревью кода, тестировщики.
Например, мне недавно нужно было прикрутить JupyterHub к одному проекту, чтобы при этом было SSO через Keycloak, чтобы API запросы из JupyerHub отправлялись не через внешнюю сеть, а в докере и чтобы в запросах token JupyterHub преобразовывался в JWT-токен. Я мог бы неделю читать документацию и потом сделать это вручную. А с ИИ потратил два дня и результатом я максимально доволен. Естественно весь сгенеренный код я не сразу деплоил в прод, а понадобились десятки итераций и ручные правки прежде чем он стал нормальным. Мне это сэкономило время. А если люди деплоят сгенеренный код не глядя в прод, то там проблема явно не только с ИИ
Wesha
26.12.2025 04:551) вообще ни для чего не использовать ИИ 2) использовать ИИ для всего, например, поручить ИИ агенту продать квартиру и на все деньги торговать акциями. Это конечно очень скучная и банальная позиция, но используемые инструменты должны быть соразмерны рискам.
Вы упускаете ещё такой момент: человек — он, сцуко, биологически так устроен (впрочем, как и чуть менее, чем все организьмы на этом шарике), что у него чем не пользуешься — то вскоре атрофируется. Поэтому нет, спасибо, я не буду пользоваться костылём дла мозга.
Я мог бы неделю читать документацию и потом сделать это вручную.
...и всю оставшуюся жизнь знать, как это сделать ещё раз...
А с ИИ потратил два дня и результатом я максимально доволен.
... а потом вероятные партнёры ИИ отключают — и вот Вы уже ни на что не способны и никому не нужны.
Ares_ekb
26.12.2025 04:55...и всю оставшуюся жизнь знать, как это сделать ещё раз...
Я напишу очень стрёмную вещь, но у меня подобных знаний в избытке. Например, недавно была проблема со сборкой фронтенда в докере. Локально всё отлично собирается, а когда приложение деплоится на сервер через докер, то сборка в 10 раз дольше и памяти съедается в 3 раза больше. Я полдня потратил на то, чтобы в этом разобраться. Очевидные причины, что сервер слабее локальной машины, что докер не видит, что на сервере не так много RAM, съедает всю память, процессы уходят в swap, ещё ИИ мне подкинул идею, что в alpine образах используется системная библиотека, которая не очень эффективно работает с памятью и переход на debian образ улучшит ситуацию.
Короче проблема оказалась в том, что сборка запускалась через bun, который локально видел у меня установленный node.js и реально запускал сборку через него, а в докер-образе node.js нет и сборка запускается через сам bun, который сжирает кучу памяти и тормозит. И как только мы устанавливаем в докере node.js всё начинает прекрасно работать.
Зачем мне эти #@#!!###$$% знания на всю оставшуюся жизнь? Зачем я потратил полдня своей жизни на их приобретение? Я могу рассказать таких историй ещё сотни не только про прекрасную сборку фронтенда, но и про какие-нибудь безумные исключения или багофичи в Hibernate и т.д. Мне не нужны все эти мусорные знания!
... а потом вероятные партнёры ИИ отключают — и вот Вы уже ни на что не способны и никому не нужны.
Разбираться почему фронтенд стал собираться в 10 раз дольше или прикручивать Keycloak к JupyterHub - это не моя основная работа. Это препятствие, которое сжирает моё время и мешает заниматься основными задачами. Мне нафиг не нужны эти навыки
Вы упускаете ещё такой момент: человек — он, сцуко, биологически так устроен (впрочем, как и чуть менее, чем все организьмы на этом шарике), что у него чем не пользуешься — то вскоре атрофируется. Поэтому нет, спасибо, я не буду пользоваться костылём дла мозга.
Когда синьор скидывает на джуна часть задач, он тупее от этого не становится. Скорее наоборот, у него появляется время для других более сложных задач.
Естественно пока я генерил код в примере с Keycloak и JupyterHub я разобрался в этом и я в состоянии это сделать без ИИ, тем более что я переписал этот код по-человечески почти полностью.
Я согласен, что наверняка что-то атрофируется. Способность искать и анализировать информацию. Способность нормально формулировать вопросы - очень часто пока пишешь вопрос погружаешься в проблему и сам находишь ответ. Способность принимать решения. Способность концентрироваться и погружаться во что-то в течение длительного времени, например, полдня дебажить какой-то безумный код.
Но у меня хватает задач, на которых можно развивать все эти навыки. Я просто не хочу тратить своё время на бессмысленные задачи. Хотя в целом я согласен, если бы современный ИИ появился 10 лет назад, то почти наверняка я был бы гораздо тупее сейчас :)
Yason_DA Автор
26.12.2025 04:55Можно было пойти другим путем
1 обсудить с тем ии как это лучше сделать. 80% что он бы учел все эти моменты
2 Он же сделал бы решение
3 Запросить "пояснительную бригаду" - что бы не терять сноровку
Wesha
26.12.2025 04:55Зачем мне эти #@#!!###$$% знания на всю оставшуюся жизнь?
Чтобы в старости сказки на Хабр писать, конечно же!
На Самом Деле™, конечно же, чтобы нарабатывать опыт. По моему опыту, заранее никогда нельзя предсказать, когда пригодится то или иное знание. Поэтому не надо
строить из себя Шерлока Холмса
Yason_DA Автор
26.12.2025 04:55Торговлю акциями пробывали. Причем с RAG. На коротких позициях - отлично. Но на длинных на пару недель - все очень плохо. Энтропия высокая.
Пробывали разуметься не на реальные деньги. Потеряли 4 млн из 10.
Yason_DA Автор
26.12.2025 04:55Реальынй случай. Но ИИ его и восстановит. Решил одну тему сделать, сломал кластер. Понял что изначально бред делал. Просто сказал в том контексте "верни все как было"
Через 2 минуты работа восстановилась.
Что делал - решил с CNI поиграть.Wesha
26.12.2025 04:55Через 2 минуты работа восстановилась.
Как Вы можете прочитать по ссылке, у них ничего не восстановилось. Прикиньте, даже ИИ не под силу восстановить дропнутую базу.
Ares_ekb
ИИ в режиме агента, а не просто чата на мой взгляд отличная штука. Недавно спорили в комментариях на сколько (бес)полезен ИИ для поиска проблем с производительностью. В итоге я написал примитивный bash‑скрипт, который запускает команды top, uptime, df, iostat и другие. Скормил результат ИИ и он выдал вполне осмысленное описание состояния сервера.
Конечно можно и самому зайти на сервер по SSH, выполнить команду top и другие, самому интерпретировать результат. ИИ для этого не обязателен, но если он сам в режиме агента это делает, то это просто быстрее и удобнее. Если можно сэкономить 5 минут своего времени, то почему бы и нет
Ares_ekb
При этом ИИ почему-то очень токсичная тема, это 100% гарантия получить минус на хабре :) Если бы в дополнение к минусу я получил комментарий хотя бы из нескольких слов, то мне было бы проще понять в чём я не прав. Хотя минусы - это ещё более токсичная тема! Теперь я ещё и за этот комментарий получу минус. Всё тлен...
Wesha
Скрытый текст
Yason_DA Автор
Увы не могу сказать что вы не права. Но основных проблем 2
1 ИИ не человек. Но это не возможно объяснить почему-то. И если дать конкретную задачу - то связные с ней он пропустит с большой вероятность.
https://rutube.ru/video/71ed75e456a1d9ad4c7481ada01a9563/ - кубы встали.
Знакомый посомтрел видео. После решил проверить. Расписал на страницу инструкции как ставить кубы - в итоге получил кривое решение. Потому что сместил голову внимания.
2 Пока еще нужен контролер.
Конкретно за минусы - не знаю. Но в 2013 году, я получал такие минуса за k8s. Новое не понятно, потому плохо и так далеть нельзя. А я , негодяй, писал что за этим будущее.
MEGA_Nexus
А можно просто открыть дашборд в zabbix\prometheus и сразу понять, в чём проблема. :)