Well-Architected Framework: pilar de fiabilidad

Last reviewed 2025-02-14 UTC

El pilar de fiabilidad del Google Cloud framework de arquitectura proporciona principios y recomendaciones para ayudarte a diseñar, desplegar y gestionar cargas de trabajo fiables en Google Cloud.

Este documento está dirigido a arquitectos de la nube, desarrolladores, ingenieros de plataformas, administradores e ingenieros de fiabilidad de sitios.

La fiabilidad es la capacidad de un sistema para realizar de forma constante las funciones previstas en las condiciones definidas y mantener un servicio ininterrumpido. Las prácticas recomendadas para la fiabilidad incluyen la redundancia, el diseño tolerante a fallos, la monitorización y los procesos de recuperación automatizados.

Como parte de la fiabilidad, la resistencia es la capacidad del sistema para resistir y recuperarse de fallos o interrupciones inesperadas, manteniendo el rendimiento. Las funciones deGoogle Cloud , como las implementaciones multirregionales, las copias de seguridad automáticas y las soluciones de recuperación ante desastres, pueden ayudarte a mejorar la resistencia de tu sistema.

La fiabilidad es un aspecto importante de tu estrategia en la nube por muchos motivos, entre los que se incluyen los siguientes:

  • Tiempo de inactividad mínimo: el tiempo de inactividad puede provocar pérdidas de ingresos, una disminución de la productividad y daños en la reputación. Las arquitecturas resilientes pueden ayudar a asegurar que los sistemas sigan funcionando durante los fallos o que se recuperen de ellos de forma eficiente.
  • Experiencia de usuario mejorada: los usuarios esperan interacciones fluidas con la tecnología. Los sistemas resilientes pueden ayudar a mantener un rendimiento y una disponibilidad constantes, y proporcionan un servicio fiable incluso en momentos de gran demanda o ante problemas inesperados.
  • Integridad de los datos: los fallos pueden provocar la pérdida o el daño de los datos. Los sistemas resilientes implementan mecanismos como copias de seguridad, redundancia y replicación para proteger los datos y asegurarse de que sigan siendo precisos y accesibles.
  • Continuidad empresarial: tu empresa depende de la tecnología para llevar a cabo operaciones críticas. Las arquitecturas resilientes pueden ayudar a asegurar la continuidad tras un fallo catastrófico, lo que permite que las funciones empresariales continúen sin interrupciones significativas y favorece una recuperación rápida.
  • Cumplimiento: muchos sectores tienen requisitos normativos sobre la disponibilidad del sistema y la protección de datos. Las arquitecturas resilientes pueden ayudarte a cumplir estos estándares, ya que garantizan que los sistemas sigan operativos y seguros.
  • Reducción de los costes a largo plazo: las arquitecturas resilientes requieren una inversión inicial, pero la resiliencia puede ayudar a reducir los costes con el tiempo, ya que evita los periodos de inactividad costosos, las correcciones reactivas y permite un uso más eficiente de los recursos.

Mentalidad de organización

Para que tus sistemas sean fiables, necesitas un plan y una estrategia establecida. Esta estrategia debe incluir formación y la autoridad para priorizar la fiabilidad junto con otras iniciativas.

Deja claro que toda la organización es responsable de la fiabilidad, incluidos los departamentos de desarrollo, gestión de productos, operaciones, ingeniería de plataformas y Site Reliability Engineering (SRE). Incluso los grupos centrados en la empresa, como los de marketing y ventas, pueden influir en la fiabilidad.

Todos los equipos deben conocer los objetivos de fiabilidad y los riesgos de sus aplicaciones. Los equipos deben cumplir estos requisitos. Los conflictos entre la fiabilidad y el desarrollo de funciones de productos habituales deben priorizarse y derivarse según corresponda.

Planifica y gestiona la fiabilidad de forma integral en todas tus funciones y equipos. Te recomendamos que crees un Centro de Excelencia de Cloud (CCoE) que incluya un pilar de fiabilidad. Para obtener más información, consulta el artículo Optimizar el proceso de adopción de la nube de tu organización con un Centro de Excelencia de Cloud.

Áreas de mejora de la fiabilidad

Las actividades que llevas a cabo para diseñar, implementar y gestionar un sistema fiable se pueden clasificar en las siguientes áreas de enfoque. Cada uno de los principios y las recomendaciones de fiabilidad de este pilar se relaciona con una de estas áreas.

  • Definición del ámbito: para comprender tu sistema, realiza un análisis detallado de su arquitectura. Debes conocer los componentes, cómo funcionan e interactúan, cómo fluyen los datos y las acciones por el sistema, y qué podría fallar. Identifica posibles fallos, cuellos de botella y riesgos, lo que te ayuda a tomar medidas para mitigar esos problemas.
  • Observación: Para evitar fallos en el sistema, implementa una observación y una monitorización completas y continuas. Gracias a esta observación, puedes identificar tendencias y posibles problemas de forma proactiva.
  • Respuesta: para reducir el impacto de los fallos, responde de forma adecuada y recupérate de forma eficiente. Las respuestas automatizadas también pueden ayudar a reducir el impacto de los fallos. Aunque se planifiquen y se apliquen controles, pueden producirse fallos.
  • Aprendizaje: para evitar que se repitan los fallos, aprende de cada experiencia y toma las medidas oportunas.

Principios básicos

Las recomendaciones del pilar de fiabilidad del framework Well-Architected se corresponden con los siguientes principios básicos:

Colaboradores

Autores:

Otros colaboradores:

Definir la fiabilidad en función de los objetivos de experiencia de usuario

Este principio del pilar de fiabilidad del Google Cloud framework Well-Architected te ayuda a evaluar la experiencia de tus usuarios y, a continuación, a asignar los resultados a los objetivos y las métricas de fiabilidad.

Este principio se aplica al ámbito de la fiabilidad.

Descripción general de los principios

Las herramientas de observabilidad proporcionan grandes cantidades de datos, pero no todos los datos están directamente relacionados con los efectos en los usuarios. Por ejemplo, puede que observes un uso elevado de la CPU, operaciones lentas del servidor o incluso tareas que se han bloqueado. Sin embargo, si estos problemas no afectan a la experiencia de usuario, no se consideran interrupciones.

Para medir la experiencia de usuario, debe distinguir entre el comportamiento del sistema interno y los problemas que afectan a los usuarios. Céntrate en métricas como la proporción de solicitudes de usuario que se completan con éxito. No te bases únicamente en métricas centradas en el servidor, como el uso de la CPU, ya que pueden llevarte a conclusiones erróneas sobre la fiabilidad de tu servicio. La fiabilidad verdadera significa que los usuarios pueden usar tu aplicación o servicio de forma constante y eficaz.

Recomendaciones

Para medir la experiencia de usuario de forma eficaz, ten en cuenta las recomendaciones de las siguientes secciones.

Medir la experiencia de usuario

Para comprender realmente la fiabilidad de tu servicio, prioriza las métricas que reflejen la experiencia real de tus usuarios. Por ejemplo, mide la proporción de consultas de los usuarios que se completan con éxito, la latencia de las aplicaciones y las tasas de error.

Lo ideal es recoger estos datos directamente del dispositivo o del navegador del usuario. Si esta recogida directa de datos no es viable, aleja progresivamente el punto de medición del usuario en el sistema. Por ejemplo, puedes usar el balanceador de carga o el servicio frontend como punto de medición. Este enfoque te ayuda a identificar y solucionar problemas antes de que puedan afectar significativamente a tus usuarios.

Analizar los recorridos de los usuarios

Para saber cómo interactúan los usuarios con tu sistema, puedes usar herramientas de seguimiento como Cloud Trace. Si sigues el recorrido de un usuario por tu aplicación, puedes encontrar cuellos de botella y problemas de latencia que podrían afectar negativamente a la experiencia del usuario. Cloud Trace registra datos de rendimiento detallados de cada salto de la arquitectura de tu servicio. Estos datos te ayudan a identificar y solucionar problemas de rendimiento de forma más eficiente, lo que puede mejorar la fiabilidad y la satisfacción de los usuarios.

Fija objetivos realistas de fiabilidad

Este principio del pilar de fiabilidad del Google Cloud framework Well-Architected te ayuda a definir objetivos de fiabilidad que sean técnicamente viables para tus cargas de trabajo en Google Cloud.

Este principio se aplica al ámbito de la fiabilidad.

Descripción general de los principios

Diseña tus sistemas para que sean lo suficientemente fiables como para que los usuarios estén contentos. Puede parecer contradictorio, pero un objetivo de fiabilidad del 100% no suele ser la estrategia más eficaz. Una mayor fiabilidad puede suponer un coste significativamente más alto, tanto en términos de inversión financiera como de posibles limitaciones en la innovación. Si los usuarios ya están satisfechos con el nivel de servicio actual, los esfuerzos para aumentar aún más su satisfacción pueden dar lugar a un bajo retorno de la inversión. En su lugar, puedes invertir mejor los recursos en otros ámbitos.

Debes determinar el nivel de fiabilidad con el que tus usuarios están satisfechos y el punto en el que el coste de las mejoras incrementales empieza a superar los beneficios. Cuando determines este nivel de fiabilidad suficiente, podrás asignar recursos de forma estratégica y centrarte en las funciones y las mejoras que aporten más valor a tus usuarios.

Recomendaciones

Para definir objetivos de fiabilidad realistas, ten en cuenta las recomendaciones de las siguientes subsecciones.

Acepta algunos errores y prioriza los componentes

Intenta conseguir una alta disponibilidad, como un tiempo de actividad del 99,99 %, pero no fijes un objetivo del 100 %. Reconoce que algunos fracasos son inevitables.

La diferencia entre el 100% de tiempo de actividad y el objetivo del 99,99% es el margen de error. Esta diferencia se suele denominar presupuesto de errores. El presupuesto de errores puede ayudarte a asumir riesgos e innovar, lo cual es fundamental para que cualquier empresa siga siendo competitiva.

Prioriza la fiabilidad de los componentes más importantes del sistema. Acepta que los componentes menos críticos pueden tener una mayor tolerancia a los fallos.

Equilibra la fiabilidad y el coste

Para determinar el nivel de fiabilidad óptimo de tu sistema, realiza análisis exhaustivos de costes y beneficios.

Ten en cuenta factores como los requisitos del sistema, las consecuencias de los fallos y la tolerancia al riesgo de tu organización para la aplicación específica. No olvides tener en cuenta las métricas de recuperación tras desastres, como el objetivo de tiempo de recuperación (RTO) y el objetivo de punto de recuperación (RPO). Decide qué nivel de fiabilidad es aceptable dentro del presupuesto y otras restricciones.

Busca formas de mejorar la eficiencia y reducir los costes sin poner en riesgo las funciones de fiabilidad esenciales.

Crear sistemas de alta disponibilidad mediante la redundancia de recursos

Este principio del pilar de fiabilidad del Google Cloud framework Well-Architected proporciona recomendaciones para planificar, crear y gestionar la redundancia de recursos, lo que puede ayudarte a evitar fallos.

Este principio se aplica al ámbito de la fiabilidad.

Descripción general de los principios

Una vez que hayas decidido el nivel de fiabilidad que necesitas, debes diseñar tus sistemas para evitar cualquier punto único de fallo. Todos los componentes críticos del sistema deben replicarse en varias máquinas, zonas y regiones. Por ejemplo, una base de datos crítica no puede estar ubicada en una sola región y un servidor de metadatos no puede desplegarse en una sola zona o región. En esos ejemplos, si la única zona o región tiene una interrupción, el sistema tiene una interrupción global.

Recomendaciones

Para crear sistemas redundantes, ten en cuenta las recomendaciones de las siguientes subsecciones.

Identificar dominios de error y replicar servicios

Define los dominios de los fallos de tu sistema, desde las máquinas virtuales individuales hasta las regiones, y diseña la redundancia en los dominios de los fallos.

Para asegurar una alta disponibilidad, distribuye y replica tus servicios y aplicaciones en varias zonas y regiones. Configura el sistema para que se produzca una conmutación por error automática y asegúrate de que los servicios y las aplicaciones sigan estando disponibles en caso de que se produzcan interrupciones en una zona o una región.

Para ver ejemplos de arquitecturas multizona y multirregión, consulta Diseñar una infraestructura fiable para las cargas de trabajo en Google Cloud.

Detectar y solucionar problemas rápidamente

Monitoriza continuamente el estado de tus dominios de error para detectar y solucionar problemas rápidamente.

Puedes monitorizar el estado actual de los Google Cloud servicios en todas las regiones mediante el Google Cloud panel de control Service Health. También puedes ver los incidentes relacionados con tu proyecto en Personalized Service Health. Puedes usar balanceadores de carga para detectar el estado de los recursos y enrutar automáticamente el tráfico a los backends en buen estado. Para obtener más información, consulta el artículo Introducción a las comprobaciones del estado.

Probar escenarios de conmutación por error

Al igual que en un simulacro de incendio, simula fallos periódicamente para validar la eficacia de tus estrategias de replicación y conmutación por error.

Para obtener más información, consulta Simular una interrupción de la zona en un MIG regional y Simular un fallo de zona en clústeres regionales de GKE.

Aprovechar la escalabilidad horizontal

Este principio del pilar de fiabilidad del Google Cloud framework de arquitectura óptima proporciona recomendaciones para ayudarte a usar la escalabilidad horizontal. Si usas la escalabilidad horizontal, puedes asegurarte de que tus cargas de trabajo enGoogle Cloud se escalen de forma eficiente y mantengan el rendimiento.

Este principio se aplica al ámbito de la fiabilidad.

Descripción general de los principios

Rediseña tu sistema para que tenga una arquitectura horizontal. Para adaptarse al aumento del tráfico o de los datos, puede añadir más recursos. También puedes quitar recursos cuando no los estés usando.

Para entender el valor del escalado horizontal, ten en cuenta las limitaciones del escalado vertical.

Un caso habitual de escalado vertical es usar una base de datos MySQL como base de datos principal con datos críticos. A medida que aumenta el uso de la base de datos, se necesita más RAM y CPU. Con el tiempo, la base de datos alcanza el límite de memoria en el host y debe actualizarse. Es posible que tengas que repetir este proceso varias veces. El problema es que hay límites estrictos en la cantidad que puede crecer una base de datos. Los tamaños de las máquinas virtuales no son ilimitados. La base de datos puede llegar a un punto en el que ya no sea posible añadir más recursos.

Aunque los recursos fueran ilimitados, una VM grande puede convertirse en un único punto de fallo. Cualquier problema con la VM de la base de datos principal puede provocar respuestas de error o una interrupción en todo el sistema que afecte a todos los usuarios. Evita los puntos únicos de fallo, tal como se describe en el artículo Crea sistemas de alta disponibilidad mediante la redundancia de recursos.

Además de estos límites de escalado, el escalado vertical suele ser más caro. El coste puede aumentar de forma exponencial a medida que se adquieren máquinas con mayor potencia de cálculo y memoria.

Por el contrario, el escalado horizontal puede costar menos. El potencial de escalado horizontal es prácticamente ilimitado en un sistema diseñado para escalarse.

Recomendaciones

Para pasar de una arquitectura de una sola máquina virtual a una arquitectura horizontal de varias máquinas, debes planificarlo con cuidado y usar las herramientas adecuadas. Para ayudarte a conseguir un escalado horizontal, ten en cuenta las recomendaciones de las siguientes subsecciones.

Usar servicios gestionados

Los servicios gestionados eliminan la necesidad de gestionar manualmente el escalado horizontal. Por ejemplo, con los grupos de instancias administradas (MIGs) de Compute Engine, puedes añadir o quitar VMs para escalar tu aplicación horizontalmente. En el caso de las aplicaciones en contenedores, Cloud Run es una plataforma sin servidor que puede escalar automáticamente tus contenedores sin reconocimiento del estado en función del tráfico entrante.

Promocionar el diseño modular

Los componentes modulares y las interfaces claras te ayudan a adaptar los componentes individuales según sea necesario, en lugar de adaptar toda la aplicación. Para obtener más información, consulta la sección Promover el diseño modular del pilar de optimización del rendimiento.

Implementar un diseño sin reconocimiento del estado

Diseña las aplicaciones para que no tengan estado, es decir, que no almacenen datos de forma local. De esta forma, puedes añadir o quitar instancias sin preocuparte por la coherencia de los datos.

Detectar posibles fallos mediante la observabilidad

Este principio del pilar de fiabilidad del Google Cloud marco de trabajo Well-Architected ofrece recomendaciones para ayudarte a identificar de forma proactiva las áreas en las que pueden producirse errores y fallos.

Este principio se aplica al área de enfoque de la observación de la fiabilidad.

Descripción general de los principios

Para mantener y mejorar la fiabilidad de tus cargas de trabajo enGoogle Cloud, debes implementar una observabilidad eficaz mediante métricas, registros y trazas.

  • Las métricas son medidas numéricas de las actividades que quieres monitorizar en tu aplicación en intervalos de tiempo específicos. Por ejemplo, puede que quieras monitorizar métricas técnicas como la tasa de solicitudes y la tasa de errores, que se pueden usar como indicadores de nivel de servicio (SLIs). También puede que tengas que monitorizar métricas de negocio específicas de la aplicación, como los pedidos realizados y los pagos recibidos.
  • Los registros son registros con marca de tiempo de eventos discretos que se producen en una aplicación o un sistema. El evento puede ser un fallo, un error o un cambio de estado. Los registros pueden incluir métricas y también se pueden usar para los SLIs.
  • Una traza representa el recorrido de un solo usuario o transacción a través de varias aplicaciones independientes o de los componentes de una aplicación. Por ejemplo, estos componentes podrían ser microservicios. Los rastreos te ayudan a monitorizar qué componentes se han usado en los recorridos, dónde hay cuellos de botella y cuánto han durado los recorridos.

Las métricas, los registros y las trazas te ayudan a monitorizar tu sistema de forma continua. La monitorización integral te ayuda a averiguar dónde y por qué se han producido los errores. También puedes detectar posibles fallos antes de que se produzcan errores.

Recomendaciones

Para detectar posibles fallos de forma eficiente, tenga en cuenta las recomendaciones de las siguientes subsecciones.

Obtener estadísticas completas

Para monitorizar métricas clave, como los tiempos de respuesta y las tasas de error, usa Cloud Monitoring y Cloud Logging. Estas herramientas también te ayudan a asegurarte de que las métricas cumplen constantemente los requisitos de tu carga de trabajo.

Para tomar decisiones basadas en datos, analiza las métricas de servicio predeterminadas para comprender las dependencias de los componentes y su impacto en el rendimiento general de la carga de trabajo.

Para personalizar tu estrategia de monitorización, crea y publica tus propias métricas con el SDK de Google Cloud.

Solucionar problemas de forma proactiva

Implementa un control de errores sólido y habilita el registro en todos los componentes de tus cargas de trabajo en Google Cloud. Activa registros como los registros de acceso a Cloud Storage y los registros de flujo de VPC.

Cuando configure el registro, tenga en cuenta los costes asociados. Para controlar los costes de registro, puedes configurar filtros de exclusión en los sumideros de registros para evitar que se almacenen determinados registros.

Optimizar el uso de los recursos

Monitoriza el consumo de CPU y las métricas de E/ de red y de disco para detectar recursos insuficientes y excesivos en servicios como GKE, Compute Engine y Dataproc. Para ver una lista completa de los servicios admitidos, consulta la descripción general de Cloud Monitoring.

Priorizar alertas

En el caso de las alertas, céntrate en las métricas críticas, define umbrales adecuados para minimizar la fatiga de alertas y asegúrate de responder a tiempo a los problemas importantes. Este enfoque específico te permite mantener la fiabilidad de las cargas de trabajo de forma proactiva. Para obtener más información, consulta el resumen de las alertas.

Diseñar para una degradación gradual

Este principio del pilar de fiabilidad del Google Cloud framework Well-Architected proporciona recomendaciones para ayudarte a diseñar tus Google Cloud cargas de trabajo de forma que fallen correctamente.

Este principio se aplica al ámbito de la respuesta de la fiabilidad.

Descripción general de los principios

La degradación gradual es un enfoque de diseño en el que un sistema que experimenta una carga elevada sigue funcionando, aunque posiblemente con un rendimiento o una precisión reducidos. La degradación gradual asegura la disponibilidad continua del sistema y evita que falle por completo, aunque el sistema no funcione de forma óptima. Cuando la carga vuelve a un nivel gestionable, el sistema recupera todas sus funciones.

Por ejemplo, durante los periodos de carga elevada, la Búsqueda de Google da prioridad a los resultados de las páginas web con un ranking más alto, lo que puede suponer una pérdida de precisión. Cuando la carga disminuye, la Búsqueda de Google vuelve a calcular los resultados de búsqueda.

Recomendaciones

Para diseñar tus sistemas de forma que se degraden sin problemas, ten en cuenta las recomendaciones de las siguientes subsecciones.

Implementar la limitación

Asegúrate de que tus réplicas puedan gestionar las sobrecargas de forma independiente y limitar las solicitudes entrantes en situaciones de mucho tráfico. Este enfoque te ayuda a evitar errores en cascada causados por cambios en el exceso de tráfico entre zonas.

Usa herramientas como Apigee para controlar la frecuencia de las solicitudes a la API en momentos de mucho tráfico. Puede configurar reglas de política para reflejar cómo quiere reducir las solicitudes.

Rechazar solicitudes excesivas pronto

Configura tus sistemas para que rechacen las solicitudes excesivas en la capa de frontend y así proteger los componentes del backend. Si se rechazan algunas solicitudes, se evitan los fallos globales y el sistema puede recuperarse de forma más fluida.Con esta estrategia, es posible que algunos usuarios experimenten errores. Sin embargo, puedes minimizar el impacto de las interrupciones, a diferencia de un enfoque como el de interrupción de circuitos, donde todo el tráfico se descarta durante una sobrecarga.

Gestionar errores parciales y reintentos

Crea tus aplicaciones para que gestionen los errores parciales y los reintentos sin problemas. Este diseño ayuda a garantizar que se sirva la mayor cantidad de tráfico posible en situaciones de carga elevada.

Probar situaciones de sobrecarga

Para validar que los mecanismos de limitación y de rechazo de solicitudes funcionan correctamente, simula periódicamente condiciones de sobrecarga en tu sistema. Las pruebas ayudan a asegurar que tu sistema esté preparado para los picos de tráfico reales.

Monitorizar picos de tráfico

Usa herramientas de analíticas y monitorización para predecir y responder a los picos de tráfico antes de que se conviertan en sobrecargas. La detección y la respuesta tempranas pueden ayudar a mantener la disponibilidad del servicio durante los periodos de gran demanda.

Realizar pruebas de recuperación tras fallos

Este principio del pilar de fiabilidad del Google Cloud framework Well-Architected proporciona recomendaciones para ayudarte a diseñar y ejecutar pruebas de recuperación en caso de fallos.

Este principio se aplica al área de aprendizaje de la fiabilidad.

Descripción general de los principios

Para asegurarte de que tu sistema puede recuperarse de los fallos, debes realizar periódicamente pruebas que incluyan conmutaciones por error regionales, reversiones de lanzamientos y restauración de datos a partir de copias de seguridad.

Estas pruebas te ayudan a practicar las respuestas a eventos que suponen un riesgo importante para la fiabilidad, como la interrupción del servicio en toda una región. Estas pruebas también te ayudan a verificar que tu sistema se comporta como debería durante una interrupción.

En el improbable caso de que se produzca una interrupción del servicio en toda una región, debes conmutar por error todo el tráfico a otra región. Durante el funcionamiento normal de tu carga de trabajo, cuando se modifican los datos, deben sincronizarse de la región principal a la de conmutación por error. Debes verificar que los datos replicados sean siempre muy recientes para que los usuarios no sufran pérdidas de datos ni interrupciones de sesión. El sistema de balanceo de carga también debe poder desviar el tráfico a la región de conmutación por error en cualquier momento sin que se produzcan interrupciones en el servicio. Para minimizar el tiempo de inactividad después de un fallo regional, los ingenieros de operaciones también deben poder desviar el tráfico de usuarios de una región de forma manual y eficiente en el menor tiempo posible. Esta operación se denomina a veces desactivación de una región, lo que significa que detienes el tráfico entrante a la región y lo trasladas a otro lugar.

Recomendaciones

Cuando diseñes y ejecutes pruebas de recuperación tras fallos, ten en cuenta las recomendaciones de las siguientes subsecciones.

Definir los objetivos y el alcance de las pruebas

Define claramente qué quieres conseguir con las pruebas. Por ejemplo, tus objetivos pueden incluir lo siguiente:

  • Valida el objetivo de tiempo de recuperación (RTO) y el objetivo de punto de recuperación (RPO). Para obtener más información, consulta el artículo Conceptos básicos de la planificación de la recuperación ante desastres.
  • Evalúa la resiliencia y la tolerancia a fallos del sistema en diferentes situaciones de fallo.
  • Prueba la eficacia de los mecanismos de conmutación por error automatizados.

Decide qué componentes, servicios o regiones se incluirán en las pruebas. El ámbito puede incluir niveles de aplicación específicos, como el frontend, el backend y la base de datos, o recursos específicos, como instancias de Cloud SQL o clústeres de GKE. Google Cloud El ámbito también debe especificar las dependencias externas, como las APIs de terceros o las interconexiones en la nube.

Preparar el entorno para las pruebas

Elige un entorno adecuado, preferiblemente un entorno de staging o de pruebas, que replique tu configuración de producción. Si realizas la prueba en producción, asegúrate de tener listas medidas de seguridad, como la monitorización automatizada y los procedimientos de reversión manual.

Crea un plan de copia de seguridad. Haz copias de seguridad o instantáneas de las bases de datos y los servicios críticos para evitar la pérdida de datos durante la prueba. Asegúrate de que tu equipo esté preparado para realizar intervenciones manuales si fallan los mecanismos de conmutación por error automatizados.

Para evitar interrupciones en las pruebas, asegúrese de que los roles y las políticas de gestión de identidades y accesos, así como las configuraciones de conmutación por error, estén configurados correctamente. Verifica que se hayan concedido los permisos necesarios a las herramientas y las secuencias de comandos de prueba.

Informa a las partes interesadas, como los equipos de operaciones, DevOps y los propietarios de las aplicaciones, sobre la programación, el alcance y el posible impacto de las pruebas. Proporciona a las partes interesadas una cronología estimada y los comportamientos esperados durante la prueba.

Simular situaciones de fallo

Planifica y ejecuta fallos con herramientas como Chaos Monkey. Puedes usar secuencias de comandos personalizadas para simular fallos de servicios críticos, como el cierre de un nodo principal en un clúster de GKE multizona o una instancia de Cloud SQL inhabilitada. También puedes usar secuencias de comandos para simular una interrupción de la red en toda una región mediante reglas de cortafuegos o restricciones de API en función del ámbito de la prueba. Aumenta gradualmente los casos de fallo para observar el comportamiento del sistema en diferentes condiciones.

Introduce pruebas de carga junto con situaciones de fallo para replicar el uso real durante las interrupciones. Prueba los efectos de los fallos en cascada, como el comportamiento de los sistemas de frontend cuando los servicios de backend no están disponibles.

Para validar los cambios en la configuración y evaluar la resiliencia del sistema frente a errores humanos, prueba situaciones que impliquen configuraciones incorrectas. Por ejemplo, ejecuta pruebas con ajustes de conmutación por error de DNS incorrectos o permisos de IAM incorrectos.

Monitorizar el comportamiento del sistema

Monitoriza cómo los balanceadores de carga, las comprobaciones del estado y otros mecanismos redirigen el tráfico. Usa Google Cloud herramientas como Cloud Monitoring y Cloud Logging para registrar métricas y eventos durante la prueba.

Observa los cambios en la latencia, las tasas de errores y el rendimiento durante y después de la simulación de fallos, y monitoriza el impacto general en el rendimiento. Identifica cualquier degradación o incoherencia en la experiencia de usuario.

Asegúrate de que se generen registros y se activen alertas para eventos clave, como interrupciones de servicio o conmutaciones por error. Utilice estos datos para verificar la eficacia de sus sistemas de alertas y de respuesta a incidentes.

Verificar la recuperación en función de los objetivos de tiempo de recuperación y de punto de recuperación

Mide el tiempo que tarda el sistema en volver a funcionar con normalidad después de un fallo y, a continuación, compara estos datos con el RTO definido y documenta las diferencias.

Asegúrate de que la integridad y la disponibilidad de los datos se ajusten al RPO. Para probar la coherencia de la base de datos, compara las copias o las copias de seguridad de la base de datos antes y después de un fallo.

Evalúa la restauración del servicio y confirma que todos los servicios se han restaurado a un estado funcional con una interrupción mínima para los usuarios.

Documentar y analizar los resultados

Documenta cada paso de la prueba, cada caso de error y el comportamiento del sistema correspondiente. Incluye marcas de tiempo, registros y métricas para realizar análisis detallados.

Destaca los cuellos de botella, los puntos únicos de fallo o los comportamientos inesperados que se hayan observado durante la prueba. Para priorizar las correcciones, categoriza los problemas por gravedad e impacto.

Sugerir mejoras en la arquitectura del sistema, los mecanismos de conmutación por error o las configuraciones de monitorización. Según los resultados de las pruebas, actualice las políticas de conmutación por error y los manuales pertinentes. Presenta un informe post mortem a las partes interesadas. El informe debe resumir los resultados, las lecciones aprendidas y los próximos pasos. Para obtener más información, consulta Realizar análisis post mortem exhaustivos.

Repetir y mejorar

Para validar la fiabilidad y la resiliencia continuas, planifica pruebas periódicas (por ejemplo, trimestrales).

Realiza pruebas en diferentes situaciones, como cambios en la infraestructura, actualizaciones de software y aumento de las cargas de tráfico.

Automatiza las pruebas de conmutación por error usando las cadenas de CI/CD para integrar las pruebas de fiabilidad en tu ciclo de vida de desarrollo.

Durante el análisis post mortem, utiliza los comentarios de las partes interesadas y los usuarios finales para mejorar el proceso de prueba y la resiliencia del sistema.

Realizar pruebas de recuperación tras una pérdida de datos

Este principio del pilar de fiabilidad del Google Cloud marco de trabajo Well-Architected ofrece recomendaciones para ayudarte a diseñar y ejecutar pruebas de recuperación tras una pérdida de datos.

Este principio se aplica al área de aprendizaje de la fiabilidad.

Descripción general de los principios

Para asegurarte de que tu sistema puede recuperarse en situaciones en las que se pierden o dañan datos, debes realizar pruebas en esos casos. Los casos de pérdida de datos pueden deberse a un error de software o a algún tipo de desastre natural. Después de estos eventos, debes restaurar los datos a partir de las copias de seguridad y volver a poner en marcha todos los servicios con los datos recién restaurados.

Te recomendamos que utilices tres criterios para determinar si este tipo de prueba de recuperación se ha realizado correctamente o no: integridad de los datos, tiempo de recuperación objetivo (RTO) y punto de recuperación objetivo (RPO). Para obtener más información sobre las métricas de RTO y RPO, consulta Conceptos básicos de la planificación de recuperación ante desastres.

El objetivo de las pruebas de restauración de datos es verificar periódicamente que tu organización puede seguir cumpliendo los requisitos de continuidad empresarial. Además de medir el RTO y el RPO, una prueba de restauración de datos debe incluir pruebas de toda la pila de aplicaciones y de todos los servicios de infraestructura críticos con los datos restaurados. Esto es necesario para confirmar que toda la aplicación implementada funciona correctamente en el entorno de prueba.

Recomendaciones

Cuando diseñes y ejecutes pruebas para recuperarte de una pérdida de datos, ten en cuenta las recomendaciones de las siguientes subsecciones.

Verificar la coherencia de las copias de seguridad y probar los procesos de restauración

Debes verificar que tus copias de seguridad contengan capturas coherentes y utilizables de los datos que puedas restaurar para que las aplicaciones vuelvan a estar operativas inmediatamente. Para validar la integridad de los datos, configura comprobaciones de coherencia automatizadas que se ejecuten después de cada copia de seguridad.

Para probar las copias de seguridad, restáuralas en un entorno que no sea de producción. Para asegurarte de que las copias de seguridad se pueden restaurar de forma eficiente y de que los datos restaurados cumplen los requisitos de las aplicaciones, simula periódicamente escenarios de recuperación de datos. Documenta los pasos para restaurar los datos y forma a tus equipos para que los ejecuten de forma eficaz en caso de fallo.

Programa copias de seguridad periódicas y frecuentes

Para minimizar la pérdida de datos durante la restauración y cumplir los objetivos de RPO, es fundamental programar copias de seguridad periódicas. Establece una frecuencia de copia de seguridad que se ajuste a tu RPO. Por ejemplo, si tu RPO es de 15 minutos, programa las copias de seguridad para que se ejecuten al menos cada 15 minutos. Optimiza los intervalos de las copias de seguridad para reducir el riesgo de pérdida de datos.

Usa Google Cloud herramientas como Cloud Storage, copias de seguridad automáticas de Cloud SQL o copias de seguridad de Spanner para programar y gestionar copias de seguridad. En el caso de las aplicaciones críticas, usa soluciones de copia de seguridad casi continua, como la recuperación a un momento dado (PITR) de Cloud SQL o las copias de seguridad incrementales para conjuntos de datos de gran tamaño.

Definir y monitorizar el RPO

Define un RPO claro en función de las necesidades de tu empresa y monitoriza el cumplimiento del RPO. Si los intervalos de copia de seguridad superan el RPO definido, usa Cloud Monitoring para configurar alertas.

Monitorizar el estado de las copias de seguridad

Usa el Google Cloud servicio de copia de seguridad y recuperación ante desastres u otras herramientas similares para monitorizar el estado de tus copias de seguridad y confirmar que se almacenan en ubicaciones seguras y fiables. Asegúrate de que las copias de seguridad se repliquen en varias regiones para aumentar la resiliencia.

Planificar situaciones que van más allá de la copia de seguridad

Combina las copias de seguridad con estrategias de recuperación tras fallos, como configuraciones de conmutación por error activo-activo o replicación multirregional, para mejorar el tiempo de recuperación en casos extremos. Para obtener más información, consulta la guía de planificación para la recuperación tras fallos.

Realizar análisis post mortem exhaustivos

Este principio del pilar de fiabilidad del Google Cloud marco de trabajo bien diseñado proporciona recomendaciones para ayudarte a llevar a cabo análisis post mortem eficaces después de fallos e incidentes.

Este principio se aplica al área de aprendizaje de la fiabilidad.

Descripción general de los principios

Un informe post mortem es un registro escrito de un incidente, su impacto, las medidas tomadas para mitigar o resolver el incidente, las causas principales y las medidas de seguimiento para evitar que se repita. El objetivo de un análisis post mortem es aprender de los errores y no culpar a nadie.

En el siguiente diagrama se muestra el flujo de trabajo de un análisis post mortem:

El flujo de trabajo de un análisis post mortem.

El flujo de trabajo de un análisis post mortem incluye los siguientes pasos:

  • Crear un informe post mortem
  • Captura los hechos
  • Identificar y analizar las causas principales
  • Planifica el futuro
  • Ejecutar el plan

Realiza análisis post mortem después de eventos importantes y no importantes, como los siguientes:

  • Tiempos de inactividad o degradaciones visibles para los usuarios que superen un umbral determinado.
  • Pérdida de datos de cualquier tipo.
  • Intervenciones de ingenieros de guardia, como la reversión de una versión o el desvío del tráfico.
  • Tiempos de resolución superiores a un umbral definido.
  • Fallos de monitorización, que suelen implicar la detección manual de incidentes.

Recomendaciones

Define los criterios de análisis post mortem antes de que se produzca un incidente para que todos sepan cuándo es necesario realizar un análisis post mortem.

Para llevar a cabo análisis post mortem eficaces, ten en cuenta las recomendaciones de las siguientes subsecciones.

Realizar análisis post mortem sin buscar culpables

Las post mortem eficaces se centran en los procesos, las herramientas y las tecnologías, y no culpan a personas ni a equipos. El objetivo de un análisis post mortem es mejorar tu tecnología y tu futuro, no encontrar al culpable. Todos cometemos errores. El objetivo debe ser analizar los errores y aprender de ellos.

En los siguientes ejemplos se muestra la diferencia entre los comentarios que atribuyen la culpa y los que no:

  • Comentarios que atribuyen la culpa: "Tenemos que volver a escribir todo el complicado sistema backend. Se ha estado rompiendo semanalmente durante los últimos tres trimestres y estoy seguro de que todos estamos cansados de arreglar las cosas poco a poco. En serio, si me avisan una vez más, lo reescribiré yo mismo".
  • Comentarios sin culpabilizar: "Una tarea para reescribir todo el sistema backend podría evitar que se sigan produciendo estos errores. El manual de mantenimiento de esta versión es bastante largo y resulta muy difícil aprenderlo por completo. Seguro que nuestros futuros ingenieros de guardia nos lo agradecerán".

Redactar el informe post mortem de forma que sea legible para todas las audiencias a las que va dirigido

Por cada información que quieras incluir en el informe, evalúa si es importante y necesaria para que el público entienda lo que ha ocurrido. Puedes mover los datos complementarios y las explicaciones a un apéndice del informe. Los revisores que necesiten más información pueden solicitarla.

Evita las soluciones complejas o demasiado elaboradas

Antes de empezar a buscar soluciones para un problema, evalúa su importancia y la probabilidad de que vuelva a ocurrir. Añadir complejidad al sistema para resolver problemas que es poco probable que vuelvan a ocurrir puede provocar una mayor inestabilidad.

Comparte el análisis post mortem lo más ampliamente posible

Para asegurarte de que los problemas no queden sin resolver, publica los resultados del análisis post mortem para una audiencia amplia y pide ayuda a la dirección. El valor de un análisis post mortem es proporcional al aprendizaje que se produce después de él. Cuando más personas aprendan de los incidentes, menor será la probabilidad de que se produzcan fallos similares.