Cuando suena el teléfono, necesitas un plan claro. Aquí vas a encontrar cómo actuar con triage disciplinado, comunicación transparente y post‑mortems útiles para que el equipo que despliega a producción también maneje sus incidentes, reduzca el estrés y evite repetir errores.

¿Quién debe manejar los incidentes y cómo decidir con triage?

En lugar de delegar siempre a infraestructura, la propuesta es que quien envía el software a producción se haga cargo. Servicios como Pager Duty pueden alertarte y escalar si no respondes, pero asumir el incidente implica liderazgo y foco desde el primer minuto.

¿Qué significa estar on call y asumir el incidente?

• Confirmar: “lo manejo yo” y evitar escalación innecesaria.
• Abrir un canal de comunicación con el equipo desde el inicio.
• Registrar cada acción en un timeline para no repetir pasos.
• Usar logs y dashboards para validar hipótesis rápido.
• Mantener la compostura y trabajar con calma.

¿Cómo aplicar triage y priorizar?

• Evaluar impacto: ¿es pequeño o significativo?.
• Si es menor, marcar como resuelto o diferir con criterio.
• Si es importante, medir alcance y abrir comunicación con el equipo.
• Documentar: “ya verifiqué X, Y, Z” para evitar retrabajo y preguntas.

¿Cómo comunicar con status page y evitar escalación y tickets?

La comunicación es crucial. Tanto si afecta a clientes externos como si es interno, anunciar el estado reduce ruido, evita duplicar esfuerzos de soporte y genera confianza.

¿Qué y cuándo informar a clientes internos o externos?

• Publicar en el status page o canal interno: “sabemos que hay un problema y estamos trabajando”.
• Actualizar por etapas: “identificamos”, “estamos arreglando”, “enviamos la fix a producción”, “estamos monitoreando”.
• Cerrar como resuelto cuando haya confianza real en la estabilidad.
• Recordar: una buena comunicación evita tickets, tuits y pánico innecesario.

¿Por qué la comunicación reduce estrés y errores?

• Evita interrupciones de soporte con preguntas repetidas.
• Disminuye el ruido que aumenta el estrés durante el incidente.
• Centraliza respuestas en un solo lugar y muestra transparencia.
• Es el primer paso práctico de un buen incident response.

¿Qué incluye un post-mortem y cómo compartir el aprendizaje?

Cuando termina el incidente, el trabajo clave comienza. Un buen post‑mortem es donde aprendes, previenes regresiones y ayudas a que la organización mejore de forma concreta.

¿Cómo usar el timeline después del incidente?

• Reconstruir la secuencia de eventos con fecha y acciones.
• Usarlo para entender decisiones y tiempos de reacción.
• Publicarlo interno si aporta claridad, aunque no siempre es necesario.

¿Qué debe contener un post-mortem efectivo?

• Qué falló y por qué falló.
• Cómo no nos dimos cuenta antes.
• Qué haremos al respecto para mejorar.
• Ejemplos útiles: faltó un log; no había timeout; manejo de errores incorrecto cuando Facebook no estaba disponible.
• Datos para contexto: fecha, cantidad de errores, tiempo de downtime.
• Un resumen claro para clientes y una disculpa honesta cuando aplique.
• Contexto técnico y gráficas que sirvan para aprender internamente.
• Difusión interna: un blog post interno ayuda a que otros equipos eviten el mismo problema, sin perseguir a nadie.

Consejo práctico: si el teléfono suena por lo mismo otra vez, no te castigues, arregla la causa raíz y compártelo dentro del equipo para que no vuelva a pasar.

¿Qué prácticas te han funcionado cuando estás on call? Comparte tu experiencia y enfoques para mejorar el incident response de tu equipo.