Dejar de depurar producción adivinando
Instrumentación, SLOs y práctica de incidentes que convierten una caída de un misterio en una secuencia de preguntas con respuesta.
Hablar con un ingenieroCómo se sabe que hace falta
- Un incidente arranca con veinte minutos de discusión sobre qué servicio tiene la culpa.
- La alerta que salta nunca es la que importa, así que todo el mundo silenció el canal.
- Un cliente reporta un problema antes que su monitoreo.
- Los logs existen, en cuatro lugares, en tres formatos, sin un identificador de request en común.
- Saben que el sistema está lento, pero no en qué salto está la lentitud.
- El mismo incidente ocurre dos veces porque nadie anotó qué lo resolvió.
Qué construimos
Trazas que cubren el request completo
Instrumentación con OpenTelemetry propagando contexto a través de servicios, colas y workers, para que un request lento tenga una cascada en lugar de una teoría.
Logs, métricas y trazas conectados
Un identificador de correlación común a los tres, para que una línea de log lleve a su traza y un pico en una métrica lleve a los requests que lo causaron.
SLOs que reflejan el producto
Objetivos basados en lo que los usuarios notan, con presupuestos de error que informan decisiones de release en lugar de decorar un dashboard.
Alertas por las que valga la pena despertarse
Alertar sobre síntomas y no sobre causas, ajustadas para que una notificación signifique que hay que actuar. Pocas alertas buenas superan a la cobertura ruidosa.
Runbooks y práctica de incidentes
Procedimientos escritos para las fallas predecibles, un proceso posterior al incidente que produce cambios en lugar de culpas, y ensayos antes de la situación real.
Proyectos típicos
Instrumentar un sistema que no tiene nada
Agregar trazas primero a los caminos críticos, unificar formatos de log, y llegar al punto en que un request se puede seguir de punta a punta.
Curar la fatiga de alertas
Auditar cada alerta, eliminar las que nadie atiende, reescribir el resto alrededor de síntomas visibles para el usuario, y definir escalamiento acorde a la severidad.
Definir los primeros SLOs
Elegir el puñado de indicadores que reflejan la experiencia del producto, fijar objetivos alcanzables, y conectarlos con las decisiones de release.
Diagnosticar una latencia que nadie ubica
Instrumentar los caminos sospechosos, perfilar los puntos calientes, y producir una lista ordenada de dónde se va realmente el tiempo.
Armar el proceso de incidentes
Rotación de guardia, niveles de severidad, plantillas de comunicación, y revisiones posteriores que terminan en trabajo registrado.
Qué se lleva
- Servicios instrumentados emitiendo logs, métricas y trazas correlacionados
- Dashboards para las preguntas que se hacen durante un incidente, no una pared de gráficos
- Un conjunto de alertas lo bastante chico como para que se confíe en cada una
- SLOs escritos, con presupuestos de error y qué pasa cuando se agotan
- Runbooks y una plantilla de revisión posterior que su equipo vaya a usar de verdad
Preguntas que nos hacen
¿Qué proveedor de observabilidad usan?
En general el que ya estén pagando. Instrumentamos con OpenTelemetry, que es neutral respecto del proveedor, así que los datos pueden ir a Datadog, Grafana, Prometheus o a un reemplazo futuro sin reinstrumentar todo. Atar la telemetría al SDK propietario de un proveedor es una decisión que se lamenta en la renovación del contrato.
¿Vale la pena antes de tener escala?
El momento más barato para instrumentar es antes de necesitarlo, y el más caro es durante una caída. Dicho eso, es trabajo proporcional: un sistema chico necesita trazas en su camino crítico y un puñado de alertas, no un programa de observabilidad.
¿Pueden ayudar durante un incidente en curso?
Podemos ayudar a estabilizar y después a corregir la causa de fondo, pero conviene saber que llegar en medio de un incidente sin contexto previo es el peor escenario para todos. El valor de este trabajo es que exista de antemano.
Iniciar una conversación
Cuéntenos qué están construyendo, o qué se está rompiendo. Va a recibir una respuesta directa de un ingeniero, no un libreto de ventas.