Observabilitet og overvåking – mønstre
Lær mer om Operational Excellence → Observability and Monitoring
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Plattform | Hendelsesovervåking | ✅ Hendelsesovervåking er utformet i den første arkitekturen som fanger opp korrelasjons-ID-er som sporer forespørsler gjennom asynkrone behandlingskjeder og eksterne integrasjoner |
| Plattform | Hendelsesovervåking | ✅ Observabilitetsinfrastruktur inkluderes fra startsprint i stedet for etterhåndsutforming etter at produksjonshendelser har vist seg å være umulig å diagnostisere |
| Plattform | Integrasjon | ✅ Integreringssjekkpunkter plasseres med vilje for å aktivere forespørselssporing på tvers av systemgrenser |
| Plattform | Plattformhendelser | ✅ Plattformhendelsesbelastninger er strukturert for operativ synlighet med transaksjonsmarkører og kontekst |
| Plattform | Tilpasset logging | ✅ Tilpasset loggingsrammeverk fanger opp diskrete hendelser med full kontekstinformasjon, inkludert brukeridentitet, tidsstempel, varighet og utfall |
| Plattform | Målinger | ✅ Målinger samler numeriske målinger over tid som viser trender, inkludert API-forbruksrater, Apex CPU-tidsfordelinger og suksessfrekvenser for batchjobber |
| Plattform | Distribuert sporing | ✅ Sporer kobler synkrone API-kall til asynkrone behandlingskjeder, plattformhendelser til abonnentutførelser og integrasjonsforespørsler til eksterne systemsvar |
| Plattform | Observabilitet | ✅ Observabilitet gir operatorer mulighet til å svare på vilkårlige spørsmål om systemvirkemåte uten å distribuere ny instrumentering for hver undersøkelse |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Plattform | Hendelsesovervåking | ⚡️ Løsningen startes uten tilpasset logging og krever omfattende omstrukturering seks måneder senere når produksjonshendelser viser seg å være umulig å diagnostisere med plattformlogger alene |
| Plattform | Hendelsesovervåking | ⚡️ Observabilitet er ettermontert i eksisterende løsning som krever endringer i instrumenteringen som berører de fleste komponenter og risikerer feil under operasjonelt forbedringsarbeid |
| Plattform | Integrasjon | ⚡️ Det oppstår integrasjonsfeil, men forespørselsbaner kan ikke spores på tvers av systemgrenser uten omfattende telemetri |
| Plattform | Plattformhendelser | ⚡️ Plattformhendelsesbelastninger mangler operasjonell kontekst, noe som gjør hendelsesundersøkelse avhengig av å søke i flere systemer |
| Plattform | Tilpasset logging | ⚡️ Logger fanger opp ikke tilstrekkelig kontekst. Undersøkelser krever reprodusering av problemer for å innhente mer informasjon |
| Plattform | Observabilitet | ⚡️ Forhåndsdefinerte kontrollpaneler kan ikke svare på uventede spørsmål om systemvirkemåte som oppstår i produksjonsorganisasjonen |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Plattform | Hendelsesovervåking | ✅ Hendelsesovervåking er aktivert for produksjonsmiljøer som fanger opp API-bruk, påloggingsaktivitet, Apex, SOQL-spørringer, Visualforce, Lightning og rapportkjøringer |
| Plattform | Hendelsesovervåking | ✅ Hendelsesloggfiler eksporteres hver time til sentralisert loggplattform som aktiverer historikkanalyse utover oppbevaring av innebygd plattform |
| Plattform | Hendelsesovervåking | ✅ Ekstern loggaggregering aktiverer korrelasjon med enterprise telemetry fra andre systemer for ende-til-ende-transaksjonssporing |
| Plattform | Hendelsesovervåking | ✅ Hendelsesloggfiler beholdes i samsvar med lovpålagte krav for rapportering av samsvar og langsiktig trendanalyse |
| Plattform | Proactive Monitoring | ✅ terskler for Proactive Monitoring avstemmes med vilje basert på organisasjonsspesifikt normal driftsområde i stedet for å godta standardinnstillinger |
| Plattform | Proactive Monitoring | ✅ Proactive Monitoring oppdager API-grensenivåer, samtidige Apex, SOQL-radgrense-tilnærminger og radlåsekonflikter før brukersynlige hendelser |
| Plattform | Proactive Monitoring | ✅ Avstemme terskler genererer handlingsmessige signaler som team Trust og handler på å skape gode sykluser med kontinuerlig forbedring |
| Plattform | Skaleringssenter | ✅ Standardverdier for skaleringssenter fastsettes under løsningsstabilisering og revideres etter hver hovedutgivelse |
| Plattform | Skaleringssenter | ✅ Skaleringssenter viser hvilke operasjoner som bruker mest ressurser, hvilke transaksjoner som nærmer seg tidsavbrudds terskler, og hvor optimaliseringsinvesteringer gir størst innvirkning |
| Plattform | Skaleringssenter | ✅ Transaksjonstid øker fra grunnleggende ledetekstundersøkelse som avslører utilsiktede N+1-spørringsmønstre som er introdusert i nyeste distribusjon |
| Plattform | Revisjonsspor for oppsett | ✅ Revisjonsspor for oppsett sporer konfigurasjonsendringer, inkludert tillatelsesendringer, metadatadistribusjoner og oppdateringer av sikkerhetsinnstillinger med oppbevaring opptil 180 dager |
| Plattform | Revisjonsspor for oppsett | ✅ Revisjonsspor for oppsett eksporteres for oppbevaring ut over 180 dager når overholdelse eller kontraktsmessige krav krever lengre historiske vinduer |
| Plattform | Shield | ✅ Feltrevisjonsspor er aktivert selektivt for felt som inneholder sensitive data, regulerte data som krever endringshistorikk, eller viktige forretningsdata |
| Plattform | Shield | ✅ Feltrevisjonsspor gir oppbevaring i opptil 10 år for felt der forståelse av historiske verdier hjelper operasjoner og rapportering av samsvar |
| Plattform | Tilstandssjekk | ✅ Tilstandssjekk-gjennomganger planlegges kvartalsvis med funn rettet opp basert på risikoprioritering for miljøet |
| Plattform | Tilstandssjekk | ✅ Funnene i tilstandssjekken mottar hensiktsmessig gjennomgang i stedet for passiv godkjenning. Kompensasjonskontroller eller forskjellige risikotoleranser er dokumentert |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Plattform | Hendelsesovervåking | ⚡️ Hendelsesovervåking er aktivert, men logger eksporteres aldri, noe som begrenser undersøkelser til det innebygde oppbevaringsvinduet og hindrer analyse av historiske trender |
| Plattform | Hendelsesovervåking | ⚡️ Hendelsesloggfiler forblir i plattformlagring, ekstern aggregering implementeres ikke, noe som hindrer langsiktig kapasitetsplanlegging |
| Plattform | Proactive Monitoring | Proactive Monitoring bruker standard terskler som er for sensitive eller for laxe, og genererer bråkete varsler som team lærer å ignorere |
| Plattform | Proactive Monitoring | ⚡️ Varselstøy ødelegger Trust i overvåkingssystemet, team slutter å svare på gyldige signaler |
| Plattform | Skaleringssenter | ⚡️ Skaleringssenter er aktivert, men gjennomgås aldri proaktivt. Ytelsen reduseres sakte til brukerne klager etter måneder med inkrementell nedgang |
| Plattform | Skaleringssenter | ⚡️ Ytelsesmålinger mangler grunnleggende kontekst. Det er uklart om transaksjonstider på 3 sekunder er typiske, forbedrende eller nedverdigende |
| Plattform | Revisjonsspor for oppsett | ⚡️ Revisjonsspor for oppsett eksporteres ikke. Oppbevaringsbegrensninger hindrer sikkerhetsundersøkelser eller validering av samsvar ut over 180 dager |
| Plattform | Shield | ⚡️ Feltrevisjonsspor er aktivert for alle felt i stedet for selektivt, slik at lagringskostnader opprettes uten tilsvarende samsvarsverdi |
| Plattform | Tilstandssjekk | ⚡️ Tilstandssjekk-funn blir aldri gjennomgått. Sikkerhetskonfigurasjon avviker fra standardanbefalinger uten bevisst godkjenning |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Plattform | Brukerflyter | ✅ Kritiske brukerflyter defineres basert på forretningseffekt og overvåket ende-til-slutt for suksessfrekvenser, fullføringstid, avbruddspunkter og feilfrekvenser |
| Plattform | Brukerflyter | ✅ Viktige flyter inkluderer omsetningsgenererende aktiviteter (sending av bestillinger, utføring av kontrakter, avslutning av salgsmuligheter), aktiviteter med stor trafikk (pålogging, søk, postopprettelse) og aktiviteter som kreves for overholdelse (samtykkefangst, innfrielse av registrertes rettigheter) |
| Plattform | Brukerflyter | ✅ Flyter instrumenteres med transaksjonsmarkører som angir start, fullføring, avbrudd og feil i hvert viktig trinn |
| Plattform | Brukerflyter | ✅ Bestillingsinnsendingsflyt instrumentert med plattformhendelser i hver fase (kurvvalidering, lagerbeholdningssjekk, betalingsbehandling, innfrielsesutløser) som viser suksessrate etter fase |
| Plattform | Brukerflyter | ✅ Overvåking på flytnivå avdekker problemer som ikke er synlige i overvåking på komponentnivå, fordi feil kan skje på hvilket som helst overgangspunkt |
| Plattform | Brukerflyter | ✅ Varsler utløses når flytsuksessfrekvenser faller under akseptable terskler eller varighet overskrider latensmål |
| Plattform | Integrasjon | ✅ Integreringstilstandsovervåking oppdager eksterne systemfeil, nettverksproblemer, godkjenningsproblemer og tilganger for grensefrekvenser før de går gjennom brukervennlige feil |
| Plattform | Integrasjon | ✅ Varsler om overvåking av suksessfrekvens når de faller under 99 % for viktige synkrone integrasjoner |
| Plattform | Integrasjon | ✅ Feilfordelingsovervåking varsler når nye feiltyper vises som ikke fantes i standarden |
| Plattform | Integrasjon | ✅ Varsler om latensprosentilovervåking (p95) når de overskrider 3 sekunder for synkrone brukervennlige samtaler |
| Plattform | Integrasjon | ✅ Varsler om gjennomløpsovervåking når 80 % av den kjente grensen eller SLA- terskelen er over |
| Plattform | Integrasjon | ✅ Varsler om tilstandsovervåking av kryssbryter når en krets åpnes, som indikerer nedgang i det eksterne systemet |
| Plattform | Integrasjon | ✅ Varsler om overvåking av antall forsøk på nytt når pågående antall forsøk på nytt overskrider 5 %, som indikerer pålitelighetsproblemer |
| Plattform | Integrasjon | ✅ Integreringstelemetriruter til sentraliserte overvåkingsplattformer som muliggjør korrelasjon på tvers av systemgrenser |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Plattform | Brukerflyter | ⚡️ Komponenter overvåkes uavhengig og viser riktig drift, mens 12 % av brukerne avslutter viktige flyter uten å se hvorfor |
| Plattform | Brukerflyter | ⚡️ Kontrollpaneler for komponenttilstand viser grønt mens brukere ikke kan fullføre viktige arbeidsflyter som viser feil i overvåkingsarkitekturen |
| Plattform | Brukerflyter | ⚡️ Brukerreise som berører flere Apex, flyter, plattformhendelser og eksterne integrasjoner, mangler ende-til-slutt-synlighet |
| Plattform | Brukerflyter | ⚡️ Kritiske forretningsreiser mangler instrumentering, suksessfrekvenser og avbruddspunkter er ukjente |
| Plattform | Integrasjon | ⚡️ Integrasjonsfeil oppdages først etter å ha gått over til brukervennlige feil i stedet for proaktivt |
| Plattform | Integrasjon | ⚡️ Integrasjonstelemetri forblir isolert i individuelle systemer for å hindre korrelasjon og rotårsaksanalyse på tvers av grenser |
| Plattform | Integrasjon | ⚡️ Overvåke varsler om nedstrøms symptomer etter at skaden er gjort i stedet for å avdekke rotårsaker tidlig |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Plattform | SLI-er | ✅ Tilgjengelighets-SLI-er måler prosentandelen av tidskritiske flyter som utføres riktig fra brukerperspektiv (mottar forventet resultat, ikke bare statuskode 200) |
| Plattform | SLI-er | ✅ Latency SLI-er måler tiden til å fullføre operasjoner på p50 (median), p90 (90th percentile excluding outliers), p95 (95th percentile excluding worst outliers) og p99 (99th percentile showing worst case experience) |
| Plattform | SLI-er | ✅ Latensmål varierer etter operasjonskritikk og brukerforventning (500 ms søk føles umiddelbart, den samme latensen for å skrive inndata føles treg) |
| Plattform | SLI-er | ✅ SLI-er for gjennomløp måler volumet av vellykkede operasjoner per tidsenhet som viser kapasitetsutnyttelse og veksttrender |
| Plattform | SLI-er | ✅ Gjennomløp kombinert med latens viser om systemet opprettholder ytelsen under økende belastning eller reduseres etter hvert som volumet øker |
| Plattform | SLI-er | ✅ Feilfrekvens-SLI-er skiller mellom feiltyper (brukerfeil som valideringsfeil kontra systemfeil som styringsgrenseunntak) |
| Plattform | SLO-er | ✅ Tjenestenivåmål fastsettes ved å definere akseptable SLI- terskler basert på forretningskrav før du velger arkitekturmønstre |
| Plattform | SLO-er | ✅ Forretningskravet “Salgsrepresentanter må se salgsmulighetsoppdateringer innen 5 sekunder” fører til enkel avlogging “Salgsmulighetsdetaljside lastes inn innen 3 sekunder ved p95” som styrer arkitekturbeslutninger |
| Plattform | SLO-er | ✅ SLO-er kommer ut fra forretningskrav og driver arkitektoniske beslutninger i stedet for å bli definert basert på hva systemet for øyeblikket oppnår |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Plattform | SLI-er | ⚡️ Tilgjengelighet måles fra teknisk perspektiv (200 statuskode) i stedet for fra brukerperspektiv (motta forventet resultat) |
| Plattform | SLI-er | ⚡️ Latens måles bare ved middelverdi uten å forstå brukeropplevelse i verste tilfeller ved p95- eller p99-prosentiler |
| Plattform | SLI-er | ⚡️ Feilfrekvens-SLI-er skiller ikke mellom brukerfeil og systemfeil, og maskerer forskjellige problemer som krever forskjellige løsninger |
| Plattform | SLO-er | ⚡️ Arkitektur bygges først, og deretter defineres enkel avlogging som “det vi for øyeblikket oppnår” som fører til godkjenning av 12-sekunders sideinnlastinger fordi systemutformingen aldri vurderte brukerkrav |
| Plattform | SLO-er | ⚡️ SLO-er er arkitekturdrevet i stedet for forretningsdrevet, og angir mål basert på hva systemet oppnår i stedet for hva brukerne trenger |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Plattform | Varsel | ✅ Alvorlighetsklassifisering ruter viktige hendelser (produksjon ikke tilgjengelig, risiko for datakrutt, sikkerhetskompromiss) til side-på-kall-ingeniører umiddelbart |
| Plattform | Varsel | ✅ Hendelser med høy alvorlighetsgrad (forringet ytelse, delvise avbrudd) genererer varsler for umiddelbar undersøkelse innenfor åpningstidene |
| Plattform | Varsel | ✅ Advarsler (nærmer seg terskler, konfigurasjonsavvik) genererer daglige sammendragsvarsler for proaktiv rettelse |
| Plattform | Varsel | ✅ Varselkontekst inkluderer antall berørte brukere, feilmeldinger, stablesporinger, nylige distribusjoner, relaterte varsler og lenker til relevante kontrollpaneler |
| Plattform | Varsel | ✅ Rik kontekst reduserer gjennomsnittstiden for bekreftelse ved å aktivere umiddelbar vurdering av alvorlighetsgrad og undersøkelse uten å innhente grunnleggende informasjon |
| Plattform | Varsel | ✅ Varselgruppering hindrer varselstorm der hundrevis av relaterte varsler utløses for ett underliggende problem |
| Plattform | Varsel | ✅ Integrasjonsfeil utløser ett varsel gruppert etter integrasjonssluttpunkt som viser 156 mislykkede forespørsler de siste 5 minuttene med latensdiagram, feilfordeling og kontrollpanellenke |
| Plattform | Varsel | ✅ Varselundertrykkelse hindrer kjente forbigående tilstander i å generere varsler i forventede vedlikeholdsvinduer eller perioder med automatisk rettelse |
| Plattform | Varsel | ✅ Varsler undertrykkes under planlagt vedlikehold, i løpet av de første minuttene etter distribusjon mens bufferen er varm, og under korte midlertidige feil der logikken for å prøve på nytt lykkes |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Plattform | Varsel | ⚡️ Alle varsler ruter til samme kanal uten alvorlighetsklassifisering. Kritiske hendelser skilles ikke fra rutinemessige advarsler |
| Plattform | Varsel | ⚡️ Varsler mangler diagnostisk kontekst. ingeniører på oppkall må innhente grunnleggende informasjon via separate spørringer før alvorlighetsgraden vurderes |
| Plattform | Varsel | ⚡️ Integrasjonsfeil genererer 156 individuelle varsler på 5 minutter og overvelder ingeniørens telefon ved oppringing, hvert varsel er identisk unntatt tidsstempel |
| Plattform | Varsel | ⚡️ Varselstorm hindrer at respondenter skiller mellom ett underliggende problem og hundrevis av relaterte symptomer |
| Plattform | Varsel | ⚡️ Varsler brenner under kjente vedlikeholdsvinduer og forbigående forhold som genererer støy som eroderer Trust i overvåking |
| Plattform | Varsel | ⚡️ Varselutmattelse fra bråkete usanne positive fører til at team ignorerer varsler som reduserer svarets effektivitet |