Почему промышленное ПО падает ночью

В 7:00 склад не открывается, в 7:05 звонят вам — а ночью «всё работало». На промышленных объектах ночной простой редко бывает случайностью: это накопленные логи, плановый обмен, бэкап и отсутствие дежурного, который понимает цепочку диск → PostgreSQL → Docker → WMS.

Короткий ответ

Промышленное ПО падает ночью, когда фоновые процессы (обмен 1С, выгрузка отчётов, ротация без настройки) заполняют диск или очереди Redis, PostgreSQL уходит в read-only, Docker-контейнер зависает, Nginx отдаёт 502. Контролировать это можно мониторингом порогов, ротацией логов и runbook-сценариями — в том числе через модуль AI Support Agent, который не заменяет инженера и не выполняет произвольные команды.

Кому полезна статья

Начальникам склада и производства, которые получают звонки «система не работает» в начале смены. Системным администраторам и интеграторам 1С на объектах с WMS, SCADA и маркировкой. Владельцам бизнеса, которые хотят понять, зачем платить за отдельный модуль диагностики.

Какая проблема возникает

Днём операторы видят ошибки сразу: ТСД не сканирует, линия встаёт, принтер молчит. Ночью никто не смотрит дашборды. Типичная цепочка:

1. Плановый обмен 1С выгружает большой XML/JSON в каталог интеграции.
2. Лог integration.log пишется в тот же раздел, что и данные WMS.
3. Диск заполняется до 95% — система ещё «жива», но медленная.
4. В 4:00 PostgreSQL не может создать WAL — режим read-only.
5. В 6:30 контейнер backend уходит в restart loop.
6. В 7:15 кладовщик видит белый экран на ТСД.

Параллельно может страдать маркировка: буфер КМ в той же базе, обмен с ГИС МТ в очереди. Это не ошибка DataMatrix — это инфраструктура. Коды проверяют через разбор структуры КМ, а не перезагрузкой сервера.

Пример реальной ошибки

Производство напитков, SCADA + MES + сервер маркировки на одной VM. Ночью cron запускает отчёт по смене за неделю — тяжёлый SQL к PostgreSQL. Одновременно Docker пишет json-log без лимита размера. К 3:00 диск 98%. PostgreSQL: could not extend file. MES перестаёт записывать факт выпуска. Линия физически работает, но учёт остановлен.

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

Пять частых ночных триггеров

1. Логи без ротации

Интеграция с 1С, трассировка HTTP, debug в production — всё в один файл. Рекомендации по логированию контейнеров описаны в документации Docker. На объекте часто никто не настраивает max-size и max-file.

2. PostgreSQL и полный диск

При нехватке места СУБД переходит в режим, где нельзя писать. Это описано в документации PostgreSQL. WMS, SCADA и буфер маркировки одновременно перестают сохранять транзакции.

3. Redis и очереди ТСД

Задания на отбор, подтверждения сканирования, статусы КМ — в очередях. Переполнение памяти Redis или eviction политики без контроля даёт «тихие» потери сообщений к утру.

4. Docker restart loop

Контейнер падает, Docker перезапускает, снова падает — в логе тысячи строк за час. Без мониторинга restart count дежурный узнаёт только утром.

5. Nginx 502 как симптом

Часто это не «сломался Nginx», а мёртвый upstream. Проверка должна идти цепочкой: Nginx → backend → БД → диск.

Что делать без магии «ИИ всё починит»

Шаг	Действие	Ошибка
1	Алерт при 80–85% диска	ждать 100%
2	Ротация и архив логов по политике	удалять всё подряд
3	Лимиты логов Docker	безлимитный json-file
4	Runbook с подтверждением	произвольные команды ночью
5	Отчёт после инцидента	«перезагрузили и забыли»

Модуль AI Support Agent автоматизирует только пункты из согласованного runbook — например, архив логов старше 14 дней в отдельный том, перезапуск конкретного контейнера после проверки PostgreSQL, уведомление в Telegram с фрагментом лога.

Связь со складом, линией и клиникой

• WMS — см. WMS для склада с маркировкой; ночной обмен остатков бьёт по диску.
• SCADA — SCADA / HMI; архив трендов растёт, если нет политики хранения.
• Маркировка — интеграция 1С и WMS; заказ КМ из ГИС МТ ночью не должен ронять сервер.
• XRAY/PACS — веб-архив для клиники; DICOM занимает гигабайты, отдельный контур хранения.

Чек-лист проверки

• Есть алерт на диск 85% на сервере WMS/SCADA/маркировки
• Настроена ротация логов интеграции с 1С (не вручную раз в месяц)
• Docker logging driver с лимитом размера
• PostgreSQL: мониторинг места под WAL и data
• Redis: лимит памяти и политика eviction согласована с разработчиком WMS
• Описан runbook «диск заполнен» — что архивировать, что не трогать
• После инцидента есть отчёт, а не только устный «перезапустили»
• Рассмотрен AI Support Agent как доп. модуль к проекту

Когда пора внедрять систему контроля

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

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

Что можно внедрить

• мониторинг диска, логов, PostgreSQL, Redis, Docker, Nginx;
• runbook с уровнями автономности и подтверждением критичных шагов;
• AI Support Agent от 60 000 ₽ как отдельная опция;
• ежемесячное сопровождение от 15 000 ₽/мес.

Связанные материалы

• AI Support Agent для промышленного ПО
• Страница решения AI Support Agent
• Интеграция 1С, WMS и Честного Знака
• Проверка DataMatrix онлайн

Связанные решения

• AI Support Agent
• WMS для склада с ТСД
• ПО для маркировки