Herramientas de crisis de Linux
Preinstalación de “herramientas de crisis”
- Muchos abogan por un grupo de paquetes estándar “crisis-essential”, análogo a build-essential, instalado de antemano en todos los servidores.
- Algunos ya mantienen esas listas mediante gestión de configuración (Ansible/Salt/Chef) bajo nombres como devops_tools.
- Existe la preocupación de que despojar sistemas y contenedores “por seguridad” a menudo elimina herramientas vitales de depuración, haciendo que los incidentes sean mucho más difíciles de resolver.
Cloud, ganado y “simplemente mata la máquina”
- Un grupo elogia el “ganado” virtualizado (a menudo en la nube), donde los nodos que fallan pueden reemplazarse rápidamente, restaurando el servicio y depurando fuera de línea.
- Otros se oponen: el reemplazo puede ocultar causas raíz, erosionar las habilidades de resolución de problemas y, a veces, el problema persiste en nuevas instancias.
- Varios señalan que esta cultura de “reiniciar/reemplazar primero” se parece a los desarrolladores junior que vuelven a clonar repositorios git en lugar de entender los problemas.
- Algunos distinguen entre el cálculo a corto y largo plazo: los reinicios rápidos son válidos, pero si se usan en exceso conducen al “misticismo tecnológico”.
Almacenamiento, redes y modos de fallo no triviales
- Los comentarios destacan que reemplazar ciegamente VMs es arriesgado con almacenamiento complejo (RAID, Ceph, MD, sistemas de archivos distribuidos); las reconstrucciones pueden aumentar el riesgo de fallo.
- Los problemas de red y DNS son frecuentes y a menudo se diagnostican mal; hay humor sobre “nunca es DNS… hasta que lo es”.
- En clústeres grandes de “big iron” o HPC, los fallos pueden involucrar capas de orquestación (p. ej., planificadores), almacenamiento por niveles e interconexiones exóticas.
Contenedores, Kubernetes y serverless
- Las herramientas siguen siendo útiles en EC2 y dentro de contenedores, ya que los contenedores son solo procesos en un host; las herramientas a nivel de host aún pueden inspeccionarlos.
- Para serverless (p. ej., Lambda) sin acceso al sistema operativo, la gente recurre a la observabilidad/perfilado a nivel de aplicación.
- Las configuraciones de Kubernetes orientadas a la seguridad a menudo carecen de shells y herramientas; se sugiere añadir imágenes de depuración o volúmenes de binarios estáticos, pero la administración puede resistirse debido a requisitos de pruebas y escaneo.
Herramientas y enfoques concretos mencionados
- Herramientas de sistema y trazado: perf, herramientas eBPF, strace (como “último recurso”), lsof, fuser, la familia sar, atop (con salvedades), tmux/screen.
- Ayudas de red/disco/depuración: nmap, netstat, nc, tcpdump-en-Docker, ncdu, rsync, busybox, binarios estáticos de rescate.
- Algunos abogan por herramientas entregadas mediante Docker cuando los gestores de paquetes están rotos, mientras que otros señalan que esto falla en entornos aislados de red.
Seguridad frente a operabilidad
- Un lado teme que preinstalar herramientas potentes aumente la superficie de ataque.
- Otros responden que los atacantes normalmente pueden traer sus propias herramientas; el verdadero coste es quedar repetidamente “encerrados” en entornos casi sin herramientas durante las crisis.