Журнал событий как источник правды: зачем это нужно бизнесу
Event sourcing - не просто архитектурный паттерн. Это способ сохранить историю изменений и дать аналитике честный фундамент.
Большинство систем хранят только текущее состояние. Заказ был создан - запись есть. Заказ изменён - запись обновлена. Заказ отменён - запись удалена или помечена. История того, что происходило между этими точками, как правило, теряется.
Когда всё работает, это не важно. Но когда нужно разобрать инцидент, восстановить цепочку решений или понять, почему цифры в отчёте расходятся - оказывается, что ответа нет. Данные есть, а истории нет.
Что такое журнал событий
Журнал событий - это подход, при котором система сохраняет не только текущее состояние объекта, но и каждое действие, которое к нему привело. Не "заказ 1234 отменён", а "заказ 1234 создан в 10:00, изменён менеджером Ивановым в 11:30, отменён клиентом в 14:45".
Текущее состояние становится производным от истории, а не самостоятельным фактом. Это принципиальный сдвиг.
В инженерии этот подход называют event sourcing. Но управленческая ценность не в названии - она в том, что компания получает, когда такой журнал есть.
Что это даёт на практике
Первое - разбор инцидентов. Если система ведёт полный журнал действий, любой спорный момент можно восстановить с точностью до события. Кто изменил цену? В какой момент статус заявки переключился? Почему система выдала такое решение? На эти вопросы есть ответы.
Второе - аудит без дополнительных усилий. Регуляторные требования, внутренние проверки, расследования по жалобам клиентов - всё это опирается на журнал событий, который уже ведётся как часть работы системы, а не собирается постфактум.
Третье - аналитика, которой можно доверять. Если журнал событий есть, аналитик может воссоздать состояние системы на любой момент в прошлом. Это позволяет сравнивать периоды честно, без допущений о том, "какими были данные в том квартале".
Четвёртое - возможность отмены и воспроизведения. Технически журнал событий позволяет откатить состояние системы назад или воспроизвести цепочку событий с изменёнными параметрами. Для финансовых систем и операционных процессов это ценный инструмент при миграции и исправлении ошибок.
Где это не нужно
Я не хочу создавать впечатление, что журнал событий нужен везде. Для простых справочников, статических данных, систем без значимой истории изменений - это избыточная сложность.
Журнал событий имеет смысл там, где важна история: транзакционные системы, управление заявками, финансовые операции, изменения в договорах, логистические события.
Организационный вопрос важнее технического
Даже если архитектура правильная, журнал событий полезен только тогда, когда на него есть спрос. Я видел системы с прекрасным логированием, которые никто не смотрел, потому что не было процесса разбора инцидентов и не было ответственного за аналитику данных.
Несколько вопросов, которые стоит задать:
- Когда у нас последний раз был спор о том, что произошло в системе - и смогли ли мы его разрешить по данным?
- Кто в компании разбирает инциденты и на какие данные опирается?
- Есть ли задачи аудита или compliance, для которых нам нужна история изменений?
- Насколько наша текущая аналитика зависит от допущений о прошлых состояниях данных?
Если вопросы вызывают неудобное молчание - это сигнал, что архитектура данных стоит пересмотра. Не обязательно сразу и везде, но в ключевых системах.