# Incident Response — Fundamental Skill

Skill para manejar incidentes en producción. Usar cuando algo se rompe — seguir esta guía sin improvisar.

---

## Niveles de severidad

### P1 — Crítico 🔴
Sistema caído o unusable. Impacto en ingresos o datos.
- Site completamente caído, pérdida de datos, brecha de seguridad, core inaccesible
- **Respuesta**: Todo el equipo. War room inmediata.
- **SLA**: Respuesta en 5 min. Resolución objetivo: 1 hora.

### P2 — Alto 🟠
Funcionalidad importante degradada con workaround.
- Feature lenta/errores intermitentes, página secundaria caída, emails no se envían
- **Respuesta**: Equipo responsable prioriza sobre trabajo planeado.
- **SLA**: Respuesta en 15 min. Resolución objetivo: 4 horas.

### P3 — Medio 🟡
Bug no crítico. No afecta operación.
- Bug visual, feature secundaria con error, problema de performance sin impacto
- **Respuesta**: Se planifica en sprint actual o siguiente.
- **SLA**: Respuesta en 1 hora. Resolución: próximo release.

---

## Primeros 15 minutos

**00:00** — Detectás el incidente
- No entres en pánico. Anotá hora exacta. Copiá mensaje textual de alerta/usuario.

**00:01** — Confirmá que es real
- Reproducí desde otra sesión. ¿Una persona o generalizado? ¿Deploy reciente (< 2h)?

**00:03** — Abrí canal de comunicación
- #alerts: "INCIDENT: [descripción breve]. Investigando. Actualizaré cada 10 min."
- Si P1, iniciá call de voz. Asigná rol de comunicador.

**00:05** — Diagnóstico inicial
- Dashboard de monitoreo: errores, latencia, throughput.
- Logs recientes filtrando ERROR. Si hay deploy reciente, es el sospechoso #1.
- Alcance: ¿todos los usuarios? ¿una región? ¿un endpoint?

**00:10** — Decidir: rollback o fix forward
- Si deploy reciente → rollback inmediato. No debuguees.
- Sin deploy → investigar causa raíz: ¿pico de tráfico? ¿dependencia caída? ¿DB lenta?
- Documentá hipótesis en el thread.

**00:15** — Actualizá al equipo
- "UPDATE [15 min]: Esto sabemos, esto hacemos, este es el ETA."
- Sin avance → escalá. Mejor pedir ayuda a los 15 min que a las 2 horas.
- P1 sin resolución → notificá liderazgo.

---

## Templates de comunicación

### Inicio (#alerts)
```
🚨 INCIDENT: [Título]
Severidad: P1 / P2 / P3
Scope: [% usuarios / endpoint / región]
Inicio: [HH:MM UTC]
Estado: Investigando
Actualizaré cada 10 minutos. No deploy hasta nuevo aviso.
```

### Update (#alerts, cada 10-15 min)
```
📡 UPDATE [HH:MM UTC] — +10 min
Lo que sabemos: [hallazgos]
Lo que hacemos: [acción actual]
Próximo paso: [siguiente acción]
ETA: [si se conoce]
```

### Resolución (#alerts)
```
✅ RESUELTO [HH:MM UTC] — [duración]
Causa: [una frase]
Qué hicimos: [acción concreta]
Impacto: [usuarios, datos, duración]
Postmortem: [link]
```

---

## Postmortem

### Template
1. **Resumen**: Qué pasó, a quién afectó, cuánto duró (2-3 frases)
2. **Timeline (UTC)**: Tabla hora/evento/acción. Incluí decisiones incorrectas.
3. **Causa raíz**: Los 5 porqués. No te quedes en el síntoma.
4. **Qué salió bien**: Alerta temprana, rollback rápido, comunicación clara.
5. **Qué salió mal**: Sin culpables. "El alerta llegó 8 min tarde."
6. **Action items**: Concretos con responsable y fecha.
7. **¿Cómo evitar que vuelva a pasar?**: Detección más rápida, mejor respuesta, menor blast radius.

---

## Rollback

1. Identificar último deploy bueno: `git log --oneline -10`
2. Ejecutar: `git revert <commit-id>` o redeploy del workflow anterior
3. Verificar: `curl health endpoint`, revisar dashboard de errores
4. Si no resuelve: no es código → infra/dependencia externa/datos. Revisar DB, gateway de pago, etc.
5. Mitigación sin rollback: feature flags, rate limiting, failover, degradación elegante, escalado manual

---

## Lecciones
1. 90% de incidentes vienen de un deploy. Si deployaste hace < 2h, rollback primero.
2. Nunca debuguees en producción. Rollback → reproducí en staging → arreglá → redeployá.
3. La comunicación salva más vidas que el código.
4. El postmortem no busca culpables. Busca que no pase dos veces.
5. Practicá rollback en frío. La primera vez no puede ser durante un P1.