Modelado de estado para cargas de trabajo
Las aplicaciones en la nube generan grandes volúmenes de datos operativos, lo que hace que sea difícil identificar y resolver problemas rápidamente. Una razón común para este desafío es la ausencia de una línea de base de mantenimiento personalizada para 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 en la que puede supervisar la carga de trabajo. Debe tener en cuenta 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 el 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 accionable. Le ayuda a administrar 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 mantenimiento | 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. |
Le recomendamos que vea 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 health 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 los tres estados:
Correcto: funciona de forma óptima y satisface las expectativas de calidad.
Degradado: muestra menos que un comportamiento 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 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 derivados de varias señales de estado y se contextualicen para la carga de trabajo. Por ejemplo, la definición de mantenimiento 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 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 está fuera de 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 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 específicos, pods, servicios o microservicios. O bien, las entidades pueden capturar interacciones de 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 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 implícita de ingresos. 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 maneras siguientes:
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 llevó a respuestas prioritarias. Los operadores también identifican fácilmente problemas en cascada o correlacionados.
Los operadores realizaron actividades posteriores al incidente con precisión porque el modelo de mantenimiento proporcionó información sobre las causas principales de anomalías y las señales de mantenimiento específicas implicadas.
Hizo que los datos de supervisión sean 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 que consume mucha 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
Por ejemplo, el modelo de mantenimiento 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 mediante 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 notificación.
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 se incorporan 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 estado 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 del estado 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 toda 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 los 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.
Registre 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 para diagnosticar los problemas de producción detectados.
Registre 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 los 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 cumplen los requisitos normativos o de cumplimiento, mantenerlos distintos evita las transacciones eliminadas.
Implementación del seguimiento distribuido
Implemente el seguimiento distribuido mediante la correlación de telemetría entre 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 las 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 como un todo 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 a 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 salud conocidas.
Adopción de técnicas de supervisión estructural y funcional
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.
Reforzar 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. Comprueba 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 mantenimiento 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 como resultado 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 alerta ambiental. 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 ambiental de las alertas suele dar lugar a alertas que se omiten o se omiten.
Un modelo de mantenimiento presenta la separación entre los datos de supervisión y las reglas de alerta. Una definición de mantenimiento 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 de procesos 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 mantenimiento proporciona flexibilidad para los distintos roles de carga de trabajo. Los propietarios de aplicaciones y los administradores de productos se pueden alertar a 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 proporcione información procesable.
Al visualizar el modelo de mantenimiento, considere la posibilidad de adoptar un enfoque de luz de tráfico para que los estados de mantenimiento tengan una visión inmediata de 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 mantenimiento. Para ver los procedimientos recomendados de diagrama, 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 y la 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 operativa. Un oficial de seguridad podría preocuparse más por las señales de intrusiones 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 sobre el estado para las distintas partes interesadas. Considere la posibilidad de crear modelos independientes de conjuntos de datos superpuestos.
Validación continua
Use el modelo de mantenimiento 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 se asocia normalmente 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 la aplicación y la información operativa. Cada aplicación puede tener su propio modelo de mantenimiento 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 de un patrimonio de nube completo mediante el uso de modelos de mantenimiento como componentes dentro de un modelo mayor. Los modelos de mantenimiento 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 lo que 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 heath 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 mantenimiento 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 una administración coherente y controlada por versiones del modelo de mantenimiento. Use la automatización para que el modelo permanezca actualizado a medida que agregue o quite los 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 los datos para satisfacer los requisitos de auditoría o en escenarios que implican el análisis de patrones a largo plazo en ia para las operaciones de TI.
Nota:
Al archivar los datos de mantenimiento, asegúrese de asociarlos con el estado de configuración del modelo. La interpretación de 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 mantenimiento para la carga de trabajo crítica.