Весной 2022 года наша команда столкнулась с нестандартной задачей: за две недели нужно было перенести всю ИТ-инфраструктуру крупного производственного предприятия из-под контроля иностранного менеджмента в российскую юрисдикцию. На кону стояла непрерывность работы завода: от заводских станков до систем учета и документооборота.

Меня зовут Константин Ким, я эксперт по сетевым технологиям ИТ-интегратора К2Тех. В этой статье я расскажу, как мы в условиях хаоса и начинающейся паники перенесли все критически важные системы заказчика в Россию и забрали управление всем оборудованием. Вы узнаете о технических особенностях миграции Active Directory, восстановлении доступа к сетевому оборудованию Cisco и Aruba, а также о психологической поддержке построении доверительных отношений с заказчиком в кризисной ситуации.

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

Ситуация — SOS 

В 2022 году на фоне всем известных событий иностранный менеджмент решил отключить очень крупный российский завод от ИТ-инфраструктуры. Они предупредили сотрудников о прекращении работы в РФ, но почему то забыли рассказать, как будет происходить передача управления.

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

И вот за две недели до часа X руководство российского завода обратилось к нам за помощью. Нам предстояло обеспечить непрерывность производства, после отключения зарубежных систем. Работы начались немедленно.

Оцениваем ситуацию и составляем план

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

Выяснилось, что ИТ-инфраструктура и корпоративные системы предприятия располагались на трех площадках: в облаке Microsoft, в офисах рядом с производством в России и на серверах в Европе. Локальная сеть работала по технологии SD Access под управлением контроллеров в Европе.

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

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

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

Как поведут себя европейские коллеги, было еще неясно, поэтому мы рассматривали два сценария развития событий: 

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

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

На начальном этапе проекта руководство заказчика было сильно обеспокоено ситуацией. Основным источником стресса для них был даже не второй сценарий, а банально - неопределенность. 

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

Приступаем к работе

Инфраструктура заказчика включала три ключевые локации: производственный комплекс в одном из регионов, склад готовой продукции в Подмосковье и центральный офис в Москве. Все объекты были объединены корпоративными каналами передачи данных с головным офисом в Европе. Прекращение взаимодействия с европейской стороной означало разрыв этих соединений. Нужно было установить каналы связи между российскими площадками напрямую.

Отдельной задачей стало восстановление системы аутентификации пользователей. Существующая схема использовала доменную авторизацию с парой логин-пароль и цифровыми сертификатами. Чтобы сохранить ее работоспособность, нужен был новый локальный сервер домена. Еще одной важной задачей стал перезапуск корпоративного DNS-сервера.

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

• доменная структура DC-AD;

• сопутствующие инфраструктурные сервисы;

• сервисы печати (принт сервер); 

• система документооборота;

• терминальные серверы RDS. 

А также серверы баз данных и приложений 1С, на которых профильный подрядчик осуществляет разработку и воссоздание систем ERP + MES на платформенных решениях от 1С.

Все под контролем? 

Успехи в развертывании инфраструктуры создали ощущение контроля над ситуацией. Ситуация парадоксально изменилась: теперь нам приходилось не успокаивать заказчика, а мотивировать на более активное участие в проекте.

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

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

Инфраструктура заказчика включала оборудование Cisco и Aruba, оснащенное встроенным сервисом Password Recovery. В крайнем случае мы могли бы использовать этот механизм, чтобы восстановить доступ к устройствам. Однако этот метод мог привести к частичной потере конфигураций, так что мы рассматривали его, только как запасной вариант.

Но главной задачей стало получение доступа к ядру локальной вычислительной сети завода. Масштаб производственной территории и многообразие сетевых сервисов делали восстановление конфигурации критически сложным. Техническая служба обладала только базовым пониманием схемы IP-адресации, без детальной логической топологии сети. Восстановление такой инфраструктуры вслепую могло затянуться на недели.

Восстанавливаем доступ к оборудованию

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

Полученные реквизиты позволили восстановить управление частью инфраструктуры, но нам не дали паролей от пограничных маршрутизаторов. 

Пришлось задействовать тот самый Service Password Recovery. Это стандартный механизм восстановления, который есть у большинства производителей сетевого оборудования. 

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

Таким образом, в течение трех дней после отключения зарубежных серверов мы:

• получили контроль над локальной сетью и Wi-Fi инфраструктурой;

• восстановили доступ к пограничным маршрутизаторам;

• настроили защищенное сетевое подключение к новой российской облачной инфраструктуре;

• отработали процедуру удаленного доступа к ядру сети через пограничные маршрутизаторы для удаленного администрирования.

Как все функционирует сейчас

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

Сетевая инфраструктура заказчика изначально была спроектирована с учетом высоких требований к отказоустойчивости и безопасности. Благодаря этому при восстановлении доступа нам не потребовалось внедрять дополнительные механизмы защиты — усилия были направлены на обеспечение независимости от зарубежных администраторов. В результате управление сетевой инфраструктурой передано техническим специалистам на местах.

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

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

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

• Геораспределенный ЦОД, резервирование утраты канала связи или всей площадки.

• Митигация отказа платформы виртуализации и утраты возможности авторизации связанными сервисами через существование аппаратно независимого ЦОД.

• Гарантированная локальная доступность средства авторизации и аутентификации для систем и пользователей в пределах локальной по отношению к ним площадки.

Подводим итоги

В завершение хочется отметить несколько ключевых моментов из нашего опыта:

Миграция инфраструктуры крупного предприятия возможна даже в экстремально сжатые сроки при правильной организации процесса. Критически важными факторами успеха становятся компетентная команда, четкое распределение ролей и мотивация заказчика к сотрудничеству.

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

Зависимость от единственного вендора или облачного провайдера создает серьезные риски для бизнеса. Поэтому при проектировании корпоративной инфраструктуры стоит заранее продумать сценарии автономной работы и возможность быстрой миграции критически важных сервисов. Рекомендуем иметь актуальную документацию и прописанные процедуры восстановления доступа к оборудованию.

Надеемся, наш опыт поможет коллегам лучше подготовиться к подобным ситуациям.