Anbefalinger for å utføre feilmodusanalyse
Gjelder denne Power Platform Well-Architected Reliability-sjekklisteanbefalingen:
| RE:03 | Bruk feilmodusanalyse til å identifisere og prioritere potensielle feil i løsningskomponentene. Utfør feilmodusanalyse for å hjelpe deg med å vurdere risikoen for og virkningen av hver feilmodus. Avgjør hvordan arbeidsbelastningen svarer og gjenopprettes. |
|---|
Denne veiledningen beskriver de beste fremgangsmåtene for å utføre feilmodusanalyse (FMA) for arbeidsbelastningen. FMA er praksisen med å identifisere potensielle feilpunkter i arbeidsbelastningen og de tilknyttede flytene og planlegging av løsningshandlinger i henhold til dette. Ved hvert trinn i flyten identifiserer du utbruddet av flere feiltyper, noe som hjelper deg med å utforme en ny arbeidsbelastning eller refaktorering av en eksisterende arbeidsbelastning for å redusere antall feil som oppstår.
En viktig slutning i FMA er at feil oppstår uansett hvor mange lag med fleksibilitet du bruker. Mer komplekse miljøer utsettes for flere typer feil. På grunn av denne feilen kan du bruke FMA til å utforme arbeidsbelastningen slik at den kan stå imot de fleste typer feil og gjenopprette når en feil oppstår.
Hvis du hopper over FMA helt eller utfører en ufullstendig analyse, står arbeidsbelastningen i fare for uventet virkemåte og potensielle avbrudd forårsaket av deloptimal utforming.
Definisjoner
| Term | Definisjon |
|---|---|
| Feilmodus | En type problem som kan føre til at en eller flere arbeidsbelastningskomponenter blir redusert eller sterkt påvirket til det punktet at den ikke er tilgjengelig. |
| Reduksjon | Aktivitetene du har identifisert for å løse problemer, enten proaktivt eller reaktivt. |
| Registrering | Data- og appovervåkning og varselprosesser og -prosedyrer. |
Viktige utformingsstrategier
Når det gjelder FMA, er det avgjørende å forstå forhåndskravene. Begynn med å se gjennom og implementere anbefalinger for identifisering av flyter ved å prioritere dem basert på viktighet. Dataartefaktene spiller en viktig rolle i å beskrive databanene i disse flytene. Når du fordyper deg i FMA-metoden, fokuserer du på å planlegge komponenter for kritiske flyter, identifisere avhengigheter (både interne og eksterne) og utarbeide løsningsstrategier.
Forutsetning
Gjennomgå og implementer anbefalingene for identifisering og vurdering av flyter. Det antas at du har identifisert og prioritert bruker- og systemflyter basert på viktighet.
Dataene du har samlet inn, og artefaktene du har opprettet i arbeidet, gir en konkret beskrivelse av databanene som er involvert i flytene. For å lykkes i FMA-arbeidet er nøyaktighet og grundighet i artefaktene svært viktig.
FMA-metode
Når du har fastslått de avgjørende flytene, kan du planlegge de nødvendige komponentene. Deretter følger du hver flyt trinnvis for å identifisere avhengigheter, inkludert tredjepartstjenester og potensielle feilpunkter, og planlegge løsningsstrategiene.
Del opp arbeidsbelastningen
Når du går fra forslag til utforming, må du identifisere komponenttypene som kreves for å støtte arbeidsbelastningen. Arbeidsbelastningen din avgjør nødvendige komponenter som du må planlegge for.
Når du har opprettet den opprinnelige arkitekturutformingen, kan du overlappe flytene for å identifisere de diskrete komponentene som brukes i disse flytene, og opprette lister eller arbeidsflytdiagrammer som beskriver flytene og komponentene i dem. Hvis du vil forstå viktigheten til komponentene, bruker du definisjonene for viktighet som du har tildelt til flytene. Vurder virkningen av en komponentfeil på flytene.
Identifiser avhengigheter
Identifiser avhengighetene for arbeidsbelastningen for å utføre feilanalysen på ett enkelt punkt. Når du deler opp arbeidsbelastningen og overlappingsflytene, får du innsikt i avhengigheter som er interne og eksterne for arbeidsbelastningen.
Interne avhengigheter er komponenter i arbeidsbelastningsområdet som er nødvendig for at arbeidsbelastningen skal fungere. Vanlige interne avhengigheter omfatter API-er eller løsninger for hemmelighet/nøkkeladministrasjon, for eksempel Azure Key Vault. For disse avhengighetene registrerer du pålitelighetsdata, for eksempel tjenesteavtaler for tilgjengelighet og begrensninger for skalering. Eksterne avhengigheter er nødvendige komponenter utenfor omfanget av arbeidsbelastningen, for eksempel et annet program eller en tredjepartstjeneste. Vanlige eksterne avhengigheter omfatter godkjenningsløsninger, for eksempel Microsoft Entra ID og Power Platform-infrastruktur.
Identifiser og dokumenter avhengighetene i arbeidsbelastningen, og inkluder dem i flytdokumentasjonsartefaktene.
Feilpunkter
I de viktige flytene i arbeidsbelastningen må du vurdere hver enkelt komponent og avgjøre hvordan komponenten og avhengighetene, kan bli påvirket av en feilmodus. Husk at det finnes mange feilmoduser du må vurdere når du planlegger å bruke elastisitet og gjenoppretting. Alle komponenter kan påvirkes av mer enn én feilmodus på et gitt tidspunkt. Disse feilmodusene omfatter følgende:
- Områdebrudd: Et helt Power Platform- eller Azure-område er ikke tilgjengelig
- Tjenestebrudd: En eller flere Power Platform- eller Azure-tjenester er ikke tilgjengelige
- Distribuert tjenestenekt (DDoS) eller andre skadelige angrep
- Feilkonfigurasjon av app eller komponent
- Operatorfeil
- Avbrudd for planlagt vedlikehold
- Komponentoverbelastning
Vurder sannsynligheten for hver type feilmodus. Noen er svært usannsynlige, for eksempel avbrudd i flere soner eller flere områder, og det å legge til reduksjonsplanlegging utover overflødighet er ikke god bruk av ressurser og tid.
Reduksjon
Løsningsstrategier kan brukes i to brede kategorier: å bygge mer robusthet og utforme for redusert ytelse.
Bygging av mer elastisitet betyr å sikre at programutformingen følger de beste fremgangsmåtene for å få hjelp. Du kan for eksempel dele opp programmer i isolerte apper og mikrotjenester og bruke konfigurasjoner for plattformbasert elastisitet, for eksempel nye policyer for nye forsøk. Hvis du vil ha mer informasjon, kan du se Anbefalinger for overflødighet og Anbefalinger for selvbevaring.
Hvis du vil utforme for redusert ytelse, identifiserer du potensielle feilpunkter som kan deaktivere en eller flere komponenter i flyten, men ikke deaktivere flyten fullstendig. For å opprettholde funksjonaliteten til ende-til-ende-flyten kan det hende du må omrute et eller flere trinn til andre komponenter eller godta at en mislykket komponent kjører en funksjon, så funksjonen er ikke lenger tilgjengelig i brukeropplevelsen. Hvis du vil gå tilbake til eksemplet på natthandelsprogrammet, kan en mislykket komponent som en mikrotjeneste føre til at anbefalingsmotoren ikke er tilgjengelig, men kundene kan likevel søke etter produkter og fullføre transaksjonen.
Du må også planlegge reduksjon i avhengigheter. Sterke avhengigheter spiller en kritisk rolle i programfunksjon og tilgjengelighet. Hvis de er fraværende eller opplever feilfunksjon, kan det ha betydelig effekt. Fraværet av svake avhengigheter påvirker kanskje bare bestemte funksjoner og påvirker ikke den generelle tilgjengeligheten. Dette skillet gjenspeiler kostnadene for å opprettholde den høye tilgjengelighetsrelasjonen mellom tjenesten og avhengighetene. Klassifiser avhengigheter som enten sterke eller svake, slik at du kan identifisere hvilke komponenter som er nødvendige for programmet.
Hvis programmet har sterke avhengigheter som det ikke kan operere uten, må tilgjengelighets- og gjenopprettingsmålene for disse avhengighetene justeres med målene for selve programmet. Hvis programlivssyklusen er nært forbundet med livssyklusen til avhengighetene, kan det hende at driften av programmet er begrenset, spesielt for nye utgivelser.
Registrering
Feilregistrering er viktig for å sikre at du har identifisert feilpunkter i analysen riktig og har planlagt løsningsstrategiene på riktig måte. Registrering i denne konteksten betyr overvåkning av infrastrukturen, dataene og programmet, og varsler når det oppstår problemer. Automatiser registreringen så mye som mulig, og bygg opp overflødighet i driftsprosessene for å sikre at varsler alltid blir varslet og respondert raskt nok til å oppfylle forretningskravene. Hvis du vil ha mer informasjon, kan du se Anbefalinger for overvåking.
Resultat
For resultatet av analysen oppretter du et sett med dokumenter som effektivt kommuniserer resultatene, avgjørelsene du har tatt i forhold til flytkomponentene og reduksjonen, og virkningen av feilen på arbeidsbelastningen.
I analysen prioriterer du feilmodusene og løsningsstrategiene du har identifisert, basert på alvorsgrad og sannsynlighet. Bruk denne prioriteringen til å fokusere dokumentasjonen på feilmodusene som er vanlige og alvorlige nok til at du kan bruke tid, innsats og ressurser på å utforme løsningsstrategier rundt. Det kan for eksempel være noen feilmoduser som er svært sjeldne ved forekomst eller registrering. Utforming av løsningsstrategier rundt dem er ikke verdt kostnadene.
Se eksempeltabellen for et dokumentasjonsstartpunkt.
Under den første FMA-øvelsen vil dokumentene du produserer, for det meste være teoretisk planlegging. FMA-dokumentene bør gjennomgås og oppdateres regelmessig for å sikre at de holder seg oppdatert om arbeidsbelastningen din. Kaostesting og virkelige erfaringer hjelper deg med å finjustere analysene over tid.
Eksempel
Tabellen nedenfor viser et FMA-eksempel for et utgiftsprogram som driftes som en Power Apps-lerretsapp med en Microsoft Dataverse-serverdel og API-er driftet i APIM for å samhandle med et tredjepartssystem.
Brukerflyt: Brukerpålogging, innsending av utgiftskrav og samhandling med utgiftsrapport
| Komponent | Risiko | Sannsynlighet | Effekt/løsning/merknad | Strømbrudd |
|---|---|---|---|---|
| Microsoft Entra-ID | Tjenesteavbrudd | Lav | Full arbeidsbelastningsavbrudd. Avhengig av Microsoft for å reparere. | Fullstendig |
| Microsoft Entra-ID | Feilkonfigurasjon | Middels | Brukere kan ikke logge seg på. Ingen nedstrømseffekt. Kundestøtte rapporterer konfigurasjonsproblem til identitetsteamet. | None |
| Power Apps | Tjenesteavbrudd | Lav | Fullt avbrudd for eksterne brukere. Avhengig av Microsoft for å reparere. | Fullstendig |
| Power Apps | Regionalt avbrudd | Svært lavt | Fullt avbrudd for eksterne brukere. Avhengig av Microsoft for å reparere. | Fullstendig |
| Power Apps | DDoS-angrep | Middels | Mulig avbrudd. Microsoft administrerer DDoS-beskyttelse (L3 og L4). | Mulig delvis avbrudd |
| Dataverse | Tjenesteavbrudd | Lav | Full arbeidsbelastningsavbrudd. Avhengig av Microsoft for å reparere. | Fullstendig |
| Dataverse | Regionalt avbrudd | Svært lavt | Automatisk failover-gruppe mislykkes til sekundært område. Mulig avbrudd under failover. Mål for gjenopprettingstid og gjenopprettingspunktmål som skal fastsettes under pålitelighetstesting. | Potensielt fullt |
| Dataverse | Ondsinnet angrep (injeksjon) | Middels | Minimal risiko. | Mulig lav risiko |
| API Management | Tjenesteavbrudd | Lav | Fullt avbrudd for eksterne brukere. Avhengig av Microsoft for å reparere. | Fullstendig |
| API Management | Regionalt avbrudd | Svært lavt | Fullt avbrudd for eksterne brukere. Avhengig av Microsoft for å reparere. | Fullstendig |
| API Management | DDoS-angrep | Middels | Mulig avbrudd. Microsoft administrerer DDoS-beskyttelse (L3 og L4). | Mulig delvis avbrudd |
| Power Platform-løsningen | Feilkonfigurasjon | Middels | Feilkonfigurasjoner bør registreres under utrulling. Hvis disse skjer under en konfigurasjonsoppdatering, må administratorer rulle tilbake endringer. Konfigurasjonsoppdatering fører til en kort ekstern avbrudd. | Mulig fullt avbrudd |
Tilrettelegging for Power Platform
Power Platform integreres med Application Insights, som er en del av Azure Monitor-økosystemet. Du kan bruke denne integreringen til følgende:
Abonner for å motta telemetri registrert av Dataverse-plattformen i Application Insights om diagnose, ytelse og 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 i Application Insights til å bruke disse analysene for å diagnostisere problemer, forstå hva brukere faktisk gjør med appene, ta bedre forretningsavgjørelser og forbedre kvaliteten på appene dine.
Konfigurer Power Automate-telemetri til flyt i Application Insights. Du kan bruke denne telemetrien til å overvåke kjøringer av skyflyter og opprette varsler for feil i 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.
Power Platform-ressurser logger aktiviteter i samsvarsportalen Microsoft Purview. De fleste hendelser er tilgjengelige innen 24 timer etter aktiviteten. Ikke bruk denne informasjonen til overvåking i sanntid. Hvis du vil ha mer informasjon om logging av aktiviteter i Power Platform, kan du se følgende:
- Power Apps
- Power Automate
- Copilot Studio
- Power Pages
- Power Platform-koblinger
- Hindring av datatap
- Administrative Power Platform-logger
- Dataverse-sporing
Sjekkliste for pålitelighet
Se hele settet med anbefalinger.