Потеря быстродействия 1С: как ИТ-директору найти причину и снизить риск

Для пользователя корпоративная система либо работает, либо нет. Если документ проводится минуту вместо нескольких секунд, закрытие месяца затягивается, а утром в 1С невозможно войти, претензия быстро доходит до ИТ-директора. За простой жалобой стоит более сложный вопрос: где реальная причина, насколько она опасна для бизнеса и что исправлять в первую очередь.

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

Ситуация 1. Пользователи недовольны: где искать причину

Самая дорогая ошибка при деградации – начать лечить систему по первой правдоподобной версии. Высокая загрузка CPU ещё не доказывает, что нужны новые процессоры, а блокировки не всегда следует устранять первыми.

Подход ИТ-Экспертизы начинается не с переписывания кода, а с проверки технологического контура. Сначала оцениваются ОС и виртуализация, серверные ресурсы и дисковая подсистема, настройки СУБД и кластера 1С. После проверки инфраструктуры переходят к прикладному уровню: запросам, транзакциям, блокировкам и коду. Ценность здесь – не перечень замечаний, а причинно-следственная картина и порядок действий.

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

Отдельная боль – расчёт себестоимости и закрытие месяца. В крупном агропромышленном холдинге операция занимала чуть более 11 часов. После сокращения объёма обрабатываемых и записываемых данных, изменений в учёте и распределении партий НДС и функциональных доработок время сократилось до 2 часов 20 минут. В другом промышленном проекте – с 12 до 8 часов. Эффект может быть разным, но принцип один: сначала найти реальное ограничение, а не пытаться ускорить критичную операцию одной настройкой.

Ситуация 2. Впереди запуск или масштабирование: выдержит ли система

Функциональные тесты могут пройти успешно, а инфраструктура – соответствовать расчётам. Но промышленная нагрузка складывается из одновременной работы пользователей разных ролей, интеграций, фоновых заданий, массовых расчётов и пиков вроде закрытия месяца. Поэтому «серверы соответствуют спецификации» и «система выдержит бизнес-сценарий» – разные утверждения.

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

Здесь возможны несколько сценариев. Компания может впервые запускать крупную ERP на 1С и ещё не знать, какие операции станут критичными под полной нагрузкой. При переходе с SAP на 1С:ERP команда сталкивается с новой платформой и должна заново сформировать профиль нагрузки и критерии быстродействия. Третий вариант – действующая база работает нормально, но к ней собираются подключить ещё несколько заводов или обществ.

В одном проекте по масштабированию 1С:ERP. Управление холдингом анализировали влияние роста системы на производительность и ключевые операции, включая закрытие месяца. До масштабирования выявили узкие места разной критичности, конфликты блокировок и настройки СУБД, связанные с таймаутами и аварийными завершениями процессов. Такая проверка позволяет найти ограничения до того, как новые подразделения начнут конкурировать за ресурсы уже в продуктиве.

Ситуация 3. Каждая команда доказывает, что проблема не у неё

У инфраструктуры «ресурсы в норме», у администраторов СУБД «база живая», у разработчиков «код не меняли». Это один из самых неприятных сценариев: совещания идут, метрики пересылаются между командами, а бизнес продолжает ждать.

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

В одном корпоративном контуре очереди на процессор возникали при невысокой общей загрузке CPU; одновременно проявлялись пики дисковой активности, длительные транзакции и нагрузка со стороны прикладного кода. По отдельности каждая команда могла показать «нормальные» цифры. Сводный анализ позволял связать события и определить, какая команда должна действовать дальше.

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

Ситуация 4. Как перестать узнавать о проблеме от пользователей

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

«Умный мониторинг» ИТ-Экспертизы собирает данные о работе 1С и технологического контура, поддерживает оповещения и анализ первопричин. Для руководителя это сокращает путь от «что-то медленно» до конкретной зоны диагностики.

Корпоративная поддержка отвечает на следующий вопрос: что произойдёт после сигнала. В 1С:РКЛ от ИТ-Экспертизы к стандартной поддержке добавлены проактивный мониторинг и уведомления, ускоренная реакция на критичные обращения, регулярные отчёты о состоянии и рекомендации по улучшениям. Так вместо набора разовых обращений формируется постоянный контур управления технологическим риском.

Карта решений для ИТ-директора

• Бизнес жалуется на скорость или долго выполняется критичная операция – технологический аудит: сначала инфраструктура, затем прикладной слой.

• Впереди новый ERP, переход на 1С или подключение новых заводов и обществ – нагрузочное тестирование бизнес-сценариев и проверка запаса прочности.

• Команды спорят, где причина – сквозная экспертная диагностика с единой картиной и разделением зон ответственности.

• Инциденты повторяются, а первым о них узнаёт бизнес – мониторинг и формализованный процесс корпоративной поддержки.

Смежный кейс: управление сложной цифровой экосистемой

Проект создания единой цифровой экосистемы «Уралхима» стал победителем конкурса «1С:Проект года 2026» в номинации по управленческому учёту. В пилотном контуре автоматизированы 450 рабочих мест и 603 бизнес-процесса, настроено 119 интеграционных потоков. ИТ-Экспертиза участвовала в создании интеграционного слоя на базе «1С:Интеграция КОРП» и передаче компетенций внутренней команде. Подробнее о проекте «Уралхима»

Что в итоге

ИТ-директору не нужно лично подбирать параметры PostgreSQL или искать строку кода, вызывающую блокировку. На его уровне важно другое: сделать производительность, стабильность и готовность к росту управляемыми, опираясь на измеримые критерии, понимание реальных рисков и подходящие для каждой ситуации инструменты. Тогда разговор с бизнесом меняется с «кажется, стало быстрее» на «мы знаем, что происходит, что исправили и какой запас у системы остался». Компания «ИТ-Экспертиза» полностью готова выступить надежным партнером в решении этих высокотехнологичных задач. Обращайтесь: info@it-expertise.ru

Корпоративные решения ИТ-Экспертизы