Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
При рассмотрении мультитенантной архитектуры важно учитывать все различные этапы жизненного цикла клиента. На этой странице мы предоставляем рекомендации для технических лиц, принимающих решения, о этапах жизненного цикла и важных соображениях для каждого этапа.
Пробные клиенты
При создании решения SaaS следует учитывать, что многие клиенты запрашивают или требуют пробных версий перед покупкой решения.
Тесты подразумевают следующие уникальные соображения:
- Требования к службе: Должны ли пробные версии соответствовать тем же требованиям к безопасности данных, производительности и уровню обслуживания, что и данные для полных клиентов?
- Инфраструктура: Следует ли использовать ту же инфраструктуру для пробных клиентов, что и для полных клиентов, или следует ли использовать выделенную инфраструктуру для пробных клиентов?
- Миграция: Если клиенты приобретут службу после пробной версии, как они переносят данные из своих пробных клиентов в платные клиенты?
- Процесс запроса: Существуют ли ограничения относительно того, кто может запросить пробную версию? Как предотвратить злоупотребление решением? Разрешаете ли вы автоматическое создание пробных арендаторов или ваша команда участвует в каждом запросе?
- Ограничения: Какие ограничения нужно или нужно разместить на пробных клиентах, таких как ограничения времени, ограничения функций или ограничения производительности?
В некоторых ситуациях модель ценообразования freemium может быть альтернативой предоставлению пробных версий.
Подключение новых клиентов
При подключении нового клиента рассмотрите следующие вопросы:
- Процесс: Будет ли подключение самообслуживанием, автоматизированным или ручным процессом?
- Место расположения данных: Имеет ли клиент какие-либо конкретные требования к месту размещения данных? Например, существуют ли правила суверенитета данных?
- Согласие: Должен ли клиент соответствовать любым стандартам соответствия (например, PCI DSS, HIPAA и т. д.)?
- Аварийное восстановление: Есть ли у клиента определенные требования к аварийному восстановлению, такие как цель времени восстановления (RTO) или цель точки восстановления (RPO)? Отличаются ли они от гарантий, предоставляемых другим клиентам?
- Информация: Какие сведения требуются, чтобы иметь возможность полностью интегрировать арендатора? Например, вам нужно знать юридическое имя своей организации? Вам нужен логотип компании для фирменной символики приложения, и если да, какой размер файла и формат вам нужен?
- Выставления счетов: Предоставляет ли платформа различные варианты ценообразования и модели выставления счетов?
- Среды: Требуются ли арендатору предварительные среды? И есть ли установленные ожидания по доступности для этой среды? Является ли она временной (по запросу) или всегда доступна?
После подключения клиентов они переходят в состояние "бизнес как обычно". Однако существует еще несколько важных событий жизненного цикла, которые могут возникать, даже если они находятся в этом состоянии.
Обновление инфраструктуры арендаторов
Вам потребуется учитывать, как вы применяете обновления к инфраструктуре арендаторов. Разные клиенты могут применять обновления в разное время.
Чтобы ознакомиться с другими аспектами обновления развертываний арендаторов, см. раздел "Обновления".
Масштабирование инфраструктуры арендаторов
Рассмотрите, могут ли арендаторы иметь сезонные бизнес-шаблоны или изменить уровень потребления вашего решения.
Например, если вы предоставляете решение для розничных торговцев, вы можете ожидать, что определенные времена года будут особенно заняты в некоторых географических регионах, и тихо в другое время. Рассмотрите, влияет ли эта сезонность на способ разработки и масштабирования решения. Имейте в виду, как сезонность может повлиять на шумные проблемы соседей, например, когда подмножество клиентов испытывает внезапное и неожиданное увеличение нагрузки, что снижает производительность других клиентов. Вы можете рассмотреть возможность применения мер по смягчению, которые могут включать масштабирование инфраструктуры отдельных клиентов, перевод клиентов между различными развертываниями и подготовку достаточного уровня ресурсов для обработки пиков и спадов в трафике.
Перемещение арендаторов между инфраструктурами
Возможно, потребуется переместить клиентов между инфраструктурой по нескольким причинам, например:
- Перебалансирование: Вы следуете вертикально секционированному подходу, чтобы сопоставить арендаторов с инфраструктурой, и необходимо перенести арендатора в другое развертывание, чтобы перебалансировать нагрузку.
- Обновления: Клиент обновляет номер SKU или ценовую категорию, и их необходимо переместить в однотенантное выделенное развертывание с более высокой изоляцией от других клиентов.
- Миграции: Клиент запрашивает перемещение данных в выделенное хранилище данных.
- Перемещение региона: Клиенту требуется переместить данные в новый географический регион. Это требование может возникнуть во время приобретения компании или при изменении законов или геополитических ситуаций.
Подумайте о том, как перемещать данные ваших клиентов и как вы будете перенаправлять запросы на новый набор инфраструктуры, где размещаются их экземпляры. Также следует учитывать, может ли перемещение клиента привести к простою и убедиться, что клиенты полностью осведомлены о риске.
Объединение и разделение арендаторов
Это заманчиво думать об арендаторах или клиентах как о статических, неизменных сущностях. Однако в действительности это часто не так. Рассмотрим пример.
- В бизнес-сценариях компании могут быть приобретены или слиянием, включая компании, расположенные в разных географических регионах.
- В бизнесе компании могут разделяться или дивестировать.
- В сценариях потребителей отдельные пользователи могут присоединяться или покидать семьи.
Рассмотрите необходимость предоставления возможностей для управления слиянием и разделением данных, удостоверений пользователей и ресурсов. Кроме того, рассмотрим, как владение данными влияет на обработку операций слияния и разделения. Например, рассмотрим приложение для фотографии потребителей, созданное для семей, чтобы поделиться фотографиями друг с другом. Принадлежат ли фотографии конкретным членам семьи, которые их предоставили, или семье в целом? Если пользователи покидают семью, их данные следует удалить или остаться в наборе данных семьи? Если пользователи присоединяются к другой семье, должны ли их старые фотографии перемещаться с ними?
Завершение аренды арендаторов
Также неизбежно, что арендаторов иногда придется удалить из вашего решения. В мультитенантном решении это приводит к некоторым важным соображениям, включая следующие:
- Период хранения: Сколько времени следует поддерживать данные клиента? Существуют ли юридические требования к уничтожению данных через определенный период времени?
- Повторное подключение: Следует ли предоставить клиентам возможность повторно подключиться? Будут ли их данные по-прежнему доступны для них, если они повторно присоединиться в течение периода хранения данных?
- Перебалансирование: Если вы управляете общей инфраструктурой, вам нужно перебалансировать распределение арендаторов в инфраструктуру?
Деактивация и повторная активация клиентов
Существуют ситуации, когда учетная запись клиента может потребоваться деактивировать или повторно активировать. Рассмотрим пример.
- Клиент запросил деактивацию. В потребительской системе клиент может отказаться от подписки.
- Нельзя выставить счет клиенту, и вам нужно отменить подписку.
Деактивация отличается от процесса увольнения тем, что она предназначена быть временным состоянием. Однако через некоторое время вы можете решить удалить деактивированного арендатора.
Соавторы
Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.
Основной автор:
- Джон Даунс | Главный инженер программного обеспечения
Другие участники:
- Чад Киттель | Главный инженер программного обеспечения
- Паоло Сальватори | Главный инженер клиента, FastTrack для Azure
- Арсен Владимирский | Главный инженер по работе с клиентами, FastTrack для Azure
Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.
Дальнейшие действия
Рассмотрим модели ценообразования , которые будут использоваться для вашего решения.