Osservabilità e monitoraggio - Schemi
Ulteriori informazioni sull’eccellenza operativa ben progettata → Osservabilità e monitoraggio
Schemi
| Dove cercare | Che bell’aspetto |
|---|---|
| Piattaforma | Monitoraggio evento | ✅ Monitoraggio evento è progettato nell’architettura iniziale acquisendo ID di correlazione che tracciano le richieste tramite catene di elaborazione asincrone e integrazioni esterne |
| Piattaforma | Monitoraggio evento | ✅ L’infrastruttura di osservabilità è inclusa fin dallo sprint iniziale anziché essere ammodernata dopo che gli incidenti di produzione si sono rivelati impossibili da diagnosticare |
| Piattaforma | Integrazione | ✅ I checkpoint di integrazione vengono posizionati deliberatamente per consentire il tracciamento delle richieste oltre i confini del sistema |
| Piattaforma | Eventi piattaforma | ✅ I payload degli eventi piattaforma sono strutturati per la visibilità operativa con indicatori di transazione e contesto |
| Piattaforma | Registrazione personalizzata | ✅ Il framework di registrazione personalizzato acquisisce eventi discreti con informazioni contestuali complete tra cui identità utente, indicazione oraria, durata e risultato |
| Piattaforma | Metriche | ✅ Le metriche aggregano le misure numeriche nel tempo rivelando le tendenze tra cui i tassi di consumo API, le distribuzioni del tempo CPU Apex e le percentuali di successo dei processi batch |
| Piattaforma | Tracciamento distribuito | ✅ Le tracce collegano le chiamate API sincrone alle catene di elaborazione asincrone, gli eventi piattaforma alle esecuzioni degli abbonati e le richieste di integrazione alle risposte del sistema esterno |
| Piattaforma | Osservabilità | ✅ L’osservabilità consente agli operatori di rispondere a domande arbitrarie sul comportamento del sistema senza distribuire nuova strumentazione per ogni indagine |
Anti-schemi
| Dove cercare | Che brutto aspetto |
|---|---|
| Piattaforma | Monitoraggio evento | ⚠️ Lancio della soluzione senza registrazione personalizzata, che richiede un refactoring importante sei mesi dopo quando gli incidenti di produzione si rivelano impossibili da diagnosticare con i soli registri piattaforma |
| Piattaforma | Monitoraggio evento | ⚠️ L’osservabilità viene adattata alla soluzione esistente che richiede modifiche della strumentazione che interessano la maggior parte dei componenti e rischiano bug durante il lavoro di miglioramento operativo |
| Piattaforma | Integrazione | ⚠️ Si verificano errori di integrazione ma i percorsi delle richieste non possono essere tracciati oltre i confini del sistema senza una telemetria completa |
| Piattaforma | Eventi piattaforma | ⚠️ I payload Evento piattaforma mancano di contesto operativo rendendo l’indagine sugli incidenti dipendente dalla ricerca in più sistemi |
| Piattaforma | Registrazione personalizzata | ⚠️ I registri acquisiscono un contesto insufficiente; le indagini richiedono la riproduzione dei problemi per raccogliere informazioni aggiuntive |
| Piattaforma | Osservabilità | ⚠️ I cruscotti digitali predefiniti non possono rispondere a domande impreviste sul comportamento del sistema che emerge in produzione |
Schemi
| Dove cercare | Che bell’aspetto |
|---|---|
| Piattaforma | Monitoraggio evento | ✅ Monitoraggio evento è abilitato per gli ambienti di produzione che acquisiscono l’utilizzo dell’API, l’attività di accesso, l’esecuzione Apex, le query SOQL, le pagine Visualforce, le pagine Lightning e le esecuzioni di rapporti |
| Piattaforma | Monitoraggio evento | ✅ Event Log Files (File registro eventi) vengono esportati ogni ora in una piattaforma di registro centralizzata abilitando l’analisi storica oltre la conservazione nativa della piattaforma |
| Piattaforma | Monitoraggio evento | ✅ L’aggregazione dei registri esterni consente la correlazione con la telemetria aziendale da altri sistemi per il tracciamento delle transazioni end-to-end |
| Piattaforma | Monitoraggio evento | ✅ I file registro eventi vengono mantenuti in conformità ai requisiti normativi per la generazione di rapporti sulla conformità e l’analisi delle tendenze a lungo termine |
| Piattaforma | Proactive Monitoring | ✅ Le soglie di Proactive Monitoring vengono sintonizzate deliberatamente in base all’intervallo operativo normale specifico dell’organizzazione anziché accettare le impostazioni predefinite |
| Piattaforma | Proactive Monitoring | ✅ Gli avvisi Proactive Monitoring rilevano picchi di limite API, errori Apex simultanei, approcci al limite di righe SOQL e contesa per il blocco delle righe prima degli incidenti visibili all’utente |
| Piattaforma | Proactive Monitoring | ✅ Le soglie sintonizzate generano segnali fruibili di cui i team si Trust e agiscono creando cicli virtuosi di miglioramento continuo |
| Piattaforma | Scale Center | ✅ I valori di riferimento del Centro scala vengono stabiliti durante la stabilizzazione della soluzione e rivisitati dopo ogni rilascio principale |
| Piattaforma | Scale Center | ✅ Scale Center rivela quali operazioni consumano più risorse, quali transazioni si avvicinano alle soglie di timeout e dove l’investimento nell’ottimizzazione ha un impatto maggiore |
| Piattaforma | Scale Center | ✅ Il tempo di transazione aumenta rispetto all’indagine rapida di base che rivela schemi di query N+1 non intenzionali introdotti nell’ultima distribuzione |
| Piattaforma | Itinerario di controllo impostazioni | ✅ Itinerario di controllo impostazioni tiene traccia delle modifiche alla configurazione, incluse le modifiche delle autorizzazioni, le distribuzioni dei metadati e gli aggiornamenti delle impostazioni di sicurezza con conservazione fino a 180 giorni |
| Piattaforma | Itinerario di controllo impostazioni | ✅ Le voci dell’itinerario di controllo delle impostazioni vengono esportate per la conservazione oltre i 180 giorni quando i requisiti di conformità o contrattuali richiedono finestre storiche più lunghe |
| Piattaforma | Shield | ✅ Itinerario di controllo campi è abilitato in modo selettivo per i campi contenenti dati sensibili, dati regolamentati che richiedono cronologia delle modifiche o dati aziendali critici |
| Piattaforma | Shield | ✅ Itinerario di controllo campi offre fino a 10 anni di conservazione per i campi in cui la comprensione dei valori storici facilita le operazioni e la creazione di rapporti sulla conformità |
| Piattaforma | Controllo dello stato | ✅ I riesami dello stato sono pianificati trimestralmente con i risultati corretti in base alla priorità dei rischi per l’ambiente |
| Piattaforma | Controllo dello stato | ✅ I risultati del controllo dello stato vengono esaminati deliberatamente anziché accettati passivamente; sono documentati controlli compensativi o diverse tolleranze del rischio |
Anti-schemi
| Dove cercare | Che brutto aspetto |
|---|---|
| Piattaforma | Monitoraggio evento | ⚠️ Monitoraggio evento è abilitato ma i registri non vengono mai esportati, limitando le indagini alla finestra di conservazione nativa e impedendo l’analisi del trend storico |
| Piattaforma | Monitoraggio evento | ⚠️ I file del registro eventi rimangono nell’archiviazione della piattaforma; l’aggregazione esterna non viene implementata impedendo la pianificazione della capacità a lungo termine |
| Piattaforma | Proactive Monitoring | ⚠️ Proactive Monitoring utilizza soglie predefinite troppo sensibili o troppo permissive, generando avvisi rumorosi che i team imparano a ignorare |
| Piattaforma | Proactive Monitoring | ⚠️ Il rumore degli avvisi distrugge il Trust nel sistema di monitoraggio; i team smettono di rispondere ai segnali validi |
| Piattaforma | Scale Center | ⚠️ Scale Center è abilitato ma mai rivisto in modo proattivo; le prestazioni peggiorano lentamente fino a quando gli utenti non si lamentano dopo mesi di degrado incrementale |
| Piattaforma | Scale Center | ⚠️ Le metriche delle prestazioni mancano del contesto di riferimento; non è chiaro se i tempi di transazione di 3 secondi siano tipici, in miglioramento o degradanti |
| Piattaforma | Itinerario di controllo impostazioni | ⚠️ Itinerario di controllo impostazioni non viene esportato; le limitazioni di conservazione impediscono indagini di sicurezza o convalida della conformità oltre 180 giorni |
| Piattaforma | Shield | ⚠️ L’itinerario di controllo campi è abilitato per tutti i campi anziché in modo selettivo, creando costi di archiviazione senza un valore di conformità corrispondente |
| Piattaforma | Controllo dello stato | ⚠️ I risultati del controllo dello stato non vengono mai rivisti; la configurazione di sicurezza si discosta dai consigli di base senza accettazione deliberata |
Schemi
| Dove cercare | Che bell’aspetto |
|---|---|
| Piattaforma | Flussi utente | ✅ I flussi di utenti critici sono definiti in base all’impatto sul business e monitorati end-to-end per le percentuali di successo, il tempo di completamento, i punti di abbandono e le percentuali di errore |
| Piattaforma | Flussi utente | ✅ I flussi critici includono attività generanti reddito (invio dell’ordine, esecuzione del contratto, chiusura dell’opportunità), attività a volume elevato (accesso, ricerca, creazione di record) e attività richieste per la conformità (acquisizione del consenso, evasione dei diritti degli interessati) |
| Piattaforma | Flussi utente | ✅ I flussi sono strumentati con indicatori di transazione che indicano l’inizio, il completamento, l’abbandono e l’errore in ogni fase significativa |
| Piattaforma | Flussi utente | ✅ flusso di invio ordine strumentato con eventi piattaforma in ogni fase (convalida carrello, controllo inventario, elaborazione pagamento, trigger di evasione) che mostrano la percentuale di successo per fase |
| Piattaforma | Flussi utente | ✅ Il monitoraggio a livello di flusso rivela problemi invisibili nel monitoraggio a livello di componente perché gli errori possono verificarsi in qualsiasi punto di transizione |
| Piattaforma | Flussi utente | ✅ Gli avvisi vengono attivati quando le percentuali di successo del flusso scendono al di sotto delle soglie accettabili o la durata supera gli obiettivi di latenza |
| Piattaforma | Integrazione | ✅ Il monitoraggio dello stato dell’integrazione rileva errori del sistema esterno, problemi di rete, problemi di autenticazione e approcci ai limiti di traffico prima di cadere in errori indirizzati agli utenti |
| Piattaforma | Integrazione | ✅ avvisi di monitoraggio della percentuale di successo quando si scende al di sotto del 99% per le integrazioni sincrone critiche |
| Piattaforma | Integrazione | ✅ Avvisi di monitoraggio della distribuzione degli errori quando vengono visualizzati nuovi tipi di errore che non esistevano nella base di riferimento |
| Piattaforma | Integrazione | ✅ Avvisi di monitoraggio percentile latenza (p95) quando si superano i 3 secondi per le chiamate sincrone indirizzate agli utenti |
| Piattaforma | Integrazione | ✅ Avvisi di monitoraggio della produttività quando si supera l’80% del limite di traffico noto o della soglia SLA |
| Piattaforma | Integrazione | ✅ Avvisi di monitoraggio dello stato dell’interruttore quando si apre un circuito che indica un deterioramento del sistema esterno |
| Piattaforma | Integrazione | ✅ Avvisi di monitoraggio della percentuale di tentativi quando la percentuale di tentativi sostenuti supera il 5% che indicano problemi di affidabilità |
| Piattaforma | Integrazione | ✅ Integrazione telemetria instrada a piattaforme di monitoraggio centralizzate che consentono la correlazione attraverso i confini del sistema |
Anti-schemi
| Dove cercare | Che brutto aspetto |
|---|---|
| Piattaforma | Flussi utente | ⚠️ I componenti vengono monitorati in modo indipendente mostrando un funzionamento sano mentre il 12% degli utenti abbandona i flussi critici senza visibilità sul motivo |
| Piattaforma | Flussi utente | ⚠️ I cruscotti digitali di integrità dei componenti vengono visualizzati in verde mentre gli utenti non possono completare i flussi di lavoro critici che rivelano un errore dell’architettura di monitoraggio |
| Piattaforma | Flussi utente | ⚠️ Il journey utente che tocca più classi Apex, flussi, eventi piattaforma e integrazioni esterne manca di visibilità end-to-end |
| Piattaforma | Flussi utente | ⚠️ I journey aziendali critici mancano di strumentazione; le percentuali di successo e i punti di abbandono sono sconosciuti |
| Piattaforma | Integrazione | ⚠️ Gli errori di integrazione vengono rilevati solo dopo che si sono verificati errori indirizzati agli utenti anziché in modo proattivo |
| Piattaforma | Integrazione | ⚠️ La telemetria di integrazione rimane isolata nei singoli sistemi, impedendo la correlazione e l’analisi delle cause profonde oltre i confini |
| Piattaforma | Integrazione | ⚠️ Monitoraggio degli avvisi sui sintomi a valle dopo che il danno è stato fatto anziché rivelare precocemente le cause profonde |
Schemi
| Dove cercare | Che bell’aspetto |
|---|---|
| Piattaforma | SLI | ✅ Gli SLI di disponibilità misurano la percentuale di tempo in cui i flussi critici vengono eseguiti correttamente dal punto di vista dell’utente (ricevendo il risultato atteso, non solo il codice di stato 200) |
| Piattaforma | SLI | ✅ Gli SLI di latenza misurano il tempo necessario per completare le operazioni a p50 (mediana), p90 (90° percentile esclusi i valori estremi), p95 (95° percentile esclusi i valori estremi peggiori) e p99 (99° percentile che mostra l’esperienza peggiore) |
| Piattaforma | SLI | ✅ Gli obiettivi di latenza variano in base alla criticità del funzionamento e alle aspettative degli utenti (la ricerca di 500 ms è istantanea, la stessa latenza per la digitazione dell’input è lenta) |
| Piattaforma | SLI | ✅ Gli SLI della produttività misurano il volume delle operazioni riuscite per unità di tempo rivelando l’utilizzo della capacità e le tendenze di crescita |
| Piattaforma | SLI | ✅ La produttività combinata con la latenza rivela se il sistema mantiene le prestazioni sotto carico crescente o si degrada all’aumentare del volume |
| Piattaforma | SLI | ✅ Gli SLI percentuale di errore distinguono i tipi di errore (errori degli utenti come errori di convalida rispetto a errori di sistema come eccezioni limite governor) |
| Piattaforma | SLO | ✅ Gli obiettivi del livello di servizio vengono definiti definendo soglie SLI accettabili in base ai requisiti aziendali prima di selezionare gli schemi di architettura |
| Piattaforma | SLO | ✅ Requisito aziendale “Gli agenti di vendita devono visualizzare gli aggiornamenti delle opportunità entro 5 secondi” determina il caricamento della pagina dei dettagli dell’opportunità “entro 3 secondi a p95” che determina le decisioni sull’architettura |
| Piattaforma | SLO | ✅ Gli SLO emergono dai requisiti aziendali e guidano le decisioni architettoniche anziché essere definiti in base a ciò che il sistema attualmente raggiunge |
Anti-schemi
| Dove cercare | Che brutto aspetto |
|---|---|
| Piattaforma | SLI | ⚠️ La disponibilità viene misurata dal punto di vista tecnico (codice di stato 200) anziché dal punto di vista dell’utente (ricezione del risultato atteso) |
| Piattaforma | SLI | ⚠️ La latenza viene misurata solo alla mediana senza comprendere l’esperienza utente peggiore ai percentili p95 o p99 |
| Piattaforma | SLI | ⚠️ Gli SLI tasso di errore non distinguono tra errori utente ed errori di sistema, mascherando problemi diversi che richiedono soluzioni diverse |
| Piattaforma | SLO | ⚠️ L’architettura viene creata per prima, quindi SLO viene definito come “qualsiasi cosa otteniamo attualmente” portando all’accettazione di caricamenti di pagina di 12 secondi perché la progettazione del sistema non ha mai considerato i requisiti degli utenti |
| Piattaforma | SLO | ⚠️ Gli SLO sono guidati dall’architettura anziché dall’azienda, impostando obiettivi basati su ciò che il sistema raggiunge anziché su ciò di cui gli utenti hanno bisogno |
Schemi
| Dove cercare | Che bell’aspetto |
|---|---|
| Piattaforma | Avviso | ✅ La classificazione della gravità instrada immediatamente gli incidenti critici (produzione non disponibile, rischio di danneggiamento dei dati, compromissione della sicurezza) ai tecnici su chiamata |
| Piattaforma | Avviso | ✅ Gli incidenti di elevata gravità (prestazioni deteriorate, interruzioni parziali) generano notifiche per un’indagine rapida entro l’orario di ufficio |
| Piattaforma | Avviso | ✅ Avvisi (avvicinarsi alle soglie, fluttuazione della configurazione) generano notifiche giornaliere sui rapporti per una correzione proattiva |
| Piattaforma | Avviso | ✅ Il contesto degli avvisi include il conteggio degli utenti interessati, i messaggi di errore, le tracce dello stack, le distribuzioni recenti, gli avvisi correlati e i link ai cruscotti digitali pertinenti |
| Piattaforma | Avviso | ✅ Il contesto RTF riduce il tempo medio per la conferma abilitando la valutazione immediata della gravità e l’indagine senza raccogliere informazioni di base |
| Piattaforma | Avviso | ✅ Il raggruppamento degli avvisi impedisce le tempeste di avvisi in cui vengono attivati centinaia di avvisi correlati per un singolo problema sottostante |
| Piattaforma | Avviso | ✅ L’errore di integrazione attiva un avviso raggruppato per endpoint di integrazione che mostra 156 richieste non riuscite negli ultimi 5 minuti con grafico della latenza, distribuzione degli errori e link al cruscotto digitale |
| Piattaforma | Avviso | ✅ La soppressione degli avvisi impedisce che condizioni transitorie note generino avvisi durante le finestre di manutenzione previste o i periodi di riparazione automatica |
| Piattaforma | Avviso | ✅ Gli avvisi vengono soppressi durante la manutenzione pianificata, nei primi minuti dopo la distribuzione mentre le cache si riscaldano e durante brevi errori temporanei in cui la logica di tentativo riesce |
Anti-schemi
| Dove cercare | Che brutto aspetto |
|---|---|
| Piattaforma | Avviso | ⚠️ Tutti gli avvisi vengono instradati allo stesso canale senza classificazione della gravità; gli incidenti critici non vengono distinti dagli avvisi di routine |
| Piattaforma | Avviso | ⚠️ Gli avvisi mancano di contesto diagnostico; i tecnici su chiamata devono raccogliere informazioni di base tramite query separate prima di valutare la gravità |
| Piattaforma | Avviso | ⚠️ L’errore di integrazione genera 156 singoli avvisi in 5 minuti sovraccaricando il telefono del tecnico su chiamata, ogni avviso è identico tranne per l’indicazione oraria |
| Piattaforma | Avviso | ⚠️ Le tempeste di avviso impediscono ai soccorritori di distinguere un singolo problema sottostante da centinaia di sintomi correlati |
| Piattaforma | Avviso | ⚠️ Gli avvisi vengono attivati durante le finestre di manutenzione note e le condizioni transitorie generando rumore che erode Trust nel monitoraggio |
| Piattaforma | Avviso | ⚠️ L’affaticamento da falsi positivi fa sì che i team ignorino le notifiche riducendo l’efficacia della risposta |