Руководство пользователя Менеджера Сценариев

5.Эксплуатация.

5.1.Работа с расписаниями.

5.1.7.Порядок отключения и включения систем.

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

Данный порядок действий подробно описывает процесс отключения, поведение системы во время простоя и процедуру восстановления работы.

Где и как отключается система.

Управление статусом системы осуществляется в разделе «Администрирование» -> «Управление справочником «Системы»». Для доступа требуются права администратора: уровень доступа > 3.

Процесс отключения:

1. В разделе «Администрирование» -> «Управление справочником «Системы»» в общем списке систем найдите нужную систему. Для этого можно использовать поле «Фильтр».
2. Убедитесь, что выбрана правильная система. Нажмите на текущий статус системы (тег «Включена»).
3. Откроется диалоговое окно «Выключение системы «Имя системы»» (рисунок 24).
4. Заполните обязательные поля:
   • причина выключения: техническое обоснование (например: «Плановые работы на БД», «Установка обновлений»).
   • дата и время планового включения: укажите, когда система должна быть возвращена в работу.
5. После заполнения полей, активируется кнопка «Выключить». Кнопка становится активной только когда оба поля заполнены.
6. Нажмите кнопку «Выключить». Статус системы сменится на «Выключена» (рисунок 25).

Поведение процессов при отключенной системе.

Поведение зависит от типа процесса и роли отключенной системы в нем.

А. Процессы, выполняемые по расписанию (Scheduler).

Если отключенная система является источником данных или целевой системой для расписания, тогда:

• при новых запусках планировщик перестает создавать новые задания для этого расписания и проверяет статус систем перед созданием задания.
• ранее запущенные задания — задания, которые находились в статусе «Исполняется» на момент отключения,  завершатся с ошибкой, так как их работа прервется при попытке обратиться к отключенной системе (например, не сможет подключиться к БД).
• исключение: если в настройках расписания (рисунок 26) будет явно указан параметр «Игнорировать выключение систем-источников *» в статусе «Да», оно будет игнорировать статус системы и продолжать работу.

Б. Процессы-активаторы (на основе сообщений Kafka).

В данном случае роль системы критически важна.

Если отключенная система является источником данных для активатора:

• опрос БД прекращается: активатор перестает выполнять SQL-запросы к этой базе данных для получения новых данных.
• данные накапливаются в таблицах базы-источника. При включении системы активатор увидит все изменения, произошедшие за время простоя.

Если отключенная система является получателем данных:

• активаторы продолжают работать, читать сообщения из Kafka и создавать новые процессы для их обработки.
• эти процессы доходят до этапа отправки данных в целевую систему и завершаются с ошибкой, так как не могут до нее достучаться. В результате в топике Kafka накапливается задержка (Lag) для потребительской группы (Consumer Group), связанной с этой системой.

Это наглядно видно в компоненте «Состояние систем-получателей» (рисунок 27) в столбце «Задержка»: сообщения не теряются, но не могут быть обработаны, создавая очередь.

Что происходит при включении системы.

Процесс включения:

1. В списке систем нажмите на статус «Выключена».
2. Подтвердите действие во всплывающем диалоге.
3. Статус системы немедленно сменится на «Включена», а поля «Причина выключения» и «Дата и время планового включения» очистятся.

Что запускается и отрабатывается АВТОМАТИЧЕСКИ при включении системы:

• процессы по расписанию: планировщик снова начнет создавать задания согласно их cron-расписанию. Пропущенные за время простоя запуски не запускаются.
• активаторы-источники: немедленно возобновляется опрос базы данных. Активатор увидит все изменения, накопившиеся за период простоя, и начнет отправлять их в виде сообщений в Kafka. Backlog сообщений обрабатывается автоматически.
• активаторы-получатели (Kafka Consumer) из группы консьюмеров, связанные с этой системой, автоматически возобновляют обработку сообщений из своих топиков. Они начнут плановую обработку накопившегося лага сообщений. Созданные процессы будут успешно доходить до конца, так как система снова доступна.
• балансировка нагрузки: задания начнут корректно распределяться между нодами кластера.

Что требует РУЧНОГО вмешательства и контроля:

• задания в статусе «Исполняется» — задания, которые «зависли» при отключении системы, не меняют свой статус автоматически. Их нужно найти через мониторинг (логи, интерфейс заданий) и вручную завершить или перезапустить.
• задания, завершившиеся с ошибкой — задания, которые не отработали из-за недоступности системы, не перезапускаются автоматически. Необходимо, проанализировать ошибки в логах и принять решение о массовом перезапуске таких заданий или точечно исправить критические.
• мониторинг обработки лага Kafka: после включения системы-получателя необходимо убедиться, что лаг уменьшается. Это можно сделать через контроль состояния систем-получателей или напрямую в инструментах мониторинга брокера Kafka. Если лаг не уменьшается, это признак проблемы в консьюмере или в логике процесса.
• контроль нагрузки: первое время после включения система может испытывать повышенную нагрузку из-за одновременной обработки текущих данных и накопившегося backlog. Необходимо вести мониторинг метрик (CPU, память, сеть, нагрузка на БД).
• валидация данных: после стабилизации работы необходимо выборочно проверить, что данные обрабатываются корректно, нет пропусков или ошибок в бизнес-логике из-за сбоя.

Чек-лист действий после включения системы.

• проверить статус системы: убедиться, что статус сменился на «Включена».
• убедиться в работе расписаний: проверить, что в логах планировщика появились новые задания для связанных расписаний.
• проверить активаторы-источники: убедиться, что в логах активаторов пошел опрос базы данный и отправка сообщений.
• контролировать Kafka Lag: убедиться, что показатель «задержка» уменьшается.
• найти и обработать «зависшие» задания: через интерфейс заданий найти задачи с временем старта до момента включения и вручную их завершить.
• проверить логи на ошибки: просмотреть логи системы, активаторов и заданий на предмет новых ошибок после включения.
• осушествлять мониторинг метрик: следить за системными метриками в течение нескольких часов после включения на предмет аномальной нагрузки.
• уведомить пользователей: сообщить о завершении работ и успешном восстановлении системы.