Журнал действий пользователей: зачем бизнесу аудит-лог и как реализовать его на NestJS и Prisma

Клиент требует вернуть «пропавший» заказ, менеджер клянётся, что ничего не трогал, а скидка в карточке товара оказалась 90% вместо 9%. В каждой такой ситуации первый вопрос руководителя один и тот же: кто, что и когда сделал в системе. Если у веб-приложения нет журнала действий пользователей — аудиторского лога, — ответа не будет: останутся версии, догадки и испорченные отношения с клиентами или сотрудниками. В этой статье разбираем, зачем бизнесу аудит-лог, какие операции стоит фиксировать и как реализовать журнал изменений в приложении на NestJS и Prisma — с рабочими фрагментами кода.

Что такое аудит-лог и чем он отличается от технических логов

Технические логи пишут для разработчиков: ошибки, стек-трейсы, время ответа сервера. Аудит-лог — журнал для бизнеса, и каждая его запись отвечает на пять вопросов: кто (ID пользователя и его роль), что (сущность и операция — например, «изменил заказ №4821»), когда (время с таймзоной), откуда (IP-адрес и устройство) и как было и как стало (старое и новое значение полей). Важное свойство журнала — неизменяемость: записи только добавляются, редактировать и удалять их нельзя даже администраторам системы. Иначе аудит-лог теряет доказательную силу: любая правка превращает его из документа в набор мнений.

Зачем бизнесу журнал действий: пять рабочих сценариев

Аудит-лог редко входит в первые требования к продукту, но именно он выручает в самых дорогих ситуациях — конфликтах, утечках и разбирательствах.

• Споры с сотрудниками и клиентами. «Я ничего не менял» перестаёт быть аргументом: журнал показывает, кто и когда скорректировал цену, статус или реквизиты.
• Расследование инцидентов. При утечке данных или массовом удалении видно, с какого аккаунта и с какого IP это происходило.
• Контроль дисциплины. Сразу видно, кто систематически завышает скидки, обходит согласование или правит чужие сделки.
• Восстановление после ошибок. По значениям «до» можно откатить неудачное массовое изменение за минуты, а не восстанавливать весь день из бэкапа.
• Требования регуляторов. Для систем с персональными данными (152-ФЗ, приказы ФСТЭК) и в отраслях с лицензированием фиксация действий пользователей — ожидаемая мера защиты.

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

Что фиксировать, а что — нет

Главная ошибка — писать всё подряд: журнал на миллионы записей, из которых 90% — шум, стоит денег и не читается. Фиксируйте:

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

Не пишите пароли, токены и секреты, а персональные данные храните в журнале в виде ID, а не ФИО и телефонов — иначе аудит-лог сам превратится в базу ПДн со всеми требованиями к её защите. Высокочастотные сервисные операции (health-check, проверки соединений) тоже пропустите: они засоряют журнал и удорожают хранение.

Где перехватывать изменения: четыре подхода

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

1. Триггеры на уровне БД. Надёжно — не пропустят ни одной записи, но не знают, какой пользователь инициировал изменение, и усложняют миграции.
2. Расширение клиента Prisma ($extends). Один слой на все операции с базой — минимальный шанс что-то забыть.
3. Интерцепторы NestJS. Знают контекст HTTP-запроса, но пропустят изменения из фоновых задач и скриптов.
4. Явные вызовы AuditService. Полный контроль над тем, что и зачем логировать, но требует дисциплины — в новом коде легко забыть добавить вызов.

На практике хорошо работает связка: расширение Prisma как страховочная сетка для всех update и delete плюс явные вызовы для критичных операций, где нужен бизнес-контекст — причина изменения, связанная сделка. Отметим, что middleware в Prisma считается устаревшим механизмом: новые проекты стоит сразу строить на $extends.

Хранение: структура таблицы, объёмы и сроки

Классическая таблица audit_log состоит из полей id, createdAt, userId, entity, entityId, action (CREATE, UPDATE, DELETE, LOGIN), changes в формате JSONB со значениями «до/после», а также ip и userAgent. Прикинем объёмы: 30 активных пользователей при 50 значимых операциях в день дают около 1 500 записей в сутки и ~550 тысяч в год — при среднем размере записи 1–2 КБ это всего 1–2 ГБ, PostgreSQL справляется без специальных мер. Рекомендуем вынести журнал в отдельную схему, добавить индексы по (entity, entityId) и (userId, createdAt) — по ним чаще всего ищут, — и заранее определить политику хранения. Типовой вариант: детальные записи держим 12 месяцев, архив — до 3 лет; при больших объёмах помогает партиционирование по месяцам.

Интерфейс журнала: превращаем записи в бизнес-инструмент

Сырые строки в базе бесполезны для руководителя — журналу нужен интерфейс. Минимум — страница «Журнал действий» в админке с фильтрами по пользователю, периоду, сущности и типу операции, поиском и выгрузкой в CSV или Excel для бухгалтерии и службы безопасности. Второй уровень — кнопка «История изменений» в карточке заказа или клиента: таймлайн событий с подсветкой старого и нового значения поля. Третий, опциональный уровень — алерты на опасные события: выгрузка более N записей за раз, удаление заказа на крупную сумму, вход в нерабочее время. Такая доработка обычно занимает 2–4 дня разработки, а пользу приносит уже в первый месяц — чаще всего в виде закрытого спора «кто виноват».

Вывод: аудит-лог — дешёвая страховка от дорогих конфликтов

Журнал действий пользователей — одна из самых недооценённых функций веб-приложений: полный цикл внедрения на NestJS и Prisma занимает 3–5 дней, а экономит недели разбирательств, деньги на восстановление данных и репутацию компании. Начните с малого — зафиксируйте изменения заказов, платежей и прав доступа, добавьте страницу просмотра и расширяйте по мере роста требований. Если вы только выбираете подрядчика для разработки системы, спросите, как в ней реализовано отслеживание изменений и сможет ли руководитель увидеть, кто что правил, — уклончивый ответ сам по себе повод насторожиться. А если аудит-лог нужен в существующем продукте, наша команда встроит его без остановки работы сервиса.