Фраза «перенесём 1С в облако за день» звучит как обещание готовой системы. Утром подрядчик получает базу, вечером сотрудники входят в неё и продолжают работу.
Опубликованные материалы EFSOL такого срока не подтверждают. Каталог Toolfox указывает один рабочий день только для экспертной оценки задачи. Официальный кейс EFSOL описывает отдельный проект: обследование, проектирование, настройку PostgreSQL, развёртывание кластера 1С и испытания перед запуском.
Поэтому выясните, что подрядчик называет переносом. За день можно оценить задачу или подготовить небольшую среду при готовых исходных данных. Отказоустойчивую систему нельзя принимать по факту запуска виртуальных машин.
В кейсе EFSOL облако заменило не один сервер
Компания «Рыбные корма» обратилась в EFSOL из-за риска простоя рабочего сервера. Заказчик также хотел отказаться от зависимости от программ Microsoft и расширять систему без остановки пользователей. Эти задачи описаны в официальном кейсе EFSOL.
Подрядчик построил два связанных кластера. Два сервера 1С распределяли пользовательские сеансы и фоновые задания. База работала в кластере PostgreSQL под управлением Patroni, etcd и HAProxy.
Patroni следил за состоянием реплик PostgreSQL и выбирал новый ведущий сервер при сбое прежнего. etcd хранил согласованные сведения о состоянии кластера. HAProxy давал серверам 1С единую точку подключения и направлял запросы на действующий узел PostgreSQL.
В разных фрагментах кейса указано разное количество узлов PostgreSQL: два и три. Поэтому точное число нельзя переносить в проект без схемы от подрядчика. Для приёмки важнее роли узлов и поведение системы при отказе.
| Часть системы | Что она делает | Что проверить при приёмке |
|---|---|---|
| Узлы кластера 1С | Распределяют сеансы и фоновые задания | После остановки одного узла новые сеансы обслуживает оставшийся |
| PostgreSQL и Patroni | Хранят базу и выбирают ведущий узел | После имитации сбоя назначается новый ведущий сервер |
| etcd | Согласует сведения о состоянии узлов | Patroni получает актуальное состояние кластера |
| HAProxy | Передаёт запросы на действующий узел PostgreSQL | Строка подключения 1С не меняется после переключения |
| Резервное копирование | Даёт отдельную точку возврата | Копия разворачивается в изолированной среде и открывается |
Из этой схемы следует главное: запуск всех служб подтверждает только запуск. Готовность к работе подтверждает испытание всей цепочки.
Виртуальные машины — начало переноса, а не его результат
В кейсе EFSOL работы шли в пять этапов. Сначала специалисты обследовали исходную систему и спроектировали архитектуру. Затем развернули Debian, настроили PostgreSQL с репликацией, собрали кластер 1С и провели испытания.
Порядок здесь важнее списка технологий. До обследования неизвестно, какие базы переносить, какие версии платформы поддерживает конфигурация и как пользователи подключаются к 1С. Без этих данных нельзя зафиксировать состав новой среды.
После обследования подрядчик поднимает серверы и устанавливает компоненты. Затем переносит копию базы, настраивает подключения и проверяет работу прикладных заданий. Только после этого можно имитировать отказ узла и давать нагрузку.
Кейс EFSOL прямо упоминает испытания с имитацией отказов и нагрузочную проверку перед запуском. Продолжительность этапов компания не публикует. Значит, кейс подтверждает состав работ, но не перенос за один день.
Обновление компонентов без остановки пользователей тоже требует распределённой схемы. В проекте EFSOL нагрузку между двумя серверами 1С разделили так, чтобы обслуживать один узел, пока второй продолжает работу. Одинокая виртуальная машина такого свойства не получает от самого факта размещения в облаке.
Если вам нужна такая схема, заранее изучите порядок настройки автоматического переключения узлов 1С. Он поможет проверить предложение подрядчика: где резервируется сервер приложений, где СУБД и какая точка подключения остаётся постоянной.
Что подрядчик может подготовить в первый день
Toolfox в обзоре EFSOL указывает срок один рабочий день для экспертной оценки задачи. Это сторонний каталог, а не опубликованный регламент EFSOL. Зафиксируйте содержание оценки в заявке или договоре.
Мы бы требовали от первого дня не обещание «всё готово», а набор документов и решений. Этот перечень — редакционный критерий приёмки, а не цитата из регламента EFSOL.
| Результат первого дня | Что должно быть записано | Зачем это заказчику |
|---|---|---|
| Состав переноса | Базы, расширения, внешние компоненты, фоновые задания | Ничего не потеряется между оценкой и работами |
| Схема инфраструктуры | Серверы приложений, СУБД, терминальный сервер, резервные узлы | Видно, что именно строит подрядчик |
| Способ доступа | RDP, RemoteApp, веб-клиент или VDI | Можно проверить рабочие места и канал связи |
| План переключения | Время остановки, ответственные, точка возврата | Понятно, когда отключат старую систему |
| План испытаний | Вход пользователей, фоновые задания, восстановление копии, отказ узла | Критерии запуска известны до начала работ |
| Граница ответственности | Кто переносит базу, настраивает лицензии, публикует доступ и проверяет копии | Работы не зависнут между несколькими исполнителями |
К концу первого дня у вас должна появиться проверяемая схема проекта. Если подрядчик успел также развернуть тестовую базу, это дополнительный результат, но ещё не основание отключать прежний сервер.
Официальная страница облачной инфраструктуры EFSOL перечисляет несколько способов доступа: Classic RDP, RemoteApp, тонкий клиент через веб-сервер и VDI. В состав среды могут входить сервер приложений, сервер баз данных и терминальный сервер.
Выбирать способ доступа следует до переноса. Для RDP и RemoteApp нужны терминальная среда и проверка клиентских устройств. Для веб-доступа потребуется публикация базы; порядок работ зависит от веб-сервера и версии платформы.
Если пользователи будут входить через браузер, пригодится инструкция по публикации базы на Apache. Она поможет отделить запуск серверов от готовности пользовательского доступа.
Когда рабочий день может закончиться готовой тестовой базой
Срок зависит не только от подрядчика. Его определяют состояние копии, совместимость компонентов, лицензии, канал передачи и требования к отказоустойчивости.
Перенос небольшой подготовленной базы в уже созданную среду и построение нового кластера — разные задачи. Во втором случае подрядчик сначала должен принять архитектурные решения, затем доказать их на испытаниях.
| Условие | Что проверяете до начала | Что блокирует запуск |
|---|---|---|
| Копия базы готова | Копия открывается отдельно от рабочей системы | Повреждение файла или ошибка восстановления |
| Версии совместимы | Конфигурация и внешние компоненты работают на выбранной платформе | Компонент не запускается в новой ОС или версии 1С |
| Лицензии доступны | Сервер 1С и клиенты получают лицензии в новой сети | Пользователь видит ошибку лицензирования |
| Канал подготовлен | Рабочие места подключаются выбранным способом | Недоступны порты, VPN, DNS или веб-публикация |
| Окно переключения согласовано | Назначены время остановки и ответственные | Пользователи меняют данные во время финального переноса |
| Копия восстановлена | Тестовая база запускается в отдельной среде | Бэкап существует, но не разворачивается |
| Отказ испытан | По очереди отключаются предусмотренные схемой узлы | После сбоя требуется ручная смена адресов |
| Возврат предусмотрен | Старая система сохранена до приёмки новой | После неудачного запуска некуда вернуться |
Если хотя бы одно обязательное условие не закрыто, обещание «за день» превращается в ожидание входных данных. Договор должен отделять задержку заказчика от незавершённых работ подрядчика.
Готовая копия особенно важна. Сам файл резервной копии ничего не доказывает, пока его не восстановили отдельно и не открыли базу. Для финального переключения потребуется ещё одна актуальная копия либо другой согласованный способ переноса изменений.
Не восстанавливайте её поверх рабочей базы. Разворачивайте проверочную копию в отдельном каталоге или на другой машине. Иначе испытание само создаст риск потери новых данных.
Небольшой контур не обязан повторять архитектуру кейса
Проект EFSOL отвечал на конкретные требования: пережить отказ рабочего сервера, переключать PostgreSQL автоматически и обслуживать компоненты без остановки пользователей. Ради этого в схеме появились два узла 1С и кластер СУБД.
Если вашей компании нужна тестовая база или рабочая среда с допустимым окном простоя, такая схема может оказаться избыточной. Решение принимают по допустимому простою и требуемой точке восстановления, а не по количеству серверов в чужом кейсе.
Для простой клиент-серверной установки сначала определите роли машин. Сервер 1С, СУБД и терминальные сеансы могут жить раздельно либо совместно — выбор зависит от нагрузки и требований к обслуживанию.
Если вы готовите среду своими силами, начните с порядка установки серверных компонентов 1С и СУБД. Эта инструкция закрывает базовую установку, но не заменяет проектирование резервных узлов.
У облачной схемы есть ещё одна граница. Резервирование внутри площадки не защищает от ошибочного удаления данных, неудачного обновления или повреждения самой базы. Для этого нужны отдельные копии и проверенное восстановление.
Как принять перенос, а не работающие окна администрирования
Не принимайте проект по скриншоту запущенных служб. Попросите подрядчика провести проверку при вас и записать результат в акт.
Сначала пользователь должен подключиться тем способом, который указан в договоре. Затем откройте основные базы, выполните вход под рабочими ролями и дождитесь выполнения обязательных фоновых заданий. Конкретные прикладные операции выбирает владелец базы: подрядчик не знает, какие процессы критичны для вашего учёта.
После этого восстановите резервную копию отдельно. Зафиксируйте, где она развёрнута, кто проверил базу и какую дату содержит копия. Наличие архива без такого испытания не закрывает риск восстановления.
Для отказоустойчивой схемы добавьте контролируемый сбой. Остановите ведущий узел тем способом, который записан в плане испытаний. Проверьте назначение нового ведущего сервера, подключение 1С через прежнюю точку входа и продолжение работы пользователей.
Кейс EFSOL сообщает об автоматическом переключении PostgreSQL через Patroni и HAProxy. Но он не публикует длительность переключения. Подрядчик должен согласовать допустимый перерыв именно для вашей системы и подтвердить его при испытании.
Обновление без остановки тоже проверяют действием. Один сервер 1С выводят из обслуживания, а второй принимает сеансы и задания. Затем узел возвращают и повторяют процедуру для его соседа.
Если схема зависит от версий платформы, СУБД, операционной системы и способа лицензирования, общей статьи для финального решения мало. После проверки исходных данных можно заказать разбор вашего серверного контура и получить перечень требований к договору.
Что должно остаться у вас после первого дня
Обещание «облачная 1С за один день» подтверждено, только если договор определяет результат этого дня. Формулировка должна отвечать на простой вопрос: сотрудники уже могут работать или подрядчик пока подготовил оценку?
Для первого дня оценки примите пять результатов:
- Согласован список баз, компонентов и пользователей.
- Нарисована схема серверов, доступа и резервирования.
- Названы зависимости по лицензиям, сети и версиям.
- Записан порядок переноса с точкой возврата.
- Согласованы испытания перед допуском пользователей.
Для готовой системы критерии жёстче: база развёрнута отдельно, пользователи входят выбранным способом, копия восстанавливается, а предусмотренный схемой сбой проходит испытание. Пока одного из этих результатов нет, у вас не готовая облачная 1С, а незавершённый перенос.