История о том, как read-only аудит, паспорта серверов, текущее операционное состояние и аккуратные контрольные точки превращают серверный хаос в управляемую инфраструктуру.
Есть ощущение, которое знакомо каждому, у кого больше одного сервера: ты примерно помнишь, что там запущено, но уже не уверен в деталях.
Когда-то на каждом VPS жил один проект. Потом появились эксперименты, превью-контуры, стейджинг, старые версии. Что-то стало production. Что-то давно не используется, но выключить страшно — вдруг от него зависит что-то живое. Где-то старое имя хоста. Где-то забытое превью. Где-то сервис, который вроде бы не нужен, но вдруг на него кто-то завязан.
В какой-то момент инфраструктура перестаёт быть системой и становится туманом. Первый раз я это почувствовал, когда решил навести порядок на серверах Timeweb. Тогда я позвал Codex с фонариком. После двух месяцев работы с агентами подход превратился в рабочий метод.
Главная ошибка — начинать с героической чистки.
Видишь хаос — хочется сразу резать: остановить контейнеры, удалить директории, почистить nginx, закрыть порты. Но в production-среде такой порыв опасен. Потому что до карты вы не знаете, где кончается мусор и начинается живая система с неочевидным именем.
Первый принцип: read-only. Сначала смотрим, потом документируем, потом обсуждаем. И только после явного одобрения что-то меняем.
Codex идеально подходит для этого этапа. Он методично обходит состояние: проверяет запущенные сервисы, nginx-конфиги, Docker-контейнеры, открытые порты, DNS-записи. Собирает данные в документ. Ничего не трогает без разрешения.
Человеку такая работа скучна. Агенту — нормальна.
Самый ценный результат аудита — набор артефактов, по которым можно принимать решения.
Паспорт сервера — документ для каждого VPS: что на нём живёт, какие домены обслуживаются, какие сервисы активны, где production checkout, какие порты открыты, когда последний раз обновлялся certbot.
Текущее операционное состояние — актуальное состояние всей инфраструктуры: что работает, что на паузе, что запланировано. Обновляется после каждого изменения.
Список контуров — рабочие, устаревшие, можно трогать, нельзя трогать. Для каждого устаревшего контура: причина, по которой он до сих пор жив, и условие, при котором его можно выключить.
Стоп-линии — чёткие границы: что агент может делать сам, а для чего нужно отдельное одобрение. Читать конфиги — можно. Удалять директории — только после проверки.
Записи для отката — для каждого планируемого изменения: что откатить, если пойдёт не по плану. Записываются до того, как изменение происходит.
Когда эти артефакты собраны, тревога снижается. Вы больше не думаете «там что-то непонятное». Вы видите: вот живой контур, вот legacy, вот можно выключить после проверки, вот требует отдельного плана.
После карты начинается работа. Но она выглядит иначе, чем героическая чистка.
Каждое изменение — отдельный маленький шаг с явным одобрением.
Старое превью больше не нужно? Сначала резервная копия, потом проверка nginx, потом 410 Gone, потом healthcheck production-сайта. Каждый этап — отдельное подтверждение.
Strapi больше не используется? Остановить контейнер, но не удалять. Период ожидания, проверка Directus, редирект, резервная копия. Удаление — отдельный шаг через неделю.
Такой подход медленнее порыва, но безопаснее на порядок. Наведение порядка перестаёт быть рискованной уборкой и становится операционным процессом.
Инфраструктуру легко пытаться сделать идеальной: чистые папки, свежие конфиги, всё по полочкам. Но первая задача — управляемость.
Управляемость означает: вы понимаете текущее состояние и можете безопасно сделать следующий шаг.
Иногда управляемое состояние — это честно задокументированный устаревший контур с пометкой «убрать через месяц». Это лучше, чем красиво вычищенный сервер, про который никто не помнит, что на нём было и зачем.
Codex в такой работе — второй внимательный участник, который ходит с фонариком и записывает увиденное.
Он полезен тогда, когда помогает увидеть карту и принять маленькое безопасное решение. Методично обойти файлы, сравнить конфиги, проверить healthcheck, подготовить документ.
Он опасен, если дать ему свободу менять production без одобрения. Особенно когда вы ещё осваиваете терминал и не до конца уверены, что именно живёт на сервере.
Границу проводит человек. Агент её соблюдает. Вот рабочая схема для инфраструктурных задач.
Метод простой, и он работает при любом масштабе.
Первый шаг: read-only аудит. Пусть агент обойдёт всё и запишет текущее состояние.
Второй шаг: паспорта и текущее операционное состояние. Документы, по которым можно принимать решения.
Третий шаг: маленькие изменения с одобрением. Каждое действие — отдельным шагом, с записями для отката.
Четвёртый шаг: обновление текущего операционного состояния после каждого изменения.
Хаос инфраструктуры лечится картой. А карта начинается с того, что кто-то берёт фонарик и идёт смотреть.
Если у вас серверы, которые давно требуют ревизии, и вы хотите разобраться, как подойти к этому системно — можно обсудить подход.
Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov