Recomendaciones para definir objetivos de fiabilidad
Se aplica a esta recomendación de la lista de verificación de confiabilidad bien diseñada: Power Platform
| RE:04 | Defina objetivos de fiabilidad y recuperación para los componentes, los flujos y la solución global. Visualice los objetivos para negociar, obtener consenso, establecer expectativas e impulsar acciones para alcanzar el estado ideal. Usar los objetivos definidos para crear el modelo de estado. El modelo de estado define cómo son los estados correcto, degradado e incorrecto. |
|---|
Esta guía describe las recomendaciones para definir métricas de objetivos de disponibilidad y recuperación para cargas de trabajo críticas. Los objetivos de fiabilidad se obtienen a través de talleres con partes interesadas del negocio.
Los objetivos se mejoran mediante el seguimiento y las pruebas. Trabaje con sus partes interesadas internas para establecer expectativas realistas de fiabilidad. Este ejercicio también ayudará a las partes interesadas a respaldar sus elecciones de diseño arquitectónico y a comprender que está diseñando para cumplir mejor con los objetivos acordados.
Microsoft Power Platform maneja la mayoría de las inquietudes sobre disponibilidad y fiabilidad de nivel de infraestructura por usted. Sin embargo, la disponibilidad de las cargas de trabajo que usted crea es una responsabilidad compartida. Es importante entender que incluso con el compromiso de Microsoftcon la alta disponibilidad , el riesgo de que el sistema esté inactivo nunca es cero.
Considere utilizar las siguientes métricas para cuantificar los requisitos empresariales.
| Término | Definición |
|---|---|
| Objetivo de nivel de servicio (SLO) | Un objetivo porcentual que representa el estado del componente y el nivel de fiabilidad. Cuanto más alto es el nivel, más fiable es el componente. El SLO compuesto representa el objetivo agregado de toda la carga de trabajo y tiene en cuenta los SLO de los componentes. |
| Indicador de nivel de servicio (SLI) | Una métrica emitida por un servicio. Las métricas de SLI se agregan para cuantificar un valor de SLO. |
| Contrato de nivel de servicio (SLA) | Un acuerdo contractual entre el proveedor de servicios y el cliente del servicio. El acuerdo define los SLO. El incumplimiento del acuerdo podría tener consecuencias financieras para el proveedor del servicio. |
| Tiempo medio de recuperación (MTTR) | El tiempo necesario para restaurar un componente después de que se detecta un error. |
| Tiempo medio entre fallos (MTBF) | La duración durante la cual la carga de trabajo puede realizar la función esperada sin interrupción, hasta que falla. |
| Objetivo de tiempo de recuperación (RTO) | El tiempo máximo aceptable que una aplicación puede no estar disponible después de un incidente. |
| Objetivo de punto de recuperación (RPO) | La duración máxima aceptable de la pérdida de datos durante un incidente. |
Defina los valores objetivo de la carga de trabajo para estas métricas en el contexto de los flujos de usuarios y sistemas. Identifique y califique esos flujos según su grado de importancia para sus requisitos. Utilice los valores para impulsar el diseño de su carga de trabajo en términos de arquitectura, revisión, pruebas y operaciones de administración de incidentes. El incumplimiento de los objetivos afectará al negocio más allá del nivel de tolerancia.
Estrategias clave de diseño
Las discusiones técnicas no deberían determinar la forma de definir los objetivos de confiabilidad para sus flujos críticos. En cambio, las partes interesadas del negocio deberían centrarse en sus requisitos y las expectativas de los usuarios finales de la carga de trabajo. Los expertos técnicos ayudan a las partes interesadas a asignar valores numéricos realistas que cumplan con esos requisitos. Al intercambiar información, los expertos técnicos permiten la discusión y el acuerdo sobre SLO viables.
Considere un ejemplo de cómo asignar requisitos a valores numéricos mensurables. Las partes interesadas estiman que para un flujo de usuarios crítico, una hora de inactividad durante el horario comercial habitual resulta en una pérdida de X dólares en ingresos mensuales. Ese importe en dólares se compara con el importe estimado de diseñar un flujo que tenga un SLO de disponibilidad del 99,95 por ciento en lugar del 99,9 por ciento. Los responsables de toma de decisiones deben discutir si el riesgo de esa pérdida de ingresos supera los costes adicionales y la carga de administración que se necesitan para protegerse contra ella.
Siga este patrón mientras examina los flujos y crea una lista completa de objetivos.
Recuerde que los objetivos de fiabilidad difieren de los objetivos de rendimiento. Los objetivos de fiabilidad se centran en la disponibilidad y la recuperación. Para establecer objetivos de fiabilidad, comience por definir los requisitos más amplios y luego defina métricas más específicas para cumplir con los requisitos de alto nivel.
Los requisitos de fiabilidad y recuperación de más alto nivel y las métricas correlacionadas podrían 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 objetivos le ayuda a identificar qué flujos críticos están involucrados en esos objetivos. Entonces puede considerar objetivos en el nivel de componente.
Métricas de disponibilidad
Los objetivos de disponibilidad corresponden a métricas SLO, SLA y SLI.
SLO y SLA
Las métricas de disponibilidad se correlacionan con los SLO, que se utilizan para definir los SLA. 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 con el objetivo de SLO, revise los SLA de cada componente. Microsoft
Para establecer sus SLO, piense en:
Requisitos no funcionales de su carga de trabajo (por ejemplo, tasas máximas de solicitudes, usuarios simultáneos) durante los próximos 1 o 2 años.
Métricas disponibles sobre lo que puede medir, durante un período de tiempo específico. Estos datos informarán sobre qué SLI especificar.
Después de reunir los SLA para los componentes individuales de la carga de trabajo, calcule un SLA compuesto. El SLA compuesto debe coincidir con el SLO objetivo de la carga de trabajo. El cálculo de un SLA compuesto implica varios factores, según el diseño de su arquitectura.
Definir SLO adecuados requiere tiempo y una cuidadosa consideración. Las partes interesadas del negocio deben comprender la tolerancia a la fiabilidad. Estos comentarios deberían informar a los objetivos.
Valores de SLA
La siguiente tabla define los valores de SLA comunes.
| Acuerdo 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 SLA compuestos en el contexto de flujos de usuarios y sistemas, recuerde que diferentes flujos de usuarios y sistemas tienen diferentes definiciones de criticidad. Considere estas diferencias cuando cree sus SLA compuestos. Los flujos no críticos pueden tener componentes que debería omitir de sus cálculos porque no afectan a la experiencia del cliente si no están disponibles brevemente.
SLI
Piense en los SLI como métricas en el nivel de componentes que contribuyen a un SLO. Los SLI más importantes son los que afectan a sus flujos críticos desde la perspectiva de sus clientes. Para muchos flujos, los SLI incluyen latencia, rendimiento, tasa de error y disponibilidad. Un buen SLI le ayuda a identificar cuándo un SLO corre el riesgo de ser infringido. Correlacione el SLI con clientes específicos cuando sea posible.
Para evitar recopilar métricas inútiles, limite la cantidad de SLI para cada flujo. Si es posible, trate de lograr tres SLI por flujo.
Métricas de recuperación
Los objetivos de recuperación corresponden a métricas RTO, RPO, MTTR y MTBF. A diferencia de los objetivos de disponibilidad, los objetivos de recuperación para estas mediciones no dependen en gran medida de los SLA. Microsoft Microsoft publica garantías de RTO y RPO solo para algunos productos, como SQL Database.
Las definiciones de objetivos de recuperación realistas dependen de su análisis del modo de fallo y sus planes y pruebas para la continuidad del negocio y recuperación ante desastres. Antes de terminar este trabajo, analice los objetivos a los que aspira con las partes interesadas y asegúrese de que el diseño de su arquitectura respalde los objetivos de recuperación según su leal saber y entender. Comunique claramente a las partes interesadas que cualquier parte de la carga de trabajo que no se haya probado exhaustivamente en cuanto a métricas de recuperación no debería tener acuerdos de nivel de servicio garantizados. Asegúrese de que las partes interesadas comprendan que los objetivos de recuperación pueden cambiar con el tiempo a medida que se actualizan las cargas de trabajo. La carga de trabajo puede volverse más compleja a medida que se adoptan nuevas tecnologías para mejorar la experiencia del usuario. Estos cambios pueden aumentar o disminuir sus métricas de recuperación.
Nota
El MTBF puede ser difícil de definir y garantizar. Las plataformas como servicio (PaaS) o el software como servicio (SaaS) pueden fallar y recuperarse sin ninguna notificación por parte del proveedor de la nube, y el proceso puede ser completamente transparente para usted. Si define objetivos para esta métrica, cubra solo los componentes que estén bajo su control.
Creación de un modelo de estado
Utilice los datos que recopiló para sus objetivos de fiabilidad para crear su modelo de salud para cada carga de trabajo y los flujos críticos asociados. Un modelo de estado define estados correctos, degradados y no saludables* para los flujos y cargas de trabajo. Los estados garantizan una priorización operativa adecuada. Este modelo también se conoce como modelo de semáforo. El modelo asigna verde a los sanos, amarillo a los degradados y rojo a los no saludables. Un modelo de salud garantiza que usted sepa cuándo el estado de un flujo cambia de saludable a degradado o no saludable.
La forma de definir los estados saludables, degradados y no saludables depende de sus objetivos de fiabilidad. A continuación se muestran algunos ejemplos de formas en las que podría definir los estados:
Un estado verde o saludable indica que los requisitos y objetivos clave no funcionales están completamente satisfechos y que los recursos se utilizan de manera óptima.
Un estado amarillo o degradado indica que uno o más componentes del flujo están alertando contra su umbral definido, pero el flujo está operativo. Por ejemplo, se ha detectado una limitación del almacenamiento.
Un estado rojo o incorrecto indica que la degradación ha persistido por más tiempo del permitido por sus objetivos de confiabilidad o que el flujo ya no está disponible.
Nota
El modelo de salud no debería tratar todos los fallos por igual. El modelo de salud debe distinguir entre fallas transitorias y no transitorias . Debe distinguir claramente entre errores esperados transitorios pero recuperables y un verdadero estado de desastre.
Este modelo funciona utilizando una estrategia de supervisión y alerta que se desarrolla y funciona según los principios de la mejora continua. A medida que evolucionan sus cargas de trabajo, sus modelos de estado deben evolucionar con ellas.
Para obtener orientación detallada sobre las configuraciones de supervisión y alertas, consulte la guía supervisión de estado.
Visualización
Para mantener informados a sus 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 salud de la carga de trabajo, considere crear paneles de control en su solución de supervisión. Analice las soluciones de visualización con las partes interesadas para asegurarse de entregar 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 Power Platform
Power Platform Los SLA proporcionan los compromisos de tiempo de actividad y conectividad. Microsoft Diferentes servicios tienen diferentes SLA y, a veces, las SKU de un servicio tienen diferentes SLA. Para obtener más información, consulte Contratos de nivel de servicio para servicios en línea.
El SLA de Power Platform incluye procedimientos para obtener un crédito de servicio si no se cumple el SLA, junto con definiciones de disponibilidad para cada servicio. Ese aspecto del SLA actúa como una política de cumplimiento.
Microsoft Business Applications proporciona capacidades de continuidad empresarial y recuperación ante desastres (BCDR) a todos los entornos de tipo de producción en Dynamics 365 y aplicaciones SaaS. Power Platform Descubra cómo Microsoft garantiza que sus datos de producción sean resilientes durante interrupciones regionales.
Alineación de la organización
Cloud Adoption Framework proporciona orientación para recomendaciones para SLO y SLI relacionados con la supervisión en toda la organización.
Para más información, consulte SLO de supervisión de nube.
Lista de comprobación de fiabilidad
Consulte el conjunto completo de recomendaciones.