Waarneembaarheid en monitoring - Patronen
Lees meer over Goed Ontworpen Operational Excellence → Waarneming en bewaking
Patronen
| Waar te zoeken | Hoe goed eruitziet |
|---|---|
| Platform | Event Monitoring | ✅ Event Monitoring is ontworpen in de initiële architectuur vastleggen van correlatie-ID’s die verzoeken traceren via asynchrone verwerkingsketens en externe integraties |
| Platform | Event Monitoring | ✅ Observability infrastructuur wordt opgenomen vanaf de initiële sprint in plaats van opnieuw uitgerust nadat productie-incidenten onmogelijk te diagnosticeren blijken |
| Platform | Integratie | ✅ Integratiecontrolepunten worden bewust geplaatst om verzoektracering over systeemgrenzen heen mogelijk te maken |
| Platform | Platform-events | ✅ Platform Event payloads zijn gestructureerd voor operationele zichtbaarheid met transactiemarkeringen en context |
| Platform | Aangepast vastleggen | ✅ Aangepast vastleggingsframework legt afzonderlijke events vast met volledige contextuele informatie, waaronder gebruikersidentiteit, tijdstempel, duur en uitkomst |
| Platform | Meetgegevens | ✅ Meetgegevens aggregeren numerieke metingen in de loop van de tijd onthullen trends, waaronder API-verbruiksscores, Apex CPU-tijdverdelingen en batchtaaksuccesscores |
| Platform | Gedistribueerde tracering | ✅ Traces verbinden synchrone API-aanroepen met asynchrone verwerkingsketens, platformevents met abonnee-uitvoeringen en integratieverzoeken met externe systeemreacties |
| Platform | Observeerbaarheid | ✅ Observeerbaarheid stelt operators in staat om willekeurige vragen over systeemwerking te beantwoorden zonder nieuwe instrumentatie voor elk onderzoek in te zetten |
Anti-patronen
| Waar te zoeken | Hoe slecht eruitziet |
|---|---|
| Platform | Event Monitoring | ⚠️ Oplossing wordt gestart zonder aangepaste vastlegging, die zes maanden later ingrijpende refactoren vereist wanneer productie-incidenten onmogelijk blijken om alleen met platformlogboeken te diagnosticeren |
| Platform | Event Monitoring | ⚠️ Waarneembaarheid wordt opnieuw ingebouwd in de bestaande oplossing, waardoor instrumentatiewijzigingen nodig zijn die de meeste componenten raken en bugs riskeren tijdens operationele verbeteringswerk |
| Platform | Integratie | ⚠️ Integratiefouten treden op, maar verzoekpaden kunnen niet over systeemgrenzen worden getraceerd zonder uitgebreide telemetrie |
| Platform | Platform-events | ⚠️ Platform Event payloads ontbreken operationele context waardoor incidentonderzoek afhankelijk is van het doorzoeken van meerdere systemen |
| Platform | Aangepast vastleggen | ⚠️ Logboeken leggen onvoldoende context vast; onderzoeken vereisen reproductieproblemen om aanvullende informatie te verzamelen |
| Platform | Observeerbaarheid | ⚠️ Vooraf gedefinieerde dashboards kunnen geen antwoord geven op onverwachte vragen over systeemwerking die in productie naar voren komt |
Patronen
| Waar te zoeken | Hoe goed eruitziet |
|---|---|
| Platform | Event Monitoring | ✅ Event Monitoring is ingeschakeld voor productieomgevingen die API-gebruik, inlogactiviteit, Apex uitvoering, SOQL-query’s, Visualforce pagina’s, Lightning pagina’s en rapportuitvoeringen vastleggen |
| Platform | Event Monitoring | ✅ Eventlogboekbestanden worden elk uur geëxporteerd naar een gecentraliseerd logboekplatform, waardoor historische analyses mogelijk zijn die verder gaan dan native platformbehoud |
| Platform | Event Monitoring | ✅ Extern logboekaggregatie maakt correlatie met telemetrie van de onderneming vanuit andere systemen mogelijk voor end-to-end transactietracering |
| Platform | Event Monitoring | ✅ Eventlogboekbestanden worden bewaard overeenkomstig de wettelijke vereisten voor nalevingsrapportage en langetermijntrendanalyse |
| Platform | Proactive Monitoring | ✅ Proactive Monitoring drempelwaarden zijn bewust afgestemd op basis van organisatiespecifieke normale werkbereik in plaats van het accepteren van standaardwaarden |
| Platform | Proactive Monitoring | ✅ Proactive Monitoring waarschuwingen detecteren API limiet pieken, gelijktijdige Apex mislukkingen, SOQL rij limiet benaderingen, en rij lock twist vóór gebruiker-zichtbare incidenten |
| Platform | Proactive Monitoring | ✅ Afgestemde drempelwaarden genereren navolgbare signalen die teams Trust en actie ondernemen om positieve cycli van continue verbetering te creëren |
| Platform | Schaalcentrum | ✅ Scale Center baselines worden vastgesteld tijdens oplossingsstabilisatie en opnieuw bezocht na elke belangrijke release |
| Platform | Schaalcentrum | ✅ Scale Center onthult welke bewerkingen de meeste resources verbruiken, welke transacties time-outdrempels benaderen en waar investeringen in optimalisering de grootste impact hebben |
| Platform | Schaalcentrum | ✅ Transactietijd neemt toe ten opzichte van baseline prompt onderzoek met onbedoelde N + 1 querypatronen die zijn geïntroduceerd in de nieuwste implementatie |
| Platform | Set-up controletraject | ✅ Set-up controletraject houdt configuratiewijzigingen bij, inclusief machtigingswijzigingen, implementaties van metagegevens en updates van beveiligingsinstellingen met behoud van maximaal 180 dagen |
| Platform | Set-up controletraject | ✅ Set-up controletrajectitems worden geëxporteerd voor bewaring langer dan 180 dagen wanneer naleving of contractuele vereisten langere historische perioden vereisen |
| Platform | Shield | ✅ Veldcontroletraject is selectief ingeschakeld voor velden met gevoelige gegevens, gereguleerde gegevens die wijzigingshistorie vereisen of kritieke bedrijfsgegevens |
| Platform | Shield | ✅ Veldcontroletraject biedt maximaal 10 jaar retentie voor velden waarin inzicht in historische waarden helpt bij bewerkingen en nalevingsrapportage |
| Platform | Controle van toestand | ✅ Controle van toestand beoordelingen worden elk kwartaal gepland met bevindingen gecorrigeerd op basis van risicoprioriteit voor het milieu |
| Platform | Controle van toestand | ✅ Bevindingen van de toestandcontrole worden bewust beoordeeld in plaats van passief geaccepteerd; compenserende controles of verschillende risicotoleranties worden gedocumenteerd |
Anti-patronen
| Waar te zoeken | Hoe slecht eruitziet |
|---|---|
| Platform | Event Monitoring | ⚠️ Event Monitoring is ingeschakeld, maar logboeken worden nooit geëxporteerd, waardoor onderzoeken worden beperkt tot de oorspronkelijke bewaarperiode en historische trendanalyse wordt voorkomen |
| Platform | Event Monitoring | ⚠️ Eventlogboekbestanden blijven in platformopslag; externe aggregatie is niet geïmplementeerd, waardoor capaciteitsplanning op de lange termijn wordt voorkomen |
| Platform | Proactive Monitoring | ⚠️ Proactive Monitoring gebruikt standaarddrempelwaarden die te gevoelig of te laks zijn, waardoor rumoerige waarschuwingen worden gegenereerd die teams leren te negeren |
| Platform | Proactive Monitoring | ⚠️ Waarschuwingsgeluid vernietigt Trust in bewakingssysteem; teams stoppen met reageren op geldige signalen |
| Platform | Schaalcentrum | ⚠️ Schaalcentrum is ingeschakeld, maar nooit proactief beoordeeld; prestaties gaan langzaam achteruit totdat gebruikers klagen na maanden van incrementele achteruitgang |
| Platform | Schaalcentrum | ⚠️ Prestatiemeetgegevens hebben geen baselinecontext; onduidelijk of transactietijden van 3 seconden typisch, verbeterend of verlagend zijn |
| Platform | Set-up controletraject | ⚠️ Set-up controletraject wordt niet geëxporteerd; bewaarbeperkingen voorkomen beveiligingsonderzoeken of nalevingsvalidatie langer dan 180 dagen |
| Platform | Shield | ⚠️ Veldcontroletraject is ingeschakeld voor alle velden in plaats van selectief, waardoor opslagkosten worden gemaakt zonder overeenkomende nalevingswaarde |
| Platform | Controle van toestand | ⚠️ Bevindingen van Controle van toestand worden nooit beoordeeld; beveiligingsconfiguratie wijkt af van baselineaanbevelingen zonder bewuste acceptatie |
Patronen
| Waar te zoeken | Hoe goed eruitziet |
|---|---|
| Platform | Gebruikersstromen | ✅ Kritieke gebruikersstromen worden gedefinieerd op basis van bedrijfsimpact en end-to-end gecontroleerd op successcores, voltooiingstijd, verlatingspunten en foutenpercentages |
| Platform | Gebruikersstromen | ✅ Kritieke stromen omvatten omzet genererende activiteiten (order indienen, contractuitvoering, opportunity sluiten), activiteiten met groot volume (login, zoeken, maken van records) en naleving-vereiste activiteiten (vastleggen van toestemming, uitvoering van rechten van betrokkenen) |
| Platform | Gebruikersstromen | ✅ Stromen worden geïnstrumenteerd met transactiemarkeringen die het begin, de voltooiing, de stopzetting en de mislukking aangeven bij elke belangrijke stap |
| Platform | Gebruikersstromen | ✅ Order indiening stroom geïnstrumenteerd met platform events in elke fase (winkelwagen validatie, voorraadcontrole, betalingsverwerking, levering trigger) met succes score per fase |
| Platform | Gebruikersstromen | ✅ Stroomniveaubewaking onthult problemen die onzichtbaar zijn in bewaking op componentniveau, omdat storingen op elk overgangspunt kunnen optreden |
| Platform | Gebruikersstromen | ✅ Waarschuwingen gaan af wanneer stroomsuccesscores onder acceptabele drempelwaarden dalen of de duur de latentiedoelen overschrijdt |
| Platform | Integratie | ✅ Integratiestatusbewaking detecteert externe systeemfouten, netwerkproblemen, authenticatieproblemen en benaderingen van scorelimieten voordat ze in gebruikersfouten terechtkomen |
| Platform | Integratie | ✅ Waarschuwingen voor bewaking van successcores wanneer ze onder 99% zakken voor kritieke synchrone integraties |
| Platform | Integratie | ✅ Bewakingswaarschuwingen voor foutverdeling wanneer nieuwe fouttypen worden weergegeven die niet bestonden in baseline |
| Platform | Integratie | ✅ Latentie percentiel bewaking (p95) waarschuwingen bij overschrijding van 3 seconden voor synchrone gebruiker-gerichte gesprekken |
| Platform | Integratie | ✅ Doorvoerbewakingswaarschuwingen wanneer boven 80% van de bekende scorelimiet of SLA-drempel |
| Platform | Integratie | ✅ Stroomonderbrekerstatusbewaking waarschuwt wanneer een circuit wordt geopend, wat aangeeft dat het externe systeem is gedegradeerd |
| Platform | Integratie | ✅ Bewakingswaarschuwingen voor hernieuwde pogingen wanneer het aanhoudende hernieuwingspercentage hoger is dan 5%, wat duidt op betrouwbaarheidsproblemen |
| Platform | Integratie | ✅ Integratietelemetrieroutes naar gecentraliseerde bewakingsplatforms voor correlatie over systeemgrenzen heen |
Anti-patronen
| Waar te zoeken | Hoe slecht eruitziet |
|---|---|
| Platform | Gebruikersstromen | ⚠️ Componenten worden onafhankelijk bewaakt en tonen een gezonde werking, terwijl 12% van de gebruikers kritieke stromen verlaat zonder zicht op waarom |
| Platform | Gebruikersstromen | ⚠️ Dashboards voor de gezondheid van componenten worden groen weergegeven terwijl gebruikers kritieke werkstromen niet kunnen voltooien die een fout in de bewakingsarchitectuur onthullen |
| Platform | Gebruikersstromen | ⚠️ Gebruikersjourney die meerdere Apex klassen, stromen, platformevents en externe integraties aanraakt, mist end-to-end zichtbaarheid |
| Platform | Gebruikersstromen | ⚠️ Kritieke zakelijke journeys hebben geen instrumentatie; succespercentages en verlatingspunten zijn onbekend |
| Platform | Integratie | ⚠️ Integratiefouten worden alleen gedetecteerd na trapsgewijs in fouten voor gebruikers in plaats van proactief |
| Platform | Integratie | ⚠️ Integratietelemetrie blijft geïsoleerd in afzonderlijke systemen waardoor correlatie en analyse van de hoofdoorzaak over grenzen heen worden voorkomen |
| Platform | Integratie | ⚠️ Bewaking van waarschuwingen over symptomen verderop in de stroom nadat schade is aangericht in plaats van het vroegtijdig ontdekken van de hoofdoorzaken |
Patronen
| Waar te zoeken | Hoe goed eruitziet |
|---|---|
| Platform | SLI’s | ✅ Beschikbaarheid SLI’s meten percentage van tijd kritieke stromen met succes uitvoeren vanuit het perspectief van de gebruiker (ontvangen van verwachte resultaat, niet alleen 200 statuscode) |
| Platform | SLI’s | ✅ Latentie-SLI’s meten de tijd tot voltooiing van bewerkingen op p50 (mediaan), p90 (90e percentiel exclusief uitschieters), p95 (95e percentiel exclusief slechtste uitschieters) en p99 (99e percentiel met slechtste ervaring) |
| Platform | SLI’s | ✅ Latentiedoelen variëren per bedrijfskritiek en gebruikersverwachting (500ms zoekopdracht voelt onmiddellijk, dezelfde latentie voor het typen van invoer voelt traag) |
| Platform | SLI’s | ✅ Doorvoer-SLI’s meten het volume van succesvolle bewerkingen per tijdseenheid en tonen capaciteitsbezetting en groeitrends |
| Platform | SLI’s | ✅ Doorvoer in combinatie met latentie onthult of het systeem prestaties behoudt onder toenemende belasting of afneemt naarmate het volume groeit |
| Platform | SLI’s | ✅ Foutpercentage SLI’s maken onderscheid tussen fouttypen (gebruikersfouten zoals validatiefouten versus systeemfouten zoals uitzonderingen voor beheerlimieten) |
| Platform | SLO’s | ✅ Service Level Objectives worden vastgesteld en definiëren acceptabele SLI-drempelwaarden op basis van bedrijfsvereisten voordat architectuurpatronen worden geselecteerd |
| Platform | SLO’s | ✅ Bedrijfsvereiste “Verkoopvertegenwoordigers moeten opportunity-updates binnen 5 seconden zien” drijft SLO “Opportunitydetailpagina wordt binnen 3 seconden op p95 geladen” wat architectuurbeslissingen aanstuurt |
| Platform | SLO’s | ✅ SLO’s ontstaan uit bedrijfsvereisten en sturen architectonische beslissingen in plaats van te worden gedefinieerd op basis van wat het systeem momenteel bereikt |
Anti-patronen
| Waar te zoeken | Hoe slecht eruitziet |
|---|---|
| Platform | SLI’s | ⚠️ Beschikbaarheid wordt gemeten vanuit technisch perspectief (200 statuscode) in plaats van gebruikersperspectief (verwacht resultaat ontvangen) |
| Platform | SLI’s | ⚠️ Latentie wordt alleen gemeten bij mediaan zonder inzicht in worst-case gebruikerservaring bij p95- of p99-percentielen |
| Platform | SLI’s | ⚠️ SLI’s voor foutscores maken geen onderscheid tussen gebruikersfouten en systeemfouten, waardoor verschillende problemen worden gemaskeerd die verschillende oplossingen vereisen |
| Platform | SLO’s | ⚠️ Architectuur wordt eerst gebouwd, daarna wordt SLO gedefinieerd als “wat we momenteel ook bereiken”, wat leidt tot acceptatie van paginaladingen van 12 seconden, omdat systeemontwerp nooit rekening heeft gehouden met gebruikersvereisten |
| Platform | SLO’s | ⚠️ SLO’s zijn architectuurgestuurd in plaats van bedrijfsgestuurd, doelen stellen op basis van wat het systeem bereikt in plaats van wat gebruikers nodig hebben |
Patronen
| Waar te zoeken | Hoe goed eruitziet |
|---|---|
| Platform | Waarschuwing | ✅ Ernstclassificatie routeert kritieke incidenten (productie niet beschikbaar, risico op gegevenscorruptie, beveiligingscompromis) onmiddellijk naar oproepbare engineers |
| Platform | Waarschuwing | ✅ Ernstige incidenten (verminderde prestaties, gedeeltelijke uitval) genereren kennisgevingen voor onmiddellijk onderzoek binnen kantooruren |
| Platform | Waarschuwing | ✅ Waarschuwingen (naderende drempelwaarden, configuratieafwijking) genereren dagelijkse samenvattingskennisgevingen voor proactieve oplossing |
| Platform | Waarschuwing | ✅ Waarschuwing context omvat getroffen aantal gebruikers, foutberichten, stack traces, recente implementaties, gerelateerde waarschuwingen en koppelingen naar relevante dashboards |
| Platform | Waarschuwing | ✅ Rijke context verkort de gemiddelde tijd voor bevestiging door onmiddellijke beoordeling van de ernst en onderzoek in te schakelen zonder basisgegevens te verzamelen |
| Platform | Waarschuwing | ✅ Groepering van waarschuwingen voorkomt waarschuwingsstormen waarbij honderden gerelateerde waarschuwingen worden geactiveerd voor één onderliggend probleem |
| Platform | Waarschuwing | ✅ Integratiefout activeert een waarschuwing gegroepeerd op integratie-eindpunt met 156 mislukte verzoeken in de afgelopen 5 minuten met latentiegrafiek, foutverdeling en dashboardkoppeling |
| Platform | Waarschuwing | ✅ Waarschuwingsonderdrukking voorkomt dat bekende voorbijgaande omstandigheden waarschuwingen genereren tijdens verwachte onderhoudsperioden of automatische herstelperioden |
| Platform | Waarschuwing | ✅ Waarschuwingen worden onderdrukt tijdens gepland onderhoud, tijdens de eerste paar minuten na de implementatie, terwijl caches warm zijn, en tijdens korte tijdelijke storingen waarbij opnieuw proberen logica slaagt |
Anti-patronen
| Waar te zoeken | Hoe slecht eruitziet |
|---|---|
| Platform | Waarschuwing | ⚠️ Alle waarschuwingen worden naar hetzelfde kanaal gerouteerd zonder ernstclassificatie; kritieke incidenten worden niet onderscheiden van routinewaarschuwingen |
| Platform | Waarschuwing | ⚠️ Waarschuwingen hebben geen diagnostische context; oproeptechnici moeten basisgegevens verzamelen via afzonderlijke query’s voordat ze de ernst kunnen beoordelen |
| Platform | Waarschuwing | ⚠️ Integratiefout genereert 156 individuele waarschuwingen in 5 minuten overweldigende oproepengineertelefoon, elke waarschuwing identiek behalve tijdstempel |
| Platform | Waarschuwing | ⚠️ Waarschuwingsstormen voorkomen dat responders één onderliggend probleem onderscheiden van honderden gerelateerde symptomen |
| Platform | Waarschuwing | ⚠️ Waarschuwt brand tijdens bekende onderhoudsvensters en voorbijgaande omstandigheden die geluid genereren dat Trust in bewaking erodeert |
| Platform | Waarschuwing | ⚠️ Waarschuwingsvermoeidheid door luidruchtige vals-positieven zorgt ervoor dat teams kennisgevingen negeren waardoor de effectiviteit van de reactie afneemt |