Мы входили в проект миграции высоконагруженных систем 1С с Microsoft SQL Server 2017 на российскую СУБД как в типовое импортозамещение. Изначально задача формулировалась как замена одного продукта другим в рамках требований регулятора. Но на практике проект изменил всю эксплуатационную модель 1С и СУБД и дал нам возможность пересмотреть, как именно обеспечиваются их безопасность и надежность наших систем.
Автор: Петр Иванов, проректор по цифровому и технологическому развитию, Северо-Восточный федеральный университет имени М.К. Аммосова
Контур использования 1С в нашем университете большой и неоднородный: около 20 тыс. студентов и порядка 3 тыс. сотрудников, распределенная структура с учебными подразделениями (факультетами и институтами), научно-исследовательскими институтами, колледжами, лицеем и филиалами. Внутри – три ключевые системы 1С, включая расчет заработной платы и кадровый учет, около 200 рабочих мест и интеграции с государственными системами, в том числе с ГИИС УОФ "Электронный бюджет". Общий объем данных, хранимых в СУБД – порядка 1,5 Тбайт. В такой конфигурации любая ошибка – это уже не локальный сбой, а остановка операционной деятельности.
Требования для проекта перевода 1C на российскую СУБД Tantor Postgres были предельно прикладными. Данные нужно было перенести без потерь, не допустить простоев в рабочее время, сохранить или повысить производительность и не сломать интеграции. При этом основной триггер проекта был, конечно, регуляторный – курс на импортозамещение и требование использовать СУБД из реестра отечественного ПО. Все остальные задачи – производные.
Важно, что к моменту начала проекта у университета уже был опыт импортозамещения на других слоях инфраструктуры: использовались отечественные ОС, средства виртуализации, системы управления доступом и удаленных рабочих мест. Это снизило организационные риски, но не убрало технические.
От сценария одномоментного переключения мы отказались сразу – слишком велики риски. Мы разбили перенос на этапы и шли от системы к системе последовательно. Каждую базу переносили в отдельное технологическое окно, как правило на выходных. Это позволяло не затрагивать рабочие процессы и локализовать возможные проблемы.
Миграцию 1,5 Тбайт данных разделили на несколько проходов. Сначала поднимали целевую инфраструктуру, затем настраивали параметры СУБД под профиль нагрузки 1С. В качестве базовой точки использовали преднастроенную конфигурацию для 1С, но практически сразу пришлось уходить в ручную настройку – под конкретные сценарии и объемы.
После переноса мы проводили двойную проверку. Сначала – на уровне целостности данных. Затем – на уровне прикладного поведения. Прогоняли расчет зарплаты, кадровые операции, типовые отчеты, обмены с внешними системами. Там, где появлялись отклонения по времени или результатам, возвращались к настройке.
Переход оказался не равномерным по времени. На отдельных этапах приходилось откатываться, корректировать параметры и повторять прогоны. Это удлиняло сроки, но позволяло не переносить проблемы в промышленную эксплуатацию.
Границы ответственности
До миграции роли 1С и СУБД в части безопасности и эксплуатации были не до конца разделены. После перехода их пришлось четко определить. 1С стала отвечать за прикладную логику: роли на уровне метаданных, ограничения в бизнес-процессах и журнал регистрации действий пользователей. СУБД взяла на себя хранение данных, шифрование на диске, изоляцию сессий, сетевую аутентификацию и аудит изменений структуры. Часть функций безопасности была сознательно делегирована на сторону СУБД. В первую очередь это разграничение доступа между администраторами БД и прикладными пользователями, аудит подключений и контроль DDL-операций. Отдельно было включено шифрование остаточных данных.
Такое разделение дало практический эффект. Контроль сместился ближе к данным, а не к прикладной логике. Появилась возможность проверять не только действия пользователя в 1С, но и то, что реально происходило в базе.
Важным условием была согласованность ролей. За счет использования единой службы каталогов рассинхронизации между 1С и СУБД не возникло. При этом проблему избыточных прав в 1С пришлось решать отдельно: отказ от универсальных ролей, регулярный аудит назначений, использование встроенных инструментов анализа прав.
Первый заметный эффект после запуска – изменение наблюдаемости. Стало проще отвечать на вопросы, которые раньше требовали косвенных оценок. Мы начали видеть, какие именно запросы выполняются слишком долго, где возникают блокировки, какие таблицы создают нагрузку.
В MS SQL часть этих возможностей была доступна из коробки. В новой конфигурации сопоставимый уровень диагностики пришлось собирать самим. Использовали статистику запросов, расширения для анализа блокировок и ожиданий, логирование длительных операций. Вначале это воспринималось как усложнение, но в процессе стало понятно, что гибкость настроек стала выше. Теперь мы смогли настроить диагностику под свои сценарии, а не под стандартную модель.
Полезнейшим достижением стал сквозной аудит. Мы связали журнал 1С, логи СУБД и события ОС. Для этого использовали идентификаторы сессий и параметры подключения, включая передачу correlation_id через application_name. В результате появилась непрерывная цепочка: пользователь – действие – SQL-запрос – изменение данных. При инциденте мы идем по ней сверху вниз и расследуем всю картину.
Технически это реализовано через сопоставление session_id в 1С, backend_pid в СУБД и системных логах. Время восстановления всей цепочки – всего нескольких минут. Ранее на это уходили часы.
Доступ и надежность
При этом важно было учесть риск прямого доступа к данным в обход 1С. В таком сценарии администратор базы может подключиться к СУБД напрямую и выполнять операции с таблицами, не проходя через ограничения, заложенные в 1С.
Этот риск мы закрывали на стороне самой СУБД. По сути, ограничили возможности прямой работы с данными: настроили разграничение прав, запретили неконтролируемые изменения таблиц и включили аудит всех структурных изменений. Для чувствительных данных дополнительно использовали ограничения на уровне строк. Администраторов при этом перевели на работу через специальные учетные записи с полным логированием, чтобы любое действие можно было отследить. В результате администратор управляет системой, но не имеет неконтролируемого доступа к данным.
Пришлось выстраивать заново процесс обновлений. Мы перешли к регулярной схеме: плановые обновления – раз в квартал, критические – в течение 48 часов после выхода. При этом ни одно обновление не устанавливается сразу в продакшен. Сначала оно проходит тестовый стенд, затем одну из реплик, и только после этого выполняется переключение. Для крупных обновлений используем отдельный контур, чтобы заранее посмотреть, как система ведет себя под нагрузкой.
Дополнительно мы ведем собственный репозиторий пакетов. Это позволяет проверять обновления на нашей конфигурации до внедрения и не зависеть от их готовности из коробки. В результате процесс стал более управляемым: меньше неожиданностей и понятнее, что именно меняется в системе.
Вместе с этим изменилась и работа с уязвимостями. За счет более управляемого процесса обновлений среднее время их закрытия сократилось примерно до двух недель вместо прежних 30–60 дней. При этом ответственность разделена: ИБ следит за актуальностью и приоритетами, а ИТ внедряет обновления и проверяет систему.
Проверка эксплуатацией
Основные сложности начали проявляться уже после запуска, когда система попала под реальную нагрузку.
В первую очередь мы столкнулись со скрытыми зависимостями 1С от MS SQL. Они не мешали самой миграции, но влияли на поведение системы. Речь шла о вполне конкретных вещах: генерации идентификаторов, чувствительности к регистру при сравнении строк, механизмах анализа взаимных блокировок. Все это пришлось адаптировать на стороне СУБД – где-то через замену функций, где-то через настройку типов данных, где-то через подключение дополнительных инструментов диагностики. Критичных несовместимостей, к счастью, у нас не оказалось, но все же разных нюансов накопилось достаточно много, и каждый из них требовал отдельного внимания.
Следующий слой проблем был связан с планировщиком запросов. На части сложных отчетов 1С он выбирал не самые удачные планы выполнения, из-за чего время работы отдельных операций могло вырасти кратно. Здесь уже приходилось разбираться глубже: анализировать статистику, корректировать параметры и в отдельных случаях задавать подсказки, чтобы зафиксировать более стабильный вариант выполнения.
Отдельной темой стал механизм обслуживания СУБД. При интенсивной работе 1С резко увеличивается количество изменений в таблицах, и без дополнительной настройки механизм очистки начинает работать неэффективно. В результате накапливается мусор, растет фрагментация и проседает производительность. Параметры пришлось подбирать под реальную нагрузку и держать под постоянным контролем.
Похожая ситуация возникла и с индексами. Их объем оказался больше ожидаемого, а встроенных механизмов сжатия из коробки не нашлось. Для поддержания структуры в рабочем состоянии мы подключали дополнительные инструменты и выстраивали регулярное обслуживание.
Наконец, пришлось заново собрать мониторинг. Базового набора метрик оказалось недостаточно, поэтому сформировали свой: отслеживаем задержки репликации, блокировки, нагрузку на операции записи, состояние таблиц и процессы обслуживания. Пороговые значения и алерты настраивались уже не по рекомендациям, а по фактическому поведению системы.
Вместе с архитектурой пришлось пересобрать и операционные процессы. В первую очередь появилась отдельная роль аудитора базы данных – это позволило вынести контроль в самостоятельную функцию, а не размазать его между администраторами. Параллельно мы пересмотрели подход к резервному копированию: ограничиваться созданием бэкапов оказалось недостаточно, поэтому в регламент добавили регулярные тесты восстановления. Это сразу выявило ряд нюансов, которые в обычной практике остались бы незаметными.
Мы усилили контроль за обслуживанием базы – в том числе за параметрами очистки и состоянием таблиц, поскольку именно эти аспекты напрямую влияют на стабильность под нагрузкой.
Все изменения конфигурации теперь фиксируются и проходят через согласование. Это добавило формальности, но заметно упростило разбор инцидентов: стало понятно, что и когда менялось, и какие последствия это могло вызвать.
При этом ожидаемого конфликта между ИТ и ИБ не возникло. Скорее наоборот: ИБ получила реальные инструменты контроля, а ИТ – более предсказуемую систему без скрытых ограничений и неочевидного поведения.
Итоги проекта
Этот проект сложно назвать просто заменой СУБД. В результате система стала более прозрачной с точки зрения аудита, управляемой по доступу и устойчивой к сбоям. В отдельных сценариях выросла и производительность – например, массовые расчеты ускорились более чем на 15%.
При этом заметно выросли требования к эксплуатации. Система дает больше контроля, но требует более высокой квалификации команды и постоянного внимания к настройке. Даже без фактора импортозамещения такой переход выглядит оправданным – за счет прозрачности, гибкости и возможности управлять безопасностью на уровне самой СУБД.
Если бы мы повторяли проект, раньше подключили бы расширенный мониторинг, уделили больше внимания нагрузочным тестам типовых сценариев 1С и сразу настраивали бы параметры обслуживания под реальную нагрузку.
Главный вывод простой: безопасность и надежность 1С обеспечиваются не платформой по умолчанию, а правильно настроенной архитектурой и дисциплиной в эксплуатации.