Dela via


Rekommendationer för säkra distributionsmetoder

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

OE:11 Definiera arbetsbelastningens säkra distributionsmetoder tydligt. Betona idealen för små, inkrementella, kvalitetsgrindade lanseringsmetoder. Använd moderna distributionsmönster och progressiva exponeringstekniker för att kontrollera risker. Ta hänsyn till rutinmässiga distributioner och nödsituationer, eller snabbkorrigeringar, distributioner.

Den här guiden beskriver rekommendationerna för att använda säkra distributionsmetoder (SDP). Säkra distributionsprocesser och procedurer definierar hur du på ett säkert sätt kan göra och distribuera ändringar i din arbetsbelastning. Om du implementerar SDP måste du tänka på distributioner via linsen för att hantera risker. Du kan minimera risken för mänskliga fel i dina distributioner och begränsa effekterna av problematiska distributioner på dina användare genom att implementera SDP.

Viktiga designstrategier

Det finns fyra viktiga riktlinjer att tänka på när du implementerar säkra distributionsmetoder:

  • Säkerhet och konsekvens: Alla ändringar i produktionsarbetsbelastningen är i sig riskfyllda och måste göras med fokus på säkerhet och konsekvens.

  • Progressiv exponering: Du kan minimera den potentiella explosionsradien för distributionsorsakade problem genom att använda en distributionsmodell för progressiv exponering.

  • Hälsomodeller: Distributioner måste klara hälsokontroller innan varje fas av progressiv exponering kan börja.

  • Problemidentifiering: När problem identifieras bör distributionen omedelbart stoppas och återställning initieras.

Följande avsnitt innehåller detaljerade rekommendationer om var och en av dessa punkter.

Säkerställa säkerhet och konsekvens för distributioner

Oavsett om du distribuerar en uppdatering av programkoden, infrastrukturen som kod (IaC), funktionsflaggan eller en konfigurationsuppdatering, så riskerar du arbetsbelastningen. Det finns inga distributioner med låg risk till produktion. Varje distribution måste följa ett standardmönster och bör automatiseras för att framtvinga konsekvens och minimera risken för mänskliga fel. Det är viktigt att arbetsbelastningens leveranskedja och distributionspipelines är tillförlitliga, säkra och har tydligt definierade distributionsstandarder. Behandla varje distribution som en möjlig risk och utsätt varje distribution för samma nivå av riskhantering. Trots riskerna bör du fortsätta att distribuera regelbundna ändringar i din arbetsbelastning. Om du inte distribuerar regelbundna uppdateringar medför det andra risker, till exempel säkerhetsrisker som måste åtgärdas via distributioner. Mer information finns i Rekommendationer för att utforma en leveranskedja för arbetsbelastningsutveckling.

Frekventa små distributioner är att föredra framför ovanliga stora distributioner. Små ändringar är enklare att lösa när problem uppstår och frekventa distributioner hjälper ditt team att skapa förtroende för distributionsprocessen. Det är också viktigt att du lär dig från produktion genom att granska dina arbetsbelastningsprocesser när du stöter på en avvikelse under distributionen. Du kan hitta svagheter i utformningen av infrastrukturen eller distributionen. När problem uppstår under distributioner kontrollerar du att skuldlösa postmortem är en del av din SDP-process för att samla in lektioner om incidenten.

Anta en progressiv exponeringsmodell

När distributionsproblem uppstår är målet att fånga upp dem så tidigt som möjligt för att minimera effekten på slutanvändarna. Implementera en gradvis distributionsdistributionsmodell, även kallad progressiv exponeringsmodell, för att uppnå det här målet. Kanariedistributioner är ett vanligt exempel på progressiv exponering. I den här distributionsmodellen får en liten grupp interna eller externa användare den nya funktionen först. När den första gruppen har kört den nya versionen utan problem distribueras funktionen till successivt större grupper tills hela användarpopulationen kör den nya versionen. Funktionsflaggor används vanligtvis för att aktivera den nya versionen för målanvändare i kanariedistributioner.

En annan vanlig distributionsmodell är en blågrön metod. I den här modellen distribueras två identiska uppsättningar, eller pooler, av arbetsbelastningsinfrastrukturen. Båda poolerna kan hantera en fullständig produktionsbelastning. Den första (blå) poolen kör den aktuella versionen av distributionen där alla användare landar. Den andra (gröna) poolen uppdateras med den nya funktionen och testas internt. Efter intern testning dirigeras en delmängd av produktionstrafiken från den blå poolen till den gröna poolen. Precis som kanariedistributioner är distributionen progressiv när du flyttar över mer trafik till den gröna poolen i successivt större distributionsvågor. När du har slutfört distributionen blir uppdateringspoolen den blå poolen och den gröna poolen är redo för nästa distribution. De två poolerna är logiskt åtskilda från varandra för att skydda mot fel. Du kan distribuera en variant av den blågröna modellen i en arbetsbelastning som använder designmönstret Distributionsstämplar genom att distribuera på en stämpel i taget.

I båda dessa modeller bör tiden mellan varje fas i distributionen vara tillräckligt lång för att du ska kunna övervaka hälsomåtten för arbetsbelastningen. Du bör tillhandahålla gott om bakningstid, tid mellan distributionsgrupper, för att säkerställa att användare från olika regioner eller användare som utför olika uppgifter har tid att använda arbetsbelastningen i sin normala kapacitet. Gräddningstider bör mätas i timmar och dagar i stället för minuter. Gräddningstiderna bör också öka för varje distributionsgrupp så att du kan ta hänsyn till olika tidszoner och användningsmönster under dagen.

Utveckla robusta hälsomodeller för arbetsbelastningar

Utveckla en robust hälsomodell som en del av dina strategier för observerbarhetsplattform och tillförlitlighet. Din hälsomodell bör ge djupgående insyn i komponenterna och den övergripande hälsan för arbetsbelastningen. Om du får en avisering om en hälsoändring som rör en slutanvändare under en distribution bör distributionen omedelbart stoppas och en undersökning av orsaken till aviseringen bör utföras för att fastställa nästa åtgärdssätt. Om det inte finns några problem som rapporteras av slutanvändare och alla hälsoindikatorer förblir gröna under bakningstiden bör distributionen fortsätta. Se till att inkludera användningsstatistik i din hälsomodell för att säkerställa att brist på användarrapporterade problem och negativa hälsosignaler inte döljer ett problem. Mer information finns i Skapa en hälsomodell.

Implementera mekanismer för felidentifiering

När distributionen orsakar ett problem i en av distributionsgrupperna måste distributionen stoppas omedelbart. En undersökning av orsaken till problemet och effekternas allvarlighetsgrad måste utföras så snart aviseringen tas emot. Återställning från problemet kan omfatta:

  • Återställa distributionen genom att ångra de ändringar som gjorts i distributionen och återgå till den senast kända arbetskonfigurationen.

  • Distribuera distributionen genom att åtgärda problemet mitt i distributionen. Du kan åtgärda problem mitt i distributionen genom att använda en snabbkorrigering eller på annat sätt minimera problemet.

  • Distribuera ny infrastruktur med hjälp av den senast kända arbetskonfigurationen.

Återställning av ändringar, särskilt databas, schema eller andra tillståndskänsliga komponentändringar, kan vara komplexa. Dina SDP-riktlinjer bör ge tydliga instruktioner om hur du hanterar dataändringar enligt dataegendomsdesignen för din arbetsbelastning. På samma sätt måste framåtrullning hanteras noggrant för att säkerställa att SDP inte försummas och att snabbkorrigeringen eller andra minimerande åtgärder utförs på ett säkert sätt.

Upprätta protokoll för nöddistributioner

  • Implementera versionshantering i dina byggartefakter för att säkerställa att du kan återställa och rulla framåt när det behövs.

  • Använd ett versionsflöde eller en trunkbaserad förgreningsstruktur som framtvingar nära synkroniserat samarbete i utvecklingsteamet i stället för en Gitflow- eller miljöbaserad förgreningsstruktur.

  • Automatisera så mycket av din SDP som möjligt. Detaljerad vägledning om hur du automatiserar IaC- och programprocesser för kontinuerlig integrering och kontinuerlig leverans (CI/CD) finns i Rekommendationer för implementering av automatisering.

  • Använd CI-metoder för att regelbundet integrera kodändringar i lagringsplatser. CI-metoder kan hjälpa dig att identifiera integrationskonflikter och minska sannolikheten för stora, riskfyllda sammanslagningar. Mer information finns i guiden för kontinuerlig integrering.

  • Använd funktionsflaggor för att selektivt aktivera eller inaktivera nya funktioner eller ändringar i produktionen. Funktionsflaggor kan hjälpa dig att kontrollera exponeringen av ny kod och snabbt återställa distributionen om det uppstår problem.

  • Distribuera ändringar i mellanlagringsmiljöer som speglar din produktionsmiljö. Med övningsmiljöer kan du testa ändringar i en kontrollerad inställning innan du distribuerar till livemiljön.

  • Upprätta fördistributionskontroller, inklusive kodgranskning, säkerhetsgenomsökningar och efterlevnadskontroller, för att säkerställa att ändringar är säkra att distribuera.

  • Implementera kretsbrytare för att automatiskt stoppa trafik till en tjänst som har problem. Detta kan bidra till att förhindra ytterligare försämring av systemet.

SDP-protokoll för nödsituationer

Upprätta normativa protokoll som definierar hur din SDP kan justeras för en snabbkorrigering eller för nödsituationsproblem som ett säkerhetsintrång eller sårbarhetsexponering. Dina SDP-protokoll för nödsituationer kan till exempel innehålla:

  • Acceleration av upp- och godkännandesteg.

  • Acceleration av röktestning och integreringstestning.

  • Minskning av gräddningstiden.

I vissa fall kan nödsituationen begränsa kvalitets- och testgrindar, men grindar bör fortfarande köras så snabbt som möjligt som en out-of-band-övning. Se till att du definierar vem som kan godkänna SDP-acceleration i en nödsituation och de kriterier som måste uppfyllas för att accelerationen ska godkännas. Justera dina SDP-protokoll för nödsituationer med din beredskapsplan för att säkerställa att alla nödsituationer hanteras enligt samma protokoll.

Att tänka på

Det är komplext att skapa och underhålla säkra distributionsmetoder. Din framgång med att fullt ut implementera robusta standarder beror på mognaden i dina metoder inom många områden av programvaruutveckling. Användning av automatisering, endast IaC för infrastrukturändringar, konsekvens i förgreningsstrategier, användning av funktionsflaggor och många andra metoder kan bidra till säker distribution. Använd den här guiden för att optimera din arbetsbelastning och informera om dina planer för förbättringar allt eftersom dina metoder utvecklas.

Azure-underlättande

  • Azure Pipelines och GitHub Actions stöder distributioner i flera steg med hjälp av godkännandegrindar, vilket kan hjälpa dig att utforma din progressiva exponeringsdistribution för distributioner.

  • Använd Azure App Service-mellanlagringsplatser för att enkelt växla mellan kodversioner. Mellanlagringsplatser är användbara för testning i mellanlagringsmiljöer och kan användas för blågröna distributioner.

  • Lagra och hantera funktionsflaggor för webbappar i Azure App Configuration. Genom att använda den här tjänsten kan du skapa, ändra och distribuera funktioner i ett enhetligt hanteringsplan.

  • Distribuera arbetsbelastningsprogram på den virtuella datorn med hjälp av VM-program.

  • Använd Azure-lastbalanserare för att implementera distributionsstrategier och exponera hälsotillståndet för dina arbetsbelastningsprogram med hjälp av inbyggda resurser.

  • Använd Application Health-tillägget för att rapportera om programmets hälsotillstånd inifrån en vm-skalningsuppsättningsinstans. Tillägget avsöker en lokal programslutpunkt och uppdaterar hälsostatusen baserat på svar från TCP/HTTP(S) som tagits emot från programmet.

  • Använd Azure Logic Apps för att skapa en ny version av programmet när en uppdatering görs till det. Azure har en historik över programversioner och kan återställa eller höja upp till valfri tidigare version.

  • Många Azure Database-tjänster tillhandahåller funktioner för återställning till tidpunkt som kan hjälpa dig att återställa. Tjänster som stöder återställning till tidpunkt är:

Exempel

Se arkitekturguiden för blågrön distribution av AKS-kluster (Azure Kubernetes Service) för ett exempel på hur du använder den här distributionsmodellen.

Checklista för driftskvalitet

Se den fullständiga uppsättningen rekommendationer.