Son las 03:12. El teléfono vibra: "La API de Meteora responde lenta. Clientes quejándose desde hace unos minutos." No hay más información, nadie sabe qué ha cambiado y la persona que escribió el agregador está de vacaciones. Tienes acceso por SSH a meteo-01 y el resto depende de ti.

Esta lección es distinta de todas las anteriores. No introduce conceptos nuevos: usa todos los que has aprendido. Vas a recorrer un incidente completo, con las salidas reales de cada comando, las hipótesis que se descartan, las dos que resultan ciertas y una tercera que aparece sin buscarla y que cambia por completo la naturaleza del problema. Verás cómo la teoría del módulo 2 sobre patrones de acceso a disco se convierte en una línea de iostat, cómo la jerarquía de bloqueos del módulo 3 se convierte en un hilo colgado en /proc/<pid>/stack, y cómo el módulo 5 obliga a detener la investigación de rendimiento en seco.

Al final cerraremos el curso: un mapa de lo recorrido, los caminos que se abren y cómo seguir practicando.

1. El guion de actuación
2. Primera fase: los 60 segundos iniciales
3. Segundo hallazgo: el agregador y el patrón de acceso
4. Mitigación frente a solución de fondo
5. Tercer hallazgo: hilos en estado D que no avanzan
6. El interbloqueo, su corrección y la prueba
7. Cuarto hallazgo, inesperado: el incidente cambia de naturaleza
8. Post mortem sin culpables
9. Ejercicios finales
10. Cierre del curso

Antes de escribir un solo comando, tres decisiones. Cuestan treinta segundos y cambian el resultado del incidente.

Primera: acotar el síntoma con datos, no con impresiones. "Va lenta" no permite comprobar si algo mejora. Necesitas un número y un instante.

Compara con la línea base de un martes normal (p50=0.031 p95=0.104 p99=0.198) y ya tienes el síntoma cuantificado: el p99 se ha multiplicado por 30. Repitiendo la consulta minuto a minuto, la degradación empieza entre las 03:04 y las 03:06. Ese instante es tu ancla: todo lo que investigues se correlaciona con él.

Segunda: decidir si mitigar o investigar primero. Son objetivos en tensión. Mitigar restaura el servicio pero destruye evidencias: si reinicias meteo-api, el estado que explica el fallo desaparece. Investigar preserva las pruebas pero alarga la caída. El criterio es el impacto:

A las 03:12 la API responde, con latencia mala pero sin errores masivos. Decides investigar, con un límite de tiempo explícito: quince minutos.

Tercera: anotarlo todo con marca de tiempo. Abre un cuaderno del incidente y guarda cada salida:

Por qué esto importa tanto. Dentro de tres horas no recordarás si aqu-sz era 18 o 27, y el post mortem depende de esos números. Además, si el incidente acaba siendo de seguridad —como ocurrirá—, la bitácora se convierte en parte de la cadena de custodia de 05-04.

Ejecutas la lista de 07-03 entera, en orden, sin saltarte nada.

Qué descarta. Nada todavía, pero orienta: 28 de carga en una máquina de 8 núcleos, con la media de 1 minuto muy por encima de la de 15. El problema es reciente y está creciendo. No hubo reinicio (41 días de uptime), así que descartamos un arranque fallido.

Qué descarta. No hay muertes por OOM, no hay errores de dispositivo, no hay RAID degradado, no hay segfault. Esto elimina de golpe las tres causas catastróficas más frecuentes. La línea de recovery done a las 02:41 es de una resincronización del RAID ya terminada: podría haber sido la causa, pero acabó 24 minutos antes del síntoma. Anotada como no descartada del todo, porque toda coincidencia temporal merece revisión.

Aquí está el primer hallazgo grande. r=1 (un solo proceso listo para ejecutar) frente a b=31 (treinta y un procesos bloqueados en E/S ininterrumpible). si/so a cero: no es memoria. us+sy en torno al 6 % con wa al 89 %: no es CPU. La carga de 28 se explica íntegramente por los procesos en estado D de 02-01, que en Linux —y solo en Linux— cuentan en la carga media.

Qué descarta. El %iowait está repartido por igual entre los ocho núcleos, así que no es un núcleo saturado ni una interrupción mal distribuida (02-07). Y %steal a cero descarta al hipervisor (06-01): nadie nos está robando CPU.

Qué descartan. disponible de 6,1 GB y presión de memoria cero: la memoria queda definitivamente fuera. Las conexiones establecidas están en el rango normal. Y PSI es concluyente: io full avg10 del 71,6 % significa que en los últimos diez segundos la máquina ha pasado siete de cada diez sin poder progresar por esperar al disco, mientras que la presión de CPU es residual.

Conclusión de la primera fase, a las 03:17: el cuello de botella es la E/S de disco. Han bastado tres minutos y se han descartado con datos la CPU, la memoria, el intercambio, la red, el hipervisor y un fallo de hardware. Anótalo y sigue.

Lectura completa de esta salida, que es el corazón del diagnóstico. El ancho de banda es ridículo: 16 MB/s, algo que cualquier disco de hace veinte años daría sin despeinarse. Pero son 4.102 operaciones por segundo, y rareq-sz está clavado en 4,00 KB: peticiones del tamaño mínimo. rrqm/s es cero, es decir, el planificador de E/S (02-05) no puede fusionar nada, lo que solo ocurre cuando los bloques pedidos no son contiguos. Es la firma exacta de la lectura aleatoria.

Un RAID 1 de dos discos mecánicos da del orden de 150-200 IOPS aleatorias por disco, unas 300-400 en lectura sumando ambos porque el espejo reparte las lecturas. Estamos pidiendo más de diez veces esa capacidad. De ahí aqu-sz=27,4 —veintisiete peticiones esperando de media, la saturación de USE— y r_await=52 ms. El %util del 99,9 % es cierto pero poco informativo: lo que duele es la cola.

¿Quién lo provoca?

Qué demuestra. El agregador está leyendo casi 16 MB/s —el total del dispositivo— y acumula un iodelay enorme: es él quien satura el disco. meteo-api apenas lee, pero su iodelay de 41 indica que también está esperando, y esa espera es la latencia que sufre el usuario. Tenemos culpable y víctima.

Arrancó a las 03:00:14 por su temporizador y lleva 17 minutos corriendo, cuando normalmente tarda dos. Encaja perfectamente con el inicio del síntoma a las 03:05.

El hallazgo definitivo. El fichero de un día ocupa 17.280.000 bytes, unos 16,5 MiB, y debería caber en unos pocos extents contiguos. Tiene 5.314. Y read_bytes dice que el agregador ha leído 17,9 GB del disco para procesar un fichero de 16,5 MB: está releyendo el mismo fichero más de mil veces, o accediendo a él de forma completamente desordenada.

Por qué el patrón de acceso importa tanto, que es la teoría de 02-05 y 04-05 hecha carne. En un disco mecánico, una lectura secuencial de 16,5 MB es un solo posicionamiento del cabezal seguido de una transferencia continua: unos 0,15 segundos. Las mismas 16,5 MB leídas como 4.200 peticiones aleatorias de 4 KB son 4.200 posicionamientos de unos 10 ms cada uno: 42 segundos, casi trescientas veces más, con exactamente los mismos bytes leídos. El disco no es lento; el patrón es malo. Y la fragmentación en 5.314 extents convierte incluso una lectura "secuencial" del fichero en algo parecido a acceso aleatorio, porque los bloques lógicamente contiguos están físicamente dispersos: es la consecuencia de que el ingestor haya ido añadiendo al fichero durante 24 horas mientras el sistema de ficheros asignaba espacio donde podía.

Son las 03:24 y hay que restaurar el servicio. Distingue siempre las dos cosas.

Mitigación inmediata (minutos, reversible, no arregla la causa):

Qué hace y por qué funciona. ionice -c 3 mueve el proceso a la clase idle del planificador de E/S: sus peticiones solo se atienden cuando no hay ninguna otra pendiente. meteo-api deja de competir en igualdad de condiciones y su latencia debe caer de inmediato.

Verifica, siempre, que la mitigación funciona:

Resultado parcial. r_await baja de 52 a 11 ms, aqu-sz de 27 a 6, y el p99 de la API pasa de 6,1 s a 0,94 s. Enorme mejora… pero la línea base era 0,198 s. Sigue habiendo algo mal, y ese residuo es lo que llevará al tercer hallazgo. Anotarlo es fundamental: la trampa clásica del incidente es dar por cerrado el caso en cuanto mejora lo bastante.

Mitigación duradera, aplicando los cgroups de 06-02 desde la unidad, para que no dependa de que alguien ejecute ionice a mano:

Qué consigue. IOSchedulingClass=idle hace permanente lo del ionice; IOWeight=10 frente al IOWeight=200 de meteo-api reparte veinte a uno cuando ambos compiten; e IOReadBandwidthMax pone un techo duro traducido a io.max en el cgroup del servicio. Es el mismo mecanismo del núcleo que limita un contenedor, aplicado a un servicio nativo. Nota importante: MemoryMax=1G acota además el daño de una eventual fuga, matando solo al agregador en vez de dejar que el OOM killer elija víctima (02-04).

Solución de fondo, que no se hace a las tres de la madrugada pero se anota como acción del post mortem:

Son las 03:31. El disco ya no está saturado, pero el p99 sigue en 0,94 s, casi cinco veces la línea base. Vuelves a mirar meteo-api.

Qué revela. ps -eLo lista hilos (-L), no procesos: sin esa opción no verías nada de esto (03-02). Tres hilos están en estado D y el campo wchan —la función del núcleo en la que duermen— dice exactamente qué esperan: flock_lock_inode_wait, es decir, un bloqueo de fichero de 04-04. Y otros dos están en futex_wait_queue, esperando un mutex de espacio de usuario (03-04).

Confirmación desde el núcleo. La pila del hilo dentro del núcleo confirma que está dentro de la llamada flock() y no en otro sitio. Es la misma técnica que aprendiste en 03-06 para diagnosticar un proceso atascado en D.

El cuadro completo. /proc/locks es la tabla de bloqueos del núcleo, y aquí hay dos protagonistas: el PID 1834 (meteo-api) tiene tomado el bloqueo de la caché (cache.lock), y el PID 9127 (agregador) tiene tomado el del fichero de datos. Cada uno espera el que tiene el otro.

Y aquí está la causa raíz. La pila de usuario delata el orden real de adquisición: refrescar_cache_desde_disco() toma primero el bloqueo de la caché y después pide el del fichero. Pero la jerarquía acordada en 03-06 para todo el sistema es:

configuración → caché → fichero → registro

Un momento: ese código respeta la jerarquía (caché antes que fichero). El que la viola es el otro extremo. Mirando el agregador:

Confirmado: interbloqueo por violación de la jerarquía. El agregador tomó primero el bloqueo del fichero y ahora pide el de la caché; meteo-api tomó el de la caché y pide el del fichero. Es el ciclo de espera circular, la cuarta condición de Coffman, en su forma más pura y con solo dos participantes. gdb -batch con -ex 'thread apply all bt' es no destructivo si se usa con cuidado, pero detiene el proceso mientras se ejecuta: úsalo brevemente y sabiendo que añades latencia.

Nota importante sobre por qué no se había visto antes: con el agregador terminando en dos minutos, la ventana de solape era mínima. Al alargarse a 17 minutos por la saturación de disco, la probabilidad de coincidencia se disparó. El primer problema destapó el segundo, que llevaba meses latente. Es un patrón habitual: los interbloqueos raros se vuelven frecuentes cuando algo ralentiza el sistema.

Mitigación inmediata, porque el ciclo no se rompe solo:

Por qué matar al agregador y no a meteo-api. Es la recuperación por terminación de 03-06, eligiendo la víctima con dos criterios: el agregador es reejecutable —su temporizador volverá a lanzarlo, y con Persistent=true no se pierde la ejecución— mientras que reiniciar meteo-api cortaría 1.188 conexiones establecidas. Además, SIGTERM en lugar de SIGKILL le da la oportunidad de cerrar limpiamente, evitando exactamente los ficheros truncados que detectaría la comprobación tam % 24 != 0 de 07-01.

Servicio restaurado a las 03:44: p99 de 0,204 s, indistinguible de la línea base de 0,198 s. Y ahora, la corrección de fondo, que es de código:

Y la prueba de que ya no ocurre, que es la parte que casi todo el mundo se salta:

Por qué así. La primera prueba reproduce el escenario que en producción era raro; si el interbloqueo persistiera, aparecería en unos pocos intentos. La segunda es una comprobación continua barata que puede convertirse en métrica. La tercera es la más valiosa a largo plazo: centralizar toda adquisición de bloqueos en un único módulo que los tome siempre en el orden de la jerarquía convierte la disciplina en algo que el compilador y una regla de revisión pueden vigilar, en lugar de depender de que cada programador recuerde el acuerdo. Es la prevención de 03-06 llevada a la práctica.

Son las 03:52. El servicio está bien y estás reuniendo material para el post mortem. Revisas si el agregador dejó restos:

Te detienes. Ese fichero tiene el bit setuid (rws), pertenece a root, tiene nombre oculto y fecha de las 02:51. Nada del sistema de Meteora crea eso. Y entonces compruebas la otra cosa que te había extrañado:

Hay un hueco de once minutos (02:47-02:58) en un registro que escribe miles de líneas por minuto. Un servicio que estuviera bloqueado dejaría menos líneas, no cero. Un hueco exacto y limpio en un fichero de registro es, hasta que se demuestre lo contrario, manipulación.

Aquí el incidente deja de ser de rendimiento. Dos indicadores independientes —un binario setuid de root aparecido a las 02:51 en /tmp y un hueco en los registros que lo rodea— apuntan a un posible compromiso. A partir de este punto, todo lo que has aprendido en el módulo 7 se subordina a lo del módulo 5.

Lo primero es lo que NO se hace:

• No ejecutes el binario, ni siquiera con --help o en una máquina "de pruebas". Es setuid de root.
• No lo borres. Es la prueba principal.
• No reinicies la máquina. Perderías toda la memoria, las conexiones y los procesos, que es justo lo más valioso.
• No sigas "investigando el rendimiento". Cada comando que ejecutas modifica tiempos de acceso, entradas del diario e historial de shell, y contamina la escena.
• No avises por el canal que podría estar comprometido. Si el atacante tiene acceso, leerá tus mensajes.

Preservar por orden de volatilidad (05-04), de lo más efímero a lo más duradero:

Qué aporta cada uno. stat da los tres tiempos del inodo sin abrir el fichero. El hash SHA-256 permite demostrar después que la evidencia no se alteró: es el fundamento técnico de la cadena de custodia. last -F muestra los inicios de sesión con fecha completa. ausearch consulta a auditd —si estaba activo, y por eso se instala antes de necesitarlo— por las ejecuciones de esa ventana. Y el find busca otros ficheros setuid recientes en todo el sistema, porque un atacante rara vez deja uno solo.

Contener sin destruir, en este orden:

1. Aislar la red manteniendo la máquina encendida: reglas nftables que solo permitan tu acceso de administración. Apagarla destruye la memoria; desconectarla del todo también puede alertar al atacante.
2. No cambiar credenciales todavía si eso avisara al intruso, salvo indicación de quien coordine la respuesta.
3. Escalar de inmediato: responsable de seguridad, propietario del servicio, dirección, y asesoría jurídica y de cumplimiento. Si hubo acceso a datos personales, en la UE el RGPD marca plazos de notificación de 72 horas que empiezan a correr desde el conocimiento del hecho, y esa decisión no la toma quien está en la consola a las cuatro de la mañana.
4. Cambiar a un canal de comunicación fuera de banda y documentar quién sabe qué y desde cuándo.

Advertencia expresa. Este relato es material didáctico. Una respuesta a incidentes real debe seguir el procedimiento formal de tu organización y contar con asesoramiento legal. Las decisiones sobre preservación de pruebas, notificación a autoridades y clientes, comunicación pública y eventual denuncia tienen consecuencias jurídicas y contractuales que exceden lo técnico. Si tu organización no tiene ese procedimiento escrito, redactarlo antes del próximo incidente es más valioso que cualquier herramienta.

Y por qué se detiene aquí la investigación de rendimiento. Por tres razones sólidas. Primera, contaminación de evidencias: cada comando altera la escena y puede inutilizar el análisis forense. Segunda, cambio de prioridad: una latencia alta cuesta dinero, un compromiso puede costar los datos de miles de personas. Y tercera, cambio de hipótesis: si hay un intruso, todo lo diagnosticado se vuelve sospechoso —¿el agregador se ralentizó solo, o alguien lo forzó?, ¿el hueco del registro tapa el momento en que se colocó el binario?—. No sabes si el rendimiento fue la causa, la consecuencia o la cortina de humo. Investigar rendimiento sobre un sistema posiblemente comprometido es construir sobre arena.

Un post mortem sin culpables (blameless) parte de una premisa demostrada: las personas actúan razonablemente con la información que tienen en el momento. Si el objetivo es señalar a alguien, la gente oculta información y el mismo fallo vuelve a ocurrir. Si el objetivo es entender el sistema, se aprende.

Cronología (todas las horas en CEST del 31/08/2026):

Causa raíz frente a causas contribuyentes. La distinción no es académica: determina en qué se invierte el esfuerzo.

• Causa raíz de la degradación: el agregador lee los datos con un patrón aleatorio de 4 KB —releyendo 17,9 GB para procesar 16,5 MB— sobre ficheros fragmentados en más de 5.000 extents, lo que excede en un orden de magnitud la capacidad de IOPS del RAID 1.
• Contribuyente 1: no había límites de E/S en la unidad del agregador, así que podía consumir el 100 % del disco compitiendo de igual a igual con el servicio de cara al usuario.
• Contribuyente 2: el agregador viola la jerarquía de bloqueos acordada. Latente durante meses, se manifestó al alargarse su ejecución. No fue la causa, pero sin él el servicio habría vuelto a la normalidad en el minuto 12 en lugar del 32.
• Contribuyente 3: no había alerta sobre presión de E/S. El aviso llegó de los clientes, no del sistema, con siete minutos de retraso.
• Contribuyente 4: /tmp estaba montado sin noexec ni nosuid, lo que permitió que un binario setuid fuera ejecutable ahí.
• Contribuyente 5: los registros solo estaban en la máquina, por lo que el hueco no se puede contrastar con ninguna copia externa.

Acciones preventivas concretas, cada una con dueño y plazo:

Fíjate en el patrón: ninguna acción es "tener más cuidado". Todas son cambios en el sistema —límites, alertas, montajes, estructura de código— que hacen que el fallo sea imposible o que se detecte solo. Ese es el criterio para saber si un post mortem ha servido de algo.

Consejos finales para el turno de guardia: empieza siempre por dmesg; cuantifica antes de tocar y vuelve a medir después; pon un límite de tiempo a la fase de investigación y respétalo; avisa pronto aunque no tengas la respuesta, porque la gente tolera mucho mejor la incertidumbre comunicada que el silencio; y desconfía de la primera explicación que encaja, porque los incidentes reales, como este, suelen tener más de una causa.

Cada noche entre las 02:00 y las 04:00, meteo-api deja de responder unos segundos. systemctl status dice active (running) cuando lo miras por la mañana, pero Main PID ha cambiado. Datos recogidos:

Diagnostica con el método de 07-03: quién causó el problema, por qué murió quien murió, y qué mitigación y qué solución de fondo aplicarías.

Tras editar /etc/meteora/meteora.conf para añadir una ruta de caché nueva, meteo-api no arranca:

Ejecutado a mano como meteora, el binario arranca sin problemas. Explica la contradicción y da la solución correcta, además de dos incorrectas que hay que evitar y por qué.

Solución 1

Diagnóstico. Los indicadores son inequívocos y ninguno es de E/S: disponible de solo 402 MB, si=1.204 y so=1.890 páginas por segundo simultáneamente —el sistema mete y saca páginas a la vez, que es la definición de thrashing (02-04)— y una presión de memoria del 58 % (some) con 31 % de full: casi un tercio del tiempo la máquina entera no progresa.

Quién causó el problema y quién murió no son el mismo. La primera línea de dmesg lo dice literalmente: agregador invoked oom-killer, es decir, fue la petición de memoria del agregador la que agotó el sistema y disparó el mecanismo. Pero el elegido fue meteo-api, con 2,9 GB de anon-rss. La razón está en el oom_score, que es esencialmente proporcional a la memoria residente: el OOM killer mata al proceso más grande, no al culpable. Y como meteo-api corre bajo systemd con Restart=on-failure, se reinicia solo, lo que explica el active (running) con un Main PID distinto por la mañana y el hecho de que nadie se enterase.

La ventana 02:00-04:00 coincide con las ejecuciones nocturnas del agregador; el mecanismo es una acumulación de memoria en el proceso de agregación —probablemente carga en RAM todo el histórico en lugar de procesarlo por bloques.

Mitigación (esta noche, sin tocar código):

Con esto, cuando el agregador supere 1 GB, el OOM killer del cgroup lo matará a él y solo a él, sin tocar el resto del sistema; MemoryHigh añade un escalón previo en el que el núcleo lo frena y reclama páginas agresivamente antes de llegar al límite duro. Es exactamente el mecanismo de 06-02. Conviene además proteger a la víctima con MemoryMin=512M en meteo-api.service, que reserva memoria que el núcleo no le reclamará.

Solución de fondo: procesar el histórico por bloques con un consumo acotado y constante, en lugar de cargarlo entero. Y verificación: seguir el RSS del agregador durante una ejecución (while true; do awk '/VmRSS/{print $2}' /proc/$(pgrep -x agregador)/status; sleep 10; done) para comprobar que se estabiliza en lugar de crecer linealmente. Alerta preventiva: memory some avg60 > 20 % durante 5 minutos, que habría avisado semanas antes que el primer cliente.

Lo que no hay que hacer: bajar vm.swappiness (no falta menos swap, falta memoria), añadir RAM sin entender el crecimiento (solo retrasa el problema), ni ajustar oom_score_adj de meteo-api para que no lo elijan (moverías la muerte a otro proceso inocente).

Solución 2

La contradicción es aparente y su explicación es el endurecimiento de la unidad. A mano, el binario corre con el sistema de ficheros normal y meteora puede escribir donde sus permisos le dejen. Bajo systemd, la unidad tiene ProtectSystem=strict, que monta todo el árbol del sistema en solo lectura dentro del espacio de nombres de montaje del servicio, con las únicas excepciones declaradas en ReadWritePaths=: /var/lib/meteora, /var/log/meteora y /run/meteora. La ruta nueva, /var/cache/meteora, no está en esa lista, así que el proceso ve un sistema de ficheros de solo lectura y falla con EROFS. Es el mecanismo de aislamiento de 05-03 funcionando exactamente como debe.

Solución correcta, que además delega en systemd la creación del directorio con el propietario y modo adecuados:

CacheDirectory=meteora crea /var/cache/meteora con dueño meteora:meteora, lo añade automáticamente a las rutas escribibles y lo gestiona en el ciclo de vida del servicio. La alternativa aceptable, si el directorio ya existe y lo gestiona otro proceso, es añadir ReadWritePaths=/var/cache/meteora.

Dos soluciones incorrectas y por qué:

1. Quitar ProtectSystem=strict. Resuelve el síntoma desarmando la protección: el servicio pasa a poder escribir en todo el sistema, incluidos /etc y /usr. Cambias un problema de configuración de cinco líneas por un aumento permanente de la superficie de ataque, justo en el servicio expuesto a Internet. La puntuación de systemd-analyze security lo reflejaría de inmediato.
2. Ejecutar el servicio como root (o darle chmod 777 al directorio). Tira por la borda toda la cadena de decisiones del curso: la cuenta sin shell, el UID 990, CAP_NET_BIND_SERVICE en lugar de root, NoNewPrivileges. Y 777 permitiría a cualquier usuario del sistema —incluido un proceso comprometido— manipular la caché del servicio.

Lección general: cuando un servicio funciona a mano y falla bajo systemd, la diferencia está casi siempre en el entorno (PATH, directorio de trabajo, variables) o en el endurecimiento (ProtectSystem, ReadWritePaths, SystemCallFilter, capabilities). Y la respuesta correcta es casi siempre declarar la excepción concreta, nunca desactivar la protección.

Has resuelto un incidente completo, y al hacerlo has usado el curso entero. Merece la pena ver el mapa, porque cada pieza teórica ha acabado convertida en una herramienta de diagnóstico.

Del módulo 1 venía la idea de que el sistema operativo es una máquina extendida y un gestor de recursos, y que todo pasa por llamadas al sistema; sin eso, strace, wchan y /proc/<pid>/stack serían magia. Del módulo 2 salieron los estados de proceso —D y su peso en la carga media—, los patrones de acceso a disco que explican por qué 16,5 MB pueden tardar 42 segundos, el OOM killer eligiendo por tamaño y no por culpa, y RSS frente a VSZ para detectar una fuga. Del módulo 3 vinieron los hilos, flock, el futex y, sobre todo, la jerarquía de bloqueos cuya violación produjo el interbloqueo y cuya centralización lo previene. Del módulo 4, los inodos y /proc/locks, la fragmentación en extents que filefrag reveló, y la escritura atómica que evita ficheros truncados. Del módulo 5, todo lo que ocurrió a partir de las 03:52: el binario setuid, el hueco en el registro, el orden de volatilidad, la cadena de custodia, noexec en /tmp y la obligación de escalar. Del módulo 6, los cgroups que limitaron el agregador con io.max y MemoryMax. Y del módulo 7, la shell que lo ejecutó todo, systemd que lo gobierna y el método que ordenó la investigación.

Ese es el mensaje central del curso: la teoría no es un peaje previo a la práctica, es lo que permite interpretar lo que ves. Dos personas ejecutan iostat -x y ven los mismos números; solo una sabe que rareq-sz de 4 KB con rrqm/s a cero significa acceso aleatorio, que la cola importa más que la utilización y que un RAID 1 duplica lecturas pero no escrituras. La diferencia no está en el comando, sino en los módulos 2 y 4.

Los caminos que se abren desde aquí:

Todos comparten la misma base: la que acabas de terminar.

Cómo seguir practicando, que es lo único que consolida esto:

• Monta una máquina virtual de laboratorio y rómpela a propósito. Provoca un OOM, satura el disco con fio, crea un interbloqueo con dos scripts y flock, borra un fichero de unidad y arréglalo. Nada enseña como reparar algo que has roto tú.
• Lee /proc con curiosidad. Cada fichero de /proc/<pid>/ es una ventana a una estructura del núcleo. Dedica una tarde a recorrer status, maps, io, limits, stack, fd/ y environ de un proceso real: entenderás más que con muchos capítulos.
• Reproduce los ejercicios del curso en tu propia máquina, cambiando los números. Los del módulo 3 y los laboratorios de 07-03 son los que más rinden.
• Lee registros aunque no pase nada. Familiarizarte con el aspecto de un journalctl normal es lo que te permitirá detectar lo anormal en tres segundos.
• Escribe tus propios post mortem, aunque el incidente sea doméstico y tú el único lector. Poner por escrito la cronología y la causa raíz es lo que convierte una experiencia en conocimiento.

Empezamos definiendo el sistema operativo como una máquina extendida que oculta la complejidad del hardware. Terminamos a las cuatro de la mañana en un servidor de verdad, leyendo esa complejidad a través de las ventanas que el propio sistema nos ofrece: /proc, el diario, los contadores del núcleo. Entre un punto y otro hay siete módulos, pero en realidad hay una sola idea repetida: el sistema operativo no es una caja negra. Es un programa, escrito por personas, que toma decisiones comprensibles sobre recursos limitados, y que deja rastro de todas ellas. Aprender a leer ese rastro es lo que separa a quien usa un ordenador de quien lo entiende.

Ya sabes hacerlo. La próxima vez que el teléfono suene a las tres de la madrugada, no sabrás la respuesta —nadie la sabe—, pero sabrás cómo encontrarla: cuantificar el síntoma, descartar con datos, buscar la saturación y no la utilización, desconfiar de la primera explicación que encaje y anotarlo todo para que la siguiente persona lo tenga más fácil.

Gracias por llegar hasta aquí. Ahora apaga esto, abre una terminal y rompe algo.