Десять продуктивных баз 1С в трёх странах, две разные конфигурации, к ним ещё тестовые и служебные. По моей прикидке, раньше на такой контур ушло бы пятеро: каждый со своим куском, плюс человек, который помнит, у кого что. Сейчас его поддерживаю я один, с чатом вместо напарника, и на Инфостарт время остаётся.
Расскажу, как это устроено, потому что схема оказалась проще, чем звучит.
MCP, Model Context Protocol, это открытый протокол, по которому языковая модель зовёт ваши системы: вы описываете систему набором инструментов, модель дёргает разрешённое и видит только то, что вы отдали. Для 1С это обычный HTTP-сервис, и подключить к нему одну базу легко. Дальше начинается то, о чём почти не пишут: баз десять, они в трёх странах, на двух конфигурациях, и сопровождать их надо каждый день.
Сразу оговорка, чтобы потом не было сюрприза: схема выполняет присланный код в продуктивных базах и живёт в закрытом контуре. За его пределами так делать нельзя.
Весь контур одной таблицей: страна, объём метаданных, число внешних обработок, когда обновлялось, жива ли база.
Два слоя, и порознь они бесполезны
Первое, что я понял, когда попробовал: модели мало доступа к базе.
Модель с доступом, но без знания конфигурации, пишет запросы к несуществующим объектам, зовёт процедуры, которых в этой конфигурации нет, и путает реквизиты. Модель со знанием конфигурации, но без доступа, красиво рассуждает и ошибается на частностях, потому что не может пойти и посмотреть.
Отсюда два слоя, и оба обязательны:
- Контекст. Исходники всех десяти баз, включая расширения и внешние обработки, выгружены и лежат в одном месте. Модель знает, как устроена каждая база.
- Исполнение. Через одну точку входа она может пойти в любую из десяти баз и проверить, как оно там на самом деле.
Дальше по порядку про каждый.
Слой первый: исходники всех десяти баз в одном месте
Выгружается всё: конфигурации, расширения и внешние обработки. Вот на обработках меня и ждал сюрприз.
Я думал, их десятки. По справочнику дополнительных отчётов и обработок вышло 575 штук на десять баз, от 20 в самой скромной до 194 в самой обросшей. Из них 548 живые, без пометки на удаление. Реально опубликована и используется 501 штука. Расширений всего 29, из них активных 27.
Откуда взялись 575: группы-папки исключены, считались только элементы.
Именно в обработках лежит то, чем базы отличаются друг от друга, и именно их никто не помнит: в конфигурации их нет, в документации тем более. Пятьсот одна работающая обработка это пятьсот одна причина, по которой две одинаковые с виду базы ведут себя по-разному.
Прикиньте своё число прямо сейчас, не открывая базу. Потом откройте справочник дополнительных отчётов и обработок и посчитайте живые. Я был уверен, что у меня десятки. Если ваша оценка сойдётся с фактом, напишите в комментариях: мне пока ни один человек не сказал, что знал точно.
Объём выгрузки на сегодня: 474 208 файлов в 435 168 папках, 34,5 гигабайта. Разложено по трём каталогам, по стране на каталог. Из этой выгрузки получается от 3,5 до 7,3 тысячи объектов метаданных на базу, смотря розница там или ERP.
Собирает это не человек. Скрипты в планировщике заданий, ночью, в три потока, с отчётом в Telegram по окончании. Утренний отчёт заодно служит мониторингом: база перестала выгружаться, видно сразу.
Хэш-проверка решает главную проблему такой схемы. Гонять полную выгрузку десяти конфигураций каждую ночь бессмысленно: конфигурации меняются редко. Поэтому перед выгрузкой сверяется хэш, и если ничего не поменялось, конфигурация пропускается. В отчёте это выглядит честно: «без изменений» и время в пределах десяти минут против «обновлено» и почти часа. Последний полный круг: 82 минуты 57 секунд на весь контур, из которых 55 минут заняла единственная обновившаяся база.
Без неё тот же круг занимал бы часов пять каждую ночь и мешал бы регламентным операциям.
Так выглядит ночной отчёт в Telegram: весь контур одним экраном, читается за пять секунд с телефона.
Слой второй: база технологического реестра
Второй слой держится на отдельной служебной базе:
База технологического реестра это служебная база 1С, которая знает про контур всё, а продуктивные базы про неё не знают ничего. Клиент разговаривает только с ней.
Что в ней лежит:
- справочник всех баз контура с адресами и каталогами выгрузки;
- учётные данные для подключения к этим базам;
- справочник методов доступа;
- исходники всех баз, загруженные записями;
- единственная точка входа, к которой подключён MCP.
И базы, и методы, и учётки лежат данными. Конфигурацию для этого трогать не надо, отсюда и вся дешевизна сопровождения.
Справочник баз. Адрес сервера, имя базы на сервере, страна, тип системы, окружение, версия платформы, каталог выгрузки. Чтобы подключить новую базу, добавляешь строку. Когда адреса лежат в конфиге на сервере, каждая новая база это правка файла плюс её согласование. И живой человек, который помнит, где этот файл.
Справочник баз: сервер, страна, тип системы, окружение, версия платформы, каталог выгрузки.
Справочник методов. Метод это один разрешённый вид обращения к базе: выполнить код, забрать логи, посчитать их, принять пакет, отправить уведомление. У каждого своя запись: наименование, код, описание, обработчик, признак активности, HTTP-метод, флаг редиректа. Новый метод это новая строка. Выключить метод можно снятием флажка, без конфигуратора и выкатки.
Справочник методов. Снятый флажок в колонке активности и есть выключение метода.
Учётные данные. В константах реестра лежит учётная запись, под которой он ходит в продуктивные базы. Получается два независимых круга: клиент авторизуется в реестре, реестр авторизуется в базах. Клиент никогда не видит паролей продуктивных баз. Смена пароля правится в одном месте и не задевает ни одного клиента.
Исходники записями. Выгруженный код загружается в реестр как объекты метаданных: имя, тип объекта, база, дата обновления, модули с числом строк, реквизиты и табличные части. Одна карточка на обработку: имя, модуль объекта 213 строк, модуль формы 49. Видно и в интерфейсе, и через запрос.
Карточка внешней обработки из продуктивной базы. Код в панели справа закрыт по NDA.
Модель работает именно с этими записями: по ним ищется, сравнивается и собирается ответ. Файлы на диске остаются сырьём, и туда она тоже может сходить, когда нужен свежий дамп прямо сейчас.
Пятнадцать строк в целевой базе
Теперь честная оговорка к заголовку. В продуктивных базах кое-что всё-таки стоит. Пятнадцать строк, в каждой из десяти.
И вот ради чего это терпится: вместо десяти отдельных подключений MCP у меня одно. Модель видит один инструмент, а не десять, ходит по одному адресу и передаёт имя базы параметром. Десять подключений это десять конфигураций клиента и десять мест, где что-то менять при первой же правке.
Вся функция, которая перекидывает вызов из реестра в нужную базу, занимает 115 строк. День работы. Против пятнадцати строк на стороне базы это и есть вся схема.
Вот эти пятнадцать строк целиком, это весь код, который живёт в каждой базе:
Функция CodeExecute(Запрос) ЧтениеJSON = Новый ЧтениеJSON; ЧтениеJSON.УстановитьСтроку(Запрос.ПолучитьТелоКакСтроку()); Данные = ПрочитатьJSON(ЧтениеJSON, Ложь); РезультатВыполнения = "Код выполнен"; Попытка Выполнить(Данные.ТекстКода); Исключение РезультатВыполнения = ОписаниеОшибки(); КонецПопытки; Ответ = Новый HTTPСервисОтвет(200); Ответ.УстановитьТелоИзСтроки(РезультатВыполнения, КодировкаТекста.UTF8, ИспользованиеByteOrderMark.НеИспользовать); Возврат Ответ; КонецФункции
Добавляется шаблоном URL к HTTP-сервису, метод POST. В двух базах из десяти обработчик существовал ещё до проекта, в остальные восемь добавлен разово: шаблон URL, метод, модуль, публикация. Пятнадцать минут на базу.
Тут стоит приглядеться, как возвращается значение. Переменная РезультатВыполнения объявлена до вызова Выполнить() и потому видна изнутри динамического выполнения. Присланный код её переопределяет, и это значение уходит в ответ. Никакого протокола сериализации: строка на выходе решает всё, а разбирать строку остаётся клиенту, там этому и место.
Обновлять эти пятнадцать строк нечего, потому что предметной логики в них нет никакой. Новый вид запроса или новая проверка делаются в реестре и в тот же момент доезжают до всех десяти баз. Меняется реестр, а не десять баз.
Как только сюда попадёт первая предметная проверка, начнётся версионирование, и схема потеряет главное своё преимущество. Проверять надо именно неизменность: пятнадцать строк можно испортить одной шестнадцатой.
Что это даёт в работе
Три вещи, ради которых всё и строилось.
Сравнить объект между локализациями за пять минут. Покажу дословно, как это выглядит, потому что без примера в такое верить рано.
Спрашиваю в чате: чем отличаются модули объекта чека ККМ в рознице трёх стран, напиши только отличие. Дальше без меня: модель прошла по реестру, собрала дифф по шести розничным базам и вернула разбор по странам. В азербайджанских в проведении есть ветка про подарочные сертификаты с отправкой ссылки покупателю, которой больше нет нигде. В казахской единственная содержательная вставка это определение аналитики хозяйственной операции при погашении сертификатов. В узбекской своя процедура печати. Общая часть у всех шести одинаковая.
Раньше этот вопрос означал два конфигуратора и вечер переключения окон, причём с риском что-нибудь не заметить. Спорные места после ответа проверяются в живых базах, не выходя из чата.
Вопрос человеческим языком, ответ по шести розницам трёх стран. Дифф модель собрала сама, десятью командами.
Проверить обмен с двух сторон и замкнуть круг. Выгрузка в одной базе, загрузка в другой, сверка результата обратно в первой. Раньше это работа на двоих, и оба верят друг другу на слово. Сейчас обе стороны видны в одном месте, и цикл выгрузка-загрузка проверяется целиком, прозрачно, за те же пять минут.
Модель тут, кстати, необязательна. В реестр ходит любой скрипт или консоль, MCP это просто ещё один клиент у той же точки входа.
Держать код десяти баз в одном стандарте. Когда исходники всех баз лежат рядом и доступны запросу, вопрос «где ещё есть такой же кусок» перестаёт быть исследованием. Это главный эффект: контур перестал расползаться.
Побочный эффект оказался крупнее ожидаемого. Через тот же канал построили перенос технических журналов в архив, и это освободило 52 гигабайта на продуктивной базе. Делали доступ, получили заодно уборку. И оборотная сторона, без которой картина нечестная: та же дешевизна работает в обе стороны. Одна ошибка в присланном коде доезжает до десяти баз за один вызов, так же быстро и так же незаметно.
И тезис, с которым многие не согласятся. Поведение вашей базы определяет не конфигурация, а те несколько десятков внешних обработок, про которые никто не помнит. Пока исходники всех баз не выгружены и не лежат рядом, фраза «у нас типовая» это предположение, а не факт. Проверяется ровно так, как описано выше, и проверка стоит одну ночь.
Три грабли, на которых я потерял время
Публикация и заглавные буквы в имени. Публикация меняет заглавные и строчные в имени базы и добавляет слэш на конце, из-за чего запросы уезжают на перенаправление. Коды 301, 302 и 307 приходится обрабатывать вручную, иначе часть запросов теряется молча и выглядит как нестабильная сеть. В отладчике не воспроизводится: ошибка живёт между клиентом и веб-сервером. Ушло больше времени, чем на всю остальную разработку. Из-за этой грабли в справочнике методов и появился флаг редиректа.
Асинхронный режим не заработал. Схему «запустить фоновое задание в целевой базе и опрашивать статус» пробовал и отказался: задание рапортовало об успешном выполнении, фактического эффекта не было. Ложный зелёный хуже честного падения: обнаруживается через неделю. Осталась синхронная схема с таймаутом на клиенте. Тонкость: при обрыве соединения серверная операция доигрывает до конца. «Ответа нет» не значит «эффекта нет», поэтому операцию надо делать либо безопасной для повтора, либо с признаком выполнения.
Таймаут. Со 120 секунд пришлось поднять до 600: на пересчёте итогов регистров исходного не хватало. Заодно это значит, что вызывающая сторона может висеть десять минут.
Две вещи, которые стоит заложить с первого дня
Развести коды ответа по слоям.
- 502 - не достучались до базы;
- 404 - базы нет в реестре;
- 405 - метод не разрешён;
- 200 с текстом ошибки в теле - упал присланный код.
При десяти базах массовый вызов возвращает пачку ответов, и по кодам сразу видно, где что. Плюс на кодах строится автоматика: повтор имеет смысл на 502 и бесполезен на 404.
Сделать проверку связности. Отдельный вызов, который спрашивает у всех баз «ты жива?» и не выполняет никакого содержательного кода. При запуске дала 10 из 10. Без неё первый же массовый запрос вернёт кашу из результатов и отказов, и разгребать эту кашу вы будете руками.
Кому это не подойдёт
На одной базе выигрыша нет, на двух-трёх он спорный: реестр и два круга аутентификации стоят дороже прямого подключения. Схема окупается там, где обход баз руками перестал помещаться в рабочий день.
Нужна однородность задач. Если к каждой базе своя логика, сложность вернётся в целевые базы, и пятнадцать строк перестанут быть пятнадцатью строками.
Нужен человек, который отвечает за базу реестра. Она выглядит как утилита разработчика, а становится частью продуктивного ландшафта: обновлять, резервировать и мониторить её надо наравне с остальными.
Если решите повторять, то в таком порядке
- Выгрузка исходников с хэш-проверкой. Она полезна сама по себе, без всякого доступа к базам, и на ней вы сразу увидите реальное состояние контура.
- Справочник баз и проверка связности, без выполнения кода вообще. Уже здесь видно, все ли базы доступны и правильно ли разобраны публикации.
- Точка входа только на чтение, устроенная так, что изменить ничего не может физически. Большая часть задач закрывается тут, и закрывается безопасно.
- Изменяющий вход отдельной точкой, с отдельными правами, белым списком и аудитом. Добавлять его стоит тогда, когда уже понятно, чего именно не хватает.
- Проверить поведение при недоступности реестра до того, как на него завяжутся процессы.
Такой порядок даёт рабочий инструмент на первом же шаге и оставляет самый опасный кусок на конец.
У меня порядок был другим, и об этом я жалею. Я начал с самого вкусного, с выполнения кода в базах, и ловил перенаправления и ложные зелёные статусы на живом контуре, не имея ни проверки связности, ни выгрузки. Отлаживать в таком режиме нечем: непонятно даже, база не ответила или запрос ушёл не туда. Когда выгрузка и проверка «ты жива?» появились, те же грабли перестали быть загадками и стали строчкой в отчёте.
Про сроки честно. Ядро, то есть реестр и проксирование, это день работы, но день получается, когда рядом есть тот, кто уже такое собирал. В одиночку с нуля закладывайте больше, и уйдёт оно не на код, а на публикации, права и мелочи вроде тех же перенаправлений.
Если возьмётесь повторять и застрянете, пишите в комментариях или в личку, подскажу. Схема неочевидная в мелочах, и половина этих мелочей в статью не поместилась.
Если коротко
Доступа к базам мало, и знания кода тоже мало. Работает только связка.
Начинать стоит с выгрузки исходников. Она впервые показала мне контур целиком: 575 внешних обработок, из которых работает 501.
Базы и методы держите записями справочников. Новая база это строка, новый метод тоже, выключить метод это снятый флажок. Конфигурацию не трогаете вообще.
В самих базах оставляйте минимум. Пятнадцать строк без предметной логики нечего обновлять.
Другие наши инструменты диагностики 1С:
- Выгрузка метаданных для LLM - тот же первый слой в маленьком масштабе: структура базы для модели, если разворачивать полный реестр не хочется.
- Матрица прав доступа для нейросети - кто и что реально видит в каждой из баз. Первое, что спрашивают, когда доступ получает внешний инструмент.
- Аудит паролей СУБД - тот же периметр с другой стороны: до чего дотягивается пароль от базы, в которую ходит реестр.
Вступайте в нашу телеграмм-группу Инфостарт