Multi-tenancy для MSP: как обслуживать N клиентов в одной helpdesk

Три модели multi-tenancy

1. Database-per-tenant. Каждому клиенту — отдельная БД. Полная изоляция, но высокая стоимость инфраструктуры, отдельные миграции на каждый tenant.
2. Schema-per-tenant. Одна БД, отдельная PostgreSQL-схема для каждого. Дешевле в плане инфраструктуры, изоляция на уровне схемы, но миграции всё ещё надо прогонять на каждой.
3. Row-level (shared schema). Одна БД, одна схема, везде колонка tenant_id. Применяется row-level security (PostgreSQL RLS). Самая дешёвая, самая сложная в плане ошибок (один забытый WHERE — и данные одного клиента видны другому).

Для большинства MSP оптимум — schema-per-tenant. Это даёт правильный баланс изоляции и стоимости.

Брендинг для каждого клиента

Когда у MSP «Acme Support» 5 клиентов, и каждый хочет видеть свой логотип в портале и в исходящих письмах — нужна возможность:

• Кастомный домен для портала: support.client-a.com, support.client-b.com. На DNS — CNAME к одному адресу, на сервере — определять tenant по host.
• Свой логотип и цветовая схема в шапке портала. Хранится в настройках tenant.
• Свой email-домен исходящих писем: support@client-a.com. Требует SMTP-аккаунта клиента (обычно DKIM/SPF записи их домена).
• Свои тексты приветствий, политики, договоры. Каждый tenant — свои legal-документы по ссылкам.

В TIQQET этот сценарий пока реализуется через настройку отдельных инсталляций для каждого клиента — для MSP с 20+ клиентами это нерационально. Полноценный multi-tenancy на одной инсталляции — на roadmap.

Операторская визуализация

Оператор MSP обслуживает несколько клиентов. Ему нужно:

• Видеть все свои заявки независимо от tenant — единая «инбокс».
• В каждой заявке чётко видеть, какой клиент (значок / лого).
• Фильтровать по клиенту: «покажи только Acme сегодня».
• Использовать общие шаблоны ответов, но с возможностью кастомизации по клиенту.

Доступ оператора к tenant'ам определяется через membership. Senior MSP-эксперт может иметь доступ ко всем, junior — только к 2-3 «своим» клиентам.

Биллинг для MSP

MSP оплачивает helpdesk-вендору обычно по одной из моделей:

• По tenant'ам — сколько клиентов ведёт. Например, $100/мес за каждого. Простая модель, но не отражает реального использования.
• По объёму — общее число заявок в месяц. Платишь за то, что реально обрабатываешь.
• По пользователям — общее число USER-аккаунтов во всех tenant. Хорошо когда у каждого клиента маленькая команда.

Со стороны MSP — биллинг своих клиентов. Helpdesk должен позволять:

• Считать заявки и трудозатраты по каждому клиенту (для счетов «за апрель — 47 тикетов, 38 часов»).
• Экспортировать отчёт для бухгалтерии.
• Помечать заявки как «оплачено / в счёте / списано». Простая интеграция с 1С.

Изоляция данных — главное

Главный риск multi-tenancy — пересечение данных. Обязательные меры:

• Каждый API-запрос фильтруется по tenant_id. На уровне ORM — middleware, который инжектит фильтр автоматически.
• Row-level security на уровне БД как защита от ошибок в коде. Если разработчик забыл WHERE — PostgreSQL отрежет на уровне планировщика запросов.
• Аудит cross-tenant попыток. Если оператор tenant'а A открывает заявку tenant'а B — это инцидент безопасности, должен быть алерт.
• Регулярные penetration tests на корректность изоляции — нанимать внешних специалистов раз в год.

Утечка данных одного клиента к другому — фатальна для MSP. Это конец репутации.

SLA и контракты per-tenant

У каждого клиента MSP свой SLA-контракт: одному обещано 4 часа реакции, другому 24, третьему 1 час 24/7. Helpdesk должен:

• Хранить SLA-настройки per-tenant.
• Применять правильные сроки при создании заявки в каждом tenant.
• Рассчитывать с учётом рабочего календаря клиента (Acme — 9-18 Москва, BetaCorp — 8-20 Екатеринбург).
• Считать SLA-compliance per-tenant для отчётности и quarterly business review.

Это реализуется через каталог услуг с per-service SLA — на каждой услуге свой SLA, услуги привязаны к tenant.