Инфраструктура, которую понимал один человек
На фоне сокращения бюджетов у нас ушёл DevOps. Он был единственным, кто держал в голове, какие серверы у нас есть, какие домены на них смотрят, где стоят прокси и у кого остались доступы. Следующие два месяца мы жили в режиме догадок: любое изменение начиналось с раскопок.
Масштаб при этом скромный, но неудобный: 20–30 машин у разных провайдеров, никакого кластера, часть серверов в Hetzner ради цены, часть — в российском контуре ради доступности, больше сотни доменов и цепочки проксирования между странами. Нанять нового специалиста значило поиск, онбординг и бюджет, которого не было. Не нанимать — оставить риск на месте.
Модель системы вместо списка серверов
Всё началось с того, что выглядело разовой задачей, — собрать перечень машин. Первым входом стали буквально скриншоты из панелей Hetzner и AWS: агент переписал их в JSON. Схему заранее не проектировали, структура росла под каждый следующий срочный вопрос.
Дальше каждый новый слой добавлялся в тот же файл. Реестр SSH-ключей с алиасами показал, кто вообще может зайти на серверы, — нашлось около десяти лишних ключей. Характеристики машин помогли найти переплату за избыточные ресурсы. Список контейнеров показал, что реально работает на каждом узле. Для доменов появились метки роли, окружения, приоритета и региона аудитории: последняя важна, потому что российский пользователь не должен видеть зарубежный IP, а иностранный клиент — российский след. Проверка TLS фиксирует издателя и срок каждого сертификата, в том числе ради старых Android-устройств, которым нужен RSA.
Удержать это помогли два решения. Первое — не гонять агента заново на каждый прогон, а один раз сохранить написанный им скрипт и дальше запускать его напрямую: так дешевле по токенам, и данные собираются одинаково. Второе — описывать не только факты, но и норму. Эталонный сервер превратился в стандарт мониторинга с обязательными компонентами и чек-листом приёмки, а у каждой машины появился статус покрытия. Так же описаны бэкапы: куда они уходят, по какому расписанию и что показывают последние наблюдения.
Десять тысяч строк, которые живут в Git
За три недели получился инвентарь почти в 10 000 строк. Он хранится в репозитории, обновляется короткой командой, а проверки бэкапов раз в день запускаются из GitLab CI. Любая инфраструктурная работа теперь оставляет коммит: коллеге достаточно ссылки, чтобы понять, что поменялось, а об изменениях в репозитории приходят уведомления в Telegram.
Важнее цифр другое: у команды появился один источник правды, вокруг которого новые проверки и утилиты пишутся быстро и дёшево. Смена инструмента это подтвердила — когда я перешёл с Codex на Claude Code, новый агент просто прочитал структуру и продолжил с того же места.
Что я забрал бы в следующий проект
ИИ здесь не заменил инженера, а ускорил работу, которую всё равно пришлось бы делать руками. Долгосрочная ценность не в агентах, а в модели данных: пока структура стабильна, её можно расширять под новые задачи, не переписывая то, что уже есть.
У подхода есть граница. В энтерпрайзе и системах с жёсткими требованиями к соответствию место за Terraform, Ansible, Kubernetes и зрелой платформенной командой. Но стартапу, где важны скорость, воспроизводимость и каждый рубль бюджета, живой инвентарь даёт управляемость без найма — это компромисс, который у нас сработал.