Perspectiva de FSI: confiabilidade

Last reviewed 2025-07-28 UTC

Este documento do Google Cloud Well-Architected Framework: perspectiva de instituições financeiras fornece uma visão geral dos princípios e recomendações para projetar, implantar e operar cargas de trabalho confiáveis do setor de serviços financeiros (FSI, na sigla em inglês) no Google Cloud. O documento explica como integrar práticas avançadas de confiabilidade e capacidade de observação aos seus projetos arquitetônicos. As recomendações neste documento estão alinhadas ao pilar de confiabilidade do framework bem arquitetado.

Para instituições financeiras, uma infraestrutura confiável e resiliente é uma necessidade comercial e um imperativo regulatório. Para garantir a confiabilidade das cargas de trabalho de FSI em Google Cloud , é necessário entender e reduzir possíveis pontos de falha, implantar recursos de forma redundante e planejar a recuperação. A resiliência operacional é um resultado da confiabilidade. É a capacidade de absorver, se adaptar e se recuperar de interrupções. A resiliência operacional ajuda as organizações de serviços financeiros a atender a requisitos regulamentares rigorosos. Isso também ajuda a evitar danos intoleráveis aos clientes.

Os principais elementos de confiabilidade no Google Cloud são regiões, zonas e os vários escopos de localização dos recursos de nuvem: zonal, regional, multirregional e global. É possível melhorar a disponibilidade usando serviços gerenciados, distribuindo recursos, implementando padrões de alta disponibilidade e automatizando processos.

Requisitos regulatórios

As organizações de serviços financeiros operam sob mandatos de confiabilidade rigorosos de agências regulatórias, como o Federal Reserve System (em inglês) nos EUA, a Autoridade Bancária Europeia (em inglês) na UE e a Autoridade de Regulamentação Prudencial (em inglês) no Reino Unido. No mundo todo, os reguladores enfatizam a resiliência operacional, que é vital para a estabilidade financeira e a proteção do consumidor. A resiliência operacional é a capacidade de resistir a interrupções, se recuperar de maneira eficaz e manter serviços críticos. Isso exige uma abordagem harmonizada para gerenciar riscos tecnológicos e dependências de terceiros.

Os requisitos regulamentares na maioria das jurisdições têm os seguintes temas em comum:

  • Segurança cibernética e resiliência tecnológica: fortalecimento das defesas contra ameaças cibernéticas e garantia da resiliência dos sistemas de TI.
  • Gerenciamento de riscos de terceiros: gerenciamento dos riscos associados à terceirização de serviços para provedores de tecnologia da informação e comunicação (TIC).
  • Continuidade de negócios e resposta a incidentes: planejamento robusto para manter as operações críticas durante interrupções e se recuperar de maneira eficaz.
  • Proteção da estabilidade financeira: garantir a integridade e a estabilidade do sistema financeiro em geral.

As recomendações de confiabilidade neste documento são mapeadas para os seguintes princípios básicos:

Priorizar implantações multizona e multirregionais

Para aplicativos financeiros críticos, recomendamos o uso de uma topologia multirregional distribuída em pelo menos duas regiões e três zonas em cada região. Essa abordagem é importante para a resiliência contra interrupções de zona e região. As regulamentações costumam prescrever essa abordagem porque, se ocorrer uma falha em uma zona ou região, a maioria das jurisdições considera uma interrupção grave em uma segunda zona como uma consequência plausível. A lógica é que, quando um local falha, o outro pode receber uma quantidade excepcionalmente alta de tráfego adicional.

Considere as seguintes recomendações para criar resiliência contra falhas de zona e região:

  • Prefira recursos com um escopo geográfico mais amplo. Sempre que possível, use recursos regionais em vez de zonais e multirregionais ou globais em vez de regionais. Essa abordagem ajuda a evitar a necessidade de restaurar operações usando backups.
  • Em cada região, use três zonas em vez de duas. Para lidar com failovers, faça um superprovisionamento de capacidade em um terço a mais do que a estimativa.
  • Minimize as etapas de recuperação manual implementando implantações ativas-ativas, como os exemplos a seguir:
    • Bancos de dados distribuídos, como o Spanner, oferecem redundância e sincronização integradas em todas as regiões.
    • O recurso de alta disponibilidade do Cloud SQL oferece uma topologia quase ativa-ativa, com réplicas de leitura em todas as zonas. Ele oferece um objetivo de ponto de recuperação (RPO) entre regiões próximo a 0.
  • Distribua o tráfego de usuários entre regiões usando o Cloud DNS e implante um balanceador de carga regional em cada região. Outra opção que você pode considerar, dependendo dos seus requisitos e da importância, é um balanceador de carga global. Para mais informações, consulte Benefícios e riscos do balanceamento de carga global para implantações multirregionais.
  • Para armazenar dados, use serviços multirregionais, como o Spanner e o Cloud Storage.

Eliminar pontos únicos de falha

Distribua recursos em diferentes locais e use recursos redundantes para evitar que um único ponto de falha (SPOF) afete toda a pilha de aplicativos.

Considere as seguintes recomendações para evitar SPOFs:

Para mais informações, consulte Criar uma infraestrutura confiável para suas cargas de trabalho no Google Cloud.

Entender e gerenciar a disponibilidade agregada

A disponibilidade geral ou agregada de um sistema é afetada pela disponibilidade de cada nível ou componente dele. O número de níveis em uma pilha de aplicativos tem uma relação inversa com a disponibilidade agregada da pilha. Considere as seguintes recomendações para gerenciar a disponibilidade agregada:

  • Calcule a disponibilidade agregada de uma pilha de vários níveis usando a fórmula disponibilidade_nível1 × disponibilidade_nível2 × disponibilidade_nívelN.

    O diagrama a seguir mostra o cálculo da disponibilidade agregada para um sistema de várias camadas que consiste em quatro serviços:

    A fórmula de disponibilidade agregada para um serviço de várias camadas com quatro serviços.

    No diagrama anterior, o serviço em cada nível oferece 99,9% de disponibilidade, mas a disponibilidade agregada do sistema é menor, de 99,6% (0,999 × 0,999 × 0,999 × 0,999). Em geral, a disponibilidade agregada de uma pilha de vários níveis é menor que a disponibilidade do nível que oferece a menor disponibilidade.

  • Sempre que possível, escolha paralelização em vez de encadeamento. Com serviços paralelizados, a disponibilidade de ponta a ponta é maior do que a disponibilidade de cada serviço individual.

    O diagrama a seguir mostra dois serviços, A e B, implantados usando as abordagens de encadeamento e paralelização:

    As fórmulas de disponibilidade agregada para serviços encadeados em comparação com serviços paralelizados.

    Nos exemplos anteriores, os dois serviços têm um SLA de 99%, o que resulta na seguinte disponibilidade agregada, dependendo da abordagem de implementação:

    • Serviços encadeados geram uma disponibilidade agregada de apenas 98% (0,99 × 0,99).
    • Serviços paralelizados geram uma disponibilidade agregada maior, de 99,99%, porque cada serviço é executado de forma independente e os serviços individuais não são afetados pela disponibilidade dos outros serviços. A fórmula para serviços paralelos agregados é 1 − (1 − A) × (1 − B).

  • Escolha serviços Google Cloud com SLAs de tempo de atividade que podem ajudar a atender ao nível necessário de tempo de atividade geral para sua pilha de aplicativos.

  • Ao projetar sua arquitetura, considere as vantagens e desvantagens entre disponibilidade, complexidade operacional, latência e custo. Aumentar o número de noves de disponibilidade geralmente custa mais, mas ajuda você a atender aos requisitos regulamentares.

    Por exemplo, uma disponibilidade de 99,9% (três noves) significa um possível tempo de inatividade de 86 segundos em um dia de 24 horas. Por outro lado, 99% (dois noves) significa um tempo de inatividade de 864 segundos no mesmo período, que é 10 vezes maior do que com três noves de disponibilidade.

    Para serviços financeiros críticos, as opções de arquitetura podem ser limitadas. No entanto, é fundamental identificar os requisitos de disponibilidade e calcular a disponibilidade com precisão. Realizar essa avaliação ajuda você a entender as implicações das suas decisões de design na arquitetura e no orçamento.

Implementar uma estratégia de DR robusta

Crie planos bem definidos para diferentes cenários de desastre, incluindo interrupções zonais e regionais. Com uma estratégia de recuperação de desastres (DR) bem definida, é possível se recuperar de uma interrupção e retomar as operações normais com o mínimo de impacto.

DR e alta disponibilidade (HA) são conceitos diferentes. Com implantações na nuvem, em geral, a recuperação de DR se aplica a implantações multirregionais, e a alta disponibilidade se aplica a implantações regionais. Esses arquétipos de implantação oferecem suporte a diferentes mecanismos de replicação.

  • HA: muitos serviços gerenciados oferecem replicação síncrona entre zonas em uma única região por padrão. Esses serviços oferecem um objetivo de tempo de recuperação (RTO) e um objetivo de ponto de recuperação (RPO) de zero ou quase zero. Com esse suporte, é possível criar uma topologia de implantação ativo-ativo sem SPOF.
  • DR: para cargas de trabalho implantadas em duas ou mais regiões, se você não usar serviços multirregionais ou globais, defina uma estratégia de replicação. A estratégia de replicação normalmente é assíncrona. Avalie com cuidado como essa replicação afeta o RTO e o RPO de aplicativos críticos. Identifique as operações manuais ou semiautomáticas necessárias para o failover.

Para instituições financeiras, a escolha da região de failover pode ser limitada por regulamentações sobre soberania e residência de dados. Se você precisar de uma topologia ativo-ativo em duas regiões, recomendamos escolher serviços multirregionais gerenciados, como o Spanner e o Cloud Storage, principalmente quando a replicação de dados é essencial.

Considere as seguintes recomendações:

  • Use serviços de armazenamento gerenciados e multirregionais para dados.
  • Crie snapshots de dados em discos permanentes e armazene-os em locais multirregionais.
  • Ao usar recursos regionais ou por zona, configure a replicação de dados para outras regiões.
  • Teste o plano regularmente para validar a eficácia dele.
  • Conheça o RTO e o RPO e a correlação deles com a tolerância a impactos estipulada pelas regulamentações financeiras na sua jurisdição.

Para mais informações, consulte Como arquitetar a recuperação de desastres para interrupções de infraestrutura em nuvem.

Aproveitar serviços gerenciados

Sempre que possível, use serviços gerenciados para aproveitar os recursos integrados de backups, alta disponibilidade e escalonabilidade. Considere as seguintes recomendações para usar serviços gerenciados:

  • Use serviços gerenciados em Google Cloud. Eles oferecem alta disponibilidade com suporte de SLAs. Eles também oferecem mecanismos de backup e recursos de resiliência integrados.
  • Para gerenciamento de dados, considere serviços como Cloud SQL, Cloud Storage e Spanner.
  • Para hospedagem de computação e aplicativos, considere os grupos de instâncias gerenciadas (MIGs) do Compute Engine e os clusters do Google Kubernetes Engine (GKE). Os MIGs regionais e os clusters regionais do GKE são resilientes a interrupções de zona.
  • Para melhorar a resiliência contra interrupções regionais, use serviços multirregionais gerenciados.
  • Identifique a necessidade de planos de saída para serviços com características exclusivas e defina os planos necessários. Reguladores financeiros como a FCA, a PRA e a EBA exigem que as empresas tenham estratégias e planos de contingência para recuperação de dados e continuidade operacional se a relação com um provedor de nuvem terminar. As empresas precisam avaliar a viabilidade de saída antes de firmar contratos de nuvem e manter a capacidade de mudar de provedor sem interrupção operacional.
  • Verifique se os serviços escolhidos permitem exportar dados para um formato aberto, como CSV, Parquet e Avro. Verifique se os serviços são baseados em tecnologias abertas, como o suporte do GKE para o formato da Open Container Initiative (OCI) ou Cloud Composer criado no Apache Airflow.

Automatizar os processos de provisionamento e recuperação da infraestrutura

Automation ajuda a minimizar erros humanos e reduzir o tempo e os recursos necessários para responder a incidentes. O uso da automação pode ajudar a garantir uma recuperação mais rápida de falhas e resultados mais consistentes. Considere as seguintes recomendações para automatizar o provisionamento e a recuperação de recursos:

  • Minimize os erros humanos usando ferramentas de infraestrutura como código (IaC), como o Terraform.
  • Reduza a intervenção manual automatizando processos de failover. As respostas automáticas também podem ajudar a reduzir o impacto das falhas. Por exemplo, é possível usar o Eventarc ou Workflows para acionar automaticamente ações corretivas em resposta a problemas observados nos registros de auditoria.
  • Aumente a capacidade dos seus recursos de nuvem durante o failover usando o escalonamento automático.
  • Aplique automaticamente políticas e proteções para requisitos regulamentares em toda a topologia da nuvem durante a implantação do serviço ao adotar a engenharia de plataforma.