У зарубежных компаний история с ИТ-инфраструктурой очень простая: они как росли себе на Западе, так там всё и осталось. В России, как правило, нет даже инженеров, а все сервисы предоставляются откуда-нибудь из Ирландии, Франкфурта, Бостона или других городов, где находится головная организация и её дата-центры.
Драматически ситуация поменялась после вступления в силу поправок к ФЗ-152, гласящих, что персональные данные российских граждан нужно записывать, систематизировать, хранить и обрабатывать с использованием баз данных, находящихся исключительно в нашей стране. Некоторые компании приняли решение поднимать дата-центры в Москве, чтобы не терять бизнес. В нашем случае получилось примерно так (изменены некоторые компоненты и названия, так как есть соглашение о неразглашении — иностранцы, что вы хотите):
Сложностей море, например, такие:
- Полное отсутствие ИТ-персонала в российском офисе, занимающегося миграцией систем и управлением всего проекта в целом — нужно общаться с сетевиками из Европы или США и разработчиками, например, из Шанхая.
- Мало поднять прокси-структуру — нужно реально по факту обрабатывать данные в России. А, значит, в Москве (или в другом городе, но, как правило, действие происходит в столице) должен быть развёрнут инстанс CMS, почты, прикладного ПО для работы с продажами, бухгалтерия и так далее.
- Нужно перевезти всё это быстро и без существенных простоев, а потом ещё и поддерживать в плане инфраструктуры (приклад в данном случае поддерживают «родные» ИТ-команды).
Постановка задачи
Во-первых, было довольно сложно сформировать точное техзадание. Да и вообще понять, что и как нужно сделать. Специфика очень простая — в России находится офис, который занимается коммерцией, а не ИТ. И если для нас CMS, ERP, документооборот и почтовый сервер — разные вещи, то с точки зрения менеджера — это одна и та же система. Поэтому российский представитель компании выступал исключительно в качестве юр.лица, с которым подписывался контракт. Абсолютно все переговоры происходили с зарубежными коллегами. Даже договор был на двух языках. Их спецы в начале приезжали на экскурсию в наши дата-центры: их вице по ИТ в качестве гостей, наши топы — в роли экскурсоводов.
Во-вторых, география. Площадка и администраторы в одном часовом поясе, разработчики в другом, мы — в третьем. Языкового барьера не было, к счастью, весь ИТ-мир говорит на английском, и даже с китайской стороной никаких непониманий не возникало.
В-третьих, надо было понять, что такое ПД внутри их инфоообмена, то есть подключить юристов. В итоге юристы сделали заключение, что ПД для этой компании — любые данные, по которым можно идентифицировать человека. Туда попало хранение и обработка ФИО, фотографий, разные косвенные признаки типа места работы с указанием должности, адреса аккаунтов в соцсетях. При этом адреса твиттера с никнеймами — не ПД. Кстати, небольшой ликбез мы не так давно сами проводили.
Очень хорошо, что у нас было много исходных данных. История про переезд такая: чем меньше входных данных у тебя есть — тем дороже решение. Закладываешь самый дорогой продукт, который все умеет, самые дорогие лицензии — но можно не выиграть конкурс, потому что заказчику цена не понравится. Мы потратили свое время — показали, что можем разобраться. И получилось куда дешевле для заказчика.
В итоге были сформированы первичные задачи переноса и вторичные по сертификации-аттестации. История в том, что регулятор сначала будет смотреть компании с иностранным происхождением — где у них данные. Если за границей – блокировку сделать можно гораздо быстрее, чем перенести системы. И уже второй вопрос, требующий более глубокого вдумчивого копания — аттестация элементов системы. В нашей практике никто эти вопросы разом не решает. Сначала переезд, потом проверка всего на местах, уже потом остальное. Это два разных проекта.
Часть А — переезд — заняла полгода от первого контакта.
Этапы
Сначала мы предоставили тестовую зону из нескольких виртуальных машин, на которые заказчик выполнял так называемый proof of concept. КРОК выполнял задачу провайдера инфраструктуры — серверы, системы хранения, сеть.
Представители заказчика делали тестовые переносы, проверяя, как устанавливается соединение, с какой скоростью передаются данные, как разворачивать системы внутри того, что мы предоставляем. Грубо говоря, изучали инструментарий.
Потом было получено и установлено боевое оборудование. В этот момент начался перенос реальных систем, но без переноса фактической нагрузки — для того, чтобы увидеть, что системы работают, выполнялись нагрузочные тестирования. Потом шёл сам переезд в даунтайме на выходных.
Инфраструктура
Связь понадобилась с тремя дата-центрами, поэтому работали с иностранными коллегами в связке достаточно плотно. Если не считать сложностей с часовыми поясами, всё прошло гладко и на очень высоком уровне взаимопонимания.
В итоге мы полностью создавали инфраструктуру для российской площадки, а заказчик заливал на неё данные своими силами под нашим наблюдением на случай сюрпризов. Наша часть — инфраструктура до уровня операционки и виртуальной машины. Адресацию согласовали почти сразу, причём наш сетевой архитектор работал с их архитектором бок о бок. Внутренняя адресация полностью соответствует их изначальной сети. Публичные адреса российские — потому что используются уже наши каналы.
Самый простой случай — схема бекапа
Полезный урок по сбору данных
На первый взгляд проект кажется достаточно простым — мол делов-то собрать тут то же, что есть у заказчика в Европе. У заказчика эти сервисы ещё и в разных дата-центрах, плюс они сразу же захотели оценить последующую модернизацию — и все эти требования не всегда хорошо ложатся на «просто перенос», надо объяснять и выяснять.
Выявление требования к инфраструктуре и согласование техзадания заняло половину времени заказа, то есть почти три месяца. Удалось очень хорошо сэкономить время за счёт того, что мы смогли составить специальные опросники в виде списка закрытых вопросов («да»/«нет» или 3-5 вариантов) — чтобы четко получать информацию от заказчика. До этого был на похожем переезде опыт с открытыми вопросами — и ответы были такие, что пришлось заходить ещё на две итерации. Здесь же мы получили довольно много информации изначально и могли предлагать свои варианты.
В большинстве случаев подобный подход себя оправдывает. Но в паре мест мы поймали нюансы, которые в итоге чуть усложнили миграцию — несмотря на повысившиеся трудозатраты, сделали за свой счет, поскольку сами выбрали подход с закрытым опросником.
Плюс местные особенности, конечно. Например, сроки мы согласовывали с боями — зарубежные коллеги не всегда представляют актуальные сроки доставки оборудования. Не понимают, что не всегда можно привезти что-то конкретное в РФ. Цены не как у них — у нас они вообще другие, и то, что в Европе дороже, может оказаться у нас дешевле. Или наоборот.
Чем мы были удивлены, так это их идеальной скрупулезностью во всём, что касается существующих стандартов и правил, написанных часто лет 10 назад. У них всё это работает на честные 100 процентов, а не на 20-80, как мы это часто видим внутри России. У нас любое правило стандарта рассматривается как некая полезная рекомендация. У них — как железный барьер.
Или вот план миграции. У нас оперативные правки делаются просто по звонку, а у них так не работает. Надо прописать, приложить схему, потом отправить письма и ждать понедельника. Никаких сверхурочных. Они привыкли работать размеренно, медленно и кайфно, но на пять с плюсом.
Ещё мы не всегда видели их структуру: на этапе общения ты даже не всегда знаешь, с кем конкретно общаешься. И думаешь — ок, договорились, завтра дадут требования. А этот человек в Ирландии, железо в Америке, там своя ИТ-команда, с которой он ещё должен всё согласовать, а они должны показать проект тимлиду команды в Китае. Пока письмо с ответом пройдет — минимум двое суток из-за часовых поясов. Много отдельных бизнес-подразделений, и у каждого техподразделения свои хотелки, особенно на будущее. Согласование с 10 людьми в копии — совершенно нормально.
Или вот вообще чумовой пример: обновить прошивку роутера — у нас решает ИТ-главный, а у них все эти 10 человек сразу, причём туда входят и разработчики приклада.
Внедряли собственными силами, позже заказчик обратился к нам и за сопровождением не только на уровне инфраструктуры, но и на уровне операционок.
Сейчас у них следующий шаг — катастрофоустойчивость. Мы и предлагаем — есть два наших дата-центра, между ними толстые независимые каналы для синхронной репликации. Готовы в любой момент переключиться или восстановиться, иными словами строить любое их решение.
Итог
Договорились про даунтайм на переключение, перенесли за 32 часа (большая часть даунтайма — окончательная синхронизация данных и тесты продакшна), согласовав работы всех команд. Сейчас система уже несколько месяцев работает без нареканий. Кратко история прошла так: монтаж железа, сборка, проверки, накатывание инфраструктурного софта, поднятие виртуализации, первоначальная настройка, сопровождение и внедрение их систем, ещё тесты — дальше включалась команда заказчика. Иногда они просили нас помогать по своим задачам, например, на тестах производительности приклада мы ковыряли вместе с ними, искали узкие места в инфраструктуре. У нас много всяких услуг, всё же по ИТ-инфраструктурам мы по России первые. Вот они всем этим смело и пользовались к общему счастью. Их сетевики заглядывали в проект всего лишь пару раз, и то, когда были просадки на международных каналах, всё остальное время никто, кроме прикладников, в эксплуатации не участвует. После внедрения 2 недели мы были в режиме усиленной поддержки, то есть каждый день обсуждали с их спецами статусы и мелкие доработки. Сейчас предоставляем инфраструктуру: серверы, системы хранения, сети, балансировщики, устройства ИБ, виртуализация, систему резервного копирования. Плюс все это в режиме отказоустойчивости резервируется во второй дата-центр, за счет чего SLA составляет 99,9% для всех уровней инфраструктуры.
Ссылки
- Экскурсия по нашему дата-центру T-III «Компрессор» (T3 проект, T3 объект, Т3 эксплуатация)
- Миграция данных одного банка
- Распределённые системы хранения данных (часть программно-определяемого дата-центра)
- Моя почта — RSayfutdinov@croc.ru
Автор: КРОК
