Well-Architected Framework: Pilar de confiabilidad

Last reviewed 2025-02-14 UTC

El pilar de confiabilidad del Google Cloud Well-Architected Framework 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 constante las 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 resistencia es la capacidad del sistema para soportar y recuperarse de fallas o interrupciones inesperadas, al mismo tiempo que mantiene el rendimiento. LasGoogle Cloud funciones, como las implementaciones multirregionales, las copias de seguridad automatizadas y las soluciones de recuperación ante desastres, pueden ayudarte a mejorar la resistencia 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 generar pérdida de ingresos, 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 ellas de manera eficiente.
  • 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 períodos de alta demanda o problemas inesperados.
  • Integridad de los datos: Las fallas pueden provocar la pérdida o corrupción de 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 comerciales 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, 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 de ingeniería de confiabilidad de sitios (SRE). Incluso los grupos enfocados en el negocio, como marketing y ventas, pueden influir en la confiabilidad.

Todos los equipos deben comprender los objetivos de confiabilidad y los riesgos de sus aplicaciones. Los equipos deben ser responsables de cumplir con estos requisitos. Los conflictos entre la confiabilidad y el desarrollo de funciones del producto habituales deben priorizarse y derivarse según corresponda.

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

Áreas de enfoque para la confiabilidad

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

  • Delimitación: 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 a través del 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 prevenir fallas del sistema, implementa una observación y supervisión integrales y continuas. A través de esta observación, puedes comprender las tendencias e identificar posibles problemas de forma proactiva.
  • Respuesta: Para reducir el impacto de las fallas, responde de manera adecuada y recupera la situación de forma eficiente. Las respuestas automatizadas también pueden ayudar a reducir el impacto de las fallas. Incluso con la planificación y los controles, pueden producirse fallas.
  • Aprendizaje: Para evitar que se repitan las fallas, aprende de cada experiencia y toma las medidas adecuadas.

Principios básicos

Las recomendaciones del pilar de confiabilidad del Framework de Well-Architected se correlacionan con los siguientes principios básicos:

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 Google Cloud Well-Architected Framework te ayuda a evaluar la experiencia de tus usuarios y, luego, a correlacionar los hallazgos con los objetivos y las métricas de confiabilidad.

Este principio es pertinente para el área de enfoque del 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, es posible que observes un uso elevado de la CPU, operaciones lentas del servidor o incluso tareas fallidas. 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 te bases únicamente en métricas centradas en el servidor, como el uso de CPU, que pueden llevar a conclusiones engañosas sobre la confiabilidad de tu servicio. La verdadera confiabilidad significa que los usuarios pueden usar tu aplicación o servicio de manera constante y eficaz.

Recomendaciones

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

Medir 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 búsquedas 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 directa de datos no es factible, aleja progresivamente tu 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 significativamente a tus usuarios.

Analiza los recorridos del usuario

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 a través de tu aplicación, puedes encontrar cuellos de botella y problemas de latencia que podrían perjudicar la experiencia del usuario. Cloud 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 Google Cloud framework de Well-Architected te ayuda a definir objetivos de confiabilidad que sean técnicamente factibles para tus cargas de trabajo en Google Cloud.

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

Descripción general del principio

Diseña tus sistemas para que sean lo suficientemente confiables como para que los usuarios estén satisfechos. Puede parecer contradictorio, pero un objetivo de confiabilidad del 100% a menudo no es la estrategia más eficaz. Una mayor confiabilidad podría 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 por aumentar aún más su satisfacción podrían generar un bajo retorno de la inversión. En su lugar, puedes invertir 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 determines este nivel de confiabilidad suficiente, podrás asignar recursos de forma estratégica y enfocarte en las funciones y las mejoras que aporten más valor a tus usuarios.

Recomendaciones

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

Aceptar algunas fallas y priorizar componentes

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

La diferencia entre el tiempo de actividad del 100% y el objetivo del 99.99% es la tolerancia a fallas. Esta brecha suele llamarse presupuesto de error. El porcentaje de error aceptable puede ayudarte a correr riesgos e innovar, lo que es fundamental para que cualquier empresa siga siendo competitiva.

Prioriza la confiabilidad de los componentes más importantes 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 costo-beneficio.

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 tener en cuenta 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.

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

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

Este principio es pertinente para el área de enfoque del 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 falla. 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 ubicarse en una sola región, y un servidor de metadatos no puede implementarse 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, considera las recomendaciones de las siguientes subsecciones.

Identifica los dominios de falla y replica los servicios

Traza un mapa de los dominios de falla de tu sistema, desde las VMs individuales hasta las regiones, y diseña la redundancia en todos los dominios de falla.

Para garantizar la 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 y asegúrate de que los servicios y las aplicaciones sigan disponibles en caso de interrupciones zonales o regionales.

Para ver ejemplos de arquitecturas multizona y multirregión, 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 de falla para detectar y abordar los problemas con rapidez.

Puedes supervisar el estado actual de los Google Cloud servicios en todas las regiones con el Google Cloud panel de Service Health. 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 automáticamente el tráfico a los servidores de backend 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 en 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 framework de Well-Architected proporciona recomendaciones para ayudarte a usar la escalabilidad horizontal. Si usas la escalabilidad horizontal, puedes garantizar que tus cargas de trabajo enGoogle Cloud puedan escalar de manera eficiente y mantener el rendimiento.

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

Descripción general del principio

Rediseña tu sistema para que tenga una arquitectura horizontal. Para adaptarse al crecimiento del tráfico o 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.

Un caso de uso común para el escalamiento vertical es usar una base de datos 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 debas repetir este proceso varias veces. El problema es que existen límites estrictos sobre cuánto puede crecer una base de datos. Los tamaños de 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 provocar respuestas de error o una interrupción en todo el sistema que afecte a todos los usuarios. Evita los puntos únicos de falla, como se describe en Compila 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 capacidad de procesamiento y memoria.

En cambio, 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 una sola VM 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 ajuste de escala 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. En el caso de las aplicaciones alojadas en contenedores, Cloud Run es una plataforma sin servidores que puede ajustar automáticamente la escala de 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 los componentes individuales según sea necesario, en lugar de escalar toda la aplicación. Para obtener más información, consulta Promueve 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 ocurrir errores y fallas.

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

Descripción general del principio

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

  • Las métricas son mediciones numéricas de las actividades que deseas hacer un seguimiento para tu aplicación en intervalos de tiempo específicos. Por ejemplo, es posible que desees hacer un seguimiento de las métricas técnicas, como la tasa 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 de negocios específicas de la aplicación, como los pedidos realizados y los pagos recibidos.
  • Los registros son registros con marcas de tiempo de eventos discretos que ocurren dentro de una aplicación o un sistema. El evento puede 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 registro representa el recorrido de un solo usuario o transacción a través de varias aplicaciones separadas o los componentes de una aplicación. Por ejemplo, estos componentes podrían ser microservicios. Los registros te ayudan a hacer un seguimiento de los componentes que se usaron en los recorridos, dónde existen cuellos de botella y cuánto duraron 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 se produzcan errores.

Recomendaciones

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

Obtén estadísticas integrales

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 manera constante 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 a 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 evitar que se almacenen ciertos registros.

Optimiza el uso de 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 capacidad insuficiente o excesiva en servicios como GKE, Compute Engine y Dataproc. Para obtener una lista completa de los servicios compatibles, consulta la descripción general de Cloud Monitoring.

Priorizar alertas

En el caso de las alertas, enfócate en las métricas críticas, 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 la Descripción general de 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 manera que fallen correctamente.

Este principio es pertinente 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 precisión reducidos. La degradación gradual garantiza la disponibilidad continua del sistema y evita fallas completas, 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 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 algo de precisión. Cuando la carga disminuye, la Búsqueda de Google vuelve a calcular los resultados de la búsqueda.

Recomendaciones

Para diseñar tus sistemas de modo que se degraden con elegancia, ten en cuenta las recomendaciones de las siguientes subsecciones.

Implementa la limitación

Asegúrate de que tus réplicas puedan controlar de forma independiente las sobrecargas y limitar las solicitudes entrantes durante 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 en momentos de mucho tráfico. Puedes configurar reglas de políticas para reflejar cómo deseas reducir las solicitudes.

Descarta las solicitudes en exceso con anticipación

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

Cómo controlar errores parciales y reintentos

Compila tus aplicaciones para que controlen errores parciales y reintentos sin problemas. Este diseño ayuda a garantizar que se entregue la mayor cantidad de tráfico posible en 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 periódicamente condiciones de sobrecarga en tu sistema. Las pruebas ayudan a garantizar que tu sistema esté preparado para los aumentos repentinos de tráfico en el mundo real.

Supervisa los picos de tráfico

Usa herramientas de supervisión y análisis para predecir y responder a los aumentos repentinos 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 períodos de alta demanda.

Realiza pruebas para la recuperación en caso de errores

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

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

Descripción general del principio

Para asegurarte de que tu sistema pueda recuperarse de las fallas, debes ejecutar periódicamente pruebas 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 según lo previsto durante una interrupción.

En el caso improbable de que se produzca una interrupción 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, estos deben sincronizarse desde la región principal a la región de conmutación por error. Debes verificar que los datos replicados sean siempre muy recientes para que los usuarios no experimenten pérdida de datos ni interrupciones de 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 el tráfico de usuarios de una región de forma manual y eficiente, en el menor tiempo posible. Esta operación a veces se denomina vaciar 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 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 claramente 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 capacidad de recuperación y la tolerancia a errores del sistema en diversas situaciones de falla
  • Probar la eficacia de los mecanismos de conmutación por error automáticos

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

Prepara el entorno para las pruebas

Elige un entorno adecuado, de preferencia un entorno de zona de pruebas o de etapa 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 manual.

Crea un plan de copias de seguridad. Toma instantáneas o copias de seguridad 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úrate de que tus roles y políticas de IAM, y las configuraciones de conmutación por error estén configurados correctamente. Verifica que los permisos necesarios estén establecidos para las herramientas y los secuencias de comandos de prueba.

Informa a los interesados, incluidos los propietarios de operaciones, DevOps y aplicaciones, sobre el programa, el alcance y el posible impacto de las pruebas. Proporciona a las partes interesadas 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 apagado 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 gradualmente 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, por ejemplo, cómo se comportan los sistemas de frontend cuando los servicios de backend no están disponibles.

Para validar los cambios de configuración y evaluar la resistencia del sistema ante errores humanos, prueba situaciones que involucren errores de configuración. Por ejemplo, ejecuta pruebas con una configuración incorrecta de conmutación por error del DNS 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 Google Cloud herramientas 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 el rendimiento durante y después de la simulación de fallas, y supervisa el impacto general en el rendimiento. Identificar 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. Utiliza estos datos para verificar la eficacia de tus sistemas de alertas y respuesta ante incidentes.

Verifica la recuperación en función de tus objetivos de 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 restablecieron a un estado funcional con una interrupción mínima para el usuario.

Documenta y analiza los resultados

Documenta cada paso de la prueba, situación de falla y 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 observaron durante la prueba. Para ayudar a priorizar las correcciones, clasifica los problemas según su gravedad y su impacto.

Sugerir mejoras en la arquitectura del sistema, los mecanismos de conmutación por error o la configuración 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 Cómo realizar análisis post mortem exhaustivos.

Itera y mejora

Para validar la confiabilidad y la resistencia 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 revisión posterior, usa los comentarios de las partes interesadas y los usuarios finales para mejorar el proceso de prueba y la capacidad de recuperación del sistema.

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

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

Este principio es pertinente para el área de enfoque del 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 esos casos. 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 desde las copias de seguridad y volver a activar todos los servicios con los datos recién restablecidos.

Te recomendamos que utilices 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 DR desastres.

El objetivo de las pruebas de restauración de datos es verificar periódicamente que tu organización pueda seguir cumpliendo con los requisitos de continuidad del negocio. Además de medir el RTO y el RPO, una prueba de restablecimiento de datos debe incluir pruebas 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 funciona correctamente en el entorno de prueba.

Recomendaciones

Cuando diseñes y ejecutes pruebas para la recuperación en caso de pérdida de datos, ten en cuenta las recomendaciones de las siguientes subsecciones.

Verifica la coherencia de las copias de seguridad y prueba los procesos de restablecimiento

Debes verificar que tus copias de seguridad contengan instantáneas coherentes y utilizables de los datos que puedes restablecer para que las aplicaciones vuelvan a estar en servicio de inmediato. Para validar la integridad de los datos, configura verificaciones de coherencia automatizadas para 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 la restauración de datos y capacita a tus equipos para que los ejecuten de manera eficaz durante una falla.

Programa copias de seguridad frecuentes y periódicas

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 copias 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 copias de seguridad para reducir el riesgo de pérdida de datos.

Usa Google Cloud herramientas como Cloud Storage, las copias de seguridad automáticas de Cloud SQL o las copias de seguridad de Spanner para programar y administrar copias de seguridad. Para las aplicaciones críticas, usa soluciones de copias 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.

Cómo definir y supervisar el RPO

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

Supervisa el estado de la copia de seguridad

Usa el Google Cloud servicio de copia de seguridad y DR o herramientas similares para hacer un seguimiento del estado de tus copias de seguridad y confirmar que se almacenan 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. Si deseas obtener más información, consulta la Guía de planificación para la recuperación ante desastres.

Realiza análisis retrospectivos exhaustivos

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

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

Descripción general del principio

Un análisis post mortem es un registro escrito de un incidente, su impacto, las acciones que se tomaron para mitigar o resolver el incidente, 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:

Flujo de trabajo de un análisis de resultados

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

  • Cómo crear un análisis post mortem
  • Captura los hechos
  • Identificar y analizar las causas raíz
  • Planifica el futuro
  • Ejecute el plan

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

  • Interrupciones o degradaciones visibles para el usuario que superen un umbral determinado
  • Pérdidas de datos de cualquier tipo
  • Intervenciones de ingenieros de guardia, como la reversión de una versión o el redireccionamiento 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 análisis post mortem antes de que ocurra un incidente para que todos sepan cuándo es necesario realizar un análisis post mortem.

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

Realiza análisis retrospectivos libres de responsabilidad

Las post mortem eficaces se centran en los procesos, las herramientas y las tecnologías, y no culpan a personas o equipos. El propósito de un análisis a posteriori es mejorar tu tecnología y tu futuro, no encontrar a los culpables. 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 descompuesto semanalmente durante los últimos tres trimestres, y estoy seguro de que todos estamos cansados de arreglar las cosas de forma fragmentada. En serio, si me llaman una vez más, lo reescribiré yo mismo…".
  • Comentarios sin culpar a nadie: "Una acción para reescribir todo el sistema de backend podría evitar que sigan apareciendo estas páginas. El manual de mantenimiento de esta versión es bastante largo y muy difícil de aprender por completo. Estoy seguro de que nuestros futuros ingenieros de guardia nos lo agradecerán".

Haz que el informe de la revisión posterior al incidente sea legible para todos los públicos previstos

Para cada dato que planees incluir en el informe, evalúa si es importante y necesario para ayudar al público a comprender lo que sucedió. Puedes trasladar los datos y las explicaciones complementarias 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 comenzar a explorar soluciones para un problema, evalúa su importancia y la probabilidad de que se repita. Agregar complejidad al sistema para resolver problemas que es poco probable que vuelvan a ocurrir puede aumentar la inestabilidad.

Comparte el análisis post mortem con la mayor cantidad de personas posible

Para garantizar que los problemas no queden sin resolver, publica los resultados 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.