Workflow: Bug / Incident Triage

Runbook operativo. Complementa el Plan de Respuesta a Incidentes (orden 31) para el ciclo de vida de bugs y fallas técnicas. Este workflow cubre fallas operativas y de producto; para brechas de seguridad y violaciones de datos, referirse al Plan de Respuesta a Incidentes. Aprobado por la Asamblea en [__]. Versión: 1.0.

1. Trigger

Alerta automática del sistema de monitoreo (Uptime Robot, Firebase Alerting, Sentry, GitHub Actions failure).
Reporte de usuario / cliente vía: portal de soporte, email support@lawra.io, canal interno #bugs en el espacio de colaboración del equipo.
Reporte de un miembro del equipo durante el uso de la plataforma.
Falla detectada en proceso de QA o revisión de PR.
Reporte de bug bounty / disclosure responsable (ver Política de Divulgación Responsable).

2. Roles y Responsabilidades (RACI)

Tarea	Responsable	Aprobador	Consultado	Informado
Recepción y clasificación inicial	Luishy Medina (CTO) o ingeniero de turno	—	—	CCO
Asignación de severidad P0/P1	Luishy Medina	Carlos Miranda Levy	Tanya (si implica datos)	Todos los socios
Asignación de severidad P2/P3	Ingeniero de turno	Luishy Medina	—	CCO
Comunicación a clientes afectados	Ydarlis Cabrera (CCO)	Carlos Miranda Levy	Tanya	—
Resolución técnica	Ingeniero asignado	Luishy Medina	—	CCO
Deploy del fix	Luishy Medina	—	Ingeniero	CCO
Post-mortem	Luishy Medina	Carlos Miranda Levy	Tanya (si aplica)	Todos
Escalamiento a IR Plan (si seguridad)	Luishy Medina	—	Tanya	Carlos

3. Tabla de Severidades y SLAs

Nivel	Definición	Ejemplos	Tiempo de respuesta inicial	Tiempo de resolución objetivo
P0 — Crítico	Plataforma completamente caída o múltiples clientes sin acceso; brecha de datos en curso	Caída total de Firebase; fuga masiva de datos; API de IA completamente inaccesible para todos los usuarios	< 30 minutos	< 4 horas
P1 — Alto	Funcionalidad principal degradada para uno o más clientes; posible impacto en datos de un cliente	AI Suite no responde para un tenant; módulo Enterprise crítico falla; autenticación intermitente	< 2 horas	< 8 horas
P2 — Medio	Funcionalidad secundaria afectada; workaround disponible; sin impacto en datos	Feature de descarga de documentos falla; notificaciones email retrasadas; velocidad degradada	< 8 horas	< 3 días hábiles
P3 — Bajo	Bug menor, cosmético o sin impacto operativo; solo afecta experiencia de usuario	Texto mal alineado en UI; traducción incorrecta; enlace roto en página de marketing	< 24 horas	< 10 días hábiles o próximo sprint

4. Pasos Numerados

Fase 1 — Detección y Registro (< 30 min para P0/P1)

Paso 1 — Recepción: El reporte llega por cualquier canal. El ingeniero de turno o Luishy lo recibe y abre inmediatamente un issue en el repositorio de GitHub con la etiqueta bug y severidad provisional (P0/P1/P2/P3).

Paso 2 — Información mínima del issue:

Descripción del problema y pasos para reproducir.
Entorno afectado (producción / staging / dev).
Impacto: ¿cuántos usuarios / clientes afectados?
Evidencia: capturas, logs, error IDs de Sentry.
Timestamp de detección.

Paso 3 — Verificación del entorno: Ingeniero verifica en el dashboard de monitoreo: ¿es un falso positivo? ¿El proveedor (Google / Firebase / Gemini) reporta incidente en su página de status? Si el problema es del proveedor, se documenta y se notifica a los clientes afectados pero no se abre un post-mortem interno.

Fase 2 — Clasificación y Escalamiento (Day 0)

Paso 4 — Asignación de severidad definitiva: Luishy revisa el reporte y asigna severidad definitiva (puede subir o bajar desde la inicial). Si es P0 o P1: notifica inmediatamente a Carlos Miranda Levy y, si hay posible impacto en datos, a Tanya Mejía-Ricart.

Decisión A: ¿El incidente involucra posible acceso no autorizado a datos, brecha de seguridad o compromiso de credenciales?

Sí → Activar el Plan de Respuesta a Incidentes en paralelo. El Incident Commander toma el control. Este workflow continúa subordinado al IRP.
No → Continuar con Paso 5.

Paso 5 — Comunicación interna P0/P1: Para P0/P1, Luishy envía alerta al canal #incidents (o equivalente) con: descripción del problema, severidad, sistemas afectados, punto de contacto. Carlos Miranda Levy es notificado por mensaje directo.

Fase 3 — Contención y Comunicación con Clientes (Day 0)

Paso 6 — Página de status (P0/P1): Para incidentes P0/P1 visibles para los usuarios, CCO actualiza la página de status de Lawra (o publica una nota en el portal de soporte) dentro de los 30 minutos de confirmación del incidente. Texto mínimo: “Estamos al tanto de un problema que afecta [función]. Estamos trabajando en su resolución. Actualizaremos en [tiempo].”

Paso 7 — Comunicación proactiva a clientes Enterprise afectados (P0/P1): CCO identifica qué clientes Enterprise están afectados basándose en el tenant / workspace. Envía email proactivo dentro de 1 hora para P0, dentro de 3 horas para P1. Incluye: descripción del problema, impacto conocido, ETA de resolución (si se conoce), canal de contacto directo.

Paso 8 — Mitigación temporal (si disponible): Luishy o el ingeniero asignado aplica un fix temporal (feature flag, rollback parcial, desactivación de la función afectada) para reducir el impacto mientras se trabaja la solución definitiva. Se documenta la mitigación en el issue de GitHub.

Fase 4 — Resolución (según SLA)

Paso 9 — Desarrollo del fix: El ingeniero asignado trabaja en la solución. Para P0: todo el equipo disponible colabora; Luishy coordina y puede pausar otros desarrollos en curso. Para P1: al menos un ingeniero dedicado. Para P2/P3: se prioriza en el sprint activo.

Paso 10 — Code review (obligatorio para P0/P1): Aunque la urgencia es alta, el fix requiere al menos 1 revisión de código antes del deploy a producción. El revisor valida que el fix no introduce nuevas vulnerabilidades o regresiones. Para P0 se acepta revisión express (15 min mínimo), pero no se saltea.

Paso 11 — Deploy del fix (ver Workflow: Code Deployment, orden 56): Deploy a producción vía el proceso estándar. Para P0/P1 se puede omitir el preview environment, pero no el CI gate de tests automáticos. Luishy aprueba y ejecuta el deploy.

Paso 12 — Verificación post-deploy: Luishy o el ingeniero verifica que el issue está resuelto: reproduce los pasos del reporte, valida en el sistema de monitoreo que las alertas han cesado, confirma con el cliente afectado si es Enterprise.

Fase 5 — Cierre y Comunicación

Paso 13 — Actualización de status (P0/P1): CCO actualiza la página de status: “El problema ha sido resuelto. Servicio restaurado completamente a las [hora]. Publicaremos un post-mortem en [plazo].”

Paso 14 — Notificación de cierre a clientes: CCO envía email de cierre a los clientes Enterprise notificados en el Paso 7: confirmación de resolución, breve descripción del fix aplicado, disculpas por el impacto, crédito / compensación si el SLA fue incumplido (según MSA).

Paso 15 — Cierre del issue en GitHub: El ingeniero asignado cierra el issue con: descripción de la causa raíz, fix implementado, enlace al PR del fix, fecha y hora de resolución.

Fase 6 — Post-Mortem (P0 obligatorio; P1 recomendado)

Paso 16 — Post-mortem blameless (dentro de 5 días hábiles): Luishy convoca al equipo para un post-mortem. Documento incluye:

Timeline detallado (detección → contención → resolución → comunicación).
Causa raíz (no la causa superficial).
Qué funcionó bien y qué no.
Acciones de mejora con responsable y fecha.
Tiempo total de inactividad (downtime) y clientes afectados.

Paso 17 — Reporte a la Asamblea: Luishy o Carlos Miranda Levy presenta un resumen de todos los P0/P1 del trimestre en la reunión trimestral de la Asamblea, con el estado de las acciones de mejora.

5. Puntos de Decisión

Decisión	Opciones
A — ¿Implica posible seguridad / datos?	Sí → activar IRP en paralelo / No → continuar flujo normal
B — ¿El problema es del proveedor externo?	Sí → documentar, notificar clientes, no post-mortem interno / No → iniciar investigación propia
C — ¿Fix disponible en SLA?	Sí → deploy y cierre / No → escalar severidad, comunicar nuevo ETA, considerar rollback
D — ¿SLA Enterprise incumplido?	Sí → calcular crédito según MSA, CCO aplica / No → cierre estándar

6. Outputs / Artifacts

Issue de GitHub con etiqueta de severidad y resolución documentada.
PR del fix con code review aprobado.
Comunicaciones enviadas a clientes (archivo en CRM).
Post-mortem (documento en repositorio interno o Notion/Drive).
Actualización de la página de status archivada.
Acciones de mejora registradas.

7. Checklist Final

8. Métricas / KPIs

Métrica	Objetivo
Mean Time to Detect (MTTD) P0	< 15 minutos
Mean Time to Respond (MTTR) P0	< 30 minutos desde detección
Mean Time to Resolve P0	< 4 horas
Mean Time to Resolve P1	< 8 horas
Tasa de post-mortems P0 completados	100 %
Recurrencia del mismo bug (P0/P1) en 90 días	0
SLA Enterprise cumplido (uptime contratado)	≥ 99.5 % mensual

9. Referencias

Plan de Respuesta a Incidentes (orden 31) — para brechas de seguridad
Workflow: Code Deployment (orden 56) — para el proceso de deploy del fix
Política de Control de Acceso (orden 30) — para revocación de accesos tras incidente
Master Service Agreement — cláusula de SLA y créditos por downtime
NIST SP 800-61 Rev. 2 — Computer Security Incident Handling Guide
ISO 27001, Anexo A — A.16 Gestión de incidentes de seguridad

10. Auditoría

Registro	Retención	Evidencia SOC 2
Issues de GitHub (bugs + resoluciones)	5 años	CC7.3 — Evaluation and communication of security events
Post-mortems	5 años	CC7.5 — Incident response and recovery activities
Comunicaciones a clientes afectados	5 años	CC2.3 — Communication to external parties
Registros de SLA y créditos aplicados	7 años	CC9.1 — Risk management

Adoptado por la Asamblea General de Socios en fecha [__]. Próxima revisión: [fecha + 12 meses].

Por LAWRA, S.R.L. — Gerente

Workflow: Bug / Incident Triage

Workflow: Bug / Incident Triage

1. Trigger

2. Roles y Responsabilidades (RACI)

3. Tabla de Severidades y SLAs

4. Pasos Numerados

Fase 1 — Detección y Registro (< 30 min para P0/P1)

Fase 2 — Clasificación y Escalamiento (Day 0)

Fase 3 — Contención y Comunicación con Clientes (Day 0)

Fase 4 — Resolución (según SLA)

Fase 5 — Cierre y Comunicación

Fase 6 — Post-Mortem (P0 obligatorio; P1 recomendado)

5. Puntos de Decisión

6. Outputs / Artifacts

7. Checklist Final

8. Métricas / KPIs

9. Referencias

10. Auditoría

Comments