Well-Architected Framework: Pilar de confiabilidad

Last reviewed 2026-10-27 UTC

El pilar de confiabilidad en el Well-Architected Framework deGoogle Cloud proporciona principios y recomendaciones para ayudarte a diseñar, implementar y administrar cargas de trabajo confiables en Google Cloud.

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

La confiabilidad es la capacidad de un sistema para realizar de forma coherente sus funciones previstas dentro de las condiciones definidas y mantener un servicio ininterrumpido. Las prácticas recomendadas para la confiabilidad incluyen la redundancia, el diseño tolerante a errores, la supervisión y los procesos de recuperación automatizados.

Como parte de la confiabilidad, la resiliencia es la capacidad del sistema para resistir y recuperarse de fallas o interrupciones inesperadas, mientras se mantiene el rendimiento. Las funciones deGoogle Cloud , como las implementaciones multirregionales, las copias de seguridad automatizadas y las soluciones de recuperación ante desastres, pueden ayudarte a mejorar la resiliencia de tu sistema.

La confiabilidad es importante para tu estrategia de nube por muchos motivos, incluidos 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 garantizar que los sistemas sigan funcionando durante las fallas o se recuperen de manera eficiente de ellas.
  • Experiencia del 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 confiable incluso durante una alta demanda o problemas inesperados.
  • Integridad de los datos: Las fallas pueden causar 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 garantizar que sigan siendo precisos y accesibles.
  • Continuidad empresarial: Tu empresa depende de la tecnología para las operaciones críticas. Las arquitecturas resilientes pueden ayudar a garantizar la continuidad después de una falla catastrófica, lo que permite que las funciones empresariales continúen sin interrupciones significativas y respalda una recuperación rápida.
  • Cumplimiento: Muchas industrias tienen requisitos reglamentarios para la disponibilidad del sistema y la protección de datos. Las arquitecturas resilientes pueden ayudarte a cumplir con estos estándares, ya que garantizan que los sistemas sigan operativos y seguros.
  • Menores costos a largo plazo: Las arquitecturas resilientes requieren una inversión inicial, pero la resiliencia puede ayudar a reducir los costos con el tiempo, ya que evita el tiempo de inactividad costoso, evita las correcciones reactivas y permite un uso más eficiente de los recursos.

Mentalidad organizacional

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

Establece una expectativa clara de que toda la organización es responsable de la confiabilidad, incluidos los equipos de desarrollo, administración de productos, operaciones, ingeniería de plataformas y ingeniería de confiabilidad de sitios (SRE). Incluso los grupos enfocados en el negocio, como marketing y ventas, pueden influir en la confiabilidad.

Cada equipo debe comprender los objetivos de confiabilidad y los riesgos de sus aplicaciones. Los equipos deben ser responsables de estos requisitos. Los conflictos entre la confiabilidad y el desarrollo de las funciones del producto deben priorizarse y escalarse según corresponda.

Planifica y administra la confiabilidad de manera integral en todas tus funciones y equipos. Considera configurar un Centro de excelencia para la nube (CCoE) que incluya un pilar de confiabilidad. Para obtener más información, consulta Optimiza el recorrido de tu organización hacia la nube con un centro de excelencia para la nube.

Áreas de enfoque para la confiabilidad

Las actividades que realizas para diseñar, implementar y administrar un sistema confiable se pueden categorizar en las siguientes áreas de enfoque. Cada uno de los principios y recomendaciones de confiabilidad de este pilar es relevante para una de estas áreas de enfoque.

  • Alcance: Para comprender tu sistema, realiza un análisis detallado de su arquitectura. Debes comprender los componentes, cómo funcionan y cómo interactúan, cómo fluyen los datos y las acciones por el sistema, y qué podría salir mal. Identifica posibles fallas, cuellos de botella y riesgos, lo que te ayuda a tomar medidas para mitigar esos problemas.
  • Observación: Para ayudar a evitar fallas del sistema, implementa una observación y una supervisión integrales y continuas. A través de esta observación, puedes comprender las tendencias y, de forma proactiva, identificar posibles problemas.
  • Respuesta: Para reducir el impacto de las fallas, responde de forma adecuada y recupérate de manera eficiente. Las respuestas automatizadas también pueden ayudar a reducir el impacto de las fallas. Incluso con planificación y controles, pueden producirse fallas.
  • Aprendizaje: Para evitar que se repitan las fallas, aprende de cada experiencia y toma las medidas adecuadas.

Evalúa las cargas de trabajo con una habilidad de agente

Para permitir que los agentes de IA evalúen tus cargas de trabajo en la nube en función de los principios y las recomendaciones de este pilar, usa la habilidad de google-cloud-waf-reliability, que está disponible en el repositorio de habilidades de agentes de Google en GitHub.

Para instalar la habilidad, ejecuta el siguiente comando en el cliente o la terminal de tu agente:

npx skills add google/skills --skill google-cloud-waf-reliability

Cuando se te solicite, especifica los agentes de IA para los que deseas instalar la habilidad y establece el alcance de la instalación (proyecto o global).

Si ya instalaste la habilidad, puedes actualizarla a la versión más reciente ejecutando el siguiente comando:

npx skills update

Principios básicos

Las recomendaciones del pilar de confiabilidad del Well-Architected Framework se asignan a los siguientes principios fundamentales:

Colaboradores

Autores:

Otros colaboradores:

Define la confiabilidad en función de los objetivos de la experiencia del usuario

Este principio del pilar de confiabilidad del Well-Architected FrameworkGoogle Cloud te ayuda a evaluar la experiencia de tus usuarios y, luego, asignar los hallazgos a objetivos y métricas de confiabilidad.

Este principio es relevante para el área de enfoque de alcance de la confiabilidad.

Descripción general del principio

Las herramientas de observabilidad proporcionan grandes cantidades de datos, pero no todos se relacionan directamente con los impactos en los usuarios. Por ejemplo, puedes observar un uso elevado de la CPU, operaciones lentas del servidor o incluso tareas con fallas. Sin embargo, si estos problemas no afectan la experiencia del usuario, no constituyen una interrupción.

Para medir la experiencia del usuario, debes distinguir entre el comportamiento interno del sistema y los problemas que afectan al usuario. Enfócate en métricas como la proporción de éxito de las solicitudes de los usuarios. No dependas solo de las métricas centradas en el servidor, como el uso de CPU, ya que pueden llevar a conclusiones engañosas sobre la confiabilidad de tu servicio. La confiabilidad verdadera significa que los usuarios pueden usar tu aplicación o servicio de manera coherente y eficaz.

Recomendaciones

Para ayudarte a medir la experiencia del usuario de manera eficaz, ten en cuenta las recomendaciones de las siguientes secciones.

Mide la experiencia del usuario

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

Lo ideal es recopilar estos datos directamente del dispositivo o navegador del usuario. Si esta recopilación de datos directa no es factible, aleja progresivamente el punto de medición del usuario en el sistema. Por ejemplo, puedes usar el balanceador de cargas o el servicio de frontend como punto de medición. Este enfoque te ayuda a identificar y abordar los problemas antes de que puedan afectar de forma significativa a tus usuarios.

Analiza los recorridos de los usuarios

Para comprender 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 degradar la experiencia del usuario. Trace captura datos de rendimiento detallados para cada salto en la arquitectura de tu servicio. Estos datos te ayudan a identificar y abordar los problemas de rendimiento de manera más eficiente, lo que puede generar una experiencia del usuario más confiable y satisfactoria.

Establece objetivos realistas para la confiabilidad

Este principio del pilar de confiabilidad del Framework de buena arquitectura deGoogle Cloud te ayuda a definir objetivos de confiabilidad que sean técnicamente viables para tus cargas de trabajo en Google Cloud.

Este principio es relevante para el área de enfoque de alcance de la confiabilidad.

Descripción general del principio

Diseña tus sistemas para que sean lo suficientemente confiables para la satisfacción de los usuarios. Puede parecer contradictorio, pero un objetivo de confiabilidad del 100% no suele ser la estrategia más eficaz. Una mayor confiabilidad puede generar un costo 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 la satisfacción podrían generar un bajo retorno de la inversión. En cambio, puedes usar mejor los recursos en otros lugares.

Debes determinar el nivel de confiabilidad con el que tus usuarios están satisfechos y el punto en el que el costo de las mejoras incrementales comienza a superar los beneficios. Cuando determinas este nivel de confiabilidad suficiente, puedes asignar recursos de forma estratégica y enfocarte en las funciones y mejoras que ofrecen un mayor valor a tus usuarios.

Recomendaciones

Para establecer objetivos de confiabilidad realistas, ten en cuenta las recomendaciones de los siguientes apartados.

Aceptar algunas fallas y priorizar los componentes

Apunta a una alta disponibilidad, como un 99.99% de tiempo de actividad, pero no establezcas un objetivo del 100% de tiempo de actividad. Reconoce que algunas fallas son inevitables.

La diferencia entre el 100% de tiempo de actividad y un objetivo del 99.99% es el margen de error. Esta brecha suele llamarse porcentaje de error aceptable. El porcentaje de error aceptable puede ayudarte a asumir riesgos y a innovar, lo que es fundamental para que cualquier empresa mantenga su competitividad.

Priorizar la confiabilidad de los componentes más críticos del sistema Acepta que los componentes menos críticos pueden tener una mayor tolerancia a las fallas.

Equilibra la confiabilidad y el costo

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

Considera factores como los requisitos del sistema, las consecuencias de las fallas y la tolerancia al riesgo de tu organización para la aplicación específica. Recuerda considerar tus métricas de recuperación ante desastres, como el objetivo de tiempo de recuperación (RTO) y el objetivo de punto de recuperación (RPO). Decide qué nivel de confiabilidad es aceptable dentro del presupuesto y otras restricciones.

Busca formas de mejorar la eficiencia y reducir los costos sin comprometer las funciones de confiabilidad esenciales.

Crea sistemas con alta disponibilidad a través de la redundancia de recursos

Este principio del pilar de confiabilidad del Google Cloud Well-Architected Framework proporciona recomendaciones para planificar, compilar y administrar la redundancia de recursos, lo que puede ayudarte a evitar fallas.

Este principio es relevante para el área de enfoque de alcance de la confiabilidad.

Descripción general del principio

Después de decidir el nivel de confiabilidad que necesitas, debes diseñar tus sistemas para evitar cualquier punto único de fallo. Cada componente crítico del sistema se debe replicar en varias máquinas, zonas y regiones. Por ejemplo, una base de datos crítica no puede ubicarse en una sola región, y un servidor de metadatos no se puede implementar 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 compilar sistemas redundantes, ten en cuenta las recomendaciones de los siguientes apartados.

Identifica los dominios con fallas y replica los servicios

Asigna los dominios con fallas de tu sistema, desde VMs individuales hasta regiones, y diseña para la redundancia en los dominios con fallas.

Para garantizar una alta disponibilidad, distribuye y replica tus servicios y aplicaciones en varias zonas y regiones. Configura el sistema para la conmutación por error automática para asegurarte de que los servicios y las aplicaciones sigan disponibles en caso de interrupciones zonales o regionales.

Para ver ejemplos de arquitecturas multizona y multirregionales, consulta Diseña una infraestructura confiable para tus cargas de trabajo en Google Cloud.

Detecta y aborda los problemas con rapidez

Realiza un seguimiento continuo del estado de tus dominios con fallas para detectar y abordar los problemas con rapidez.

Puedes supervisar el estado actual de los servicios de Google Cloud en todas las regiones con el panel de Service Health deGoogle Cloud . También puedes ver los incidentes relevantes para tu proyecto con Personalized Service Health. Puedes usar balanceadores de cargas para detectar el estado de los recursos y enrutar el tráfico automáticamente a los backends en buen estado. Para obtener más información, consulta Descripción general de las verificaciones de estado.

Prueba situaciones de conmutación por error

Al igual que un simulacro de incendio, simula fallas con regularidad para validar la eficacia de tus estrategias de replicación y conmutación por error.

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

Aprovecha la escalabilidad horizontal

Este principio del pilar de confiabilidad del Google Cloud Well-Architected Framework proporciona recomendaciones para ayudarte a usar la escalabilidad horizontal. Con la escalabilidad horizontal, puedes asegurarte de que tus cargas de trabajo en Google Cloud puedan escalar de manera eficiente y mantener el rendimiento.

Este principio es relevante para el área de enfoque de alcance de la confiabilidad.

Descripción general del principio

Rediseña tu sistema para que tenga una arquitectura horizontal. Para adaptarte al crecimiento del tráfico o de los datos, puedes agregar más recursos. También puedes quitar recursos cuando no estén en uso.

Para comprender el valor del escalamiento horizontal, considera las limitaciones del escalamiento vertical.

Una situación común para el escalamiento vertical es usar una base de datos de MySQL como la base de datos principal con datos críticos. A medida que aumenta el uso de la base de datos, se requiere más RAM y CPU. Con el tiempo, la base de datos alcanza el límite de memoria en la máquina host y debe actualizarse. Es posible que este proceso deba repetirse varias veces. El problema es que existen límites estrictos sobre cuánto puede crecer una base de datos. Los tamaños de las VM no son ilimitados. La base de datos puede llegar a un punto en el que ya no sea posible agregar más recursos.

Incluso si los recursos fueran ilimitados, una VM grande puede convertirse en un punto único de falla. Cualquier problema con la VM de la base de datos principal puede causar respuestas de error o una interrupción en todo el sistema que afecte a todos los usuarios. Evita los puntos únicos de fallo, como se describe en Crea sistemas con alta disponibilidad a través de la redundancia de recursos.

Además de estos límites de escalamiento, el escalamiento vertical suele ser más costoso. El costo puede aumentar de forma exponencial a medida que se adquieren máquinas con mayor cantidad de potencia de procesamiento y memoria.

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

Recomendaciones

Para realizar la transición de una arquitectura de VM única a una arquitectura horizontal de varias máquinas, debes planificar con cuidado y usar las herramientas adecuadas. Para ayudarte a lograr el escalamiento horizontal, ten en cuenta las recomendaciones de las siguientes subsecciones.

Usa servicios administrados

Los servicios administrados eliminan la necesidad de administrar manualmente el escalamiento horizontal. Por ejemplo, con los grupos de instancias administrados (MIG) de Compute Engine, puedes agregar o quitar VMs para escalar tu aplicación de forma horizontal. Para las aplicaciones alojadas en contenedores, Cloud Run es una plataforma sin servidores que puede escalar automáticamente tus contenedores sin estado según el tráfico entrante.

Promueve el diseño modular

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

Implementa un diseño sin estado

Diseña aplicaciones sin estado, es decir, sin datos almacenados de forma local. Esto te permite agregar o quitar instancias sin preocuparte por la coherencia de los datos.

Detecta posibles fallas con la observabilidad

Este principio del pilar de confiabilidad del Google Cloud Well-Architected Framework proporciona recomendaciones para ayudarte a identificar de forma proactiva las áreas en las que podrían producirse errores y fallas.

Este principio es relevante para el área de enfoque de la observación de la confiabilidad.

Descripción general del principio

Para mantener y mejorar la confiabilidad de tus cargas de trabajo en Google Cloud, debes implementar una observabilidad eficaz con métricas, registros y seguimientos.

  • Las métricas son mediciones numéricas de las actividades de tu aplicación que quieres supervisar en intervalos de tiempo específicos. Por ejemplo, es posible que desees realizar un seguimiento de las métricas técnicas, como el porcentaje de solicitudes y la tasa de errores, que se pueden usar como indicadores de nivel de servicio (SLI). También es posible que debas hacer un seguimiento de las métricas empresariales 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 ocurren dentro de una aplicación o un sistema. El evento podría ser una falla, un error o un cambio de estado. Los registros pueden incluir métricas, y también puedes usarlos para los SLI.
  • Un seguimiento representa el recorrido de un solo usuario o transacción a través de una serie de aplicaciones independientes o los componentes de una aplicación. Por ejemplo, estos componentes podrían ser microservicios. Los seguimientos te ayudan a identificar qué componentes se usaron en los recorridos, dónde existen cuellos de botella y cuánto tiempo tardaron los recorridos.

Las métricas, los registros y los seguimientos te ayudan a supervisar tu sistema de forma continua. La supervisión integral te ayuda a descubrir dónde y por qué se produjeron los errores. También puedes detectar posibles fallas antes de que ocurran errores.

Recomendaciones

Para detectar posibles fallas de manera eficiente, considera las recomendaciones de los siguientes apartados.

Obtén estadísticas completas

Para hacer un seguimiento de las 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 garantizar que las métricas satisfagan de forma coherente las necesidades 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 supervisión, crea y publica tus propias métricas con el SDK de Google Cloud.

Realiza una solución de problemas proactiva

Implementa un manejo 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 de Cloud Storage y los registros de flujo de VPC.

Cuando configures el registro, ten en cuenta los costos asociados. Para controlar los costos de registro, puedes configurar filtros de exclusión en los receptores de registros para excluir ciertos registros del almacenamiento.

Optimiza el uso de los recursos

Supervisa el consumo de CPU, las métricas de E/S de red y las métricas de E/S de disco para detectar recursos con aprovisionamiento insuficiente y excesivo en servicios como Google Kubernetes Engine, Compute Engine y Managed Service para Apache Spark. Para obtener una lista completa de los servicios compatibles, consulta Descripción general de Monitoring.

Priorizar alertas

En el caso de las alertas, enfócate en las métricas esenciales, establece umbrales adecuados para minimizar la fatiga por alertas y garantiza respuestas oportunas a los problemas importantes. Este enfoque específico te permite mantener de forma proactiva la confiabilidad de la carga de trabajo. Para obtener más información, consulta Descripción general de las alertas.

Diseña para la degradación elegante

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

Este principio es relevante para el área de enfoque de respuesta de la confiabilidad.

Descripción general del principio

La degradación elegante es un enfoque de diseño en el que un sistema que experimenta una carga alta sigue funcionando, posiblemente con un rendimiento o una exactitud reducidos. La degradación elegante garantiza la disponibilidad continua del sistema y evita la falla completa, incluso si el trabajo del sistema no es óptimo. Cuando la carga vuelve a un nivel manejable, el sistema reanuda la funcionalidad completa.

Por ejemplo, durante los períodos de carga alta, la Búsqueda de Google prioriza los resultados de las páginas web con una clasificación más alta, lo que podría sacrificar cierta precisión. Cuando la carga disminuye, la Búsqueda vuelve a calcular los resultados de la búsqueda.

Recomendaciones

Para diseñar tus sistemas para una degradación elegante, ten en cuenta las recomendaciones de las siguientes subsecciones.

Implementa la limitación

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

Usa herramientas como Apigee para controlar la tasa de solicitudes a la API durante los momentos de tráfico alto. Puedes configurar reglas de política para reflejar cómo deseas reducir las solicitudes.

Descarta las solicitudes excedentes con anticipación

Configura tus sistemas para descartar el exceso de solicitudes en la capa de frontend para proteger los componentes de backend. Descartar algunas solicitudes evita fallas globales y permite que el sistema se recupere de forma más elegante. Con este enfoque, es posible que algunos usuarios experimenten errores. Sin embargo, puedes minimizar el impacto de las interrupciones, en contraste con un enfoque como el de circuit-breaking, en el que se descarta todo el tráfico durante una sobrecarga.

Cómo controlar errores parciales y reintentos

Compila tus aplicaciones para que manejen errores parciales y reintentos sin problemas. Este diseño ayuda a garantizar que se entregue la mayor cantidad posible de tráfico durante situaciones de carga alta.

Prueba situaciones de sobrecarga

Para validar que los mecanismos de limitación y descarte de solicitudes funcionen de manera eficaz, simula con regularidad condiciones de sobrecarga en tu sistema. Las pruebas ayudan a garantizar que tu sistema esté preparado para los aumentos repentinos de tráfico reales.

Supervisa los aumentos repentinos de tráfico

Usa herramientas de análisis y supervisión para predecir y responder a los aumentos repentinos de tráfico antes de que se conviertan en sobrecargas. La detección y respuesta tempranas pueden ayudar a mantener la disponibilidad del servicio durante los períodos de alta demanda.

Realiza pruebas para la recuperación ante fallas

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

Este principio es relevante para el área de enfoque de aprendizaje de la confiabilidad.

Descripción general del principio

Para asegurarte de que tu sistema pueda recuperarse de fallas, debes ejecutar pruebas de forma periódica que incluyan conmutaciones por error regionales, reversiones de versiones y restablecimiento de datos desde copias de seguridad.

Estas pruebas te ayudan a practicar las respuestas a eventos que representan riesgos importantes para la confiabilidad, como la interrupción de una región completa. Estas pruebas también te ayudan a verificar que tu sistema se comporte como se espera durante una interrupción.

En el caso improbable de que una región completa deje de funcionar, 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, estos deben sincronizarse desde la región principal hasta la región de conmutación por error. Debes verificar que los datos replicados siempre sean muy recientes para que los usuarios no experimenten pérdida de datos ni interrupción de la sesión. El sistema de balanceo de cargas también debe poder cambiar el tráfico a la región de conmutación por error en cualquier momento sin interrupciones del servicio. Para minimizar el tiempo de inactividad después de una interrupción regional, los ingenieros de operaciones también deben poder desviar de forma manual y eficiente el tráfico de los usuarios fuera de una región, en el menor tiempo posible. A veces, esta operación se denomina vaciado de una región, lo que significa que detienes el tráfico entrante a la región y mueves todo el tráfico a otro lugar.

Recomendaciones

Cuando diseñes y ejecutes pruebas para la recuperación ante fallas, ten en cuenta las recomendaciones de las siguientes subsecciones.

Define los objetivos y el alcance de las pruebas

Define con claridad lo que quieres lograr 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 Conceptos básicos de la planificación de DR.
  • Evaluar la resiliencia y la tolerancia a errores del sistema en varias situaciones de falla
  • Prueba la eficacia de los mecanismos de conmutación por error automatizados.

Decide qué componentes, servicios o regiones están dentro del alcance de las pruebas. El alcance puede incluir niveles de aplicación específicos, como el frontend, el backend y la base de datos, o puede incluir recursos de Google Cloud específicos, como instancias de Cloud SQL o clústeres de GKE. El alcance también debe especificar cualquier dependencia externa, como las APIs de terceros o las interconexiones de nube.

Prepara el entorno para las pruebas

Elige un entorno adecuado, preferiblemente uno de etapa de pruebas o de zona de pruebas que replique tu configuración de producción. Si realizas la prueba en producción, asegúrate de tener listas las medidas de seguridad, como la supervisión automatizada y los procedimientos de reversión manuales.

Crear un plan de creación de copias de seguridad Toma instantáneas o copias de seguridad de las bases de datos y los servicios esenciales 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úrate de que tus roles, políticas y configuraciones de conmutación por error de Identity and Access Management (IAM) estén configurados correctamente. Verifica que se hayan otorgado los permisos necesarios para las herramientas y las secuencias de comandos de prueba.

Informa a las partes interesadas, incluidos los propietarios de operaciones, DevOps y aplicaciones, sobre el programa, el alcance y el impacto potencial de la prueba. Proporciona a los interesados un cronograma estimado y los comportamientos esperados durante la prueba.

Simula situaciones de falla

Planifica y ejecuta fallas con herramientas como Chaos Monkey. Puedes usar secuencias de comandos personalizadas para simular fallas 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 la región con reglas de firewall o restricciones de la API según el alcance de la prueba. Aumenta de forma gradual las situaciones de falla para observar el comportamiento del sistema en diversas condiciones.

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

Para validar los cambios de configuración y evaluar la resiliencia del sistema ante errores humanos, prueba situaciones que involucren parámetros de configuración incorrectos. Por ejemplo, ejecuta pruebas con una configuración de conmutación por error de DNS incorrecta o permisos de IAM incorrectos.

Supervisa el comportamiento del sistema

Supervisa cómo los balanceadores de cargas, las verificaciones de estado y otros mecanismos redireccionan el tráfico. Usa herramientas de Google Cloud como Cloud Monitoring y Cloud Logging para capturar métricas y eventos durante la prueba.

Observa los cambios en la latencia, las tasas de error y la capacidad de procesamiento durante y después de la simulación de fallas, y supervisa el impacto general en el rendimiento. Identifica cualquier degradación o incoherencia en la experiencia del usuario.

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

Verifica la recuperación en función de tus RTO y RPO

Mide cuánto tiempo tarda el sistema en reanudar las operaciones normales después de una falla y, luego, compara estos datos con el RTO definido y documenta cualquier brecha.

Asegúrate de que la integridad y la disponibilidad de los datos se alineen con el RPO. Para probar la coherencia de la base de datos, compara las instantáneas o las copias de seguridad de la base de datos antes y después de una falla.

Evalúa el restablecimiento del servicio y confirma que todos los servicios se restablezcan a un estado funcional con una interrupción mínima para los usuarios.

Documenta y analiza los resultados

Documenta cada paso de la prueba, la situación de falla y el comportamiento correspondiente del sistema. 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 observaron 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 supervisión Según los resultados de las pruebas, actualiza las políticas de conmutación por error y las guías pertinentes. Presentar 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 Realiza análisis post mortem exhaustivos.

Itera y mejora

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

Ejecuta pruebas en diferentes situaciones, incluidos los cambios en la infraestructura, las actualizaciones de software y el aumento de las cargas de tráfico.

Automatiza las pruebas de conmutación por error con canalizaciones de CI/CD para integrar las pruebas de confiabilidad en tu ciclo de vida de desarrollo.

Durante la autopsia, usa los comentarios de las partes interesadas y los usuarios finales para mejorar el proceso de prueba y la resiliencia del sistema.

Realización de pruebas para la recuperación en caso de pérdida de datos

Este principio del pilar de confiabilidad del Google Cloud Well-Architected Framework proporciona recomendaciones para ayudarte a diseñar y ejecutar pruebas de recuperación ante la pérdida de datos.

Este principio es relevante para el área de enfoque de aprendizaje de la confiabilidad.

Descripción general del principio

Para asegurarte de que tu sistema pueda recuperarse de situaciones en las que se pierden o dañan datos, debes ejecutar pruebas para esas situaciones. Las instancias 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 restablecer los datos de las copias de seguridad y volver a activar todos los servicios con los datos recién restablecidos.

Te recomendamos que uses tres criterios para juzgar el éxito o el fracaso de este tipo de prueba de recuperación: integridad de los datos, objetivo de tiempo de recuperación (RTO) y objetivo de punto de recuperación (RPO). Para obtener detalles sobre las métricas de RTO y RPO, consulta Conceptos básicos de la planificación de DR.

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

Recomendaciones

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

Verificar la coherencia de las copias de seguridad y probar los procesos de restablecimiento

Debes verificar que tus copias de seguridad contengan instantáneas coherentes y utilizables de los datos que puedes restablecer para volver a poner las aplicaciones en servicio de inmediato. Para validar la integridad de los datos, configura verificaciones de coherencia automatizadas que se ejecuten después de cada copia de seguridad.

Para probar las copias de seguridad, restablécelas en un entorno que no sea de producción. Para garantizar que tus copias de seguridad se puedan restablecer de manera eficiente y que los datos restablecidos cumplan con los requisitos de la aplicación, simula con regularidad situaciones de recuperación de datos. Documenta los pasos para restablecer los datos y capacita a tus equipos para que ejecuten los pasos de manera eficaz durante una falla.

Programa copias de seguridad periódicas y frecuentes

Para minimizar la pérdida de datos durante el restablecimiento y cumplir con los objetivos de RPO, es fundamental tener copias de seguridad programadas con regularidad. Establece una frecuencia de copia de seguridad que se alinee con 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 copia de seguridad para reducir el riesgo de pérdida de datos.

Usa herramientas de Google Cloud como Cloud Storage, copias de seguridad automáticas de Cloud SQL o copias de seguridad de Spanner para programar y administrar copias de seguridad. En el caso de las aplicaciones críticas, usa soluciones de copia de seguridad casi continuas, como la recuperación de un momento determinado (PITR) para Cloud SQL o las copias de seguridad incrementales para conjuntos de datos grandes.

Define y supervisa el RPO

Establece un RPO claro según las necesidades de tu empresa y supervisa el cumplimiento del RPO. Si los intervalos de copia de seguridad superan el RPO definido, usa Cloud Monitoring para configurar alertas.

Supervisa el estado de las copias de seguridad

Usa el servicio de Backup and DR o herramientas similares para hacer un seguimiento del estado de tus copias de seguridad y confirmar que se almacenen en ubicaciones seguras y confiables. Asegúrate de que las copias de seguridad se repliquen en varias regiones para aumentar la resiliencia.

Planifica situaciones más allá de la copia de seguridad

Combina las copias de seguridad con estrategias de recuperación ante desastres, como configuraciones de conmutación por error activa-activa o replicación entre regiones 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 ante desastres.

Realización de análisis post mortem exhaustivos

Este principio del pilar de confiabilidad del Google Cloud Well-Architected Framework proporciona recomendaciones para ayudarte a realizar análisis post mortem eficaces después de fallas e incidentes.

Este principio es relevante para el área de enfoque de aprendizaje de la confiabilidad.

Descripción general del principio

Un análisis post mortem es un registro escrito de un incidente, su impacto, las medidas que se tomaron para mitigarlo o resolverlo, las causas raíz y las acciones de seguimiento para evitar que se repita. El objetivo de un análisis post mortem es aprender de los errores y no asignar culpas.

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 análisis post mortem
  • Captura los hechos
  • Identificar y analizar las causas raíz
  • Planifica para el futuro
  • Ejecute 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 el usuario que superen un umbral determinado.
  • Pérdidas de datos de cualquier tipo
  • Intervenciones de los ingenieros de guardia, como una reversión de la versión o un cambio de ruta del tráfico.
  • Tiempos de resolución superiores a un umbral definido.
  • Fallas de supervisión, que suelen implicar el descubrimiento manual de incidentes.

Recomendaciones

Define los criterios de las autopsias antes de que ocurra un incidente para que todos sepan cuándo es necesaria una autopsia.

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

Realiza análisis post mortem libres de culpas

Los análisis post mortem eficaces se enfocan en los procesos, las herramientas y las tecnologías, y no culpan a las personas ni a los equipos. El propósito de un análisis post mortem es mejorar tu tecnología y tu futuro, no encontrar quién es 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 asignan culpas y los comentarios sin culpas:

  • Comentarios que asignan culpas: "¡Tenemos que volver a escribir todo el complicado sistema de backend! Se ha estado rompiendo semanalmente durante los últimos tres trimestres y estoy seguro de que todos estamos cansados de arreglar las cosas de a poco. En serio, si me llaman una vez más, lo reescribiré yo mismo…"
  • Comentarios sin culpas: "Un elemento de acción para reescribir todo el sistema de backend podría evitar que estas páginas sigan ocurriendo. El manual de mantenimiento de esta versión es bastante largo y es muy difícil capacitarse por completo. Estoy seguro de que nuestros futuros ingenieros de guardia nos lo agradecerán".

Haz que el informe de análisis post mortem sea legible para todos los públicos objetivo

Para cada dato que planees incluir en el informe, evalúa si esa información es importante y necesaria para ayudar al público a comprender lo que sucedió. Puedes mover los datos y las explicaciones complementarios a un apéndice del informe. Los revisores que necesiten más información pueden solicitarla.

Evita las soluciones complejas o con exceso de ingeniería.

Antes de comenzar a explorar soluciones para un problema, evalúa la importancia del problema y la probabilidad de que vuelva a ocurrir. Agregar complejidad al sistema para resolver problemas que es poco probable que vuelvan a ocurrir puede aumentar la inestabilidad.

Comparte la autopsia con la mayor cantidad de personas posible

Para asegurarte de que los problemas no queden sin resolver, publica el resultado del análisis post mortem para un público amplio y obtén asistencia de la administración. El valor de un análisis post mortem es proporcional al aprendizaje que se produce después de este. Cuando más personas aprenden de los incidentes, se reduce la probabilidad de que se repitan fallas similares.