Departamento · Operaciones & Infraestructura
El runbook debería saber que la infra cambió.
Runbooks y postmortems verificados contra el sistema real, drift señalado antes de la guardia y contexto en el copiloto de incidente.
Escenario
Cómo circula el contexto cuando ValorBrain está en el flujo.
- 01
La verificación del runbook de failover del gateway de pagos contra el sistema real encuentra que el hostname documentado difiere del ingress actual en el k8s.
- 02
El runbook queda marcado como divergente, con el owner y la fecha de la última verificación.
- 03
La divergencia se vuelve revisión para sre/plataforma, no sorpresa en medio del incidente.
- 04
Un incidente parecido recupera los postmortems anteriores, con lo que funcionó y la fuente de cada decisión.
- 05
El copiloto de incidente parte del historial en vez de redescubrir la causa.
- 06
Lo que quedó aprendido la última vez aparece en la primera respuesta de esta.
- 07
Quien entra al on-call recibe en el bootstrap de la sesión lo que cambió desde el último turno: drift en revisión, handoff pendiente, decisión nueva.
- 08
El handoff entre turnos y agentes se enruta con estado, y no se resume de memoria.
- 09
La guardia empieza por lo que cambió, no por lo que el runbook olvidó.
Preguntas frecuentes
Ya tenemos wiki de ops y postmortems escritos.
Siguen, como fuente. La diferencia: aquí la documentación se verifica contra el sistema real, el drift se vuelve alerta con owner, y el postmortem correcto aparece en el momento del incidente parecido.
¿Qué hace exactamente una reality probe?
Compara la documentación con el sistema real y señala divergencia para revisión humana, registrando owner y fecha de la verificación. Apunta el problema; arreglarlo sigue siendo trabajo del equipo.
¿Y si el postmortem anterior está equivocado?
Cada registro tiene fuente, autor y fecha. Las correcciones se vuelven versiones nuevas, con la anterior superada en el historial, y el conflicto entre fuentes se señala para revisión.
¿Qué prueba hay de que la recuperación funciona?
Internamente medimos LoCoMo R@10 de 96,58% (1986 preguntas, +2,1 puntos sobre el líder open-source publicado) y media de 75,5% (binario 80,8%) en BEAM-100K, con metodología abierta. Benchmarks internos de recuperación; no son peer-reviewed ni QA end-to-end. Para operaciones, la prueba cotidiana es el drift señalado antes de la guardia, no después.
Próximo paso
Menos volver a empezar. Más continuidad
Trae un proyecto real. En una conversación mapeamos dónde se pierde el contexto entre las personas y los agentes de tu equipo, y por dónde empezar.