No se detenga en el primer fallo.
El primer fallo que encuentra casi nunca es el único. Nuestro método para desenredar un colapso con varias causas: ordenar las causas por contribución y no por ruido, leer las fuentes primarias a nivel de kernel en lugar de los dashboards, pelar un fallo cada vez, y tratar cualquier síntoma que vuelve como un diagnóstico completamente nuevo.
En este artículo 6 secciones
- En un colapso con varios fallos, varios de ellos llevan el mismo síntoma a la vez. Corregir el más ruidoso parece un avance y cambia casi nada.
- El método: ordene las causas por contribución, no por ruido. Corrija en ese orden. Vuelva a medir en el límite que falló después de cada cambio, sin excepción.
- Cuando una corrección se mantiene y el síntoma vuelve, no vuelva a aplicar la corrección. Diagnostique otra vez desde cero. El mismo síntoma no es la misma causa.
- La recuperación también tiene un orden: detenga primero el desencadenante inmediato, pruebe el estado antes de cualquier movimiento destructivo, mantenga cada paso reversible.
Su sitio se cae. Alguien encuentra un fallo plausible, lo corrige y canta victoria. El sitio sigue caído, o vuelve y se cae otra vez con el siguiente desencadenante. La corrección se detuvo en el primer fallo, y en los peores días hay cuatro más detrás. Esta es la disciplina que no se detiene.
Regla uno: ordene por contribución, no por ruido
El síntoma más ruidoso es una pésima clave de ordenación. Ejemplo: el kernel grita contención de E/S de disco, pero el motor de la cascada es un resolver atascado que retiene a todos los workers, y el mayor impulsor continuo es una tormenta de ficheros de sesión que ninguna primera teoría incluía. Ordene las causas por la parte del colapso que les corresponde, y corrija en ese orden.
- Contención de E/S de disco (el síntoma ruidoso)
- El job del que todos sospechan
- El resolver del que nadie sospecha
- El resolver: el motor
- La tormenta de sesiones: el mayor impulsor
- El job: real, pero no el impulsor
Regla dos: lea fuentes primarias, no dashboards
Los dashboards resumen. Los kernels testifican. Cuando las capas no coinciden, gana el kernel. La primera pasada canónica sobre cualquier máquina Linux bloqueada es la misma lista corta cada vez, y después una heurística que merece enmarcarse: margen disponible y sitio caído significa un fallo de aplicación o de dependencia, no de capacidad. Un disco a fracciones de un uno por ciento de utilización mientras los workers se cuelgan es contención de locks, no E/S, diga lo que diga la gráfica.
# the canonical first pass on a wedged Linux box
dmesg -T | tail -50 # OOM kills, hung tasks, hardware complaints
journalctl --list-boots # did this box reboot when you think it did?
last -x reboot | head # corroborate the reboot story
cat /etc/resolv.conf # who does this box think answers DNS?
iostat -x 5 3 # is the disk actually busy, or just blamed?
cat /proc/<pid>/stack # where exactly is that worker stuck?
strace -p <pid> -c -f # a few seconds: is it even making syscalls?Diez minutos de fuentes primarias valen más que una tarde de arqueología de dashboards.
Regla tres: pele un fallo cada vez
Un cambio, después volver a medir en el límite que falló, antes de tocar la siguiente capa. La disciplina parece lenta y es lo más rápido que existe, porque dos cambios simultáneos que interactúan no le dicen nada sobre ninguno de los dos. La verificación es por capa: corrija el resolver, pruebe la resolución de nombres en la máquina; despeje la tormenta, pruebe los estados de los workers; después suba.
Regla cuatro: desconfíe del momento «ya lo hemos arreglado»
Cuando una corrección se mantiene y el síntoma vuelve horas después, el reflejo es volver a aplicar la corrección con más fuerza. Vuelva a medir en su lugar. La pregunta que hay que hacer es la sencilla: ¿cómo sabe que está haciendo E/S? Unos segundos de strace que no capturan ninguna llamada al sistema significan que los workers están bloqueados en el kernel sobre un lock, sin hacer E/S en absoluto, y así es como se encuentra el impulsor real en lugar de taparlo. Cuando un síntoma vuelve después de una corrección auténtica, es un fallo distinto con la misma ropa.
Reglas cinco a siete: la recuperación también tiene un orden
Detenga el desencadenante inmediato antes de tocar la causa.
Si un sondeo de monitorización es lo que está tirando un clúster, detenga primero el sondeo, recupere la posición, elimine la causa, y solo entonces aplique el cambio planificado a un clúster sano.
Pruebe el estado antes de cualquier movimiento destructivo.
Un volumen marcado como corrupto recibe una comprobación de integridad de solo lectura antes de que nadie borre una marca o eche mano de un restore. La propia recuperación tiene trampas. Conózcalas antes de dar el paso.
Mantenga cada paso reversible.
Backup antes de tocar. Apartar, no borrar. Recargar, no reiniciar, bajo carga. El movimiento de pánico que no se puede deshacer nunca es el movimiento.
Regla ocho: cierre el agujero para todos
Cada nuevo patrón de fallo se convierte en una comprobación previa con nombre en la configuración de referencia. El método no es solo la forma de desenredar una mala mañana. Es la forma de evitar que la misma mañana se repita en cualquier otro sitio.
Respuestas directas
¿Por qué el problema de mi servidor vuelve después de cada corrección?+
Porque el incidente tiene más de una causa y cada corrección abordó una. Cuando una corrección se mantiene y el síntoma vuelve, diagnostique otra vez desde los primeros principios. El mismo síntoma no es la misma causa.
¿Cómo encuentro la causa raíz real de una carga alta en el servidor?+
Primero las fuentes primarias: dmesg para OOM y tareas colgadas, iostat para comprobar si el disco está realmente ocupado, la pila de un proceso o unos segundos de traza para ver dónde están atascados los workers. Ordene lo que encuentre por su contribución al colapso, no por lo ruidoso que parezca.
¿Qué significa que la carga sea alta pero el disco esté inactivo?+
Normalmente contención de locks o una dependencia atascada, no capacidad. Margen disponible mientras el sitio está caído apunta a un fallo de aplicación o de dependencia, y añadir recursos no cambia nada.
¿Debo reiniciar un servicio que se cae para arreglarlo?+
No mientras el desencadenante siga activo. Si algo lo está matando una y otra vez, un reinicio vuelve a ejecutar la caída. Detenga primero el desencadenante inmediato, después elimine la causa, después reinicie hacia un estado sano.
¿Cuál es un buen método de post-mortem de incidentes?+
Enumere cada fallo que contribuyó, no solo el primero. Ordene por contribución. Anote la pista que delató cada uno. Y convierta cada agujero en una comprobación previa permanente para que no pueda volver a alinearse. Si un post-mortem tiene exactamente una causa para un colapso total, léalo dos veces.
¿Una segunda opinión sobre un incidente que no cede?
Si sigue volviendo, tiene más causas de las que encontró el último informe. Tráiganos el historial del síntoma; nosotros traemos el método.
Hable con un ingenieroHa llegado al final.
Ponga la lectura a trabajar
¿Qué está ejecutando?
Cuéntenos la carga de trabajo, el tráfico y los requisitos de recuperación. Empiece por el configurador de servidores o repase los detalles con un ingeniero.
Escrito por los ingenieros que construyen y operan la infraestructura que describe.Hable con un ingeniero