При администрировании и разработке в среде «1С:Предприятие» перед многими специалистами рано или поздно встает вопрос: можно ли оставить включенным режим отладки на рабочем (production) сервере? Кажется удобным иметь возможность в любой момент подключиться к процессу и посмотреть, что происходит «под капотом» системы непосредственно на «живых» данных. Однако официальная документация фирмы «1С» и опытные администраторы настоятельно рекомендуют избегать использования ключа -debug в продуктивной среде. В этой статье мы подробно разберем, к каким критическим последствиям это может привести, проанализируем внутреннюю архитектуру платформы, рассмотрим вопросы информационной безопасности и найдем безопасные альтернативные варианты организации процесса разработки.
Рассмотрим подробнее, как работает сервер приложений 1С на системном уровне. Это один из главных технических аргументов, который часто упускается из виду администраторами:
rphost конфигурация базы данных компилируется и загружается в оперативную память практически в полном объеме. Да, это увеличивает время первоначального старта процесса, но зато гарантирует, что при обращении пользователей к любым объектам метаданных доступ к ним будет осуществляться мгновенно.Выясним причину, почему это плохо для пользователей. При обращении к новым объектам платформа вынуждена «на лету» подгружать конфигурацию, используя внутренние блокировки внутри самого сервера приложений. На высоконагруженном сервере возникает постоянная конкуренция за эти внутренние блокировки. В результате пользователи сталкиваются со случайными задержками, микрофризами интерфейса и общей нестабильностью работы системы.
Кроме того, если в кластере запущено несколько рабочих процессов rphost, каждый из них выполняет кэширование независимо. Возникает эффект «плавающей производительности»: один пользователь проводит документ мгновенно, а другой (попавший на процесс, где метаданные еще не кэшировались) сталкивается со значительным ожиданием.
Проанализируем ситуацию с точки зрения выполнения программного кода. При включенном ключе -debug платформа отключает целый ряд внутренних оптимизаций компиляции встроенного языка 1С. В исполняемый байт-код внедряется избыточная служебная информация: отладочные символы и подробная карта соответствия строк исходного кода.
В этом режиме сервер приложений 1С вынужден непрерывно выполнять дополнительные операции:
Даже если в данный момент никто из разработчиков активно не пользуется отладчиком, накладные расходы на работу этого механизма сохраняются. Это создает постоянную паразитную нагрузку на процессоры (CPU) сервера приложений, снижая общую пропускную способность системы.
Разберем по шагам классический сценарий, с которым сталкиваются компании, пренебрегающие правилами изоляции сред разработки от продуктивных систем. Представим следующую ситуацию:
// Пример транзакционной операции проведения документа
НачатьТранзакцию();
Попытка
// Блокировка таблиц для записи движений
Блокировка = Новый БлокировкаДанных;
ЭлементБлокировки = Блокировка.Добавить("РегистрНакопления.Продажи");
ЭлементБлокировки.УстановитьЗначение("Организация", Ссылка.Организация);
Блокировка.Заблокировать();
// В этот момент разработчик останавливается на точке останова!
ЗаписатьДвиженияДокумента();
ЗафиксироватьТранзакцию();
Исключение
ОтменитьТранзакцию();
ВызватьИсключение;
КонецПопытки;
Если программист устанавливает точку останова внутри транзакции (например, при проведении важного документа), выполнение кода на сервере замораживается. Однако на уровне СУБД (MS SQL Server, PostgreSQL) транзакция остается открытой, удерживая наложенные блокировки таблиц. Пока разработчик анализирует значения переменных, все остальные пользователи, пытающиеся провести аналогичные документы или даже просто записать данные, будут ожидать снятия блокировки. По истечении времени ожидания они начнут получать критические ошибки блокировок СУБД, а работа всей компании будет полностью парализована.
Включение отладки на рабочем сервере открывает серьезные уязвимости, которые ставят под угрозу конфиденциальность корпоративных данных:
Начиная с версии платформы 8.3.7, разработчикам доступен выбор протокола отладки. Посмотрим, как каждый из них влияет на продуктивную систему:
rphost могут временно подвисать, безуспешно ожидая ответа от удаленного отладчика.dbgs). Если включить отладку по HTTP для опубликованных веб- или HTTP-сервисов (через параметр debug="true" в файле default.vrd), то остановка на любой точке в коде сервиса приведет к моментальному исчерпанию пула соединений веб-сервера. Все внешние интеграции (с сайтами, CRM, государственными системами маркировки) мгновенно перестанут работать.Что же делать организации, если сервер приложений всего один, а необходимость в доработке и отладке конфигураций программистами существует постоянно? Покупать вторую дорогую серверную лицензию вовсе не обязательно. Разберем по шагам оптимальное и безопасное техническое решение.
Платформа 1С позволяет запускать несколько независимых служб (кластеров) сервера приложений на одном физическом компьютере, используя одну и ту же лицензию на сервер. Мы можем развернуть два кластера:
-debug на стандартных портах (1540, 1541, 1560-1591). Здесь работают обычные пользователи в рабочих базах с максимальной производительностью и безопасностью.-debug. В этом кластере регистрируются только тестовые базы и копии для разработчиков.Для создания второй службы на операционной системе Windows можно воспользоваться клонированием ветки реестра или утилитой sc.exe. Проанализируем пример команды для создания альтернативной службы:
sc create "1C:Enterprise 8.3 Server (Debug)" binPath= "\"C:\Program Files\1cv8\8.3.22.1709\bin\ragent.exe\" -srvc -agent -regport 2541 -port 2540 -range 2560:2591 -d \"C:\srvinfo_debug\" -debug" start= auto
Важное предупреждение: Несмотря на то что службы будут логически разделены, они все равно делят общие физические ресурсы сервера (процессорное время, оперативную память и дисковую подсистему). Тяжелые запросы или утечки памяти при отладке в тестовом кластере могут косвенно снижать производительность продуктивной базы. Полноценная изоляция достигается только выносом среды разработки на отдельный физический или виртуальный сервер.