Anbefalinger til analyse af fejltilstand
Gælder for denne anbefaling af kontrolliste til velstruktureret pålidelighed i Power Platform:
RE:03 | Brug FMA (Failure Mode Analysis - fejltilstandsanalyse) til at identificere og prioritere potentielle fejl i løsningskomponenterne. Udfør FMA for at få hjælp til at vurdere risikoen og effekten af de enkelte fejltilstande. Fastlæg, hvordan arbejdsbelastningen reagerer og gendannes. |
---|
I denne vejledning beskrives den bedste praksis for analyse af fejltilstand (FMA) for arbejdsbelastningen. FMA identificerer potentielle fejlpunkter i arbejdsbelastningen og de tilknyttede flows og planlægger afhjælpningshandlinger tilsvarende. På hvert trin i flowet kan du identificere skadens omfang af flere fejltyper, hvilket kan hjælpe dig med at designe en ny arbejdsbelastning eller omstrukturere en eksisterende arbejdsbelastning for at minimere spredningen af fejl.
Et vigtigt aspekt af FMA er, at fejl opstår, uanset hvor mange lag af robusthed du anvender. Mere komplekse miljøer bliver udsat for flere typer fejl. I betragtning af denne realitet kan du bruge FMA til at designe din arbejdsbelastning, så den kan modstå de fleste typer fejl og gendannes problemfrit, når der indtræffer en fejl.
Hvis du springer FMA over eller udfører en ufuldstændig analyse, er der risiko for uforudsigelig funktionsmåde og potentielle afbrydelser af din arbejdsbelastning, der skyldes ineffektivt design.
Definitioner
Begreb | Definition |
---|---|
Fejltilstand | En type problem, der kan medføre, at en eller flere arbejdsbelastningskomponenter forringes eller påvirkes kraftigt, så de ikke er tilgængelige. |
Afhjælpning | De aktiviteter, du har identificeret for at løse problemer, enten proaktivt eller reaktivt. |
Registrering | Processer og procedurer til overvågning og vigtige beskeder om data og app. |
Vigtigste designstrategier
I forbindelse med FMA er det vigtigt at forstå forudsætningerne. Begynd med at gennemgå og implementere anbefalinger til identifikation af flows og prioritere dem ud fra kritisk tilstand. Dine dataartefakter spiller en væsentlig rolle i beskrivelsen af datastierne i disse flows. Efterhånden som du kommer i gang med FMA-strategien, skal du fokusere på planlægning af komponenter til vigtige flows, identificere afhængigheder (både interne og eksterne) og udarbejde afhjælpningsstrategier.
Forudsætninger
Gennemgå og implementer anbefalingerne til identifikation og bedømmelse af flows. Det antages, at du har identificeret og prioriteret bruger- og systemforløb baseret på kritisk niveau.
De data, du har indsamlet, og de artefakter, du har oprettet i dit arbejde, giver dig en konkret beskrivelse af dine datastier, der er involveret i hele flowene. Hvis du vil opnå succes med dit FMA-arbejde, er det vigtigt, at du er præcis og grundig i dine artefakter.
FAA-fremgangsmåde
Når du har bestemt de vigtige flows, kan du planlægge de påkrævede komponenter. Derefter skal du følge de enkelte flowtrin for at identificere afhængigheder, herunder tredjepartstjenester og potentielle fejlpunkter, og planlægge dine afhjælpningsstrategier.
Opdel arbejdsbelastningen
Efterhånden som du går fra idé til design, skal du identificere de komponenttyper, der kræves for at understøtte arbejdsbelastningen. Arbejdsbelastningen bestemmer de nødvendige komponenter, du skal planlægge.
Når du har oprettet det første arkitekturdesign, kan du overlægge dine flows for at identificere de separate komponenter, der bruges i disse flows, og oprette lister eller arbejdsprocesdiagrammer, der beskriver flowene og deres komponenter. Du kan se, hvor vigtige komponenterne er, ved at bruge definitionerne af kritisk niveau, du har tildelt til flowene. Overvej, hvordan en komponent, der virker forkert, påvirker flowet.
Identificer afhængigheder
Identificer afhængighederne i arbejdsbelastninger for at udføre en enkelt fejlanalyse. Hvis du opdeler arbejdsbelastningen og overlægger flows, får du indsigt i afhængigheder, der er interne og eksterne i forhold til arbejdsbelastningen.
Interne afhængigheder er komponenter i omfanget af arbejdsbelastning, der kræves, for at arbejdsbelastningen kan fungere. Typiske interne afhængigheder omfatter API'er eller løsninger med hemmelighed/nøgleadministration, f.eks. Azure Key Vault. I forbindelse med disse afhængigheder skal du registrere pålidelighedsdataene, f.eks. tilgængelige serviceaftaler (SLA'er) og skaleringsgrænser. Eksterne afhængigheder er påkrævede komponenter, der ikke er omfattet af arbejdsbelastningen, f.eks. et andet program eller en tredjepartstjeneste. Typiske eksterne afhængigheder omfatter godkendelsesløsninger som f.eks. Microsoft Entra ID og Power Platform-infrastruktur.
Identificer og dokumentér afhængighederne i arbejdsbelastningen, og inkluder dem i flowdokumentationens artefakter.
Fejlpunkter
I vigtige flows for arbejdsbelastningen skal du overveje de enkelte komponenter og bestemme, hvordan den pågældende komponent og dens afhængigheder kan blive påvirket af en fejltilstand. Husk, at der er mange fejltilstande, du skal overveje, når du skal planlægge robusthed og gendannelse. En enkelt komponent kan blive berørt af mere end én fejltilstand på et givet tidspunkt. Disse fejltilstande omfatter:
- Regional afbrydelse: Et helt Power Platform- eller Azure-område er ikke tilgængeligt
- Serviceafbrydelse: En eller flere Power Platform- eller Azure-tjenester er ikke tilgængelige
- DDoS (Distributed Denial-of-Service) eller et andet ondsindet angreb
- Fejlkonfiguration af app eller komponent
- Operatørfejl
- Planlagt vedligeholdelsesafbrydelse
- Overbelastning af komponent
Overvej sandsynligheden for hver type fejltilstand. Nogle er meget usandsynlige, f.eks. afbrydelser i flere zoner eller flere områder, og det er ikke en god ide at bruge ressourcer og tid på at tilføje planlægning af afhjælpninger ud over redundans.
Afhjælpning
Afhjælpningsstrategierne er opdelt i to brede kategorier: opbygning af mere robusthed og design til forringet ydeevne.
Hvis du opbygger mere robusthed, skal du sikre, at dit programdesign følger bedste praksis med hensyn til varighed. Du kan f.eks. opdele programmer i isolerede apps og mikrotjenester og bruge konfigurationer af robusthed, der leveres på platformniveau, f.eks. politikker for nye forsøg. Du kan finde flere oplysninger i Anbefalinger til redundans og Anbefalinger til selvbevaring.
Hvis du vil designe for forringet ydeevne, skal du identificere potentielle fejlpunkter, der kan deaktivere en eller flere komponenter i flowet, men som ikke deaktiverer det pågældende flow fuldstændigt. Hvis du vil bevare funktionaliteten af hele flowet, skal du måske omdirigere et eller flere trin til andre komponenter eller acceptere, at en mislykket komponent kører en funktion, så funktionen ikke længere er tilgængelig i brugeroplevelsen. Hvis du vil vende tilbage til eksemplet med e-handelsprogrammet, kan en mislykket komponent som en mikroservice bevirke, at anbefalingsprogrammet ikke er tilgængeligt, men kunderne kan stadig søge efter produkter og fuldføre deres transaktion.
Du skal også planlægge afhjælpning omkring afhængigheder. Stærke afhængigheder spiller en vigtig rolle i forbindelse med programfunktion og -tilgængelighed. Hvis de mangler eller medfører en fejlfunktion, kan det have en betydelig effekt. Hvis der mangler svage afhængigheder, kan det kun påvirke bestemte funktioner og ikke den samlede tilgængelighed. Denne skelnen afspejler omkostningerne til at bevare den høje tilgængelighedsrelation mellem servicen og dens afhængigheder. Klassificering af afhængigheder som enten stærke eller svage gør det lettere at identificere, hvilke komponenter der er vigtige for programmet.
Hvis programmet har stærke afhængigheder, det ikke kan fungere uden, skal tilgængeligheden og genoprettelsesmålene for disse afhængigheder være i overensstemmelse med målene for selve programmet. Hvis programmets livscyklus er tæt knyttet til afhængighedernes livscyklus, kan programmets driftsmæssige fleksibilitet være begrænset, især i forbindelse med nye versioner.
Registrering
Registrering af fejl er vigtig for at sikre, at du har identificeret fejlpunkter korrekt i analysen og planlagt afhjælpningsstrategierne korrekt. Registrering i denne forbindelse betyder overvågning af infrastrukturen, dataene og programmet samt udsende advarsler, når der opstår problemer. Du kan automatisere registrering så meget som muligt og opbygge redundans i dine driftsprocesser for at sikre, at vigtige beskeder altid bliver opdaget og hurtigt reageret på for at opfylde dine forretningskrav. Du kan finde flere oplysninger i Anbefalinger til overvågning.
Resultat
Du kan få resultatet af analysen ved at oprette et sæt dokumenter, der effektivt kommunikerer resultaterne, de beslutninger, du har truffet i forhold til flowkomponenterne og afhjælpningen, og effekten af fejlene på arbejdsbelastningen.
I din analyse skal du prioritere de fejltilstande og afhjælpningsstrategier, du har identificeret, på baggrund af sårbarhed og sandsynlighed. Brug denne prioritering til at fokusere dokumentationen på de fejltilstande, der er almindelige og alvorlige nok til at berettige tid, kræfter og ressourcer på at designe afhjælpningsstrategier. Der kan f.eks. være fejltilstande, der er meget sjældne i forekomst eller registrering. Design af afhjælpningsstrategier omkring dem er ikke omkostningen værd.
Se eksempeltabellen for at få et udgangspunkt i dokumentationen.
I løbet af din første FMA-opgave vil de dokumenter, du udarbejder, overvejende være teoretisk planlægning. FMA-dokumenterne skal gennemgås og opdateres jævnligt for at sikre, at de er opdaterede for din arbejdsbelastning. Kaostest og erfaringer fra den virkelige verden hjælper dig med at finjustere dine analyser over tid.
Eksempel
I følgende tabel vises et FMA-eksempel på et udgiftsprogram, der hostes som en Power Apps-lærredsapp med en Microsoft Dataverse-backend og API'er, som APIM er vært for, for at kommunikere med et tredjepartssystem.
Brugerflow: Brugerlogon, afsendelse af udgiftskrav og interaktion med udgiftsrapport
Komponent | Risiko | Sandsynlighed | Effekt/afhjælpning/note | Afbrydelse |
---|---|---|---|---|
Microsoft Entra ID | Serviceafbrydelse | Lav | Fuld afbrydelse af arbejdsbelastning. Afhængig af Microsoft-afhjælpning. | Komplet |
Microsoft Entra ID | Fejlkonfiguration | Mellem | Brugere kan ikke logge på. Ingen downstream-effekt. Helpdesk rapporterer konfigurationsproblem til identitetsteam. | Ingen |
Power Apps | Serviceafbrydelse | Lav | Fuld afbrydelse for eksterne brugere. Afhængig af Microsoft-afhjælpning. | Komplet |
Power Apps | Regional afbrydelse | Meget lav | Fuld afbrydelse for eksterne brugere. Afhængig af Microsoft-afhjælpning. | Komplet |
Power Apps | DDoS-angreb | Mellem | Risiko for forstyrrelse. Microsoft administrerer DDoS-beskyttelse (N3 og N4). | Mulighed for delvis afbrydelse |
Dataverse | Serviceafbrydelse | Lav | Fuld afbrydelse af arbejdsbelastning. Afhængig af Microsoft-afhjælpning. | Komplet |
Dataverse | Regional afbrydelse | Meget lav | Gruppen med automatisk failover overgår til sekundært område. Mulig afbrydelse under failover. Mål for gendannelsestid (RTO'er) og mål for gendannelsespunkt (RPO'er), der skal bestemmes under test af stabilitet. | Potentiel fuld |
Dataverse | Ondsindet angreb (injektion) | Mellem | Minimal risiko. | Potentiel lav risiko |
API Management | Serviceafbrydelse | Lav | Fuld afbrydelse for eksterne brugere. Afhængig af Microsoft-afhjælpning. | Komplet |
API Management | Regional afbrydelse | Meget lav | Fuld afbrydelse for eksterne brugere. Afhængig af Microsoft-afhjælpning. | Komplet |
API Management | DDoS-angreb | Mellem | Risiko for forstyrrelse. Microsoft administrerer DDoS-beskyttelse (N3 og N4). | Mulighed for delvis afbrydelse |
Din Power Platform-løsning | Fejlkonfiguration | Mellem | Fejlkonfigurationer skal opdages under udrulning. Hvis disse sker under en konfigurationsopdatering, skal administratorer tilbagerulle ændringerne. Konfigurationsopdatering medfører en kort ekstern afbrydelse. | Mulighed for fuld afbrydelse |
Power Platform-processtyring
Power Platform integreres med Application Insights, som er en del af Azure Monitor-økosystemet. Du kan bruge denne integration til at:
Abonner på telemetri, der er registreret af Dataverse-platformen i Application Insights, for diagnoser, ydeevne og drift, som programmer udfører på din Dataverse-database og i modelbaserede apps. Denne telemetri kan bruges til at diagnosticere og foretage fejlfinding af problemer, der vedrører fejl og ydeevne.
Opret forbindelse mellem dine lærredapps og Application Insights for at bruge disse analyser til at diagnosticere problemer, forstå, hvad brugerne rent faktisk gør med dine apps, skabe bedre forretningsbeslutninger og forbedre kvaliteten af dine apps.
Konfigurer Power Automate-telemetri til at flyde ind i Application Insights. Du kan bruge denne telemetri til at overvåge udførelse af cloudflow og oprette advarsler om under kørsel af cloudflow.
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.
Power Platform-ressourcer logfører aktiviteter i Microsoft Purview-overholdelsesportalen. De fleste hændelser er tilgængelige inden for 24 timer efter aktiviteten. Brug ikke disse oplysninger til overvågning i realtid. Du kan finde flere oplysninger om logføring af aktiviteter i Power Platform i:
- Power Apps
- Power Automate
- Copilot Studio
- Power Pages
- Power Platform-connectorer
- Forebyggelse af datatab
- Power Platform-administrative logge
- Dataverse-overvågning
Kontrolliste for bæredygtighed
Se det fuldstændige sæt anbefalinger.