Planteamiento y alcance
Esta es una pregunta conductual sobre criterio y colaboración, no una solicitud para relatar detalles de una interrupción del servicio. Explica cómo los disparadores acordados previamente ayudan a evaluar el impacto en los usuarios, la calidad de la respuesta, el riesgo de recurrencia y el valor de aprendizaje, para luego transformar la decisión en una revisión útil y libre de culpas. Google SRE recomienda realizar postmortems ante eventos indeseables significativos; los disparadores comunes incluyen la degradación visible para el usuario, la pérdida de datos, la intervención mediante rollback, una resolución que excede un umbral determinado y fallas en el monitoreo. Cualquier parte interesada también puede solicitar uno.
Qué evalúa el entrevistador
- Si traduces un “impacto pequeño” en métricas observables y umbrales explícitos.
- Si separas la contención del aprendizaje y evitas tratar el postmortem como una búsqueda de culpables o un concurso de redacción.
- Si puedes proponer alcances ligeros y completos en lugar de una elección binaria.
- Si las acciones cuentan con responsables asignados, fechas límite y evidencia de verificación.
- Si te comunicas de manera respetuosa y haces que el aprendizaje sea valioso para los equipos relacionados.
Preguntas aclaratorias para hacer
- ¿Qué fracción de las solicitudes, usuarios, presupuesto de error de SLO y valor de negocio se vio afectada durante los 18 minutos?
- ¿El evento requirió un rollback, intervención manual, pasó desapercibido para el monitoreo o repitió una falla similar?
- ¿El equipo ya cuenta con criterios para postmortems, niveles de severidad y seguimiento de acciones?
- ¿Quién necesita el resultado y existen implicaciones de privacidad, cumplimiento normativo o comunicación externa?
- ¿Se necesita un informe completo o una revisión breve puede responder a las preguntas importantes?
Una respuesta de 30 segundos
“No tomaría una decisión basándome en que 'solo fueron 18 minutos'. Aplicaría los criterios acordados previamente para la proporción del impacto, la visibilidad para el usuario, el presupuesto de error, la intervención con rollback, la calidad del monitoreo y el riesgo de recurrencia. Dado que los usuarios vieron fallas y se produjo un rollback, al menos realizaría una revisión breve y libre de culpas con una cronología, impacto, respuesta y dos o tres acciones de alto valor; la evidencia puede ampliarlo a un informe completo. Cada acción necesita un responsable, fecha de entrega y señal de verificación, y luego debe pertenecer al backlog del equipo o al proceso de guardia hasta su cierre”.
Análisis detallado paso a paso
Paso 1: Aplicar un estándar de disparadores
Ubica el evento en el modelo de severidad existente: impacto en el usuario, duración, consumo del presupuesto de error, integridad de datos, rollback manual, falla del monitoreo y respuesta interequipos. Define los umbrales antes de los incidentes para que no se modifiquen después a conveniencia de un equipo en particular. Dieciocho minutos no es una conclusión definitiva; una falla parcial sumada a un rollback ya cumple con el disparador de revisión ligera para muchos equipos.
Paso 2: Elegir la profundidad de la revisión
Un postmortem completo incluye una cronología, evaluación del impacto, causas raíz y contribuyentes, efectividad de la respuesta y acciones preventivas. Si el impacto es pequeño y se comprende bien una causa, comienza con una revisión acotada a 30 minutos para evaluar el riesgo de recurrencia y amplíala solo cuando la evidencia lo exija. Ligero significa menos participantes, páginas y acciones, no omisión de hechos.
Paso 3: Mantenerse libre de culpas y guiado por la evidencia
Asume que las personas tomaron decisiones razonables con la información disponible y analiza cómo el sistema facilitó la falla: mecanismos de protección en el despliegue, alertas, permisos, runbooks o falta de contexto. Evita conclusiones como “alguien olvidó verificar”, ya que no permiten modificar el sistema. Cita logs, registros de cambios e historial de comunicación, e identifica explícitamente las incógnitas en lugar de llenarlas con suposiciones.
Paso 4: Hacer que las acciones sean ejecutables
Define un responsable, fecha límite, prioridad, dependencia y evidencia de finalización para cada acción. Los ejemplos incluyen una verificación de estado previa al despliegue, un simulacro de rollback o un umbral de alerta corregido. “Tener más cuidado” y “agregar pruebas” no constituyen criterios de aceptación. Incorpora las acciones en el backlog y revísalas en función de un SLO acordado; Google SRE señala que un postmortem sin acciones de seguimiento no mejora la confiabilidad.
Paso 5: Resolver los desacuerdos entre las partes interesadas
Explica al product manager el costo de la revisión y el valor que aporta para prevenir recurrencias, y aclara el límite del impacto al ingeniero que solicita un informe extenso. Ofrece una sesión acotada en tiempo: publica primero una página de hechos y acciones, y luego amplíala si la evidencia lo justifica. Si alguna parte interesada considera que el evento amerita una revisión, registra el motivo e inclúyelo en la evaluación en lugar de permitir que la jerarquía lo vete.
Paso 6: Verificar el cierre y los límites de divulgación
Tras la publicación, verifica el estado de las acciones, las alertas repetidas, los despliegues similares y las tendencias en el presupuesto de error. Elimina identificadores de usuario y detalles confidenciales según la audiencia, mientras compartes las conclusiones con los equipos que puedan beneficiarse. Una revisión no debe convertirse en una exposición pública punitiva, pero las restricciones de acceso excesivas también aumentan la probabilidad de que la falla se repita. Conserva la evidencia y la versión final para futuras auditorías y aprendizaje.
Ejemplo de respuesta de alta calidad
“Aplicaría la severidad y los disparadores de postmortem definidos antes del incidente en lugar de decidir a partir de los 18 minutos. Las fallas visibles para el usuario y la intervención con un rollback justifican al menos una revisión acotada en tiempo y libre de culpas que cubra el impacto, la cronología, la respuesta y el riesgo de recurrencia. Citaría logs y registros de cambios, separaría la causa raíz de los factores contribuyentes y solo pasaría a un informe completo si el monitoreo, las salvaguardas de despliegue o los runbooks revelan una brecha sistémica. Cada acción recibe un responsable, fecha límite, prioridad y señal de verificación en el backlog. Le explicaría el costo y el valor de prevención de recurrencias al product manager, mantendría el alcance controlado para el ingeniero que pide un informe extenso y compartiría un resultado con datos confidenciales suprimidos con los equipos que se beneficien. El cierre requiere evidencia de que las acciones concluyeron y los incidentes similares disminuyeron”.
Errores comunes
- Considerar únicamente la duración e ignorar la proporción de usuarios afectados, el presupuesto de error, el rollback y las fallas de monitoreo.
- Convertir el postmortem en una investigación punitiva que lleve al personal de guardia a ocultar información.
- Enumerar docenas de acciones solo por completitud, sin asignar responsables ni evidencia de finalización.
- Reemplazar los criterios de aceptación con frases como “probar más” o “tener más cuidado”.
- Cancelar la revisión simplemente porque un interesado de producto afirma que es innecesaria.
- Redactar el documento sin hacer seguimiento de las acciones ni comprobar si los incidentes similares disminuyen.
Preguntas de seguimiento y respuestas
¿Qué pasa si el equipo no cuenta con un estándar común para postmortems?
Presenta la evidencia actual: impacto en usuarios, presupuesto de error, rollback, monitoreo y riesgo de recurrencia. Utiliza este incidente para proponer una lista de verificación básica de disparadores y consensuar la siguiente versión con el equipo. No inventes una política compleja en medio del incidente.
¿Qué sucede si la revisión revela que una persona cometió un error evidente?
Registra la información y las limitaciones del sistema que rodearon la decisión, y luego analiza cómo los procesos, herramientas o capacitaciones pueden reducir la recurrencia. Las violaciones intencionales de políticas o los problemas de seguridad pueden gestionarse a través de un proceso administrativo independiente; mantén el postmortem libre de culpas para preservar con claridad su propósito de aprendizaje.
¿Cómo demuestras que una revisión breve fue suficiente?
Debe responder sobre el impacto, la cronología, la respuesta, la hipótesis de la causa raíz y las acciones, para luego comprobar la evidencia de las acciones y las métricas similares en el plazo acordado. La presencia de impacto desconocido, dependencias entre equipos o riesgo de recurrencia debe ampliar el alcance; una extensión breve por sí sola no es sinónimo de finalización satisfactoria.