Funciones y responsabilidades en las operaciones

1) Por qué formalizar roles

Una clara distribución de roles reduce el MTTA/MTTR, elimina las «zonas grises», acelera las versiones y hace que el cumplimiento de SLO/cumplimiento sea reproducible. Roles = responsabilidad + poderes + interfaces (a quién escribimos, a quién escalamos, qué decisiones están autorizadas).

2) Modelo RACI básico

R (Responsable): realiza el trabajo.
A (Accountable) - Tiene la responsabilidad final y toma las decisiones.
C (Consultado) - experto, consultado antes/durante.
I (Informed) - Informado por SLA.

3) Catálogo de roles (descripciones y responsabilidades)

3. 1 Incident Commander (IC)

Objetivo: dirigir la respuesta al incidente de SEV-1/0.
Autoridad: declarar SEV, congelar lanzamientos, cambiar de tráfico, escalar.
Tareas principales: tiempo en línea, toma de decisiones, retención de enfoque, asignación de tareas, Go/No-Go.
Artefactos: tarjeta de incidente, apdates de SLA, AAR final.

3. 2 P1/P2 On-Call (Primary/Secondary)

Objetivo: respuesta primaria y acciones técnicas.
P1: triaje, lanzamiento de playbooks, comunicación con IC.
P2: backup, cambios complejos, retención de contexto, en tormentas - toma sabotocos.

3. 3 SRE / Platform Engineer

Objetivo: fiabilidad de plataforma y barandilla (SLO, alertas, GitOps, auto skale, DR).
Tareas: SLI/SLO, higiene de alertas, lanzamientos progresivos, infraestructura como código, capacidad, observabilidad.
Durante el incidente: diagnóstico de raíz, retrocesos/folbacks, activación degrade-UX.

3. 4 Service Owner / Product Owner

Objetivo: calidad del servicio en el sentido empresarial.
Tareas: definición de SLO/prioridades, alineación de lanzamientos/ventanas, participación en Go/No-Go.
Commes: una solución para cuando y qué decir a los clientes junto con Comms.

3. 5 Release Manager

Objetivo: entrega segura de los cambios.
Tareas: orquestación de lanzamientos, chequeo de gatitos, canario/azul-verde, anotaciones de lanzamientos, freeze en incidentes.

3. 6 CAB Chair / Change Manager

Objetivo: gestionar el riesgo de cambio.
Tareas: proceso RFC, plan/retroceso, calendario de conflictos, aprobaciones de alto riesgo.

3. 7 RCA Lead / Problem Manager

Objetivo: análisis post-incidente, CAPA.
Tareas: tiempo en línea, causalidad a prueba, acciones de corregir/prevenir, control D + 14/D + 30.

3. 8 Security (IR Lead, AppSec/CloudSec)

Objetivo: seguridad y respuesta a incidentes de seguridad.
Tareas: triage security-events, rotación de claves, aislamiento, forensic, notificaciones regulatorias, auditoría WORM.

3. 9 DataOps / Analytics

Objetivo: fiabilidad de los datos y las líneas de pago.
Tareas: frescura/calidad (DQ), contratos de datos, lineage, backfills, SLA BI/informes.

3. 10 FinOps

Objetivo: costo manejable.
Tareas: cuotas/límites, informes de $/unidad, getas de presupuesto, optimizaciones (volúmenes de registro, egresos, reservas).

3. 11 Compliance / Legal

Objetivo: cumplir con la regulación y los contratos.
Tareas: plazos de las notificaciones, retenciones/perpetuidad de la videncia, negociación de textos públicos.

3. 12 Support / Comms

Objetivo: comunicaciones con clientes/stakeholder internos.
Tareas: status page, diseños de apdate, frecuencia y claridad de mensajes, recopilación de comentarios.

3. 13 Vendor Manager / Provider Owner

Objetivo: relaciones con proveedores externos (PSP/KYC/CDN, etc.).
Tareas: Escaladas, SLA/OLA, rutas de respaldo, coordinación de ventanas.

4) Roles de cambio y escalamiento

Cambio: P1/P2 + IC-of-the-day (no combinar con P1).
Escaladas de tiempo: P1→P2 (5 min sin ack) → IC (10 min) → Duty Manager (15 min).
Quiet Hours: las señales P2/P3 no despiertan; señales de seguridad - siempre.

5) Interfaces de interacciones (quién está con quién y cómo)

IC ↔ Release Manager: soluciones freeze/rollback.
IC ↔ Comms: texto de los apdates y frecuencia.
SRE ↔ DataOps: SLI empresarial (éxito de pago, frescura de datos) en SLO-gardrailes.
Seguridad ↔ Legal: reportes de incidentes de seguridad, plazos de notificación.
Vendor Owner ↔ IC: estado del proveedor, switchover/folback.

6) KPI por roles (puntos de referencia)

IC: Time-to-Declare, Cumplimiento de SLA Comms, MTTR por SEV-1/0.
P1/P2: MTTA, Time-to-First-Action,% siguiendo los playbooks.
SRE/Platform: SLO coverage, Alert Hygiene,% auto-patinaje es exitoso.
Release Manager: Change Failure Rate, On-time windows, Mean Rollback Time.
RCA Lead: Postmortem Lead Time, CAPA Completion/Overdue, Reopen ≤ 5–10%.
Security: Mean Time to Contain, Secret/Cert Rotation Time.
DataOps: Freshness SLO Adherence, Success Rate backfills.
Comms: Status Accuracy, Complaint Rate/Incidente.
FinOps: $/unidad,% de ahorro de QoQ, cumplimiento de cuotas.

7) Plantillas de tarjetas de rol

7. 1 Tarjeta IC

Role: Incident Commander
Scope: SEV-1/0 (prod)
Decisions: declare SEV, freeze deploy, traffic shift, rollback/failover
Runbooks: rb://core/ic, rb://comms/status
SLA: TTD ≤10m, first comms ≤15m, updates q=15–30m
Escalations: Duty Manager (15m), Exec On-call (30m)

7. 2 Tarjeta P1/P2

Role: Primary/Secondary On-call (service: checkout-api)
Runbooks: rb://checkout/5xx, rb://checkout/rollback
Tools: logs, traces, SLO board, feature flags
SLA: Ack ≤5m, first action ≤10m, handover at shift boundaries

7. 3 Tarjeta Release Manager

Role: Release Manager
Gates: tests, signatures, active_sev=none, SLO guardrails green 30m
Strategy: canary 1/5/25%, blue-green optional, auto-rollback on burn
Evidence: release annotations, diff configs, dashboards before/after

8) Procesos y participación de roles (resumen)

A — Accountable, R — Responsible, C — Consulted, I — Informed.

9) Hojas de cheques

9. 1 Asignación de roles

• Cada función tiene un propietario, un suplente y un área de cobertura.
• Se describen los poderes (qué decisiones pueden tomar).
• Los playbooks y los canales de comunicación están vinculados.
• SLA publicado por reacción/comms.
• El rol está disponible en el directorio (CMDB) de cada servicio.

9. 2 Cambio y handover

• Tarjeta de cambio actualizada (incidentes activos, riesgos, ventanas).
• Se verificaron los accesos JIT/JEA.
• Mensaje de eco al canal: «cambio aceptado/entregado».

9. 3 Post-incidente

• AAR realizado, RCA designado.
• CAPA con propietarios/plazos, D + 14/D + 30 control.
• Se han actualizado los playbooks/alertas/políticas.

10) Anti-patrones

No está claro «quién decide» → retrasos y tomas de esfuerzos.
IC combinado con P1 - pérdida de liderazgo.
Commes públicos sin acuerdo con Legal/Comms.
El lanzamiento sin Release Manager y Gates → el crecimiento de CFR.
Falta de reserva de roles (enfermedad/vacaciones).
«Heroicidad» en lugar de proceso: rescatamos a mano, pero no arreglamos la barandilla.
Los roles no se reflejan en el directorio CMDB/servicio → las escalaciones perdidas.

11) Incrustación en herramientas

ChatOps: команды `/who oncall`, `/declare sev1`, `/freeze`, `/rollback`, `/status update`.
Directorio/CMDB: el servicio tiene propietario, on-call, SLO, dashboards, playbooks, ventanas.
Alert-as-Code: cada Page tiene un owner y un playbook predeterminados.
GitOps: las soluciones de IC/Release se reflejan en anotaciones de lanzamientos y tickets.

12) Métricas de madurez de distribución de roles

Roles de cobertura en directorios: ≥ el 100% de los servicios críticos.
SLA On-call: Ack p95 ≤ 5 min; Page Storm p95 bajo control.
Postmortem SLA: borrador ≤ 72h; CAPA completion ≥ 85%.
Cambio de gobierno:% de cambios de alto riesgo con RFC/CAF ≥ 95%.
Comms: Adherence ≥ 95%, Complaint Rate ↓ QoQ.

13) Mini plantillas

13. 1 RACI para el servicio (archivo en repo)

yaml service: payments-api roles:
owner: team-payments oncall: oncall-payments ic: ic-of-the-day raci:
incident:  {A: ic-of-the-day, R: oncall-payments, C: security,data, I: mgmt,comms}
releases:  {A: release-manager, R: dev,platform, C: security, I: support}
changes:  {A: cab, R: owner, C: sre,security, I: affected-teams}
postmortem: {A: rca-lead, R: owner, C: security,data, I: mgmt}

13. 2 Perfil de rol (Markdown)

Role: Duty Manager
Purpose: Escalation and SEV-1/0
Powers: Assign ICs, reallocate resources, approve freeze
Inputs: # war-room channel, SLO dashboards, IC reports
Outputs: resolutions, post-factual report, CAPA escalations

14) Resultado

Las operaciones son sostenibles cuando los roles son transparentes, están habilitados e incorporados en las herramientas. El directorio de roles, RACI, interfaces claras y métricas para cada rol convierten incidentes, lanzamientos y cambios en procesos gestionados: las decisiones se toman rápidamente, los riesgos se controlan y los usuarios ven un servicio estable.