Share via

Rekommendationer för att utforma en strategi för att minska distributionsfel

  • Artikel

Gäller för denna checklista för Azure Well-Architected Framework Operational Excellence:

OE:12 Implementera en strategi för åtgärd av distributionsfel som åtgärdar oväntade problem med snabb återställning mitt i distributionen. Kombinera flera metoder, till exempel återställning, funktionsaktivering eller användning av distributionsmönstrets inbyggda funktioner.

Den här guiden beskriver rekommendationerna för att utforma en standardiserad strategi för att effektivt hantera distributionsfel. Precis som andra arbetsbelastningsproblem är distributionsfel en oundviklig del av en arbetsbelastningslivscykel. Med det här tänkesättet kan du vara proaktiv genom att ha en väldesignad, avsiktlig strategi för att hantera distributionsfel. Med en sådan strategi kan arbetsbelastningsteamet effektivt åtgärda fel med så liten inverkan som möjligt på slutanvändarna.

Avsaknaden av en sådan plan kan leda till kaotiska och potentiellt skadliga svar på problem, vilket avsevärt kan påverka team- och organisationssammanhållning, kundförtroende och ekonomi.

Viktiga designstrategier

Ibland, trots mognaden i dina utvecklingsmetoder, uppstår distributionsproblem. Genom att använda säkra distributionsmetoder och använda en robust arbetsbelastningsförsörjningskedja kan du minimera frekvensen för misslyckade distributioner. Men du måste också utforma en standardiserad strategi för att hantera misslyckade distributioner när de inträffar.

När du använder en progressiv distributionsmodell för exponering som standardpraxis:

  • Du har rätt grund för att minimera effekterna på dina kunder eller interna användare när distributionerna misslyckas.
  • Du kan åtgärda problem effektivt.

En strategi för åtgärd av distributionsfel består av fem breda faser:

  1. Identifiering: Om du vill svara på en misslyckad distribution måste du först identifiera felet. Identifieringen kan ta flera former, till exempel misslyckade röktester, användarrapporterade problem eller aviseringar som din övervakningsplattform genererar.

  2. Beslut: Du måste bestämma vilken åtgärdsstrategi som är bäst för den specifika feltypen.

  3. Åtgärd: Du utför den identifierade åtgärdsåtgärden. Åtgärden kan ske i form av en återställning, återställning, framåtrullning eller användning av en körningskonfiguration för att kringgå den felande funktionen.

  4. Kommunikation: Intressenter och berörda slutanvändare måste informeras om statusen när du identifierar och arbetar dig igenom problemet enligt din beredskapsplan.

  5. Postmortem: Skuldlösa postmortems ger arbetsbelastningsteamet möjlighet att identifiera förbättringsområden och skapa planer för att tillämpa utbildningar.

Följande avsnitt innehåller detaljerade rekommendationer för dessa faser. De här avsnitten förutsätter att du identifierar ett problem när du har distribuerat ändringarna till en eller flera grupper av användare eller system, men innan du uppdaterar alla grupper i distributionsplanen.

Identifiering

För att snabbt identifiera problem med distributioner behöver du robusta metoder för testning och observerbarhet när det gäller distributioner. För att snabbt identifiera avvikelser kan du komplettera din arbetsbelastningsövervakning och avisering genom att vidta följande steg:

  • Använd ett programprestandahanteringsverktyg.
  • Aktivera loggning via instrumentation.

Röktestning och andra kvalitetstester bör ske i varje fas av distributionen. Lyckade tester i en distributionsgrupp bör inte påverka beslut om att testa i efterföljande grupper.

Du kan implementera telemetri som korrelerar användarproblem med en distributionsfas. Sedan kan du snabbt identifiera vilken distributionsgrupp en viss användare är associerad med. Den här metoden är särskilt viktig för distributioner av progressiv exponering, eftersom du kan ha flera konfigurationer som körs över användarbasen vid en viss tidpunkt i distributionen.

Du bör vara redo att svara på användarrapporterade problem omedelbart. När det är praktiskt distribuerar du distributionsfasen under arbetstid, när du har ett fullständigt supportteam tillgängligt. Se till att supportpersonalen får utbildning om hur du eskalerar distributionsproblem för korrekt routning. Eskaleringar bör överensstämma med din beredskapsplan för arbetsbelastningar.

Beslut

När du beslutar om en lämplig åtgärdsstrategi för ett visst distributionsproblem bör du överväga många faktorer, bland annat:

  • Den typ av progressiv exponeringsmodell som du använder. Du kan till exempel använda en blågrön modell eller en kanariemodell.

    Om du använder en blågrön modell är det mer praktiskt att falla tillbaka än att rulla tillbaka. Du kan enkelt flytta tillbaka trafik till stacken som kör konfigurationen som inte har uppdaterats. Du kan sedan åtgärda problemet i den problematiska miljön och prova distributionen igen vid en lämplig tidpunkt.

  • De metoder som du har till ditt förfogande för att kringgå problemet. Exempel är användning av funktionsflaggor, miljövariabler eller någon annan typ av körningskonfigurationsegenskap som du kan aktivera och inaktivera.

    Ibland kan du enkelt kringgå ett problem genom att stänga av en funktionsflagga eller växla en inställning. I det här fallet kanske du kan:

    • Fortsätt med distributionen.
    • Undvik att falla tillbaka.
    • Återställ medan du åtgärdar den felaktiga koden.

  • Den ansträngningsnivå som krävs för att implementera en korrigering i koden.

    Om arbetet med att åtgärda koden är lågt är det rätt val att gå vidare genom att implementera en snabbkorrigering för vissa scenarier.

  • Nivån av kritiskhet för den berörda arbetsbelastningen.

    Affärskritiska arbetsbelastningar bör alltid distribueras sida vid sida, som i en blågrön modell, för att uppnå distributioner med noll driftstopp. Därför är tillbakafall den bästa åtgärdsstrategin för de här typerna av arbetsbelastningar.

  • Den typ av infrastruktur som arbetsbelastningen använder – föränderlig eller oföränderlig.

    Om din arbetsbelastning är utformad för att använda föränderlig infrastruktur kan det vara meningsfullt att gå vidare, eftersom det innebär att infrastrukturen uppdateras på plats. Omvänt kan det vara meningsfullt att återställa eller falla tillbaka när du använder oföränderlig infrastruktur.

Oavsett vilka val du gör bör du inkludera lämpliga godkännanden i beslutsprocessen och kodifiera dem i ditt beslutsträd.

Åtgärd

  • Återställning: I ett återställningsscenario återställer du uppdaterade system till det senast kända konfigurationstillståndet.

    Det är viktigt för hela arbetsbelastningsteamet att komma överens om innebörden av senast kända goda. Det här uttrycket refererar till det sista tillståndet för arbetsbelastningen som var felfri innan distributionen började, vilket inte nödvändigtvis är den tidigare programversionen.

    Återställning kan vara komplext, särskilt när det gäller dataändringar. Schemaändringar kan göra det riskabelt att återställa. Att implementera dem på ett säkert sätt kan kräva betydande planering. Som en allmän rekommendation bör schemauppdateringar vara additiva. De bör inte vara ersättningsändringar – poster bör inte ersättas med nya poster. I stället bör äldre poster vara inaktuella och bör samexistera med nya poster tills det är säkert att ta bort de inaktuella posterna.

  • Återställning: I ett fallback-scenario tas de uppdaterade systemen bort från produktionstrafikroutningen. All trafik dirigeras till stacken som inte uppdateras. Den här lågriskstrategin ger dig ett sätt att åtgärda problemen i koden utan att ytterligare störningar uppstår.

    Med kanariedistributioner kanske det inte är enkelt eller ens möjligt att falla tillbaka, beroende på din infrastruktur och appdesign. Om du behöver utföra skalning för att hantera belastningen på system som inte uppdateras utför du den skalningen innan du återgår.

  • Kringgå den felande funktionen: Om du kan kringgå problemet med hjälp av funktionsflaggor eller en annan typ av körningskonfigurationsegenskap kan du besluta att det är rätt strategi för ett visst problem att fortsätta med distributionen.

    Du bör tydligt förstå kompromissen med att kringgå funktionen, och du bör kunna kommunicera den kompromissen med intressenterna. Intressenterna bör godkänna den framåtriktade planen. Intressenterna måste fastställa hur lång tid som är acceptabel för att arbeta i ett degraderat tillstånd. De måste också väga den beslutsamheten mot din uppskattning av den tid som behövs för att åtgärda den felaktiga koden och distribuera den.

  • Nöddistribution (snabbkorrigering): Om du kan åtgärda problemet mitt i distributionen kan en snabbkorrigering vara den mest praktiska åtgärdsstrategin.

    Precis som med annan kod måste snabbkorrigeringar gå igenom dina säkra distributionsmetoder. Men med en snabbkorrigering accelereras tidslinjen avsevärt. Du måste använda en strategi för kodhöjning i dina miljöer. Du måste också kontrollera snabbkorrigeringskoden vid alla kvalitetsgrindar. Men du kan behöva förkorta bakningstiderna dramatiskt och du kan behöva ändra testerna för att påskynda dem. Se till att du kan köra fullständiga tester på den uppdaterade koden så snart som möjligt efter distributionen. Genom att automatisera kvalitetssäkringstestning i hög grad blir testningen effektiv i dessa scenarier.

Kompromisser:

  • Att kunna backa innebär vanligtvis att du behöver tillräcklig infrastrukturkapacitet för att hantera två versioner av arbetsbelastningskonfigurationen samtidigt. Dina arbetsbelastningsteam måste också kunna stödja två versioner i produktion samtidigt.
  • Att kunna återställa effektivt kan innebära refaktorisering av element i din arbetsbelastning. Du kan till exempel behöva frikoppla funktioner eller ändra datamodellen.

Kommunikation

Det är viktigt att ha tydligt definierade kommunikationsansvar för att minimera kaoset under incidenter. Dessa ansvarsområden bör fastställa hur arbetsbelastningsteamet interagerar med supportteam, intressenter och personal från räddningstjänsten, till exempel beredskapschefen.

Standardisera den takt som arbetsbelastningsteamet följer för att tillhandahålla statusuppdateringar. Se till att intressenterna är medvetna om den här standarden så att de vet när de kan förvänta sig uppdateringar.

Om arbetsbelastningsteamet behöver kommunicera direkt med slutanvändarna förtydligar du vilken typ av information och detaljnivå som är lämplig för delning med användare. Meddela även arbetsbelastningsteamet eventuella andra krav som gäller för dessa fall.

Efteranalys

Postmortems bör följa alla misslyckade distributioner, utan undantag. Varje misslyckad distribution är en möjlighet att lära sig. Postmortems kan hjälpa dig att identifiera svagheter i dina distributions- och utvecklingsprocesser. Du kan också identifiera felkonfigurationer i infrastrukturen, bland många andra möjligheter.

Postmortems bör alltid vara oskyldiga så att individer som är inblandade i incidenten känner sig säkra när de delar sina perspektiv på vad som kan förbättras. Postmortem-ledare bör följa upp planerna för att implementera de förbättringar som har identifierats och lägga till dessa planer i kvarvarande uppgifter för arbetsbelastningar.

Överväganden och allmänna rekommendationer

Se till att distributionspipelinen kan acceptera distinkta versioner som parametrar så att du enkelt kan distribuera senast fungerande konfigurationer.

Upprätthålla konsekvens med hanterings- och dataplanen när du återställer eller rullar framåt. Nycklar, hemligheter, databastillståndsdata och konfigurationer som är specifika för resurser och principer måste alla finnas i omfånget och redovisas. Var till exempel uppmärksam på utformningen av din infrastrukturskalning i den senaste fungerande distributionen. Ta reda på om du behöver justera konfigurationen när du distribuerar om koden.

Föredra små, frekventa ändringar framför ovanliga, stora ändringar så att deltat mellan dina nya och senaste fungerande distributioner är litet.

Utför en analys av felläge (FMA) på dina CI/CD-pipelines (kontinuerlig integrering och kontinuerlig leverans) för att identifiera problem som kan komplicera åtgärder. Precis som din arbetsbelastning som helhet kan dina pipelines analyseras för att identifiera områden som kan vara problematiska när du försöker använda en viss åtgärdstyp.

Använd automatiserade återställningsfunktioner på ett omdömesgillt sätt:

  • Vissa CI/CD-verktyg som Azure DevOps har funktioner för automatisk återställning som är inbyggda. Överväg att använda den här funktionen om den ger dig ett konkret värde.
  • Du bör använda funktionen för automatisk återställning först när du har testat din pipeline noggrant och regelbundet. Se till att din pipeline är tillräckligt mogen för att införa extra problem om en automatisk återställning utlöses.
  • Du måste lita på att automatiseringen endast distribuerar nödvändiga ändringar och att den bara utlöses när det behövs. Utforma utlösarna noggrant för att uppfylla dessa krav.

Använd funktioner som tillhandahålls av plattformen under återställningar. Säkerhetskopieringar och återställningar till tidpunkt kan till exempel hjälpa dig med återställning av lagring och data. Eller om du använder virtuella datorer som värd för ditt program kan det vara bra att återställa din miljö till en kontrollpunkt som är omedelbart före en incident.

Testa hela strategin för att minska distributionsfel ofta. Precis som beredskapsplaner och haveriberedskapsplaner lyckas din distributionsfelplan bara om ditt team har tränats på det och övar på det regelbundet. Kaosteknik och felinmatningstestning kan vara effektiva tekniker för att testa distributionsminskningsstrategin.

Kompromiss: Supportteamets medlemmar måste kunna utföra sina normala uppgifter och även stödja nödsituationer. Du kan behöva öka antalet personer för att säkerställa att supportteamet är korrekt bemannat och kan utföra alla nödvändiga uppgifter. Testa distributioner noggrant när du distribuerar till miljöer med lägre utveckling. Den här metoden hjälper dig att identifiera buggar och felkonfigurationer innan de kommer till produktion.

Azure-underlättande

  • Azure Pipelines tillhandahåller bygg- och versionstjänster för att stödja CI/CD för dina program.

  • Azure Test Plans är en webbläsarbaserad testhanteringslösning som är enkel att använda. Den här lösningen erbjuder funktioner som krävs för planerad manuell testning, acceptanstestning av användare och undersökande testning. Med Azure-testplaner kan du också samla in feedback från intressenter.

  • Azure Monitor är en omfattande övervakningslösning för att samla in, analysera och svara på övervakningsdata från molnet och lokala miljöer. Övervakaren innehåller en robust aviseringsplattform. Du kan konfigurera det systemet för automatiska meddelanden och andra åtgärder, till exempel autoskalning och andra självåterställningsmekanismer.

  • Application Insights är ett tillägg till Monitor som tillhandahåller funktioner för övervakning av programprestanda (APM).

  • Azure Logic Apps är en molnbaserad plattform för att köra automatiserade arbetsflöden som integrerar appar, data, tjänster och system. Du kan använda Logic Apps för att skapa en ny version av ditt program när en uppdatering görs till det. Azure har en historik över versionerna och kan återställa eller höja upp en tidigare version.

  • Många Azure-databastjänster tillhandahåller funktioner för återställning till tidpunkt som kan hjälpa dig när du behöver återställa:

  • Förhandsversionen av Azure Chaos Studio är en hanterad tjänst som använder kaosteknik för att hjälpa dig att mäta, förstå och förbättra återhämtningsförmågan för molnprogram och tjänster.

Checklista för utmärkt driftseffektivitet

Se den fullständiga uppsättningen rekommendationer.

Checklista för utmärkt driftseffektivitet