Principios SRE: Las 7 Reglas Fundamentales

Los siete principios de SRE provienen de una empresa que posee sus centros de datos, su red, sus balanceadores de carga y cada línea de código intermedia. Probablemente tu pila no se parezca a eso. Gran parte de lo que experimentan tus usuarios funciona en infraestructura a la que no puedes acceder por SSH: un CDN, un proveedor de autenticación, una pasarela de pago, DNS, un gestor de etiquetas, una API de socios.

Esa brecha importa, porque los principios siguen aplicando fuera de Google. Pero varios de ellos cambian una vez que el componente que falla no es tuyo para arreglar. Un presupuesto de errores se comporta diferente cuando un tercio de él se gasta por una caída de otro. Las cuatro señales doradas se ven diferentes desde fuera del firewall que desde dentro. Y el riesgo que no puedes eliminar con ingeniería, tienes que medirlo.

Este artículo recorre los siete principios tal como los define el libro Google SRE, y luego agrega la parte que el libro omite: cómo se ve cada principio cuando dependes de servicios que no controlas. Si eres nuevo en el rol, empieza con qué hace un ingeniero de confiabilidad del sitio y luego regresa.

¿Cuáles son los principios de SRE?

Los principios de SRE son las reglas de trabajo que Google codificó para operar sistemas confiables a escala: aceptar y gestionar el riesgo, objetivos de nivel de servicio, eliminar trabajo repetitivo, monitoreo, automatización, ingeniería de despliegues y simplicidad. Juntos responden a una pregunta: ¿qué tan confiable debe ser este servicio y cuál es la manera más barata y sostenible de mantenerlo así?

La lista no ha cambiado desde que se publicó el libro SRE en 2016. Lo que ha cambiado es la pila promedio. Microservicios, dependencias SaaS y scripts de terceros significan que parte de tu confiabilidad ahora está en manos de otras compañías. Cada sección a continuación cubre el principio como está escrito, luego qué se rompe cuando la dependencia no es tuya. Al final, una lista corta de mejores prácticas SRE extraídas de los siete principios.

Principio 1 – Aceptar y gestionar el riesgo

La formulación de Google: una confiabilidad del 100% es una meta incorrecta. Los usuarios te alcanzan a través de redes y dispositivos que fallan por sí solos, así que pasados cierto punto, los “nueves” extra cuestan dinero real y nadie puede notar la diferencia. Elige un objetivo de confiabilidad que el negocio pueda defender, y trata la diferencia entre ese objetivo y la perfección como un presupuesto que puedes gastar en lanzar características. El capítulo Aceptar Riesgo lo explica en detalle.

Dentro de Google, eso funciona porque el riesgo es una perilla que pueden girar. Más replicación, más redundancia, despliegues más lentos: gasta dinero, gana “nueves”.

Fuera de Google, parte de esa perilla no está conectada a nada. No puedes añadir una réplica a tu pasarela de pago. No puedes ajustar el comportamiento de failover de tu proveedor DNS. Su confiabilidad es un término contractual, no un parámetro de ingeniería.

Así que el principio cambia: para los componentes que posees, gestiona el riesgo mediante ingeniería. Para los que no, gestiona el riesgo mediante medición. Necesitas conocer la disponibilidad real de tu proveedor de autenticación medida desde el lado de tus usuarios en internet, no el número en su página de estado. Las páginas de estado rutinariamente muestran verde durante interrupciones parciales, y una dependencia que está arriba en su propio centro de datos puede ser inaccesible desde el tuyo. La medición independiente es lo que convierte “creemos que el CDN es inestable” en una conversación de renovación respaldada por datos. Este es el primer trabajo que hace Dotcom-Monitor aquí: poner una verificación externa en cada dependencia crítica. Una verificación DNS contra los servidores de nombres del proveedor, una verificación HTTP(S) en el borde del CDN, una verificación API contra la pasarela de pago. Cada una construye su propio historial de tiempo activo y tiempo de respuesta desde una red global. Y donde los números lo justifiquen, evita el riesgo: un segundo proveedor DNS, una ruta de pago de reserva, una copia caché del script de terceros.

Cómo implementar la gestión de riesgos

• Lista cada dependencia que toca una petición de usuario (DNS, CDN, autenticación, pagos, etiquetas de terceros) y marca cuáles puedes controlar con ingeniería y cuáles solo puedes medir.
• Crea un dispositivo Dotcom-Monitor para cada una que solo puedas medir: una tarea DNS apuntando a los servidores de nombres del proveedor, una tarea HTTP(S) en el borde del CDN, una tarea de servicios web contra el endpoint de pago o autenticación.
• Ejecuta esas verificaciones desde varias ubicaciones de monitoreo en las regiones de tus usuarios, para que una falla regional en el proveedor no se esconda detrás de una región sana.
• Lleva cada reporte de uptime del dispositivo a la conversación con el proveedor e incorpora rutas alternativas (DNS secundaria, camino de pago de respaldo) solo cuando esos datos indican que el riesgo justifica el costo.

Principio 2 – Objetivos de Nivel de Servicio (SLA, SLO, SLI)

Tres términos se confunden constantemente, aquí el desglose:

• SLA (Acuerdo de Nivel de Servicio): el contrato. Lo que prometes a los clientes, con penalidades si no lo cumples.
• SLO (Objetivo de Nivel de Servicio): la meta que estableces para un indicador de nivel de servicio, típicamente interna y más estricta que el SLA para saltar tu propia alarma antes del contrato. 99.9% de uptime, completar el pago en menos de 3 segundos, ese tipo de meta.
• SLI (Indicador de Nivel de Servicio): la medición en sí. El número real de uptime, el tiempo real de respuesta, la tasa de error que observaste.

El SLI mide, el SLO apunta, el SLA promete. Todo lo que viene después, incluyendo los reportes de uptime y SLA que entregas a un cliente, depende de que el SLI sea confiable.

Y aquí está la mayor ceguera de muchos equipos: un presupuesto de error es tan preciso como la medición que lo respalda. Si tus verificaciones corren cada 5 minutos, cada caída registrada tiene un inicio y un fin que solo se conoce con 5 minutos de precisión, y las caídas más cortas que ese intervalo pueden pasar sin ser vistas. Esto es lo que hace a un presupuesto mensual con varios objetivos SLO típicos, usando un mes de 30 días (43,200 minutos):

No puedes medir un SLO mensual de 99.99% con verificaciones cada 5 minutos. Un intervalo de verificación es mayor que tu presupuesto mensual entero.

Las matemáticas de probabilidad son igual de estrictas. Con un intervalo de verificación de I minutos, una caída aleatoria que dura D minutos (donde D es menor que I) es detectada con una probabilidad aproximada de D/I, asumiendo que el inicio de la caída es independiente del horario de verificaciones. Así, una caída de 4 minutos con un intervalo de 5 minutos es detectada unas 4 de 5 veces, y la oportunidad restante de 1 en 5 es que la caída ocurra completamente entre dos verificaciones y nunca se registre. Y para caídas más largas que el intervalo, el retraso medio de detección es aproximadamente la mitad del intervalo, así que las verificaciones de 5 minutos agregan un promedio de 2.5 minutos antes de que alguien se entere.

Una aclaración: la tabla asume una sola verificación programada y contabilización basada en intervalos. La confirmación en múltiples ubicaciones y SLIs basados en peticiones cambian detalles, no el problema de muestreo.

Las caídas breves tampoco son un caso marginal. Entre las caídas que Dotcom-Monitor detecta, alrededor del 38% se resuelven en menos de 5 minutos. Son en su mayoría fluctuaciones de ruteo, reinicios, reinicios de procesos y conmutaciones por error que se arreglan antes de que alguien pueda intervenir razonablemente. Nuestro Filtro de Respuesta retiene la alerta precisamente por esta razón. Pero filtrado de alertas no significa filtrado del registro: ese tiempo de inactividad aún cuenta contra el SLA, interno o del proveedor, y debe contabilizarse. De las caídas que sí alertan, más del 56% son resueltas en los primeros 15 minutos después de la notificación, alrededor del 18% superan una hora, y cerca del 3% duran más de 24 horas. La distribución varía según el tipo de servicio, pero la forma se mantiene: más de un tercio de todas las caídas están en el tramo que una verificación de 5 minutos apenas puede detectar. Por eso la frecuencia de verificación es una decisión de medición, no solo un costo: con intervalos de 1 minuto, el quantum de medición baja al 2.3% de un presupuesto mensual al 99.9% en lugar de 11.6%, y las caídas breves que dominan la cantidad de incidentes comienzan a aparecer en tu registro. Por eso Dotcom-Monitor ejecuta verificaciones incluso cada minuto y construye sus reportes SLA sobre el mismo registro: el número de cumplimiento que muestras a un cliente es tan confiable como el muestreo que lo respalda.

Cómo implementar objetivos de nivel de servicio

• Define dos o tres SLIs que tus usuarios reconozcan, como uptime medido desde un navegador real o tiempo de pago, y haz que una verificación Dotcom-Monitor sea la fuente de registro de cada uno.
• Establece cada SLO más estricto que el SLA que protege, y luego ajusta la frecuencia de verificación del dispositivo para que coincida con el nivel: según la tabla anterior, todo lo que pase de 99.9% necesita verificaciones cada 1 minuto.
• Programa reportes de uptime y SLA a las personas que llevan la conversación del SLA, para que el número de cumplimiento venga del mismo registro que las alertas.
• Acordar de antemano qué sucede cuando se agota el presupuesto de errores, mientras nadie discute un incidente específico.

Principio 3 – Eliminar el trabajo repetitivo

El trabajo repetitivo es trabajo manual, repetitivo que escala con el tamaño del servicio y no produce valor duradero. El capítulo Eliminar trabajo repetitivo fijó un límite famoso: los SREs no deberían gastar más de la mitad de su tiempo en ello, y el resto en ingeniería que elimine ese trabajo.

Las definiciones abstractas hacen que el trabajo repetitivo sea fácil de aceptar pero difícil de encontrar. Así que nómbralo. En la mayoría de los equipos, se parece a esto:

• Alguien inicia sesión cada mañana para confirmar que el flujo de compra sigue funcionando.
• Alguien prueba manualmente el formulario de inscripción tras cada despliegue.
• Alguien mantiene un recordatorio en calendario para la expiración del certificado SSL.
• Alguien consulta manualmente una API de socio cuando aumentan los tickets de soporte, para ver si el problema es de tu lado o del suyo.

Cada uno es una transacción scriptada por escribir, y es donde Dotcom-Monitor brilla directamente. Un script grabado con EveryStep, su grabador de transacciones por clics, recorre el mismo camino de compra cada pocos minutos desde un navegador real y avisa en el momento que falla un paso. Sus chequeos de certificados vigilan fechas de expiración sin calendario. Sus verificaciones API revisan el endpoint del socio en horario y guardan el historial de tiempo de respuesta que resuelve la discusión “nosotros o ellos” de un vistazo.

La prueba para decidir qué automatizar primero no es sofisticación, es recurrencia. La verificación que una persona hace diariamente es la que una máquina debería hacer cada minuto.

Cómo implementar la eliminación de trabajo repetitivo

• Lleva un registro de una semana de cada verificación manual hecha por alguien del equipo; la recurrencia, no la dificultad decide qué se automatiza primero.
• Graba la más frecuente como un script EveryStep haciendo clic a través del flujo una sola vez, y déjalo correr cada pocos minutos en lugar de una vez al día.
• Reemplaza el calendario de expiración de certificados con verificaciones SSL de Dotcom-Monitor, y pon las APIs de socios en chequeos programas de servicios web para que nadie las gestione por memoria.
• Registra las horas de verificación manual removidas cada trimestre, para que el trabajo de automatización siga visible y financiado.

Principio 4 – Monitoreo y las Cuatro Señales Doradas

El capítulo Monitoreo de Sistemas Distribuidos nombra cuatro señales doradas: latencia, tráfico, errores y saturación. Monitorea esas cuatro y captarás la mayor parte de lo que falla.

El capítulo menciona el monitoreo de caja negra, pero la mayoría de los equipos termina instrumentando las cuatro señales desde dentro del sistema. En cambio, míralas desde donde están tus usuarios, y tres de las cuatro cambian:

Lee la tabla honestamente y la conclusión no es “fuera es mejor.” Es que ninguno de los dos puntos de vista ve todo. Tráfico y saturación pertenecen a tus herramientas internas: Prometheus, Datadog, New Relic, lo que sea tu stack APM. Latencia como se experimenta y errores como se experimenta pertenecen al monitoreo sintético externo. Esa es la mitad que cubre Dotcom-Monitor. Las verificaciones en navegador real desde una red global cargan tus páginas como lo hacen los usuarios y miden todo el camino: resolución DNS, handshake TLS, borde CDN, renderizado de página, pasos de usuario scriptados. Las verificaciones de protocolo para HTTP(S), API, DNS, TCP e ICMP vigilan las dependencias alrededor de la página. No compiten; son diferentes vistas de las mismas cuatro señales, y necesitas ambas.

La regla práctica: cada señal que tus usuarios pueden sentir necesita al menos una medición tomada desde donde están ellos. Un dashboard APM que muestra verde mientras el CDN sirve páginas de error en caché a mitad de Europa no es hipotético. Es el modo estándar de falla del monitoreo solo interno.

Cómo implementar monitoreo

• Mantén tráfico y saturación en tu stack APM o Prometheus; da latencia y errores a las verificaciones en navegador real de Dotcom-Monitor que corran desde las regiones donde están realmente tus usuarios.
• Configura aserciones de contenido en esas verificaciones, no solo chequeos de código de estado, para que el pago roto detrás de un HTTP 200 falle como falla para un usuario.
• Script las transacciones que importan (login, búsqueda, pago) con EveryStep, para que el monitoreo recorra el mismo camino que tus usuarios.
• Compara regularmente los números dentro y fuera; la brecha entre ellos es tu capa CDN, DNS y de terceros.

Principio 5 – Automatización

El argumento SRE para la automatización es consistencia a escala. Los humanos olvidan pasos, las máquinas no, y cualquier respuesta que deba ocurrir a las 3 a.m. no debería depender de un humano despierto a esa hora.

La parte que cambia fuera de Google: la automatización solo es tan buena como la señal que la dispara. Scripts de conmutación, trabajos de reversión y reglas de autoescalado se activan con un evento de detección, así que cada minuto de retraso en la detección es un minuto sumado a la respuesta automatizada que has construido. Las matemáticas del apartado SLO aplican directamente: un failover automatizado activado por una verificación de 5 minutos le da a la caída una ventaja promedio de 2.5 minutos.

Y algunos disparadores de automatización solo pueden venir desde afuera. Un script que conmute a un proveedor de pago de respaldo necesita saber que el principal falla para los usuarios, no solo que su endpoint de salud responde pings desde la misma red. Dotcom-Monitor cierra ese ciclo al activar alertas y webhooks desde sus verificaciones externas, para que el failover se active con base en lo que experimentan los usuarios y no con lo que dice el endpoint de salud.

Cómo implementar automatización

• Empieza con las respuestas que ya haces manualmente durante incidentes: reinicios, conmutaciones, reversión de despliegues.
• Enlaza los webhooks de alerta de Dotcom-Monitor con los scripts que las ejecutan, para que el disparador sea una falla confirmada externamente, no un endpoint interno.
• Usa grupos de escalamiento de alerta para que la primera notificación llegue a la persona o sistema que actúa, no a una bandeja compartida que nadie revisa a las 3 a.m.
• Deja que el Filtro de Respuesta absorba picos que se resuelven solos para que no disparen automatizaciones, y revisa los disparadores trimestralmente contra la tasa de falsos positivos.

Principio 6 – Ingeniería de despliegues

La ingeniería de despliegues es la disciplina de construir y lanzar software de la misma manera cada vez: builds versionadas, pipelines repetibles, reversión que funciona porque se ha ensayado.

El CI/CD moderno cubre la mayoría de eso dentro del pipeline. Pasan tests, se construyen artefactos, los despliegues salen con flags. Lo que el pipeline no puede decirte es si el sistema funciona para los usuarios una vez lanzado. El CI prueba la build; por sí sola no dice nada sobre el registro DNS que no se propagó, la caché CDN que sirve el paquete viejo, la etiqueta de terceros que se rompió en combinación con tu nuevo código, o el valor de configuración que solo existe en producción.

Esa es la brecha que llena la verificación post-despliegue. Un script EveryStep que recorre la ruta crítica (cargar la página, iniciar sesión, completar la transacción), ejecutado desde la red de Dotcom-Monitor contra producción inmediatamente tras cada lanzamiento, es la única prueba que ejercita lo que los usuarios realmente obtienen. Los equipos que usan uno lo tratan como la última etapa del pipeline: despliegue, verificar desde fuera, y solo entonces marcar el despliegue como terminado. Si la verificación falla, la reversión se activa mientras el radio de daño sigue siendo medido en minutos.

Cómo implementar ingeniería de despliegues

• Versiona cada build y haz que la reversión sea una acción ensayada y de un solo paso en lugar de improvisada.
• Haz un script EveryStep contra producción la etapa final del pipeline de despliegue, ejecutado desde la red de Dotcom-Monitor para que DNS, caché CDN y etiquetas de terceros sean parte de la prueba.
• Apunta el webhook de alerta de la verificación de vuelta al pipeline, para que una ejecución fallida post-despliegue sea una señal automática de reversión en lugar de un ticket para la mañana siguiente.
• Mantén la misma verificación entre despliegues; su historial es tu línea base para saber si un despliegue hizo las cosas más lentas.

Principio 7 – Simplicidad

El capítulo Simplicidad sostiene que confiabilidad y complejidad se contraponen: cada componente que agregas es un componente que puede fallar, y el software debería ser tan complejo como el trabajo lo requiera.

Aplica eso a la pila de monitoreo, porque allí la complejidad se acumula silenciosamente. Los equipos terminan con una herramienta APM, una plataforma de logs, un ping de uptime, un servicio de páginas de estado y tres dashboards que nadie abre. Cada herramienta alerta en su propio calendario, y el resultado combinado es la fatiga de alertas: tantas notificaciones que la que importa se barre junto con las demás.

Que un proveedor de monitoreo te diga que uses menos herramientas es un argumento inusual, justo por eso vale la pena hacerlo. La prueba de simplicidad para una pila de monitoreo tiene dos preguntas. Primera: para cada cosa que monitoreas, ¿sabes qué herramienta es la autoritaria cuando dos discuten? Segunda: ¿cada alerta que se dispara tiene una persona que actúa? Si una herramienta falla ambas preguntas para todo lo que vigila, no está monitoreando, es ruido con una cuota. Consolidar monitoreo de uptime, transacciones, API e infraestructura en una plataforma con un solo camino de alertas es una decisión de simplicidad antes que de compra. Así es como se construye Dotcom-Monitor: esas verificaciones en un sitio, un camino de alerta, trabajando junto a la herramienta APM que vigila el interior sin reemplazarla.

Cómo implementar simplicidad

• Haz un inventario de tus herramientas de monitoreo y anota, para cada una, la única cosa para la que es autoritaria.
• Borra todas las alertas que no tienen dueño ni acción asociada; si nadie actúa sobre ellas, es ruido.
• Integra las verificaciones externas (uptime, página, transacción, API, infraestructura) en Dotcom-Monitor como una plataforma con un solo camino de alertas, y deja que tu APM mantenga el interior.
• Repite la auditoría anualmente; las pilas de monitoreo regenera complejidad por sí solas.

Mejores prácticas SRE

Los principios dicen qué buscar. Estas son las prácticas que funcionan en equipos que no poseen toda su pila:

• Establece SLOs en lo que experimentan los usuarios, no en lo que reportan los servidores. “El pago se completa en menos de 4 segundos desde un navegador real” es un SLO que los usuarios reconocerían. “API p95 bajo 200ms” es un insumo para ello.
• Ajusta la frecuencia de verificación a tu SLO. Según la tabla del presupuesto de errores arriba: a 99.95%, un quantum de 5 minutos ya come el 23% del presupuesto mensual, y a 99.99% lo excede completamente. Trata las verificaciones de 1 minuto como el piso práctico desde 99.95% en adelante.
• Monitorea tus dependencias como te monitoreas a ti mismo. DNS, CDN, pagos, autenticación: una verificación externa por dependencia crítica, con su propio historial de tiempo de respuesta. Cuando su página de estado dice verde y tus usuarios dicen que está roto, estos datos resuelven la disputa.
• Escribe la política del presupuesto de errores antes de gastar el presupuesto. Acordar de antemano qué sucede cuando el presupuesto se agota: congelar características, sprints de confiabilidad, prioridades en postmortems. Un presupuesto sin política es un gráfico que nadie usa.
• Ensaya la respuesta a incidentes antes de necesitarla. Rotaciones de guardia, rutas de escalamiento y postmortems sin culpas se tratan en profundidad en nuestra guía SRE incident management.
• Mantén honesto el número de herramientas. Audita la pila de monitoreo anualmente con base en las dos preguntas de simplicidad arriba. Nuestro resumen de herramientas SRE cubre las categorías que vale la pena conservar.
• Haz del reporte de confiabilidad un hábito, no una urgencia. Reportes programados de uptime y SLA significan que la conversación de cumplimiento parte de números compartidos en lugar de una excavación en logs tras una disputa.

La conclusión

Los siete principios de SRE sobrevivieron la salida de Google. Lo que no sobrevivió es la suposición detrás: que el equipo que los aplica controla la pila a la que se aplican. Tú no la controlas, y eso cambia el trabajo. El riesgo que no puedes eliminar con ingeniería debe ser medido. Los presupuestos de errores son tan reales como el intervalo de verificación que los respalda. Las herramientas internas controlan tráfico y saturación; la latencia y errores experimentados por el usuario solo aparecen desde una perspectiva externa. La verificación post-despliegue debe ejecutarse desde fuera, porque es el único lugar donde existe todo el sistema.

El hilo común es la medición desde afuera. Cada principio, aplicado a una pila llena de componentes que no posees, termina necesitando un punto de vista independiente: verificaciones por dependencia para riesgo, intervalos de 1 minuto para presupuesto de errores, navegadores reales para las señales doradas, transacciones scriptadas para trabajo repetitivo y despliegues, una plataforma para simplicidad. Ese es el papel que juega Dotcom-Monitor en los siete. No es una preferencia de herramienta; es lo que los principios requieren cuando la pila deja de ser tuya.

Preguntas Frecuentes