Нагрузочное тестирование корпоративных систем

Как проверить готовность бизнеса к росту и изменениям

Почему успешный функциональный тест еще не гарантирует стабильную работу в день запуска – и как превратить производительность из предмета споров в измеримый критерий готовности.

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

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

КЛЮЧЕВАЯ МЫСЛЬ

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

Шесть бизнес-сценариев, в которых НТ меняет качество решения

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

1. Внедрение корпоративной системы с нуля

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

2. Быстрый рост бизнеса или сезонный пик

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

3. Импортозамещение и миграция Windows/MS SQL Server → Linux/PostgreSQL

Формальная совместимость компонентов не гарантирует равной производительности конкретной доработанной системы. Методически корректный подход – зафиксировать базовую линию на исходном контуре, затем повторить тот же профиль и те же операции на целевом. Сравниваются времена, пропускная способность, ошибки, блокировки и потребление ресурсов. Именно сравнительный тест фирма «1С» включает в официальную дорожную карту перевода информационных систем на Linux и PostgreSQL.

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

4. Крупное обновление, доработка или смена архитектуры

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

5. Массовые расчеты и регламентные операции

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

6. Непрерывность бизнеса

Для 24х7-систем в НТ добавляются сценарии отключения узла, площадки или информационной системы.

Нагрузочное тестирование – не экзамен на количество виртуальных пользователей

В корпоративной практике термином «нагрузочное тестирование» часто называют весь комплекс испытаний производительности. Внутри него могут быть разные режимы:

• нагрузочный тест – работа при плановой и пиковой, но штатной нагрузке

• стресс-тест – поиск предела системы и оценка поведения за границей расчетной нагрузки

• тест нестабильности – многочасовой или многосуточный прогон для выявления накопительной деградации, утечек памяти и роста очередей

• тест резкого всплеска – реакция на быстрое увеличение числа запросов или пользователей

• объемный тест – влияние размера базы, истории операций и крупных наборов данных

• тест масштабируемости – проверка эффекта от добавления процессоров, памяти, серверов приложений или узлов СУБД

• испытание отказоустойчивости – сохранение сервиса при отключении компонента, узла или площадки и восстановление после отказа

Комбинация режимов зависит от бизнес-задачи. К примеру – для системы кадрового учета важны массовые перерасчеты и жесткое окно расчета зарплаты. Для ERP – параллельная работа ролей, проведение документов, закрытие месяца и обмены. Для клиентского сервиса – пропускная способность API. Для системы информационной безопасности – одновременное подключение большого количества рабочих мест, корректность проверок и поведение при отказе узлов.

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

Где НТ необходимо, а где достаточно облегченной проверки

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

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

Полномасштабное испытание преждевременно, если ключевые функции нестабильны, сценарии бизнеса еще не определены, интеграции отсутствуют, а данные не репрезентативны. В таком случае разумнее начать с аудита архитектуры и кода, компонентных замеров или небольшого proof of concept. НТ не заменяет функциональное тестирование, анализ кода, мониторинг и проектирование отказоустойчивости.

Какие вопросы НТ должно закрыть

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

• укладываются ли ключевые операции в согласованные целевые времена

• сохраняется ли качество работы в обычный день, в пик и при прогнозируемом росте

• какова фактическая пропускная способность и где находится безопасный запас

• какой компонент ограничивает производительность: код, блокировки, СУБД, сервер приложений, диски, сеть, виртуализация или внешняя система

• дает ли масштабирование ожидаемый эффект и какое оборудование действительно нужно

• не ухудшил ли новый релиз, доработка или изменение настроек ранее достигнутые показатели

• работает ли переключение на резервный узел и возвращается ли система к нормальному режиму после отказа

• можно ли выполнить запуск или миграцию с понятным остаточным риском

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

В проектах «1С» применяется APDEX: интегральная оценка относительно заданного целевого времени. Она удобна для общего контроля, но не заменяет анализ конкретных медленных операций, блокировок и ресурсов. В описании стандартного нагрузочного теста «1С» порог APDEX не ниже 0,85 относится именно к стандартному сценарию и не должен механически заменять проектные требования бизнеса.

Когда проводить НТ в жизненном цикле системы

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

• До запуска системы проще менять архитектуру и код

• В опытно-промышленной эксплуатации (ОПЭ) выше реализм, но меньше времени на исправления

• После запуска – НТ помогает проверить требуемые показатели быстродействия и отказоустойчивости на новом оборудовании, либо новых релизах используемого ПО

Особенности нагрузочного тестирования «1С»

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

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

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

Как организовать НТ, которому можно доверять

1. Перевести ожидания бизнеса в измеримые требования

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

2. Построить профиль нагрузки

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

3. Подготовить репрезентативные данные и стенд

Для многопользовательской системы распределение данных и их история влияют на планы запросов, блокировки, объем чтения и время выполнения отчетов. Синтетика допустима, если она воспроизводит эти свойства и ограничения проекта не позволяют использовать копию продуктивной базы. Данные должны быть обезличены, доступы – согласованы, а стенд – описан и стабилен. Если его мощность отличается от продуктивной, методика обязана объяснять, как интерпретировать результат.

4. Разработать и проверить тестовую оснастку

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

5. Синхронно собирать метрики всего стека

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

6. Выполнить серию, а не один эффектный прогон

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

7. Оптимизировать по приоритету бизнес-влияния

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

8. Завершить проект повторным доказательством

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

Типовые ошибки, которые обесценивают НТ

• сценарии составлены без владельцев бизнес-процессов и не отражают реальное сочетание операций и их интенсивность

• функционально нестабильное решение пытаются «принять нагрузкой»

• тестируется коробочная конфигурация вместо доработанного целевого решения

• синтетические данные слишком просты и не воспроизводят распределение продуктивной базы

• стенд существенно слабее, мощнее или занят другими командами, а различия не учтены

• критерии тестовой оснастки, приложения и инфраструктуры смешаны в один общий вердикт

• метрики разных уровней собираются несинхронно

• после оптимизации нет нагрузочной регрессии

• результат сводится к большому отчету без владельцев, сроков и приоритета рекомендаций

Как «ИТ-Экспертиза» может помочь

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

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

В лидерах нашей практики представлены 1С:ERP, 1С:Управление холдингом, 1С:Документооборот, 1С:УПП, 1С:ЗУП и другие корпоративные информационные системы на платформе «1С:Предприятие 8».

Практический формат взаимодействия может включать:

1. аудит текущей или проектируемой архитектуры, настроек и проблемных операций

2. сбор требований, разработку профиля нагрузки и программы испытаний

3. подготовку стенда, данных, скриптов и средств наблюдаемости

4. проведение нагрузочных, стрессовых, длительных и отказовых сценариев

5. сквозной анализ от пользовательской операции до кода, СУБД и инфраструктуры

6. разработку и внедрение рекомендаций по оптимизации и отказоустойчивости

7. повторное тестирование, прогноз емкости и итоговое заключение для решения о запуске или миграции

8. передачу сценариев в регулярную эксплуатацию и нагрузочную регрессию

У нас более 19 лет опыта команды в оптимизации систем «1С». На момент написания статьи в  портфеле команды статус партнера Центра корпоративной технологической поддержки и 11 сертификатов «1С:Эксперт по технологическим вопросам» у наших специалистов, есть проекты ЦКТП. Эти сведения важны не как перечень регалий, а как подтверждение способности работать по методикам вендора и вести диагностику на самых высоких корпоративных уровнях.

Опубликованные проекты компании «ИТ-Экспертиза»

Миграция на Linux/PostgreSQL: сравнение вместо предположений

Мы регулярно делимся с сообществом экспертов своим опытом о миграции высоконагруженных систем «1С». Пример – запрос крупного холдинга: в исходной среде он выполнялся около трех минут, а в целевой – около 17 часов. После обнаружения отсутствующего индекса время сократилось до одной минуты. В другом примере для «1С:Розницы» с более чем 2000 пользователей проблема проявлялась в механизме СУБД при высокой параллельности; после анализа совместно с вендором и установки исправленной версии APDEX вырос до 0,979. Оба случая показывают, почему сравнительное НТ нужно проводить до переключения пользователей.

Проверка отечественного стека на крупном масштабе

В 2025 году «ИТ-Экспертиза» совместно с отраслевыми и технологическими партнерами участвовала в испытаниях «1С:ERP» на 30 000 одновременно работающих пользователей на отечественном программно-аппаратном контуре. В повторном тесте APDEX составил 0,859; отдельный 11-часовой сценарий рабочего дня на 15 000 пользователей получил APDEX 0,950 без падений процессов, критических ошибок и блокировок. Ранее фирма «1С» опубликовала исходное испытание 30 000 пользователей на Linux/PostgreSQL с APDEX 0,858.

Другой публичный эксперимент моделировал 20 000 пользователей «1С:ERP» на машине баз данных с процессорами Baikal-S, СУБД Tantor Postgres и Astra Linux; зафиксированный APDEX составил 0,846. Этот тест демонстрирует характер задачи импортозамещения: проверяется не отдельный компонент, а совместная работа приложения, СУБД, ОС, оборудования и средств генерации нагрузки.

Массовый расчет в 1С:ЗУП КОРП

В кейсе 2026 года по 1С:ЗУП КОРП проверялись 40 000 перерасчетов на 30 000 табельных номеров. На первом стенде операция завершилась за 5122 секунды при целевом ограничении 7200 секунд; на более мощном оборудовании – за 2626 секунд. Здесь НТ отвечает сразу на два бизнес-вопроса: укладывается ли расчет в допустимое окно и насколько эффективно решение масштабируется при изменении инфраструктуры.

НТ за пределами «1С»: нагрузка и отказоустойчивость

Для собственного комплекса информационной безопасности САКУРА компания опубликовала результаты нагрузочного и стресс-тестирования с эмуляцией примерно 105 000 удаленных рабочих мест. При отключении одного ЦОД или трех из четырех серверов система сохраняла контроль и приемлемое время отклика. Этот пример показывает, что методика НТ применима к любым корпоративным системам, где необходимо одновременно проверить пропускную способность, корректность бизнес-решений и сохранение сервиса при отказах.

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

Что подготовить заказчику до старта

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

• перечень критичных бизнес-процессов, ролей и владельцев

• статистику количества операций и одновременной активности по времени суток

• описание пиков, сезонности и прогноза роста

• целевые времена, SLA, пакетные окна и допустимую долю ошибок

• размеры баз, темпы прироста и особенности распределения данных

• схему интеграций и фоновых заданий

• состав исходного и целевого технологического стека, версии и настройки

• перечень доработок и недавних изменений

• доступные стенды, ограничения по данным и требования информационной безопасности

• ответственных за бизнес, приложение, инфраструктуру, СУБД и приемку результатов

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

Вместо вывода: НТ – это управляемый эксперимент перед запуском дорогого решения

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

Практическая ценность зависит от исходного события. При внедрении НТ обосновывает решение о запуске; при росте – показывает запас емкости; при миграции – сравнивает исходный и целевой стеки на одинаковой задаче; при массовом расчете – проверяет технологическое окно; в 24х7-контуре – подтверждает переключение и восстановление не только на архитектурной схеме, но и в эксперименте.

Для «ИТ-Экспертизы» логичная точка входа – технологический аудит и постановка измеримых целей. Дальше масштаб работ определяется риском: от локального теста критичной операции до полной модели предприятия с оптимизацией, повторными прогонами и проверкой отказов. Такой подход оставляет бизнесу не рекламное обещание, а основание для решения – запускать, дорабатывать или масштабировать.

Напишите нам, если описанные в статье вопросы назревают или уже назрели в вашем бизнесе. Мы проведем необходимые работы и поможем разобраться в ситуации!