Меню

«Русагро» столкнулась со сбоями и медленной работой «1С» в крупнейшем бизнес-юните. Самостоятельная поддержка систем не задалась

Как заметил TAdviser, «Русагро», один из крупнейших вертикально интегрированных агрохолдингов в России, решил провести аудит информационных систем «1С» в объединенном масложировом бизнес-направлении (ОМЖБН). Это следует из запроса предложений соответствующих услуг, который компания опубликовала 2 ноября 2026 года.

Масложировой бизнес — крупнейшее направление в «Русагро», активы которого включают маслоэкстракционные заводы и заводы по производству масложировой продукции. По данным годового отчёта компании, в 2025 году оно принесло «Русагро» 49% выручки, около 208 млрд рублей.

Внедрение решений на базе «1С» приведено в числе ключевых цифровых проектов в годовом отчёте. В масложировом бизнесе, в частности, там упоминается внедрение системы «1С» ТОИР на Сорочинской и Урюпинской площадках, а также системы «1С» «Весовая» на площадках группы компаний «НМЖК» с целью централизации процессов.

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

• «1С:УПП МПРА» (конфигурация «1С Управление производственным предприятием 1.3»);
• «1С:ERP МПРА» (конфигурация «1С ERP»);
• «1С:УПП Жировые комбинаты Зеркало» (конфигурация «1С Управление производственным предприятием 1.3»);
• «1С:УПП Жировые комбинаты» (конфигурация «1С Управление производственным предприятием 1.3»);
• «1С:УПП Масло экстракционные заводы, элеваторы» (конфигурация «1С Управление производственным предприятием 1.3»);
• «1С:MDM MZHBN» (конфигурация «1С:MDM Управление нормативно справочной информацией, редакция 2.0»);
• «1С:ТоиР МЖБН» (конфигурация «ТОИР Управление ремонтами и обслуживанием оборудования 2 КОРП, редакция 2.0»).

Рис. За последние 5 лет «Русагро» значительно расширила свои мощности производства масложировой продукции

Проект аудита нацелен на решение нескольких задач. Во-первых, необходимо провести анализ текущих настроек и проверку работоспособности, выявление причин медленной работы систем на базе «1С» для подготовки общих рекомендаций и экспертных решений по повышению производительности и отказоустойчивости решений на платформе «1С:Предприятие 8».

Ещё одной задачей указано выявление причин сбоев, падений производительности системы, фоновых блокировок, зависаний фоновых заданий «1С», медленной работы систем на базе «1С», входящих в ИТ-ландшафт. Это необходимо для подготовки общих рекомендаций и экспертных решений по повышению производительности и отказоустойчивости решений на платформе «1С:Предприятие 8», а также формирования необходимых регламентных процедур для дальнейшего анализа и поддержки производительности информационных систем силами ИТ-специалистов подрядчика.

Работы, которые для этого необходимо выполнить, включают: аудит текущего состояния прикладных баз данных, ОС/СУБД/кластера серверов «1С», мониторинг нагрузки, осуществляемой в стандартном режиме; настройку подсистемы замеров производительности в продуктивных базах данных, подлежащих аудиту и настройку замеров по ключевым операциям; включение технологического журнала «1С» и необходимых для анализа счетчиков работы СУБД, ОС, систем виртуализации, а также последующий анализ проблем стабильности по данным технологического журнала.

Кроме того, будет проведён анализ данных мониторинга по загрузке оборудования и потреблению ресурсов на серверах; анализ настройки серверов, СУБД, кластера «1С», включая проверку на соответствие рекомендациям и стандартам вендора; анализ узких мест в инфраструктуре и решении с точки зрения производительности.

После этого предстоит формирование целевых рекомендаций по перенастройке оборудования и серверного ПО, выдача экспертного заключения о целевой модели инфраструктуры и консультационная поддержка в части изменения настроек целевой инфраструктуры.

На сбор данных в рамках аудита отводится до 14 календарных дней. Анализ данных мониторинга, узких мест информационных баз, проблем стабильности требуется провести за 28 календарных дней. С подготовкой рекомендаций и отчёта по результатам технологического аудита также необходимо уложиться в 28 календарных дней.

В «Русагро» не смогли ответить на вопросы TAdviser, связанные с проблемами в работе «1С».

Стоит отметить, что решения на базе «1С» применяются и в других бизнес-направлениях «Русагро». Для сахарного бизнеса группы, компании «Русагро-Центр», техподдержку корпоративных систем на платформе «1С» в 2025 году оказывала IBS. По завершении трёхмесячного проекта в IBS отмечали большое количество доработок в «1С:УХ» и «1С:УПП», что делало обновление систем до последнего релиза очень сложной задачей, включающей дописывание кода. В ИТ-«дочке» «Русагро», «Русагро Тех», тогда рассчитывали в дальнейшем сопровождать системы «1С» собственными силами, посчитав, что набрались от IBS достаточно информации для этого.

Евгений Филиппов, эксперт отделения «1С»-разработки IBS, рассказал TAdviser, что в целом среди основных причин медленной работы «1С», с которыми их компания регулярно сталкивается на практике, можно выделить несколько и разделить их на ключевые блоки:

Архитектурные ошибки и проблемы кода

• Неэффективный или ошибочный код прикладного решения или его доработок: это могут быть ошибки разработчиков (неоптимальные запросы, неверно установленные блокировки, некорректная работа с составными типами) или не учтенные при внедрении особенности вендорских и партнерских решений.
• Однопоточность при больших объемах данных: часто система работает в один поток там, где масштабы бизнеса и объемы информации требуют многопоточности (здесь возможно два варианта — типового функционала многопоточности не предусмотрено или он есть, но не используется).
• Ошибки архитектуры и выбора метаданных: использование неподходящего прикладного решения для высоконагруженной системы. Классический пример — попытка построить масштабный биллинг на миллионы документов с контролем авансов на регистре бухгалтерии.
• Неоптимальная настройка прав (RLS): избыточные или ошибочные настройки ограничения доступа на уровне записей.

Избыточность функциональности и настроек

• Функциональное перенасыщение: сюда входит как включение и задействование тяжелых механизмов, которые компании на самом деле не нужны, так и избыточная универсальность используемых имеющихся механизмов.
• Избыточная детализация аналитики: слишком глубокий учет «ради учета», усложняющий расчеты.
• Пользовательские настройки: неверные настройки на рабочих местах, сделанные потому, что «платформа это позволяет» (например, группировки в динамических списках на больших объемах данных, неправильное использование поиска).

Проблемы инфраструктуры и окружения

• Недостатки собственной ИТ-инфраструктуры: классические аппаратные проблемы, связанные с нехваткой ресурсов, обычно вытекающие из отсутствия или неполноты контроля за их утилизацией.
• «Болезни» облачной инфраструктуры: в первую очередь переподписка (overselling) ресурсов провайдером, когда ресурсы, выделенные системе, используются кем-то еще.
• Влияние стороннего ПО: работа антивирусов, систем безопасности или логирования сетевого трафика, которые «тормозят» процессы «1С».

Ошибки администрирования и платформы

• Неправильная сборка кластера «1С»: копирование (без проверки на практике) рекомендаций, не являющихся универсальными, или игнорирование специфики конкретной версии платформы, так как некоторые релизы и механизмы (например, СЛК) требуют адаптации архитектуры кластера.
• Некорректное обслуживание баз данных: недостаток регламентных процедур (индексация, обновление статистики) и их избыточность в неподходящее время.
• Ошибки самой платформы: специфические баги конкретных релизов, которые могут влиять на производительность.

Организационные факторы

• Отсутствие профильных специалистов: до сих пор встречаются ситуации, когда в поддержке крупных и высоконагруженных систем нет выделенных экспертов по технологическим вопросам, которые бы на постоянной основе занимались мониторингом и оптимизацией производительности.
• «Неподконтрольные» аномалии: случаи, когда причину определить не удается, например, из-за плавающего характера проблемы или наложения нескольких редких факторов друг на друга.

Технический архитектор департамента «1С» ГК «Корус Консалтинг» Денис Андронов, отмечает, что когда пользователи жалуются на медленную работу «1С», причина может оказаться совсем не в системе. Нередко возникает ситуация, когда разработчики ищут проблему в инфраструктуре, инфраструктурная команда — в коде, тогда как реальная причина задержек скрывается, например, в сетевом оборудовании. В его практике было несколько подобных случаев. Главное при поиске узких мест — системный подход: необходимо проверять все ИТ-компоненты и сопоставлять их метрики, считает специалист.

«Производительность системы на базе «1С» в значительной степени зависит от мощности серверов и каналов связи, настроек платформы и баз данных, архитектуры прикладного решения и качества кода. Так, среди типичных причин медленной работы — ограничения инфраструктуры и нехватка вычислительных мощностей. На уровне самой системы источником задержек часто становятся неоптимальные запросы к базе данных или длительные транзакции (когда система «виснет» при проведении объемного документа из-за перегруженности доработками). Кроме того, система может работать медленнее из-за тяжелых фоновых задач (например, период закрытия месяца), которые идут параллельно с активной работой пользователей. Задержки также могут возникать из-за неоптимально построенных интеграций с внешними сервисами», — перечислил в разговоре с TAdviser Денис Андронов.    

Ограничения производительности не всегда заметны сразу. При внедрении система может работать безупречно, но по мере ее развития — роста объемов данных, увеличения числа пользователей и усложнения интеграций — прежние механизмы могут стать проблемным участком. Даже если когда-то система показывала отличные результаты на нагрузочном тестировании, при изменениях в ИТ-архитектуре или инфраструктуре эти испытания необходимо проводить заново.

Универсального способа ускорить работу системы на базе «1С» не существует. Без качественной диагностики есть серьезный риск потратить бюджет на модернизацию компонента, который на самом деле не является источником проблемы. Например, покупка дорогостоящих серверов никак не решит проблему блокировки документов в базе. Аудит производительности позволяет найти истинную причину и подобрать оптимальное решение: изменить настройки, оптимизировать прикладной код или перераспределить нагрузку. После устранения проблемы результат обязательно нужно подтвердить новым нагрузочным тестированием.

«Однако наиболее эффективный подход — это превентивные меры. Бизнесу выгоднее мониторить сигналы заранее, до того, как сбои критично повлияют на работу пользователей. Для этого необходимо организовать мониторинг, который в реальном времени сопоставляет задержки на стороне пользователей с показателями технических компонентов», — резюмировал Денис Андронов.

Источник: TAdviser.

Больше новостей читайте в сообществе SAPLAND в ВК и телеграм-канале SAPLAND: Новости экосистемы.

Продолжая использовать сайт, вы соглашаетесь на обработку персональных данных, собираемых с использованием cookie-файлов и сервиса «Яндекс Метрика» для анализа использования сайта и оценки эффективности маркетинговых кампаний. Более подробная информация представлена в Политике конфиденциальности.
Понятно