Diseña un Business Continuity Plan (BCP) técnico para cuando un sistema crítico falla en producción. El prompt te ayuda a estructurar runbooks, definir RPO/RTO y organizar la respuesta del equipo de ingeniería.
Cuándo usarlo: Crear runbooks y planes de respuesta a incidentes críticos en producción
Herramienta recomendada: Claude
Actúa como un arquitecto de sistemas senior especializado en resiliencia de software, disaster recovery y gestión de incidentes en entornos de producción de alta disponibilidad. Necesito que me ayudes a elaborar un Plan de Continuidad del Negocio (BCP) técnico para mi equipo de desarrollo ante un fallo crítico de uno de nuestros sistemas en producción. **CONTEXTO DEL SISTEMA:** [Describe tu arquitectura: tipo de aplicación (monolito, microservicios, serverless), stack tecnológico, proveedor cloud, número aproximado de usuarios activos, nivel de criticidad del negocio y dependencias externas clave.] **OBJETIVOS DEL PLAN:** 1. **Clasificación del incidente** - Define una matriz de severidades (P0, P1, P2, P3) con criterios concretos: porcentaje de usuarios afectados, tiempo de degradación, impacto en ingresos. - Explica qué tipo de fallo activa cada nivel (caída total, degradación parcial, lentitud, fallo de integración externa). 2. **Runbook de respuesta inmediata (primeros 15 minutos)** - Pasos exactos para el ingeniero de guardia: qué verificar primero, qué comandos ejecutar para diagnosticar, cómo aislar el componente fallido. - Árbol de decisión: si el problema es X, hacer Y; si es Z, hacer W. - Lista de herramientas de observabilidad que deben consultarse y en qué orden (logs, métricas, trazas, alertas). 3. **Escalado y comunicación interna** - Define quién notificar según la severidad (on-call, tech lead, CTO, CEO). - Propón la cadencia de actualizaciones en el canal de incidentes (Slack, Teams o similar). - Redacta una plantilla de mensaje de incidente inicial y de actualización periódica. 4. **Estrategias de mitigación técnica** - Enumera las tácticas de mitigación más habituales según el tipo de fallo: rollback de despliegue, feature flags, circuit breakers, escalado horizontal, failover a región secundaria, modo mantenimiento. - Para cada táctica, indica el tiempo estimado de implementación y el riesgo asociado. 5. **Comunicación externa durante el incidente** - Plantilla de mensaje para la página de estado (statuspage.io o similar). - Plantilla de email o mensaje in-app para usuarios afectados. - Pautas sobre qué información técnica no debe compartirse públicamente. 6. **Post-mortem sin culpas (blameless post-mortem)** - Estructura el documento de post-mortem: timeline del incidente, causa raíz (5 Whys), impacto cuantificado, acciones de mejora con responsable y fecha. - Explica cómo facilitar la reunión de post-mortem para que sea constructiva y no defensiva. 7. **Métricas de resiliencia a monitorizar continuamente** - MTTR (Mean Time to Recovery), MTTD (Mean Time to Detect), frecuencia de incidentes por severidad, SLO/SLA cumplimiento. - Recomienda una cadencia de revisión de estos KPIs y con quién compartirlos. 8. **Ejercicios de preparación (Game Days y Chaos Engineering)** - Sugiere 3 escenarios de simulación de fallos que mi equipo debería practicar trimestralmente. - Explica cómo organizar un Game Day sin impactar producción. **FORMATO DE RESPUESTA:** Devuelve el plan estructurado en secciones con headers claros. Incluye plantillas de texto listas para adaptar, árboles de decisión en formato de lista anidada y comandos de ejemplo donde sea relevante. El tono debe ser técnico pero claro, pensado para ingenieros bajo presión.