{"id":22392,"date":"2021-11-16T17:41:33","date_gmt":"2021-11-16T17:41:33","guid":{"rendered":"https:\/\/www.dotcom-monitor.com\/blog\/2021\/11\/16\/principios-de-la-sre-las-7-reglas-fundamentales\/"},"modified":"2026-08-27T21:25:53","modified_gmt":"2026-08-27T21:25:53","slug":"principios-de-la-sre-las-7-reglas-fundamentales","status":"publish","type":"post","link":"https:\/\/www.dotcom-monitor.com\/blog\/es\/principios-de-la-sre-las-7-reglas-fundamentales\/","title":{"rendered":"Principios SRE: Las 7 Reglas Fundamentales"},"content":{"rendered":"
\"Ilustraci\u00f3n
El libro de Google SRE asume que posees toda la pila. Gran parte de lo que experimentan tus usuarios funciona en infraestructura que no es tuya.<\/figcaption><\/figure>\n

Los siete principios de SRE provienen de una empresa que posee sus centros de datos, su red, sus balanceadores de carga y cada l\u00ednea de c\u00f3digo 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\u00f3n, una pasarela de pago, DNS, un gestor de etiquetas, una API de socios.<\/p>\n

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 \u00e9l se gasta por una ca\u00edda de otro. Las cuatro se\u00f1ales doradas se ven diferentes desde fuera del firewall que desde dentro. Y el riesgo que no puedes eliminar con ingenier\u00eda, tienes que medirlo.<\/p>\n

Este art\u00edculo recorre los siete principios tal como los define el libro Google SRE<\/a>, y luego agrega la parte que el libro omite: c\u00f3mo se ve cada principio cuando dependes de servicios que no controlas. Si eres nuevo en el rol, empieza con qu\u00e9 hace un ingeniero de confiabilidad del sitio<\/a> y luego regresa.<\/p>\n

\u00bfCu\u00e1les son los principios de SRE?<\/h2>\n

Los principios de SRE son las reglas de trabajo que Google codific\u00f3 para operar sistemas confiables a escala: aceptar y gestionar el riesgo, objetivos de nivel de servicio, eliminar trabajo repetitivo, monitoreo, automatizaci\u00f3n, ingenier\u00eda de despliegues y simplicidad. Juntos responden a una pregunta: \u00bfqu\u00e9 tan confiable debe ser este servicio y cu\u00e1l es la manera m\u00e1s barata y sostenible de mantenerlo as\u00ed?<\/p>\n

La lista no ha cambiado desde que se public\u00f3 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\u00e1 en manos de otras compa\u00f1\u00edas. Cada secci\u00f3n a continuaci\u00f3n cubre el principio como est\u00e1 escrito, luego qu\u00e9 se rompe cuando la dependencia no es tuya. Al final, una lista corta de mejores pr\u00e1cticas SRE extra\u00eddas de los siete principios.<\/p>\n

Principio 1 – Aceptar y gestionar el riesgo<\/h2>\n

La formulaci\u00f3n de Google: una confiabilidad del 100% es una meta incorrecta. Los usuarios te alcanzan a trav\u00e9s de redes y dispositivos que fallan por s\u00ed solos, as\u00ed 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\u00f3n como un presupuesto que puedes gastar en lanzar caracter\u00edsticas. El cap\u00edtulo Aceptar Riesgo<\/a> lo explica en detalle.<\/p>\n

Dentro de Google, eso funciona porque el riesgo es una perilla que pueden girar. M\u00e1s replicaci\u00f3n, m\u00e1s redundancia, despliegues m\u00e1s lentos: gasta dinero, gana “nueves”.<\/p>\n

Fuera de Google, parte de esa perilla no est\u00e1 conectada a nada. No puedes a\u00f1adir una r\u00e9plica a tu pasarela de pago. No puedes ajustar el comportamiento de failover de tu proveedor DNS. Su confiabilidad es un t\u00e9rmino contractual, no un par\u00e1metro de ingenier\u00eda.<\/p>\n

As\u00ed que el principio cambia: para los componentes que posees, gestiona el riesgo mediante ingenier\u00eda. Para los que no, gestiona el riesgo mediante medici\u00f3n. Necesitas conocer la disponibilidad real de tu proveedor de autenticaci\u00f3n medida desde el lado de tus usuarios en internet, no el n\u00famero en su p\u00e1gina de estado. Las p\u00e1ginas de estado rutinariamente muestran verde durante interrupciones parciales, y una dependencia que est\u00e1 arriba en su propio centro de datos puede ser inaccesible desde el tuyo. La medici\u00f3n independiente es lo que convierte “creemos que el CDN es inestable” en una conversaci\u00f3n de renovaci\u00f3n respaldada por datos. Este es el primer trabajo que hace Dotcom-Monitor aqu\u00ed: poner una verificaci\u00f3n externa en cada dependencia cr\u00edtica. Una verificaci\u00f3n DNS<\/a> contra los servidores de nombres del proveedor, una verificaci\u00f3n HTTP(S) en el borde del CDN, una verificaci\u00f3n API<\/a> 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\u00fameros lo justifiquen, evita el riesgo: un segundo proveedor DNS, una ruta de pago de reserva, una copia cach\u00e9 del script de terceros.<\/p>\n

C\u00f3mo implementar la gesti\u00f3n de riesgos<\/h3>\n