Cuando algo falla en producción, esto es lo que hacemos.
Este playbook define el protocolo operacional de DevZen ante incidentes en sistemas cliente en producción. Aplica durante la garantía técnica de 90 días (MSA cláusula 7) y durante cualquier contrato de mantenimiento o renta SaaS vigente. Los pasos no son sugerencia — son la mínima ejecución comprometida con cada cliente.
Cuando aplique tratamiento de datos personales, las obligaciones de notificación de incidentes de seguridad de la cláusula 9 del MSA y el DPA · Anexo B (notificación 72 horas conforme LFPDPPP) son imperativas y prevalecen sobre cualquier disposición de este playbook.
Lo que entregamos hoy es lo que usaríamos en producción mañana — y respondemos a las 3 a.m. como si fuera nuestro propio sistema. Anchor cultural · § garantía técnica
- § 1 — Severidades. SEV1–SEV4 con SLA de respuesta y mitigación.
- § 2 — Los primeros 15 minutos. Timeline T+0 a T+15 para SEV1.
- § 3 — Cómo comunicamos. Reglas duras + 4 templates literales al cliente.
- § 4 — Cómo mitigamos. Árbol de decisión textual: código DevZen · servicio externo · cliente.
- § 5 — Postmortem template. Entrega al cliente en 48 horas máximo.
- § 6 — Escalación. Niveles 1–3 con contactos de emergencia.
- § 7 — Cierre y mejora continua. Compromiso de revisión trimestral.
Severidades · clasificación de incidentes.
Cuatro niveles. La severidad la determina DevZen al recibir el reporte, no el cliente. Si hay desacuerdo, escala a Kike — no se negocia el SLA por teléfono.
| Severidad | Definición | Ejemplo típico | SLA respuesta | SLA mitigación |
|---|---|---|---|---|
| SEV1 Crítico |
Sistema completamente caído · datos en riesgo · operación del cliente paralizada. | Base de datos no responde · auth caído · pago no procesa · pérdida de datos en curso. | 15 min hábil 30 min fuera de hábiles |
4h hábiles 8h fuera de hábiles |
| SEV2 Alto |
Funcionalidad mayor degradada · workaround posible pero costoso. | Reportes no generan · módulo cobranza intermitente · endpoint externo con tasa de error elevada. | 1h hábil | 24h hábiles |
| SEV3 Medio |
Funcionalidad menor afectada · sin impacto en operación crítica. | UI bug · export PDF mal formateado · campo no se valida correctamente. | 4h hábiles | 5 días hábiles |
| SEV4 Bajo |
Cosmético · mejora · deuda técnica. | Typo en label · color inconsistente · padding desalineado. | 24h hábiles | Siguiente sprint |
La severidad la asigna DevZen al recibir el reporte. Si el cliente reporta como SEV1 lo que DevZen considera SEV2, se explica el criterio con evidencia técnica y se acuerda en máx 30 min. Si el cliente insiste, se atiende al SLA superior por respeto comercial — pero se documenta la decisión y se revisa en postmortem.
Cualquier SEV1 o SEV2 que involucre acceso no autorizado, pérdida o exposición de datos personales activa la cláusula 9 del MSA y la cláusula 8 del DPA: notificación al Responsable (Cliente) dentro de 72 horas con naturaleza · datos afectados · medidas tomadas · medidas previstas. Esto es obligación legal, no opcional.
Los primeros 15 minutos.
Protocolo de respuesta para SEV1. Los primeros 15 minutos definen si el incidente se controla o se cascada. Cada paso es obligatorio y se ejecuta en paralelo cuando es posible.
Vía email a kike@numia.group, WhatsApp, Telegram, o alerta automatizada del monitoreo. Todo reporte se registra con timestamp exacto. La fuente original del reporte no determina la severidad — el diagnóstico inicial sí.
Mensaje canónico: "Recibido. Estamos diagnosticando. Próxima actualización en 15 min." Sin promesa prematura de fix · sin culpar a terceros sin evidencia · sin lenguaje técnico que el PO no pueda comunicar a su equipo.
En paralelo al ack: levantar canal Slack/Discord #{PROYECTO}-incident-{FECHA}. Invocar a Kike + Eduardo + freelancer asignado al proyecto si aplica. Tomar notas en vivo · grabar timeline.
Revisar logs centralizados · APM · status pages de servicios externos (BBVA · SAT · Supabase · Cloudflare · etc.). Determinar capa afectada (frontend · API · DB · integración externa · datos). Confirmar severidad real vs reportada.
Mensaje literal: "Update: identificamos {CAUSA}. Mitigación en curso: {MITIGACIÓN}. Próxima actualización en {N} minutos." Si todavía no hay causa identificada, se dice así explícito — nunca inventar diagnóstico para tranquilizar.
Riesgo identificado · Mitigación · Owner. Estructura literal de cada update durante incidente
Cómo comunicamos.
SEV1: cada 30 min · SEV2: cada 2h · SEV3: cada 24h · SEV4: al fix.
Primario: status page actualizada en vivo. Secundario: email a PO/Sponsor + WhatsApp/Telegram a contactos críticos del proyecto.
Prometer fechas de fix antes del diagnóstico · culpar a terceros sin evidencia · usar jerga técnica que el PO no pueda repetir a su equipo.
Usar "Riesgo identificado · Mitigación · Owner" en cada update · explicitar lo que ya se descartó · fechas tentativas solo con evidencia.
Copia y reemplaza placeholders. No improvises bajo presión — usa estos 4 templates como base.
Cómo mitigamos.
Árbol de decisión textual. Se ejecuta en el war room interno apenas hay diagnóstico inicial. No se aplica fix sin pasar por las preguntas.
Recomendamos rollback porque hotfix requiere 4h y el riesgo de cascada es alto. Re-release con fix completo en sprint siguiente. Ejemplo · frase firma aplicada a decisión de mitigación
Si el incidente ocurre a menos de 2 horas del cierre del día hábil y el fix no es trivial, se prefiere rollback. Nunca se hace deploy nocturno bajo presión salvo SEV1 con datos en riesgo y autorización explícita de Kike.
Postmortem · template.
Se entrega al cliente en máximo 48 horas después de la resolución de cualquier SEV1. SEV2 genera postmortem interno; se comparte al cliente bajo petición.
El postmortem es para aprender, no para culpar. Se publica internamente sin nombres de personas — solo causas técnicas. El cliente recibe la versión cliente-facing con compromisos accionables.
Cuándo escalamos.
Primera línea durante horario hábil del proyecto. Responde acknowledgments, ejecuta diagnóstico inicial. Escala al Nivel 2 ante SEV1 confirmado o si SEV2 excede SLA de mitigación.
SEV1 siempre · SEV2 si el freelancer no resuelve en SLA. Toda comunicación al PO/Sponsor del cliente pasa por aquí. Decisión final de rollback vs hotfix.
Temas comerciales o contractuales derivados del incidente. Se invoca si el cliente amenaza con cancelación, cobro de penalización, o si el postmortem implica revisión del SOW o del MSA.
| Kike Vázquez | kike@numia.group · +52 981 123-6415 · WhatsApp 24/7 durante SEV1 |
| Eduardo Nepote | Vía Kike · contacto directo si pre-establecido en SOW |
| Suplente de guardia | {SUPLENTE_GUARDIA} · TBD por proyecto |
Cierre y mejora continua.
- · Todo SEV1 genera postmortem público al cliente en 48h.
- · Todo SEV2 genera postmortem interno (compartido bajo petición).
- · Acciones correctivas se documentan en el Project Runbook del proyecto afectado.
- · Cada trimestre se revisan todos los postmortems · se identifican patrones · se actualiza este playbook.