Карта инфраструктуры с нуля: описываем чужое хозяйство за неделю

MAATRIX

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

Чем это отличается от карты за вечер

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

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

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

Прежде чем начинать, заведите рабочее место для находок — репозиторий с markdown-файлами, страницу в вики, таблицу — неважно что именно, важно, чтобы записи копились с первого часа, а не восстанавливались по памяти в пятницу.

День 1: сколько вообще есть серверов и что на каждом запущено

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

Источники, где искать полный список:

• личные кабинеты у хостинг-провайдеров и облаков (спросите бухгалтерию или посмотрите историю платежей по картам компании — обычно там всплывают провайдеры, о которых никто не вспомнил сходу);
• файл ~/.ssh/config у предыдущего администратора — там часто перечислены все хосты с алиасами;
• DNS-записи существующих доменов — A/AAAA-записи указывают на реальные IP, а значит и на реальные серверы, даже если о них забыли (см. следующий день);
• старые тикеты в техподдержку, счета на почте, файлы .pem/.ppk в бэкапах ноутбука предшественника.

На каждый найденный сервер заведите строку в общей таблице:

Дальше по каждому серверу пройдитесь тем же быстрым проходом, что описан в карте за вечер: ps auxf, systemctl list-units --type=service --state=running, docker ps -a, ss -tulpn, конфиги nginx/Apache, базы данных, cron и таймеры. Разница в том, что здесь это не самоцель одного вечера, а один из пяти рабочих потоков недели — отведите на каждый сервер фиксированный бюджет времени (час-полтора для типового веб-сервера, больше для машины с десятком сайтов и баз), и не позволяйте себе увязать в разборе одной находки в ущерб остальным серверам.

Результат первого дня — таблица серверов плюс краткая карта сервисов по каждому. Это ещё не полная инфраструктура: домены и внешние сервисы пока не учтены.

День 2: домены, DNS и сертификаты

Второй день — домены. Это отдельный слой, который живёт своей жизнью независимо от серверов: домен может быть зарегистрирован у одного регистратора, DNS может обслуживаться у другого провайдера, а указывать записи могут на третий сервер, давно выведенный из эксплуатации.

Откуда брать список доменов:

• аккаунты у регистраторов — часто их несколько, потому что домены покупались в разное время разными людьми;
• вывод certbot certificates на каждом сервере из первого дня — сертификаты называют реальные домены, даже если конфиг веб-сервера успел устареть;
• DNS-зоны, если у вас есть доступ к панели DNS-провайдера — там же видны поддомены, про которые никто не помнит;
• WHOIS по уже известным доменам — иногда вскрывает контактный email, по которому находится ещё пачка доменов на том же аккаунте.

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

whois example.com | grep -iE "registrar|expir"
dig NS example.com +short
dig A example.com +short

Соберите вторую таблицу:

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

Не забудьте о доменах, которые ни на что не указывают, но продолжают оплачиваться — площадки для будущих проектов, старые бренды, домены-опечатки, купленные ради защиты. Их тоже стоит внести, пометив, что они «припаркованы», а не забыть как несуществующие.

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

День 3: внешние сервисы и интеграции

Третий день — то, что физически не находится ни на одном из ваших серверов, но от чего зависит работа всего хозяйства: почтовые сервисы, платёжные шлюзы, CDN, объектные хранилища, системы мониторинга, аналитика, сервисы отправки SMS и push-уведомлений, сторонние API.

Прямого способа получить полный список нет — приходится собирать его из нескольких источников одновременно:

# ищем ключи и упоминания внешних доменов в конфигах приложений на каждом сервере
grep -rEi "API_KEY|SECRET|TOKEN|_URL=" /var/www/*/.env 2>/dev/null
grep -rl "amazonaws\|cloudflare\|stripe\|sendgrid\|twilio" /var/www/*/ 2>/dev/null

DNS-записи тоже подсказывают внешние сервисы даже без доступа к коду — TXT-записи с SPF почти всегда называют реального отправителя почты, DKIM-селекторы указывают на конкретный email-сервис:

dig TXT example.com +short
dig TXT default._domainkey.example.com +short

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

ss -tnp state established | awk '{print $5}' | sort -u

По каждому найденному сервису — своя строка в таблице:

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

День 4: доступы, секреты и кто чем управляет

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

По каждому серверу из первого дня:

for u in $(cut -f1 -d: /etc/passwd); do
  echo "== $u =="
  cat "/home/$u/.ssh/authorized_keys" 2>/dev/null
  cat "/root/.ssh/authorized_keys" 2>/dev/null
done

Поле-комментарий в конце SSH-ключа (user@hostname) часто подсказывает, кому ключ принадлежал изначально — но доверять ему на сто процентов нельзя, комментарий можно было скопировать вместе с чужим ключом. Сверяйте список ключей с реальным списком людей, которые должны иметь доступ, и явно фиксируйте расхождения.

По панелям и аккаунтам — хостинг, регистраторы, облачные консоли, сервисы из третьего дня — пройдитесь по списку пользователей/участников в каждом личном кабинете, где это возможно, и запишите, кто там числится администратором. Отдельно стоит пометить:

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

Итог четвёртого дня — не сам список паролей (в общем документе карты инфраструктуры секретам в открытом виде не место), а карта того, где эти секреты хранятся и кто ими управляет: «доступ к prod-web-1 — в общем хранилище паролей команды, владелец — вы», «доступ к аккаунту регистратора — известен только уволенному сотруднику, требует восстановления». Сама таблица секретов и то, как её вести дальше, — тема отдельная и выходит за рамки одной недели документирования; здесь важно зафиксировать сам факт «где что лежит и кто имеет право доступа».

День 5: собираем итоговый документ

Пятый день не про сбор новых данных, а про то, чтобы четыре предыдущих дня превратились в один связный документ, а не остались четырьмя разрозненными таблицами в разных файлах.

Разумный скелет итогового документа:

1. Обзор
   - сколько серверов, доменов, внешних сервисов всего
   - что критично, что второстепенно
2. Серверы (таблица из дня 1 + карта сервисов по каждому)
3. Домены и сертификаты (таблица из дня 2)
4. Внешние сервисы и интеграции (таблица из дня 3)
5. Доступы: кто чем управляет, где хранятся секреты (день 4)
6. Открытые вопросы: всё, что помечено «неизвестно» или «требует выяснения»
7. Дата последнего обновления и ответственный за поддержку документа

Формат самого документа — на ваше усмотрение (markdown в git-репозитории, страница в вики компании, документ с контролем версий), но два свойства обязательны в любом варианте: доступ к нему должен быть у всех, кому он реально нужен, а не только у автора, и в нём должна быть видна дата последнего обновления — недельная карта, которую никто не открывал год, немногим полезнее её отсутствия.

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

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

Частые вопросы