La ingeniería de confiabilidad del sitio (SRE) utiliza técnicas de ingeniería de software para automatizar las tareas de operaciones de TI, 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 otra manera debían realizar 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 sistemas de software grande es una estrategia más escalable y sustentable que la intervención manual, especialmente cuando 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 en 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án 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 le atribuye a Ben Treynor Sloss, vicepresidente de ingeniería de Google, en su 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 también entiende cómo mantener en funcionamiento todo un entorno de TI a gran escala. 

Los ingenieros de confiabilidad del sitio dedican no más de la mitad de su tiempo a realizar operaciones de TI manuales y tareas de administración del sistema (analizar registros, ajustar el rendimiento, aplicar parches, probar entornos de producción, responder a incidentes, realizar autopsias) y dedican el resto de su tiempo a desarrollar código que automatiza esas tareas Su objetivo es acabar dedicando mucho menos tiempo a lo primero y mucho más a lo segundo.

En un nivel superior, el equipo de SRE sirve como puente entre los equipos de desarrollo y los equipos de operaciones, lo que permite que el equipo de desarrollo lleve nuevo software o nuevas funciones a la producción lo más rápido posible, al tiempo que garantiza un nivel aceptable acordado de rendimiento de operaciones de TI y un riesgo de errores en línea con los acuerdos de nivel de servicio (SLA) que la organización tenga establecidos con sus clientes. Basado en su experiencia y una gran cantidad de datos de operaciones, el equipo de SRE ayuda a los equipos de desarrollo y operaciones a establecer:

• Indicadores de nivel de servicio (SLI): mediciones del nivel de servicio proporcionado por los sistemas, métricas como disponibilidad (tiempo de actividad) o latencia
  
  
• Objetivos de nivel de servicio (SLO): 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 tener un rendimiento inferior sin violar los términos contractuales del SLA. Más que una métrica, el presupuesto de error es la herramienta de confiabilidad del sitio que el equipo de ingeniería utiliza para reconciliar automáticamente el ritmo de innovación de una empresa con la confiabilidad de su servicio. 

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

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

Ahora digamos que el equipo de desarrollo quiere implementar algunas funciones nuevas o mejoras en el sistema. Si el sistema se ejecuta por debajo del presupuesto de error, el equipo puede ofrecer las nuevas funciones. De lo contrario, el equipo no puede ofrecer las nuevas funciones hasta que trabajen con el equipo de operaciones para reducir estos errores o interrupciones a un nivel aceptable.

De esta manera, los presupuestos de error ayudan a los equipos de desarrollo y operaciones a:

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

DevOps es una forma moderna de entregar aplicaciones de mayor calidad más rápidamente, al automatizar el ciclo de vida de la entrega de software y al brindar a los equipos de desarrollo y operaciones una mayor 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 entregar 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 tiene como objetivo lograr este equilibrio estableciendo un riesgo aceptable de errores. De hecho, SRE y DevOps parecen tan similares que algunos expertos dicen que son lo mismo, pero la mayoría considera que las prácticas de SRE con una forma excelente de implementar los principios de DevOps. Por ejemplo:

Principios de DevOps: reducir los silos organizacionales, aprovechar las herramientas y la automatización

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

Principios de DevOps: aceptar las fallas como algo normal, implementar cambios graduales

Práctica de SRE: utilizar 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

Para conocer más acerca de DevOps, vea este video (5:58):

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

• Obtener 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 brindar contexto para identificar las causas raíz en caso de un incidente.
  
  
• Cuantificar el costo del tiempo de inactividad al ayudar a los equipos de desarrollo y operaciones a comprender el costo de las brechas de los SLA y ayudar 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.
  
  
• Optimizar la respuesta a incidentes mediante la creación de procesos eficientes de emergencia y la optimización de los flujos de trabajo de alerta.
  
  
• Crear un centro de operaciones de red moderno al combinar un profundo conocimiento de las operaciones de TI con machine learning y automatización para enviar alertas directamente a la persona responsable por solucionar el problema.

La migración desde centros de datos locales y de TI tradicionales a entornos de nube híbrida es una de las principales razones por las que la empresa 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 empresarial incluso cuando el entorno de TI se vuelve más complejo.

Un enfoque de desarrollo nativo de la nube (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. Pero 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 ejercer presión operativa adicional sobre los equipos de DevOps.