Инфраструктура выросла стихийно: собираем реестр серверов, доменов и доступов

MAATRIX

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

Почему так получается и когда это становится проблемой

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

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

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

Платежи — самый надёжный источник правды

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

Практический порядок:

• Поднимите выписки по всем корпоративным картам и счетам минимум за 12-24 месяца — часть сервисов выставляет счёт раз в год, и месячная выписка их просто не покажет.
• Отфильтруйте строки по ключевым словам: названия известных провайдеров, «hosting», «cloud», «domain», «registrar», «VPS», «SSL», а также по характеру суммы — регулярные небольшие списания раз в месяц почти всегда что-то техническое (домен, хранилище, мониторинг, SaaS), а не разовая покупка.
• Отдельно проверьте платежи в криптовалюте, если в компании так платят за часть сервисов — история транзакций кошелька так же надёжна, как выписка, и часто содержит то, что не попало в «официальную» бухгалтерию именно потому, что проходило в обход обычного счёта.
• Если карт и счетов несколько (личная карта сотрудника, корпоративная, карта бывшего партнёра) — пройдите по каждой отдельно. Именно на стыке разных источников оплаты чаще всего теряются записи: то, что оплачивал уволившийся человек с личной карты «пока не оформим на компанию», невидимо для всех, кто смотрит только корпоративный счёт.

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

Панели управления: пройтись по каждой на предмет всего активного

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

Практический чек-лист по каждому известному провайдеру:

• Список активных серверов/инстансов целиком, а не только тех, что на слуху. В панели часто есть машины, о которых последний раз вспоминали при их создании — тестовые, staging, «резервные», оставленные после миграции.
• Раздел биллинга и история счетов, а не только текущий баланс. История счетов обычно глубже памяти команды: там видны сервисы, которые уже выключены как ресурс, но продолжают тянуть плату за смежное — снапшоты, зарезервированные IP, хранилище с бэкапами.
• Привязанный способ оплаты в панели — сверьте с картой из выписки. Если он не совпадает ни с одной известной картой, аккаунт заводил кто-то, чьи данные оплаты вы ещё не нашли, — повод вернуться на шаг с платежами.
• Список пользователей внутри самой панели, отдельно от доступов на серверах. У облачного аккаунта может быть несколько человек с полным доступом, о которых никто, кроме провайдера, не вспомнит без явной проверки.

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

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

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

Порядок действий:

• Пройдите по каждому известному регистратору лично — список доменов в личном кабинете, а не по памяти. Если аккаунтов несколько (личный сотрудника, корпоративный, от старого проекта) — по каждому отдельно.
• Сверьте список доменов со списком плательщиков из выписки — регулярные некрупные списания раз в год с формулировкой вроде «renewal» почти всегда домен, который иначе легко пропустить.
• Для каждого найденного домена проверьте, куда он реально указывает — не по документации (её может не быть), а по факту:

dig +short example.com A
dig +short example.com CNAME
whois example.com | grep -i "registrar\|expir"

• Если DNS-запись указывает на IP, которого нет в списке серверов из панелей с предыдущего шага, — вы нашли ещё одну машину. Это одна из самых частых находок при первой сборке реестра: домен есть, сервер за ним есть, но сервер физически у провайдера, который в списке ещё не фигурировал.
• Отдельно зафиксируйте дату истечения и текущего плательщика по каждому домену — этого достаточно для реестра на первом проходе. Более подробный разбор доменной части (кто платит, куда приходит уведомление, напоминания по нескольким порогам) — в статье реестр доменов и сертификатов.

Опросить всех, кто когда-либо касался инфраструктуры

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

Практические наблюдения, которые делают опрос полезным, а не формальностью:

• Спрашивайте конкретно, а не общо. Вопрос «ты что-нибудь помнишь про наши серверы» почти всегда даёт «нет, вроде всё знаю» — человек не находит зацепку без контекста. Вопрос «ты регистрировал какие-нибудь домены или тестовые VPS, может, на свою карту, чтобы быстро проверить идею» — даёт совсем другой уровень ответов, потому что называет конкретную ситуацию.
• Не ограничивайтесь текущей командой. Бывшие сотрудники и подрядчики, если с ними можно связаться, часто держат в памяти именно те системы, которые не пережили их уход в документации, — потому что настраивали их лично и в одиночку.
• Поднимите переписку и почту как источник. Поиск по старым чатам и письмам по словам «домен», «сервер», «VPS», «регистратор», «счёт» часто всплывает быстрее, чем ответ человека, который уже сам не помнит деталей.
• Относитесь к устным находкам как к гипотезам, а не фактам, пока не подтвердите их платежом, панелью или DNS-записью. «Кажется, там был ещё один сервер для аналитики» — повод проверить по первым трём источникам, а не строка, которую сразу заносят в реестр как подтверждённую.

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

Структура реестра: минимум полей, максимум дисциплины

К этому моменту накопился сырой список: строки из выписки, серверы из панелей, домены из регистраторов, обрывки из разговоров. Дальше — свести это в единый реестр. Главная ошибка на этом шаге — не выбор неправильного инструмента, а попытка сразу спроектировать идеальную схему с двадцатью полями и связями между таблицами. Такой реестр никто не заполнит до конца, а незаполненный реестр бесполезен так же, как его отсутствие.

Минимально необходимые поля, без которых запись не работает:

Этого достаточно для рабочего реестра — простая таблица в Google Sheets или CSV в git-репозитории справляется не хуже специализированного инструмента, особенно на старте. Форма хранения решает меньше, чем факт, что реестр реально ведётся и проверяется, а не заполняется один раз и забывается — с этим риском справляется отдельный ритуал, разобранный в статье как поддерживать документацию инфраструктуры актуальной: тот же принцип регулярной сверки применим и к реестру целиком.

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

Как не допустить повторного стихийного роста

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

Практически это выглядит так:

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

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