Проект по импортозамещению 1С в Т-Банке: планы, подготовка, сроки, ресурсы, сложности, результат

В этой статье я расскажу про проект импортозамещения в Т-Банке на примере конфигурации 1С:ЗУП, потому что сейчас именно эти конфигурации и базы у нас наиболее большие. Мы их успешно перевели, и наибольшее количество проблем у нас было именно с ними.

Начало. Исходная архитектура баз данных ЗУП

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

Первая база весила примерно 40 ГБ. В ней была одна организация, около полутора тысяч сотрудников, не было RLS и каких-то особых особенностей. Эта база выполняла роль, условно говоря, «песочницы». Все эксперименты мы проводили на ней, а затем раскатывали изменения на другие базы.

Следующая – конфигурация ЗУП для дочерних компаний. Она была больше, весила около 80 ГБ. В ней несколько десятков юридических лиц и порядка 9 000 сотрудников. Из особенностей – включен RLS по организациям.

И отдельная база – под банк. Сейчас она весит порядка 1 ТБ. В ней одна организация и около 90 000 сотрудников. Примерно половина из них – штатные сотрудники, половина – подрядчики. Особенность этой базы в том, что в ней включен RLS по физическим лицам.

Вся эта инфраструктура работала на MS SQL Server под Windows. Каких-то серьезных проблем мы не испытывали, спокойно развивали сервис и развивали 1С. Так продолжалось до 2022 года.

Регуляторные требования ЦБ и сроки импортозамещения

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

Основные факторы риска с точки зрения ЦБ – это:

• Продукты из США,

• Оборудование,

• Базы данных Oracle и SQL Server,

• средства защиты информации (СЗИ).

Они считаются элементами риска из-за отсутствия поддержки и невозможности устранения уязвимостей.

В Центральном банке есть специальная комиссия, которая следит за выполнением планов по импортозамещению. По срокам установлены следующие ориентиры:

• 10% – до 2022 года,

• 40% – до конца 2023 года,

• 100% – в период 2024–2027 годов.

Компоненты системы, подлежащие импортозамещению

В контур импортозамещения 1С в у нас попали следующие компоненты.

Прежде всего, система виртуализации. Ранее мы использовали зарубежный Hyper-V, и нам необходимо было перейти на систему виртуализации OpenStack.

Серверное программное обеспечение – переход с Windows на Linux.

Веб-сервер – IIS на Apache.

СУБД под 1С – переход с MS SQL Server на PostgreSQL. При этом у нас была СУБД не только под саму базу 1С, но и большая СУБД на MS SQL Server, которая использовалась для обмена данными с другими сервисами. Архитектуру этих обменов я опишу чуть позже.

Также в контур импортозамещения попали файловые обмены через сетевые шары – старые legacy-обмены. Мы приняли решение заменить их на новые инструменты. Основным инструментом для нас стал Kafka/rest api.

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

Дополнительные требования в рамках проекта

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

По производительности требовалось отсутствие деградации. Скорость работы на MS SQL Server не устраивала заказчика, поэтому необходимо было сделать как минимум не хуже.

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

По надежности – отказоустойчивый кластер СУБД.

И Observability. Под Observability подразумевалось оснащение 1С необходимыми мониторинговыми логами, чтобы система самостоятельно сигнализировала о возникающих проблемах.

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

Зависимые сервисы

В Т-Банке 1С система не существует сама по себе, она находится внутри нашей микросервисной архитектуры. Основной проблемой и давней головной болью было то, что витрина данных и все обменные таблицы находились на MS SQL Server.

Схема обмена выглядела следующим образом: 1С в течение дня накапливала данные у себя, ночью по расписанию все это выгружала, а все зависимые сервисы ночью забирали эти данные. Объем накопился достаточно большой – порядка 110 обменных таблиц. При этом существовала «матрешка» неочевидных зависимостей: один сервис забирал данные у нас, но на эти данные опирался другой сервис, который ходил к нам не напрямую.

Старт проекта и первую встречу мы провели в марте 2023 года, а первые задачи попали в план на второй квартал 2023 года.

Середина. Что с этим делать тимлиду

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

Объявить End of Life

Прежде всего, необходимо объявить End of Life (EOL) и зафиксировать, что MS SQL Server находится в статусе deprecated. Если в организации есть формальная процедура, ее обязательно нужно пройти. В дальнейшем вы будете опираться на этот документ.

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

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

Договариваться и выравниваться

Обязательно нужно договариваться, выравниваться и описывать коллегам риски. Делать это лучше заранее, потому что можно не попасть в планирование из-за внутренних процедур. Либо попасть в планирование, но не с первого раза, и тогда можно потерять месяц или квартал.

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

Можно попробовать провести задачу как бизнес-задачу по бизнес-квоте: договориться с заказчиком и описать регуляторные и законодательные риски. Если это не получается, можно попробовать провести задачу как избавление от технического долга, если регламент организации это позволяет. Это можно обосновать тем, что от этого legacy давно хотелось избавиться, и сейчас есть подходящий повод.

Провести плановое тестовое отключение

Не стоит рассчитывать, что все коммитменты будут выполнены на 100%. Часть команд выполнит свои обязательства, часть – нет. Если EOL объявлен, его необходимо соблюдать и переходить в формальную плоскость. Можно проводить тестовые отключения – на час или на день. Это подчеркивает серьезность намерений и позволяет выявить неочевидные зависимости. Иногда сервисы или команды используют ваши данные, но сами об этом не знают. Такие отключения помогают это выявить и запланировать дополнительные задачи.

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

Управлять процессами

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

Подготовительные работы

Подготовительную работу мы начали с консультаций с внешними экспертами. Консультировались как по Ubuntu и Linux, так и со специалистами по PostgreSQL. Параллельно готовили мониторинги и настраивали алертинг.

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

Мы развивали QA, готовили тесты. Предпочтение отдавали автоматизированным тестам. Ручные тесты делать дольше, но автоматизированные можно использовать многократно. Если есть выгрузка в Allure, можно зафиксировать время выполнения тестов и легко сравнивать, как одна и та же операция выполняется при разных настройках.

Там, где не было зависимостей, мы начали работы по отключению COM-объектов и переписали обмены ЗУП на HTTP-сервисы. Конфигурация у нас нетиповая, и все уверяли, что миграция должна пройти без сложностей. Были показаны прецеденты, и мы тоже считали, что серьезных проблем не возникнет.

В части отключения обменных таблиц ситуация была следующей: около 110 таблиц, более 10 сервисов и команд, зависимых от нас. Старт работ был в апреле 2023 года, завершение проекта – в июле 2024 года.

Уроки на будущее

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

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

Отдельный неочевидный момент – DWH. Для дата-хранилища процесс поиска и отключения всех зависимостей занимает очень много времени. В нашем случае DWH отключались от нас самыми последними.

Результаты отключения почтовых рассылок

В рамках миграции почтовых рассылок у нас было отключено более 140 рассылок. Примерно 20 из них были признаны целевыми и остались в 1С. Часть рассылок ожидает переезда в свои целевые сервисы.

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

Сейчас эти рассылки переехали в DWH, и нагрузка на команду 1С в этой части заметно снизилась.

Уроки по проекту отключения почтовых рассылок

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

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

Новая архитектура обмена данными

В новой архитектуре обмена данными целевыми инструментами для нас являются Kafka либо REST – в зависимости от зависимого сервиса. В сумме у нас получилось более ста Kafka-топиков. Это связано как с выгрузкой данных, так и с обменом, потому что, как правило, используется два топика: топик с запросами и топик с ответами.

Изначально наш коннектор был написан на Python, но количество интеграций стало настолько большим, что он перестал справляться с нагрузкой, и его пришлось переписать на Go. Потребление ресурсов на Go оказалось в шесть–восемь раз меньше, чем на Python. В ряде случаев бывает достаточно просто поменять стек.

Замеры 1С

Вернемся к 1С. Мы проводили замеры на MS SQL Server и на PostgreSQL и получили примерно одинаковые результаты.

Существенных отклонений замечено не было, показатели совпадали с тем, что было на MS SQL Server. Поэтому миграцию мы провели достаточно быстро.

Первая база была переведена в феврале на PostgreSQL, в марте была переведена вторая база объемом 80 ГБ.

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

19 мая была переведена первая база, а 7 июля – вторая база объемом 80 ГБ.

Что выявили на базе 1Тб?

Что было выявлено на базе объемом 1 ТБ? На замерах мы поймали ошибку платформы, связанную с замедлением при удалении записей регистров расчетов. Со стороны конфигуратора это выглядело так: код на MS SQL Server выполнялся около 4 секунд, а на PostgreSQL – уже около 4 минут.

Некоторое время мы потратили на регистрацию этой ошибки и сбор информации через наш РКЛ. На небольших базах эта ошибка не воспроизводилась, она проявлялась только на больших объемах данных. Именно на этой базе мы ее зафиксировали.

А что делать теперь?

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

Если кратко, мы обошли эту проблему с помощью утилиты PG Query Rewrite. К ней было подключено около полутора тысяч правил подмены. Платформа в запросах использует временные таблицы, номера которых формируются случайным образом, поэтому использовать маски для подмены запросов не получалось.

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

Производительный RLS или обычный?

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

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

Архитектура позволяет выполнять такую манипуляцию. В обратную сторону это не работает. Переключение реализовано через управление сеансами пользователей.

Последние штрихи перед миграцией

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

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

По результатам замеров и с учетом требований к производительности мы приняли решение переехать на выделенный физический сервер Bare Metal именно для баз данных. Серверы приложений при этом остаются на OpenStack, то есть в виртуализированной среде. Небольшие базы также продолжают работать на виртуальных машинах.

Миграция базы 1ТБ

Миграцию базы PostgreSQL мы провели 5 ноября 2024 года. В течение следующих двух недель мы в режиме ASAP отрабатывали все возникающие проблемы и замечания.

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

16 ноября мы перевели серверы приложений на Linux. Если посмотреть на даты, видно, что первая миграция была выполнена после выплаты зарплаты, а вторая – после выплаты аванса. В обоих случаях миграция прошла без сбоев. Продакшн не останавливался, и ни одна из операций не привела к остановке продуктовой базы.

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

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

Выводы

Выводы, которыми мы хотим поделиться с сообществом 1С, следующие:

• Небольшие базы 1С переходят на PostgreSQL практически без проблем. В нашем случае объемы выглядят как 40–80 ГБ и сразу около 1 ТБ, без промежуточных баз порядка 500 ГБ, что затрудняет определение пороговых значений.

• Сборка PostgreSQL Pro, которая используется бесплатно, по нашим тестам показала себя лучше, чем сборка от 1С.

• Большие нагруженные базы могут работать на PostgreSQL, но для этого требуется оптимизация.

• Платформа 1С пока не полностью адаптирована под новый стек, но со своей стороны мы ведем коммуникацию с компанией «1С» и регистрируем все выявленные ошибки.

• Типовая конфигурация ЗУП также пока не полностью адаптирована под PostgreSQL, но это решаемая задача. Все необходимые механизмы для оптимизации существуют, а мест, где требуется доработка, не так много.

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

• Командам разработки необходимо перестраивать подход к работе с новой СУБД. Инструменты оптимизации в MS SQL Server и PostgreSQL отличаются, и это нужно учитывать.

• Наш банк этот путь прошел, и мы можем уверенно сказать, что PostgreSQL работает на объемах в 1 ТБ.

Мы накопили значительный опыт оптимизации систем на PostgreSQL и готовы делиться этим опытом с другими командами и сообществом.

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

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