Сначала была боль…
Однажды в стародавние времена наша команда столкнулась с типовой проблемой публикации ярлыков запуска 1С-систем. Имеющиеся на тот момент механизмы публикации через logon-скрипты обладали существенными недостатками:
- При изменении состава списка баз, пользователю требовалось перезагружаться, закрывая все свои любимые программы и мега-эксельки.
- Для получения списка баз пользователь должен быть в домене, в противном случае начинались танцы с отправкой ярлыков в письмах.
- Непонятная организация групп пользователей для размещения ярлыков. Например, по отделам в домене. Таким образом некоторые пользователи получали базы куда им ходить нельзя, но очень хочется.
- При появлении новой базы нужно было отвлекать "очень занятых" системных администраторов.
- При смене схемы публикации или сервера сотрудникам технической поддержки нужно было бежать к богам доменов и серверов.
- Если вдруг требовалось дать доступ пользователю к системе вне «группового списка», допустим к системе из тестового окружения или к демосистеме, то техподдержка снаряжала самого молодого и удалого в путь дорогу дальнюю.
- Бывало звучал звонок, что дескать при запуске появляется сообщение: «не обнаружена система» (переехала в связи с улучшением жилищных условий), тогда техподдержка рекомендовала перезагрузиться, а потом, если не помогало, подключался специалист и менял параметры доступа, судорожно вспоминая: «у кого же еще может быть эта система?!».
- Или еще одна забава, игра «прогулка по минному полу» - это когда нужно перевезти базу и попытаться угадать места, где требуется изменить параметры подключения к ней внутри других систем, чтобы ничего не развалилось (одни забывают про ведение документации, другие о том, что её нужно читать).
- А при смене версии платформы или переезде на другой сервер приключения техподдержки начинали играть еще более яркими красками.
Этот список можно пополнять еще кучей ситуаций из жизни техподдержки, которые они вспоминают с содроганием. Запутанность, отсутствие контроля за пользователями, непонятный перечень систем и их параметров, сложность понимания и тяготы взаимодействий между подразделениями приводили к состоянию нервного тика у техподдержки, да и у пользователей.
Было решено, что так дальше жить нельзя, и морально-психологическое состояние коллектива надо поправлять.
Поиск пути к дзену…
Вашему вниманию хочу предоставить один из примеров автоматизации управления списками ярлыков информационных баз.
Первый шаг был сделан к стандартизации названия систем и среды их обитания.
Требовалось разделить 1с-системы на контуры и избавить свои головы от необходимости помнить заковыристые имена баз и их место жительства.
Каждая система была переписана и зарегистрирована в нашей системе управления информационными базами, где ей назначался уникальный код. Также создали и закрепили правила именования при наследовании баз. А сами системы были распределены по зонам: production, testing, development, archive.
Второй шаг заключался в разделении зон ответственности между админами и остальными.
Позвали на чай админов, и после пары чашек у нас родилась мысль о применении возможностей сервера DNS: использовать CNAME-записи, объединяющие зоны сервера и системы.
В итоге мы получили красивые пути к системам. Путь "srv21-prod-1c/UT" превратился в "ut.production/UT". Таким образом, когда админам требуется изменить место жительства системы на серверах после работ по миграции, то они изменяют только CNAME-запись и никто больше от этих переездов не страдает.
После этих двух шагов мы вместо страшных и сложно-запоминающихся названий типа "srv04-1c/UT10_copy_3" уже получали красивое и логичное 'UT_dev2_1.development/UT_dev2_1" («UT» - это родительская система, «dev2» это код разработчика, а «1» это порядковый номер системы у разработчика)
Теперь техподдержке не нужно будет устраивать гадания и демонстрировать скрытые таланты своей памяти при попытках вспомнить актуальное имя сервера или кому принадлежит база. Всё что нужно знать так это код системы и ее зону. А информация о том куда/когда/какая база мигрирует стала абсолютно неинтересной.
Вслед за админами пришли разработчики, в чашках образовалось кофе и мы начали размышлять, что пользователей нужно тоже учитывать, а главное знать с какими системами они работают. После множественного употребления кофе в перерывах на разработку появилась система управления пользователями (СУП). О том, как и что там работает, тема отдельного большого рассказа. А пока представим, что произошел телепорт и система уже существует. Коротко могу сказать: при приеме на работу пользователь автоматически добавляется в этот СУП (да, забавно звучит), где ему на основании должности назначается профиль со списком баз и ролей для каждой системы.
Дело осталось за малым, разработать механизм публикации ярлыков. Да так, чтобы было в ней минимум рабского труда и максимум автоматизации.
Определились окончательные требования и ограничения, я посмотрел по сторонам, заглянул в ИТС, немного покопался на сайте Инфостарта (спасибо автору публикации 1069081), пофантазировал да приправил нотками философии и на выходе получилась концепция сервиса публикации ярлыков. Дальше оставалось только наложить идею на технологии.
В итоге получилась система с неброским именем «Коннект 1С».
Что же мы хотели получить от системы…
Требования и ограничения выглядели так:
- Работа клиентов с продакт-системой должна осуществляться через https (технологические стандарты компании).
- Каждый пользователь должен иметь индивидуальный список баз (пользователей около 2000)
- Система добавляется только при наличии прав на работу с ней. (назначение ролей в системах в зависимости от должности)
- Возможность формировать списки как автоматически, так и дополнять их в ручном режиме при необходимости.
- Формирование индивидуального списка на любом рабочем месте вне зависимости от наличия доменной учетной записи.
- Принудительный сброс списка с перезапросом нового.
- Изменения списка без потери рабочего пространства (нет перезагрузкам и завершению работы)
- Возможность формирования индивидуальных или групповых параметризованных ярлыков системы.
- Автоматизация обновления тонкого клиента, если сменилась версия платформы сервера.
- Получение списка баз по своим учетным данным.
Как система выглядит глобально…
Концепт по автоматизации сервиса управления ярлыками получился таким:
Картинка есть… и что дальше?!
А дальше же всё просто. Спроектировать систему «Коннект 1С», разработать, протестировать да запустить :)
После в докере поднять контейнер apache с 1с-модулем на борту и с двумя конфигами default.vrd. Этот контейнер присасывается к системе «Коннект 1С» и начинает транслировать её данные для всех стартеров 1С, которым они потребны.
Ремарка: допускаем, что системы справа от «Коннект 1С» уже существуют и не влияют на вращение шестерёнок остального.
Немного технических базовых моментов…
Движок работы стартера с системой «Коннект 1с» базируется на 2-х типовых механизмах платформы 1с:
1. WebCommonInfoBases
2. WebDistributiveLocation
Дабы не плодить еще один вариант описания работы этих механизмов, предлагаю для подробностей почитать здесь:
//infostart.ru/public/1069081/ (пример реализации)
https://its.1c.ru/db/v837doc#bookmark:adm:TI000000422 (самая техническая документация от создателя)
Что же в итоге получил обычный пользователь…
Как мы все знаем, начинается жизнь каждого свежего (а иногда и не очень) пользователя со старта окна авторизации в увлекательный желтый мир. Пока новый пользователь изучал маршрут до своего рабочего места, система уже изучила его досье и определила ему место в «пищевой цепочке» компании с назначением полномочий в каждой доступной ему системе. Пользователю всего лишь требуется зайти на сайт и получить пароль себе на телефон.
Далее ввести свои учетные данные при запуске стартового окна 1С:
и получить список доступных ему баз на своем рабочем месте:
Доступ к системам предоставлен. Теперь можно приступать к работе и радоваться (или страдать, кому как). Если измениться состав систем или метод доступа, то сервис снова запросит данные у пользователя и сформирует новый список.
А что же получила техподдержка…
При входе в систему техподдержка видит рабочую область для работы и контроля:
В окне ниже техподдержка может управлять публикацией ярлыка базы и параметрами ярлыка через выбранный шаблон:
Так выглядит запись о самой системе:
А так информация о версии платформы для автоматического обновления тонкого клиента:
Дальше работа с шаблонами уже настройки для продвинутых специалистов технической поддержки:
И самое важное, это конечно же информация о пользователе и его списке баз:
Здесь отображается список баз с указанием способа добавления:
• Автоматически (добавлена из системы управления пользователями),
• Публикация (внутренняя публикация через механизмы самой системы),
• Вручную (возможность добавить запись вручную для неординарных ситуаций)
У пользователя в списке для каждой системы индивидуально можно переопределить шаблон ярлыка.
В редком случае, но… если вдруг случилась вспышка на солнце и список у пользователя не обновляется, а ершик для прочистки кеша потеряли, то специалист техподдержки может зайти сюда и принудительно сбросить информацию о списке баз, нажав на кнопку «обновить».
Послесловие
Архитектура системы управления публикацией получилась простой и в тоже время достаточно эффективной, чтобы забыть обо всех бедах «средневековья».
Специалисты технической поддержки после внедрения испытали полную гамму эмоций: удивление, недоверие, принятие, радость :). После выдохнули и продолжили работать над новыми задачами.
Спасибо за внимание!
P.S. Не претендую на оригинальность решений. Если будут интересны технические подробности, пишите, поделюсь деталями.
