Servicios / Observabilidad y SRE
Operar producción sin quemar al equipo ni mentir al negocio
SLOs honestos, instrumentación que sí sirve, alerting humanizable, runbooks vinculados, postmortems sin culpa y on-call sostenible. La operación deja de ser un acto heroico y se vuelve una práctica medible.
Qué resolvemos
Problemas reales de operación de producción
Alertas que nadie atiende
Equipos saturados de notificaciones sin contexto, sin severidad clara y sin acción asociada. La alerta importante se pierde en el ruido.
Sin SLOs, sin criterio de calidad
Producción se mide por sensación, no por números. No hay acuerdo entre producto, ingeniería y negocio sobre qué nivel de servicio es aceptable.
Incidentes sin runbook ni postmortem
Cada incidente se resuelve desde cero, el conocimiento queda en la cabeza de una persona y los mismos errores se repiten cada trimestre.
On-call que quema al equipo
Guardias sin compensación, sin rotación clara, con alertas falsas a las 3 a.m. y sin proceso para mejorar después de cada página.
Qué incluye
Alcance del servicio
Descubrimiento
Inventario de servicios críticos, señales actuales, dolor del equipo on-call, expectativas de negocio y restricciones operativas.
Diseño
Definición de SLIs y SLOs por servicio, política de error budget, modelo de severidad, estructura de runbooks y rotación on-call sostenible.
Implementación
Instrumentación con OpenTelemetry, dashboards de SLO, alerting humanizable basado en burn rate, runbooks vinculados y proceso de postmortem sin culpa.
Transferencia
Capacitación al equipo, plantillas de postmortem, calendario de revisión de SLOs y modelo de mejora continua a partir de cada incidente.
Casos típicos
Tres ejemplos reales (anonimizados)
SaaS B2B definió SLOs por endpoint crítico e implementó alerting por burn rate; alertas falsas bajaron 78% y el tiempo de detección de incidentes reales bajó a la mitad.
Empresa fintech rediseñó on-call con rotación semanal, runbooks vinculados y postmortems sin culpa; rotación de guardia dejó de ser razón de salida del equipo.
Plataforma logística instrumentó trazas distribuidas con OpenTelemetry; un incidente recurrente que tomaba 4 horas diagnosticar se resolvió en 18 minutos la siguiente vez.
Stack
Herramientas que usamos
Preguntas frecuentes
FAQ
¿Qué es un SLO y por qué importa?
Un SLO (Service Level Objective) es el nivel de servicio que prometes cumplir, medido por SLIs concretos. Importa porque convierte 'la app está lenta' en una conversación de números entre producto, ingeniería y negocio, y permite priorizar trabajo de confiabilidad con criterio.
¿Qué significa alerting humanizable?
Alertas con contexto, severidad, runbook vinculado y umbral basado en impacto al usuario (burn rate del SLO), no en métricas técnicas aisladas. El objetivo: cada página despierta a alguien por algo que sí justifica despertarse.
¿El on-call siempre quema al equipo?
No. Un on-call sostenible tiene rotación justa, compensación clara, alertas accionables, runbooks útiles y revisiones periódicas para reducir el ruido. Si el equipo se quema, el problema es de diseño, no de la práctica en sí.
¿Para qué tamaño de empresa aplica SRE?
Aplica desde que tienes producción que importa al negocio. No necesitas un equipo dedicado de SRE: necesitas las prácticas correctas (SLOs, runbooks, postmortems) ajustadas a tu escala.
¿Tu operación se sostiene sola?
Cuéntanos cómo se ve hoy tu on-call y qué incidentes se repiten. Te decimos por dónde empezar para que la operación deje de doler.
Agenda una conversación