Журнал действий отвечает ровно на два вопроса, и оба задаются задним числом. Первый: что происходило в системе с 19:40 пятницы до 11:00 среды, когда сломался обмен. Второй, куда более неприятный: кто выгрузил базу клиентов, когда и в каком объёме. Ни на один из них нельзя ответить в момент, когда вопрос возник, — можно только прочитать то, что было записано раньше.
Это отличает журнал от оповещений. Оповещение — сигнал: событие произошло, нужна реакция сейчас. Журнал — доказательство: событие произошло, и через полгода это можно будет подтвердить. Требования у них разные и почти не пересекаются: какие двенадцать событий должны звать человека немедленно и с какими порогами, мы разбирали отдельно. Здесь речь только о том, что записывается и как это потом находить.
Отдельная и самая новая часть темы — журнал решений ИИ-агента. Он отличается от обычного журнала не объёмом, а составом: кроме действия в записи должно быть основание, и без него разбирательство с клиентом через три месяца выигрывает не тот, кто прав, а тот, у кого есть бумага.
Минимальный состав: пять групп событий
Записывать всё подряд — плохая идея: журнал разбухает, поиск замедляется, а нужные события тонут в служебном шуме. Обязательных групп пять, и каждая отвечает на конкретный вопрос, который рано или поздно задают.
| Группа событий | Что записывается обязательно | На какой вопрос отвечает потом |
|---|---|---|
| Вход в систему | Кто, когда, с какого адреса, успешно или нет, с какого устройства | Работал ли сотрудник в системе в тот вечер и не было ли входов под его учётной записью после увольнения |
| Изменение суммы, цены и статуса | Объект, было — стало, кто и когда, из какого интерфейса или обменом | Кто поменял цену в счёте и статус заказа задним числом |
| Выгрузка данных | Кто, какой раздел, сколько строк, в каком формате, куда: файл, почта, интеграция | Кто выгрузил базу клиентов, когда и в каком объёме — самый частый повод открыть журнал |
| Изменение прав доступа | Кому, кем, какие права добавлены и сняты, было — стало | Откуда у менеджера появился доступ к отчёту по марже и кто его выдал |
| Действия роботов и ИИ-агентов | Под какой служебной учётной записью, какое действие, по какому событию запущено | Это сделал сотрудник или автоматика — вопрос, который в разборе возникает первым |
Пятая группа обычно отсутствует, и это самая дорогая из недостач. Робот и агент работают под общей служебной учётной записью, и в журнале их действия выглядят как действия абстрактного «сервиса интеграции». В разборе инцидента это сразу останавливает работу: непонятно, ошибся человек или сценарий, и восстанавливать приходится по косвенным признакам. Разводить эти два потока надо заранее, отдельной пометкой в каждой записи.
Выгрузок, обращений интеграций и действий служебных учётных записей. Все три включаются отдельно и почти никогда не включены по умолчанию, потому что производители систем считают их служебным шумом. Выясняется это в момент, когда они впервые понадобились, то есть в худший из возможных. Проверить наличие всех трёх — вопрос пяти минут и одного письма подрядчику.
Журнал решений ИИ-агента: действие плюс основание
Строка журнала, в которой кроме самого действия зафиксировано, на чём оно основано: какие фрагменты базы знаний и какие поля учётных систем были прочитаны, в какой редакции они находились на тот момент и по какой инструкции работал агент. Обычная запись отвечает на вопрос «что произошло», запись решения — на вопрос «почему система считала это правильным».
Разница выясняется в первом же споре. Клиент утверждает, что в марте ему назвали другую цену. Обычный журнал покажет, что в марте бот отправил сообщение с такой-то суммой, — и на этом всё: неизвестно, откуда сумма взялась, была ли она верной на тот момент и кто отвечает за расхождение. Запись решения показывает, что сумма взята из строки прайса в редакции от 3 марта, и вопрос закрывается за минуту.
- Действие или текст ответа. То, что реально ушло клиенту или было записано в систему, а не то, что планировалось.
- Использованные источники со ссылками и редакцией. Не «взято из базы знаний», а конкретные фрагменты с датой их последнего изменения. Именно редакция на момент ответа отвечает на вопрос, ошиблась система или устарел справочник.
- Прочитанные поля систем. Из какой карточки, какого документа, какие поля. Это же поле показывает, не увидел ли агент чужие данные.
- Версия инструкции и версия модели. После обновления любой из них поведение меняется, и без этих двух значений сравнить «до» и «после» невозможно.
- Уверенность и факт передачи человеку. Если агент передал диалог оператору, это тоже решение, и оно записывается наравне с ответом. Отсутствие таких записей означает, что стоп-темы не работают.
Есть и вторая польза, ежедневная: без ссылок на источник невозможен выборочный контроль. Проверяющий должен видеть не только ответ, но и то, откуда он взят, — иначе проверка сводится к чтению текста на правдоподобие. Норму такой проверки и её цену мы считали отдельно: 70 диалогов в неделю при потоке 6 000 обращений.
Схема одной записи журнала в виде развёрнутой карточки с пятью подписанными блоками сверху вниз: «Действие или текст ответа», «Использованные источники: фрагменты базы знаний со ссылкой и датой редакции», «Прочитанные поля систем: карточка, документ, перечень полей», «Версия инструкции и версия модели», «Уверенность и факт передачи оператору». Слева от карточки узкая колонка «обычная запись» с одним закрашенным блоком — только первым; справа колонка «запись решения» со всеми пятью. Внизу подпись: «спор через три месяца закрывается вторым блоком, а не первым».
«Журналы есть, а найти в них ничего нельзя»
Это самая частая жалоба и самый недооценённый расход. Записи ведутся, объём растёт, но в момент разбирательства выясняется, что найти нужное событие невозможно: фильтров нет, поиск только по дате, а выгрузить результат некуда. Такой журнал формально существует и практически бесполезен.
- 1Фильтры по четырём измерениям сразу: пользователь, тип события, объект (номер документа, карточки, заказа) и период. Три из четырёх недостаточно: разбор почти всегда звучит как «что делал вот этот человек вот с этим документом на прошлой неделе».
- 2Поиск по значению внутри записи. Найти все события, где встречается конкретный телефон, номер счёта или сумма. Без него невозможно ответить на вопрос про клиента, у которого сменился менеджер и карточка была объединена с другой.
- 3Выгрузка результата в файл. Найденное придётся приложить к разбору инцидента, отдать юристу или включить в акт. Скриншот экрана таким приложением не является.
- 4Единая лента из нескольких систем с часовым поясом. События CRM, учётной системы и прослойки обмена должны сводиться в один хронологический список. Если время в трёх системах записано в трёх поясах и без указания какого — восстановление хронологии превращается в отдельную работу.
- 5Ссылка на конкретную запись. Чтобы её можно было передать коллеге или вставить в карточку разбора, а не пересказывать своими словами.
Попросите того, кто отвечает за систему, найти, кто и когда менял сумму в конкретном счёте месячной давности. Не «покажите журнал», а именно найти конкретное событие. Если это заняло больше пяти минут или закончилось словами «надо выгружать и смотреть в таблице» — журнал у вас есть, а поиска нет, и в день реального разбирательства он не поможет.
Сколько это стоит и сколько весит
Модельная компания: 60 человек, около 2 800 значимых событий в сутки, плюс ИИ-ассистент с потоком 6 000 обращений в месяц и четырьмя записями решений на каждое обращение.
Для сравнения: журнал обменов, в который пишутся тела запросов и ответов, весит на порядок больше — мы считали его отдельно вместе с требованиями к сквозному идентификатору. Это две разные сущности, и путать их не стоит: журнал обменов отвечает на вопрос «где потерялась заявка», журнал действий — на вопрос «кто это сделал».
Срок хранения, целостность и персональные данные
Срок хранения ставится осознанно и разный для разных групп. Действия пользователей достаточно держать 12 месяцев: спор о том, кто менял сумму, возникает в пределах отчётного года. Выгрузки данных и изменения прав доступа стоит хранить дольше, до трёх лет, — именно они всплывают позже всех, когда бывший сотрудник уже год как работает у конкурента.
- «Храним вечно» — тоже неправильный ответ. Журнал с телефонами, адресами и суммами сам является системой персональных данных со всеми требованиями: серверы в России, ограниченный доступ по списку, шифрование и записанный срок хранения. Бессрочное хранение — это не запас прочности, а расширение зоны риска.
- Тот, кого проверяют, не должен править журнал. В типовых системах администратор технически может очистить журнал регистрации. Поэтому записи выгружаются на отдельный ресурс, куда у него нет прав на запись, — иначе журнал доказывает ровно то, что администратор захотел оставить.
- Журнал у подрядчика — это передача данных подрядчику. Если записи хранятся в его контуре, оформляется поручение обработки с перечнем действий и сроком. Практичнее держать журнал у себя: он всё равно понадобится при смене подрядчика поддержки как одна из передаваемых позиций.
- Пароли и ключи доступа в журнал не пишутся никогда. Ни в каком виде и ни в каком поле. Это правило не имеет исключений, и его стоит проверить выборочно, а не спросить.
Смотрит журнал в компании без службы безопасности администратор системы — та самая роль, которая ведёт справочники и права; что в неё входит и сколько часов она занимает, мы разбирали отдельно. Регулярного чтения журнал не требует: достаточно ежеквартальной сверки активных учётных записей с кадровым списком, пятнадцать минут. Всё остальное чтение происходит по факту — при разборе инцидента, где журнал и есть источник хронологии; семь полей карточки разбора заполняются в основном из него.
Сравнение в две колонки: «Без журнала» и «С журналом». Строки: срок разбирательства (3 недели — 25 минут), кто участвует (9 сотрудников, инженер, юрист, руководитель — один администратор), стоимость (60 500 ₽ — 292 ₽), характер ответа (вероятностный, по косвенным следам — точный, с отметкой времени и объёмом), что можно приложить к акту (ничего — выгрузку записей). Внизу подпись: «настройка журнала стоит 60 000 ₽ и окупается одним разбирательством».
Когда журнал в таком объёме не нужен
Полный состав из пяти групп с настроенным поиском оправдан не везде. Есть четыре ситуации, в которых достаточно штатных средств системы без всякой настройки.
- В системе работают два-три человека и все они — собственники. Вопрос «кто это сделал» здесь не возникает, а хронологию инцидента восстанавливают по памяти за пять минут.
- Система не хранит персональных данных и не оперирует деньгами. Внутренний справочник, календарь загрузки оборудования, планировщик задач — здесь предметом спора нечему быть.
- Данные из системы физически невозможно выгрузить. Если выгрузки нет как функции, самая дорогая группа событий не нужна, и остаются четыре.
- Систему выключают в ближайшие месяцы. Настраивать поиск в контуре, который доживает последний квартал, смысла нет — достаточно один раз выгрузить существующие записи и сохранить их вместе с копией данных.
Во всех остальных случаях помните главное свойство журнала: его нельзя сделать задним числом. Копию можно снять сегодня, документацию написать за неделю, мониторинг включить за день. Записать то, что произошло в прошлом месяце, нельзя ничем — поэтому журнал настраивают в первый месяц эксплуатации, а не в день, когда он понадобился.
Журнал — единственная часть системы, которую нельзя доделать задним числом. Если запись не велась, события не было.
