Modelo de madurez de confiabilidad

Establecer una base sólida para la resistencia en la infraestructura y las operaciones de la carga de trabajo, en lugar de dedicar tiempo a las tareas de optimización.

El nivel 1 del modelo de madurez está diseñado para ayudar a los equipos de carga de trabajo a crear una base sólida para la confiabilidad del sistema. El enfoque se centra en el arranque, que es el proceso de establecer los fundamentos para futuras decisiones de confiabilidad. Esta fase implica principalmente la implementación funcional con extensiones secundarias a las prácticas actuales.

Esta fase incluye la investigación, la obtención de información y la creación de un inventario de los sistemas. También usa características de confiabilidad integradas en Azure, como habilitar la redundancia de zona para mejoras inmediatas.

Al establecer estos conceptos básicos, puede preparar al equipo para avanzar a través de los niveles del modelo de madurez de confiabilidad para mejorar progresivamente la resistencia y el rendimiento del sistema.

Estrategias clave

✓ Evaluar oportunidades para descargar la responsabilidad operativa

Esta estrategia es fundamentalmente un enfoque de desarrollo frente a uno de compra o dependencia de terceros. La decisión depende de la cantidad de responsabilidad que se pueda administrar en esta fase, a la vez que se sigue apoyando el desarrollo futuro. Se desea usar recursos relevantes para la carga de trabajo, pero siempre es necesario explorar las oportunidades para delegar su mantenimiento. Estos son algunos casos de uso clásicos en los que es posible que quiera aplicar este enfoque.

• Descargue las responsabilidades en la plataforma en la nube eligiendo soluciones de plataforma como servicio (PaaS). Proporcionan soluciones preparadas para necesidades comunes de resistencia, como la replicación, la conmutación por error y los almacenes de copia de seguridad. Al adoptar este enfoque, el proveedor de nube controla las mejoras de hospedaje, mantenimiento y resistencia.

  Por ejemplo, el proveedor de nube replica datos en varios nodos de proceso y distribuye las réplicas entre zonas de disponibilidad. Si crea su propia solución en máquinas virtuales (VM), debe administrar estos aspectos usted mismo, lo que puede llevar mucho tiempo y ser complejo.

• Delegue responsabilidades operativas que no están directamente alineadas con los objetivos empresariales de la carga de trabajo. Algunas operaciones especializadas, como la administración de bases de datos y la seguridad, pueden afectar potencialmente a la confiabilidad de la carga de trabajo. Explore la posibilidad de tener equipos experimentados, tecnología o ambos controlar esas tareas.

  Por ejemplo, si el equipo no tiene experiencia en bases de datos, use servicios administrados para ayudar a cambiar la responsabilidad al proveedor. Este enfoque puede ser útil al empezar porque permite al equipo centrarse en la funcionalidad de la carga de trabajo. Muchas empresas han compartido servicios administrados centralmente. Si los equipos de plataforma están disponibles, úselos para controlar estas operaciones. Sin embargo, este enfoque podría agregar dependencias y complejidad organizativa.

  Como alternativa, si el equipo tiene la experiencia adecuada, puede tomar una decisión explícita de usar sus aptitudes y seleccionar servicios que no incluyan funcionalidades de administración.

• Descargue las responsabilidades de los proveedores que no son de Microsoft. Elija productos fuera de la estantería como punto de partida. Cree soluciones personalizadas solo cuando contribuyen al valor empresarial de la carga de trabajo.

Riesgo: Si la opción comprar o confiar cumple parcialmente sus requisitos, es posible que tenga que implementar extensiones personalizadas. Este método puede dar lugar a una situación de "bloqueo de personalización", donde las actualizaciones y la modernización resultan poco prácticas. Revise periódicamente los requisitos y compárelos con las funcionalidades de la solución. Desarrolle una estrategia de salida para cuando haya una desviación significativa entre los dos.

El escenario opuesto también es un riesgo. Aunque la opción de compra o confianza puede parecer más sencilla al principio, podría requerir volver a evaluar y rediseñar más adelante si las limitaciones del servicio PaaS, la solución de proveedor o los recursos propiedad de la plataforma no cumplen la granularidad o el nivel de autonomía necesarios para la carga de trabajo.

✓ Identificar los flujos críticos de usuario y sistema

Dividir la carga de trabajo en flujos es fundamental en esta fase. Céntrese en los flujos de usuario y sistema . Los flujos de usuario determinan las interacciones del usuario y los flujos del sistema determinan la comunicación entre los componentes de carga de trabajo que no están asociados directamente con las tareas del usuario.

Por ejemplo, en una aplicación de comercio electrónico, los clientes realizan actividades de front-end, como la exploración y el orden. Mientras tanto, las transacciones de back-end y los procesos desencadenados por el sistema cumplen las solicitudes de usuario y controlan otras tareas. Esos flujos distintos forman parte del mismo sistema, pero implican distintos componentes y sirven para distintos propósitos.

Empiece a crear un catálogo de flujos en esta fase. Observe las interacciones del usuario y la comunicación de componentes. Enumere y clasifique los flujos, defina sus puntos iniciales y finales y anote las dependencias. Documente los resultados y las excepciones mediante diagramas para mayor claridad. Este catálogo puede servir como una herramienta importante para la conversación inicial con las partes interesadas empresariales para identificar los aspectos más importantes desde su perspectiva. Esta conversación puede informar al primer nivel de priorización.

Clasifique un flujo como crítico mediante la evaluación del riesgo y el impacto en las actividades empresariales principales. Si espera una interrupción, la degradación correcta se centra en mantener estos flujos críticos. En el ejemplo de comercio electrónico, los flujos críticos incluyen búsquedas de productos, agregar artículos al carrito y procesar el pago porque estas tareas son esenciales para el negocio. Otros procesos, como actualizar los datos del producto y mantener imágenes de producto, no son tan críticos. Asegúrese de que los flujos críticos permanecen operativos durante una interrupción para evitar la pérdida de ingresos al permitir que los usuarios sigan buscando productos y agregando elementos al carro.

Para más información, consulte Azure Well-Architected Framework: Optimización del diseño de cargas de trabajo mediante flujos.

✓ Seleccione el modelo de diseño adecuado, los recursos y las características.

Debe aplicar esta estrategia en los siguientes niveles:

• Arquitectura: El diseño de la carga de trabajo debe tener en cuenta las expectativas de confiabilidad en varios niveles de infraestructura. Las decisiones iniciales pueden ser la elección entre la contenedorización o PaaS para hospedar la aplicación. O bien, puede considerar las configuraciones de red, como el centro y el radio (hub and spoke) o una sola red virtual.

  También debe establecer límites que creen segmentación en función de la funcionalidad. Por ejemplo, en lugar de hospedar todo en una máquina virtual con un disco virtual de una sola zona, considere la posibilidad de dividir el almacenamiento de datos y el proceso y el uso de servicios dedicados.

  Precaución

  En escenarios de migración, adoptar un enfoque lift-and-shift sin revisar nuevas oportunidades puede resultar en beneficios perdidos e ineficiencias. Es importante investigar la modernización pronto para evitar que se bloquee con las configuraciones que son difíciles de cambiar y para aprovechar las mejores opciones y mejoras.

• Servicios de Azure: Use árboles de decisión para ayudarle a seleccionar los servicios adecuados para su diseño. Elija los componentes que satisfagan sus necesidades actuales, pero siga siendo flexible para poder cambiar los servicios a medida que evoluciona la carga de trabajo y requiere más características.

• SKU o niveles dentro de los servicios de Azure: Revise las características de cada SKU y comprenda las garantías de disponibilidad de la plataforma. Evalúe los acuerdos de nivel de servicio para comprender la cobertura proporcionada alrededor del percentil publicado.

• Características que admiten la confiabilidad: Elija servicios nativos en la nube para mejorar la disponibilidad a través de configuraciones sencillas sin cambiar el código. Es importante comprender las opciones y seleccionar intencionadamente las configuraciones, como aumentar la redundancia de zona o replicar datos en una región secundaria.

✓ Implementar con un nivel básico de redundancia

Dentro de cada parte de la solución, evite puntos únicos de error, como instancias únicas. En su lugar, cree varias instancias para la redundancia. Los servicios de Azure suelen controlar la redundancia, especialmente con los servicios PaaS, que normalmente incluyen redundancia local de forma predeterminada y opciones para actualizar. Preferiblemente, use redundancia de zona para distribuir esas instancias entre varios centros de datos de Azure. Si no lo hace, al menos garantiza la redundancia local, pero este método conlleva un mayor riesgo. En los niveles futuros, evaluará si es posible que se cumplan los requisitos de confiabilidad ampliando la solución con componentes con redundancia geográfica.

Compensación: Una compensación significativa es el mayor costo de redundancia. Además, la comunicación entre zonas puede introducir latencia. En el caso de las aplicaciones heredadas que requieren una latencia mínima, la redundancia puede degradar el rendimiento.

Riesgo: Si una aplicación no está diseñada para un entorno de varias instancias, podría tener problemas con varias instancias activas, lo que puede provocar datos incoherentes. Además, si una aplicación se compila para una configuración local que tiene baja latencia, el uso de zonas de disponibilidad podría interrumpir su rendimiento.

✓ Habilite métricas, registros y seguimientos para supervisar los flujos

Elija herramientas nativas de plataforma como Azure Monitor para garantizar la visibilidad de las métricas, los registros y los seguimientos. Use características integradas para establecer alertas para posibles problemas. Debe tener alertas básicas para enviar notificaciones y obtener alertas. Aproveche las funcionalidades de la plataforma Azure que indican los cambios en el estado de mantenimiento de los servicios, como:

• Azure Service Health para comprobar el estado de funcionamiento a nivel de plataforma.

• Azure Resource Health para comprobar el estado de salud a nivel de recurso.

Configure grupos de acciones de Azure Monitor para la infraestructura y la aplicación.

Dilema: A medida que recopila más registros, debe administrar el volumen creciente, lo que afecta a los costos relacionados con el almacenamiento de esos registros. Use directivas de retención para administrar el volumen. Use Azure Monitor para establecer un límite diario en un área de trabajo. Para obtener más información, consulte Recomendaciones de configuración para confiabilidad.

Comience a crear observabilidad en las capas siguientes.

Infraestructura

Comience habilitando los registros de diagnóstico y asegurándose de recopilar métricas nativas de los componentes de la plataforma para su análisis. Recopile información sobre el uso de recursos, como CPU, memoria, entrada/salida y actividad de red.

Aplicación

Recopile métricas de nivel de aplicación, como el consumo de memoria o la latencia de solicitudes, y registre las actividades de la aplicación. Realice el registro de operaciones en un hilo o proceso independiente del hilo de aplicación principal. Este enfoque no hace que el registro ralentice las tareas principales de la aplicación.

Además, compruebe las pruebas de disponibilidad básicas en Application Insights.

Datos

Para supervisar las bases de datos en un nivel básico, recopile métricas clave que emiten los recursos de la base de datos. De forma similar a los componentes de infraestructura, realice un seguimiento del uso de recursos en el contexto de los almacenes de datos, como las métricas de red. La recopilación de datos sobre cómo se agrupan las conexiones es importante para mejorar la eficacia en las fases posteriores.

Para la confiabilidad, es importante realizar un seguimiento de las métricas de conexión, como la supervisión de conexiones activas y con errores. Por ejemplo, en Azure Cosmos DB, se devuelve un código de estado 429 cuando el número de solicitudes supera las unidades de solicitud asignadas y las conexiones comienzan a generar errores.

✓ Empezar a crear un cuaderno de estrategias de mitigación de errores

Los errores van desde errores transitorios intermitentes a ligeramente extendidos y interrupciones catastróficas.

En el nivel 1, céntrese en los errores de la plataforma. A pesar de que están fuera de su control, todavía debe tener estrategias para controlarlas. Por ejemplo, solucione las interrupciones zonales mediante zonas de disponibilidad. Anticipar fallos transitorios en el nivel de plataforma y gestionarlos en la carga de trabajo.

El proceso de control de estos errores varía en función de la complejidad. Comience a documentar posibles errores de nivel de plataforma, sus riesgos asociados y las estrategias de mitigación. Este ejercicio es principalmente teórico y madura con automatización en niveles posteriores.

Debe documentar errores, incluidos factores como su probabilidad, impacto y estrategias de mitigación. Use una escala de importancia crítica que se alinee con los objetivos de la carga de trabajo. Tu escala puede incluir:

• Alto. Una interrupción completa del sistema que da lugar a una pérdida financiera significativa y un descenso en la confianza del usuario.

• Mediana. Una interrupción temporal que afecta a parte de la carga de trabajo y provoca molestias del usuario.

• Bajo. Un problema de software menor que afecta a una característica no esencial de la aplicación y provoca un tiempo de inactividad mínimo para los usuarios.

Esta es una plantilla de ejemplo:

En el nivel 1, no te esfuerces por lograr una cobertura completa porque siempre hay casos de fallo imprevistos. Si experimenta interrupciones inesperadas, documente las causas y mitigaciones en el manual de operaciones. Trate este recurso como un documento activo que actualice con el tiempo.

✓ Agregar mecanismos para recuperarse de errores transitorios

En un entorno de nube, los errores transitorios son comunes. Indican problemas temporales que los reintentos normalmente pueden resolver en cuestión de segundos.

Utilice SDKs y configuraciones integrados para gestionar estos errores y mantener el sistema activo. Las configuraciones integradas suelen ser la configuración predeterminada, por lo que es posible que tenga que probar para validar la implementación. Además, implemente patrones diseñados para controlar errores transitorios en la arquitectura. Para obtener más información, consulte Patrones de diseño de arquitectura que admiten la confiabilidad.

Los problemas persistentes pueden indicar un error que no es transitorio o el inicio de una interrupción. Este escenario requiere más que corregir problemas localizados dentro de la aplicación. Implica examinar los flujos críticos de usuario y sistema del sistema y agregar técnicas de autoconservación y esfuerzos de recuperación. Estos métodos son prácticas maduras que describe el nivel 2.

✓ Ejecutar pruebas básicas

Integre las pruebas de confiabilidad básicas en las primeras fases del ciclo de vida de desarrollo de software. Busque oportunidades para realizar pruebas, empezando por pruebas unitarias para validar la funcionalidad y las configuraciones.

Además, desarrolle casos de prueba sencillos para los problemas que identifique en el cuaderno de estrategias de mitigación de riesgos. Céntrese en mitigaciones de mayor impacto y menor esfuerzo. Por ejemplo, simulación de interrupciones de red o problemas de conectividad intermitentes para ver cómo la lógica de reintento resuelve las interrupciones.

Riesgo: Las pruebas a menudo presentan fricción en el ciclo de desarrollo. Para mitigar este riesgo, haga que las pruebas de confiabilidad sean rastreables junto con las tareas de desarrollo.

El desarrollo de características es la prioridad y las pruebas pueden introducir fricción en el ciclo de desarrollo. Es más fácil iniciar las pruebas antes de que se complete el desarrollo de características. El diseño de aspectos no funcionales de la aplicación al principio le permite ampliarlos a medida que agrega funcionalidades funcionales, en lugar de crear un trabajo pendiente de problemas para solucionarlos más adelante. Aunque este enfoque requiere más esfuerzo inicialmente, es manejable y evita problemas más grandes más adelante.

Asegúrese de que el sistema permanece funcional y estable mediante la incorporación de funcionalidades de autoconservación y tener un plan de recuperación básico para administrar los errores.

Los errores en la nube son inevitables. Las estrategias de resistencia deben esforzarse por mantener el sistema funcional en todas las condiciones. El nivel 1 presenta métodos para solucionar errores transitorios. El nivel 2 se centra en la incorporación de estrategias de autoconservación para evitar, detectar y recuperarse de errores más duraderos. Si se deja sin resolver, estos problemas pueden convertirse en interrupciones completas.

Los flujos críticos que identifique en el nivel 1 tienen prioridad. Requieren un mayor esfuerzo de resistencia y recuperación para todos los componentes, incluidas las aplicaciones, los servicios y las bases de datos. Espere ajustar los tamaños de aprovisionamiento iniciales, los recuentos de instancias y las directivas de escalado automático para reducir los riesgos de confiabilidad.

En este nivel, sea intencionado con sus prácticas de monitorización y pruebas. Use técnicas de supervisión avanzadas que se adapten a las necesidades técnicas y que estén limitadas a los equipos de desarrollo. Expanda el cuaderno de estrategias sencillo para cubrir los componentes arquitectónicos que posee y desarrolla, como el código de las aplicaciones.

Estrategias clave

✓ Evaluar el estado actual de resistencia para protegerse frente a errores

• ¿El nivel de redundancia es lo suficientemente bueno como para resistir errores? Defina una estrategia de redundancia que especifique el número de recursos redundantes que se van a mantener. Determine dónde colocar estos recursos, ya sea localmente, entre zonas o en ubicaciones distribuidas geográficamente. Evalúe la configuración de la plataforma en la nube y seleccione un nivel que satisfaga las necesidades empresariales y las ventajas comerciales aceptables.

• ¿Los componentes de carga de trabajo están lo suficientemente aislados como para contener sus errores? Los patrones como el patrón Bulkhead ayudan a crear resistencia y aislamiento de errores. El patrón Bulkhead divide un sistema en componentes aislados, conocidos como mamparos, para evitar que los fallos se propaguen a otras partes del sistema.

• ¿Los componentes de la ruta crítica se comunican de forma asincrónica? Si no es así, use métodos de comunicación, como colas. Este enfoque mantiene el sistema en funcionamiento incluso si se produce un error en un componente descendente. También impide que el sistema entre en un estado indeterminado. Explore las opciones de Azure, incluido Azure Service Bus para colas y Azure Event Hubs para flujos de eventos.

  Dilema: La comunicación asincrónica puede ayudar a evitar errores en cascada mediante procesos de desacoplamiento. Sin embargo, agrega latencia en la ruta de comunicación, lo que puede suponer un problema para los componentes críticos. Evalúe el impacto en el rendimiento antes de realizar cambios en los patrones de diseño.

• ¿Están diseñadas las operaciones para la coherencia? Los recursos, como los secretos de aplicación y los certificados, pueden expirar y requerir la actualización normal. Las incoherencias en las actualizaciones rutinarias pueden dar lugar a problemas de confiabilidad.

  Idealmente, identifique y elimine las tareas en curso operadas por personas porque son propensas a errores y pueden causar incoherencias que suponen riesgos de confiabilidad. Descargue tantas tareas operativas como sea posible en el proveedor de nube. Por ejemplo, use identidades administradas que microsoft Entra ID proporciona y certificados de seguridad de la capa de transporte (TLS) que administra Azure Front Door.

  La supervisión es necesaria para medidas proactivas, como el seguimiento de la expiración del certificado y la recepción de notificaciones. La aplicación debe registrar eventos importantes, como un certificado TLS que se acerca a la expiración. El uso de varios métodos para comprobar posibles errores ayuda a garantizar que se realizan las acciones necesarias.

✓ Agregar funcionalidades técnicas en el sistema de supervisión

En el nivel 1, ha recopilado datos de supervisión de los componentes de carga de trabajo, con un enfoque en la infraestructura. El análisis básico está completo y se establecen alertas básicas. Esta configuración es esencial para comprender el rendimiento de línea base de los componentes de carga de trabajo e identificar el comportamiento anómalo.

El nivel 2 lleva a cabo la supervisión un paso más allá agregando funcionalidades avanzadas de observabilidad a los recursos de carga de trabajo y adoptando un enfoque más estructurado para analizar los datos de supervisión. Aproveche las herramientas de análisis que proporciona el servicio en la nube. Por ejemplo, las herramientas de información de Azure Monitor, como VM Insights y network Insights, proporcionan visualizaciones de estado y rendimiento entre dependencias.

Planee las funcionalidades de observabilidad en las capas siguientes.

Aplicación

• Responder al sondeo de estado de salud. Habilite la aplicación para responder a las solicitudes de comprobación de estado de las sondas. La aplicación debe tener puntos de conexión dedicados para las verificaciones de salud que, como mínimo, proporcionen información de estado, como correcto o incorrecto. Este enfoque permite a los sistemas de supervisión evaluar si la aplicación funciona correctamente y puede controlar las solicitudes, o si hay problemas que deben solucionarse.

  Los servicios de equilibrio de carga de Azure, como Azure Front Door, Azure Traffic Manager, Azure Application Gateway y Azure Load Balancer, admiten sondeos de estado. Los sondeos de estado envían solicitudes de comprobación de estado a las aplicaciones.

• Avance al registro semántico. Incluya información estructurada sobre eventos y acciones en la aplicación. Con el registro estructurado, los datos de registro se registran en un formato coherente mediante un esquema bien definido. Este esquema facilita la creación de automatización, búsqueda y análisis en fases posteriores. Incluya campos específicos como marcas de tiempo y códigos de error para ayudar a identificar y solucionar problemas rápidamente.

• Implemente el seguimiento distribuido. Cuando una solicitud fluye a través de distintos componentes del sistema, es importante capturar datos de seguimiento a través de los límites. Estos datos son útiles para obtener información sobre el comportamiento de la aplicación e identificar cuellos de botella de rendimiento, errores y problemas de latencia. Azure Monitor admite la recopilación de datos basada en OpenTelemetry con Application Insights.

Datos

• Realice un seguimiento de la duración de la consulta, las consultas con errores y otras métricas pertinentes. Las consultas de larga duración pueden indicar restricciones de recursos y, posiblemente, una necesidad de ajustar el diseño del esquema.

  En esta fase, la base de datos ha estado funcionando durante algún tiempo. Preste atención a la tasa de crecimiento de datos, especialmente en las tablas que crecen inesperadamente rápido. Esta información es fundamental para planear las necesidades futuras de almacenamiento y abordar los problemas de rendimiento al principio.

• Supervise el estado de la replicación de la base de datos mediante las herramientas y el panel que proporciona el sistema de administración de bases de datos. Por ejemplo, si usa Azure Cosmos DB, use Azure Cosmos DB Insights. Para Azure SQL Database o Azure SQL Managed Instance, considere la posibilidad de usar el monitor de base de datos para obtener detalles de diagnóstico sobre las bases de datos.

  A medida que crece la base de datos, es posible que los problemas de esquema se vuelvan más evidentes, lo que afecta al rendimiento. Para optimizar la eficacia de las consultas, considere la posibilidad de agregar índices o modificar el esquema porque estos cambios pueden afectar a la confiabilidad.

Operaciones

El nivel 1 se centra en las capas anteriores. En el nivel 2, usted empezará a desarrollar operaciones en torno al sistema de monitoreo.

• Almacene los registros el tiempo suficiente para obtener información. Desde una perspectiva de confiabilidad, configure la duración de retención para que pueda recopilar suficientes datos para detectar patrones de error, solucionar problemas y realizar análisis de la causa principal.

• Supervise los procesos de copia de seguridad y recuperación. Asegúrese de que las copias de seguridad se almacenan correctamente en ubicaciones según lo planeado y que los datos de la carga de trabajo se recuperan en un período de tiempo razonable. La supervisión de esos procesos es importante para establecer líneas base para las métricas de objetivo de punto de recuperación (RPO) en niveles posteriores.

✓ Ampliar el cuaderno de estrategias de mitigación de errores

El nivel 1 se centra en los errores esperados de la plataforma. En el nivel 2, se abordan los puntos de falla en los componentes y las operaciones dentro de tu propia carga de trabajo. A medida que el código se ejecuta en la plataforma, aumentan los puntos de interacción entre la plataforma y la aplicación. Espere errores de errores en el código, implementaciones incorrectas y errores humanos. Mitigue estos problemas mediante el uso de tácticas de recuperación o autoconservación.

Amplíe el cuaderno de estrategias de mitigación de errores para incluir errores y problemas de implementación. La tabla siguiente se basa en la plantilla de Nivel 1:

Este ejercicio puede resultar abrumador si intenta tener en cuenta todos los posibles errores. Para facilitarlo, céntrese en los componentes que forman parte de los flujos críticos de usuario. Este documento vivo sigue creciendo a medida que la carga de trabajo madura.

✓ Desarrollar un plan de recuperación básico

El cuaderno de estrategias de mitigación de errores es la base para crear un plan de recuperación básico. Las estrategias de mitigación pueden incluir la implementación de patrones de diseño, los ajustes de configuración de la plataforma, la administración de incidentes del sitio activo, las pruebas automatizadas y el personal de entrenamiento para detectar problemas durante las revisiones de código.

Comience con una estrategia de degradación correcta, que incluye correcciones temporales cuando las partes del sistema no funcionan correctamente. El objetivo es seguir atendiendo a los usuarios a pesar de los errores al deshabilitar las partes que no funcionan y ajustar la experiencia del usuario. Por ejemplo, si una base de datos está inactiva, la aplicación puede deshabilitar la característica afectada e informar a los clientes de que el servicio no está disponible temporalmente mediante códigos de estado HTTP.

Para que la degradación correcta funcione, aísle los componentes del sistema para que solo las partes afectadas experimenten problemas mientras el resto de los componentes siguen funcionando. Use el patrón Bulkhead para lograr el aislamiento de errores.

Aproveche esta oportunidad para revisar las opciones de diseño que podrían ralentizar la recuperación. Por ejemplo, apuntar registros del sistema de nombres de dominio (DNS) directamente a la aplicación en Azure App Service puede provocar retrasos durante la recuperación debido a la propagación de DNS. Use un servicio dedicado como Azure Front Door como punto de entrada para facilitar la reconfiguración durante los pasos de recuperación.

Espere que este plan básico evolucione en un plan de recuperación ante desastres completo en niveles más maduros.

✓ Crear planes de prueba

Cree planes de prueba simulando interrupciones y problemas identificados en el cuaderno de estrategias de mitigación de riesgos. Complemente esas mitigaciones con casos de prueba simples para asegurarse de que funcionan según lo previsto y son factibles. Compruebe que estas características funcionan correctamente y realice pruebas de degradación para ver cómo funciona el sistema cuando se produce un error en determinados componentes. Mantenga el resultado sencillo asegurándose de que la prueba sea o no sea superada.

Use herramientas de prueba como marcos de trabajo ficticios para insertar errores en solicitudes HTTP, lo que le ayudará a probar las directivas de reintento de forma más explícita. Azure Chaos Studio proporciona un conjunto de pruebas completo para simular interrupciones de componentes y otros problemas, lo que hace que sea un servicio valioso para explorar. Puede adoptar gradualmente Chaos Studio a medida que esté familiarizado con sus características.

✓ Evaluar el impacto de las operaciones de escalado en la confiabilidad

Para manejar los picos de carga, los componentes críticos deben ser capaces de ampliarse horizontalmente o crecer verticalmente de forma eficaz. Aproveche las funcionalidades de escalado automático que proporciona Azure. Estas funcionalidades ajustan los límites de capacidad de un servicio en función de las configuraciones predefinidas. Este ajuste le permite escalar o reducir el servicio según lo necesite.

• Identifique posibles cuellos de botella y comprenda los riesgos que podrían suponer. Por ejemplo, un alto rendimiento no debe hacer que el flujo se descomponga.

• Comprenda los patrones de carga. Los patrones de uso estáticos pueden hacer que los cuellos de botella sean menos críticos, pero los cambios en la dinámica de uso y consumo pueden empeorar los riesgos.

  Nota:

  Puede haber componentes que no se pueden escalar horizontalmente, como bases de datos monolíticas y aplicaciones heredadas. Supervise de forma proactiva la curva de carga para permitir la nueva arquitectura si es necesario.

• Decida los límites de escalado que sean razonables en función de los requisitos de rendimiento y confiabilidad. En el caso de los problemas de rendimiento, aumentar los recursos gradualmente es más común. Sin embargo, los problemas de confiabilidad de los flujos críticos pueden requerir un escalado más rápido para evitar interrupciones. En cualquier caso, evite el escalado infinito.

Riesgo: Cuando se tratan problemas relacionados con el rendimiento, el escalado puede ser una estrategia de mitigación útil. Sin embargo, el escalado es una corrección temporal y no una solución. Investigue y resuelva el problema subyacente, como una pérdida de memoria o un proceso descontrolado. De lo contrario, corre el riesgo de volver a aplicar la misma mitigación en otro punto crítico, lo que resulta en pagar por recursos innecesarios. Al abordar la causa principal, puede garantizar la estabilidad a largo plazo y la rentabilidad.

Establecer objetivos y objetivos de confiabilidad para mantener al equipo responsable de los procedimientos de recuperación.

En los primeros niveles, los equipos se centran en las victorias fáciles y las funcionalidades básicas. Comienzan con pequeñas mejoras, solucionando problemas sencillos para crear una base sólida mientras se basan principalmente en las funcionalidades de confiabilidad de Azure. A medida que los equipos crecen, controlan más desafíos técnicos relacionados con sus propios recursos y procesos.

En el nivel 3, los equipos deben integrar conocimientos empresariales y aptitudes técnicas para el planeamiento de la recuperación. Establecen objetivos y planean procesos de recuperación mediante la supervisión avanzada. Este enfoque ayuda a los ingenieros de confiabilidad de sitios (SRE) a cumplir rápidamente los objetivos de confiabilidad.

Estrategias clave

✓ Formalizar las capacidades de confiabilidad como objetivos

Los objetivos de confiabilidad ayudan a establecer la responsabilidad de los equipos de cargas de trabajo. Es importante tener una conversación colaborativa con las partes interesadas de la empresa para analizar los costos y los tiempos de recuperación, y hacer compromisos que se adapten a los objetivos empresariales. Reúna a las partes interesadas y lleve a cabo este debate como taller. Tenga en cuenta los siguientes puntos para la agenda del taller:

• Explicar las métricas subyacentes a los objetivos. Empiece por explicar las métricas clave que se usan para definir objetivos como objetivos de nivel de servicio, objetivos de tiempo de recuperación (RTO) y objetivos de punto de recuperación (RPO). Mostrar cómo se alinean esas métricas con los objetivos empresariales. Céntrese en los flujos críticos de usuario. Por ejemplo, en una aplicación de comercio electrónico, el RTO para actualizar las preferencias de correo electrónico es menos importante que los usuarios concluyendo las compras en los carros.

• Comunique las ventajas y desventajas. Las partes interesadas suelen esperar más de lo que se puede lograr. Explicar cómo la expansión del ámbito afecta al presupuesto, los requisitos operativos y el rendimiento.

• Proponer objetivos objetivos. En función de la experiencia de arquitectura y el diseño de cargas de trabajo, se recomiendan objetivos como tiempo de actividad de 99.9%, con RPO y RTO establecido en cuatro horas. Facilitar una discusión para que las partes interesadas proporcionen comentarios y realicen ajustes. Asegúrese de que tanto las partes interesadas empresariales como técnicas protegen contra las expectativas poco realistas. Enfoque las discusiones con una mentalidad colaborativa.

• Alcance un consenso o una decisión. Aspira a un consenso, pero si eso no es posible, haga que un responsable de la toma de decisiones finalice los objetivos para garantizar el progreso.

✓ Supervisar de forma proactiva mediante el modelo de salud

En el nivel 1, los datos de supervisión se recopilan de componentes de carga de trabajo, incluidos los servicios de plataforma y las aplicaciones. El análisis básico y las alertas se establecen para establecer el rendimiento de línea base e identificar anomalías. En el nivel 2, el foco cambia a la obtención de datos de observabilidad de componentes de carga de trabajo, como el código de la aplicación.

El nivel 3 mejora la monitorización agregando contexto de negocio a los flujos críticos y definiendo los estados saludable, no saludable y degradados a través del modelado de salud. El acuerdo de la parte interesada es necesario para determinar los compromisos aceptables de la experiencia del usuario y debe usarse como entrada para definir los estados de salud.

El modelado de salud requiere madurez operativa y experiencia en las herramientas de monitorización. El equipo revisa los datos sin procesar, los niveles de rendimiento y los registros para crear métricas y umbrales personalizados que definen el estado de mantenimiento del flujo. Deben comprender cómo se relacionan estos valores con el estado general del sistema. Comunicar definiciones y umbrales claros a las partes interesadas.

Visualice el modelo de salud en los paneles para ayudar a los SREs a identificar rápidamente los problemas centrándose en flujos no saludables o degradados.

El modelo de mantenimiento define el estado de la aplicación y los flujos críticos. Green indica que todos los flujos críticos funcionan según lo previsto. Rojo indica un error. Y amarillo muestra las tendencias hacia los problemas. La iteración a través de las versiones del modelo de estado garantiza la confiabilidad y la precisión, pero requiere un esfuerzo significativo para aplicaciones grandes.

Se debe configurar un cambio en el estado de salud como alertas. Sin embargo, para mantener las alertas intencionadas, se debe tener en cuenta la importancia crítica del componente.

Para obtener más información, consulte Well-Architected Marco: Modelado de salud.

✓ Establecer alertas accionables

Para mejorar la eficacia de la respuesta, defina alertas claramente y proporcione suficiente información para una acción rápida. Los nombres y descripciones de alertas detallados pueden ayudar a ahorrar tiempo y esfuerzo durante la solución de problemas. Configure cuidadosamente la gravedad, el nombre y la descripción, con especial atención a los niveles de gravedad. No todos los eventos son de emergencia. Evalúe cuidadosamente los niveles de gravedad y establezca criterios para cada nivel, como si un pico de CPU de 80% a 90% se califica como una emergencia. Establezca umbrales adecuados para asegurarse de que las alertas se definen de forma eficaz.

La administración de alertas eficaz garantiza que las alertas notifiquen a las personas adecuadas en el momento adecuado. Las alertas frecuentes y perjudiciales indican una necesidad de ajuste y pueden convertirse en contraproductivas cuando se omiten. Reduzca las notificaciones innecesarias estableciendo umbrales adecuados para filtrar las falsas alarmas. Identifique las oportunidades en las que la automatización puede desencadenar procedimientos operativos.

Cree una sola página de aterrizaje que tenga la información necesaria para solucionar problemas de alertas de forma eficaz. Este enfoque ahorra tiempo en comparación con el inicio de sesión en Azure Portal y la búsqueda de métricas. Si las características integradas de Azure Monitor no satisfacen completamente sus necesidades, considere la posibilidad de desarrollar un panel personalizado.

✓ Realizar análisis del modo de fallo

En los niveles anteriores, creó un cuaderno de estrategias de mitigación de errores simple para componentes individuales. En este nivel, desarrolle ese cuaderno de estrategias en un ejercicio de análisis formal del modo de error (FMA). El propósito de este ejercicio es identificar proactivamente posibles modos de error.

FMA requiere que identifique posibles puntos de error dentro de la carga de trabajo y planee acciones de mitigación, como la recuperación automática o la recuperación ante desastres (DR). Para empezar, supervise las mayores tasas de errores y detecte impactos en los flujos críticos. Use experiencias pasadas y pruebe datos para identificar posibles errores y evaluar su radio de explosión. Priorice los principales problemas, como una interrupción en toda la región.

Es importante clasificar acciones como preventivas o reactivas. Las acciones preventivas identifican los riesgos antes de que provoquen una interrupción, lo que reduce su probabilidad o gravedad. Las acciones reactivas abordan problemas para mitigar un estado de salud degradado o una interrupción.

En la aplicación de ejemplo de comercio electrónico, el equipo de gestión de carga de trabajo quiere realizar un FMA para prepararse para un evento importante. Uno de los flujos de usuario clave es agregar elementos al carro. Los componentes que forman parte del flujo son el front-end, CartAPI, ProductCatalogAPI, UserProfileAPI, PricingAPI, Azure Cosmos DB y Azure Event Hubs.

FMA es compleja y puede requerir mucho tiempo, por lo que desarrolle su análisis de manera progresiva. Este proceso es iterativo y continúa evolucionando en fases posteriores.

Para obtener más información, consulte RE:03 Recomendaciones para realizar FMA.

✓ Preparar un plan de recuperación ante desastres

En el nivel 2, creó un plan de recuperación centrado en los controles técnicos para restaurar la funcionalidad del sistema. Sin embargo, un desastre requiere un enfoque más amplio debido a una pérdida o error catastróficos. Los planes de recuperación ante desastres se basan en procesos. Cubren la comunicación, los pasos de recuperación detallados y, posiblemente, incluyen artefactos técnicos como scripts.

En primer lugar, identifique los tipos de desastres para los que planear, como interrupciones de regiones, errores en toda Azure, interrupciones de la infraestructura, daños en la base de datos y ataques de ransomware. A continuación, desarrolle estrategias de recuperación para cada escenario y asegúrese de que se aplican mecanismos para restaurar operaciones. Los requisitos empresariales, los RTO y los RPO deben guiar los planes de recuperación ante desastres. Los RPO y los RPO bajos requieren procesos automatizados explícitos, mientras que los RPO y los RPO superiores permiten métodos de recuperación más sencillos y análisis manual.

La recuperación ante desastres (DR) incluye principalmente las siguientes acciones:

• Notificar a las partes responsables. Es importante tener claridad sobre quién involucrar y cuándo. Asegúrese de que el equipo usa los procesos correctos, tiene los permisos adecuados y entiende sus roles en la recuperación. Algunas responsabilidades, como el director ejecutivo informando al mercado o gestionando los requisitos normativos, deben identificarse pronto.

  Idealmente, debe tener roles de recuperación y comunicación independientes y asignar diferentes personas a cada rol. Inicialmente, la persona de operaciones de TI que detecta el problema podría controlar ambos roles. Pero a medida que se escala la situación, el personal sénior podría controlar la recuperación técnica mientras una persona empresarial administra las comunicaciones.

• Tome decisiones empresariales. Durante un desastre, los niveles de estrés pueden ser altos, lo que hace que sea fundamental tomar decisiones claras. Un plan de recuperación ante desastres bien estructurado requiere discusiones continuas entre el equipo técnico y las partes interesadas empresariales para definir opciones de decisión preliminares. Por ejemplo, considere si los recursos de carga de trabajo deben ejecutarse en una región de Azure con copias de seguridad en otra región, o si los recursos de IaC deben prepararse de antemano para crear nuevos recursos o restaurar desde una copia de seguridad durante la conmutación por error.

  Las acciones tomadas según los planes de recuperación ante desastres pueden ser destructivas o tienen efectos secundarios significativos. Es esencial comprender las opciones, ponderar sus ventajas y desventajas, y determinar el momento adecuado para aplicarlas. Por ejemplo, evalúe si la recuperación en una región diferente es necesaria si se espera que la región primaria esté operativa dentro de un período de tiempo aceptable.

• Restaure las operaciones del sistema. Durante un desastre, el enfoque debe estar en la restauración de operaciones y no en identificar la causa. Para la recuperación técnica, especialmente en la conmutación por error de región, decida con antelación los enfoques como activo-activo, activo-pasivo, en espera semiactiva o en espera pasiva.

  Prepare pasos de recuperación específicos en función del enfoque elegido. Comience con una lista concreta de pasos para restaurar operaciones. A medida que el proceso madura, tiene como objetivo definir el plan de recuperación ante desastres como un script con una interacción manual mínima. Use el control de versiones y almacene el script de forma segura para facilitar el acceso. Este enfoque requiere más esfuerzo inicial, pero minimiza el estrés durante un incidente real.

  Para obtener más información, consulte Implementación en activo-pasivo para DR.

• Realice el análisis posterior al incidente. Identifique la causa del incidente y encuentre formas de evitarlo en el futuro. Realice cambios para mejorar los procesos de recuperación. Este ejercicio también podría descubrir nuevas estrategias. Por ejemplo, si el sistema cambió al entorno secundario, determinar si el entorno principal sigue siendo necesario y cuál debe ser el proceso de reversión.

Un plan de recuperación ante desastres es un documento vivo que se adapta a los cambios en la carga de trabajo. Actualice el plan de recuperación ante desastres a medida que surjan nuevos componentes y riesgos. Refinar el plan en función de la información obtenida de los simulacros o desastres reales mediante la recopilación de información realista de los operadores de recuperación ante desastres.

Controlar los riesgos derivados de los cambios técnicos y operativos, y priorizar la administración de incidentes.

En los niveles anteriores, el equipo de trabajo se centra en desarrollar funcionalidades y poner el sistema en funcionamiento. En el nivel 4, el foco cambia a mantener el sistema confiable en producción. La administración de incidentes se convierte en tan importante como asegurarse de que los cambios introducidos se prueban y se implementan de forma segura para evitar que el sistema sea inestable.

Este proceso requiere mejoras en los controles operativos, como invertir en equipos dedicados para administrar incidentes de confiabilidad. También requiere controles técnicos para mejorar la confiabilidad del sistema más allá de los componentes críticos reforzados en niveles anteriores. A medida que el sistema continúa ejecutándose en producción, el crecimiento de los datos podría requerir rediseños, como la creación de particiones, para garantizar un acceso confiable y mantenimiento.

Estrategias clave

✓ Administración confiable de cambios

Los mayores riesgos de confiabilidad se producen durante los cambios, como actualizaciones de software, ajustes de configuración o modificaciones de procesos. Estos eventos son críticos desde el punto de vista de la confiabilidad. El objetivo es minimizar la probabilidad de problemas, interrupciones, tiempo de inactividad o pérdida de datos. Cada tipo de cambio requiere actividades específicas para administrar sus riesgos únicos de forma eficaz.

En el nivel 4, la confiabilidad se interseca con los procedimientos de implementación seguros descritos en Excelencia operativa, al mantener un entorno estable al administrar los cambios. La administración confiable de cambios es un requisito para lograr la estabilidad de la carga de trabajo. Tenga en cuenta los siguientes aspectos clave:

• Reaccionar a las actualizaciones de la plataforma. Los servicios de Azure tienen diferentes mecanismos para actualizar los servicios.

  • Familiarícese con los procesos de mantenimiento y actualice las directivas de cada servicio que use. Comprenda si el servicio admite actualizaciones automáticas o manuales y el período de tiempo para las actualizaciones manuales.

  • En el caso de los servicios que tienen actualizaciones planeadas, administre estas actualizaciones de forma eficaz programandolas durante tiempos de bajo impacto. Evite las actualizaciones automáticas y aplazarlas hasta después de evaluar el riesgo. Algunos servicios le permiten controlar el tiempo, mientras que otros servicios proporcionan un período de gracia. Por ejemplo, con Azure Kubernetes Service (AKS), tiene 90 días para participar antes de que la actualización se convierta en automática. Pruebe las actualizaciones en un clúster que no sea de producción que refleje la configuración de producción para evitar regresiones.

    Aplicar actualizaciones gradualmente. Incluso si las pruebas muestran que la actualización es segura, aplicarla a todas las instancias simultáneamente puede ser arriesgada. En su lugar, actualice algunas instancias a la vez y espere entre cada conjunto.

  • Compruebe periódicamente las notificaciones sobre las actualizaciones, que podrían estar disponibles en los registros de actividad u otros canales específicos del servicio.

  • Supervise si hay cambios repentinos o graduales después de aplicar una actualización. Lo ideal es que su modelo de salud le notifique sobre estos cambios.

• Pruebas exhaustivas con automatización. Integre más pruebas en las canalizaciones de compilación e implementación al implementar los cambios. Busque oportunidades para convertir procesos manuales en partes automatizadas de las canalizaciones.

  Realice pruebas completas mediante una combinación de diferentes tipos de pruebas en varias fases para confirmar que los cambios funcionan según lo previsto y no afectan a otras partes de la aplicación. Por ejemplo, las pruebas positivas pueden comprobar que el sistema funciona según lo previsto. Debe validar que no hay errores y que el tráfico fluye correctamente.

  Cuando planee actualizaciones, identifique las puertas de prueba y los tipos de pruebas que se van a aplicar. La mayoría de las pruebas deben producirse en fases previas a la implementación, pero las pruebas de humo también se deben realizar en cada entorno al actualizarla.

• Siga los procedimientos de implementación seguros. Use topologías de implementación que incluyan ventanas de validación y prácticas de implementación seguras. Implemente patrones de implementación seguros, como implementaciones canario y azul-verde, para mejorar la flexibilidad y la confiabilidad.

  Por ejemplo, en las implementaciones canarias, un pequeño subconjunto de usuarios recibe primero la nueva versión. Este proceso permite la supervisión y validación antes de la implementación en toda la base de usuarios. Las técnicas como las banderas de características y los lanzamientos oscuros facilitan las pruebas en el entorno de producción antes de lanzar cambios a todos los usuarios.

• Actualice el plan de DR. Actualice periódicamente el plan de recuperación ante desastres para mantenerlo relevante y eficaz. Evite las instrucciones obsoletas. Este enfoque garantiza que el plan refleje el estado actual del sistema que está implementado en producción y del que dependen los usuarios. Incorpore las lecciones aprendidas de los simulacros y los incidentes reales.

Para obtener más información, consulte Nivel de excelencia operativa 4.

✓ Invertir en un equipo dedicado para controlar incidentes

Inicialmente, el equipo de desarrollo podría estar implicado durante incidentes. En el nivel 4, invierta en ingeniería de confiabilidad de sitios (SRE) para la administración de incidentes. Los SRE se especializan en problemas de producción y son expertos en eficiencia, gestión de cambios, supervisión, respuesta ante emergencias y gestión de la capacidad. Un equipo de SRE experto puede reducir significativamente la dependencia del equipo de ingeniería.

Proporcione a los SRE las herramientas, la información y los conocimientos necesarios para controlar los incidentes de forma independiente. Esta preparación reduce la dependencia del equipo de ingeniería. Los SREs deben ser capacitados en las guías de respuesta y el modelo de salud de la carga de trabajo desarrollado en niveles anteriores para reconocer rápidamente patrones comunes e iniciar el proceso de mitigación.

El equipo de ingeniería debe tener tiempo para reflexionar sobre problemas recurrentes y desarrollar estrategias a largo plazo, en lugar de abordarlos individualmente cada vez.

✓ Automatizar procesos de autocuración

En los niveles anteriores, las estrategias de recuperación automática están diseñadas mediante patrones de redundancia y diseño. Ahora que el equipo tiene experiencia con el uso real, puede integrar la automatización para mitigar los patrones de error comunes y reducir la dependencia del equipo de ingeniería.

Dilema: La automatización puede tardar tiempo y ser costosa de configurar. Céntrese en automatizar primero las tareas más impactantes, como las tareas que se producen a menudo o que probablemente provoquen interrupciones.

Configure acciones basadas en desencadenadores y automatice las respuestas a lo largo del tiempo para crear un cuaderno de estrategias automatizado para los SRE. Un enfoque consiste en mejorar el cuaderno de estrategias con scripts que implementan pasos de mitigación. Explore las opciones nativas de Azure, como el uso de grupos de acciones de Azure Monitor, para configurar desencadenadores que inician automáticamente varias tareas.

✓ Ampliar la resistencia a las tareas en segundo plano

La mayoría de las cargas de trabajo incluyen componentes que no admiten directamente flujos de usuario, pero que desempeñan un papel fundamental en el flujo de trabajo general de una aplicación. Por ejemplo, en un sistema de comercio electrónico, cuando un usuario realiza un pedido, el sistema agrega un mensaje a una cola. Esta acción desencadena varias tareas en segundo plano, como la confirmación por correo electrónico, la finalización del cargo de tarjeta de crédito y la notificación de almacenamiento para la preparación del envío. Estas tareas funcionan por separado de las funciones que atienden las solicitudes de usuario en el sitio web, lo que reduce la carga y mejora la confiabilidad. Los sistemas también se basan en tareas en segundo plano para la limpieza de datos, el mantenimiento normal y las copias de seguridad.

Después de evaluar y mejorar los flujos de usuario principales, tenga en cuenta las tareas en segundo plano. Use las técnicas y la infraestructura que ya están en vigor y agregue mejoras para las tareas en segundo plano.

• Aplique puntos de control. La creación de puntos de control es una técnica para guardar el estado de un proceso o tarea en puntos específicos. Los puntos de control son especialmente útiles para tareas o procesos de larga duración que podrían interrumpirse debido a problemas inesperados, como errores de red o bloqueos del sistema. Cuando se reinicia el proceso, puede retomarse desde el último punto de control guardado, lo que minimiza el impacto de las interrupciones.

• Mantenga los procesos idempotentes. Asegúrese de la idempotencia en los procesos en segundo plano para que, si se produce un error en una tarea, otra instancia pueda recogerla y continuar el procesamiento sin problemas.

• Asegúrese de la coherencia. Impedir que el sistema entre en un estado incoherente si una tarea en segundo plano se detiene durante el procesamiento. Tanto los puntos de control como la idempotencia a nivel de tarea son técnicas que permiten una mayor coherencia en las operaciones de tareas en segundo plano. Ejecute cada tarea como una transacción atómica. Para una tarea que abarque varios almacenes de datos o servicios, use la idempotencia a nivel de tarea o las transacciones de compensación para asegurarse de que concluya.

• Integre tareas en segundo plano en el sistema de supervisión y las prácticas de prueba. Detecte errores y evite interrupciones desapercibidas que pueden dar lugar a consecuencias funcionales y no funcionales. El sistema de supervisión debe capturar datos de estos componentes, establecer alertas para interrupciones y usar desencadenadores para reintentar o reanudar el proceso automáticamente. Trate estos recursos como parte de la carga de trabajo y realice pruebas automatizadas de la misma manera que para los componentes críticos.

Azure proporciona varios servicios y características para trabajos en segundo plano, como Azure Functions y WebJobs de Azure App Service. Revise sus procedimientos recomendados y límites al implementar flujos que se centran en la confiabilidad.

Permanecer resistente a medida que evoluciona la arquitectura de la carga de trabajo, lo que permite al sistema resistir riesgos nuevos e imprevistos.

En el nivel 5, el enfoque de mejorar la confiabilidad de la solución se aleja de la implementación de controles técnicos. La infraestructura, las aplicaciones y las operaciones deben ser lo suficientemente confiables como para ser resistentes a las interrupciones y recuperarse de ellas dentro de los tiempos de recuperación de destino.

Use datos y objetivos empresariales futuros para reconocer que si su empresa necesita ir más allá, es posible que sea necesario realizar cambios arquitectónicos. A medida que la carga de trabajo evoluciona y se agregan nuevas características, se esfuerza por minimizar las interrupciones relacionadas con esas características, a la vez que se reducen aún más las interrupciones de las características existentes.

Estrategias clave

✓ Usar información de confiabilidad para guiar la evolución de la arquitectura

En este nivel, tome decisiones en colaboración con las partes interesadas empresariales. Tenga en cuenta los siguientes factores:

• Analice las métricas que indican cuántas veces el sistema cruza los umbrales de confiabilidad dentro de un período de tiempo y si es aceptable. Por ejemplo, experimentar cinco fallos críticos en un año podría desencadenar una revisión del diseño del sistema y las prácticas operativas.

• Evalúe la importancia empresarial del sistema. Por ejemplo, un servicio que soporte flujos de trabajo críticos para la misión podría requerir un rediseño para implantaciones de cero tiempo de inactividad y conmutación por error instantánea, incluso si esto aumenta el costo o la complejidad. Por el contrario, un servicio de uso reducido podría beneficiarse de objetivos de nivel de servicio más relajados.

• Evalúe cómo afectan los cambios en otros pilares a la confiabilidad. Por ejemplo, un aumento de las medidas de seguridad puede requerir mitigaciones de confiabilidad para saltos de seguridad adicionales, lo que puede introducir posibles puntos de error.

• Evalúe los costos operativos de mantenimiento de la confiabilidad. Si estos costos superan las restricciones presupuestarias, considere la posibilidad de realizar cambios arquitectónicos para optimizar y controlar el gasto.

Para ayudar a las partes interesadas, ingenieros y administradores de productos a tomar decisiones fundamentadas, considere la posibilidad de visualizar los puntos de datos anteriores junto con información adicional. Este enfoque proporciona una imagen completa de la confiabilidad.

✓ Ejecutar pruebas controladas en producción

En este nivel, considere la posibilidad de realizar experimentos controlados en producción solo si la carga de trabajo requiere las mayores garantías de resistencia. Estas prácticas de prueba se conocen como ingeniería de caos. Las pruebas validan que el sistema puede recuperarse correctamente y continuar funcionando en condiciones adversas.

Tenga en cuenta los siguientes casos de uso de ejemplo:

• Análisis de flujo de dependencias: Un caso de uso común es probar aplicaciones diseñadas como microservicios. Puede desactivar instancias aleatorias de microservicios para asegurarse de que los errores no se producen en cascada ni interrumpir la experiencia del usuario. Puede ampliar este enfoque a los flujos del sistema deshabilitando componentes específicos para analizar cómo reaccionan los sistemas de bajada. El objetivo es identificar dependencias ocultas u acoplamiento estrictos y probar cómo funcionan los planes de redundancia del sistema.

• Pruebas de degradación elegante: Evalúe cómo se ejecuta el sistema con una funcionalidad reducida durante una falla. Por ejemplo, puede ocultar características no críticas si se produce un error en un motor de recomendaciones.

• Simulación de fallos de terceros: Deshabilite o limite las llamadas a APIs externas para ver cómo funciona su sistema y si se implementan correctamente las alternativas o reintentos.

La ingeniería de caos es un estándar de oro para probar la resistencia. Sin embargo, reserve esta práctica para los sistemas maduros y los equipos de trabajo. Asegúrese de que existen medidas de seguridad para limitar el radio de explosión y evitar el impacto del usuario.

• Prepárese ejecutando simulaciones. Comience en entornos que no son de producción que simulan condiciones reales mediante configuraciones de menor riesgo con transacciones sintéticas. Este enfoque ayuda a identificar brechas de procesos, rutas de acceso a errores humanos y defectos arquitectónicos.

  Cuando las pruebas que no son de producción dejan de producir información valiosa, es posible que sea el momento de pasar a producción si está seguro. Asegúrese de enumerar todas las preocupaciones, evaluar la resistencia y solucionar los problemas antes de realizar la transición.

• Limite el ámbito de los experimentos. Por ejemplo, puede apagar una sola instancia. Defina claramente el propósito de la prueba. Comprenda lo que está probando y por qué.

Estas pruebas deben cumplir los acuerdos de nivel de servicio trabajando dentro de los límites predefinidos y los presupuestos de errores. Seleccione los períodos de tiempo adecuados para estos experimentos. Normalmente, realizarlos durante un día laboral garantiza que el equipo esté totalmente equipado y tenga amplios recursos para responder a los incidentes que puedan producirse.

✓ Realizar simulacros de recuperación ante desastres

La ingeniería de caos prueba la resistencia de los controles técnicos. Los simulacros de recuperación ante desastres (DR) evalúan la resistencia de los controles de proceso. El objetivo de los simulacros de recuperación ante desastres es validar la eficacia de los procedimientos, la coordinación y las acciones humanas cuando el sistema se recupera de errores importantes o desastres.

En el caso de las cargas de trabajo normativas, los requisitos de cumplimiento podrían dictar la frecuencia de los simulacros de recuperación ante desastres para asegurar un registro del esfuerzo realizado. Para otras cargas de trabajo, se recomienda realizar estos simulacros con regularidad. Un intervalo de seis meses proporciona una buena oportunidad para capturar los cambios de carga de trabajo y actualizar los procedimientos de recuperación ante desastres en consecuencia.

Los simulacros de recuperación ante desastres deben ser más que ejercicios rutinarios. Cuando se realizan correctamente, los simulacros de recuperación de desastres ayudan a entrenar a los nuevos miembros del equipo e identificar las brechas en las herramientas, la comunicación y otras tareas relacionadas con los simulacros. También pueden resaltar nuevas perspectivas que, de lo contrario, podrían pasarse por alto.

Tenga en cuenta los siguientes métodos clave para realizar simulacros de recuperación ante desastres, cada uno de los cuales varía en riesgo y práctica:

• Totalmente simulado: Estos ejercicios están totalmente basados en pizarras e incluyen tutoriales de procedimientos sin afectar a ningún sistema. Son adecuados para el entrenamiento y la validación inicial. Sin embargo, no proporcionan información sobre incidentes reales.

• Simulacros reales en entornos no productivos: Estos simulacros permiten validar la automatización, los scripts y los procesos sin ningún riesgo empresarial.

• Simulacros reales en producción: Estos simulacros proporcionan el mayor nivel de confianza y realismo. Realice estos simulacros solo después de probar los dos métodos anteriores. Las estrategias de planeación y reversión exhaustivas son esenciales para minimizar el riesgo. No continúe si hay alguna posibilidad de provocar interrupciones.

Independientemente del tipo de simulacro de DR, defina claramente los escenarios de recuperación de cargas de trabajo. Realice simulacros como si fueran incidentes reales. Este enfoque garantiza que el equipo siga listas de comprobación bien comprendidas. Documente y clasifique los resultados para impulsar la mejora continua. La preparación de la recuperación ante desastres puede incluir los siguientes procesos:

• Comprenda los sistemas de administración de incidentes y asegúrese de que el equipo está entrenado en rutas de escalación.

• Enumera las herramientas de comunicación para las actualizaciones de colaboración y estado, incluidas las alternativas en caso de que se vean afectados los sistemas principales.

• Proporcione materiales de formación sobre escenarios de prueba relevantes para la carga de trabajo.

• Realice un seguimiento de las discrepancias para capturar los problemas detectados durante la implementación.

Contrapartida: estos simulacros no suelen ser perjudiciales, pero tardan tiempo. Para maximizar su eficacia, céntrese en los aspectos clave y evite tareas innecesarias. Asegúrese de asignar tiempo para esta práctica en el trabajo pendiente.

Al crear planes de recuperación ante desastres o realizar simulacros de recuperación ante desastres, específicamente para los primeros simulacros, considere la posibilidad de incluir conocimientos especializados. Sus aportes sobre el diseño multirregional, las estrategias de conmutación por error y recuperación tras conmutación por error, y los servicios o herramientas pueden ser invaluables. Si su organización tiene un equipo de Cloud Center of Excellence, asegúrese de incluirlos en el proceso de planeación.

✓ Evaluar el modelo de datos y el segmento si es necesario

Los datos son dinámicos y evolucionan constantemente. A diferencia de otros componentes de la arquitectura, los datos suelen crecer a medida que los usuarios interactúan con el sistema. La supervisión de patrones de datos a lo largo del tiempo y la evaluación de su impacto en otras partes de la arquitectura es esencial. En este nivel, considere las técnicas que simplifican la administración de datos y mejoran el rendimiento para mejorar la confiabilidad general. La creación de particiones es una estrategia clave para lograr estos resultados.

Explore técnicas como la creación de particiones en frío y en caliente, que divide los datos en función de los patrones de acceso y los almacena por separado. Use criterios como la frecuencia de acceso o relevancia para decidir qué particionar.

El particionamiento en frío-calor se puede combinar con el sharding, que es un proceso que divide una base de datos grande en unidades más pequeñas denominadas shards. Cada partición contiene una parte de los datos y juntas forman el conjunto de datos completo. Este enfoque permite la administración de datos independiente.

Contrapartida: el equilibrio de particiones requiere procesos operativos para evaluar y confirmar su distribución. Este enfoque ayuda a evitar particiones calientes en las que se sobreutiliza una partición. Sin embargo, también requiere un esfuerzo continuo y recursos para mantener el equilibrio.

Al elegir una técnica de creación de particiones, tenga en cuenta las siguientes ventajas de confiabilidad:

• Rendimiento mejorado: Al distribuir solicitudes entre varias particiones, puede reducir la carga en almacenes individuales. Cuando se implementa de forma eficaz, el particionamiento permite a un sistema procesar millones de solicitudes de escritura al día. Esta estrategia mejora el rendimiento y minimiza la latencia.

  La creación de particiones puede simplificar el escalado horizontal. Por ejemplo, la fragmentación puede dividir usuarios o clientes en grupos de tamaño aproximadamente igual.

• Administración de datos mejorada: La creación de particiones en frío en caliente permite aplicar distintos niveles de administración de datos a cada nivel de almacenamiento. Por ejemplo, mover datos de archivado a un almacén independiente ayuda a evitar ralentizaciones en las operaciones y las copias de seguridad. Del mismo modo, no todos los datos de registro deben almacenarse en una base de datos relacional. Se puede almacenar en otro almacén de datos mientras que los datos de carga de trabajo activos permanecen relacionales.

• Directivas de confiabilidad adaptadas: Se pueden aplicar diferentes directivas de confiabilidad para ayudar a garantizar que cada partición tiene el nivel correcto de resistencia y evita que cualquier almacén único se convierta en un cuello de botella. Las particiones activas pueden ser totalmente redundantes, incluida la redundancia de zona y la redundancia geográfica, mientras que las particiones inactivas se basan en copias de seguridad. Una ventaja de confiabilidad adicional es que puede reducir el radio de impacto de algunos tipos de errores. Por ejemplo, si un error afecta a una partición, es posible que no afecte a las otras particiones.

Dilema: Puede ser difícil mantener o modificar particiones debido a las interdependencias fuertes entre diferentes particiones de datos. Estos cambios pueden afectar a la capacidad de comprobar la coherencia e integridad de los datos, especialmente cuando se compara con un único almacén de datos. A medida que aumenta el número de particiones, la necesidad de procesos sólidos para mantener la integridad de los datos es más crucial. Sin estas medidas, la confiabilidad podría verse comprometida.