Исходные данные: «1С: ДО КОРП» версии 2.1.10.2, которую нужно обновить до актуальной 2.1.33.6. Проект осложнялся дополнительными факторами:
- в организации работает свыше 5000 сотрудников;
- медленные сервера;
- объем базы в 260 ГБ (файлы хранились в томах отдельно);
- работа в базе ведется круглосуточно, максимально разрешенное технологическое окно — 1 час за выходные (в реальности все-таки 3 часа смогли выделить).
Установка обновления на рабочую базу обычным способом, как мы позже выяснили в ходе тестирования, заняла бы около 1,5 недель. Казалось бы, невозможно успеть обновить ИБ.
Мы предложили заказчику использовать механизм из ERP — «Обновление через копию».
Часть первая, короткая, теоретическая: как работает «Обновление через копию» в 1С:ERP — и как перенести механизм на «1С: Документооборот КОРП»
По нашей задумке требовалось разобраться, как работает этот механизм, и внедрить его в ДО.
Основные положения плана были такими:
- Обновить конфигурацию с 2.1.10 на 2.1.36 «как обычно», протестировать работу объектов «как обычно» («дымовое», сценарное, пообъектное виды тестирования). «Как обычно» — это так, как мы делаем при стандартном подходе на наших проектах обновления.
- Создать копию обновленной конфигурации 2.1.36 (назовем это обязательной промежуточной), куда нужно встроить ERP-подсистему «Обновление через копию» и все связанные с ней объекты, адаптировать их в двух конфигурациях: в «рабочей» и в «обновленной».
- В состав плана обмена в обеих конфигурациях включить объекты, которые используются заказчиком (от заказчика получили такие списки).
- Написать правила обмена между конфигурациями на КД 3.1.
- Настроить обмен между «рабочей» и «обновленной» базой (разумеется, сначала на тестовой паре баз).
- Протестировать всю цепочку: регистрацию данных в рабочей базе, отправку файла обмена, приемку файла обмена в обновленную базу, запуск обновления на монопольные и отложенные обработчики обновления, завершение обмена.
План обновления виделся таким:
- Внедрить в «прод» заказчика нашу версию рабочей конфигурации, куда встроен план обмена «Обновление через копию».
- Начать копить зарегистрированные данные в рабочей базе.
- Создать копию рабочей базы данных, обновить ее на конфигурацию с планом обмена «Обновление через копию» на монопольные обработчики, начинаем обновлять на отложенные.
- Настроить обмен между базами.
- Ежедневно принимать файл обмена в обновленную базу и ждать, пока обновление новой порции данных не начнет укладываться в технологическое окно.
- Завершить обмен в рабочей базе, заблокировать доступ к «боевой» базе для всех пользователей, принять последний файл обмена в обновленной базе.
- Последний раз провести обновление на монопольные и отложенные обработчики.
- Загрузить в базу обновленную конфигурацию без плана обмена «Обновление через копию».
- И, наконец, перевести всех пользователей на работу в обновленной базе.
Средства, которые мы использовали для разработки этого проекта:
- ERP версии 2.5.23.70 в качестве источника подсистемы «ОбменЧерезКопию»
- КД версии 3.1.5.35 для создания правил обмена
- Опыт коллеги «Обновление через копию» - как это использовать?
- Информативная ветка с комментариями на партнерском: https://partners.v8.1c.ru/forum/topic/1940374
- Наш собственный опыт 100+ сложных обновлений 🙂👍
Часть вторая, длинная, практическая: что пошло не по плану и как мы с этим справлялись
Честные признания об обновлении и подводных камнях, с которыми пришлось столкнуться.
1. Потеря данных при обновлении
В процессе тестирования некоторые обработчики обновления отработали некорректно и произошла потеря данных. По-хорошему, нужно обновлять на промежуточный релиз 2.1.19, но поскольку ошибки были незначительными, скорректировать обработчики обновления в финальной версии 2.1.36 было быстрее и удобнее.
Подробнее о выборе ключевых релизов для обновления можно узнать в наших материалах:
- Промежуточные конфигурации, часть 1: зачем они нужны и как их правильно подобрать для обновления нетиповой 1С
- Промежуточные конфигурации 1С, часть 2: что делать, если база не успевает обновиться
2. Оптимизация и распараллеливание обработчиков
По первым замерам обновление на отложенные обработчики шло немногим меньше двух недель. Всё из-за того, что в ДО 2.1 отсутствует многопоточное выполнение обработчиков обновления, а обработать надо несколько миллионов объектов данных.
Самой проблемной была процедура обновления ЗаполнитьФормуДокументовОтложенно() при обновлении на 2.1.21.11. Эта процедура заполняет реквизит ФормаДокумента у всех входящих / исходящих / внутренних документов. Документов было 4 миллиона, за раз выбиралось всего по 500 ссылок.
Мы распараллелили этот обработчик на 10 потоков и увеличили выборку до 10 тысяч ссылок за раз, срок работы этого обработчика сократился с недели до 12 часов.
Также проверили все другие обработчики обновления:
- нашли еще один медленный обработчик ПерейтиНаВерсию_2_1_11_4() который обрабатывает 3 миллиона записей в регистре сведений ФайлыВРабочемКаталогеКомпьютера и распараллелили его таким же способом;
- увеличили размер порций выборки в запросах везде, где это было возможно.
3. Изолированность подсистемы «Обновление через копию»
Самым важным было то, что в процессе обновления, пока объекты будут регулярно передаваться в обновленную базу, пользователи должны будут продолжать работу в своей «рабочей» базе. А их «Документооборот» связан обменами с другими конфигурациями 1С. Так что нам нужно было учесть, чтобы наше внедрение подсистемы «Обновление через копию» не изменяло код общих модулей для обмена.
Для гарантии работоспособности других обменов мы внедрили со своими префиксами в ДО модули из ERP — ОбменДаннымиСервер и несколько с ним связанных модулей, обработки КонвертацияОбъектовИнформационныхБаз и ТранспортСообщенийОбменаFILE, подсистему НастройкиТранспортаОбмена. И заменили все вызовы из модуля ОбновленичеЧерезКопию на вызовы из ERP.
Таким образом все существующие обмены должны работать без изменений, а подсистема ОбновлениеЧерезКопию будет пользоваться только своими общими модулями, полученными из ERP.
Также важно было сделать это для обновленной конфигурации.
4. ОбменДанными. Загрузка
На всякий случай проверили, что в обновляемой конфигурации во всех типовых и нетиповых объектах стоит условие, которое отключит логику проверки заполнения, записи, проведения полученных объектов.
Если ОбменДанными. Загрузка Тогда
Возврат;
КонецЕсли;
И не зря. Таких объектов оказалось очень много.
Далее — о трудностях обмена.
5. Константы
Изначально было не до конца понятно, как определить, какие константы должны участвовать в обмене, а какие не должны. Отслеживать их изменение в период обновления и переносить вручную — нецелесообразно, разбираться в предназначении каждой из 100+ констант — долго, посмотреть, как сделано в ERP — неинформативно, ДО слишком сильно отличается.
Методом проб и ошибок выяснили, что необходимо регистрировать к обмену все константы, за исключением констант:
- относящихся к подсистеме БСП,
- начинающихся на «Удалить»,
- относящихся к плану обмена «Обновление через копию» и синхронизации
При этом состав отправляемых констант в составе плана обмена должен на 100% совпадать с составом в подписках, с составом ПКС в правилах обмена для НабораКонстант.
P. S.: это касается не только констант, но и некоторых регистров сведений и справочников, связанных с обменом — их передавать не нужно.
6. Передача типов БизнесПроцессСсылка и ТочкаМаршрутаБизнесПроцессСсылка
В ходе тестирования переноса бизнес-процессов в ДО выяснилось, что конвертация данных, как 2.1, так и 3.1, не умеет работать с типами БизнесПроцессСсылка и ТочкаМаршрутаБизнесПроцессСсылка.
Типовая ERP при попытке передать такой тип выдает ошибку (но, видимо, никому это никогда не мешало). Однако в ДО бизнес-процессы очень важны и передавать их корректно — обязательно.
Эту проблему мы решили следующим образом: доработали правила выгрузки и правила загрузки.
Пример передачи точек маршрута в бизнес-процессе.
Перед выгрузкой в параметр запоминаем Индекс точки маршрута.
После загрузки из параметра читаем Индекс, находим точку маршрута по нему.
Ниже пример передачи типа БизнесПроцессСсылка в ПКО ЗадачаИсполнителя.
На скриншоте выделены три ПКС.
В ПКС БизнесПроцесс указан тип «Утверждение», но это конвертация неправильно понимает тип БизнесПроцессСсылка, в строке указывается первый из всех типов. Это тоже может вызывать ошибку вида «Объект не найден» (об этом подробнее в конце этого пункта).
Два других ПКС — передача в параметр типа бизнес-процесса и точки маршрута. Перед выгрузкой типа БизнесПроцессСсылка
После загрузки типа БизнесПроцессСсылка
Чуть выше упоминалось об ошибке вида «Объект не найден» из-за чтения типа БизнесПроцессСсылка.
В некоторых регистрах сведений тип измерения может указываться так:
так:
или даже так:
В случаях, когда в типе источника и/или приемника указан только БизнесПроцессСсылка в КД 3.1 не нужно указывать тип источника и/или приемника (как на скриншоте), иначе в файле обмена запись сформируется с указанным типом (а это может быть любой другой бизнес-процесс), а при загрузке получим ошибку «Объект не найден». На скриншоте — неправильное формирование записи в файле обмена.
Можно вручную отредактировать правила, а можно удалить типы в КД 3.1. Пример:
Суть доработки в том, чтобы Тип всегда совпадал с типом приемника в файле выгрузки вот так:
В случае, когда в типе указан БизнесПроцессСсылка + конкретный БизнесПроцесс можно оставить тип конкретного бизнес-процесса в обработке КонвертацияОбъектовИнформационныхБаз тип приемника переопределится).
В случае, когда в типе указан БизнесПроцессСсылка + ссылка на другой ссылочный объект аналогично предыдущему случаю.
7. Бизнес-процесс «Комплексный»
После первой проблемы с бизнес-процессами сразу же обнаружилась вторая: у бизнес-процесса «Комплексный» есть как собственные точки маршрута, так и точки маршрута принадлежащие другим типам бизнес-процессов. Поэтому оказалось недостаточно передавать в параметр лишь индекс точки маршрута, нужно было передавать еще и тип.
Для этого записываем его в параметр:
И получаем после загрузки:
При отладке особое внимание уделили случаю, когда передается комплексный процесс, в который вложен еще один комплексный процесс.
8. Другие бизнес-процессы
Были еще аналогичные проблемы с передачей бизнес-процессов «Обработка внутреннего \ входящего \ исходящего документа», но в ходе тестирования выяснилось, что у заказчика таких бизнес-процессов в базе нет, так что эти правила мы просто отключили 🤫
9. Передача типа ПланОбменаСсылка
К сожалению КД 3.1 не понимает, как работать с этим типом.
Поэтому его передачу тоже реализовали через параметр: номер узла запоминаем в параметре перед выгрузкой свойства, после загрузки объекта читаем из параметра, находим нужный узел по наименованию и записываем.
10. Неявные вызовы объектов подсистемы Обмен через копию
При тестировании мы обнаружили, что у нас не заполняется регистр сведений ОбновлениеЧерезКопиюДинамикаПроцесса, который должен хранить данные о количестве зарегистрированных к обновлению / количестве обновленных объектов.
Оказалось, что в ERP есть вызовы функций подсистемы «Обновление через копию» из других модулей, которые не входят в эту подсистему. Речь идет о модуле ERP ОбменДаннымиЛокализация. Такого модуля в ДО нет, так что все вызовы из него были перенесены в ОбменДаннымиПереопределяемый.
11. Файлы в томах на диске
Завершив отладку обменов на тестовых базах, мы встроили подсистему обновления через копию в боевую базу. Пока выполнялось обновление копии базы у нас регистрировались к обмену реальные данные. После выгрузки зарегистрированных данных мы были удивлены — размер файла обмена был около 25 Гб. Загрузка такого файла заняла около суток.
Для определения причин формирования большого размера файла данных и долгой загрузки в обновленную базу мы выполнили замеры производительности при выгрузке и загрузке. Замеры показали неожиданную причину: файлы, которые хранятся в томах на диске, при выгрузке считываются, помещаются в файл обмена в виде двоичных данных, а при загрузке считываются из файла и перезаписываются в тома🤯. Оказалось, что это особенность выгрузки присоединенных файлов подсистемы БСП, и возможно, в конфигурации ERP это имеет смысл для некоторых обменов, но в текущем проекте для обмена «Обновление через копию», где мы переносим только ссылки на файлы, нам совсем не нужно их перезаписывать (учитывая, что в «Документооборот», как правило, ведется работа с присоединенными файлами).
Мы отказались от перезаписи присоединенных файлов, благодаря этому общее время загрузки одного суточного файла в базу сократилось в 3 раза.
12. Версионирование объектов
Еще одна особенность обменов подсистемы БСП — создание версий объектов при загрузке, что тоже замедляет выполнение обмена. В нашем случае объекты должны передаваться «1-в-1», и при записи нам не требуется создавать новую версию объекта, поэтому, как и в предыдущем случае, мы отказались от функционала БСП.
СтандартныеПодсистемыСервер. ПриПолученииДанныхОтГлавного()
13. Дескрипторы
Еще одной причиной замедления обмена стал регистр сведений Дескрипторы прав доступа. Это регистр сведений, который содержит права доступа пользователей на объекты ДО. Его особенность заключается в том, что регистр постоянно перезаписывается регламентным заданием пересчета прав.
Через сутки после включения регистрации в боевой базе по этому регистру было зарегистрировано более 4 млн записей к выгрузке. Если их передавать то мы никогда не сможем приблизится к минимальному технологическому окну — регистр наполняется новыми записями быстрее, чем мы успеваем их передавать
В итоге решили отключить передачу этого регистра и связанных с ним объектов, а после выполнения обновления запустить регламентное задание, которое пересоздает все дескрипторы для всех объектов базы.
14. Движения самописных документов
При передаче движений документов сделали всё, как указано в справке: установили признак ОбъектСДвижениями, убедились, что появилась табличная часть с движениями документа.
Может быть это «глюк» именно этой версии КД 3.1, но при выгрузке конвертации в правила свойство ОбъектСДвижениями = true выгружался отлично, но если загрузить эту же конвертацию обратно в КД 3.1, то галка в документе слетала.
Проблема обмена была в том, что при запуске обмена сначала всегда происходило чтение файла правил конвертации из регистра ПравилаДляОбменаДанными в тип ХранилищеЗначения, и после выгрузки в кэш в этих правилах отсутствовало свойство ОбъектСДвижениями. Из-за того, что эти самописные документы в рабочей базе при проведении генерировали бизнес-процессы, которые тоже регистрируются к обмену через копию, при проведении документа в обновленной базе после получения мы рисковали получить дубли бизнес-процессов.
Решение подсмотрели в статье «Обновление через копию» — как это использовать? Заполнили обработчик «Перед загрузкой» для каждого документа с движениями текстом:
РежимЗаписи = «Запись»;
В нашем случае (в отличие от случая в статье) документы не стали пытаться проводиться, так как мы заблаговременно приняли решение закомментировать код проведения документов в обработке КонвертацияОбъектовИнформационныхБаз.
Такое решение нам подошло (но лучше бы ОбъектСДвижениями заполнялся сам).
15. Обработка КонвертацияОбъектовИнформационныхБаз
В этой обработке нам потребовалось предусмотреть все случаи, описанные в пунктах выше.
Были внесены следующие изменения в алгоритмы приемки / записи объектов в обработке КонвертацияОбъектовИнформационныхБаз:
- Отказ от версионирования.
- Отказ от записи присоединенных файлов.
- Отказ от записи соответствий объектов в регистр СоответствияОбъектовИнформационныхБаз.
- Отключение механизма регистрации объектов в обновляемой базе при приемке, чтобы они заново не регистрировались к другим обменам.
- Отказ от записи объектов с включением логики записи (обработчики проверки заполнения в массив ОбъектыДляОтложеннойЗаписи).
- Отказ от проведения документов (так как переносим сразу с движениями).
16. Неинформативный типовой отчет о прогрессе
В типовом ERP есть отчет «Динамика обновления», который по данным регистра ОбновлениеЧерезКопиюДинамикаПроцесса сообщает о прогрессе обновления принятых данных.
Оказалось, что в ERP (на момент работ по проекту) нет кода, который бы проверял, сколько из принятых объектов уже были обновлены, и в ходе обновления данные этого регистра никак не обновляются.
Коллега в вышеуказанной статье предлагает свои обработки, для подсчета объектов, нуждающихся в обновлении.
Результаты работ
Мы добились сокращения времени обновления базы «1С: Документооборот» с 1,5 недель — до 1 суток.
При этом обменами дошли до выгрузки, которая умещается в технологическое окно, всего за 15 часов:
- С момента снятия копии с базы и до завершения обновления базы прошло 24 часа.
- Всего за сутки было зарегистрировано 133000 объектов к выгрузке, размер файла выгрузки составил 700 МБ.
- Финальная выгрузка состояла из 2600 объектов, заняла 15 минут на операции выгрузки\загрузки.
Также в момент обновления узнали, что у заказчика в настройках базы SQL была установлена полная (FULL) модель восстановления (RECOVERY MODEL), а не простая (SIMPLE), что тоже повлияло на скорость обновления.
Какой ещё багаж мы вязли из этого проекта:
- Получили уникальный опыт обновления через копию базы, для которой этот механизм не предусмотрен.
- Создали готовую изолированную подсистему «Обновление через копию» на основе ERP, которую можно встраивать в любую другую конфигурацию (с поправкой на версию БСП: чем старше версия БСП, тем труднее встроить). Вынесли все объекты в расширение для удобства.
- Порадовались, что проект не предусматривал обновление базы на промежуточные конфигурации, это избавило нас от переноса обработчиков обновления в правила конвертации. Кроме бизнес-процессов все объекты и их свойства переносились «1-к-1».
- Также порадовались, что в этом проекте нет расширений, что тоже упростило разработку правил конвертации.
- Узнали, что конвертация не умеет работать с некоторыми типами, и бывает «глючит» на передаче движений 🙁
- Еще раз поупражнялись в оптимизации обработчиков обновления.
В следующий раз мы сможем оценить обновление через копию точнее, а сделать — еще быстрее.
Влезем в любое технологическое окно. =)
Вступайте в нашу телеграмм-группу Инфостарт