← На главную

В практике системного администрирования и сопровождения программных продуктов «1С:Предприятие» нередко возникают ситуации, когда логика выхода обновлений кажется неочевидной. Например, после публикации инновационной ветки 8.3.13 разработчики внезапно выпускают обновление для предыдущей ветки 8.3.12. В этой статье мы подробно разберем, почему это происходит, как ориентироваться в таблице релизов и что делать, если работа системы прерывается критическими ошибками сетевого протокола.

Анализируем стратегию выпуска релизов: LTS и инновационные ветки

Для начала проанализируем ситуацию, когда версия 8.3.12.1714 появляется в разделе тестовых версий позже, чем 8.3.13.1549. Это не означает, что разработка новой ветки прекращена. Рассмотрим основные причины такого поведения вендора:

1. Концепция Long Term Support (LTS): В экосистеме 1С четные ветки (например, 8.3.12, 8.3.14) часто становятся де-факто стабильными версиями с длительной поддержкой. В то время как нечетные ветки (8.3.13) внедряют новые механизмы, которые могут содержать «детские болезни».
2. Исправление критических уязвимостей: Если в ядре платформы обнаруживается серьезная ошибка безопасности, 1С выпускает исправление для всех поддерживаемых веток одновременно. Пользователи, которые не готовы переходить на 8.3.13 из-за несовместимости оборудования или конфигураций, получают патч в рамках привычной им 8.3.12.
3. Поддержка прикладных решений: Некоторые конфигурации (например, специализированные отраслевые решения или старые версии ЗУП) могут иметь жесткую привязку к функционалу конкретной ветки платформы.

Разберем по шагам, как интерпретировать данные на портале 1С. Часто пользователи путаются из-за того, что сайт выводит в топ версию с наибольшим номером сборки, а не самую стабильную. Важно понимать, что статус «Ознакомительная» или «Тестовая» для новой сборки в старой ветке (8.3.12) — это сигнал о подготовке стабильного фикса для консервативных пользователей.

Проблема стабильности 13-й ветки и ошибка POST-запроса

Многие администраторы столкнулись с тем, что при переходе на первые релизы 8.3.13 (например, 8.3.13.1513) система начинала вести себя нестабильно. Одной из самых неприятных проблем стала ошибка:

«Ошибка при выполнении запроса POST к ресурсу /e1cib/misc»

Выясним причину этого сбоя. Данная ошибка обычно возникает при работе через веб-сервер (IIS или Apache) в тонком или веб-клиенте. Проанализируем технические аспекты:

• Проблема связана с некорректной обработкой HTTP-сессий внутри процесса rphost.
• При определенных условиях (длительный простой сессии или специфические действия пользователя с динамическими списками) платформа разрывает соединение, но клиент пытается отправить данные по старому контексту.
• В ветке 8.3.13 на ранних этапах были замечены утечки памяти, которые приводили к деградации производительности сервера приложений и, как следствие, к падению сетевых запросов.

Варианты решения проблемы и выбор стабильной версии

Если вы столкнулись с нестабильностью на 13-й ветке, рассмотрим алгоритм действий для восстановления работоспособности системы.

Вариант 1: Откат на стабильную ветку 8.3.12

Как показывает практика, ветка 8.3.12 является гораздо более предсказуемой. Если ваша конфигурация требует версию не ниже 8.3.12.1529, оптимальным решением будет установка последней доступной сборки из этой же ветки (например, 8.3.12.1714). Рассмотрим, как это сделать правильно:

1. Выполните полную резервную копию информационной базы.
2. Деинсталлируйте текущую версию платформы 8.3.13 с сервера и клиентских рабочих станций.
3. Установите выбранную сборку 8.3.12.
4. Обязательно очистите кэш конфигурации на сервере и у пользователей, так как структуры кэша между 12-й и 13-й ветками могут конфликтовать, вызывая дополнительные ошибки.

Вариант 2: Обновление до исправленных релизов 8.3.13

Если функционал вашей конфигурации (например, использование новых возможностей расширений или интеграций) требует именно 13-ю ветку, не стоит использовать релизы ниже 8.3.13.1576. Разберем, что изменилось в более поздних сборках:

В новых версиях (таких как 8.3.13.1576 и последующих) разработчики внесли правки в механизмы взаимодействия с веб-сервером. Посмотрим на пример типичного исправления в журнале ошибок платформы: «Исправлена ошибка взаимодействия с веб-сервером при передаче больших пакетов данных». Именно это исправление зачастую устраняет проблему с /e1cib/misc.

Практические советы по выбору версии платформы

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

Во-первых, всегда изучайте раздел «Информация об исправленных ошибках» (bugboard). Если вы видите, что в текущем релизе числится критическая ошибка с тегом rphost или сетевой протокол, воздержитесь от обновления.

Во-вторых, используйте тестовый сервер. Посмотрим, как организовать процесс: установите новую платформу на отдельный сервер с копией базы, запустите автоматизированные тесты или попросите ключевых пользователей выполнить типовые операции (проведение документов, формирование тяжелых отчетов). Если в течение 2-3 дней ошибок типа POST /e1cib/misc не возникло, платформу можно тиражировать на рабочую среду.

В-третьих, обратите внимание на требования конфигурации. Если в требованиях указано «не ниже 8.3.12.1529», это означает, что минимальный функционал гарантирован именно на этой версии. Переход на 8.3.13 в таком случае является вашим добровольным шагом в сторону инноваций, который не всегда оправдан в промышленной эксплуатации.

Заключение

Появление «старых» веток в списке тестовых — это нормальный процесс поддержки стабильных решений. Не стоит гнаться за самым высоким номером версии, если ваша текущая инфраструктура требует стабильности. Для большинства корпоративных систем на базе 1С:Предприятие 8.3 лучшим выбором остается использование проверенных LTS-веток (8.3.12) до момента, пока следующая четная ветка (например, 8.3.14) не пройдет стадию обкатки и не получит несколько сервисных релизов.