Operaciones y Gestión → Cultura de Responsabilidad Operativa
Cultura de responsabilidad operacional
1) Por qué es necesario
La tecnología proporciona herramientas, pero la fiabilidad la crean las personas y su comportamiento. La cultura de la responsabilidad operativa hace predecible la plataforma, acelera la recuperación de fallas, reduce el «ruido» y convierte los incidentes en combustible para mejoras.
Objetivos:- Un entendimiento unificado de «qué es la fiabilidad» y quién es responsable de ella.
- Funciones, responsabilidades y autoridad transparentes en las operaciones.
- Un entorno seguro para discutir errores y ajustes rápidos.
- Mejora rítmica del SLO, el tiempo de reacción y el coste de las operaciones.
2) Principios (núcleo de la cultura)
1. You build it — you run it. El equipo posee la calidad de su dominio desde código hasta on-call.
2. SLO-first. Las decisiones se evalúan a través del impacto en SLO y error budget.
3. Blameless & factual. Postmortem sin cargos, sólo hechos, datos y acciones.
4. Small & reversible. Pequeños cambios, fichflags, canarios, retroceso rápido.
5. Safety to speak up. Todos pueden levantar la «bandera roja» sin miedo.
6. Evidence over opinions. Los datos y los artefactos son más importantes que las opiniones y el estatus.
7. Continuously learn. Incidentes → hipótesis → experimentos → normas.
3) Roles y posesión
Propietario del dominio (Payments/Bets/Games/KYC): SLO, on-call, hoja de ruta de mejoras, presupuesto de errores.
Gestión de incidentes (rotación): coordinación de reacciones, línea de tiempo, calidad de las comunicaciones.
SRE/Plataforma: herramientas de fiabilidad (observabilidad, alertas, fichflags, canarios).
Equipo Lead/EM: expectativas, desarrollo de competencias, cumplimiento de rituales.
Stakeholder de negocios: acuerda SLO/prioridades, acepta riesgos/compromisos.
4) SLO como contrato de responsabilidad
La única fuente de verdad: la definición de métricas, ventanas, excepciones.
Error budget: límites claros de riesgo → gate en lanzamientos/experimentos.
Discusión en lenguaje SLO: "¿Esta liberación quemará el 20% del presupuesto? ».
Revisión trimestral: en conjunto con el producto y el negocio.
5) On-call y preparación para incidentes
Expectativas claras: tiempos de reacción, canales, poderes (derecho de «parada-grúa»).
Entrenamiento: emulaciones de incidentes, shadow-service, ejercicios de RD.
Artefactos: runbook en vivo 'y, matriz de escaladas, patrones de apdate.
Preocupación por las personas: carga de trabajo intercambiable, compensación, rotación, política «no heroica».
- Accesos y VPN verificados.
- Los canales de notificación y los contactos de respaldo son correctos.
- Runbook actualizado ≤ hace 30 días.
- Participación de DR en los últimos 90 días.
6) Comunicaciones en operaciones
Plantillas uniformes: apdates cortos por incidentes, paquetes «handover» entre turnos.
Publicidad de las decisiones: los compromisos clave se registran por escrito.
Anotaciones en gráficos: lanzamientos, fichflags, ventanas de proveedores.
Paneles SLO para todos: transparencia de estados y presupuesto de errores.
[HH: MM] P2 Games latency ↑ p99 to 420 ms (base + 28%). Canary rolled back.
ETA of the next update: 20 min. Owner: squad-games. Next steps: tuning the breaker, checking provider Y.
7) Postmortem sin cargos
Hechos y tiempo en línea: quién, cuándo, qué hizo, en base a qué datos.
Causas del sistema: procesos, herramientas, interfaces, no «culpables».
Acciones con las líneas de salida: correctivas y preventivas.
Aprender lecciones: estándares, hojas de comprobación, actualización de runbook.
Impact: <metrics/revenue/users>
Timeline: <UTC+TZ>
Root cause: <system cause, not personalities>
Fix now: <3 actions + owners + ETA>
Prevent: <3 process/tool improvements>
Signals to watch: <SLO/metrics>
8) Rituales y cadencia
Revisión semanal de Ops (30 min): SLO, incidentes, alertas, progreso de las acciones.
Retrospectiva mensual de la fiabilidad: lecciones, tendencias, actualización de estándares.
Reliability Review trimestral: revisión de SLO/presupuestos, integración en la hoja de ruta.
Días de juego/Chaos: scripts planificados para fallas y failover.
9) Motivación, crecimiento y trayectorias
Competencias: on-call, gestión de incidentes, observabilidad, ingeniería SLO, FinOps.
Niveles de carrera: expectativas para contribuir a la confiabilidad (iniciativas, postmortems, mentoring).
Motivación intangible: reconocimiento, autoría de las mejoras, «Reliability Champion» del trimestre.
Material: compensación on-call, bonificaciones para lograr SLO-KPI.
10) Políticas y normas de conducta (fragmentos)
Política de «parada de grúa»:- Cualquier coll puede poner la liberación/ficha en pausa cuando SLO amenaza.
- La decisión se fija y revisa una vez eliminado el riesgo.
- Grandes cambios solo con fichflags y canarios.
- Autogates por métricas SLO; desviación → pausa/retroceso.
- Toda la información crítica está en canales compartidos, sin soluciones privadas.
- ETS (Estimated Time to Status) es obligatorio para incidentes de P1/P2.
11) Métricas culturales (KPI de madurez)
SLO Coverage: proporción de rutas críticas con SLO/alertas formalmente descritas.
Tasa de detección previa al incidente: proporción de incidentes interceptados en la fase de degradación.
MTTR/MTTD: dinámica por barrios.
Change Failure Rate: retrocesos/regresiones después de lanzamientos.
Acción postmortem SLA: proporción de acciones cerradas a tiempo.
Alert Fatigue Index: alertas en el call/turno.
Puntuación de calidad Handoff: calidad de transmisión entre turnos.
Psychological Safety Pulse: una breve encuesta regular (anónima).
12) Lista de verificación de implementación
- Dominios, propietarios, on-call y SLO definidos.
- Se adoptaron políticas de «stop grúa», postmortems y comunicaciones.
- Se levantó el panel SLO y las anotaciones de las versiones.
- Rituales lanzados: Revisión semanal de Ops y hendover por plantilla.
- Se han desarrollado plantillas postmortem y rastreador de acciones.
- Se realizó el primer juego-día/DR-enseñanza.
- Configurado por KPI de cultura y revisión mensual.
13) Anti-patrones
Culto a los héroes: rescatamos en el último minuto en lugar de correcciones del sistema.
La culpa de la gente es: encontrar al «culpable», no la razón.
Soluciones ocultas: chats privados, «arreglos orales».
Grandes lanzamientos nocturnos: sin banderas y canarios.
Métricas sin acción: hay informes, no hay soluciones.
Hendover caótico: no hay plantilla y confirmación de admisión.
14) Herramientas y artefactos (mínimo)
Catálogo de SLO/alertas con propietarios.
repositorio de runbook (por dominios, actualización ≥ mensual).
Plantillas: postmortem, hendover, apdate del incidente, plan de degradación.
Панели: SLO Overview, Incidents, Change Safety, Providers.
Rastreador de acciones: un único backlog con SLA y propietarios.
15) Incrustación en contornos HR
Onboarding: entrenamientos en SLO, on-coll, postmortems.
Evaluación del rendimiento: la contribución a la fiabilidad y la cultura es parte de la revisión del rendimiento.
Tutoría: shadow-service, gestión de incidentes en pareja.
Encuestas de pulso: evaluación trimestral de seguridad/burnout.
16) 30/60/90 - plan de lanzamiento
30 días:- Asignar propietarios de dominios y on-call, fijar un mínimo por SLO (p95, tasa de éxito).
- Adoptar políticas de «stop grúa» y postmortems, aprobar plantillas.
- Ejecutar una revisión semanal de Ops y un ritual de hendover.
- Realice 2 ejercicios de juego/DR, levante el panel SLO y cambie la seguridad.
- Incorpora canarios y autogates a través de SLO en 1-2 servicios críticos.
- Ejecutar métricas de cultura (MTTR, Action SLA, Pulse-encuesta).
- Análisis de tendencias, actualización de presupuestos/SLO, integración de mejoras en la hoja de ruta.
- Introduzca «Reliability Champion» y el programa de tutoría.
- Ajustar los rituales y las políticas de acuerdo con los resultados retrospectivos.
17) Plantillas (fragmentos)
Política postmortem (conjecto):
scope: P1/P2 and repeated P3 timeline: ≤72 hours format: impact, timeline, root cause, actions (now/prevent), owners/due dates review: monthly on Reliability Review blameless: specifying personalities only as a fact of time stamp
Estándar de hendover (encabezados):
SLO summary Incidents and ETAs Providers and quotas Releases/Canaries Risks/observations Action items
Definición de lectura para el lanzamiento:
- Ficheflags/canary set up
- SLO alerts and annotations included
- Rollback plan and "safe mode" defined
- Provider windows considered
- Responsible on-call confirmed
18) FAQ
P: ¿Cómo medir la «cultura» y no solo la técnica?
R: Introduzca Pulse-encuesta (seguridad psicológica), Acción SLA postmortem, proporción de decisiones públicas, HQS hendover.
P: ¿Qué hacer con el «heroísmo»?
R: Agradecer, pero registrar los cambios sistémicos para que no se requiera heroísmo. En performance, tener en cuenta la prevención y las mejoras, no solo las «hazañas».
P: ¿Cómo convencer a las empresas del valor de la cultura?
R: Mostrar la conexión: reducción de MTTR/Change Failure Rate → aumento de la conversión/ingresos, menos penalizaciones y paginas nocturnas, lanzamientos predecibles.