Perspectiva de FSI: Confiabilidad

Last reviewed 2025-07-28 UTC

En este documento del Google Cloud Framework de Well-Architected: perspectiva de la industria de servicios financieros (FSI), se proporciona una descripción general de los principios y las recomendaciones para diseñar, implementar y operar cargas de trabajo confiables de la industria de servicios financieros (FSI) enGoogle Cloud. En el documento, se explora cómo integrar prácticas avanzadas de confiabilidad y observabilidad en tus planos arquitectónicos. Las recomendaciones de este documento se alinean con el pilar de confiabilidad del Framework de Well-Architected.

Para las instituciones financieras, una infraestructura confiable y resiliente es tanto una necesidad comercial como un requisito reglamentario. Para garantizar que las cargas de trabajo de FSI enGoogle Cloud sean confiables, debes comprender y mitigar los posibles puntos de falla, implementar recursos de forma redundante y planificar la recuperación. La resiliencia operativa es un resultado de la confiabilidad. Es la capacidad de absorber, adaptarse y recuperarse de las interrupciones. La resiliencia operativa ayuda a las organizaciones de FSI a cumplir con los estrictos requisitos reglamentarios. También ayuda a evitar daños intolerables a los clientes.

Los componentes básicos de la confiabilidad en Google Cloud son las regiones, las zonas y los diversos alcances de ubicación de los recursos de la nube: zonales, regionales, multirregionales y globales. Puedes mejorar la disponibilidad con servicios administrados, distribuir recursos, implementar patrones de alta disponibilidad y automatizar procesos.

Requisitos reglamentarios

Las organizaciones de FSI operan bajo estrictos mandatos de confiabilidad de agencias regulatorias como el Sistema de la Reserva Federal en EE.UU., la Autoridad Bancaria Europea en la UE y la Autoridad de Regulación Prudencial en el Reino Unido. A nivel global, los reguladores enfatizan la resiliencia operativa, que es vital para la estabilidad financiera y la protección del consumidor. La resiliencia operativa es la capacidad de resistir interrupciones, recuperarse de manera eficaz y mantener los servicios críticos. Esto requiere un enfoque armonizado para administrar los riesgos tecnológicos y las dependencias de terceros.

Los requisitos reglamentarios de la mayoría de las jurisdicciones tienen los siguientes temas en común:

  • Ciberseguridad y resiliencia tecnológica: Fortalecimiento de las defensas contra las ciberamenazas y garantía de la resiliencia de los sistemas de TI
  • Administración de riesgos de terceros: Administración de los riesgos asociados con la subcontratación de servicios a proveedores de tecnología de la información y la comunicación (TIC).
  • Continuidad empresarial y respuesta ante incidentes: Planificación sólida para mantener las operaciones críticas durante las interrupciones y recuperarse de manera eficaz.
  • Protección de la estabilidad financiera: Garantizar la solidez y la estabilidad del sistema financiero en general

Las recomendaciones de confiabilidad que se incluyen en este documento se correlacionan con los siguientes principios básicos:

Prioriza las implementaciones multizona y multirregionales

Para las aplicaciones de servicios financieros críticos, te recomendamos que uses una topología multirregional distribuida en al menos dos regiones y en tres zonas dentro de cada región. Este enfoque es importante para la resiliencia ante las interrupciones de zonas y regiones. Las reglamentaciones suelen prescribir este enfoque, ya que, si se produce una falla en una zona o región, la mayoría de las jurisdicciones consideran que una interrupción grave en una segunda zona es una consecuencia plausible. La razón es que, cuando falla una ubicación, la otra podría recibir una cantidad excepcionalmente alta de tráfico adicional.

Ten en cuenta las siguientes recomendaciones para generar resiliencia ante las interrupciones de zonas y regiones:

  • Prefiere los recursos que tengan un alcance de ubicación más amplio. Cuando sea posible, usa recursos regionales en lugar de zonales, y usa recursos multirregionales o globales en lugar de regionales. Este enfoque ayuda a evitar la necesidad de restablecer operaciones con copias de seguridad.
  • En cada región, aprovecha tres zonas en lugar de dos. Para controlar las conmutaciones por error, aprovisiona un tercio más de capacidad de la que se estima.
  • Minimiza los pasos de recuperación manual implementando implementaciones activo-activo, como en los siguientes ejemplos:
    • Las bases de datos distribuidas, como Spanner, proporcionan redundancia y sincronización integradas en todas las regiones.
    • La función de HA de Cloud SQL proporciona una topología casi activa-activa, con réplicas de lectura en todas las zonas. Proporciona un objetivo de punto de recuperación (RPO) entre regiones cercano a 0.
  • Distribuye el tráfico de usuarios en las regiones con Cloud DNS y, luego, implementa un balanceador de cargas regional en cada región. Un balanceador de cargas global es otra opción que puedes considerar según tus requisitos y la criticidad. Para obtener más información, consulta Beneficios y riesgos del balanceo de cargas global para implementaciones multirregionales.
  • Para almacenar datos, usa servicios multirregionales como Spanner y Cloud Storage.

Elimina los puntos únicos de fallo

Distribuye los recursos en diferentes ubicaciones y usa recursos redundantes para evitar que cualquier punto único de falla (SPOF) afecte toda la pila de aplicaciones.

Ten en cuenta las siguientes recomendaciones para evitar los SPOF:

Para obtener más información, consulta Diseña una infraestructura confiable para tus cargas de trabajo en Google Cloud.

Comprende y administra la disponibilidad agregada

Ten en cuenta que la disponibilidad general o agregada de un sistema se ve afectada por la disponibilidad de cada nivel o componente del sistema. La cantidad de niveles en una pila de aplicaciones tiene una relación inversa con la disponibilidad agregada de la pila. Ten en cuenta las siguientes recomendaciones para administrar la disponibilidad agregada:

  • Calcula la disponibilidad agregada de una pila de varios niveles con la fórmula disponibilidad_nivel1 × disponibilidad_nivel2 × … × disponibilidad_nivelN.

    En el siguiente diagrama, se muestra el cálculo de la disponibilidad agregada para un sistema de varios niveles que consta de cuatro servicios:

    Fórmula de disponibilidad agregada para un servicio de varios niveles que tiene cuatro servicios.

    En el diagrama anterior, el servicio de cada nivel proporciona una disponibilidad del 99.9%, pero la disponibilidad agregada del sistema es inferior, del 99.6% (0.999 × 0.999 × 0.999 × 0.999). En general, la disponibilidad agregada de una pila de varios niveles es menor que la disponibilidad del nivel que proporciona la menor disponibilidad.

  • Cuando sea posible, elige la paralelización en lugar del encadenamiento. Con los servicios paralelizados, la disponibilidad de extremo a extremo es mayor que la disponibilidad de cada servicio individual.

    En el siguiente diagrama, se muestran dos servicios, A y B, que se implementan con los enfoques de encadenamiento y paralelización:

    Las fórmulas de disponibilidad agregada para los servicios encadenados en comparación con los servicios paralelizados.

    En los ejemplos anteriores, ambos servicios tienen un ANS del 99%, lo que genera la siguiente disponibilidad agregada según el enfoque de implementación:

    • Los servicios encadenados generan una disponibilidad agregada de solo el 98% (0.99 × 0 .99).
    • Los servicios paralelizados generan una mayor disponibilidad agregada del 99.99% porque cada servicio se ejecuta de forma independiente y los servicios individuales no se ven afectados por la disponibilidad de los demás servicios. La fórmula para los servicios paralelos agregados es 1 − (1 − A) × (1 − B).
  • Elige Google Cloud servicios con ANS de tiempo de actividad que puedan ayudarte a cumplir con el nivel requerido de tiempo de actividad general para tu pila de aplicaciones.

  • Cuando diseñes tu arquitectura, considera las compensaciones entre la disponibilidad, la complejidad operativa, la latencia y el costo. Por lo general, aumentar la cantidad de nueves de disponibilidad cuesta más, pero hacerlo te ayuda a cumplir con los requisitos reglamentarios.

    Por ejemplo, una disponibilidad del 99.9% (tres nueves) significa un posible tiempo de inactividad de 86 segundos en un día de 24 horas. En cambio, el 99% (dos nueves) significa un tiempo de inactividad de 864 segundos durante el mismo período, que es 10 veces más tiempo de inactividad que con tres nueves de disponibilidad.

    En el caso de los servicios financieros críticos, las opciones de arquitectura pueden ser limitadas. Sin embargo, es fundamental identificar los requisitos de disponibilidad y calcularla con precisión. Realizar una evaluación de este tipo te ayuda a analizar las implicaciones de tus decisiones de diseño en tu arquitectura y presupuesto.

Implementa una estrategia de DR sólida

Crea planes bien definidos para diferentes situaciones de desastre, incluidas las interrupciones zonales y regionales. Una estrategia de recuperación ante desastres (DR) bien definida te permite recuperarte de una interrupción y reanudar las operaciones normales con un impacto mínimo.

La recuperación ante desastres (DR) y la alta disponibilidad (HA) son conceptos diferentes. En general, con las implementaciones en la nube, la DR se aplica a las implementaciones multirregionales y la alta disponibilidad a las implementaciones regionales. Estos arquetipos de implementación admiten diferentes mecanismos de replicación.

  • HA: Muchos servicios administrados proporcionan replicación síncrona entre zonas dentro de una sola región de forma predeterminada. Estos servicios admiten un objetivo de tiempo de recuperación (RTO) y un objetivo de punto de recuperación (RPO) de cero o casi cero. Esta compatibilidad te permite crear una topología de implementación activa-activa que no tenga ningún SPOF.
  • DR: Para las cargas de trabajo que se implementan en dos o más regiones, si no usas servicios multirregionales o globales, debes definir una estrategia de replicación. Por lo general, la estrategia de replicación es asíncrona. Evalúa cuidadosamente cómo afecta la replicación al RTO y al RPO de las aplicaciones críticas. Identifica las operaciones manuales o semiautomáticas necesarias para la conmutación por error.

En el caso de las instituciones financieras, la elección de la región de conmutación por error puede estar limitada por las reglamentaciones sobre la soberanía y la residencia de los datos. Si necesitas una topología activo-activo en dos regiones, te recomendamos que elijas servicios multirregionales administrados, como Spanner y Cloud Storage, en especial cuando la replicación de datos es fundamental.

Ten en cuenta las siguientes recomendaciones:

  • Usa servicios de almacenamiento multirregionales administrados para los datos.
  • Toma instantáneas de los datos en discos persistentes y almacénalas en ubicaciones multirregionales.
  • Cuando uses recursos regionales o zonales, configura la replicación de datos en otras regiones.
  • Valida que tus planes de DR sean eficaces probándolos con regularidad.
  • Ten en cuenta el RTO y el RPO, y su correlación con la tolerancia al impacto que estipulan las reglamentaciones financieras de tu jurisdicción.

Para obtener más información, consulta Arquitectura de recuperación ante desastres para interrupciones de infraestructura de nube.

Aprovecha los servicios administrados

Siempre que sea posible, usa servicios administrados para aprovechar las funciones integradas de copias de seguridad, alta disponibilidad y escalabilidad. Ten en cuenta las siguientes recomendaciones para usar los servicios administrados:

  • Usa servicios administrados en Google Cloud. Proporcionan alta disponibilidad respaldada por ANS. También ofrecen mecanismos de copia de seguridad y funciones de resiliencia integrados.
  • Para la administración de datos, considera servicios como Cloud SQL, Cloud Storage y Spanner.
  • Para el procesamiento y el alojamiento de aplicaciones, considera los grupos de instancias administrados (MIG) de Compute Engine y los clústeres de Google Kubernetes Engine (GKE). Los MIGs regionales y los clústeres regionales de GKE son resilientes a las interrupciones zonales.
  • Para mejorar la resiliencia ante las interrupciones regionales, usa servicios administrados multirregionales.
  • Identificar la necesidad de planes de salida para los servicios que tienen características únicas y definir los planes requeridos. Los reguladores financieros, como la FCA, la PRA y la EBA, exigen que las empresas tengan estrategias y planes de contingencia para la recuperación de datos y la continuidad operativa si finaliza la relación con un proveedor de servicios en la nube. Las empresas deben evaluar la viabilidad de la salida antes de celebrar contratos de servicios en la nube y deben mantener la capacidad de cambiar de proveedor sin interrupciones operativas.
  • Verifica que los servicios que elijas admitan la exportación de datos a un formato abierto, como CSV, Parquet y Avro. Verifica si los servicios se basan en tecnologías abiertas, como la compatibilidad de GKE con el formato de Open Container Initiative (OCI) o Cloud Composer compilado en Apache Airflow.

Automatiza los procesos de aprovisionamiento y recuperación de la infraestructura

La automatización ayuda a minimizar los errores humanos y a reducir el tiempo y los recursos necesarios para responder a los incidentes. El uso de la automatización puede ayudar a garantizar una recuperación más rápida de las fallas y resultados más coherentes. Ten en cuenta las siguientes recomendaciones para automatizar la forma en que aprovisionas y recuperas recursos:

  • Minimiza los errores humanos con herramientas de infraestructura como código (IaC) como Terraform.
  • Reducir la intervención manual automatizando los procesos de conmutación por error Las respuestas automatizadas también pueden ayudar a reducir el impacto de las fallas. Por ejemplo, puedes usar Eventarc o Workflows para activar automáticamente acciones correctivas en respuesta a los problemas observados a través de los registros de auditoría.
  • Aumenta la capacidad de tus recursos de nube durante la conmutación por error con el ajuste de escala automático.
  • Aplica automáticamente políticas y medidas de protección para los requisitos reglamentarios en toda tu topología de nube durante la implementación del servicio adoptando la ingeniería de plataformas.