В прошлом году один из самых дорогих сбоев, который я видел, начался с фразы: «обновим 1С на выходных, там работы на пару часов». Сам релиз занял вечер, а потом еще 4 дня команда вручную разбирала заказы: обмен с сайтом начал передавать статусы через раз, резервы разъехались, склад жил в двух версиях реальности.
Проблема обычно не в 1С. Она в накопленных доработках, старых обменах и привычке проверять только одно: «документы же проводятся». Ниже - короткая схема, по которой мы оцениваем, когда обновление еще можно провести спокойно, а когда это уже отдельный проект с риском для продаж и учета.
Пока база открывается, бизнесу кажется, что все под контролем
Фраза «все работает» в 1С почти всегда означает только одно: пользователь может зайти и провести документ. Для бизнеса этого недостаточно. Я видел базы, где интерфейс был живой, но регламентные задания уже падали, обмен по CommerceML терял часть реквизитов, а закрытие месяца шло с ручными правками.
Мы всегда разделяем два слоя: платформа 1С:Предприятие 8.3 и конфигурация - 1С УТ, 1С КА, производство, 1С:Фреш. В прошлом году у клиента платформа уже была обновлена до 8.3.24, а конфигурация 1С УТ оставалась старой. Внешне все выглядело терпимо, но маркетплейс поменял формат обмена, и заказы начали приезжать частично.
Вот как это выглядит в цифрах.
| Сценарий | До обновления | После нормального релиза |
|---|---|---|
| Заказы с сайта | 18-22 ручных правки в день | 0 критичных сбоев в обмене |
| Закрытие месяца | задержка 1-2 дня | по графику |
| Работа склада | сверка резервов вручную | контроль по сценариям |
Плановая работа на 2-3 недели почти всегда дешевле, чем аварийный режим с ночными правками и простоями в отгрузке. По деньгам разница обычно выглядит так: вместо понятного бюджета 120-250 тыс. ₽ компания получает ручные операции, срочные доработки и потери в пиковый день.
Ломается не новая версия, а старые связи вокруг нее
Если у базы больше 5 интеграций - сайт, CRM, WMS, банк, кассы, ЭДО, маркировка, - обновление уже нельзя считать задачей администратора «на вечер». Это мини-проект. Основной риск сидит в расширениях, внешних обработках, печатных формах, ролях и старых правилах обмена, которые когда-то сделали «временно», а потом оставили на годы.
У нас был проект на 1С КА для оптовой компании. Само обновление заняло 4 часа. Восстановление обмена с CRM - еще 5 рабочих дней, потому что логика преобразования статусов жила во внешней обработке без описания. Пока ее не трогали, все выглядело нормально.
Мы и сами однажды ошиблись на похожем релизе и недооценили фоновые задания. База открылась, документы проводились, но склад встал утром из-за тихой ошибки в фоне. С тех пор сначала делаем карту зависимостей, а уже потом обновляем.
Что проверяем в первую очередь:
- расширения и конфликт объектов после обновления
- внешние обработки и печатные формы
- обмены с сайтом, CRM и маркетплейсами
- ЭДО, маркировку, кассы, права и фоновые задания
Чем дольше компания не обновляет 1С, тем меньше это похоже на администрирование и тем больше - на аудит всей учетной схемы.
УТ, КА, Фреш и производство дают разный риск
С 1С:Фреш и 1С облаком есть опасная иллюзия: инфраструктура на стороне сервиса, значит обновление почти безопасно. На практике сервис обновит платформу, но не проверит ваши роли, расширения и пользовательские сценарии. Мы проходили это на проекте, где после штатного релиза руководители на день потеряли нужные отчеты из-за конфликта прав в расширении.
В 1С УТ самые чувствительные точки понятны: цены, скидки, остатки, резервы, обмен с сайтом. Если здесь возникает ошибка, бизнес видит ее сразу - по отменам заказов, лишним обещаниям клиентам и ручной сверке склада. У клиента на связке Bitrix + 1С УТ 11 такая ошибка дала 11% отмен за 2 дня.
В 1С КА и в производственном контуре проблема часто всплывает позже. Заказ уже отгружен, а ошибка становится заметна в конце месяца, когда искажается себестоимость или распределение затрат. На одном проекте мы отдельно гоняли закрытие месяца на копии базы объемом 280 ГБ, потому что баг проявлялся только на полном цикле.
Безопасный релиз выглядит скучно. В этом его польза
Рабочая схема почти всегда одна и та же: копия базы, тестовый стенд, обновление, проверка доработок, короткий smoke test, окно релиза и план отката. Героизма здесь нет, но именно такая дисциплина обычно и экономит деньги.
Хороший smoke test из 10-15 операций у нас ловил до 80% критичных проблем еще до выхода в рабочую базу. Проверять нужно путь бизнеса: заказ, поступление, реализацию, возврат, печать УПД, обмены, права, закрытие месяца.
Когда обновление уже нельзя откладывать?
Если обмены идут с ручными правками, если релиз никто не может оценить без одного конкретного специалиста, если нет тестового стенда, а закрытие месяца зависит от ручной корректировки, тянуть уже опасно. В такой точке компания платит не за развитие системы, а за ее выживание.
1. Снять резервную копию
2. Развернуть тестовую копию базы
3. Обновить платформу и конфигурацию
4. Проверить расширения и внешние обработки
5. Прогнать 10-15 ключевых сценариев
6. Провести релиз с планом отката
7. Смотреть журнал регистрации 7-14 дней
Иногда дешевле не лечить старую схему, а пересобрать контур
Не каждую старую базу стоит тянуть до актуальной версии любой ценой. Если доработки не документированы, логика разбросана по внешним обработкам, а каждый релиз держится на одном человеке, система уже стала операционным риском.
В таких случаях мы чаще убираем лишнюю кастомизацию, выносим обмены в отдельный интеграционный слой и только потом обновляем ядро. На старте это стоит дороже, но потом релизы перестают быть событием с риском остановить продажи.
В ближайшие 6-12 месяцев обновления 1С станут сложнее не из-за самой платформы, а из-за числа внешних связей вокруг нее: маркетплейсы, ЭДО, маркировка, облачные сервисы, внутренние кабинеты. Если хотите быстро понять свой реальный риск, посчитайте не версии 1С, а сколько ручных действий появится у команды утром в понедельник после поломки одного обмена.
