Hiciste deploy un viernes a las 5 PM. Sabías que la migración no se había ejecutado en staging — staging siendo la copia de producción donde pruebas las cosas antes de que los usuarios reales las vean. Te dijiste que ya lo habías hecho cien veces. A las 5:47 PM, la base de datos se bloqueó. A las 6:12 PM, te sonó el teléfono. Pasaste el sábado arreglando lo que una revisión de dos minutos habría evitado. 📋

Lo sé porque yo fui esa persona. Y porque cada retrospectiva de ops que he leído cuenta la misma historia: alguien se saltó un paso que sabía que existía.

Un piloto, un río y un checklist

El 15 de enero de 2009, el Capitán Chesley Sullenberger aterrizó el vuelo 1549 de US Airways en el río Hudson. Ambos motores fallaron tras impactar contra una bandada de gansos. Las 155 personas sobrevivieron. Cuando los reporteros le preguntaron cómo, no dijo "experiencia" ni "instinto". Dijo que su tripulación siguió sus checklists. El checklist de falla de ambos motores. El checklist de amerizaje. Paso a paso, bajo la máxima presión.

La aviación lleva haciendo esto desde 1935, cuando un vuelo de prueba del Boeing Model 299 se estrelló porque el piloto olvidó liberar un seguro de control. El avión — un prototipo de bombardero de cuatro motores — era literalmente demasiado complejo para la memoria de una sola persona. La respuesta de Boeing no fue "contraten mejores pilotos". Fue un simple checklist en una tarjeta. La tasa de accidentes bajó. La industria nunca miró atrás.

Tu deploy a producción — el proceso de enviar código nuevo a los servidores que tus usuarios realmente usan — no es menos complejo que la revisión pre-vuelo de un bombardero de 1935. Tu respuesta a incidentes no es menos crítica que un aterrizaje de emergencia en el agua. Pero sigues confiando en la memoria, la experiencia y el "siempre lo hemos hecho así".

Por qué la gente inteligente se salta pasos

Esto no es cuestión de inteligencia. Es cuestión de cómo funciona el cerebro.

Los cirujanos que usan checklists reducen complicaciones en un 35% y muertes en un 47%, según un estudio histórico de la OMS publicado en 2009 en el New England Journal of Medicine. Estas son personas con una década de formación médica. No se saltan pasos porque sean descuidados — se los saltan porque la memoria de trabajo humana colapsa bajo presión secuencial.

Atul Gawande, el cirujano que escribió The Checklist Manifesto, identificó dos tipos de falla:

Fallas de ignorancia: No sabes qué hacer. Estas se están reduciendo a medida que el conocimiento se difunde en internet.

Fallas de ineptitud: Sabes exactamente qué hacer pero fallas en ejecutarlo. Estas van en aumento porque los sistemas son cada vez más complejos. El conocimiento existe. La ejecución se desmorona.

En tech, casi cada incidente en producción que he investigado fue una falla de ineptitud. Alguien sabía que debía ejecutar la migración de base de datos — un script que actualiza la estructura de la base de datos para que coincida con el nuevo código — antes de hacer deploy. Alguien sabía que debía revisar el plan de rollback — los pasos documentados para volver a la versión anterior funcional si todo se rompe. Alguien sabía que debía verificar que el feature flag — un toggle que mantiene las funciones nuevas ocultas hasta que estés listo — estuviera desactivado.

Lo sabían. Lo olvidaron. A las 11 PM, después de un día de 10 horas, se saltaron el paso 7 de 12 porque su cerebro les susurró "ya lo hice cien veces". 🫶

Tres checklists que todo equipo tech necesita

Este es el sistema. Tres checklists. Cada uno apunta a un momento específico donde la memoria humana falla con más fuerza.

Checklist 1: El checklist de deploy

Se ejecuta antes de cada deploy a producción. Cada ítem es binario — sí o no. Sin juicios subjetivos. Si algún ítem es "no", te detienes. En aviación, un solo "no" deja el avión en tierra. Tus deploys merecen el mismo respeto.

## Pre-Deploy

- [ ] Todas las pruebas pasan en staging
- [ ] Migraciones de base de datos probadas en staging
- [ ] Plan de rollback documentado y probado
- [ ] Feature flags verificados (funciones nuevas apagadas por defecto)
- [ ] Dashboards de monitoreo abiertos
- [ ] Ingeniero de guardia confirmado y disponible
- [ ] Ventana de deploy confirmada (no viernes a las 5 PM)
- [ ] Cambio anunciado en el canal del equipo
- [ ] Métricas del deploy anterior estables por 24h+

## Verificación Post-Deploy

- [ ] Health check endpoints respondiendo 200
      (200 = la forma del servidor de decir "estoy bien")
- [ ] Tasa de errores sin elevación vs. línea base
- [ ] Flujos clave del usuario probados manualmente
- [ ] Métricas de rendimiento dentro del rango normal
- [ ] Deploy registrado en el changelog

Mi equipo adoptó este checklist hace 18 meses. Los incidentes relacionados con deploys bajaron de aproximadamente uno cada dos semanas a uno cada tres meses. No porque nos volvimos más inteligentes. Porque dejamos de saltarnos pasos. ⚙️

Checklist 2: El checklist de respuesta a incidentes

Cuando producción se cae, tu cerebro entra en modo de lucha o huida. La adrenalina se dispara. Quieres arreglarlo YA. Este es exactamente el momento en que los checklists más importan — porque tu corteza prefrontal, la parte responsable del pensamiento secuencial, es lo primero que la adrenalina apaga.

## Minuto 0-5: Evaluar
- [ ] Confirmar que el incidente es real (no una falsa alarma del monitoreo)
- [ ] Severidad: S1 (caída total), S2 (parcial), S3 (degradado)
- [ ] Asignar comandante de incidente (una persona toma las decisiones)
- [ ] Abrir canal dedicado al incidente

## Minuto 5-15: Comunicar
- [ ] Página de estado actualizada
- [ ] Clientes afectados notificados (si es S1/S2)
- [ ] Stakeholders internos notificados
- [ ] ETA de la próxima actualización comunicada
      (aunque sea solo "estamos investigando")

## Minuto 15+: Resolver
- [ ] Causa raíz identificada O escalamiento activado
- [ ] Fix probado en staging primero (si es posible)
- [ ] Fix desplegado en producción
- [ ] Monitoreo confirma la resolución

## Post-Incidente
- [ ] Post-mortem agendado en las próximas 48 horas
- [ ] Timeline documentado mientras los recuerdos están frescos
- [ ] Action items asignados con responsables y fechas límite
- [ ] Checklist actualizado si faltaba algún paso

Ese último ítem es el motor silencioso de todo el sistema. Cada incidente se convierte en retroalimentación para el checklist. ¿Falta algo? Agrégalo. ¿Algo sobra? Elimínalo. El checklist está vivo — aprende de cada falla, para que tú no tengas que repetirlas. 🧘

Checklist 3: El checklist de code review

El code review — cuando un compañero lee tu código antes de que llegue a producción — sin un checklist es leer y cruzar los dedos. Con un checklist, es una verificación sistemática de que categorías específicas de problemas no existen.

## Seguridad
- [ ] Sin credenciales, API keys o tokens hardcodeados
- [ ] Input del usuario validado y sanitizado
- [ ] Queries a la base de datos usan statements parametrizados
      (previene SQL injection — un ataque donde alguien
       introduce comandos de base de datos en un formulario de login)
- [ ] Autenticación verificada en todos los endpoints protegidos
      (endpoint = una URL específica a la que tu app responde)

## Confiabilidad
- [ ] Manejo de errores cubre los casos de falla
- [ ] Llamadas a APIs externas tienen timeouts configurados
      (API = una forma en que los programas se comunican entre sí)
- [ ] Queries a la base de datos tienen índices para tablas grandes
      (índice = un atajo de búsqueda, como el índice de un libro)
- [ ] Sin queries N+1 (obtener datos relacionados uno por uno
      en vez de en un solo batch eficiente)

## Mantenibilidad
- [ ] Las funciones hacen una sola cosa
- [ ] Los nombres de variables describen lo que contienen
- [ ] La lógica compleja tiene comentarios explicando el POR QUÉ
- [ ] Los tests cubren los nuevos flujos de código

Cómo hacer que los checklists se queden

Crear checklists es fácil. La parte difícil — la que nadie menciona — es evitar que se abandonen. Cuatro reglas:

Hazlos obligatorios, no opcionales. Integra el checklist en tu pipeline de deploy — la secuencia automatizada de pasos que construye y envía tu código. El botón de deploy se queda gris hasta que cada casilla esté marcada. Un checklist que es "recomendado" se usa el 80% del tiempo, lo que significa que falla precisamente cuando más importa: bajo presión, de noche, cuando estás cansado.

Mantenlos cortos. Investigaciones en aviación encontraron que los checklists con más de 9 ítems tienen un cumplimiento dramáticamente menor. Si el tuyo tiene 30 ítems, divídelo en fases. Cada fase: 5-9 ítems. Un checklist corto que se sigue le gana a uno largo que se ignora.

Revísalos cada trimestre. Elimina ítems que nunca atrapan nada. Agrega ítems de incidentes recientes. Un checklist estancado genera desprecio — la gente deja de tomarlo en serio cuando la mitad de los ítems se sienten irrelevantes para su stack actual.

Hazlos visibles. Fíjalos en el canal del equipo. Ponlos en la interfaz de la herramienta de deploy. Imprime uno y pégalo junto a los monitores. El mejor checklist es el que ves sin buscarlo.

Lo que esto te cuesta

Seamos honestos sobre los tradeoffs. Los checklists agregan fricción. Un checklist de deploy agrega 5-10 minutos a cada deploy. Un checklist de respuesta a incidentes se siente desesperadamente lento cuando producción está en llamas. Los checklists de code review hacen que las revisiones tomen más tiempo.

Esa fricción es justamente el punto. Es lentitud deliberada en momentos donde la velocidad causa daño. Un piloto no apura la revisión pre-vuelo porque los pasajeros ya están abordando. Tú no deberías apurar un deploy porque el PM lo pidió para hoy.

El otro costo es el mantenimiento. Un checklist sin mantenimiento es peor que no tener checklist — le enseña a tu equipo que el proceso es puro teatro. Alguien necesita ser dueño de cada checklist, revisarlo cada trimestre y actualizarlo después de cada incidente. Eso es trabajo real.

Ahora eres peligroso

¿Recuerdas ese deploy del viernes? ¿El que te saltaste la verificación de staging y pasaste tu sábado reconstruyendo una base de datos?

Ahora tienes tres checklists que previenen exactamente ese tipo de falla. No a través de disciplina, no a través de fuerza de voluntad — a través de un sistema que asume que tu cerebro va a fallar bajo presión y lo atrapa antes de que importe.

Los checklists no son cuestión de disciplina. Son cuestión de humildad. Un reconocimiento de que tu cerebro — por afilado que sea — no puede ejecutar de manera confiable 15 pasos secuenciales bajo estrés sin saltarse uno. Los pilotos lo saben. Los cirujanos lo saben. Los astronautas lo saben.

Tech es la única industria donde profesionales experimentados todavía dicen "no necesito un checklist, ya lo hice mil veces". Eso no es confianza. Esa es la frase que precede a cada incidente prevenible.

Escribe el checklist. Sigue el checklist. Actualiza el checklist. Tu entorno de producción te lo va a agradecer. Y también la persona que recibe la alerta a las 2 AM — y esa persona podrías ser tú. 🛁