Well-Architected Framework: Pilar de confiabilidad

Last reviewed 2025-02-14 UTC

El pilar de confiabilidad del Google Cloud framework de arquitectura bien definida 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, desarrolladores, ingenieros de plataformas, administradores y de confiabilidad de sitios de la nube.

La confiabilidad es la capacidad de un sistema para realizar de forma coherente las funciones previstas dentro de las condiciones definidas y mantener un servicio sin interrupciones. 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, a la vez 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 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 ocasionar pérdida de ingresos, productividad reducida y daños en la reputación. Las arquitecturas resilientes pueden ayudar a garantizar que los sistemas puedan seguir funcionando durante las fallas o recuperarse 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 coherentes, y proporcionan un servicio confiable incluso durante períodos de alta demanda o problemas inesperados.
  • Integridad de 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 permanezcan precisos y accesibles.
  • Continuidad del negocio: 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 admita una recuperación rápida.
  • Cumplimiento: Muchas industrias tienen requisitos reglamentarios para la disponibilidad del sistema y la protección de los datos. Las arquitecturas resilientes pueden ayudarte a cumplir con estos estándares, ya que garantizan que los sistemas permanezcan 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 tiempos de inactividad costosos, 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 establecidos. Esta estrategia debe incluir la 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 el desarrollo, la administración de productos, las operaciones, la ingeniería de plataformas y la ingeniería de confiabilidad de sitios (SRE). Incluso los grupos enfocados en la empresa, 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 normal de las funciones del producto deben priorizarse y escalarse según corresponda.

Planifica y administra la confiabilidad de forma 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 Cómo optimizar el proceso de migración a la nube de tu organización 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.

  • Determinación del 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 a través del sistema y qué podría salir mal. Identifica posibles fallas, cuellos de botella y riesgos, lo que te ayudará a tomar medidas para mitigar esos problemas.
  • Observación: Para ayudar a evitar fallas del sistema, implementa una observación y supervisión integrales y continuas. A través de esta observación, puedes comprender las tendencias y, además, identificar posibles problemas de forma proactiva.
  • Respuesta: Para reducir el impacto de las fallas, responde de manera apropiada y recupérate de manera 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 los errores, aprende de cada experiencia y toma las medidas adecuadas.

Principios básicos

Las recomendaciones del pilar de confiabilidad del framework de arquitectura bien diseñada 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 en el pilar de confiabilidad del Google Cloud framework bien estructurado te ayuda a evaluar la experiencia de tus usuarios y, luego, asignar los resultados a los objetivos y las métricas de confiabilidad.

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

Descripción general de los principios

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 alto de la CPU, operaciones de servidor lentas 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 enfrentan los usuarios. Enfócate en métricas como la proporción de éxito de las solicitudes de usuario. 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 confiabilidad real 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.

Cómo medir la experiencia del usuario

Para comprender realmente la confiabilidad de tu servicio, prioriza las métricas que reflejan 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 desde el dispositivo o el navegador del usuario. Si esta recopilación de datos directa 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 de manera significativa a los usuarios.

Cómo analizar los recorridos de los usuarios

Para comprender cómo los usuarios interactúan 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 bien diseñado te ayuda a definir objetivos de confiabilidad que sean técnicamente factibles para tus cargas de trabajo en Google Cloud.

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

Descripción general de los principios

Diseña tus sistemas para que sean lo suficientemente confiables para que los usuarios estén satisfechos. Puede parecer contraintuitivo, pero un objetivo de confiabilidad del 100% a menudo no es la estrategia más eficaz. Una mayor confiabilidad podría generar un costo mucho 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 conformes 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 los recursos en otro lugar.

Debes determinar el nivel de confiabilidad con el que tus usuarios están conformes 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 mejoras que brindan un mayor valor a tus usuarios.

Recomendaciones

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

Aceptar algunas fallas y priorizar los componentes

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

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

Prioriza 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 de costo-beneficio detallados.

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 de alta disponibilidad a través de la redundancia de recursos

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

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

Descripción general de los principios

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 debe replicarse en varias máquinas, zonas y regiones. Por ejemplo, una base de datos fundamental no se puede ubicar 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, considera las recomendaciones de las siguientes sub secciones.

Identifica los dominios de fallas y replica los servicios

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

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 para asegurarte de que los servicios y las aplicaciones sigan disponibles en caso de interrupciones de zona o región.

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

Detecta y aborda los problemas de forma oportuna

Realiza un seguimiento continuo del estado de tus dominios con errores 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 estado del servicio. 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 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 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 bien diseñado proporciona recomendaciones para ayudarte a usar la escalabilidad horizontal. Cuando usas la escalabilidad horizontal, puedes ayudar a garantizar que tus cargas de trabajo enGoogle Cloud puedan escalar de manera eficiente y mantener el rendimiento.

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

Descripción general de los principios

Cambia tu sistema a 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.

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 de la máquina anfitrión 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 las VMs 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 generar 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 de 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 mayores cantidades de potencia 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 VM única a una arquitectura horizontal de varias máquinas, debes planificar con cuidado y usar las herramientas adecuadas. Para ayudarte a lograr la escala horizontal, ten en cuenta las recomendaciones de las siguientes sub secciones.

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 horizontalmente. En el caso de las aplicaciones en contenedores, Cloud Run es una plataforma sin servidores que puede escalar automáticamente tus contenedores sin estado según el tráfico entrante.

Promociona 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 Promociona 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, que no tengan 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 Framework de arquitectura bien diseñada proporciona recomendaciones para ayudarte a identificar de forma proactiva las áreas en las que pueden ocurrir errores y fallas.

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

Descripción general de los principios

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 de las 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 marca de tiempo de eventos discretos que ocurren en 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 una serie de aplicaciones independientes o los componentes de una aplicación. Por ejemplo, estos componentes podrían ser microservicios. Los registros te ayudan a hacer un seguimiento de qué componentes se usaron en los recorridos, dónde existen cuellos de botella y cuánto 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 saber dónde y por qué se produjeron los errores. También puedes detectar posibles fallas antes de que ocurran los errores.

Recomendaciones

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

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 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 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 GKE, Compute Engine y Dataproc. Para obtener una lista completa de los servicios compatibles, consulta la descripción general de Cloud Monitoring.

Prioriza las alertas

En el caso de las alertas, enfócate en las métricas críticas, establece umbrales adecuados para minimizar la fatiga de las alertas y asegúrate de responder a tiempo los problemas importantes. Este enfoque dirigido 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 framework bien diseñado proporciona recomendaciones para ayudarte a diseñar tus cargas de trabajo Google Cloud de modo que fallen de forma elegante.

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

Descripción general de los principios

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 elegante garantiza la disponibilidad continua del sistema y evita fallas completas, incluso si el funcionamiento 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 mejor clasificación, lo que podría sacrificar cierta 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 para una degradación elegante, ten en cuenta las recomendaciones de las siguientes sub secciones.

Implementa la limitación

Asegúrate de que tus réplicas puedan controlar las sobrecargas de forma independiente y limitar las solicitudes entrantes durante situaciones de mucho tráfico. Este enfoque te ayuda a evitar fallas en cascada que se producen 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 períodos de mayor tráfico. Puedes configurar las reglas de políticas para reflejar cómo deseas reducir la escala de las solicitudes.

Cómo descartar solicitudes en exceso con anticipación

Configura tus sistemas para que descarten las solicitudes excedentes en la capa de frontend y protejan los componentes del backend. Si descartas algunas solicitudes, se evitan fallas globales y se 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, en contraste con un enfoque como el disyuntor, en el que se descarta todo el tráfico durante una sobrecarga.

Cómo controlar errores parciales y reintentos

Compila tus aplicaciones para controlar 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 frecuencia las 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 picos 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 anticipadas pueden ayudar a mantener la disponibilidad del servicio durante los períodos de alta demanda.

Realiza pruebas para la recuperación de fallas

Este principio del pilar de confiabilidad del Google Cloud framework bien diseñado 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 confiabilidad del aprendizaje.

Descripción general de los principios

Para asegurarte de que tu sistema pueda recuperarse de las fallas, debes ejecutar pruebas de forma periódica que incluyan conmutaciones por error regionales, reversiones de lanzamientos 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 el sistema se comporte según lo previsto durante una interrupción.

En el caso improbable de que falle una región completa, 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, se deben sincronizar de la región principal a la región de resguardo. Debes verificar que los datos replicados siempre sean muy recientes para que los usuarios no experimenten pérdida de datos ni interrupciones de la sesión. El sistema de balanceo de cargas también debe poder transferir 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. A veces, esta operación se denomina descarga 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 de fallas, ten en cuenta las recomendaciones de las siguientes sub secciones.

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.
  • Evalúa la resiliencia del sistema y la tolerancia a errores en diferentes 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 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 en la nube.

Prepara el entorno para las pruebas

Elige un entorno adecuado, preferiblemente 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 preparadas las medidas de seguridad, como la supervisión automatizada y los procedimientos de reversión manuales.

Crea un plan de copias de seguridad. Crea 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, políticas y configuraciones de conmutación por error de IAM estén configurados correctamente. Verifica que los permisos necesarios para las herramientas y secuencias de comandos de prueba estén en su lugar.

Informa a las partes interesadas, incluidos los propietarios de operaciones, DevOps y aplicaciones, sobre el programa de pruebas, el alcance y el posible impacto. 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 de varias zonas o una instancia de Cloud SQL inhabilitada. También puedes usar secuencias de comandos para simular una interrupción de red en toda la región con reglas de firewall o restricciones de API según el alcance de la prueba. Deriva gradualmente las situaciones de falla para observar el comportamiento del sistema en varias condiciones.

Introduce pruebas de carga junto con situaciones de falla para replicar el uso del 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 capacidad de recuperación del sistema ante errores humanos, prueba situaciones que impliquen parámetros de configuración incorrectos. Por ejemplo, ejecuta pruebas con parámetros de configuración incorrectos de conmutación por error de 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 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 tu 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 las brechas.

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 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 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 las configuraciones de supervisión En función de los resultados de la prueba, actualiza las políticas de conmutación por error y las guías relevantes. 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 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 cambios en la infraestructura, actualizaciones de software y cargas de tráfico aumentadas.

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 el análisis post mortem, 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 ante la pérdida de datos

Este principio del pilar de confiabilidad del Google Cloud framework bien diseñado 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 confiabilidad del aprendizaje.

Descripción general de los principios

Para garantizar que tu sistema pueda recuperarse de situaciones en las que se pierden o se dañan los datos, debes ejecutar pruebas para esas situaciones. 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 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 más información 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 del negocio. 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 prueba.

Recomendaciones

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

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 volver a poner las aplicaciones en servicio de inmediato. Para validar la integridad de los datos, configura verificaciones de coherencia automáticas que se ejecuten después de cada copia de seguridad.

Para probar las copias de seguridad, restablecelas 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 situaciones de recuperación de datos con regularidad. 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 regulares

Para minimizar la pérdida de datos durante el restablecimiento y cumplir con los objetivos de RPO, es esencialmente necesario 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 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 aplicaciones críticas, usa soluciones de copia de seguridad casi continuas, como la recuperación de un momento determinado (PITR) para Cloud SQL o 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 las 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 activo-activo 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.

Realiza análisis retrospectivos exhaustivos

Este principio del pilar de confiabilidad del Google Cloud Framework de arquitectura bien definida 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 confiabilidad del aprendizaje.

Descripción general de los principios

Un análisis post mortem es un registro escrito de un incidente, su impacto, las acciones 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:

Flujo de trabajo de un análisis post mortem.

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

  • Crea un informe post mortem
  • Captura los hechos
  • Identifica y analiza 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:

  • Tiempos de inactividad o degradaciones visibles para el usuario más allá de un umbral determinado
  • Pérdidas de datos de cualquier tipo
  • Intervenciones de ingenieros de guardia, como una reversión de lanzamiento o una reorientación 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 sub secciones.

Realiza análisis post mortem sin buscar culpables

Los análisis post mortem eficaces se enfocan en los procesos, las herramientas y las tecnologías, y no culpan a las personas o los equipos. El propósito de un análisis post mortem es mejorar tu tecnología y tu futuro, no encontrar a los culpables. Todos cometen 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: “Necesitamos reescribir todo el sistema de backend complicado. Se rompe semanalmente desde hace tres cuartos y estoy seguro de que todos estamos cansados de arreglar las cosas de forma parcial. 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 sucediendo. El manual de mantenimiento de esta versión es bastante largo y es muy difícil completar la capacitación. Estoy seguro de que nuestros futuros ingenieros de guardia nos lo agradecerán".

Haz que todos los públicos previstos puedan leer el informe post mortem

Para cada dato que planeas incluir en el informe, evalúa si es importante y necesario 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 sobreingeniería

Antes de comenzar a explorar soluciones para un problema, evalúa su importancia 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 el análisis post mortem lo más ampliamente posible

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