Runbooks Operativos por Servicio

1. Estructura mínima de runbook

Cada runbook de servicio debe incluir:

• Síntomas.
• Métricas/alertas asociadas.
• Pasos de diagnóstico.
• Mitigación inmediata.
• Rollback.
• Verificación post-incidente.

2. Auth Service

• Síntomas: incremento de 401/429, fallas login, refresh reuse anómalo.
• Diagnóstico: revisar auth_5xx_rate, auth_login_p95, estado Redis y proveedor OAuth.
• Mitigación: activar rate limit reforzado, fallback a login email/password, invalidación selectiva de sesiones.
• Rollback: versión previa de task definition.
• Validación: login, refresh y logout operativos en smoke tests.

3. Search Service

• Síntomas: latencia alta, resultados vacíos anómalos.
• Diagnóstico: revisar FTS index health, cache hit rate, filtros por país.
• Mitigación: desactivar filtros no críticos por feature flag, invalidar caché.
• Rollback: restaurar configuración previa de índice/filtro.
• Validación: búsquedas por especialidad, ubicación y seguro.

4. Appointments Service

• Síntomas: colisiones de slot, 409 altos, doble reserva.
• Diagnóstico: revisar lock contention e idempotencia.
• Mitigación: bloquear temporalmente creación en nodo afectado, reprocesar comandos pendientes.
• Rollback: revertir release y restaurar consistencia de slots.
• Validación: crear, cancelar y confirmar citas sin conflicto.

5. Notification Service

• Síntomas: caída entrega OTP, dlq_depth > 0, latencia alta.
• Diagnóstico: revisar proveedor SES/SMS/push, cola principal y DLQ.
• Mitigación: failover a proveedor secundario, retries controlados.
• Rollback: revertir configuración de provider o release.
• Validación: envío OTP y notificación de cita exitosos.

6. Catalog Service

• Síntomas: catálogos vacíos/inconsistentes, errores de mutación admin.
• Diagnóstico: revisar últimas mutaciones, versión de catálogo, invalidaciones de caché.
• Mitigación: restaurar snapshot lógico de catálogo y re-publicar versión estable.
• Rollback: revertir mutación o release de backoffice.
• Validación: selectores país/área/especialidad consistentes.

7. Payments Service (Recurrente)

• Síntomas: callbacks no procesados, estados de pago inconsistentes.
• Diagnóstico: revisar firma webhook, latencia del endpoint, idempotencia por transaction_id.
• Mitigación: reintento/reproceso desde cola de eventos, bloqueo temporal de conciliación automática.
• Rollback: desactivar versión nueva de webhook processor.
• Validación: pago aprobado, rechazado y webhook duplicado manejados correctamente.

8. Escalamiento y tiempos

Severidad	Tiempo de respuesta	Responsable inicial	Escalamiento
SEV1	5 min	Incident Commander	Tech Lead + DevOps + Seguridad
SEV2	15 min	Owner del servicio	Tech Lead + QA Lead
SEV3	60 min	Owner del servicio	Team de módulo

9. Evidencia obligatoria

• trace_id principal.
• dashboard/alarma que disparó.
• acción aplicada y timestamp.
• verificación de recuperación.
• postmortem para SEV1/SEV2.