Recién termino el curso Troubleshooting and Debugging Techniques en Coursera. Muy bueno.
Troubleshooting
Si bien parte de mi trabajo está relacionado a la temática (ya que suelo realizar soporte de linux nivel 3) el curso formaliza bastante la tarea de Troubleshooting en su ciclo de:
- Obtención de información: ¿cual es el estado actual?, ¿cuando pasa?, ¿cuales
son las consecuencias?
- Pasar del no funciona a una descripción más exacta preguntando a los involucrados.
- Obtención del caso mínimo reproducible.
- Hipotesis respecto a la causa del problema
- Considerar siempre las explicaciones más simples primero y luego seguir un proceso de eliminación hasta dar con el problema.
- Aplicación de correcciones
- A corto plazo (workaround)
- A largo plazo (corrección definitiva)
- Documentación del problema y solución para referencia futura.
Algunos de los trucos que aprendí:
- ltrace, para interceptar y grabar llamadas a librerías dinámicas.
- trickle, para limitar el ancho de banda de una aplicación.
- ab, para obtener estadisticas de un servidor HTTP.
- daemonize, para ejecutar un programa como demonio.
kill -STOP
ykill -CONT
, para detener y continuar procesos que estén utilizando mucho CPU. Sin duda un recordatorio para releer la página del manual de signal(7).- Encadenamiento de head y tail para realizar partición binaria en archivos
al buscar datos inválidos. Ejemplo:
$ wc -l data.csv 100 data.csv $ head -50 data.csv | tail -25 | ./script
- Busqueda de archivos en uso a los que se les realizó unlink (borrados
inmediatamente despues de ser creados para que al cerrarse el programa se
libere el espacio) mediante lsof:
sudo lsof | grep deleted
Sobre los distintos programas existentes para observar el funcionamiento y la performance en linux, conviene ver la página Linux Performance de Brendan Gregg.
Debugging
Respecto al debugging, en mi caso fué más un repaso:
- strace, para rastrear las llamadas al sistema
- Obtención de core dump en caso de crash (usando
ulimit -c unlimited
) - gdb, para depurar programas
- valgrind, para realizar análisis de memoria (entre otros)
- Uso de profilers según lenguaje
Lo mismo con respecto a las causas de lentitud en programas:
- La mejor forma de no utilizar recursos es no hacer nada
- Intentar procesar una sola vez la información
- Mantener en memoria solo la información necesaria
- Utilizar estructuras de memoria adecuadas y caches cuando sea conveniente
- Liberar memoria y disco (caches/logs)
- Agregar información de depuración a los programas (logs que puedan habilitarse mediante flags que den más información respecto a lo que está haciendo el programa)
- Evaluar la utilización de threads
Manejo de tiempos
Nuevamente, ya se descubrió la pólvora, pero entre los tips a recordar:
- Matriz de decisión de Eisenhower o método de Eisenhower - matriz (urgente|no
urgente) x (importante|no importante) donde:
- Importante y urgente: hacer inmediatamente
- Importante y no urgente: tareas a largo plazo
- No importante y urgente: interrupciones - evitarlas, fijando horas en las que pueden interrumpirnos
- No importante y no urgente: distracciones - consumen nuestro tiempo y no nos dan nada a cambio; evitarlas
- Tener listadas en un mismo lugar todas las tareas a realizar y determinar urgencia e importancia de cada tarea
- No perder mucho tiempo en priorizar las tareas, ya que pasa a ser una distracción
- Estimar cuanto tiempo llevará una tarea. Para ello utilizar como estimación inicial el tiempo que nos llevó una tarea previa. Si la tarea es muy compleja descomponerla en partes que podamos estimar y agregar un tiempo de integración. Por último ponderar por un factor (se menciona 3) para cubrir los problemas que puedan surgir.
- Comunicar expectativas en cuanto a la realización de las tareas
- Automatizar procesos en la medida de lo posible.
Conclusión
Valió la pena, por lo menos como repaso de lo que ya conocía y para aprender algunos tips. Se lleva bastante bien el curso, ¡y hasta dan diploma!