Recomendaciones para definir destinos de confiabilidad
Se aplica a esta recomendación de lista de comprobación de confiabilidad del marco de trabajo bien diseñado de Azure:
| RE:04 | Defina objetivos 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. Debe derivar objetivos de confiabilidad de ejercicios de taller con las partes interesadas de la empresa. Después, afina esos destinos mediante la supervisión y prueba de las 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.
| Término | Definición |
|---|---|
| Objetivo de nivel de servicio (SLO) | Medida del rendimiento y la confiabilidad de una carga de trabajo o aplicación. Un SLO es un destino específico y medible que se ha establecido para interacciones específicas del cliente. Es un destino que establezca para la carga de trabajo o aplicación en función de la calidad de servicio que esperan recibir los clientes. |
| Indicador de nivel de servicio (SLI) | Medición cuantitativa de un aspecto concreto del rendimiento de un servicio. Puede usar una SLI para medir el cumplimiento de la carga de trabajo con un SLO. |
| Acuerdo de Nivel de Servicio (SLA) | Acuerdo contractual entre el proveedor de servicios y el cliente del servicio. Si no se cumple el contrato, 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 que 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. |
Estrategias de diseño principales
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.
Compensación: es posible que tenga una brecha entre los límites técnicos del sistema y su impacto empresarial, como el rendimiento frente a las transacciones por segundo. El puente de esta brecha puede ser difícil. Busca una solución práctica y rentable en lugar de sobreengineering.
Establecimiento de objetivos de disponibilidad
El SLO general de una carga de trabajo refleja la calidad holística, incluidas todas sus dependencias. Una declaración madura del SLO debe indicar el destino empresarial general de esa carga de trabajo, no solo una composició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 cargas de trabajo toman muchas decisiones técnicas basadas en SLO. Los SLO pueden:
Actúe como entrada crítica en las decisiones arquitectónicas cuando considere 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.
Importante
Debe conocer la diferencia entre los SLA y los SLO. Aunque los SLA y los SLO pueden usar o incluso presentar datos similares, su intención es diferente. Un Acuerdo de Nivel de Servicio es un contrato formal entre una organización y sus clientes, y tiene implicaciones financieras y legales directas si la organización no cumple su promesa. Las organizaciones usan SLO para evaluar si el posible tiempo de inactividad está dentro de los límites tolerables.
Los SLO y los SLA comparten una relación empresarial y deben controlarse de forma independiente. Si el Acuerdo de Nivel de Servicio actúa como táctica empresarial, la organización podría establecerla intencionadamente en un valor alto en función de los objetivos del propietario de la empresa. Por el contrario, los SLO pueden ser más altos. Considere las cargas de trabajo críticas como ejemplo. Esta clase de carga de trabajo no puede permitir tiempos de inactividad prolongados porque los efectos, incluidas las pérdidas financieras e incluso las amenazas a la seguridad humana, son importantes. Por lo tanto, los SLO suelen tener como destino un tiempo de actividad del 99,999 %, comúnmente denominados cinco nueves. Si los SLO no cumplen esos objetivos, las organizaciones deben reaccionar rápidamente para mitigar los errores y evitar los resultados de un Acuerdo de Nivel de Servicio con error.
En el ejemplo de este artículo se establece un Acuerdo de Nivel de Servicio elevado para admitir objetivos empresariales.
Los proveedores de plataforma y tecnología en la nube publican acuerdos de nivel de servicio en sus ofertas. Debe considerar los Acuerdos de Nivel de Servicio como parte del cálculo del SLO, pero no debe usarlos tal como está sin comprender el ámbito de cobertura del Acuerdo de Nivel de Servicio. Para obtener más información, consulte Evaluación del impacto de los Acuerdos de Nivel de Servicio de Microsoft.
Considerar los SLO comunes e influir en los factores
Cada SLO tiene como objetivo un criterio de calidad específico. Tenga en cuenta estos SLO comunes para la confiabilidad. 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 limitación.
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 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.
| Características de componentes | Interacción del cliente | Otros factores |
|---|---|---|
| - ¿Expone las API de solicitud o respuesta? - ¿Tiene API de consulta? - ¿Es un componente de proceso ? - ¿Es un componente de procesamiento de trabajos? |
- Acceso al plano de control y al plano de administración para los servicios de Azure orientados al público. - Acceso al plano de datos, por ejemplo, operaciones de creación, lectura, actualización y eliminación (CRUD). |
- ¿El proceso de lanzamiento implica tiempo de inactividad? - ¿Cuál es la probabilidad de introducir errores? Si la carga de trabajo se integra con otros sistemas, es posible que tenga que tener en cuenta los errores de integración. - ¿ Cómo afectan las operaciones rutinarias como la aplicación de revisiones al destino de disponibilidad? ¿Ha factorizado las dependencias de asociados? - ¿El personal es suficiente para apoyar la rotación constante de emergencia y de emergencia? - ¿La aplicación tiene vecinos ruidosos fuera del ámbito de control que puede provocar interrupciones? |
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 de nivel para que pueda personalizar los SLO en función de 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 para todo el sistema que agregue todos los recursos en 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 inquilinos para una solución de multiinquilino.
Definición de destinos de SLO compuestos
Los SLO deben ser medibles y medidos dentro de una ventana de observabilidad.
Los SLO suelen ser porcentajes como 99,90 %, pero también pueden ser instrucciones. Use ambos métodos para obtener un valor numérico que incluya todos los factores.
Un SLO consta de SLO medibles que definen factores aceptables. Los SLA son métricas con un umbral establecido que se puede alertar. Puede recopilarlos desde una plataforma o una aplicación. Los distintos componentes emiten los SLA pertinentes. Al elegir los SLA, 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 usadas, cada una con sus propios destinos de SLO.
Una buena 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.
| Objetivo | Incumplimiento por semana | Incumplimiento por mes | Incumplimiento por año |
|---|---|---|---|
| 99% | 1,68 horas | 7,20 horas | 3,65 días |
| 99,90 % | 10,10 minutos | 43,20 minutos | 8,76 horas |
| 99,95% | 5 minutos | 21,60 minutos | 4,38 horas |
| 99,99% | 1,01 minutos | 4,32 minutos | 52,56 minutos |
| 99,999 % | 6 segundos | 25,90 segundos | 5,26 minutos |
Importante
Un valor de SLO compuesto es una distribución del producto de los factores que contribuyen.
Un SLO compuesto de ejemplo es del 99,95 % × 99,99999 % = ~99,95 %.
Al crear SLO compuestos para distintos flujos, tenga en cuenta su importancia y importancia variables. Es posible que los flujos tengan componentes que considere que no son críticos y se omiten de los cálculos. Puede justificar su omisión en función de si su breve falta de disponibilidad afecta a la experiencia del cliente. En algunos casos, es posible que un componente no sea relevante para el caso de uso que considere para el SLO. También puede omitir estos componentes del cálculo.
El mismo principio se aplica a las operaciones. Algunas operaciones pueden introducir riesgos o afectar al SLO, y otras son insignificantes. La decisión debe ser explícita y basada en el consenso.
Para obtener un ejemplo ilustrativo de cómo definir y medir los SLO y los SLO, consulte la sección Ejemplo .
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 tener en cuenta las áreas que no se mencionan explícitamente en el contrato como disponibles por el mejor esfuerzo de la plataforma.
Por lo tanto, si la carga de trabajo se basa en ranuras de implementación, no puede derivar el SLO únicamente del Acuerdo de Nivel de Servicio de App Service. Como equipo de carga de trabajo, debe cubrir y predecir la disponibilidad del tiempo de actividad. 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.
Implementación de destinos de varias regiones
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 está diseñada correctamente, puede mejorar los SLO porque agrega 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 restringe 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 restringe 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 sello por separado, con los SLA que son adecuados para la carga de trabajo. Considere el SLO de la carga de trabajo general en función del estado de cada sello. Si puede conmutar por error entre stamps, el SLO de carga de trabajo general es mayor porque un error en una marca se puede recuperar a través de una conmutación por error a otra marca.
Preste atención a la cantidad de redundancia que necesita para satisfacer los SLO altos. 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 RTO y RPO garantiza solo 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.
Nota:
MTBF puede ser difícil de definir y garantizar. Los modelos de Plataforma como servicio (PaaS) o 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.
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.
Supervisión y visualización de los destinos
Use los datos que recopila para los objetivos de confiabilidad para crear el modelo de mantenimiento para cada carga de trabajo y los flujos críticos asociados. Un modelo de mantenimiento define estados correctos, degradados y incorrectos para los flujos y 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 de la carga de trabajo, cree una visualización que refleje el estado en tiempo real y las tendencias generales del modelo de mantenimiento 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 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 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.
Explore los paneles de Azure Monitor para el sistema de visualización.
Ejemplo
Contoso, Ltd. está diseñando una nueva experiencia móvil para su sistema de vales de 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.
SQL Instancia administrada es propiedad de 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. SQL Instancia administrada también se expone a la aplicación a través de un punto de conexión privado.
En esta arquitectura, el equipo de API define un destino de SLO inicial para flujos críticos en 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.
Cálculo de un SLO compuesto
SLO de disponibilidad de Azure: el Acuerdo de Nivel de Servicio de compromiso financiero para Azure actúa como proxy para evaluar la confiabilidad 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 GETcorrectasAlmacenamiento en caché, motor de reglas 99.98% Aplicaciones de contenedor 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% Private Link 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 de la promesa del equipo de carga de trabajo a 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 y 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 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 bien diseñado para la excelencia operativa. Implementan recursos en la nube, configuración y código 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 Instancia administrada como la dependencia principal, que ya tiene un 99,80 % de disponibilidad factorizado en la disponibilidad general de la plataforma. No se tienen en cuenta otras dependencias externas.
Un SLO compuesto basado en dependencias externas: no aplicable.
Determinación del resultado del SLO compuesto general
El destino de SLO compuesto general se establece 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 no disponibilidad al mes, el equipo de carga de trabajo establece una rotación de llamadas. Tanto el soporte técnico al cliente como la supervisión sintética de transacciones pueden invocar la compatibilidad con la ingeniería de confiabilidad de sitios de llamada (SRE) para iniciar rápidamente los pasos de recuperación para solucionar problemas de SLO.
Establecimiento del Acuerdo de Nivel de Servicio de carga de trabajo
El Acuerdo de Nivel de Servicio de la carga de trabajo es del 99,90 % 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.
Establecimiento del SLO de corrección
Los flujos de usuario principales de la aplicación deben estar disponibles y disponibles de forma utilizable, o incluso competitiva, con capacidad de respuesta. 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 destino del SLO y la medición de rendimiento, que captura la experiencia típica del cliente y excluye los escenarios de peor caso.
Vínculos relacionados
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.