La SRE en contexto

Antes de explorar algunas de las prácticas asociadas con la SRE, sería conveniente poner en contexto algunas de las ideas que acabamos de aprender en la unidad anterior. En esta breve unidad aprenderemos algo de historia de la SRE y cómo se relaciona con otros procedimientos de operaciones que tal vez conozca. Este conocimiento nos equipará para que todo salga mejor más adelante, ya que estas prácticas tendrán más sentido en contexto. Además, cuando sus amigos le pregunten "¿en qué se diferencia la SRE de...?", tendrá una respuesta preparada.

Historial

Una historia muy comprimida de la SRE comienza con sus orígenes en Google en el año 2003. Ben Treynor, ahora Treynor Sloss, tomó el liderazgo del "equipo de producción" de Google (que entonces contaba con solo siete ingenieros de software). Treynor creó la idea y acuño la célebre descripción "es lo que sucede cuando se pide a un ingeniero de software que diseñe una función de operaciones". Es útil entender esta historia porque permite explicar por qué la SRE puede parecer "ingeniería de software" a las personas implicadas en las operaciones que la ven por primera vez. Ha adoptado valores y herramientas de ese campo, como la importancia de la codificación y de los sistemas de control de código fuente como una herramienta esencial. La implementación inicial y actual de la SRE de Google está bien documentada en los dos libros publicados por O'Reilly (consulte la unidad Introducción).

A medida que los empleados de Google se iban de la empresa (y las personas de la empresa hablaban más de sus prácticas en público), la SRE empezó a extenderse a más organizaciones del sector. A medida que la SRE se expandía a organizaciones nuevas, esas organizaciones adoptaron y adaptaron los principios y prácticas de la SRE a su cultura local. Este proceso de expansión ha supuesto numerosas implementaciones distintas de la SRE en el campo.

DevOps y la SRE

La industria en general se enfrentó a los mismos desafíos relativos al escalado, la velocidad de desarrollo frente a la estabilidad operativa y otros problemas de entrega de software que generaron el movimiento de la ingeniería de confiabilidad de sitios. Los esfuerzos en paralelo para abordarlos fuera de Google (y en algunas empresas más grandes de ese momento) dieron lugar a DevOps.

Para obtener una gran cantidad de información buena sobre DevOps, consulte el Centro de recursos de DevOps.

Las diferencias entre la SRE y DevOps siguen siendo tema de discusión en este campo. Hay algunas diferencias ampliamente aceptadas, como las siguientes:

• SRE es una materia de ingeniería centrada en la confiabilidad. DevOps es un movimiento cultural que surgió de la necesidad de dividir los silos que solían asociarse a las distintas organizaciones de desarrollo y operaciones.
• La SRE puede ser el nombre de un rol como en "Soy ingeniero de confiabilidad de sitios (SRE)", pero DevOps no. Nadie, en sentido estricto, se gana la vida con DevOps.
• La SRE tiende a ser más normativa, mientras que DevOps no lo es de forma intencionada. La adopción casi universal de la integración o entrega continuas y los principios de Agile se acercan más en este sentido.

Ambas prácticas de operaciones, DevOps y SRE, comparten un amor mutuo por la supervisión/observación y por la automatización (quizás por razones distintas). Esta confluencia es uno de los motivos por los que a veces puede ser más fácil importar prácticas y principios de la SRE en una organización que ya cuenta con una práctica de DevOps. Ese proceso debe llevarse a cabo con cuidado e intención. También puede y debe implementarse incrementalmente. Uno no tiene que hacer un cambio repentino.

Conclusión

En esta breve unidad hemos querido contextualizar la SRE y DevOps. SRE y DevOps se conocen mejor como escuelas adyacentes de pensamiento en los procedimientos de operaciones.

Ahora que se ha analizado brevemente parte del contexto de la SRE, pasaremos directamente a algunos de sus principios básicos.