Nombre del procedimiento

:::note Cómo usar esta plantilla

1. Copia este archivo a docs/runbooks/<slug-del-runbook>.md (kebab-case, descriptivo).
2. Ajusta el frontmatter:
   • id: identificador corto en mayúsculas (ej. RB-RESTART-WORKERS).
   • owner: equipo o persona responsable del procedimiento. Acepta handles (@usuario) o teams (@org/team).
   • severity: nivel del incidente al que aplica este runbook.
     • P0: caída total / pérdida de datos / impacto a clientes
     • P1: degradación severa de producción
     • P2: degradación parcial o recurrente
     • P3: issue menor / mantenimiento planeado
   • last_tested: última vez que el procedimiento se ejecutó (en drill o producción) y se verificó que funciona. Entre comillas para evitar que YAML lo interprete como Date.
   • on_call: handle de quien está actualmente on-call para este servicio (opcional; puede rotar).
3. Actualiza sidebar_label a un nombre corto.
4. Borra este bloque :::note.
5. Completa las secciones de abajo. El H1 y la metadata se renderizan automáticamente desde el frontmatter.

:::

When to use

Describir la condición que dispara este runbook. Ej: "Alerta worker_queue_depth > 1000 durante más de 5 min".

Preconditions

• Acceso a kubectl del cluster prod.
• Credenciales activas en @eigenoid/platform.
• ...

Procedure

1. Paso 1: verificar el estado actual.

   kubectl get pods -n workers

2. Paso 2: aplicar la mitigación.

   kubectl rollout restart deployment/workers -n workers

3. Paso 3: verificar que se estabilizó.

Verification

Cómo confirmar que el procedimiento funcionó. Métricas, logs, endpoints a revisar.

Rollback

Si algo sale mal, cómo revertir.

Escalation

A quién escalar si el runbook no resuelve. Ej: @oncall-lead o el team @eigenoid/platform.

References

• Dashboards relacionados.
• Alertas que lo disparan.
• ADRs relevantes.