Обмен встал ночью, а узнали в обед: как перестать узнавать о сбоях 1С от своих сотрудников

5 августа 2026 · 10 минут · Радик Шафеев, архитектор поддержки 1С

Самые дорогие сбои в 1С — тихие. Программа работает, ошибок никто не видит, а данные между базами уже сутки не ходят. К моменту, когда кладовщик скажет «у меня остатки не те», компания успевает отгрузить не то, посчитать не так и провести документы, которые придётся переделывать. Рассказываем, как устроен проактивный контроль состояния баз: что он ловит, чего принципиально не может и почему счётчик ошибок в журнале регистрации вам не поможет.

Сбой начинается ночью, а замечают его в обед

Типичный путь. Ночью встал обмен между базами: транспорт не прошёл, узел недоступен или сообщение обмена оказалось битым. Утром данные не приехали, но этого никто не заметил — ошибка не выскакивает, программа работает как обычно. К обеду кассир не видит остатков, бухгалтер не может провести документ. Начинаются звонки, и только тогда включается диагностика — по следам, когда контекст сбоя уже затёрт.

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

Проактивный контур переворачивает последовательность: сигнал о том, что обмен не продвинулся, приходит инженеру в пределах часа после сбоя. Обычно этого достаточно, чтобы починить раньше, чем кто-то в компании столкнётся с последствиями.

«У нас есть журнал ошибок — посмотрим, если что»

Журнал регистрации есть у всех, и именно поэтому он не спасает. У живой базы всегда есть фон ошибок: несколько десятков в час при более-менее стабильном наборе типов. Что-то ругается на права, что-то на не заполненный реквизит, что-то на внешний сервис. Люди к этому привыкают и перестают открывать журнал вообще.

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

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

Восемь мест, где 1С ломается тихо

Список собран не из теории, а из разбора реальных инцидентов на боевых базах разных конфигураций. Под каждым пунктом — случай из практики; всё обезличено, без названий компаний, баз и имён.

1. Обмен данными

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

2. Доработки, которые не применились

Расширение установлено, но платформа его не применила. Интерфейс выглядит обычным, кнопка на месте, функция просто не работает. Такая ошибка пишется уровнем «предупреждение» — пользователи её не видят вообще. В одном случае доработка не работала трое суток, и всё это время люди были уверены, что она считает.

3. Регламентные задания

Закрытие месяца, расчёты, выгрузки на сайт, интеграции с маркетплейсами: упало, зависло или перестало запускаться. Мы отдельно различаем «упало» и «не стартует»: второе тише и опаснее, потому что нет даже сообщения об ошибке — просто ничего не произошло.

4. Проведение документов

Ошибки проведения, битые ссылки в справочниках, отрицательные остатки, поломанная аналитика учёта. Эти вещи копятся незаметно и всплывают в конце месяца — ровно тогда, когда закрывать период уже некогда.

5. Блокировки и «тормозит»

Кто кого блокирует, какие операции стоят в очереди, сколько длится проведение документа сегодня по сравнению с прошлой неделей. Прямое наблюдение на одной базе показало: из 60 конфликтов блокировок за два часа 45 приходились на регламентные задания интеграции, а не на людей. Разговор о «тормозах» после такой цифры идёт совсем иначе — и решение оказывается другим.

6. Склад и маркировка

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

7. Интеграции и токены

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

8. Сервер

Свободное место на дисках, рост журналов СУБД, накопление брошенных сеансов, состояние резервных копий. Накопление незавершённых сеансов однажды довело сервер до отказа сервиса метаданных — при этом до последнего момента «всё работало».

Что приходит вместо тишины

Контур не требует смотреть в панели и разбираться в терминах. Всё сводится к трём вещам: сигнал, регулярная сводка и накопленная динамика. Сигнал приходит инженеру сразу, вам — по договорённости, и выглядит он примерно так:

Здесь важна не форма, а то, что диагностика начинается не с расспросов «а когда это началось и что вы делали», а с готового контекста: что, где, с какого времени и что при этом было нормой. Инженер садится чинить, а не восстанавливать картину.

Второй элемент — спокойная сводка по расписанию, включая «всё в норме». Это не формальность: тишина в канале не должна быть двусмысленной. Если сообщений нет, вы должны понимать, что система в порядке, а не что мониторинг отвалился.

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

Первый вопрос руководителя: а он ничего не сломает?

Правильный вопрос, и отвечаем на него по пунктам.

Контур работает только на чтение. Запись, удаление и изменение данных заблокированы на уровне инструмента — это техническое ограничение, а не обещание в договоре.

Закрытые периоды не трогаются. Они не открываются, дата запрета не меняется — отдельный жёсткий запрет в наших правилах работы.

Нагрузка — один короткий запрос по расписанию. Подробный сбор включается только на время разбора конкретной проблемы, с лимитом объёма и отключением одной операцией.

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

Доступ к серверу желателен, но не обязателен: если внутрь периметра не пускают, контур работает снаружи с меньшим набором сигналов. Такой вариант тоже рабочий.

Неделя на внедрение и полчаса вашего времени

Порядок один и тот же независимо от того, четыре у вас базы или сорок.

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

День второй — подключение и базовая линия. Ставим контур, снимаем «норму» базы. Первые сутки он молчит специально.

Три-пять дней — настройка порогов. Вычитаем плановые окна: ночные регламентные работы, суточные обмены, обслуживание. Цель — чтобы каждое сообщение требовало реакции.

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

От вас нужно немного: технологический доступ к базам на чтение, канал для сообщений (мессенджер или почта) и полчаса на разговор об инвентаре сбоев — что болело за последние месяцы. Этот разговор, к слову, самая полезная часть внедрения.

Чего мониторинг не делает

Чтобы ожидания совпали с результатом, назовём и обратную сторону.

Он не устраняет причину. Контур находит и показывает — исправление остаётся работой инженера, отдельной по каждому случаю.

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

Он не ловит то, что не оставляет следа. Ошибку в самих данных, введённую человеком без всякого сообщения об ошибке, автоматика не увидит: для этого нужны отдельные сверки.

Первая неделя шумит. Пороги калибруются на живой базе — это нормальная часть внедрения, а не сбой.

Что меняется по сути

Если свести всё к пяти строчкам, разница выглядит так.

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

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

Частые вопросы

С чего начать

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

Если состояние баз в целом понятное, а болит именно непредсказуемость обменов и интеграций — смотрите страницу продукта: AI Мониторинг баз 1С. Там подробно про восемь классов сбоев, безопасность и порядок внедрения. Серверная часть разобрана отдельно — AI Мониторинг сервера 1С.