Разбор от сообщества: 1с не работает сегодня

4 октября 2026 · infolimp.ru

Контекст и ситуация: почему «1С не работает» — это всегда про три слоя

Запрос «1с не работает сегодня» в Яндексе возникает волнами: утром в понедельник, в начале квартала или после обновления релиза. Но почти никогда это не значит, что «упал» сам сервер 1С. Специалист с опытом более 5 лет знает: платформа редко отказывает целиком. Чаще всего проблема локализуется в одном из трёх слоёв:

• Сетевая инфраструктура — потери пакетов, MTU, медленные DNS, неверные настройки прокси для внешних сервисов.
• СУБД — блокировки, разрастание журнала транзакций, проблемы с индексами.
• Клиентские лицензии — исчерпание количества подключений, конфликт с обновлением ключей защиты.

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

Типичные ошибки при «массовом сбое»: как мы неверно интерпретируем симптомы

Когда пользователи жалуются, что «все пропало», первое, что делает администратор — проверяет службы и перезагружает сервер. Это часто лечит симптомы, но не причину. Классическая картина: в 9:00 начинается интенсивная работа, в 10:30 появляются ошибки «Превышено время ожидания» или «Не удалось заблокировать транзакцию». К полудню система «висит». А причина — не в сервере, а в том, что несколько фоновых заданий одновременно пытаются обновить одни и те же данные, создавая взаимные блокировки.

Вот нетривиальный момент: сама платформа не всегда пишет в журнал регистрации причину блокировки. Она лишь фиксирует факт ожидания. Увидеть её можно только через технологический журнал (ТЖ) на уровне сервера 1С или через средства мониторинга СУБД.

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

Механика под капотом: что происходит при «горячей» блокировке

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

Технологический журнал как единственный источник объективной информации

Многие администраторы не включают ТЖ, считая его «лишней нагрузкой». Зря. Именно ТЖ позволяет увидеть реальную картину: какие вызовы выполняются дольше всего, сколько времени ожидаются блокировки, какие контексты их порождают. Для настройки ТЖ на сервере 1С необходимо отредактировать файл logcfg.xml в каталоге сервера. Минимальный конфиг для охвата проблем производительности выглядит так:

<config xmlns="http://v8.1c.ru/v8/tech-log">
    <log location="D:\Logs\1C" history="10">
        <event>EXCP</event>
        <event>DBLOCK</event>
        <event>SDBL</event>
    </log>
    <property name="all">true</property>
</config>

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

2026-04-10 10:30:12.123- 1C:Enterprise 8.3 (Managed) - DBLOCK: duration=1543221, wait=1543221, block=Table: _Reference13 (Count=10)
    SessionID=12345, User=Иванов, Computer=PC-1, AppID=BackgroundJob
    Text=Удаление движений по документу "ПриходнаяНакладная" 

Из этого фрагмента видно: фоновая задача держит блокировку на таблицу справочника №13 более 1,5 секунд, и никакой дочерний процесс не может продолжиться. Теперь можно найти, какая именно обработка запущена и почему она так долго выполняет Записать().

Неочевидная ловушка: настройки таймаутов при обращении к внешним ресурсам

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

// Корректное создание HTTP-соединения с таймаутом 10 секунд
Соединение = Новый HTTPСоединение("api.example.com", 443, , , , 10, Новый ЗащищенноеСоединениеOpenSSL());

// Отправка запроса с проверкой результата
Запрос = Новый HTTPЗапрос("/getData");
Попытка
    Ответ = Соединение.Получить(Запрос);
Исключение
    ЗаписьЖурналаРегистрации("Ошибка HTTP", УровеньЖурналаРегистрации.Ошибка, , ,
        "Таймаут или ошибка соединения: " + КраткоеПредставлениеОшибки(ИнформацияОбОшибке()));
    // Корректная обработка ошибки, не даем сеансу "висеть"
КонецПопытки;

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

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

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

Что делать прямо сейчас (5 шагов)

1. Определите масштаб: только часть пользователей или все? Если часть — общий сетевой канал или отдельный сегмент, проверьте доступность сервера по ping и по портам TCP 1540 (для клиент-серверного варианта).
2. Проверьте мониторинг СУБД: количество активных блокировок, время ожидания, размер журнала транзакций. Обычная команда для PostgreSQL: SELECT * FROM pg_stat_activity where state = 'active';
3. Проанализируйте ТЖ за последние 30 минут: откройте файлы, ищите события DBLOCK и TTIMEOUT.
4. Проверьте лицензии: если у вас сервер 1С с программными лицензиями, посмотрите rphost_* процессы — не исчерпан ли пул лицензий. Ошибка «Недостаточно лицензий» часто маскируется как «Соединение прервано».
5. Какие фоновые задания запущены? Зайдите в консоль кластера и посмотрите, нет ли «вечных» задач с высокой длительностью.

Типичные ошибки при диагностике

• Перезагрузка сервера без снятия ТЖ — вы теряете доказательства причины.
• Игнорирование конфигурации СУБД: часто проблема в настройках пула соединений, а не в 1С.
• Настройка таймаутов HTTP на клиенте, когда нужно на сервере — различайте места вызова (клиентский тонкий клиент или серверный фоновый).
• Проверка только системного журнала Windows — там платформа пишет редко, основная информация в ТЖ.

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

Заключение: как предотвратить «завтрашний сбой»

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

• Включите ТЖ в продуктивном контуре с ротацией файлов (например, 4-5 дней) — это снимает нагрузку на диск.
• Установите таймауты на все внешние HTTP-вызовы — проверьте фоновые задания, которые обращаются к веб-сервисам.
• Мониторьте блокировки в СУБД в реальном времени, настройте алерты на длительные транзакции.
• Проводите регулярное тестирование пиковой нагрузки (например, имитация входа 50 пользователей) — можно использовать простой скрипт, генерирующий запросы через COM-объект, но лучше через штатные средства.

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