Dela via

Rekommendationer för att utforma en strategi för åtgärd av 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. Kombinera flera metoder, till exempel återställning, funktionsaktivering eller användning av distributionsmönstrets interna 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äl utformad, avsiktlig strategi för att hantera distributionsfel. En sådan strategi gör det möjligt för ditt arbetsbelastningsteam att effektivt minimera 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 teamets och organisationens sammanhållning, kundförtroende och ekonomi.

Viktiga designstrategier

Ibland uppstår distributionsproblem, trots mognaden i dina utvecklingsmetoder. Genom att använda säkra distributionsmetoder och använda en robust leveranskedja för arbetsbelastningar 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 distributionsmodell för progressiv 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 effektivt åtgärda problem.

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, återställning framåt eller användning av en körningskonfiguration för att kringgå den felaktiga funktionen.

  4. Kommunikation: Intressenter och berörda slutanvändare måste informeras om statusen när du identifierar och arbetar igenom problemet enligt vad som krävs i 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.

Utforma mekanismer för felidentifiering

För att snabbt identifiera problem med distributioner behöver du robusta metoder för testning och observerbarhet när de 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 annan kvalitetstestning bör ske i varje fas i distributionen. Lyckade tester i en distributionsgrupp bör inte påverka beslut 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 progressiva exponeringsdistributioner 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 utbildas i hur du eskalerar distributionsproblem för korrekt routning. Eskaleringar bör överensstämma med din beredskapsplan för arbetsbelastningen.

Besluta om riskreduceringsstrategin

Att besluta om en lämplig åtgärdsstrategi för ett visst distributionsproblem handlar om att ta hänsyn till 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 trafiken till stacken som kör konfigurationen som inte uppdateras. Du kan sedan åtgärda problemet i den problematiska miljön och försöka distribuera 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.
    • Rulla tillbaka 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åg ä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, till exempel i en blågrön modell, för att uppnå distributioner utan driftstopp. Därför är tillbakafall den bästa strategin för att minska risken för dessa typer 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 rulla framåt, 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.

Implementera åtgärdsstrategin

  • Å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 återställningen riskfylld. 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 reservscenario tas de uppdaterade systemen bort från routningen för produktionstrafik. 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 införa ytterligare störningar.

    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 felaktiga funktionen: Om du kan kringgå problemet med hjälp av funktionsflaggor eller en annan typ av körningskonfigurationsegenskap kan du besluta att fortsätta med distributionen är rätt strategi för ett visst problem.

    Du bör tydligt förstå kompromissen med att kringgå funktionen, och du bör kunna förmedla den kompromissen till intressenterna. Intressenterna bör godkänna den framåtriktade planen. Intressenter måste fastställa hur lång tid som är acceptabelt för att fungera i ett degraderat tillstånd. De måste också väga den beslutsamheten mot din uppskattning av den tid som krä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 kod för snabbkorrigering 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 falla tillbaka innebär vanligtvis att du behöver tillräckligt med 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.

Standardisera statusuppdateringar under en incident

Det är viktigt att ha tydligt definierade kommunikationsansvar för att minimera kaos under incidenter. Dessa ansvarsområden bör fastställa hur arbetsbelastningsteamet interagerar med supportteam, intressenter och personal i beredskapsteamet, 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.

Utföra incidentpostmortems

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 med planer för att implementera de förbättringar som har identifierats och lägga till dessa planer i kvarvarande arbetsbelastningar.

Operationalisera åtgärdsprocesser

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

Upprätthålla konsekvens med hanterings- och dataplan 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 din senaste kända distribution. 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 senast kända 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 pipelinen 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 endast 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. Till exempel kan säkerhetskopieringar och återställningar till tidpunkt hjälpa till 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 miljön till en kontrollpunkt som är omedelbart före en incident.

Testa hela strategin för distributionsfelreducering ofta. Precis som beredskapsplaner och planer för haveriberedskap lyckas din distributionsfelplan bara om ditt team tränas på det och övar det regelbundet. Kaosteknik och felinmatningstestning kan vara effektiva tekniker för att testa distributionsreduceringsstrategin.

Kompromiss: Supportteamets medlemmar måste kunna utföra sina normala uppgifter och även stödja nödsituationer. Du kan behöva öka antalet huvud 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 lägre utvecklingsmiljöer. 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, testning av användargodkännande 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 molnmiljöer och lokala miljöer. Övervakaren innehåller en robust aviseringsplattform. Du kan konfigurera 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 av det. Azure har en historik över versionerna och kan återställa eller höja upp valfri 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 molnprograms- och tjänstresiliens.

Checklista för driftskvalitet

Se den fullständiga uppsättningen rekommendationer.

Checklista för driftskvalitet