Prospettiva dei servizi finanziari: affidabilità

Last reviewed 2026-10-28 UTC

Questo documento del Google Cloud Well-Architected Framework: prospettiva dei servizi finanziari (FS) fornisce una panoramica dei principi e dei consigli per progettare, eseguire il deployment e gestire workload FS affidabili in Google Cloud. Il documento esplora come integrare pratiche di affidabilità avanzate e osservabilità nei tuoi progetti di architettura. I suggerimenti contenuti in questo documento sono in linea con il pilastro dell'affidabilità del Well-Architected Framework.

Per gli istituti finanziari, un'infrastruttura affidabile e resiliente è sia un'esigenza aziendale che un imperativo normativo. Per garantire l'affidabilità dei workload FS inGoogle Cloud , devi comprendere e mitigare i potenziali punti di errore, eseguire il deployment delle risorse in modo ridondante e pianificare il ripristino. La resilienza operativa è un risultato dell'affidabilità. È la capacità di assorbire, adattarsi e riprendersi dalle interruzioni. La resilienza operativa aiuta le organizzazioni di servizi finanziari a soddisfare requisiti normativi rigorosi. Inoltre, aiuta a evitare danni intollerabili ai clienti.

I componenti di base dell'affidabilità principali in Google Cloud sono le regioni, le zone e i vari ambiti di località delle risorse cloud: a livello di zona, di regione, multiregionale e globale. Puoi migliorare la disponibilità utilizzando servizi gestiti, distribuendo le risorse, implementando pattern ad alta affidabilità e automatizzando i processi.

Requisiti normativi

Le organizzazioni di servizi finanziari operano nel rispetto di rigorosi mandati di affidabilità da parte di enti regolatori come il Federal Reserve System negli Stati Uniti, l'European Banking Authority nell'UE e la Prudential Regulation Authority nel Regno Unito. A livello globale, le autorità di regolamentazione sottolineano la resilienza operativa, che è fondamentale per la stabilità finanziaria e la protezione dei consumatori. La resilienza operativa è la capacità di resistere alle interruzioni, riprendersi in modo efficace e mantenere i servizi critici. Ciò richiede un approccio armonizzato per la gestione dei rischi tecnologici e delle dipendenze da terze parti.

I requisiti normativi nella maggior parte delle giurisdizioni hanno i seguenti temi comuni:

• Cybersicurezza e resilienza tecnologica: rafforzamento delle difese contro le cyber minacce e garanzia della resilienza dei sistemi IT.
• Gestione dei rischi di terze parti: gestione dei rischi associati all'outsourcing di servizi a fornitori di tecnologie dell'informazione e della comunicazione (ICT).
• Continuità aziendale e risposta agli incidenti: una pianificazione solida per mantenere le operazioni critiche durante le interruzioni e per eseguire il ripristino in modo efficace.
• Protezione della stabilità finanziaria: garantire la solidità e la stabilità del sistema finanziario più ampio.

I suggerimenti per l'affidabilità contenuti in questo documento sono mappati ai seguenti principi fondamentali:

• Dai la priorità ai deployment multizona e multiregionali
• Elimina i single point of failure (SPOF)
• Comprendi e gestisci la disponibilità aggregata
• Implementa una strategia di RE efficace
• Sfrutta i servizi gestiti
• Automatizza i processi di provisioning e ripristino dell'infrastruttura

Dai la priorità ai deployment multizona e multiregionali

Per le applicazioni di servizi finanziari critici, ti consigliamo di utilizzare una topologia multiregionale distribuita in almeno due regioni e in tre zone all'interno di ciascuna regione. Questo approccio è importante per la resilienza alle interruzioni di zone e regioni. I regolamenti spesso prescrivono questo approccio, perché se si verifica un errore in una zona o regione, la maggior parte delle giurisdizioni considera una grave interruzione in una seconda zona come una conseguenza plausibile. Il motivo è che, quando una località non funziona, l'altra potrebbe ricevere una quantità eccezionalmente elevata di traffico aggiuntivo.

Prendi in considerazione i seguenti suggerimenti per creare resilienza contro le interruzioni di zone e regioni:

• Preferisci le risorse con un ambito di località più ampio. Se possibile, utilizza risorse di regione anziché di zona e risorse multiregionali o globali anziché di regione. Questo approccio aiuta a evitare la necessità di ripristinare le operazioni utilizzando i backup.
• In ogni regione, utilizza tre zone anziché due. Per gestire i failover, esegui l'overprovisioning della capacità di un terzo in più rispetto alla stima.
• Riduci al minimo i passaggi di recupero manuale implementando deployment attivo-attivo come i seguenti esempi:
  • I database distribuiti come Spanner forniscono ridondanza e sincronizzazione integrate tra le regioni.
  • La funzionalità HA di Cloud SQL fornisce una topologia quasi attiva-attiva, con repliche di lettura tra zone. Fornisce un Recovery Point Objective (RPO) tra regioni vicino allo 0.
• Distribuisci il traffico degli utenti tra le regioni utilizzando Cloud DNS ed esegui il deployment di un bilanciatore del carico regionale in ogni regione. Un bilanciatore del carico globale è un'altra opzione che puoi prendere in considerazione a seconda dei requisiti e della criticità. Per saperne di più, consulta Vantaggi e rischi del bilanciamento del carico globale per i deployment multiregionali.
• Per archiviare i dati, utilizza servizi multiregionali come Spanner e Cloud Storage.

Elimina i single point of failure

Distribuisci le risorse in diverse località e utilizza risorse ridondanti per evitare che un single point of failure (SPOF) influisca sull'intero stack di applicazioni.

Prendi in considerazione i seguenti suggerimenti per evitare i single point of failure:

• Evita di eseguire il deployment di un solo server di applicazioni o database.
• Assicurati che le VM con errori vengano ricreate automaticamente utilizzando i gruppi di istanze gestite (MIG).
• Distribuisci il traffico in modo uniforme tra le risorse disponibili implementando il bilanciamento del carico.
• Utilizza le configurazioni ad alta affidabilità per i database come Cloud SQL.
• Migliora la disponibilità dei dati utilizzando Persistent Disk a livello di regione con la replica sincrona.

Per saperne di più, consulta Progetta un'infrastruttura affidabile per i workload in Google Cloud.

Comprendi e gestisci la disponibilità aggregata

Tieni presente che la disponibilità complessiva o aggregata di un sistema è influenzata dalla disponibilità di ogni livello o componente del sistema. Il numero di livelli in uno stack di applicazioni ha una relazione inversa con la disponibilità aggregata dello stack. Tieni presente i seguenti consigli per la gestione della disponibilità aggregata:

• Calcola la disponibilità aggregata di uno stack multilivello utilizzando la formula tier1_availability × tier2_availability × tierN_availability.

  Il seguente diagramma mostra il calcolo della disponibilità aggregata per un sistema multilivello composto da quattro servizi:

  

  Nel diagramma precedente, il servizio in ogni livello fornisce una disponibilità del 99,9%, ma la disponibilità aggregata del sistema è inferiore al 99,6% (0,999 × 0,999 × 0,999 × 0,999). In generale, la disponibilità aggregata di uno stack multilivello è inferiore alla disponibilità del livello che offre la disponibilità minima.

• Se possibile, scegli la parallelizzazione anziché il concatenamento. Con i servizi parallelizzati, la disponibilità end-to-end è superiore alla disponibilità di ogni singolo servizio.

  Il seguente diagramma mostra due servizi, A e B, di cui viene eseguito il deployment utilizzando gli approcci di concatenamento e parallelizzazione:

  

  Negli esempi precedenti, entrambi i servizi hanno uno SLA del 99%, il che si traduce nella seguente disponibilità aggregata a seconda dell'approccio di implementazione:

  • I servizi concatenati producono una disponibilità aggregata di solo il 98% (0,99 × 0,99).
  • I servizi parallelizzati offrono una disponibilità aggregata più elevata, pari al 99,99%, perché ogni servizio viene eseguito in modo indipendente e i singoli servizi non sono influenzati dalla disponibilità degli altri servizi. La formula per i servizi parallelizzati aggregati è 1 − (1 − A) × (1 − B).

• Scegli i servizi Google Cloud con SLA di uptime che possono aiutarti a soddisfare il livello richiesto di uptime complessivo per lo stack di applicazioni.

• Quando progetti l'architettura, considera i compromessi tra disponibilità, complessità operativa, latenza e costi. L'aumento del numero di nove di disponibilità in genere comporta costi maggiori, ma ti aiuta a soddisfare i requisiti normativi.

  Ad esempio, una disponibilità del 99,9% (tre nove) significa un potenziale tempo di inattività di 86 secondi in un giorno di 24 ore. Al contrario, il 99% (due nove) significa un tempo di inattività di 864 secondi nello stesso periodo, ovvero 10 volte più tempo di inattività rispetto a tre nove di disponibilità.

  Per i servizi finanziari critici, le opzioni di architettura potrebbero essere limitate. Tuttavia, è fondamentale identificare i requisiti di disponibilità e calcolarla con precisione. Eseguire questa valutazione ti aiuta a valutare le implicazioni delle tue decisioni di progettazione sull'architettura e sul budget.

Implementa una strategia di RE efficace

Crea piani ben definiti per diversi scenari di emergenza, tra cui interruzioni a livello di zona e di regione. Una strategia di ripristino di emergenza (RE) ben definita ti consente di riprenderti da un'interruzione e riprendere le normali operazioni con un impatto minimo.

RE e l'alta affidabilità (HA) sono concetti diversi. In generale, con i deployment cloud, RE si applica ai deployment multiregionali e l'HA ai deployment regionali. Questi archetipi di deployment supportano diversi meccanismi di replica.

• HA: molti servizi gestiti forniscono la replica sincrona tra le zone all'interno di una singola regione per impostazione predefinita. Questi servizi supportano un Recovery Time Objective (RTO) e un Recovery Point Objective (RPO) pari a zero o quasi. Questo supporto ti consente di creare una topologia di deployment attivo-attivo senza SPOF.
• DR: per i workload di cui viene eseguito il deployment in due o più regioni, se non utilizzi servizi multiregionali o globali, devi definire una strategia di replica. La strategia di replica è in genere asincrona. Valuta attentamente l'impatto di questa replica su RTO e RPO per le applicazioni critiche. Identifica le operazioni manuali o semiautomatiche necessarie per il failover.

Per gli istituti finanziari, la scelta della regione di failover potrebbe essere limitata dalle normative sulla sovranità dei dati e sulla residenza dei dati. Se hai bisogno di una topologia attivo-attivo in due regioni, ti consigliamo di scegliere servizi multiregionali gestiti, come Spanner e Cloud Storage, soprattutto quando la replica dei dati è fondamentale.

Prendi in considerazione i seguenti consigli:

• Utilizza servizi di archiviazione multiregionali gestiti per i dati.
• Scatta snapshot dei dati nei Persistent Disk e archiviali in località multiregionali.
• Quando utilizzi risorse a livello di zona o di regione, configura la replica dei dati in altre regioni.
• Convalida l'efficacia dei tuoi piani di RE testandoli regolarmente.
• Tieni presente l'RTO e l'RPO e la loro correlazione con la tolleranza all'impatto prevista dalle normative finanziarie della tua giurisdizione.

Per saperne di più, consulta Progettazione ripristino di emergenza per interruzioni dell'infrastruttura cloud.

Sfrutta i servizi gestiti

Quando possibile, utilizza i servizi gestiti per sfruttare le funzionalità integrate per i backup, l'alta affidabilità e la scalabilità. Prendi in considerazione i seguenti consigli per l'utilizzo dei servizi gestiti:

• Utilizza i servizi gestiti in Google Cloud. Forniscono l'alta affidabilità supportata da SLA. Offrono inoltre meccanismi di backup integrati e funzionalità di resilienza.
• Per la gestione dei dati, prendi in considerazione servizi come Cloud SQL, Cloud Storage e Spanner.
• Per l'hosting di applicazioni e computing, prendi in considerazione i gruppi di istanze gestite (MIG) di Compute Engine e i cluster Google Kubernetes Engine (GKE). I MIG regionali e i cluster GKE a livello di regione sono resilienti alle interruzioni delle zone.
• Per migliorare la resilienza alle interruzioni di servizio a livello di regione, utilizza i servizi multiregionali gestiti.
• Identifica la necessità di piani di uscita per i servizi con caratteristiche uniche e definisci i piani richiesti. Le autorità di regolamentazione finanziaria come FCA, PRA ed EBA richiedono alle aziende di avere strategie e piani di emergenza per il recupero dei dati e la continuità operativa se il rapporto con un cloud provider termina. Le aziende devono valutare la fattibilità dell'uscita prima di stipulare contratti cloud e devono mantenere la capacità di cambiare provider senza interruzioni operative.
• Verifica che i servizi che scegli supportino l'esportazione dei dati in un formato aperto come CSV, Parquet e Avro. Verifica se i servizi sono basati su tecnologie aperte, come il supporto di GKE per il formato Open Container Initiative (OCI) o Managed Service for Apache Airflow.

Automatizza i processi di provisioning e ripristino dell'infrastruttura

L'Automation aiuta a ridurre al minimo gli errori umani e a ridurre il tempo e le risorse necessari per rispondere agli incidenti. L'utilizzo dell'automazione può contribuire a garantire un ripristino più rapido in caso di errori e risultati più coerenti. Prendi in considerazione i seguenti suggerimenti per automatizzare il provisioning e il recupero delle risorse:

• Riduci al minimo gli errori umani utilizzando strumenti di infrastructure as code (IaC) come Terraform.
• Riduci l'intervento manuale automatizzando i processi di failover. Le risposte automatiche possono anche contribuire a ridurre l'impatto degli errori. Ad esempio, puoi utilizzare Eventarc o Workflows per attivare automaticamente azioni correttive in risposta ai problemi osservati tramite gli audit log.
• Aumenta la capacità delle tue risorse cloud durante il failover utilizzando la scalabilità automatica.
• Applica automaticamente policy e misure di protezione per i requisiti normativi nella tua topologia cloud durante il deployment dei servizi adottando la platform engineering.