За последний год я достаточно кардинально поменял сферу своей деятельности и ушел от технологий управления, проектирования и разработки, построенных на решениях 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 часа.
В результате можно выделить следующие причины, которые меня не устраивали как руководителя, почему данную обработку необходимо была кардинально переделать:
- Общая неуправляемость.
- Мешает работать пользователям.
- Низкая собственная производительность.
- Отсутствие внятной отчетности по результатам работы.
Чтобы устранить негативные причины, было решено прийти к следующей целевой схеме:
Как следствие наметился следующий план работ:
- Уменьшение блокировок путем:
- остановки восстановления последовательности при ошибках,
- мгновенная не аварийная остановка процесса восстановления по требованию.
- Вынос логирования работы обработки во внешнюю базу данных.
- Отказ от неуправляемого убийства работающего процесса восстановления последовательности.
- Автоматическая установка периода восстановления последовательности в зависимости от нагрузки на систему и количества документов за период.
- Разработка отчетности.
В следующих постах планирую подробно осветить каждый этап обозначенного выше плана со сравнительным анализом старого и нового механизмов работы.