Когда бизнес растёт быстрее, чем успевает 1С: от первого звоночка до явных «тормозов»

Привет, я СБиСик — тот самый пушистый консультант, который обычно прыгает по офису, собирая жалобы вроде «а почему у меня документ крутится дольше, чем я наливаю чай?». Сегодня разложу по полочкам, как именно рост компании ударяет по скорости 1С и почему «да всё же открывается» — не аргумент.

Утро, которое началось с маленькой задержки

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

Кто-то думает: «Ну, сервер не проснулся». Но я вижу знакомый симптом — база живёт на пределе, а количество операций выросло почти вдвое за квартал. Не один процесс тормозит, а вся связка кода, СУБД и сети. Пока обед, считаю простую метрику: суммарное время ожидания пользователей в пиковый час выросло с 17 до 45 минут. Фактически бизнес теряет почти целого сотрудника ежеднвено, только об этом никто не пишет в KPI.

Кстати, подобные мини-истории я иногда выкладываю короче и оперативнее в наш канал в MAX, потому что статья пока допишется — база уже может вырасти ещё на пару гигабайт.

Почему «ещё работает» — не значит «нормально живёт»

Есть старая шутка админов: «Файл открывается? Тогда всё ок». В 1С так не прокатывает. Система может отвечать, но если документ проводится 20 секунд вместо 2 — это уже прямые деньги. Умножаем задержку на количество операций в день и на среднюю зарплату исполнителя — получаем аккуратную строку расходов, которая нигде не отражается, зато прекрасно чувствуется в конце месяца, когда отдел продаж кричит, что «срываются отгрузки».

Частый самообман звучит так: «Купим мощнее сервер — ускоримся». Я на старте своей карьеры тоже верил в чудо Геркулеса-процессора. Но спустя сотню проектов понял: новые ядра спасают ровно до момента, пока статистика СУБД не скажет «а я всё равно читаю медленно, потому что у вас индексы устарели, запросы тяжёлые, а фоновые задания забирают кеш».

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

Первое, что начинает хромать: интерфейс и проведение

Когда база ещё компактная, формы открываются мгновенно, а проведение документа успевает завершиться, пока пользователь переводит взгляд на клавиатуру. Прибавьте 30 новых сотрудников и год исторических данных — и тот же документ лезет во все подсистемы: склад, финансы, CRM-метаданные, регламентные остатки прошлых периодов. Каждая проверка тянет свой запрос в СУБД, каждое обращение ждёт блокировки.

Самый явный маркер — новые пользователи раздражаются быстрее старых. Вчера нанятый менеджер не знает, что «крутится 15 секунд — это нормально», он уверен, что программа должна шустро отвечать. Его первое же «Почему так медленно?» лучшее напоминание, что 1С тормозит не сама, её тормозит несоответствие архитектуры росту нагрузки.

И да, не путайте «сложный документ» и «медленный документ». Иногда пятистрочная реализация в УТ «висит» дольше, чем приход на 300 позиций, потому что в первом случае кто-то добавил проверку остатков на каждую партию, а во втором логику обошли пакетно. Такие парадоксы всплывают на замерах и здорово удивляют собственников.

Отчёты: когда бизнес видит тормоза в цифрах

Отчётность — зеркало состояния базы. Пока её мало, всё летит. Потом появляются филиалы, склады, новые юрлица, а директор просит «свод по рентабельности за квартал». Запрос уходит в глубину базы на миллионы строк, поднимает временные таблицы, цепляет регистры, задевает движки аналитики. Итог — пятнадцать минут ожидания, кофе, и только потом цифры. Иногда даже без детализации.

Хуже, когда за отчётом стоит бизнес-решение. Пример: сеть розничных магазинов, ERP. Финансовый директор запрашивает отчёт по оборачиваемости, чтобы утвердить закупку на следующий месяц. Пока отчёт строится, поставщик уже ждёт подтверждения. Задержка превращается в реальный риск пустых полок. И вот тут начинаются Excel-выгрузки, ручные сводки, бесконечные «кто крайний в очереди на отчёт».

Мы однажды считали: при 80 пользователях суммарная потеря времени на формирование трёх ключевых отчётов в месяц съедала эквивалент зарплаты одного программиста. А программист как раз мог бы оптимизировать запросы. Замкнутый круг? Нет, просто бизнесу не видно, куда текут секунды.

Кстати, эта тема всплывала в нашем Telegram-канале — там обсуждали, как отдел продаж в пиковый сезон завис на формировании оборотки и чем это кончилось для премий.

Фоновые задания: скрытый пожиратель производительности

Они тихие, их не видно в интерфейсе, но именно регламентные задачи часто откусывают процессор, когда никто не ждёт. Классика: ночью стартует расчёт себестоимости, но не успевает завершиться к утру. В 09:15 бухгалтер нажимает «Расчёт РСВ», а в этот момент сервер ещё жует прошлую ночь. Блокировки, конфликты, и снова чат «Коллеги, у кого ещё не открывается?». Как-то так.

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

Доработки: полезные друзья, пока не станут врагами

1С ценят за гибкость: кнопка добавляется за день, отчёт — за вечер. Проблема в том, что каждая доработка несёт код. Код рождает запросы. Запросы живут в СУБД и требуют оптимизации. Когда бизнес растёт быстрее дисциплины разработки, в конфигурации копятся патчи, которые никто не профилировал. А там, в глубине, могут скрываться SELECT * без индексов или хитрые вычисления в цикле по тысячи раз.

Я однажды нашёл в модуле обработки успеха продажи (казалось бы, микроскопическая процедура) вызов запроса к регистру движения за три года, без ограничений по периоду. Раскрыли, оптимизировали, и документ стал проводиться в пять раз быстрее. Но таких мест десятки. И нет, «обновим конфигурацию» не панацея: чем больше кастомизации, тем дольше слияние, тем больше шанс, что оптимизация откатится.

СУБД: вечный кандидат на роль «бутылочного горлышка»

Файловый режим живёт, пока данных мало. Клиент-сервер берёт больше, но и он не всесилен. Частая ситуация: выросла база, DBA нет, статистика устарела, планы запросов неглубокие, журнал транзакций пухнет. Добавьте к этому диски на RAID 5, где I/O под нагрузкой падает в три раза. Voilà — система медленно открывает формы, пользователи жалуются, а в мониторе видно: CPU свободен, а диск стучит на 100 %.

В таких случаях первый порыв — «надо оптимизировать 1С». На деле помогает ревизия БД: актуализация статистики, перестройка индексов, перевод таблиц на SSD, разгрузка лога. Без этого даже самый чистый код упирается в физический плинтус устройства хранения.

И вот парадокс: бизнесу кажется, что «железо дорого», но год задержек в пару секунд на документ иногда дороже комплекта дисков. Просто расходы размазаны, а закупка оборудования — единоразовый платёж. Тут надо уметь посчитать TCO, но это, ох, отдельная тема…

Когда новый филиал — не только про людей, но и про лицензии, сеть и отказоустойчивость

Открылся склад в другом городе, подключили VPN, добавили терминальные сеансы. Казалось бы, подняли каналы, всё ок. Но внезапно документа «Заказ покупателя» бегут по сети туда-сюда в тонком клиенте, а регламентные обмены с головной базой висят на часовом поясе +2. В итоге пиковая нагрузка смещается и перекрывает ночные фоновые задания. Плюс забывают купить дополнительные лицензии на сервер приложений, и в 10:05 бизнес слышит: «Достигнуто предельное число подключений».

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

Как заметить проблему, пока она не стала пожаром

Самый опасный этап — когда пользователи уже жалуются, а руководители считают, что «потерпим». Деградация производительности обычно ползучая. Сегодня +1 секунда, завтра +3. Через полгода сотрудники открывают Excel, чтобы не ждать формы, и вот у вас теневая система учёта вне ERP.

Я держу простой чек-лист: среднее время открытия формы, проведения, отклика отчёта. Если показатели растут на 10-15 % месяц к месяцу — это не сезонный всплеск, это тенденция. Ставим маркер «красный». Анализируем, что расширилось: пользователи, данные, регламенты. Дальше решаем, где бить: код, БД, железо, сеть. Жаль, что многие достают чек-лист, когда отчёт уже не строится совсем. Тут важно ловить сигналы рано, иначе оптимизация 1С превращается в срочный, дорогой проект.

Я бы ещё рассказал, как один ретейлер за год утроил оборот и внезапно обнаружил, что еженедельное обновление аналитики стало занимать 14 часов вместо двух. Они подумали, что «переживём сезон», а через квартал отчёты стали строиться по ночам, потому что днём база падала. Но стоп, об этом чуть дальше…

Частые сценарии, где бизнес сам создаёт «узкое горлышко»

1. “Тестовая база летает — значит и боевая полетит”. На демо-данных всё шустро, но в проде запросы срезаются о миллионы строк. Менеджеры радуются пилоту, а в релизе слышат знакомый вздох сервера. Проверяйте производительность на копии, где объём данных близок к реальности, иначе сюрприз гарантирован.

2. “Сделайте отчёт побыстрее, а остальное потом”. Дорабатывать отдельный отчёт, не трогая регистры, — как ремонтировать одну трубу при забитом стояке. Итог: отчёт ускорили, но заблокировали движения, и сотрудники заметили другой «тормоз». Разберитесь с корнем — индексы, планы, блокировки — и только потом шлифуйте формы.

3. “У нас один DBA, он всё чинит ночью”. Ночью у DBA время, днём — у пользователей бизнес-процессы. Рано или поздно смены пересекутся: ночная перестройка индексов войдёт в рабочий пик, и 1С тормозит уже без всякой доработки. Планируйте окна обслуживания; если их нет — это уже симптом, а не обстоятельство.

4. “Интеграции же работают?” Да, пока объём обмена десятки мегабайт. Но вот подключают новый маркетплейс, пакеты растут вдвое, а маршрут идёт теми же REST-точками. База ждёт ответов, веб-службы висят, пользователи стоят в очереди на проведение. Интеграции требуют такого же мониторинга, как и сервер 1С, иначе шина сама станет шлагбаумом.

Три проверенных шага, чтобы вернуть скорость без капремонта

Шаг 1. Замеряем, а не гадаем. В платформе давно есть профилировщик — снимайте трассу: какие процедуры висят, какие запросы лезут в диски. Часто достаточно увидеть, что один SELECT отъедает 70 % времени, и вы уже знаете, куда копать. На этом этапе фраза “давайте просто купить сервер” быстро исчезает.

Шаг 2. Обновляем статистику и индексируем выборочно. Классика: база 400 ГБ, статистике полгода, планы запросов устарели. Тридцать минут на UPDATE STATISTICS сокращают время тяжёлых отчётов втрое. Оптимизация 1С начинается с оптимизации СУБД — дёшево, быстро, безопасно.

Шаг 3. Разводим фон и операционку. Выделите отдельный сервер приложений под регламентные задания или хотя бы перенесите их на дневные «ямы» нагрузки. Звучит банально, но перенос расчёта себестоимости на воскресенье вечера спасал нам не одну закрывашку месяца. Итог — сотрудники не ждут, база не рушится, а вы не сидите в режиме “fire-fight”.

Когда без архитектурного пересмотра не обойтись

Сигнал 1. Рост пользователей > 30 % в год. Прибыл филиал — считайте лицензию, ширину канала, возможность поставить реплику. Если инфрастуктура трещит, пора думать о кластере или сегментации данных. Иначе любой патч — пластырь на надвигающийся разлом.

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

Сигнал 3. Доработки > 40 % кода от типовой. Значит, каждое обновление — долгий merge, тесты, откаты. Чем дальше, тем больнее. Возможно, пора перейти на микросервисы или хотя бы вынести периферию (интеграции, печатные формы) наружу. Когда ядро останется чистым, и обновления, и производительность станут предсказуемыми.

Как говорить о производительности с руководством — язык денег

ИТ говорит «секунды», директор слышит «рубли». Берём число операций × задержку × среднюю ставку × рабочие дни. Простой пример: 500 документов продажи, по 8 сек ожидания, 22 дня в месяце. Получаем 14 666 человеко-минут, то есть ~2,5 человека ставки. Вот вам обоснование бюджета, а не «нам нужен новый сервер, потому что хочется».

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

Реальные приёмы из практики

Проверка “две кнопки”. Ставим таймер на «Открыть документ» и «Провести». Всё, что выше 5 сек на стандартной форме, — повод для расследования. Рекорд, который видел: приход из пяти строк открывался 38 сек. Нашли: в модуле события — три вызова запроса остатков за весь период, без фильтра склада. Один индекс — и стало 3 сек.

Дробление регламентных заданий. Расчёт себестоимости за месяц режем на неделю, каждую неделю — на день. Такая инженерия дала выигрыш в четыре раза по CPU-time, и база провалилась в спокойные 20 % загрузки. Неделя работы — минус тридцать минут ожиданий на каждого бухгалтера.

Смена RAID 5 → RAID 10. Тот случай, когда «железо» действительно решает. I/O вырос вдвое, отчёт по рентабельности с миллиона строк рисовался не 18, а 7 минут. Ытого: окупилось за сезон, потому что скоростной отчёт дал возможность закупать точнее.

Что делать завтра утром

1. Соберите метрики: время открытия, проведения, отчётов.
2. Снимите профилировщик, выведите топ-10 медленных запросов.
3. Проверьте, когда последний раз обновляли статистику и индексы.
4. Найдите фоновое задание с самым длинным окном — перенесите.
5. Сядьте с финансистом и посчитайте деньги, которые утекают в «крутится».

Пять пунктов занимают день-два, а понимание, где именно 1С тормозит, экономит недели паники в горячий сезон.

Итого

Скорость 1С — это не магия и не каприз сервера. Это зеркало того, как быстро растёт бизнес и насколько вовремя вы пересматриваете архитектуру. Секунда здесь, секунда там — и вот уже месяц человеческой работы испаряется в ожидании. Так что вопрос открытый: где лично у вас сегодня прячется та самая лишняя секунда?