Disponibilità e modelli di prestazioni

Ulteriori informazioni su Affidabilità ben progettata → Architettura High Availability

Schemi

Dove cercare	Che bell’aspetto
Analisi dell’impatto aziendale	✅ SLO definiti per funzionalità aziendale (ad esempio, “Flusso di chiusura opportunità: Disponibilità 99,9%, latenza p95 inferiore a 2 secondi”) anziché per componente tecnico
Documentazione del flusso utente	✅ Ogni flusso utente critico ha uno SLO misurabile che copre la disponibilità, la latenza, la produttività, la percentuale di errore e il tempo di ripristino legato all’esperienza utente effettiva
Record decisioni architettura	✅ Obiettivi di disponibilità basati sull’analisi dell’impatto del tempo di inattività aziendale con logica documentata (ad esempio, rapporti batch interni 99% vs elaborazione ordini critici per il reddito 99,95%)
Specifiche SLO	✅ Obiettivi realistici considerando la complessità dell’architettura (99% = funzionalità standard della piattaforma, 99,5% = ridondanza di base e monitoraggio attivo, 99,9% = consapevolezza multi-regione e failover automatico, 99,95% = schemi attivi e test caos, 99,99% = architettura multi-organizzazioni)
Documentazione della piattaforma	✅ SLO della soluzione meno rigorosi degli SLA della piattaforma (ad esempio, SLA della piattaforma 99,9% → SLO della soluzione 99,5%) che forniscono un budget di errore per gli errori a livello di applicazione
Configurazione di monitoraggio	✅ Indicatori del livello di servizio (SLI) misurabili oggettivamente tramite la strumentazione della piattaforma: tempo di attività Trust.salesforce.com, analisi Experience Cloud, tempo di risposta API Monitoraggio evento, completamento del processo AsyncApex
Metriche dell’esperienza utente	✅ Gli SLO riflettono i journey utente completi (ad esempio, “Flusso di invio caso: tutti e 5 i passaggi vengono completati entro 8 secondi per gli utenti p95”) non il tempo di attività API individuale

Anti-schemi

Dove cercare	Che brutto aspetto
Documentazione sull’architettura	⚠️ “Il sistema deve essere veloce e affidabile” (non misurabile, non determina decisioni sull’architettura)
Specifiche SLO	⚠️ “Tutto ha bisogno di un tempo di attività del 99,999%” (costo ingiustificato che ignora le differenze di criticità aziendale tra operazioni di reddito e strumenti di amministrazione interni)
Strategia di monitoraggio	⚠️ Monitoraggio della CPU dell’infrastruttura come SLI principale (gli architetti delle metriche della piattaforma non possono agire, non riflettendo l’esperienza rivolta agli utenti)
Pianificazione della capacità della piattaforma	⚠️ Solution SLO corrisponde esattamente a SLA piattaforma al 99,9% (nessun budget di errore per problemi a livello di applicazione, errori di integrazione o manutenzione pianificata)
Documentazione SLO	⚠️ SLO definiti per componente tecnico anziché per capacità aziendale rivolta agli utenti (disponibilità dei componenti necessaria ma insufficiente per l’affidabilità dell’esperienza utente)

Schemi

Dove cercare	Che bell’aspetto
Strategia di distribuzione regionale	✅ La distribuzione a regione singola con ridondanza Hyperforce gestita dalla piattaforma (più zone di disponibilità, failover automatico dell’infrastruttura) offre uno SLO del 99,9% per la maggior parte delle soluzioni
Architettura multi-organizzazioni	✅ Modelli multi-organizzazioni solo quando il business richiede un RPO/RTO garantito oltre le funzionalità della piattaforma, l’isolamento dei dati geografici normativi o la completa indipendenza regionale (attivo-passivo o attivo-attivo con sincronizzazione dei dati)
Replica dei dati	✅ Acquisizione dati di modifica per i dati critici (RPO quasi in tempo reale, minuti), Eventi piattaforma per eventi aziendali quasi in tempo reale, estrazione API in blocco 2.0 pianificata per i dati di riferimento (RPO 24 ore)
Monitoraggio dello stato della piattaforma	✅ Abbonamento alle notifiche di stato Trust.salesforce.com e alle API di stato specifiche dell’istanza che consentono una risposta proattiva a incidenti, finestre di manutenzione e impatti sulle prestazioni
Gestione dinamica del carico	✅ Le soluzioni rispondono allo stato di salute della piattaforma riducendo l’elaborazione batch non critica durante il degrado, rinviando i processi in background durante le finestre di manutenzione
Utilizzo di Scale Center	✅ Revisione settimanale del Centro scala identifica le transazioni e le operazioni di lunga durata che consumano risorse sproporzionate, abilitando la riparazione architettonica prima dell’impatto dell’utente
Livelli di rilevamento errori	✅ Rilevamento a più livelli: errori della piattaforma tramite l’API di stato, errori di integrazione tramite il monitoraggio del timeout, errori delle applicazioni tramite la registrazione delle eccezioni, deterioramento delle prestazioni tramite percentili di latenza, avvisi sulla capacità tramite Proactive Monitoring
Soglie di avviso	✅ Gli avvisi vengono attivati in caso di schemi di tasso di errore (ad esempio, 5 timeout API in 60 secondi) o di degrado prolungato, non di errori isolati normali nei sistemi distribuiti

Anti-schemi

Dove cercare	Che brutto aspetto
Progettazione multi-organizzazioni	⚠️ Architettura multi-organizzazioni implementata “solo in caso” senza requisiti aziendali documentati che giustifichino la complessità operativa della sincronizzazione dei dati, del provisioning utente e del coordinamento della distribuzione
Monitoraggio dello stato della piattaforma	⚠️ Ignorare le notifiche di stato Trust.salesforce.com, scoprire le finestre di manutenzione quando gli utenti segnalano errori (risposta reattiva anziché proattiva)
Rilevamento errori	⚠️ Avviso su ogni singolo errore indipendentemente dalla frequenza (genera affaticamento avviso oscurando i segnali critici); timeout API singolo attiva page-out (reazione eccessiva al normale comportamento del sistema distribuito)
Replica dei dati	⚠️ Nessun monitoraggio specifico dell’integrazione, scopri solo gli errori di integrazione quando gli utenti segnalano operazioni bloccate (manca visibilità sullo stato del sistema esterno)
Strategia di ridondanza	⚠️ Chiamata sincrona al servizio di arricchimento esterno senza timeout o fallback (utente bloccato quando il servizio esterno è lento o non disponibile)

Schemi

Dove cercare	Che bell’aspetto
Monitoraggio utente reale (RUM)	✅ Latenza utente effettiva misurata tramite analisi Experience Cloud o strumentazione personalizzata che riflette le condizioni di rete reali, le prestazioni del dispositivo, la distribuzione geografica
Monitoraggio sintetico	✅ transazioni automatiche da più posizioni che convalidano la disponibilità e le prestazioni prima che gli utenti segnalino problemi (ad esempio, invio di ordini ogni 15 minuti da 3 regioni)
Tracciamento delle transazioni	✅ Operazioni a più fasi strumentate con tempistiche per fase che identificano i colli di bottiglia (ad esempio, la chiamata di convalida indirizzo fase 3 rappresenta il 70% della latenza totale)
Ottimizzazione delle query	✅ Query selettive con filtri indicizzati, query di relazione che riducono i viaggi di andata e ritorno, considerazione dell’ottimizzazione delle query con volumi di dati su scala di produzione (il comportamento cambia drasticamente con più di 10 milioni di record)
Utilizzo della cache piattaforma	✅ Partizioni cache di sessioni o organizzazioni che servono dati di riferimento accessibili di frequente, precompilati durante le operazioni riuscite che forniscono dati non aggiornati ma disponibili quando l’API in tempo reale non è disponibile
Configurazione timeout	✅ chiamate sincrone indirizzate all’utente 5-10 secondi (interfaccia utente reattiva), chiamate asincrone in background 30-60 secondi (prestazioni esterne variabili), elaborazione batch 120 secondi (nessuna attesa utente); totale budget in più chiamate per transazione
Monitoraggio della latenza di integrazione	✅ percentili di latenza p50/p95/p99 per integrazione con SLO per endpoint; le anomalie di latenza (tempi di risposta in fluttuazione verso l’alto) indicano la saturazione della capacità prima del guasto completo

Anti-schemi

Dove cercare	Che brutto aspetto
Strategia di monitoraggio	⚠️ Monitorare solo le metriche dell’infrastruttura (CPU server, larghezza di banda di rete) senza misurazione del flusso indirizzata all’utente (le metriche non riflettono l’esperienza utente effettiva)
Strategia cache	⚠️ Nessun utilizzo della cache piattaforma per i dati di riferimento consultati di frequente (query ripetute per gli stessi dati che aumentano la latenza e consumano limiti SOQL)
Configurazione timeout	⚠️ Chiamata del flusso sincrono con timeout di 120 secondi che causa all’utente di fissare il filatore di caricamento per 2 minuti (dovrebbe utilizzare il timeout di 5-10 secondi con fallback)
Test delle prestazioni	⚠️ Test su piccola scala con volumi di dati minimi (il comportamento dell’ottimizzazione delle query cambia drasticamente a più di 10 milioni di record rendendo i risultati su piccola scala fuorvianti)
Progettazione dell’integrazione	⚠️ Nessun tracciamento a livello di transazione dei flussi di lavoro a più fasi (fase collo di bottiglia invisibile nelle metriche aggregate)

Schemi

Dove cercare	Che bell’aspetto
Schemi di scala orizzontale	✅ Carico di lavoro distribuito su più risorse: l’elaborazione in blocco elabora più record per transazione, l’elaborazione asincrona distribuisce il lavoro nel tempo, il partizionamento dei dati distribuisce il carico oltre i confini
Configurazione di elaborazione batch	✅ Dimensioni ottimali del batch che bilanciano la produttività e i limiti del governor (2.000 record per esecuzione Batch Apex, 200 record per chiamata trigger, 25 richieste per chiamata API composita)
Gestione dei tassi API	✅ Il batching e il caching dell’integrazione riducono il consumo dell’API, monitorano l’allocazione API 24 ore su 24 in base alla versione, la pianificazione della capacità aggiunge licenze o limita gli aumenti prima dell’esaurimento
Esecuzione simultanea	✅ Processi batch paralleli per i dati partizionati (5 batch di roll-up regionali in esecuzione simultanea), abbonati Evento piattaforma che elaborano stream contemporaneamente
Monitoraggio della profondità dell’area di attesa	✅ Per le integrazioni asincrone, le tendenze della profondità dell’area di attesa indicano che l’elaborazione è in ritardo rispetto al tasso di produzione che richiede l’aumento della capacità o l’ottimizzazione della produttività
Rilevamento anomalia volume	✅ I volumi delle transazioni significativamente superiori/inferiori agli schemi previsti possono indicare processi in fuga che richiedono indagini e limitazioni

Anti-schemi

Dove cercare	Che brutto aspetto
Elaborazione in batch	⚠️ Elaborare tutti i record in sequenza quando il volume di dati richiede l’esecuzione parallela partizionata (il partizionamento basato sulla data, sul tipo di record o sul titolare abilita l’elaborazione simultanea)
Consumo API	⚠️ Lo schema di integrazione aggiunge il 25% di consumo API senza pianificazione della capacità (gli errori “limite API superato” improvvisi influiscono sugli utenti)
Monitoraggio dell’area di attesa	⚠️ Nessun monitoraggio della profondità dell’area di attesa di integrazione asincrona (l’elaborazione rimane indietro rispetto al tasso di produzione senza visibilità)
Gestione dei limiti governor	⚠️ Operazioni sincrone che elaborano grandi volumi che raggiungono le dimensioni dell’heap o i limiti di tempo della CPU (dovrebbe passare all’elaborazione asincrona con limiti dedicati)

Schemi

Dove cercare	Che bell’aspetto
Gerarchia delle criticità delle funzioni	✅ Livelli definiti: Critico (reddito/conformità, mai degradato), Importante (flussi di lavoro principali, deteriorato solo durante incidenti gravi), Supportante (esperienza ottimizzata, disabilitato durante l’errore di integrazione), Facoltativo (bello da avere, disabilitato durante carichi elevati)
Implementazione dell’interruttore	✅ Stati dei circuiti (Chiuso = normale, Aperto = non riesce subito dopo la soglia, Mezzo aperto = sonda di ripristino); Cache piattaforma memorizza lo stato, Eventi piattaforma trasmette modifiche; apre dopo errori consecutivi (ad esempio, 10 errori)
Riprova logica	✅ Backoff esponenziale per errori temporanei (1s, 2s, 4s, 8s, limite a 30-60s); riprovare i timeout di rete e gli errori 5xx con backoff, riprovare i limiti di traffico 429 dopo l’intestazione Retry-After; non riprovare mai gli errori client 4xx o gli errori limite governor nella stessa transazione
Strategie di fallback	✅ Fonti di dati alternative (cache piattaforma quando l’API in tempo reale non è disponibile), comportamento predefinito (regole standard quando il servizio di personalizzazione non è disponibile), processo manuale (interfaccia di amministrazione per le transazioni bloccate), area di attesa per riprovare (Eventi piattaforma con replay di 72 ore)
Architettura di gestione degli errori	✅ fallire velocemente (convalidare gli input all’ingresso), fallire in modo grazioso (elaborare 197 di 200 record quando 3 non convalidano), fallire in modo informativo (registrare con ID transazione, contesto utente, traccia dello stack), fallire in modo sicuro (ritirare transazioni parziali, non esporre mai gli elementi interni agli utenti)
Automazione del ripristino	✅ Il monitoraggio della piattaforma attiva il ripristino automatico: meccanismi di nuovo tentativo asincroni, aree di attesa senza risposta per elaborazione non riuscita, flussi di lavoro di autoguarigione che consentono un ripristino rapido senza intervento manuale

Anti-schemi

Dove cercare	Che brutto aspetto
Dipendenza di integrazione	⚠️ L’invio dell’ordine non riesce completamente quando il servizio di convalida dell’indirizzo esterno non funziona (flusso critico bloccato dalla funzione di supporto; dovrebbe degradarsi con grazia con la revisione manuale)
Strategia dell’interruttore	⚠️ Nessun interruttore su chiamata esterna che causa ogni transazione di attendere 120 secondi per il timeout quando il sistema esterno è inattivo (tutti gli utenti interessati da un’integrazione non riuscita)
Riprova logica	⚠️ Riprova errore superato limite CPU Apex immediatamente nello stesso contesto della transazione (fallirà di nuovo; dovrebbe ripetere l’area di attesa come operazione asincrona con limiti dedicati)
Riprova logica	⚠️ Riprova indefinitamente fino al successo (rischio di loop infinito, la transazione non viene mai completata; dovrebbe limitare il numero massimo di tentativi di nuovo tentativo)
Gestione degli errori	⚠️ Eccezione di blocco Prova-cattura ingoia senza registrazione (errore invisibile agli operatori che impedisce la diagnosi e la riparazione)
Gestione degli errori	⚠️ Visualizza la traccia dello stack per l’utente finale nella pagina Lightning (rischio di sicurezza che rivela i dettagli dell’implementazione, scarsa esperienza utente)
Strategia di fallback	⚠️ Il servizio di calcolo delle imposte non riesce a bloccare tutti gli invii di ordini (funzionalità critica senza fallback; dovrebbe attendere l’elaborazione manuale o utilizzare le tariffe predefinite)

Schemi

Dove cercare	Che bell’aspetto
Modellazione della salute	✅ stato di salute aggregato: Salute dell’assistenza (percentuale di successo delle transazioni >99,5% verde, 98-99,5% giallo, <98% rosso), Salute dell’integrazione (verde tutto rispondente, giallo degradato, rosso aperto interruttore), Salute dei dati (verde corrente di sincronizzazione, dietro giallo, rosso obsoleto/non riuscito), Salute della capacità (<70% verde, 70-85% giallo, >85% rosso)
Monitoraggio evento	✅ oggetti EventLogFile con consegna 24h/1h instradata a SIEM esterno per la conservazione oltre i limiti di conservazione nativi; acquisisce chiamate API, visualizzazioni pagina, esportazioni di rapporti, attività di accesso, esecuzione Apex
Avvisi di Proactive Monitoring	✅ Picchi di limite delle richieste API (indagine sui trigger di soglia del 75%), errori di esecuzione Apex simultanei, problemi di limite delle righe SOQL, tendenze del consumo di memoria
Cruscotto digitale di integrità integrazione	✅ Metriche per integrazione: tasso di errore (target <1%), latenza p50/p95/p99 con SLO, tasso di timeout (target <0,1%), stato dell’interruttore, profondità dell’area di attesa asincrona; registri strutturati con ID richiesta, endpoint, codice risposta, durata
Progettazione di avvisi fruibili	✅ Ogni avviso definisce chi risponde, cosa controlla, come corregge; include la soglia superata, il valore corrente, il trend recente, il link al cruscotto digitale, il link al runbook; la gravità corrisponde all’urgenza (pagine CRITICHE su richiesta per l’impatto degli utenti, email di ATTENZIONE per le preoccupazioni di tendenza)
Rilevamento dell’anomalia	✅ anomalie del volume (300% del carico tipico), anomalie del tasso di errore (2% vs 0,5% tipico anche se al di sotto della soglia del 5%), fluttuazione della latenza (tendenza graduale verso l’alto), anomalie comportamentali (schemi di accesso insoliti, processi batch fuori programma); utilizzato per guidare l’indagine non attivare l’inoltro immediato al livello superiore

Anti-schemi

Dove cercare	Che brutto aspetto
Monitoraggio evento	⚠️ Monitoraggio evento abilitato ma mai esportato (conservazione nativa insufficiente per l’analisi del trend, dati storici persi)
Progettazione avviso	⚠️ Messaggio di avviso “Si è verificato un errore” senza contesto, soglia o azione di risposta (genera affaticamento avviso, gli operatori non possono eseguire il triage in modo efficace)
Gravità avviso	⚠️ Considerare tutte le anomalie come avvisi critici (l’alto tasso di falsi positivi crea affaticamento degli avvisi causando la perdita di avvisi critici)
Monitoraggio sanitario	⚠️ Nessun modello sanitario aggregato, gli operatori sovraccaricati da singole metriche tecniche che mancano di schemi tra sistemi
Monitoraggio dell’integrazione	⚠️ Nessun tasso di errore specifico dell’integrazione, latenza o tracciamento dello stato dell’interruttore (errori di integrazione rilevati in modo reattivo tramite i rapporti utente)
Monitoraggio della capacità	⚠️ Nessuna revisione Proactive Monitoring o Scale Center (i rischi di affidabilità derivanti da transazioni che richiedono molte risorse non vengono rilevati fino all’impatto sulla produzione)

Per esempi in linea e istruzioni dettagliate, vedere il pilastro Affidabilità o sfogliare l’Explorer schemi e antischemi.