Panel sztabowy

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

Штабная панель - наш ответ на это напряжение. Один дашборд сводит клиентов VulCode и Aphrodi, обслуживаемых из одного представления, но с жёсткой границей: сотрудник, закреплённый за одним брендом, не видит клиентов другого. К этому добавляется то, о чём рано или поздно спрашивает каждая команда поддержки: кто и когда изменил этот флаг на аккаунте. Это исследование о том, как мы примирили общее ядро с разделением, которое должно держать по-настоящему, а не только выглядеть так.

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

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

Поэтому мы решили, что ядро одно. Клиенты обоих брендов сидят в одном бэк-офисе, на одной модели данных, обслуживаются одним API. Разницу делает не отдельный код, а объём прав, наложенный на общее целое.

Сердце этой панели - контроль доступа, ограниченный по бренду. Роль сотрудника не глобальна. Она привязана к конкретному бренду, и объём его прав кончается ровно на границе этого бренда. Кто-то из команды VulCode видит клиентов VulCode и только их, хотя физически они сидят в том же бэк-офисе, что и клиенты Aphrodi.

Ключевое - где эта граница проверяется. Если бы ограничение было лишь фильтром в интерфейсе, его удалось бы обойти, дописав чужой id в адрес. Поэтому проверка объёма сидит на входе в API и отклоняет запрос прежде, чем он коснётся данных, независимо от того, что показывает или прячет фронтенд.

В панели, где можно пометить аккаунт, изменить ставку комиссии или сдвинуть баланс кошелька, вопрос "кто это сделал" падает неизбежно. Без ответа остаётся гадание задним числом и поиск виноватого по памяти, что и несправедливо, и бесполезно.

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

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

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

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

Команда работает из одного места, а не из двух вкладок браузера, которые надо держать в голове и следить, чтобы они не разошлись. Клиенты обоих брендов там, где должны быть, каждый сотрудник видит ровно свой участок, а граница между брендами держит на уровне API, а не на доброй воле интерфейса.

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

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