Протоколы обработки ошибок и политики повторных попыток для ИИ-агента СПЗП.1.1
Общие принципы для всего роя
Классификация ошибок
yaml
Класс A (Временные/Транзиентные):
- Сетевые проблемы (timeout, connection refused)
- Временная недоступность внешних систем (1С, АППИУС)
- Блокировки БД (deadlock, lock timeout)
- Ошибки квот/лимитов (rate limiting)
Код: ERR_TEMPORARY_XXX
Класс B (Логические/Бизнес-ошибки):
- Невалидные входные данные
- Нарушение бизнес-правил (шаг сетки)
- Отсутствие зависимых сущностей
- Конфликты (дублирование данных)
Код: ERR_BUSINESS_XXX
Класс C (Критические/Системные):
- Недостаточно памяти/диска
- Недоступность критических сервисов
- Ошибки конфигурации
- Неавторизованный доступ
Код: ERR_CRITICAL_XXX
Стандартный формат ошибки
json
{
"error_id": "uuid",
"correlation_id": "uuid",
"timestamp": "ISO-8601",
"robot_id": "NR.NSI.X",
"error_class": "A|B|C",
"error_code": "ERR_XXX_YYY",
"message": "Человекочитаемое описание",
"details": {
"input_data": {},
"system_context": {},
"retry_count": 0,
"last_attempt": "ISO-8601"
},
"recovery_actions": [
{"action": "RETRY", "delay_seconds": 5},
{"action": "ESCALATE", "recipient": "team@domain.com"}
]
}
Детальные протоколы по роботам
1. NR.NSI.1_detect_new_scrap_need (Детектор)
yaml
Типичные ошибки:
- ERR_TEMPORARY_APPIUS_UNAVAILABLE: АППИУС не отвечает
- ERR_BUSINESS_INVALID_EVENT: Невалидная структура события
- ERR_CRITICAL_PARSE_ERROR: Ошибка парсинга сообщения
Политика повторных попыток:
Стратегия: Exponential Backoff + Jitter
Максимум попыток: 3
Интервалы: [2s, 8s, 32s] ± 25% jitter
Условия повторения: Только для ошибок класса A
Действия при неудаче:
- После 3 неудач: запись в Dead Letter Queue (DLQ)
- Уведомление: PagerDuty (Critical), email (Warning)
- Время эскалации: 5 минут
Логика восстановления:
if error_code == "ERR_TEMPORARY_APPIUS_UNAVAILABLE":
wait_for_system_health_check()
retry_with_circuit_breaker()
else:
escalate_to_human()
2. NR.NSI.2_fetch_appius_scrap_payload (Извлекатель данных)
yaml
Типичные ошибки:
- ERR_TEMPORARY_API_TIMEOUT: Таймаут запроса к API
- ERR_BUSINESS_TECH_DOC_NOT_FOUND: Техдокумент не найден
- ERR_CRITICAL_DATA_CORRUPTION: Поврежденные данные в ответе
Политика повторных попыток:
Стратегия: Fibonacci Backoff
Максимум попыток: 5
Интервалы: [1s, 1s, 2s, 3s, 5s] ± 15% jitter
Условия повторения: Ошибки классов A и некоторые B (кроме NOT_FOUND)
Действия при неудаче:
- Создание отложенной задачи на повтор через 30 минут
- Запись в журнал несинхронизированных документов
- Автоматическое создание инцидента в ServiceNow
Компенсирующие действия:
- Кэширование предыдущих успешных payload на 24 часа
- Использование кэша при временной недоступности (только для чтения)
Circuit Breaker:
Режим: Half-Open после 10 неудач за 5 минут
Timeout: 60 секунд в состоянии Open
3. NR.NSI.3_validate_nsi_infrastructure (Валидатор инфраструктуры)
yaml
Типичные ошибки:
- ERR_TEMPORARY_1C_UNAVAILABLE: 1С не отвечает
- ERR_BUSINESS_MISSING_NOMENCLATURE_TYPE: Отсутствует вид номенклатуры
- ERR_BUSINESS_MISSING_CHARACTERISTIC: Отсутствует характеристика
- ERR_CRITICAL_CONFIG_MISMATCH: Несовместимость версий систем
Политика повторных попыток:
Стратегия: Fixed Interval
Максимум попыток: 2
Интервалы: [10s, 30s] (без jitter - критично для инфраструктуры)
Условия повторения: Только ERR_TEMPORARY_1C_UNAVAILABLE
Действия при неудаче:
- Немедленная остановка цепочки (fail-fast)
- Создание задачи на ручное исправление в ITSM
- Уведомление администратору 1С
Протокол восстановления:
1. Проверка зависимостей через health-check endpoint
2. Автоматический запуск скриптов настройки (если разрешено)
3. При критических ошибках - ручное вмешательство обязательно
Timeout: 15 секунд на запрос к каждому справочнику
4. NR.NSI.4_create_stock_nomenclature_item (Создатель заготовок)
yaml
Типичные ошибки:
- ERR_TEMPORARY_DB_CONFLICT: Конфликт транзакций
- ERR_BUSINESS_DUPLICATE_ITEM: Дублирующаяся номенклатура
- ERR_BUSINESS_VALIDATION_FAILED: Ошибка валидации в 1С
- ERR_CRITICAL_INTEGRATION_ERROR: Несовместимость API
Политика повторных попыток:
Стратегия: Exponential Backoff с проверкой дублей
Максимум попыток: 4
Интервалы: [3s, 9s, 27s, 81s] ± 20% jitter
Условия повторения: Все ошибки, кроме DUPLICATE_ITEM
Идемпотентность:
- Генерация уникального idempotency_key на основе данных
- Проверка существования перед созданием
- Использование условных заголовков HTTP (If-None-Match)
Действия при неудаче:
- Для DUPLICATE_ITEM: возврат ссылки на существующий элемент
- Для VALIDATION_FAILED: логирование с детальной диагностикой
- Переход в режим "только чтение" при 5 неудачах подряд
Compensation Action:
- При неудаче после создания: пометка элемента как "некорректный"
- Автоматический откат через 24 часа, если не подтвержден
5. NR.NSI.5_create_scrap_nomenclature_item (Создатель отходов)
yaml
Типичные ошибки:
- ERR_BUSINESS_INVALID_SCRAP_TYPE: Неподдерживаемый тип отхода
- ERR_TEMPORARY_BATCH_FAILURE: Частичный сбой пакетной обработки
- ERR_CRITICAL_MEMORY_OVERFLOW: Превышение лимита пакета
Политика повторных попыток:
Стратегия: Batch Retry with Exponential Backoff
Максимум попыток: 3 для всего пакета, 5 для отдельных элементов
Интервалы: Пакет - [5s, 25s, 125s], Элементы - [1s, 3s, 9s, 27s, 81s]
Batch Processing:
Размер пакета: 10 элементов максимум
Стратегия: Частичный успех разрешен
При сбое > 50% элементов: откат всего пакета
Действия при неудаче:
- Для частичного успеха: продолжение с оставшимися элементами
- Логирование статистики успехов/неудач
- Автоматический split больших пакетов при MEMORY_OVERFLOW
Idempotency:
- Каждый элемент обрабатывается с уникальным ключом
- Перед повторной попыткой проверяется текущее состояние
6. NR.NSI.6_setup_scrap_characteristics (Конфигуратор)
yaml
Типичные ошибки:
- ERR_TEMPORARY_CHARACTERISTIC_LOCK: Блокировка характеристики
- ERR_BUSINESS_INVALID_GRID_VALUE: Значение вне сетки
- ERR_CRITICAL_TEMPLATE_MISSING: Отсутствует шаблон характеристики
Политика повторных попыток:
Стратегия: Linear Backoff with Lock Detection
Максимум попыток: 3
Интервалы: [15s, 30s, 45s] (длинные интервалы из-за блокировок)
Условия повторения: Все ошибки, кроме TEMPLATE_MISSING
Обработка блокировок:
- Ожидание освобождения блокировки до 60 секунд
- Принудительный разрыв блокировки через 90 секунд (только для чтения)
- Оптимистичные блокировки с версионированием
Действия при неудаче:
- Переход на ручной режим конфигурации
- Создание задач на исправление характеристик
- Временное хранение значений в буфере до исправления
Compensation:
- При сбое после частичной настройки: полный откат изменений
- Ведение журнала всех операций для аудита
7. NR.NSI.7_validate_scrap_geometry_step (Контролер шага)
yaml
Типичные ошибки:
- ERR_BUSINESS_STEP_VIOLATION: Нарушение шага сетки
- ERR_BUSINESS_OUT_OF_RANGE: Значение вне допустимого диапазона
- ERR_TEMPORARY_CALCULATION_TIMEOUT: Таймаут сложных расчетов
Политика повторных попыток:
Стратегия: No Retry for Business Errors
Максимум попыток: 1 для бизнес-ошибок, 3 для временных
Интервалы: Только для временных ошибок: [2s, 4s, 8s]
Валидационный контекст:
- Строгий режим: любое нарушение = ошибка
- Либеральный режим: допуск ±2% от шага с предупреждением
- Аварийный режим: только логирование при критической нагрузке
Действия при неудаче:
- Для STEP_VIOLATION: отклонение данных и уведомление технолога
- Для OUT_OF_RANGE: предложение ближайшего допустимого значения
- Автоматическая корректировка при включенном флаге auto_correct
Escalation Path:
1. Предупреждение оператору
2. Уведомление руководителю смены
3. Остановка производственной линии (при критических нарушениях)
8. NR.NSI.8_link_nomenclature_to_techdoc (Интегратор связей)
yaml
Типичные ошибки:
- ERR_TEMPORARY_REFERENCE_INTEGRITY: Нарушение ссылочной целостности
- ERR_BUSINESS_CIRCULAR_REFERENCE: Циклическая зависимость
- ERR_CRITICAL_VERSION_MISMATCH: Несовпадение версий документов
Политика повторных попыток:
Стратегия: Two-Phase Retry with Validation
Максимум попыток: 2
Фаза 1: Немедленная повторная попытка (0s)
Фаза 2: Отложенная попытка после валидации (30s)
Консистентность:
- Использование транзакционных сообщений
- Паттерн Outbox для гарантированной доставки
- Саги для распределенных транзакций
Действия при неудаче:
- Помещение связи в очередь на ручное согласование
- Создание инцидента с приоритетом P2
- Резервное копирование состояния связей
Recovery Protocol:
1. Проверка всех зависимостей
2. Восстановление из snapshot
3. Перестроение индексов связей
4. Валидация целостности
9. NR.NSI.9_track_nsi_creation_kpi (Аналитик KPI)
yaml
Типичные ошибки:
- ERR_TEMPORARY_METRICS_STORAGE_UNAVAILABLE: Хранилище метрик недоступно
- ERR_BUSINESS_KPI_CALCULATION_ERROR: Ошибка в расчетах KPI
- ERR_CRITICAL_DATA_LOSS: Потеря данных журнала
Политика повторных попыток:
Стратегия: Aggressive Retry with Fallback Storage
Максимум попыток: Бесконечно (с экспоненциальным ростом интервала)
Интервалы: [1s, 2s, 4s, 8s, 16s, 32s, 64s, 128s, 256s, 512s]
Maximum Interval: 10 минут
Fallback Strategy:
- Первичное хранилище: InfluxDB/ClickHouse
- Вторичное хранилище: Локальный кэш Redis
- Аварийное хранилище: Файловая система (JSON файлы)
- Восстановление: Автоматическая синхронизация при восстановлении
Действия при неудаче:
- Продолжение работы в режиме degraded (только сбор метрик)
- Буферизация метрик в памяти до восстановления хранилища
- Принудительная запись на диск при достижении лимита памяти
Data Recovery:
- Регулярные снепшоты каждые 5 минут
- Восстановление из последнего валидного снепшота
- Репликация метрик в другой датацентр
Система мониторинга и оповещений
Dashboard мониторинга
yaml
Основные метрики:
- success_rate_per_robot: Целевое значение > 99.5%
- average_processing_time: Целевое значение < 30s
- retry_rate: Предупреждение при > 5%
- error_distribution: Мониторинг по классам ошибок
Alert Levels:
- WARNING: success_rate < 99% или retry_rate > 10%
- ERROR: success_rate < 95% или наличие критических ошибок
- CRITICAL: success_rate < 80% или остановка цепочки
Политики уведомлений
yaml
Каналы уведомлений:
- Slack: Все предупреждения и бизнес-ошибки
- Email: Ежедневные отчеты и недельные тренды
- PagerDuty: Критические ошибки в рабочее время
- SMS: Критические ошибки вне рабочего времени
Частота уведомлений:
- Дедупликация: Группировка одинаковых ошибок за 5 минут
- Эскалация: Повторное уведомление через 15 минут без ответа
- Авто-разрешение: Автоматическое закрытие при успешном retry
Процедура восстановления после сбоев
Автоматическое восстановление
python
def auto_recovery_protocol(error_class, robot_id):
if error_class == "A":
# Временные ошибки - автоматический retry с backoff
schedule_retry(robot_id, delay=calculate_backoff())
elif error_class == "B":
# Бизнес-ошибки - требующие вмешательства
if is_auto_correctable(error_code):
execute_correction_script()
schedule_retry(robot_id, delay=60)
else:
create_support_ticket()
notify_human_operator()
elif error_class == "C":
# Критические ошибки - немедленная эскалация
trigger_incident_response()
switch_to_backup_system()
escalate_to_management()
Ручное вмешательство
yaml
Checklist для оператора:
1. Проверить доступность зависимых систем
2. Просмотреть логи последних 100 ошибок
3. Проверить квоты и лимиты
4. Валидировать входные данные
5. Выполнить тестовый запрос
6. Перезапустить робота в диагностическом режиме
Tools:
- Командный интерфейс для управления retry
- Dashboard для просмотра состояния очередей
- Инструмент для принудительного пропуска ошибок
- Система отката изменений
Post-Mortem процедура
yaml
Требования к анализу инцидента:
- Время восстановления (MTTR) < 30 минут
- Анализ первопричины (Root Cause Analysis)
- Обновление документации и playbooks
- Добавление тестов для предотвращения повторения
Артефакты:
- Отчет об инциденте с временной шкалой
- Список предпринятых действий
- Рекомендации по улучшению
- Обновленные политики retry
Резервные стратегии и деградация функциональности
Degraded Mode
yaml
Уровни деградации:
Level 0 (Full): Все роботы работают нормально
Level 1 (Reduced): Только критичные роботы (1, 2, 3, 9)
Level 2 (Minimal): Только детектор и логирование (1, 9)
Level 3 (Emergency): Ручной режим, только оповещения
Активация:
- Автоматически при > 20% ошибок
- Вручную администратором
- По расписанию (ночное время)
Fallback Mechanisms
yaml
Для каждого робота:
- Кэширование успешных результатов
- Статические шаблоны как запасной вариант
- Локальная база данных для автономной работы
- Очередь отложенных задач при восстановлении
Эта система обработки ошибок обеспечивает высокую отказоустойчивость при сохранении консистентности данных и минимального времени простоя.