Дневник импортозамещения. Часть 1: Работа для Бэтмена. Начало

Руководитель корпоративных проектов ALP Group Алексей Гапонов делится четким планом импортозамещения для базы данных на платформе 1С.

Иногда мне кажется, что задачи, с которыми приходится сталкиваться на работе, по плечу разве что Бэтмену — настолько сложными, трудоемкими и масштабными они выглядят на первый взгляд. Но как известно, глаза боятся, а руки делают. В этой серии статей я расскажу о переносе 1С-базы размером 6 ТБ с регистром бухгалтерии с проприетарного ПО (Windows + Microsoft SQL Server) на импортонезависимое (Astra Linux + PostgreSQL).

Впрочем, не так важно, какое именно решение из линейки 1С используется и является ли оно кастомизированным. По-настоящему важно только одно — грамотно составленный план, или, как говорил известный кинозлодей Бейн, «Не важно, кто мы такие, важно, какой у нас план».

Итак, основными этапами плана импортозамещения являются:

Выглядит вроде просто… но на самом деле, каждый пункт требует пояснений, так что наш план усложняется. Детальный, всеобъемлющий и адаптируемый план — основа успеха ИТ-проекта. План должен учитывать все возможные сценарии, задачи и риски. Нам нужно разработать дорожную карту, которая будет включать пошаговый план миграции и комплексную стратегию тестирования. Что ж, приступим…

1. Разворачивание тестового контура, или создание нужной среды.

Точно так же, как Бэтмену нужна Бэтпещера для подготовки к миссиям, нашему проекту для процветания требуется подходящая среда. Для проекта по миграции базы данных функциональное тестирование рекомендуется выполнять на четырех контурах, так как разработку и тестирование функционала удобнее выполнять в тестовой базе небольшого размера, а для проведения нагрузочного тестирования следует использовать базы с предпродуктивными данными, чтобы получить объем и сценарии использования базы, аналогичные рабочим. Таким образом, мы должны создать два контура разработки — Microsoft SQL и PostgreSQL — и два контура тестирования — также Microsoft SQL и PostgreSQL. Эти контуры станут фоном для всего нашего проекта, предлагая безопасное пространство для экспериментов, оттачивания навыков и доработки кода.

2. Анализ необходимых доработок, или поиск уязвимостей.

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

Этот этап, как правило, включает в себя:

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

О тонкостях нагрузочного тестирования мы поговорим чуть ниже.

3. Разработка, или создание своего Бэтмобиля.

Готовясь к битве, Бэтмен будет совершенствовать свои гаджеты, а мы — писать оптимальный код. Помимо работ, выявленных на этапе анализа, мы должны будем адаптировать решение для перехода на новую версию платформы 1С — 8.3.21 — в частности, увеличить режим совместимости. Кстати, здесь карма-полиция настигнет всех тех, кто не спешил обновлять платформу, ожидая, пока другие не набьют шишки.

Также нам потребуется адаптация под Linux механизмов работы с файлами, COM, EXCEL и т. п. И, конечно, подготовка инструментов анализа полноты и целостности данных после перехода с Microsoft SQL на PostgreSQL, которые помогут нам убедиться, что при переходе данные не были утеряны.

4. Свертка базы, или превращение в супергероя.

Перед отправкой на миссию Брюс Уэйн наденет свой черный костюм и обретет способность летать. Чтобы наша база данных тоже «летала», нам нужно будет запустить процесс ее свертки, то есть форматирования одних документов и удаления других. Свертка информационной базы выполняется, чтобы сократить объем данных в рабочей базе и увеличить скорость работы системы. В дальнейшем это позволит нам сэкономить время при реструктуризации.

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

5. Тестирование на предпродуктивных данных, или проверка суперспособностей.

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

В первую очередь, повторюсь, что для проведения нагрузочного тестирования нам нужно будет развернуть две базы на платформе 8.3.21 — одну на Microsoft SQL + Windows, и вторую — на PostgreSQL + Linux.

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

Впрочем, даже если релиз с доработками по импортозамещению будет той же версии, то при его установке всё равно возможна реструктуризация (из-за снятия совместимости). И здесь мы должны будем учесть, что процесс реструктуризации тяжелой информационной базы порой может занимать до нескольких дней, а то и недель! Чтобы не потерять много времени на данном этапе, имеет смысл использовать оптимизированную процедуру реструктуризации — такая методика появилась в 1С начиная с версии 8.3.11, она позволяет ускорить процесс примерно в два раза. Гарантий применимости данной методики на Linux, к сожалению, нет, и, возможно, нам придется использовать промежуточный Windows-контур для решения задачи на PostgreSQL.

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

Следующий момент: поскольку целью нагрузочного тестирования является сравнение времени выполнения критичных процессов в системе, то сервера приложений и сервера баз данных двух контуров должны обладать сопоставимой мощностью — число и частота ядер, память, в том числе на СУБД, и параметры дисков. Также параметры кластера 1С должны быть настроены одинаково. Только так мы сможем исключить влияние аппаратной части на результаты тестирования. В противном случае, если разница обнаружится уже после выполнения сравнительных тестов, мы не сможем сделать окончательные выводы или будем вынуждены проводить тесты заново.

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

Если после всех объяснений кто-то скажет «Я не понял ни слова», я отвечу словами Люциуса Фокса: «Я знаю, просто хотел объяснить, как это было сложно».

Для тех, кто привык мыслить визуально — представим переход на новую платформу 1С 8.3.21 в виде схемы:

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

P. S. А что бы вы добавили в этот план? Очень интересно почитать ваши комментарии ⬇