Las caidas parciales son de las incidencias que mas tiempo roban en guardia. No tumban todo, asi que nadie entra en modo panico total, pero si rompen suficiente como para llenar Slack, dashboards y tickets a la vez. En equipos SRE esto pasa un monton: una region responde lento, un worker consume mensajes con atraso, o una dependencia externa empieza a fallar solo en ciertos caminos.
Con los años me sirvio una idea simple: el runbook para una degradacion parcial no debe listar veinte comandos. Debe ayudar a decidir rapido si el problema es capacidad, dependencia, despliegue, red o datos. Cuando el documento falla en eso, la guardia se vuelve lenta y cada persona investiga un universo distinto.
Por que una caida parcial confunde mas que una total
Cuando todo cae, el objetivo es obvio. Cuando cae solo una parte, los sintomas se pelean entre si:
- El uptime general sigue "verde".
- Solo un porcentaje de usuarios ve errores.
- Los logs muestran ruido, pero no una firma unica.
- La gente empieza a asumir causas demasiado pronto.
Segun el libro Site Reliability Engineering de Google, la claridad operacional y la reduccion del toil son parte central del trabajo SRE, no un lujo documental (Google SRE Book). En incidentes parciales eso se nota enseguida: si tu primer documento no reduce incertidumbre, ya vas tarde.
Tambien he visto que los equipos mezclan evidencia de producto, pruebas y experimentos internos. Ese desorden se parece mucho a evitar mezclar corridas cuando el flujo se complica: si no separas contexto desde el inicio, cada dato parece sospechoso y el triage se pone mas lento.
El runbook que me ha funcionado en guardias reales
Mi version favorita cabe en una pantalla y sigue cinco preguntas:
- Que superficie esta degradada exactamente.
- Desde cuando ocurre y que cambio coincide.
- Si el impacto depende de region, tenant o tipo de trafico.
- Que metrica decide si vamos mejorando.
- Cual es la accion segura de menor costo.
Ese orden importa. Mucha gente abre primero los logs de aplicacion, pero en varias guardias lo mas util fue empezar por diffs de despliegue, errores por zona y una metrica de saturacion. No suena heroico, pero evita perder media hora persiguiendo sintomas secundarios.
Un runbook base podria verse asi:
# 1. Confirmar alcance
kubectl get pods -n payments -o wide
kubectl top pods -n payments
# 2. Revisar eventos recientes
kubectl get events -n payments --sort-by=.lastTimestamp | tail -n 20
# 3. Comparar despliegue actual vs anterior
kubectl rollout history deploy/payments-api -n payments
# 4. Ver errores por region o tenant en observabilidad
# aqui entra tu consulta en Grafana, Datadog o CloudWatch
No es magico, claro. Lo util es que obliga a mirar estado, cambio y alcance antes de tocar cosas. Esa pausa de dos minutos evita decisiones medio apresuradas.
Que evidencia reunir antes de tocar nada
Si el runbook no define evidencia minima, cada persona captura algo distinto. Yo intento pedir siempre estas piezas:
- Una metrica principal de impacto.
- El ultimo cambio conocido en la ventana del incidente.
- Una lista corta de componentes sanos y degradados.
- Un ejemplo concreto de request fallida con timestamp.
- Un criterio de rollback o mitigacion.
Parece basico, pero no siempre esta escrito. Y cuando no esta, el canal del incidente se llena de "creo que" o "parece que". Eso desgasta bastante. Tambien ayuda mucho hacer pruebas reales sin perder claridad operativa: si distingues trafico de prueba, seeds raros y notas como temp mailid desde el principio, quitas ruido que luego parece señal util aunque no lo sea.
En AWS, por ejemplo, un cambio de seguridad en una cola o un timeout mas agresivo entre servicios puede dejar solo una franja de requests en mal estado. Ahí conviene mirar dependencia por dependencia y no asumir que "cloud esta fallando". Dicho asi suena obvio, pero en una guardia cansada no siempre lo es.
Como escribir alertas que ayudan de verdad
Una alerta buena no intenta contar toda la historia. Solo debe entregar contexto suficiente para que la primera persona no empiece desde cero.
Yo suelo revisar estas cuatro partes:
- Sintoma observable:
5xx en checkout suben al 8% - Alcance:
principalmente tenant enterprise en eu-west - Cambio cercano:
deploy 2026.08.18-3 hace 11 min - Siguiente paso:
comparar latencia de Redis y rollout actual
Eso le gana por mucho a una alerta generica de "high error rate". El informe de PagerDuty sobre incident response ha repetido varios años que la velocidad inicial depende bastante del contexto util, no solo de detectar mas rapido (PagerDuty Incident Response Report). No hace falta memorizar el PDF completo; basta entender que una alerta muda obliga al humano a reconstruir el escenario desde cero.
Tambien me gusta dejar un mini checklist al final del runbook:
- Confirmar si el impacto sigue creciendo.
- Verificar cambio mas cercano al inicio del fallo.
- Aislar componente comun entre requests rotas.
- Elegir mitigacion reversible primero.
- Registrar que señal confirma mejora.
Es una tonteria pequeña, pero funciona. En guardia nocturna el cerebro agradece esos pasos medio obvios.
Preguntas frecuentes
Un runbook parcial debe ser muy detallado?
No necesariamente. Debe ser especifico en decisiones, no largo por deporte. Si ocupa tres pantallas y aun asi no deja claro que mirar primero, esta flojito.
Conviene ligar el runbook a una sola herramienta?
Mejor no. Puedes poner ejemplos en Grafana o CloudWatch, pero el valor real esta en la secuencia mental: alcance, cambio, evidencia, mitigacion. Esa parte deberia sobrevivir aunque cambie la herramienta.
Esto sirve solo para Kubernetes?
No. Kubernetes aparece mucho en SRE, pero la idea funciona igual para colas, bases de datos, workers o integraciones externas. Lo importante es evitar que cada guardia reescriba el metodo sobre la marcha.
Si hoy tus incidentes parciales duran demasiado, yo empezaria por rehacer dos runbooks clave con esta estructura. No arregla la plataforma por si sola, obvio, pero baja friccion, mejora el diagnostico y le da al equipo una base comun para responder mejor.
Top comments (0)