Saltar al contenido principal
AI Empire
Runbooks operacionales · transparencia SRE

Cómo manejamos producción

6 runbooks operacionales públicos · cómo manejamos deploys · incidents P0 · rotación secrets · backups · escalation Enterprise · onboarding. MTTR <15min crítico · cultura SRE explícita · zero black box.

Postmortems incidentsHistórico uptimeSLA contractualArquitectura técnica
<15min
MTTR P0 target
Critical incidents · founder-led
<2min
MTTD target
Sentry + UptimeRobot polling
6
Runbooks
Públicos · canonical · auditable
Blameless
Cultura
Procesos > personas · postmortems

6 runbooks canónicos

Deploy a producción

Trigger: PR mergeado a main + CI verde
MTTR: Deploy <5min · Rollback <2minOwner: Auto + Founder confirm
Pasos
  1. 1.Pre-check: typecheck + tests + claims-policy (CI gate)
  2. 2.wrangler deploy --dry-run (verifica tamaño bundle <10MB)
  3. 3.Deploy a worker production (Cloudflare Workers)
  4. 4.Smoke test: /health endpoint 200 + 5 test requests
  5. 5.Si fail cualquier paso → rollback inmediato + notify Sentry
  6. 6.Si OK → update changelog + notify Slack founder

Incident response P0 (todo down)

Trigger: UptimeRobot detect 2 polls consecutivos rojos · OR Sentry alert critical · OR cliente WhatsApp `down`
MTTR: MTTD <2min · MTTR <15minOwner: Founder
Pasos
  1. 1.Trigger: alerta inmediata Slack + email + SMS founder
  2. 2.Reconocer alerta < 5min (acknowledge en UptimeRobot)
  3. 3.Status page update: 'Investigating' + post Slack clientes pago
  4. 4.Diagnóstico: Cloudflare logs tail + Sentry recent + Supabase queries
  5. 5.Mitigar: rollback si reciente deploy · escalation Cloudflare support si CF · Supabase status si DB
  6. 6.Validar fix: health endpoint 2 polls verdes + sample requests OK
  7. 7.Status update: 'Resolved' + comms internas
  8. 8.Postmortem started en <48h (ver /incident-postmortems)

Rotación secret (cualquier API key)

Trigger: Suspected compromise · OR rotation calendar scheduled (semestral) · OR vendor force rotation
MTTR: Rotation completa <30min · zero downtimeOwner: Founder
Pasos
  1. 1.Generar nuevo secret en vendor (e.g., OpenAI dashboard)
  2. 2.Blue-green pattern: wrangler secret put NEW_KEY (NUEVO nombre temporal)
  3. 3.Deploy con código que usa NEW_KEY o falls back a OLD_KEY
  4. 4.Validar producción con NEW_KEY (smoke test)
  5. 5.Revoke OLD_KEY en vendor dashboard
  6. 6.Update código para usar NEW_KEY canonical name
  7. 7.Deploy final · sin OLD_KEY referenced
  8. 8.Audit log: registro rotación en docs/security/SECRET_ROTATION_LOG.md

Backup verify (Supabase mensual)

Trigger: Cron mensual day-1 + manual on-demand pre-major changes
MTTR: Verify completo <2h · restore test <1hOwner: Founder
Pasos
  1. 1.Supabase dashboard → Backups → seleccionar latest point-in-time
  2. 2.Crear branch de prueba 'restore-test-YYYY-MM' (Supabase branching)
  3. 3.Restore backup a branch (no toca prod)
  4. 4.Validar: COUNT(*) tables principales vs prod numbers
  5. 5.Validar: random sample 10 pacientes con datos completos
  6. 6.Validar: RLS policies activas (no cross-tenant leak en branch)
  7. 7.Cleanup: delete branch test
  8. 8.Audit log: backup_verify_log.md update

Escalation cliente Enterprise crítico

Trigger: Cliente Enterprise tier reporta issue P0 vía Slack/WhatsApp founder directo
MTTR: Acknowledge <15min · Update cada 30min · Resolution path <2hOwner: Founder
Pasos
  1. 1.Acknowledge inmediato (no auto-response · founder real)
  2. 2.Triage: replicar issue (si posible) en staging · gather logs
  3. 3.Comunicación honest: si causa identificada → comparir · si no → 'investigando'
  4. 4.Updates cada 30min vía Slack/WhatsApp (no email · velocidad)
  5. 5.Fix: hotfix patch + deploy URGENT (skip standard CI gates si crítico patient-facing)
  6. 6.Validar fix con cliente (no auto-confirm · cliente verifica)
  7. 7.Postmortem público en <48h (ver /incident-postmortems)
  8. 8.Si SLA breach → credit automático en próxima invoice (ver /sla)

Onboarding clínica nueva (semana 1)

Trigger: Owner clínica firma propuesta + acuerdo signado
MTTR: Kickoff <72h post-firma · Staging operativo <7 díasOwner: Founder
Pasos
  1. 1.Kickoff call 60min (grabada · transcripción)
  2. 2.Audit técnico stack actual cliente (PMS · WhatsApp · Cal · Stripe)
  3. 3.Provisionar tenant staging Supabase (RLS · secrets)
  4. 4.Setup WhatsApp Business número (template approval Meta)
  5. 5.Configurar Cal.com event types (sync with PMS si aplica)
  6. 6.Cargar Knowledge Base (precios · tratamientos · FAQ · staff)
  7. 7.Smoke test 10 mensajes en staging
  8. 8.Sign-off owner para semana 2 (training + UAT) · ver /onboarding-process

6 principios cultura SRE

Inspirados en Google SRE Book + Stripe engineering culture + Linear incident response. Aplicados desde el primer commit · no añadidos post-incidente.

Blameless postmortems
Cada incident >5min downtime termina con postmortem público (ver /incident-postmortems). Análisis procesos · NO personas. Error humano = síntoma proceso débil.
MTTR < MTBF strategy
Preferimos optimizar Mean Time To Recover (rollback rápido · auto-mitigation) sobre Mean Time Between Failures (puede fallar más · solo rápido en recovery).
Toil reduction continua
Cualquier task manual >3 veces se automatiza. Crons + scheduled tasks reemplazan checks manuales. Founder time es resource limitado · automation paga rápido.
Defense in depth
Multiple layers de protection: CI gates + dry-run + smoke test + rollback automation + alerts + audit logs. Single layer failure no causa producción incidents.
Observable by default
Cada deploy logs · cada request traceable · cada error captured Sentry · cada alert reaches founder <2min. Visibility total · no debug print() needed.
Honest reporting
Status page actualizada en tiempo real (no maquillada). Uptime publicado mensualmente (ver /uptime-history). Si algo va mal, lo sabrás antes que mis pretextos.
Runbooks ejecutables · slash commands

Los runbooks no son docs estáticos. Cada uno tiene su slash command ejecutable en repo (Claude Code agentic operating system):

  • · /deploy-safe · runbook deploy completo
  • · /incident-rca · runbook incident response P0
  • · /rotate-secret <NAME> · runbook rotación
  • · /backup-verify · runbook backup verify mensual
  • · /smoke-test · runbook end-to-end test
  • · /onboard-clinic · runbook onboarding cliente

Cada slash command está documentado en `.claude/commands/` repo público. Auditable · reproducible · sin tribal knowledge.

¿Tu ops/SRE team quiere revisión técnica?

Si tu compliance/ops team necesita ver runbooks específicos en acción · arquitectura monitoring · escalation paths · reservamos 60min sesión técnica directa founder. Útil para DSO/Enterprise compliance review pre-firma.

Reservar sesión técnicaArquitectura técnicaSeguridadDisclosure policy