Управление инцидентами на парковке

Коротко

Камера может сообщить о нарушении за секунду. Но если сигнал появляется в отдельном окне, не получает ответственного и исчезает без истории, автоматизация только увеличивает шум.

Операционный инцидент — это не красная точка. Это объект с причиной, состоянием, доказательствами, ответственным, сроком и финальным решением.

Сигнал, событие и инцидент — разные сущности

Сигнал устройства сообщает, что внешний источник увидел условие: например, wrong parking started.

Доменное событие подтверждает, что система приняла сигнал, доверяет привязке и нормализовала контекст.

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

Не каждое наблюдение должно создавать новую задачу. Повтор одного сигнала может обновить существующий lifecycle; дребезг должен подавляться; событие ended должно закрывать только связанную активную генерацию.

Базовый lifecycle

NEW — новый

Система создала инцидент и приложила максимум контекста: объект, уровень, зона, место, источник, время, тип, severity и доказательные материалы.

IN_PROGRESS — в работе

Оператор принял ответственность. В истории фиксируются пользователь и время. Два оператора не должны одновременно «владеть» одной задачей без явной модели передачи.

RESOLVED — решён

Причина устранена или оператор выполнил согласованное действие. Желательно сохранить resolution code и комментарий.

IGNORED — игнорирован

Это не удаление. Нужно указать причину: ложное срабатывание, разрешённая ситуация, дубликат, тест и т. п. Иначе метрика MTTR улучшается искусственно.

Что должно быть в карточке оператора

Минимальный контекст:

• понятное название без raw enum;
• место, зона и уровень;
• время начала и длительность;
• свежесть события;
• кадр и при наличии записанный фрагмент;
• связанная камера и её health;
• история статуса места;
• предыдущие инциденты по источнику;
• SLA/эскалация;
• допустимые действия текущей роли.

Если оператору приходится открывать три системы и вручную искать камеру по серийному номеру, время реакции определяется интерфейсом, а не скоростью детекции.

Доказательные материалы: полезное и допустимое

Доказательные материалы помогает восстановить решение, но повышает чувствительность данных. Кадр может содержать ГРЗ, людей, пропуск и план закрытого объекта.

Рабочая модель:

1. исходное медиа хранится приватно;
2. ссылка ограничена по времени;
3. право просмотра отделено от права управлять инцидентом;
4. чувствительный просмотр и экспорт аудитируются;
5. retention зависит от категории;
6. публичная версия кейса создаётся отдельно и обезличивается.

Автоматическое создание и завершение

Автоматизация безопасна, когда внешний источник имеет парный lifecycle и стабильную корреляцию:

• started открывает/обновляет активный инцидент;
• повтор started не создаёт дубль;
• ended закрывает связанную генерацию;
• старый redelivery не закрывает новый случай;
• подтверждённое освобождение места может завершить wrong-parking по отдельному правилу.

Ложные тревоги: что измерять

Термин «ложная» должен иметь основание. Разделите:

• ошибка детектора;
• неверная привязка камеры к месту;
• повторная доставка;
• устаревший сигнал;
• допустимая бизнес-ситуация, которую правило не учло;
• ошибка оператора.

Тогда корректирующее действие понятно: калибровать камеру, исправить mapping, изменить debounce, версионировать правило или обучить оператора.

SLA и эскалация

SLA должен учитывать severity, расписание и роль. Базовые метрики:

• MTTA: taken_at - created_at;
• MTTR: resolved_at - created_at;
• time in progress;
• breach rate;
• unassigned age;
• повтор по источнику;
• доля ignored по причинам.

CShark имеет поля assignment/SLA/history и watcher эскалации. Реальный SLA и каналы уведомления настраиваются проектом.

Пример полного сценария

Условие: автомобиль занимает место с нарушением разметки.

1. Камера отправляет started с местом и кадром.
2. Gateway нормализует событие и фиксирует его до NATS.
3. Core проверяет источник и создаёт инцидент с site/zone/spot.
4. WebSocket обновляет карту и ленту.
5. Оператор открывает доказательные материалы и принимает инцидент.
6. Водитель переставляет автомобиль; камера подтверждает ended или место становится свободным.
7. Покрытая системная логика завершает инцидент; история сохраняет все переходы.
8. Аналитик видит MTTA/MTTR и повторяемость по месту.

Для настоящего кейса необходимо показать не синтетический «успех», а 20–50 реальных инцидентов и причины исключений.

Матрица приёмки

FAQ

Какие инциденты можно автоматизировать?

Те, для которых есть доверенное событие, контекст и понятное условие завершения. В текущем CShark покрыты camera alerts и vendor-neutral video analytics; новые типы требуют контракта и правила.

Можно ли закрывать инцидент автоматически?

Да, для проверенного парного lifecycle. Универсальный автоклоуз опасен: старое событие не должно закрыть новый случай.

Чем SLA отличается от уведомления?

SLA измеряет обязательный срок/эскалацию. Уведомление — один из каналов доставки информации и не гарантирует, что задачу приняли.

Как бороться с ложными тревогами?

Классифицировать причину, измерять, применять dedupe/debounce, исправлять mapping и версионировать правила. Не скрывать их массовым ignore.

Что можно показывать в публичном кейсе?

Только согласованные обезличенные кадры/таймлайны. ГРЗ, лица, адрес, сетевые детали и коммерческие данные удаляются или маскируются по утверждённой политике.

Граница применимости к CShark

Материал описывает проверяемый инженерный подход. Конкретный состав CShark зависит от версии, подключённых источников данных, прав, конфигурации и приёмки оборудования на объекте.

Посмотрите, какие возможности CShark доступны водителю и оператору и как они применяются на парковке, на странице возможностей системы.