Leggi qui le nostre pianificazioni degli aggiornamenti.

Le soluzioni resilienti mantengono un'alta qualità del servizio anche in caso di errori. Se le prestazioni peggiorano o il servizio viene interrotto, la soluzione viene ripristinata in modo rapido ed efficace.

La resilienza di una soluzione si basa su due qualità chiave:

• Durezza: Quando si verificano problemi, la soluzione li resiste e li sopporta.
• Elasticità: Una volta risolti i problemi, la soluzione torna allo stato o alla forma ideale.

Per progettare la soluzione per la resilienza, è necessario progettare sia per la resistenza che per l'elasticità, garantendo sia la durata che il rapido recupero a fronte di cambiamenti pianificati e non pianificati.

Nei contesti tecnologici, considerare un sistema o una soluzione come un insieme di componenti interdipendenti che si coordinano per raggiungere obiettivi condivisi. Ogni componente potrebbe non funzionare. Problemi all'interno di questi componenti, dal codice e dai difetti di configurazione ai problemi di rete e hardware, possono causare comportamenti imprevisti e indesiderati. Un sistema dimostra un comportamento resiliente quando uno o più componenti si guastano, ma l'intero sistema continua a funzionare o torna rapidamente a uno stato stabile.

Per migliorare la resilienza delle soluzioni Salesforce, si consiglia di concentrarsi su tre abitudini chiave.

• Application Lifecycle Management (ALM): come i team gestiscono il software durante tutto il suo ciclo di vita, dall'ideazione al ritiro
• Risposta agli incidenti: come i team identificano, risolvono e prevengono i problemi che influiscono sulla disponibilità o la sicurezza di un sistema
• Pianificazione della continuità: come i team pianificano che le persone e i sistemi continuino a funzionare quando eventi non pianificati causano problemi

La gestione del ciclo di vita delle applicazioni (ALM, Application Lifecycle Management) è una pratica per la gestione olistica del software in tutto il suo ciclo di vita, dalla creazione al ritiro. ALM è una pietra angolare della resilienza del sistema e comprende persone, processi, strumenti e discipline relativi al ciclo di vita dell'applicazione. Queste discipline includono DevOps e metodologie di consegna, osservabilità, strategie di test, governance e CI/CD.

Quando un'azienda pratica un ALM efficace, i suoi team reagiscono rapidamente ai cambiamenti e le sue applicazioni stanno al passo con l'evoluzione dei requisiti aziendali senza compromettere la stabilità o la qualità.

D'altra parte, senza un'ALM sana, i team faticano in ogni fase del ciclo di vita dell'applicazione.

I sintomi di ALM scarsa includono:

• Cicli di sviluppo lenti e soggetti a errori
• Implementazioni intensive e difficili
• Problemi o bug di elevata gravità rilevati in ambienti di produzione e post-QA
• Agenti AI che hanno allucinazioni o comportamenti incoerenti
• Ritiri frequenti o distribuzioni di hotfix necessari per stabilizzare i rilasci

Poiché ALM riguarda quasi ogni aspetto di una soluzione, stabilire procedure ALM chiare ed efficaci per la soluzione è una parte fondamentale del lavoro architettonico.

Creare procedure ALM migliori concentrandosi su tre aree chiave.

• Gestione dei rilasci: pianificazione, sequenza, controllo e migrazione delle modifiche in ambienti diversi
• Strategia ambientale: una strategia per l'utilizzo e la gestione delle applicazioni negli ambienti di destinazione durante lo sviluppo e i test
• Strategia di segnalazione: definizione dei segnali critici e della strumentazione dell'applicazione utilizzata per rilevare e risolvere i guasti all'interno del sistema prima che si verifichi il degrado
• Strategia di test: i principi e gli standard che guidano la pianificazione e l'esecuzione dei test per valutare il successo delle applicazioni durante i processi ALM

La gestione dei rilasci prevede la pianificazione, la sequenza, il controllo e la migrazione delle modifiche in uno o più ambienti. Un singolo rilascio è un gruppo di modifiche pianificate che un team sposta contemporaneamente in un ambiente di destinazione.

Il rilascio di una modifica a un sistema comporta dei rischi. Se il sistema è in uno stato stabile prima della modifica, passa a un nuovo stato, dove è anche più vulnerabile ai rischi derivanti da modifiche future. Se modifiche future attivano uno stato incontrollato e instabile nel sistema, possono causare un incidente critico. In un'architettura di soluzioni, progettare rilasci resilienti non è solo testare efficacemente singole modifiche. Include anche la pianificazione di come introdurre modifiche ai sistemi e ai relativi utenti in modo sicuro.

Il lavoro svolto dai team dipende da informazioni sul rilascio prevedibili e accurate. Nei processi di gestione e abilitazione del cambiamento, indicare chiaramente quali modifiche possono essere apportate al sistema. Nei processi di gestione e abilitazione dei rilasci, specificare come e con quale frequenza vengono rilasciate le modifiche al sistema.

Anche gli stakeholder aziendali si preoccupano delle informazioni sui rilasci, soprattutto se sono correlate a funzioni o correzioni di bug che richiedono. Per creare Trust nella soluzione e dimostrare valore agli stakeholder, stabilire pianificazioni di rilascio coerenti e chiare e artefatti di rilascio della spedizione stabili.

Per stabilire una gestione dei rilasci efficace per Salesforce:

• Allinearsi strettamente alla governance dell'architettura e dello sviluppo. Assicurarsi che i rilasci siano pianificati con largo anticipo per allinearsi a tutti i forum e i controlli di governance pertinenti. Prima di iniziare lo sviluppo, fare in modo che tutti i casi d'uso Agentforce con priorità vengano rivisti e approvati dal Consiglio AI. Utilizzare gli elenchi di controllo e la documentazione della distribuzione per tenere traccia degli elementi della distribuzione, ad esempio i nomi API degli agenti Agentforce, rispetto alle attività di governance.
• Non utilizzare processi di sviluppo. Questo paradigma riflette le tecnologie più datate e limitate per lo sviluppo e il rilascio. Con Salesforce CLI, i team possono ora adottare funzionalità di sviluppo e rilascio basate sui sorgenti.
• Scegliere il meccanismo di rilascio più stabile possibile. Questo approccio realizza due cose. Innanzitutto, riduce al minimo la durata delle finestre di rilascio e delle interruzioni del servizio. In secondo luogo, consente comportamenti di rilascio altamente controllati e prevedibili. Più stabile è il meccanismo di rilascio, meno è probabile che i rilasci introducano modifiche che richiedono aggiornamenti rapidi o ritiri. In caso di problemi imprevisti, i meccanismi di rilascio stabili consentono anche al personale di assistenza o agli amministratori di sistema di eseguire i rollback in modo più semplice.

I meccanismi di rilascio migliori per il team sono le opzioni più stabili per cui il team ha le competenze richieste. Di seguito sono elencati i meccanismi di rilascio consigliati, elencati in ordine di stabilità. Poiché sono tutti compatibili tra loro, utilizzarne diversi in tandem, se è meglio per la propria azienda.

• Pacchetti sbloccati: i pacchetti sbloccati sono l'artefatto rilascio più stabile. La distribuzione delle modifiche tramite l'installazione di un pacchetto è il modo più rapido e prevedibile per introdurre le modifiche. I pacchetti utilizzano il controllo delle versioni, che consente una gestione efficace delle modifiche e un rollback preciso e intuitivo per l'amministratore di sistema. Inoltre, i pacchetti richiedono una gestione avanzata dei metadati, che può aiutare a identificare precocemente le dipendenze gestite in modo errato. Creano anche pipeline di sviluppo e artefatti controllabili. Vedere Pacchetto.
• DevOps Center: DevOps Center consente ai team di consegna con competenze a basso codice o pro-codice di utilizzare il controllo sorgente, lavorare in collaborazione sulle modifiche e definire percorsi di rilascio comuni. DevOps Center si integra con il controllo sorgente e consente il controllo "point-and-click" delle modifiche e delle distribuzioni.
• Sviluppo e distribuzione dei metadati basati sulla fonte utilizzando Salesforce CLI: se non è possibile utilizzare i pacchetti, utilizzare Salesforce CLI per lo sviluppo e la distribuzione dei metadati basati sulla fonte. Non distribuire i metadati utilizzando il formato package.xml precedente, che segue una struttura diversa rispetto al formato di origine consigliato. Il formato di origine si è evoluto per supportare lo sviluppo di pacchetti, flussi di lavoro di organizzazioni vuote e un tracciamento delle modifiche più dettagliato nei Sandbox. Il formato è più leggibile, consente un maggiore disaccoppiamento dei tipi di metadati complessi e delle dipendenze e offre un controllo molto maggiore sui manifesti di distribuzione.
• Date un nome. Assegnare ai rilasci identificatori chiari per aiutare i team e gli stakeholder a rimanere allineati. In Salesforce, il nome di ogni rilascio principale inizia con "Primavera", "Estate" o "Inverno", seguito dall'anno del rilascio (ad esempio, "Estate '25"). Se non si dispone già di una convenzione di denominazione per definire e organizzare i rilasci nella propria azienda, crearne una e utilizzarla. L'uso di nomi di rilascio chiari semplifica l'organizzazione in ogni fase della pianificazione, dello sviluppo e della consegna, in tutti i sistemi dei team. Utilizzare i nomi dei rilasci nella roadmap per comunicare chiaramente agli stakeholder quali modifiche sono in arrivo e quando. Utilizzare i nomi dei rilasci nella documentazione, nei registri di modifica, nelle descrizioni del lavoro, nei commenti al codice e nei rami del controllo sorgente per poter tracciare e controllare facilmente gli elementi di sviluppo.
• All'interno di un manifesto di rilascio, gestire correttamente le dipendenze. I metadati Salesforce hanno dipendenze incorporate. Un motivo comune per cui le distribuzioni Salesforce non riescono è che le dipendenze non vengono gestite correttamente. La scelta di un meccanismo di rilascio stabile, come descritto in precedenza, può aiutare a esporre le dipendenze gestite in modo errato nelle prime fasi del ciclo di sviluppo. Uno dei motivi principali per cui i pacchetti sbloccati sono il veicolo di rilascio più stabile è la loro forte gestione dei metadati, necessaria per lo sviluppo e la creazione dei pacchetti. Se l'utente o i suoi team di gestione dei rilasci non comprendono le dipendenze incorporate tra i tipi di metadati Salesforce, non sarà in grado di individuare in modo proattivo le combinazioni problematiche nei manifesti di distribuzione e rilascio. Vedere Gestione delle dipendenze.

Gli schemi e antischemi mostrano l'aspetto corretto e inadeguato della gestione dei rilasci per un'organizzazione Salesforce. Utilizzare gli schemi per convalidare i progetti prima della creazione o per identificare i punti del sistema che devono essere sottoposti a refactoring.

Per ulteriori informazioni sugli strumenti Salesforce per la gestione dei rilasci, vedere Salesforce Tools for Resiliency.

Salesforce offre una varietà di ambienti utilizzabili durante i cicli di sviluppo e test delle applicazioni. Una strategia ambientale efficace per Salesforce richiede la comprensione dell'utilizzo degli ambienti e di una buona gestione. In ALM, l'utilità di un ambiente di sviluppo o test dipende dalla fedeltà e dall'isolamento dalla produzione.

Una buona strategia ambientale offre diversi vantaggi.

• Maggiore fedeltà alla produzione
• Configurazioni e arresti dell'ambiente più rapidi
• Maggiore agilità nello sviluppo e nei test
• Maggiore sicurezza in tutta la pipeline
• Meno rumore e conflitti durante le fasi di consegna
• Team di sviluppo più soddisfatti

I team spesso faticano a realizzare questi vantaggi. Le sfide per sfruttare al meglio gli ambienti di sviluppo e la strategia possono provenire da diverse fonti. Una fonte probabile è il tipo di modello di sviluppo seguito dai team.

Nel vecchio approccio di sviluppo basato sull'organizzazione, ogni ambiente doveva svolgere diverse funzioni. Oltre a essere la sede in cui il team svolge i suoi vari tipi di lavoro, doveva essere l'origine degli artefatti rilascio (ovvero i metadati che si desiderava distribuire in un rilascio). Poiché gli ambienti non erano facili da configurare o abbattere, erano spesso sovraffollati e pieni di conflitti di metadati tra i team e non contribuivano in modo significativo alla velocità o alla flessibilità di ALM in generale.

L'utilizzo di un modello di sviluppo basato su sorgente modifica in modo sostanziale la relazione degli ambienti con i rilasci e gli artefatti rilascio. In questo modello, il controllo sorgente è l'origine dei metadati che si desidera rilasciare. Gli ambienti sono solo luoghi in cui i team svolgono il proprio lavoro.

Tuttavia, seguire il modello di sviluppo basato sul sorgente non garantisce da solo una buona strategia ambientale. Anche con il controllo sorgente, i team possono ancora avere difficoltà a impostare le condizioni per testare le integrazioni con i sistemi esterni; configurazioni che dipendono da metadati che non sono nel controllo sorgente, ad esempio pacchetti gestiti o personalizzazioni che dipendono dai dati) e così via. In alcune circostanze, le sfide di un modello basato su origine sono simili alle sfide tipiche di un modello basato su organizzazione.

Per sviluppare una strategia ambientale efficace:

• Adottare un modello di sviluppo e rilascio basato sulla fonte. Smettere di utilizzare i modelli di sviluppo basati sull'organizzazione. Vedere Gestione dei rilasci.) È necessario separare gli ambienti da ciò che viene distribuito per creare una strategia per un ambiente sano e rilasci più sani.
• Comprendere i tipi di lavoro supportati da ogni ambiente. I tipi di ambiente supportati da Salesforce hanno funzionalità e limiti diversi. Quando si progetta la strategia ambientale, considerare ciò che gli ambienti possono e non possono fare. Assicurarsi che i team svolgano il proprio lavoro in un ambiente dotato delle funzionalità necessarie. Per indicazioni, vedere questa panoramica degli ambienti di sviluppo Salesforce e delle relative funzionalità.

Fare riferimento a questa tabella per informazioni sulle funzioni e gli ambienti da utilizzare per diverse operazioni di sviluppo comuni.

Inoltre, tenere presente che per gli agenti Agentforce che utilizzano funzioni come la libreria di dati Einstein, gli articoli Knowledge e i dati non strutturati, i test completi sono limitati a meno che non si disponga di un Sandbox Data 360. È necessario anche un Sandbox Data 360 per garantire condizioni di test accurate.

• Disaccoppiare gli ambienti dagli artefatti rilascio. Non utilizzare lo sviluppo basato sull'organizzazione. Considerare gli ambienti come luoghi in cui il lavoro si svolge per un periodo di tempo fisso. Considerare lo stato dei metadati in un ambiente come separato dagli elementi di rilascio. Se una porzione di codice o configurazione viene "capita" in un ambiente, deve essere assegnata al controllo sorgente, rendendola un artefatto rilascio.

  • Gli ambienti sono effimeri. Creare processi in modo da poterli creare e distruggere il più rapidamente possibile.
  • Gli artefatti resistono. Appartengono al controllo sorgente.

• Disaccoppiare gli ambienti dai percorsi di rilascio. È comune vedere percorsi di rilascio obbligatori che richiedono la distribuzione delle modifiche in ambienti specifici. Spesso questo approccio viene implementato per stabilire un proxy per convalidare la maturità dell'applicazione o la stabilità del rilascio. I team possono utilizzarlo anche per cercare di ridurre al minimo il numero di ambienti in cui devono configurare un'infrastruttura di test complessa. Nei paradigmi basati sulla fonte, si dispone di una maggiore flessibilità nel modo e nella posizione in cui è possibile convalidare e testare le modifiche.

  • Le fasi di rilascio si applicano agli artefatti rilascio, non agli ambienti. Non creare un ambiente solo per "raccogliere" tutte le modifiche in una determinata fase di rilascio. A questo serve il controllo sorgente, in particolare la ramificazione. Utilizzare le strategie di ramificazione nel controllo sorgente per organizzare le modifiche da distribuire a quali ambienti. A seconda del lavoro da eseguire, potrebbe essere necessario distribuire tutti i metadati di un rilascio a un ambiente. La ramificazione consente di eseguire questa operazione. Con alcune eccezioni, ogni ambiente di sviluppo deve essere aggiornato o distrutto non appena viene completato il lavoro pertinente. Assicurarsi di sincronizzare tutte le modifiche ai metadati che avvengono all'interno di un ambiente specifico e che si desidera mantenere nel controllo sorgente.
  • Gli ambienti sono utili tanto quanto la loro fedeltà alla produzione. Ottimizzare i flussi di lavoro o l'automazione di impostazione dell'ambiente in modo da poter demolire o aggiornare gli ambienti il più rapidamente possibile. Considerare qualsiasi configurazione che impedisce di eseguire aggiornamenti di ambiente più rapidi e frequenti come un rischio critico per la resilienza complessiva dei processi ALM. Se sono presenti interventi di riparazione correlati, aggiungerli ai piani e assegnargli la priorità. Esplorare come adottare unità modulari più vagamente accoppiate nel sistema. Consentono ai team di eseguire più tipi di sviluppo nelle organizzazioni vuote e liberano le allocazioni Sandbox per altri lavori. Non dimenticare le funzionalità offerte dalle organizzazioni vuote per testare funzioni che non sono presenti in produzione, sia perché non sono state acquistate licenze per le organizzazioni o non sono state abilitate.
  • Negli ambienti a cui possono accedere gli utenti aziendali o finali, consentire a tali utenti di concentrarsi su ciò che è importante per loro. Non avere ambienti generici e indifferenziati in cui molti gruppi diversi di utenti finali o stakeholder aziendali tentano di svolgere attività correlate all'ALM. Invitare e attivare stakeholder specifici in ambienti specifici per svolgere un lavoro specifico. Valutare attentamente qualsiasi processo che mette gli utenti finali o gli stakeholder aziendali in un ambiente con più dati di quelli supportati da un Sandbox Copia parziale. Assicurarsi che il volume di dati sia necessario per il lavoro da eseguire. Pianificare i test di accettazione utente e i cicli di sviluppo iniziali in modo che si verifichino il più vicino possibile. Ottimizzare tutte le fasi di test per consentire cicli di feedback e iterazioni più rapidi e anticipati per i team di sviluppo e gli utenti finali. Vedere Strategia di test.

• Creare percorsi di rilascio diversi per diversi tipi di modifiche. Non tutte le modifiche richiedono che gli stessi tipi di lavoro ALM vengano completati nello stesso ordine. Fare in modo che gli utenti finali eseguano test di accettazione per modifiche minori ai componenti di backend di un sistema probabilmente non è un buon uso del loro tempo. Tuttavia, l'accettazione da parte degli utenti e i test su larga scala possono essere estremamente utili durante lo sviluppo iniziale di un'applicazione mobile. Identificare i percorsi di rilascio per le diverse categorie di modifiche, ad esempio rischio alto, rischio medio e rischio basso.

  • Rischio elevato: Le modifiche hanno effetto su clienti, partner o tutti gli utenti interni. Le modifiche influiscono sulla sicurezza o sull'integrazione. Le modifiche aggiungono nuove funzionalità complesse.
  • Rischio medio: Le modifiche hanno un impatto superiore a una soglia definita di utenti interni. Le modifiche influiscono sui modelli di dati, sull'automazione che esegue le operazioni sui dati o sull'integrazione.
  • Rischio basso: Ha un impatto diretto inferiore a una soglia definita di utenti interni. Non include modifiche alla sicurezza, ai modelli di dati o alle automazioni che comportano operazioni sui dati o integrazione.

• Non consentire l'esistenza di ambienti sovraffollati. Una mancanza di disciplina nell'assegnazione delle priorità, nella definizione degli ambiti e nella sequenza del lavoro porta inevitabilmente a ambienti di sviluppo sovraccarichi, con volumi di lavoro eccessivi, troppi, troppo diversi. Gli ambienti sovraffollati creano elevati livelli di stress, ambiguità e conflitti tra i team di sviluppo. Inoltre, creano rumore all'interno delle opportunità di sviluppo in corso di realizzazione e ostacolano le attività di controllo della qualità. Oltre a questi impatti negativi, gli ambienti di sviluppo sovraffollati rappresentano gravi minacce per la manutenzione e la sicurezza dell'ambiente. Considerare il sovraffollamento come sintomo di potenziali problemi nei processi ALM. Esaminare eventuali problemi di causa principale e risolverli. Se si continua a riscontrare sovraffollamento, è possibile acquistare ulteriori Sandbox.

L'elenco degli schemi e antischemi per ALM mostra l'aspetto di una gestione dell'ambiente corretta e inadeguata in un'organizzazione Salesforce. Utilizzarli per convalidare i progetti prima di procedere alla creazione o per identificare le aree del sistema che devono essere sottoposte a refactoring.

Per ulteriori informazioni sugli strumenti Salesforce per la gestione dell'ambiente, vedere Salesforce Tools for Resiliency.

Una strategia di segnalazione definisce i segnali critici e la strumentazione dell'applicazione necessari per rilevare, diagnosticare e risolvere i guasti prima che si verifichino nel degrado a livello di sistema. Una strumentazione efficace trasforma le applicazioni da vittime passive di errori in partecipanti attivi alla propria resilienza, in grado di rilevare i problemi, adattare il loro comportamento e coordinare il degrado grazioso quando necessario.

Quando le applicazioni implementano una strumentazione completa, acquisiscono la capacità di autoregolarsi sotto stress, comunicare il proprio stato di salute agli operatori e partecipare a sforzi di ripristino coordinati. Queste funzionalità consentono ai sistemi di mantenere la qualità del servizio anche quando i singoli componenti subiscono difficoltà. D'altra parte, senza una strumentazione adeguata, le applicazioni diventano scatole nere che falliscono silenziosamente fino a quando non compaiono sintomi catastrofici. I team reagiscono ai problemi solo dopo che gli utenti li hanno segnalati e la risoluzione dei problemi diventa un esercizio di archeologia anziché di osservazione.

• Rilevamento di errori nell'applicazione. Le applicazioni devono dotarsi di strumenti per rilevare e rispondere agli schemi di guasto comuni che emergono sotto carico pesante. Considerare la saturazione dell'area di attesa. Quando le aree di attesa dei messaggi si riempiono più velocemente di quanto possano essere elaborate, le applicazioni non strumentate continuano ad accettare il lavoro fino a esaurimento della memoria o fino a quando non si verificano cascate di timeout. Applicazioni adeguatamente strumentate monitorano la profondità dell'area di attesa, le percentuali di rifiuto e la latenza di elaborazione, attivando risposte difensive quando vengono superate le soglie.

• Gestire efficacemente i segnali esterni all'applicazione: La gestione dei segnali dal sistema operativo rappresenta un altro punto critico della strumentazione. Le applicazioni devono registrare gli handler per i segnali di terminazione (SIGTERM, SIGINT) per abilitare l'arresto graduale. Durante l'arresto, le applicazioni dotate di strumenti appropriati interrompono l'accettazione di nuovo lavoro, consentono il completamento delle richieste in volo, svuotano gli buffer, chiudono le connessioni in modo pulito e annullano la registrazione dal rilevamento del servizio. Questo arresto orchestrato impedisce la perdita di dati e consente ai bilanciatori del carico di reindirizzare il traffico senza interruzioni.

• Strumento per scenari di errore complessi: Al di là di questi schemi di base, le applicazioni devono adottare modalità di errore più sottili. L'identificazione dei guasti grigi, in cui i componenti appaiono sani per alcuni osservatori mentre per altri non funzionano, richiede la correlazione dei segnali interni ed esterni. Un'applicazione può utilizzare lo strumento del pool di connessioni al database per segnalare controlli dello stato riusciti, monitorando contemporaneamente le percentuali di completamento delle transazioni che rivelano un deterioramento strisciante. Strategie di strumentazione efficaci sovrappongono più punti di osservazione.

  • Le metriche aziendali tengono traccia degli indicatori di successo specifici dell'applicazione, ad esempio le percentuali di completamento degli ordini o la qualità dei risultati della ricerca.
  • Le metriche di sistema monitorano l'utilizzo delle risorse, le distribuzioni della latenza e le percentuali di errore.
  • Le sonde sintetiche eseguono continuamente percorsi critici per rilevare la degradazione prima che gli utenti la incontrino.
  • Il tracciamento distribuito offre visibilità a livello di richiesta oltre i limiti del servizio.

Questi segnali vengono esposti attraverso interfacce standardizzate che consentono sia ai sistemi automatizzati che agli operatori umani di valutare lo stato dell'applicazione. La strumentazione stessa diventa parte della strategia di resilienza dell'applicazione, consentendo agli interruttori di scattare in base alle percentuali di errore, ai scalatori automatici di rispondere alle profondità dell'area di attesa e agli operatori di prendere decisioni informate durante gli incidenti.

Gli schemi e anti-schemi per ALM mostrano l'aspetto di una strategia di segnalazione corretta e scadente in un'organizzazione Salesforce. Utilizzarli per convalidare i progetti prima di procedere alla creazione o per identificare le aree del sistema che devono essere sottoposte a refactoring.

Per ulteriori informazioni sugli strumenti Salesforce per una strategia di segnalazione, vedere Salesforce Tools for Resiliency.

Una strategia di test è una serie di principi e standard guida per la pianificazione e l'esecuzione di test che misurano il successo e l'insuccesso delle applicazioni durante i processi ALM. Una strategia di test tiene informati e allineati tutti gli stakeholder coinvolti nel test sulla priorità, lo scopo e l'ambito di un determinato test. Aiuta anche i team di progetto a creare piani di test efficaci e ponderati.

In genere, gli sviluppatori o gli esperti di controllo della qualità e test sono coinvolti nella creazione e nell'esecuzione di test specifici. Una strategia di test consente di assicurarsi che queste persone sappiano quali tipi di test devono essere condotti per un determinato progetto e in quale sequenza condurli. Una strategia di test consente anche di assicurarsi che i team dispongano di ciò di cui hanno bisogno per creare test, piani di test e artefatti adeguati (ad esempio, serie di dati di test, dispositivi e simulatori di traffico o rete).

Una strategia di test efficace crea un quadro chiaro di come, quando, dove e perché eseguire diversi tipi di test, inclusi test di unità, test dell'interfaccia utente e test di regressione, in varie combinazioni e condizioni per scoprire come si comporterà il sistema ed eventuali modifiche in volo. Una strategia di test efficace produce test che mostrano la conformità di un sistema a requisiti non funzionali, come scalabilità, affidabilità e fruibilità, che possono essere difficili da misurare con un unico tipo di test.

Per creare strategie di test efficaci per Salesforce:

• Testare in modo iterativo, frequente e con mezzi automatizzati il più possibile. Progettare e implementare l'automazione dei test che consente ai team di eseguire una varietà di tipi di test su una varietà di carichi di lavoro. È possibile orchestrare varie serie di test in modo che avvengano automaticamente quando le modifiche entrano nel controllo sorgente. Questo approccio consente ai team di identificare e gestire in modo proattivo le regressioni in anticipo. Se possibile, utilizzare l'integrazione continua/erogazione continua (CI/CD) per questo sforzo. In caso contrario, stabilire piani di test chiari che consentano ai team di eseguire sequenze di test in anticipo e spesso, in modalità self-service. Per i test degli agenti Agentforce, affidarsi al Centro test per eseguire test batch rigorosi degli agenti AI con vari input per assicurarsi che funzionino correttamente in scenari diversi.
• Riconoscere che non tutte le modifiche richiedono ogni tipo di test. Così come una pipeline di rilascio efficace consente percorsi per applicazioni ad alto, medio e basso rischio, così una strategia di test efficace. Descrivere chiaramente per i team come selezionare e seguire un regime di test appropriato per le applicazioni con vari tipi di rischio, casi d'uso o complessità. Vedere Strategia ambientale.
• Definire quali test possono essere condotti in diversi tipi di ambiente. La fedeltà alla produzione è un componente chiave di test accurati, ma significa cose diverse per i diversi tipi di test. Ad esempio, il test di regressione richiede fedeltà alla produzione in termini di metadati e, in una certa misura, di dati. Assicurarsi di definire il tipo di fedeltà alla produzione richiesta per un determinato insieme di test e di classificare chiaramente i tipi di ambienti che possono supportare le condizioni appropriate per i diversi test. Per una panoramica dei tipi di lavoro allineati a ogni tipo di ambiente, vedere Strategia ambientale.
• Utilizzare test di resistenza, stress, prestazioni e scalabilità per misurare continuamente la maturità delle applicazioni. Questi test mostrano in che modo un'applicazione è pronta per il rilascio rispetto alle esigenze a livello di produzione. Per le nuove funzionalità principali, eseguire questi test a diversi intervalli nel ciclo di sviluppo dell'applicazione. Considerare questi test come parte di una singola fase o fase di sviluppo anziché come parte di operazioni in corso è anti-schema. È molto utile che i team ricevano feedback sulle prestazioni dell'app in anticipo e spesso, il che li aiuta a capire meglio quanto l'app sia vicina o lontana dalla preparazione a livello di produzione. La capacità di identificare e risolvere meglio i problemi prima che le modifiche entrino in produzione vale la pena di aggiungere la complessità di eseguire spesso test più sofisticati.
  • Sapere quali test sono importanti. Probabilmente si avrà una quantità fissa di tempo per condurre i test di scala o delle prestazioni, rendendo poco pratico testare ogni aspetto del sistema. Non tutte le funzioni vengono utilizzate allo stesso modo e non tutti i colli di bottiglia su larga scala avranno un impatto uguale sul business. Assicurarsi che i test di scala siano concentrati sulle parti del sistema più utilizzate e apprezzate. Definire e comprendere le opportunità più importanti per verificare e migliorare la scalabilità e le prestazioni nell'organizzazione.
  • Conoscere l'aspetto "abbastanza buono". La definizione dei criteri di successo per i test di scala e delle prestazioni è fondamentale. Assicurarsi che l'utente e i suoi team di sviluppo utilizzino i criteri di successo come benchmark di test. Assicurarsi inoltre che soddisfino i requisiti funzionali definiti dai team di sviluppo. In genere, questi criteri includono il supporto di un numero specifico di utenti simultanei con tempi di risposta inferiori a un valore concordato e gli obiettivi del livello di servizio. Definire i criteri di destinazione chiave e quindi progettare test di scala e delle prestazioni che garantiscano che i criteri siano soddisfatti.
  • Assicurarsi di disporre di ambienti adeguati. I test di scala e delle prestazioni richiedono una particolare fedeltà alla produzione. Le serie di dati, i dati demografici delle richieste, le percentuali di richieste e le caratteristiche del carico di lavoro negli ambienti non di produzione devono corrispondere il più possibile a ciò che si vede in produzione. Per i test su scala, è necessario utilizzare un Sandbox Completo. Se l'organizzazione non dispone di un Sandbox Completo per i test di scala, non è possibile eseguire test di scala adeguati.
• Assicurarsi che i carichi di lavoro di prova aiutino a misurare i requisiti non funzionali. Ricordati di considerare:
  • Dati di test: ogni tipo di test deve essere eseguito con dati isolati dalla produzione. Nei test di unità Apex, implementare schemi di fabbrica per garantire che il codice generi i propri dati di test, isolati dai dati ambientali. È anche possibile creare e gestire serie di dati di test in vari formati per testare i comportamenti di caricamento dei dati, compilare gli ambienti di sviluppo con dati per i test basati sull'interfaccia utente e fornire assistenza per i test di integrazione. Tutti i dati di test, siano essi gestiti come serie di dati esternalizzata o creati su richiesta dal codice data-factory, devono essere cancellati dai dati sensibili e identificativi. Dovrebbe includere dati corrotti, incompleti e in formato non corretto per supportare comportamenti negativi e di test di unità limite.
  • Servizi fittizi e stub: per i test di integrazione, è possibile utilizzare i servizi fittizi e stub per simulare le risposte API. Apex supporta un'API Stub per creare framework fittizi da utilizzare nei test Apex. Scherzi per creare framework fittizi che possono essere utilizzati nei test Apex. I falsi e gli stub possono aiutare a convalidare i comportamenti di gestione dei dati di un sistema, con una minore dipendenza da fabbriche di dati complesse o serie di dati di test esterni. I falsi e gli stub sono a volte più appropriati da utilizzare nei test in cui il traffico o i volumi di dati simili alla produzione non sono rilevanti.
  • Dispositivi e tecnologie per l'assistenza: una parte fondamentale della creazione di applicazioni coinvolgenti e accessibili è garantire che soddisfino le aspettative degli utenti in una varietà di dispositivi e con diversi tipi di tecnologie per l'assistenza. Un test di fruibilità significativo può richiedere più investimenti e diversi tipi di esperienza per essere eseguito in modo efficace, ma è una parte essenziale per sapere quanto saranno ben progettate le applicazioni rivolte agli utenti quando verranno rilasciate.
  • Simulatori: quando è necessario replicare volumi simili a quelli di produzione di richieste utente, traffico API o variazioni della velocità di rete, potrebbero essere necessari strumenti che simulano queste condizioni. Non tutti i test richiedono questo livello di investimento. Questi strumenti sono spesso più utili nei test di scalabilità e prestazioni.
  • AI e test degli agenti - Un obiettivo principale dei test è ridurre le allucinazioni AI, che sono risposte convincenti fabbricate e non corrette. Assicurarsi che i casi d'uso AI vengano testati per evidenziare i problemi comuni causati da una comprensione incompleta del cliente, dati mancanti, campi con metadati incompleti e dati non aggiornati. Utilizzare il Centro test per facilitare la creazione dei dati di test necessari per tali test.

La tabella seguente mostra una selezione di schemi da cercare o creare nell'organizzazione e di schemi anti-schemi da evitare o a cui indirizzare la riparazione.

✨ Scopri altri modelli per ALM in Pattern & Anti-Pattern Explorer.

Nell'ingegneria della sicurezza e dell'affidabilità dei siti (SRE), la risposta agli incidenti si concentra sul modo in cui i team identificano e risolvono gli eventi che influiscono sulla disponibilità o la sicurezza complessive di un sistema, nonché sul modo in cui i team lavorano per affrontare le cause principali e prevenire problemi futuri. La risposta agli incidenti include i processi, gli strumenti e i comportamenti organizzativi necessari per risolvere i problemi in tempo reale e dopo che si è verificato un problema.

Un architetto potrebbe non essere la persona che monitora quotidianamente le attività della soluzione una volta che viene resa disponibile. Parte dell'architettura per la resilienza consiste nella progettazione di funzionalità di ripristino che consentono ai team di assistenza di eseguire diagnosi di primo livello, stabilizzare i sistemi e affidare efficacemente l'analisi e la mitigazione delle cause principali ai team di sviluppo o manutenzione. I team che supportano direttamente gli utenti quotidianamente potrebbero non avere una profonda conoscenza o esperienza dell'architettura del sistema. È essenziale che questi team dispongano degli strumenti e dei processi necessari per monitorare le operazioni quotidiane, accedere alle informazioni del sistema quando diagnosticano un potenziale incidente e svolgere un ruolo di primo soccorso efficace per qualsiasi problema che influisce sulla disponibilità.

È possibile migliorare la risposta dei team agli incidenti nelle soluzioni Salesforce concentrandosi sul tempo di recupero, sulla capacità di triage e sul monitoraggio e avviso.

Quando si verifica un incidente, la prima priorità deve essere il ripristino di uno stato operativo stabile. Spesso le aziende pensano che l'unico modo per riprendersi da un incidente sia "risolvere il problema". Questo presupposto è corretto in quanto un'analisi accurata delle cause principali e la risoluzione dei problemi critici in un sistema sono il modo in cui si risolvono. Tuttavia, “risolvere il problema” durante le prime fasi della risposta alla crisi non è l’approccio più pratico. A seconda della gravità di un incidente, ogni secondo di incidente e il relativo impatto potrebbero causare una perdita di reddito o di reputazione per l'azienda.

Spesso, il tentativo di diagnosticare e risolvere i problemi alla radice ritarda gli sforzi per ripristinare il funzionamento di un sistema. Logisticamente, l'adozione di un approccio che chiede ai soccorritori di affrontare le cause profonde mette a dura prova gli esperti in materia (PMI) e il personale di assistenza dell'azienda. Lavorare per trovare e correggere le cause profonde durante un incidente richiede che le PMI siano disponibili per ogni incidente, il che può impedire al personale di assistenza in prima linea rivolto ai clienti di intraprendere azioni. Può anche causare il rilascio di modifiche da parte dei team che, a loro volta, creano ulteriori incidenti. In definitiva, un approccio di questo tipo aumenta i costi, consuma larghezza di banda tra i team e genera comportamenti in tempi di crisi che possono erodere il Customer Trust e la reputazione del marchio.

Il giusto paradigma di gestione degli incidenti consiste nel dare priorità e concentrarsi sul ripristino come primo passo. Dopo che un sistema è stato ripristinato alla stabilità, è possibile eseguire autopsie, indagini sugli incidenti, riparazione delle cause principali e attività simili. Questo ordine di operazioni consente al personale di risposta agli incidenti di eseguire il triage, la diagnosi e l'esecuzione delle tattiche di ripristino, avvisando le PMI pertinenti di fornire assistenza solo se necessario. Consente inoltre alle PMI di identificare e correggere le cause profonde di un incidente con meno pressione da un ticchettio.

Per adottare una mentalità basata sul ripristino per la risposta agli incidenti:

• Stabilire e raggiungere gli obiettivi del livello di servizio SLO. Gli SLO sono standard sviluppati con le parti interessate per requisiti non funzionali (NFR) specifici di un sistema, ad esempio prestazioni o tempo di attività. Questi obiettivi vengono misurati da indicatori del livello di servizio (SLI) in un periodo di tempo. Senza gli SLO, gran parte del lavoro sulla risposta agli incidenti e la risoluzione dei problemi complessi può sembrare disorganizzato e reattivo, ad esempio richiedere un'azione rapida per "arrestare questo errore specifico, per questa manciata di utenti che lo hanno segnalato". Questo ciclo è spesso ciò che spinge i team a spingere l'analisi delle cause principali più vicino alla risposta agli incidenti, perché sembra che aiuterà a fermare i comportamenti reattivi. Stabilire SLO e SLI è un modo più efficace per iniziare. Per stabilire gli SLO, tenere presenti le seguenti domande.
  • Quali sono i valori NFR del sistema per i prossimi 1–3 anni? Ad esempio, l'NFR può includere i tempi di risposta, le percentuali di richieste di picco e gli utenti simultanei che il sistema deve essere in grado di supportare.
  • Cosa si desidera che i clienti e i loro utenti possano sperimentare? Basare gli SLO sulla risposta a questa domanda, che potrebbe essere "Gli utenti possono eseguire rapidamente i rapporti in Salesforce".
  • Cosa si può misurare e per quale periodo di tempo misurarlo? Basare gli SLI sulla risposta a questa domanda. Uno SLI corrispondente all'esempio precedente potrebbe essere "l'x% dei rapporti viene caricato in media entro _n_o secondi, misurato in un periodo di 30 giorni".
• Definire e standardizzare le tattiche di ripristino. I ritiri di modifiche e le implementazioni di soluzioni possono aiutare a ripristinare il funzionamento di un sistema e a ridurre al minimo l'impatto di un incidente. Tattiche e protocolli di ripristino dei documenti che possono essere eseguiti dai membri appropriati dei team di assistenza o operativi. Le tattiche di ripristino variano a seconda del tipo di incidente. La tabella seguente mostra un framework generale che mappa i tipi di incidenti alle tattiche di ripristino. Per ulteriori informazioni sull'identificazione dei punti di errore e la definizione delle strategie di mitigazione, vedere Disponibilità.

• Definire criteri di uscita chiari. Utilizzare gli SLO per determinare quando il sistema è fuori dallo stato di incidente o impatto.
• Definire i processi per le revisioni post-incidente e la riparazione delle cause principali. Rivedere gli incidenti dopo il ripristino del servizio. Durante le revisioni, adottare un approccio post mortem senza colpe. Collaborare con le parti interessate per stabilire fatti chiari su ciò che si è verificato e su come si è verificato, anziché tentare di assegnare colpe o colpe ai singoli. Utilizzare formati di revisione diversi per esaminare come affrontare i problemi a lungo termine.
  • Un riesame post-azione si concentra sulla risposta all'incidente. È utile per valutare se sono in atto i processi e le tattiche di risposta appropriati.
  • Un'analisi della causa principale si concentra sulla causa principale dell'incidente. Può aiutare a identificare eventuali bug o problemi nella progettazione e nell'implementazione del sistema che hanno portato all'incidente.
• Praticare periodicamente i protocolli di ripristino concordati. Esercitarsi sui protocolli di ripristino per assicurarsi che tutti sappiano come gestire gli incidenti in modo corretto. Utilizzare i Sandbox e gli ambienti di test per offrire ai team luoghi in cui esercitarsi nella simulazione e nel ripristino degli incidenti. Esercitarsi anche nelle revisioni post-incidente. Facendo tutto questo, il ripristino diventa parte della cultura ingegneristica e di assistenza.

Gli schemi e anti-schemi per la risposta agli incidenti mostrano l'aspetto dell'architettura per assegnare la priorità al ripristino in una soluzione Salesforce. Utilizzarli per convalidare i progetti prima di procedere alla creazione o per identificare le aree del sistema che devono essere sottoposte a refactoring.

Per ulteriori informazioni sugli strumenti Salesforce per aiutare il recupero, vedere Salesforce Tools for Resiliency.

Nel contesto della tecnologia, il triaging prevede l'assegnazione di categorie e livelli di gravità ai problemi e alle richieste di assistenza. Non importa quanto sia ben pianificata la soluzione, si presenteranno problemi e richieste di assistenza agli utenti. Questi problemi possono derivare da una mancanza di formazione sufficiente o di gestione del cambiamento, lacune nell'interfaccia utente/interfaccia utente, comportamenti imprevisti degli utenti finali e problemi urgenti del sistema non rilevati dal monitoraggio o dagli avvisi.

I team di assistenza e operativi devono essere in grado di analizzare le richieste di assistenza degli utenti in modo efficiente e diagnosticarle rapidamente. Risolvere i problemi per escludere le preoccupazioni meno gravi e individuare rapidamente gli incidenti di sistema critici è una competenza chiave per questi team. Una scarsa ottimizzazione rallenta tutti i livelli di assistenza agli utenti, prolunga gli incidenti critici e aumenta il rischio di ulteriori interruzioni per i clienti e per l'azienda.

Anche se l'utente potrebbe non essere coinvolto nelle attività e nell'assistenza quotidiane, in qualità di architetto è sua responsabilità assicurarsi che i team di assistenza e operativi possano risolvere efficacemente i problemi in qualsiasi soluzione creata sulla piattaforma Salesforce.

Per consentire ai team di gestire efficacemente i problemi all'interno delle soluzioni Salesforce:

• Assicurarsi che i team di assistenza abbiano accesso a informazioni utili.
  • Documentare il sistema e gli schemi di progettazione. Garantire la leggibilità e la coerenza della soluzione è una parte fondamentale per consentire al personale di assistenza di comprendere il sistema di cui è responsabile. Nella documentazione, considerare come i team troveranno informazioni su come assegnare la priorità a problemi o incidenti con diverse parti del sistema. Assicurarsi inoltre che i team possano ottenere rapidamente informazioni tecniche sulle tattiche di recupero in base all'area di impatto. Fornire le guide per la risoluzione dei problemi più comuni di Agentforce, ad esempio Classificazione argomenti e Selezione azioni, che possono aiutare i team a risolvere rapidamente i problemi relativi alle autorizzazioni o alla configurazione.
  • Progettare pensando al debug. I team di assistenza e gli amministratori dell'organizzazione dovranno abilitare il debug e la diagnostica per individuare correttamente i problemi degli utenti in vari ambienti. Esempi di schemi facili da utilizzare per i bug sono quelli che incorporano messaggi di registrazione e di errore personalizzati nei percorsi di esecuzione in tutto il sistema. Abilitare i team di assistenza sugli approcci di debug più comuni di Agentforce con strumenti come i registri eventi e la visualizzazione ragionamento di Agent Builder.
  • Identificare PMI e stakeholder degli incidenti. Creare un elenco delle PMI o degli stakeholder pertinenti che dovrebbero essere disponibili a sostenere la ripresa da un incidente e che dovrebbero essere coinvolti durante l'analisi post-incidente.
  • Tratta con attenzione le consegne. Assicurare la qualità di ogni passaggio di soluzione ai team di assistenza o operativi nell'ambito dell'implementazione. Fornire formazione al personale di assistenza per esaminare l'architettura di sistema pertinente e le esercitazioni di risposta agli incidenti fittizi. Pensare ai trasferimenti successivi all'incidente, incluso il modo in cui i team devono documentare le informazioni che non vengono acquisite dai registri o dalle note caso, nonché al modo in cui i soccorritori degli incidenti possono contribuire alle indagini sulle cause principali o eseguire test di accettazione degli utenti per eventuali rimedi.
• Se si viene consultati, tenere tutti concentrati sul recupero come la preoccupazione principale.
  • Rispondere rapidamente. Rispondere rapidamente alle richieste di assistenza degli utenti, alle notifiche di monitoraggio e agli avvisi ricevuti.
  • Consentire di distinguere i sintomi dai problemi. Verificare se esiste un incidente di sistema effettivo che deve essere risolto. Provare a identificare i componenti con i problemi effettivi. Assicurarsi che vengano seguite le tattiche di ripristino concordate per far uscire rapidamente il sistema dallo stato di incidente.
• Per gli agenti Agentforce che supportano casi d'uso critici, assicurarsi che siano disponibili soluzioni valide e pertinenti e che possano essere attivate con breve preavviso come misura di ridondanza. Alcuni esempi sono il passaggio alla gestione manuale o il reindirizzamento alla documentazione pertinente per la revisione manuale.

Gli schemi e antischemi mostrano l'aspetto dell'architettura per un triaging efficace in una soluzione Salesforce. Utilizzarli per convalidare i progetti prima di procedere alla creazione o per identificare le aree del sistema che devono essere sottoposte a refactoring.

Per ulteriori informazioni sugli strumenti Salesforce per il triaging, vedere Salesforce Tools for Resiliency.

Monitoraggio e avviso sono termini ampiamente utilizzati nella progettazione dell'affidabilità del sito. Nel contesto della resilienza del sistema, il monitoraggio valuta costantemente lo stato attuale di un sistema e l'avviso automatizza le notifiche alle parti interessate in merito a potenziali preoccupazioni sullo stato del sistema. Monitoraggio e avvisi efficaci sono una parte fondamentale per separare la scala e la crescita del sistema dalla scala e dalla crescita del personale di assistenza.

Salesforce offre una varietà di funzionalità incorporate per monitorare i comportamenti nel sistema. Salesforce offre anche il monitoraggio evento reale come componente aggiuntivo o come parte di Salesforce Shield. In qualsiasi soluzione Salesforce, le strutture progettate per il monitoraggio e l'avviso offrono:

• Funzionalità per la risposta automatica agli incidenti
• Informazioni pertinenti agli utenti giusti, al momento giusto
• Informazioni chiare per visualizzazioni storiche e analisi delle tendenze

Per progettare un monitoraggio e un avviso efficaci all'interno delle soluzioni Salesforce:

• Impostare l'automazione come priorità. Sebbene informare gli utenti delle modifiche critiche dello stato sia una parte cruciale per mantenere i sistemi stabili e operativi, in un'architettura ideale, il sistema corregge automaticamente i problemi quando possibile e invia avvisi solo per problemi urgenti e non risolvibili. Anche senza funzionalità di autocorrezione, l'automazione può rendere più utili gli avvisi e i rapporti.
  • Iniziare con ciò che Salesforce offre già. Salesforce Platform fornisce registri e API pertinenti per monitorare le operazioni della soluzione in base ai limiti del governor. Inoltre, la piattaforma invia avvisi per violazioni dei limiti governor e problemi simili. Utilizzare questi registri e avvisi come base per esplorare modi per automatizzare in modo più completo l'autoripristino del sistema, la segnalazione degli incidenti e gli avvisi. Ad esempio, è possibile implementare un'automazione che monitora il registro e quindi esegue un'azione di ripristino quando viene registrato un particolare tipo di evento.
  • Classificare le modifiche allo stato del sistema in modi prevedibili. Creare categorie specifiche e significative per gli stati chiave su cui si desidera monitorare e generare rapporti. Allineare queste categorie alle categorie definite per gestire lo stato nei componenti dell'applicazione. Adottare una mentalità orientata all'API per gestire le informazioni sulle modifiche di stato. Formati dei messaggi e categorie di stato coerenti semplificano l'automazione, la generazione di rapporti e gli avvisi.
  • Allineare la logica di automazione alle altre parti del sistema. Se è stata creata una corretta gestione degli errori di automazione, è possibile estendere tali schemi al modo in cui si classificano le modifiche di stato e si risponde con l'automazione. Per le modifiche dello stato considerate recuperabili, è possibile automatizzare i comportamenti di tentativo. Per le modifiche dello stato considerate critiche o fatali, automatizzare gli avvisi agli utenti.
• Evitare di creare rumore. Quando gli utenti ricevono troppi avvisi, soprattutto quelli che non richiedono alcuna azione, tendono a disabilitare o ignorare tutti gli avvisi. Questo scenario compromette qualsiasi sforzo per creare avvisi utili. Per comprendere meglio chi riceve gli avvisi, che cosa li attiva e quando vengono attivati, valutare la possibilità di eseguire queste operazioni.
  • Creare mappe stakeholder. Per assicurarsi che il sistema fornisca gli avvisi giusti agli stakeholder giusti al momento giusto, identificare e classificare innanzitutto i gruppi di stakeholder.
  • Instradare i messaggi in base ai privilegi utente. Inviare avvisi solo ai destinatari che hanno la capacità e l'autorità per rispondere. Gli utenti aziendali potrebbero trarre vantaggio dagli avvisi sui problemi che possono risolvere correggendo i problemi nei record a cui hanno accesso. Se un problema richiede una risposta tecnica più coinvolta, gli avvisi devono essere indirizzati al personale di assistenza.
  • Chiarire la risposta prevista. Inviare avvisi solo in scenari che richiedono l'intervento umano. Strutturare i messaggi per indicare chiaramente l'azione che ci si aspetta dal destinatario. Se si invia un avviso a uno stakeholder per la visibilità e non è richiesta alcuna azione da parte dello stesso, specificarlo chiaramente nella versione del messaggio che riceve.
  • Rendere tempestivi e pertinenti gli avvisi. Gli avvisi inviati in risposta a errori che si sono verificati e che devono ancora essere risolti) non sono utili quanto gli avvisi relativi a un potenziale errore. Idealmente, il personale di assistenza viene avvisato non appena si verificano condizioni problematiche nel sistema, offrendo l'opportunità di risolvere i problemi prima che possano avere impatti negativi sulle operazioni aziendali.

L'elenco di schemi e antischemi mostra l'aspetto dell'architettura per un monitoraggio e un avviso efficaci in una soluzione Salesforce. Utilizzarli per convalidare i progetti prima di procedere alla creazione o per identificare le aree del sistema che devono essere sottoposte a refactoring.

Per ulteriori informazioni sugli strumenti Salesforce per il monitoraggio e l'avviso, vedere Salesforce Tools for Resiliency.

Questa tabella mostra una selezione di schemi da cercare o creare nell'organizzazione e di schemi anti-schemi da evitare o a cui indirizzare la riparazione.

✨ Scopri altri schemi per la risposta agli incidenti in Pattern & Anti-Pattern Explorer.

Una chiave per la resilienza del business è la pianificazione della continuità, che si concentra su come consentire alle persone e ai sistemi di funzionare attraverso i problemi causati da un evento non pianificato. I piani di continuità operativa (BCP) hanno una visione orientata alle persone di come far avanzare i processi attraverso la crisi. Gli aspetti tecnici della pianificazione della continuità sono contenuti nelle parti di ripristino di emergenza di un BCP. Vedere Continuità tecnologica.

Senza piani di continuità adeguati, l'organizzazione potrebbe ora sapere come agire, e quindi non agire affatto, durante una crisi o un guasto del sistema. Una pianificazione della continuità inefficace può avere un impatto catastrofico su clienti, stakeholder e aziende. A seguito di un evento avverso, ogni momento trascorso senza mantenere o ripristinare processi critici rischia danni finanziari, danni alla reputazione, sicurezza dei dipendenti e persino conformità alle normative.

È possibile migliorare la pianificazione della continuità nei sistemi concentrando gli sforzi in tre aree: definizione della continuità aziendale, pianificazione della continuità e creazione di backup e ripristino.

È possibile che la società disponga già di un BCP. In caso affermativo, assicurarsi che Salesforce sia incluso. Se la propria azienda non dispone di un BCP, collaborare con gli stakeholder per crearne uno che copra le organizzazioni Salesforce.

Salesforce è spesso considerato una fonte di dati veritieri per i dati dei clienti e i processi aziendali essenziali in molte divisioni aziendali. Di conseguenza, il ruolo svolto da Salesforce in un BCP può essere diverso da quello svolto da altri sistemi. È probabile che Salesforce sarà coinvolto in molte aree con priorità alta per il ripristino.

Per creare una pianificazione della continuità operativa pertinente per i sistemi Salesforce:

• Chiarire le priorità per il ripristino. Come per l'approccio generale per la risposta agli incidenti, la ripresa deve essere la prima priorità per i sistemi nei momenti di crisi. Molti servizi business critical vengono eseguiti in e con Salesforce. È necessario aiutare gli stakeholder a identificare la priorità corretta per il ripristino di varie funzioni e funzionalità aziendali. Un quadro generale potrebbe essere:
  • Stabilizzare l'infrastruttura aziendale essenziale.
  • Stabilizzare l'assistenza clienti.
  • Stabilizzare i servizi per dipendenti e partner.
• Tenere conto del proprio ecosistema nei BCP. Salesforce non è l'unico sistema nel panorama. Assicurarsi di identificare eventuali lacune nel BCP relative ai sistemi che si integrano con Salesforce, alle soluzioni installate dai fornitori AppExchange e a qualsiasi altro sistema che si connette a dati o processi in Salesforce. Se la capacità di fornire dipende dai fornitori, chiedere a questi ultimi informazioni sui loro piani di continuità. Valutare le loro capacità e pianificare come mantenere disponibili i sistemi.
• Integrare le preoccupazioni BCP nella strategia di test. Creare piani di test per il BCP ed eseguirli. È particolarmente importante testare le aree del BCP relative ai processi o alle persone, che spesso vengono trascurate. Incorporare gli elementi pertinenti del BCP nella strategia di test ALM generale. Creare e seguire una pianificazione di manutenzione per rivedere i test e assicurarsi che il piano rimanga aggiornato.

Gli schemi e antischemi mostrano l'aspetto di una pianificazione della continuità corretta e inadeguata in una soluzione Salesforce. Utilizzarli per convalidare i progetti prima di crearli o per identificare i punti del sistema che devono essere sottoposti a refactoring.

Per ulteriori informazioni sugli strumenti Salesforce per la definizione della continuità operativa, vedere Salesforce Tools for Resiliency.

L'obiettivo della continuità tecnologica è assicurarsi che i problemi con i componenti di un sistema non impediscano all'azienda di gestire le operazioni essenziali. Salesforce dà priorità al mantenimento dei servizi ai massimi livelli di disponibilità e alla fornitura di informazioni trasparenti su eventuali problemi. È possibile visualizzare informazioni in tempo reale sulle prestazioni e i problemi del sistema Salesforce su Trust.salesforce.com. In qualità di architetto basato su Salesforce, le soluzioni sfruttano l'affidabilità, la sicurezza e le prestazioni del sito offerte da Salesforce in tutta la piattaforma.

Tuttavia, la continuità complessiva delle soluzioni Salesforce va oltre i servizi integrati offerti da Salesforce. Da un punto di vista architetturale, la pianificazione della continuità tecnologica di Salesforce deve iniziare ponendo e rispondendo a domande su come Salesforce si inserisce nel panorama aziendale più ampio. Quali tipi di sistemi si integrano con Salesforce? In che modo i sistemi esterni dipendono dai processi o dalle informazioni in Salesforce? Nelle organizzazioni Salesforce, quali processi o funzionalità si basano sulle soluzioni AppExchange? Gli utenti accedono a Salesforce tramite servizi di identità di terze parti o SSO?

Per migliorare la continuità tecnologica nei sistemi Salesforce:

• Valutare l'infrastruttura. La strategia di risoluzione più comune per le interruzioni o i problemi tecnologici è la creazione di servizi o sistemi ridondanti a cui è possibile ricorrere durante un incidente. Salesforce dispone di un'architettura intenzionalmente ridondante, ovvero gestisce copie dei sistemi e dei servizi dei clienti in sedi fisiche diverse. Utilizziamo diverse tecniche di ripristino di emergenza, tra cui il passaggio da un sito all'altro, che ci consente di indirizzare il traffico degli utenti da un data center all'altro se necessario. Per identificare dove potrebbe essere necessario creare una ridondanza intenzionale, porsi le seguenti domande.
  • Che cosa accade durante un'interruzione del servizio per il servizio [X]? Possiamo passare da quel servizio a un altro?
  • Quanto tempo ci vuole per recuperare [X]? Qual è l'impatto sui nostri clienti? Qual è l'impatto sui nostri partner? Qual è l'impatto sui team interni?
  • E i backup e la loro frequenza? I backup potrebbero fornire i dati necessari per supportare l'azienda?
  • Abbiamo dipendenze dai fornitori? Quali sono i loro piani BCP?
• Fornire supporto operativo. Il supporto operativo consiste nel ripristinare l'operatività dei team il più velocemente possibile. Riflettere su come il sistema può gestire aumenti significativi dei requisiti di capacità e della domanda dovuti a cambiamenti imprevisti, inclusi cambiamenti a livello di settore, regionale o globale. Assicurarsi che il proprio BCP tenga conto delle risorse aggiuntive o delle procedure break-glass di cui Site Reliability Engineering (SRE) o i team di assistenza potrebbero avere bisogno per rispondere efficacemente agli incidenti. Le domande da porre sul supporto operativo includono:
  • In caso di guasto, i nostri team tecnici avrebbero gli strumenti necessari per continuare a lavorare? Abbiamo simulato un guasto per convalidare i piani o identificare lacune?
  • Se un disastro si verifica in un'area specifica, abbiamo piani di copertura per quell'area?
  • I nostri clienti sono globali? Operano 24 ore su 24, 7 giorni su 7?
  • Disponiamo di monitoraggio e avvisi adeguati per informare le persone appropriate in caso di errori?
• Automatizzare e testare le tattiche di recupero. Dopo aver risolto un problema, identificare dove si è verificato e come è stato risolto. Se possibile, in base alla riparazione, automatizzare le tattiche di ripristino e correggere eventuali problemi del processo. Molte aziende pianificano simulazioni di incidenti per un sottoinsieme di servizi per testare la resilienza del sistema. Un esempio potrebbe essere la simulazione di un account amministratore di sistema bloccato o compromesso o la simulazione di un guasto o un problema con un provider AppExchange. Vedere Risposta agli incidenti.)Le domande su come i test e l'automazione possono aiutare a ripristinare più rapidamente i servizi includono:
  • Con che frequenza vengono pianificate ed eseguite le simulazioni degli incidenti?
  • Sappiamo quanto tempo ci vuole per riportare i servizi a uno stato stabile?
  • Sono in atto processi di consegna stabili?
  • Sappiamo dove automatizzare il failover e il ripristino?

Considerare tutti gli elementi che escono dalle recensioni post-incidente come gli altri elementi di sviluppo. Aggiungerli ai sistemi di pianificazione in modo da poterli assegnare alle priorità e utilizzarli.

Gli schemi e antischemi per la pianificazione della continuità mostrano l'aspetto corretto e inadeguato della pianificazione della continuità tecnologica in una soluzione Salesforce. Utilizzarli per convalidare i progetti prima di crearli o per identificare i punti del sistema che devono essere sottoposti a refactoring.

Per ulteriori informazioni sugli strumenti Salesforce per la pianificazione della continuità tecnologica, vedere Salesforce Tools for Resiliency.

Il ripristino delle copie di backup dei dati o dei metadati può contribuire a riportare l'organizzazione all'ultimo stato stabile noto. Può anche fornire un sistema di failover durante un guasto catastrofico del sistema o un'interruzione del servizio. Il backup regolare dei dati e dei metadati e l'archiviazione delle copie di backup crittografate in un luogo sicuro aggiungono un ulteriore livello di resilienza all'architettura.

Senza strategie di backup e ripristino, non è possibile ripristinare versioni pulite dei dati di produzione e dei metadati quando vengono danneggiati in modo dannoso, quando i difetti si fanno inavvertitamente strada nella produzione o quando un errore durante un carico di dati elevato danneggia i dati di produzione. Uno qualsiasi di questi scenari può causare la corruzione o addirittura la perdita definitiva dei dati di produzione critici per l'azienda. L'impostazione della tecnologia di backup e ripristino offre una serie di vantaggi oltre alla pianificazione della continuità, tra cui l'assistenza nelle strategie per mitigare grandi volumi di dati e l'adesione alle policy di conservazione relative alla conformità.

Per garantire la continuità con le strategie di backup e ripristino nelle soluzioni Salesforce:

• Inizia. Il primo passo per avere una buona strategia di backup e ripristino è innanzitutto avere una strategia. Anche un'operazione semplice come l'esecuzione di backup notturni di tutti i dati e metadati dell'organizzazione può evitare che l'azienda perda informazioni o funzionalità critiche durante un disastro.
• Limitare l'accesso ai backup. Gli amministratori di sistema sono gli unici utenti che dovrebbero avere accesso alle copie di backup dei dati. Questa limitazione di accesso impedisce a un utente aziendale di visualizzare i record in una copia di backup che non sarebbe autorizzato a visualizzare nell'organizzazione.
• Testare regolarmente il processo di ripristino. Indipendentemente dalla strategia di backup e ripristino implementata, testare regolarmente il processo di ripristino in un Sandbox Copia completa o parziale per assicurarsi che funzioni correttamente quando necessario.
• Allineare la strategia di backup e ripristino alla strategia di archiviazione dei dati. Determinare cosa deve accadere nei backup o negli archivi quando i record vengono archiviati o eliminati dal sistema. Vedere Volume di dati).

Può essere necessaria una strategia di backup più dettagliata se i volumi di dati sono così elevati che un backup completo non ha il tempo di essere completato prima che inizi l'esecuzione del backup successivo. Può anche essere necessaria una strategia di backup più dettagliata se i dati dell'organizzazione cambiano così spesso che gli aggiornamenti sono mission critical per l'organizzazione.

Per rendere la strategia di backup più dettagliata:

• Amministrare i backup a oggetti specifici. Questa strategia prevede il backup dei record di oggetti diversi a intervalli di tempo diversi. Tenere presente che è necessario eseguire il backup degli oggetti secondari con gli stessi intervalli dei relativi oggetti controllanti per mantenere la coerenza dei dati.
• Backup parziali della casella temporale. Questa strategia prevede la distinzione tra backup completi (di tutti i dati e metadati) e backup parziali (solo dei metadati e dei record aggiunti o modificati dopo l'ultimo backup).

* Non smettere mai di eseguire backup completi. È importante notare che non è mai opportuno eliminare completamente i backup completi, anche se i volumi di dati causano tempi di esecuzione lunghi. Per volumi di dati elevati, pianificare backup completi regolari ma poco frequenti (ad esempio, backup settimanali). Pianificare anche backup parziali o specifici degli oggetti più frequenti (ad esempio backup notturni o backup ogni X ore). Questo approccio offre la flessibilità di ricostruire la serie di dati più completa e precisa da utilizzare nei processi di ripristino.*

Gli schemi e antischemi per la pianificazione della continuità mostrano come si presentano le funzionalità di backup e ripristino appropriate e scadenti in una soluzione Salesforce. Utilizzarli per convalidare i progetti prima di crearli o per identificare i punti del sistema che devono essere sottoposti a refactoring.

Salesforce Backup and Recover, una soluzione Salesforce integrata che include Own Recover from the Own acquisition, protegge i dati importanti da perdite o danneggiamenti. La nostra soluzione altamente sicura, facile da configurare e sempre disponibile garantisce la continuità operativa e la resilienza dei dati e semplifica la conformità.

Utilizzare Salesforce Backup and Recover per prevenire la perdita di dati, ripristinare rapidamente i dati da incidenti e semplificare la strategia di gestione dei dati complessiva. È possibile creare policy di backup per i dati di valore elevato e regolamentati e ripristinarli in pochi clic.

I backup automatici giornalieri proteggono tutti i dati cruciali dell'organizzazione, inclusi metadati, Sandbox, dati dei pacchetti gestiti, file allegati e altro ancora. Eseguire i backup con la frequenza necessaria per raggiungere gli obiettivi del punto di ripristino (RPO) e salvaguardare le distribuzioni. I backup sono sempre accessibili e archiviati in modo sicuro e conforme. La protezione continua dei dati è disponibile anche per i dati più sensibili o transazionali, consentendo un ripristino più rapido delle informazioni critiche in rapida evoluzione.

Rileva attività insolite dei dati, perdita di dati e danneggiamento con avvisi proattivi inviati direttamente al tuo indirizzo email. Ricevere avvisi in tempo reale per identificare i valori anomali statistici o per creare regole che informano dell'attività insolita dei dati, consentendo di rilevare gli incidenti più rapidamente che mai.

Salesforce Backup and Recover accelera il ripristino offrendo una visibilità granulare delle modifiche, consentendo l'identificazione e il ripristino rapidi dei dati interessati. Strumenti come i grafici visivi evidenziano le modifiche indesiderate, mentre le funzioni di ripristino facili da usare ripristinano con precisione oggetti, campi e record interessati.

I nostri strumenti consentono di utilizzare i backup per analisi, controlli e conformità, offrendo dati storici ricercabili, funzionalità di ricerca aperte per la visibilità dei dati passati e funzionalità di esportazione per analisi o magazzini esterni. In questo modo i backup vengono riutilizzati senza bisogno di API Salesforce aggiuntive.

Backup and Recover offre un'unica console per consolidare tutti i backup, la gestione, le operazioni e la conformità. Questa console consente di accedere, gestire, personalizzare e monitorare i backup per tutte le organizzazioni di produzione e i Sandbox. Con questo strumento è anche possibile eseguire le richieste degli interessati per garantire la conformità dei dati di backup e avere il controllo completo sulla personalizzazione delle pianificazioni di backup, della frequenza e dei criteri di conservazione.

• Mitigare l'impatto degli incidenti sui dati. Salesforce Backup and Recover aiuta a mitigare gli incidenti nei dati, ad esempio attacchi informatici o attività interne o esterne dannose, consentendo agli utenti di ripristinare lo stato precedente all'incidente. La funzionalità di esportazione di Backup and Recover garantisce l'accesso continuo ai dati critici degli utenti e la loro fruibilità.
• Impedire perdite permanenti. L'errore umano rimane la causa principale della perdita di dati. Backup and& Recover offre una soluzione precisa e rapida a questi errori.
• Soddisfare più facilmente la conformità dei dati e i requisiti legali. Salesforce Backup and Recover supporta il modello di responsabilità condivisa, abilitando la funzionalità self-service per gli errori in blocco o la rettifica dei dati nei dati di backup.

Per ulteriori informazioni sugli strumenti Salesforce per il backup e il ripristino, vedere Salesforce Tools for Resiliency.

Questa tabella mostra una selezione di schemi da cercare o creare nell'organizzazione e di schemi anti-schemi da evitare o a cui indirizzare la riparazione.

✨ Scopri altri schemi per la pianificazione della continuità in Pattern & Anti-Pattern Explorer.

Aiutaci a mantenere Salesforce Well-Architected pertinente per te; partecipa al nostro sondaggio per fornire un feedback su questo contenuto e dirci cosa vorresti vedere dopo.