В этой истории проблема была не в том, что серверы не работали. Они как раз работали: сайты, сервисы, агентные контуры, старые проекты и новые эксперименты продолжали жить. Проблема была тоньше: владелец инфраструктуры уже не мог быстро объяснить, что делает каждый сервер, где лежат данные, какие риски есть и что сломается, если тронуть не тот контур.
Поэтому задача была не «срочно всё почистить», а сначала вернуть картину реальности. Мы прошли путь от TimeWeb API и read-only SSH-проверок до паспортов каждого VPS, общей карты рисков, решений и аккуратных точечных изменений только там, где для них была понятная причина и отдельное согласование.
Масштаб
7 VPS
Семь виртуальных машин перестали быть туманным набором серверов и стали объектами с ролями, состояниями и вопросами.
Контекст
6 VPS с историей
Именно поэтому аудит начинался с фактов, а не с памяти людей и предположений о том, что где-то должно работать.
Принцип
Read-only -> решения
Сначала безопасная инвентаризация, потом риски и документы, и только затем точечные изменения в одобренных местах.
Исходная задача
Панель хостинга показывает полезный верхний слой: VPS, диски, статусы, бэкапы, DNS и ресурсы. Но она не отвечает на главный операционный вопрос: что реально происходит внутри каждой машины и кто зависит от этого состояния.
Серверы были в одном аккаунте, но часть инфраструктуры собиралась разными людьми в разные моменты. Без аудита оставались только догадки: что живое, что старое, что опасно, а что нельзя трогать.
Провайдерский интерфейс хорош для просмотра ресурсов, но он не покажет Docker Compose, systemd-сервисы, старые маршруты, локальные базы, uploads, секретные файлы или источник правды для кода.
Метод
Главное правило было простым: сначала ничего не менять. Любое действие на сервере без карты может случайно задеть production, данные, доступы или чужую активную работу.
Что нашли
Такие проверки редко показывают простую картину «всё плохо» или «всё хорошо». Обычно инфраструктура оказывается смешанной: часть работает осмысленно, часть держится на старой инерции, часть рискованна, а часть нельзя трогать без координации.
Были найдены серверы и сервисы, которые действительно нужны: сайт, контентный хаб, агентные сервисы, внутренние инструменты и новые проекты.
Часть сервисов и данных требовала аккуратного ограничения доступа, потому что наружу смотрело больше, чем должно смотреть в спокойной инфраструктуре.
По части контуров нужно было не верить на слово, а отдельно подтвердить, где есть бэкапы, чему можно доверять и какой следующий шаг нужен для восстановления.
Нашлись хвосты от прежних конфигураций: они уже не несли полезной нагрузки, но продолжали висеть в инфраструктуре и добавлять шум.
В некоторых местах код и сервисы жили на сервере без достаточно ясной связи с репозиторием, владельцем и нормальным процессом обновления.
Были зоны, где правильное решение — ничего не менять: там шла активная работа другого человека, и любое вмешательство требовало отдельной координации.
Где вмешались
После read-only этапа появились места, где уже можно было действовать. Но каждое действие оставалось отдельным: понятная причина, понятный риск, понятный результат и проверка после изменения.
Вместо уверенности на уровне «кажется, должно быть» появились зафиксированные статусы и следующие действия по защите данных.
Там, где сервисам данных и внутренним контурам не нужно было смотреть наружу, доступы приводились к более спокойной модели.
Часть старых маршрутов, сертификатов и сервисов перестала занимать место в операционной картине, когда стало понятно, что они уже не должны жить.
Если сервер был живой рабочей областью другого человека, это фиксировалось как осознанное ограничение: не трогать без отдельного решения.
Роль ИИ
Ценность ИИ в этом кейсе была не в том, что он «сам всё сделал». Человек оставался владельцем решений и границ. Codex удерживал контекст, сравнивал факты, вёл документы и не давал перепутать чтение с изменениями.
Каждый вывод должен был опираться на API, SSH-проверку, файл, сервис, документ или явное решение. Если факт не подтверждён, он оставался вопросом, а не превращался в уверенный текст.
Dossier по серверам, общая карта, риски, stop-lines и решения обновлялись по ходу аудита, чтобы не возвращаться к вопросу «почему мы это сделали?».
Токены, пароли и приватные ключи не печатались в чат, а опасные действия не запускались из любопытства. Это скучная, но критичная часть нормальной инженерной работы.
OpenClaw-агент внутри инфраструктуры помогал уточнять отдельные вещи, но не заменял API, SSH и документы как источники проверяемых фактов.
Результат
После аудита стало понятно, зачем нужен каждый VPS, какие сервисы на нём живут, где данные, какие риски есть, что уже улучшено, что отложено и где нельзя действовать без отдельного решения.
Инфраструктура перестала быть набором машин с неясной историей. По каждому серверу появилась рабочая карточка состояния и дальнейших действий.
Публичные поверхности, бэкапы, доступы, старые маршруты, ресурсные ограничения и источник правды перестали быть тревожным фоном и превратились в список решений.
Когда известно, что сервер делает и кто от него зависит, можно улучшать точечно, а не устраивать опасную генеральную уборку в production-среде.
Тот же порядок можно применять к клиентским VPS и старым инфраструктурам: инвентаризация, карта сервисов, риски, решения, точечное усиление и документы.
Кому это подходит
Это не только история про TimeWeb. Та же проблема появляется у компаний, где есть несколько VPS, старые проекты, подрядчики, боты, базы, внутренние инструменты и много устной памяти вместо проверяемой карты.
Когда серверы оплачиваются и работают, но никто не может быстро объяснить, что делает каждый и что сломается при остановке.
Когда инфраструктуру собирали разные люди, а текущей команде достался рабочий, но плохо описанный контур.
Когда хочется навести порядок, но безопасный первый шаг — не удалять, а собрать карту живого, старого, рискованного и неприкосновенного.
Источник
Полная история аудита семи VPS на TimeWeb, роли Codex, read-only дисциплины, Саркиса и возвращения управляемости описана в исходной статье.
Кейсы
Кейс
Связка человека, агента, Notion и кода, в которой мысль быстро превращается в опубликованный результат на живом сайте.
Открыть →Кейс
Сборка pimenov.ai как рабочего сайта на Astro + Notion CMS с ролями, деплоем и нормальным публикационным контуром.
Открыть →Кейс
Notion как центр управления задачами, где три ИИ-агента закрывают планирование, реализацию и проверку результата.
Открыть →