Знакомство и автоматизация восстановления последовательности (начало)

За последний год я достаточно кардинально поменял сферу своей деятельности и ушел от технологий управления, проектирования и разработки, построенных на решениях Microsoft. Теперь я занимаюсь, пожалуй, самой популярной информационной системой в России – 1С (редакция УПП). За год я сумел немного изучить продукт 1С как с технической точки зрения, так и с точки зрения организации командной разработки, неудивительно, что у меня появилось желание начать делиться некоторыми решениями, построенными на данной платформе. В отличии от моих предыдущих постов, часть статей будет на русском и будет объединять в себе как технику, так и командную работу.

В учете 1С УПП есть такое понятие, как восстановление последовательности. Детально про этот процесс можно прочитать по ссылке, здесь я скажу, что он важен, что он занимает много времени (при большом объеме документов). В дополнение: в моем случае граница регулярно падает на несколько недель в прошлое, и нужно очень быстро ее восстанавливать до текущей даты, при том, что наша 1с используется в режиме 24 на 7 (за исключением половины воскресенья).

Год назад было внедрено решение, которое в автоматическом режиме запускало восстановление последовательности в ночное время (когда нагрузка на систему минимальна) и работала по следующим принципам:

  • С 20-00 до 2-00 обработка с небольшой паузой двигала последовательность на 1 минуту, а с 2-00 до 4-00 – на 3 минуты.
  • Существовала возможность через константу остановить работу обработки.

В общем виде принципиальная схема работы может быть изображена следующим образом:

В результате система за 8 часов проходила 2-3 рабочих дня, при этом с первого дня работы выявились следующие недостатки:

  • Несмотря на щадящий режим работы, регулярно возникали блокировки с работающими пользователями. Как результат – приходилось ночью регулярно останавливать проведение.
  • Бухгалтерию категорически перестали устраивать 2-3 рабочих дня за ночь.

При ближайшем рассмотрении обработки выявились еще дополнительные недостатки разработанного решения:

  • Логирование работы велось в журнал регистрации – очень спорный инструмент 1С, с моей точки зрения, катастрофически неудобный для системного анализа.
  • Обработка запускалась через клиент 1С, который стартовал планировщиком Windows через bat-файл. При этом обработка иногда подвисала, и, так как планировщик с наружи не мог увидеть, что делает 1С, то раз в три часа процесс на сервере убивался и запускался заново.
  • Ошибки блокировки никак не анализировались, наоборот, при ошибках система начинала двигать последовательность в цикле и без паузы, что приводило к остановке работы пользователей на 1-2 часа.

В результате можно выделить следующие причины, которые меня не устраивали как руководителя, почему данную обработку необходимо была кардинально переделать:

  1. Общая неуправляемость.
  2. Мешает работать пользователям.
  3. Низкая собственная производительность.
  4. Отсутствие внятной отчетности по результатам работы.

Чтобы устранить негативные причины, было решено прийти к следующей целевой схеме:

Как следствие наметился следующий план работ:

  1. Уменьшение блокировок путем:
  • остановки восстановления последовательности при ошибках,
  • мгновенная не аварийная остановка процесса восстановления по требованию.
  1. Вынос логирования работы обработки во внешнюю базу данных.
  2. Отказ от неуправляемого убийства работающего процесса восстановления последовательности.
  3. Автоматическая установка периода восстановления последовательности в зависимости от нагрузки на систему и количества документов за период.
  4. Разработка отчетности.

В следующих постах планирую подробно осветить каждый этап обозначенного выше плана со сравнительным анализом старого и нового механизмов работы.

Добавить комментарий

Ваш адрес email не будет опубликован.