Глава 06

Память и репутация

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

Память — это основной режим работы сообщества, не вспомогательная функция. Платформа, которая обращается с историей как со вторичным артефактом (бэкапом, журналом, архивом), проигрывает платформе, в которой история первична.

Event Sourcing как архитектурное решение

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

ComUnify устроен иначе. Базовая единица хранения — не состояние, а событие. Событие — это запись о том, что произошло: «такого-то числа такой-то участник подал такую-то заявку», «такого-то числа состоялось такое-то голосование с таким-то результатом», «такого-то числа на лицевом счёте участника появились такие-то деньги». Штатным путём приложения события не перезаписываются и не удаляются — их можно только дополнять новыми событиями.

Event Sourcing — архитектурный подход, при котором текущее состояние системы вычисляется воспроизведением всех событий с момента её начала. Это позволяет в любой момент посмотреть на состояние системы на любую дату в прошлом — для аудита, для разрешения споров, для восстановления. В ComUnify состояние хранится как события плюс снапшоты; снапшот — кэш для скорости, не замена истории.

Из этой архитектуры вытекают свойства, которые в обычной системе либо отсутствуют, либо требуют отдельной разработки.

Time travel. Можно посмотреть состояние сообщества на любой день. Кто был членом кооператива второго марта прошлого года. Кто за что голосовал на собрании год назад. Сколько было денег на казне в первый день текущего квартала.

Никаких задним числом. Штатный путь приложения не перезаписывает событие — запись о голосовании нельзя «исправить» через месяц через интерфейс. Если решение оспаривается, оформляется новое событие (отменяющее первое с указанием причины), либо первое стоит, как было. Историю можно только дополнять.

Аудитируемость по требованию. Любая операция может быть проверена в её историческом контексте. Сколько денег было на счёте перед спорной транзакцией. Кто голосовал в спорный момент. Когда и кем выдано спорное разрешение.

Снапшоты для производительности

Хранить все события с начала времён и воспроизводить их при каждом запросе — медленно. Поэтому ComUnify периодически создаёт снапшоты — сохранённые состояния на конкретный момент, от которых восстанавливаются дальнейшие события. Снапшот — это не подмена истории, а её точка кэширования. Сами события остаются в журнале.

Производительность Event Sourcing — отдельная инженерная задача. В текущих объёмах платформы (десятки участников в сообществе) она не является проблемой. При росте до сотен решается снапшотами; при росте до десятков тысяч потребуется шардирование и более агрессивные стратегии — эти подходы в архитектуре заложены, но не активированы, потому что сейчас нет сообществ такого размера.

Репутация как длинный процесс

Репутация — это не «оценка от одного до пяти». Это история взаимодействий участника с сообществом и его конкретными членами, накопленная за всё время участия. В работающей системе репутация отвечает на конкретные вопросы:

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

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

Поручительство как мост к новым участникам

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

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

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

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

Что это даёт сообществу

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

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

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