Доступность 99,9% оставляет около 525 минут простоя в год. Такой бюджет указан в описании открытого пакета 1C:SRE-Suite. Ошибка локали, закрытый порт и нерабочая копия расходуют его одинаково — остановкой пользователей.
Задача администратора не сводится к запуску кластера. Нужно принять контур так, чтобы обновления проходили предсказуемо, сбой находился по журналам, а резервная копия возвращала рабочую базу.
Ниже — 23 проверки в порядке зависимости. Не переходите к автоматизации выпуска, пока платформа не запускается вручную. Не считайте защиту готовой, пока не восстановили базу отдельно от рабочей.
Сначала добейтесь предсказуемого запуска 1С
1. Не переносите требования Windows на Linux
Платформа 1С работает на Linux штатно. Клиенты подключаются к ней тонким клиентом или через браузер, поэтому графический рабочий стол на сервере не нужен.
Linux также снимает расходы на серверную лицензию Windows. Это не довод в пользу миграции само по себе: команда должна уметь сопровождать выбранную ОС.
2. Создайте локаль ru_RU.UTF-8
Инструкция Hosting Russia по установке сервера 1С на Linux указывает русскую локаль среди обязательных условий запуска. Без неё служба сервера может завершиться с ошибкой ещё до подключения базы.
Проверьте локаль до установки платформы:
locale -a | grep -i ru_RUКоманда должна вернуть вариант ru_RU.utf8 или ru_RU.UTF-8. Если строк нет, создайте локаль средствами вашего дистрибутива, затем перезапустите службу 1С.
3. Установите шрифты до проверки печатных форм
Запущенная база ещё не доказывает готовность сервера. Без подходящих шрифтов буквы в счёте, накладной или отчёте превращаются в квадраты.
Эту ошибку легко пропустить при приёмке: администратор проверяет вход и проведение документа, но не формирует печатную форму. Добавьте печать одного рабочего документа в обязательную проверку.
4. Зафиксируйте системные настройки
Запишите локаль, часовой пояс, установленные шрифты и параметры службы в конфигурации сервера. После переустановки или переноса вы сможете воспроизвести окружение, а не восстанавливать его по памяти.
Фиксация настроек нужна до появления второго узла. Иначе два сервера под одной версией платформы могут различаться системными пакетами и поведением печатных форм.
Затем проверьте PostgreSQL, кластер и сеть
5. Не ставьте PostgreSQL из репозитория дистрибутива вслепую
Обычная сборка PostgreSQL из системного репозитория может не подойти платформе. Инструкция Hosting Russia требует адаптированную для 1С сборку от фирмы «1С» или Postgres Pro.
Совместимость проверяйте по версии платформы, СУБД и операционной системы. Само имя пакета postgresql ничего не говорит о нужных патчах.
6. Получайте пакеты из контролируемого места
Сборки PostgreSQL для 1С распространяются через портал релизов при действующем договоре поддержки. Сохраните адрес репозитория, версию пакета и дату установки в документации контура.
Не заменяйте пакет при обычном обновлении ОС без проверки совместимости. Обновление зависимостей не должно незаметно сменить сборку СУБД.
7. Проверьте создание тестовой базы
Неподходящая сборка PostgreSQL часто обнаруживается при создании базы. Не переносите рабочие данные, пока тестовая база не создаётся и не открывается на том же сервере.
Так вы отделите ошибку установки от проблем конкретной базы. Проверка займёт меньше времени, чем разбор неудачного переноса.
8. Выберите рабочий способ управления кластером
На Linux нет локальной графической консоли администрирования кластера. Управлять им можно утилитой rac либо консолью на Windows с установленным компонентом администрирования.
Для регулярных операций лучше освоить rac: команды проще включить в сценарии и журналировать. Состав процессов и команды управления описаны в практике работы с ragent, rmngr, rphost и rac.
9. Запускайте ras до обращения через rac
Утилита rac работает через службу RAS. Если ras не запущена или слушает другой адрес, команда управления не получит ответ даже при исправном кластере.
Проверяйте отдельно два состояния: работает ли кластер и отвечает ли административный интерфейс. Это разные точки отказа.
10. Откройте только нужные порты
По инструкции Hosting Russia клиентам 1С нужны TCP-порты 1540, 1541 и диапазон 1560–1591. Правила межсетевого экрана должны пропускать их из пользовательского сегмента, а не из любой сети.
После изменения правил подключитесь с обычного рабочего места. Проверка через localhost не показывает, что трафик проходит между сегментами.
11. Научитесь воспроизводить четыре базовые проверки
До настройки мониторинга администратор должен вручную отличать сбой службы от ошибки сети или административного интерфейса.
| Признак | Где смотреть | Что проверять дальше |
|---|---|---|
| Служба 1С не стартует | systemctl status, системный журнал | локаль ru_RU.UTF-8, права сервисной учётной записи, параметры запуска |
| Клиент не подключается | журнал клиента, firewall, маршрутизация | порты 1540, 1541 и 1560–1591, адрес кластера |
rac не отвечает | состояние RAS и порт административного интерфейса | запущена ли ras, совпадают ли адрес и порт команды |
| В печатной форме квадраты | состав шрифтов и журнал формирования формы | установлены ли шрифты, видит ли их процесс платформы |
Пока эти проверки не воспроизводятся вручную, автоматизировать выпуск рано: робот лишь быстрее повторит неизвестную ошибку.
Журналы должны приводить к следующему действию
12. Включите запись исключений
Файл config/logcfg.xml из 1C:SRE-Suite включает события EXCP технологического журнала. Они дают точку входа, когда пользователь сообщает лишь время ошибки и название операции.
Не включайте все события без срока хранения и ротации. Сначала определите, какие записи нужны для ответа на рабочие вопросы: где упал вызов, какой процесс участвовал и что происходило с СУБД.
13. Отделите обычные вызовы от подозрительно долгих
Пример конфигурации 1C:SRE-Suite записывает CALL и SCALL при длительности от 100 мс. Это параметр конкретного открытого решения, а не универсальный порог для любой базы.
Возьмите его как исходную настройку и сопоставьте с объёмом журнала. Если полезные события теряются в потоке, поднимите порог; если короткая задержка повторяется сотнями раз, снижайте осторожно.
14. Наблюдайте за PostgreSQL отдельно
В том же примере DBPOSTGRS настроен на поиск запросов длительностью более пяти секунд с дополнительным порогом 50 мс. Такая запись помогает связать задержку операции 1С с работой СУБД.
Метрики ОС, процессы 1С и PostgreSQL нужно смотреть по одной временной шкале. Подход к такой проверке показан в маршруте диагностики хоста, сеансов и PostgreSQL.
15. Автоматизируйте контроль rphost через штатный интерфейс
1C:SRE-Suite управляет рабочими процессами через RAS API. Для периодических проверок пакет использует службу admincluster-monitor@.service и таймер admincluster-monitor@.timer системы systemd.
Сценарий контроля должен оставлять запись о причине и выполненном действии. Перезапуск без журнала скрывает повторяющийся сбой и лишает администратора материала для разбора.
| Событие | Доказательство в журнале | Следующее действие |
|---|---|---|
| Исключение платформы | запись EXCP со временем и контекстом | найти связанную операцию и процесс |
| Долгий вызов | CALL или SCALL выше принятого порога | сопоставить с нагрузкой процесса и запросами СУБД |
| Долгий запрос PostgreSQL | событие DBPOSTGRS | проверить план, блокировки и состояние хранилища |
Перезапуск rphost | запись службы systemd и ответ RAS API | установить причину, а не ограничиваться перезапуском |
Журнал полезен, когда каждая запись ведёт к проверке. Набор файлов без маршрута разбора только занимает диск.
Выпуск должен повторяться без ручных догадок
16. Храните конфигурацию в формате, пригодном для Git
Бинарный файл .cf неудобен для просмотра изменений. Платформа поддерживает выгрузку конфигурации в XML, которую можно версионировать в Git.
В репозитории должны лежать исходные файлы, а не только собранный результат. Тогда ревью показывает, какие объекты изменились перед выпуском.
17. Свяжите хранилище конфигурации с Git
gitsync, созданный на базе OneScript, синхронизирует хранилище конфигурации 1С с репозиторием Git. Это полезно там, где разработчики ещё работают через хранилище, а выпуск уже строится вокруг коммитов.
Синхронизация не исправляет процесс сама. Назначьте владельца задания, храните журнал выполнения и проверяйте, что очередной коммит появился после изменения хранилища.
18. Используйте OneScript для служебных операций
OneScript выполняет сценарии на языке 1С вне платформы. Через него запускают вспомогательные инструменты, проверки и преобразования между этапами выпуска.
Не складывайте весь выпуск в один длинный сценарий. Разделите получение исходников, сборку, тесты и публикацию: тогда видно, на каком шаге произошёл отказ.
19. Проверяйте пользовательские сценарии через Vanessa Automation
Vanessa Automation запускает BDD-сценарии в формате Gherkin с конструкциями Given, When и Then. Они описывают действие пользователя и ожидаемый результат на естественном языке.
Берите для выпуска короткие сценарии, которые защищают основной рабочий путь. Полный регрессионный набор можно запускать отдельно, чтобы редкая проверка не задерживала каждую сборку.
20. Добавьте smoke-тесты после развёртывания
Smoke-тест — короткая проверка основных функций после публикации. Для контура 1С это может быть вход, открытие ключевого справочника, создание тестового документа и формирование печатной формы.
Проверка должна идти на отдельной среде до боевой публикации. Успешная сборка подтверждает только сборку; она не доказывает, что приложение запускается и выполняет рабочие операции.
21. Соберите пайплайн с явными условиями перехода
По руководству ITCodik для автоматизации 1С подходят GitLab CI, Jenkins, GitHub Actions и TeamCity. Выбирайте систему, которую команда уже сопровождает: название продукта меньше влияет на результат, чем разделение этапов.
| Этап выпуска | Инструмент | Условие перехода |
|---|---|---|
| Получение изменений | Git и gitsync | нужный коммит доступен, синхронизация завершилась без ошибки |
| Сборка | платформа 1С и сценарии OneScript | получен ожидаемый файл, команда вернула успешный код |
| Функциональная проверка | Vanessa Automation | обязательные BDD-сценарии завершились успешно |
| Проверка развёртывания | smoke-тесты | база открывается, основные операции выполняются |
| Публикация | GitLab CI, Jenkins, GitHub Actions или TeamCity | пройдены все предыдущие этапы |
| Уведомление | Telegram или Slack | сообщение содержит среду, версию и итог этапов |
Публикацию разрешают после сборки и проверок, а не после успешного завершения одного сценария.
Защита заканчивается отдельным восстановлением
22. Ограничьте учётные записи и сетевой доступ
Практическое руководство Serverzilla советует не выдавать сервисной учётной записи 1С права администратора домена. Каждый администратор должен работать под своим именем, с двухфакторной аутентификацией и аудитом действий.
Серверы платформы и СУБД разместите в отдельном VLAN. Межсетевой экран должен содержать явные правила, а удалённый доступ — проходить через VPN. Тогда украденный пароль одной рабочей станции не открывает весь серверный сегмент.
23. Постройте схему 3-2-1 и проведите пробное восстановление
Схема 3-2-1 хранит три копии данных на двух типах носителей, причём одну — вне основной площадки. Serverzilla отдельно рекомендует защищённую от изменения копию и ежеквартальную проверку восстановления на другом стенде.
Снимок виртуальной машины не заменяет такую копию: при потере или шифровании общего хранилища снимок исчезнет вместе с рабочей машиной. Порядок создания архивов, ротации и тестового развёртывания приведён в инструкции по копированию и контрольному восстановлению базы.
| Риск | Барьер | Доказательство работы |
|---|---|---|
| Кража пароля администратора | именная учётная запись и 2FA | журнал входов связывает действие с конкретным сотрудником |
| Проникновение из пользовательской сети | отдельный VLAN и firewall | правило пропускает только нужные адреса и порты |
| Шифрование рабочих файлов | неизменяемая копия вне основной площадки | база восстановлена на отдельном стенде |
| Ошибка при выпуске | сборка, BDD-сценарии и smoke-тесты | пайплайн остановил публикацию до боевой базы |
Установленный барьер ещё не доказывает защиту. Доказательством служит журнал проверки, заблокированная публикация или отдельно восстановленная база.
Порядок работ на ближайший цикл обслуживания
Начните с локали, шрифтов, сборки PostgreSQL, службы ras и сетевых портов. Зафиксируйте результат каждой проверки.
Затем включите исключения технологического журнала и контроль долгих операций. После этого соберите выпуск из XML-выгрузки, сборки, BDD-сценариев и smoke-тестов.
Последним этапом уберите общие административные учётные записи, отделите серверный VLAN и восстановите резервную копию на отдельном стенде. Архив без такой проверки ещё нельзя считать рабочим.
Правило приёмки короткое: следующий слой вводят после проверки предыдущего. Запущенная служба не доказывает готовность базы. Успешная сборка не доказывает готовность выпуска. Созданная копия не доказывает возможность восстановления.