Dela via

Överväganden för att uppdatera en lösning med flera klienter

  • Artikel

En av fördelarna med molnteknik är kontinuerlig förbättring och utveckling. Som tjänstleverantör måste du tillämpa uppdateringar på din lösning: du kan behöva göra ändringar i programkoden, Din Azure-infrastruktur, dina databasscheman eller någon annan komponent. Det är viktigt att planera hur du uppdaterar dina miljöer. I en lösning med flera klienter är det särskilt viktigt att vara tydlig med din uppdateringsprincip eftersom vissa av dina klienter kan vara ovilliga att tillåta ändringar i sina miljöer, eller så kan de ha krav som begränsar de villkor under vilka du kan uppdatera tjänsten.

När du planerar en strategi för att uppdatera din lösning måste du:

  • Identifiera dina klientorganisationers krav.
  • Förtydliga dina egna krav för att driva din tjänst.
  • Hitta en balans som både du och dina klienter kan acceptera.
  • Förmedla din strategi tydligt till dina klienter och andra intressenter.

I den här artikeln ger vi vägledning för tekniska beslutsfattare om de metoder som du kan överväga för att uppdatera klientorganisationens programvara och de kompromisser som är inblandade.

Dina kunders krav

Kunder har ofta explicita eller implicita krav som kan påverka hur systemet uppdateras. Överväg följande aspekter för att skapa en bild av eventuella problem som kunder kan ta upp:

  • Förväntningar och krav: Upptäck eventuella förväntningar eller krav som kunderna kan ha om när deras lösning kan uppdateras. Dessa kan formellt meddelas dig i kontrakt eller serviceavtal, eller så kan de vara informella.
  • Underhållsperioder: Förstå om dina kunder förväntar sig tjänstdefinierade eller till och med självdefinierade underhållsperioder. De kan behöva kommunicera med sina användare om eventuella avbrott, eller så kan de behöva testa viktiga aspekter av din tjänst när uppdateringen är klar.
  • Föreskrifter: Förtydliga om kunderna har några regelproblem som kräver ytterligare godkännande innan uppdateringar kan tillämpas. Om du till exempel tillhandahåller en hälsolösning som innehåller IoT-komponenter kan du behöva få godkännande från UNITED States Food and Drug Administration (FDA) innan du tillämpar en uppdatering.
  • Känslighet: Förstå om någon av dina kunder är särskilt känsliga eller resistenta mot att uppdateringar tillämpas. Om de är det, försök att förstå varför. Om de till exempel kör en fysisk butik eller en detaljhandelswebbplats kanske de vill undvika uppdateringar runt Black Friday, eftersom riskerna är högre än potentiella fördelar.
  • Historik: Granska din egen meritlista för att slutföra uppdateringar utan att påverka dina kunder. Du bör följa bra metoder för DevOps, testning, distribution och övervakning för att minska risken för avbrott och för att säkerställa att du snabbt identifierar eventuella problem som uppdateringar introducerar. Om dina kunder vet att du kan uppdatera deras miljöer smidigt är det mindre troligt att de invänder.
  • Återställning: Överväg om kunder vill återställa uppdateringar om det sker en icke-bakåtkompatibel ändring och vem som skulle utlösa en sådan återställningsbegäran.

Dina krav

Du måste också tänka på följande frågor ur ditt eget perspektiv:

  • Kontroll som du är villig att tillhandahålla: Är det rimligt att dina kunder har kontroll över när uppdateringar tillämpas? Om du skapar en lösning som används av stora företagskunder kan svaret vara ja. Men om du skapar en konsumentfokuserad lösning är det osannolikt att du ger någon kontroll över hur du uppgraderar eller använder din lösning.
  • Versioner: Hur många versioner av din lösning kan du underhålla på en gång? Kom ihåg att om du hittar en bugg och behöver snabbkorrigeringar kan du behöva använda snabbkorrigeringen på alla versioner som används.
  • Konsekvenser av gamla versioner: Vad är effekten av att låta kunderna hamna för långt efter den aktuella versionen? Kommer gamla versioner att bli föråldrade snabbt om du släpper nya funktioner regelbundet? Beroende på din uppgraderingsstrategi och typen av ändringar kan du också behöva underhålla separata infrastrukturer för varje version av lösningen. Det kan därför finnas både driftskostnader och ekonomiska kostnader eftersom du har stöd för äldre versioner.
  • Återställning: Kan distributionsstrategin stödja återställningar till tidigare versioner? Är det här något du vill aktivera?

Kommentar

Fundera på om du behöver ta lösningen offline för uppdateringar eller underhåll. I allmänhet ses avbrottsfönster som en föråldrad metod, och moderna DevOps-metoder och molntekniker gör att du kan undvika driftstopp under uppdateringar och underhåll. Du måste dock utforma för distributioner utan driftstopp, så det är viktigt att tänka på din uppdateringsprocess när du planerar din lösningsarkitektur.

Även om du inte planerar avbrott under uppdateringsprocessen kan du fortfarande överväga att definiera ett regelbundet underhållsperiod. Ett fönster kan hjälpa dig att kommunicera med dina kunder om att ändringar sker under specifika tider.

Mer information om hur du uppnår distributioner med noll driftstopp finns i Eliminera stilleståndstid via versionsbaserade tjänstuppdateringar.

Hitta ett saldo

Om du lämnar dina tjänstuppdateringar helt till klientorganisationens gottfinnande kan de välja att aldrig uppdatera. Det är viktigt att tillåta dig själv att uppdatera din lösning, samtidigt som du tar hänsyn till eventuella rimliga problem eller begränsningar som dina kunder kan ha. Om en kund till exempel är särskilt känslig för uppdateringar på en fredag eftersom det är deras mest trafikerade dag i veckan, kan du lika enkelt skjuta upp uppdateringar till måndagar utan att påverka din lösning?

En metod som kan fungera bra är att distribuera uppdateringar per klientorganisation, med någon av de metoder som beskrivs nedan. Meddela kunden om planerade uppdateringar. Tillåt kunder att tillfälligt välja bort, men inte för evigt; sätta en rimlig gräns för när du kommer att kräva att uppdateringen tillämpas.

Överväg också att tillåta dig själv att distribuera säkerhetskorrigeringar eller andra kritiska snabbkorrigeringar, med minimal eller ingen förvarning. Se till att klientorganisationer förstår den här metoden och dess betydelse för att skydda sina data.

En annan metod kan vara att tillåta klientorganisationer att initiera sina egna uppdateringar, vid en tidpunkt som de väljer. Återigen bör du ange en tidsgräns, då du tillämpar uppdateringen för deras räkning.

Varning

Var försiktig med att göra det möjligt för klientorganisationer att initiera sina egna uppdateringar. Detta är komplext att implementera och kräver betydande utvecklings- och testningsarbete för att leverera och underhålla.

Vad du än gör bör du se till att du har en process för att övervaka hälsotillståndet för dina klienter, särskilt före och efter att uppdateringar har tillämpats. Ofta inträffar kritiska produktionsincidenter (kallas även live-platsincidenter) efter uppdateringar av kod eller konfiguration. Därför är det viktigt att du proaktivt övervakar och svarar på eventuella problem för att behålla kundernas förtroende. Mer information om övervakning finns i Rekommendationer för att utforma och skapa ett övervakningssystem.

Kommunicera med dina kunder

Tydlig kommunikation är nyckeln till att skapa kundernas förtroende. Det är viktigt att förklara fördelarna med regelbundna uppdateringar, inklusive nya funktioner, felkorrigeringar, lösning av säkerhetsrisker och prestandaförbättringar. En av fördelarna med en modern molnbaserad lösning är den pågående leveransen av funktioner och uppdateringar.

Överväg följande frågor:

  • Kommer du att meddela kunderna om kommande uppdateringar?
  • Om du gör det begär du implicit behörighet genom att tillhandahålla en avaktiveringsprocess och vilka är gränserna för att avregistrera dig?
  • Har du ett schemalagt underhållsperiod som du använder när du tillämpar uppdateringar?
  • Vad händer om du har en nödsituationsuppdatering, som en kritisk säkerhetskorrigering? Kan du framtvinga uppdateringar i sådana situationer?
  • Om du inte proaktivt kan meddela kunden om kommande uppdateringar, kan du ge retroaktiva meddelanden? Kan du till exempel uppdatera en sida på din webbplats med listan över uppdateringar som du har tillämpat?
  • Hur många separata versioner av systemet kommer du att underhålla i produktion?

Kommunicera med kundsupportteamet

Det är viktigt att ditt eget supportteam har fullständig insyn i uppdateringar som har tillämpats på varje klientorganisations infrastruktur. Kundsupportrepresentanter bör enkelt kunna svara på följande frågor:

  • Har uppdateringar nyligen tillämpats på en klientorganisations infrastruktur eller på delade komponenter?
  • Vad var det för typ av uppdateringar?
  • Vilken var den tidigare versionen?
  • Hur ofta tillämpas uppdateringar på den här klientorganisationen?

Om en av dina kunder har problem på grund av en uppdatering måste du se till att kundsupportteamet har den information som krävs för att förstå vad som har ändrats.

Distributionsstrategier för att stödja uppdateringar

Överväg hur du ska distribuera uppdateringar till infrastrukturen. Detta påverkas starkt av den innehavarmodell som du använder. Tre vanliga metoder för att distribuera uppdateringar är distributionsstämplar, funktionsflaggor och distributionsringar. Du kan använda dessa metoder oberoende av varandra, eller så kan du kombinera dem för att uppfylla mer komplexa krav.

Se alltid till att du har tillräcklig rapportering och synlighet, så att du vet vilken version av infrastruktur, programvara eller funktion som varje klientorganisation är på, vad de är berättigade att migrera till och alla tidsrelaterade data som är associerade med dessa tillstånd.

Mönster för distributionsstämplar

Många program med flera klienter passar bra för mönstret Distributionsstämplar, där du distribuerar flera kopior av ditt program och andra komponenter. Beroende på dina isoleringskrav kan du distribuera en stämpel för varje klientorganisation eller delade stämplar som kör flera klientorganisationers arbetsbelastningar.

Stämplar är ett bra sätt att tillhandahålla isolering mellan klienter. De ger dig också flexibilitet för din uppdateringsprocess, eftersom du kan distribuera uppdateringar progressivt över stämplar, utan att påverka andra.

Funktionsflaggor

Med funktionsflaggor kan du lägga till funktioner i din lösning, samtidigt som du endast exponerar den funktionen för en delmängd av dina kunder eller klienter.

Överväg att använda funktionsflaggor om någon av dessa situationer gäller för dig:

  • Du distribuerar uppdateringar regelbundet men vill undvika att visa nya funktioner tills de har implementerats fullt ut.
  • Du vill undvika att tillämpa ändringar i beteendet tills en kund väljer att göra det.

Du kan bädda in stöd för funktionsflagga i ditt program genom att skriva kod själv eller med hjälp av en tjänst som Azure App Configuration.

Distributionsringar

Med distributionsringar kan du stegvis distribuera uppdateringar över en uppsättning klienter eller distributionsstämplar. Du kan tilldela en delmängd av klientorganisationer till varje ring.

Du kan avgöra hur många ringar som ska skapas och vad varje ring betyder för din egen lösning. Organisationer använder vanligtvis följande ringar:

  • Canary: En kanariering innehåller dina egna testklientorganisationer och kunder som vill ha uppdateringar så snart de är tillgängliga, med förståelse för att de kan få mer frekventa uppdateringar och att uppdateringar kanske inte har gått igenom en så omfattande valideringsprocess som i andra saker.
  • Tidig användare: En tidig adopterring innehåller klienter som är något mer riskvilliga, men som fortfarande är beredda att ta emot regelbundna uppdateringar.
  • Användare: De flesta av dina klienter tillhör användarringen , som får mindre frekventa och mer testade uppdateringar.

API-versioner

Om din tjänst exponerar ett externt API kan eventuella uppdateringar som du tillämpar påverka hur kunder eller partner integreras med din plattform. I synnerhet måste du vara medveten om icke-bakåtkompatibla ändringar i dina API:er. Överväg att använda en API-versionshanteringsstrategi för att minska risken för uppdateringar av ditt API.

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.

Gå vidare

Tänk på när du skulle mappa begäranden till klientorganisationer i en lösning med flera klienter.