Выживалово. 70 баз и один админ, Или атака клонов

Когда читаешь статьи про базы на 200 терабайт, команды из 450 разработчиков и системы с 200 тысячами пользователей, это напрягает и пугает. Возникает вопрос: а как живут остальные?

Я занимаюсь 1С с 2000 года. На последнем месте работы, когда я туда пришёл, было 20 расширений без описания и комментариев, 55 баз Бухгалтерии и 15 ЗУП. О том, что их столько, я узнал лишь недели через три. Видимо, побоялись сказать сразу, чтобы я не убежал. Меня одного сразу посадили и на Бухгалтерию, и на ЗУП.

Первые шаги: разбор завалов и анализ баз

Что ж, как сапёры, надеваем перчатки и начинаем разгребать. Смотрим: одно большое расширение. Проверяем соседнюю базу — там другой вариант. Где-то блоков нет, где-то что-то добавлено. Уже интересно. Постепенно я просмотрел все 55 баз и составил карту: что в них есть и как это работает.

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

Проблемы с печатными формами и обменами

И зарплатчики, и кадровики оказались людьми творческими. Их удовлетворяли как могли, и в итоге появилось 150 разных шаблонов печатных форм. Это не просто «Заявление №1», «Заявление №2 для увольнения», а действительно разные варианты под разные задачи.

Наши проблемы во многом были именно из-за этих форм. Иногда без видимых причин падали обмены между базами. В однотипных системах наблюдалось разное поведение: здесь для приёмной работы выполняются одни движения, там — другие. Из-за этого обновление релизов и расширений занимало неприлично много времени.

Когда бухгалтерии стало нужно, они всё-таки решились выделить на это время. Мы посчитали: все базы Бухгалтерии и ЗУП на четырёх ключевых релизах удалось обновить за две недели по рабочим дням. В среднем — около четырёх часов на 5–6 баз, больше физически переключиться не успеваешь. Так, порционно, закончили за две недели. После этого я взял два отгула, отдохнул — и снова можно было работать.

Отсутствие инструментов и переход к централизации

Инструментов для администрирования баз у нас не было. Хотя на одной из предыдущих работ мы использовали хитрый метод: все базы были прицеплены к одному хранилищу конфигурации. Был мастер, который в своей базе смотрел, что изменилось в новом обновлении, добавлял нужное, ставил, тестировал. После этого наши 20–30 баз пачками подключались к хранилищу: загружали конфигурацию, применяли изменения — и готово. На одну базу уходило минут 20–30, зато был гарантированно одинаковый результат. Здесь же ничего подобного внедрено не было. Я уже начал планировать это сделать, но в итоге всё-таки согласовали и купили обновлятор.

Оптимизация расширений и внедрение версионности

Поставили КОРП-версию, нашли под неё место и ресурсы — жить стало легче. Примерно за полгода была составлена и отредактирована карта расширений. Мы посмотрели, какие расширения нам действительно нужны, а какие можно было убрать. Из порядка двадцати осталось двенадцать.

На изображении одно из расширений и его варианты: где-то есть, где-то нет, где-то добавлено что-то дополнительно.

Чтобы разобраться с этим, в каждом расширении, каждой печатной форме и каждой внешней обработке мы стали указывать номер версии — не типовой «1-2-3-4», а дату в формате «год, месяц, день». Благодаря этому в сводном отчёте сразу видно: где обновление прошло, где всё в порядке, а где дата отличается — значит, что-то забыли обновить или остались экспериментальные данные.

Чтобы управлять этим удобнее, мы сделали так называемую «базу баз» на 1С. Она опрашивает серверы и кластеры, показывает, какие базы развернуты, их статус, платформу, релиз, объём и так далее. Таких разработок тоже было около десятка.

Для администраторов мы добавили сводные отчеты по объектам баз. Теперь не нужно вручную проверять и выписывать — достаточно нажать кнопку.

Кроме того, внедрили мониторинг доступности баз. Каждые 5 минут система отправляет запрос и, если что-то не так, сразу сигнализирует в Telegram.

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

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

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

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

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

В центральном сервисе обмена мы сделали размещение обработок по базам. Если узел не заполнен — обработка уходит во все базы. Если заполнен — только в нужную.

Чтобы это работало, мы сделали расширение HTTP GET DATA. Через HTTP мы получаем текст запроса и его параметры. Параметры — примитивные: число, строка, дата.

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

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

Борьба с конфликтами расширений

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

Конфликты, когда модуль вместо основного используется в расширении №1, а тебе нужно, чтобы он использовался в расширении №2, были устранены.

Свели их по блокам на те, что отвечают за:

• Обмены,
• Интерфейс,
• Расчётные механизмы,
• Локальные патчи (иногда при обновлениях в 1С всё-таки случаются ошибки, мы их оперативно заливаем в одно централизованное расширение),
• То, что общается с внешними системами: ЭДО, КЭДО, СБИС, прочие ФНС.

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

Мы полностью отказались от COM-соединений между базами. Все работает на HTTP – на одном и универсальном методе.

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

На картинке один из наших сводных отчетов показывает состояние наших объектов.

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

Состояние обработок. Указана версия и можно посмотреть по какой-то одной базе, что входит в ее состав.

Можно посмотреть по внешней обработке, какая версия у нее в разных базах. Все это быстро и эффективно пишется на 1С.

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

Техническая реализация обмена данными между базами

Два этих блока закрыли 90% задач.

Это исходящий – дополнить набор по удаленной базе данных. То есть сделать какую-нибудь болванку запроса, выбрать первые ноль текста запроса, чтобы получить поля. Мы получаем пустую таблицу значений и ее, как параметр, закидываем в HTTP-запрос, который обрабатывает базы, которые находятся в справочнике.

Они получают этот запрос, устанавливают параметры, которые с ним пришли, и отправляют ответ в таблице значений.

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

Большое спасибо Владимиру Милькину, который написал «Обновлятор». Для администратора баз данных 1С это великий механизм, который закрывает практически все задачи.

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

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.