9.1 Ingeniería de fiabilidad de sitios

Presentación y motivación

La ingeniería de fiabilidad de sitios (SRE) aplica las prácticas de ingeniería de software a la operación de sistemas de producción. En lugar de tratar las operaciones como trabajo manual impulsado por tickets mantenido separado del desarrollo, la SRE trata la fiabilidad como un problema de ingeniería que resuelves con código, medición, y objetivos de servicio claros. La idea central, popularizada por Google pero ahora extendida, es simple: la gente que mantiene los sistemas funcionando debería pasar la mayor parte de su tiempo construyendo automatización y mejorando los sistemas, no apagando incendios a mano una y otra vez con los mismos fallos.

Para los equipos grandes, esto importa porque la escala eleva tanto el valor de la fiabilidad como el costo de equivocarse. Cuando un servicio soporta millones de usuarios o miles de consumidores internos, una hora de inactividad significa ingresos perdidos, transacciones perdidas, y confianza erosionada. Las operaciones manuales que funcionan bien para un puñado de servidores se desmoronan bajo cientos de servicios y despliegue continuo. La SRE te da un lenguaje compartido para la fiabilidad, una manera de hacer explícita la contrapartida entre enviar funciones y mantener las cosas estables, y una manera de mantener esa línea consistentemente entre muchos equipos.

Los contextos empresariales y gubernamentales añaden más peso. Las industrias reguladas como la banca, la salud, y los servicios públicos a menudo cargan compromisos legales o contractuales de disponibilidad, requisitos de auditoría, y poca tolerancia para las interrupciones que afectan a los ciudadanos o la seguridad. Los servicios digitales gubernamentales cada vez más publican sus objetivos de fiabilidad y datos de rendimiento abiertamente. La SRE te da una manera rigurosa y basada en evidencia de definir qué significa «lo bastante confiable», medirlo con honestidad, y defender las prioridades de ingeniería ante el liderazgo y los organismos de supervisión con datos en lugar de opinión.

Véase también: el capítulo 9.2 (observabilidad y monitoreo), el capítulo 9.3 (gestión de incidentes), y el capítulo 3.5 (escalabilidad, rendimiento, y resiliencia).

Principios fundamentales

La fiabilidad es la función más importante. Un sistema que no funciona no vale nada sin importar cuántas funciones tenga, pero la fiabilidad perfecta no es alcanzable ni vale su costo.
Define la fiabilidad con objetivos medibles. Los indicadores de nivel de servicio (SLI), los objetivos (SLO), y los acuerdos (SLA) convierten las expectativas vagas en números en los que todos pueden estar de acuerdo.
El 100 por ciento es el objetivo equivocado. Los usuarios no pueden notar la diferencia entre un sistema muy confiable y uno perfectamente confiable, así que apunta a «lo bastante confiable» y gasta el presupuesto restante en velocidad.
Los presupuestos de error alinean los incentivos. La brecha entre el SLO y el 100 por ciento es un presupuesto para el riesgo que desarrolladores y operadores comparten, reemplazando las discusiones con aritmética.
El esfuerzo repetitivo es el enemigo. El trabajo operacional manual, repetitivo, y automatizable debería medirse, limitarse, y eliminarse sistemáticamente.
Automatiza deliberadamente. La automatización es cómo un equipo pequeño opera un sistema grande; invertir en ella es una actividad de ingeniería de primera clase.
Aprendizaje sin culpa. Los fallos se tratan como oportunidades para mejorar los sistemas y procesos, no para castigar a los individuos.

Recomendaciones

Define los SLI, SLO, y SLA deliberadamente

Empieza desde la perspectiva del usuario. Un indicador de nivel de servicio es una medida cuantitativa del comportamiento de un servicio, como la proporción de solicitudes servidas en menos de 300 milisegundos o la fracción de respuestas exitosas. Elige un pequeño número de SLI que genuinamente reflejen la felicidad del usuario: la disponibilidad, la latencia, la corrección, y la frescura son comunes. Un objetivo de nivel de servicio es un valor o rango objetivo para un SLI, por ejemplo «el 99.9 por ciento de las solicitudes tienen éxito en una ventana móvil de 28 días». Un acuerdo de nivel de servicio es un contrato con consecuencias (reembolsos, penalizaciones) adjuntas a un nivel prometido. Mantén tus SLO más estrictos que tus SLA, así obtienes una advertencia antes de incumplir un compromiso. Publica tus SLO, revísalos trimestralmente, y trátalos como documentos vivos que se ajustan a medida que aprendes.

Adopta los presupuestos de error y hazlos cumplir

El presupuesto de error es 100% menos el SLO. Si tu SLO es 99.9 por ciento, tu presupuesto es 0.1 por ciento de falta de fiabilidad por ventana, aproximadamente 43 minutos por mes. Gástalo en riesgo planificado: lanzamientos agresivos, experimentos, y pruebas de fallo controladas. Cuando el presupuesto está saludable, los equipos pueden enviar rápido. Cuando se agota, la política debería cambiar automáticamente las prioridades hacia el trabajo de fiabilidad y pausar los cambios riesgosos hasta que el sistema se recupere. El poder del presupuesto de error es que lo acuerdas por adelantado, así saca la emoción y la política del momento de una interrupción.

Mide y reduce el esfuerzo repetitivo

El esfuerzo repetitivo es trabajo operacional que es manual, repetitivo, automatizable, táctico, y crece al ritmo del sistema. Rastrea el porcentaje de tiempo de SRE gastado en esfuerzo repetitivo y fija un techo, comúnmente alrededor del 50 por ciento, para que al menos la mitad de tu tiempo de ingeniería vaya a mejoras duraderas. Mantén un atraso de proyectos de reducción de esfuerzo repetitivo, prioriza por frecuencia multiplicada por costo, y celebra eliminar una tarea recurrente tanto como enviar una nueva función. Un mandato de automatización hace esto explícito: cualquier procedimiento manual que realices más de un número fijo de veces se convierte en candidato para la automatización o las herramientas de autoservicio.

Planifica la capacidad y pronostica la demanda

Modela tu carga esperada a partir de tendencias históricas, lanzamientos planificados, y proyecciones de negocio. Combina los pronósticos de crecimiento orgánico con eventos únicos como campañas de marketing, plazos tributarios, o períodos de inscripción de beneficios que importan enormemente en el gobierno. Mantén margen sobre el pico, prueba de carga para comprobar tus suposiciones, y automatiza el escalado donde puedas mientras mantienes un plan de capacidad revisado por humanos para los compromisos grandes. Rastrea los tiempos de espera de aprovisionamiento para que una escasez nunca te agarre desprevenido.

Trata la fiabilidad como una función con costo real

Cada «nueve» adicional de disponibilidad usualmente cuesta mucho más en redundancia, pruebas, y sofisticación operacional que el anterior. Haz explícito el costo de los nueves, para que los dueños de producto elijan el objetivo con los ojos abiertos. Diseña para la degradación elegante, para que los fallos parciales den un servicio reducido en lugar de interrupciones totales. Invierte en redundancia y conmutación por error en proporción al SLO, no uniformemente a través de cada componente.

Elige un modelo organizacional de SRE

No hay una única estructura correcta. Un equipo de SRE centralizado te da consistencia, experiencia profunda, y herramientas compartidas, pero puede convertirse en un cuello de botella o un basurero para los problemas de otras personas. Un modelo incrustado coloca a los SRE dentro de los equipos de producto para una colaboración cercana, pero arriesga la inconsistencia y el aislamiento. Muchas grandes organizaciones usan un híbrido: un equipo central de plataforma y estándares más ingenieros de fiabilidad incrustados, con un modelo de compromiso claro que define cuándo un servicio califica para el soporte de SRE y qué estándar de preparación para producción debe superar primero.

Ventajas y desventajas

Decisión	Ventajas	Desventajas
SLO estrictos (más nueves)	Mayor confianza del usuario, cumple contratos	Costo creciente, entrega de funciones más lenta
SLO laxos (menos nueves)	Envío más rápido, menor costo	Riesgo de fuga de usuarios y penalizaciones de SLA
SRE centralizado	Consistencia, experiencia compartida	Cuellos de botella, distancia del producto
SRE incrustado	Colaboración cercana, contexto	Inconsistencia, difícil de dotar de personal
Inversión pesada en automatización	Escala, reduce el esfuerzo repetitivo	Costo por adelantado, la automatización misma puede fallar

La ingeniería de fiabilidad realmente trata de gastar sabiamente recursos finitos. Perseguir un nueve adicional que los usuarios ni siquiera pueden percibir desperdicia dinero que podría financiar funciones o bajar precios. Ir en la otra dirección y subinvertir en un sistema cuyos fallos causan daño real es negligente. El marco del presupuesto de error existe precisamente para hacer visible y negociable esta contrapartida en lugar de implícita y conflictiva. La contrapartida del modelo organizacional es igual de real: la respuesta correcta depende del tamaño de la empresa, la madurez de ingeniería, y cuán uniformes son tus servicios.

Preguntas para discutir con tu equipo

¿Qué SLI exacto refleja lo que tus usuarios realmente sienten, y puedes mostrar que no es una métrica de vanidad? Elige el indicador equivocado y cada tablero se ve verde mientras los usuarios sufren, que es la trampa del SLI de vanidad contra la que advierte este capítulo. Trae datos reales a la discusión: mide el mismo recorrido de usuario desde una ruta de solicitud real (inicio de sesión al tablero, pago hasta confirmación) en lugar de la CPU del servidor o una comprobación de salud del backend. Para un equipo grande, un mal SLI se propaga: docenas de servicios lo heredan, las alertas se disparan por lo equivocado, y el presupuesto de error deja de significar algo. En entornos empresariales y gubernamentales donde un SLA lleva reembolsos o impacto ciudadano, tu SLI es la evidencia que defiendes ante los auditores, así que debe rastrearse directamente hasta el éxito visible al usuario. Si no puedes trazar una línea desde el número hasta la experiencia de un usuario, reemplaza el número.
¿Qué debe probar un servicio antes de que tu equipo de SRE lo ponga de guardia, y quién dice que no? Sin un estándar de preparación para producción, un equipo central de SRE se convierte en un basurero para cada servicio inestable y se ahoga en la deuda técnica de otras personas. Escribe los criterios de entrada: un SLO con dueño, runbooks funcionando, alertas accionables, margen de capacidad, y una ruta demostrada de despliegue y reversión. Para una organización grande este modelo de compromiso es lo que evita que el equipo de fiabilidad se convierta en un cuello de botella que ralentiza a todos. En entornos regulados la revisión de preparación duplica como un control que puedes mostrar a los organismos de supervisión. Decide quién tiene la autoridad para rechazar la incorporación, porque un estándar que nadie aplica no es un estándar, y la respuesta cambia si la SRE escala o colapsa bajo el dolor heredado.
¿Cuánto tiempo por adelantado aprovisionas para tu pico predecible más grande, y conoces tu tiempo de espera de aprovisionamiento? Asumir que la elasticidad de la nube es instantánea e infinita invita a la escasez durante exactamente los picos que más importan, y esos picos (plazos tributarios, ventanas de inscripción, eventos de venta) son los momentos en que el fallo es más visible y más costoso. Trae los números: la carga pico histórica, el crecimiento pronosticado, el múltiplo al que pruebas la carga, y el tiempo de espera real para adquirir capacidad reservada grande o instancias especializadas. Para los servicios gubernamentales estacionales el pico puede ser varias veces la carga normal y es políticamente imposible de pasar por alto, así que preaprovisionar semanas antes supera a esperar que el autoescalado se mantenga al ritmo. La respuesta debería fijar un calendario concreto: cuándo pruebas la carga, cuándo bloqueas la capacidad, y quién es dueño de la decisión de seguir adelante.
Cuando tu presupuesto de error se agota, ¿qué pasa realmente, y quién tiene la posición para hacerlo cumplir? Un presupuesto de error sobre el que nunca se actúa cuando se agota es solo decoración, y el momento de una interrupción es el peor momento para negociar la política desde cero. La atracción en competencia es real: un lanzamiento comprometido, un plazo de ingresos, o un anuncio público presionarán fuerte contra una congelación de cambios riesgosos. Trae los datos de tasa de consumo, el texto de la política preacordada, y un registro de las últimas veces que se incumplió el presupuesto, para que puedas ver si la congelación realmente se mantuvo. Para un equipo grande el presupuesto solo alinea los incentivos si cada grupo hereda la misma aplicación, así que decide de antemano quién aprueba una excepción y cómo se registra esa excepción. En entornos empresariales y gubernamentales donde un SLA lleva penalizaciones o impacto ciudadano, el rastro de excepción se convierte en un artefacto de auditoría, así que nombra al dueño responsable ahora en lugar de improvisar cuando el presupuesto ya se haya ido.
¿Qué fracción de la semana de tu equipo de SRE es esfuerzo repetitivo, y es eso un número medido o un sentimiento? El esfuerzo repetitivo que nadie cuenta se expande silenciosamente hasta que el equipo pasa todo su tiempo apagando incendios y nada construyendo mejoras duraderas, que es exactamente la trampa de la que existe la SRE para escapar. La tensión es que medir el esfuerzo repetitivo es en sí mismo trabajo, y los ingenieros bajo presión de plazo resisten registrar a dónde van sus horas. Trae una muestra honesta: una o dos semanas de tiempo rastreado contra una definición compartida de esfuerzo repetitivo (manual, repetitivo, automatizable, táctico, y escalando con el sistema), más el atraso de proyectos de automatización clasificados por frecuencia multiplicada por costo. Para una organización grande, un techo del 50 por ciento solo significa algo si se reporta y defiende equipo por equipo, así que acuerda quién revisa el número y qué pasa cuando un equipo lo incumple. En contextos regulados y gubernamentales, limitar el esfuerzo repetitivo libera a los escasos especialistas para el trabajo de control y auditoría que las operaciones manuales desplazan, así que trata la cifra de esfuerzo repetitivo como una señal de capacidad que el liderazgo debería ver.
¿Qué modelo organizacional de SRE operas, y qué evidencia te diría que ha dejado de ajustarse? Un equipo centralizado da consistencia y herramientas compartidas pero puede convertirse en un cuello de botella; un modelo incrustado da contexto pero deriva hacia la inconsistencia; el híbrido en el que se establecen la mayoría de las grandes organizaciones necesita un modelo de compromiso claro o hereda las debilidades de ambos. Trae las señales que revelan la tensión: cuánto esperan los servicios el soporte de SRE, cuánto varía la práctica de fiabilidad entre equipos, y si los ingenieros incrustados se sienten aislados de una comunidad profesional. La respuesta correcta depende del tamaño de la empresa, la madurez de ingeniería, y cuán uniformes son tus servicios, así que revísala a medida que esos cambian en lugar de tratar la primera elección como permanente. Para una empresa u organismo gubernamental con muchos equipos y requisitos estrictos de uniformidad, un grupo central de estándares y plataforma más ingenieros de fiabilidad incrustados usualmente equilibra la consistencia con el contexto local, pero solo si el modelo de compromiso y el estándar de preparación para producción están escritos y alguien es su dueño.

Perspectiva sectorial

Startup. Con un puñado de ingenieros y sin fondos para un equipo de fiabilidad dedicado, elige un único SLO en el recorrido de usuario que más importa y comparte la guardia entre todo el equipo. Apóyate en los servicios gestionados y el monitoreo incorporado de tu proveedor de nube en lugar de construir infraestructura de observabilidad, y escribe postmortems cortos en un documento compartido para que las correcciones se mantengan. La velocidad importa más que el proceso aquí: un SLO laxo que realmente aplicas supera a uno elaborado que nadie vigila.

Pequeña empresa. Sin un especialista para operar la fiabilidad, trátala como una disciplina en la que compras a través de tu plataforma: monitoreo de tiempo de actividad alojado, bases de datos gestionadas, y herramientas de página de estado en lugar de una pila personalizada. Fija uno o dos SLO vinculados a las transacciones que pagan las cuentas, y decide honestamente qué fallos te costarían un cliente. Compra resiliencia donde sea más barato que construirla, y mantén la carga operacional lo bastante ligera para que tus ingenieros existentes puedan cargarla junto al trabajo de funciones.

Empresa. El desafío es la consistencia entre muchos equipos: un vocabulario compartido de SLO, una política común de presupuesto de error, y un estándar de preparación para producción que cada servicio supera antes de que la SRE lo ponga de guardia. Un grupo central de plataforma y estándares más ingenieros de fiabilidad incrustados mantiene la práctica uniforme sin convertirse en un cuello de botella, y la gobernanza necesita que los presupuestos de error se reporten y apliquen de la misma manera en todas partes. Presupuesta explícitamente la infraestructura de observabilidad y la inversión en automatización, y gestiona la fiabilidad como una cartera con métricas que el liderazgo pueda ver.

Gobierno. Los servicios públicos a menudo cargan objetivos de disponibilidad publicados, compromisos estatutarios, y obligaciones de auditoría, así que las decisiones de SLO y presupuesto de error se convierten en registros que defiendes ante los organismos de supervisión. Las reglas de contratación pública pueden restringir qué monitoreo y alojamiento puedes usar, y las expectativas de transparencia te empujan a publicar datos de fiabilidad en un tablero de estado público. Planifica para picos estacionales extremos como plazos tributarios y ventanas de inscripción de beneficios con semanas de anticipación, y mantén una cultura de postmortem sin culpa para que los fallos públicos impulsen la mejora del sistema en lugar de la culpa individual.

Ejemplos

Startup. Una startup de diez personas opera una única aplicación web y comparte la guardia entre tres ingenieros. En lugar de construir un equipo de fiabilidad que no puede costear, elige un SLO significativo: 99.5 por ciento de éxito en el flujo de inicio de sesión al tablero, medido desde solicitudes de usuario reales. Cuando una API de terceros inestable empieza a comerse ese presupuesto, el equipo gasta un viernes añadiendo un reintento y una caché en lugar de enviar la siguiente función, luego escribe un postmortem de dos párrafos en un documento compartido para que la corrección se mantenga.

Empresa. Una empresa global de pagos fija un SLO de disponibilidad de 99.99 por ciento para su API de transacciones, lo cual da un presupuesto de error de aproximadamente cuatro minutos por mes. Un equipo central de plataforma de SRE es dueño de la observabilidad compartida, las herramientas de incidentes, y la política de presupuesto de error, mientras los ingenieros de fiabilidad incrustados trabajan dentro de cada grupo de producto. Cuando una nueva función de detección de fraude quema la mitad del presupuesto mensual en una semana, la política preacordada congela los lanzamientos no críticos hasta que el trabajo de fiabilidad restaure el margen. Los ejecutivos aceptan esto sin debate, porque ratificaron la política de antemano.

Gobierno. Una autoridad tributaria nacional opera un servicio de declaración en línea con picos estacionales extremos alrededor del plazo anual. Su equipo de SRE pronostica la demanda a partir de años anteriores más los cambios de población y política, prueba la carga a varias veces el pico normal, y preaprovisiona capacidad con semanas de anticipación. Los SLO de cara al público para la disponibilidad y la latencia de página se publican en un tablero de estado. Una cultura de postmortem sin culpa (revisar los fallos para mejorar los sistemas en lugar de asignar culpa individual) y un mandato de automatización recortan constantemente las intervenciones manuales que antes dominaban la temporada de declaraciones, liberando al personal para mejorar el sistema en lugar de cuidarlo a través de cada plazo.

Caso de negocio: motivaciones, ROI y TCO

El retorno de la SRE viene de tres fuentes: inactividad evitada, menos trabajo operacional, y entrega segura más rápida. La inactividad para un servicio grande puede costar de miles a millones por hora en ingresos perdidos, penalizaciones, y remediación, así que incluso ganancias modestas de fiabilidad pagan rápidamente un equipo. La reducción del esfuerzo repetitivo convierte el costo manual recurrente en una inversión única de automatización, así que el costo total de propiedad cae a medida que crece la escala en lugar de subir al mismo ritmo. Los presupuestos de error permiten que el negocio envíe más rápido cuando la fiabilidad está saludable, capturando el valor de las funciones que las operaciones excesivamente cautelosas dejarían sobre la mesa.

El costo de adopción es real. La SRE necesita ingenieros calificados, infraestructura de observabilidad, y cambio cultural que compite con los plazos de funciones. Pero el costo de no adoptar es mayor a escala: personal operacional sin límite, interrupciones impredecibles, agotamiento y rotación de personal, y daño reputacional que es difícil de cuantificar pero fácil de sufrir. Para presentar el caso al liderazgo, enmarca la SRE como gestión de riesgo con retornos medibles. Presenta el costo actual de los incidentes y las operaciones manuales, los objetivos de SLO vinculados a los compromisos de negocio, y la reducción proyectada en ambos. Ancla el argumento en el presupuesto de error como una herramienta de gobernanza que da al liderazgo una palanca sobre la contrapartida de fiabilidad frente a velocidad.

Antipatrones y trampas

SRE como operaciones renombradas. Renombrar un equipo de operaciones sin el tiempo de ingeniería, el mandato de automatización, y la autoridad para objetar no cambia nada.
Apuntar al 100 por ciento. Perseguir la fiabilidad perfecta desperdicia dinero y bloquea la entrega por ganancias que los usuarios no pueden percibir.
SLI de vanidad. Medir la CPU del servidor en lugar del éxito visible al usuario da números que se ven bien mientras los usuarios sufren.
Presupuestos de error sin dientes. Un presupuesto sobre el que nunca se actúa cuando se agota es solo decoración.
Esfuerzo repetitivo sin medición. Si no rastreas el esfuerzo repetitivo, consume silenciosamente al equipo hasta que no ocurre trabajo de mejora.
SRE como basurero. Los equipos centralizados que heredan cada servicio inestable sin un estándar de preparación se ahogan en la deuda técnica de otros.
Ignorar los tiempos de espera de capacidad. Asumir que la elasticidad de la nube es instantánea e infinita invita a la escasez durante exactamente los picos que más importan.

Modelo de madurez

Nivel 1, Iniciar. Las operaciones son manuales y reactivas. No hay SLO formales, la fiabilidad es una cuestión de opinión, y los mismos incidentes recurren mientras apagar incendios domina. Cualquier automatización es incidental, y nadie es dueño de la fiabilidad como una preocupación de ingeniería.

Nivel 2, Desarrollar. Algunos servicios tienen SLI y SLO básicos y monitoreo y alertas rudimentarios, pero la práctica varía ampliamente entre equipos. El esfuerzo repetitivo se reconoce pero no se mide, la automatización es ad hoc, y los postmortems ocurren de forma inconsistente. La fiabilidad mejora en los bolsillos donde los individuos la impulsan, no porque la organización lo exija.

Nivel 3, Estandarizar. Los SLI, SLO, y una política de presupuesto de error están documentados y se aplican consistentemente entre equipos. El esfuerzo repetitivo está definido y se rastrea, la planificación de capacidad es rutinaria, existe un modelo de compromiso de SRE con revisiones de preparación para producción, y la automatización es un flujo de trabajo financiado en lugar de un proyecto secundario. La práctica de fiabilidad está escrita y se aplica en toda la organización.

Nivel 4, Gestionar. El programa de fiabilidad se mide y controla con datos contra líneas base. La tasa de consumo del presupuesto de error, el porcentaje de esfuerzo repetitivo, el logro del SLO, el tiempo medio de recuperación, y los tiempos de espera de aprovisionamiento se rastrean como métricas, se revisan en una cadencia fija, y se usan para mantener a los equipos en sus objetivos. Los incumplimientos de presupuesto disparan la congelación acordada, la capacidad se pronostica contra modelos de demanda, y cada decisión de continuar o no descansa en evidencia en lugar de opinión.

Nivel 5, Orquestar. La ingeniería de fiabilidad se integra en toda la organización y se mejora continuamente. La política de presupuesto de error está automatizada y se respeta en todas partes, la mayoría de las operaciones son de autoservicio, la capacidad se aprovisiona proactivamente, y los datos de fiabilidad impulsan contrapartidas adaptativas entre la velocidad y la estabilidad. La organización rutinariamente reajusta el alcance de los SLO, retira el esfuerzo repetitivo, y reequilibra la inversión en fiabilidad a medida que cambian el negocio y el panorama de riesgo.

Ideas para el debate

¿Cómo debería una organización fijar sus primeros SLO cuando no tiene datos históricos de fiabilidad en los cuales anclarlos?
Cuando el presupuesto de error está agotado pero un lanzamiento importante está comprometido, ¿quién tiene autoridad para anular la congelación, y cómo se registra esa decisión?
¿Es correcto un modelo de SRE centralizado, incrustado, o híbrido para tu organización, y qué dispararía un cambio?
¿Cómo valoras un nueve adicional de disponibilidad contra las funciones que la misma inversión podría financiar?
¿Qué cuenta como esfuerzo repetitivo en tu contexto, y dónde está la línea entre el juicio manual valioso y la repetición eliminable?
¿Cómo deberían diferir los objetivos de fiabilidad entre los servicios gubernamentales de cara al ciudadano y las herramientas empresariales internas?

Puntos clave

La SRE aplica la ingeniería de software a las operaciones, tratando la fiabilidad como una función medible y financiable.
Los SLI, SLO, y SLA convierten la fiabilidad de opinión a números acordados; mantén los SLO más estrictos que los SLA.
El presupuesto de error alinea a desarrolladores y operadores haciendo explícita y prenegociada la contrapartida de fiabilidad frente a velocidad.
Mide y limita el esfuerzo repetitivo, y trata la automatización como ingeniería de primera clase para que las operaciones escalen sublinealmente.
Planifica la capacidad a partir de pronósticos de demanda y respeta los tiempos de espera de aprovisionamiento, especialmente para los picos estacionales.
Elige un modelo organizacional de SRE deliberadamente y define un estándar claro de compromiso y preparación para producción.

Referencias y lecturas adicionales

Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy, Site Reliability Engineering: How Google Runs Production Systems
Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara, Stephen Thorne, The Site Reliability Workbook: Practical Ways to Implement SRE
David N. Blank-Edelman (editor), Seeking SRE: Conversations About Running Production Systems at Scale
Thomas A. Limoncelli, Strata R. Chalup, Christina J. Hogan, The Practice of Cloud System Administration
Nicole Forsgren, Jez Humble, Gene Kim, Accelerate: The Science of Lean Software and DevOps