Как мы случайно сделали стартап, пока учили ИИ работать с реальной инфраструктурой

Когда мы впервые увидели AI-чаты, это выглядело впечатляюще. Они писали код, помогали с документацией, объясняли архитектурные решения.

Это было хорошо. Но довольно быстро стало понятно главное:

ИИ умеет говорить, но не видит, что происходит в системе

Любой DevOps или SRE знает: проблемы в продакшене почти никогда не решаются «в вакууме».

Всегда есть:

• окружение,

• кластера,

• ноды,

• сеть,

• DNS,

• секреты,

• история предыдущих действий.

AI-чат может подсказать:

Но:

• логи нужно собрать,

• events — отфильтровать,

• вывод — интерпретировать,

• и только потом принять решение, что делать дальше.

ИИ в этом процессе остаётся вне системы.

Мы поняли: ИИ должен видеть контекст сам

В какой-то момент мысль оформилась очень чётко:

Контекст — это:

• доступ к окружению,

• выполнение команд,

• анализ реального 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, а не демо.