Когда честнее переехать на чистый сервер, чем разбирать старый

MAATRIX

Иногда легаси-сервер не нуждается в методичном разборе — ему нужна кремация. Есть системы, где месяц аккуратного картирования и маленьких обратимых шагов действительно снимает страх и возвращает контроль. А есть системы, где то же самое картирование через месяц упирается в стену: находок больше, чем в начале, часы капают, а уверенности не прибавляется. Разница между этими случаями видна не сразу, и цена ошибки — недели чужого времени на спасение того, что дешевле было просто заменить. Ниже — как отличить один случай от другого и посчитать это в деньгах, а не в ощущениях.

Два пути с чужим сервером: разобрать или переехать целиком

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

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

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

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

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

ОС или ключевые пакеты вышли из поддержки без пути обновления на месте. Debian 8-9, Ubuntu 14.04-16.04, CentOS 6-7, PHP 5.x, MySQL 5.5 — если апстрим давно не выпускает патчи безопасности, а обновление дистрибутива «на живую» рискует уронить половину зависимостей, вы чините не сервер, а прошлое десятилетие. Проверить версию и дату конца поддержки:

cat /etc/os-release
lsb_release -a
dpkg -l | grep -i php   # или rpm -qa | grep php

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

ss -tulpn | grep LISTEN | wc -l     # сколько портов слушает система
crontab -l -u root; for u in $(cut -f1 -d: /etc/passwd); do crontab -l -u "$u" 2>/dev/null; done | wc -l
find / -maxdepth 3 -name "*.conf" -newer /etc/hostname 2>/dev/null | wc -l

Диск и логи показывают годы бесконтрольного роста. du -sh /var/log, разросшийся на десятки гигабайт без ротации, база данных без вменяемого партиционирования и вакуума, /tmp с файлами трёхлетней давности — всё это симптомы того, что систему не просто не трогали, за ней не следили годами. Проверка:

du -sh /var/log /var/lib/mysql /var/lib/postgresql /tmp 2>/dev/null
find /tmp /var/tmp -type f -mtime +365 | wc -l

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

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

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

Считаем в часах: стоимость разбора против стоимости переезда

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

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

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

Риск для бизнеса: цена месяцев неопределённости

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

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

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

Скорость разработки и найм упираются в легаси. Новый инженер первым делом натыкается на систему, которую «лучше не трогать» и в которой никто толком не разбирается. Это удлиняет онбординг, увеличивает bus factor и снижает привлекательность работы в проекте.

Каждый месяц отсрочки — упущенная альтернатива. Часы, потраченные на археологию в чужих cron-скриптах, не тратятся на продуктовую работу. Если разбор растягивается на кварталы, стоит спросить: что бы эта же команда сделала за то же время на новом, понятном сервере, вместо того чтобы разгадывать назначение fix_tmp.sh?

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

Когда разбор всё-таки выгоднее переезда

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

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

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

У вас нет ресурсов поднять параллельную инфраструктуру даже на время переезда. Полноценный переезд требует, чтобы старый и новый сервер какое-то время существовали одновременно. Если бюджета или мощностей на это временно нет, а сервер пока стабилен, — разумнее сначала снизить риск на месте (закрыть уязвимости, навести порядок в cron и firewall), а переезд запланировать отдельным проектом, когда ресурсы появятся.

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

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

Как спланировать честный переезд на чистый сервер

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

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

Шаг 2. Поднимите новый сервер с нуля по актуальному стеку, без попытки воспроизвести старые костыли — свежая ОС в поддержке, актуальные версии рантайма и БД, конфигурация под версионным контролем с первого дня. Чистый сервер, который вы поднимаете осознанно, не унаследует ни один из пяти признаков руин из второго раздела просто потому, что вы строите его заново.

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

Шаг 4. Держите старый сервер в режиме read-only ещё некоторое время после переключения, прежде чем выключать его насовсем. Это дешёвая страховка: если после переезда обнаружится забытая зависимость — данные из старого хранилища, скрипт, который дергал внешний API со старого IP, — у вас будет источник, откуда её восстановить, вместо того чтобы разгадывать её с нуля.

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

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

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