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

Суть понятия

Параллельный бег, это режим одновременной работы двух информационных баз (или двух конфигураций на одной базе):

• Текущая («боевая») система — продолжает обслуживать реальные бизнес-процессы, пользователи работают в привычной среде.
• Новая (тестовая/переходная) система — развернута на отдельном сервере (или отдельном кластере/контейнере) «на своих» мощностях заказчика. В неё загружаются актуальные данные (копия базы), применяются обновления конфигурации, настраиваются интеграции.

Ключевая фраза «на своих» подчеркивает, что тестирование и прогоняются сценарии не в облаке вендора (не на демо-стенде 1С, не в 1С Fresh), а именно на железе заказчика — тех серверах, где будет работать итоговая система. Это учитывает специфику «железа», настройки ОС, СУБД (MS SQL / PostgreSQL), сетевую топологию, антивирусы, бэкапы и права доступа.

Зачем нужен ПБ на своих? (Цели и задачи)

Многие заказчики пытаются сэкономить, пропуская этот этап, полагаясь на тесты разработчика или работу в «облаке». Это грубая ошибка. Основные цели ПБ на своих:

1. Проверка производительности на реальном железе. Конфигурация может летать на мощном сервере разработчика или в облаке, но «захлебнуться» на старом сервере заказчика с медленными дисками (HDD vs NVMe), нехваткой RAM или специфическими настройками MS SQL (MAXDOP, параметры параллелизма).
2. Валидация миграции данных. При переходе на новые релизы (например, ERP 2.5 -> 3.0, ЗУП 3.1 -> 3.2) запускаются процедуры перестройки данных. На своих данных (с их «историей», ошибками ввода, нестандартными настройками) эти процедуры могут отрабатывать часами, выдавать ошибки или зацикливаться. ПБ позволяет замерить время миграции и отладить скрипты исправления до остановки производства.
3. Тестирование интеграций «в бою». Обмены с сайтами, банками (Клиент-банк), ККМ (ФФД 1.2), ЭДО, CRM, WMS, внешними API. В облаке часто закрыты порты, нет доступа к локальным ключевым носителям (Рутокен, eToken), нет доступа к файловым шарам обмена. На своих, всё это работает (или не работает) реально.
4. Проверка лицензирования и защиты. Работа лицензий 1С (HASP/SoftNet), привязка к железу, работа через веб-сервер (IIS/Apache), настройка HTTPS, CORS, CSP — всё это специфично для инфраструктуры заказчика.
5. Адаптация пользователей и обучение. Ключевые пользователи (бухгалтеры, кладовщики, менеджеры) могут поработать в новой конфигурации с реальными данными, не боясь «сломать» основную базу. Это снимает стресс при реальном переходе.
6. Отработка процедуры переключения (Cutover). Репетиция остановки старой базы, финального обмена/бэкапа, развертывания новой базы в боевом режиме, переключения пользователей, запуска регламентных заданий. ПБ позволяет составить чек-лист переключения на каждую минуту.

Архитектура и инфраструктура для ПБ на своих

Для качественного проведения параллельного бега требуется изолированная среда. Идеальный вариант — полная копия боевой инфраструктуры:

Вариант А: Полная изоляция (Рекомендуемый)

• Сервер приложений 1С: Отдельный сервер (физический или VM) с той же ОС и версией платформы 1С.
• Сервер СУБД: Отдельный экземпляр MS SQL Server / PostgreSQL (желательно на отдельном сервере, как в бою).
• Веб-сервер: Отдельный IIS/Apache для публикации веб-клиента/REST/OData.
• Лицензирование: Отдельный ключ (или временный тестовый ключ от 1С/франчайзи) для кластера ПБ.

Вариант Б: Изоляция на уровне экземпляров (Экономия ресурсов)

Если железа мало, допустимо использовать те же физические серверы, но с разделением:

• Отдельный кластер 1С (отдельный порт агента, отдельный реестр/служба).
• Отдельный экземпляр СУБД (Named Instance в MS SQL) или отдельная база данных в том же экземпляре (менее предпочтительно из-за ресурсов).
• Отдельный пул приложений (AppPool) в IIS и отдельный сайт/виртуальный каталог.

Этапы проведения ПБ на своих

Подготовительный этап

• Согласование плана и сроков с бизнесом (обычно 1-4 недели).
• Подготовка железа / выделение VM.
• Установка платформы 1С (та же сборка, что планируется в бою).
• Настройка СУБД (модель восстановления Simple для теста? Нет, лучше Full для реализма бэкапов, но с отключением бэкапов логов чтобы не забить диск).

Развертывание базы-донора

• Создание бэкапа боевой базы (Full backup).
• Восстановление (Restore) на тестовый SQL-экземпляр с OTHER NAME (например, MyBase_PB).
• Очистка служебных таблиц логов, сеансов, фоновых заданий (чтобы не слали письма/СМС клиентам из теста).
• Анонимизация/маскировка ПДн (персональных данных) — если требуется законом/политикой безопасности (ФИО сотрудников, контрагентов, зарплаты).

Применение обновлений (Миграция)

• Загрузка новой конфигурации (CF/CFU) в базу ПБ.
• Запуск процедур обновления ИБ (перестройка данных). Здесь замеряем время!
• Исправление ошибок миграции (скрипты исправления данных, доработки конфигурации).

Настройка периферии и интеграций

• Публикация на веб-сервере (отдельный URL: pb.Company.ru).
• Настройка обменов: отключение отправки реальных документов во внешние системы (банк, налоговая, сайт) или перенаправление в тестовые контуры контрагентов.
• Подключение оборудования (ККМ, сканеры, весы) — если возможно, к тестовым драйверам/эмуляторам.

Функциональное и нагрузочное тестирование

• Сценарийное тестирование: Ключевые пользователи отрабатывают типовые бизнес-процессы (продажа, закупка, зарплата, закрытие месяца, НДС, УСН).
• Нагрузочное тестирование (опционально, но желательно): Имитация работы N пользователей (через инструменты вроде 1C:LoadTest, JMeter, Gatling или самописных скриптов) для выявления узких мест (блокировки, медленные запросы, нехватка памяти).

Репетиция переключения (General Rehearsal)

За 1-3 дня до планируемого перехода проводится «генеральная»:

1. Остановка пользователей на боевой базе (в нерабочее время).
2. Финальный бэкап боевой базы.
3. Восстановление на стенд ПБ (или применение дифференциального бэкапа/логов).
4. Запуск миграции данных (инкремента).
5. Проверка контрольных сумм/отчетов.
6. Запуск регламентных заданий.
7. Оценка суммарного времени простоя (Downtime).

Типичные ошибки и риски

Чек-лист готовности к выходу в бой (после успешного ПБ)

Если ПБ на своих прошел успешно, перед финальным переключением должны быть закрыты пункты:

• [ ] Время миграции данных (инкремента) укладывается в окно обслуживания (ночь/выходные).
• [ ] Все критичные бизнес-сценарии отработаны ключевыми пользователями без блокеров.
• [ ] Интеграции работают в тестовых контурах контрагентов (банк, ЭДО, сайт, ККМ).
• [ ] Производительность на своих серверах соответствует SLA (отчеты формируются за норм. время, интерфейс не лагает).
• [ ] Составлен и согласован План переключения (Cutover Plan) по минутам с ответственными.
• [ ] Подготовлены скрипты отката (Rollback) на случай критического сбоя при выходе в бой;
• [ ] Обучены все пользователи (инструкции, вебинары, раздаточный материал).
• [ ] Готовы лицензии 1С для новой конфигурации/платформы на боевом сервере.

ПБ на своих (Параллельный бег на собственной инфраструктуре) — это не формальность и не каприз ИТ-отдела. Это единственный способ гарантировать, что переход на новую версию 1С (ERP, ЗУП, КА, УТ, БП и др.) пройдет без остановки бизнеса на неопределенное время, потери данных и нервного срыва у бухгалтерии.

Экономия на этом этапе (проведение ПБ в облаке, на урезанных данных, без пользователей) почти всегда приводит к затратам в 5-10 раз большим во время аварийного восстановления после неудачного перехода. Планируйте ресурсы, выделяйте время, включайте бизнес — и ваш переход будет бесшовным.

Статья подготовлена на основе лучших практик администрирования и внедрения систем на платформе 1С:Предприятие 8; Актуально на 2026 год.