Cómo respondemos cuando algo se rompe · severidades · roles · runbook genérico · postmortem.
| Sev | Definición | Tiempo respuesta | Ejemplo |
|---|---|---|---|
| SEV1 | App caída · usuarios no entran · data corruption | <15 min | Supabase down · 500 prod en login |
| SEV2 | Feature crítica rota · workaround posible | <1h | Checkout falla en 1 canal · sync MeLi roto |
| SEV3 | Bug visible · sin impacto crítico | <1 día | Tipo en email · gráfico no carga |
| SEV4 | Bug menor · cosmético | <1 semana | Espaciado mal · color off |
Para Marketplace SMC inicial: 1 persona puede llevar 2-3 roles · ideal 1 persona = 1 rol.
1. DETECTAR - Alerta (CloudWatch · Sentry · status page) - Reporte usuario en soporte - Detección proactiva monitoring 2. TRIAGE - Asignar severidad (tabla 01) - Activar Commander - Si SEV1/SEV2: notificar equipo en canal #incidents 3. CONTENER - Rollback si deploy reciente (último merge a main) - Disable feature flag si feature específica - Aislar tenant si data corruption (RLS) 4. INVESTIGAR - Logs Amplify · Supabase · Sentry - Reproducir en QAS si posible - Identificar root cause 5. REMEDIAR - Patch + deploy - Verificar fix en prod - Anunciar resolución 6. POSTMORTEM - <48h después - Blameless: foco en sistema · no personas - Acciones de prevención con dueño y fecha
"Estamos investigando" es mejor que silencio. NUNCA prometer ETA que no se va a cumplir.
[análisis técnico claro · sin asignar culpa]