Affidabilità

Salesforce gestisce un'infrastruttura resiliente in più regioni con failover automatico e resilienza a livello di infrastruttura. La piattaforma gestisce la ridondanza del data center, la disponibilità della rete e il patching dell'infrastruttura, con lo stato di disponibilità della piattaforma in tempo reale visibile all'indirizzo Trust.salesforce.com.

Si progetta l'affidabilità di tutto ciò che viene eseguito in questa infrastruttura:: i modelli di dati scalabili entro i limiti del governor, le transazioni che anticipano e risolvono gli errori, il monitoraggio che rileva quando la soluzione si discosta dai target di disponibilità e le procedure di ripristino di emergenza che ripristinano le operazioni aziendali quando si verificano errori.

Il contratto sul livello di servizio di Salesforce copre la piattaforma, ma si è titolari dell'affidabilità per tutto ciò che si trova al di sopra del livello di infrastruttura. L'utente è responsabile della definizione e del raggiungimento dei propri obiettivi dei livelli di servizio (SLO), ovvero gli obiettivi di affidabilità richiesti dalla propria azienda. L'affidabilità a livello di applicazione rimane una responsabilità dell'utente indipendentemente dal livello SLA della piattaforma. Anche la stessa piattaforma che garantisce la disponibilità la limita: i limiti del governor limitano il consumo di risorse di ogni tenant in modo che nessun tenant possa degradare la piattaforma per altri. La soluzione deve quindi essere scalata con grazia entro questi limiti, anziché richiedere semplicemente più capacità.

Soluzioni inaffidabili possono creare impatti aziendali a catena. Il flusso di reddito rallenta quando le piattaforme di commercio non sono disponibili. La produttività diminuisce quando gli strumenti interni non funzionano a metà flusso di lavoro. Trust si erode quando i dati vengono danneggiati o i record vengono persi. Questi problemi si aggravano nel tempo man mano che le soluzioni si accumulano e il debito tecnico cresce.

Affidabilità non significa prevenire tutti gli errori. Gli errori si verificano nei sistemi distribuiti. L'affidabilità riguarda la progettazione di sistemi che anticipano i guasti, aiutano a contenere il raggio di esplosione e ripristinano automaticamente il servizio. I requisiti di affidabilità variano a seconda dell'impatto sul business. Ad esempio, un portale Experience Cloud indirizzato ai clienti che richiede una disponibilità del 99,9% implica scelte architettoniche fondamentalmente diverse rispetto a un processo di creazione di rapporti batch interni che tollera ritardi occasionali.

Affidabilità ed Eccellenza Operativa sono profondamente interconnesse. Entrambi riguardano il monitoraggio, la risposta agli incidenti e la disponibilità del sistema. Questa sovrapposizione è intenzionale, non accidentale. La distinzione sta nel tempo di progettazione rispetto al tempo di esecuzione.

L'affidabilità è ciò che si progetta in un sistema prima che venga eseguito, tra cui:

• i modelli di dati menzionati in precedenza che rientrano nei limiti del governor
• le transazioni che anticipano e risolvono gli errori
• ridondanza e interruttori che contengono il raggio di esplosione
• gli obiettivi di ripristino - obiettivo tempo di ripristino (RTO) e obiettivo punto di ripristino (RPO) - che determinano il comportamento del sistema quando le cose non vanno.

L'affidabilità è una caratteristica strutturale della soluzione.

L'Eccellenza Operativa è il modo in cui si gestisce, migliora e sostiene il sistema una volta in esecuzione, tra cui:

• le procedure di distribuzione che riducono il rischio di cambiamento
• Runbook e percorsi di inoltro al livello superiore che guidano il team durante gli incidenti
• le pipeline di osservabilità che evidenziano i segnali
• i cicli di feedback che migliorano il sistema nel tempo.

L'eccellenza operativa è la disciplina umana e di processo che circonda la soluzione.

Il terreno condiviso tra i due pilastri è il livello di monitoraggio e osservabilità. Il monitoraggio è progettato come un problema di affidabilità. Dovresti creare dei sistemi osservabili. È praticato come una preoccupazione di eccellenza operativa. Il team agisce in base a ciò che viene comunicato dai sistemi. L'affidabilità copre gli schemi architettonici creati, ad esempio le soglie di avviso e i cruscotti digitali di salute. L'eccellenza operativa copre il modo in cui il team risponde ai segnali, ad esempio runbook e risposte su chiamata.

Considerare questa distinzione: Gli indirizzi di affidabilità "Il sistema sopravviverà?" mentre gli indirizzi di Eccellenza operativa "Il team può gestirlo?" Un sistema perfettamente affidabile gestito da un team senza runbook, distribuzioni incoerenti o cicli di feedback può comunque fallire nella pratica. Un team operativamente eccellente che gestisce un sistema fragile e mal progettato sarà sopraffatto da incidenti che non può prevenire. Entrambi i pilastri sono necessari, e nessuno dei due sostituisce l'altro.

L'affidabilità non funziona isolatamente. Come descritto nelle sezioni precedenti, Eccellenza Operativa è il partner più vicino. I due pilastri condividono il livello di osservabilità, con l'affidabilità che definisce ciò che si crea in un sistema e l'eccellenza operativa che definisce il modo in cui opera il team. Trust richiede anche un'infrastruttura che resista agli attacchi e mantenga l'integrità dei dati: un sistema non è affidabile se può essere compromesso. L'ottimizzazione delle risorse evita l'esaurimento del limite del governor, garantendo che la piattaforma rimanga affidabile su larga scala. L'ottimizzazione dei costi bilancia gli investimenti in affidabilità con il valore aziendale che offrono. Gli obiettivi di disponibilità giustificano la complessità architettonica richiesta per raggiungerli. Nessun singolo pilastro produce una soluzione ben progettata isolatamente: l'affidabilità fornisce le basi strutturali da cui gli altri pilastri dipendono e si rafforzano.

Utilizzare questi principi per guidare le decisioni relative all'architettura per garantire l'affidabilità della piattaforma.

• Distribuire il carico di lavoro tramite l'esecuzione in blocco. Elaborare più record in singole transazioni anziché affidarsi a operazioni sequenziali per record. La creazione in blocco condivide i limiti del governor in un batch elaborato in una singola transazione, rispettando tali limiti e massimizzando la produttività. L'elaborazione Apex basata sulle raccolte, i processi batch con ambito configurabile e gli eventi piattaforma consumati in blocco racchiudono tutti questo principio. Le soluzioni ben in blocco elaborano 200 record con lo stesso numero di istruzioni SOQL e DML di un record nell'elaborazione sequenziale. Gli schemi di carico di lavoro distribuiti offrono resilienza poiché nessun errore di un singolo record influisce sull'elaborazione dell'intero batch.
• Supponiamo che tutto fallisca. I limiti del governor, le finestre di manutenzione della piattaforma e le dipendenze di integrazione creano modalità di errore correlate all'architettura multitenant Salesforce. Progettare per questi errori specifici della piattaforma fin dall'inizio. Le query SOQL superano i limiti di righe sotto la distorsione dei dati. Il tempo CPU Apex può scadere durante calcoli complessi. I timeout delle chiamate possono verificarsi a causa della lentezza dei servizi esterni. I blocchi delle righe DML non riescono quando le transazioni simultanee si scontrano. I limiti di memoria possono fallire quando i caricamenti dei file aumentano in modo imprevisto. Gli architetti che pianificano questi errori creano soluzioni affidabili senza intervento manuale. Questi sistemi affidabili rilevano l'avvicinarsi dei limiti del governor, contengono il raggio di esplosione tramite la gestione degli errori e ripristinano automaticamente tramite i framework di tentativo e gli eventi piattaforma.
• Creare sistemi di auto-ripristino. Progettare soluzioni che rilevano gli errori e si ripristinano automaticamente senza intervento umano. Gli eventi piattaforma abilitano schemi di tentativo personalizzati. La consegna a un abbonato può essere tentata con EventBus.RetryableException, anche se la riproduzione della transazione originale richiede un'architettura personalizzata. La gestione degli errori dei flussi indirizza le eccezioni ai flussi di ripristino. I processi batch Apex isolano gli errori dei blocchi - un blocco non riuscito non impedisce l'elaborazione di altri blocchi - abilitando il completamento parziale del processo e un nuovo tentativo mirato. Implementare una logica di tentativo esplicita utilizzando il tracciamento degli errori in AsyncApexJob per il ripristino temporaneo degli errori. Applicare un backoff esponenziale a questi schemi di tentativo quando si gestiscono errori temporanei. I sistemi di auto-ripristino mantengono gli obiettivi di disponibilità anche durante gli incidenti fuori orario, quando i soccorritori umani potrebbero non essere disponibili, riducendo il carico operativo e migliorando il tempo medio per il ripristino.
• Progettare prima per i requisiti aziendali. Definire gli obiettivi del livello di servizio in base all'impatto effettivo sul business prima di selezionare le soluzioni tecniche. Non tutti i componenti richiedono una disponibilità di cinque-nove. Abbinare l'investimento in affidabilità alla criticità aziendale e progettare un degrado armonioso per le funzioni di supporto. Gli obiettivi realistici consentono scelte di architettura appropriate ed evitano l'ingegneria eccessiva o la fornitura insufficiente.
• Convalidare il recupero tramite esercitazioni. Pianificare esercitazioni di ripristino di emergenza che testano il ripristino del backup, le procedure di failover e i playbook di risposta agli incidenti. Ripristino di un Full Copy Sandbox dal backup di produzione per convalidare i processi di ripristino. Introdurre errori intenzionali negli ambienti Sandbox per verificare che il monitoraggio rilevi problemi e che il ripristino automatico venga eseguito correttamente. Le esercitazioni rivelano lacune nelle procedure, negli strumenti e nei runbook prima che incidenti reali li rendano visibili. Documentare i risultati delle esercitazioni e tenere traccia della correzione delle lacune rilevate. Test regolari assicurano che le funzionalità di ripristino rimangano aggiornate man mano che le soluzioni evolvono e che cambia l'appartenenza ai team.

Capire che cosa funziona Salesforce aiuta a concentrare le attività di progettazione dell'affidabilità su ciò che si controlla. La piattaforma gestisce i problemi infrastrutturali che richiederebbero team dedicati negli ambienti IT tradizionali, ad esempio:

• Infrastruttura multiregionale e failover: Salesforce Hyperforce offre ai data center regionali il failover automatico dei servizi interni. Fornisce inoltre più zone di disponibilità all'interno delle regioni e la replica dei dati a livello di infrastruttura. La piattaforma gestisce in modo trasparente la ridondanza e la distribuzione delle zone di disponibilità all'interno delle regioni.
• Impegni sugli SLA piattaforma: I livelli di disponibilità garantita con rimedi contrattuali sono negoziati per cliente. Trust.salesforce.com pubblica lo stato della piattaforma in tempo reale e la cronologia dei tempi di attività, ma qualsiasi garanzia di disponibilità specifica e i relativi rimedi sono inclusi nell'accordo negoziato. Esaminare il contratto e la documentazione corrente di Salesforce Trust and Compliance per verificare gli impegni validi per la propria organizzazione.
• Ridondanza dell'infrastruttura: La piattaforma gestisce server, percorsi di rete, infrastrutture di database e sistemi di archiviazione ridondanti. Il failover a livello di infrastruttura avviene automaticamente durante i guasti hardware senza intervento del cliente. I backup della piattaforma proteggono dalla perdita di dati a livello di infrastruttura.
• Manutenzione e aggiornamenti della piattaforma: I rilasci principali della piattaforma offrono funzioni e patch di sicurezza con compatibilità retroattiva gestita da Salesforce. Le finestre di manutenzione della piattaforma sono pianificate e comunicate su Trust.salesforce.com. Il patching dell'infrastruttura avviene in modo trasparente, senza coinvolgimento del cliente.
• Monitoraggio dello stato della piattaforma Core: Salesforce monitora le prestazioni dell'infrastruttura, inclusi i tempi di risposta del database, la latenza di rete, lo stato del gateway API e le prestazioni del sistema di archiviazione. Lo stato di integrità della piattaforma è visualizzato su Trust.salesforce.com e include gli aggiornamenti degli incidenti in tempo reale. Lo stato specifico dell'istanza è disponibile tramite l'API Stato.

Queste operazioni della piattaforma creano le basi su cui costruire. Non si gestiscono data center, server di provisioning o si progetta il ripristino di emergenza dell'infrastruttura. L'utente è piuttosto responsabile di ciò che progetta e configura in cima a questa base.

Il modello di responsabilità condivisa specifica che si è titolari dell'affidabilità per tutto ciò che si crea con Salesforce. L'affidabilità della piattaforma consente il lavoro ma non lo sostituisce. Le responsabilità di affidabilità riguardano sei aree interconnesse:

Gli obiettivi del livello di servizio (SLO) quantificano i requisiti di affidabilità in termini misurabili. Gli SLO collegano i requisiti aziendali e l'architettura tecnica. Prima di selezionare le tecnologie o progettare modelli di dati, stabilire SLO che definiscono il successo di ogni flusso utente critico.

Gli SLO in genere misurano:

• Disponibilità: percentuale di tempo in cui il sistema è operativo e accessibile
• Latenza: tempo necessario per completare le operazioni, misurato come percentili (p50, p95, p99)
• Throughput - volume di operazioni completate correttamente per unità di tempo
• Tasso di errore - percentuale di richieste non riuscite o che restituiscono errori
• Tempo di ripristino: durata richiesta per ripristinare il servizio dopo gli incidenti

Definire gli SLO in base alle funzionalità aziendali anziché in base ai componenti tecnici. Le funzionalità rivolte agli utenti richiedono SLO più rigorosi rispetto ai processi amministrativi o batch. Ogni SLO deve essere oggettivamente misurabile utilizzando la strumentazione disponibile.

I contratti sui livelli di servizio (SLA) sono impegni contrattuali con conseguenze in caso di errore. Qualsiasi livello di disponibilità garantito e i relativi rimedi contrattuali vengono negoziati per cliente. Esaminare il contratto e la documentazione corrente di Salesforce Trust and Compliance per verificare gli impegni applicabili alla propria organizzazione.

Gli SLO delle soluzioni devono essere meno rigorosi degli SLA della piattaforma per preservare il budget degli errori. Se il contratto sul livello di servizio della piattaforma e lo SLO della soluzione hanno entrambi come obiettivo il 99,9%, qualsiasi tempo di inattività significativo della piattaforma consuma direttamente il budget per gli errori, evitando errori a livello di applicazione, problemi di integrazione o manutenzione pianificata nello stesso periodo di misurazione. Uno SLO viene formalmente violato solo quando il tempo di inattività cumulativo esaurisce il budget di errore completo per il periodo di misurazione. Se SLA e SLO sono impostati sullo stesso obiettivo, un singolo incidente piattaforma può esaurire completamente il budget. Ad esempio, quando la piattaforma fornisce il 99,9%, puntare a uno SLO della soluzione del 99,5% per mantenere un buffer significativo per i problemi che è necessario risolvere (bug delle applicazioni, errori di integrazione e finestre di distribuzione).

Gli indicatori del livello di servizio (SLI) sono misure utilizzate per valutare il raggiungimento degli SLO. Gli SLI devono essere oggettivamente misurabili, raccolti in modo coerente e direttamente collegati all'esperienza utente.

Per le soluzioni Salesforce, gli SLI includono:

• Tempo di attività della piattaforma tramite Trust.salesforce.com
• Tempo di caricamento delle pagine tramite Experience Cloud Analytics
• Tempo di risposta API tramite Monitoraggio evento (che richiede il componente aggiuntivo Monitoraggio evento o Salesforce Shield)
• Percentuale di successo delle transazioni tramite registrazione applicazione personalizzata
• Completamento del processo batch tramite il monitoraggio AsyncApexJob

Obiettivi di disponibilità più elevati creano complessità e costi in aumento esponenziale. Comprendere le implicazioni architettoniche prima di impegnarsi per raggiungere gli obiettivi:

Evita obiettivi arbitrari come "cinque nove per tutto". Valutare invece l'impatto aziendale del tempo di inattività per funzionalità e impostare gli obiettivi di conseguenza. I rapporti batch interni che tollerano 7 ore di tempo di inattività mensile richiedono un'architettura fondamentalmente diversa rispetto all'elaborazione degli ordini critica per il reddito che richiede un ripristino sub-orario.

Definire l'affidabilità dal punto di vista dell'utente anziché dalle sole metriche tecniche. Un sistema che segnala un tempo di attività del 99,9% ma che presenta frequenti timeout non garantisce l'affidabilità basata sull'esperienza utente. Gli utenti si preoccupano di completare correttamente i flussi di lavoro più del tempo di attività delle singole API.

Progettare SLO che riflettano i journey degli utenti anziché le singole chiamate API. Un flusso Checkout multifase richiede che ogni fase venga completata correttamente in un tempo accettabile. Misurare le percentuali di completamento dei flussi utente end-to-end come indicatore di affidabilità principale. La disponibilità dei componenti è necessaria, ma insufficiente per l'affidabilità dell'esperienza utente.

Salesforce Hyperforce offre data center regionali che consentono la distribuzione geografica. La piattaforma gestisce la ridondanza dell'infrastruttura all'interno delle regioni, incluse più zone di disponibilità, il failover automatico dei servizi interni e la replica dei dati a livello di infrastruttura. Gli SLA piattaforma riflettono questa ridondanza dell'infrastruttura.

Per la maggior parte delle soluzioni, la distribuzione a regione singola con ridondanza gestita dalla piattaforma offre una disponibilità sufficiente. Trust nell'infrastruttura Salesforce per la disponibilità di base e per concentrare l'architettura delle soluzioni sull'affidabilità a livello di applicazione, inclusi schemi di integrazione tolleranti ai guasti, degradazione graduale e ripristino automatico.

Il failover all'interno dell'area geografica nelle zone di disponibilità è automatico e incluso negli impegni SLA standard della piattaforma, che Salesforce gestisce in modo trasparente a livello di infrastruttura. Il ripristino di emergenza tra regioni (fuori regione) è un'offerta a pagamento separata e non è incluso per impostazione predefinita in alcuna versione standard. Se i requisiti di continuità operativa richiedono il failover tra regioni, documentare esplicitamente questa dipendenza nel piano di ripristino di emergenza in modo che le parti interessate comprendano la distinzione tra la resilienza della piattaforma inclusa e le funzionalità di DR tra regioni acquistate.

L'architettura multi-organizzazione offre la massima isolamento e ridondanza geografica, ma moltiplica la complessità operativa, incluse la sincronizzazione dei dati, il provisioning utente, il coordinamento della distribuzione e i costi delle licenze. Riservare gli schemi multi-organizzazione agli scenari in cui i requisiti aziendali giustificano chiaramente la complessità. Si consideri ad esempio uno schema multi-organizzazione per questi scenari:

• L'azienda richiede un RPO/RTO garantito oltre le funzionalità della piattaforma
• I requisiti normativi impongono l'isolamento dei dati geografici, la pianificazione della continuità operativa richiede una completa indipendenza da una singola regione
• Il consolidamento dell'organizzazione non è possibile a causa dei requisiti di autonomia dell'unità operativa.

Schema attivo-passivo: - L'organizzazione principale serve tutto il traffico in condizioni normali. Le organizzazioni secondarie in regioni diverse rimangono sincronizzate ma inattive. Il failover si verifica durante un guasto della regione principale. Questa soluzione offre lo schema multi-organizzazione più semplice ma lascia inutilizzata la capacità secondaria. I livelli di instradamento DNS o di autenticazione utente indirizzano gli utenti all'organizzazione attiva.

Schema attivo-attivo: Entrambe le organizzazioni servono il traffico di produzione in modo continuo. Gli utenti vengono allocati per area geografica, unità operativa o tipo di carico di lavoro. Attivo-attivo massimizza l'utilizzo della capacità ma richiede una sincronizzazione dei dati e un instradamento utente sofisticati. La risoluzione dei conflitti è fondamentale quando lo stesso record viene modificato in entrambe le organizzazioni.

Progettare una sincronizzazione dei dati adeguata ai requisiti RPO. Gli eventi piattaforma offrono uno streaming degli eventi quasi in tempo reale per le modifiche critiche dei dati. Acquisizione dati di modifica offre il tracciamento automatico delle modifiche per gli oggetti selezionati con uno sviluppo minimo. La replica API pianificata tramite API in blocco 2.0 a intervalli fissi è adatta ai dati di riferimento meno sensibili al tempo.

Applicare la ridondanza a livello di dati, applicazione e integrazione per evitare singoli punti di errore. La ridondanza a livelli garantisce che l'errore a qualsiasi livello non comprometta la disponibilità complessiva del sistema.

• Ridondanza dei dati: La piattaforma fornisce la ridondanza dei dati tramite backup dell'infrastruttura. Integrare questa ridondanza con la replica a livello di applicazione quando l'azienda richiede un ripristino più rapido rispetto alle procedure di ripristino della piattaforma. Utilizzare Acquisizione dati di modifica o eventi piattaforma per replicare continuamente dati critici in archivi secondari o in sistemi esterni. Ciò consente il ripristino da un danneggiamento logico o da errori di configurazione che i backup dell'infrastruttura non possono risolvere.
• Ridondanza applicazione: Progettare una logica di applicazione stateless in modo che qualsiasi server di applicazioni possa elaborare qualsiasi richiesta. Evitare lo stato lato server che impedisce la scalabilità orizzontale. Utilizzare tipi di metadati personalizzati e impostazioni personalizzate per la configurazione che deve essere immediatamente disponibile in tutti i server di applicazioni. La progettazione stateless consente a un server di applicazioni di elaborare le richieste senza dipendere dallo stato specifico del server.
• Ridondanza integrazione: Progettare integrazioni che tollerino l'indisponibilità temporanea del sistema esterno. Implementare schemi di interruttori che rilevano integrazioni non riuscite. Inserire in area di attesa le richieste tramite Eventi piattaforma quando i sistemi esterni sono inattivi anziché bloccare le operazioni degli utenti. Ciò isola gli errori del sistema esterno dalle funzionalità rivolte agli utenti.

Monitorare lo stato della piattaforma Salesforce utilizzando Trust.salesforce.com e le API di stato specifiche dell'istanza. Abbonarsi alle notifiche sullo stato dell'istanza per ricevere avvisi su incidenti, finestre di manutenzione e impatti sulle prestazioni. I segnali di integrità della piattaforma consentono una risposta proattiva anziché la risoluzione reattiva dei problemi.

Progettare soluzioni che rispondano allo stato di integrità della piattaforma. Quando le prestazioni della piattaforma peggiorano, ridurre il carico di elaborazione batch non critico. Rinviare i processi in background durante le finestre di manutenzione utilizzando il monitoraggio pianificato dei processi. Disabilitare le integrazioni non essenziali per proteggere le operazioni critiche rivolte agli utenti durante gli incidenti. Questa riduzione dinamica del carico mantiene l'affidabilità per le capacità critiche sotto stress.

Utilizzare Scale Center per identificare transazioni e operazioni di lunga durata che consumano risorse sproporzionate della piattaforma. Scale Center offre visibilità a livello di transazione, consentendo agli architetti di rilevare i rischi di affidabilità prima che diventino incidenti indirizzati agli utenti. L'esame settimanale del Centro di scala rivela schemi che richiedono una bonifica architettonica.

Implementare il rilevamento dei guasti a più livelli per individuare i problemi prima che si verifichino interruzioni complete. Il rilevamento a livelli offre una difesa approfondita contro errori non rilevati.

Progettare soglie di avviso che bilanciano il rilevamento precoce con i falsi positivi. Avvisa quando i tassi di errore superano le soglie o si verifica un deterioramento prolungato, non in caso di errori isolati. Gli errori singoli sono normali nei sistemi distribuiti. Gli schemi di errore indicano problemi di affidabilità che richiedono attenzione.

I limiti del governor Salesforce limitano il consumo di risorse di ogni tenant nella piattaforma multitenant in modo che nessun tenant possa peggiorare le prestazioni per gli altri. Queste non sono restrizioni arbitrarie; sono confini architettonici che modellano la progettazione delle soluzioni. Prima di progettare un'architettura affidabile, è importante conoscere i limiti del governor. Le soluzioni che si avvicinano regolarmente ai limiti del governor sotto carico normale probabilmente falliranno sotto stress.

Limiti critici del governor che influiscono sulle decisioni architettoniche:

Progettare transazioni che vengano completate entro i limiti previsti, anche sotto carico di punta. Creare un margine puntando al 70% dei limiti del governor come tetto operativo in condizioni normali, riservando il 30% a picchi imprevisti. Questo buffer consente aumenti temporanei del carico, in genere senza superare i limiti massimi.

La creazione in blocco è lo schema di scalabilità di base per Salesforce. Elaborare più record in una singola transazione anziché in singole operazioni record. La messa in blocco riduce il consumo limite del governor aumentando la produttività. Ogni architetto Salesforce deve padroneggiare gli schemi di bulking, poiché sono alla base di tutte le soluzioni scalabili.

Progettare tutti i trigger Apex, le classi batch e le integrazioni per elaborare le raccolte di record in modo efficiente. Raccogliere prima gli identificatori dei record, quindi elaborare tutti i record con istruzioni DML e query singole. Utilizzare mappe e insiemi per ricerche efficienti anziché loop nidificati con query singole. L'elaborazione basata sulle raccolte migliora l'efficienza in ordine di grandezza rispetto agli approcci record per record.

L'automazione attivata da record deve gestire 200 record per chiamata trigger, poiché la piattaforma elabora l'esecuzione dei trigger in batch di un massimo di 200 record. Le operazioni di Lightning Data Service vengono eseguite automaticamente in batch, ma i componenti personalizzati devono implementare schemi in blocco in modo esplicito quando eseguono operazioni DML.

L'elaborazione asincrona distribuisce il lavoro nel tempo anziché tentare il completamento immediato entro i limiti del governor di una singola transazione. Utilizzare schemi asincroni quando le operazioni elaborano grandi volumi di dati che superano i limiti del governor sincrono, dipendono da sistemi esterni con tempi di risposta variabili, possono tollerare un completamento ritardato o richiedere un tempo di esecuzione prolungato oltre i limiti della CPU sincrona.

Funzionalità asincrone di Salesforce e loro adattamento all'architettura:

• Batch Apex: Elaborare grandi volumi di record in blocchi di un massimo di 2.000 record per metodo di esecuzione. Batch fornisce limiti governor dedicati per blocco e isolamento da errori: un blocco non riuscito non impedisce il completamento di altri blocchi. Ciò consente un successo parziale e un tentativo mirato. Implementare una logica di tentativo personalizzata per gli errori temporanei monitorando gli intervalli di blocchi non riusciti nell'oggetto AsyncApexJob e rimettendo in area di attesa i processi batch mirati. Utilizzare batch per le migrazioni dei dati, gli aggiornamenti in blocco pianificati e l'elaborazione dati su larga scala. Sono presenti un massimo di cinque processi batch in esecuzione o in attesa di esecuzione simultanea per organizzazione. Ulteriori processi vengono inseriti nell'area di attesa Flex Apex (fino a 100 processi con stato In attesa) ed eseguiti automaticamente quando si aprono delle finestre.
• Apex in area di attesa: Eseguire processi asincroni con la funzionalità di concatenazione per abilitare flussi di lavoro a più fasi e parametri di oggetti complessi. Queueable Apex condivide il limite DailyAsyncApexExecutions di tutta l'organizzazione di 250.000 esecuzioni ogni 24 ore con tutti gli altri Apex asincroni (Batch, Future e Scheduled Apex) anziché avere un'allocazione specifica Queueable dedicata. Utilizzare Queuable Apex per l'orchestrazione a più fasi e i flussi di lavoro di integrazione che richiedono un'elaborazione sequenziale con un monitoraggio migliore rispetto ai metodi @future.
• Eventi piattaforma: Gli eventi piattaforma vengono utilizzati in un'architettura di eventi pubblicazione-abbonamento che separa i publisher dagli abbonati. Gli eventi vengono riprodotti da un periodo di conservazione di 72 ore (3 giorni). La conservazione prolungata oltre le 72 ore è disponibile come componente aggiuntivo a pagamento: verificare i limiti massimi correnti e lo stato GA nella documentazione più recente degli eventi Salesforce Platform prima di impegnarsi per gli obblighi degli accordi sul livello di servizio che dipendono dalla riproduzione estesa. Utilizzare Eventi piattaforma per l'automazione basata sugli eventi, l'integrazione tra sistemi e lo streaming di dati in tempo reale. Gli eventi piattaforma offrono confini asincroni naturali tra le fasi della transazione.
• Apex pianificato: Eseguire processi con una pianificazione fissa utilizzando espressioni CRON tramite System.schedule(). L'esecuzione di un processo può essere pianificata al massimo una volta all'ora: i campi CRON secondi e minuti devono utilizzare valori fissi, non intervalli. Rimanere entro il limite massimo di 100 processi Apex pianificati per organizzazione consolidando operazioni simili in singole classi pianificabili.

Quando i volumi di dati superano i limiti pratici di elaborazione anche con schemi di in blocco e asincroni, suddividere i dati attraverso confini logici per consentire l'elaborazione parallela. Il partizionamento dei dati converte le operazioni sequenziali di grandi dimensioni in operazioni parallele più piccole che vengono completate più rapidamente e rimangono entro i limiti del governor.

• Partizionamento basato sulla data: Elaborare i dati in finestre temporali che includono le transazioni di questo mese o i casi dell'ultimo trimestre. Archiviare i dati storici in Big Object o in memoria esterna per mantenere gestibile l'insieme di lavoro. La maggior parte delle query transazionali si concentra sui dati recenti rendendo il partizionamento basato sul tempo naturalmente efficiente.
• Partizionamento del tipo di record: Elaborare diversi tipi di record in modo indipendente, inclusi i casi Partner e i casi Cliente o gli account Enterprise e gli account PMI. Processi batch separati per tipo abilitano la parallelizzazione. Il tipo di record è spesso correlato a processi aziendali distinti che giustificano l'elaborazione indipendente.
• Partizionamento basato sul titolare: Distribuire l'elaborazione in base al titolare del record, ad esempio elaborando le opportunità di ogni regione di vendita in modo indipendente. Il partizionamento basato sul titolare è particolarmente efficace se combinato con un modello di condivisione, poiché la sicurezza viene applicata tramite meccanismi esistenti. Il partizionamento basato sul titolare consente la distribuzione geografica del carico di elaborazione.

Proiettare i requisiti di capacità futuri in base alla crescita aziendale anziché reagire per limitare l'esaurimento. La pianificazione proattiva della capacità evita incidenti di affidabilità causati dall'esaurimento delle risorse della piattaforma.

• Licenze utente - crescita del personale che guida l'allocazione delle chiamate API e i diritti di archiviazione per utente
• Memoria dati: volumi delle transazioni e policy di conservazione che determinano il consumo di memoria (prevedere una crescita annuale minima del 10-20%)
• Chiamate API - conteggio integrazione e frequenza che determinano l'allocazione API su 24 ore (ogni nuovo schema di integrazione aggiunge un consumo ricorrente)
• Capacità di elaborazione: conteggio e complessità dei processi batch che determinano aree di attesa di elaborazione asincrona e limiti di esecuzione simultanea

Utilizzare Proactive Monitoring per valutare continuamente l'utilizzo della capacità dell'organizzazione. Proactive Monitoring mette in evidenza i rischi di capacità, tra cui l'utilizzo dell'API che si avvicina ai picchi di limite delle richieste, l'archiviazione che si avvicina ai limiti e la profondità dell'area di attesa dei processi batch che cresce oltre i livelli sostenibili. L'esame settimanale della capacità consente il lead time di procurement per licenze aggiuntive o limiti prima che si verifichi l'impatto sul business.

Convalidare i presupposti di scalabilità tramite test di carico prima della distribuzione in produzione. I test di carico rilevano problemi di limiti governor, colli di bottiglia di integrazione e vincoli di capacità invisibili nei test di sviluppo a basso volume. Eseguire il test con volumi di dati e concomitanza su scala di produzione per convalidare l'affidabilità in condizioni realistiche.

• Test del volume di dati: Compilare i volumi di dati su scala di produzione nell'ambiente Sandbox Copia completa per convalidare le prestazioni delle query con la distorsione dei dati, la profondità delle relazioni e i conteggi dei record reali. Testare con oltre 10 milioni di record quando la produzione raggiungerà quella scala. Il comportamento dell'ottimizzazione delle query cambia drasticamente all'aumentare del volume dei dati, il che può causare risultati fuorvianti nei Test di scalabilità ridotta.
• Test utente simultaneo: Simulare il caricamento simultaneo di picco degli utenti per convalidare la produttività delle transazioni e la contesa. Utilizzare i test di scala disponibili per le organizzazioni qualificate per simulare i carichi di lavoro di produzione negli ambienti Sandbox prima della distribuzione. L'esecuzione simultanea rivela problemi di blocco invisibili nei test per utente singolo.
• Test di carico API: Generare volumi API di picco per convalidare la scalabilità dell'integrazione, la gestione dei limiti di traffico e il comportamento degli interruttori sotto carico sostenuto. I test di caricamento API rivelano se la logica di tentativo e la gestione degli errori funzionano correttamente in condizioni di stress.
• Test scala: Test di scalabilità è un prodotto Salesforce utilizzato per simulare i carichi di lavoro di produzione con ambienti Sandbox Copia completa scalati in base alla capacità di produzione. Test di scalabilità eseguiti con i Sandbox Copia completa in Hyperforce. L'istanza di produzione non deve necessariamente essere su Hyperforce per utilizzarla. I piani di test vengono creati nell'organizzazione di produzione, mentre i test vengono eseguiti nel Sandbox. Utilizzare Test di scalabilità per convalidare il comportamento di headroom limite governor, throughput di elaborazione asincrona e risposta di integrazione in condizioni di carico di picco prima delle distribuzioni principali.

La degradazione graduale mantiene la funzionalità di base quando i componenti non critici si guastano. Progettare sistemi che diano priorità ai flussi utente critici rispetto alle funzioni di supporto durante gli errori. Non tutte le funzionalità hanno la stessa importanza per il business e le architetture dovrebbero riflettere queste priorità.

Definire la gerarchia delle criticità delle funzioni:

Questa gerarchia consente agli architetti di progettare policy di degrado che mantengono la continuità operativa anche in caso di errori parziali del sistema. Gli utenti preferiscono una funzionalità ridotta a una completa indisponibilità.

Lo schema dell'interruttore evita errori a catena quando le integrazioni non sono disponibili. Anziché accumulare timeout che consumano tempo di transazione e limiti del governor, rilevare gli schemi di errore e interrompere le chiamate ai sistemi in errore. Gli interruttori automatici forniscono un guasto rapido anziché lento.

Stati interruttore:

• Chiuso - funzionamento normale, le richieste vengono inviate al sistema esterno come progettato
• Aperte - soglia di errore superata, richieste non riuscite immediatamente senza tentare chiamate esterne, risparmio di risorse
• Mezzo aperto - periodo di test di ripristino, richieste limitate sondare i sistemi esterni per rilevare il ripristino prima di chiudere completamente il circuito

Implementare gli interruttori utilizzando la cache piattaforma per memorizzare lo stato dei circuiti accessibile in tutte le transazioni. Utilizzare Eventi piattaforma per trasmettere le modifiche dello stato in tutta l'organizzazione. La logica degli interruttori automatici controlla lo stato prima di tentare le chiamate esterne, evitando gli sprechi dei limiti delle chiamate sui sistemi con errori noti.

Gli errori temporanei sono normali nei sistemi distribuiti. Le interruzioni della rete, l'indisponibilità temporanea del servizio e le risposte ai limiti di traffico spesso si risolvono in pochi secondi. Implementare una logica di tentativo che ripeta le operazioni non riuscite dopo ritardi progressivi anziché fallire immediatamente.

Il backoff esponenziale impedisce che si ripetano i temporali che sovraccaricano i sistemi di ripristino. Un primo tentativo può verificarsi dopo 1 secondo, un secondo dopo 2 secondi, un terzo dopo 4 secondi e un quarto dopo 8 secondi. Limitare il ritardo massimo a 30-60 secondi indipendentemente dalla crescita esponenziale. Questo schema di backoff offre ai sistemi in errore il tempo di ripristinare, limitando la durata totale dei nuovi tentativi.

Abbinare la strategia di tentativo al tipo di errore.

• Timeout di rete: Riprovare con un breve backoff (l'operazione potrebbe non aver raggiunto il server)
• Errori limite di traffico (429): Riprova dopo il valore di intestazione Riprova dopo o dopo il tempo di reimpostazione del limite di traffico
• Errori del server (5xx): Riprovare con backoff esponenziale, poiché il server potrebbe essere temporaneamente sovraccaricato
• Errori del client (4xx tranne 429): Non riprovare; correggere la richiesta poiché l'errore indica un input non valido
• Errori del limite del governor: Non riprovare nella stessa transazione; accodarsi nuovamente come operazione asincrona con limiti dedicati, ad esempio pubblicando un evento di errore che un abbonato asincrono rielabora con backoff entro limiti di transazione aggiornati

Le strategie di fallback definiscono approcci alternativi quando i metodi principali non riescono, abilitando il funzionamento continuo in condizioni degradate.

• Fonte di dati alternativa: Recuperare i dati dalla sessione cache della piattaforma o da una partizione dell'organizzazione quando l'API in tempo reale non è disponibile. Precompilare la cache durante le operazioni riuscite. La cache fornisce dati obsoleti ma disponibili, il che è meglio di un errore completo per molti casi d'uso.
• Comportamento predefinito: Applicare le regole aziendali standard quando un servizio di personalizzazione o arricchimento non è disponibile. Elaborare con valori predefiniti e segnalare l'arricchimento quando il servizio viene ripristinato. Il comportamento predefinito mantiene la produttività a costo di una precisione ridotta.
• Processo manuale: Abilitare il completamento manuale dell'operazione quando l'automazione non riesce. Fornire un'interfaccia di amministrazione per completare le transazioni bloccate. Il fallback manuale evita la perdita di dati e mantiene la continuità operativa quando l'automazione è compromessa.
• Area di attesa per riprovare: Memorizzazione delle operazioni negli eventi piattaforma o negli oggetti area di attesa personalizzati per l'elaborazione quando un sistema esterno viene ripristinato. La riproduzione degli eventi piattaforma con conservazione standard di 72 ore consente il ripristino dell'abbonato dopo errori temporanei, senza perdita di dati.

Configurare i timeout appropriati per tutte le chiamate di integrazione. Salesforce impone un tempo di chiamata totale massimo di 120 secondi per transazione. Budget questa volta per tutte le chiamate all'interno di una singola transazione per evitare di esaurire il tempo di transazione sulle connessioni sospese.

Considerazioni sulla progettazione del timeout:

• Chiamate sincrone indirizzate all'utente: Utilizzare 5-10 secondi al massimo per mantenere l'interfaccia utente reattiva poiché gli utenti tendono a non attendere più a lungo
• Chiamate asincrone in background: Utilizzare da 30 a 60 secondi per adattare le prestazioni esterne variabili senza che l'utente debba attendere
• Callout di elaborazione batch: Utilizzare tutti i 120 secondi disponibili quando nessun utente è in attesa di una risposta
• Più chiamate per transazione: Tempo totale del budget per tutte le chiamate, ad esempio tre chiamate a 10 secondi ciascuna che consumano 30 secondi del budget di 120 secondi.

Timeout più brevi non vengono eseguiti più rapidamente, consentendo alle strategie di fallback di interagire più rapidamente. Timeout più lunghi aumentano la percentuale di successo dei sistemi esterni lenti ma funzionali. Le considerazioni sul bilanciamento si basano sul fatto che l'utente sia in attesa di una risposta e sulla disponibilità di strategie di fallback.

Progettare una gestione completa degli errori per trasformare gli errori da arresti anomali in degrado gestito:

• Fail fast: Convalidare gli input e le precondizioni ai punti di ingresso. Controllare il consumo limite del governor prima di eseguire operazioni costose. Rilevare immediatamente gli errori anziché propagare lo stato non valido attraverso più livelli di elaborazione. Il rilevamento precoce riduce il raggio di esplosione e semplifica il debug.
• Fallire con grazia: Mantenere le funzionalità dell'utente anche quando le operazioni non riescono parzialmente. Se 3 dei 200 record in batch non superano la convalida, elaborare i 197 record riusciti e segnalare i 3 errori anziché non superare l'intero batch. Per le operazioni batch è meglio un successo parziale che un errore totale.
• Informativo non corretto: Registrare gli errori con ID transazione, contesto utente, parametri di input e traccia dello stack. Un contesto di errore insufficiente è l'ostacolo principale alla risoluzione rapida degli incidenti. Ogni registro errori dovrebbe consentire al risponditore di capire che cosa non è riuscito, perché e come riprodursi.
• Sicurezza degli errori: Assicurarsi che gli errori non compromettano l'integrità o la sicurezza dei dati. Ritirare le transazioni parziali anziché lasciare i dati in uno stato incoerente. Non esporre mai i dettagli degli errori interni agli utenti finali, poiché le tracce dello stack rivelano dettagli di implementazione utili per gli aggressori.

Obiettivo tempo di ripristino definisce il tempo di inattività massimo accettabile dopo il disastro. L'RTO determina le decisioni architetturali relative all'automazione del failover, alla frequenza di backup e agli investimenti nei test di ripristino. Capacità aziendali diverse giustificano investimenti in RTO diversi. Poiché l'RTO è il tempo di inattività che gli utenti sperimentano direttamente, un obiettivo mancato si traduce in interruzioni prolungate e in un'erosione del Customer Trust.

L'RTO varia in base alla capacità aziendale:

Definire l'RTO per funzionalità prima di progettare l'architettura di ripristino di emergenza. RTO definisce la selezione della tecnologia, l'investimento nell'automazione e la cadenza dei test. Obiettivi RTO più aggressivi richiedono maggiori investimenti nell'automazione e nella ridondanza.

Obiettivo punto di ripristino definisce la finestra di perdita di dati massima accettabile misurata nel tempo. RPO determina la frequenza di backup, la strategia di replica e gli schemi di sincronizzazione. Un RPO più rigoroso richiede una replica dei dati più frequente, aumentando la complessità e i costi. Poiché RPO è la perdita di dati assorbita dall'azienda, un obiettivo mancato può significare transazioni perse e lacune non recuperabili nei record.

Bilanciare i requisiti RPO con i costi e la complessità. RPO quasi zero richiede una replica continua dei dati con investimenti significativi nell'infrastruttura. Il backup giornaliero offre un servizio di prenotazione su 24 ore con una complessità minima. La maggior parte delle organizzazioni può tollerare alcune perdite di dati per i dati non finanziari.

La ridondanza dell'infrastruttura piattaforma protegge da errori dell'infrastruttura, ma replica i risultati di errori degli utenti, distribuzioni non corrette e difetti di integrazione, che causano la maggior parte delle perdite di dati. I backup esistono per ripristinare questi errori a livello di applicazione, non per compensare l'affidabilità della piattaforma. Implementare strategie di backup che coprono dati, metadati e file poiché ognuna richiede approcci di backup diversi:

• Backup dei dati: Implementare una strategia di backup completa che affronti sia i dati che i metadati. Esportare i dati degli oggetti critici utilizzando il servizio di esportazione dati nativo: ogni 7 giorni per le versioni Enterprise Edition, Performance Edition e Unlimited Edition; ogni 29 giorni per le versioni Professional Edition e inferiori. I file di esportazione sono disponibili per 48 ore dopo l'invio dell'email di notifica, esclusi i fine settimana, prima dell'eliminazione automatica. Impostare un processo di download automatico in modo che i file non vadano persi definitivamente. Utilizzare l'API dei metadati e Salesforce CLI (recupero progetto Sf) per controllare la configurazione dell'organizzazione, il codice personalizzato e l'automazione dichiarativa in un sistema di controllo sorgente come Git. Considerare il backup dei metadati come parte della pipeline standard di CD/IC. Integrare il backup dei dati con servizi di backup e ripristino dedicati come Own for point-in-time restore, ripristino granulare a livello di record e conservazione oltre la cadenza di esportazione nativa. L'esportazione nativa dei dati non supporta il ripristino puntuale e sono necessari strumenti di terze parti se l'RTO/RPO richiede finestre di ripristino granulari. Testare regolarmente le procedure di ripristino; un backup che non è mai stato ripristinato è un presupposto non testato.
• Backup dei metadati: Controllo della versione di tutti i metadati utilizzando il formato di origine Salesforce DX negli archivi Git. Il controllo della versione dei metadati consente il ripristino rapido della configurazione dopo il danneggiamento o le modifiche non intenzionali. Ogni distribuzione deve essere riproducibile dal controllo sorgente. I metadati in Git forniscono il ripristino nel tempo per la configurazione.
• Backup dei file: Esportare record, allegati e documenti ContentVersion in un'archiviazione esterna. Salesforce funziona meglio per i dati attivi, non per l'archiviazione di file a lungo termine: esportare i file in archivi esterni per la conservazione normativa. Implementare l'esportazione automatica dei file per i requisiti di conservazione normativi che superano le funzionalità della piattaforma.
• Convalida: Ripristinare periodicamente i backup nelle organizzazioni vuote o nei Sandbox per sviluppatori per convalidare sia le procedure che l'integrità del backup. I backup non testati spesso non riescono quando necessario a causa di un ambito di backup incompleto o archivi danneggiati. Pianificare la convalida trimestrale del ripristino per individuare i problemi prima che si verifichino i disastri. Monitorare la freschezza del backup oltre a ripristinare la convalida. Avvisare quando il backup riuscito più recente è precedente alla cadenza prevista, ad esempio quando un'esportazione settimanale non viene completata da più di 8 giorni. Con questa convalida, un processo di backup non riuscito in modo silenzioso viene visualizzato immediatamente anziché al prossimo esercizio.

Progettare una replica adeguata ai requisiti di RPO e multi-organizzazione:

• Cambia acquisizione dati (CDC): Abbonarsi agli eventi di modifica per gli oggetti tracciati. CDC fornisce eventi di creazione, aggiornamento, eliminazione e annullamento dell'eliminazione con valori di campo modificati. Offre una replica quasi in tempo reale con un impegno di sviluppo minimo per gli oggetti supportati, inclusi standard e personalizzati. Soggetto ad allocazione giornaliera della consegna in base alla versione.
• Eventi piattaforma: Architettura degli eventi personalizzata per replicare eventi aziendali e modifiche di stato. Più flessibile del CDC che supporta payload personalizzati e strutture di eventi complesse ma richiede una logica di pubblicazione esplicita nei trigger o nei processi. Lo standard della finestra di replay di 72 ore consente il ripristino da errori temporanei dell'abbonato.
• Replica API pianificata: La replica API di pianificazione è l'estrazione in batch tramite API in blocco 2.0 con una pianificazione fissa. È l'implementazione più semplice con un RPO uguale alla frequenza di estrazione. La replica API pianificata è adatta per i dati non critici in cui l'esecuzione quasi in tempo reale non è necessaria, ad esempio con dati di riferimento o analisi storiche.
• Replica orchestrata da MuleSoft: Per le topologie di replica multi-sistema complesse, MuleSoft Anypoint Platform fornisce orchestrazione, trasformazione e monitoraggio. Il suo utilizzo è appropriato per la replica in Salesforce e in più sistemi esterni, che richiede una logica di instradamento e trasformazione sofisticata.

Testare il ripristino di emergenza con esercitazioni pianificate che convalidano persone, processi e tecnologia insieme:

• Esercizi da tavolo: Il team esamina gli scenari di calamità, discutendo i ruoli e i punti decisionali senza un failover effettivo. Questa attività è a basso costo e rivela lacune procedurali e interruzioni delle comunicazioni. Eseguire regolarmente esercizi da tavolo per mantenere la preparazione del team al cambiamento del personale.
• Failover parziale: - Testare procedure di ripristino specifiche come il ripristino dei metadati dal controllo sorgente, il ripristino dei dati dal servizio di backup o l'aggiornamento Sandbox. Questo convalida le procedure tecniche con un impatto limitato sull'azienda. Eseguire regolarmente la rotazione delle procedure testate per coprire tutte le funzionalità di ripristino ogni anno.
• Esercizio di failover completo: Il failover completo è il failover completo nell'ambiente di ripristino di emergenza con riduzione del traffico di produzione. Fornisce la massima confidenza ma richiede coordinamento aziendale e comunicazione degli utenti. Eseguire questo esercizio ogni anno per i sistemi critici. L'esercizio di failover completo convalida l'intera funzionalità di ripristino, incluse le procedure di cutover e la comunicazione con l'utente.

Documentare le lezioni apprese dopo ogni esercitazione. Aggiornare i runbook in base ai risultati. Le funzionalità di ripristino possono peggiorare man mano che i team cambiano e le soluzioni evolvono. Considerare la documentazione di DR come artefatti viventi che richiedono una manutenzione regolare anziché come prodotti consegnati una tantum.

La continuità operativa si estende oltre il ripristino tecnico per includere persone, processi e dipendenze dei fornitori:

• Disponibilità del team: Documentare le procedure di inoltro al livello superiore e il personale di backup per i ruoli critici. Assicurarsi che non esista un singolo punto di errore in Knowledge operativo. I soccorritori principali potrebbero non essere disponibili durante i disastri, il che rende il personale di backup fondamentale.
• Procedure di comunicazione: Definire le modalità di comunicazione degli incidenti a utenti, clienti e dirigenti. Stabilire canali di comunicazione che funzionino quando gli strumenti principali (ad esempio, pagine di stato esterne o sistemi di notifica SMS), incluso Salesforce stesso, non sono disponibili.
• Dipendenze del fornitore: Mappare le dipendenze dei fornitori esterni critiche per il funzionamento della soluzione. Documentare i percorsi di inoltro al livello superiore e gli SLA contrattuali per ogni fornitore critico, inclusi Salesforce, i partner integrazione e i fornitori di pacchetti ISV. È possibile capire, ad esempio, quali fornitori offrono assistenza 24 ore su 24, 7 giorni su 7, e quali solo in orario di ufficio influiscono sui tempi di ripristino.
• Obblighi normativi: Identificare i requisiti di notifica attivati da interruzioni estese. I servizi finanziari, l'assistenza sanitaria e i contratti governativi spesso richiedono la notifica degli incidenti entro intervalli di tempo specifici. La non conformità può creare rischi normativi e legali, entrambi con un impatto disastroso.

Definire un modello di salute che aggrega più segnali nello stato di integrità generale del sistema. I modelli sanitari mostrano rapidamente lo stato operativo, senza richiedere l'analisi di metriche dettagliate. Ad esempio:

Progettare cruscotti digitali di salute che mostrano immediatamente lo stato operativo.. Lo stato di salute guida la risposta operativa, incluse le normali operazioni in stato verde, il monitoraggio intensificativo in stato giallo e la risposta attiva agli incidenti in stato rosso.

I segnali di stato della piattaforma (precedentemente descritti in Monitoraggio dello stato della piattaforma) indicano quando l'infrastruttura Salesforce è degradata, ma non le prestazioni della propria soluzione.

Aumentare questi segnali con l'osservabilità specifica della soluzione:

• Monitoraggio evento: Monitoraggio evento include registri dettagliati che acquisiscono chiamate API, visualizzazioni pagina, esportazioni di rapporti, attività di accesso ed esecuzione Apex. Gli oggetti EventLogFile consegnano registri con frequenza 24 ore (giornaliera) o 1 ora: la consegna oraria richiede il componente aggiuntivo Monitoraggio evento o Salesforce Shield. La conservazione è configurabile fino a 365 giorni tramite Imposta, ma la conservazione estesa richiede Salesforce Shield o il componente aggiuntivo Monitoraggio evento. Senza un componente aggiuntivo, i file di registro vengono conservati per 1 giorno. Instradare gli eventi a un sistema SIEM (Security Information and Event Management) esterno o a una piattaforma di aggregazione dei registri per la correlazione, l'avviso e la conservazione oltre i limiti nativi. Utilizzare Monitoraggio evento per rilevare schemi di consumo API anomali, identificare processi Apex in fuga e controllare l'accesso ai dati in ambienti regolamentati.
• Centro scala: Scale Center offre una visibilità a livello di transazione sulle operazioni di lunga durata, sulle dispute per il blocco delle righe e sulle transazioni che richiedono un uso intensivo delle risorse. Scale Center consente agli architetti di identificare i rischi di affidabilità derivanti da schemi di transazione specifici prima che causino incidenti indirizzati agli utenti. Le revisioni settimanali possono rivelare opportunità di ottimizzazione.
• Proactive Monitoring: Proactive Monitoring consente una valutazione continua dello stato dell'organizzazione, evidenziando i rischi di prestazioni e scalabilità. Proactive Monitoring fornisce avvisi sui picchi di limite delle richieste API, sugli errori di esecuzione Apex simultanei, sui problemi di limite delle righe SOQL e sulle tendenze del consumo di memoria. È disponibile per i clienti con diritto Firma riuscita (in precedenza Supporto firma), non è una funzione self-service inclusa nelle versioni standard.

Monitorare le prestazioni delle applicazioni dal punto di vista dell'utente anziché dal punto di vista dell'infrastruttura:

• Monitoraggio utente reale (RUM): Misurare l'esperienza utente effettiva tramite strumenti di analisi o personalizzati di Experience Cloud. RUM acquisisce la latenza reale, che riflette le condizioni effettive della rete, le prestazioni del dispositivo e la distribuzione geografica. Il monitoraggio sintetico non può replicare questa variabilità.
• Monitoraggio sintetico: Eseguire transazioni automatiche periodicamente da più posizioni per convalidare la disponibilità e le prestazioni. Il monitoraggio sintetico rileva i problemi prima che gli utenti li segnalino. Implementare il monitoraggio sintetico utilizzando Apex pianificato, eseguendo operazioni critiche e creando rapporti sui risultati con Eventi piattaforma.
• Tracciamento delle transazioni: Strumentazione di operazioni complesse in più fasi per acquisire le tempistiche per ogni fase. Quindi, identificare la fase del flusso di lavoro in cinque fasi che introduce la latenza. Non considerare l'intero flusso come scatola nera. La tempistica a livello di fase rivela le opportunità di ottimizzazione invisibili nelle metriche aggregate.

Monitorare tutte le integrazioni esterne utilizzando percentuali di errore, percentili di latenza e produttività. Gli errori di integrazione sono una delle principali cause di incidenti di affidabilità:

• Percentuale di errori: percentuale di chiamate che restituiscono errori (target: <1% per un'integrazione sana)
• Latenza: il tempo di risposta misurato a p50, p95, p99 (impostare SLO per integrazione in base al budget di timeout)
• Timeout rate: percentuale di superamento del timeout configurato (target: <0,1%)
• Stato interruttore - Lo stato aperto indica un guasto prolungato che richiede attenzione immediata
• Profondità dell'area di attesa: per le integrazioni asincrone, l'area di attesa in crescita indica che l'elaborazione è in ritardo rispetto al tasso di produzione

Registrare tutte le chiamate di integrazione con ID richiesta, endpoint, codice di risposta e durata. Questi dati consentono un'analisi rapida delle cause principali quando gli errori di integrazione influiscono sull'affidabilità. I registri di integrazione devono consentire l'aggregazione e l'analisi delle tendenze.

Progettare avvisi sui problemi prima che gli utenti siano interessati, abilitando risposte proattive:

• Avvisi fruibili: Ogni avviso ha un'azione di risposta definita e un risponditore assegnato. Gli avvisi senza una risposta chiara creano stanchezza e oscurano i segnali critici. La progettazione degli avvisi deve riguardare chi risponde, cosa controlla e come corregge.
• Urgenza appropriata: Pagina personale su chiamata per gli errori che interessano gli utenti. Inviare un'email per segnalare un peggioramento delle prestazioni. Includere i problemi in un rapporto giornaliero per acquisire le tendenze. L'urgenza non corrispondente crea stanchezza da eccessivo inoltro al livello superiore o incidenti mancati da sottoinoltro al livello superiore.
• Notifiche ricche di contesto: Includere la soglia superata, il valore corrente, la tendenza recente e un link a un cruscotto digitale o runbook pertinente. Consentire ai soccorritori di iniziare immediatamente la diagnosi senza raccogliere contesto. Ogni avviso deve includere informazioni sufficienti per il triage senza ulteriori query.
• Soppressione della tempesta: Quando più sistemi non funzionano contemporaneamente, eliminare gli avvisi ridondanti. Un avviso che indica un errore della piattaforma di integrazione è più fruibile di 50 singoli avvisi di errore di integrazione che oscurano la causa principale.

Il rilevamento dell'anomalia identifica schemi insoliti e può indicare problemi emergenti invisibili agli avvisi di soglia statici:

• Anomalie dei volumi: I volumi delle transazioni significativamente superiori o inferiori agli schemi giornalieri previsti possono indicare processi in fuga o problemi di accesso degli utenti.
• Anomalie del tasso di errore: I tassi di errore elevati rispetto ai valori di riferimento della stessa ora della scorsa settimana rilevano un deterioramento graduale prima che si verifichi una violazione della soglia.
• Anomalie di latenza: I tempi di risposta che aumentano su più giorni indicano la saturazione della capacità o la regressione delle prestazioni.
• Anomalie comportamentali: Schemi di accesso insoliti, picchi di utilizzo API imprevisti e processi batch eseguiti al di fuori delle finestre pianificate possono indicare un uso sospetto.

Per i clienti con diritto Signature Success, Proactive Monitoring fornisce il rilevamento delle anomalie a livello di piattaforma senza configurazione aggiuntiva. Integrarlo con il rilevamento delle anomalie specifico dell'applicazione per gli SLI personalizzati esportati in piattaforme di analisi esterne. Utilizzare i segnali di anomalia per guidare l'indagine anziché attivare un inoltro immediato al livello superiore, poiché il rilevamento dell'anomalia ha percentuali di falsi positivi più alte rispetto agli avvisi di soglia.

Utilizzare questo elenco di controllo durante le revisioni dell'architettura, prima della distribuzione in produzione e periodicamente per una valutazione continua dell'affidabilità.

Obiettivi di affidabilità e SLO

• Definire SLO per tutti i flussi utente critici prima dell'inizio della progettazione
• Stabilire SLI misurabili legati all'esperienza degli utenti, non solo alle metriche dell'infrastruttura
• Impostare obiettivi di disponibilità realistici basati sull'analisi dell'impatto aziendale, non su obiettivi arbitrari
• Assicurarsi che gli SLO delle soluzioni siano meno rigorosi degli SLA della piattaforma per fornire il budget degli errori
• Obiettivi di disponibilità dei documenti e logica nei record decisione architettura

Architettura High Availability

• Ridondanza di progettazione a livello di dati, applicazioni e integrazione
• Monitoraggio dello stato della piattaforma tramite Trust.salesforce.com e l'API dello stato dell'istanza
• Implementare controlli dello stato delle applicazioni indipendentemente dallo stato della piattaforma
• Considerare l'architettura multi-organizzazioni solo quando i requisiti aziendali giustificano chiaramente la complessità
• Progettare un failover automatico con runbook testati per schemi multi-organizzazione

Scalabilità e pianificazione della capacità

• Progettare le transazioni completando entro il 70% dei limiti del governor in condizioni di carico normale
• Implementare schemi di blocco in tutti i trigger Apex, le classi batch e le integrazioni
• Utilizzare l'elaborazione asincrona per le operazioni che superano i limiti sincroni
• Inserimento in batch di tutte le integrazioni API anziché effettuare chiamate di singoli record
• Eseguire test di carico con volumi di dati su scala di produzione prima della distribuzione
• Monitorare l'utilizzo della capacità tramite l'API OrgLimits o Apex personalizzato e avvisare quando il consumo si avvicina al limite operativo del 70%
• Requisiti di capacità del progetto basati sulle aspettative di crescita a 12 mesi
• Partizionare i dati a volume elevato per data, tipo di record o titolare per abilitare l'elaborazione parallela quando i volumi superano i limiti sequenziali

Tolleranza e resilienza ai guasti

• Progettare un degrado armonioso con livelli di criticità delle funzioni definiti
• Implementare gli interruttori automatici per tutte le integrazioni di sistemi esterni
• Applicare una logica di tentativo con backoff esponenziale per errori temporanei
• Configurare i timeout appropriati al tipo di operazione (5–10 secondi rivolti all'utente, 30–60 secondi asincroni)
• Progettare strategie di fallback utilizzando cache piattaforma e schemi basati sull'area di attesa
• Implementare la gestione strutturata degli errori con un contesto diagnostico sufficiente

Ripristino di emergenza e continuità operativa

• Definire RTO e RPO per funzionalità aziendale prima della progettazione
• Implementare il backup automatico per dati, metadati (controllo sorgente) e file
• Convalida trimestralmente le procedure di ripristino del backup in ambienti non di produzione
• Monitorare l'aggiornamento del backup e l'avviso quando un backup pianificato è scaduto
• Progettare una strategia di replica dei dati corrispondente ai requisiti RPO
• Eseguire test di ripristino di emergenza ogni anno (trimestrale da tavolo)
• Documentare le procedure di continuità operativa, inclusi i percorsi di inoltro al livello superiore dei fornitori

Monitoraggio e osservabilità

• Definire il modello sanitario aggregando i segnali di servizio, integrazione, dati e capacità
• Abbonamento alle notifiche sullo stato della piattaforma per l'istanza di Salesforce
• Implementare il monitoraggio degli utenti reali per i flussi Experience Cloud critici
• Monitoraggio dello stato dell'integrazione con percentuale di errore, latenza e stato dell'interruttore
• Progettare avvisi fruibili con procedure di risposta e titolarità definite
• Instradamento dei dati di Monitoraggio evento a piattaforme esterne per la conservazione e l'analisi a lungo termine
• Utilizzare Proactive Monitoring and Scale Center per una valutazione continua del rischio di affidabilità
• Applicare il rilevamento dell'anomalia per schemi di volume, tasso di errore e latenza per rilevare il degrado che le soglie statiche non rispettano

Condividere i propri commenti sul framework ben progettato.