La ingeniería de fiabilidad de sitios (SRE) utiliza ingeniería de software para automatizar las tareas de las operaciones de TI, por ejemplo, la gestión de sistemas de producción, la gestión de cambios, la respuesta a incidencias e incluso la respuesta a emergencias, que de otro modo debían realizar manualmente los administradores de sistemas (sysadmins). 

La SRE se basa en el principio de que usar 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, sobre todo cuando esos sistemas se amplían o se 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 publicar continuamente software nuevo o actualizado en producción, y los equipos de operaciones, que no quieren publicar ningún tipo de actualización o software nuevo sin estar absolutamente seguros de que no provoquen interrupciones u otros problemas operativos. En consecuencia, aunque no es estrictamente necesaria para DevOps, la SRE se ajusta estrechamente a sus principios, y puede ser una pieza importante del éxito en ese campo.

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

Un ingeniero de fiabilidad de sitios 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 fiabilidad de sitios dedican no más de la mitad de su tiempo a realizar operaciones de TI manuales y tareas de administración de sistema (analizar registros, ajustar el rendimiento, aplicar parches, probar entornos de producción, responder a incidentes, realizar pruebas postmortem), y el resto del 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.

A 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 características a 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 que concuerde con los acuerdos de nivel de servicio (SLA) que la organización tenga establecidos con sus clientes. Gracias a su experiencia y a la gran cantidad de datos de operaciones de los que dispone, el equipo de SRE ayuda a los equipos de desarrollo y operaciones a establecer:

• Indicadores de nivel de servicio (SLI): medidas del nivel de servicio que proporcionan los sistemas; métricas 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.
  
  
• Presupuestos de error: la cantidad máximo de tiempo durante la que un sistema puede fallar o rendir menos de lo esperado sin violar los términos contractuales del SLA. Más que una métrica, el presupuesto de error es la herramienta que utiliza un equipo de ingeniería de fiabilidad de sitios para conciliar automáticamente el ritmo de innovación de una empresa con su fiabilidad de servicio. 

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

Supongamos que el SLA de una empresa promete un 99,99 % de tiempo de actividad (un objetivo de disponibilidad habitual) al año. Eso significa que el presupuesto de error mensual —la cantidad total de tiempo de inactividad permitido durante un mes determinado sin que se deriven consecuencias contractuales— es de aproximadamente 4 minutos y 23 segundos.

Imaginemos, ahora, que el equipo de desarrollo quiere implantar algunas características o mejoras nuevas en el sistema. Si el sistema está funcionando por debajo del presupuesto de error, el equipo puede suministrar las nuevas funciones. De lo contrario, el equipo no puede suministrar las nuevas funciones hasta que consiga, junto con el equipo de operaciones, rebajar estos errores o interrupciones hasta un nivel aceptable.

Así, los presupuestos de error ayudan a los equipos de desarrollo y a los equipos de operaciones a:

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

DevOps es una forma moderna de entregar aplicaciones de más calidad con una mayor rapidez; automatiza el ciclo de vida de entrega de software, otorga a los equipos de desarrollo y de operaciones una mayor responsabilidad compartida y les permite participar más entre ellos en sus respectivos trabajos. 

Al igual que la SRE, DevOps aumenta la agilidad de negocio equilibrando la necesidad de entregar más aplicaciones y cambios con más rapidez con la necesidad de evitar "romper" el entorno de producción. Y al igual que la SRE, de nuevo, DevOps pretende lograr este equilibrio estableciendo un riesgo de errores aceptable. De hecho, SRE y DevOps parecen tan similares que algunos expertos afirman que son lo mismo, pero la mayoría considera que las prácticas de SRE son una forma excelente de implementar los principios de DevOps. Por ejemplo:

Principios de DevOps: reducir los silos organizativos, aprovechar los conjuntos de herramientas y la automatización

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

Principios de DevOps: aceptar el error como algo normal, implementar cambios graduales

Práctica de SRE: usar presupuestos de error para desplegar continuamente nuevas características y funcionalidad dentro de niveles aceptables

Principio de DevOps: medirlo todo

Práctica de SRE: basar las decisiones de publicación de nuevo software en las métricas de SLA

Para obtener más información sobre DevOps, vea este vídeo (5:58):

Además de facilitar el éxito de DevOps, la ingeniería de fiabilidad de sitios puede ayudar a una compañía a:

• Obtener más visibilidad sobre el estado del servicio mediante el seguimiento de métricas, registros y rastreos a través de todos los servicios de la organización, y ofreciendo contexto para identificar las causas raíz en caso de incidencia.
  
  
• Cuantificar el coste del tiempo de inactividad ayudando a los equipos de desarrollo y operaciones a comprender el coste de las violaciones de los SLA, y al nivel directivo a cuantificar la repercusión de la fiabilidad del sistema en las funciones de producción, ventas, marketing y servicio al cliente, entre otras.
  
  
• 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 combinando un profundo conocimiento de las operaciones de TI con machine learning y automatización para enviar alertas directamente a la persona responsable de resolver el problema.

La migración de los centros de datos locales y de TI tradicionales a entornos de nube híbrida es una de las principales razones por las que las empresas, en general, generan de dos a tres veces más datos de operaciones cada año. La SRE se considera un elemento cada vez más indispensable para aprovechar estos datos para automatizar la administración, las operaciones y la respuesta a incidentes de los sistemas, y para mejorar la fiabilidad empresarial incluso cuando aumenta la complejidad del entorno de TI.

Los enfoques de desarrollo nativo en la nube —específicamente, la creación de aplicaciones como microservicios y su despliegue en contenedores— pueden simplificar el desarrollo, el despliegue y la escalabilidad de las aplicaciones. Sin embargo, el desarrollo nativo en 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 responder al rápido ritmo de innovación que habilitan los enfoques nativos en la nube y garantizar o mejorar la fiabilidad del sistema, sin añadir más presión de operaciones en los equipos de DevOps.