Anbefalinger til design af en strategi til afhjælpning af installationsfejl
Dette gælder for denne Power Platform kontrolliste til velarkitekt driftsmæssige kontrollister:
| OE:11 | Implementer en strategi til afhjælpning af udrulningsfejl, der løser uventede problemer under udrulning med hurtig gendannelse. Kombiner flere fremgangsmåder, f.eks. tilbagerulning, deaktivering af funktioner eller brug af de indbyggede funktioner i udrulningsmønsteret. |
|---|
I denne vejledning beskrives anbefalingerne til design af en standardiseret strategi til effektiv håndtering af implementeringsfejl. Ligesom andre problemer med arbejdsbelastningen er installationsfejl en uundgåelig del af arbejdsbelastningens livscyklus. Med dette eksempel kan du være proaktiv ved at have en veldesignet, tilsigtet strategi, så du kan håndtere fejl i installationen. En sådan strategi gør det muligt for dit arbejdsbelastningsteam effektivt at afhjælpe fejl med så lille indvirkning som muligt på dine brugere.
Hvis der ikke findes en sådan plan, kan det medføre hurtige svar på problemer, der kan have en betydelig indflydelse på gruppe- og organisationsstruktur, kundetillid og tillidsforhold.
Vigtigste designstrategier
Til tider opstår der problemer med installationen, selvom dine udviklingsmetoder er så forskellige. Hvis du bruger sikre installationsmetoder og kører en robust arbejdsbelastning, kan du minimere hyppigheden af mislykkede installationer. Du skal også designe en standardiseret strategi til håndtering af mislykkede udrulninger, når de sker.
En strategi for afhjælpning af fejl i installationen består af fem overordnede faser:
- Registrering: Hvis du vil reagere på en mislykket installation, skal du først registrere fejlen. Detektion kan antage flere former, såsom mislykkede røgtest, brugerrapporter eller advarsler, som din overvågningsplatform genererer.
- Beslutning: Du skal beslutte, hvad den bedste afhjælpningsstrategi er for den specifikke fejltype.
- Reduktion: Du skal udføre den identificerede afhjælpningshandling. Afhjælpningen kan tage form af reserve, annullering eller videresendelse.
- Kommunikation: Interessenter og berørte brugere skal gøres opmærksomme på statussen, når du registrerer og arbejder dig igennem problemet, som krævet i din beredskabsplan.
- Post-mortem: Uløselige indlæg giver arbejdsbelastningsgruppen mulighed for at identificere områder, hvor der kan forbedres, og oprette planer for anvendelse af læring.
Følgende afsnit indeholder detaljerede anbefalinger til hvert af disse faser.
Registrering
Hvis du hurtigt vil identificere problemer med udrulninger, har du brug for robuste test- og overvågningspraksisser, der vedrører udrulninger. For at hjælpe med at registrere uregelmæssigheder hurtigt kan du supplere overvågningen af og advarslerne om din arbejdsbelastning ved hjælp af et værktøj til styring af programmets ydeevne og logføring gennem instrumentering.
Test af test af møg og andre kvalitetstest skal udføres i hver fase af udrulningen. Vellykkede test i én installationsgruppe bør ikke påvirke beslutninger, der skal testes i efterfølgende grupper.
Du kan implementere telemetri, der korrelerer brugerproblemer med en installationsfase. Derefter kan du hurtigt identificere, hvilken udrulningsgruppe en bestemt bruger er tilknyttet. Denne fremgangsmåde er især vigtig i forbindelse med progressiv opsætning af installationer, da du kan have flere konfigurationer, der kører på tværs af brugerbasen på et hvilket som helst tidspunkt i installationen.
Du skal være klar til at reagere på brugerrapporterede problemer med det samme. Når det er praktisk, kan du installere udrulningsfasen i arbejdstiden, når der er et fuldt supportteam tilgængeligt. Sørg for, at supportmedarbejderne er uddannet i, hvordan de eskalerer udrulningsproblemer for at sikre korrekt routing. Eskaleringer skal tilpasses i forhold til responsplanen for arbejdsbelastning.
Beslutning
Beslutningen om en passende afbødningsstrategi for et udrulningsproblem indebærer overvejelser om faktorer som:
Den type model til progressivt mønster, du bruger. Du kan f.eks. bruge en blå-grøn model eller en kanarisk model. Hvis du bruger en blå-grøn model, er det mere praktisk at vende tilbage end at rulle tilbage. Du kan nemt flytte trafik tilbage til den stak, der kører den konfiguration, der ikke er opdateret. Du kan derefter løse problemet i det problematiske miljø og prøve at installere igen på et passende tidspunkt.
De metoder, du har til rådighed, til at springe problemet over. Af eksempler kan nævnes brug af funktions flag, miljøvariabler eller andre typer af kørselskonfigurationsegenskab, som du kan slå til eller fra. Nogle gange kan du nemt omgå et problem ved at slå et funktions flag eller en indstilling fra. I dette tilfælde kan du måske:
- Fortsæt med udrulningen.
- Undgå at blive tilbage igen.
- Rul tilbage, mens du reparerer den stødende kode.
Den indsats, der kræves for at implementere en rettelse i koden. Hvis indsatsen for at rette koden er lav, er det rigtige valg at rulle fremad ved at implementere et hotfix i visse scenarier.
Graden af kritiskhed for den berørte arbejdsbelastning. Arbejdsbelastninger, der er vigtige for virksomheden, skal altid installeres side om side, f.eks. i en blå-grøn model, for at opnå installationer med nul nedetid. Tilbagefald er derfor den foretrukne afhjælpningsstrategi for disse typer arbejdsbelastninger.
Afhjælpning
Følgende er nogle almindelige afhjælpningsstrategier:
Annullering: I et annulleringsscenario kan du ændre opdaterede systemer til den senest kendte gode konfigurationstilstand.
Det er vigtigt, at hele arbejdsbelastningsteamet bliver enige om betydningen af "sidst kendte gode". Dette udtryk refererer til den sidste tilstand af arbejdsbelastningen, der var sund, før udrulningen startede, hvilket ikke nødvendigvis er den tidligere programversion.
Det kan være komplekst at gå tilbage, især fordi det er relateret til dataændringer. Skemaændringer kan gøre det risikopåliggende at rulle tilbage. Hvis de implementeres sikkert, kan det kræve planlægning. Som en generel anbefaling skal skemaopdateringer være additive. Poster bør ikke erstattes med nye poster. I stedet bør ældre poster frarådes, og de skal findes sammen med nye poster, indtil det er sikkert at fjerne de frabedte poster.
Reserve: I et reservescenarie fjernes de opdaterede systemer fra produktionstrafikrouting. Al trafik omdirigeres til den stak, der ikke opdateres. Du kan bruge denne strategi til lave risici til at løse problemerne i koden uden at introducere yderligere forstyrrelser.
Med kanariske installationer er det måske ikke ligetil eller endda muligt at vende tilbage, afhængigt af infrastrukturen og appdesignet. Hvis du skal udføre skalering for at håndtere belastningen på systemer, der ikke opdateres, skal du udføre denne skalering, før du falder tilbage.
Omgå den fejlbehæftede funktion: Hvis du kan tilsidesætte problemet ved hjælp af funktionsflag eller en anden type egenskab til konfiguration af kørsel, kan du beslutte, at det er den rigtige strategi for et problem at fortsætte med udrulningen.
Du skal klart forstå afvejning af omgåelse af funktionen, og du skal kunne kommunikere denne afvejning til interessenter. Interessenterne skal godkende planen for videresendelse. Interessenter skal afgøre, hvor lang tid der kan bruges til at arbejde i forringet tilstand. De skal også afveje denne bestemmelse i forhold til din anslåede tid, der er nødvendig for at rette den angrebne kode og installere den.
Nødinstallation (hotfix): Hvis du kan løse problemet midt i udrulningen, kan et hotfix være den mest praktiske afhjælpningsstrategi.
Som enhver anden kode skal hotfixes gennemgå din sikre udrulningspraksis. Men med et hotfix accelereres tidslinjen betydeligt. Du skal bruge en strategi for kodekampagner i hele miljøet. Du skal også kontrollere hotfixkode ved alle kvalitetsporte. Men det kan være nødvendigt at afkorte tiderne hurtigt, og du skal måske ændre testene for at gøre dem hurtigere. Sørg for, at du kan køre komplette test af den opdaterede kode hurtigst muligt efter installationen. Ved i høj grad at automatisere test af kvaliteten er det med til at effektivisere testene i disse scenarier.
Kommunikation
Det er vigtigt at definere kommunikations ansvarsområder klart for at minimere kaos i forbindelse med hændelser. Disse ansvarsområder skal fastlægge, hvordan arbejdsbelastningsgruppen skal involvere supportteams, interessenter og medarbejdere i responsteamet som f.eks. responschefen.
Standardisere den cadence, som arbejdsbelastningsgruppen følger for at levere statusopdateringer. Sørg for, at interessenterne er opmærksomme på denne standard, så de ved, hvornår de kan forvente opdateringer.
Hvis arbejdsbelastningsteamet har brug for at kommunikere direkte med brugerne, skal du tydeliggøre, hvilken type oplysninger og detaljeringsgrad der er relevante til deling. Du kan også kommunikere eventuelle andre krav, der gælder for disse sager, til arbejdsbelastningsgruppen.
Post-mortem
Post-mortems bør følge alle mislykkede installationer uden undtagelse. Alle mislykkede installationer er en mulighed for læring. Postmortems kan hjælpe dig med at identificere svagheder i dine implementerings- og udviklingsprocesser og fejlkonfigurationer i din infrastruktur.
Post-mortems skal altid være uløselige, så de personer, der er involveret i hændelsen, føler sig sikre, når de deler deres perspektiver på, hvad der kan forbedres. Postmortem-ledere bør følge op med planer for implementering af de forbedringer, der er identificeret, og for at tilføje disse planer til arbejdsbyrdens efterslæb.
Overvejelser og generelle anbefalinger
Sørg for, at installationspipelinen kan acceptere forskellige versioner som parametre, så du nemt kan installere konfigurationer, der kendes sidst.
Bevare konsistensen i administrationen og dataene, når du ruller tilbage eller ruller fremad. Nøgler, hemmeligheder, databasetilstandsdata og konfigurationer, der er specifikke for ressourcer og politikker, skal alle være omfattet og tages i betragtning. Vær f.eks. opmærksom på designet af infrastrukturens skalering i den senest kendte gode installation. Find ud af, om du skal justere konfigurationen, når du geninstallerer koden.
Foretræk små, hyppige ændringer frem for sjældne, store ændringer, så forskellen mellem dine nye og sidst kendte fungerende udrulninger er lille.
Udfør en analyse af fejltilstanden på dine pipelines til løbende integration og løbende levering (CI/CD) for at identificere problemer, der kan komplicere afhjælpningsindsatsen. Som med din arbejdsbelastning som helhed kan dine pipelines analyseres for at identificere områder, der kan være problematiske, når du forsøger en given afhjælpningstype.
Brug automatisk annulleringsfunktionalitet:
- Nogle CI/CD-værktøjer som Azure DevOps har f.eks. indbyggede funktioner til automatisk annullering. Overvej at bruge denne funktion, hvis den giver dig en håndgribelig værdi.
- Du bør først anvende funktioner til automatisk annullering, når du har testet pipelinen grundigt og jævnligt. Sørg for, at pipelinen er tilstrækkelig moden til at introducere ekstra problemer, hvis der udløses en automatisk annullering.
- Du skal have tillid til, at automatiseringen kun implementerer de nødvendige ændringer, og at de kun udløses, når det er nødvendigt. Design udløserne omhyggeligt for at imødekomme disse krav.
Brug funktioner, der leveres på platform, under annullering af opdatering. For eksempel kan sikkerhedskopier og tidsgendannelse hjælpe med lagring og tilbageførsel af data. Eller hvis du bruger virtuelle maskiner som vært for dit program, kan det være nyttigt at gendanne miljøet til et kontrolpunkt fra umiddelbart før en hændelse.
Test hele strategien for afhjælpning af fejl i installationen ofte. På samme måde som planer for katastrofeberedskab og planer for it-katastrofeberedskab lykkes installationen kun, hvis dit team er uddannet i det og bruger den jævnligt. Test af kaosteknik og fejlinjektion kan være effektive teknikker til test af strategien for begrænsning af installationen.
Power Platform-processtyring
Pipelines i Power Platform har til formål at udnytte ALM-funktionerne (Application Lifecycle Management) for Power Platform og Dynamics 365-kunder ved at udnytte ALM-automatisering og løbende integration og funktioner til løbende levering (CI/CD) til servicen.
Microsoft Power Platform Opbyg værktøjer til Azure DevOps kan bruges til at automatisere almindelige build- og udrulningsopgaver til apps, der bygger på Power Platform.
GitHub handlinger til Power Platform gør det muligt for udviklere at bygge automatiserede arbejdsprocesser for softwareudviklingens livscyklus. Med GitHub-handlinger for Microsoft Power Platform kan du oprette arbejdsprocesser i dit lager for at bygge, teste, pakke, frigive og installere apps, udføre automatisering og administrere bots og andre komponenter, der er bygget på Microsoft Power Platform.
ALM Accelerator er et open source-værktøj, der består af et sæt programmer, scripts og pipelines, der er udviklet til at automatisere den kontinuerlige integration/kontinuerlige leveringsproces.
Automatisere test med Azure-pipelines.
Brug Power CAT Copilot Studio-pakke til at konfigurere agenter og tests. Ved at køre individuelle tests i forhold til Copilot Studio API'erne (Direct Line) evalueres agent-svarene i forhold til de forventede resultater.
Miljøvariabler i løsninger lagrer parameternøglerne og -værdierne, som derefter fungerer som input til forskellige andre programobjekter. Hvis du adskiller parametrene fra de forbrugende objekter, kan du ændre værdierne i det samme miljø, eller når du overfører løsninger til andre miljøer.
Power Platform -miljøer indeholder funktioner til gendannelse i realtid, der kan hjælpe dig med at vende tilbage.
Power Platform integreres med Application Insights, som er en del af Azure Monitor-økosystemet. Brug denne integration til at:
Modtage telemetri på diagnose og ydeevne, der registreres af Dataverse-platformen i Application Insights. Du kan abonnere på telemetri om handlinger, som programmer udfører Dataverse på din database og i modelbaserede apps. Denne telemetri kan bruges til at diagnosticere og foretage fejlfinding af problemer, der vedrører fejl og ydeevne.
Oprette forbindelse mellem dine lærredapps og Application Insights. Du kan bruge disse analyser til at diagnosticere problemer og forstå, hvad brugerne gør med dine apps. Du kan indsamle oplysninger, der kan hjælpe dig med at træffe bedre beslutninger i virksomheden og forbedre kvaliteten af dine apps.
Konfigurer Power Automate telemetri til at flyde ind i Application Insights - f.eks. til at overvåge udførelse af cloud flows og oprette beskeder om fejl under udførelse af cloud flows.
Registrer telemetridata fra din Microsoft Copilot Studio agent til brug i Azure Application Insights. Du kan bruge denne telemetri til at overvåge logførte meddelelser og hændelser, der sendes til og fra din agent, emner, der skal udløses under brugersamtaler, og brugerdefinerede telemetrihændelser, der kan sendes fra dine emner.
Tjekliste for Driftsmæssige præstationer
Se det fuldstændige sæt anbefalinger.