Logo GH

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.

Matriz RACI (fragmento):
ProcesoRACI
Aprobación de SLOPropietario de dominioJefe de productoSRE/NegocioEquipos
Respuesta a P1Gerente de incidentesHead of OpsPropietario de dominioTodo
postmortemPropietario de dominioHead of OpsSRE/Legal/PRTodo

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».

Mini check-list on-calla:
  • 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.

Plantilla de apdate (breve):

[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.

Plantilla de «post mortem corto»:

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.
Política de cambios:
  • Grandes cambios solo con fichflags y canarios.
  • Autogates por métricas SLO; desviación → pausa/retroceso.
Política de comunicaciones:
  • 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.
60 días:
  • 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).
90 días:
  • 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.

Contact

Póngase en contacto

Escríbanos ante cualquier duda o necesidad de soporte.¡Siempre estamos listos para ayudarle!

Telegram
@Gamble_GC
Iniciar integración

El Email es obligatorio. Telegram o WhatsApp — opcionales.

Su nombre opcional
Email opcional
Asunto opcional
Mensaje opcional
Telegram opcional
@
Si indica Telegram, también le responderemos allí además del Email.
WhatsApp opcional
Formato: +código de país y número (por ejemplo, +34XXXXXXXXX).

Al hacer clic en el botón, usted acepta el tratamiento de sus datos.