Rekommendationer för att utforma av en strategi för att begränsa distributionsfel

Gäller för den här Power Platform checklisterekommendationen för driftförutsättningar för välstrukturerat ramverk:

OE:11	Implementera en strategi för att begränsa distributionsfel och åtgärda oväntade problem med under lanseringen med snabb återställning. Kombinera flera metoder, till exempel återställning, funktionsinaktivering eller använd distributionsmönstrets inbyggda funktioner.

I den här guiden beskrivs rekommendationer för hur du utformar en standardiserad strategi för att effektivt hantera distributionsfel. Precis som andra arbetsbelastningsproblem är distributionsfel en oundviklig del av en arbetsbelastnings livscykel. Med den här tankesä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 påverkan som möjligt på dina användare.

Avsaknaden av en sådan plan kan leda till allvarliga och potentiellt negativa reaktioner på problem, som kan påverka teamets och organisationens sammanhållning, kundernas förtroende och ekonomin.

Viktiga designstrategier

Ibland uppstår problem med distributionen trots väl utvecklade utvecklingsmetoder. Om du använder säkra distributionsmetoder och driver en robust arbetsbelastning för försörjningskedjan kan du minimera antalet misslyckade distributioner. Du måste också utforma en standardiserad strategi för att hantera misslyckade distributioner när de inträffar.

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

1. Identifiering: Om du vill reagera på en misslyckad distribution måste du först identifiera felet. Identifieringen kan ske på flera olika sätt, till exempel misslyckade röktester, användarrapporter eller aviseringar som din övervakningsplattform genererar.
2. Beslut: Du måste fastställa den bästa begränsningsstrategin för den specifika feltypen.
3. Åtgärd: Du måste utföra den identifierade åtgärden. Riskreduceringen kan ta formen av reserv, återställning eller uppdatering.
4. Kommunikation: Intressenter och berörda användare måste göras medvetna om statusen när du identifierar och arbetar igenom problemet, enligt kraven i din beredskapsplan.
5. Utredning: Klanderfria utredningar gör det möjligt för arbetsbelastningsteamet att identifiera förbättringsområden och skapa planer för att ta vara på erfarenheter.

I följande avsnitt finns detaljerade rekommendationer för dessa faser.

Identifiering

För att snabbt identifiera problem med distributioner behöver du robusta test- och övervakningsmetoder som är relaterade till distributioner. För att snabbt identifiera avvikelser kan du komplettera din arbetsbelastningsövervakning och avisering med hjälp av ett verktyg för hantering av programprestanda och loggning via instrumentation.

Grovtestning och andra kvalitetstester bör ske i varje fas av utrullningen. Lyckade tester i en distributionsgrupp bör inte påverka besluten att testa i efterföljande grupper.

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

Du bör vara beredd på att reagera på användarrapporterade problem omedelbart. När det är praktiskt möjligt kan du distribuera utrullningsfasen under arbetstid, när du har tillgång till ett fullständigt supportteam. Se till att supportpersonalen är utbildad i hur man eskalerar distributionsproblem för korrekt routning. Eskaleringar bör anpassas efter arbetsbelastningens nödsituationsplan.

Beslut

Att besluta om en lämplig åtgärdsstrategi för ett distributionsproblem innebär att överväga faktorer som:

• Den typ av progressiv spridningsmodell som du använder. Du kan till exempel använda en blå-grön modell eller en kanariefågelsmodell. Om du använder en blå-grön modell är det mer praktiskt att återställa än att rulla tillbaka. Du kan enkelt flytta tillbaka trafik till den stack 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 rätt tidpunkt.

• De metoder som du har tillgång till för att kringgå problemet. Några exempel är användning av funktionsflaggor, miljövariabler eller någon annan typ av konfigurationsegenskap för körning som du kan aktivera/inaktivera. Ibland kan du enkelt kringgå ett problem genom att inaktivera en funktionsflagga eller växla en inställning. I så fall kanske du kan:

  • Fortsätta med utrullningen.
  • Undvika återställning.
  • Rulla tillbaka medan du åtgärdar den felaktiga koden.

• Vilken insats som krävs för att implementera en korrigering i koden. Om ansträngningsnivån för att åtgärda koden är låg är det rätt val för vissa scenarier att gå vidare genom att implementera en snabbkorrigering.

• Allvarlighetsnivån för den påverkade arbetsbelastningen. Affärskritiska arbetsbelastningar bör alltid distribueras sida vid sida, på samma sätt som i en blå-grön modell, så att distributionen kan genomföras utan driftavbrott. Därför är det bättre att gå tillbaka för den här typen av arbetsbelastning.

Åtgärd

Här följer några vanliga begränsningsstrategier:

• Återtagning: I ett återtagningsscenario återställs uppdaterade system till det senaste konfigurationstillståndet.

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

  Det kan vara svårt att rulla tillbaka, särskilt när det gäller dataändringar. Schemaändringar kan göra det riskabelt att rulla tillbaka. Det krävs omfattande planering för att implementera dem på ett säkert sätt. Schemauppdateringar bör som en allmän rekommendation vara additiva. Poster ska inte ersättas med nya poster. I stället bör äldre poster fasas ut bort och de ska samexistera med nya poster tills det är säkert att ta bort de utfasade posterna.

• Återställning: I ett återställningsscenario tas de uppdaterade systemen bort från produktionstrafikens dirigering. All trafik dirigeras till den stack som inte uppdateras. Med den här lågriskstrategin kan du lösa problemen i din kod utan att vidare avbrott.

  När det gäller kanariedistributioner är det kanske inte helt enkelt eller ens möjligt att återställa, beroende på infrastrukturen och appdesignen. Om du behöver utföra skalning för att hantera belastning på system som inte är uppdaterade, ska du utföra den skalningen innan du återställer.

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

  Du bör förstå vilka avvägningar som krävs för att kringgå funktionen, och att du bör kommunicera detta med intressenterna. Intressenterna bör godkänna planen. Intressenterna måste avgöra hur lång tid som ett försämrat tillstånd tolereras. De måste också väga in den tid som krävs för att åtgärda 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 all annan kod måste snabbkorrigeringar gå igenom dina säkra distributionsmetoder. Men med en snabbkorrigering påskyndas tidslinjen avsevärt. Du måste använda en kodkampanjsstrategi i alla miljöer. Du måste också kontrollera snabbkorrigeringskoden vid alla kvalitetsgrindar. Men du kan behöva förkorta bearbetningstiden, och du kan behöva ändra testerna för att det ska gå snabbare. Kontrollera att du kan köra fullständiga tester på den uppdaterade koden så fort som möjligt efter distributionen. Genom att i högre grad automatisera kvalitetssäkringstester blir testerna effektiva i de här scenarierna.

Kommunikation

Det är viktigt att tydligt definiera kommunikationsansvar för att minimera kaos vid incidenter. Dessa ansvarsområden bör fastställa hur arbetsbelastningsteamet interagerar med supportteam, intressenter och nödsituationsteam, till en exempel en nödsituationsansvarig.

Standardisera hur ofta arbetsbelastningsteamet ska tillhandahålla statusuppdateringar. Se till att intressenterna känner till den här standarden så att de vet när de kan vänta sig uppdateringar.

Om arbetsbelastningsteamet behöver kommunicera direkt med användarna bör du klargöra vilken typ av information och detaljnivå som är lämplig att dela. Kommunicera även med arbetsbelastningsteamet om andra krav som gäller dessa ärenden.

Utredningar

Utredningar bör genomföras efter alla misslyckade distributioner, utan undantag. Alla misslyckade distributioner utgör en möjlighet att lära sig. Postmortems kan hjälpa dig att identifiera svagheter i dina distributions- och utvecklingsprocesser och felkonfigurationer i infrastrukturen.

Utredningar bör alltid vara klanderfria, så att de individer som är inblandade i incidenter känner sig trygga när de förmedlar sina perspektiv på vad som kan förbättras. Postmortem-ledare bör följa upp med planer för att genomföra de förbättringar som identifieras och för att lägga till dessa planer i eftersläpningen av arbetsbelastningen.

Att tänka på och allmänna rekommendationer

Se till att distributionspipelinen kan acceptera olika versioner som parametrar, så att du enkelt kan distribuera de senast använda konfigurationerna.

Upprätthåll enhetlighet i hanteringen och dataplanerna när du återgår eller fortsätter. Nycklar, hemligheter, databastillståndsdata och konfigurationer som är specifika för resurser och principer måste också kunna användas och någon måste ha ansvar för dem. Var till exempel uppmärksam på utformningen av infrastrukturskalningen i den senast använda distributionen. Bestäm om du behöver ändra konfigurationen när du distribuerar om koden.

Föredra små, frekventa ändringar framför sällsynta, stora ändringar så att skillnaden mellan dina nya och senast fungerande distributioner är liten.

Utför en fellägesanalys på dina pipelines för kontinuerlig integrering och kontinuerlig leverans (CI/CD) för att identifiera problem som kan krångla till begränsningsåtgärderna. Precis som med din arbetsbelastning som helhet kan dina pipelines analyseras för att identifiera områden som kan vara problematiska när du försöker med en viss åtgärdstyp.

Använd den automatiska återställningsfunktionen omdömesgillt:

• Vissa CI/CD-verktyg som Azure DevOps har inbyggda funktioner för automatisk återställning. Överväg att använda den här funktionen om den passar dig.
• Du bör bara använda funktionen för automatisk återställning efter att du har testat pipelinen noggrant och regelbundet. Se till att pipelinen kan hantera nya problem som kan uppstå om en automatisk återställning utlöses.
• Du måste vara säker på att automatiseringen bara distribuerar nödvändiga ändringar och att den bara utlöses när det behövs. Utforma dina utlösare noggrant för att uppfylla dessa krav.

Använd plattformsfunktioner under återställningar. Säkerhetskopieringar och återställning till tidpunkt kan till exempel hjälpa till med lagring och återställning av 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 från omedelbart före en incident.

Testa hela begränsningsstrategin för distributionsfel regelbundet. Precis som med nödsituationsplaner och haveriberedskapsplaner fungerar bara distributionsfelsplanen bara om ditt team är utbildat i den och regelbundet använder den. Kaosteknik och fel felinjektionstestning kan vara effektiva metoder för testning av begränsningsstrategin.

Underlätta Power Platform

Pipelines i Power Platform syftar till att demokratisera hanteringen av programmets livscykel (ALM) för Power Platform och Dynamics 365-kunder genom att föra in ALM-automatisering och kontinuerlig integration och kontinuerlig leverans (CI/CD) i tjänsten.

Microsoft Power Platform Build Tools för Azure DevOps kan för att automatisera vanliga bygg- och distributionsuppgifter relaterade till appar som skapats i Power Platform.

GitHub Actions för Power Platform kan utvecklare bygga automatiska livscykel-arbetsflöden för programutveckling. Med GitHub-åtgärder för Microsoft Power Platform, kan du skapa arbetsflöden i ditt arkiv för att bygga, testa, paketera, släppa och distribuera program; utföra automatisering; och hantera bots och andra komponenter som bygger på Microsoft Power Platform.

ALM Accelerator är ett verktyg med öppen källkod som består av en uppsättning program, skript och pipelines som är utformade för att automatisera processen för kontinuerlig integrering/kontinuerlig leverans.

Automatisera tester med Azure-pipelines.

Använd Power CAT Copilot Studio-paket för att konfigurera agenter och tester. Genom att köra enskilda tester mot Copilot Studio API:erna (Direct Line) utvärderas agentens svaren mot förväntade resultat.

Miljövariabler i lösningar lagrar parameternycklarna och värdena, som sedan fungerar som indata till andra programobjekt. Genom att separera parametrarna från de tidskrävande objekten kan du ändra värdena i samma miljö eller när du migrerar lösningar till andra miljöer.

Power Platform -miljöer tillhandahåller funktioner för återställning till tidpunkt som kan hjälpa dig att återställa.

Power Platform integreras med Application Insights, som ingår i Azure Monitor-ekosystemet. Använd integreringen för att:

• Ta emot telemetri om diagnostik och prestanda som samlats in av Dataverse-plattformen i Application Insights. Du kan prenumerera på mottagning av telemetri om åtgärder som applikationer utför på din Dataverse databas och inom modellbaserade program. Denna telemetri innehåller information som du kan använda för att diagnostisera och felsöka problem relaterade till fel och prestanda.

• Anslut dina arbetsyteappar till Application Insights. Med hjälp av dessa analyser kan du diagnostisera problem och förstå vad användarna gör med dina appar. Du kan samla in information som hjälper dig att fatta bättre affärsbeslut och förbättra kvaliteten på dina appar.

• Konfigurera Power Automate telemetri som ska flöda till Application Insights, till exempel för att övervaka molnflödeskörningar och skapa aviseringar för fel vid molnflödeskörningar.

• Samla in telemetridata från din Microsoft Copilot Studio agent för användning i Azure Application Insights. Du kan använda den här telemetrin för att övervaka loggade meddelanden och händelser som skickas till och från din agent, ämnen som ska utlösas under användarkonversationer och anpassade telemetrihändelser som kan skickas från dina ämnen.

Checklista för driftförutsättningar

Se den fullständiga uppsättningen med rekommendationer.

Checklista för driftförutsättningar