Cuando hay una interrupción importante del sistema o un problema de rendimiento, los equipos de TI acuden al rescate para restaurar los servicios lo más rápido posible. Algunas organizaciones de TI siguen la gestión de servicios de TI (ITSM) administracion de incidentes prácticas para restaurar el servicio, luego siga los procedimientos de gestión de problemas para realizar el análisis de causa raíz (RCA). Las organizaciones más avanzadas pueden emplear ingenieros de confiabilidad del sitio (SRE) involucrados en la gestión de incidentes y problemas, pero su responsabilidad principal es impulsar medidas más proactivas para reducir las tasas de error y mejorar objetivos de nivel de servicio.
Si bien gran parte de las operaciones de TI tienden a centrarse en incidentes importantes como interrupciones, problemas de rendimiento disruptivo y ataques a la seguridad, uno de los desafíos más difíciles es encontrar la causa raíz de los problemas esporádicos que surgen como una aguja en un pajar. Estos problemas son poco frecuentes, afectan a un pequeño subconjunto de usuarios o duran muy poco tiempo. Sin embargo, pueden ser muy perjudiciales para el negocio si ocurren durante operaciones críticas realizadas por usuarios finales importantes.
Aquí hay unos ejemplos:
- Un usuario crea una búsqueda compleja en un sitio web o una consulta en una base de datos que acumula recursos del sistema y obstaculiza todas las demás actividades de búsqueda.
- Una transacción bloquea los recursos del sistema y sólo crea un problema de rendimiento cuando varios usuarios realizan la misma transacción simultáneamente.
- Un cable, una tarjeta de red u otro dispositivo defectuoso genera una pérdida de paquetes, pero el impacto solo lo sienten los usuarios finales durante los períodos de uso pico.
- La duración de un procedimiento de copia de seguridad de una base de datos aumenta a medida que crecen los datos, lo que crea problemas de rendimiento sólo para un subconjunto de usuarios finales.
- Un servicio de terceros tiene tiempos de respuesta más lentos de lo habitual y degrada el rendimiento de las aplicaciones dependientes.
«Reducir los problemas de rendimiento de las aplicaciones difíciles requiere un ciclo de retroalimentación y depuración que funcione», dice Liz Fong-Jones, directora de tecnología de campo de Panal. “Los problemas simples y rápidos a menudo aparecen en un pico en una única consulta preagregada en un panel, pero cualquier problema más complicado que eso es, por definición, un “desconocido” que no fue visto ni anticipado previamente por el desarrollador en el momento en que escribieron el código”.
Encontrar la causa raíz de los problemas de rendimiento esporádicos
Como desarrollador en mi juventud y luego como CIO, he experimentado muchos problemas de aguja en el pajar, y encontrar la causa raíz puede llevar mucho tiempo y ser propenso a errores.
A veces, el desafío es resolver la causa raíz de demasiados datos, un problema Plataformas AIops puede ayudar a abordar. Otras veces, faltan datos, hay problemas de calidad de los datos o conjuntos de datos que deben unirse. Geoff Hixon, vicepresidente de ingeniería de soluciones de Software junto al lagodice: «Los problemas de rendimiento de las aplicaciones no siempre son fáciles de encontrar y solucionar, especialmente cuando hay lagunas en los datos que pueden causar puntos ciegos sobre la verdadera causa raíz».
Cómo realizar un análisis de causa raíz (RCA)
Lo que se necesita es un proceso que los SRE, los desarrolladores y los ingenieros operativos de TI puedan seguir para realizar RCA en problemas que son más difíciles de encontrar. Propongo cuatro pasos:
- Gestionar la observabilidad como producto.
- Planifique un análisis de arriba hacia abajo y de abajo hacia arriba
- Determinar si se trata de un problema de red
- Colaborar y triangular sobre las causas fundamentales
Paso 1: gestionar la observabilidad como producto
En mi libro, Pionero digital, cuento varias historias sobre cómo solucionar problemas de rendimiento mediante la observabilidad. «Es fácil para las personas perseguir a los conejos blancos y tomar otros caminos equivocados, y los datos de observabilidad deberían ayudar a guiar a los equipos hacia las áreas de enfoque óptimas».
Una mejor práctica de Devops es mejorar la observabilidad de microservicios, canalizaciones de datos, aplicaciones y otro software desarrollado internamente. El desafío para muchas organizaciones es crear y mejorar estándares de datos para que la coherencia mejore la facilidad de uso cuando se necesita RCA.
Nick Heudecker, director senior de estrategia de mercado e inteligencia competitiva de Cribl, recomienda llevar la estandarización un paso más allá y tratar los registros de aplicaciones como un producto de datos diseñado para ser consumido por las operaciones de TI. “El factor más importante a la hora de identificar problemas de rendimiento de las aplicaciones es garantizar que la telemetría procedente de las aplicaciones sea utilizable por los sistemas posteriores. Esto significa estructurar registros, enriquecerlos con el contexto adecuado y entregarlos a plataformas relevantes. Suena simple, pero el desafío es que los desarrolladores que producen los registros a menudo no son las personas que los usan en el lado de las operaciones”.
La estandarización de los datos de observabilidad es una forma de producir la observabilidad y simplificarla para las necesidades operativas. Otro Mejores prácticas para la observabilidad de Devops. incluir consultoría con gestión de riesgos sobre datos confidenciales y políticas de retención de datos. Los equipos de Devops también deben tomar medidas para educar a los SRE y a las personas que trabajan en la red y los centros de operaciones de seguridad (NOC y SOC) para conectar lo que hace el software con cómo se representan los datos de observabilidad en archivos de registro y otros repositorios.
Para las grandes organizaciones que desarrollan muchas aplicaciones y microservicios, los estándares de observabilidad deben combinarse con automatización, herramientas de análisis y modelos para facilitar el análisis de la causa raíz.
«Un cambio hacia una mentalidad de análisis de datos más específica y en tiempo real en la práctica de observabilidad de una empresa permite a los ingenieros consultar los datos de forma proactiva y obtener la información necesaria para resolver los problemas de rendimiento de las aplicaciones más desconcertantes», afirma Asaf Yigal, cofundador y director de tecnología. de Logz.io. «Para llegar a la causa raíz y resolver problemas críticos de rendimiento de los sistemas modernos con muchos microservicios, se requiere una solución más eficiente que atraviese los datos mediante la automatización y permita una respuesta proactiva en lugar de reactiva».
Es importante tener una mentalidad de mejora continua y una estrategia de lanzamiento incremental según los estándares de observabilidad. A medida que los NOC, SOC y SRE encuentren nuevos problemas, los equipos de desarrollo deben utilizar los comentarios para mejorar la recopilación de datos.
Paso 2: Planifique un análisis de arriba hacia abajo y de abajo hacia arriba
Es relativamente fácil encontrar una consulta lenta con archivos de registro de bases de datos básicos. Identificar las causas fundamentales se vuelve más complejo cuando el rendimiento de las consultas solo se degrada cuando la base de datos está bajo carga y varias consultas compiten por los mismos recursos del sistema.
Grant Fritchey, defensor de Devops en Software Redgate, comparte un ejemplo de una consulta que se ejecutaba rápidamente, aproximadamente 6 ms en promedio. “Desde el punto de vista de la medición del rendimiento, era una consulta sin importancia, hasta que veías los recuentos de ejecución y te dabas cuenta de que la consulta se llamaba miles de veces por minuto. Incluso a 6 ms, no corría lo suficientemente rápido. Esto subraya la necesidad de integrar herramientas de observabilidad y monitoreo de bases de datos para lograr una comprensión holística y matizada del desempeño del sistema”.
Un RCA efectivo requiere herramientas de monitoreo hacer más que alertas básicas de interrupciones o rendimiento importante. Las operaciones y los SRE necesitan indicadores cuando el desempeño está fuera de la norma y herramientas para análisis de arriba hacia abajo para profundizar en transacciones y actividades sospechosas. Las herramientas también deberían ayudar a identificar valores atípicos de desempeño, especialmente para actividades de gran volumen y de bajo desempeño. Las mejores herramientas también ayudan a aislar las experiencias del usuario final, de modo que cuando hay una llamada de atención al cliente sobre un problema, las operaciones tienen herramientas para realizar un RCA para ese usuario.
Paso 3: determine si se trata de un problema de red
Es más fácil para los equipos de desarrollo señalar problemas en la red y la infraestructura como la causa raíz de un problema de rendimiento, especialmente cuando son responsabilidad de un proveedor u otro departamento. Esa respuesta instintiva fue un problema importante antes de que las organizaciones se adaptaran cultura devops y reconoció que la agilidad y la resiliencia operativa son responsabilidad de todos.
«El villano cuando hay problemas de rendimiento de las aplicaciones es casi siempre la red, y siempre es a lo primero a lo que culpamos, pero también a lo más difícil de demostrar», dice Nicolas Vibert de isovalente. «La nube nativa y las múltiples capas de virtualización y abstracción de la red causadas por la contenedorización hacen que sea aún más difícil correlacionar la red como la causa raíz del problema».
Identificar y resolver problemas complejos de red puede resultar más desafiante cuando se crean microservicios, aplicaciones que se conectan a sistemas de terceros, flujos de datos de IoT y otros sistemas distribuidos en tiempo real. Esta complejidad significa que las operaciones de TI deben monitorear las redes, correlacionarlas con problemas de rendimiento de las aplicaciones y realizar RCA de red de manera más eficiente.
«La supervisión integrada de paquetes en entornos virtualizados en rutas de tráfico de norte a sur y de este a oeste proporciona información coherente y en tiempo real sobre el tráfico y el rendimiento de las aplicaciones», afirma Eileen Haggerty, vicepresidenta ejecutiva de marketing de productos y soluciones de NETSCOUT. “Pero cada dominio y ubicación debe tener el mismo nivel de análisis, inteligencia y visibilidad, sin importar dónde se ejecuten las cargas de trabajo, las aplicaciones y los servicios. Un enfoque de medición consistente en todos los entornos de alojamiento permite una determinación más fácil y rápida de la causa raíz y la ubicación de los problemas de rendimiento para las aplicaciones en cualquier infraestructura de red».
Paso 4: Colaborar y triangular las causas fundamentales
Otras dos recomendaciones se centran en cómo colaboran los equipos para resolver incidentes y realizar análisis de causa raíz. He dirigido más de lo que me corresponde en llamadas de puente y salas para encontrar y solucionar problemas, lo que puede ser un mal necesario durante una interrupción importante. Sin embargo, estos enfoques son mucho menos efectivos cuando se resuelven problemas de rendimiento esporádicos que requieren correlacionar datos de múltiples herramientas y fuentes de datos de observabilidad. Muchos de estos problemas requieren un equipo interdisciplinario para colaborar, compartir conocimientos y trabajar juntos de manera eficiente cuando se necesita un RCA.
«He observado una ausencia notable de documentación de aplicaciones y una comunicación limitada entre equipos en muchas organizaciones más grandes y bien establecidas», dice Chris Hendrich, CTO asociado de AHORA. «Romper estos silos inconexos puede ayudar a las empresas a mejorar su capacidad para realizar análisis de causa raíz».
El segundo habla de cómo los equipos buscan las causas fundamentales. Fong-Jones de Honeycomb dice: “No es necesario saltar directamente a la aguja en el pajar, sólo poder reducir las partes del pajar en las que está o no la aguja hasta encontrarla. Pero las herramientas pueden ayudar a generar preguntas que le ayudarán a filtrar el pajar”.
Todas las organizaciones de TI se enfrentan a problemas de rendimiento que son difíciles de resolver. Los equipos que colaboran, comparten información, crean estándares de observabilidad y desarrollan experiencia en el uso de herramientas de monitoreo pueden reducir el estrés, reducir el tiempo y mejorar la precisión de sus RCA.
Copyright © 2024 IDG Communications, Inc.