Как я решил узнать, что вообще живет на моих серверах, и позвал Codex с фонариком

Иногда инфраструктура растёт как книжная полка: сначала одна аккуратная папка, потом рядом ещё одна, потом кто-то положил сверху коробку с проводами, потом «это временно», потом «не трогай, оно работает», и в какой-то момент вы открываете шкаф и понимаете — формально это ваш шкаф, но юридически там уже отдельное государство. У меня примерно так и получилось с серверами на TimeWeb.

Было семь виртуальных машин — мои серверы, мой аккаунт, моя инфраструктура. Но в реальности шесть из этих машин разворачивал не я: я примерно представлял, что там должно быть, но полной операционной картины у меня не было. Где что запущено, что действительно работает, какие сервисы живые, какие давно забыты, где данные, где бэкапы, кто к чему подключён, что можно выключить, а что лучше не трогать даже взглядом без предварительного плана — на эти вопросы у меня не было быстрых ответов.

И вот это чувство, когда вы платите за серверы, но не можете за пять минут объяснить, что делает каждый из них, мне совсем не понравилось. Я решил, что нужен полный аудит — если назвать это нормальным человеческим языком, аудит и наведение порядка в серверной инфраструктуре, а если чуть более инженерно, DevOps-аудит без героизма: сначала карта, потом риски, потом аккуратные изменения. Не «посмотреть в панели, вроде всё зелёное», не «спросить у кого-нибудь, помнит ли он», не «ну там же сайт крутится, значит нормально», а нормальный аудит с картой, документами, выводами, рисками, решениями и управлением.

Чтобы по каждому серверу было понятно: что на нём живёт, какие домены и сервисы на него завязаны, где данные, есть ли бэкапы, что торчит наружу, что нужно закрыть, что можно удалить, что нельзя трогать и кто и чем рискует, если мы дёрнем не тот провод.

В общем, я позвал Codex — в нашей рабочей драматургии его зовут Степан. И Степан сразу испортил мне удовольствие от хаоса.

«Сначала ничего не трогаем. Сначала считаем, смотрим, фиксируем. Любое геройство на сервере без карты — это не инженерия, а азартная игра с бэкапами».

Справедливо. Неприятно, но справедливо.

Сначала была панель, потом появился API

Я знал, что у TimeWeb есть API, и где-то на периферии сознания это знание лежало давно. Но, как часто бывает с такими вещами, я не придавал ему значения: панель же есть, в ней видно серверы, можно кликать, смотреть вкладки, открывать карточки.

Аудит через панель быстро превращается в ручную археологию: один скриншот, второй скриншот, третья вкладка, где-то забыли DNS, где-то непонятно с бэкапами, где-то название сервера не совпадает с тем, что реально внутри. Степан посмотрел на это и сказал:

«Панель хороша для человека. Но нам нужна не экскурсия, а инвентаризация. Давайте подключим API».

Мы подключили API TimeWeb аккуратно: без сохранения токенов в проекте, без вывода секретов в чат, без опасных действий, и сначала только чтение. Это важный момент — когда у вас есть API к облаку, очень легко почувствовать себя человеком с волшебной кнопкой, но волшебная кнопка в инфраструктуре обычно подписана мелким шрифтом: «Случайно удалить DNS», «Остановить production», «Сломать доступ». Поэтому первый принцип был простой: read-only, только смотреть и ничего не менять.

Через API мы собрали карту верхнего уровня — сколько VPS, какие проекты, какие диски, где включены бэкапы, какие домены и DNS-записи есть, какие firewall-группы подключены, какие ресурсы вообще существуют на стороне провайдера. И тут случился первый приятный момент: вместо ощущения «где-то там семь серверов» появилась таблица — не идеальная, но уже настоящая. Семь машин перестали быть облаком тумана и стали семью объектами с ролями, состояниями и вопросами.

Степан довольно сухо прокомментировал:

«Поздравляю, у нас появился список подозреваемых».

Оказалось, что API видит не всё

У API есть важное ограничение: он показывает облачный слой, но не показывает жизнь внутри сервера. Он может сказать, что вот VPS, вот диск, вот статус, вот бэкап, вот DNS, но он не скажет, что внутри кто-то пять месяцев назад поднял Docker Compose, оставил старую админку, забыл базу, включил сервис руками, положил .env не туда или развернул полезный, но никем не описанный рабочий контур.

Поэтому после API началась вторая часть: сервер за сервером, только read-only, через SSH, с паспортом каждого VPS. Мы смотрели не содержимое секретов, а саму структуру — какие процессы работают, какие сервисы запускаются через systemd, что поднято в Docker, где reverse proxy, какие публичные поверхности есть, где лежат данные, есть ли локальные базы, есть ли uploads, есть ли бэкапы и можно ли им доверять, где исходники, а где просто runtime-хаос, какие файлы выглядят чувствительными и какие сервисы уже мертвы, но продолжают занимать место и внимание.

Это было похоже на обход старого здания с планом БТИ, где план вроде есть, но на третьем этаже кто-то построил переговорку, в подвале стоит сервер с табличкой «не выключать», а из кладовки внезапно идёт production-трафик.

Что мы нашли

Самое интересное в таких аудитах — почти никогда не оказывается, что «всё плохо». Обычно оказывается сложнее: часть работает хорошо, часть работает случайно, часть опасна, часть вообще нельзя трогать, потому что она внезапно важная.

Мы нашли активные сервисы, которые действительно нужны, нашли серверы, которые нельзя выключать, нашли рабочие контуры сайта, контентного хаба, агентных сервисов, внутренних инструментов, старых и новых проектов. Нашли и неприятное: где-то не было нормальной уверенности в бэкапах, где-то наружу смотрели сервисы, которым лучше жить внутри, где-то доступы были устроены слишком широко, где-то старые маршруты и сертификаты продолжали висеть, хотя смысл уже уехал, где-то сервис падал и перезапускался по кругу, где-то логи и данные разрастались слишком уверенно, где-то код на сервере жил без понятного источника правды, а где-то было «трогать нельзя, там сейчас работает человек» — и это тоже важный результат аудита.

Последний пункт особенно важен. Аудит — это не уборка ради уборки: нельзя увидеть большой каталог и сказать «о, удаляем», сначала нужно понять, кто от этого зависит. Иногда самый правильный инженерный шаг — ничего не делать, а честно записать: «Сервер активен, владелец работы есть, изменения только после координации».

Степан в такие моменты становился почти занудным, но полезным:

«Мы не чистим неизвестное. Мы сначала превращаем неизвестное в известное. Потом решаем».

Это, кстати, хороший девиз для половины цифровой жизни.

Как Codex собирал картину

Работа шла не в стиле «зашёл на сервер, посмотрел пару команд, написал, что всё нормально» — мы сделали более скучную, но гораздо более ценную вещь и завели общий формат аудита. По каждому серверу появлялся отдельный dossier: что это за машина, что на ней работает, какие данные лежат, какие домены ведут туда, какие риски есть, что уже изменено, что не трогали и какое решение по серверу. Параллельно обновлялась общая карта всей инфраструктуры — не семь отдельных историй, а один связанный контур.

И вот здесь ИИ оказался не «чатиком, который советует команды», а рабочим партнёром. Codex держал контекст, сравнивал факты, не давал смешивать предположения с доказательствами, писал документы, фиксировал решения и каждый раз возвращал нас к дисциплине: сначала read-only, потом риск, потом предложение, потом отдельное согласование, потом изменение, потом проверка, потом запись в документы.

Это звучит медленно, но на практике это сильно быстрее хаоса — потому что вы не возвращаетесь по десять раз к вопросу «а почему мы это сделали?». Ответ уже записан.

Отдельный персонаж: Саркис

В этой истории был ещё один важный участник — Саркис. Саркис — это мой OpenClaw-агент, который живёт внутри моей инфраструктуры: не абстрактный «бот где-то в облаке», а рабочий агентный контур, с которым Codex теперь может общаться по MCP.

То есть у нас получилась довольно смешная, но очень практичная сцена: один ИИ-помощник помогает мне проводить аудит инфраструктуры и при необходимости обращается к другому ИИ-агенту, который уже живёт внутри этой инфраструктуры. Звучит как начало технического анекдота, но на практике это оказалось очень полезно. В разные моменты Степан обращался к Саркису, когда нужно было что-то уточнить, получить информацию, сверить контекст или понять, как отдельный агентный контур видит ситуацию со своей стороны.

Это не заменяло нормальный аудит через API и SSH, скорее это добавляло ещё один слой: не только «что показывает сервер», но и «что знает рабочий агент, который на этом сервере живёт и участвует в процессах».

Мне в этом нравится сама архитектурная мысль. Инфраструктура перестаёт быть набором немых машин — в ней появляются участники: серверы, сервисы, документы, API, агенты. Один агент может проверять карту, второй — быть частью рабочего контура, а человек остаётся тем, кто принимает решения и держит смысл.

Степан, конечно, сказал бы спокойнее:

«Саркис — не магия и не источник абсолютной истины. Но если в инфраструктуре уже есть агент, глупо не использовать его как ещё один канал контекста».

Вот так в нашем DevOps-аудите появилась почти командная работа: я, Codex, TimeWeb API, SSH, документы и Саркис, который иногда выглядывал из своего агентного мира и помогал понять, что происходит.

Где пришлось вмешаться

После read-only этапа появились места, где уже можно было действовать, но не одним большим движением «сейчас всё улучшим», а маленькими понятными шагами. Где-то мы включили или подтвердили бэкапы, где-то закрыли публичный доступ к сервисам данных, где-то остановили сломанный сервис, который бессмысленно перезапускался, где-то удалили старые маршруты, которые уже не должны были жить, где-то аккуратно поправили права на чувствительные файлы, где-то добавили системный ресурс, чтобы рабочий сервис меньше рисковал упасть от нехватки памяти, а где-то, наоборот, честно остановились: «Это активная зона, тут работает другой человек, ничего не трогаем».

Важный нюанс: я не публикую технические детали — не потому что хочется напустить тумана, а потому что инфраструктурная статья не должна становиться инструкцией «куда стучать». Достаточно смысла: были риски публичной поверхности, доступов, бэкапов, старых маршрутов, диска, источника правды и восстановления, и по каждому риску появились документы, решения и следующий шаг. То есть вместо «у нас где-то что-то крутится» появилось «мы знаем, что крутится, почему оно важно и что с этим делать».

Самое неожиданное: аудит оказался не про серверы

Точнее, не только про серверы. Я начинал с мысли, что нужно разобраться с TimeWeb, узнать, что где работает, навести порядок и получить контроль. А в процессе стало понятно: настоящий результат аудита — это не список машин, настоящий результат — возвращение управляемости.

Когда инфраструктура растёт рывками, особенно если её собирали разные люди в разные моменты, она легко становится «устной традицией»: кто-то помнит, где что лежит, кто-то знает, почему это нельзя выключать, кто-то когда-то включил бэкап, кто-то когда-то поднял сервис «временно», потом люди заняты, проекты меняются, а серверы продолжают жить. И в какой-то момент у бизнеса появляется странная зависимость от памяти людей и от удачи.

Аудит ломает эту зависимость — он превращает «кажется» в «проверено», «где-то» в «вот здесь», «лучше не трогать» в «не трогать до такого-то решения», «опасно» в «риск, приоритет, план». Для меня это было очень важное ощущение: я снова стал не просто владельцем счёта, а владельцем системы.

Что здесь сделал ИИ

Мне кажется, это хороший пример того, как ИИ реально полезен в инженерной работе. Не как магическая сущность, которая «сама всё сделала» — нет, я принимал решения, задавал границы, останавливал, когда нужно, давал согласование на изменения, уточнял контекст и выбирал, что важно. Но Codex сделал то, что человеку тяжело делать долго и внимательно: держал многоуровневый контекст, не уставал сверять факты, аккуратно вёл документы, отделял чтение от изменений, помнил, где нельзя печатать секреты, собирал повторяемый протокол, превращал хаос в карту и проверял результат после каждого действия.

Это не отменяет инженера, это делает инженерную работу более собранной. Степан, конечно, сформулировал суше:

«Я не заменяю владельца инфраструктуры. Я снижаю стоимость внимания, которое нужно, чтобы инфраструктура снова стала управляемой».

Вот за это я его и люблю: сначала звучит как документация к пылесосу, а потом понимаешь, что он прав.

Почему я об этом пишу

Потому что у многих похожая история, и не обязательно с TimeWeb. Может быть любой хостинг, несколько VPS, старые проекты, один сервер настраивал подрядчик, другой поднимал сотрудник, третий появился под тесты, четвёртый живёт с пометкой «там что-то важное». Снаружи всё выглядит нормально: сайты открываются, деньги списываются, панель зелёная. Но если вы не можете быстро ответить, что делает каждый сервер и что сломается при его остановке, значит у вас не инфраструктура, а надежда — а надежда иногда работает, но плохо масштабируется.

Я не призываю всех срочно бежать и всё переделывать, наоборот. Первый шаг — не менять, первый шаг — посмотреть, собрать карту, понять риски, зафиксировать, что живое, отделить активное от старого, найти данные, проверить бэкапы, увидеть публичные поверхности и сделать документы. А уже потом решать, что закрывать, что переносить, что усиливать, что архивировать и что оставить как есть.

Что получилось в итоге

После этого проекта у меня появилась нормальная карта семи серверов, и по каждому стало понятно, зачем он нужен, что на нём работает, какие есть риски и какие следующие действия возможны. Некоторые уязвимости были закрыты, некоторые старые хвосты убраны, некоторые сервисы остановлены, некоторые вещи, наоборот, получили статус «не трогать без отдельного решения», а главное — появилась привычка не относиться к инфраструктуре как к чёрному ящику.

Я отдельно ценю, что весь процесс был не героическим, а взрослым: без «сейчас быстро всё почистим», без «давайте на всякий случай перезапустим», без публикации секретов и без изменений там, где нет согласования. Так выглядит нормальная работа с цифровым хозяйством — скучно, аккуратно, с документами, но в итоге очень спокойно. Хотя, если честно, временами это было похоже на сериал: просто вместо погонь там были бэкапы, вместо подозрительных персонажей — старые сервисы, а вместо финальной сцены — таблица, в которой наконец всё понятно.

И ещё у этого проекта появился второй результат: я понял, что теперь могу делать такую работу не только для себя. Система уже налажена, есть понятный порядок: сначала безопасная инвентаризация, потом карта сервисов, потом риски, потом решения, потом точечные изменения только там, где они действительно нужны. Это можно быстро и качественно применять для клиентских серверов, особенно когда инфраструктура уже живёт несколько лет, собиралась разными людьми и давно просит не «переписать всё с нуля», а спокойно вернуть ей управляемость.

Для клиента это не звучит как «мы сейчас зайдём на сервер и что-нибудь улучшим», это звучит иначе: сначала разберёмся, что у вас реально работает, что критично, где данные, где бэкапы, где публичные риски, что можно закрыть, а что нельзя трогать без отдельного решения. А потом наведём порядок так, чтобы после нас осталась не магия, а документы, карта и понятный контроль.

Мой вывод

Инфраструктура не должна быть загадкой для владельца. Если у вас есть серверы, сайты, боты, базы, рабочие контуры, старые проекты и новые эксперименты, вам не обязательно всё помнить — но у вас должна быть система, которая позволяет быстро понять реальность.

Для меня таким способом стал аудит вместе c Codex: TimeWeb API, read-only проверки, серверные паспорта, документы, аккуратные согласованные изменения и постоянный вопрос «Что мы знаем точно?». Это, возможно, не самая эффектная формула, зато она работает.

А Степан в конце сказал:

«Теперь это не куча серверов. Теперь это инфраструктура».

И знаете что? В этот раз я бы с ним не спорил.

«Я всегда знал, что я в прошлом будущий DevOps»

По теме

• Статья: Как два ИИ-агента и один человек собрали этот сайт за ночь
• Блог: Почему OpenClaw — это не просто ещё один агент, а ваш цифровой напарник
• База знаний: Directus — headless CMS и backend как контентный хаб для мультисайтовой архитектуры

Если у вас тоже несколько VPS, разные подрядчики и ощущение, что инфраструктура где-то живёт без вас — приходите на консультацию. Спокойно разберёмся, что у вас реально работает, где риски и с чего начать, чтобы вернуть управляемость без переписывания всего с нуля.