Cincuenta y cinco lecciones. srv-tramontana está instalado, endurecido, monitorizable, respaldado, automatizado, cifrado en tránsito y con una base de datos que ya no corre con la configuración de fábrica. Sabes reconstruirlo en cincuenta minutos, recuperar la base de datos a un segundo concreto, diagnosticar una latencia con eBPF y decidir con números si hace falta alta disponibilidad.

Y aun así falta algo, porque «funciona» y «está en producción» no son lo mismo. Un sistema en producción es aquel del que otras personas dependen sin saber que existe: tiene un dueño, un objetivo de servicio acordado, alguien que lo mira cada mañana, alertas que se atienden, un procedimiento cuando se rompe y un registro de por qué está como está. Nada de eso es software; todo eso es operación.

Esta lección cierra el curso poniendo esa capa. La checklist completa con su evidencia, la monitorización con Prometheus y Grafana que quedó aplazada desde 05-07, alertas que se puedan atender sin odiarlas, la rutina diaria, la revisión post-incidente sin culpables, y el presupuesto de error que convierte el 99,8 % de 07-07 en una decisión ejecutable. Y las tres deudas que siguen abiertas desde el Módulo 5, que se cierran hoy.

1. Qué significa estar en producción
2. La checklist de puesta en producción
3. Monitorizar y alertar: no son lo mismo
4. Prometheus y node_exporter
5. PromQL de lo imprescindible
6. Métricas propias: las que ya tienes sin saberlo
7. Grafana y el panel mínimo
8. Alertas que se pueden atender
9. Registros centralizados: la deuda de 05-06
10. Operación diaria, semanal y mensual
11. El cuaderno de guardia y el registro de cambios
12. La revisión post-incidente sin culpables
13. Gestión del cambio y ventanas de despliegue
14. SLI, SLO y presupuesto de error
15. Cierre de las deudas pendientes
16. Cumplimiento: RGPD y retención de datos
17. Cierre del curso

La última fila es la que resume la lección. La diferencia entre un sistema aficionado y uno profesional no es la tecnología: es que ante «¿va bien?» hay un dato, no una impresión.

Y hay una prueba práctica, más útil que cualquier definición:

¿Podrías irte dos semanas de vacaciones sin ordenador?

Para responder que sí hacen falta seis cosas: que el sistema se autorrepare en los fallos previstos, que alguien reciba las alertas, que ese alguien tenga procedimientos escritos que pueda seguir sin ser tú, que las copias se verifiquen solas, que haya un camino de escalado, y que exista un registro de qué se ha cambiado y por qué. Esta lección construye las seis.

Cada fila lleva evidencia comprobable: un comando que devuelve un resultado, no una casilla de conciencia. Sin evidencia, una checklist es una lista de buenas intenciones.

Resumen: 30 filas cumplidas de 42. Nueve se cierran en esta lección; tres quedan como trabajo planificado con fecha. Esa cifra es en sí misma la evidencia número 43: saber exactamente qué falta.

Es la distinción que evita el error más caro de esta área.

Monitoriza todo lo que puedas; alerta de casi nada. Es contraintuitivo y es la única forma de que las alertas sirvan. Un sistema que envía cuarenta notificaciones al día es un sistema sin alertas, porque nadie las lee.

De 05-07, ahora con instrumentación real:

Dos matices que hacen la diferencia entre medir y medir bien:

La latencia se mide en percentiles, nunca en media. Una media de 80 ms puede esconder que el 1 % de los usuarios espera 4 segundos. Y hay que separar la latencia de las peticiones correctas de la de las erróneas: un error 500 devuelto en 2 ms mejora la media y empeora el servicio.

La latencia de los errores se excluye del SLI. Si no, una caída total —donde todo falla rápido— aparecería como una mejora de rendimiento.

Y el método USE, complementario, para cada recurso: Utilización, Saturación y Errores.

Prometheus es una base de datos de series temporales que recolecta métricas: en lugar de que los servicios le envíen datos, él los pide periódicamente a extremos HTTP.

Esa segunda fila es una ventaja enorme: con recolección, un servicio caído produce inmediatamente up == 0, que es una señal explícita.

Las unidades del paquete son razonables pero no cumplen el estándar del curso. Drop-ins, como siempre:

promtool check config es el nginx -t de Prometheus, y se usa igual: siempre antes de recargar.

Sobre la retención y el disco, que es la pregunta que siempre surge:

Treinta días bastan para investigar incidentes y ver tendencias mensuales. Para histórico de años existen Thanos o Mimir, y para Tramontana son innecesarios.

PromQL asusta al principio y se reduce a cinco patrones que cubren el 90 % de los casos.

1. up: lo más importante y lo más simple.

2. rate() sobre contadores. Un contador solo sube. Su valor absoluto no dice nada; lo que importa es a qué ritmo crece.

rate() maneja correctamente los reinicios: si el contador vuelve a cero porque el proceso se reinició, lo detecta y no produce un valor negativo absurdo.

Regla: rate() solo sobre contadores (_total). Para medidores —memoria, temperatura, conexiones— se usa el valor directamente.

3. Agregaciones y proporciones.

4. histogram_quantile(): los percentiles de latencia.

La etiqueta le (less or equal) define los cubos del histograma y debe conservarse en el by. Es el error más común de PromQL: agregar sin by (le) y obtener resultados sin sentido.

5. Predicción, que es lo que convierte una alerta en útil.

Alertar de «disco al 90 %» es alertar tarde o alertar en vano —un disco estable al 91 % no es un problema—. Alertar de «a este ritmo se llena en cuatro horas» es accionable, que es la propiedad que define una buena alerta.

Los node_exporter y compañía dan métricas técnicas. Las que de verdad importan son las que responden a preguntas del negocio, y la mayoría ya las estás calculando en los scripts del curso — solo hay que exponerlas.

El mecanismo es el recolector de ficheros de texto: cualquier script deja un .prom en un directorio y node_exporter lo publica.

Cuatro decisiones de diseño del script:

1. Escritura atómica con mktemp y mv. node_exporter puede leer el fichero en cualquier momento; uno truncado hace que descarte todo su contenido.
2. umask 022, en contra de la convención general del curso: node_exporter corre como otro usuario y necesita leerlo. Es una excepción justificada, y por eso está comentada.
3. La métrica 8, la marca de frescura, es la que hace fiables a las otras siete. Sin ella, si este script deja de ejecutarse, Prometheus seguiría publicando los últimos valores conocidos indefinidamente y todo parecería correcto para siempre. Con ella se puede alertar de que las métricas están rancias.
4. La métrica de negocio, tramontana_reservas_total, es la que a Marta le importa y la que detecta el fallo más peligroso: el que no rompe nada. Si el sistema responde 200 a todo pero nadie consigue reservar, ninguna métrica técnica lo revelará.

Y para la aplicación, lo que Luis debe exponer en /metrics:

Y el acceso, aprovechando lo montado: por la VPN de 08-04, sin publicar nada nuevo.

El panel mínimo, seis paneles y ni uno más:

Un consejo que contradice el instinto: un panel con cuarenta gráficas no se mira. El panel principal debe caber en una pantalla y responder en tres segundos a «¿va bien?». El detalle vive en paneles secundarios a los que se llega cuando hace falta.

Toda alerta debe requerir una acción humana inmediata. Si el receptor no puede hacer nada, o puede esperar a mañana, no es una alerta: es un panel o un informe.

La fatiga de alertas es el modo de fallo característico de la monitorización, y su progresión es siempre la misma:

1. Se configuran alertas para todo, «por si acaso».
2. Llegan diez al día, casi todas irrelevantes.
3. La gente empieza a ignorarlas.
4. Se crea un filtro de correo que las archiva.
5. Llega la alerta importante y nadie la ve.

El sistema queda peor que sin alertas, porque hay una falsa sensación de vigilancia. Y el remedio es contraintuitivo: borrar alertas.

Regla: alerta de síntomas, diagnostica con causas. Un for: 5m sobre la tasa de errores detecta cualquier fallo que afecte al usuario, incluidos los que nadie anticipó. Una alerta de CPU al 90 % dispara cuando se ejecuta la copia nocturna y el servicio va perfectamente.

Con dos excepciones legítimas, que son alertas de causa y deben existir porque su síntoma llega demasiado tarde:

• El disco se va a llenar. Cuando el síntoma aparece, el servicio ya está caído.
• El certificado va a caducar. Cuando el síntoma aparece, la web ya no carga.

Ambas comparten la propiedad clave: avisan con horas o días de antelación y la acción es evidente.

Las inhibit_rules merecen atención: cuando el servicio cae, se dispararían también las alertas de latencia, de errores y de conexiones a la base de datos. Recibir cinco notificaciones del mismo incidente es fatiga de alertas en su forma más pura. La inhibición envía una: la causa.

Y el silencio programado durante el mantenimiento, sin el cual la ventana de despliegue genera una avalancha de notificaciones:

Los silencios se ponen con caducidad, siempre. Un silencio indefinido puesto un martes es una alerta que no volverá a sonar nunca, y nadie se acordará.

En 05-06 quedó una pieza pendiente: el journal es persistente y local. Con un solo servidor funciona; en cuanto hay dos —los nodos de aplicación de 07-07, el balanceador, la réplica— diagnosticar exige entrar en cada máquina y correlacionar a mano.

Por qué hace falta centralizar:

Esa segunda fila es de seguridad pura y enlaza con 06-04: si los registros solo viven en la máquina atacada, el atacante los edita. Es el mismo razonamiento por el que la base de datos de AIDE vive fuera del servidor.

Loki como opción ligera:

Loki es la elección para Tramontana por dos razones: no indexa el texto completo —que es lo que hace a Elasticsearch caro— y comparte etiquetas y sintaxis con Prometheus, de modo que se puede saltar de una gráfica de latencia a los registros de ese mismo instante en el mismo panel. Esa correlación es lo que hace útil un sistema de registros.

Y la advertencia obligatoria: los registros contienen datos personales —IP, identificadores de usuario, a veces correos—. Centralizarlos multiplica el alcance de una fuga. Retención acotada, acceso restringido y el mismo tratamiento que la base de datos.

El cuaderno de guardia es un fichero de texto donde se anota lo que pasa. Suena trivial y es la herramienta que más tiempo ahorra en un incidente, porque responde a «¿esto ya nos había pasado?».

Cuatro reglas para que funcione:

1. Se escribe en el momento, no al final del día. Lo que se pospone no se escribe.
2. Marcas de tiempo siempre, para poder correlacionar con las gráficas.
3. Las observaciones valen tanto como los incidentes. La entrada de las 16:10 es la que explicará una alerta dentro de dos meses.
4. Vive fuera del servidor —en el repositorio de Ansible— porque hará falta precisamente cuando el servidor no esté.

El registro de cambios ya existe: es el git log de ~/tramontana-infra. La disciplina es que todo cambio de configuración pase por ahí, para que se pueda responder a «¿qué cambió antes de que empezara a fallar?».

Un incidente es un fallo del sistema, no de una persona. Si alguien pudo borrar 40.000 filas con un comando, el problema es que el sistema lo permitiera sin fricción, no que esa persona se equivocara.

Esto no es amabilidad corporativa: es la única forma de obtener información verdadera. En una cultura donde se buscan culpables, la gente oculta los errores, y entonces los incidentes se repiten porque nadie sabe que ocurrieron. La revisión sin culpables es una decisión de ingeniería.

Revisión post-incidente: borrado accidental de reservas

Incidente: INC-2026-003 · Fecha: 2026-08-18 · Severidad: Alta Duración del impacto: 34 min · Datos perdidos: ninguno Redactado por: Operaciones · Revisado con: Marta, Luis

1. Qué pasó

Durante una limpieza rutinaria de datos antiguos, se ejecutó en la base de datos de producción un DELETE cuya cláusula WHERE no era la prevista, eliminando 40.218 reservas históricas. Se detectó 19 minutos después y se recuperaron mediante recuperación a un punto en el tiempo. No hubo pérdida de datos ni interrupción del servicio.

2. Impacto

Dimensión	Impacto
Disponibilidad del servicio	Ninguno: la web siguió funcionando
Datos perdidos definitivamente	Ninguno
Datos temporalmente inaccesibles	40.218 reservas históricas, 34 min
Clientes afectados	Ninguno (datos de consulta interna)
Presupuesto de error consumido	0 %

3. Línea temporal

Hora	Suceso
14:30	Se inicia la limpieza de datos anteriores a 2024
14:32	Se ejecuta el DELETE con la condición incorrecta
14:51	Un informe devuelve cifras anómalas: se detecta
14:53	Se detiene toda escritura adicional. Se abre el incidente
14:58	Se localiza la marca temporal exacta en pg_stat_statements
15:02	Comienza la restauración PITR en srv-tramontana-pruebas
15:19	Recuperación completada y verificada en pruebas
15:24	Datos reimportados a producción con psql -1
15:26	Verificación final. Incidente cerrado

4. Causa raíz: los cinco porqués

#	Pregunta	Respuesta
1	¿Por qué se borraron 40.218 reservas?	Un DELETE con WHERE incorrecto
2	¿Por qué se ejecutó con la condición incorrecta?	Se escribió a mano, sin SELECT previo
3	¿Por qué se escribió a mano?	No existe procedimiento para limpiezas de datos
4	¿Por qué no existe?	Nunca se había hecho una limpieza masiva
5	¿Por qué hizo falta ahora?	La tabla de auditoría creció sin política de retención

Causa raíz: la ausencia de una política de retención de datos obligó a una limpieza manual improvisada, sin procedimiento ni salvaguardas.

Y una observación sobre el método: los cinco porqués atraviesan la respuesta fácil —«alguien se equivocó al teclear»— hasta llegar a una causa sistémica y accionable. Quedarse en el porqué número 2 habría producido la conclusión inútil de «hay que tener más cuidado».

5. Qué funcionó bien

Esta sección es obligatoria y se olvida siempre:

• La recuperación a un punto en el tiempo funcionó exactamente como se ensayó (RB-BD-02, 08-02). El ensayo trimestral demostró su valor a los tres días.
• La restauración en máquina aparte preservó las transacciones posteriores. Restaurar sobre producción habría perdido 19 minutos de reservas reales.
• La detección en 19 minutos fue razonable, aunque mejorable.
• Se avisó de inmediato, sin ocultarlo. Eso permitió actuar rápido.

6. Qué se cambia

#	Acción	Responsable	Fecha	Estado
1	Política de retención de auditoria acordada con Marta	Marta + Ops	25/08	Pendiente
2	Runbook de limpiezas: SELECT count(*) obligatorio antes de cualquier DELETE	Ops	22/08	En curso
3	Rol svc_limpieza con statement_timeout y sin permiso de DELETE masivo	Ops	25/08	Pendiente
4	Purga programada como timer idempotente y probado, no manual	Ops	31/08	Pendiente
5	Alerta si una tabla pierde más del 10 % de filas en 5 min	Ops	25/08	Pendiente
6	psql de producción con \set ON_ERROR_ROLLBACK off y aviso en el prompt	Ops	22/08	Hecho

Ninguna acción es «tener más cuidado». Una acción correctiva que depende de la atención humana no es una acción correctiva: es una expresión de deseo.

7. Lecciones

1. Los ensayos de recuperación se pagan solos. El de 08-02 se hizo el día 15; el día 18 hizo falta de verdad, y nadie tuvo que improvisar.
2. Una tabla que crece sin política de retención acaba forzando una operación arriesgada. El crecimiento silencioso es una deuda que se cobra de golpe.
3. Detectar en 19 minutos es mucho para un borrado masivo. La acción 5 lo bajará a menos de 5.

La mayoría de las interrupciones no vienen de fallos de hardware: vienen de cambios. Y sin embargo el cambio es necesario. Gestionarlo es ponerle fricción proporcional al riesgo, no impedirlo.

La ventana de Tramontana: martes y miércoles, de 10:00 a 12:00. Y las razones de por qué no se despliega el viernes por la tarde, que es la regla más famosa del sector:

1. Los problemas aparecen con carga real, horas después. Un viernes a las 18:00, esa carga llega el lunes.
2. La gente se va. Si algo falla a las 20:00 del viernes, quien lo desplegó ya no está.
3. El fin de semana es cuando más reservas se hacen en Tramontana: el peor momento posible para un fallo.
4. Un incidente el viernes se arrastra el fin de semana, con la persona de guardia trabajando en un cambio que no hizo.

La regla, formulada correctamente: no se despliega si no hay tiempo suficiente por delante para detectar y revertir el problema con el equipo disponible. El martes por la mañana cumple; el viernes por la tarde no.

Lista de verificación previa a cada despliegue:

Tres conceptos que se confunden y son distintos:

El SLO se pone siempre más exigente que el SLA, para tener margen antes de incumplir el contrato.

Recogiendo el 99,8 % propuesto en 07-07 y convirtiéndolo en números concretos:

SLI: proporción de peticiones HTTP a reservas.tramontana.example respondidas con código < 500 y en menos de 2 segundos.

SLO: ≥ 99,8 % de esas peticiones, medido en ventana móvil de 30 días.

Aquí está la idea que cambia la forma de trabajar:

Presupuesto de error = 100 % − SLO. Es la cantidad de fallo que te puedes permitir. No es un residuo: es un recurso que se gasta.

Tramontana puede estar caída 1 h 26 min cada 30 días y seguir cumpliendo su objetivo. Ese tiempo es un presupuesto que se puede gastar deliberadamente: en despliegues arriesgados, en actualizaciones, en experimentos.

Y de ahí sale una regla de gestión que sustituye a las discusiones eternas entre «hay que ir más rápido» y «hay que ser más estables»:

31,4 % consumido: hay margen. Ese número va al panel principal, y es lo que convierte «¿desplegamos?» de una discusión de opiniones en una consulta de datos.

Lo más valioso del presupuesto de error, y suele sorprender: es tan malo agotarlo como no gastarlo. Un equipo que termina el mes con el 5 % consumido está siendo demasiado conservador — podría haber desplegado más, entregado más valor y asumido más riesgo dentro de lo acordado. La fiabilidad excesiva también tiene un coste: el de las funciones que no se hicieron.

El problema. restic sube las copias con un token que también puede borrar. Un atacante con acceso a srv-tramontana puede ejecutar restic forget --prune y destruir todo el histórico. Es exactamente el modo de operar del ransomware moderno: primero borra las copias, luego cifra los datos.

La solución: un token de solo añadir, más un restic en modo --append-only en el lado del repositorio.

El principio general, aplicable mucho más allá de esto: el sistema respaldado no debe poder destruir sus copias. Si puede, no son copias: son una réplica con retraso.

Checklist fila 23: cerrada.

Qué es. authorized_keys2 es un fichero obsoleto de OpenSSH 2.x, cuando había ficheros separados para claves SSH-1 y SSH-2. Las versiones modernas de OpenSSH lo ignoran por completo, salvo que AuthorizedKeysFile lo mencione explícitamente.

Y ahí está el problema: la configuración por defecto de Ubuntu sí lo incluye. Esa clave RSA de 2048 bits, de un proveedor con el que ya no se trabaja, da acceso al servidor hoy mismo.

Es un ejemplo perfecto de un riesgo real: no es una vulnerabilidad de software, es un fichero que nadie miró en dieciocho meses.

Y en Ansible, para que sea permanente y verificado:

La lección de método: en el inventario de accesos, un fichero que no se puede explicar es un fichero que se retira. Y el error de fondo fue no tener nunca una revisión periódica de accesos — que ahora es la fila mensual de la tabla del apartado 10.

Checklist fila 40: cerrada.

Se cierra formalizando lo propuesto en 07-07:

Acuerdo de nivel de servicio interno · Tramontana Reservas Acordado el 18/08/2026 entre Operaciones y Dirección (Marta Vidal). Revisión: agosto de 2027.

Concepto	Valor
SLI	Peticiones con código < 500 y latencia < 2 s
SLO	99,8 % en ventana móvil de 30 días
Presupuesto de error	1 h 26 min cada 30 días
Ventana de mantenimiento	Martes y miércoles, 10:00-12:00
RPO	15 minutos
RTO	2 horas
Horario de guardia	Laborable 8:00-20:00; críticas 24×7
Revisión del cumplimiento	Mensual, en el panel

Checklist fila 33: cerrada.

Tramontana guarda datos personales de clientes: nombre, contacto y fechas de estancia. Eso activa obligaciones concretas del Reglamento General de Protección de Datos, y algunas son técnicas y son tuyas.

Y el punto que conecta directamente con el incidente del apartado 12: la tabla auditoria ocupa 1.204 MB, más que todos los datos de reservas juntos, y nadie ha decidido cuánto tiempo se conservan. Eso no es solo un problema de espacio: conservar datos personales sin plazo definido es un incumplimiento del principio de limitación del plazo de conservación.

Anonimizar en lugar de borrar conserva la utilidad estadística —cuántas reservas hubo, de qué casas— sin conservar los datos personales. Es la solución técnicamente correcta y la que más se pasa por alto.

La advertencia final, y es importante: el RGPD no es un asunto técnico, es un asunto legal con implicaciones técnicas. Nada de este apartado sustituye a asesoría profesional. Lo que sí es responsabilidad tuya como administrador es: que existan las medidas técnicas, que la retención sea aplicable con una orden, que haya trazabilidad de accesos, y que quien decide —Marta— tenga la información para decidir. Un administrador que implementa una purga sin que nadie haya decidido los plazos está tomando una decisión legal sin autoridad para hacerlo.

• Confundir monitorizar con alertar. Monitoriza todo; alerta de casi nada.
• Alertar de causas en lugar de síntomas. «CPU al 90 %» dispara cuando corre la copia. «Más del 5 % de errores» detecta cualquier fallo real.
• No podar alertas. Diez notificaciones al día equivalen a ninguna. La revisión mensual de alertas es tan importante como crearlas.
• Alertas sin acción. Si el receptor no puede hacer nada, es un panel, no una alerta. Toda alerta lleva su accion y su enlace al runbook.
• Silencios sin caducidad. Un silencio indefinido es una alerta apagada para siempre.
• No monitorizar la monitorización. Un script de métricas muerto hace que todo parezca correcto indefinidamente. La marca de frescura lo resuelve.
• Medias de latencia en lugar de percentiles. Una media de 80 ms esconde que el 1 % espera 4 segundos.
• Incluir los errores en la latencia. Una caída total, donde todo falla rápido, aparecería como mejora de rendimiento.
• rate() sobre un medidor. Solo tiene sentido sobre contadores (_total).
• Agregar histogramas sin by (le). Es el error clásico de PromQL: los percentiles salen sin sentido.
• Etiquetas de alta cardinalidad. Una etiqueta con el ID de reserva crea una serie por reserva y revienta la memoria de Prometheus.
• Un panel con cuarenta gráficas. No se mira. El principal debe caber en una pantalla.
• Post-incidentes que buscan culpables. Garantizan que el siguiente incidente se oculte.
• Acciones correctivas del tipo «tener más cuidado». No son acciones: son deseos. Deben cambiar el sistema.
• Desplegar el viernes por la tarde. Los problemas aparecen con carga real y para entonces no hay nadie.
• Un SLO sin presupuesto de error. El objetivo sin su consecuencia operativa no cambia ninguna decisión.
• Gastar el 5 % del presupuesto de error. Estás siendo demasiado conservador: podrías haber entregado más valor.
• Copias que el propio servidor puede borrar. No son copias: son una réplica con retraso, y el ransomware lo sabe.
• No revisar los accesos periódicamente. Un authorized_keys2 de un proveedor de hace año y medio da acceso hoy.
• Guardar datos personales sin plazo definido. Es un incumplimiento del RGPD, no solo un problema de espacio.
• Consejo de método. Ante «¿va bien el sistema?», si la respuesta no es un número, no estás en producción.

A las 03:47 se dispara TasaErroresAlta. Documenta la respuesta completa al incidente —desde la notificación hasta el cierre— y redacta la revisión post-incidente resultante.

Diseña la revisión mensual de alertas: qué se mide de cada alerta, con qué criterios se decide eliminarla, ajustarla o mantenerla, y aplica el método a las alertas configuradas en esta lección.

Marta pide un informe de estado del sistema para la reunión anual con los socios: qué se ha hecho este año, en qué situación está y qué se necesita. Redáctalo.

Solución 1

03:47 — Notificación.

03:49 — Confirmar que el problema es real, antes de tocar nada.

Confirmado: uno de cada tres usuarios recibe un error. No es una falsa alarma.

03:51 — Acotar el alcance con el panel, no adivinando.

La latencia subió tres minutos antes que los errores, y hay 47 clientes esperando conexión. El cuello de botella está en la base de datos, no en la aplicación ni en Nginx.

03:53 — El registro de cambios, que es la pregunta obligatoria.

Sin cambios recientes. No es un despliegue: es algo que ha ocurrido solo.

03:55 — Diagnóstico en la base de datos.

Causa raíz encontrada en ocho minutos. Un VACUUM FULL sobre app.disponibles tiene un bloqueo ACCESS EXCLUSIVE que impide toda lectura y escritura de esa tabla. Las peticiones se acumulan esperando, agotan el pool de PgBouncer, y la aplicación devuelve 502.

application_name = psql y arrancado a las 03:30: alguien lo lanzó a mano. La consulta al cuaderno de guardia lo confirma —una nota de la tarde anterior: «disponibles con 31,7 % de tuplas muertas, mirar».

03:58 — Mitigación.

04:00 — Verificar y cerrar.

04:05 — Anotar en el cuaderno mientras está fresco.

Revisión post-incidente: errores 502 por bloqueo de VACUUM FULL

Incidente: INC-2026-004 · Fecha: 2026-08-19 · Severidad: Crítica Duración del impacto: 17 min (03:41-03:58) · Detección: 6 min

1. Qué pasó

Un VACUUM FULL ejecutado manualmente sobre app.disponibles adquirió un bloqueo exclusivo que impidió toda lectura y escritura de la tabla durante 28 minutos. Las peticiones se acumularon, se agotó el pool de conexiones y la aplicación devolvió errores 502 al 34 % de las peticiones durante 17 minutos.

2. Impacto

Dimensión	Valor
Duración del impacto	17 min
Peticiones fallidas	~2.100 (34 % de 6.200)
Reservas perdidas estimadas	1-2 (madrugada, tráfico bajo)
Presupuesto de error consumido	19,7 % del mes (17 de 86 min)
Datos perdidos	Ninguno

3. Línea temporal

Hora	Suceso
03:30	Se lanza VACUUM FULL app.disponibles manualmente
03:38	El p95 de latencia sube a 8 s (síntoma temprano, sin alerta)
03:41	Primeros 502: el pool de PgBouncer se agota
03:47	Se dispara TasaErroresAlta y llega la notificación
03:49	Se confirma el problema
03:51	Se acota con el panel: la base de datos
03:55	Se identifica el bloqueo y el VACUUM FULL
03:58	pg_cancel_backend. Servicio restablecido
04:00	Verificado. Incidente cerrado

4. Causa raíz: los cinco porqués

#	Pregunta	Respuesta
1	¿Por qué hubo 502?	La aplicación no pudo consultar la base de datos
2	¿Por qué no pudo?	Un bloqueo ACCESS EXCLUSIVE sobre app.disponibles
3	¿Por qué había ese bloqueo?	Un VACUUM FULL manual
4	¿Por qué se ejecutó a mano en producción?	Se detectó 31,7 % de tuplas muertas y se quiso resolver rápido
5	¿Por qué había tanta hinchazón?	autovacuum no está ajustado para esa tabla

Causa raíz: autovacuum con los valores por defecto (umbral del 20 %) no sigue el ritmo de escritura de app.disponibles. La hinchazón resultante motivó una intervención manual con una herramienta cuyo bloqueo no se anticipó.

Causa contribuyente: no había ningún control que impidiera ejecutar una operación bloqueante en producción, ni alerta que avisara antes de que los usuarios se vieran afectados.

5. Qué funcionó bien

• La alerta era de síntoma y funcionó: detectó un fallo que nadie había anticipado. Una alerta de causa sobre VACUUM no existía y no habría hecho falta.
• El panel acotó el problema en dos minutos. Sin él, el diagnóstico habría sido a ciegas.
• El registro de cambios descartó un despliegue en treinta segundos.
• La mitigación fue reversible: cancelar en lugar de terminar la conexión.
• El cuaderno de guardia dio el contexto —la nota del día anterior— que explicó quién y por qué.

6. Qué se cambia

#	Acción	Responsable	Fecha	Estado
1	Ajustar autovacuum de app.disponibles al 2 % (08-02)	Ops	19/08	Hecho
2	lock_timeout = 5s por defecto en la sesión de psql de producción	Ops	20/08	Hecho
3	Instalar pg_repack y documentarlo como la herramienta para hinchazón	Ops	26/08	Pendiente
4	Alerta EsperaBloqueoProlongada (> 30 s) — avisa antes del síntoma	Ops	22/08	Pendiente
5	Runbook RB-BD-03: mantenimiento de base de datos, con la lista de operaciones bloqueantes	Ops	26/08	Pendiente
6	Panel con tuplas muertas por tabla, para no descubrirlo por casualidad	Ops	22/08	Pendiente
7	Ninguna operación de mantenimiento manual en producción fuera de ventana	Equipo	20/08	Acordado

# Acción 2: /etc/postgresql/16/main/conf.d/50-proteccion.conf
# Si una consulta no consigue un bloqueo en 5 s, falla en lugar de
# esperar. Una consulta que falla rápido es infinitamente preferible
# a una que bloquea el servicio entero.
lock_timeout = 5s

7. Lecciones

1. La latencia subió 9 minutos antes que los errores. Ese es el margen que perdimos por no tener una alerta temprana. La acción 4 lo recupera.
2. La intención era buena y el resultado fue una caída. No es un fallo de la persona: es un fallo del sistema, que permitía ejecutar una operación bloqueante en producción sin ninguna fricción. Las acciones 2, 5 y 7 añaden esa fricción.
3. El 19,7 % del presupuesto de error en un incidente de 17 minutos demuestra por qué el SLO cambia decisiones: con dos incidentes así, el mes entra en zona de precaución y los despliegues se moderan.
4. VACUUM FULL no es «un vacuum más grande». Bloquea la tabla entera. Merece estar en un runbook con esa advertencia en mayúsculas.

Solución 2

Por qué existe esta revisión. Las alertas se crean tras cada incidente y casi nunca se eliminan. En un año, un sistema acumula treinta alertas de las que cinco sirven. La revisión mensual es el contrapeso.

Las cuatro métricas que se miden de cada alerta:

El árbol de decisión, aplicado a cada alerta:

Aplicación a las alertas de esta lección:

Análisis y corrección de las dos problemáticas:

CopiaAntigua: 412 disparos, 0,2 % de precisión. Es el caso de libro de fatiga de alertas: se disparaba cada 30 minutos, todas las noches, entre la ejecución de la copia y su verificación. Cuatrocientas doce notificaciones que nadie leía, y que además entrenaron al equipo a ignorar el canal.

LatenciaDegradada: 38 disparos, 21 % de precisión, 45 minutos hasta la reacción. Los 45 minutos son el dato revelador: el equipo ya la estaba ignorando. Se dispara cada tarde durante el informe de facturación de Marta, que es lento y esperado.

Y para los informes, que sí conviene vigilar pero con otro umbral:

Resultado de la revisión:

Cuatro principios que resume esta revisión:

1. Una alerta con precisión baja es peor que ninguna, porque entrena al equipo a ignorar el canal donde también llegan las buenas.
2. El tiempo de reacción mide si la alerta se atiende. Cuarenta y cinco minutos significa que se ignora, y ese dato es más honesto que cualquier opinión.
3. Una alerta que nunca se dispara no es inútil, si cubre un riesgo grave y su coste es cero. ServicioCaido no se ha disparado en un año y debe seguir ahí.
4. Ajustar antes que eliminar. Las dos problemáticas cubrían riesgos reales; el problema estaba en el umbral, no en la idea.

Y una nota final de método: esta revisión se anota en el cuaderno de guardia, con el antes y el después de cada alerta modificada. Dentro de seis meses, cuando alguien se pregunte por qué el umbral de CopiaAntigua es 26 horas y no 8, la respuesta estará escrita.

Solución 3

Informe anual de sistemas · Tramontana Reservas

Para: Marta Vidal y socios · De: Operaciones de sistemas Ejercicio: 2026 · Fecha: 18 de agosto de 2026

---

Resumen ejecutivo

El sistema que sostiene Tramontana Reservas ha pasado, en el último año, de ser una máquina configurada a mano que nadie más que yo sabía reconstruir a una infraestructura documentada, automatizada, vigilada y con procedimientos escritos que otra persona podría seguir.

Los tres cambios más importantes, en una línea cada uno:

• Los datos de nuestros clientes ya viajan cifrados. Hasta junio no lo hacían.
• Podemos recuperar la base de datos a cualquier instante concreto, y lo hemos ensayado: 24 minutos.
• Reconstruir el servidor entero pasó de 8 horas a 50 minutos, y está medido, no estimado.

Disponibilidad medida en los últimos 30 días: 99,94 %, por encima del objetivo del 99,8 % que proponemos formalizar.

---

1. Dónde estábamos y dónde estamos

	Hace un año	Hoy
Configuración del servidor	En mi cabeza	En código, versionado
Reconstruir tras un desastre	8 h estimadas	50 min medidos
Datos que podríamos perder	Hasta 24 h	15 minutos
Recuperar un borrado accidental	Imposible sin perder un día	Al segundo anterior
¿Se han probado las copias?	Nunca	Ensayo trimestral documentado
Cifrado del tráfico web	No	Sí
Acceso remoto seguro	Solo desde la oficina	Desde cualquier sitio, por túnel cifrado
¿Sabemos si va bien?	«Creo que sí»	99,94 %, en un panel
Si algo falla de madrugada	Nos enteramos por la mañana	Alerta al teléfono
Documentación operativa	Ninguna	6 procedimientos escritos y ensayados

---

2. Lo que se ha hecho, agrupado

Fiabilidad. Automatización completa de la configuración: el servidor se reconstruye desde cero con un comando, y eso ha reducido el tiempo de recuperación ante un desastre de ocho horas a cincuenta minutos. Es la mejora que más ha aumentado la disponibilidad, y no ha costado un euro en equipamiento.

Protección de datos. Copias automáticas verificadas, cifradas, guardadas fuera del servidor y —desde este mes— imposibles de borrar desde el propio servidor durante 30 días, que es la defensa concreta contra un ataque de secuestro de datos. Y la capacidad de rebobinar la base de datos a cualquier instante, ensayada.

Seguridad. Cortafuegos restrictivo, detección de intrusiones, auditoría de accesos, contraseñas y certificados guardados cifrados, y el servicio funcionando con los mínimos permisos posibles. Una evaluación automática independiente puntúa nuestro nivel de endurecimiento en 82 sobre 100, cuando la instalación por defecto ronda el 60.

Rendimiento. Ajuste de la base de datos a la máquina real, que ha reducido los accesos a disco un 93 %. Y una consulta de informes que tardaba 3,8 segundos ahora tarda 0,18.

Visibilidad. Este es el cambio más reciente y el que más cambia el día a día: un panel que responde en tres segundos a «¿va bien?», con histórico de 30 días, y alertas que avisan antes de que el problema afecte a los clientes.

---

3. Incidentes del año

Fecha	Qué pasó	Impacto	Estado
17/08	El disco de copias se llenó y bloqueó el registro de la base de datos	Ninguno: detectado antes	Resuelto + alerta nueva
18/08	Borrado accidental de 40.218 reservas históricas	Ninguno: recuperadas en 34 min	Resuelto + 6 medidas
19/08	Errores durante 17 min por una operación de mantenimiento	~2.100 peticiones fallidas	Resuelto + 7 medidas

Ningún incidente causó pérdida de datos. Los tres se analizaron con el mismo método —qué pasó, por qué, qué se cambia— y generaron quince mejoras concretas, todas aplicadas o con fecha.

Quiero destacar el del 18 de agosto: se recuperaron 40.000 reservas sin perder nada, usando un procedimiento que habíamos ensayado tres días antes. Ese ensayo, que parecía burocracia, se pagó solo en 72 horas.

---

4. Lo que proponemos acordar

Un objetivo de servicio. Hasta ahora no teníamos ninguno, y sin él no se puede decidir cuánto invertir. Proponemos:

Concepto	Propuesta	Qué significa en la práctica
Disponibilidad	99,8 % mensual	Como máximo 1 h 26 min de fallo cada 30 días
Datos recuperables	15 minutos	En el peor caso se perderían 15 min de reservas
Tiempo de recuperación	2 horas	Desde un desastre total hasta el servicio restablecido
Ventana de cambios	Martes y miércoles por la mañana	Nunca viernes por la tarde ni fin de semana

Estamos por encima de ese objetivo hoy (99,94 %). Lo proponemos así a propósito: un objetivo que ya se cumple con holgura permite desplegar mejoras con tranquilidad, y uno demasiado exigente obligaría a frenar el desarrollo del producto.

Y una idea que quiero explicar porque cambia cómo decidimos. Ese 0,2 % de margen es un presupuesto: podemos «gastarlo» en cambios y mejoras. Si un mes lo consumimos por debajo de la mitad, seguimos desplegando con normalidad. Si nos acercamos al límite, se congelan las funciones nuevas y se dedica el esfuerzo a estabilizar. Convierte la discusión «¿vamos demasiado rápido?» en una consulta a un número. Este mes llevamos consumido el 31 %.

---

5. Lo que hace falta

Prioridad alta, decisión de dirección:

1. Política de retención de datos. Guardamos el histórico de actividad de la aplicación sin plazo definido, y ya ocupa más que todas las reservas juntas. Además de ser un problema de espacio, conservar datos personales sin plazo determinado no es defendible ante el Reglamento de Protección de Datos. Necesito que se decida cuánto tiempo guardamos cada cosa; lo aplico en una semana. Recomiendo asesoría legal para fijar los plazos.
2. Registro de actividades de tratamiento. Es un documento que el RGPD exige y que no tenemos. No es trabajo técnico, pero necesita mi aportación.

Prioridad media, inversión moderada:

3. Segundo servidor de aplicación con reparto de carga. Es la recomendación que analicé en detalle: eliminaría las interrupciones por despliegue y por fallo de una máquina, que son la mayoría. Coste: dos máquinas y una semana de trabajo, más tres o cuatro semanas de desarrollo previo con Luis. Nos llevaría del 99,8 % actual a un margen mucho más holgado.
4. Réplica de la base de datos. Justificada sobre todo porque permitiría ejecutar los informes pesados sin afectar a la web, y de paso actualizar sin cortar servicio.

Lo que NO recomiendo, y quiero dejarlo por escrito:

• Arquitectura de alta disponibilidad completa (cinco máquinas, cambio automático de servidor). Analizado con números: cuesta varias veces más que la opción 3 y aporta apenas 670 € adicionales de ahorro anual. Y añadiría una complejidad que con la plantilla actual no podemos vigilar bien — un sistema sofisticado mal mantenido es menos fiable que uno sencillo bien cuidado.
• Kubernetes, que es la tecnología de moda. Lo he montado y evaluado en el entorno de pruebas: para nuestro tamaño consumiría entre dos y cuatro semanas de trabajo al año solo en mantenerlo, para resolver problemas que no tenemos.

---

6. Riesgos que asumimos conscientemente

Prefiero que estén escritos a que se descubran el día malo:

Riesgo	Consecuencia	Por qué lo aceptamos
Una sola máquina de aplicación	Un fallo de hardware = servicio caído hasta 2 h	Propuesta 3 lo resolvería
Cambio manual de base de datos	5-15 min adicionales en ese caso	Automatizarlo exige 5 máquinas y crearía un riesgo mayor
Una sola persona con conocimiento operativo	Vacaciones o baja = respuesta lenta	Mitigado en parte: procedimientos escritos
Dependencia de un proveedor	Una caída suya nos afecta entera	Habitual a nuestra escala

El tercero es el que más me preocupa a medio plazo, y es la razón de que este año haya dedicado tanto esfuerzo a escribir procedimientos: hoy, alguien con conocimientos técnicos generales podría seguir la mayoría de ellos sin haber trabajado nunca en nuestro sistema. Hace un año, no.

---

7. Conclusión

El sistema está en una situación considerablemente mejor que hace un año, y —lo que más importa— está en una situación que puedo demostrar con datos en lugar de afirmar con confianza. Hemos pasado de «creo que va bien» a «99,94 %, aquí está el panel».

Lo que queda pendiente son sobre todo decisiones, no trabajo técnico: cuánto tiempo guardamos los datos, qué nivel de servicio nos comprometemos a dar, y si invertimos en el segundo servidor. Con esas tres decisiones tomadas, tenemos un sistema del que se puede depender.

El curso termina donde tenía que terminar: no en una herramienta más, sino en la capa que convierte un servidor que funciona en un servicio del que se puede depender. Tienes una checklist de cuarenta y dos filas con evidencia comprobable en cada una, y sabes exactamente cuáles faltan, que es una forma de saber más valiosa que creer que están todas. Tienes monitorización con histórico de treinta días, alertas que se pueden atender porque son pocas y son de síntoma, y un panel que responde en tres segundos a la única pregunta que importa.

Sobre todo tienes criterio operativo. Sabes que monitorizar y alertar no son lo mismo y que hay que hacer mucho de lo primero y muy poco de lo segundo. Sabes que una alerta con precisión del 2 % es peor que ninguna, porque entrena al equipo a ignorar el canal por donde también llegan las buenas. Sabes que un post-incidente que busca culpables garantiza que el siguiente se oculte, y que una acción correctiva del tipo «tener más cuidado» no es una acción sino un deseo. Y sabes que el presupuesto de error convierte «¿desplegamos?» en una consulta a un número, con la conclusión que sorprende: gastar solo el 5 % del presupuesto significa haber sido demasiado conservador.

Las tres deudas están cerradas. La copia externa ya no la puede borrar el servidor que respalda, porque un sistema que puede destruir sus copias no tiene copias. El authorized_keys2 resultó ser lo que suelen ser estas cosas: no una vulnerabilidad exótica, sino un fichero de un proveedor de hace año y medio que seguía dando acceso porque nadie lo había mirado — y lo que se ha corregido no es el fichero, es la ausencia de revisión periódica que permitió que estuviera ahí. Y el objetivo de disponibilidad existe por fin, con su número, su ventana y su presupuesto.

Y con esto se cierra el curso completo. Ocho módulos.

Empezaste en el Módulo 1 sin saber qué era un kernel, y montaste el sistema desde una imagen de instalación. En el 2 dejaste de temer la terminal: permisos, inodos, enlaces y man como primera parada. En el 3 el shell dejó de ser un intérprete de órdenes sueltas y pasó a ser un lenguaje: tuberías, find, awk, procesos, señales. En el 4 escribiste scripts que no se rompen —set -euo pipefail, trap, flock, idempotencia—, y desplegar.sh con su rollback atómico sigue en producción cincuenta lecciones después. El 5 fue la administración de verdad: usuarios, paquetes con pinning, LVM, systemd endurecido, journal persistente, y unas copias con RPO y RTO acordados en lugar de improvisados. El 6 puso la seguridad como disciplina y no como lista de trucos: modelo de amenazas, cortafuegos de lista blanca, AIDE con su base de datos fuera, secretos cifrados y aquel certificado TLS que esperó dos módulos. El 7 miró debajo del capó —arranque, strace, perf, eBPF, el kernel, KVM, contenedores, Ansible— y terminó con el análisis honesto de si hacía falta alta disponibilidad. Y el 8 aplicó todo a construcciones completas, de principio a fin.

Lo que se llevan de aquí no es una lista de comandos. Es un método: medir antes y después, porque un ajuste sin medición es superstición. Probar en pruebas antes de producción. --dry-run antes de actuar. Copia y diff -u antes de editar. Validar antes de recargar, sea nginx -t, promtool check, testparm -s o pg_hba_file_rules. Nunca cierres la puerta por la que estás entrando. Silencio si todo va bien. Y decir siempre qué protege y qué no protege una medida, que es lo que separa un informe honesto de un argumento de venta.

Y una idea que ha aparecido en cada módulo con distinta ropa: la respuesta profesional no siempre es que sí. No a la arquitectura completa de alta disponibilidad, no a Kubernetes, no a subir max_connections, no a copiar seis terabytes a la nube. Saber decir que no, con números y con alternativa, vale tanto como saber montarlo.

Sobre cómo seguir. Las certificaciones LPIC-1 y LPIC-2 o la RHCSA ordenan y acreditan lo que ya sabes; la RHCSA es práctica y exigente, y prepararla enseña de verdad. Las especializaciones naturales desde aquí son cuatro: ingeniería de fiabilidad, que es esta última lección llevada a escala; plataforma y nube, donde Kubernetes y la infraestructura como código son el día a día; ciberseguridad, prolongando el Módulo 6; y bases de datos, prolongando 08-02. Participa en la comunidad —listas, foros, un informe de error bien escrito, una corrección de documentación— porque explicar algo es la mejor forma de descubrir si lo entiendes. Y lee los cambios de las versiones del kernel y de tu distribución: es la manera más barata de no quedarse atrás.

Pero si solo puedes conservar una cosa, que sea esta: mantén el laboratorio. Esa VM de pruebas, o el servidor de medios de 08-03, o el clúster de k3s que decidiste no llevar a producción. Un sitio propio donde romper cosas a propósito, provocar los fallos en horario laboral en lugar de esperarlos, y probar lo que aún no sabes. Todo lo que has aprendido en este curso lo has aprendido haciéndolo, y esa es la única forma que hay. La diferencia entre quien lee sobre sistemas y quien los administra no es lo que ha estudiado: es lo que ha roto y ha vuelto a levantar. Enciende la máquina y sigue.