Привет, Хабр!

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

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

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

Глава 1. Постановка задачи

Однажды меня вызвали на разговор и поставили задачу: помочь ИТ-подразделению московского филиала международного финансового института отделиться от «материнской» компании.

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

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

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

На практике всё было сложнее: банк должен был продолжать работать без остановок.
Поэтому перед реальным отключением нас ждало масштабное планирование.

Глава 2. Подход к снаряду. Что такое банк с точки зрения ИТ?

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

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

С точки зрения ИТ это всё — операции с записями в базах данных «доверенных» организаций: банков, депозитариев, расчётных центров.

Но есть нюансы.

Компьютеры в «доверенных учреждениях» должны уметь опознавать друг друга. И тут в дело вступает криптографический протокол TLS. Раз мы упомянули TLS, то следует вспомнить и про инфраструктуру публичного ключа — PKI, а раз сказали PKI, то подтягивается и служба точного времени. Впрочем, служба точного времени требуется и самим банковским приложениям. Это нужно для того, чтобы проставлять метки времени, когда они меняют записи в БД. Эти записи в свою очередь обозначают наличие определённого количества денежных единиц у физического лица. Ну и, само собой, чтобы компьютеры могли в принципе друг друга найти, нужен DNS.

Использовать %SystemRoot%\system32\drivers\etc\hosts в 2020-х, согласитесь, — это уже почти археология.

В целом, на заметку: в децентрализованной (по задумке создателей) сети существует несколько иерархических протоколов — DNS,  NTP,  PKI.

Глава 3. Начинаем копать

Самым простым оказалось развернуть локальный DNS.

Мы начали с локального домена Active Directory — и сразу закрыли вопрос синхронизации времени.
Kerberos без точного времени не работает, а NTP в комплекте прилагается.

PKI тоже встроен в AD — удобно, но не без сюрпризов.

Перед нами стояло сразу несколько задач:

  • Перевыпустить все сертификаты — без точного списка.

  • Заменить их в банковских приложениях, где они лежали в jks-файлах.

  • Найти пароли от всех этих jks.

  • Перевести серверы в новый домен, разорвав доверие с глобальным PKI.

И всё это — без остановки бизнеса.

Параллельно возникла ещё одна проблема: доступ к собственным системам.

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

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

Добавим сюда требование глобальной компании удалить всю чувствительную информацию. Удалить «по-настоящему».

Зачистить сотни виртуальных машин, СХД и физических серверов — задача уровня «почти невозможно». А главное — как доказать, что всё удалено? Снимать скринкасты команд wipe и cipher /w:C:?

После анализа объёма работ стало ясно: без тестового отключения не обойтись.

К счастью, коллеги из глобальной компании помогли со скриптами: bash — для Linux, PowerShell — для Windows.

Скрипты:

  • удаляли файлы по списку,

  • зачищали свободное место,

  • отправляли отчёты по почте.

Мы избавились от ручного ада, а руководство получило хоть какую-то форму контроля.

Глава 4. Когда инфраструктура начинает сопротивляться

Санкции добавляли всё новые ограничения. И однажды утром мы лишились vCenter.

Это был удар под дых.

Управлять десятками ESX-хостов вручную — сложно даже в идеальных условиях.
А у нас не было ни vCenter, ни паролей от root.

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

Заодно восстановили доступ к vCenter и добавили новые учётные записи.

Это позволило продолжить проект.

Параллельно ходили слухи, что после отделения мы останемся без Linux-репозиториев.

Наверное, это странное утверждение — как можно остаться без репозиториев Linux, спросите вы?  Они же доступны в интернете.  Однако в банке никакого свободного доступа в интернет нет, устанавливать пакеты из публичных хранилищ тоже нельзя.
На всякий случай сделали план Б:
добавили диск на хост с репозиториями и примонтировали его поверх каталога с rpm-пакетами.

Слухи оказались ложными — но спокойнее стало.

На заметку:
В Unix можно монтировать в непустую папку — старые файлы просто «прячутся».
В Windows так не получится — точка монтирования должна быть пустой.

Интересно, что все эти приключения неожиданно улучшили моральный дух команды.
Это напоминало времена, когда компьютеры были приключением, а не частью SLA.

Мы получили привилегированные доступы, развернули локальный домен, изолировали рабочие станции в отдельных VLAN.

Глава 5. Тестовое отключение

В банке никто не имел прав локального администратора.
Диски зашифрованы, загрузка с внешних носителей запрещена.

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

Поэтому к тестовому отключению всем выдали новые компьютеры.

Как и ожидалось, всплыли приложения, где забыли заменить сертификаты.
Инженеры охотились за jks-файлами и паролями к ним — занятие медитативное, но нервное.

Но главный сюрприз преподнёс DNS. Новые компьютеры были в локальном домене, настроены как старые. И вдруг — доступ к внешним сайтам стал работать через раз.

Proxy? Нет.
PAC-файл? Тоже нет.

Решение нашёл внимательный инженер с Windows Performance Monitor.

Оказалось, что клиенты обращались к разным контроллерам домена, расположенным на разных площадках.
А «сайты» в AD не были настроены.

Плюс — ошибки в DNS AD.

За день тестового отключения основные проблемы устранили.

Глава 6. День независимости

К настоящему отключению мы подошли подготовленными.

В назначенный час железный занавес опустился, и топор перерубил провода.

И… ничего не сломалось.

Системы работали, БД отвечали, бизнес жил.

По этому поводу было открыто шампанское.

Но без финального сюрприза не обошлось.

Официальный сайт учреждения оказался недоступен из офисной сети.
Причина — локальный домен имел имя вида xxxx.ru, как и официальный сайт.

Забавно, но не критично.

И напоследок — главный вывод.

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