База для управления базами. Монстр или Франкенштейн?

Меня зовут Дмитрий Фурцев. Последние 2,5 года я работаю в отделе внутренней автоматизации компании WiseAdvice, где занимаюсь поддержкой работы клиентских баз, которые у нас находятся на аутсорсинге – для бухгалтерии, юридических услуг и расчета заработной платы.

И сегодня я расскажу о задачах обслуживания всего этого. Как вообще можно это сделать, стоит ли это делать, и сколько времени на это стоит тратить.

Проблематика

Наша инфраструктура представляет собой «зоопарк», где есть:

• Разнородные кластеры:

  • серверные базы, которые развернуты в стандартно;

  • базы, которые развернуты в дата-центрах;

  • базы, которые развернуты в Яндекс.Облаке;

  • большое количество баз, которые развернуты по технологии сервиса 1cfresh.

• Мы обслуживаем совершенно разные конфигурации – это и Бухгалтерия, и ЗУП, и УНФ, и «Управление торговлей». Все, что к нам придет. Мы готовы забирать любую базу.

• Также у нас есть еще и внутренняя система для автоматизации работы внутренних сотрудников – для краткости я буду ее называть CRM. Там ведется информация по контрагентам, договорам и прочее.

Вокруг этого «зоопарка» возникают различные около-1С-ные задачи, которые нужно решать. Сюда относится:

• администрирование баз – например, создание веб-публикаций;

• так как у нас много баз, нам нужно как-то решать вопрос с правами, с доступами к этим конкретным базам;

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

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

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

Задача: разработать интерфейс для запуска нужной базы конкретного контрагента

Начали с простого – мы хотели иметь в одном месте список всех обслуживаемых у нас баз с возможностью что-то с ними делать.

Для этого мы разработали отдельную базу, которую назвали УИБ (управление информационными базами). В рамках доклада я еще буду называть эту базу «монстром».

Расскажу, на каких принципах строилась эта разработка.

• Мы подключаемся к кластерам серверов, чтобы забрать эти базы. Чтобы не было вопросов с точки зрения безопасности, у нас заведены администраторы кластеров, мы храним пароли подключения к кластерам в БСП-шном безопасном хранилище данных. Для подключения к кластерам используем OneScript или COM-соединение с вызовом TCP-агента – кто что умеет. Подключились к кластеру, забрали список баз, загрузили в справочник «Инфобазы» – в этом справочнике мы можем увидеть список баз и указание, в каком кластере они находятся. Правда, пока мы еще не понимаем, какая база к чему относится, потому что имя базы не всегда что-то значит. Соответственно, нам нужно как-то понимать, что это за база, с каким контрагентом она связана.

• Базу УИБ, которую мы разработали, мы поставили отдельно – во-первых, чтобы было безопасно. Во-вторых, чтобы к этим данным был доступ у конкретных людей – зачем все в одном месте агрегировать.

• Мы интегрировали базу УИБ с нашей CRM. Как я ранее говорил, мы решали задачу синхронизации контрагентов и баз. Соответственно, нам нужно затянуть всю информацию о контрагентах и договорах. Но мы затягиваем только ту информацию, которая значима для нас. Т.е. только тех контрагентов, которые действительно в рамках обслуживания свои базы будут хостить у нас. Соответственно, мы просто затянем всех контрагентов и договоров прямо с УИДами. И дальше будем синхронизироваться по этой информации.

• Но тут возникает вопрос – как нам соединить базу с контрагентом? Автоматически это никак не сделать. Этот вопрос, конечно, приходится решать административным путем – здесь все-таки используется ручная привязка. У нас есть админы 1С – не серьезные администраторы, которые обслуживают сервера и так далее. Это – местные админы, которые у нас разворачивают базы, выгружают бэкапы. У них более простая работа. Они разворачивают базу и непосредственно в карточке контрагента нашей CRM указывают, куда они базу развернули. Соответственно, мы знаем, что у этого контрагента развернут такой-то список баз. И мы перед синхронизацией с CRM можем сопоставить базу с контрагентом. После того как мы получили вот такой список баз и контрагентов, мы уже можем понимать, сколько у нас баз. Какие из них мы обслуживаем, к каким контрагентам они относятся, найти дубли, если у нас что-нибудь старое. И дальше каким-то образом это раскручивать.

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

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

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

Мы у себя обслуживаем определенный список конфигураций, и по маске мы можем определить – если в свойстве «Версия» мы нашли значение «3.0.%», а в свойстве «ПодробнаяИнформация» – текст «%Процессинг%.П.%», мы знаем, что это какая-то наша модифицированная база. Ее мы обслуживаем не так, как обычные типовые «Бухгалтерии».

После подобной обработки мы получаем вот такой список инфобаз:

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

• Можно выбрать конкретный элемент, нажать на кнопку «Запустить инфобазу» и выбрать тип клиента для запуска.

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

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

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

Если такое произойдет, инфобезопасники будут очень недовольны.

Поэтому, пожалуйста, делайте все правильно.

Раздача ролей

Следующей шагом нам потребовалось реализовать механизм ролей.

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

Как он работает изначально?

• У нас на стороне CRM есть механизм, в котором ответственное лицо может создать документ с информацией о том, кому какую роль дать. Например, мы даем сотруднику Иванову роль «Координатор группы Payroll».

• В карточке роли «Координатор группы Payroll» прописано, в какие базы она предоставляет доступ – например, в базу ЗУП и в Бухгалтерию.

• Далее на стороне на УИБ (на стороне нашей базы-монстрика) у нас есть соответствие, где для имени роли мы прописываем, какие профили групп доступа соответствуют этой роли в типовой конфигурации. Естественно, этот механизм применим для каких-то типовых конфигураций на базе БСП, где профилей групп доступа используются. Но таких конфигураций все-таки подавляющее большинство – 99%, поэтому их применение профилей групп доступа объяснимо.

Далее:

• На стороне CRM есть регистр, в котором мы храним текущий список ответственных в разрезе ролей (по имени роли определяется, у кого в какую базу есть доступ).

• По расписанию мы запускаем синхронизацию с нашей базой УИБ – передаем в нее изменения списка ответственных и дополняем этот список профилями групп доступа (сопоставляются по имени роли).

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

• На стороне УИБ получаем результат – успех или неуспех. Если у нас есть какие-то проблемы, мы оповещаем ответственных и на сторону CRM эту информацию уже не будем возвращать как успех – соответственно, она у нас раздастся в следующий раз или после того как исправится ошибка.

• В случае, если у нас все успешно прошло, регистр ответственных на стороне CRM обновляется.

• А на стороне базы клиента мы создаем пользователей через доменную авторизацию – берем информацию из Active Directory и создаем пользователя с доменной авторизацией. После того как эти права розданы, он может заходить в любую базу, которая относится к его роли.

Эталонные базы

Поскольку нам нужно раздать профили групп доступа, нужно обеспечить, чтобы эти профили групп доступа в базе были.

Для решения этой проблемы у нас есть эталонные базы разных типов. Например, эталонная база «Бухгалтерия для УСН».

Из эталонной базы наши админы 1С могут:

• Развернуть новую базу для клиента.

• Использовать эталонную базу для синхронизации с базой клиента каких-то справочников. Например, справочника «Статьи движения денежных средств» или «Статьи доходов» или «Статьи расходов». Это – та информация, которую наши сотрудники у всех контрагентов хотят вести одинаково.

• Также мы синхронизируем с эталонной базой профили групп доступа – у нас есть методологи 1С, которые знают, какими должны быть профили групп доступа, отслеживают их изменения и эти профили групп доступа создают. А дальше мы на стороне УИБ их дополняем и синхронизируем в каждую базу клиента – тоже по какому-то расписанию. Если мы добавляем новую базу, например, мы тоже этот регламент запускаем и у нас профили групп доступа добавляются.

Отслеживание проблем и регламентное обслуживание

Какие задачи еще можно решить в рамках этой базы-монстра?

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

Мы в нашей базе сделали механизм периодических операций, который может:

• Выполнять какие-то алгоритмы обслуживания в конкретной клиентской базе. Например, можно на основе СКД сделать отбор инфобаз (по типу конфигурации или по имени) и записать какой-то алгоритм, который будет выполняться на стороне этой базы. Например, будут пересчитываться итоги. Тут тоже, конечно, нужно помнить о безопасности и о том, что давать права на выполнение этих алгоритмов нужно аккуратно, не забывать об этом. Соответственно, мы можем такие операции настраивать.

• Когда регламент у нас запускается, обходит все эти периодические операции, запускает их в фоновом режиме, мы эту информацию получаем, логируем. Если у нас какие-то ошибки, мы оповещаем ответственных. Естественно, логировать ошибки было бы неплохо в отдельных инструментах, которые для этого предназначены – сложить логи в Elastic, настроить Kibana и так далее. Но если это недоступно или хочется очень быстро что-то запустить, мы можем это все тоже делать через такую базу. Мы можем подключиться ко всем базам клиента, собрать информацию из журнала регистрации этой базы и дальше эту информацию как-то обработать. Например, отправить ответственному письмо или сообщение в Telegram. Или создать файлик для Zabbix, который оповестит ответственных уже отдельно. Также, если мы хотим отслеживать события не на стороне базы клиента, а на стороне нашей базы УИБ, то мы можем уже в журнале регистрации сделать эту рассылку тоже на стороне базы УИБ.

• И также мы здесь мы решили встроить механизм запуска быстрых гипотез – опроса клиентских баз. Например, собрать какой-то консолидированный отчет. Или собрать какие-то данные, и их дальше обработать. Это нужно для того, чтобы быстро запустить, не дорабатывая конфигурацию.

Управление расширениями и внешними отчетами/обработками

Но не все легко решаемо, и какие-то вещи нам приходится делать через расширения или внешние обработки, встроенные в подсистему БСП «Дополнительные отчеты и обработки».

Чтобы отслеживать их изменения, мы на стороне УИБ создали справочник, который хранит все объекты регистрации – расширения, внешние обработки и внешние отчеты. Они по расписанию будут раздаваться в те базы клиентов, для которых предназначены. Например, по типу конфигурации.

Как это будет происходить?

• Когда мы добавляем обработку, мы ее добавляем в эталонную базу, про которую я раньше говорил. Она там проверяется на применимость. То же самое с расширением. Если все в порядке, расширение действительно применится, и мы сможем его передать.

• Дальше мы анализируем версию. Версия обязательно должна быть указана – если мы говорим про внешнюю обработку, версия будет указана в функции «СведенияОВнешнейОбработке»; если расширение, то информацию о версии мы берем из свойств расширения. В расширении еще можно анализировать контрольную сумму.

• Мы сравниваем версию в базе клиента и в эталонной базе, и, если они отличаются, мы в базе клиента их обновим.

• Естественно, если мы хотим запуститься в локальном контуре, это можно сделать достаточно быстро. Но если мы хотим ставить расширение на отдельную область в 1С:Фреш, там это сделано сложнее, и нужно будет решать уже более глобальные проблемы. Тем более, если мы добавляем расширение с изменением данных – там нужно предварительно на эталонной базе тщательно проверить, что все действительно ок.

Обновление конфигураций типовых баз

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

Мы сделали инструмент для наших админов 1С по обновлению типовых баз – это делается максимально быстро за пару часов. Мы указываем:

• файл конфигурации, которым будем обновлять;

• файл расширения, который погасит всякие окна по легальности обновления и пр.;

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

Админам нужно просто зайти в эту АРМ, выбрать нужные файлы, отметить список баз, нажать ОК и подождать, пока все это обновится. Понятно, что такое автообновление возможно только для каких-то типовых баз на полной поддержке, которые не подключены к хранилищу.

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

• Например, наши базы для 1С:Фреш мы обновляем через OneScript.

• Здесь мы можем точно так же хранить подключение к тестовым и продовым базам. Сделать на основе этой базы инструмент управления обновлением всех баз.

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

Создание веб-публикации базы по запросу

Какую мы задачу еще решали?

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

Так как баз много, вручную публиковать каждую тоже долго. Плюс, если мы изменим расположение веб-сервера, нам нужно либо перенести все файлы default.vrd, либо заходить во все базы и заново их переопубликовывать.

Для этой цели мы делаем следующее:

• На стороне УИБ мы сохраняем макеты публикаций для каждого типа конфигураций с минимально доступными минимально необходимыми настройками подключения к HTTP-сервисам и веб-сервисам. Т.е. мы публикуем какой-то определенный состав этих сервисов. Дальше этот макет дополняется информацией об имени базы, дополнительной информацией о каких-то веб-сервисах, например, из расширений, которые мы должны опубликовать именно для этой базы. Например, это можно сделать просто текстовым полем, дополняющим эту публикацию.

• УИБ публикует макет с этой информацией прямо в мастер-ветку. Это все делается через GitLab. Сначала мы затягиваем текущую информацию обо всех публикациях. Потом обновляем конкретную публикацию выбранной базы либо публикацию по списку баз. И далее пушим это в Git – у нас все обновляется

• И уже на стороне сервера, где стоит Apache, он раз в какое-то время (например, раз в полчаса) опрашивает Git об изменениях, и, если они там есть, Apache их затягивает и перезапускается через Reload, чтобы не разрывать текущие соединения, а опубликовать новые публикации.

Таким образом мы можем быстро опубликовать базу на веб-сервер. Это полезно.

API для управления

По ходу развития нашей базы УИБ мы начали ее использовать также и в других проектах.

• Например, у нас есть продукт «Личный кабинет клиента» – это веб-приложение, где человек может увидеть список своих баз, к которым можно подключиться через веб-клиент. Чтобы мы знали, какие ссылки к базам ему предоставить, мы на стороне УИБ реализовали интерфейс для получения этих ссылок. Потому что у нас база может ходить между серверами, мы ее можем обслуживать как хотим. И только УИБ знает, где сейчас база находится. Соответственно, при входе пользователя в личный кабинет посылается запрос в нашу CRM. Там сопоставляется информация о контрагенте и дальше посылается запрос в УИБ, возвращающий список баз для этого контрагента, который дальше можно отобразить в личном кабинете. Полезный и быстрый способ запуска.

• Также мы реализовали API для управления пользователями. Это то же самое, что и с раздачей прав, только если нам нужно конкретному человеку что-то предоставить. В этом случае нет смысла ждать, пока права раздадутся по всем базам, поэтому предоставили отдельно.

• И еще мы можем сделать запрос в нашу базу УИБ, выполнить там какой-то запрос с параметрами и получить информацию об этом. Этот запрос выполняется в безопасном режиме, и позволяет получить нужную информацию – например, о списке баз контрагента.

Недостатки текущей архитектуры

К минусам текущего подхода можно отнести использование COM-объекта. Он не очень легко обслуживается, особенно, если у вас несколько платформ или если вы переходите на новую платформу.

Наверное, для покрытия нужной нам функциональности по управлению, реализованной сейчас через COM-объект, стоит реализовать расширение с HTTP-сервисом и управлять подключенными базами клиента уже через HTTP-соединение.

Тут возникает вопрос – как в первый раз это расширение поставить?

• либо его установим каким-то административным способом;

• либо по тому же COM подключиться и поставить расширение;

• либо можно через OneScript поставить расширение.

Какие-то способы есть. Суть в том, что, наверное, нужно уходить от COM. Хотя его плюс - в быстром запуске. Вам ничего не нужно делать – вы подключились, сделали все нужное для обеспечения безопасности и можете уже с этим работать.

Еще минусы в том, что:

• Базу УИБ нам нужно как-то спрятать, скрыть, чтобы не было к ней никакого несанкционированного доступа.

• Плюс ее нужно как-то дополнительно администрировать – это какие-то ресурсы, в том числе, административные.

• И работа через COM-объект не очень быстрая. Поэтому, если будет большая нагрузка, какие-то операции не будут успевать выполняться. Тут уже, естественно, нужно будет переходить на HTTP-сервис в любом случае.

Выгоды использования базы для управления базами

А какие плюсы?

• Мы очень сильно уменьшили нашу ручную работу. Причем, минимальными затратами. Например, первичное заполнение списка баз можно сделать за пару часов, если вы знаете, что делать. Если не знаете, вы сделаете это за день или за два. Подключить и синхронизировать с CRM достаточно быстро.

• Мы смогли передать часть ответственности другим отделам. Наши админы 1С смогли публиковать веб-публикации по кнопке. Смогли обновлять список типовых баз. Смогли управлять профилями групп доступа. Это снимает работу с нас. И позволяет нам больше развивать какие-то сервисные продукты.

• Мы можем быстро запускать гипотезы через механизм подключения к разным базам. Так как у нас есть какой-то механизм с централизованным подключением, мы можем быстро подключиться, что-то проверить. И, если нам все нравится, развивать его уже дальше.

• И, естественно, мы упростили нашу работу с зоопарком.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2021 Post-Apocalypse.