К статье
Практический материал

Администрирование · 10 мин

Какая платформа 1С самая стабильная и как её выбрать

Разбираем, какая платформа 1С считается стабильной, как читать номера релизов, когда обновляться и как безопасно протестировать новую версию перед боевым запуском.

Вопрос «какая платформа 1С самая стабильная» возникает у каждого администратора перед обновлением. Однозначного ответа вида «ставьте релиз X» не существует: стабильность зависит от линейки платформы, номера сборки внутри неё, используемой конфигурации и режима работы базы. Однако есть понятные правила, которые позволяют выбрать версию с минимальным риском.

Платформа 1С:Предприятие развивается линейками: 8.3.20, 8.3.21, 8.3.22, 8.3.23, 8.3.24 и далее. Внутри каждой линейки выходят корректирующие релизы, исправляющие найденные ошибки. Практика показывает: первые сборки новой линейки чаще содержат регрессии, а к третьему–пятому корректирующему релизу платформа становится предсказуемой и надёжной.

Поэтому вместо поиска «идеальной версии» правильнее выстроить процесс: выбрать зрелую линейку, проверить совместимость с конфигурацией, протестировать на копии базы и только потом обновлять рабочую среду. Ниже разберём каждый шаг.

Как устроена нумерация релизов платформы 1С

Номер версии платформы состоит из четырёх частей, например 8.3.24.1467. Первые две цифры (8.3) — поколение платформы. Третья цифра (24) — номер линейки, то есть крупного функционального обновления. Четвёртое число — номер сборки внутри линейки: чем оно больше, тем больше исправлений вошло в релиз.

Ключевой вывод из этой схемы: линейка с высоким номером сборки обычно стабильнее свежей линейки с низким номером. Например, условный релиз 8.3.22.2000 прошёл больше исправлений, чем 8.3.24.1100, хотя вторая линейка новее по функциональности.

Также учитывайте, что 1С периодически прекращает поддержку старых линеек: для них перестают выходить исправления. Работать на линейке, снятой с поддержки, рискованно — найденные ошибки и уязвимости останутся без патчей.

Какие линейки чаще выбирают для рабочих баз

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

Для файловых баз небольших компаний требования мягче — там критичнее совместимость с конфигурацией. Для клиент-серверных баз с десятками одновременных пользователей зрелость платформы важнее: ошибки в кластере серверов или в работе с СУБД проявляются именно под нагрузкой.

Подходы к выбору версии

Свежая линейка, первая сборка

Даёт новые функции, но выше риск регрессий. Подходит только для тестовых баз.

Зрелая линейка, 3–5 корректирующий релиз

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

Старая линейка без обновлений

Работает привычно, но не получает исправлений безопасности и может конфликтовать с новыми версиями конфигураций.

Важно понимать: «стабильность» конфигурации и платформы связаны. Типовые конфигурации (1С:Бухгалтерия, ERP, ЗУП) тестируются вендором на конкретных версиях платформы, и в требованиях к обновлению конфигурации часто указана минимальная версия платформы. Игнорировать это требование нельзя.

Как проверить совместимость платформы с конфигурацией

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

Для самописных и доработанных конфигураций проверку придётся выполнять самостоятельно. Основные зоны риска при смене линейки платформы: изменения в поведении СКД, работе веб-клиента, фоновых заданиях, механизмах интеграции (HTTP-сервисы, веб-сервисы) и в режиме совместимости.

Порядок проверки новой платформы
  1. 1
    Узнайте требуемую версию платформы в описании вашей конфигурации
  2. 2
    Выберите зрелый релиз линейки, удовлетворяющий этому требованию
  3. 3
    Сделайте полную резервную копию рабочей базы
  4. 4
    Разверните копию базы на тестовом сервере или отдельном компьютере
  5. 5
    Установите новую платформу и запустите тестирование и исправление информационной базы
  6. 6
    Прогоните ключевые сценарии: проведение документов, формирование отчётов, обмены данными
  7. 7
    Проверьте работу под реальной нагрузкой, если база клиент-серверная
  8. 8
    Только после успешной проверки планируйте обновление рабочей базы

Режим совместимости: скрытый фактор стабильности

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

Проверить режим можно в конфигураторе: свойства корня конфигурации, пункт «Режим совместимости». Если конфигурация типовая, менять этот параметр самостоятельно не стоит — поставщик рассчитывает код под конкретное значение. Для собственных разработок смену режима проводите осознанно, с полным тестированием.

Типичные ошибки при выборе и обновлении платформы

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

Типичные ошибки
01
Обновление без резервной копии — при сбое базу не откатить, данные можно потерять
02
Установка платформы без проверки требований конфигурации — конфигурация не запускается или работает с ошибками
03
Разные версии платформы на сервере и клиентах в клиент-серверном режиме — пользователи не могут подключиться
04
Обновление платформы и конфигурации одновременно — невозможно локализовать причину проблем
05
Игнорирование технологического журнала — ошибки кластера остаются незамеченными до жалоб пользователей

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

Как проверить, что новая версия работает стабильно

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

Контрольные точки

Как проверить результат

Запуск базы и авторизация пользователей
Норма

Все пользователи входят без ошибок версии

Тревожный признак

Сообщение о несовпадении версий платформы

Проведение документов и отчёты
Норма

Документы проводятся, суммы в отчётах совпадают с контрольными

Тревожный признак

Ошибки проведения, расхождения итогов

Рабочие процессы сервера
Норма

Процессы rphost работают без аварийных перезапусков

Тревожный признак

Рост памяти, падения процессов в технологическом журнале

Фоновые и регламентные задания
Норма

Задания выполняются по расписанию без ошибок

Тревожный признак

Задания зависают или завершаются с ошибкой

Контрольные точки фиксируйте до обновления: снимите показания ключевых отчётов (оборотно-сальдовая ведомость, взаиморасчёты, остатки склада) на тестовой копии под старой платформой и сравните с результатами под новой. Совпадение итогов — главный признак того, что обновление не повредило данные.

Когда обновляться обязательно, а когда можно подождать

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

Маршрут решения

Как выбрать действие

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

Держите под рукой дистрибутив предыдущей рабочей версии платформы. Откат платформы на файловой базе — это установка старого релиза и восстановление копии базы; на клиент-серверной — переустановка сервера. Без сохранённого дистрибутива и свежей резервной копии откат превращается в проблему.

Итог

Что важно запомнить

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

Частые вопросы о стабильных версиях 1С

Есть ли официальный список стабильных версий платформы 1С?

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

Можно ли работать на старой платформе, если всё функционирует?

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

Чем отличается стабильность файловой и клиент-серверной базы на одной платформе?

На одной и той же платформе файловая база обычно ведёт себя предсказуемее, потому что в ней нет кластера серверов и взаимодействия с СУБД. В клиент-серверном варианте добавляются факторы: версия СУБД, настройки кластера, нагрузка — поэтому тестирование там должно быть тщательнее.

Как откатиться на предыдущую версию платформы?

Установите предыдущий релиз платформы и восстановите базу из резервной копии, сделанной до обновления. Если копии нет, а база уже была открыта и изменена на новой платформе, откат может быть невозможен без потери данных — поэтому резервная копия перед обновлением обязательна.

Нужно ли обновлять платформу на всех компьютерах одновременно?

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