Prospettiva dei servizi finanziari: affidabilità

Last reviewed 2025-07-28 UTC

Questo documento della Google Cloud prospettiva dei servizi finanziari (FS) del Well-Architected Framework 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 progetti architettonici. I consigli 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 sia un imperativo normativo. Per garantire l'affidabilità dei workload FS in Google Cloud sono affidabili, devi comprendere e mitigare i potenziali punti di errore , eseguire il deployment delle risorse in modo ridondante e pianificare il ripristino. La resilienza operativa è il risultato dell'affidabilità. È la capacità di assorbire, adattarsi e riprendersi dalle interruzioni. La resilienza operativa aiuta le organizzazioni FS a soddisfare i rigorosi requisiti normativi. Aiuta anche a evitare danni intollerabili ai clienti.

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

Requisiti normativi

Le organizzazioni FS operano in base a rigorosi mandati di affidabilità da parte di agenzie di regolamentazione come il Federal Reserve System negli Stati Uniti, l' Autorità bancaria europea 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: rafforzare le difese contro le minacce informatiche e garantire la resilienza dei sistemi IT.
  • Gestione dei rischi di terze parti: gestione dei rischi associati all' outsourcing dei servizi ai fornitori di tecnologie dell'informazione e della comunicazione (ICT).
  • Continuità aziendale e risposta agli incidenti: pianificazione solida per mantenere le operazioni critiche durante le interruzioni e per riprendersi in modo efficace.
  • Protezione della stabilità finanziaria: garantire la solidità e la stabilità del sistema finanziario più ampio.

I consigli sull'affidabilità contenuti in questo documento sono mappati ai seguenti principi fondamentali:

Dai la priorità ai deployment multi-zona e multi-regione

Per le applicazioni di servizi finanziari critici, ti consigliamo di utilizzare una topologia multi-regione distribuita in almeno due regioni e in tre zone all'interno di ogni regione. Questo approccio è importante per la resilienza contro le interruzioni di zona e regione. Le normative 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 una conseguenza plausibile. La logica è che quando una località non funziona, l'altra località potrebbe ricevere una quantità eccezionalmente elevata di traffico aggiuntivo.

Considera i seguenti consigli per aumentare la resilienza contro le interruzioni di zona e regione:

  • Preferisci le risorse con un ambito di località più ampio. Ove possibile, utilizza le risorse regionali anziché le risorse di zona e le risorse multi-regione o globali anziché le risorse regionali. Questo approccio consente di 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 ripristino manuale implementando deployment active-active come i seguenti esempi:
    • I database distribuiti come Spanner forniscono ridondanza e sincronizzazione integrate tra le regioni.
    • La funzionalità di alta disponibilità di Cloud SQL fornisce una topologia quasi active-active, con repliche di lettura tra le zone. Fornisce un obiettivo del punto di ripristino (RPO) tra le regioni vicino a 0.
  • Distribuisci il traffico utente 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 tuoi requisiti e della criticità. Per saperne di più, consulta Vantaggi e rischi del bilanciamento del carico globale per i deployment multi-regione.
  • Per archiviare i dati, utilizza servizi multiregionali come Spanner e Cloud Storage.

Elimina i single point of failure

Distribuisci le risorse in località diverse e utilizza risorse ridondanti per impedire che un singolo punto di errore (SPOF) influisca sull'intero stack di applicazioni.

Considera i seguenti consigli per evitare gli SPOF:

Per saperne di più, consulta Progettare 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. Considera i seguenti consigli per la gestione della disponibilità aggregata:

  • Calcola la disponibilità aggregata di uno stack multi-livello utilizzando la formula disponibilità_livello1 × disponibilità_livello2 × disponibilità_livelloN.

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

    La formula di disponibilità aggregata per un servizio multilivello con quattro servizi.

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

  • Ove possibile, scegli la parallelizzazione anziché l'incatenamento. 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 è stato eseguito il deployment utilizzando gli approcci di incatenamento e parallelizzazione:

    Le formule di disponibilità aggregate per i servizi concatenati rispetto ai servizi parallelizzati.

    Negli esempi precedenti, entrambi i servizi hanno uno SLA del 99%, il che comporta la 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 producono 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 Google Cloud servizi con SLA di uptime che possono aiutarti a soddisfare il livello di uptime complessivo richiesto 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 costa di più, 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 in più 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 calcolare con precisione la disponibilità. L'esecuzione di una valutazione di questo tipo ti aiuta a valutare le implicazioni delle tue decisioni di progettazione sull'architettura e sul budget.

Implementa una strategia di RE solida

Crea piani ben definiti per diversi scenari di emergenza, incluse le interruzioni di zona e 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. Con i deployment cloud, in generale, RE si applica ai deployment multi-regione e l'alta disponibilità ai deployment regionali. Questi archetipi di deployment supportano meccanismi di replica diversi.

  • HA: per impostazione predefinita, molti servizi gestiti forniscono la replica sincrona tra le zone all'interno di una singola regione. Questi servizi supportano un obiettivo del tempo di ripristino (RTO) e un Recovery Point Objective (RPO) pari a zero o quasi zero. Questo supporto ti consente di creare una topologia di deployment active-active senza SPOF.
  • Ripristino di emergenza: per i workload di cui è stato eseguito il deployment in due o più regioni, se non utilizzi servizi multi-regione o globali, devi definire una strategia di replica. La strategia di replica è in genere asincrona. Valuta attentamente in che modo questa replica influisce sull'RTO e sull'RPO per le applicazioni critiche. Identifica le operazioni manuali o semi-automatiche 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 active-active in due regioni, ti consigliamo di scegliere servizi multi-regione gestiti, come Spanner e Cloud Storage, soprattutto quando la replica dei dati è fondamentale.

Considera i seguenti consigli:

  • Utilizza i servizi di archiviazione multi-regione gestiti per i dati.
  • Crea snapshot dei dati nei Persistent Disk e archiviali in località multiregione.
  • Quando utilizzi risorse regionali o di zona, configura la replica dei dati in altre regioni.
  • Verifica l'efficacia dei 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 nella tua giurisdizione.

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

Sfrutta i servizi gestiti

Ove possibile, utilizza i servizi gestiti per sfruttare le funzionalità integrate per backup, alta disponibilità e scalabilità. Considera i seguenti consigli per l'utilizzo dei servizi gestiti:

  • Utilizza i servizi gestiti in Google Cloud. Forniscono un'alta disponibilità supportata da SLA. Offrono anche meccanismi di backup e funzionalità di resilienza integrati.
  • Per la gestione dei dati, valuta i servizi come Cloud SQL, Cloud Storage, e Spanner,
  • Per il calcolo e l'hosting delle applicazioni, valuta i gruppi di istanze gestite (MIG) di Compute Engine e i cluster Google Kubernetes Engine (GKE). I MIG regionali e i cluster regionali GKE sono resilienti alle interruzioni di zona.
  • Per migliorare la resilienza contro le interruzioni di regione, utilizza i servizi multi-regione 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 provider cloud 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 basato su Apache Airflow.

Automatizza i processi di provisioning e ripristino dell'infrastruttura

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 dagli errori e risultati più coerenti. Considera i seguenti consigli per automatizzare il provisioning e il ripristino delle risorse:

Indietro
Sicurezza
Avanti
Ottimizzazione dei costi