Att tänka på när du uppdaterar en lösning för flera olika i samma miljö

  • Artikel
  • 7 minuter för att läsa

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 Din Azure-infrastruktur, din kod/dina program, dina databasscheman eller någon annan komponent. Det är viktigt att planera hur du uppdaterar dina miljöer. I en lösning för flera klienter är det särskilt viktigt att vara tydlig med uppdateringsprincipen, eftersom vissa av dina klienter kanske inte vill tillåta ändringar i sina miljöer, eller så kan de ha krav som begränsar de tider då du kan uppdatera deras tjänster. Du måste identifiera klientorganisationens krav, tydliggöra dina egna krav för att driva tjänsten, hitta en balans som fungerar för alla och sedan kommunicera detta tydligt. På den här sidan ger vi vägledning till tekniska beslutsfattare om de metoder som du kan överväga för att uppdatera klientorganisationens programvara och de kompromisser som ingår.

Dina kunders krav

Överväg följande frågor:

  • Har kunderna förväntningar eller krav på när de kan uppdateras? Dessa kan formellt meddelas dig i kontrakt eller serviceavtal, eller så kan de vara informella.
  • Förväntar sig kunderna servicedefinierade eller till och med självdefinierade underhållsfönster? De kan behöva kommunicera med sina egna kunder om eventuella avbrott.
  • Har kunderna 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 USA Food and Drug Administration (FIRMWARE) innan du tillämpar en uppdatering.
  • Är någon av dina kunder särskilt känslig eller motståndskraftig mot att tillämpa uppdateringar? Försök att förstå varför. Om de till exempel kör en fysisk butik eller en butikswebbplats kanske de vill undvika uppdateringar kring Black Friday, eftersom riskerna är högre än potentiella fördelar.
  • Vad har du för resultat av att slutföra uppdateringar utan att påverka dina kunder? Du bör följa bra DevOps-, testnings-, distributions- och övervakningsmetoder för att minska risken för avbrott och se till att du snabbt kan identifiera eventuella problem som uppdateringar inför. Om dina kunder vet att du kan uppdatera deras miljöer på ett smidigt sätt är det mindre troligt att de har objekt.
  • Kommer kunderna att vilja återställa uppdateringar om det finns en stor ändring?

Dina krav

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

  • Är det rimligt att dina kunder har kontroll över när uppdateringar tillämpas? Om du skapar en lösning som används av kunder i stora företag kan svaret vara Ja. Men om du skapar en konsumentfokuserad lösning ger du förmodligen inte någon kontroll över hur du uppgraderar eller använder din lösning.
  • Hur många versioner av din lösning kan du rimligen underhålla samtidigt? Kom ihåg att om du hittar en bugg och behöver snabbkorrigeringar kan du behöva tillämpa snabbkorrigeringen på alla versioner som används.
  • Vilka är konsekvenserna 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 vilka typer av ändringar du har kan du dessutom behöva underhålla separata infrastrukturer för varje version av lösningen. Det kan därför finnas både operativa och ekonomiska kostnader, eftersom du har stöd för äldre versioner.
  • Kan din distributionsstrategi stödja återställningar till tidigare versioner? Vill du aktivera det här?

Anteckning

Överväg om du behöver ta din lösning offline för uppdateringar eller underhåll. I allmänhet ses avbrottsfönster som en inaktuell metod, och med moderna DevOps-metoder och molntekniker kan du undvika driftstopp under uppdateringar och underhåll. Du måste designa för detta, så det är viktigt att tänka på uppdateringsprocessen när du utformar din lösningsarkitektur. Observera att även om du inte planerar för avbrott kan du ändå överväga att definiera en regelbunden underhållstid så att kunderna förstår att ändringar sker under specifika tider. Mer information om hur du uppnår noll stilleståndstid för distributioner finns i Uppnå ingen stilleståndstid via versionsuppdateringar för tjänsten.

Hitta en balans

Om du lämnar takten för dina tjänstuppdateringar helt efter dina klienters gottfinnande kan de välja att aldrig uppdatera. Det är viktigt att tillåta dig 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 den mest trafikerade dagen 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 för varje klientorganisation med någon av de metoder som beskrivs nedan. Ge kunden ett meddelande om planerade uppdateringar. Tillåt kunder att tillfälligt avanmäla sig, men inte för alltid; sätt 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 utan förvarning.

En annan metod kan vara att tillåta klienter att initiera sina egna uppdateringar, vid en tidpunkt som de själva 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 klienter att initiera sina egna uppdateringar. Detta är komplicerat att implementera och kräver betydande utvecklings- och testningsarbete för att leverera och underhålla.

Vad du än gör, se till att du har en process för att övervaka hälsotillståndet för dina klienter, särskilt före och efter uppdateringar tillämpas. Kritiska produktionsincidenter (kallas även live-platsincidenter)inträffar ofta efter kod- eller konfigurationsuppdateringar. 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 Övervakning för DevOps

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äkerhetsproblem och prestandaförbättringar. En av fördelarna med en modern molnbaserad lösning är kontinuerlig leverans av funktioner och uppdateringar.

Överväg följande frågor:

  • Kommer du att meddela kunderna om kommande uppdateringar?
  • Om du gör det, kommer du att begära behörighet implicit genom att tillhandahålla en avanmälningsprocess?
  • Har du en schemalagd underhållsfönstret som du använder när du tillämpar uppdateringar?
  • Vad händer om du har en nöduppdatering, till exempel en kritisk säkerhetskorrigering? Kan du tvinga fram uppdateringar i sådana situationer?
  • Om du inte proaktivt kan meddela kunden om kommande uppdateringar, kan du då skicka tillbakablicksmeddelanden? Kan du till exempel uppdatera en sida på din webbplats med listan över uppdateringar som du har tillämpat?

Kommunicera med kundsupporten

Det är viktigt att ditt eget supportteam har fullständig insyn i uppdateringar som har tillämpats på varje klientorganisation. Kundtjänstrepresentanter bör enkelt kunna besvara följande frågor:

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

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

Distributionsstrategier för att stödja uppdateringar

Fundera över hur du ska distribuera uppdateringar till din infrastruktur. Detta påverkas kraftigt av den innehavaresmodell som du använder. Tre vanliga metoder för att distribuera uppdateringar är distributionsstämplar, funktionsflaggor och distributionsringar.

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

Distributionsstämplar

Vissa program för flera användare 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 klient eller delade stämplar som kör flera klienters arbetsbelastningar.

Stämplar är ett bra sätt att tillhandahålla isolering mellan klienter. De ger dig också flexibilitet för uppdateringsprocessen, 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 bara exponerar för en delmängd av dina kunder eller klienter. Du kan använda funktionsflaggor om du distribuerar uppdateringar regelbundet men vill undvika att visa nya funktioner, eller om du vill undvika att tillämpa ändringar i beteendet förrän en kund väljer att göra det.

Du kan bädda in stöd för funktionsflaggan i ditt program genom att skriva kod själv eller genom att använda en tjänst som Azure App Configuration.

Distributionsringar

Med distributionsringar kan du progressivt distribuera uppdateringar över en uppsättning klienter eller distributionsstämplar. Du kan tilldela en delmängd av klienterna till varje ring. En kanariering innehåller dina egna testklienter 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 lika omfattande valideringsprocess som i andra saker. En tidig adopter-ring innehåller klienter som är något mer riskbenägna, men som fortfarande är redo att ta emot regelbundna uppdateringar. 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 bör du tänka på att eventuella uppdateringar som du tillämpar kan påverka hur kunder eller partner integrerar med din plattform. I synnerhet måste du vara medveten om större ändringar i dina API:er. Överväg att använda en strategi för API-versionshantering för att minska risken för uppdateringar av ditt API.

Nästa steg