Dela via

Att tänka på när du uppdaterar en lösning för flera klientorganisationer

  • 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 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 klientorganisationer ä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 ett saldo 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 till 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

Överväg följande frågor:

  • Förväntningar och krav: Har dina kunder förväntningar eller krav på när de kan uppdateras? Dessa kan meddelas dig formellt i kontrakt eller serviceavtal, eller så kan de vara informella.
  • Underhållsperioder: Förväntar sig dina kunder tjänstdefinierade eller till och med självdefinierade underhållsperioder? De kan behöva kommunicera med sina egna kunder om eventuella avbrott.
  • Förordningar: Har dina kunder 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 (FDA) innan du tillämpar en uppdatering.
  • Känslighet: Är någon av dina kunder särskilt känslig eller resistent mot att uppdateringar tillämpas? 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.
  • Historia: Vad har du för erfarenhet av att slutföra uppdateringar utan att det påverkar dina kunder? Du bör följa bra DevOps-, testnings-, distributions- och övervakningsmetoder för att minska sannolikheten 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.
  • Rollback: Kommer kunderna att vilja återställa uppdateringar om det sker en icke-bakåtkompatibel ändring?

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 kommer att ge någon kontroll över hur du uppgraderar eller använder din lösning.
  • Versioner: Hur många versioner av din lösning kan du rimligen underhålla samtidigt? Kom ihåg att om du hittar ett fel och behöver snabbkorrigeringar kan du behöva tillämpa 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? Om du släpper nya funktioner regelbundet, kommer gamla versioner att bli föråldrade snabbt? Beroende på din uppgraderingsstrategi och typerna av ändringar kan du också behöva underhålla separata infrastrukturer för varje version av din lösning. Därför kan det finnas både driftkostnader och ekonomiska kostnader, eftersom du underhåller stödet för äldre versioner.
  • Rollback: Kan distributionsstrategin stödja återställningar till tidigare versioner? Är det något du vill aktivera?

Anteckning

Överväg om du behöver ta lösningen offline för uppdateringar eller underhåll. I allmänhet ses avbrottsperioder som inaktuella, 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 överväga uppdateringsprocessen när du planerar din lösningsarkitektur.

Även om du inte planerar för avbrott under uppdateringsprocessen kan du fortfarande överväga att definiera en regelbunden 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 utan driftstopp finns i Eliminera stilleståndstid via versionsbaserade tjänstuppdateringar.

Hitta ett saldo

Om du lämnar takt för dina tjänstuppdateringar helt efter dina klientorganisationers gottfinnande kan de välja att aldrig uppdatera. Det är viktigt att du låter dig 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 hektiska 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 för varje 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 alltid; en rimlig gräns för när du kommer att kräva att uppdateringen tillämpas.

Överväg också att ge dig själv möjlighet att distribuera säkerhetskorrigeringar eller andra kritiska snabbkorrigeringar, med minimal eller ingen förvarning.

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 låta klientorganisationer initiera sina egna uppdateringar. Detta är komplext att implementera och kräver betydande utvecklings- och testningsarbete för att leverera och underhålla.

Oavsett vad du 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 Ö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ösa 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 implicit att begära behörighet genom att tillhandahålla en avaktiveringsprocess och vilka är gränserna för att avregistrera dig?
  • Har du en schemalagd underhållsperiod 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 framtvinga uppdateringar i sådana situationer?
  • Om du inte proaktivt kan meddela kunden om kommande uppdateringar, kan du ge retrospektiva 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 kundsupporten

Det är viktigt att ditt eget supportteam har fullständig insyn i uppdateringar som har tillämpats på varje klientorganisation. Kundsupportrepresentanter 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?
  • 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 din infrastruktur. 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.

I samtliga fall bör du se 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 klientorganisationer 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 isolera klientorganisationer. 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 bara 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 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.

Du kan bestämma 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 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 så omfattande valideringsprocess som i de andra sakerna.
  • 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 bör du tänka på att eventuella uppdateringar som du tillämpar kan 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 STRATEGI för API-versionshantering för att minska risken för uppdateringar av ditt API.

Deltagare

Den här artikeln underhålls av Microsoft. Den skrevs ursprungligen av följande deltagare.

Huvudförfattare:

  • John Downs | Huvudkundstekniker, FastTrack för Azure

Andra deltagare:

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

Nästa steg