Привет! Меня зовут Руслан Мамлеев, я эксперт курса «Архитектор ПО» в Практикуме и технический директор (CTO) в GetFloorPlan.
Недавно на фоне кризиса и сокращения бюджетов у нас ушёл DevOps. А вместе с ним исчезла и целостная картина инфраструктуры — только он понимал, какие серверы, домены и прокси у нас есть, где что живёт, какие доступы выданы, что мониторится, а что нет. Два месяца провели в хаосе.
Нанимать нового специалиста было рискованно — это дополнительный бюджет, поиск и онбординг. Не нанимать — тоже, потому что инфраструктура бы никуда не делась. Поэтому я пошёл по третьему пути — и за три недели переосмыслил сам подход к инфраструктуре.
С чем мы имели дело
Немного контекста:
мы небольшой стартап, достаточно сильно экономим — у нас нет Kubernetes, platform engineering и прочих энтерпрайз-практик,
всего 20–30 серверов у разных провайдеров, не объединённых в кластер,
часть серверов — в Hetzner, потому что так дешевле, а часть — в российском контуре, так как сервисы должны быть доступны в России,
инфраструктура живая и местами исторически сложившаяся — например, некоторые домены тянутся корнями к удалённому инстансу GitLab через несколько форков.
Сначала я думал, что инвентаризация — это разовая задача. Нужно просто собрать список серверов, чтобы понять, что у нас есть. Но когда мы начали делать это с помощью ИИ-агентов, быстро выяснилось, что мы можем создать живой инвентарь — единый source of truth, который можно расширить под любые инфраструктурные задачи.
Шаг 1. Скриншоты
Начало было простым и немного смешным, потому что состояние было отчаянное. Я просто накидал в Codex скриншоты из Hetzner, AWS и других кабинетов (даже не текстом, а просто картинками) и попросил агента зафиксировать всё, что он видит: названия серверов, IP-адреса, провайдеров, базовые атрибуты.
Все данные мы сложили в JSON. Просто потому что было удобно: у меня технический бэкграунд, я его нативно понимаю, и с ним хорошо работает ИИ. У нас не было какой-то идеальной схемы — просто живая структура, которая отвечала текущим потребностям. Начали с массива серверов, а остальное наращивали по мере необходимости и срочности.
Шаг 2. Реестр SSH-ключей
Одно дело — видеть сервер, а другое — иметь к нему доступ. Надо было понять, могу ли я вообще куда-то зайти. Мы проверили SSH-доступы, убедились, что везде прокинуты ключи, и дописали это в инвентарь. Файл сразу начал расширяться: мы не только перечислили серверы, но и описали, как в них зайти, под каким пользователем, через какой порт, есть ли доступ или выдаёт ошибку.
Я задумался: а кто ещё, кроме меня, может войти на сервер? Возможно, старый DevOps, а может, кто-то, кому доступ уже давно не нужен. В стартапах такие вещи часто живут по инерции, пока всё работает, но с точки зрения безопасности — это слабое место. В итоге нашли около десяти лишних ключей.
ИИ хорошо лёг и на эту задачу. Мы проинвентаризировали SSH-ключи через реестр: в отдельном блоке JSON составили список всех ключей. Промпт использовали простой: зайди на все серверы и запиши в JSON-файл в ключ ssh_key_refs, кто имеет к ним доступ. Агент помог собрать и оформить логику и написал под неё простой код.
Теперь с помощью одного запроса можно было посмотреть, какие ключи и доступы есть в инфраструктуре, а что можно спокойно удалить. Запускаешь короткую команду, и инвентарь обновляется. Так у нас появилась начальная автоматизация.
Шаг 3. Характеристики серверов и контейнеры
Дальше мы решили поискать, где может быть неправильный размер сервера: например, стоит машина с 64 GB RAM, но по-хорошему хватило бы восьми, а мы переплачиваем. Для этого мы расширили структуру и добавили характеристики: дата-центр, CPU, RAM, SSD, регион, ОС, тарифный план у провайдера. Часть информации агент брал с сайтов облачных платформ, а часть вытаскивал с самих машин командами.
Примерно в то же время я переключился на Claude Code, и оказалось, что вся система классно переезжает и масштабируется. Мне не пришлось ничего переносить вручную — новый агент просто считал структуру JSON и продолжил работу с того же места. Тогда я впервые почувствовал, что у меня в руках не просто заметки на коленке, а живая карта инфраструктуры.
Параллельно мы стали разбираться: а что вообще запущено на серверах? Поскольку у нас почти всё живёт в Docker, задача свелась к тому, чтобы выполнить docker ps, вытащить список контейнеров, их образы и порты, и записать это в JSON.
Поначалу агент просто писал код и исполнял его в рантайме, а мы тестировали, может ли это вообще работать. Но гонять агента каждый раз заново экономически невыгодно — он тратит токены на генерацию одного и того же кода. Поэтому мы попросили агента один раз написать скрипт, сохранить его в определённом месте и дальше просто запускать его напрямую. Это и сэкономило нам токены, и сделало всё консистентным: данные теперь собираются одним и тем же способом и в одном формате.
Шаг 4. Домены, лейблы и прокси-цепочки
Отдельной болью оказались домены. Их у нас оказалось больше ста, и я не до конца понимал, какой домен на каком сервере задеплоен, какие идут напрямую, а какие через прокси, как связаны российский и зарубежный контуры.
Из-за блокировок серверы в России работали через прокси и специальные маршруты. Например, приложение запускалось на сервере в Германии, а российские пользователи заходили через сервер в России. Нам было важно понять, как они связаны: если перезагрузить российский сервер, к каким именно сервисам в Германии пользователи потеряют доступ? Поэтому было критично отдельно распутать все цепочки: куда приходит пользователь, где edge, где origin, где используется 443, где 8443, где терминируется TLS.
Всё это органично легло в структуру инвентаря. Особенно полезным оказалось проставить нормальные лейблы: role, env, priority, audience_region. Последний нам особенно важен, так как если российский пользователь видит иностранный IP, есть риск блокировки, а если зарубежный клиент видит российский след — это уже репутационный риск.
Раньше я знал, что прокси-цепочки где-то есть, но не мог быстро проследить путь трафика. С инвентарём маршрут стал читаемым.
Как и в случае с серверами, у нас получался не просто список, а полноценная структура, с которой можно работать как с моделью системы. В том числе проверять её автоматически.
Шаг 5. SSL-сертификаты
SSL — это хроническая боль, если у вас много доменов. Во-первых, рано или поздно они истекают, и уследить за этим вручную почти нереально. Во-вторых, старые устройства поддерживают RSA-сертификаты, но не работают с ECDSA. Если на домен пойдёт трафик, например, со старых Android-устройств, важно иметь оба типа.
Инвентарь помог решить обе проблемы. Мы добавили в него информацию о каждом сертификате: когда выдан, когда истекает, кто issuer, какой статус, есть ли ошибка.
Как только появилась структура, агент сам написал под неё код проверки. Скрипт подключается к каждому домену и смотрит, какой сертификат реально отдаётся «снаружи». Он сохраняет главное: кем выдан, на кого выписан, до какой даты действует. Сразу видно, где всё ок, а где скоро истекает.
Шаг 6. Принципиальный сдвиг: мониторинг-стандарт
У нас есть Grafana, Prometheus, Loki, но я не был уверен, что все серверы к ним корректно подключены. Какие-то появились позже, какие-то менялись, что-то делалось на ходу, поэтому нужен был не просто мониторинг для галочки, а стандарт, который можно проверить на каждом сервере.
Чтобы это сделать, я взял один хорошо настроенный сервер как эталон и попросил агента зафиксировать, как именно в нём устроен мониторинг. Так в JSON появился отдельный блок monitoring_standard с required_components, scrape_jobs и дефолтами для promtail и acceptance_checklist.
Это был принципиальный сдвиг: мы начали описывать не только факты о системе, но и ожидаемую норму. Теперь нам не нужно вспоминать, как мы обычно ставим мониторинговую обвязку. Достаточно сказать агенту: возьми monitoring_standard и перенеси на эту ноду. Шаблон можно масштабировать по всей инфраструктуре.
Параллельно у каждого сервера появился monitoring_coverage — статус full, partial и т. д., в зависимости от чек-листа. Система перестала работать в режиме «или настроено, или непонятно», появились понятные статусы и отклонения.
Шаг 7. Бэкапы
Похожая история была с бэкапами — мы не знали, делаются ли они везде, туда ли едут, с нужной ли периодичностью, можно ли потом восстановить. Для надёжности мы создаём их сразу в два направления и в разные дата-центры — например, в Яндекс и Amazon. Это тоже появилось в инвентаре:
backup_destinations — endpoint, bucket, region, lifecycle, переход в холодное хранение
backup_policies — на каком сервере, что именно бэкапится, по какому расписанию, в какие destinations
backup_observations — сколько бэкапов видно, когда был последний, нет ли аномалий
Агент держит это в контексте как модель, а скрипт запускается раз в день по расписанию через CI/CD в GitLab — обновляет наблюдения и подсвечивает отклонения. Как и с SSL-сертификатами, мне не нужно глубоко читать весь код. Достаточно понимать, что он делает, и проверять результат.
Это отлично показывает, как работает весь подход: когда структура данных стабилизировалась, вокруг неё можно дёшево и быстро навайбкодить сколько угодно проверок, алертов и утилит.
Что получилось: живой инвентарь
Мы не только собрали целостную модель инфраструктуры, но и дёшево нарастили полезную автоматику. Теперь, когда что-то меняется (подняли новый сервер, поменяли доступы, добавили домен, обновили сертификат, изменили бэкап-политику), можно просто запустить короткую команду актуализации инвентаря, и в JSON перепишется несколько строк.
Сейчас в файле почти 10 000 строчек, и он живёт в Git. Это важный слой: когда мы делаем инфраструктурные работы, всё фиксируем в репозиторий. Достаточно скинуть коллегам ссылку на коммит — и по нему сразу понятно, что сделали. Git хранит всю историю изменений по инфраструктуре: даты, действующие лица, контекст. К этому можно вернуться в любой момент.
Главное, что я вынес
ИИ — не волшебная замена человеку, а усилитель, который помогает быстро собрать и поддерживать живую модель инфраструктуры. Ключевая ценность не в самих агентах, а в том, что у команды появляется единый source of truth, который можно расширять под реальные потребности. Архитектурное мышление здесь важнее конкретных инструментов.
ИИ-подход не заменяет зрелый DevOps, особенно в энтерпрайзе и высококомплаентных системах, где уместны Terraform, Ansible, Kubernetes и полноценные платформенные практики. Но он может сработать в стартапах, где важны скорость и воспроизводимость, а бюджет ограничен. Для меня это и делает всю историю ценной: она не про идеальный мир, а про компромисс, который оказался рабочим.