Observabilidad en Producción — Cultura y Prácticas
Observabilidad en Producción — Cultura y Prácticas
La observabilidad es una práctica, no solo tecnología
Puedes tener las mejores herramientas del mundo — Honeycomb, Datadog, el stack más sofisticado — y aún así tener un sistema operativamente caótico si el equipo no tiene las prácticas adecuadas.
La observabilidad efectiva requiere:
- Las herramientas correctas (lo que cubrimos en capítulos anteriores)
- Los procesos correctos (este capítulo)
- La cultura correcta (el punto más difícil y más importante)
On-Call: el arte de estar de guardia
El on-call es la práctica de tener ingenieros disponibles para responder a incidentes fuera del horario normal. Es una práctica esencial y, cuando está mal implementada, es la principal causa de burnout en equipos de ingeniería.
Principios de un on-call saludable
1. El on-call debe ser sostenible
Si el on-call interrumpe el sueño más de una vez por semana, o genera más de 5 páginas por turno, es insostenible. Los equipos que tienen on-call insostenible pierden ingenieros buenos y crean un ciclo vicioso: menos personas → más carga por persona → más burnout → más rotación.
2. Quien desarrolla, opera
El modelo de “desarrollo” y “operaciones” como equipos separados crea una desconexión fatal: el equipo que desarrolla features no experimenta las consecuencias operativas, y el equipo de operaciones no tiene contexto para mejorar el sistema.
El modelo moderno (DevOps, SRE) pone a los desarrolladores en el on-call. Esto crea el incentivo correcto: si tu código crea incidentes, tú serás quien se despierte a las 3AM.
3. Compensación y reconocimiento
El on-call es trabajo real y debe ser compensado. Muchas empresas pagan “on-call pay” adicional más “incident pay” cuando hay respuesta activa.
graph TD
OC[Turno de On-Call] --> ALERT{¿Hay página?}
ALERT --> |Sí| RESP[Responder incidente]
ALERT --> |No\nmás del 70% del tiempo| REST[Descanso / trabajo normal]
RESP --> RES{¿Resuelto?}
RES --> |Sí| DOC[Documentar en ticket\nActualizar runbook]
RES --> |No en 15 min| ESC[Escalar a siguiente nivel]
DOC --> HANDOFF[Handoff al próximo\nturno on-call]El schedule de on-call
Para un equipo de 4+ personas, un schedule típico:
- Duración del turno: 1 semana (algunos equipos prefieren 2 días)
- Solapamiento: 1 semana de “shadowing” antes del primer turno
- Rotación: Estricta, nadie queda fuera del ciclo
- Escalación: Siempre hay un segundo nivel (el on-call anterior o el manager)
Gestión de incidentes: el proceso
Cuando una alerta se dispara y hay un incidente real, el proceso importa tanto como las herramientas.
sequenceDiagram
participant A as Alerta
participant OC as On-Call
participant IC as Incident Commander
participant COMM as Comms Lead
participant TEAM as Equipo Técnico
A->>OC: Página: p99 latencia 5x normal
OC->>OC: Acknowledge en <5 min
OC->>OC: Evaluar severidad
alt Incidente P1
OC->>IC: Declarar incidente, asignar IC
IC->>COMM: Iniciar comunicaciones a stakeholders
IC->>TEAM: Convocar al equipo relevante
TEAM->>TEAM: Investigar con observabilidad
TEAM->>IC: Causa raíz identificada
IC->>TEAM: Coordinar fix/rollback
TEAM->>IC: Fix aplicado
IC->>COMM: Comunicar resolución
IC->>OC: Incidente resuelto
else Incidente P2/P3
OC->>OC: Investigar solo
OC->>OC: Fix o rollback
OC->>OC: Documentar
endLos roles en un incidente
Incident Commander (IC): No investiga técnicamente — coordina. Toma decisiones cuando el equipo no converge, escala, maneja las comunicaciones hacia arriba. En incidentes pequeños, el on-call puede hacer este rol también.
Communications Lead: Maneja las comunicaciones hacia clientes, stakeholders y management. El IC no puede estar coordinando técnicamente Y escribiendo updates cada 15 minutos — necesita apoyo.
Subject Matter Expert (SME): Los ingenieros que conocen el sistema y hacen el debugging real.
Comunicación durante el incidente
La comunicación durante un incidente es crítica. Reglas básicas:
- Updates frecuentes, aunque no haya novedades: “Seguimos investigando, próximo update en 15 minutos” es mejor que silencio.
- Separar el canal de debugging del canal de comunicaciones: Un hilo de Slack para el equipo técnico, otro para stakeholders.
- No especular sobre causa raíz hasta tener evidencia clara: “Creemos que es X” sin evidencia genera confusión y pérdida de confianza.
Postmortems: aprendiendo de los fallos
Un postmortem (o retrospectiva de incidente) es el proceso de documentar y analizar lo que ocurrió durante un incidente con el objetivo de prevenir que ocurra nuevamente.
La palabra “postmortem” asusta a algunos equipos porque suena a buscar culpables. La práctica moderna es el blameless postmortem: el objetivo es entender el sistema, no castigar personas.
El principio de blameless postmortem
Los sistemas complejos fallan de formas complejas. Cuando un ingeniero comete un error, la pregunta no es “¿por qué fue descuidado?” sino:
- ¿Por qué el sistema permitió que ese error tuviera tanto impacto?
- ¿Por qué los controles existentes no lo detectaron antes?
- ¿Qué condiciones del sistema hicieron que el error fuera fácil de cometer?
La persona que cometió el error estaba tomando decisiones racionales dadas la información y herramientas disponibles en ese momento. El objetivo es cambiar el sistema, no culpar a la persona.
“Human error is the symptom, not the cause.” — Sidney Dekker
Estructura de un postmortem efectivo
# Postmortem: [Título del Incidente]
**Fecha del incidente**: 2026-04-04 14:23 - 15:47 UTC
**Duración**: 84 minutos
**Impacto**: 100% de los checkouts fallaron durante 40 minutos,
degradados 44 minutos adicionales
**Severidad**: P1
**Autores**: [Lista]
**Revisores**: [Lista]
**Estado**: Borrador / En revisión / Finalizado
## Resumen ejecutivo
[2-3 oraciones: qué pasó, cuándo, qué impacto tuvo]
## Timeline
| Tiempo | Evento |
|--------|--------|
| 14:23 | Deploy de payment-service v2.3.2 completado |
| 14:25 | Primera alerta: error rate checkout > 5% |
| 14:28 | On-call acknowledges alerta |
| ... | ... |
| 15:47 | Sistema completamente recuperado |
## Causa raíz
[Descripción técnica precisa de qué falló y por qué]
## Factores contribuyentes
[Qué condiciones hicieron posible el incidente]
## Qué funcionó bien
[Qué detectó el problema rápido, qué limitó el impacto]
## Qué no funcionó bien
[Qué tardó más de lo necesario, qué faltó]
## Action items
| Acción | Owner | Fecha límite | Prioridad |
|--------|-------|--------------|-----------|
| Agregar feature flag al nuevo código de pagos | @juan | 2026-04-11 | P1 |
| Mejorar alerta de latencia de Stripe | @maria | 2026-04-18 | P2 |Las preguntas que guían un buen postmortem
- ¿Qué evento precipitante inició el incidente?
- ¿Qué condiciones preexistentes lo hicieron posible?
- ¿Cómo se detectó el problema? ¿Podría haberse detectado antes?
- ¿Qué dificultó o prolongó el diagnóstico?
- ¿Qué acciones de mitigación funcionaron y cuáles no?
- ¿Cómo prevenimos que esto ocurra de nuevo?
Runbooks: la memoria operativa del equipo
Un runbook es un documento que describe cómo responder a una situación operativa específica. Es la guía práctica que el on-call consulta durante un incidente.
Características de un buen runbook
graph TD
RB[Runbook efectivo] --> AC[Accionable\nPasos concretos, no teoría]
RB --> CX[Contextual\nExplica el qué y el por qué]
RB --> UP[Actualizado\nVerificado después de cada incidente]
RB --> LI[Links\nAl dashboard, logs, código relevante]
RB --> ES[Escalación clara\nA quién llamar si falla]Estructura típica de un runbook
# Runbook: Payment Service — High Error Rate
## Cuándo usar este runbook
Cuando la alerta `PaymentServiceHighErrorRate` se dispara,
o cuando el error rate del payment service supera el 2%.
## Impacto
- Checkout completamente bloqueado si error rate > 50%
- Revenue impactado directamente
## Dashboard
https://grafana.example.com/d/payment-service
## Diagnóstico rápido (primeros 5 minutos)
1. Verificar si es un deploy reciente:kubectl rollout history deployment/payment-service
Si hay un deploy en los últimos 30 min → ir a "Rollback"
2. Verificar el tipo de error:
- HTTP 503: problema de disponibilidad del servicio
- HTTP 504: problema de timeout (Stripe u otra dependencia)
- HTTP 500: bug de código
3. Revisar logs del payment-service:
https://grafana.example.com/explore/loki?service=payment-service&level=error
## Acciones por tipo de problema
### Rollback de deploy
```bash
kubectl rollout undo deployment/payment-service
kubectl rollout status deployment/payment-serviceStripe está lento/caído
- Verificar https://status.stripe.com
- Si hay incidente en Stripe: activar modo de “pago diferido”
kubectl set env deployment/payment-service PAYMENT_MODE=deferred - Notificar a stakeholders con template de comunicación: [link]
Escalación
- Si no se resuelve en 15 minutos: llamar al tech lead de Payments
- Si Stripe está caído y no hay ETA: escalar a VP Engineering
---
## Game Days: practicando el caos
Un **Game Day** (o Chaos Engineering experiment) es una práctica planificada donde el equipo simula fallos para verificar que los sistemas y procesos de respuesta funcionan como se espera.
El concepto fue popularizado por Netflix con **Chaos Monkey** — un servicio que aleatoriamente terminaba instancias en producción para verificar que el sistema era realmente resiliente.
### Tipos de Game Days
**Tabletop exercise**: Simulación en papel/pizarrón. "¿Qué haríamos si la base de datos principal fallara?" Sin afectar sistemas reales, el equipo recorre el incidente hipotético.
**Fire drill**: Simulación real pero controlada en staging. El equipo introduce una falla y tiene que diagnosticarla y resolverla.
**Production chaos**: Introducir fallos en producción de manera controlada (con rollback automático). Herramientas como Gremlin o el Chaos Monkey original.
```mermaid
flowchart TD
PLAN[Planificar experimento\n¿Qué fallo simulamos?\n¿En qué entorno?\n¿Cuándo?] --> HYPO[Hipótesis\n¿Qué esperamos que ocurra?]
HYPO --> METRIC[Definir métricas\nde éxito/fallo]
METRIC --> EXEC[Ejecutar\ncon rollback claro]
EXEC --> OBS[Observar\ncon herramientas de observabilidad]
OBS --> COMPARE{¿Hipótesis\ncumplida?}
COMPARE --> |Sí| CONFIRM[Confirmar resiliencia\nDocumentar]
COMPARE --> |No| LEARN[Aprender\nFix + re-test]Ejemplos de experimentos de chaos
- Terminar un pod aleatoriamente (¿el autohealing funciona?)
- Inyectar latencia en la comunicación entre servicios (¿los timeouts están bien configurados?)
- Saturar la base de datos (¿el circuit breaker actúa correctamente?)
- Cortar la conectividad a una dependencia externa (¿hay fallback?)
Capacity Planning: observabilidad hacia el futuro
La observabilidad no es solo para el presente. Los datos históricos de métricas permiten planificar la capacidad futura.
xychart-beta
title "Crecimiento de tráfico y proyección de capacidad"
x-axis ["Ene", "Feb", "Mar", "Abr", "May", "Jun", "Jul", "Ago", "Sep"]
y-axis "Requests/segundo" 0 --> 10000
line [1000, 1200, 1400, 1700, 2100, 2600, 3200, 3900, 4800]Con esta tendencia, puedes:
- Predecir cuándo necesitarás más capacidad
- Identificar si el crecimiento es lineal o exponencial
- Planificar deploys de infraestructura antes de que sea urgente
- Calcular el costo de la infraestructura para el año siguiente
La cultura de aprendizaje continuo
La observabilidad efectiva requiere una cultura donde:
Se celebra detectar problemas antes que los usuarios
Si un ingeniero encuentra y arregla un problema antes de que afecte usuarios, eso debe celebrarse — no ignorarse. Es el mejor resultado posible.
Los errores son visibles, no ocultados
Si los errores se ocultan por miedo al castigo, no se pueden mejorar. La cultura blameless es prerequisito.
La observabilidad es parte del definition of done
Un feature no está completo hasta que tiene la instrumentación adecuada: logs estructurados, métricas de las operaciones clave, trazas en los flujos críticos. No es opcional.
Las mejoras de confiabilidad tienen la misma prioridad que las features
Si el error budget se agota, el equipo no trabaja en nuevas features hasta que la confiabilidad mejore. Esta es la mecánica que hace que los equipos inviertan en observabilidad.
Resumen del capítulo
mindmap
root((Cultura de\nObservabilidad))
On-Call Saludable
Sostenible
Turnos rotativos
Compensado
Escalación clara
Gestión de Incidentes
Proceso definido
Roles claros
Comunicación constante
Postmortems
Blameless
Orientados a aprendizaje
Action items con owners
Runbooks
Accionables
Actualizados
Links directos
Game Days
Tabletop exercises
Fire drills
Chaos engineering
Mejora Continua
Métricas de on-call
Revisión de alertas
Capacity planning