Observerbarhet och övervakning - Mönster
Få reda på mer om välarkitekturerad operativ excellens → Observerbarhet och övervakning
Mönster
| Var man ska leta | Hur bra ser ut |
|---|---|
| Plattform | Händelseövervakning | ✅ Händelseövervakning är utformad till inledande arkitektur som samlar in korrelations-ID:n som spårar begäranden genom asynkrona bearbetningskedjor och externa integreringar |
| Plattform | Händelseövervakning | ✅ Observerbarhet infrastruktur inkluderas från inledande sprint snarare än eftermontering efter produktionsincidenter visar sig vara omöjligt att diagnostisera |
| Plattform | Integrering | ✅ Integreringskontrollpunkter placeras avsiktligt för att möjliggöra begäran spårning över systemgränser |
| Plattform | Plattformshändelser | ✅ Platform Event payloads är strukturerade för operativ synlighet med transaktionsmarkörer och sammanhang |
| Plattform | Egen loggning | ✅ Eget loggningsramverk samlar in diskreta händelser med fullständig sammanhangsinformation inklusive användaridentitet, tidsstämpel, varaktighet och resultat |
| Plattform | Mått | ✅ Mått aggregerar numeriska mätningar över tid och avslöjar trender, inklusive API-användningsresultat, Apex CPU-tidsfördelningar och satsjobbresultat |
| Plattform | Distribuerad spårning | ✅ Spår ansluter synkrona API-anrop till asynkrona bearbetningskedjor, plattformshändelser till prenumerantkörningar och integreringsbegäranden till externa systemsvar |
| Plattform | Observabilitet | ✅ Observability låter operatörer svara på godtyckliga frågor om systembeteende utan att distribuera nya instrument för varje undersökning |
Antimönster
| Var man ska leta | Hur dåligt ser ut |
|---|---|
| Plattform | Händelseövervakning | ⚠️ Lösningen lanseras utan egen loggning, vilket kräver omfattande refaktorisering sex månader senare när produktionsincidenter visar sig vara omöjliga att diagnostisera enbart med plattformsloggar |
| Plattform | Händelseövervakning | ⚠️ Observerbarhet eftermonteras i befintlig lösning som kräver instrumentändringar som berör de flesta komponenter och riskerar buggar under operativt förbättringsarbete |
| Plattform | Integrering | ️ Integreringsfel inträffar men begärandevägar kan inte spåras över systemgränser utan omfattande telemetri |
| Plattform | Plattformshändelser | ⚠️ Plattformshändelsebelastningar saknar operativt sammanhang vilket gör incidentutredning beroende av att söka i flera system |
| Plattform | Egen loggning | ️ Loggar samlar in otillräckligt sammanhang; undersökningar kräver att problem reproduceras för att samla in ytterligare information |
| Plattform | Observabilitet | ⚠️ Fördefinierade instrumentpaneler kan inte svara på oväntade frågor om systembeteende som uppstår i produktion |
Mönster
| Var man ska leta | Hur bra ser ut |
|---|---|
| Plattform | Händelseövervakning | ✅ Händelseövervakning är aktiverat för produktionsmiljöer som samlar in API-användning, inloggningsaktivitet, Apex, SOQL-frågor, Visualforce, Lightning och rapportkörningar |
| Plattform | Händelseövervakning | ✅ Händelseloggfiler exporteras varje timme till centraliserad loggplattform vilket möjliggör historisk analys utöver inbyggd plattformslagring |
| Plattform | Händelseövervakning | ✅ Extern loggaggregering möjliggör korrelation med företagets telemetri från andra system för spårning av transaktioner från början till slut |
| Plattform | Händelseövervakning | ✅ Händelseloggfiler behålls matchande lagstadgade krav för efterlevnadsrapportering och långsiktig trendanalys |
| Plattform | Proactive Monitoring | ✅ Proactive Monitoring trösklar justeras medvetet baserat på organisationsspecifika normala driftsintervall istället för att acceptera standarder |
| Plattform | Proactive Monitoring | ✅ Proactive Monitoring varningar upptäcker API gränstoppar, samtidiga Apex fel, SOQL radgräns metoder och radlås tvist innan användarsynliga incidenter |
| Plattform | Proactive Monitoring | ✅ Justerade trösklar skapar användbara signaler som team Trust och agera på att skapa goda cykler av kontinuerlig förbättring |
| Plattform | Skalcenter | ✅ Scale Center-baslinjer etableras under lösningsstabilisering och besöks igen efter varje större utgåva |
| Plattform | Skalcenter | ✅ Scale Center avslöjar vilka operationer som konsumerar mest resurser, vilka transaktioner som närmar sig timeout-trösklar och var optimeringsinvesteringar ger störst påverkan |
| Plattform | Skalcenter | ✅ Transaktionstid ökar från grundläggande snabb undersökning avslöjar oavsiktliga N+1 sökfrågemönster som introducerats i senaste distribuering |
| Plattform | Granskningslogg för inställningar | ✅ Inställningar Granskningslogg följer konfigurationsändringar, inklusive behörighetsändringar, metadatadistribueringar och säkerhetsinställningsuppdateringar med lagring upp till 180 dagar |
| Plattform | Granskningslogg för inställningar | ✅ Inställningar Granskningsloggposter exporteras för lagring efter 180 dagar när efterlevnad eller avtalskrav kräver längre historiska fönster |
| Plattform | Shield | ✅ Fältgranskningslogg aktiveras selektivt för fält som innehåller känsliga data, reglerade data som kräver ändringshistorik eller viktiga verksamhetsdata |
| Plattform | Shield | ✅ Fältgranskningslogg ger upp till 10 års lagring för fält där förståelse av historiska värden underlättar verksamheten och efterlevnadsrapportering |
| Plattform | Hälsokontroll | ✅ Hälsokontrollgranskningar schemaläggs kvartalsvis med upptäckter åtgärdade baserat på riskprioritering för miljön |
| Plattform | Hälsokontroll | ✅ Hälsokontrollresultat får avsiktlig granskning snarare än passiv acceptans; kompenserande kontroller eller olika risktoleranser dokumenteras |
Antimönster
| Var man ska leta | Hur dåligt ser ut |
|---|---|
| Plattform | Händelseövervakning | ⚠️ Händelseövervakning har aktiverats men loggar exporteras aldrig, vilket begränsar undersökningar till det inbyggda lagringsfönstret och förhindrar historisk trendanalys |
| Plattform | Händelseövervakning | ⚠️ Händelseloggfiler förblir i plattformslagring; extern aggregering implementeras inte vilket förhindrar långsiktig kapacitetsplanering |
| Plattform | Proactive Monitoring | ️ Proactive Monitoring använder standardtrösklar som är för känsliga eller för slappa, vilket skapar brusiga varningar som team lär sig ignorera |
| Plattform | Proactive Monitoring | ⚠️ Varningsbrus förstör Trust i övervakningssystemet; team slutar svara på giltiga signaler |
| Plattform | Skalcenter | ⚠️ Skalningscenter är aktiverat men granskas aldrig proaktivt; prestanda försämras långsamt tills användare klagar efter månader av inkrementell försämring |
| Plattform | Skalcenter | ⚠️ Prestandamått saknar grundläggande sammanhang; oklart om 3 sekunders transaktionstider är typiska, förbättrar eller försämrar |
| Plattform | Granskningslogg för inställningar | ️ Granskningslogg för inställningar exporteras inte; lagringsbegränsningar förhindrar säkerhetsutredningar eller efterlevnadsvalidering efter 180 dagar |
| Plattform | Shield | ⚠️ Fältgranskningslogg är aktiverad för alla fält istället för selektivt, vilket skapar lagringskostnader utan motsvarande efterlevnadsvärde |
| Plattform | Hälsokontroll | ️ Hälsokontrollresultat granskas aldrig; säkerhetskonfigurationen avviker från grundläggande rekommendationer utan avsiktligt godkännande |
Mönster
| Var man ska leta | Hur bra ser ut |
|---|---|
| Plattform | Användarflöden | ✅ Kritiska användarflöden definieras baserat på verksamhetspåverkan och övervakas från början till slut för framgångsresultat, slutförandetid, övergivande punkter och felfrekvenser |
| Plattform | Användarflöden | ✅ Kritiska flöden inkluderar aktiviteter som genererar intäkter (orderinlämning, kontraktutförande, säljprojektavslut), aktiviteter med hög volym (inloggning, sökning, postskapande) och aktiviteter som krävs för efterlevnad (samtyckesinsamling, uppfyllande av registrerades rättigheter) |
| Plattform | Användarflöden | ✅ Flöden instrumenteras med transaktionsmarkörer som indikerar start, slutförande, övergivande och misslyckande vid varje viktigt steg |
| Plattform | Användarflöden | ✅ Orderinskickningsflöde instrumenterat med plattformshändelser i varje steg (varukorgsvalidering, lagerkontroll, betalningsbehandling, uppfyllandeutlösare) som visar framgångsresultat efter steg |
| Plattform | Användarflöden | ✅ Övervakning på flödesnivå avslöjar problem som är dolda i övervakning på komponentnivå eftersom fel kan inträffa vid vilken övergångspunkt som helst |
| Plattform | Användarflöden | ✅ Varningar aktiveras när flödesresultat faller under acceptabla tröskelvärden eller varaktighet överskrider latensmål |
| Plattform | Integrering | ✅ Integreringshälsoövervakning upptäcker externa systemfel, nätverksproblem, autentiseringsproblem och hastighetsgränsmetoder innan kaskad till användarfel |
| Plattform | Integrering | ✅ Framgångsfrekvensövervakning varnar när de hamnar under 99% för kritiska synkrona integrationer |
| Plattform | Integrering | ✅ Övervakning av feldistribution varnar när nya feltyper visas som inte fanns i baslinjen |
| Plattform | Integrering | ✅ Latens percentilövervakning (p95) varnar när de överstiger 3 sekunder för synkrona användarsamtal |
| Plattform | Integrering | ✅ Genomströmningsövervakning varnar när över 80% av känd gräns eller SLA-tröskel |
| Plattform | Integrering | ✅ Övervakning av strömbrytares status när någon krets öppnas som indikerar försämring av externt system |
| Plattform | Integrering | ✅ Försök hastighet övervakning varningar när ihållande försöksfrekvens överstiger 5% vilket indikerar pålitlighet problem |
| Plattform | Integrering | ✅ Integration telemetri rutter till centraliserade övervakningsplattformar som möjliggör korrelation över systemgränser |
Antimönster
| Var man ska leta | Hur dåligt ser ut |
|---|---|
| Plattform | Användarflöden | ⚠️ Komponenter övervakas oberoende och visar hälsosam drift medan 12 % av användarna lämnar kritiska flöden utan insyn i varför |
| Plattform | Användarflöden | ⚠️ Instrumentpaneler för komponenthälsa visar grönt medan användare inte kan slutföra viktiga arbetsflöden som avslöjar fel i övervakningsarkitekturen |
| Plattform | Användarflöden | ⚠️ Användarresa som berör flera Apex klasser, flöden, plattformshändelser och externa integreringar saknar synlighet från början till slut |
| Plattform | Användarflöden | ⚠️ Viktiga affärsresor saknar instrument; framgångsresultat och avhoppspoäng är okända |
| Plattform | Integrering | ⚠️ Integreringsfel upptäcks endast efter kaskad till användarfel istället för proaktivt |
| Plattform | Integrering | ️ Integrationstelemetri förblir isolerad i individuella system vilket förhindrar korrelation och analys av grundorsak över gränser |
| Plattform | Integrering | ⚠️ Bevaka varningar om symtom längre ner efter att skadan är skedd istället för att tidigt avslöja grundorsakerna |
Mönster
| Var man ska leta | Hur bra ser ut |
|---|---|
| Plattform | SLIs | ✅ Tillgänglighet SLIs mäter procentandel av tid kritiska flöden körs framgångsrikt från användarperspektiv (ta emot förväntade resultat, inte bara 200 statuskod) |
| Plattform | SLIs | ✅ Latens-SLI mäter tid till slutförande av operationer vid p50 (median), p90 (90:e percentilen exklusive avvikelser), p95 (95:e percentilen exklusive värsta avvikelser) och p99 (99:e percentilen visar sämsta-fall-upplevelse) |
| Plattform | SLIs | ✅ latensmål varierar beroende på operationskriticitet och användarförväntningar (500ms sökning känns direkt, samma latens för att skriva indata känns långsam) |
| Plattform | SLIs | ✅ Genomströmnings-SLI mäter volymen av framgångsrika operationer per tidsenhet som avslöjar kapacitetsutnyttjande och tillväxttrender |
| Plattform | SLIs | ✅ Genomströmning i kombination med latens avslöjar om systemet behåller prestanda under ökande belastning eller försämras när volymen ökar |
| Plattform | SLIs | ✅ Felfrekvens SLI skiljer mellan feltyper (användarfel som valideringsfel kontra systemfel som styrande gränsundantag) |
| Plattform | SLOs | ✅ Servicenivåmål fastställs och definierar acceptabla SLI-trösklar baserat på verksamhetskrav innan du väljer arkitekturmönster |
| Plattform | SLOs | ✅ Verksamhetskrav “Säljare måste se säljprojektuppdateringar inom 5 sekunder” driver SLO “Säljprojektdetaljsida laddas inom 3 sekunder på p95” som driver arkitekturbeslut |
| Plattform | SLOs | ✅ SLO uppstår från verksamhetskrav och driver arkitektoniska beslut istället för att definieras baserat på vad systemet för närvarande uppnår |
Antimönster
| Var man ska leta | Hur dåligt ser ut |
|---|---|
| Plattform | SLIs | ⚠️ Tillgänglighet mäts från tekniskt perspektiv (200 statuskod) snarare än användarperspektiv (erhåller förväntat resultat) |
| Plattform | SLIs | ⚠️ Latens mäts endast vid median utan att förstå sämsta möjliga användarupplevelse vid p95 eller p99 percentiler |
| Plattform | SLIs | ⚠️ Felprocents-SLI skiljer inte mellan användarfel och systemfel, vilket maskerar olika problem som kräver olika lösningar |
| Plattform | SLOs | ⚠️ Arkitektur byggs först, sedan definieras SLO som “vad vi för närvarande uppnår” vilket leder till att 12 sekunders sidinläsning accepteras eftersom systemdesign aldrig övervägde användarkrav |
| Plattform | SLOs | ️ SLO är arkitekturdrivna snarare än verksamhetsdrivna och sätter mål baserat på vad systemet åstadkommer snarare än vad användare behöver |
Mönster
| Var man ska leta | Hur bra ser ut |
|---|---|
| Plattform | Varning | ✅ Allvarlighetsklassificering dirigerar kritiska incidenter (produktion ej tillgänglig, datakorruptionsrisk, säkerhetskompromiss) till sidjourtekniker omedelbart |
| Plattform | Varning | ✅ Hög allvarlighetsgrad incidenter (försämrad prestanda, delvisa avbrott) generera notiser för snabb utredning inom arbetstider |
| Plattform | Varning | ✅ Varningar (närmar sig trösklar, konfiguration drift) generera dagliga digest notiser för proaktiv sanering |
| Plattform | Varning | ✅ Varningssammanhang inkluderar påverkat användarantal, felmeddelanden, stackspårningar, senaste distribueringar, relaterade varningar och länkar till relevanta instrumentpaneler |
| Plattform | Varning | ✅ Rik sammanhang minskar genomsnittlig tid att erkänna genom att möjliggöra omedelbar allvarlighetsbedömning och utredning utan att samla in grundläggande information |
| Plattform | Varning | ✅ Varningsgruppering förhindrar varningsstormar där hundratals relaterade varningar aktiveras för enskilda underliggande problem |
| Plattform | Varning | ✅ Integrationsfel utlöser en varning grupperad efter integrationsslutpunkt som visar 156 misslyckade begäranden under de senaste 5 minuterna med latensgraf, felfördelning och instrumentpanellänk |
| Plattform | Varning | ✅ Varningsdämpning förhindrar kända tillfälliga förhållanden från att skapa varningar under förväntade underhållsfönster eller automatiska saneringsperioder |
| Plattform | Varning | ✅ Varningar undertrycks under planerat underhåll, under de första minuterna efter distribuering medan cacharna värms, och under korta tillfälliga fel där försökslogik lyckas |
Antimönster
| Var man ska leta | Hur dåligt ser ut |
|---|---|
| Plattform | Varning | ⚠️ Alla varningar dirigeras till samma kanal utan allvarlighetsklassificering; kritiska incidenter skiljer sig inte från rutinvarningar |
| Plattform | Varning | ⚠️ Varningar saknar diagnostiskt sammanhang; jourhavande tekniker måste samla in grundläggande information genom separata sökfrågor innan de kan bedöma allvarlighetsgraden |
| Plattform | Varning | ⚠️ Integrationsfel skapar 156 individuella varningar på 5 minuter överväldigande jourhavande teknikers telefon, varje varning är identisk förutom tidsstämpel |
| Plattform | Varning | ⚠️ Varningsstormar förhindrar respondenter från att skilja enskilda underliggande problem från hundratals relaterade symtom |
| Plattform | Varning | ⚠️ Varnar brand under kända underhållsfönster och tillfälliga förhållanden som skapar brus som urholkar Trust i övervakning |
| Plattform | Varning | ⚠️ Varningströtthet från brusiga falska positiva resultat gör att team ignorerar notiser vilket minskar svarseffektiviteten |