Affidabilità - Schemi di ripristino di emergenza | Schemi |

Affidabilità - Schemi di ripristino di emergenza

Ulteriori informazioni su Affidabilità ben progettata → Ripristino e continuità operativa

Schemi

Dove cercare	Che bell’aspetto
Strategia di backup dei dati	✅ Esportazioni automatiche settimanali o mensili utilizzando il servizio di esportazione dati o un servizio di backup e ripristino dedicato (ad esempio Own). La frequenza di esportazione corrisponde ai requisiti RPO. Dati di oggetti critici esportati in archivi di oggetti esterni dove necessario.
Strategia di backup dei metadati	✅ Tutti i metadati con versione in Git utilizzando il formato di origine Salesforce DX. Modifiche dei metadati distribuite solo dal controllo sorgente. La pipeline CI/CD può ricreare qualsiasi ambiente dal repository. Ripristino punto nel tempo disponibile tramite la cronologia Git.
Strategia di backup dei file	✅ ContentVersion record, allegati e documenti esportati in memoria esterna nei tempi previsti. Esportazione automatica dei file per i requisiti normativi di conservazione. Sistema di archiviazione esterno per i file precedenti alle esigenze operative aziendali.
Convalida del backup	✅ esercitazioni trimestrali di ripristino in ambienti Sandbox Completi o Developer. Ripristino delle procedure documentate nei runbook con istruzioni dettagliate. Il ripristino del test convalida l’integrità e la completezza del backup prima che si verifichino i disastri.
Pianificazione dei test di ripristino	✅ Test trimestrali di ripristino parziale (metadati, oggetti specifici, sottoinsiemi di file). Esercitazione annuale di recupero completo con ripristino completo dell’ambiente. Lezioni apprese documentate e runbook aggiornati dopo ogni test.
Servizio di backup di terze parti	✅ Backup automatico con funzionalità di ripristino point-in-time. Contratto sul livello di servizio che definisce RPO/RTO. Verifica automatica giornaliera del completamento del backup. Ridondanza geografica con backup archiviati in più regioni.
Oggetti e campi personalizzati	✅ Oggetti personalizzati inclusi nelle esecuzioni pianificate del servizio di esportazione dati, con i valori dei campi formula e riepilogo di roll-up ricalcolati anziché esportati (non esiste un valore memorizzato da estrarre) e i file binari o allegati gestiti tramite un percorso di esportazione separato. Tipi di campi complessi e relazioni di ricerca documentati e testati nella sequenza di ripristino.
File e allegati	✅ oggetti ContentDocument e ContentVersion esportati con file binari. Librerie di documenti di cui è stato eseguito il backup, incluse le strutture delle cartelle e le autorizzazioni. I file esportati mantengono la cronologia delle versioni per i tipi di documenti critici.
Strategia di aggiornamento Sandbox	✅ Organizzazione di produzione aggiornata al Sandbox Completo trimestralmente per il test del carico e la convalida del ripristino di emergenza. Aggiornamento Sandbox utilizzato come test della procedura di ripristino. Mascheramento dei dati applicato dopo l’aggiornamento per proteggere i dati sensibili negli ambienti di test.
Monitoraggio e avviso del backup	✅ Avvisi automatici quando i backup pianificati non riescono o sono in ritardo. Cruscotto digitale che mostra la percentuale di successo dei processi di backup, il tempo di completamento e le tendenze del volume di dati. Inoltro al livello superiore su chiamata per errori di backup che superano la finestra di ritardo accettabile.

Anti-schemi

Dove cercare	Che brutto aspetto
Strategia di backup	⚠️ Nessun backup automatico configurato, basato solo sui backup dell’infrastruttura della piattaforma. Servizio di backup di terze parti configurato ma mai testato: i backup possono essere danneggiati o incompleti. Esportazioni manuali di Data Loader basate sui backup (esecuzione incoerente, copertura incompleta, nessuna automazione).
Controllo delle versioni dei metadati	⚠️ Modifiche dei metadati distribuite tramite Serie di modifiche senza controllo sorgente. Nessun repository Git per la cronologia dei metadati. Impossibile ripristinare il ripristino nel tempo: impossibile ripristinare l’ultima configurazione buona nota dopo modifiche distruttive.
Convalida del backup	⚠️ Backup configurati ma mai ripristinati nell’ambiente di test. Il primo tentativo di ripristino si verifica durante il disastro effettivo che rivela un ambito incompleto o archivi danneggiati. Procedure di backup documentate ma non testate dal personale di backup.
Ambito di backup	⚠️ Presupponendo che il servizio di esportazione dati acquisisca tutto quando i valori dei campi formula e riepilogo di roll-up non vengono mai esportati (ricalcolati dinamicamente, non memorizzati) e i binari dei file o degli allegati richiedono una gestione separata, lasciando vuoti scoperti solo al ripristino.
Procedure di recupero	⚠️ Runbook di ripristino contiene fasi obsolete dell’architettura di 2 anni. Procedure di recupero testate da un singolo esperto che nel frattempo ha lasciato la società. Procedure manuali così complesse che l’esecuzione sotto stress è soggetta a errori.
Frequenza di backup	⚠️ Dati di transazione critici di cui viene eseguito il backup settimanale quando il requisito aziendale è un contratto di servizio su 24 ore. Frequenza di backup non allineata alla criticità aziendale - stessa pianificazione per tutti i dati indipendentemente dall’importanza. Pianificazione del backup non riuscita a causa della mancanza di monitoraggio e avviso.
Conformità normativa	⚠️ Conservazione dei backup più breve di quanto richiesto dal regolamento. Ad esempio, la documentazione di conformità HIPAA (polizze, analisi dei rischi, BAA, record violazioni) è stata eliminata prima della conservazione di sei anni ai sensi del §164.316 o i record di controllo finanziario gestiti da SOX sono stati eliminati prima della conservazione di sette anni. Lacuna di conformità rilevata durante il controllo.
Memoria file	⚠️ File di grandi dimensioni archiviati in Salesforce senza strategia di archiviazione. La memoria file cresce fino a quando l’organizzazione non si avvicina al limite. Nessun backup dei record ContentVersion - file persi se l’organizzazione è danneggiata. Affidarsi agli utenti per conservare copie personali di file critici.
Test Sandbox	⚠️ Sandbox Completo mai aggiornato dalla produzione - ambiente di test selvaggiamente diverso dalla produzione. Volume di dati nell’ambiente Sandbox dell’1% della produzione che impedisce una convalida realistica del ripristino. L’aggiornamento del Sandbox viene trattato come inconveniente anziché come opportunità di convalida del ripristino di emergenza.
Monitoraggio	⚠️ I processi di backup non riescono silenziosamente senza alcun avviso. Scoprire gli errori di backup settimane dopo durante il disastro quando è necessario un backup. Nessun cruscotto digitale che mostra le tendenze di esito positivo del processo di backup. Lo stato del servizio di backup viene monitorato solo quando arriva la fattura.
Chiavi di crittografia	⚠️ Considerare i dati crittografati da Shield come sicuri senza proteggere il materiale della chiave: la rotazione delle chiavi da sola lascia intatti i dati precedenti, ma la distruzione di un segreto tenant (crypto-shred) o la perdita di Bring Your Own Key o del materiale della chiave solo cache rende i dati crittografati irrecuperabili in modo permanente. La gestione delle chiavi non è inclusa nelle procedure di ripristino.
Dipendenze tra organizzazioni	⚠️ Backup dell’organizzazione principale da sola quando la soluzione dipende da applicazioni connesse, integrazioni esterne o SSO: i segreti delle applicazioni connesse, le autorizzazioni denominate e OAuth e i token di autenticazione esterni non vengono conservati da un ripristino di dati e metadati e devono essere riconfigurati e riautorizzati prima che un’organizzazione recuperata possa eseguire l’autenticazione in sistemi esterni. Quando SSO esterno è l’unico percorso di accesso, un provider di identità non disponibile blocca l’accesso anche a un’organizzazione completamente ripristinata.

Schemi

Dove cercare	Che bell’aspetto
Definizione obiettivo tempo di recupero (RTO)	✅ RTO definito in base alla funzionalità aziendale anziché uniforme in tutta l’organizzazione. Operazioni critiche per il reddito: da minuti a 1 ora. Servizi rivolti ai clienti: 1-4 ore. Strumenti interni: 4-24 ore. Rapporti storici: giorni. RTO documentati con l’approvazione degli stakeholder aziendali.
Definizione obiettivo punto di ripristino (RPO)	✅ RPO definito in base alla perdita di dati accettabile per capacità. Transazioni finanziarie: RPO quasi zero (secondi, replica asincrona basata sugli eventi). Record cliente: quasi zero (minuti tramite CDC). Dati Analytics: ore (sincronizzazione pianificata). Stato del flusso di lavoro temporaneo: giorni (non è necessaria alcuna replica).
Disponibilità e ruoli del team	✅ Personale principale e di backup documentato per tutti i ruoli critici. Nessun singolo punto di errore in Knowledge operativo. Albero di inoltro al livello superiore che definisce il soccorritore principale, il primo backup, il secondo backup. Informazioni di contatto mantenute nel sistema accessibile quando Salesforce non è disponibile.
Procedure di comunicazione	✅ Piano di comunicazione degli incidenti che definisce chi notifica utenti, clienti, dirigenti. Pagina di stato esterna ospitata all’esterno di Salesforce per la comunicazione degli utenti durante i guasti della piattaforma. Sistema di notifica SMS per il team su chiamata quando gli strumenti di comunicazione principali non sono disponibili. Intervalli di tempo di inoltro al livello superiore documentati (quando passare dal team al responsabile al dirigente).
Mappatura delle dipendenze fornitore	✅ Tutti i fornitori esterni critici documentati, inclusi Salesforce, partner integrazione, fornitori di pacchetti ISV. SLA del fornitore e finestre di assistenza documentate (24/7 vs solo orario di ufficio). Contatti e procedure di inoltro al livello superiore del fornitore documentati. Opzioni del fornitore alternative identificate per le dipendenze critiche.
Obblighi di notifica normativi	✅ Requisiti obbligatori di notifica degli incidenti documentati per settore (servizi finanziari, assistenza sanitaria, governo). Tempi di notifica definiti in modo da corrispondere alla finestra di tempo richiesta da ogni regolamento. Matrice di responsabilità che definisce chi invia le notifiche a quali organismi di regolamentazione. Modelli preparati per una notifica normativa rapida.
Analisi dell’impatto aziendale	✅ Ogni funzionalità aziendale classificata per impatto sul reddito, impatto sugli utenti e rischio normativo. Assegnazione di priorità al ripristino in base alla classificazione dell’impatto sul business. Risorse allocate al ripristino di emergenza in proporzione alla criticità aziendale. Analisi dell’impatto rivista ogni anno man mano che le priorità aziendali si evolvono.

Anti-schemi

Dove cercare	Che brutto aspetto
Definizione RTO/RPO	⚠️ “Il sistema deve essere affidabile” senza obiettivi misurabili per RTO/RPO. RTO/RPO definito dal team IT senza l’input degli stakeholder aziendali. Obiettivi uniformi in tutte le funzionalità ignorando le differenze di criticità (“tutto richiede un tempo di attività del 99,999%”).
Preparazione del team	⚠️ Un singolo amministratore Salesforce conosce le procedure di ripristino di emergenza senza documentazione o personale di backup. La rotazione su chiamata include il personale che non ha mai eseguito procedure di ripristino. I soccorritori principali non sono disponibili durante il disastro (vacanze, malattia, compagnia che ha lasciato l’azienda).
Pianificazione della comunicazione	⚠️ Nessun piano di comunicazione - scoprire la necessità di informare gli utenti dopo l’incidente già in corso. Pagina di stato ospitata in Salesforce non disponibile durante il guasto di Salesforce. Ore di attesa per informare i dirigenti durante il tentativo di ripristino.
Dipendenze del fornitore	⚠️ Ignaro dei termini del contratto sul livello di servizio del fornitore fino a quando non si verifica il disastro e in attesa di assistenza 24 ore su 24, 7 giorni su 7 dal fornitore con copertura solo in orario di ufficio. Nessun referente di inoltro al livello superiore del fornitore documentato. Provider di pacchetti ISV richiesto per il ripristino ma la società non è più in attività.
Requisiti normativi	⚠️ Ignaro delle leggi obbligatorie di notifica delle violazioni. Scoprire l’obbligo di notifica 24 ore dopo che sono trascorse 48 ore. Nessun modello preparato - stesura di notifiche normative durante la risposta agli incidenti con il tempo di conformità.
Assegnazione di priorità al ripristino	⚠️ Tentare di ripristinare tutte le funzionalità contemporaneamente durante il disastro anziché assegnare la priorità alle operazioni critiche per il reddito. Dedicare 8 ore al ripristino della funzionalità di creazione di rapporti interni prima di affrontare il sistema degli ordini indirizzato ai clienti.
Test e esercitazioni	⚠️ Piano di continuità aziendale mai testato attraverso esercitazioni. Presupponendo che le procedure documentate funzionino sotto stress senza convalida. Esercizi da tavolo evitati a causa della “mancanza di tempo” nonostante le giornate trascorse a riprendersi da problemi non rilevati durante disastri effettivi.
Trasferimento Knowledge	⚠️ Disaster recovery Knowledge concentrato in un architetto senior che non ha documentato nulla. Nuovi membri del team inseriti senza formazione per il ripristino di emergenza. Presupponendo che tutti sappiano cosa fare durante i disastri senza un addestramento esplicito o esercitazioni.
Convalida del presupposto	⚠️ Le procedure di ripristino presumono che il backup sia accessibile entro 15 minuti, ma il recupero del backup dalla cella frigorifera richiede 8 ore. Presupponendo che il team sia disponibile entro 30 minuti ma non siano definite procedure di rotazione su chiamata o di inoltro al livello superiore. Stime del tempo di recupero basate su ipotesi ottimistiche mai convalidate tramite test.

Schemi

Dove cercare	Che bell’aspetto
Allineamento dell’architettura RTO	✅ Le decisioni di architettura corrispondono agli impegni degli RTO. Minutes RTO richiede il failover automatico e l’hot standby. Hours RTO richiede il ripristino con script e lo standby a caldo. Days RTO accetta il ripristino manuale dal backup a freddo. Evitare l’eccesso di ingegneria laddove il business non giustifica la complessità.
Strategia di replica RPO	✅ Il metodo di replica corrisponde alla destinazione RPO. RPO quasi zero: streaming di eventi asincroni tramite Eventi piattaforma su ogni salvataggio di record (secondi di ritardo di propagazione, consegna almeno una volta). Minuti RPO: Modificare la replica asincrona Acquisizione dati. Ore RPO: estrazione API batch pianificata. Days RPO: backup manuale con pianificazione fissa.
Test RTO	✅ procedure di recupero testate in condizioni temporizzate. RTO effettivo misurato durante le esercitazioni di ripristino di emergenza. Divari tra RTO target e RTO raggiunto identificati e corretti. RTO raggiungibile dal personale di backup, non solo dagli esperti principali.
Convalida RPO	✅ Perdita di dati misurata durante i test di ripristino. RPO effettivo rispetto al target durante le esercitazioni. Ritardo di replica monitorato continuamente in produzione. Avvisi configurati quando la replica non rientra nell’impegno RPO.
RTO/RPO specifico della capacità	✅ Capacità aziendali diverse hanno target RTO / RPO diversi che riflettono la criticità aziendale. Flusso ordine di e-commerce: RTO di 15 minuti, RPO quasi zero (giustifica l’attivazione-passiva multi-organizzazione). Knowledge Base interna: RTO di 8 ore, RPO di 24 ore (giustifica il ripristino manuale dal backup).
Analisi costi-benefici	✅ obiettivi RTO/RPO bilanciati con i costi di implementazione. Obiettivi più rigorosi richiedono investimenti in aumento esponenziale. Caso aziendale documentato che mostra il costo del tempo di inattività che giustifica l’investimento nel ripristino di emergenza. L’esame annuale conferma il continuo allineamento tra investimento e valore aziendale.
Allineamento SLA	✅ I target RTO/RPO della soluzione considerano i livelli di riferimento degli SLA della piattaforma. La soluzione può solo fornire un RTO migliore rispetto alla base di riferimento della piattaforma con architettura multi-organizzazioni. Obiettivi realistici impostati considerando le funzionalità della piattaforma come base.
Monitoraggio delle capacità di ripristino	✅ Monitoraggio continuo della valuta di backup (età del backup rispetto al target RPO). Avviso quando il backup è in ritardo rispetto alla pianificazione. Convalida automatica che l’infrastruttura di ripristino (organizzazione secondaria, memoria esterna) è operativa.
Ripristino automatico o manuale	✅ Gli obiettivi RTO aggressivi (minuti) richiedono il failover automatico con un intervento umano minimo. I target RTO moderati (ore) consentono il ripristino dello script con l’iniziazione umana. Gli obiettivi RTO ridotti (giorni) accettano il ripristino manuale seguendo procedure documentate.

Anti-schemi

Dove cercare	Che brutto aspetto
Obiettivi non realistici	⚠️ Impegno per un RTO di 15 minuti con procedure di ripristino manuali che richiedono 4 ore per essere eseguite. RPO zero promettente senza infrastruttura di replica sincrona. Obiettivi RTO impostati dall’IT senza supporto architettonico.
Disallineamento dell’architettura	⚠️ Impegno RTO di 30 minuti ma nessuna procedura automatica di failover e ripristino sono interamente manuali. Impegno RPO zero ma solo backup giornalieri configurati. Obiettivi aggressivi senza investimenti corrispondenti in automazione e ridondanza.
Target non testati	⚠️ RTO mai convalidato attraverso esercizi di ripristino di emergenza temporizzati. Presupponendo un RTO di 2 ore ottenibile ma mai effettivamente ripristinabile in base a vincoli di tempo. Scoprire durante un disastro reale che l’RTO documentato di 4 ore richiede in realtà 18 ore.
Obiettivi uniformi	⚠️ Tutte le funzionalità assegnate allo stesso RTO/RPO indipendentemente dalla criticità aziendale. Sistema di creazione di rapporti batch interni progettato per la disponibilità di cinque-nove elementi mentre l’e-commerce critico per il reddito ha lo stesso target. Massicci sovrainvestimenti in capacità non critiche e sottoinvestimenti in sistemi critici.
Ignorare le dipendenze	⚠️ RTO presuppone solo il ripristino dell’organizzazione Salesforce ma la soluzione dipende anche dal provider di identità esterno non disponibile. RPO presuppone che il backup dei dati sia sufficiente, ma le credenziali di integrazione e la configurazione non sono supportate. Le stime del tempo di ripristino ignorano il tempo necessario per ripristinare i sistemi dipendenti.
Lacune nella replica	⚠️ Impegno per RPO di 15 minuti ma Modifica acquisizione dati configurato solo per 3 dei 12 oggetti critici. Replica evento piattaforma configurata ma nessun monitoraggio del ritardo di consegna evento. L’infrastruttura di replica si rompe e non viene rilevata per settimane fino al disastro.
Ignoranza dei costi	⚠️ Impegno a cinque-nove disponibilità senza comprendere i costi di implementazione. Obiettivi RTO/RPO impostati senza analisi costi-benefici. Aziende che non sono disposte a finanziare l’infrastruttura necessaria per gli obiettivi già assegnati ai clienti.
Target statici	⚠️ RTO/RPO definito 5 anni fa non è mai stato rivalutato nonostante la crescita del business e l’evoluzione delle priorità. Gli obiettivi continuano invariati man mano che la soluzione si evolve e la criticità cambia. Processo di revisione annuale assente.
Lacune nella documentazione	⚠️ Obiettivi RTO/RPO documentati nel documento di architettura ma non comunicati agli stakeholder aziendali. Azienda non consapevole delle funzionalità di ripristino confermate. Lacuna rilevata quando l’azienda prevede una ripresa di 1 ora ma l’architettura supporta solo l’RTO 24 ore.
Falsa precisione	⚠️ Impegno a una “disponibilità del 99,97%” quando il monitoraggio dell’infrastruttura non può misurare con tale precisione. Obiettivi definiti con falsa precisione che suggeriscono il rigore quando l’analisi sottostante è una stima approssimativa.
Monitoraggio dell’assenza	⚠️ Nessun monitoraggio continuo delle capacità di ripristino. Il backup cade con 2 giorni di ritardo rispetto alla pianificazione violando l’impegno RPO ma senza avvisi. Organizzazione secondaria in architettura attivo-passiva che non riceve aggiornamenti di replica ma controlli dello stato non configurati.
Pianificazione senza esecuzione	⚠️ Bellissimo piano di ripristino di emergenza con obiettivi RTO / RPO aggressivi ma senza automazione, test o procedure convalidate. Piano creato per soddisfare la casella di controllo di conformità ma nessuna realtà operativa dietro gli impegni.

Schemi

Dove cercare	Che bell’aspetto
Ridondanza dei dati	✅ Platform fornisce automaticamente il backup dell’infrastruttura. La replica a livello di applicazione integra il backup della piattaforma quando il business richiede un ripristino più rapido. Modifica acquisizione dati o Eventi piattaforma replicano continuamente i dati critici nell’archiviazione secondaria. La replica consente il ripristino da errori di danneggiamento logico o di configurazione che i backup dell’infrastruttura non possono risolvere.
Ridondanza delle applicazioni	✅ Logica di applicazione stateless che sopravvive agli errori delle singole transazioni. Nessuno stato lato server impedisce la scalabilità orizzontale. Tipi di metadati personalizzati e impostazioni personalizzate per la configurazione sono immediatamente disponibili in tutti i server di applicazioni. Qualsiasi server di applicazioni può elaborare qualsiasi richiesta senza dipendere dallo stato specifico del server.
Ridondanza integrazione	✅ Gli schemi degli interruttori rilevano integrazioni non riuscite. Eventi piattaforma richiede l’area di attesa quando i sistemi esterni non sono disponibili anziché bloccare le operazioni degli utenti. Errori del sistema esterno isolati dalla funzionalità rivolta agli utenti. Più opzioni fornitore esterno identificate per le integrazioni critiche che consentono un rapido passaggio da un fornitore all’altro durante le interruzioni del fornitore.
Schemi multi-organizzazione per carichi di lavoro critici	✅ Schema attivo-passivo: l’organizzazione principale serve tutto il traffico, l’organizzazione secondaria sincronizzata ma inattiva, failover durante il guasto della regione principale. Schema attivo-attivo: entrambe le organizzazioni servono il traffico di produzione in modo continuo, gli utenti allocati per area geografica o unità operativa. Multi-organizzazioni giustificate solo quando l’azienda richiede RPO/RTO oltre le funzionalità della piattaforma.
Sincronizzazione dei dati multi-organizzazioni	✅ Acquisizione dati di modifica offre una replica quasi in tempo reale per i dati critici (15 minuti RPO). Gli eventi piattaforma forniscono lo streaming degli eventi per le transazioni critiche (RPO quasi zero). Replica pianificata API in blocco 2.0 per i dati di riferimento (RPO accettabile su 24 ore). Strategia di risoluzione dei conflitti definita per attivo-attivo quando lo stesso record viene modificato in entrambe le organizzazioni.
Architettura attiva-passiva multi-organizzazioni	✅ L’organizzazione principale nella regione US East serve tutto il traffico di produzione. Organizzazione secondaria in Europa sincronizzata tramite CDC ma inattiva. L’instradamento DNS o il livello di autenticazione indirizza gli utenti all’organizzazione attiva. I controlli automatici dello stato attivano il failover quando l’organizzazione principale non è disponibile per 10 minuti consecutivi.
Architettura attiva multi-organizzazioni	✅ utenti EMEA nell’organizzazione Europa, utenti AMER nell’organizzazione USA in base al campo regione profilo utente. Replica bidirezionale per i dati di riferimento condivisi (account, prodotti). I dati regionali rimangono nelle rispettive organizzazioni (ordini, casi). La risoluzione dei conflitti utilizza last write-wins with regional authority per i dati master dei clienti.
Distribuzione geografica	✅ I data center regionali Hyperforce abilitano la distribuzione geografica. Distribuzione a regione singola con ridondanza gestita dalla piattaforma sufficiente per una disponibilità del 99,9%. Multi-organizzazioni tra regioni considerate solo per requisiti del 99,95% o mandati di residenza dati normativi.
Ridondanza del sistema esterno	✅ API esterne critiche hanno endpoint principali e di failover. L’interruttore passa all’endpoint di failover quando l’elemento principale riscontra errori prolungati. Servizi esterni con ridondanza geografica preferita ai provider di singole regioni per le integrazioni critiche.
Monitoraggio dell’infrastruttura	✅ Trust.salesforce.com monitorato tramite API di stato. Abbonarsi alle notifiche di stato specifiche dell’istanza. La soluzione risponde dinamicamente allo stato di salute della piattaforma riducendo il carico non critico durante il degrado. Scale Center identifica le operazioni che richiedono più risorse prima che influiscano sulla capacità di ridondanza.
Automazione del failover	✅ failover automatico preferito rispetto al manuale per i target RTO aggressivi. I controlli dello stato vengono eseguiti ogni 1-5 minuti per rilevare eventuali errori. La logica decisionale di failover evita i falsi positivi (richiede un errore prolungato, non errori temporanei). Ritiro automatico se anche la destinazione del failover non è sana.
Singoli punti di errore	✅ Revisione dell’architettura identifica tutti i singoli punti di errore. Ogni SPOF identificato è stato valutato per l’impatto sul business e il costo di mitigazione. SPOF ad alto impatto mitigati dalla ridondanza. SPOF a basso impatto accettati con procedure documentate di accettazione e ripristino del rischio.
Test delle funzionalità di ridondanza	✅ Le esercitazioni di failover pianificate convalidano la logica di failover automatica. Sistemi di backup testati sotto carico (non solo in standby caldo inattivo). La capacità dell’organizzazione secondaria ha convalidato la gestione del carico di produzione durante i test attivo-passivo. Le lezioni apprese da ogni test migliorano l’automazione e le procedure.

Anti-schemi

Dove cercare	Che brutto aspetto
Singoli punti di errore	⚠️ L’intera soluzione dipende da una singola API esterna senza fallback. Il provider di dominio personalizzato è SPOF: se il provider non riesce, gli utenti non possono raggiungere Experience Cloud. Singolo account utente integrazione: se disabilitato, tutte le integrazioni non riescono.
Ridondanza non testata	⚠️ Architettura multi-organizzazioni attiva-passiva configurata ma mai testata. L’organizzazione secondaria non viene sincronizzata ma i controlli dello stato non sono configurati. Il primo tentativo di failover si verifica durante un disastro reale che rivela un’organizzazione secondaria danneggiata o non funzionale.
Lacune nella sincronizzazione dei dati	⚠️ Multi-organizzazione attivo-passivo con replica CDC configurata per 5 dei 30 oggetti critici. Il failover si verifica ma all’organizzazione secondaria manca l’80% dei dati richiesti. Monitoraggio del ritardo di replica assente - organizzazione secondaria in ritardo di 3 giorni rispetto all’organizzazione principale ma senza avvisi.
Falsa ridondanza	⚠️ Presupponendo un’architettura multiregione quando entrambe le organizzazioni sono effettivamente ospitate nella stessa regione Hyperforce. API esterne “ridondanti” che utilizzano effettivamente lo stesso provider a monte. Più percorsi di integrazione che attraversano tutti lo stesso singolo punto di errore.
Architettura statale	⚠️ La logica di applicazione dipende dallo stato in memoria che impedisce la scalabilità orizzontale. Il server di un’unica applicazione mantiene tutto lo stato della sessione utente - il riavvio del server disconnette tutti gli utenti. Le risorse statiche memorizzate nella cache dell’applicazione anziché nella cache piattaforma creano incoerenze tra i server.
Nessun interruttore	⚠️ L’integrazione esterna non riesce e ogni transazione attende un timeout completo di 120 secondi. Tutti gli utenti interessati quando un singolo sistema esterno non è disponibile. Nessun isolamento degli errori: un’integrazione non riuscita compromette le prestazioni dell’intera piattaforma.
Solo failover manuale	⚠️ Architettura multi-organizzazioni con solo procedure di failover manuali. Richiede una procedura di 2 ore per avviare il failover mentre l’attività è inattiva. Controlli automatici dello stato non implementati. La decisione di failover richiede l’approvazione dell’esecutivo che ritarda il ripristino.
Errore di pianificazione della capacità	⚠️ Organizzazione secondaria in architettura attivo-passiva dimensionata per il 20% del carico di produzione. Il failover si verifica ma l’organizzazione secondaria non è in grado di gestire l’intero traffico di produzione. Architettura attiva con entrambe le organizzazioni con capacità dell’85% che non lascia ridondanza quando un’organizzazione non riesce.
Spostamento della configurazione	⚠️ Le organizzazioni principali e secondarie divergono nel tempo perché le distribuzioni non sono sincronizzate. Metadati distribuiti al principale ma non al secondario. Il failover rivela che l’organizzazione secondaria esegue una versione di codice vecchia di 6 mesi.
Sovringegneria	⚠️ Architettura multi-organizzazione con replica attivo-attivo per gli strumenti di amministrazione interni utilizzati da 5 persone. Complessità operativa di più organizzazioni non giustificata dalla criticità aziendale. Obiettivo di disponibilità del 99,999% per i rapporti batch accettabile al 99%.
Incomprensione geografica	⚠️ Presupponendo che Hyperforce “multi-regione” fornisca automaticamente funzionalità multi-organizzazione. Non si capisce che una singola organizzazione è sempre in una singola regione e che la multiregione richiede più organizzazioni. Ridondanza basata sulla geografia impossibile con l’architettura a organizzazione singola.
Accoppiamento integrazione	⚠️ Tutte le integrazioni sincrone senza fallback asincrono. L’indisponibilità del sistema esterno blocca le operazioni dell’utente. Nessun meccanismo di attesa: le transazioni non riescono se il sistema esterno è temporaneamente inattivo. Gli utenti non possono procedere quando l’integrazione non è disponibile.