Modelado de estado para cargas de trabajo

Las aplicaciones en la nube generan grandes volúmenes de datos operativos, lo que dificulta la identificación y resolución rápida de problemas. Una razón común para este desafío es la ausencia de una línea base de mantenimiento que se personaliza con la funcionalidad de la carga de trabajo y la incapacidad de detectar el desfase de esa línea de base.

El modelado de estado es un ejercicio de observabilidad que combina el contexto empresarial con datos de supervisión sin procesar para cuantificar el estado general de una carga de trabajo. Ayuda a establecer una línea base con la que puede supervisar la carga de trabajo. Debe considerar los datos como la telemetría de los componentes de la infraestructura y de la aplicación. El modelado de estado también puede incorporar otra información necesaria para lograr los objetivos de calidad de la carga de trabajo.

Los problemas de rendimiento o la degradación operativa pueden provocar un desfase del estado operativo esperado. Al modelar el estado de una carga de trabajo, puede identificar el desfase y tomar decisiones operativas informadas que consideren el impacto empresarial.

El modelado de salud puentea la brecha entre los conocimientos operativos tribales y la información procesable. Le ayuda a administrar los problemas críticos de forma eficaz. El concepto es esencial para maximizar la confiabilidad y la eficacia operativa.

En esta guía se ofrecen instrucciones prácticas sobre el modelado de estado, incluido cómo crear un modelo que evalúe el estado en tiempo de ejecución de una carga de trabajo y todos sus subsistemas.

Terminología	Definición
Modelado de estado	Ejercicio de observabilidad que usa el contexto empresarial para interpretar los datos de supervisión como estados de mantenimiento.
Modelo de estado	Representación gráfica de entidades lógicas y sus relaciones para un ámbito determinado. Cada nodo tiene una definición de estado de mantenimiento para racionalizar los datos de supervisión en el modelo.
Entidad de mantenimiento	Componente lógico que representa una unidad individual de un sistema, una combinación lógica de varias entidades relacionadas o el sistema general.
Estado de mantenimiento	Estado definido y medible que proporciona información operativa significativa sobre el estado de una entidad.
Señal de estado	Flujos de datos individuales que proporcionan información sobre el comportamiento operativo de una entidad.
Modelo de modelos	Ámbito de modelado agregado en el que las entidades representan modelos de mantenimiento distintos para los sistemas de componentes.

Se recomienda watch este vídeo para comprender de alto nivel el modelado de estado.

¿Qué es el estado, el modelado de estado y un modelo de mantenimiento?

El término mantenimiento hace referencia al estado operativo de una entidad y sus dependencias. Esa entidad puede ser una unidad individual de un sistema, una combinación lógica de varias entidades relacionadas o el sistema general.

Se recomienda representar el estado en uno de estos tres estados:

• Correcto: funciona de forma óptima y satisface las expectativas de calidad.

• Degradado: muestra un comportamiento menor que correcto, lo que indica posibles problemas.

• Incorrecto: en un estado crítico y requiere atención inmediata

Nota

Puede representar el estado con una puntuación en lugar de estados para proporcionar más granularidad de datos.

Los estados de mantenimiento se derivan mediante la combinación de datos de supervisión con información de dominio. Cada estado debe definirse y debe ser medible. Los estados de mantenimiento se calculan mediante señales de estado, que son flujos de datos individuales que proporcionan información sobre el comportamiento operativo de una entidad. Las señales pueden incluir métricas, registros, seguimientos u otras características de calidad. Por ejemplo, una señal de estado para una entidad de máquina virtual (VM) podría realizar un seguimiento de la métrica de uso de CPU. Otras señales de esta entidad pueden incluir el uso de memoria, la latencia de red o las tasas de error.

A medida que defina las señales de estado, tenga en cuenta los requisitos no funcionales de la carga de trabajo. En el ejemplo de uso de CPU, incluya los umbrales esperados para cada estado de mantenimiento. Si el uso supera el umbral tolerado de acuerdo con los requisitos de carga de trabajo, el sistema pasa de Correcto a Degradado o Incorrecto. Estos cambios de estado desencadenan las alertas o acciones adecuadas.

El modelado de estado requiere que las entidades tengan estados bien definidos que se derivan de varias señales de estado y se contextualizan para la carga de trabajo. Por ejemplo, la definición de estado de una máquina virtual podría ser:

• Correcto: los requisitos y destinos no funcionales clave, como el tiempo de respuesta, el uso de recursos y el rendimiento general del sistema, están totalmente satisfechos. Por ejemplo, el 95 % de las solicitudes se procesan en 500 milisegundos. La carga de trabajo usa recursos de máquina virtual como CPU, memoria y almacenamiento de forma óptima y mantiene un equilibrio entre las demandas de carga de trabajo y la capacidad disponible. La experiencia del usuario está en los niveles esperados.

• Degradado: los recursos no funcionan de forma óptima, pero siguen funcionando. Por ejemplo, el disco de almacenamiento está experimentando problemas de limitación. Los usuarios pueden experimentar respuestas lentas.

• Incorrecto: la degradación supera los límites tolerados. Los recursos ya no tienen capacidad de respuesta ni están disponibles y el sistema ya no cumple los niveles de rendimiento aceptables. La experiencia del usuario se ve afectada gravemente.

El resultado del modelado de estado es un modelo o una representación gráfica de las entidades lógicas y sus relaciones para una arquitectura de carga de trabajo. Cada nodo tiene una definición de estado de mantenimiento.

Importante

El modelado de estado es un concepto abstracto que puede implementar y aplicar en distintos ámbitos si tiene una buena comprensión de los escenarios empresariales.

En la imagen:

• Las entidades son componentes lógicos de la carga de trabajo que representan aspectos del sistema. Pueden ser componentes de infraestructura, como servidores, bases de datos y redes. También pueden ser módulos de aplicación, pods, servicios o microservicios específicos. O bien, las entidades pueden capturar interacciones del usuario y flujos del sistema dentro de la carga de trabajo.

  Nota

  Los flujos de usuario y sistema resumen los requisitos no funcionales en escenarios empresariales que implican componentes de aplicación e infraestructura. Este resumen refleja el valor empresarial de la aplicación.

• Las relaciones entre las entidades reflejan las cadenas de dependencia dentro del sistema. Por ejemplo, un módulo de aplicación podría llamar a componentes de infraestructura específicos que forman una relación.

Considere un escenario en el que una carga de trabajo de comercio electrónico experimenta un pico en los mensajes con errores en una cola de Azure Service Bus, lo que provoca un error en los pagos. Este problema es fundamental para la organización debido a la pérdida de ingresos implícita. Aunque un desarrollador de aplicaciones puede comprender el efecto de este pico de métricas en los pagos, este conocimiento tribal no suele compartirse en el equipo de operaciones.

Un modelo de mantenimiento puede proporcionar a los operadores visibilidad inmediata del problema y sus efectos. El flujo de pago depende de Service Bus, que es uno de los componentes de carga de trabajo. La representación visual revela el estado degradado de la instancia de Service Bus y su efecto en el flujo de pago. Los operadores pueden comprender la importancia del problema y centrar sus esfuerzos de corrección en ese componente específico.

El modelado de estado era importante en el escenario anterior de las siguientes maneras:

• Mejoró el tiempo para detectar (TTD) y el tiempo para mitigar (TTM) al habilitar un aislamiento de problemas más rápido, lo que llevó a una detección más rápida de problemas y posibles correcciones.

• Los operadores recibieron alertas basadas en estados de mantenimiento, lo que redujo el ruido innecesario. Los operadores recibieron notificaciones que proporcionaron contexto específico sobre el impacto empresarial en los pagos.

• Las cadenas de dependencias ayudaron a los operadores a comprender completamente la extensión de los problemas operativos. Este conocimiento aceleró las evaluaciones de impacto y condujo a respuestas prioritarias. Los operadores también identifican fácilmente problemas en cascada o correlacionados.

• Los operadores llevaron a cabo actividades posteriores al incidente con precisión porque el modelo de mantenimiento proporcionó información sobre las causas principales de las anomalías y las señales de mantenimiento específicas implicadas.

• Hizo que los datos de supervisión fuera significativos para todos los miembros del equipo. Ha puentedo la brecha entre el conocimiento tribal y la información compartida.

• La organización usó el modelo de mantenimiento como base de referencia para futuras inversiones en operaciones controladas por inteligencia artificial para obtener información inteligente.

Esquema del modelo de mantenimiento

Los modelos de mantenimiento proporcionan un esquema de datos distinto optimizado para casos de uso de observabilidad. Este esquema toma el modelado de estado de un concepto abstracto a una solución medible. Al modelar los requisitos, los objetivos y el contexto arquitectónico específicos, puede adaptar los datos de mantenimiento a su escenario único.

El estado es un concepto de datos relativo. Cada modelo representa los datos de mantenimiento únicos y prioritarios para su ámbito contextual, incluso si usa el mismo conjunto de entidades. Lo que constituye un estado correcto en un escenario específico puede diferir significativamente en otros contextos.

Por ejemplo, considere los recursos de Azure del mismo tipo dentro de la carga de trabajo.

• La máquina virtual A ejecuta una aplicación sensible a la CPU.
• La máquina virtual B controla un servicio de uso intensivo de memoria.

Las definiciones de mantenimiento de estas máquinas son diferentes. Las métricas de uso de CPU probablemente influyen en el estado de mantenimiento de la máquina virtual A y la máquina virtual B podría priorizar las métricas relacionadas con la memoria.

Importante

Un modelo de mantenimiento no debe tratar todos los errores iguales. Debe distinguir claramente entre los errores esperados o transitorios pero recuperables y un verdadero estado de desastre.

Creación de un modelo de mantenimiento

El primer paso para crear un modelo de mantenimiento es un ejercicio de diseño lógico, que normalmente implica las actividades que se describen en las secciones siguientes.

Evaluación del diseño de la carga de trabajo

Comience este ejercicio de diseño lógico mediante la evaluación de los siguientes componentes del diseño de la carga de trabajo.

• Componentes de infraestructura como clústeres de proceso y bases de datos

• Componentes de la aplicación que se ejecutan en el proceso y sus componentes pertinentes

• Dependencias lógicas o físicas entre componentes

• Flujos de usuario y sistema

Por ejemplo, el modelo de estado de una aplicación de comercio electrónico debe representar el estado actual de los procesos críticos, como el inicio de sesión del usuario, la desprotección y los pagos.

Contextualizar el uso de requisitos empresariales

Evalúe la importancia relativa y el impacto general de cada flujo de su organización. Tenga en cuenta factores como la experiencia del usuario, la seguridad y la eficacia operativa. Por ejemplo, en la mayoría de los escenarios, es probable que el error de un proceso de pago sea más significativo que el error de un proceso de informes.

Identifique las rutas de escalación para controlar problemas relacionados con cada flujo. Para más información, consulte Optimización del diseño de cargas de trabajo mediante flujos.

Nota

Solo se da cuenta del valor del modelado de estado cuando incorpora los escenarios empresariales y el contexto. A continuación, puede racionalizar el impacto empresarial de los problemas operativos.

Asignación a métricas de confiabilidad

Busque métricas de confiabilidad relevantes en el diseño de la aplicación.

Considere la posibilidad de definir indicadores de nivel de servicio (SLA) y objetivos de nivel de servicio (SLO) para toda la aplicación y sus procesos empresariales individuales. Estos SLA y SLO deben alinearse con las señales de estado específicas que se tienen en cuenta para el modelo de mantenimiento. Al hacerlo, se crea una definición completa de mantenimiento que refleja con precisión el logro de un nivel de servicio aceptable para la aplicación.

Importante

Los SLA y los SLO son señales de estado críticas. Crean una definición significativa de mantenimiento que refleja el nivel de servicio que desea junto con otros atributos de calidad. También puede definir objetivos de mantenimiento del servicio (SPO) para capturar el estado que desea alcanzar en un intervalo de tiempo agregado.

Identificación de señales de estado

Para crear un modelo de mantenimiento completo, correlacione varios tipos de datos de supervisión, incluidas las métricas, los registros y los seguimientos. Al hacerlo, asegúrese de que el concepto de mantenimiento refleje con precisión el estado en tiempo de ejecución de una entidad específica o toda la carga de trabajo.

Uso de métricas y registros de la plataforma

En el contexto del modelado de estado, es esencial recopilar registros y métricas de nivel de plataforma de los recursos subyacentes de Azure. Estas métricas incluyen porcentaje de CPU, red dentro y salida de red y operaciones de disco por segundo. Puede usar estos datos en el modelo de mantenimiento para detectar y predecir posibles problemas al tiempo que mantiene un entorno confiable.

Además, este enfoque le ayuda a diferenciar entre errores transitorios o interrupciones temporales, y errores notranscientes o problemas persistentes.

Nota

Como procedimiento recomendado, debe configurar todos los recursos de la aplicación para dirigir los registros de diagnóstico y las métricas a la tecnología de agregación de registros elegida. Cree límites de protección mediante Azure Policy para garantizar una configuración de diagnóstico coherente en la aplicación y aplicar la configuración elegida para cada servicio de Azure.

Adición de registros de aplicaciones

Los registros de aplicación son un origen importante de datos de diagnóstico para el modelo de mantenimiento. Estos son algunos procedimientos recomendados para el registro de aplicaciones:

• Use el registro semántico o estructurado. Los registros estructurados facilitan el consumo automatizado y el análisis de datos de registro a escala.

  Considere la posibilidad de almacenar métricas de recursos de Azure y datos de diagnóstico en un área de trabajo de registros de Azure Monitor en lugar de una cuenta de almacenamiento. Mediante este método, puede crear señales de estado mediante consultas de Kusto para una evaluación eficaz.

• Registrar datos en el entorno de producción. Capture datos completos mientras la aplicación funciona en el entorno de producción. La información suficiente es esencial para la evaluación de la salud y diagnosticar los problemas de producción detectados.

• Registrar eventos en los límites del servicio. Incluya un identificador de correlación que atraviesa los límites del servicio. Si una transacción implica varios servicios y se produce un error en uno de ellos, el identificador de correlación le ayuda a realizar un seguimiento de las solicitudes en toda la aplicación e identificar la causa del error.

• Use el registro asincrónico. Evite operaciones de registro sincrónicas que puedan bloquear el código de la aplicación. El registro asincrónico garantiza la disponibilidad evitando trabajos pendientes de solicitud durante las escrituras de registro.

• Separe el registro de aplicaciones de la auditoría. Mantenga los registros de auditoría por separado de los registros de diagnóstico. Aunque los registros de auditoría satisfacen los requisitos normativos o de cumplimiento, mantenerlos distintos impide que se eliminen las transacciones.

Implementación del seguimiento distribuido

Implemente el seguimiento distribuido mediante la correlación de telemetría en los flujos críticos del sistema. La telemetría correlacionada proporciona información sobre las transacciones de un extremo a otro y es esencial para el análisis eficaz de la causa principal (RCA) cuando se producen errores.

Uso de sondeos de estado

Implemente y ejecute sondeos de estado fuera de la aplicación para comprobar explícitamente el estado y la capacidad de respuesta de la aplicación. Use respuestas de sondeo como señales dentro del modelo de mantenimiento.

Puede implementar sondeos de estado midiendo el tiempo de respuesta de la aplicación en su conjunto o desde sus componentes individuales. Los sondeos pueden ejecutar procesos para medir la latencia y comprobar la disponibilidad o extraer información de la aplicación. Para más información, consulte Patrón Health Endpoint Monitoring.

La mayoría de los equilibradores de carga admiten la ejecución de sondeos de estado que hacen ping a los puntos de conexión de la aplicación en intervalos configurados. Como alternativa, puede usar un servicio de guardián externo. Un servicio guardián agrega comprobaciones de estado de entre varios componentes de la carga de trabajo. Los guardianes también pueden hospedar código que corrige inmediatamente las condiciones de mantenimiento conocidas.

Adopción de técnicas de supervisión estructurales y funcionales

La supervisión estructural implica equipar la aplicación con registros semánticos y métricas. La aplicación recopila directamente estas métricas, que incluyen el consumo de memoria actual, la latencia de solicitudes y otros datos pertinentes de nivel de aplicación.

Fortalecer los procesos de supervisión mediante la supervisión funcional. Este enfoque se centra en medir los servicios de plataforma y su efecto en la experiencia general del usuario. A diferencia de la supervisión estructural, la supervisión funcional no requiere conocimientos detallados del sistema. Prueba el comportamiento visible externamente de la aplicación. Este enfoque es útil para evaluar los SLO y los SLA.

Modelar el diseño

Representa el diseño de aplicación identificado como entidades y relaciones. Asigne señales de estado a componentes específicos para cuantificar los estados de mantenimiento en un nivel de entidad. Tenga en cuenta la importancia de los componentes para determinar cómo deben propagarse los estados de mantenimiento a través del modelo. Por ejemplo, los componentes de informes podrían no ser tan críticos como otros componentes, lo que da lugar a distintos efectos en el estado general de la carga de trabajo.

Establecimiento de alertas accionables

Use los estados de mantenimiento evaluados para desencadenar alertas y acciones automatizadas. El estado debe integrarse dentro de los runbooks operativos existentes como una red de datos de observabilidad principal.

Normalmente, hay una asignación uno a uno entre los datos de supervisión y las reglas de alerta, lo que puede provocar resultados no deseados, como tormentas de alertas y ruido de alertas ambientales. Por ejemplo, en un clúster de proceso, los grandes volúmenes de alertas de nivel de máquina virtual en función del uso de cpu y el recuento de errores pueden sobrecargar a los operadores durante los errores y provocar retrasos en la resolución. De forma similar, cuando hay un gran número de alertas configuradas, el ruido de alerta ambiente suele dar lugar a alertas que se pasan por alto o se omiten.

Un modelo de mantenimiento introduce la separación entre los datos de supervisión y las reglas de alerta. Una definición de estado agrega muchas señales en un único estado de mantenimiento, lo que reduce el número de alertas para que los operadores puedan centrarse únicamente en alertas de alto valor que son críticas para la organización. Considere el escenario de comercio electrónico. Puede configurar una alerta para enviar notificaciones sobre los cambios en el estado del flujo de pagos del proceso en lugar de los cambios en los recursos subyacentes, como la cola de Service Bus.

Nota

La capacidad de alertar en todas las capas del modelo de estado proporciona flexibilidad para los distintos roles de carga de trabajo. Los propietarios de aplicaciones y los administradores de productos pueden recibir alertas sobre los cambios de estado de mantenimiento en escenarios empresariales clave o en toda la carga de trabajo. Los operadores se pueden alertar en función del estado de los componentes de la infraestructura o de la aplicación.

Visualización del modelo

Cree representaciones visuales, como tablas o gráficos, para transmitir eficazmente el estado actual y el historial del modelo de mantenimiento. Asegúrese de que la visualización se alinea con el contexto empresarial y proporciona información práctica.

Al visualizar el modelo de mantenimiento, considere la posibilidad de adoptar un enfoque de semáforo para que los estados de mantenimiento sean inmediatamente detallados en las cadenas de dependencias.

Asigne verde para un estado correcto, ámbar para degradado y rojo para un estado incorrecto. Al identificar rápidamente los estados codificados por colores, puede localizar eficazmente la causa principal de cualquier degradación de la aplicación.

Nota

Se recomienda tener en cuenta los requisitos de accesibilidad para las personas que tienen una discapacidad visual al crear un panel para el modelo de salud. Para ver los procedimientos recomendados de diagramas, consulte Diagramas de diseño de arquitectura.

Adopción del modelo de mantenimiento

Después de crear un modelo de mantenimiento, tenga en cuenta los siguientes casos de uso para impulsar la detección e interpretación de errores o problemas operativos.

Aplicabilidad a varios roles

El modelado de estado puede proporcionar información específica de las funciones de trabajo o de los roles dentro del mismo contexto de la carga de trabajo. Por ejemplo, un rol de DevOps podría necesitar información de mantenimiento operativo. Un oficial de seguridad podría estar más preocupado por las señales de intrusión y la exposición a la seguridad. Es probable que un administrador de bases de datos solo esté interesado en un subconjunto del modelo de aplicación a través de los recursos de la base de datos.

Adapte la información de salud para diferentes partes interesadas. Considere la posibilidad de crear modelos independientes de conjuntos de datos superpuestos.

Validación continua

Use el modelo de estado para optimizar los procesos de prueba y validación, como las pruebas de carga y las pruebas de caos. Puede validar el estado operativo en tiempo de ejecución durante las pruebas y evaluar la eficacia del modelo en escenarios de escala y error mediante la incorporación de modelos de mantenimiento al ciclo de vida de ingeniería.

Estado de la organización

Aunque el modelado de estado suele asociarse con la cuantificación de estados de mantenimiento para aplicaciones individuales, su aplicabilidad se extiende más allá de ese ámbito.

En un nivel de carga de trabajo individual, los modelos de mantenimiento proporcionan una base para la observabilidad de las aplicaciones y la información operativa. Cada aplicación puede tener su propio modelo de estado que capture lo que significa cada estado de mantenimiento dentro de su contexto.

Puede combinar varios modelos de mantenimiento en una construcción de alto nivel mediante la creación de un modelo de modelos. Por ejemplo, puede crear la superficie de observabilidad de una unidad de negocio o un patrimonio de nube completo mediante modelos de mantenimiento como componentes dentro de un modelo mayor. Los modelos de estado representan cargas de trabajo dentro del patrimonio como nodos dentro del gráfico de nivel superior. Use las relaciones de este modelo para capturar dependencias entre aplicaciones, incluidos flujos de datos, interacciones de servicio e infraestructura compartida.

Considere una empresa minorista que tiene varias aplicaciones para el comercio electrónico, los pagos y el procesamiento de pedidos. Puede definir cada una de estas aplicaciones como un modelo de mantenimiento independiente para cuantificar qué significa el mantenimiento de esa carga de trabajo. A continuación, puede usar un modelo primario para asignar todos estos modelos de mantenimiento de componentes como entidades y capturar el impacto operativo entre aplicaciones a través de cadenas de dependencias. Por ejemplo, si la aplicación de comercio electrónico se vuelve incorrecta, tiene un efecto en cascada en la aplicación de pago.

Tendencias de mantenimiento e inteligencia artificial para las operaciones de TI

El modelado de estado proporciona una línea base operativa cuantificada que se ajusta a un contexto empresarial específico. La inteligencia artificial para las operaciones de TI (AIOps) es una manera popular de mejorar la eficacia operativa. Los datos de mantenimiento son una entrada fundamental para los modelos de aprendizaje automático para analizar las tendencias de mantenimiento. Por ejemplo, los modelos de aprendizaje automático pueden:

• Extraiga más información de los cambios de estado y las acciones recomendadas.

• Analice las tendencias de mantenimiento a lo largo del tiempo para impulsar la predicción del problema y el refinamiento del modelo.

Mantenimiento del modelo de mantenimiento

Mantener un modelo de calor es una actividad de ingeniería continua que se alinea con el desarrollo y las operaciones de la aplicación. A medida que la aplicación evoluciona, asegúrese de que el modelo de mantenimiento evoluciona en paralelo.

Además, trate modelos de estado como artefactos de carga de trabajo que se deben integrar en el ciclo de vida de desarrollo. Adopte la infraestructura como código (IaC) para la administración coherente y controlada por versiones del modelo de mantenimiento. Use la automatización para que el modelo permanezca actualizado al agregar o quitar componentes de infraestructura y aplicación de la carga de trabajo.

Los datos de mantenimiento disminuyen gradualmente en el valor a lo largo del tiempo. Para optimizar la eficiencia operativa y minimizar los costos, evite conservar los datos de mantenimiento más allá de 30 días. Si es necesario, puede archivar datos para satisfacer los requisitos de auditoría o en escenarios que impliquen análisis de patrones a largo plazo en ia para las operaciones de TI.

Nota

Al archivar los datos de mantenimiento, asegúrese de acoplarlo con el estado de configuración del modelo. Interpretar los cambios de estado puede ser difícil sin este contexto.

Vínculos relacionados

• Para implementar sondeos de estado en ASP.NET, consulte Comprobaciones de estado en ASP.NET Core.
• Para obtener información sobre las métricas de supervisión, consulte Información general sobre las métricas en Microsoft Azure.
• Para obtener información sobre el uso de Application Insights, consulte Application Insights.
• Para conocer las consideraciones de diseño y las recomendaciones relacionadas con las cargas de trabajo críticas, consulte Modelado de estado y observabilidad para cargas de trabajo críticas en Azure.
• Para obtener una experiencia práctica, consulte Diseño de un modelo de estado para la carga de trabajo crítica.

Paso siguiente

Recomendaciones para diseñar una estrategia confiable de supervisión y alertas