Errores comunes del sysadmin Linux¶

Este módulo recoge errores reales y recurrentes que cometen sysadmins en sistemas Linux, tanto principiantes como experimentados.

No es una lista para señalar culpables: es una colección de lecciones aprendidas. Muchos de estos errores solo se cometen una vez… si se entienden bien.

Introducción¶

En Linux, los errores no suelen ser por falta de comandos, sino por:

Exceso de confianza
Falta de método
Prisas
Cambios sin analizar impacto
No leer logs

Este módulo existe para que aprendas de errores ajenos y no tengas que pagarlos tú en producción.

Error 1: Trabajar siempre como root¶

Qué ocurre¶

Usar root para todo “porque es más rápido”.

Por qué es un problema¶

No hay protección ante errores
Un rm mal ejecutado es irreversible
No hay trazabilidad

Buen enfoque¶

Usuario normal para trabajo diario
sudo solo cuando es necesario

whoami
sudo comando

Regla: si puedes hacerlo sin root, hazlo sin root.

Error 2: Reiniciar sin mirar logs¶

Qué ocurre¶

“Algo no funciona → reinicio”.

Por qué es un problema¶

Pierdes información clave
El problema puede volver
No sabes qué pasó realmente

Buen enfoque¶

Antes de reiniciar:

journalctl -e
systemctl status servicio

Reiniciar no es solucionar, es ocultar síntomas.

Error 3: Usar chmod 777 como solución¶

Qué ocurre¶

Un servicio falla → chmod 777.

Por qué es un problema¶

Riesgo de seguridad grave
No soluciona la causa real
Mala práctica profesional

Buen enfoque¶

Analiza:

ls -l archivo
ps aux | grep servicio
id usuario_servicio

El problema casi siempre está en propietario o permisos del directorio.

Error 4: Matar procesos a ciegas¶

Qué ocurre¶

Ver algo consumir CPU → kill -9.

Por qué es un problema¶

Puedes matar procesos críticos
Corromper datos
Provocar caídas mayores

Buen enfoque¶

ps aux --sort=-%cpu | head
systemctl status servicio

Usa primero:

kill PID

Y solo al final:

kill -9 PID

Error 5: Cambiar varias cosas a la vez¶

Qué ocurre¶

Modificar permisos, config y reiniciar todo “para probar”.

Por qué es un problema¶

No sabes qué cambio funcionó
Dificulta rollback
Aumenta el riesgo

Buen enfoque¶

Un cambio
Probar
Observar logs
Documentar

Método > velocidad.

Error 6: No entender el impacto del disco lleno¶

Qué ocurre¶

Ignorar el uso de disco hasta que algo falla.

Por qué es un problema¶

Servicios dejan de escribir
Bases de datos se bloquean
El sistema se vuelve inestable

Buen enfoque¶

df -h
du -sh /var/log/*

Configura bien:

logrotate
alertas de espacio

Error 7: Actualizar sin pensar en producción¶

Qué ocurre¶

apt upgrade en horas críticas.

Por qué es un problema¶

Cambios de versión
Servicios reiniciados
Incompatibilidades

Buen enfoque¶

Antes de actualizar:

¿Qué se va a tocar?
¿Hay mantenimiento?
¿Hay rollback?
¿Hay backup?

apt upgrade --simulate

Error 8: No documentar lo ocurrido¶

Qué ocurre¶

Se arregla algo… y se olvida.

Por qué es un problema¶

El problema vuelve
Se pierde tiempo otra vez
El conocimiento no se acumula

Buen enfoque¶

Documenta para ti, no para otros:

FECHA:
PROBLEMA:
CAUSA:
SOLUCIÓN:

Un sysadmin sin notas repite errores.

Error 9: Confundir problema de red con problema de servicio¶

Qué ocurre¶

“El servicio no funciona” → tocar servicio.

Por qué es un problema¶

El servicio puede estar bien
El fallo puede ser red, DNS o firewall

Buen enfoque¶

Orden correcto:

ip addr
ip route
ping IP
ping nombre
ss -tulnp

Red primero, servicio después.

Error 10: Falta de método¶

Qué ocurre¶

Ejecutar comandos “a ver si funciona”.

Por qué es un problema¶

Diagnóstico errático
Cambios innecesarios
Riesgo alto

Buen enfoque¶

Siempre el mismo flujo:

Estado del sistema
Logs
Recursos
Red
Servicio

La consistencia evita errores.

Errores comunes (resumen)¶

Errores más repetidos:

Trabajar como root
No mirar logs
Usar 777
Matar procesos sin analizar
Cambiar muchas cosas a la vez
No documentar
Actuar con prisas

Consejo clave: la calma es una herramienta técnica.

Ejercicios prácticos¶

1. Simular mal hábito¶

Ejecuta:

sudo su -

Y pregúntate:
¿realmente necesito estar aquí?

2. Resolver sin reiniciar¶

Elige un servicio y diagnostica sin reiniciar:

systemctl status servicio
journalctl -u servicio -e

3. Documentar una solución¶

Crea una nota simple con:

PROBLEMA:
SOLUCIÓN:

Aunque sea ficticia.

Mentalidad¶

Un buen sysadmin:

Aprende de errores pasados
No repite errores conocidos
Prioriza método sobre ego
Prefiere entender antes que “arreglar”
Sabe que producción no es laboratorio

Los errores son inevitables. Repetirlos no.

Resumen¶

Los errores más graves son de método, no técnicos
root, logs y permisos son focos habituales
Cambiar poco y observar mucho es clave
Documentar evita repetir fallos
La experiencia se construye con errores bien entendidos

Siguiente paso¶

En el siguiente y último módulo entrarás en:

Casos reales de administración Linux 16-casos-reales.md

Donde verás:

Incidentes reales explicados paso a paso
Decisiones tomadas en producción
Qué salió mal y qué salió bien
Cómo piensa un sysadmin con experiencia