← На главную
Перевод учетной системы в облачную инфраструктуру требует четкого понимания технических различий между моделями предоставления сервиса, механизмов резервного копирования, правил миграции данных и способов доработки прикладных решений. Разберем ключевые аспекты работы с облачной 1С, архитектуру разделения данных и пошаговый процесс перехода между облаком и локальной средой.
Архитектурные различия: модель SaaS против аренды виртуального сервера (IaaS/PaaS)
При выборе облачного провайдера для 1С пользователи чаще всего сталкиваются с двумя принципиально разными моделями работы:
- Модель SaaS с разделением данных (мультитенантность, например, 1С:Фреш): Тысячи пользователей подключаются к единой информационной базе, в которой платформа
1С:Предприятие программно изолирует данные каждого абонента с помощью системного механизма разделения данных. Все регламентные процедуры, обновление платформы, установка типовых релизов конфигураций и резервное копирование выполняются администраторами сервиса централизованно. Доступ к конфигуратору закрыт, а пользователи работают через веб-клиент или тонкий клиент. - Модель аренды выделенного сервера / базы (IaaS / Hosted 1C): Клиенту предоставляется изолированная информационная база на выделенном виртуальном сервере (VDS) или экземпляре СУБД (PostgreSQL, MS SQL). В этом случае предоставляется полный доступ к конфигуратору, возможность снятия типовой конфигурации с поддержки, самостоятельное управление версиями релизов и прямое создание резервных копий в формате
.dt.
Возможности доработки и ограничения кастомизации в облаке
Проанализируем, как реализуется изменение функционала типовой конфигурации (например, 1C:Бухгалтерия) в облачном сервисе с разделением данных:
- Использование расширений конфигурации: Доработка бизнес-логики, добавление новых печатных форм, отчетов и обработок выполняется исключительно через механизм расширений и подключаемых внешних обработок.
- Аудит безопасности: Любое расширение или внешняя обработка перед загрузкой в сервис проходит обязательный аудит кода на соответствие стандартам безопасности. Не допускается использование опасных системных вызовов командной строки, прямого доступа к файловой системе сервера и несанкционированных сетевых соединений.
- Безопасный режим: Дополнительные программные модули подключаются с признаком безопасного режима, что блокирует выполнение привилегированного кода без явного декларирования разрешений в коде модуля интеграции.
- Ограничения внешних компонент: В мультитенантной среде нельзя зарегистрировать сторонние серверные DLL-компоненты, требующие привилегий уровня операционной системы.
Особенности переноса и выгрузки данных: почему XML, а не DT?
Выясним причину, по которой штатная выгрузка базы из облака с разделением данных формируется в формате архива XML, а не стандартного файла выгрузки .dt:
Файл .dt представляет собой полный дамп физической информационной базы целиком, включая все метаданные конфигурации и таблицы СУБД. В сервисе с мультитенантной архитектурой одна физическая база содержит изолированные области множества разных компаний. Выгрузить .dt для одного абонента технически невозможно, так как это привело бы к экспорту данных всех остальных клиентов сервиса.
Для выгрузки используется штатный механизм Библиотеки стандартных подсистем (БСП). Программа сериализует только данные текущей области разделения в структурированный XML-файл и сжимает его в ZIP-архив. Этот файл содержит всю нормативно-справочную информацию, документы, регистры и настройки конкретной организации.
Пошаговый переход из облака в локальную версию 1С
Разберем по шагам алгоритм переноса базы из облачного сервиса на локальный компьютер:
- Проверка номеров релизов: В облачном приложении переходим в меню
О программе и фиксируем точные номера релизов платформы и конфигурации. Для корректной загрузки данных версия локальной пустой конфигурации-приемника должна строго совпадать с облачной версией. - Формирование выгрузки в облаке: В интерфейсе сервиса переходим в раздел администрирования абонента, выбираем команду выгрузки данных для перехода на локальную версию и сохраняем сформированный архив
data_dump.zip (содержащий XML). - Подготовка локальной базы: Устанавливаем локальный шаблон типовой конфигурации нужного релиза и создаем новую пустую информационную базу. Важно: Загрузка данных из сервиса возможна только в версии
ПРОФ или КОРП. Загрузить выгрузку напрямую в базовую версию невозможно из-за отсутствия в ней поддержки механизмов разделения данных и многофирменного учета. - Загрузка данных: Запускаем созданную чистую базу в режиме
1С:Предприятие, открываем обработку загрузки данных из сервиса (в типовых решениях мастер загрузки запускается автоматически при первом старте чистой базы с вопросом о переносе данных) и указываем сохраненный ZIP-архив. - Контроль корректности: После завершения загрузки выполняем проверку оборотно-сальдовой ведомости, справочников и регистров для подтверждения целостности перенесенных данных.
Организация интеграций и безопасность данных
Рассмотрим технические нюансы взаимодействия с облачной базой при интеграции с внешними системами:
- Интеграция через API: Прямой доступ через
V83.COMConnector в SaaS-модели заблокирован. Все интеграции с сайтами, CRM и внешними сервисами строятся через стандартный интерфейс OData (REST API), либо через опубликованные в сервисе HTTP- и Web-сервисы по защищенному протоколу HTTPS. - Подключение торгового оборудования: Локальные фискальные регистраторы (ККТ), сканеры штрихкодов и терминалы эквайринга при работе через веб-клиент взаимодействуют с облаком через специализированные браузерные модули и расширения для работы с внешним оборудованием. При работе через Тонкий клиент подключение выполняется штатными драйверами локальной платформы.
- Сетевая безопасность и шифрование: Доступ к данным в облаке осуществляется исключительно по зашифрованным каналам (TLS/HTTPS). Физический доступ к серверам баз данных изолирован внутри дата-центров, а системные учетные записи сервиса разграничивают права доступа между компонентами кластера серверов
1С:Предприятие.