Cómo hacer troubleshooting en infraestructura (imho, casi un source code de troubleshooteo para administración de sistemas).
Puede haber y debería haber mejores métodos, por eso todo el tiempo estoy buscando optimizarlo (así que las críticas son más que bienvenidas).
Hay dos partes en mi metodología de troubleshooting habitual,
- la parte lógica, cómo pensamos el problema y
- la parte práctica, cómo implementamos lo que hay que hacer para avanzar en la solución.
Escenario
Con un ejemplo es más fácil: tenemos que copiar archivos entre dos servers, usamos rsync directamente (no el modo daemon), le damos enter y no anda > acá comienza el troubleshooting.
El comando rsync para los ejemplos de "no funciona".
$ rsync -avz /home/ahornero/ alberto@192.168.1.30:/home/alberto/
[ en realidad el comando está perfecto, pero vamos a hacer de cuenta que tiene algun problema que le impide ejecutarse correctamente]
Parte lógica
Esto es lo fácil. "Todos" los sistemas funcionan igual: tienen - básicamente - tres etapas
- input (datos de entrada),
- procesamiento (se procesa el input),
- (y luego dan un) output (datos de salida).
Los problemas pueden estar en cualquiera de esas 3 etapas, se ubican casi siempre en las dos primeras, pero *no hay que olvidar chequear la 3ra. (nunca).
* Que un problema se solucione, no implica nada más, puede haber otros problemas, relacionados o no con el anterior.
Ejemplos de algunos problemas posibles por etapa:
1) Input: rsync "no actualiza" porque no hay datos nuevos para sincronizar.
2) Procesamiento: rsync "no actualiza" porque el comando está mal ( o el archivo de configuración en el modo daemon), apunta a una ip erronea, no a la correcta.
3) Output: rsync "no actualiza" porque los datos supuestamente nuevos ya fueron copiados antes (en un comando previo por ej.), el output no estaba mal, nos estabamos confundiendo nomás.
Parte práctica
Esta es la difícil. Acá le ponemos "nombre y apellido" al input, procesamiento y output, luego empezamos a "trastear" con cada una de ellas.
Tenemos que identificar efectivamente qué constituye en el sistema cada una de esas etapas. Luego de identificarlas, hay que checkear la integridad de cada una, es decir comparar el estado esperado en un comportamiento normal con el estado que obtenemos nosotros en nuestro sistema con fallas.
* Sistema modelo: Acá nos puede servir muchísimo tener un sistema "modelo" que funcione bien, para compararlo con el que anda mal (comentario: los artículos de Internet pueden tener errores, doble-chequeen si ven algo "raro" en una sintaxis o en una implementación).
* Documentación: En este punto es donde solemos repasar:
- la documentación de arquitectura de un sistema (como está pensado que funcione), y
- la documentación de configuración (como se instala y configura), y
- la documentación de implementación (como lo instalaron y configuraron en la práctica).
- Cualquier fallo o debilidad en la documentación necesaria (los 3 tipos), nos va a traer (más) problemas, sepanlo desde el vamos.
- De hecho, un método práctico para convertir un alto nivel de skillset de un sysadmin experimentado en nada, es no tener documentación adecuada para troubleshooting. Para un novato, la ausencia de documentación debería ranquear entre los primeros lugares de lo peor que le puede pasar como sysadmin, sepanlo para preparar las (contra) medidas necesarias.
* KISS: esta filosofía, KISS (Keep It Simple Stupid, Mantenlo Fácil, Estúpido), de los sysadmin está fuertemente orientada al troubleshooting rápido, por ello las soluciones más genéricas y obvias posibles son las mejores. Cualquier customización innecesaria en la implementación introduce nuevas variables a analizar y, en consecuencia, nuevos puntos de fallo.
Ejemplo: en el comando rsync de antes, una customización es la ip y si estuviera mal, el comando no funcionaría.
Ejemplo de la parte práctica:
En el comando rsync de arriba, repasamos el cómo debería funcionar exactamente rsync (arquitectura), y luego vemos cómo debería estar escrito (configuración), y finalmente chequeamos cómo está escrito el comando (implementación).
Ejemplo del ejemplo: si hay un error de sintaxis, acá debería aparecer, claro como agua mineral.
Luego de este paso, ya deberíamos tener a la vista nueva información de utilidad para solucionar el problema.
La 4ta. etapa: el "medio"
* Ahora subimos la dificultad 1 (un) nivel.
A veces en el tránsito de una etapa a otra, de input a procesamiento y de ahí a output, y luego del output en sí (hasta justo antes del resultado normal esperado del sistema), puede haber problemas (también). En otras palabras, hay que agregar una etapa de chequeo al troubleshooting, el medio:
4) El "medio" por donde se transcurre de un estado al otro puede estar mal.
Ejemplo 1: rsync "no actualiza" porque el disco donde intenta escribir está lleno y no puede volcar correctamente su "output".
"Medio" no es la red siempre (como ven en el ejemplo), pero en procesos distribuídos y remotos, sí puede serlo, aparte de otros "medios".
Ejemplo 2: rsync "no actualiza" porque el puerto de red donde intenta establecer la conexión está firewalled en la red.
"Medio" es un también sinónimo de "ambiente", environment en inglés, si todo el sistema (el comando rsync en este caso), no funciona y las 3 primeras etapas están bien, puede haber un fallo en el ambiente donde corre el sistema.
Ejemplo 3: Cuando rsync no está instalado, cuando no figura en el $PATH del usuario o,
Ejemplo 3 más difícil: si solo se puede correr usando sudo (deberíamos haberlo detectado cuando leímos la documentación de implementación de hecho, ya que en este caso no sería un modo estándar de correr rsync, por lo que habría que probar primero si el "ambiente" funciona bien).
* Trágicamente, la etapa 4) consiste en realidad tres chequeos distintos adicionales, ya que estamos viendolo para las 3 primeras etapas del troubleshooting y llegamos a un total final de 6 chequeos a realizar.
Problemas del problema
Cómo se ve, en algun punto vamos a resolver las 3 etapas iniciales, input, procesamiento y output, y luego pasaremos a analizar la 4 etapa.
Se ve que puede haber fallos que tienen mucha (muchísima) interacción con software y sistemas fuera del que está fallando en sí (gracias etapa 4), y es por eso que un sysadmin debe tener un buen nivel de insight / conocimiento / información de tanto software / sistema como le sea posible.
Algun nuevo fallo recien detectado puede directamente sacarnos del troubleshooting de fallo del sistema que ya estamos analizando y llevarnos a un nuevo proceso de troubleshooting, ubicado en un sistema relacionado con el anterior y requisito necesario para que el primero funcione (gracias etapa 4, siempre nos acordamos de vos).
Ejemplo: si rsync no está instalado, tenemos que instalarlo (hay que aprender a hacerlo); si la instalación falla, hay que ver por qué falló la instalación o; si el puerto donde se conecta rsync está firewalled, tenemos que reconfigurar el firewall (o pedirle al netadmin que lo haga y luego correr diagnósticos para ver que sea así),
Iteración
Esta metodología es eso, un método, y no es una receta porque debe ser utilizada con criterio, es decir, se debe manejar analizando la situación actual y modificando las acciones de acuerdo a ello, como si fuera un automovil, si hay una curva adelante, se baja la velocidad, se ve la dificultad de la curva, se suspenden otras acciones temporalmente (no tratamos de adelantarnos), etc.
La iteración se va a dar cuando haya varios problemas, paralelos o anidados, y tengamos que ir resolviéndolos.
La habilidad y la experiencia (skillset & expertise), dan ventaja para acelerar el avance hacia la solución, principalmente porque un sysadmin experimentado descarta rápidamente los problemas posibles pero sumamente improbables (y guarda un registro de qué fue lo que obvió, para volver sobre sus pasos si fuera necesario).
Un sysadmin sin los beneficios anteriores puede igualmente tener excelente performance en un troubleshooting, simplemente prestando atención a cuando un proceso de troubleshooting deriva hacia otro nuevo proceso y por qué (así podrá retomar el troubleshooting inicial cuando solucione el problema derivado).
Links:
(al final de la página tiene una linda lista de links con documentación)
(de ahí saqué el comando)
No hay comentarios:
Publicar un comentario