Централизация ИТ в холдинге: опыт и решения на 1С

24 сентября 2026 · infolimp.ru

Контекст и вызовы централизации

Типичный сценарий: холдинг с 5–15 юридическими лицами решает «объединить всё в одну базу» под предлогом единой отчётности и прозрачности. Архитектура выбирается интуитивно — единая конфигурация с общими справочниками (Номенклатура, Контрагенты) и разделением через реквизит «Организация». Уже на этапе пилота, когда количество пользователей превышает 200, а ежедневный документооборот — 5000 строк, начинают нарастать взаимные блокировки. Истинная причина — неверная оценка накладных расходов на RLS при записи общих объектов.

Ключевой тезис: Централизация выявляет слабые места проектных решений, которые были незаметны в изолированных базах. Проблема не в платформе, а в том, как мы делим общее.

Ловушка: RLS на общих справочниках

Когда справочник Номенклатура помечен как общий для всех организаций, типовое решение — добавить реквизит Владелец (ссылка на справочник Организации) и установить ограничение Владелец = &ТекущаяОрганизация. На форме выбора элемента это приводит к тому, что платформа автоматически подставляет Где Владелец = ... в запрос. Но при записи нового элемента из документа другой организации система должна проверить право текущего пользователя на вставку именно этого владельца. Механизм RLS пересчитывает ограничения для каждого вставляемого или изменяемого реквизита, порождая дополнительный запрос к базе на каждую строку табличной части.

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

Процедура ЗаполнитьТоварыИзДокументаОснования(Основание, ТаблицаТоваров)
    Для Каждого СтрокаОсн Из Основание.Товары Цикл
        НовСтрока = ТаблицаТоваров.Добавить();
        НовСтрока.Номенклатура = СтрокаОсн.Номенклатура;
        НовСтрока.Количество = СтрокаОсн.Количество;
        // Неявная проверка RLS при попытке установить реквизит владельца
        // Если у пользователя нет прав на эту номенклатуру по RLS — будет ошибка
    КонецЦикла;
КонецПроцедуры

Если для 500 документов в день это незаметно, то при 2000+ блокировки начинают накапливаться, и транзакции уходят в «ложный» таймаут. Ловушка в том, что при тестовом запуске никто не проверяет сценарий одновременного ввода документов разными организациями под разными пользователями.

Сравнение подходов: условия применимости

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

• Единая база + разделение через RLS: работает только если объём условно-постоянных данных (справочников) не превышает 50–70 тыс. элементов, а интенсивность записи — не более 15 000 движений в день. При большем объёме блокировки на таблице справочника становятся узким местом. Противопоказан при сильных пиковых нагрузках (закрытие месяца, когда все компании одновременно записывают регламентные операции).
• Распределённая информационная база (РИБ): оправдан, если юридические лица имеют разные учётные политики или физически находятся в зонах с нестабильной связью. Ловушка здесь — сложность управления нумерацией. Стандартный механизм в платформе использует префиксы: Документы.РеализацияТоваровУслуг.УстановитьПрефиксНомера("00" + СокрЛп(Организация.Код)). Часто забывают сделать уникальными префиксы для реквизитов документов (например, номер счета-фактуры), что ведёт к коллизиям после слияния.
• Внешние хранилища мастер-данных (MDM): применяют, когда справочник Номенклатура реально огромен (миллионы позиций) и не может быть размножен в каждую базу. В этом случае централизация реализуется через HTTP-сервисы. Пример реально используемой архитектуры: каждая локальная база обращается к внешнему сервису для валидации и получения нормализованных данных. Здесь важно не делать синхронизацию в реальном времени — асинхронность через очередь задач.

Как выбрать стратегию объективно

Критерий выбора — не «хочется единую отчетность», а частота обращений к общим данным при записи. Чем выше частота, тем дороже RLS. Если средний документ ссылается на справочник более 5 раз, а создаётся 300 документов в час — RLS становится проблемой.

Практическое руководство: что делать прямо сейчас

Чек-лист первой недели проекта централизации

1. Аудит текущего документооборота: собрать статистику количества записей на каждую организацию за месяц. Выявить организации-лидеры по числу операций.
2. Замерить производительность RLS: создать тест, который параллельно (в 10 потоках) записывает 1000 строк в табличную часть документа, привязанных к 5 организациям. Измерить время выполнения и количество взаимных блокировок (использовать ТехнологическийЖурнал с пометкой TLOCK).
3. Определить профиль справочников: проверить, есть ли реквизиты, которые могут быть вынесены в отдельные справочники (например, ХарактеристикиНоменклатуры у каждой организации разные — значит, лучше создать отдельные типовые элементы с помощью СоздатьЭлемент(), не перегружая RLS).
4. Выбрать топ-5 справочников, по которым RLS обязателен: для остальных отказаться от RLS в пользу разделения через группы доступа (роли). В УТ/ERP это реализовано через ГруппыДоступа на уровне подсистемы, что не создаёт нагрузки на уровне записей.
5. Спроекти