La ingeniería de fiabilidad del sitio (SRE) emplea la ingeniería de software para automatizar tareas de operaciones informáticas (por ejemplo, gestión de sistemas de producción, gestión de cambios, respuesta a incidentes, incluso respuesta a emergencias) que, de otro modo, realizarían manualmente los administradores de sistemas (sysadmins). 

El principio detrás de SRE es que el uso de código de software para automatizar la supervisión de grandes sistemas de software es una estrategia más escalable y sostenible que la intervención manual, especialmente a medida que esos sistemas se extienden o migran a la nube.

SRE también puede reducir o eliminar gran parte de la fricción natural entre los equipos de desarrollo que desean lanzar continuamente software nuevo o actualizado a producción, y los equipos de operaciones que no desean lanzar ningún tipo de actualización o software nuevo sin estar absolutamente seguros de que no causará interrupciones u otros problemas operativos. Como resultado, aunque no es estrictamente necesario para DevOps, SRE se alinea estrechamente con los principios de DevOps y puede desempeñar un papel importante en el éxito de DevOps.

El concepto de SRE se atribuye a Ben Treynor Sloss, vicepresidente de ingeniería de Google, quien escribió la famosa frase: "SRE es lo que sucede cuando le pides a un ingeniero de software que diseñe un equipo de operaciones".

Un ingeniero de confiabilidad del sitio es un desarrollador de software con experiencia en operaciones de TI, alguien que sabe cómo codificar y que entiende cómo "mantener las luces encendidas" en un entorno de TI a gran escala. 

Los ingenieros de confiabilidad del sitio dedican la mitad de su tiempo a realizar operaciones manuales de TI y tareas de administración de sistemas: analizar registros, ajustar el rendimiento, aplicar parches, probar entornos de producción, responder a incidentes y realizar postmortems. El resto de su tiempo, desarrollan código que automatiza esas tareas. Su objetivo es pasar menos tiempo en el primero y más tiempo en el segundo.

A un nivel superior, el equipo de SRE sirve como puente entre los equipos de desarrollo y los equipos de operaciones, lo que permite al equipo de desarrollo llevar nuevo software o nuevas características a producción lo más rápido posible. Lo hacen al tiempo que garantizan un nivel aceptable acordado de rendimiento de las operaciones de TI y riesgo de error en línea con los acuerdos de nivel de servicio (SLA) que la organización tiene con sus clientes. Con base en su experiencia y una gran cantidad de datos de operaciones, el equipo de SRE ayuda a los equipos de desarrollo y operaciones a establecerse

• Indicadores de nivel de servicio (SLI): mediciones del nivel de servicio proporcionado por los sistemas, como la disponibilidad (tiempo de actividad) o la latencia.
  
  
• Objetivos de nivel de servicio (SLO): medios acordados para medir los indicadores de nivel de servicio.
  
  
• Presupuesto de errores: la cantidad máxima de tiempo que un sistema puede fallar o tener un rendimiento inferior sin violar los términos contractuales del SLA. Más que una métrica, el presupuesto de errores es la herramienta que emplea un equipo de ingeniería de confiabilidad del sitio para conciliar automáticamente el ritmo de innovación de una compañía con la confiabilidad de su servicio. 

El presupuesto de errores es la herramienta que emplea un equipo de SRE para conciliar automáticamente la confiabilidad del servicio de una compañía con su ritmo de desarrollo e innovación de software. 

Supongamos que el SLA de una compañía promete un tiempo de actividad del 99.99 % (un objetivo de disponibilidad común) por año. Eso significa que el presupuesto mensual de errores (la cantidad total de tiempo de inactividad permitido sin consecuencias contractuales para un mes determinado) es de aproximadamente 4 minutos y 23 segundos.

Ahora supongamos que el equipo de desarrollo quiere implementar algunas características nuevas o mejoras en el sistema. Si el sistema funciona por debajo del presupuesto para errores, el equipo puede ofrecer las nuevas funciones. Si no es así, el equipo no puede entregar las nuevas funciones hasta que trabaje con el equipo de operaciones para reducir estos errores o interrupciones a un nivel aceptable.

De esta manera, el presupuesto de errores ayuda a los equipos de desarrollo y de operaciones a

• Mejorar la estabilidad y el rendimiento de los servicios.
  
  
• Tome decisiones basadas en datos sobre la implementación de nuevas funciones o aplicaciones.
  
  
• Maximice la innovación asumiendo riesgos dentro de límites aceptables.

DevOps es una forma moderna de entregar aplicaciones de mayor calidad con mayor rapidez, mediante la automatización del ciclo de vida de entrega de software y al dar a los equipos de desarrollo y operaciones una mayor responsabilidad compartida y más información sobre el trabajo de los demás. 

Al igual que SRE, DevOps hace que una compañía sea más ágil al equilibrar la necesidad de ofrecer más aplicaciones y cambios más rápidamente con la necesidad de evitar "romper" el entorno de producción. Y al igual que SRE, DevOps pretende lograr este equilibrio estableciendo un riesgo de errores aceptable. De hecho, SRE y DevOps parecen tan similares que algunos expertos dicen que son la misma cosa, pero la mayoría ve las prácticas de SRE como excelentes formas de aplicar los principios de DevOps. Por ejemplo:

Principios de DevOps: reducir el silo organizacional, aprovechar las herramientas y la automatización.

Práctica de SRE: emplee las mismas herramientas para automatizar y mejorar las operaciones que emplean los desarrolladores para desarrollar y mejorar el software.

Principios de DevOps: aceptar el fracaso como algo normal e implementar cambios graduales.

Práctica de SRE: emplee presupuestos de error para implementar continuamente nuevas características y funcionalidades dentro de niveles aceptables.

Principio de DevOps: medirlo todo.

Práctica de SRE: Basar las decisiones de lanzamiento de nuevo software en métricas de SLA.

Además de respaldar el éxito de DevOps, la ingeniería de confiabilidad del sitio puede ayudar a una compañía

• Obtenga una mayor visibilidad del estado del servicio mediante el seguimiento de métricas, registros y rastreos en todos los servicios de la organización y proporcionando contexto para identificar las causas principales en caso de un incidente.
  
  
• Cuantifique el costo del tiempo de inactividad ayudando a los equipos de desarrollo y operaciones a comprender el costo de las violaciones de SLA y ayudando a la gerencia a cuantificar el impacto de la confiabilidad del sistema en la producción, las ventas, el marketing, el servicio al cliente y otras funciones comerciales.
  
  
• Optimice la respuesta a incidentes creando procesos eficientes de guardia y optimizando los flujos de trabajo de alerta.
  
  
• Construya un moderno centro de operaciones de red combinando un profundo conocimiento de las operaciones de TI con el aprendizaje automático y la automatización, para enviar alertas directamente a la persona responsable de abordar el problema.

La migración de TI tradicional y centros de datos locales a entornos de nube híbrida es una de las principales razones por las que la compañía promedio genera dos o tres veces más datos de operaciones cada año. Cada vez más, se considera que SRE es fundamental para aprovechar estos datos para automatizar la administración de sistemas, las operaciones y la respuesta a incidentes, y para mejorar la confiabilidad de la empresa, incluso cuando el entorno de TI se vuelve más complejo.

El enfoque de desarrollo nativo de la nube consiste específicamente en crear aplicaciones como microservicios y desplegarlas en contenedores,lo cual puede simplificar el desarrollo, el despliegue y la escalabilidad de las aplicaciones. Sin embargo, el desarrollo nativo de la nube también crea un entorno cada vez más distribuido que complica la administración, las operaciones y la gestión. Un equipo de SRE puede respaldar el rápido ritmo de innovación habilitado por un enfoque nativo de la nube y garantizar o mejorar la confiabilidad del sistema, sin poner más presión operativa en los equipos de DevOps.