03:07 AM. Suena el pager

Escena ficticia, basada en patrones reales.

Laura, ingeniera de backend, lanzó un script de migración a las 23:40. A las 03:07 el dashboard está en rojo: el checkout no responde, la tasa de errores se dispara y el canal #incidents empieza a llenarse de mensajes.

Laura sabe que fue su script. Y tiene unos segundos para decidir algo que no aparece en ningún runbook: ¿lo dice en voz alta o espera a ver si alguien lo descubre?

Esa decisión no depende de su seniority ni de su stack. Depende de lo que pasó la última vez que alguien del equipo dijo «he sido yo». Si aquella vez hubo gritos, señalamientos en la daily o un correo con copia a dirección, Laura callará. Y cada minuto de silencio alarga el MTTR.

Este post va de ese momento. De cómo la reacción de un líder ante un incidente define si el siguiente se reporta en minutos o se esconde durante semanas.

Cada minuto de silencio tiene precio

Un incidente que se esconde no desaparece: se encarece. Y las cifras de downtime ya son altas cuando todo el mundo habla.

Dato	Fuente
Más del 90% de las medianas y grandes empresas declara que una hora de caída les cuesta más de 300.000 $	ITIC 2024 Hourly Cost of Downtime Survey (más de 1.000 empresas)
El 41% sitúa ese coste entre 1 y más de 5 millones de dólares por hora	ITIC 2024, vía Dotcom-Monitor
La mediana de un outage de alto impacto es de 2 millones de dólares por hora	New Relic, 2025 Observability Forecast, vía Virima
El 54% afirma que su último outage significativo costó más de 100.000 $	Uptime Institute, análisis 2025, vía ManageEngine

Son datos autodeclarados por las empresas encuestadas y varían mucho según sector y tamaño. Aun así, el mensaje es claro: el tiempo que tarda alguien en decir «creo que he sido yo» se mide en dinero. La cultura del equipo es, literalmente, una variable del MTTR.

Tres formas de recibir al mensajero

El sociólogo Ron Westrum clasificó las organizaciones según cómo procesan la información. DORA, el programa de investigación de Google sobre DevOps, usa su modelo para explicar el rendimiento de los equipos de software. La fila clave es la del mensajero: quien trae la mala noticia.

Tipo de cultura	Orientación	Qué le pasa al mensajero	A las 03:07, Laura…
Patológica	Al poder	Se le castiga	…calla y reza
Burocrática	A las reglas	Se le ignora	…abre un ticket y espera
Generativa	Al rendimiento	Se le forma	…escribe «he sido yo» en #incidents

Fuente: DORA, Generative organizational culture. La última columna es una adaptación nuestra.

No es solo una cuestión de buen ambiente. Según Google Cloud, el informe Accelerate State of DevOps de 2023 confirma que una cultura generativa sigue prediciendo un mayor rendimiento en la entrega de software y en la organización. Y el informe DORA de 2019 concluyó que una cultura de seguridad psicológica, confianza y respeto contribuye a la productividad y al rendimiento.

La investigación de Amy Edmondson apunta en la misma dirección: en un estudio de 51 equipos encontró una asociación entre sentirse seguro para asumir riesgos interpersonales y conductas como pedir ayuda o reconocer errores. El propio estudio no permite demostrar causalidad (Prevención Integral).

Caso 1. GitLab, 2017: el rm -rf en la terminal equivocada

Noche del 31 de enero de 2017. Una réplica de PostgreSQL de GitLab.com se había quedado demasiado atrás y un ingeniero intentaba resincronizarla. Para eso había que vaciar el directorio de datos de la réplica. El comando se ejecutó en la terminal equivocada: la de la base de datos primaria.

El ingeniero se dio cuenta en segundos y lo cortó, pero el daño estaba hecho. Al intentar restaurar, el equipo descubrió algo peor: los mecanismos de backup llevaban semanas fallando sin que nadie lo supiera.

El balance, según los análisis publicados del incidente:

•          Unas 18 horas de caída.

•          Unas 6 horas de datos perdidos: alrededor de 5.000 proyectos, 5.000 comentarios y 700 cuentas de usuario.

Lo interesante es lo que GitLab hizo después. En vez de buscar un culpable, abrió el incidente al mundo: notas en directo en un Google Doc público, actualizaciones en redes y la restauración retransmitida en YouTube. Diez días después publicó un postmortem completo, con los detalles incómodos incluidos.

Ese postmortem no se quedó en «un ingeniero borró producción». Fue más hondo: una carga anómala ligada a un sistema antispam había provocado el desfase de la réplica, y nadie tenía asignada la responsabilidad de verificar que los backups se podían restaurar. El error humano fue el disparador, no la causa raíz.

Fuentes: The Hacker News, Stork.ai, Byte-Sized Design. El postmortem original está en el blog de GitLab: GitLab.com database incident.

Caso 2. AWS S3, 2017: el typo que apagó media internet

28 de febrero de 2017. Un miembro autorizado del equipo de S3 depuraba un problema en el sistema de facturación siguiendo un playbook. El comando debía retirar unos pocos servidores. Un error en un parámetro de entrada hizo que retirara muchos más, en dos subsistemas críticos de la región us-east-1.

S3 estuvo caído entre las 9:37 y las 13:54 (hora del Pacífico) aproximadamente, y con él una parte enorme de los servicios web que dependían de esa región. El detalle más irónico: el propio Service Health Dashboard de AWS, la página que los clientes consultan para saber si AWS está caído, también estaba alojado en S3 en us-east-1.

¿Qué hizo Amazon? Publicar esa misma semana un resumen técnico público. Y la pregunta que planteó no fue «quién tecleó mal», sino por qué un solo comando podía retirar tanta capacidad. La respuesta fue de ingeniería: la herramienta se modificó para retirar capacidad más despacio y para negarse a dejar un subsistema por debajo de un mínimo seguro.

Ahí está la lección para cualquier tech lead: un typo no debería poder tumbar producción. Si puede, el bug está en el sistema, no en los dedos de quien teclea.

Fuentes: Resumen oficial de AWS, BleepingComputer, Engineering Playbook, Zof.ai.

Blameless no significa consequence-less

El concepto no lo inventó Silicon Valley. Según el libro de SRE de Google, la cultura sin culpables nació en la sanidad y la aviación, sectores donde un error puede ser mortal y cada fallo se trata como una oportunidad para reforzar el sistema.

En software, el texto fundacional es de John Allspaw, entonces responsable de operaciones técnicas de Etsy: «Blameless PostMortems and a Just Culture», publicado en mayo de 2012. Su idea central es la Just Culture: buscar el equilibrio entre seguridad y responsabilidad. Quien participa en un fallo puede contar con detalle qué hizo, qué esperaba y qué supuso, sin miedo a represalias (Scrum Expert, InfoQ).

Google lo convirtió en práctica estándar de SRE. Su criterio, según recoge incident.io: un postmortem es realmente blameless cuando identifica las causas que contribuyeron al incidente sin acusar a ninguna persona ni equipo. Y su SRE Workbook afirma que, en su experiencia, una cultura de postmortems verdaderamente sin culpables produce sistemas más fiables.

Blameless SÍ es	Blameless NO es
Preguntar «¿qué permitió que pasara?»	Fingir que no pasó nada
Responsabilidad orientada al futuro: acciones, owners, fechas	Ausencia de seguimiento o de acciones correctivas
Arreglar el sistema: guardrails, automatización, permisos	Pedir «tener más cuidado» la próxima vez
Reconocer a quien reporta rápido	Tolerar negligencias repetidas o deliberadas

La tabla es una síntesis nuestra a partir de estas fuentes. Un matiz importante: blameless tampoco significa culparse a uno mismo. El objetivo es entender el sistema, no castigar a nadie, tampoco a quien se equivocó.

Manual del líder a las 3 AM

La cultura no se declara en una presentación de onboarding. Se demuestra en el canal #incidents, en directo. Estas son las prácticas que proponemos en Sandav, inspiradas en las fuentes de este post.

Durante el incidente

1.          Tu primera frase marca el tono. «Gracias por avisar rápido» vale más que cualquier política escrita.

2.        Primero mitigar, luego entender. Restaurar el servicio es lo urgente. El «por qué» llega en el postmortem.

3.        Prohibido el «¿quién ha sido?». Cambia la pregunta por «¿qué sabemos y qué necesitamos?».

4.        Roles claros. Un incident commander, alguien en comunicación y quien ejecuta. GitLab, en su incidente, dio a una persona autoridad para parar todo si los datos corrían riesgo.

Después del incidente

5.        Postmortem siempre, no solo cuando hay daños. Etsy documentaba también los casi-incidentes y los compartía con toda la empresa.

6.        Busca la segunda historia. Si la conclusión es «error humano», no has terminado: pregunta qué hizo posible ese error.

7.        Acciones con dueño y fecha. Un postmortem sin acciones es un relato. Uno con acciones es un parche.

8.        Comparte y premia. Publica los postmortems dentro de la organización y reconoce públicamente a quien reportó primero.

La prueba de fuego es sencilla: la próxima vez que alguien escriba «he sido yo» en el canal, ¿cuántos minutos tarda en hacerlo?

Plantilla mínima de postmortem blameless

Cópiala, adáptala y úsala en el próximo incidente. Es una propuesta de Sandav basada en las prácticas de Google SRE y Etsy.

# Postmortem: [título del incidente]
Fecha · Severidad (SEV-1/2/3) · Incident commander

## Resumen
Qué pasó, en 3 líneas. Impacto en usuarios y duración.

## Timeline
HH:MM — detección
HH:MM — escalado
HH:MM — mitigación
HH:MM — resolución

## Causas que contribuyeron
(Sistemas, procesos, herramientas. Sin nombres propios.)

## Qué funcionó bien

## Dónde tuvimos suerte

## Acciones
| Acción | Owner | Fecha |

Una regla de estilo: escribe el postmortem como si lo fuera a leer la persona que cometió el error. Porque lo va a leer.

El patch que necesita tu cultura

Volvamos a Laura, a las 03:07. En un equipo con cultura patológica, el incidente se alarga mientras ella decide si arriesgarse. En uno generativo, su mensaje llega en el primer minuto, el equipo mitiga en veinte y el postmortem del jueves termina con dos guardrails nuevos en el pipeline.

La diferencia entre ambos equipos no está en el stack. Está en cómo reaccionó su líder la última vez.

En Sandav montamos y reforzamos equipos IT que trabajan así: perfiles técnicos que se integran en tus procesos de incident management, tus on-calls y tus postmortems desde el primer día. Si estás escalando tu equipo de ingeniería y quieres que la cultura escale con él, hablemos.