Sdílet prostřednictvím

Aspekty životního cyklu tenanta ve víceklientských řešeních

  • Článek

Při zvažování víceklientské architektury je důležité vzít v úvahu všechny různé fáze životního cyklu tenanta. Na této stránce poskytujeme pokyny pro pracovníky technického rozhodování o fázích životního cyklu a důležitých aspektech jednotlivých fází.

Zkušební tenanti

Při vytváření řešení SaaS zvažte, že mnoho zákazníků požádá nebo vyžaduje zkušební verze, než se potvrdí k nákupu řešení.

Zkušební verze přinášejí následující jedinečné aspekty:

  • Požadavky na služby: Měly by zkušební verze podléhat stejným požadavkům na zabezpečení dat, výkon a úroveň služeb, jako jsou data pro úplné zákazníky?
  • Infrastruktura: Měli byste použít stejnou infrastrukturu pro zkušební tenanty jako pro úplné zákazníky, nebo byste měli mít vyhrazenou infrastrukturu pro zkušební tenanty?
  • Migrace: Pokud si zákazníci po zkušební verzi koupí vaši službu, jak budou migrovat data ze zkušebních tenantů do svých placených tenantů?
  • Proces žádosti: Existují omezení ohledně toho, kdo může požádat o zkušební verzi? Jak můžete zabránit zneužití vašeho řešení? Povolíte automatizované vytváření tenantů zkušební verze nebo se váš tým zapojí do každé žádosti?
  • Limity: Jaké limity chcete nebo potřebujete u zákazníků se zkušební verzí, jako jsou časové limity, omezení funkcí nebo omezení týkající se výkonu?

V některých situacích může být cenový model freemium alternativou k poskytování zkušebních verzí.

Onboarding nových tenantů

Při onboardingu nového tenanta zvažte následující otázky:

  • Proces: Bude onboarding samoobslužný, automatizovaný nebo ruční proces?
  • Rezidence dat: Má tenant nějaké specifické požadavky na rezidenci dat? Existují například předpisy týkající se suverenity dat?
  • Dodržování předpisů: Musí tenant splňovat nějaké standardy dodržování předpisů (například PCI DSS, HIPAA atd.)?
  • Zotavení po havárii: Má tenant nějaké specifické požadavky na zotavení po havárii, jako je cíl doby obnovení (RTO) nebo cíl bodu obnovení (RPO)? Liší se od záruk, které poskytujete jiným tenantům?
  • Informace: Jaké informace potřebujete, abyste mohli tenanta plně připojit? Potřebujete třeba znát právní název organizace? Potřebujete logo společnosti k označení aplikace, a pokud ano, jakou velikost a formát souboru potřebujete?
  • Fakturace: Poskytuje platforma různé cenové možnosti a fakturační modely?
  • Prostředí: Vyžaduje tenant předprodukční prostředí? A existují očekávání ohledně dostupnosti pro toto prostředí? Je to přechodné (na vyžádání) nebo vždy k dispozici?

Po onboardingu tenantů se přesunou do "obchodního stavu jako obvykle". Stále však existuje několik důležitých událostí životního cyklu, ke kterým může dojít, i když jsou v tomto stavu.

Aktualizace infrastruktury tenantů

Budete muset zvážit způsob instalace aktualizací na infrastrukturu tenantů. Různí tenanti můžou mít aktualizace použité v různých časech.

Další důležité informace o aktualizaci nasazení tenantů najdete v tématu Aktualizace .

Škálování infrastruktury tenantů

Zvažte, jestli vaši tenanti můžou mít sezónní obchodní vzory, nebo jinak změnit úroveň spotřeby vašeho řešení.

Pokud například poskytnete řešení maloobchodníkům, můžete očekávat, že určité časy v roce budou v některých geografických oblastech obzvláště zaneprázdněné a jindy tiché. Zvažte, jestli tato sezónnost ovlivňuje způsob návrhu a škálování řešení. Mějte na paměti, jak může sezónnost ovlivnit problémy s hlučným sousedem, například když u podmnožina tenantů dojde k náhlému a neočekávanému zvýšení zatížení, které snižuje výkon jiných tenantů. Můžete zvážit použití omezení rizik, která můžou zahrnovat škálování infrastruktury jednotlivých tenantů, přesun tenantů mezi nasazeními a zřízení dostatečné úrovně kapacity pro zvládnutí špiček a škrtů v provozu.

Přesun tenantů mezi infrastrukturou

Tenanty mezi infrastrukturou možná budete muset přesunout z několika důvodů, například:

  • Znovu vyrovnávat: Při mapování tenantů na infrastrukturu postupujete svisle děleným přístupem a pokud chcete znovu vyrovnávat zatížení, musíte tenanta přesunout do jiného nasazení.
  • Upgrady: Tenant upgraduje svou skladovou položku nebo cenovou úroveň a je potřeba je přesunout do vyhrazeného nasazení s jedním tenantem s vyšší izolací od ostatních tenantů.
  • Migrace: Tenant požádá o přesun dat do vyhrazeného úložiště dat.
  • Přesuny oblastí: Tenant vyžaduje přesun dat do nové geografické oblasti. K tomuto požadavku může dojít během získávání společnosti nebo při změně zákonů nebo geopolitických situací.

Zvažte, jak přesunete data tenantů a jak přesměrujete požadavky na novou sadu infrastruktury, která je hostitelem jejich instance. Měli byste také zvážit, jestli přesunutí tenanta může vést k výpadku a zajistit, aby tenanti plně věděli o riziku.

Sloučení a rozdělení tenantů

Je lákavé uvažovat o tenantech nebo zákaznících jako statických neměnných entit. Ve skutečnosti to ale často není pravdivé. Příklad:

  • V obchodních scénářích mohou být společnosti získány nebo sloučeny, včetně společností umístěných v různých geografických oblastech.
  • V obchodních scénářích můžou společnosti rozdělit nebo rozdělit.
  • V spotřebitelských scénářích se můžou jednotliví uživatelé připojovat nebo opustit rodiny.

Zvažte, jestli potřebujete poskytnout možnosti pro správu slučování a oddělení dat, identit uživatelů a prostředků. Zvažte také, jak vlastnictví dat ovlivňuje vaše zpracování operací sloučení a rozdělení. Představte si například aplikaci pro fotografii spotřebitele vytvořenou pro rodiny, která bude sdílet fotky s ostatními. Jsou fotky vlastněné jednotlivými členy rodiny, kteří je přispěli, nebo rodinou jako celku? Pokud uživatelé opustí rodinu, měli by se jejich data odebrat nebo zůstat v sadě dat rodiny? Pokud se uživatelé připojí k jiné rodině, měli by se s nimi jejich staré fotky přesouvat?

Offboard tenanty

Je také nevyhnutelné, že tenanti budou občas muset z vašeho řešení odebrat. Ve víceklientských řešeních to přináší několik důležitých aspektů, včetně následujících:

  • Doba uchovávání: Jak dlouho byste měli uchovávat zákaznická data? Existují právní požadavky na zničení dat po určité době?
  • Opětovné zprovoznění: Měli byste zákazníkům poskytnout možnost opětovného zprovoznění? Budou jim jejich data stále k dispozici, pokud se znovu připojí v rámci doby uchovávání dat?
  • Vyrovnávání: Pokud spouštíte sdílenou infrastrukturu, potřebujete znovu vyvážit přidělení tenantů k infrastruktuře?

Deaktivace a opětovná aktivace tenantů

Existují situace, kdy může být potřeba deaktivovat nebo znovu aktivovat účet zákazníka. Příklad:

  • Zákazník požádal o deaktivaci. V systému příjemců se zákazník může rozhodnout odhlásit odběr.
  • Zákazník se nedá fakturovat a musíte předplatné deaktivovat.

Deaktivace je oddělená od offboardingu v tom, že má být dočasným stavem. Po určité době se ale můžete rozhodnout deaktivovaného tenanta zrušit.

Přispěvatelé

Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.

Hlavní autor:

Další přispěvatelé:

Pokud chcete zobrazit neveřejné profily LinkedIn, přihlaste se na LinkedIn.

Další kroky

Zvažte cenové modely, které budete pro své řešení používat.