Ретроспективный анализ инцидента: события, видеоархив, голос и документы

В этом кейсе рассматривалась система ситуационного контроля безопасности и предусмотренный проектом инструмент ретроспективного анализа событий. Проверочный вопрос состоял в том, как разнородная информация объединяется вокруг одного инцидента, чтобы его можно было рассматривать не по отдельным системам, а как связанную последовательность событий и действий.

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

Состав информации об одном инциденте

Центром решения был сам инцидент. К нему проект относил несколько типов информации, которые возникают в разных подсистемах и имеют различную форму. Системные события показывают срабатывания и иные зарегистрированные события контролируемых технических средств. Действия операторов отражают предусмотренную проектом сторону реагирования. Видеоархив, голосовые записи и фотографии дают медийную составляющую, а документы дополняют её документированной информацией.

Для ретроспективного анализа значение имеет именно связь этих элементов с одним рассматриваемым событием. Отдельная видеозапись или отдельная системная запись дают только часть картины. Проектная логика предусматривала возможность собрать вокруг инцидента несколько информационных слоёв и рассматривать их совместно.

Такой подход отличается от задачи простой передачи изображения от внешней системы видеонаблюдения. Здесь предметом проверки была более широкая проектная функция: формирование связанной истории инцидента из событий, действий операторов, медиафайлов и документов.

Документы и архитектура решения

При проверке рассматривались техническое задание, подраздел «Сети связи», структура системы учёта рабочего времени, планы оборудования, а также описание серверной и программной части. Вместе эти материалы задавали проектный контекст, в котором должна была работать функция ретроспективного анализа.

Техническое задание определяло требуемую функциональную задачу. Подраздел «Сети связи» относил её к соответствующим техническим решениям проекта. Планы оборудования показывали проектную инфраструктуру, связанную с реализацией системы. Описание серверной и программной части раскрывалo ту часть решения, где разнородная информация должна была обрабатываться и связываться между собой.

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

События и действия операторов

В ретроспективный анализ проектом включались события контролируемых технических средств. Это задаёт машинную часть истории инцидента: система должна учитывать сведения о событиях, зарегистрированных соответствующими средствами контроля.

Одновременно учитывались действия операторов по реагированию. Благодаря этому проектная модель охватывала не только то, что зарегистрировала техническая система, но и предусмотренную информацию о реакции персонала. Для разбора инцидента эти два слоя имеют разную функцию: первый относится к зарегистрированным событиям, второй — к действиям, связанным с реагированием.

При профессиональной проверке подобной схемы важно сохранять это различие. Событие оборудования и действие оператора могут относиться к одному эпизоду, но являются разными типами записей. Их совместное использование становится полезным только тогда, когда проект предусматривает их объединение вокруг одной истории инцидента и не смешивает происхождение данных.

Видеоархив, голос, фотографии и документы

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

Видео позволяет сопоставлять инцидент с визуальной записью, голосовые материалы — с предусмотренной аудиоинформацией, фотографии — с отдельными зафиксированными изображениями, документы — с относящимися к событию документированными сведениями. В рассматриваемом проекте подтверждён сам состав этих информационных компонентов и их включение в общую схему ретроспективного анализа.

Для аналогичной системы на этапе проектной проверки имеет значение происхождение каждого типа информации и его место в общей архитектуре. Если один вид данных существует изолированно и проект не определяет его связь с событием, наличие такого архива ещё не формирует единую историю инцидента. В этом кейсе проверялось именно предусмотренное объединение нескольких типов данных.

Связь данных во времени

Ретроспективный анализ предполагает рассмотрение информации в связи с произошедшим инцидентом. Поэтому для профессиональной оценки подобного решения существенно различать проектное наличие источников данных и фактическое качество их временного сопоставления при эксплуатации.

Рассмотренная документация подтверждала состав информации, включаемой в анализ, но не подтверждала качество фактической синхронизации временных меток. Из проектного решения нельзя автоматически выводить, что все события, видео, голосовые записи и действия операторов в реальной системе будут иметь требуемую точность временного совмещения.

При реализации аналогичной архитектуры именно временная связность определяет, насколько уверенно можно восстановить очередность событий из разных подсистем. Проверка этого свойства уже требует эксплуатационных данных и фактических записей. Они не входили в подтверждённый результат рассматриваемой проектной проверки.

Подтверждённый результат проверки

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

Практический смысл вывода состоит в подтверждении предусмотренной архитектуры ретроспективного анализа. Для дальнейшей работы с проектом можно опираться на то, что перечисленные информационные компоненты предусмотрены как части одной функции анализа инцидента. Изменение состава источников или принципа их объединения уже затрагивало бы предмет подтверждённого проектного решения.

Пределы проектного вывода

Экспертный результат относится к проектному составу информации и логике её объединения. Он не подтверждает фактические результаты эксплуатации системы. Числовые эксплуатационные показатели, реальная полнота архивов и фактическое качество синхронизации данных в рамках этой проверки не устанавливались.

Отдельно не подтверждалась юридическая допустимость каждого вида записи. Наличие в проекте голосовых записей, видео, фотографий или документов описывает состав предусмотренной информации, но само по себе не является правовой оценкой порядка её получения или дальнейшего использования.

Поэтому результат кейса имеет точную границу: подтверждена проектная возможность собрать вокруг одного инцидента системные события, действия операторов, видеоархив, голосовые записи, фотографии и документы. Фактическая полнота такой истории, качество временной синхронизации и эксплуатационная работа системы требуют уже другой проверки на основании данных реализованной системы.