В
В 2022 году, в связи с приостановкой бизнеса Atlassian в России и ростом санкционных угроз, у облачных версий продуктов Jira и Confluence в нашей стране стало больше рисков, чем у серверных версий. Многим российским компаниям пришлось организовывать перенос данных информационных систем с зарубежных облаков в собственную серверную инфраструктуру.
Сложности таких проектов миграции связаны с рядом факторов. В первую очередь облачные (Cloud) и серверные (Data Center) версии Jira уже долгое время развиваются независимо друг от друга разными подразделениями Atlassian. Это сказывается на совместимости некоторых объектов внутри этих версий (плагинов, типов проектов и т. д.) и, соответственно, на корректном переносе исторических данных. Кроме того, компания Atlassian в последнее время делает ставку на облачные технологии, поощряя переход заказчиков с серверной версии на облачную, и создавая для этого больше инструментов. При этом обратный процесс поддерживается гораздо меньше.
В итоге оказалось, что даже большое экспертное сообщество, которое сложилось вокруг Jira и Confluence, не знает, как решить проблемы, связанные с процессом обратной миграции. Хотя в стандартной ситуации вероятность получить любой ответ на вопрос о продуктах Atlassian от его участников очень высока.
Так, на одном из проектов по миграции Atlassian Jira и Confluence из облака на сервер, реализуемом для крупной ритейл-компании, специалисты iFellow первоначально попробовали воспользоваться официальной пошаговой инструкцией вендора. Однако, в процессе выяснилось, что гайд не учитывает множество дополнительных особенностей процесса. Исторические данные, такие как пользователи системы и их учетные записи, в облачной версии не соответствовали серверной. Существовали разногласия в отображении кастомизированного интерфейса.
В результате, помимо обычной работы системного администратора — аккуратно выполнить экспорт, поставить систему, выполнить импорт — специалисты iFellow разработали утилиту, исправляющую ошибки в процессе переноса. Она чинит поломки в базе данных, из-за которых нельзя создавать, редактировать, связывать задачи и подзадачи, а на рабочую панель не прикрепляются быстрые ссылки, необходимые для работы команды. Дополнительно утилита решает проблему синхронизации каталогов пользователей, вызывающую смену логинов на хеш-коды из 25 символов, а также замену имен на id пользователей в комментариях к задачам.
Практика iFellow показывает, что подобные сложности так или иначе свойственны многим проектам на продуктах Atlassian. Наработанные в компании методология и инструментарий могут быть использованы в качестве универсального типового решения, позволяющего обойти большинство сложностей в процессе миграции, и обеспечить грамотный перенос всех исторических данных.
«Сегодня проекты по миграции данных из зарубежных облаков распространены в тех сферах бизнеса, где заказчики изначально делали ставку на облачные сервисы, например, в ритейле. Российским компаниям, особенно крупным, нет смысла оставаться в зарубежном облаке. Решение On-Premise более защищенное, также оно позволяет тесно встроить систему в ИТ-ландшафт организации, гибко организовать взаимодействие со смежными системами, оперирующими большими данными. Фактически, это не только проект по минимизации рисков, но и задел на будущее. Мы накопили большой опыт миграции продуктов Atlassian из облака на сервер, прошли через все сложности и теперь можем предложить заказчикам универсальную методику, и инструментарий для такого перехода», — прокомментировал руководитель практики BPM iFellow Владимир Таранченко.
Российская ИТ-компания iFellow ведет комплексную разработку, тестирование и сопровождение программного обеспечения. Отдельная команда iFellow занимается решениями класса BPM (Business Process Management, управление бизнес-процессами).
