Resolución proactiva de problemas

El trabajo de administrar sistemas consiste en un buen porcentaje en resolver problemas en la infraestructura.

Resolución de problemas reactivo vs. proactiva
La visión de décadas anteriores, cuando las infraestructuras informáticas no eran tan importantes para las organizaciones como las de ahora, era actuar reactivamente, resolver los problemas a medida que iban ocurriendo, intentando rastrear la fuente del error (la fatídica "causa raíz", root cause), mediante RCA (Root Cause Analisys, "Análisis de Causa Raíz").

En algun momento hace no tantos años las infraestructuras añadieron el requerimiento de tener que estar funcionales el 100% del tiempo (online), es decir, ímplicitamente, es el requerimiento no poder fallar nunca.

La forma de trabajo anterior al 100% de tiempo online era: montar la infraestructura lo mejor posible, luego ir reparandola según era necesario; es decir resolver los problemas de forma reactiva.

Si hacía falta sacarla de línea (apagarla), durante varios %MEDIDA_DE_TIEMPO% (segundos, minutos, horas, días, etc.), se consideraba ello un fallo catastrófico y se procedía implementar planes más drásticos de resolución del problema (DR - Disaster Recovery).

Avance rápido al 2012 y las medidas de DR son anatema, nadie quiere oír hablar de no tener en servicio un sistema con requisito de 100% de tiempo online, mucho menos de tener que implementar acciones para restaurarlo a un estado funcional. Hay que tener esas medidas, pero se aspira, se planea y se diseña las infraestructuras para nunca tener que usar planes de Disaster Recovery.

Claro, la resolución reactiva de los problemas implica la existencia de "causas raíz" que estaban ahí en la infraestructura previo a la existencia del problema a resolver. Lo necesario para evitar caídas de servicio que impliquen implementar planes de DR es resolver los problemas proactivamente, en otras palabras, resolver los problemas antes de que ocurran, y por ende, buscar y encontrar las causas que van a crear problemas.


Predicción de problemas + resolución proactiva
La idea de que los problemas deben resolverse antes de que ocurran se vuelve viable mediante diferentes herramientas, claro, la información útil que esas herramientas producen debe estar disponible a los administradores. En general, podemos mencionar al típico Nagios, con un buen nivel de provisión de información (vía agente local por ejemplo), sumando algun soft de recogida de métricas y otro de análisis de esas métricas.

La información clave para el administrador está en la vista del análisis de las métricas, en gral. y como mínimo serán una gráficas a revisar al menos semanalmente para verificar que la "imagen" es la típica de una buena performance.

En realidad un buen análisis predictivo se puede realizar operando - programando una aplicación, implementando un software prearmado que lo haga - sobre las métricas, extrayendo y mostrando los valores fuera de promedios usuales. Los promedios usuales son una buena manera de crear código "template" para analizar métricas en gral., de ese modo se evita tener que depender de valores threshold hardcodeados server por server.

Por ejemplo, si tenemos un server "Caño" donde el consumo promedio de memoria está en un 80% diario de la capacidad disponible, y otro server "Pareto" donde el mismo recurso solo se consume a un 15% diario, usar promedios nos va a evitar tener que "explicar" en el código que hace el análisis que en Caño el 80% de consumo de ram está OK, pero en Pareto si vemos un 80% de consumo de ram, algo no anda muy bien.

Y eso se realiza automáticamente, no hay que depender de valores hardcodeados que pueden cambiar de un día para otro.

Si nuestra app de análisis tiene un buen código para dumpear los resultados significativos, al menos en forma de texto, el resultado final podría llegar a ser desde un simple logfile en un server (de análisis), con el resumen de lo extraído por la app, hasta un mail enviado a diario al sysadmin, que dependiendo de si encontró o no valores fuera de los promedios puede llegar a modificar el subject del correo desde un [Valores Normales] a un [Valores Extraños], o incluso un [Valores Críticos Confirmados] > si es que acaso llegara a encontrar cualquier cosa con 90% a 100% de valores. Idealmente tendríamos todo lo anterior, más una interfaz gráfica con algun rutilante mensaje en color rojo indicandonos que algo no anda tan bien, al parecer.

Diferencia con alertas activas
En Nagios y otros software de monitoreo tenemos interfaces gráficas que van a mostrar en "rojo rutilante" los errores actuales en la infraestructura. No me refiero a este tipo de herramientas ni resultados al hablar de avisos previos a la ocurrencia de errores y outages (el error/outage ya ha ocurrido cuando vemos esos mensajes).

Fuentes de datos
La información base en la cual se puede realizar ese análisis puede ser casi cualquiera: se puede configurar Nagios para que dumpee datos históricos a un registro, se puede operar sobre los logfiles de sistema de los servers (el resultado de syslog en Linux, y/o el de Event Log en Windows Server), idealmente esos logs deberían ser automáticamente enviados a un log server para poder trabajar sobre ellos con facilidad. Otra opción para Linux es operar sobre los registros de soft como SAR por ejemplo.

Como se ve, en el párrafo anterior los datos necesarios para la resolución proactiva de problemas están disponibles por defecto, y sin mayor customización de la configuración de los servers en gral., sin importar la plataforma (win, linux). Lo necesario es montar software que se encargue de aprovechar esas fuentes de datos.


Conclusiones
La resolución reactiva de problemas en una infraestructura que tiene el requerimiento de permanecer funcional el 100% del tiempo no es el modo ni la práctica correcta.

La consecuencia probable de trabajar con práctica de resolución reactiva de problemas es que la infraestructura pueda fallar, no lograndose el 100% de funcionalidad requerida (y casi de seguro necesaria e indispensable), llegando en casos extremos a la necesidad de implementar Disaster Recovery.

Se necesita cambiar la práctica para implementar la resolución proactiva de los problemas y esto implica el montaje de más infraestructura, que permita adquirir los datos necesarios y analizarlos convenientemente, de modo que generen y además comuniquen oportunamente - luego de que ya no se pueda evitar que ocurra el problema es demasiado tarde - esos datos a los encargados de solucionar proactivamente los problemas (los administradores de sistemas).