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

El principio en el que se basa la 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 amplían o migran a la nube.

La SRE también puede reducir o eliminar gran parte de la fricción natural entre los equipos de desarrollo, que quieren lanzar continuamente software nuevo o actualizado a producción, y los equipos de operaciones, que no quieren 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, la 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, autor de la célebre frase: "la SRE es lo que ocurre cuando le pides a un ingeniero de software que diseñe un equipo de operaciones".

Un ingeniero de fiabilidad del sitio es un desarrollador de software con experiencia en operaciones informáticas, alguien que sabe programar y que entiende cómo garantizar el funcionamiento mínimo en un entorno informático a gran escala. 

Los ingenieros de fiabilidad del sitio pasan la mitad del tiempo realizando operaciones manuales de TI y tareas de administración del sistema: analizando registros, ajustando el rendimiento, aplicando parches, probando entornos de producción, respondiendo a incidentes, realizando análisis post mortem... El resto del tiempo, desarrollan código que automatiza esas tareas. Su objetivo es dedicar menos tiempo a las primeras y más a las segundas.

A un nivel superior, el equipo de SRE sirve de puente entre los equipos de desarrollo y los de operaciones, permitiendo al equipo de desarrollo poner en producción nuevo software o nuevas características lo antes posible. Lo hacen a la vez que garantizan un nivel aceptable acordado de rendimiento de las operaciones de TI y de riesgo de error en línea con los acuerdos de nivel de servicio (SLA) que la organización tiene con sus clientes. Basándose en su experiencia y en una gran cantidad de datos sobre operaciones, el equipo de SRE ayuda a los equipos de desarrollo y operaciones a establecer

• Indicadores del nivel de servicio (SLI): mediciones del nivel de servicio proporcionado por los sistemas, métricas como la disponibilidad (tiempo de actividad) o la latencia.
  
  
• Objetivos de nivel de servicio: medios acordados para medir los indicadores de nivel de servicio.
  
  
• Presupuestos de error: la cantidad máxima de tiempo que un sistema puede fallar o rendir por debajo de lo esperado sin violar los términos contractuales del SLA. Más que una métrica, el presupuesto de errores es la herramienta que utiliza un equipo de ingeniería de fiabilidad del sitio para conciliar automáticamente el ritmo de innovación de una empresa con la fiabilidad de su servicio. 

El presupuesto de errores es la herramienta que utiliza un equipo de SRE para conciliar automáticamente la fiabilidad del servicio de una empresa con su ritmo de desarrollo e innovación de software. 

Supongamos que el SLA de una empresa promete un tiempo de actividad del 99,99 % (un objetivo de disponibilidad habitual) al 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 unos 4 minutos y 23 segundos.

Supongamos que el equipo de desarrollo quiere introducir nuevas características o mejoras en el sistema. Si el sistema funciona por debajo del presupuesto de errores, el equipo puede entregar las nuevas características. Si no, el equipo no puede entregar las nuevas características hasta que trabaje con el equipo de operaciones para reducir estos errores o interrupciones a un nivel aceptable.

De este modo, los presupuestos de errores ayudan a los equipos de desarrollo y de operaciones a

• Mejorar la estabilidad y el rendimiento de los servicios.
  
  
• Tomar decisiones basadas en datos sobre la implementación de nuevas características o aplicaciones.
  
  
• Maximizar la innovación asumiendo riesgos dentro de unos límites aceptables.

DevOps es una forma moderna de ofrecer aplicaciones de mayor calidad con mayor rapidez, automatizando el ciclo de vida de la entrega de software y dando a los equipos de desarrollo y operaciones más responsabilidad compartida y más participación en el trabajo de los demás. 

Al igual que la SRE, DevOps hace que una empresa 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 la SRE, DevOps pretende lograr este equilibrio estableciendo un riesgo aceptable de errores. De hecho, la SRE y DevOps parecen tan similares que algunos expertos dicen que son lo mismo, 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 los silos organizativos, aprovechar las herramientas y la automatización.

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

Principios de DevOps: aceptar el fracaso como algo normal, aplicar cambios graduales.

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

Principio de DevOps: medirlo todo.

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

Además de respaldar el éxito de DevOps, la ingeniería de fiabilidad del sitio puede ayudar a una empresa a

• Obtener una mayor visibilidad del estado de salud de los servicios mediante el seguimiento de métricas, registros y trazas en todos los servicios de la organización y proporcionando contexto para identificar las causas raíz en caso de incidente.
  
  
• Cuantificar el costo del tiempo de inactividad ayudando a los equipos de desarrollo y operaciones a comprender el coste de las infracciones de los SLA, y ayudando a la dirección a cuantificar el impacto de la fiabilidad del sistema en la producción, las ventas, el marketing, el servicio de atención al cliente y otras funciones empresariales.
  
  
• Optimizar la respuesta ante incidentes mediante la creación de procesos de guardia eficientes y la racionalización de los flujos de trabajo de alerta.
  
  
• Construir un centro de operaciones de red moderno combinando el conocimiento profundo de las operaciones de TI con el machine learning y la automatización, para enviar alertas directamente a la persona encargada de abordar el problema.

La migración de la TI tradicional y los centros de datos locales a entornos de nube híbrida es una de las principales razones por las que la empresa media genera de dos a tres veces más datos de operaciones cada año. La SRE se considera cada vez más crucial para aprovechar estos datos con el fin de automatizar la administración de sistemas, las operaciones y la respuesta a incidentes, así como para mejorar la fiabilidad de la empresa incluso a medida que el entorno de TI se vuelve más complejo.

Un enfoque de desarrollo nativo de la nube implementar (específicamente, la creación de aplicaciones como microservicios y su implementación en contenedores) puede simplificar el desarrollo, la implementación y la escalabilidad de las aplicaciones. No obstante, 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 que permite un enfoque nativo de la nube y garantizar o mejorar la fiabilidad del sistema, sin aumentar la presión de las operaciones sobre los equipos de DevOps.