От экспертов «1С-Рарус»: Введение в управление доступом в больших системах 1С. Оптимизация RLS

Почему управление доступом в 1С это важно и не просто?

Размер имеет значение

Начиная с 2010 года фирма «1С» объявила о формировании новой стратегии по завоеванию рынка автоматизации крупных предприятий. Целью компании и сети ее франчайзи стала не только работа с небольшими фирмами, но и полноценная комплексная автоматизация крупных компаний и холдингов на тысячи рабочих мест. Автоматизация подобного масштаба диктует строгие требования к самой технологической платформе «1С:Предприятие», к выпускаемым на ней решениям и конфигурациям.

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

Для большинства крупных проектов на десятки, сотни и тысячи рабочих мест стали характерными общие проблемы производительности при работе с большим объемом данных.

Можно выделить две основные проблемы:

1. Деградация производительности с ростом объема данных.
2. Деградация производительности с ростом количества пользователей, закономерного увеличения числа функциональных ролей и усложнения при этом «матрицы прав».

Что такое крупный проект?

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

• Конфигурация на базе БСП + УТ 11 + CRM + самописные блоки.
• Объем базы данных 700 Гб.
• 2100 пользователей всего.
• 800–1000 активных пользователей.
• 1130 ролей доступа к объектам метаданных.
• 310 профилей (из них 40 — функциональные должности).
• 1157 групп доступа.

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

• филиалы компании,
• дирекции,
• организации,
• подразделения,
• склады.

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

Организация прав доступа к данным

Что в решении этой задачи для нас и для клиента чрезвычайно важно:

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

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

Настройка системы прав доступа с использованием ограничения по «Видам доступа»

Рассмотрим примеры настройки прав доступа на реальном проекте. Для начала детально изучим составные части системы прав доступа. Основные из них:

• роли,
• профили групп доступа,
• группы доступа,
• виды доступа,
• RLS шаблоны.

Роли

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

Роли могут выдавать пользователю права на просмотр определенных подсистем или специфическую функциональность (например «открытие внешних обработок и отчетов», доступ к режиму «все функции» и т. п.). Также существуют роли проверяемые программно.

Профили групп доступа

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

Группы доступа

Группа доступа является экземпляром профиля групп доступа. Т.е. набором прав конкретного «менеджера по продажам», «кладовщика», «бухгалтера» на предприятии со своим специфичным набором ограничений.

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

Создание ролей и профилей групп доступа

При внедрении конкретного проекта всегда возникает вопрос о правилах построения системы прав доступа. Фирма «1С» при использовании Библиотеки Стандартных Подсистем дает свои рекомендации организации ролей. Выдержка с сайта its.1c.ru:

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

Выдача прав пользователям

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

Статус группы доступа

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

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

Удаляемые и Неразобранные группы доступа являются также временными и используются только на этапе построения комплексной системы прав доступа.

Опросник прав

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

Мониторинг состояния системы прав доступа

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

• добавление группы доступа пользователю;
• исключение пользователя из группы доступа;
• изменение параметров группы доступа.

Как сделать так, чтобы ограничения прав работали и при этом все не тормозило?

1С RLS (Row-Level Security) или ограничение прав на уровне записи — это настройка прав пользователей в системе 1С, которая позволяет разделить права для пользователей в разрезе динамически меняющихся данных.

Напомним, как работает ограничение прав на уровне записей: на уровне конкретной роли и права доступа к данным (чтение, изменение, добавление) есть возможность задать вызов шаблонного запроса RLS с определенным набором Видов доступа. Возможно использовать шаблонные запросы БСП, а можно написать любой свой произвольный запрос.

Типовой шаблон запроса RLS содержит несколько десятков тысяч строк...

Оптимизация типового шаблона RLS (получение групп доступа)

Попробуем посмотреть типовой шаблон RLS, возможно, там есть что оптимизировать?

Одной из самых часто выполняемых частей запроса RLS — проверка права конкретного пользователя на текущую конкретную таблицу (объект метаданных). При этом каждый раз сначала перебираются (определяются) группы доступа, дающие права на запрашиваемый объект метаданных, а следом выполняется запрос по определению групп доступа, доступных текущему пользователю.

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

Основным сценарием разбора проблемы был анализ плана запроса через extended events. Сразу под подозрение попала последняя ветка запроса, у которой был обнаружен достаточно высокий COST и возникло интуитивное сомнение в необходимости постоянного получения текущих групп доступа пользователя при каждом выполнении запроса RLS. Список групп доступа пользователей достаточно статичен, меняется крайне редко, а вот постоянное его получение в каждом запросе могло приводить к замедлению скорости выполнения запроса. Проверяем!

В параметр сеанса были инициализированы все актуальные группы доступа пользователей и в шаблонном запросе RLS выполнена замена поиска групп доступа на обращение к параметру сеанса.

Заменили на параметр сеанса, что дало ускорение примерно на 20% на самых тяжелых таблицах.

Пользовательский отбор по ключевому измерению

Продолжая разбираться с оптимизацией RLS запросов наткнулись на интересную ситуацию: в нашей базе есть специальная аналитика — справочник «Филиалы», по которому мы разделяем все документы в системе и, соответственно, настроили ограничения RLS. Обнаружили проблему: при открытии списка документов «Заказы клиентов» по филиалу, у которого не было введено ни одного документа, динамический список открывался десятки секунд. При этом у пользователей других филиалов (по которым есть документы) открытие того же списка происходило практически мгновенно. Как так? На момент эксперимента в базе было более 500 000 документов «Заказ клиентов».

Разбираемся в ситуации: динамический список пытается получить первые 50/1000 строк данных, удовлетворяющих заданному условию. При этом также выполняется RLS запрос с целью скрыть недоступные пользователю данные.

Чем больше «нужных» данных в текущей таблице тем быстрее SQL найдет первые 20/1000 подходящих строк и вернет их динамическому списку. Если «нужных» данных в базе нет — придется все строки текущей таблицы соединять с RLS запросом и проверить на «пригодность».

Возникла идея «помочь» динамическому списку и планировщику запросов SQL — сразу фильтровать данные на уровне динамического списка через пользовательские отборы.

Шаг 1

В настройках динамического списка ставим отбор по филиалу (офису).

Шаг 2

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

В итоге при открытии формы списка у пользователя автоматически установлен отбор по филиалу:

Посмотрим план запроса — какие изменения произошли при выполнении запроса?

На таблицу «Заказа клиента» сразу накладывается отбор по филиалу и вместо 500 000 записей остается 6000. Только после этого срабатывает RLS запрос и по каждой из 6000 строк проверяется соответствие ограничениям доступа.

Было: выборка из 527 138 строк таблицы Заказа клиента.

Стало: 6267 строк.

Перенастройка ролей, «выравнивание» запросов RLS

В ходе эксплуатации системы прав мы продолжали испытывать проблемы с производительностью при открытии документов. Причем ошибка была «плавающая» — у некоторых пользователей с настроенным RLS все отрабатывало мгновенно, у других «жутко тормозило».

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

Включаем extended events, сравниваем планы запросов в ситуациях когда у пользователя 1 роль на объект и когда 2. Замечаем увеличение количества веток запроса с результирующим объединением.

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

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

Выполняем простую, но утомительно долгую работу — обходим ВСЕ роли, перепроверяем шаблоны RLS и порядок их вызова. Стараемся во всех ролях сделать единый шаблон и одинаковый оптимальный в нашей ситуации порядок вызова шаблонов RLS.

Что же нам пишет фирма «1С» на сайте в разделе Прав доступа по БСП:

Какой результат в цифрах мы получили:

Ускорение более чем в 8 раз!

Хотелось бы также отметить что порядок вызова видов доступа имеет достаточно важное значение и позволяет ускорить выполнение запроса RLS.

Три точки роста производительности RLS на крупных проектах

Подведём итоги:

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

Ранее мы уже писали о производительности нового RLS в 1С БСП 3 — приглашаем вас прочитать эту статью.