Интеграция данных: баланс между «быстро» и «хорошо»
Интеграция данных играет ключевую роль в процессе миграции на новую ИТ-платформу. Эта задача, которую сегодня приходится решать многим российским заказчикам, долгие годы «сидевшим» на зарубежных решениях от SAP, Oracle, Microsoft и других западных вендоров, покинувших отечественный рынок и оставивших своих пользователей без обновлений, поддержки и лицензий. Но дело не только в миграции. С возрастающим количеством облачных сервисов, SaaS-продуктов и унаследованных систем, потребность в их бесшовной интеграции растет с каждым днем. Таким образом, бизнесу нужен переход на новые платформы (российские проприетарные либо продукты с открытым исходным кодом), и этот переход должен быть максимально безболезненным, наименее затратным и эффективным.
Данные — кровь современного бизнеса. При миграции необходимо обеспечить их целостность, гарантировать, что вся информация будет перенесена без потерь и искажений. Интеграция данных помогает поддерживать актуальность и точность информации в новой среде. От данных зависят бизнес-процессы. Правильно настроенная интеграция данных помогает обеспечить нормальное функционирование критических бизнес-процессов и после их миграции. Во время перехода на новую программную платформу важно свести к минимуму время, когда система не доступна для использования. Эффективная интеграция данных помогает ускорить процесс миграции и сократить перерывы к их доступу. Нередко нужная информация находится в различных форматах и системах, зачастую устаревших и унаследованных. Интеграция обеспечивает их согласование и унификацию, что критически важно для эффективной работы новой системы. Бизнес нуждается в прозрачной картине для принятия решений. Только грамотная интеграция данных способна предоставить такую прозрачность для принятия решений на всех уровнях управления. Неправильное управление данными во время миграции может привести к серьезным проблемам, таким как потеря данных или сбои в системе. После миграции может потребоваться дальнейшее обновление данных или их архитектуры. Если данные правильно интегрированы, управление последующими изменениями становится проще и менее рискованным. Это лишь некоторые аргументы в пользу того, что интеграция данных — стратегически важная часть проекта по миграции на новую ИТ-платформу, и ей следует уделить самое пристальное внимание. В ходе планирования интеграции данных у заказчиков нередко возникают вопросы, которые они задают консультантам, часто не удается избежать и подводных камней на этом пути. Мы попросили экспертов поделиться мнением, как грамотно спланировать, спроектировать и осуществить интеграцию данных.
Переход на открытый код
Если осуществляется миграция с проприетарных решений на ПО с открытым исходным кодом, заказчики нередко опасаются столкнуться с теми или иными техническими препятствиями. По мнению Александра Чиченина, технического директора компании ITentika, для закрытых систем наиболее вероятными рисками становятся слабое качество документации и трудности с реализацией механизмов интеграции. Под этим эксперт подразумевает закрытые форматы передачи данных и недокументированное API, скрытые уязвимости, требующие дополнительного black box security-тестирования, невозможность расширения существующей функциональности силами внутренней команды, а также высокую зависимость от поставщика системы — так называемый Vendor Lock-In, ситуацию в которой будет трудно за приемлемое время и средства поменять одну интегрированную систему на другую, если компания расторгнет договор или прекратит свое существование. С другой стороны, по его мнению, системы с открытым исходным кодом не несут рисков прекращения деятельности компании, однако на первый план выходят вопросы лицензирования, не каждая лицензия позволяет использовать лицензированный ею продукт без открытия кода системы, которая ее интегрирует, дополнительных трудностей добавляет и существование систем с двойным лицензированием для коммерческого и некоммерческого использования. «Следует отметить, что, хотя расширение исходной функциональности и допустимо, появляются риски невозможности обновления системы из-за конфликтов между сделанными изменениями и изменениями, пришедшими от разработчика системы. Также к минусам подобных систем можно отнести, как правило, слабую или вовсе отсутствующую поддержку со стороны разработчиков системы, которая, однако, частично компенсируется более развитым сообществом, готовым ответить на различные технические вопросы», — заключает Александр.
«При интеграции систем с открытым и закрытым исходным кодом чаще всего возникают технические препятствия, связанные с тем, что системы с закрытым исходным кодом используют проприетарные технологии, в которых возможно отсутствие необходимых механизмов интеграции с другими системами. Обычно в подобных случаях нужна поддержка производителя таких систем, но в текущей ситуации, когда многие западные производители, которые являются и создателями этих систем, ушли с отечественного рынка, поддержка затруднена или не оказывается вовсе», — добавляет Анатолий Савинков, заместитель руководителя службы системной интеграции и ИБ компании «Абак-2000».
«При реализации проекта интеграции информационных систем на базе любого ПО — свободно распространяемого или коммерческого, с закрытым или открытым исходным кодом — возникает вопрос ответственности за результат. Ответственность лежит либо на интеграторе, либо на самой компании, если она это делает для себя и выступает интегратором, — считает Станислав Дарчинов, советник генерального директора по технической политике «Национальной компьютерной корпорации» (НКК). — В случае с коммерческим программным продуктом часть ответственности можно делегировать разработчику и решать возникающие вопросы, обращаясь в техподдержку. А когда интегрируется свободно распространяемый продукт с открытым исходным кодом, то это полностью ответственность компании, реализующей интеграцию. Несмотря на наличие сообщества, которое поможет советом, — отвечать все равно будет интегратор. Технические проблемы в любом варианте может вызвать недостаточная документированность интегрируемых систем». С другой стороны, по мнению Станислава, если говорить о коммерческом продукте с открытым исходным кодом, который поддерживается какой-либо компанией-разработчиком, то при наличии документации и технических специалистов, готовых отвечать на вопросы, проблем скорее не возникнет. «Свободно распространяемый продукт с открытым исходным кодом, разрабатываемый сообществом, может быть неплохо документирован и, как правило, сопровождаться активными форумами, где можно получить консультации специалистов. Но с точки зрения ответственности интегратора — тут все на свой страх и риск. При этом следует отметить, что к настоящему моменту технологии интеграции достигли достаточной зрелости, чтобы предложить универсальные механизмы обмена данными, в том числе де-факто стандартизированные и/или открытые. Основные вопросы в возможности реализации в том или ином программном продукте», — резюмирует он.
Как избежать потери данных
Один из наиболее распространенных рисков, которые могут возникнуть при интеграции систем, — потеря данных. Чтобы ее избежать, эксперты рекомендуют реализовать некую промежуточную среду, или песочницу. «Для снижения рисков рекомендуется использовать промежуточную среду для загрузки сырых данных, затем уже загружать их в целевую систему. В случае неполадок, неполноты или конфликтов данных они будут сохранены в промежуточной среде в сыром виде для последующих попыток загрузки. Для оценки рисков также следует учесть доступность источника и надежность сети», — советует Денис Куц, руководитель направления заказной разработки компании iiii Tech (Форайз).
Среди основных шагов для минимизации рисков потери данных Виталий Попов, директор департамента реализации инфраструктурных проектов ГК Softline считает введение классификации по уровню критичности для бизнеса. Он предлагает задействовать несколько уровней важности данных: критичные, важные, некритичные и несущественные. Проследить, как работает классификация, эксперт рекомендует на примере интеграции данных электронной почты. «Во-первых, разделяем пользователей на группы, учитывая тот же уровень классификации, что и у данных. Для одних требуется полный перенос содержимого почтового ящика, для других предоставляем инструкции по самостоятельному переносу. Во-вторых, классифицируем служебные почтовые ящики по группам. Часто не нужен перенос данных из ящиков, используемых для рассылок, и подобных. Для остальных ящиков проводим анализ и определяем, какая информация может быть критически важной. В-третьих, изучаем настройки системы, которые, как правило, могут быть повторяющимися. В случаях, когда повторение невозможно из-за отсутствия функционала целевой системы, определяем критичность и рассматриваем возможность применения дополнительных продуктов, например, встроенной системы DLP», — говорит он.
Артур Синельщиков, ведущий технический специалист департамента технического консалтинга, аудита и инженерной поддержки компании Axoft:
Данные являются ценностью компании, и их потеря недопустима. Поэтому при любых манипуляциях с данными необходимо составить и максимально продумать план проекта, в том числе постараться проработать и негативные сценарии. А это не только описания проекта по переносу данных, анализ структуры данных для понимания совместимости платформ, тестовые миграции, но и вопросы резервного копирования.
«Вряд ли можно составить рецепт на все случаи. Но, очевидно, ни оценить, ни минимизировать риски потери данных невозможно без полной модели данных обеих платформ и их связи с бизнес-функциями. В этой модели следует определить допустимые с точки зрения критичности бизнес-функций потери данных, которые не должны привести к откату миграции. Детальный сценарий миграции с определением точки невозврата с учетом временного профиля бизнес-процессов поможет спланировать точки и критерии контроля полноты переноса данных. Эти критерии должны основываться на определении областей допустимых потерь данных, которые позволят исключить запуск отката сценария миграции до преодоления точки невозврата. Далее — дело техники. Инструменты контроля полноты переноса данных как по количественным показателям (по записям), так и по содержанию (по полям), сценарии валидации перенесенных данных путем выполнения достаточного набора бизнес-функций и другие инструменты, позволяющие оценить полноту переноса. Плюс меры по восполнению обнаруженных некритичных потерь данных после завершения сценария миграции. Но все это не будет полным без архивной копии системы-источника в защищенном хранилище, на которое не распространяются стандартные политики уничтожения по возрасту или остатку свободного пространства», — рассказывает Николай Подстрелов, директор по маркетингу компании «Диджитал Дизайн».
Прощание со «старыми друзьями»
Использование устаревших или унаследованных (legacy-систем) до сих пор остается серьезной проблемой. И сегодня можно встретить организации, у которых есть системы, работающие десятилетиями, еще со времен MS-DOS либо ведущие свою историю с 1990-х или начала 2000-х годов. Компания-разработчик давно канула в Лету, а приложение функционирует, поскольку по-прежнему соответствует задачам заказчика. Но далеко не все задумываются, что такие системы представляют собой бомбу замедленного действия. «Ключевыми моментами при использовании подобных систем являются безопасность, возможность поддержки и их модификаций для внедрения новых функциональных возможностей, — комментирует Антон Аплемах, генеральный директор российского объектного хранилища Platformcraft. — В разрезе безопасности известны прецеденты многолетнего существования уязвимостей в ПО, которое применялось огромным количеством компаний. Например, уязвимость в одной из библиотек SSH, позволяющая злоумышленнику получить доступ к серверу без ввода пароля. Именно поэтому безопасность унаследованных систем становится одним из важных моментов в их эксплуатации. Возможность поддержки подобных систем накладывает определенные ограничения на команду специалистов и предполагает уровень не ниже middle, а в случае сложных систем — senior. Похожая ситуация складывается и с модификациями подобных решений, которые порой требуют проведения серьезного R&D».
«Это классическая история, в которой самый оптимальный вариант — сохранять legacy-системы без изменений настолько долго, насколько это возможно. До тех пор пока не будут проведены все необходимые тесты по интеграции систем/переносу данных в новые системы. В исключительных случаях идут по малоприятному и дорогому пути самописных коннекторов», — комментирует Артур Синельщиков, ведущий технический специалист департамента технического консалтинга, аудита и инженерной поддержки компании Axoft.
«Рассмотрим Enterprise-системы. Если ты работаешь в крупной компании, то самой большой проблемой в интеграции с устаревшей системой становится недостаток информации. Зачастую это старая, мало кому знакомая система, со своим внутренним миром. Поэтому в первую очередь необходимо найти человека, который в подобной системе разбирается и знает все ее тонкости и нюансы. Дальше желательно создать красивый прокси к этой системе или хотя бы хорошую документацию, чтобы те, кто будет с ней интегрироваться в дальнейшем, понимали с чем имеют дело», — советует Виктория Долженко, team lead компании Itez.
По мнению Ахмада Бокова, генерального директора компании «Искусство Автоматизации», критически важную систему нельзя просто взять и выключить. Приходится рассматривать и презентовать заказчику варианты постепенной поэтапной модернизации. «Вновь созданная система сможет в ходе циклов разработки и внедрения поэтапно забрать на себя функции унаследованной системы, которую спустя несколько таких итераций можно будет вывести из эксплуатации», — утверждает он.
Интегрируй, но проверяй
Часто необходимо найти баланс между потребностью в быстрой интеграции и необходимостью тщательной проверки данных на соответствие. Константин Тельной, старший бэкенд-разработчик компании Simple, рекомендует в подобных ситуациях внимательно проконсультироваться с бизнесом. «Необходимо выяснять, насколько допустимы потери данных и ошибки, на чем можно сэкономить, — объясняет он. — Зачастую среди данных есть 20%, которые нужны прямо сейчас, и 80%, которые можно привлечь позже. Неплохо также понимать, насколько в целом сложна задача и на что влияют те или иные задержки. Часто можно сделать решение, которое технически не будет идеальным, однако устроит бизнес».
Александр Хантеев, руководитель архитектурной практики компании RNT Group, предлагает разделить переносимые данные на домены, сделать акцент на наиболее значимых областях и ускорить процесс за счет поэтапного переноса — этот подход позволит поддерживать высокий темп миграции, не допуская проблем с качеством переносимых данных. Бизнесу, по его словам, не нужны некачественные данные.
«Все в большой степени зависит от критичности данных для бизнеса и конкретных требований проекта. Больше внимания необходимо уделять критически важным данным и бизнес-процессам. Если, например, речь идет о банковских операциях, где необходима максимальная точность, то пренебрегать проверкой качества информации нельзя. Скорее всего, в этом случае придется корректировать сроки проекта. А если мы работаем со статистикой, не особо влияющей на финансовый результат, то в отдельных случаях можно пренебречь проверками или перенести их на следующие этапы проекта, после внедрения», — отмечает Павел Ревин, старший архитектор департамента аналитических решений ГК «КОРУС Консалтинг».
Новые технологии и подходы
Интеграция данных — серьезная область ИТ-услуг, которая постоянно развивается и совершенствуется. Здесь регулярно появляются и берутся на вооружение свои инновации, технологии и подходы. «Основной тренд последних лет — изменение подхода к отношению к данным. Данные и аналитика — это не просто инструмент написания отчетов, а мощный механизм, помогающий принимать правильные решения на всех уровнях руководства компании. В развитие такой идеи применяется подход DataOps, определяющий процесс непрерывной интеграции данных между различными подразделениями компании, — комментирует Александр Чиченин (ITentika). — В технических аспектах хотелось бы выделить бессерверный подход, позволяющий сократить расходы на поддержку физических и виртуальный машин, а также уменьшить издержки во время простоя вычислительных мощностей. В последнее время мы активно изучаем возможность применения ИИ в анализе данных, для установки трендов и выявления аномалий».
«Для меня, самым интересным в жизни были интеграции с различными блокчейнами и блокчейн-системами. Это невероятный зоопарк. Многие из них выросли из стартапов, что наложило свой отпечаток на качество таких систем. Особенно меня поражают блокчейны, которые постоянно ломаются, но в которых крутятся немалые деньги, вот и работай с ними», — свидетельствует Виктория Долженко (Itez).
По словам Артура Синельщикова (Axoft), одним из самых новых и «модных» направлений во всем ИТ является технология машинного обучения. К примеру, с помощью данной технологии можно проводить анализ больших массивов данных из различных источников с целью построения различных моделей данных и дальнейшей проверки гипотез.
«В области интеграции данных мы сталкивались с разными интересными инновациями и технологиями, проиллюстрировать которые можно различными сценариями. Например, в одном случае нам удалось решить задачу, объединив календари различных систем — почтовой, ВКС и совместной работы. Это позволило добавить функцию создания видеоконференций в каждый из календарей. Несмотря на видимую простоту, на подобную интеграцию ушло два месяца, включая взаимодействие с разработчиками и специалистами, знакомыми с каждой из систем. В данном случае мы имели дело с тремя разными вендорами, — рассказывает Виталий Попов (Softline). — Другой пример — одно из решений в области информационной безопасности не взаимодействовало с каталогами службы Active Directory. Вендор не смог обеспечить интеграцию и сообщил, что реализация данной функции займет два года, если вообще будет осуществлена. Учитывая неприемлемость такого срока для нас, мы решили проблему, обучив FreeIPA эмулировать Active Directory, таким образом добившись успешной интеграции. Иногда, чтобы найти решение для задачи интеграции, необходимо взглянуть на проблему под другим углом, и тогда путь к решению становится очевидным».
На пути в облако и обратно
Миграция из локальной ИТ-инфраструктуры в облачную — отдельная история, и здесь может возникнуть целый спектр сложностей, связанных с интеграцией данных, начиная с объема, безопасности и пропускной способности вплоть до вопросов юридических и управления изменениями. «Прежде всего, при переносе данных в облако может возникнуть угроза конфиденциальности и целостности данных. Также могут появиться трудности при синхронизации данных из-за несовпадения структур и типов. Чтобы избежать ошибок и сократить время на миграцию, для переноса большого количества данных лучше использовать автоматизированные инструменты», — считает Анна Чеснокова, руководитель QA-отдела компании SimbirSoft.
По словам Павла Ревина («КОРУС Консалтинг»), в случае миграции в облако часто происходят сложности, связанные в сетевой доступностью, безопасностью и согласованностью данных. Также нередко возникают организационные вопросы согласования с ИБ-подразделениями. «Компания может иметь внутренние требования относительно данных: например, одни данные можно перемещать в облако, а другие ни при каких обстоятельствах не должны туда попадать. Для такого контроля могут потребоваться дополнительные модули и компоненты в системах. Важно создать план миграции, который учитывает эти аспекты, и провести тестирование, чтобы убедиться в успешной миграции», — говорит он.
Станислав Дарчинов (НКК) в первую очередь говорит о трудностях организационного плана. Они связаны с передачей ответственности по вопросам сертификации по ряду федеральных законов — о персональных данных 152-ФЗ, о безопасности критической информационной инфраструктуры (КИИ) 187-ФЗ. «Некоторая внешняя инфраструктура становится частью защищаемого периметра, и корпоративные данные являются защищенными согласно законодательству. Требования по наличию соответствующих сертификатов и специалистов для работы с ГИСами, медицинскими информационными системами, персональными данными и т. д. предъявляются к провайдерам облачных услуг, — комментирует эксперт. — Если, наоборот, происходит миграция из облака в корпоративную ИТ-инфраструктуру, то у предприятия должны быть все перечисленные выше сертификации и компетенции».
Если речь идет о миграции локальной ИТ-инфраструктуры в облако, то чаще всего, по словам Станислава, это перенос рабочих места в VDI-структуру. «Здесь сложность заключается в пользовательском опыте, который станет другим, в том числе с точки зрения решения вопросов безопасности. Хотя экран для пользователя выглядит также, но это другая среда и многих действий пользователь сделать не сможет — например, скопировать файл на флэшку или отправить письма на личную почту», — поясняет он.
«Сложности миграции данных между облачными и локальными платформами могут включать ограничения предоставляемых облаком сервисов и их недостаточную зрелость. Также важно учитывать пропускную способность сети и безопасность, требования регуляторов и внутренние регламенты информационной безопасности. Большую роль играет неготовность бизнеса доверять свои данные публичному облаку. Именно поэтому в нашей стране такое развитие получают приватные и гибридные облака», — уверен Александр Хантеев (RNT Group).
Если говорить о приоритетности решаемых задач при переходе в облако, то Александр Чиченин (ITentika) в первую очередь советует решить проблемы, связанные с доступностью, надежностью и стоимостью каналов передачи данных между локальными и облачными контурами. «Для минимизации рисков многие провайдеры предоставляют выделенные линии, позволяющие напрямую связать облачные дата-центры с оборудованием клиента, тем не менее, резервирование таких каналов может быть значительно более сложным, чем резервирование обычных интернет-каналов», — объясняет он.
«При миграции данных между «облаком и землей» используется канал связи, при разрыве которого могут произойти различные негативные сценарии. Поэтому крайне важно подготовить и резервный канал связи для стабильной передачи данных. Также не следует опираться на заявленные характеристики отказоустойчивости облаков, и лучше лишний раз пересмотреть резервирование», — добавляет Артур Синельщиков (Axoft).
О нескольких типичных сложностях при переходе в облако и обратно говорит Виталий Попов (Softline). Прежде всего, это отсутствие локальных аналогов для облачных решений. «Некоторые облачные платформы становятся стандартом, но не всегда предоставляют возможность локального развертывания. Например, популярная система совместной работы от известного вендора может быть доступна только в облаке, и при решении отказаться от облачного варианта приходится потерять не только функциональность, но и данные, которые трудно перенести», — говорит он. Вторая сложность состоит в необходимости крупных капиталовложений для заказчика. «Объем данных в облаках может оказаться слишком велик для локальной платформы. Перемещение такого объема данных требует значительных капиталовложений в оборудование и вычислительные мощности», — отмечает эксперт. Третья сложность — неожиданные расходы в облаках. Это может быть плата за трафик, количество обращений к данным и другие параметры, о которых при использовании локальной инфраструктуры не приходится беспокоиться. Правильная оценка мощностей (сайзинг) становится важным аспектом для эффективного применения облачных ресурсов. «С учетом текущих реалий даже облачные технологии гиперскейлеров не всегда оказываются надежным инструментом. В связи с этим гибридные схемы работы с облаками становятся оптимальным решением. Важно иметь подготовленный инструментарий миграции, а в некоторых случаях и план восстановления и перехода системы в локальной инфраструктуре», — заключает наш собеседник.
Бизнес-процессы должны остаться непрерывными
В заключение хотелось бы поговорить о том, какие меры необходимо предпринять для гарантии непрерывности бизнес-процессов во время интеграции систем. «Согласно различным стратегиям миграции данных, наиболее эффективными оказываются методы, основанные на поэтапном или параллельном переносе информации. Оба подхода способствуют непрерывности бизнес-процессов и работоспособности инфраструктуры во время переноса, — комментирует Александр Жижанков, руководитель направления разработки информационных систем и бизнес-приложений компании Cesca. — Постепенная миграция предполагает перенос данных частями или по этапам. Этот метод позволяет постоянно тестировать и корректировать все происходящее, минимизируя риски для бизнес-процессов. Параллельная миграция, в свою очередь, осуществляет перенос данных одновременно на новую и текущую системы, обеспечивая непрерывную доступность данных и предотвращая значительные сбои в работе».
Ахмад Боков («Искусство Автоматизации») отмечает несколько этапов решения этой задачи. Первый — планирование работ. «Определяем цели и задачи интеграции. Для того чтобы все участники процесса интеграции одинаково понимали процесс и его этапы. Составляем список систем, на которых повлияет интеграция. На этом же этапе определяем риски, которые несет процесс интеграции. Что может пойти не так и как на это будем реагировать», — говорит он. Второй шаг, по словам Ахмада, представляет собой составление детального плана тестирования (функционального, интеграционного и ИБ). «Выбираем информационный контур, на котором будут проводиться тестовые интеграции», — продолжает он. На третьем этапе необходимо описать и реализовать процесс мониторинга интегрируемых систем. «Определяем метрики (например, количество ошибок в логах), по которым можно судить об успешности интеграции. Также продумываем возможность обратного отката к прошлым состояниям системы в случае сбоев интеграции», — рекомендует эксперт. На четвертом, завершающем этапе после интеграции все заинтересованные стороны обеспечиваются документацией на изменения в работе систем, а при необходимости, также проходят обучение.
«Для гарантии непрерывности бизнес-процессов во время интеграции систем необходимо предварительно разработать план, описывающий шаги по предотвращению, реагированию и восстановлению в случае любого сбоя, оценить потенциальные риски и уязвимости в бизнес процессах, стараться проводить интеграции поэтапно, чтобы уменьшить воздействие изменений на всю бизнес среду, выполнять тестирование каждого этапа до перехода к следующему. Не следует забывать и о ключевых мерах отказоустойчивости, таких как резервное копирование, план восстановления, постоянный мониторинг и прочее», — отвечает Анатолий Савинков («Абак-2000»).
«Если мы говорим о переходе с одной систему на другую, необходимо обеспечить возможность одновременной работы с обеими системами на момент интеграции, — советует Константин Тельной (Simple). — На время процесса такой миграции обычно делается проверка наличия данных в новой системе и в случае их отсутствия чтение из старого источника и запись в новое место. Еще одним не маловажным моментом я бы назвал оценку возможности интегрируемой системы выдерживать предполагаемую нагрузку которую планируется подключать. Одно дело протестировать все на тестовом стенде, но в момент переключения может оказаться, что система не была готова к такому количеству пользователей, либо не умеет так быстро подстроится под новую нагрузку и переключение нужно было распределять равномерно на какое-то время».
«Очень важный этап — планирование и управление интеграцией. Если неверно его провести, будет сложно избежать простоев бизнеса. Также перед началом интеграции важно верно расставить приоритеты. Системы с наиболее высоким приоритетом лучше всего интегрировать в часы их минимального использования. А для бесперебойной работы бизнеса во время интеграции важно постоянно находиться на связи с командой, чтобы получать оперативную информацию о ходе интеграции, быстрые ответы на вопросы, а также необходимые данные о сроках восстановления систем в случае их падения», — рекомендует Анна Чеснокова (SimbirSoft).
Опубликовано 04.12.2023