Дизайн журнала аудита: события, изменения и результаты

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

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

Начните с вопроса, на который должен ответить журнал

Представим приложение службы поддержки. Администратор выясняет, почему новые обращения теперь попадают в группу Billing, а не General. Похоже, изменилось правило маршрутизации RR-17. Полезный вопрос здесь не «Сколько событий произошло сегодня?», а «Какое зафиксированное действие изменило это правило и что именно поменялось?»

Заложите в макет два намеренно разных события:

• 6 октября 2026 года в 14:08:12 UTC администратор Mina изменила назначение правила RR-17 с General на Billing. Изменение выполнено успешно.
• В 14:09:03 UTC автоматизация маршрутизации попыталась ещё раз изменить RR-17. Попытка завершилась ошибкой, назначением осталось Billing.

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

Разделите исполнителя, действие и объект

Короткая фраза помогает просматривать список: «Mina изменила правило маршрутизации RR-17». Дополнительные поля показывают результат и время. В подробностях доступны разрешённые к просмотру изменения и идентификатор события. Не пытайтесь вывести все исходные атрибуты в основной таблице.

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

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

Показывайте изменение только тогда, когда его подтверждает событие

Для EV-2041 достаточно короткой подробности: назначение изменено с General на Billing. Укажите имя поля один раз, подпишите прежнее и новое значения и сделайте направление изменения понятным без цвета. На узком экране блоки «До» и «После» можно расположить друг под другом, сохранив обе подписи.

Не восстанавливайте старое значение путём сравнения текущей записи с несвязанным снимком данных. Если событие сообщает только об обновлении правила, прямо укажите, какие подробности отсутствуют. Текущее состояние отвечает на вопрос «Что действует сейчас?», а подробности события — «Что было зафиксировано об этом действии?». Это не одно и то же.

Для неудачной попытки автоматизации покажите запрошенное действие и записанную причину ошибки с допустимой степенью подробности. Не помещайте неприменённое значение под безусловной подписью «После». Отдельная подпись «Запрошенное изменение» уместна, если источник содержит эти сведения и пользователь вправе их видеть.

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

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

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

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

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

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

Спроектируйте переход от строки события к полезным подробностям

Создайте в файле Pixso таблицу событий приложения поддержки и рядом — панель подробностей EV-2041. В обеих частях должны совпадать RR-17, Mina, 14:08:12 UTC и General → Billing. Добавьте более позднюю неудачную попытку автоматизации отдельной строкой с другим результатом, а не просто другим значком.

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

Спроектировать журнал с подробностями событий в Pixso →

Не выдавайте отсутствие истории за отсутствие событий

Список событий может быть пуст по разным причинам. Фильтрам ничего не соответствует. Выбранный период выходит за срок хранения. У пользователя нет доступа. Источник не передал события или сервис не смог их загрузить. Эти ситуации требуют разных объяснений.

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

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

Больше подробностей — не всегда больше полезных доказательств

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

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

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

Оценивайте интерфейс по тому, что он позволяет установить

При разборе RR-17 администратор должен определить успешное изменение, прочитать доступные значения до и после него, отличить более позднюю неудачную попытку и назвать просмотренные период и область данных. Он также должен заметить недоступную подробность, а не заполнять пробел собственным предположением.

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