Хранение и поиск событий в системе ситуационного контроля и учёта рабочего времени

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

Единая база связала регистрацию событий с последующим поиском

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

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

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

Трёхмесячный срок хранения был частью проектного решения

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

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

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

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

Поиск событий задан через метки времени и типы событий

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

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

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

Что проверялось по документам автоматизированной системы

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

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

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

Как из параметров хранения и поиска сформирован результат

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

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

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

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

Практическое значение для аналогичной автоматизированной системы

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

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

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