Слияние двух инфраструктур после покупки бизнеса

MAATRIX

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

Аудит безопасности обеих сторон — до, а не после объединения сетей

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

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

Практический чек-лист аудита для КАЖДОЙ стороны отдельно, до начала любых сетевых работ:

• Инвентаризация: полный список серверов, их ролей, версий ОС и открытых портов. Быстрая проверка внешней поверхности — nmap -sV -p- <публичный_IP> по каждому хосту с внешним адресом.
• Статус обновлений: когда последний раз накатывались патчи безопасности, есть ли автообновления вообще.
• Учётные записи: сколько людей имеют root/admin-доступ, включена ли MFA, живы ли ещё аккаунты уволенных сотрудников — это частая находка при аудите купленной компании.
• Бэкапы: не просто «есть ли бэкап», а был ли хоть раз протестирован реальный restore.
• Логи и мониторинг: пишутся ли логи доступа, куда, на какой срок.
• Прогон автоматического аудита конфигурации — lynis audit system на репрезентативной выборке серверов с обеих сторон, с сравнением итоговых score.

Если по итогам аудита разрыв в зрелости большой — это не повод останавливать сделку, но повод растянуть сроки сетевого объединения и сначала подтянуть слабую сторону до приемлемого минимума (патчи, MFA, закрытие лишних портов). Подробный процесс подготовки к такой проверке разобран в статье как подготовить сервер к аудиту безопасности.

Зафиксируйте результат аудита письменно — это документ, на который вы будете опираться, когда через полгода кто-то спросит «а мы точно проверяли инфраструктуру Б перед тем, как открывать к ней доступ из сети А».

Конфликты имён и адресных пространств

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

IP-адреса. Классика: обе стороны используют 192.168.1.0/24 для офисной сети или 10.0.0.0/16 для VPC. Пока сети не соединены — конфликта нет. В момент, когда вы поднимаете site-to-site VPN или peering, у вас появляются два хоста с одинаковым адресом в разных сетях, и роутинг просто не знает, куда слать пакет.

Варианты решения, от быстрого к правильному:

На практике разумно начать с NAT как временного моста на период проекта, но сразу планировать перенумерацию менее критичной стороны (обычно — той, где меньше внешних интеграций и захардкоженных адресов). Прежде чем переносить что-либо, задокументируйте оба адресных пространства в одном месте — вручную в таблице этого хватит для двух-трёх десятков подсетей, а для сотен хостов и VLAN проще поднять IPAM-инструмент вроде NetBox, который сразу подсветит пересечения. Установка разобрана в статье как установить и настроить NetBox на VPS.

Внутренние доменные имена. Похожая история с DNS: обе компании называют внутреннюю зону corp.local, intra.company.com или просто local. При объединении DNS-серверов один из corp.local побеждает, второй начинает резолвиться неправильно или вообще перестаёт. Решения:

• Split-horizon DNS с условной пересылкой (conditional forwarding): каждая сторона сохраняет свою зону, но добавляет forwarder на DNS-сервер другой стороны для конкретных доменов.
• Полное переименование зоны одной из сторон (например, corp.local → legacy.corp.local) с постепенной заменой ссылок — больнее, но чище на дистанции.
• Централизация на одном DNS-сервере с делегированием зон — хорошо работает, если планируется глубокая интеграция, а не временное сосуществование.

Имена баз данных и сервисов. Если обе компании называли основную БД production или app_db, а инстансы БД планируется когда-либо объединять на одном сервере (даже просто для миграции) — переименование потребуется заранее, иначе pg_restore или простое копирование дампа затрёт данные другой стороны. Правило простое: прежде чем что-то объединять физически, убедитесь, что имена уникальны хотя бы в рамках целевого окружения.

Разные технологические стеки: унифицировать или интегрировать

Почти всегда у двух независимо выросших компаний разные стеки под похожие задачи: одна на PostgreSQL и Python, другая — на MySQL и PHP; один бэкенд — монолит на Django, другой — набор Node.js-сервисов. Дальше два реалистичных пути, и однозначно правильного нет — выбор зависит от бизнес-приоритетов, а не только от техники.

Путь А — унификация на один стек. Полная миграция более слабой (по вашей оценке) стороны на стек другой. Плюс — на дистанции один стек дешевле поддерживать, не нужно держать в команде экспертизу по двум СУБД и двум фреймворкам. Минус — это отдельный, часто многомесячный проект с реальным риском для данных и функциональности: перенос бизнес-логики между языками почти никогда не бывает механическим, а миграция боевой БД с одного движка на другой — это risk-проект сам по себе, с планом отката и тестовым прогоном на копии данных. Для собственно переноса самой базы с минимальным простоем пригодится подход из статьи перенос большой базы с минимальным даунтаймом — но там речь о переносе одной и той же СУБД на новый сервер, а смена движка (MySQL → PostgreSQL и обратно) — на порядок сложнее и требует ручной сверки типов данных и поведения запросов.

Путь Б — сосуществование через интеграцию. Обе системы остаются как есть, между ними строится интеграционный слой: REST/gRPC API, очередь сообщений (RabbitMQ, Kafka) для событий, которые должны быть видны обеим сторонам. Плюс — намного быстрее и безопаснее в моменте, каждая команда продолжает работать в привычном стеке. Минус — вы навсегда (или надолго) берёте на себя эксплуатационные расходы двух стеков одновременно, и интеграционный слой сам становится точкой отказа, которую нужно мониторить отдельно.

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

Дублирующиеся сервисы: мониторинг, CI/CD, тикеты

У каждой компании к моменту сделки уже есть своя система мониторинга, свой CI/CD и своя система тикетов/хелпдеска. Держать всё это в двух экземплярах бесконечно — дорого и неудобно (два места, куда смотреть при инциденте — это гарантированная задержка реакции). Но консолидация означает миграцию данных и процессов той стороны, чью систему не выбрали, а это тоже стоит времени и вызывает сопротивление команды, которая теряет привычный инструмент.

Практичный порядок:

1. Мониторинг и алерты. Обычно первое, что стоит объединить — само по себе не критично для продакшена, а видимость всей инфраструктуры в одном месте (Grafana + Prometheus, Zabbix — не так важно, какой инструмент победит) резко снижает риск «слепых зон» на следующих, более рискованных этапах.
2. Коммуникация. Один общий канал (Slack/Mattermost) с алертами обеих систем мониторинга, пока они не объединены — дешёвый способ убрать разрозненность до того, как технические системы физически слиты.
3. CI/CD. Консолидация на одну систему (например, GitLab CI вместо Jenkins с одной из сторон) — задача среднего риска: неправильно перенесённый пайплайн деплоя может сломать релизный процесс, но откатить его проще, чем откатить слияние баз данных.
4. Тикет-система / хелпдеск. Технически не самая сложная миграция, но самая политически чувствительная — здесь решение часто принимает не техдиректор, а руководитель поддержки, и стоит закладывать время на согласование процессов, а не только на перенос данных.

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

Порядок работ: с наименее рискованного к наиболее рискованному

Главная ошибка — начинать с самого заметного («объединить сети или базы данных, чтобы было единое целое»), а не с самого безопасного. Рекомендуемая последовательность:

1. Инвентаризация и аудит безопасности обеих сторон (см. первый раздел) — без сетевых изменений, только сбор информации.
2. Общий канал коммуникации и общий мониторинг/статус-страница — минимальный риск, максимальная польза для координации следующих шагов. Пример: единая Uptime-страница для обеих команд, чтобы все видели одну картину состояния сервисов.
3. План устранения конфликтов имён и адресов (какая сторона перенумеровывается, какие домены переименовываются) — согласуется и документируется, но пока не применяется в проде.
4. Пилотный сетевой мост в тестовом окружении. Site-to-site VPN между копиями инфраструктур (staging), а не между продакшенами — здесь ловятся реальные конфликты маршрутизации без риска для клиентов.
5. Консолидация CI/CD, если решение принято, — на этом этапе команды уже привыкли к общей коммуникации из шага 2.
6. Продакшен сетевое объединение — только после того, как аудит закрыт, конфликты адресов устранены хотя бы частично, а пилот в тестовом окружении прошёл без сюрпризов.
7. Консолидация продакшен баз данных — самый рискованный этап, делается последним и как отдельный проект с полным планом отката, а не «заодно» с сетевым объединением.

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

Техника сетевого объединения: VPN, маршрутизация, файрвол

Когда план готов и пилот в тестовом окружении пройден, само сетевое объединение обычно строится на site-to-site VPN между площадками — самый предсказуемый вариант для двух независимых инфраструктур, которые не обязаны доверять друг другу полностью с первого дня.

Пример минимальной конфигурации WireGuard для сайта А (аналогично зеркалится для сайта Б), с явным ограничением AllowedIPs только теми подсетями, которые реально нужны на первом этапе — не «всё на всё»:

[Interface]
PrivateKey = <ключ_сайта_А>
Address = 10.200.0.1/30
ListenPort = 51900

[Peer]
PublicKey = <публичный_ключ_сайта_Б>
Endpoint = <внешний_IP_сайта_Б>:51900
AllowedIPs = 10.20.0.0/24, 10.20.5.0/24
PersistentKeepalive = 25

Обратите внимание: в AllowedIPs перечислены не все внутренние сети партнёра, а конкретные подсети — например, только сегмент с сервисами мониторинга и репликации БД. Полное открытие маршрутизации между всей сетью А и всей сетью Б в первый день — частая причина инцидентов: скомпрометированная рабочая станция в одной сети внезапно получает сетевой доступ к продакшену другой. Подробнее про построение такого моста между площадками — в статье site-to-site VPN между офисами на WireGuard.

На уровне файрвола после поднятия туннеля явно ограничьте, какие порты и с каких адресов доступны через него, вместо политики «доверяем всему трафику из туннеля»:

# nftables, пример для сегмента мониторинга
add rule inet filter forward ip saddr 10.20.5.0/24 ip daddr 10.10.5.0/24 tcp dport { 9090, 3000 } accept
add rule inet filter forward ip saddr 10.20.0.0/24 ip daddr 10.10.0.0/24 drop

Расширяйте список разрешённых маршрутов постепенно, по мере того как конкретные интеграции согласованы и протестированы, а не выдавайте доступ «про запас». Для DNS, если выбрали путь split-horizon, каждая сторона добавляет условный forwarder на зону другой стороны только через туннель — так внутренние имена резолвятся без вынесения их в публичный DNS.

Для пилота или переходного периода нейтральный сервер вне обеих существующих инфраструктур — например, под промежуточный DNS-forwarder или staging-копию одной из систем — проще арендовать отдельно, чем городить временное решение поверх продакшен-серверов одной из сторон.

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