La llamada que cambió mi perspectiva
Eran las 11pm cuando llamó el CEO. El sistema de pagos estaba caído. No era la primera vez. Era la tercera en el mes.
Lo que me dijo no fue "arreglalo". Fue: "Nuestro cliente más grande acaba de escribirme. Dice que si esto pasa una vez más, se va."
En ese momento entendí que la confiabilidad no era un problema técnico. Era un problema de negocio.
Confiabilidad no es uptime
El error más común que veo en equipos de ingeniería es pensar que confiabilidad = uptime. Son relacionados, pero no son lo mismo.
Un sistema puede tener 99.95% de uptime y aun así generar desconfianza si cada caída ocurre en el momento equivocado, dura demasiado, o la comunicación es pobre.
La confiabilidad real tiene tres dimensiones:
Disponibilidad — el sistema funciona cuando el usuario lo necesita.
Recuperación — cuando algo falla, cuánto tardás en volver. El MTTR (Mean Time To Recovery) importa más que el MTBF (Mean Time Between Failures).
Confianza — cómo comunica tu equipo durante y después de un incidente. Un postmortem bien escrito puede convertir un incidente en un activo de confianza con el cliente.
El framework que implementé
Después de esa llamada del CEO, implementamos un sistema de tres capas:
Capa preventiva
- SLOs definidos por flujo de negocio, no por servicio técnico
- Budget de error explícito por mes
- Alertas que despiertan personas solo cuando el SLO está en riesgo
Capa reactiva
- Runbooks para los 10 incidentes más frecuentes
- Definición clara de severidades (P1/P2/P3) con tiempos de respuesta
- Comunicación proactiva al cliente antes de que pregunte
Capa de aprendizaje
- Postmortem blameless dentro de las 48 horas del incidente
- Una acción de mejora por postmortem, con dueño y fecha
- Review mensual de tendencias de incidentes con el negocio
El resultado tres meses después
Los incidentes no desaparecieron. Eso no es realista. Lo que cambió fue cómo los manejamos y cómo los comunicamos.
El cliente que amenazaba con irse renovó el contrato. No porque dejamos de tener problemas, sino porque cuando los tuvimos, supimos cómo responder.
La acción que podés tomar esta semana
Agarrá el último incidente de tu equipo y escribí un postmortem en este formato simple:
¿Qué pasó? (2 párrafos, sin culpables)
¿Cómo lo detectamos?
¿Cómo lo resolvimos?
¿Qué vamos a cambiar?
Compartilo con el equipo. Si podés, compartilo también con el cliente afectado.
La transparencia construye más confianza que la perfección.
¿Cómo manejás los postmortems en tu equipo? Escribime a [email protected]