План разбора легаси на 30 дней: от описи до переезда на новый сервер

MAATRIX

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

30 дней вместо бессрочного «когда-нибудь разберёмся»

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

Логика плана — от неизвестного к решению, а не от решения к деталям:

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

Неделя 1: опись и карта рисков (дни 1-7)

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

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

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

Отдельно в опись обязательно входит ревизия периодических задач — легаси-серверы славятся cron-скриптами и systemd-таймерами, о назначении которых никто не помнит, но которые продолжают что-то делать каждую ночь. Полный чек-лист мест, где прячется автозадача помимо очевидного crontab -l — cron.d, spool-каталоги, anacron, systemd timers — разобран в статье «Чужие cron-задачи: разбираем расписание, которое никто не помнит». Каждую найденную задачу заносите в общую таблицу со статусом «требует проверки» — трогать её в первую неделю рано, задача пока просто фиксируется.

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

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

Неделя 2: аудит доступов и безопасности (дни 8-14)

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

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

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

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

Если на сервере есть веб-приложение с папкой загрузок — проверьте её на посторонние PHP-файлы, оставленные прошлыми взломами или неаккуратными подрядчиками; как искать веб-шеллы среди легитимных загрузок и закрыть исполнение PHP в uploads — в статье «Веб-шелл в папке uploads: как найти чужой php среди своих».

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

Неделя 3: документирование и развилка — чинить или переезжать (дни 15-21)

Третья неделя — не про новые находки, а про то, чтобы превратить две недели разрозненных заметок в один документ и принять на его основе решение.

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

Отдельного внимания заслуживает база данных без схемы — типичная ситуация, когда таблицы называются tmp2, old_users_v3 и test_dont_delete, и непонятно, что из них ещё живое. Как в этом разобраться — в статье «Чужая база без схемы и документации: как понять, что в ней ещё живое».

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

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

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

Заканчивать неделю 3 нужно с зафиксированным письменно решением, а не с ощущением «наверное, стоит переехать». Решение — это конкретный вход в неделю 4.

Неделя 4, вариант А: чистим легаси на месте (дни 22-30)

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

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

Неделя 4, вариант Б: начинаем миграцию на новый сервер (дни 22-30)

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

Ключевой принцип переезда без риска для работающего сервиса — не переключать домен, пока копия на новом сервере не поднята и не проверена по IP; пошаговый порядок с синхронизацией данных и переключением DNS без даунтайма разобран в статье «Перенос сайта на новый VPS без простоя». Документ недели 3 — список сервисов, доменов, интеграций и доступов — становится чек-листом для переноса: переезжает то, что реально описано и понятно, а не сервер «как есть» вслепую, вместе со всеми нерасшифрованными костылями.

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

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

Как подстроить план под свою ситуацию

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

Маленькую инфраструктуру (один сервер, несколько сервисов) недели 1 и 2 реально сжать до трёх-четырёх дней каждая, а освободившееся время перенести на неделю 3, чтобы решение принималось без спешки. Большую инфраструктуру (десятки серверов, годы наслоений без документации) 30 дней покроют только первым проходом по самому критичному, а полное покрытие потребует второй итерации того же цикла — тогда в конце недели 1 стоит явно расставить приоритеты.

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

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

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