Перед распродажей компания увеличивает рекламный бюджет, закупает товар и усиливает склад. В обычный день через 1С проходит, скажем, 80 заказов в час, в Чёрную пятницу — 500, и каждый нужно принять из интернет-магазина, зарезервировать, провести и отгрузить. Если 1С тормозит и не успевает проводить документы и передавать остатки, рост продаж превращается в очередь: сотрудники ждут систему, покупатели — подтверждение и доставку. Сколько стоит такой простой в пиковый день, мы разбирали отдельно.

Готовность к сезону подтверждают на рабочих сценариях: сколько операций система выполняет одновременно, за какое время и без каких ошибок. Этот чек-лист поможет руководителю и IT-команде увидеть, что уже проверено, а где до начала сезона остаётся риск.

Речь о клиент-серверной «1С:Предприятии»: кластере серверов 1С, СУБД и связанных сервисах. Сайт — отдельная история: что происходит с магазином на 1С-Битрикс в пик, разобрано в статье почему Битрикс падает под нагрузкой. Если база работает в файловом режиме, пункты о кластере и СУБД к ней не относятся.

Как пользоваться чек-листом

Для каждого пункта фиксируйте статус («подтверждено», «не подтверждено», «не применимо»), ответственного, дату проверки и ссылку на результат. «Настроено» и «в прошлом году справились» — это ещё не подтверждение: нужен замер или протокол.

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

Когда начинать подготовку

Исправления после замеров требуют времени — на доработку кода, повторный тест, иногда на закупку оборудования. Ориентир по срокам:

• За 6–8 недель: описать пик, снять замеры, проверить ресурсы, найти медленные запросы и блокировки (пункты 1–4).
• За 3–4 недели: развести фоновые задания, проверить обмены, мониторинг и восстановление из копии (пункты 5–8).
• За 1–2 недели: итоговый нагрузочный тест, проверка доступов и лицензий, заморозка изменений в конфигурации и инфраструктуре (пункты 9–10).
• В дни пика: дежурство, контроль ключевых операций и обменов, готовый план действий при сбое.

1. Ожидаемый пик описан в операциях

Начните с нагрузки, которую создаёт бизнес. Число пользователей в базе ничего не говорит о том, сколько документов одновременно будут проводить менеджеры и склад.

• Определены часы пика, число одновременно работающих сотрудников и поток документов.
• Учтены обмен с интернет-магазином, массовые загрузки, отчёты и фоновые задания. В декабре отдельно учтено закрытие месяца и года: тяжёлые регламентные операции бухгалтерии совпадают с пиком отгрузок.
• Для ключевых операций согласованы целевое время и допустимая доля ошибок. Удобный способ задать их одной шкалой — APDEX: для каждой операции выбирают целевое время, а итоговый индекс показывает, какая доля выполнений в него укладывается.
• Для критических операций записи отдельно оговорено: никаких потерь и дублей данных.

Подтверждение: сценарий сезонной работы с объёмами и критериями приёмки. Если прогноз неточен, опишите два-три варианта нагрузки — например, «как в прошлом году», «+50%» и «вдвое больше».

2. Измерена скорость ключевых операций

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

• Есть замеры обычного рабочего дня — с ними потом сравнивают пик.
• Для каждой операции сохранены время выполнения, ошибки и условия замера.
• Замеры сделаны с правами обычных пользователей и на данных, сопоставимых с рабочими.

Собирать такие замеры постоянно, а не разово, помогает Центр управления производительностью (ЦУП) из Корпоративного инструментального пакета 1С: он считает APDEX по ключевым операциям и показывает, когда и где показатель проседает.

Подтверждение: протокол замеров по операциям. Синтетический тест сервера удобен для сравнения окружений, но о скорости ваших документов он ничего не скажет.

3. Под нагрузкой проверены процессор, память и хранилище

Низкая загрузка сервера в спокойное утро не означает запаса на распродажу. Метрики снимают во время сезонного сценария, отдельно для кластера 1С и для СУБД.

• Проверены загрузка отдельных ядер, память рабочих процессов 1С (rphost) и СУБД, использование подкачки. В консоли кластера видно, сколько рабочих процессов запущено, сколько памяти они занимают и как часто перезапускаются.
• Измерены задержки дисковых операций; рассчитано место под рост базы, журналов, временных файлов и копий.
• Для виртуальных машин проверены лимиты и конкуренция за ресурсы хоста.

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

4. Разобраны медленные запросы, блокировки и обслуживание СУБД

Если проведение документа ждёт другую транзакцию, новые ядра задержку не уберут. Нужно найти, где возникает ожидание и какая операция держит ресурс.

• Найдены запросы, которые дают основную нагрузку в проверяемых сценариях.
• Изучены длительные транзакции, ожидания блокировок и взаимоблокировки. Проверено, в каком режиме управления блокировками работает конфигурация: в автоматическом режиме конфликтов обычно больше, чем в управляемом.
• Выполнено регламентное обслуживание СУБД: обновлена статистика, обслужены индексы, проверен рост журнала транзакций и временной базы (для PostgreSQL — работа VACUUM и ANALYZE). Устаревшая статистика — одна из самых частых причин, по которой вчера быстрый запрос сегодня выполняется минутами.
• Каждое изменение запросов и настроек СУБД повторно проверено на том же сценарии.

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

5. Фоновые задания не мешают рабочему пику

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

• Составлен перечень регламентных и фоновых заданий с длительностью и расписанием.
• Проверены параллельные запуски, повторные попытки и накопление незавершённых задач.
• Переносимые задачи сдвинуты на спокойные часы; обязательные обмены протестированы вместе с пользовательской нагрузкой.

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

6. Обмены выдерживают поток и восстанавливаются после сбоя

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

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

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

7. Мониторинг показывает проблемы до массовых жалоб

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

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

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

Как связать метрики, уведомления и действия инженеров, разобрано в статье про проактивный мониторинг 24/7.

8. Резервная копия действительно восстанавливается

Зелёная галочка у задания резервного копирования не говорит, сколько времени займёт возврат системы в работу. Проверять нужно само восстановление и запуск приложения.

• Согласованы RPO — сколько данных по времени можно потерять — и RTO, за сколько систему нужно вернуть.
• Копия восстановлена в изолированной среде; база запускается, ключевые данные и операции проверены.
• Под рукой настройки, расширения, учётные данные и лицензии, нужные для восстановления.

Подтверждение: протокол восстановления с фактическим временем и моментом последней восстановленной транзакции. Копии и доступ к ним хранятся отдельно от сервера, который может отказать. Сценарии восстановления подробно описаны в материале о Disaster Recovery Plan, а если плана ещё нет, его можно разработать вместе с нами.

9. Доступы, лицензии и команда готовы к пику

Временные сотрудники, дополнительные рабочие места или перенос системы на новый сервер часто упираются в доступы и лицензии. Эти вопросы закрывают до первого пикового дня.

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

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

10. Сезонный сценарий выполнен целиком

Отдельные успешные проверки ещё не доказывают, что система выдержит всё сразу. Финальный шаг — нагрузочное тестирование 1С с одновременной работой пользователей, обменов и обязательных фоновых заданий.

• Нагрузка растёт до согласованного пика и выше — на случай, если прогноз окажется скромным.
• Тест идёт достаточно долго, чтобы проявились накопление очередей и пересечения с расписанием заданий.
• Проверены время операций, ошибки, целостность данных и возврат к нормальной работе после снижения нагрузки.

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

Как принять решение о готовности

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

• Готовность подтверждена: согласованный пик пройден, критерии по ключевым операциям выполнены, восстановление и реакция команды проверены.
• Нужны доработки: есть отклонения, у каждого — ответственный, срок и повторная проверка. Оставшиеся риски согласованы с бизнесом.
• Готовность не подтверждена: итогового теста нет или критические требования ничем не подтверждены. Это не обязательно значит, что система не справится, — просто пока нет оснований это утверждать.

Если у вас получился третий вариант, а до сезона несколько недель, проверку можно провести вместе с нами: в рамках аудита инфраструктуры пройдём этот чек-лист на вашей системе и покажем, что исправить в первую очередь.

Зафиксируйте, для каких условий получен результат. Рост базы, новый обмен, изменения конфигурации или инфраструктуры — повод повторить проверку.

FAQ

Почему 1С тормозит при большом количестве пользователей?

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

Как подготовить 1С к Чёрной пятнице и концу года?

Начните за 6–8 недель: опишите пик в операциях, снимите замеры, найдите медленные запросы и блокировки, обслужите СУБД. Затем разведите фоновые задания и закрытие периода с часами пика, проверьте обмены и восстановление из копии, а за одну-две недели проведите итоговый нагрузочный тест.

Сколько пользователей выдержит сервер 1С?

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

Как проверить, что резервная копия 1С восстанавливается?

Восстановить её в изолированной среде, запустить базу и проверить ключевые данные и операции. Результат фиксируют в протоколе с фактическим временем восстановления и моментом последней восстановленной транзакции.

Что такое APDEX в 1С?

Это индекс от 0 до 1, который показывает, насколько время выполнения ключевых операций укладывается в целевое. Для каждой операции задают целевое время, а затем по замерам считают, какая доля выполнений была быстрой, допустимой или слишком медленной.

Если нужна помощь

Если команде не хватает времени или опыта, чтобы проверить сервер, СУБД и восстановление до сезона, U-Team предоставляет поддержку и администрирование проектов на 1С: диагностику, оптимизацию серверного окружения, мониторинг и настройку резервного копирования. Объём работ определяем по архитектуре системы и требованиям бизнеса.