Anbefalinger for utforming av en strategi for løsningsstrategi for distribusjonsfeil
Gjelder denne Power Platform Well-Architected Framework Operational Excellence-sjekklisteanbefalingen:
| OE:11 | Implementer en strategi for å redusere distribusjonsfeil som løser uventede problemer under utrullingen med rask gjenoppretting. Kombiner flere fremgangsmåter, for eksempel tilbakerulling, deaktivering av funksjoner eller bruk av de opprinnelige funksjonene i utrullingsmønsteret. |
|---|
Denne veiledningen beskriver anbefalingene ved utforming av en standardisert strategi for effektivt å håndtere distribusjonsfeil. I likhet med andre arbeidsbelastningsproblemer er utrullingsfeil en uunngåelig del av en livssyklus for arbeidsbelastninger. Med dette tankesettet kan du være proaktiv ved å ha en godt utformet, forsettlig strategi for håndtering av distribusjonsfeil. En slik strategi gjør at arbeidsbelastningsteamet effektivt kan redusere feil med så liten innvirkning som mulig på brukerne.
Fraværet av en slik plan kan føre til kaotiske og potensielt skadelige svar på problemer, noe som kan ha betydelig innvirkning på team- og organisasjonskohesjon, kundetillit og økonomi.
Viktige utformingsstrategier
Fra tid til annen oppstår distribusjonsproblemer til tross for modenheten i utviklingspraksisen. Bruk av sikker distribusjonspraksis og en kraftig arbeidsbelastningsforsyningskjede kan hjelpe deg med å redusere hyppigheten av mislykkede distribusjoner. Du må også utforme en standardisert strategi for å håndtere mislykkede utrullinger når de skjer.
En strategi for å redusere distribusjonsfeil består av fem hovedfaser:
- Registrering: For å reagere på en mislykket utrulling må du først registrere feilen. Deteksjon kan ta flere former, for eksempel mislykkede røyktester, brukerrapporter eller varsler som overvåkingsplattformen genererer.
- Beslutning: Du må bestemme hva som er den beste løsningsstrategien for den bestemte feiltypen.
- Løsning: Du må utføre den identifiserte begrensningshandlingen. Løsningen kan være en tilbakestilling, tilbakerulling eller fremoverrulling.
- Kommunikasjon: Interessenter og berørte brukere må gjøres oppmerksomme på statusen når du oppdager og arbeider deg gjennom problemet, slik det kreves av beredskapsplanen.
- Konklusjon: Konklusjoner som ikke fordeler skyld, gir arbeidsbelastningsteamet mulighet til å identifisere områder for forbedring og lage planer for å ta i bruk lærdommer.
Delene nedenfor inneholder detaljerte anbefalinger for disse fasene.
Registrering
Hvis du raskt vil identifisere problemer med utrullinger, trenger du robuste test- og overvåkingspraksiser som er relatert til utrullinger. For å oppdage avvik raskt kan du komplettere overvåkingen og varslingen av arbeidsbelastningen ved å bruke et administrasjonsverktøy for programytelse og logge gjennom instrumentering.
Pretesting og andre kvalitetstester skal skje i hver fase av utrullingen. Vellykkede tester i én distribusjonsgruppe bør ikke påvirke avgjørelser om å teste i påfølgende grupper.
Du kan implementere telemetri som korrelerer brukerproblemer med en distribusjonsfase. Deretter kan du raskt identifisere hvilken utrullingsgruppe en bestemt bruker er tilknyttet. Denne metoden er spesielt viktig for progressive eksponeringsdistribusjoner fordi du kan ha flere konfigurasjoner som kjører på tvers av brukerbasen din når som helst i distribusjonen.
Du må være klar til å svare på brukerrapporterte problemer umiddelbart. Når det er praktisk, distribuerer du utrullingsfasen i arbeidstiden når du har et fullstendig støtteteam tilgjengelig. Sørg for at støttepersonalet er opplært i hvordan de kan eskalere utrullingsproblemer for riktig ruting. Eskaleringer må samsvare med nødresponsplanen for arbeidsbelastningen.
Beslutning
Å avgjøre en passende løsningsstrategi for et utrullingsproblem innebærer å vurdere faktorer som:
Typen progressiv eksponeringsmodell du bruker. Du kan for eksempel bruke en blågrønn modell eller en kanarimodell. Hvis du bruker en blågrønn modell, er det mer praktisk å falle tilbake enn å rulle tilbake. Du kan enkelt flytte trafikk tilbake til stakken som kjører konfigurasjonen som ikke er oppdatert. Du kan deretter løse problemet i det problematiske miljøet og prøve distribusjonen på nytt på et passende tidspunkt.
Metodene du kan bruke når du ønsker å omgå problemet. Eksempler omfatter bruk av funksjonsflagg, miljøvariabler eller andre typer egenskaper for kjøretidskonfigurasjoner som du kan aktivere og deaktivere. Noen ganger kan du enkelt omgå et problem ved å slå av et funksjonsflagg eller slå på en innstilling. I dette tilfellet kan det hende du kan gjøre følgende:
- Fortsett med utrullingen.
- Unngå å falle tilbake.
- Rull tilbake mens du reparerer den problematiske koden.
Innsatsnivået som kreves for å implementere en rettelse i koden. Hvis innsatsnivået for å fikse koden er lavt, er det riktige valget for bestemte scenarioer å rulle fremover ved å implementere en hurtigreparasjon.
Kritikalitetsnivået for den berørte arbeidsbelastningen. Forretningskritiske arbeidsbelastninger bør alltid distribueres side ved side, på samme måte som i en blågrønn modell, for å oppnå distribusjoner med null nedetid. Dette fører til at du må gå tilbake og heller foretrekke en løsningsstrategi for denne typen arbeidsbelastninger.
Reduksjon
Følgende er noen vanlige løsningsstrategier:
Tilbakerulling: I et tilbakerullingsscenario reverserer du oppdaterte systemer til konfigurasjonstilstanden som sist var kjent som god.
Det er viktig for hele arbeidsbelastningsteamet å bli enige om betydningen av «sist kjente gode». Dette uttrykket henviser til den siste tilstanden for arbeidsbelastningen som var frisk før utrullingen begynte, som ikke nødvendigvis er den forrige programversjonen.
Det kan være komplisert å rulle tilbake, spesielt når det gjelder dataendringer. Skjemaendringer kan gjøre det risikabelt å rulle tilbake. Implementering av dem på en sikker måte kan kreve betydelig planlegging. Som en generell anbefaling bør skjemaoppdateringer være additive. Poster skal ikke erstattes med nye poster. I stedet bør eldre oppføringer avskrives og eksistere sammen med nye oppføringer til det er trygt å fjerne de avskrevne oppføringene.
Reserve: I et reservescenario fjernes de oppdaterte systemene fra rutingen av produksjonstrafikken. All trafikk omdirigeres til stakken som ikke er oppdatert. Denne lavrisikostrategien gjør det mulig for deg å løse problemene i koden uten at det blir flere avbrudd.
Med kanaridistribusjoner er det ikke enklere eller en gang mulig å falle tilbake, avhengig av infrastrukturen og apputformingen. Hvis du må utføre skalering for å håndtere belastning på systemer som ikke er oppdatert, utfører du denne skaleringen før du faller tilbake.
Hopp over den skadelige funksjonen: Hvis du kan omgå problemet ved å bruke funksjonsflagg eller en annen type konfigurasjonsegenskap for kjøretid, kan du bestemme at det å fortsette med utrullingen er riktig strategi for et problem.
Du bør forstå avveiningene ved omgåelse av funksjonen, og du må kunne kommunisere denne avveiningen til interessenter. Interessenter bør godkjenne planen for å gå videre. Interessenter må bestemme hvor lenge det drift i redusert tilstand skal tolereres. De må også vekte denne beslutningen opp mot ditt estimat for hvor lang tid det tar å rette koden og distribuere den.
Nødutrulling (hurtigreparasjon): Hvis du kan løse problemet midt i utrullingen, kan en hurtigreparasjon være den mest praktiske løsningsstrategien.
I likhet med all annen kode må hurtigreparasjoner gå gjennom sikker utrullingspraksis. Men med en hurtigreparasjon blir tidslinjen betydelig akselerert. Du må bruke en kodekampanjestrategi i hele miljøet. Du må også sjekke hurtigreparasjonskoden ved alle kvalitetsporter. Det kan imidlertid hende du må redusere innkjøringstiden betraktelig, og det kan hende du må endre tester for å fremskynde dem. Kontroller at du kan kjøre fullstendige tester på den oppdaterte koden så snart som mulig etter distribusjonen. Automatisering av kvalitetssikringstesting i stor grad bidrar til å gjøre testingen effektiv i disse scenarioene.
Kommunikasjon
Det er viktig å tydelig definere kommunikasjonsansvar for å redusere kaoset under hendelser. Disse ansvarsområdene bør fastsette hvordan arbeidsbelastningsteamet samhandler med kundestøtteteam, interessenter og personale i beredskapsteamet, for eksempel sjefen for beredskapssvar.
Standardiser frekvensen som arbeidsbelastningsteamet følger for å oppdatere statusen. Sørg for at interessenter er klar over denne standarden, slik at de vet når de kan forvente oppdateringer.
Hvis arbeidsbelastningsteamet trenger å kommunisere direkte med brukere, må du avklare hvilken type informasjon og detaljnivå som passer for deling. Kommuniser også med arbeidsbelastningsteamet eventuelle andre krav som gjelder for disse sakene.
Konklusjon
Konklusjoner må følge alle mislykkede utrullinger, uten unntak. Alle mislykkede distribusjoner er en mulighet for læring. Konklusjoner kan hjelpe deg med å identifisere svakheter i utrullings- og utviklingsprosesser og feilkonfigurasjoner i infrastrukturen.
Konklusjoner må alltid være uten skyldfordeling, slik at personer som er involvert i hendelsen, skal føle seg trygg når de deler sine perspektiver på hva som kan forbedres. Konklusjonsledere bør følge opp med planer for implementering av forbedringene som er identifisert og for å legge disse planene til arbeidsbelastningsetterslepet.
Vurderinger og generelle anbefalinger
Kontroller at distribusjonsforløpet kan godta ulike versjoner som parametere, slik at du enkelt kan distribuere siste gode konfigurasjoner.
Oppretthold ensartethet med administrasjonen og dataplanene når du ruller tilbake eller ruller fremover. Nøkler, hemmeligheter, databasetilstandsdata og konfigurasjoner som er spesifikke for ressurser og policyer, må være i omfang og tatt hensyn til. Ta for eksempel hensyn til utformingen av infrastrukturen som skaleres i den siste gode distribusjonen. Avgjør om du må justere konfigurasjonen når du repliserer koden.
Foretrekk små, hyppige endringer fremfor sjeldne, store endringer, slik at forskjellen mellom de nye og de siste fungerende utrullingene er liten.
Utfør en feilmodusanalyse på de kontinuerlige integrasjons- og CI/CD-forløpene for å hjelpe deg med å identifisere problemer som kan komplisere løsningsarbeidet. På samme måte som med arbeidsbelastningen som helhet, kan kanalene analyseres for å identifisere områder som kan være problematiske når du prøver en gitt løsningstype.
Bruk automatisk tilbakerullingsfunksjonalitet med omhu:
- Noen CI/CD-verktøy som Azure DevOps har innebygd automatisk tilbakerullingsfunksjonalitet. Vurder å bruke denne funksjonaliteten hvis det gir konkret verdi for deg.
- Du bør bare ta i bruk automatisk tilbakerullingsfunksjonalitet etter at du har testet forløpet grundig og regelmessig. Sørg for at forløpet er modent nok til å introdusere ekstra problemer hvis en automatisk tilbakerulling utløses.
- Du må klarere at automatiseringen distribuerer bare nødvendige endringer, og at den bare utløses når det er nødvendig. Utform utløserne nøye for å oppfylle disse kravene.
Bruk funksjoner som leveres av plattformen, under tilbakerullinger. For eksempel kan sikkerhetskopiering og øyeblikksgjenoppretting hjelpe med lagring og tilbakerulling av data. Eller hvis du bruker virtuelle maskiner som vert for programmet, kan det være nyttig å gjenopprette miljøet til et kontrollpunkt fra umiddelbart før en hendelse.
Test hele løsningsstrategien ofte for distribusjonsfeil. Som tiltaksplaner for beredskap og planer for gjenoppretting etter katastrofer er planen for distribusjonsfeil bare vellykket hvis teamet har opplæring i den og bruker den regelmessig. Kaosutvikling og testing av introduksjon av feil kan være effektive teknikker for testing av løsningsstrategien for utrullingen.
Tilrettelegging for Power Platform
Pipeliner i Power Platform tar sikte på å demokratisere administrasjon av programlivssyklus for Power Platform- og Dynamics 365-kunder ved å innføre ALM-automatisering og kontinuerlig integrasjon og kontinuerlig levering (CI/CD) inn i tjenesten.
Microsoft Power Platform Build Tools for Azure DevOps kan brukes til å automatisere vanlige kompilerings- og utrullingsoppgaver relatert til apper som er basert på Power Platform.
GitHub-handlinger for Power Platform gjør det mulig for utviklere å bygge automatiske arbeidsflyter for livssyklus for programvareutvikling. Med GitHub-handlinger for Microsoft Power Platform kan du opprette arbeidsflyter i lageret for å bygge, teste, pakke, distribuere og distribuere apper, utføre automatisering og administrere automatiseringer og andre komponenter som er innebygd i Microsoft Power Platform.
ALM Accelerator er et verktøy med åpen kildekode som består av et sett med programmer, skripter og kanaler som er utformet for å automatisere prosessen for kontinuerlig integrasjon / kontinuerlig levering.
Automatiser tester med Azure-forløp.
Bruk Power CAT Copilot Studio-pakke til å konfigurere agenter og tester. Ved å kjøre individuelle tester mot Copilot Studio-API-ene (Direct Line), evalueres agentsvarene mot forventede resultater.
Miljøvariabler i løsninger lagrer parameternøklene og verdiene, som deretter fungerer som inndata til andre programobjekter. Hvis du skiller parameterne fra forbrukerobjektene, kan du endre verdiene i det samme miljøet eller når du overfører løsninger til andre miljøer.
Power Platform-miljøer gir funksjonalitet for tidspunktbasert gjenoppretting som kan hjelpe deg å rulle tilbake.
Power Platform integreres med Application Insights, som er en del av Azure Monitor-økosystemet. Bruk denne integreringen til å gjøre følgende:
Motta telemetri om diagnostisering og ytelse som registreres av Dataverse-plattformen i Application Insights. Du kan abonnere for å motta telemetri om operasjoner som programmer utfører i Dataverse-databasen og i modelldrevne apper. Denne telemetrien inneholder informasjon som du kan bruke til å diagnostisere og feilsøke problemer relatert til feil og ytelse.
Koble lerretsappene til Application Insights. Du kan bruke disse analysene til å diagnostisere problemer og forstå hva brukerne gjør med appene dine. Du kan samle inn informasjon som hjelper deg med å ta bedre forretningsavgjørelser og forbedre kvaliteten på appene dine.
Konfigurer Power Automate-telemetri til å flyte inn i Application Insights, for eksempel for å overvåke kjøring av skyflyt og opprette varsler for feil ved skyflytkjøring.
Registrer telemetridata fra Microsoft Copilot Studio-agent for bruk i Azure Application Insights. Du kan bruke denne telemetrien til å overvåke loggede meldinger og hendelser som sendes til og fra agent, emner som skal utløses under brukersamtaler, og egendefinerte telemetrihendelser som kan sendes fra emnene.
Sjekklisten for driftskvalitet
Se hele settet med anbefalinger.