Estrategias de arquitectura para definir objetivos de fiabilidad

Se aplica a la siguiente recomendación de la lista de comprobación de fiabilidad del marco de trabajo Azure Well-Architected:

En esta guía se describen las recomendaciones para definir las métricas de destino de disponibilidad y recuperación para cargas de trabajo y flujos críticos. Debe derivar objetivos de confiabilidad de ejercicios de taller con las partes interesadas de la empresa. Después, afina esos objetivos supervisando y probando tus cargas de trabajo.

Establezca expectativas realistas con las partes interesadas internas sobre la confiabilidad de la carga de trabajo. Después, pueden usar acuerdos contractuales para comunicar esas expectativas a los clientes. Las expectativas realistas también ayudan a las partes interesadas a comprender y apoyar sus decisiones de diseño arquitectónico y saber que está diseñando para cumplir de forma óptima los objetivos que acepta.

Considere la posibilidad de usar las siguientes métricas para cuantificar los requisitos empresariales.

Los objetivos de confiabilidad representan el objetivo de calidad deseado de una carga de trabajo, como se prometió a sus usuarios y a las partes interesadas de la empresa. Este objetivo incluye la disponibilidad y la capacidad de recuperación de la carga de trabajo. Tenga en cuenta que los objetivos de confiabilidad difieren de los objetivos de rendimiento, pero debe incluir los objetivos de rendimiento en los objetivos de confiabilidad. Tenga en cuenta los siguientes objetivos de confiabilidad:

• Los objetivos de disponibilidad definen los estándares de calidad para que un sistema permanezca accesible y funcional. Si no cumple estos estándares, el sistema se considera no confiable. Use SLO para ayudar a comprobar si el sistema cumple estos estándares. Las partes interesadas empresariales y técnicas colaboran para establecer acuerdos de nivel de servicio realistas y tener en cuenta factores como el análisis comparativo, la experiencia del usuario y el perfil de carga de trabajo.

• Los objetivos de corrección garantizan que la carga de trabajo realice correctamente sus funciones con una calidad coherente. Para medir la corrección, cuantifique los indicadores de la carga de trabajo para poder combinarlos en una puntuación unificada y objetiva.

• Los objetivos de recuperación corresponden a las métricas RTO, RPO, MTTR y MTBF, que cuantifican la eficacia de los planes y pruebas para la continuidad empresarial y la recuperación ante desastres.

Para establecer objetivos de confiabilidad, las partes interesadas de la empresa definen amplios requisitos. Después, los expertos técnicos evalúan el estado actual de la carga de trabajo y trabajan para lograr y mantener objetivos mediante la supervisión y las alertas. Ambas partes deben acordar objetivos realistas.

Identifique y puntee los flujos de usuario y sistema en función de su importancia para sus requisitos empresariales. Use estas puntuaciones para guiar el diseño, la revisión, las pruebas y la administración de incidentes de la carga de trabajo. Establezca objetivos de confiabilidad para estos flujos y comprenda que no cumplir esos objetivos puede afectar significativamente a su negocio.

Disyuntiva: Puede haber un desfase entre los límites técnicos de su sistema y su impacto en el negocio, por ejemplo, entre el rendimiento y las transacciones por segundo. Cerrar esta brecha puede ser difícil. Busca una solución práctica y rentable en lugar de complicarla en exceso.

Establecimiento de objetivos de disponibilidad

El SLO general de una carga de trabajo refleja la calidad global, incluidas todas sus dependencias. Una definición bien desarrollada del SLO debe indicar el objetivo de negocio global de esa carga de trabajo, no solo una agregación de esas dependencias. Por ejemplo, si los clientes esperan una disponibilidad del 99,99 %, el SLO general debe tener como objetivo ese objetivo, incluso si una parte solo alcanza el 99,80 %.

Las partes interesadas evalúan la experiencia del cliente y tienen en cuenta cómo afecta el tiempo de inactividad a los ingresos. Comparan esta pérdida con el costo de diseñar y operar el flujo de negocio. A continuación, los responsables de la toma de decisiones deciden si deben gastar más dinero en confiabilidad para evitar la pérdida de ingresos y mantener su reputación.

Los propietarios de cargas de trabajo usan objetivos financieros para determinar los objetivos. Los requisitos empresariales se asignan a métricas medibles. El objetivo es identificar un conjunto de factores que influyen en la calidad de la experiencia del cliente.

Los arquitectos de la carga de trabajo toman muchas decisiones técnicas basadas en los SLO. Los SLO pueden:

• Sirva como aporte clave en las decisiones de arquitectura al tener en cuenta otras dependencias.

• Proporcione una vista casi en tiempo real y una comprensión compartida del estado de una carga de trabajo para permitir discusiones objetivas. También ayudan al equipo de cargas de trabajo a priorizar los esfuerzos para mejorar la confiabilidad y desarrollar nuevas características.

• Actúe como señal principal para las operaciones de implementación, que impulsa la reversión automatizada si se producen problemas y proporciona validación de que los cambios logran las mejoras esperadas en la experiencia del cliente.

• Acelere la corrección y la recuperación centrándose en objetivos, impulse la notificación automatizada de problemas a los clientes y cree confianza entre los equipos de su organización.

Tenga en cuenta los SLO más comunes y los factores que influyen

Cada SLO tiene como objetivo un criterio de calidad específico. Tenga en cuenta estos SLO comunes para la fiabilidad. Esta lista no es exhaustiva. Agregue SLO en función de sus requisitos empresariales.

• La tasa de éxito mide el éxito de las solicitudes y los procesos en relación con los que devuelven un error o producen un error en su tarea.

• La latencia mide el tiempo entre cuando se inicia una solicitud de una operación y cuando el resultado está disponible o el proceso está completo.

• La capacidad mide el uso simultáneo, como el número de respuestas basadas en la limitación del ancho de banda.

• La disponibilidad mide el tiempo de actividad desde la perspectiva de los clientes.

• El rendimiento mide la velocidad mínima de transferencia de datos durante una determinada cantidad de tiempo. El rendimiento se mide como una unidad de velocidad de datos, como transacciones por segundo (TPS) o solicitudes por segundo (RPS).

Conozca los escenarios y tolerancias de la carga de trabajo en Azure. Tanto los servicios de Azure como los componentes de la aplicación afectan al SLO de la carga de trabajo. Combine las respuestas de la tabla siguiente para derivar el SLO general. Use estas preguntas como ejemplos para evaluar la utilidad del componente de carga de trabajo.

Determinación del ámbito de SLO

Puede establecer SLO en varios niveles, como para cada aplicación, carga de trabajo o un flujo específico, en el sistema. Establezca SLO específicos para cada nivel para que pueda personalizar los SLO según la importancia de cada componente.

En soluciones de software como servicio (SaaS), mida los SLO por cliente para optimizar la experiencia de cada cliente. Los clientes pueden tener diferentes recursos de infraestructura en sus segmentos. En tales casos, es posible que un SLO de todo el sistema que agregue todos los recursos de todos los segmentos de clientes no tenga sentido. En su lugar, mida los SLO que se alinean con el contexto específico de cada cliente. Para más información, consulte Modelos de arrendamiento para una solución multiinquilino.

Definir objetivos compuestos de SLO

Los SLO deben ser medibles y medidos dentro de una ventana de observabilidad.

Los SLO suelen ser porcentajes como el 99,90 %, pero también pueden ser declaraciones. Use ambos métodos para obtener un valor numérico que incluya todos los factores.

Un SLO se compone de SLI medibles que definen factores aceptables. Los SLI son métricas con un umbral definido que puede generar alertas. Puede recopilarlos desde una plataforma o una aplicación. Los distintos componentes emiten SLI relevantes. Al elegir los SLI, tenga en cuenta los factores que influyen en el SLO.

Por ejemplo, para calcular el SLO de un flujo que usa una API de respuesta y solicitud, mida la latencia del servidor y el tiempo de procesamiento de solicitudes. Las tasas de rendimiento y errores no se aplican a entornos de proceso continuos, como máquinas virtuales, conjuntos de escalado o Azure Batch.

Para el acceso al plano de control, considere las tasas de error y la latencia para las respuestas de API y las operaciones de ejecución prolongada, como la creación de recursos. El acceso al plano de datos depende de las API utilizadas, cada una con sus propios objetivos de SLO.

Un buen SLI muestra cuándo podría infringir un SLO. Normalmente se mide en percentiles. Estos son algunos percentiles usados habitualmente y el tiempo estimado de incumplimiento de la disponibilidad esperada.

Evaluación del impacto de los Acuerdos de Nivel de Servicio de Microsoft

Un Acuerdo de Nivel de Servicio de Microsoft proporciona información sobre la disponibilidad de las áreas a las que Microsoft se compromete. Los Acuerdos de Nivel de Servicio no garantizan una oferta en su conjunto. Al evaluar acuerdos de nivel de servicio, tenga una buena comprensión de la cobertura proporcionada alrededor del percentil publicado.

Considere Web Apps, una característica de App de Azure Service. La característica se considera disponible cuando devuelve un estado 200 OK en un caso de uso determinado. Dentro de ese contexto y período de tiempo específicos, no cubre una garantía respaldada financieramente sobre la disponibilidad de características como Easy Auth o el cambio de ranura. Debe considerar que las áreas que no se mencionan explícitamente en el contrato están disponibles por el mejor esfuerzo de la plataforma.

Por lo tanto, si la carga de trabajo depende de las ranuras de implementación, no puede obtener su SLO únicamente del SLA específico para App Service. Como equipo de gestión de cargas de trabajo, debe anticipar y predecir la disponibilidad. Sin embargo, esta predicción puede ser incierta, por lo que asociar estrechamente el SLO a los SLA de la plataforma puede ser problemático.

Considere otro ejemplo. Si Azure Front Door tiene disponibilidad del 99,99 %, el diseño debe cumplir los criterios específicos publicados en el contrato. Por ejemplo, el back-end debe incluir almacenamiento, necesita una GET operación que pueda recuperar un archivo de al menos 50 KB de tamaño y debe implementar agentes en varios lugares en al menos cinco ubicaciones geográficamente diversas. Este caso de uso estrecho de Azure Front Door no garantiza características como el almacenamiento en caché, las reglas de enrutamiento o un firewall de aplicaciones web. Estos aspectos están fuera del ámbito del Acuerdo de Nivel de Servicio.

Implementar objetivos multirregión

Desde una perspectiva de confiabilidad, la implementación de varias regiones es una implementación del principio de redundancia. El objetivo es mitigar el riesgo de una interrupción regional o un rendimiento degradado. Esta estrategia, cuando se diseña correctamente, puede mejorar los SLO, ya que añade una región secundaria con fines de conmutación por error.

Hay dos casos de uso principales:

• Patrón de alta disponibilidad, en el que se distribuye una carga entre regiones para obtener más capacidad. La alta disponibilidad no limita a los usuarios de la carga de trabajo a una región, y el rendimiento de todo el sistema contribuye al SLO.

• Patrón Bulkhead, en el que se limita a los clientes a regiones específicas para segmentarlos. En tales casos, trate las implementaciones de varias regiones como implementaciones independientes o stamps, en cada región. Mida el estado de cada stamp por separado, con los SLI que sean adecuados para la carga de trabajo. Considere el SLO de la carga de trabajo general en función del estado de cada stamp. Si puede realizar una conmutación por error entre stamps, el SLO de la carga de trabajo general es mayor porque un fallo en un stamp se puede recuperar mediante una conmutación por error a otro stamp.

Contrapartida: Determine si la reducción del riesgo compensa la complejidad adicional. Los destinos de varias regiones también presentan complejidades operativas, como coordinar implementaciones, garantizar la coherencia de los datos y controlar la latencia. Esas operaciones son significativas durante la recuperación. El equipo debe pesar estas complejidades frente al aumento de la resistencia.

Preste atención al nivel de redundancia que necesita para cumplir con SLO elevados. Por ejemplo, Microsoft garantiza acuerdos de nivel de servicio más altos para implementaciones de varias regiones de Azure Cosmos DB que garantiza las implementaciones de una sola región.

Definición de métricas de recuperación

Las definiciones de destinos de recuperación realistas, como las métricas RTO, RPO, MTTR y MTBF, dependen del análisis del modo de error y de sus planes y pruebas para la continuidad empresarial y la recuperación ante desastres. Al definir estos destinos, tenga en cuenta las garantías de recuperación proporcionadas por la plataforma. Microsoft publica las garantías de RTO y RPO solo para algunos productos, como Azure SQL Database.

Antes de finalizar este trabajo, analice los objetivos aspiracionales con las partes interesadas y asegúrese de que el diseño de la arquitectura admite los objetivos de recuperación a la mejor de su comprensión. Comunique claramente a las partes interesadas que los flujos o cargas de trabajo completas que no se hayan probado exhaustivamente para las métricas de recuperación no deben tener acuerdos de nivel de servicio garantizados. Asegúrese de que las partes interesadas entiendan que los destinos de recuperación pueden cambiar a lo largo del tiempo a medida que se actualizan las cargas de trabajo. La carga de trabajo puede ser más compleja a medida que agrega clientes o a medida que adopta nuevas tecnologías para mejorar la experiencia del cliente. Estos cambios pueden aumentar o disminuir las métricas de recuperación.

Al definir destinos de recuperación, defina umbrales para iniciar una recuperación. Por ejemplo, si un nodo web no está disponible durante más de cinco minutos, agregue automáticamente un nuevo nodo al grupo. Defina umbrales para todos los componentes y tenga en cuenta lo que implica la recuperación de un componente específico, incluido el efecto en otros componentes y dependencias. Los umbrales también deben tener en cuenta los errores transitorios para asegurarse de que no inicie acciones de recuperación demasiado rápidamente. Documente y comparta con las partes interesadas los posibles riesgos, como la pérdida de datos o las interrupciones de sesión para los clientes, de las operaciones de recuperación.

Supervisar y visualizar los objetivos

Utilice los datos que recopile para sus objetivos de fiabilidad para crear su modelo de estado para cada carga de trabajo y los flujos críticos asociados. Un modelo de estado define los estados saludable, degradado y no saludable de los flujos y las cargas de trabajo. Cuando cambia el estado, el modelo debe alertar a las partes responsables. Para obtener recomendaciones y consideraciones de diseño detalladas, consulte Guía de modelado de estado.

Para mantener informados a los equipos de operaciones y a las partes interesadas en la carga de trabajo, cree una visualización que refleje el estado en tiempo real y las tendencias generales del modelo de estado de la carga de trabajo. Analice las soluciones de visualización con las partes interesadas para asegurarse de que proporciona información que valoran y que es fácil de consumir. Es posible que también quieran ver informes generados semanalmente, mensuales o trimestrales.

Facilitación en Azure

Los Acuerdos de Nivel de Servicio de Azure proporcionan los compromisos de Microsoft para el tiempo de actividad y la conectividad. Los distintos servicios tienen acuerdos de nivel de servicio diferentes y, a veces, los productos dentro de un servicio tienen acuerdos de nivel de servicio diferentes. Para obtener más información, consulte Acuerdos de Nivel de Servicio para servicios en línea.

El Acuerdo de Nivel de Servicio de Azure incluye procedimientos para obtener un crédito de servicio si la carga de trabajo no cumple el Acuerdo de Nivel de Servicio, junto con las definiciones de disponibilidad de cada servicio. Ese aspecto del Acuerdo de Nivel de Servicio actúa como una directiva de cumplimiento.

Consulte los paneles de Azure Monitor para su sistema de visualización.

Ejemplo

Contoso, Ltd. está diseñando una nueva experiencia para dispositivos móviles para su sistema de venta de entradas para eventos. Esta es la arquitectura de alto nivel.

El logotipo de Grafana es una marca comercial de su empresa correspondiente. El uso de esta marca no implica ninguna aprobación.

Componentes

Estos son algunos componentes que ilustran el concepto de definición de SLO. Hay componentes en esta arquitectura que no se incluyen en la lista siguiente. Por ejemplo, aunque Key Vault forma parte del flujo de solicitud crítico, no forma parte del caso de uso de la respuesta. Si Key Vault no está disponible, la aplicación continúa funcionando mediante secretos que se cargan durante el inicio. Sin embargo, si la aplicación necesita escalarse, la disponibilidad de Key Vault se vuelve crítica porque los nuevos nodos deben cargarse con secretos. En este ejemplo, no se tienen en cuenta las operaciones de escalado. Otros componentes se omiten por motivos de brevedad.

• Azure Front Door es el único punto de entrada que expone una API que los clientes usan para enviar solicitudes.

• Azure Container Apps es el entorno que posee el equipo de cargas de trabajo y usa para ejecutar lógica de negocios para la aplicación.

• Instancia administrada de SQL pertenece a otro equipo y es una dependencia crítica de la carga de trabajo.

• Azure Private Link proporciona conectividad privada entre las implementaciones de Azure Front Door y Container Apps. La Instancia administrada de SQL también está expuesta a la aplicación a través de un punto de conexión privado.

En esta arquitectura, el equipo de la API define un objetivo inicial de SLO para los flujos críticos de la aplicación. Adoptan la estrategia que se describe en Factores que influyen en los SLO. Tienen como objetivo definir objetivos que cubran la funcionalidad básica sin resaltar excesivamente las características complementarias. Miden el estado de tres flujos de usuario críticos, que implican todas las funcionalidades principales de la nube y ejecutan código entre implementaciones. Sin embargo, estos flujos no cubren todo el código ni el acceso a los datos. Estos son los factores que influyen.

Calcular un SLO compuesto

• SLO de disponibilidad de Azure: El compromiso financiero del SLA de Azure sirve como indicador indirecto para evaluar la fiabilidad de la plataforma.

  Componente de Azure	Cobertura del Acuerdo de Nivel de Servicio aplicable	No cubierto por el Acuerdo de Nivel de Servicio	SLO ajustado
  Azure Front Door	99,99 % para las operaciones HTTP GET correctas	Almacenamiento en caché, motor de reglas	99.98%
  Aplicaciones en contenedores	99,95 % en función de las aplicaciones implementadas a las que se pueda acceder mediante la entrada integrada	Escalado automático, funcionalidades del almacén de tokens	99,95%
  Instancia administrada de SQL	99,99 % en función de la conexión a la instancia de SQL Server	Rendimiento, retención de datos	99.80%
  Enlace privado	99,99 % en función de minutos completos cuando la red del punto de conexión privado no aceptó tráfico o cuando el tráfico no fluyó entre el punto de conexión y el servicio Private Link	Errores individuales que duran menos de un minuto	99,99%

  El ajuste se basa en varios factores que dependen del compromiso del equipo de trabajo con sus objetivos. Un factor podría ser la confianza en la funcionalidad de la plataforma en función de la experiencia anterior. Por ejemplo, para Container Apps y Private Link, el equipo se siente cómodo tomando el valor del Acuerdo de Nivel de Servicio tal como está.

  También hay factores matizados. Por ejemplo, el equipo reduce el valor de SLO de SQL Instancia administrada al 99,80 % para tener en cuenta posibles errores en sus operaciones de datos, como los cambios de esquema y la realización de copias de seguridad.

  El equipo establece el SLO compuesto calculando el impacto de los valores de SLO individuales, una vez ajustados. Este valor es del 99,72 %.

  Hay otros factores que contribuyen. La arquitectura se basa en componentes de red de Azure, como redes virtuales y grupos de seguridad de red (NSG) que no tienen un Acuerdo de Nivel de Servicio publicado. El equipo de carga de trabajo decide considerar esos factores con una disponibilidad del 99,99 % para cada componente.

  Un SLO compuesto basado en la disponibilidad prevista de la plataforma: 99,68 % al mes.

• SLO de código de aplicación: el equipo reconoce que los errores en su código de aplicación o en los procedimientos almacenados pueden afectar a la disponibilidad del sistema, y asignan una hora de tiempo de inactividad mensual para tener en cuenta los errores relacionados con el código.

  Usan percentiles de tiempo de inactividad comunes para calcular el SLO para factores individuales, como defectos de código, problemas de escalado y otras consideraciones relacionadas con el código.

  Un SLO compuesto basado en la disponibilidad de código y datos: 99,86 % al mes.

• SLO de configuración de recursos y aplicaciones: el equipo reconoce que los recursos en la nube y el código de aplicación deben estar configurados correctamente. Este destino incluye la configuración de reglas de escalado automático, la implementación de reglas de NSG y la selección del tamaño correcto de las SKU. Para tener en cuenta los errores de configuración, presupuestan 10 minutos de tiempo de inactividad mensual, que es aproximadamente un 99,98 % de disponibilidad.

  Un SLO compuesto basado en la disponibilidad de configuración: 99,95 % al mes.

• SLO de operaciones: el equipo de cargas de trabajo desarrolla una buena cultura de DevOps siguiendo los principios del marco de buena arquitectura para la excelencia operativa. Despliegan recursos en la nube, configuración y código en cada sprint.

  El equipo considera que las implementaciones son un riesgo porque pueden desestabilizar un sistema en ejecución. Puede haber errores como resultado de las actualizaciones de certificados TLS, los cambios de DNS o los errores de herramientas. El equipo también considera posibles tiempos de inactividad causados por correcciones de emergencia. Presupuestan un total de 20 minutos de tiempo de inactividad mensual, que es aproximadamente un 99,95 % de disponibilidad.

  Las ventanas de mantenimiento se designan períodos de tiempo durante los que se producen actualizaciones o mantenimiento del sistema. La API no se usa principalmente durante aproximadamente cuatro horas al día. Para reducir el riesgo de no disponibilidad, el equipo puede programar tareas de mantenimiento durante esas horas menos activas. Este enfoque conduce a un SLO superior, pero el equipo decide no incluir la ventana de mantenimiento como parte de su SLO.

  Un SLO compuesto basado en la disponibilidad de operaciones: 99,95 % al mes.

• SLO de dependencias externas: El equipo considera SQL Managed Instance como la dependencia principal, cuya disponibilidad del 99,80 % ya está incluida en la disponibilidad global de la plataforma. No se tienen en cuenta otras dependencias externas.

  Un SLO compuesto basado en dependencias externas: no aplicable.

Determinar el resultado compuesto general del SLO

El objetivo compuesto general de SLO se fija en el 99,45 %, lo que equivale a aproximadamente cuatro horas de tiempo de inactividad al mes.

Para cumplir el objetivo de SLO de solo cuatro horas de indisponibilidad al mes, el equipo responsable de la carga de trabajo establece una rotación de guardias. Tanto el servicio de soporte al cliente como la supervisión de transacciones sintéticas pueden invocar el servicio de ingeniería de fiabilidad del sitio (SRE) de guardia para iniciar rápidamente los pasos de recuperación para solucionar los problemas de SLO.

Establezca el SLA de la carga de trabajo

El SLA para la carga de trabajo es del 99,90 % de disponibilidad al mes.

Los departamentos legales y financieros del equipo de cargas de trabajo establecen el Acuerdo de Nivel de Servicio para la carga de trabajo en una disponibilidad del 99,90 % al mes, lo que supera el objetivo de SLO del 99,45 %. Toman esta decisión después de analizar pagos financieros frente al crecimiento proyectado de los clientes en función de un acuerdo de nivel de servicio atractivo. El Acuerdo de Nivel de Servicio cubre dos flujos de usuario principales e incluye consideraciones de rendimiento, no solo disponibilidad. Es un riesgo calculado asumido por el equipo empresarial para beneficiar al negocio y el equipo de ingeniería es consciente del compromiso.

Configuración del SLO de corrección

Los flujos de usuario principales de la aplicación deben estar disponibles y tener una capacidad de respuesta adecuada para su uso, o incluso competitiva. El equipo establece un SLO de tiempo de respuesta específico para la API, excepto el tiempo de procesamiento del cliente y el recorrido de red de Internet. Evalúan este SLO solo durante períodos de disponibilidad. Eligen el percentil 75 como objetivo del SLO y como métrica de rendimiento, ya que ambos reflejan la experiencia típica del cliente y excluyen los peores casos.

Vínculos relacionados

Modelado de salud para cargas de trabajo

Lista de comprobación de confiabilidad

Consulte el conjunto completo de recomendaciones.