El objetivo de este conjunto de artículos es el ser capaces de poder identificar y gestionar los posibles incidentes que se puedan presentar en el rendimiento de las aplicaciones en producción. Estos conocimientos se podrán aplicar con cualquier herramienta APM como pueden ser Dynatrace, AppDynamics, New Relic entre otras.
Es importante asimismo, con el conocimiento explicado en estos artículos, definir una buena estrategia para la gestión de los incidentes. No vale de nada identificar problemas en el software productivo, si luego no existe un estrategia en la empresa de comunicación y seguimiento de los mismos. En mi experiencia de más de 15 años en el mundo APM, he visto muchas veces que se generan alertas en los sistemas y se envían a una lista de distribución y al final nadie se hace responsable de la atención y seguimiento de los problemas.
Por tanto es importante para la implantación de una estrategia APM en una empresa, que todas las áreas estén implicadas en el proceso, y se establezca una metodología de gestión de incidentes correcta. Donde se identifique el problema, se documente, se envíe al área correspondiente para su solución, se realicen las pruebas adecuadas para identificar si ya se ha solucionado el problema, y finalmente se pase a producción la solución.
Para esta gestión de incidentes se deben seguir los siguientes principios:
- Hay que minimizar la disrrupción del servicio mediante una restauración lo más rápida posible del servicio
- Hay que ser un punto central entre el cliente e IT
- Tiene que proporcionar un camino desde el descubrimiento, pasando por el escalado, hasta asegurarse de su resolución
- Tiene que mejorar la eficiencia del área de IT
Los pasos que se siguen en la gestión de incidentes son los siguientes:
- Detectar y verificar que ha ocurrido un problema
- Caracterizar el identificar el problema
- Aislar el problema
- Documentar el problema
- Redirigirlo a la persona que puede solucionarlo
- Hacer seguimiento de la resolución
- Probar que la solución arregla el problema
- Subirlo a producción
Detectar y verificar que ha ocurrido un problema
Lo primero que hay que hacer es determinar si el problema viene identificado por un humano, o por una respuesta automática. Puede ser una queja de un usuario o una alerta definida en el sistema.
En el caso de que el problema venga identificado por un humano, hay que verificar cómo surge dicho problema e intentar replicarlo. Hay dos tipos de problemas que nos pueden reportar los humanos, los objetivos (error 500, mensaje de error en pantalla, timeout,…) y los subjetivos (tarda mucho en dar la respuesta, el sistema es lento,…).
En el primer caso es relativamente sencillo obtener evidencias, ya que el propio usuario nos puede enviar copias de pantalla de las evidencias. En el segundo caso, lo que hay que hacer es utilizar herramientas que nos permitan realizar mediciones sobre esas percepciones del usuario para poder valorar de una forma más precisa.
Es importante verificar los datos para validar los problemas reportados, ver tiempos de respuesta del navegador, verificar los problemas que se puedan identificar en los monitores de red o cuadros de mando de las herramientas.
Caracterizar e identificar el problema
Hay cuatro categorías de problemas:
- Consistentes (problemas que siempre están presentes y ni mejoran ni empeoran el comportamiento)
- Progresivos (el comportamiento del sistema se degrada a lo largo del tiempo)
- Repentinos (problemas que ocurren sin ningún aviso previo y son imposibles de predecir)
- Periódicos (problemas que aparecen y desaparecen a intervalos regulares)
Para identificarlos es importante observar datos a lo largo del tiempo y para ello se tienen que recolectar y almacenar, y finalmente hay que priorizar la resolución del problema dependiendo de la severidad del comportamiento del problema.
Aislar el problema
El origen de los problemas normalmente se van a originar en una de estas cuatro razones y es lo que hay que identificar:
- Carga: El problema ocurre únicamente cuando se lleva a cabo una actividad que es mayor de la esperada cuando se realizó el capacity planning
- Código: El problema ocurre debido a cómo se ha escrito el código
- Configuración: El problema ocurre debido a que uno o más configuraciones del servidor son incorrectas
- Back-end: El problema ocurre debido a que el sistema backend no está respondiendo como necesita la aplicación.
Proceso de eliminación de problemas
Cada problema tiene una combinación única de métricas llamada firma de métricas. El aislamiento del problema es un proceso sistemático de eliminación. Hay que analizar el problema para determinar si la firma de la métrica se ajusta al análisis. Si no se ajusta al análisis, hay que reanalizar de nuevo con una firma de métrica diferente.
Explicaremos más adelante las combinaciones de métricas que definen cada uno de los diferentes problemas, de forma que siguiendo esas combinaciones, se pueda identificar la combinación de métricas que identifiquen el problema que se esté teniendo en cada momento.
Mediante ese proceso de eliminación, se podrán identificar los problemas, considerando las opciones y comprobando si las métricas se ajustan al análisis. Si la firma no confirma la teoría supuesta, se debe continuar, hasta que se encuentre la que lo confirme.
Documentar el Problema
La documentación debe responder a lo siguiente:
- ¿Cómo se ha caracterizado el problema?
- ¿Qué métricas llevan a la caracterización del problema?
- ¿Dónde y cómo parece que ocurre el problema?
- ¿Qué componentes están involucrados?
- ¿Cómo están impactados los recursos como memoria y CPU?
Se debe comparar el estado durante el problema con el estado normal, combinar las métricas con las descripciones del comportamiento, hacer un caso de ejemplo y probarlo.
Todo esto es lo que tiene que haber en la documentación del problema para que se pueda replicar posteriormente por la persona que lo tenga que resolver.
La documentación debe mostrar también cuales son las métricas en un estado normal y cómo se diferencian con el estado del problema. Estos informes deben ser similares a un desarrollo de de una teoría científica en las que están envueltas la teoría, y los datos y los argumentos para reproducirla.
Redirigirlo a la persona responsable de solucionarlo.
La documentación generada debe ser enviada a los diferentes expertos que la tienen que resolver dependiendo del tipo de problema encontrado.
- Los problemas de carga se redirigen al administrador de sistemas o de red para que se considere un aumento de capacidad extra.
- Los problemas de código se reenvían a los programadores o arquitectos para que encuentren nuevas aproximaciones para el diseño de la aplicación.
- Los problemas de configuración se redirigen habitualmente a los administradores de los servidores de aplicaciones quienes son los que entienden las relaciones entre las diferentes configuraciones como el tamaño de los pooles de threads o la cantidad de memoria disponible en la JVM por ejemplo.
- Un problema de backend, normalmente es un problema de base de datos, y hay que redirigirlo al responsable del sistema backend, en este caso sería el responsable de la base de datos. En otros casos puede ser un sistema tercero, a través de webservices, y habría que conectar con el responsable del webservice.
