Экспертный кейс. История расследования одного небыстрого закрытия месяца в 1C:ERP. Пример неочевидных путей расследования в виде детективной истории
В данной статье хотим рассказать об одном нашем непростом расследовании, в котором удалось собрать сразу несколько проблем на разных уровнях инфраструктуры заказчика и изначальной методологии ведения учета. Само расследование в какой-то момент стало напоминать детективную историю, с роялями в кустах, ошибками платформы, странным поведением пользователей и магическим поведением хорошо знакомых механизмов. Но мы реалисты, поэтому все проблемы были выявлены и устранены 😉
- Описание
- Подробнее
Описание
В данной статье хотим рассказать об одном нашем непростом расследовании, в котором удалось собрать сразу несколько проблем на разных уровнях инфраструктуры заказчика и изначальной методологии ведения учета. Само расследование в какой-то момент стало напоминать детективную историю, с роялями в кустах, ошибками платформы, странным поведением пользователей и магическим поведением хорошо знакомых механизмов. Но мы реалисты, поэтому все проблемы были выявлены и устранены J
Инфраструктура
Платформа 1С:Предприятие 8, версия 8.3.17.1549
1С:ERP Управление предприятием 2, версия 2.5.5.77
Сервер СУБД: MS SQL Server
Виртуализация средствами VMware
Количество баз ERP: 20+
Все 20 ИБ работают в режиме «20 кластеров на одной ВМ»:
- один сервер приложений 1C
- один сервер СУБД
- один сервер лицензирования
Проблема, с которой пришел заказчик
В одном крупном отечественном публичном акционерном обществе, в более 20 дочерних организаций (далее ДО) учет ведется в 1С:ERP Управление предприятием 2 (далее ERP) – по базе на ДО. В одной из баз ДО (наиболее крупной) процедуры быстрого закрытия месяца выполнялись неприемлемо долго.
Детализация проблемы – понимаем масштаб бедствия
Что показало обследование текущего положения дел:
1. Сроки выполнения закрытия месяца не устраивали заказчика абсолютно. Например, в самой крупной ДО вся процедура стала выполняться более суток!
2. А самая длительная операция – непосредственно расчет себестоимости, – выполнялась порядка 9-11 часов.
3. Длительность операции отражения документов в регламентированном учете достигала 12 часов.
4. Кроме этого, сам расчет себестоимости далеко не всегда завершался успешно. Часто возникала ситуация, когда фоновое задание внезапно неожиданно прекращало свою работу. Все приходилось начинать заново, что катастрофически замедляло весь процесс и требовало «ручного» контроля выполнения требуемых операций.
5. Исходя из аппаратных мощностей заказчика были попытки запустить на одновременное выполнение закрытие месяца в 20+ баз ERP, но эти попытки к успеху не привели – фатальная деградация производительности возникала и в этом случае.
На момент обращения к нам у заказчика был организован такой порядок: закрытие месяца запускалось последовательно в каждой базе ERP. С дежурством ответственных лиц по круглосуточному графику.
Самое начало – декомпозиция проблемы
После обследования проблему заказчика укрупненно разбили на две подзадачи:
