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

Наш заказчик – крупная компания-производитель – принял решение создать автономную ИТ-инфраструктуру на базе отечественных решений. Как команда из «ЛАНИТ-Интеграции» реализовала такой проект и с какими трудностями столкнулась, читайте в этой статье.

Локализация инфраструктуры: что это такое, зачем нужно и какие есть особенности

Для начала озвучу, как оказалось, неочевидный, но очень важный факт: локализация ≠ импортозамещение.

Давайте по порядку.

• Импортозамещение – это полная или локальная замена зарубежного ПО и железа на российские аналоги. Другими словами, это часть обновленной стратегии, которая решает определенные задачи в условиях неопределенности. Саму процедуру должны пройти правительственные организации, оборонные и силовые ведомости, а также компании с госучастием.

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

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

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

Задача, стоящая перед заказчиком: какой результат требовалось получить, в какие сроки

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

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

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

Перед командой «ЛАНИТ-Интеграции» встала амбициозная задача: администраторы должны получить функции и дизайн, к которым привыкли, а пользователи – не заметить ничего глобального, кроме как смены названия домена при входе в свои компьютеры.

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

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

Вводные: выявленные нюансы, стартовые позиции заказчика и исполнителя

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

1. Что было у «ЛАНИТ-Интеграции»

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

• Большинство оборудования и ИТ-сервисов управляются головной компанией из-за рубежа.

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

• Объем инфраструктуры - более 100 виртуальных машин. Помимо инфраструктурных машин на базе продуктов MS и учетных систем SAP, 1C, также присутствуют отраслевые программные комплексы, управляющие производственным оборудованием и промышленными роботами.

• Документирование ИТ-инфраструктуры не развито.

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

• Компания-заказчик находится в другом регионе, поэтому большинство работ должны были проводиться удаленно. P.s.: производитель предоставил нам своих сотрудников, которые стали нашими «руками» на площадках. Однако нам потребовалось максимально детализировать ТЗ. Доходило и до такого: «Нажмите красную кнопку в верхнем нижнем углу».

• Сеть построена на белых адресах.

2. Что было у заказчика

• Неконтролируемая остановка производственных процессов при обрыве связи материнской компанией.

• Параллельные проекты, завязанные на локализуемой инфраструктуре.

• Неизменный набор ресурсов. Проект не предполагал закупку дополнительного оборудования или лицензий – бюджет не предусмотрен.

Ход реализации проекта

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

Плановая этапность и сроки 

Чтобы правильно рассчитать время на реализацию проекта, важно учесть первоначальные вводные, срочность и нюансы работы бизнес-процессов.

1. Предпроектное обследование (1 месяц). Стандартный процесс сбора исходных данных для проектирования и проведения работ, уточнения требований к результатам, выявления значимых особенностей и т.д.

2. Проектирование (1,5 месяца). Тут начинается разработка и согласование технических решений и утвержденного набора проектных документов по подсистемам.

3. Развертывание локализованной ИТ-инфраструктуры (1,5 месяца). Фактически – это создание заготовки будущей инфраструктуры. Чтобы подготовить «болванку» нужно: выделить ресурсы, установить операционную систему и гипервизоры, создать новый домен и другие корпоративные сервисы. Затем провести базовую настройку и подготовку к переносу данных.

4. Миграция инфраструктурных систем (2 месяца). На этом этапе в заготовку переносятся данные: создаются пользователи, настраиваются группы безопасности, политики межсетевого экранирования; параллельно настраивается резервное копирование и т.д.

5. Миграция прикладных сервисов (2 месяца). Уже в созданную инфраструктуру переносятся прикладные системы по типу Sharepoint, CMDB, производственные системы.

Итого получается восемь месяцев – вполне нормальный срок для реализации подобного проекта.

Реальная этапность и сроки проекта

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

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

К параллельности выполнения этапов работ приводили и другие причины. Например, мы оказались зависимы от других подрядчиков и вынуждены были ждать. Так, нам оставалось 10% до завершения этапа, но сдать его вовремя не получилось.

Решение: особенности и примечательные моменты проекта

Пора приступать непосредственно к «решению». С учетом особенностей «условий» будет правильным представлять каждый технический аспект по подсистемам.

1. Active Directory

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

2. Domain name system (DNS)

Изначально сервис DNS был реализован на базе немецкого продукта наподобие pfSense. Естественно, административного доступа к нему не было. Нужно было получить DNS-записи, созданные вручную, и которые невозможно выгрузить из исходного домена. А такие записи использовались весьма обширно – для недоменных серверов и некоторого производственного оборудования.

3. Dynamic Host Configuration Protocol

Данный сервис был реализован на базе того же продукта, что и DNS. Мы осуществили перевод на Microsoft (MS), создали пулы под целевую схему адресации. Также расположили DHCP-серверы на всех локациях, чтобы пользователи на локациях могли работать, если пропадет её связь с остальными локациями. Дополнили подсистему IPAM’ом от MS.

4. Public Key Infrastructure

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

5. Файловые сервисы

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

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

6. СХД, Storage Area Network (SAN) 

На этом этапе все осталось приблизительно так, как и было: со сменой адресации и привязкой объектов к локализованному домену.

7. Система резервного копирования (СРК)

Заказчик использовал СРК на базе ПО NetWorker + Data Domain. Такой софт не имеет функций смены домена под своими компонентами. Как следствие его пришлось полностью разворачивать с нуля. Непосредственно резервные копии между старой и новой СРК не переносились.

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

Заодно провели ревизию процесса резервного копирования: создали недостающих клиентов и удалили ненужных, а также оптимизировали набор заданий резервного копирования.

8. Платформа виртуализации

Заказчик как использовал VMware, так и продолжил ее использовать. Для локализованной платформы виртуализации был создан новый VCenter и настроен по образу и подобию исходного, к которому административного доступа уже не было. Так как набор оборудования не менялся, серверы переводились под управление нового VCenter по очереди, с переустановкой гипервизора.

Для миграции виртуальных машин использовался общий DataStore, доступный как старым, так и локализованным серверам. Машины переносились по одной или группами по-принципу принадлежности к определенной системе и выключались. Затем мы помещали их на общий DataStore в исходной платформе виртуализации и удаляли из конфигурации (unregister без удаления файлов). Уже в новой платформе виртуализации машины регистрировались, клонировались в целевые. Исходные клоны в DataStore удалялись для освобождения места и процесс повторялся для следующей группы машин. Сетевая адресация была сменена на целевую, но потребовалось сохранить небольшое наследие старых адресов.

9. Виртуальные машины

Часть виртуальных машин мы создали на базе продуктов MS. Также некоторые отраслевые, уже установленные ПО не имели возможности смены домена и требовали повторного развертывания. Для большого количества машин наша команда выполнила смену принадлежности к домену. К счастью, установленное в них ПО это позволяло, плюс имелись локальные административные учетные записи. Ну и сама адресация менялась на целевую. Для некоторых машин адресацию пришлось оставить исходную, поскольку в них было установлено ПО, у которого лицензия была завязана в том числе на IP-адресе, а получить новые ключи было невозможно. Для этого в платформе виртуализации была сохранена одна старая подсеть.

10.  Почта и коммуникации

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

11.  Локальная вычислительная сеть (ЛВС)

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

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

12.  Межсетевые экраны (МСЭ)

У заказчика был кластер МСЭ Fortigate, расположенный на двух основных локациях. Изначально межсетевые экраны использовались для межсетевого экранирования. Через них была организована маршрутизация внутренних подсетей между собой, а также VPN-тоннели к некоторым контрагентам. Такая функциональность была сохранена, а также дополнена реализацией удаленного доступа пользователей через VPN взамен VPN-сервиса от MS в головной организации.

13.  Не обошлось и без потерь

Части некоторых прикладных подсистем физически находились на территории головной организации и доступ к ним был утрачен. «Жертвами» стали MS Project и Sharepoint. Получить их не было никакой возможности, поэтому пришлось с этим фактом смириться. Однако потеря в итоге оказалась не столь значительной, как казалась на первый взгляд.

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

• Когда рабочее время заказчика и исполнителя не совпадает – это довольно неудобно.

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

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

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

Что хочется сказать в конце

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

• Такую экспертизу надо развивать, она востребована в современных реалиях. 

• Для системных интеграторов это отличное поле деятельности. 

• Для любой задачи, даже полностью локализуемой в одном человеке, нужно два человека. 

• Люди ходят в отпуск, болеют, могу покинуть компанию или уехать в командировку. А передача опыта между людьми должна быть налажена. 

• Важно четко очерчивать границы проекта и не лезть, куда не следует. 

P.s.: двух одинаковых проектов не бывает, но такой мы бы сделали еще раз. Если стало интересно – welcome на наш сайт «Локализация ИТ», там все подробно.