Recomendaciones para definir destinos de confiabilidad

Se aplica a esta recomendación de lista de comprobación de confiabilidad de Azure Well-Architected Framework:

RE:04

Defina los destinos de confiabilidad y recuperación para los componentes, los flujos y la solución general. Visualice los objetivos para negociar, obtener consenso, establecer expectativas e impulsar acciones para lograr el estado ideal. Use los destinos definidos para compilar el modelo de mantenimiento. El modelo de mantenimiento define el aspecto de los estados correctos, degradados y incorrectos.

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. Los objetivos de confiabilidad se derivan a través de ejercicios de taller con las partes interesadas de la empresa. Los objetivos se refinan mediante la supervisión y las pruebas.

Con las partes interesadas internas, establezca expectativas realistas para la confiabilidad de la carga de trabajo para que las partes interesadas puedan comunicar esas expectativas a los clientes mediante acuerdos contractuales. 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 ha acordado.

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

Término	Definición
Objetivo de nivel de servicio (SLO)	Destino de porcentaje que representa el estado del componente y el nivel de confiabilidad. Cuanto mayor sea el nivel, más confiable será el componente. El SLO compuesto representa el destino agregado de toda la carga de trabajo y las cuentas de los SLO del componente.
Indicador de nivel de servicio (SLI)	Métrica emitida por un servicio. Las métricas de SLI se agregan para cuantificar un valor de SLO.
Acuerdo de Nivel de Servicio (SLA)	Acuerdo contractual entre el proveedor de servicios y el cliente de servicio. El contrato define los SLO. Si no se cumple el acuerdo, es posible que el proveedor de servicios tenga consecuencias financieras.
Promedio de tiempo de recuperación (MTTR)	Tiempo necesario para restaurar un componente después de detectar un error.
Tiempo medio entre el error (MTBF)	Duración durante la cual la carga de trabajo puede realizar la función esperada sin interrupción, hasta que se produzca un error.
Objetivo de tiempo de recuperación (RTO)	El tiempo máximo aceptable que una aplicación puede estar no disponible después de un incidente.
Objetivo de punto de recuperación (RPO)	Duración máxima aceptable de pérdida de datos durante un incidente.

Defina los valores de destino de la carga de trabajo para estas métricas en el contexto de los flujos de usuario y los flujos del sistema. Identifique y puntee esos flujos según lo crítico que son para sus requisitos. Use los valores para impulsar el diseño de la carga de trabajo en términos de arquitectura, revisión, pruebas y operaciones de administración de incidentes. Si no se cumplen los objetivos, afectará al negocio más allá del nivel de tolerancia.

Estrategias de diseño principales

Las discusiones técnicas no deben impulsar la forma en que se definen los objetivos de confiabilidad para los flujos críticos. En su lugar, las partes interesadas de la empresa deben centrarse en los clientes a medida que definen los requisitos de una carga de trabajo. Los expertos técnicos ayudan a las partes interesadas a asignar valores numéricos realistas que se correlacionan con esos requisitos. A medida que comparten conocimientos, los expertos técnicos permiten la negociación y el consenso mutuo sobre acuerdos de nivel de servicio realistas.

Considere un ejemplo de cómo asignar requisitos a valores numéricos medibles. Las partes interesadas estiman que para un flujo de usuario crítico, una hora de tiempo de inactividad durante las horas laborables normales da lugar a una pérdida de X dólares en ingresos mensuales. Esa cantidad en dólares se compara con el costo estimado de diseñar un flujo que tiene un SLO de disponibilidad del 99,95 por ciento en lugar del 99,9 por ciento. Los responsables de la toma de decisiones deben analizar si el riesgo de que la pérdida de ingresos supere los costos añadidos y la carga de administración necesaria para protegerse contra ella. Siga este patrón a medida que examine los flujos y cree una lista completa de destinos.

Recuerde que los objetivos de confiabilidad difieren de los objetivos de rendimiento. Los objetivos de confiabilidad se centran en la disponibilidad y recuperación. Para establecer destinos de confiabilidad, empiece por definir los requisitos más amplios y, a continuación, defina métricas más específicas para cumplir los requisitos de alto nivel.

Los requisitos de confiabilidad y recuperación de nivel más alto y las métricas correlacionadas pueden incluir, por ejemplo, una disponibilidad de la aplicación del 99,9 por ciento para todas las regiones o un RTO objetivo de 5 horas para la región de Las Américas. Definir estos tipos de destinos le ayuda a identificar qué flujos críticos están implicados en esos destinos. A continuación, puede considerar los destinos de nivel de componente.

Equilibrio: una brecha conceptual podría existir entre las limitaciones técnicas de los componentes de la carga de trabajo y lo que significa para la empresa, por ejemplo, el rendimiento en megabits por segundo frente a las transacciones por segundo. La creación de un modelo entre estas dos vistas podría ser difícil. En lugar de sobreengineering la solución, intente abordarla de una manera económica pero significativa.

Métricas de disponibilidad

SLO y SLA

Las métricas de disponibilidad se correlacionan con los SLO, que se usan para definir acuerdos de nivel de servicio. El SLO de carga de trabajo determina cuánto tiempo de inactividad es tolerable en un período determinado, por ejemplo, menos de 1 hora al mes. Para asegurarse de que puede cumplir el destino de SLO, revise los SLA de Microsoft para cada componente. Preste atención a la cantidad de redundancia que necesita para cumplir los acuerdos de nivel de servicio altos. Por ejemplo, Microsoft garantiza acuerdos de nivel de servicio mayores para las implementaciones de varias regiones de Azure Cosmos DB que garantiza para las implementaciones de una sola región.

Nota

Los Acuerdos de Nivel de Servicio de Azure no siempre cubren todos los aspectos de un servicio. Por ejemplo, Azure Application Gateway tiene un Acuerdo de Nivel de Servicio de disponibilidad, pero la funcionalidad de Azure Web Application Firewall no proporciona ninguna garantía de que el tráfico malintencionado deje de pasar el tráfico malintencionado. Tenga en cuenta esta limitación al desarrollar los SLA y los SLO.

Después de recopilar los Acuerdos de Nivel de Servicio para los componentes de carga de trabajo individuales, calcule un Acuerdo de Nivel de Servicio compuesto. El Acuerdo de Nivel de Servicio compuesto debe coincidir con el SLO de destino de la carga de trabajo. El cálculo de un Acuerdo de Nivel de Servicio compuesto implica varios factores, en función del diseño de la arquitectura. Considere los ejemplos siguientes.

Nota

Los valores del Acuerdo de Nivel de Servicio de los ejemplos siguientes son hipotéticos y son solo para fines de demostración.No están diseñados para representar los valores actuales admitidos por Microsoft.

Los Acuerdos de Nivel de Servicio compuestos implican varios servicios que admiten una aplicación, con distintos niveles de disponibilidad. Por ejemplo, considere una aplicación web de Azure App Service que escribe en Azure SQL Database. Hipotéticamente, estos Acuerdos de Nivel de Servicio pueden ser:

• App Service aplicaciones web = 99,95 %
• SQL Database = 99,99 %

¿Cuál es el tiempo de inactividad máximo que puede esperar para esta aplicación? Si se produce un error en cualquiera de los servicios, se produce un error en toda la aplicación. La probabilidad de que cada servicio falle es independiente, por lo que el Acuerdo de Nivel de Servicio compuesto para esta aplicación es del 99,95 por ciento × 99,99 por ciento = 99,94 por ciento. Ese valor es menor que los SLA individuales. Esta conclusión no es sorprendente porque una aplicación que se basa en varios servicios tiene más puntos de error potenciales.

Puede mejorar el Acuerdo de Nivel de Servicio compuesto mediante la creación de rutas de reserva independientes. Por ejemplo, si SQL Database no está disponible, coloque las transacciones en una cola para procesarlas más adelante:

En este diseño, la aplicación sigue estando disponible aunque no pueda conectarse a la base de datos. Sin embargo, se produce un error si se produce un error en la base de datos y la cola al mismo tiempo. El porcentaje de tiempo esperado para un error simultáneo es 0,0001 × 0,001, por lo que este es el Acuerdo de Nivel de Servicio compuesto para esta ruta combinada:

Base de datos o cola = 1,0 − (0,0001 × 0,001) = 99,99999 %

Acuerdo de Nivel de Servicio compuesto total:

Aplicación web y (base de datos o cola) = 99,95 % × 99,99999 % = ~99,95 %

Este enfoque supone inconvenientes:

• La lógica de la aplicación es más compleja.
• Paga por la cola.
• Debe tener en cuenta los problemas de coherencia de los datos.

En el caso de las implementaciones de varias regiones, el Acuerdo de Nivel de Servicio compuesto se calcula de la siguiente manera:

• N es el Acuerdo de Nivel de Servicio compuesto para la aplicación que se implementa en una región.

• Res el número de regiones en las que se implementa la aplicación.

La probabilidad esperada de que se produzca un error de la aplicación en todas las regiones al mismo tiempo es de ((1 − N) ^ R). Por ejemplo, si el Acuerdo de Nivel de Servicio hipotético de una sola región es del 99,95 por ciento:

• Acuerdo de Nivel de Servicio combinado para dos regiones = (1 − (1 − 0,9995) ^ 2) = 99,999975%

• El Acuerdo de Nivel de Servicio combinado para cuatro regiones = (1 − 1 − 0,9995) ^ 4) = 99,999999 %

La definición de SLO adecuada tarda tiempo y tiene cuidado. Las partes interesadas de la empresa deben comprender cómo los clientes clave usan la aplicación. También deben comprender la tolerancia a la confiabilidad. Estos comentarios deben informar a los destinos.

Valores de Acuerdo de Nivel de Servicio

En la tabla siguiente se definen los valores comunes del Acuerdo de Nivel de Servicio.

Contrato de nivel de servicio	Tiempo de inactividad por semana	Tiempo de inactividad por mes	Tiempo de inactividad por año
99%	1,68 horas	7,2 horas	3,65 días
99,9%	10,1 minutos	43,2 minutos	8,76 horas
99,95%	5 minutos	21,6 minutos	4,38 horas
99,99%	1,01 minutos	4,32 minutos	52,56 minutos
99,999 %	6 segundos	25,9 segundos	5,26 minutos

Cuando piense en acuerdos de nivel de servicio compuestos en el contexto de los flujos, recuerde que los distintos flujos tienen definiciones de importancia diferentes. Tenga en cuenta estas diferencias al crear los Acuerdos de Nivel de Servicio compuestos. Los flujos no críticos pueden tener componentes que debe omitir de los cálculos porque no afectan a la experiencia del cliente si no están disponibles brevemente.

Nota

Las cargas de trabajo orientadas al cliente y las cargas de trabajo de uso interno tienen diferentes SLO. Normalmente, las cargas de trabajo de uso interno pueden tener SLO de disponibilidad mucho menos restrictivas que las cargas de trabajo orientadas al cliente.

SLA

Piense en los SLA como métricas de nivel de componente que contribuyen a un SLO. Los SLA más significativos son los que afectan a los flujos críticos desde la perspectiva de los clientes. Para muchos flujos, los SLA incluyen latencia, rendimiento, tasa de errores y disponibilidad. Una buena SLI le ayuda a identificar cuándo un SLO está en riesgo de vulnerarse. Correlacionar el SLI con clientes específicos siempre que sea posible.

Para evitar recopilar métricas inútiles, limite el número de SLA para cada flujo. Apunte a tres SLA por flujo, si es posible.

Métricas de recuperación

Los destinos de recuperación corresponden a las métricas RTO, RPO, MTTR y MTBF. A diferencia de los destinos de disponibilidad, los objetivos de recuperación de estas medidas no dependen en gran medida de los SLA de Microsoft. Microsoft publica RTO y RPO garantiza solo para algunos productos, como SQL Database.

Las definiciones de destinos de recuperación realistas se basan en el análisis del modo de error y los planes y pruebas para la continuidad empresarial y la recuperación ante desastres. 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 con el tiempo a medida que se actualizan las cargas de trabajo. La carga de trabajo puede ser más compleja a medida que se agregan 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.

Nota

MTBF puede ser difícil de definir y garantizar. Las plataformas como servicio (PaaS) o el software como servicio (SaaS) pueden producir errores y recuperarse sin ninguna notificación del proveedor de nube, y el proceso puede ser completamente transparente para usted o sus clientes. Si define destinos para esta métrica, cubra solo los componentes que están bajo su control.

A medida que defina los destinos de recuperación, defina umbrales para iniciar una recuperación. Por ejemplo, si un nodo web no está disponible durante más de 5 minutos, se agrega automáticamente un nuevo nodo al grupo. Defina umbrales para todos los componentes, teniendo en cuenta qué recuperación de un componente específico implica, 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 de las operaciones de recuperación, como la pérdida de datos o las interrupciones de sesión para los clientes.

Creación de un modelo de mantenimiento

Use los datos recopilados para los destinos de confiabilidad para crear el modelo de mantenimiento para cada carga de trabajo y los flujos críticos asociados. Un modelo de mantenimiento define estadoscorrectos, degradados y incorrectos para los flujos y cargas de trabajo. Los estados garantizan la priorización operativa adecuada. Este modelo también se conoce como modelo de semáforo. El modelo asigna verde para un estado correcto, amarillo para degradado y rojo para un estado incorrecto. Un modelo de estado garantiza que sepa cuándo cambia el estado de un flujo de correcto a degradado o incorrecto.

La forma de definir estados correctos, degradados y incorrectos depende de los destinos de confiabilidad. Estos son algunos ejemplos de formas en que puede definir los estados:

• Un estado verde o correcto indica que los requisitos y destinos no funcionales clave están totalmente satisfechos y que los recursos se usan de forma óptima. Por ejemplo, el 95 % de las solicitudes se procesan en <=500 ms con Azure Kubernetes Service nodo (AKS) que se usan en el porcentaje X.

• Un estado amarillo o degradado indica que uno o varios componentes del flujo están alertando contra su umbral definido, pero el flujo está operativo. Por ejemplo, se ha detectado una limitación de almacenamiento.

• Un estado rojo o incorrecto indica que la degradación ha conservado más tiempo que lo permitido por los destinos de confiabilidad o que el flujo no está disponible.

Nota

El modelo de mantenimiento no debe tratar todos los errores iguales. El modelo de mantenimiento debe distinguir entre errores transitorios y no transitorios . Debe distinguir claramente entre los errores transitorios esperados, pero recuperables, y un estado de desastre real.

Este modelo funciona mediante una estrategia de supervisión y alertas desarrollada y operada en los principios de mejora continua. A medida que las cargas de trabajo evolucionan, los modelos de mantenimiento deben evolucionar con ellas.

Para obtener información detallada sobre las consideraciones de diseño y las recomendaciones para un modelo de mantenimiento de aplicaciones en capas, consulte la guía de modelado de estado que se encuentra en las áreas de diseño de cargas de trabajo críticas. Para obtener instrucciones detalladas sobre la supervisión y las configuraciones de alertas, consulte la guía de supervisión de estado.

Visualización

Para mantener informados a los equipos de operaciones y a las partes interesadas de la carga de trabajo sobre el estado en tiempo real y las tendencias generales del modelo de mantenimiento de la carga de trabajo, considere la posibilidad de crear paneles en la solución de supervisión. Analice las soluciones de visualización con las partes interesadas para asegurarse de que entrega la información que valoran y que es fácil de consumir. Es posible que también quieran ver los informes generados semanalmente, mensualmente o trimestralmente.

Facilitación de 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 diferentes SLA y, a veces, las SKU 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 no se cumple el Acuerdo de Nivel de Servicio, junto con definiciones de disponibilidad para cada servicio. Ese aspecto del Acuerdo de Nivel de Servicio actúa como una directiva de cumplimiento.

Vínculos relacionados

• Well-Architected Guía crítica para el modelado de estado: Modelado de estado y observabilidad de cargas de trabajo críticas en Azure

Lista de comprobación de confiabilidad

Consulte el conjunto completo de recomendaciones.

Lista de comprobación de confiabilidad