К сожалению, с момента описываемых событий прошло много лет, поэтому скриншоты и подробная техническая информация не сохранились. Тем не менее, сам кейс показателен с точки зрения сопровождения типовых решений 1С.
В тот период мы обслуживали конфигурацию УПП (Управление производственным предприятием, редакция 1.3). Платформа 1С:Предприятие 8.3 только начинала появляться в эксплуатации. Информационная база была большой, поэтому обновления конфигурации мы выполняли либо ночью, либо рано утром, пока пользователи не начали работу.
Однажды рано утром один из специалистов выполнял обновление конфигурации на сервере. Обновление завершилось без ошибок, каких‑либо предупреждений платформа не выдала. Однако примерно через 30 минут начали поступать звонки от пользователей:
• при открытии документа «Начисление заработной платы организации» открывался «Кадровый перевод»;
• при открытии документа «Прием на работу» открывалось «Начисление заработной платы».
Предварительный вывод: ссылки на объекты конфигурации (формы/документы) были полностью перепутаны. Как именно это произошло, установить уже не представлялось возможным; необходимых артефактов для анализа не сохранилось. Работу предприятия такая ситуация фактически парализовала. Можно предположить, что произошел сбой кэширования метаданных или некорректная привязка к другой версии конфигурации на сервере, но проверить эти гипотезы было уже нельзя.
Мы обратились в техническую поддержку 1С, не рассчитывая на быстрый результат. Тем не менее, от техподдержки поступил стандартный запрос: выслать базу для анализа.
Параллельно мы создали копию информационной базы, в которой воспроизводилась описанная проблема, и начали искать оперативное решение. Среди предложенных вариантов была простая идея: выполнить явную загрузку той же самой конфигурации из файла.
В конфигураторе был выполнен следующий шаг: «Конфигурация» → «Загрузить конфигурацию из файла» → выбран актуальный файл конфигурации → выполнена загрузка. После завершения операции:
• ссылки на объекты встали на свои места;
• данные в базе сохранились;
• функциональность восстановилась в полном объеме.
Инцидент был успешно локализован, однако в моменте ситуация выглядела критической.
Вторая характерная история была связана с этой же информационной базой. В процессе закрытия месяца бухгалтерия столкнулась с тем, что не удается закрыть счет 20: в отчете появлялась необъяснимая сумма, а причины расхождений выявить не удавалось.
Те, кто работал с закрытием месяца в УПП, понимают, что это ресурсоемкая и сложная процедура, особенно при регламентном бизнес‑процессе, когда при возникновении ошибки на одном из этапов требуется повторно проходить все этапы заново. По традиции, начальное предположение звучало так: «проблема на стороне программистов». Мы начали детальное расследование.
Анализ цепочки документов привел нас к одному из первичных документов (по памяти — «Передача материалов в эксплуатацию»). При просмотре проводок удалось заметить некорректное заполнение счета:
• вместо счета бухгалтерского учета был выбран одноименный счет из плана счетов налогового учета.
• Ошибка выглядела неочевидной при беглом просмотре, поскольку наименование счетов совпадало, отличалась только принадлежность к плану счетов. После корректировки счета в документе и повторного запуска закрытия месяца проблема была устранена.
В обоих случаях нам удалось восстановить работоспособность системы и подтвердить, что:
• даже при формально «успешном» обновлении конфигурации стоит закладывать время на оперативную проверку критичных сценариев;
• при аномалиях при закрытии месяца важно внимательно проверять не только алгоритмы, но и корректность выбора счетов в первичных документах, особенно при наличии нескольких планов счетов.
Спасибо за внимание.
