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

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

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

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

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

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

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

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

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

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

Условный пример (типовой сценарий)

Условный пример: производство напитков, SCADA + MES + сервер маркировки на одной VM. Ночью cron запускает отчёт по смене — тяжёлый SQL к PostgreSQL. Одновременно Docker пишет json-log без лимита размера. Диск заполняется, PostgreSQL выдаёт ошибки записи. 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 для склада с ТСД
• ПО для маркировки