Prólogo: el simulador de Houston

En Apollo 13 (1995) hay una escena que suele pasar desapercibida al lado de la frase famosa. Cuando el tanque de oxígeno explota, los ingenieros en Houston no improvisan sobre la nave real: reproducen el problema en el simulador de tierra, con los mismos instrumentos y las mismas restricciones, y ensayan ahí cada secuencia de encendido antes de dictársela a la tripulación. El simulador existía desde antes de la misión. Nadie lo construyó durante la emergencia.

Lo que salva a la tripulación no es que alguien revise cada decisión con más cuidado. Es que, meses antes, alguien decidió que habría un simulador, que habría procedimientos de vuelta a casa y que la gente los habría ensayado. La seguridad real estaba en lo preparado de antemano. Este paper es sobre nuestro simulador, nuestro tanque de oxígeno, y lo que aprendimos de los dos.

El día que el servidor murió

Un servidor virtual alojaba tres productos en producción: un sistema de gestión, su tienda en línea y una plataforma de monitoreo de un cliente externo. Era una tarde de agosto de 2026. El Tech Lead y el agente estaban depurando un problema de despliegue, y el agente, para explicar qué había pasado, citó el comando de sincronización que usa el script de despliegue: copia una carpeta a otra y borra en el destino lo que ya no está en el origen. El comando llevaba una variable con la ruta de destino. En la explicación, la variable no tenía valor.

El comando se pegó en la terminal del servidor y se ejecutó. Con la variable vacía, la ruta de destino quedó apuntando a la raíz del sistema de archivos. En segundos desaparecieron los directorios de binarios, bibliotecas, configuración, usuarios y aplicaciones. Los tres productos cayeron a la vez. El servidor ya no podía ni abrir una sesión nueva: no quedaba un intérprete de comandos con el que abrirla.

Conviene decir qué no falló. No falló el código del agente: el sistema de gestión, la tienda y la plataforma estaban correctos. No falló la revisión: el comando se leyó antes de pegarlo y se pegó igual, porque a una persona que lleva horas depurando una variable vacía le parece una línea más. Falló lo que Cook (2000) describe en sus dieciocho tesis sobre sistemas complejos: «la catástrofe siempre está a la vuelta de la esquina», y «la atribución post-accidente a una causa raíz es fundamentalmente errónea», porque un sistema complejo solo falla cuando varias defensas pequeñas fallan juntas. Aquí fallaron tres: un comando destructivo dentro de un bloque ejecutable, una variable sin valor y la costumbre de pegar lo último que aparece en pantalla.

Lo que siguió es la parte que importa. Meses antes, en la fase de endurecimiento, se habían dejado preparadas dos cosas que hasta ese día nadie había necesitado: snapshots periódicos del servidor completo en el proveedor, y respaldos automáticos cifrados de las bases de datos con copia fuera del servidor. Se restauró el snapshot más reciente. Se aplicaron sobre él los respaldos de las bases para cerrar la brecha de tiempo entre el snapshot y el incidente. Se verificó cada servicio. Se avisó al cliente. Todo volvió a estar corriendo en menos de una hora.

Para ponerle escala: en la encuesta de Gremlin a más de 400 profesionales, solo el 23 % de los equipos reporta un tiempo medio de recuperación menor a una hora, y la mitad de los equipos tarda más de doce (Gremlin, 2021). Un equipo de una persona y un agente, con un servidor de tamaño modesto, entró en ese 23 % no por heroísmo esa tarde, sino por una decisión aburrida tomada meses antes. Jamás volvió a ocurrir — y no porque desde entonces se lea con más cuidado, sino por las reglas del capítulo 3.

Un respaldo que nunca se restauró es una esperanza

El manual de Site Reliability Engineering de Google tiene un capítulo sobre integridad de datos cuya frase central debería estar en la pared de todo laboratorio: «los respaldos no importan; lo que importa es la recuperación». Nadie quiere hacer respaldos; lo que la gente quiere son restauraciones. Y solo sabes que puedes recuperar tu estado reciente «si de verdad lo haces» (Beyer et al., 2016). El mismo capítulo cuenta cómo Gmail recuperó en 2011 los buzones de decenas de miles de cuentas desde cinta magnética, antes del plazo estimado, porque la restauración se había ensayado antes de necesitarla.

El contraejemplo canónico es el de GitLab. El 31 de enero de 2017, un ingeniero borró por error el directorio de datos de la base de datos primaria. Al ir a recuperar, descubrieron que el respaldo lógico llevaba tiempo fallando en silencio por una incompatibilidad de versiones, que los correos de error eran rechazados por el filtro de correo, que la replicación había fallado y que los snapshots de disco del proveedor no estaban activados para las bases. De cuatro mecanismos, solo sirvió un snapshot manual de seis horas antes, que no estaba pensado para recuperación de desastres y cuya restauración tardó unas dieciocho horas. La causa raíz del postmortem no fue técnica: «como no había un dueño, nadie era responsable de probar este procedimiento» (GitLab, 2017).

Las guías oficiales dicen lo mismo con otras palabras. La regla 3-2-1 — tres copias, en dos medios distintos, una fuera del sitio — viene acompañada de una advertencia: los respaldos rotativos pueden propagar en silencio la corrupción del original a la copia (Ruggiero y Heckathorn, 2012). La guía de contingencia del NIST define los dos números que todo equipo debería conocer de su propio sistema: el tiempo objetivo de recuperación (RTO) y el punto objetivo de recuperación (RPO), y exige probar y ejercitar los planes, no solo escribirlos (Swanson et al., 2010). En nuestro caso, el RTO fue menos de una hora y el RPO, la brecha entre el último respaldo de las bases y el incidente — minutos de ventas, no horas.

Y los proveedores de servidores virtuales ofrecen justo la pieza que hace posible el simulacro del capítulo 4: un snapshot se puede restaurar sobre el mismo servidor o usar para crear uno nuevo idéntico (Hetzner, s. f.). Hay que leer la letra chica: en algunos proveedores los respaldos automáticos solo conservan los dos más recientes y rotan, y conviene convertir uno en snapshot para que no desaparezca (Vultr, s. f.).

Anécdota: el simulacro que encontró el respaldo roto

Después del incidente, el agente construyó para un sistema de gestión multitienda un contenedor de respaldo que cada madrugada vuelca cada base, la cifra en el mismo tubo para que el archivo en claro nunca toque el disco, verifica que el archivo descifre entero y que lo de adentro sea legible, y lo copia fuera del servidor. Y un simulacro mensual: toma el último respaldo de cada base, lo restaura en una base temporal con un nombre que ninguna base real puede tener, compara tablas y filas con la original, y la borra. El simulacro prueba lo que el respaldo diario no puede: que el archivo se descifra con la frase de hoy (si la frase cambió, los respaldos viejos dejaron de servir y no se nota hasta que hacen falta) y que la restauración corre sin un solo error con los roles de hoy.

Al probar el simulacro en local con seis escenarios, apareció que el script de restauración exigía cinco tablas y la base del plano de control tiene cuatro: restaurarla «fallaba» siempre. Un respaldo perfecto con una restauración que nunca iba a funcionar. Nadie lo habría visto leyendo el script — se veía razonable. Lo vio el ensayo. Y el resultado de cada respaldo y cada simulacro quedó anotado en el plano de control, de donde lo lee el panel del operador y avisa por correo si uno no salió: que el contenedor esté corriendo no dice si el respaldo de anoche salió.

Lo que aprendimos sin culpar a nadie

La reacción natural después de un desastre es buscar al culpable y revisar más. Dekker (2014) llama a eso la «teoría de la manzana podrida»: el error humano como causa, que se arregla castigando o controlando más. La alternativa — la «nueva visión» — trata el error como síntoma de problemas más profundos del sistema, y pregunta por qué la acción tenía sentido para quien la hizo. Allspaw (2012) lo llevó a la práctica con los postmortems sin culpa: castigar reduce el reporte de incidentes y, por tanto, el aprendizaje. Google lo resume en una línea del capítulo sobre cultura de postmortem: «el costo del fallo es educación» (Beyer et al., 2016).

Nuestro postmortem no fue sobre el comando. Fue sobre por qué pegar ese comando tenía sentido, y qué del sistema lo permitió. De ahí salieron reglas que desde entonces el agente aplica a todo lo que propone, y que están escritas en su memoria de trabajo:

• Nada destructivo dentro de un bloque ejecutable, ni siquiera para explicar. En la herramienta del Tech Lead, los bloques de código traen botón de ejecutar. Lo que borra, trunca, sobreescribe o reinicia va en prosa o en código en línea, diciendo que no se corre. Y la ruta que se borra se dice en palabras antes del comando.
• Cero placeholders. Ningún comando lleva algo que haya que reemplazar. Antes del incidente, un comando con un marcador entre paréntesis angulares nunca corrió — el intérprete lo leyó como una redirección — y el reinicio siguiente relanzó la configuración equivocada en silencio. Si falta un dato, se resuelve dentro del mismo comando o se pide antes con una consulta de solo lectura.
• Guarda de máquina. Un bloque que solo debe correr en un servidor comprueba él mismo el nombre del servidor y aborta si no coincide. Rotularlo en prosa no protege: dos veces se pegó en producción un bloque marcado «para el servidor viejo», porque había dos sesiones abiertas y el rótulo se perdió entre la salida del comando anterior.
• Un comando que vuelve sin salida no se asume corrido. Se verifica con una consulta de solo lectura. Y todo script largo va por el repositorio, no pegado: la terminal corrompe los pegados largos.

Fíjense en que ninguna de estas reglas es «revisar con más cuidado». Todas son cambios en el sistema que rodea a la persona. Y vienen de la misma familia que las medidas que los fabricantes de agentes recomiendan: la documentación de Claude Code describe un sandbox que el sistema operativo impone — escritura restringida al directorio de trabajo, red limitada a dominios permitidos — y una arquitectura de permisos donde lo destructivo pide aprobación (Anthropic, s. f.-a, s. f.-b). El control recomendado es de contención del daño, no de inspección línea a línea.

Porque los agentes también se equivocan solos. En julio de 2025, el agente de Replit borró la base de datos de producción de una empresa durante una congelación de cambios, con registros de más de mil ejecutivos, y afirmó que la reversión no funcionaría; los datos se recuperaron porque los respaldos existían (Nolan, 2025). La respuesta de Replit no fue «revisaremos más»: fue separar los entornos de desarrollo y producción, restauración con un clic del estado completo del proyecto y entornos de preproducción (Sharwood, 2025). El mismo mes, un usuario de Gemini CLI perdió archivos cuando el agente asumió que un directorio se había creado, el comando había fallado, y movió los archivos unos encima de otros (Gupta, 2025). Todas las medidas que sirven en estos casos son las mismas que nos sirvieron a nosotros: lo preparado antes.

Romper el clon a propósito

El incidente motivó una práctica nueva, que resultó tener nombre y literatura: se clona el servidor desde un snapshot, se rompe a propósito de distintas maneras y se mide cuánto tarda en volver y qué se pierde. Netflix lo empezó en 2011 con Chaos Monkey, un servicio que apaga instancias de producción al azar para obligar a construir servicios que toleren la pérdida de una máquina: la mejor defensa contra los fallos inesperados graves es fallar a menudo (Izrailevsky y Tseitlin, 2011). Cinco años después, el mismo equipo lo formalizó como disciplina: experimentar sobre un sistema para ganar confianza en que soporta condiciones turbulentas, porque los fallos de los sistemas complejos no se descubren revisando código sino provocándolos de forma controlada (Basiri et al., 2016). Los principios publicados piden una hipótesis sobre el estado estable, variar eventos del mundo real, automatizar los experimentos y, sobre todo, minimizar el radio de impacto (Principles of Chaos Engineering, 2019). El libro de referencia de la disciplina recomienda empezar con «game days» a mano antes de automatizar (Rosenthal y Jones, 2020).

Google lleva esto más lejos con DiRT, su programa de pruebas de recuperación de desastres, que rompe sistemas vivos a propósito y además aparta al personal crítico para probar la resiliencia operacional, no solo la técnica (Krishnan, 2012). En el manual de SRE lo cuentan como entrenamiento: una «rueda de la desgracia» semanal donde se juegan desastres por roles, y «romper cosas reales» en una instancia apartada del tráfico o un clúster de preproducción — el equipo de búsqueda «quema un clúster hasta los cimientos» cada trimestre (Beyer et al., 2016). Jesse Robbins creó en Amazon los GameDay con la misma lógica: la única forma de saber si un sistema y su gente se recuperan es provocar el desastre en condiciones controladas (Robbins et al., 2012). Y hoy existe como servicio gestionado: la inyección de fallos de AWS trae plantillas de experimento, condiciones de parada y la recomendación explícita de ensayar primero en preproducción (Amazon Web Services, s. f.).

Nuestro simulacro es más modesto y se parece más al clúster quemado que a Chaos Monkey. Se crea un servidor nuevo desde el snapshot de producción — un clon exacto, con otra dirección y sin tráfico real — y sobre él se ejecutan escenarios parecidos al incidente, empezando por el mismo comando con la variable vacía. Para cada uno se evalúa el resultado: cuánto tarda en volver, qué datos se pierden y cuántos pasos requirieron improvisación. Los pasos que requirieron improvisación se escriben como script y pasan a estar en el repositorio para la próxima vez. Después el clon se destruye: cuesta unas horas de servidor, no un mes.

Anécdota: el script de reconstrucción que no estaba en ningún lado

Un simulacro de reconstrucción desde cero destapó algo que el incidente real no había alcanzado a mostrar. El script original de aprovisionamiento del servidor del sistema de gestión tenía una contraseña escrita adentro y, por eso, estaba excluido del repositorio. Consecuencia: tras un desastre total, el script para reconstruir el servidor no se podía clonar desde el repositorio — solo existía en el disco del dueño. Peor: lo que describía ya no era cierto. Hablaba de un solo directorio de runtime cuando el despliegue usa dos colores alternados, de un puerto fijado con una variable que el archivo de configuración ignora, y de un directorio de registros que ningún componente usa. Corría y terminaba bien; por eso era peligroso. El agente inventarió, línea por línea, lo que el script decía contra lo que el servidor real tenía, y el reemplazo quedó versionado, sin secretos adentro, y probado contra un clon.

Ese es el tipo de hallazgo que solo aparece ensayando. Nadie revisa el script de reconstrucción un martes cualquiera. Y es, de nuevo, la tesis de Cook: «las operaciones libres de fallos requieren experiencia con el fallo» (Cook, 2000).

La métrica que protege cuando el agente produce mucho

Cuando un agente genera mucho código, la pregunta ya no es cómo impedir que algo falle: es cuánto tarda el sistema en volver cuando falla. Las métricas DORA, surgidas de años de investigación sobre equipos de alto rendimiento, miden exactamente eso: frecuencia de despliegue, tiempo de entrega, tiempo de restauración del servicio y tasa de fallo de los cambios (Forsgren et al., 2018). Y el reporte DORA de 2024 — el mismo que registra la caída de estabilidad con la adopción de IA — concluye que siguen siendo imprescindibles los lotes pequeños y las pruebas robustas (Harvey y DeBellis, 2024). Lotes pequeños, pruebas robustas y recuperación rápida: eso es un pipeline de despliegue como lo describieron Humble y Farley (2010), donde todo cambio pasa por etapas automatizadas antes de producción y se puede revertir.

En el laboratorio, eso se traduce en despliegues azul-verde: el nuevo binario se publica en el color apagado, se comprueba su salud y solo entonces se mueve el tráfico. Y en una trampa que el agente encontró antes de que mordiera: los patrones de exclusión del script de despliegue estaban escritos con barra final, y en la herramienta de sincronización un patrón que termina en barra solo coincide con directorios — un enlace simbólico no lo es, así que el borrado se los habría llevado en el primer despliegue y las aplicaciones habrían vuelto a escribir en carpetas locales sin que nada avisara. Como eso era lo que el agente entendía de la herramienta y no podía comprobarlo desde donde escribía, el script no lo documenta: lo prueba. Antes de tocar nada, monta el caso exacto en una carpeta temporal, saca el patrón del script instalado — no de una copia — y le pregunta a la herramienta en seco qué quitaría. Si el enlace aparece, aborta.

Esa es la forma madura de «revisar»: no leer el script, sino hacer que el script se ponga a prueba contra su propio supuesto antes de actuar.

El tanque de oxígeno como prueba del simulador

Volvamos a Houston. Nadie celebra que el tanque haya explotado. Pero la explosión fue la prueba de que el simulador, los procedimientos y los ensayos valían lo que costaron. Nuestro servidor muerto fue lo mismo: una prueba de fuego de meses de trabajo aburrido que hasta ese día no había servido para nada visible.

Si la primera parte de esta serie decía que el humano ya no revisa código sino evidencia, esta parte agrega la mitad que faltaba: la evidencia tiene un punto ciego, y la red que lo atrapa se teje antes. Snapshots antes de cada cambio en producción. Respaldos cifrados, fuera del servidor, verificados por un simulacro que pasa. Un clon que se rompe a propósito con cadencia fija. Reglas que cambian el sistema, no que piden más cuidado. Con eso, estar a merced de la inteligencia artificial deja de ser una apuesta y pasa a ser un riesgo medido: lo peor que puede pasar es una hora.

Queda una pregunta. Si el agente construye y prueba, y la seguridad está en la infraestructura que lo rodea, ¿qué tiene que saber la persona que dirige todo esto? Esa es la tercera parte.