Dela via


Överväganden för klientlivscykel i en lösning med flera klienter

När du överväger en arkitektur för flera klienter är det viktigt att du överväger alla de olika stegen i en klients livscykel. På den här sidan ger vi vägledning för tekniska beslutsfattare om faserna i livscykeln och de viktiga övervägandena för varje steg.

Utvärderingsklientorganisationer

När du skapar en SaaS-lösning bör du tänka på att många kunder begär eller kräver utvärderingsversioner innan de förbinder sig att köpa en lösning.

Utvärderingsversioner medför följande unika överväganden:

  • Tjänstkrav: Ska utvärderingsversioner omfattas av samma krav på datasäkerhet, prestanda och tjänstnivå som data för fullständiga kunder?
  • Infrastruktur: Ska du använda samma infrastruktur för utvärderingsklientorganisationer som för fullständiga kunder, eller ska du ha dedikerad infrastruktur för utvärderingsklientorganisationer?
  • Migrering: Hur migrerar kunderna data från sina utvärderingsklientorganisationer till sina betalda klienter om kunderna köper din tjänst efter en utvärderingsversion?
  • Begärandeprocess: Finns det gränser för vem som kan begära en utvärderingsversion? Hur kan du förhindra missbruk av din lösning? Tillåter du automatiskt skapande av utvärderingsklientorganisationer eller engagerar sig ditt team i varje begäran?
  • Gränser: Vilka gränser vill eller behöver du använda för utvärderingskunder, till exempel tidsgränser, funktionsbegränsningar eller begränsningar kring prestanda?

I vissa situationer kan en freemium-prismodell vara ett alternativ till att tillhandahålla utvärderingsversioner.

Registrera nya klienter

När du registrerar en ny klientorganisation bör du tänka på följande frågor:

  • Process: Kommer registrering att vara en självbetjäning, automatiserad eller manuell process?
  • Datahemvist: Har klientorganisationen några specifika krav för datahemvist? Gäller till exempel regler för datasuveränitet?
  • Efterlevnad: Måste klientorganisationen uppfylla några efterlevnadsstandarder (till exempel PCI DSS, HIPAA och så vidare)?
  • Haveriberedskap: Har klientorganisationen några specifika krav på haveriberedskap, till exempel ett mål för återställningstid (RTO) eller ett mål för återställningspunkt (RPO)? Skiljer du dig från de garantier som du ger andra klienter?
  • Information: Vilken information behöver du för att kunna registrera klientorganisationen fullt ut? Behöver du till exempel känna till organisationens juridiska namn? Behöver du företagets logotyp för att märka programmet, och i så fall vilken filstorlek och format behöver du?
  • Fakturering: Tillhandahåller plattformen olika prisalternativ och faktureringsmodeller?
  • Miljöer: Kräver klientorganisationen förproduktionsmiljöer? Och finns det förväntningar på tillgänglighet för den miljön? Är det tillfälligt (på begäran) eller alltid tillgängligt?

När klientorganisationer har registrerats flyttas de till ett "business as usual"-tillstånd. Det finns dock fortfarande flera viktiga livscykelhändelser som kan inträffa, även när de är i det här tillståndet.

Uppdatera klientorganisationens infrastruktur

Du måste överväga hur du tillämpar uppdateringar på klientorganisationens infrastruktur. Olika klienter kan ha uppdateringar som tillämpas vid olika tidpunkter.

Mer information om hur du uppdaterar klientdistributioner finns i Uppdateringar .

Skala klientorganisationens infrastruktur

Överväg om dina klienter kan ha säsongsbaserade affärsmönster eller på annat sätt ändra förbrukningsnivån för din lösning.

Om du till exempel tillhandahåller en lösning för återförsäljare kan du förvänta dig att vissa tider på året kommer att vara särskilt upptagna i vissa geografiska regioner och tysta vid andra tillfällen. Fundera på om den här säsongsvariationen påverkar hur du utformar och skalar din lösning. Tänk på hur säsongsvariationer kan påverka problem med bullriga grannar, till exempel när en delmängd av klientorganisationer upplever en plötslig och oväntad ökning av belastningen som minskar prestandan för andra klienter. Du kan överväga att tillämpa åtgärder, som kan omfatta skalning av enskilda klientorganisationers infrastruktur, flytt av klientorganisationer mellan distributioner och etablering av en tillräcklig kapacitetsnivå för att hantera toppar och dalar i trafiken.

Flytta klienter mellan infrastrukturer

Du kan behöva flytta klienter mellan infrastrukturen av flera orsaker, till exempel:

  • Ombalansering: Du följer en vertikalt partitionerad metod för att mappa dina klienter till infrastrukturen och du måste flytta en klientorganisation till en annan distribution för att balansera om belastningen.
  • Uppgraderingar: En klientorganisation uppgraderar sin SKU eller prisnivå och måste flyttas till en dedikerad distribution med en enda klientorganisation med högre isolering från andra klienter.
  • Migreringar: En klientorganisation begär att deras data flyttas till ett dedikerat datalager.
  • Regionflytt: En klientorganisation kräver att deras data flyttas till en ny geografisk region. Detta krav kan uppstå under ett företagsförvärv, eller när lagar eller geopolitiska situationer ändras.

Fundera på hur du flyttar klientorganisationens data och hur du omdirigerar begäranden till den nya uppsättningen infrastruktur som är värd för deras instans. Du bör också överväga om en flytt av en klientorganisation kan leda till stilleståndstid och se till att klienterna är fullt medvetna om risken.

Sammanfoga och dela klientorganisationer

Det är frestande att betrakta klienter eller kunder som statiska, oförändrade entiteter. Men i verkligheten är detta ofta inte sant. Till exempel:

  • I affärsscenarier kan företag förvärvas eller slås samman, inklusive företag i olika geografiska regioner.
  • I affärsscenarier kan företag dela upp eller avyttra.
  • I konsumentscenarier kan enskilda användare ansluta sig till eller lämna familjer.

Fundera på om du behöver tillhandahålla funktioner för att hantera sammanslagning och separation av data, användaridentiteter och resurser. Tänk också på hur dataägarskapet påverkar din hantering av sammanslagnings- och delningsåtgärder. Överväg till exempel ett program för konsumentfotografering som skapats för familjer att dela foton med varandra. Ägs bilderna av de enskilda familjemedlemmar som bidrog med dem, eller av familjen som helhet? Om användarna lämnar familjen, bör deras data tas bort eller finnas kvar i familjens datauppsättning? Om användarna går med i en annan familj, bör deras gamla foton flyttas med dem?

Avregistrera klientorganisationer

Det är också oundvikligt att klienter ibland måste tas bort från din lösning. I en lösning med flera klienter medför detta några viktiga överväganden, bland annat följande:

  • Kvarhållningsperiod: Hur länge ska du underhålla kunddata? Finns det juridiska krav för att förstöra data efter en viss tidsperiod?
  • Återregistrering: Bör du ge kunderna möjlighet att återregistreras? Kommer deras data fortfarande att vara tillgängliga för dem om de återansluts inom datakvarhållningsperioden?
  • Ombalansering: Om du kör delad infrastruktur behöver du balansera om allokeringen av klienter till infrastrukturen?

Inaktivera och återaktivera klienter

Det finns situationer där en kunds konto kan behöva inaktiveras eller återaktiveras. Till exempel:

  • Kunden har begärt inaktivering. I ett konsumentsystem kan en kund välja att avbryta prenumerationen.
  • Kunden kan inte faktureras och du måste inaktivera prenumerationen.

Inaktivering är separat till offboarding eftersom det är avsett att vara ett tillfälligt tillstånd. Men efter en viss tid kan du välja att avregistrera en inaktiverad klientorganisation.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudförfattare:

Övriga medarbetare:

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg

Överväg de prismodeller som du kommer att använda för din lösning.