Módulo 5: The Incident Lifecycle
6. On-call, con honestidad sobre su costo
Descripción
El Módulo 1, lección 7 ya definió on-call, citado de Google SRE: disponibilidad comprometida, con un límite explícito —"no more than 25% [of an engineer's time] can be spent on-call"—. Esta lección no repite esa definición; la extiende con el ángulo que VALIDACION.md marcó como faltante crítico en todo el mercado: el costo real, financiero y operativo, de cómo se implementa esa disponibilidad, con la cita completa de Hacker News que motiva, directamente, el diseño de la rotación que la lección 7 va a construir.
Conexión con el módulo
Esta lección es, a propósito, la más honesta del módulo: no promete que una buena rotación de guardia resuelve todos los problemas de confiabilidad de un sistema. Nombra, con la misma precisión que el resto de esta guía aplica a cada caso representativo, qué SÍ resuelve una rotación bien diseñada y qué NO — y por qué la forma en que se implementa (portable, o encerrada dentro de una sola herramienta) importa tanto como el diseño mismo de los turnos.
La cita, sobre el costo real de encerrar el on-call dentro de una sola herramienta
src/paths/aws-cloud-ecosystem/VALIDACION.md, la misma auditoría de mercado que motivó el diseño completo de esta guía, cita un comentario real de Hacker News, del usuario jamiemallers (hilo 47088882), sobre el patrón de precios de las plataformas de guardia comerciales y el riesgo real de depender de una sola de ellas:
"Switching costs are higher than almost any other category."
— jamiemallers, Hacker News (#47088882)
El punto completo, verificado contra la fuente para esta lección: el comentario señala que herramientas de guardia como PagerDuty tienden a seguir un patrón de precios conocido —costo bajo al inicio, para asegurar la adopción, subiendo el costo por asiento una vez que la herramienta ya está profundamente integrada en el flujo de trabajo diario de un equipo—. Lo que hace que ese patrón funcione, específicamente para herramientas de guardia, es que las cadenas de escalamiento, los horarios, y las integraciones con monitoreo terminan tan entrelazadas con la plataforma específica que migrar a otra herramienta deja de ser una decisión técnica simple y se convierte en un proyecto completo de reingeniería de procesos. La recomendación concreta del comentario: tratar el enrutamiento de guardia como una capa delgada y portable — horarios guardados en un formato simple (el comentario menciona YAML), enrutamiento de alertas basado en estándares abiertos — en vez de construir el flujo de trabajo completo directamente dentro de la interfaz propietaria de un solo proveedor.
EL PATRON QUE LA CITA DESCRIBE
Adopcion inicial Meses/anos despues El costo real
───────────────── ──────────────────── ──────────────
Precio bajo, Horarios, cadenas de Migrar exige
facil integrar con escalamiento e reconstruir todo
el monitoreo existente integraciones ya viven ese proceso desde
│ DENTRO de la plataforma cero, en otra
▼ │ herramienta
Equipo adopta ▼ │
la herramienta El proveedor sube ▼
con confianza el precio por asiento "Switching costs
higher than
almost any
other category"Qué SÍ resuelve una rotación de guardia bien diseñada
Una rotación clara y predecible resuelve un problema real y concreto: la ambigüedad de "¿a quién llamo?" en el momento exacto en que un incidente se declara. Sin ella, ese primer minuto de un incidente real se gasta averiguando quién está disponible, en vez de empezando a responder. Una rotación bien diseñada también distribuye el costo humano del on-call de forma predecible y auditable —cada persona sabe, con semanas de anticipación, cuándo le toca, en vez de depender de la buena voluntad de quien conteste primero—, y hace posible verificar, con datos, si el límite del 25% que Google SRE ya cita se está respetando o no.
Qué NO resuelve una rotación de guardia, sin importar qué tan bien diseñada esté
No reduce la cantidad de veces que algo se rompe. Una rotación perfecta no mejora la calidad del código desplegado, ni reduce el número real de alertas de ALERTING-POLICY.md que disparan — eso es trabajo de ingeniería (mejores pruebas, mejores runbooks, el Módulo 7 completo de esta guía), no de programación de turnos. No elimina el costo humano de ser interrumpido, solo lo distribuye de forma más justa — el propio límite del 25% que Google SRE se impone es, en sí mismo, una admisión de que el on-call tiene un costo real, incluso dentro de la organización que probablemente maneja este proceso con más rigor que casi cualquier otra en la industria. No sustituye una buena clasificación de severidad — una rotación de guardia perfecta, combinada con una matriz de severidad mal diseñada que dispara SEV1 por cada anomalía menor (el error que la lección 3 de este módulo ya nombró), agota a cualquier equipo igual de rápido, sin importar qué tan justos sean los turnos. Y, el punto central de esta lección: no protege contra el costo de cambiar de herramienta si el proceso completo de guardia queda construido, sin ninguna capa de portabilidad, dentro de la interfaz propietaria de un solo proveedor.
Por qué esto importa para la lección 7
La lección 7 de este módulo construye oncall/schedule.py con esta cita como restricción de diseño explícita, no como una idea abstracta: sin ningún SaaS, sin ninguna integración propietaria, con la rotación completa expresada en estructuras de datos de Python tan simples que exportarlas a YAML o JSON —el mismo formato portable que la cita de esta lección recomienda— es una sola línea de código, nunca una reingeniería completa. La decisión de construir la rotación así, desde el principio, es la aplicación directa de la lección que esta cita de Hacker News enseña: la portabilidad no se agrega después, con esfuerzo — se diseña desde el primer día, o se paga después, con switching costs reales.
Errores comunes
Interpretar esta lección como "nunca uses una herramienta comercial de guardia" (de sobre-generalizar la cita). Qué pasa: alguien concluye que PagerDuty u Opsgenie son, por diseño, malas decisiones para cualquier equipo. Cómo detectarlo: si tu conclusión de esta lección es "las herramientas de guardia comerciales son un error". Cómo corregirlo: el Módulo 4, lección 7 de esta misma guía ya nombró PagerDuty/Opsgenie como el destino real de una alerta en un equipo de producción real —representativo, sin capa $0, pero real y ampliamente usado—. El punto de esta lección no es evitar esas herramientas, es no construir el proceso completo dentro de ellas sin ninguna capa de portabilidad propia — la diferencia entre usar una herramienta y quedar encerrado en ella.
Asumir que el límite del 25% de Google SRE es solo una cifra corporativa arbitraria, sin relevancia para un equipo pequeño como Andes Cargo (repetido del mismo error ya nombrado en el Módulo 1, lección 7, ahora con consecuencias de diseño reales). Qué pasa: alguien diseña una rotación con solo dos personas, sin verificar si eso implica que cada una está de guardia el 50% del tiempo. Cómo detectarlo: si tu rotación de guardia no incluye suficientes personas como para que nadie exceda el 25% de tiempo en guardia primaria. Cómo corregirlo: la lección 7 de este módulo va a diseñar la rotación de Andes Cargo con exactamente el número mínimo de personas que respeta ese límite — cuatro personas, una semana de cada cuatro, es 25% justo, el techo, no un margen cómodo por debajo de él.
Tratar "on-call bien diseñado" como sinónimo de "sistema confiable" (de confundir capacidad de respuesta con prevención). Qué pasa: alguien, después de construir la rotación de la lección 7, asume que Andes Cargo ya tiene resuelta su confiabilidad, sin necesitar mejorar nada más. Cómo detectarlo: si tu razonamiento es "ya tenemos guardia, ya estamos cubiertos". Cómo corregirlo: esta lección fue explícita en la sección "Qué NO resuelve" — una rotación de guardia es capacidad de respuesta, no un mecanismo de prevención. El Módulo 7 de esta guía (postmortems, runbooks, action items) es, específicamente, el trabajo que reduce cuántas veces la guardia necesita responder en primer lugar; sin ese trabajo, la mejor rotación del mundo solo distribuye el mismo volumen de interrupciones de forma más justa, sin reducirlo.
Ejercicios
Ejercicio 1 — Explica, sin usar la palabra "SaaS", qué hace que el on-call sea un tipo de herramienta con "switching costs" particularmente altos, comparado con, por ejemplo, cambiar de proveedor de hosting de un sitio web estático.
Ver solución
Cambiar de proveedor de hosting para un sitio estático, en general, requiere mover archivos y actualizar un registro DNS — un cambio técnico contenido, con poco o ningún proceso humano entrelazado. El on-call, en cambio, no es solo una pieza de infraestructura: es un proceso humano operativo —quién responde, en qué orden se escala si no contesta, cómo se integra con cada sistema de monitoreo que ya existe— que, con el tiempo, se entrelaza profundamente con los hábitos reales del equipo. Migrar de herramienta no es solo mover datos; es reconstruir cadenas de escalamiento, reintegrar cada fuente de alertas, y reentrenar a cada persona en el nuevo flujo — exactamente el tipo de costo "más alto que casi cualquier otra categoría" que la cita de esta lección describe.
Ejercicio 2 — Un colega, después de leer esta lección, propone que Andes Cargo nunca use ninguna herramienta comercial de guardia, ni siquiera en producción real con un equipo grande. Usando la sección de errores comunes de esta lección, ¿qué le responderías?
Ver solución
Esta lección no argumenta contra usar herramientas comerciales de guardia — el Módulo 4, lección 7 de esta misma guía ya las nombró como el destino real y esperado de una alerta en un equipo de producción real. El argumento de esta lección es más preciso: el riesgo no está en usar una herramienta comercial, está en construir el proceso completo de guardia sin ninguna capa propia de portabilidad por debajo de ella. Un equipo puede usar PagerDuty en producción y, al mismo tiempo, mantener sus horarios y su lógica de rotación en un formato portable propio (como el oncall/schedule.py que la lección 7 construye) que simplemente se sincroniza hacia la herramienta comercial — de esa forma, si algún día cambia de proveedor, la lógica real de la rotación no se pierde ni hay que reconstruirla desde cero.
Ejercicio 3 — Explica por qué esta lección afirma que una rotación de guardia perfecta, combinada con una matriz de severidad mal diseñada, "agota a cualquier equipo igual de rápido". ¿Qué tienen en común esos dos problemas?
Ver solución
Ambos problemas producen el mismo resultado final —interrupciones frecuentes e innecesarias a la persona de guardia—, solo que por rutas distintas: una rotación mal diseñada concentra las interrupciones de forma injusta en pocas personas; una matriz de severidad mal calibrada, que dispara SEV1 para incidentes que en realidad son SEV3 o SEV4 (el error ya nombrado en la lección 3 de este módulo), multiplica el número total de interrupciones para cualquier persona de guardia, sin importar qué tan justa sea la distribución de turnos. Una rotación perfecta, sobre una matriz de severidad que llama a todo "urgente", sigue distribuyendo, de forma perfectamente justa, un volumen de interrupciones que nunca debió existir en primer lugar — arreglar solo uno de los dos problemas deja el otro intacto.
Resumen y siguiente paso
Esta lección extendió la definición de on-call ya citada en el Módulo 1 con el ángulo del costo real de implementación: la cita completa de Hacker News sobre por qué las herramientas de guardia comerciales tienen switching costs particularmente altos, y la recomendación de tratar el enrutamiento de guardia como una capa portable, no como un flujo de trabajo construido dentro de un solo proveedor sin salida. Nombraste, con la misma honestidad del resto de esta guía, qué SÍ resuelve una rotación bien diseñada (ambigüedad de "a quién llamo", distribución justa, cumplimiento verificable del límite del 25%) y qué NO (la cantidad real de incidentes, el costo humano de ser interrumpido, una mala matriz de severidad, y el riesgo de encierro en un proveedor).
Antes de avanzar deberías poder: citar la frase central de jamiemallers sobre switching costs; explicar la diferencia entre "usar" una herramienta comercial de guardia y "quedar encerrado" en ella; y nombrar, de memoria, qué tres cosas una rotación de guardia por sí sola nunca resuelve.
La lección 7 aplica esta lección directamente: oncall/schedule.py, una rotación semanal fija, determinista, construida desde el primer día sin ningún SaaS, sobre estructuras de datos tan simples que exportarlas a un formato portable —exactamente la recomendación de la cita de esta lección— es trivial.
Recursos
- Hacker News — comentario de jamiemallers (#47088882) — la fuente completa de la cita sobre switching costs del on-call.
- Este mismo repositorio, Módulo 1, lección 7 (
07-the-vocabulary-youll-use-all-guide.md) — la definición de on-call y el límite del 25%, citados de nuevo en esta lección. src/paths/aws-cloud-ecosystem/VALIDACION.md— la fuente que identificó esta cita como el faltante crítico de mercado que motiva este módulo.- Este mismo repositorio, Módulo 4, lección 7 (
07-hands-on-routing-the-alert.md) — PagerDuty/Opsgenie nombrados como el destino real de una alerta en producción, el contraste honesto con esta lección.