SRE vs. DevOps ¿Realmente son distintos?

Apenas unos días antes de que muriera a principios de la década de 1990, un hombre sabio nos enseñó que "el espectáculo debe continuar". Las palabras de despedida de Freddie Mercury siempre han servido de guía para muchos equipos de operaciones, si no para todos. Desde su punto de vista, el entorno de producción debería exponerse a un riesgo mínimo, incluso a expensas de las nuevas características y la resolución de problemas.

Hace unos 10 años, Google decidió cambiar su enfoque de gestión de la producción. Le tomó a la compañía solo unos pocos años darse cuenta de que mientras Investigación y Desarrollo se enfocaba en crear nuevas características y empujarlas a la producción, el grupo de Operaciones intentaba mantener la producción lo más estable posible: los dos equipos tiraban en direcciones opuestas. Esta tensión surgió debido a los diferentes antecedentes, conjuntos de habilidades, incentivos y métricas de los grupos por los cuales fueron medidos.

Tratando de cerrar esta brecha entre los dos grupos, uno de los líderes de operaciones de Google, Ben Treynor, pensó en una solución innovadora. En lugar de tener un equipo Oerativo creado únicamente por los administradores del sistema, los ingenieros de software -con experiencia y mentalidad en Investigación y Desarrollo- podrían enriquecer la forma en que el equipo trabajó con el grupo de Desarrollo, cambiar sus objetivos y ayudar a automatizar las soluciones.

Ingeniería de Confiabilidad del Sitio, o SRE

Y así, se creó el puesto de Ingeniería de Confiabilidad del Sitio (Site Reliability Engineering). Según Google, los ingenieros de SRE son responsables de la estabilidad del entorno de producción, pero al mismo tiempo están comprometidos con las nuevas funciones y la mejora operativa.

Google decidió que sus equipos de SRE deberían estar compuestos por un 50 por ciento de ingenieros de software y un 50 por ciento de administradores de sistemas.

Los ingenieros se vieron obligados a utilizar el software como una forma de resolver problemas y perfeccionar lo que históricamente se había resuelto a mano. Se integraron fácilmente con el equipo de desarrollo y alentaron las mejoras de la calidad del código y las pruebas de automatización.

Al comprender el valor de SRE, varias organizaciones de diversos tamaños decidieron adoptar sus principios. Algunos, como Dropbox, Netflix y Github, son conocidos por estar a la vanguardia del liderazgo tecnológico.

Espera, ¿Qué eso no es DevOps?

DevOps es un movimiento más reciente, diseñado para ayudar al departamento de Tecnologías de la Información de las organizaciones, a moverse de forma ágil y eficiente. Construye una relación de trabajo saludable entre el personal de Operaciones y el equipo de Desarrollo, lo que permite que cada uno vea cómo su trabajo influye y afecta al otro. Al combinar conocimiento y esfuerzo, DevOps debe producir un producto más robusto, confiable y ágil.

Tanto SRE como DevOps son metodologías que abordan las necesidades de las organizaciones para la gestión de operaciones de producción. Pero las diferencias entre las dos doctrinas son bastante significativas: mientras DevOps plantea problemas y los envía a Desarrollo para que los resuelva, el enfoque de SRE es encontrar problemas y resolver algunos de ellos por sí mismos.

Si bien los equipos de DevOps generalmente elegirían el enfoque más conservador, dejando intacto el entorno de producción a menos que sea absolutamente necesario, los SRE tienen más confianza en su capacidad para mantener un entorno de producción estable, presionar por cambios rápidos y actualizaciones de software.

Al igual que el equipo de DevOps, los SRE también prosperan en un entorno de producción estable, pero uno de los objetivos del equipo de SRE es mejorar el rendimiento y la eficiencia operativa.

Google intentó algunos enfoques para implementar el proceso de SRE antes de encontrar el que más le convenía. Uno de estos enfoques intentó vincular el número de lanzamientos permitidos, con la estabilidad del producto. El principio que subyace en este proceso es que las nuevas versiones se "iluminan en verde" según el rendimiento actual del producto.

Para cada servicio, el equipo de SRE establece un Acuerdo de Nivel de Servicio (SLA por sus siglas en inglés) que define qué tan confiable debe ser el sistema para los usuarios finales. Si el equipo acepta un SLA del 99.9 por ciento, eso les da un presupuesto de error del 0.1 por ciento.

Un presupuesto de error es exactamente lo que sugiere su nombre: el límite máximo permitido para errores e interrupciones. Y es aquí donde está lo interesante: el equipo de desarrollo puede "gastar" este presupuesto de error de la manera que quiera. Si el producto se está ejecutando sin problemas, con pocos o ningún error, pueden ejecutar lo que quieran, cuando lo deseen. Por el contrario, si han cumplido o excedido el presupuesto de error, y están funcionando en el SLA definido o por debajo, todas las nuevas versiones se congelan hasta que reduzcan la cantidad de errores a un nivel que permita que el lanzamiento continúe. Este proceso asegura que tanto los SRE como los desarrolladores tengan un fuerte incentivo para minimizar el número de errores en la producción.

Otro enfoque interesante recomendado por Treynor, que está más relacionado con el profesionalismo y la eficiencia de SRE, está permitiendo que los SRE se muevan entre proyectos. Además, sugiere permitir que los ingenieros de SRE se muevan hacia el desarrollo, e incluso al revés.

Como el trabajo realizado por ambos equipos es similar, estas transiciones ayudan al equipo de Operaciones a obtener un mejor y más profundo conocimiento del producto y el código, llevando a los equipos de Desarrollo al espacio de producción para ayudarlos a comprender sus desafíos. Esto promueve fuertemente una atmósfera de equipo, en lugar de una en la que un individuo siente que "estoy en el equipo de SRE para este producto".

Como parte de este enfoque, Treynor hizo que los equipos de Desarrollo manejaran el 5 por ciento de la carga de trabajo de las operaciones. Esto de acuerdo con muchas organizaciones, se suma a la motivación y efectividad del equipo de SRE.

Acertijos en la oscuridad

Bueno, SRE parece perfecto. Como ya se dijo, varias organizaciones a gran escala han decidido trasladar algunas de sus operaciones de producción de antiguas áreas cien por ciento Operativas a SRE. Sin embargo, todavía hay algunas preguntas que deben hacerse:

¿El puesto de Administrador de Sistemas (producción/operaciones) ya no es relevante para los Administradores de Sistemas?

Históricamente casi todos los administradores de sistemas han asumido sus roles, a través de soporte técnico y trabajo similar, o incluso simplemente ejecutando Linux en sus escritorios y luego haciendo la transición al trabajo del servidor. Debería quedar bastante claro que el mismo camino no está disponible en SRE. Para conservar sus posiciones, los Administradores de Sistemas ahora deberían estar más orientado al código, tener un mejor conocimiento tecnológico y ser receptivos a los nuevos métodos para realizar el trabajo que ya realizan.

¿Puede un equipo de SRE evitar incidentes de producción?

Una de las fortalezas de un Ingeniero de Confiabilidad del Sitio profesional, es la capacidad de manejar el crecimiento de la carga de producción y el tráfico interno. Monitorear y analizar procesos y registros con plataformas como ELK (Elasticsearch, Logstash, and Kibana) Stack, es parte de la carga de trabajo diaria, debiendo de ser capaz el equipo de identificar problemas a medida que ocurren, e incluso prever riesgos para la estabilidad del software.

El poder de este puesto, basado en el conjunto de habilidades que requiere, radica en desarrollar soluciones para estos problemas y riesgos. Como Ciara, un ingeniero de software en el equipo SRE de almacenamiento en la nube de Google, lo describió en una publicación de "La vida en Google": "Resolvemos problemas más fríos en formas más frescas".

¿Estamos haciendo DevOps o estamos haciendo SRE?

Esta pregunta generalmente la hacen personas que intentan posicionarse en el mundo de Operaciones. Según muchas empresas que implementaron SRE de una manera ligeramente diferente a Google, no tienen qué decidir. En Reddit, los ingenieros de operaciones trabajan para reducir el trabajo pesado, mejorando los procesos de implementación y escalado, pero se les conoce como "DevOps".

En Logz.io, cerraron la brecha entre los desarrolladores y la producción a través del uso de monitoreo automatizado, así como pruebas de esfuerzo de rendimiento. En Logz.io lo llaman "DevOps" en lugar de "SRE".

Entonces, ¿es solo una cuestión de contexto?

En su blog, Charity Majors habla de que -"SRE y DevOps son dos enfoques operativos diferentes que cualquier organización puede elegir para trabajar"-, pero insiste en enfatizar que no existe un enfoque "correcto".

Aunque Google y Dropbox han decidido por SRE, esto no significa que el resto del mundo también deba hacerlo. Lo que se ajusta a las necesidades y la filosofía organizacional de Google, no necesariamente funciona para otras organizaciones a cualquier escala.

Además Charity cree que DevOps, habiendo crecido y evolucionado dentro de una variedad más amplia de organizaciones de software, es el enfoque más flexible, colaborativo y adaptable, funcionando mejor para la mayoría de las organizaciones de software en todas las etapas de desarrollo.

Por otro lado, el ingeniero senior de SoundCloud, Matthias Rampke, emitió una serie de tweets sobre cómo SRE y DevOps eran básicamente los mismos, con solo un soporte de gestión altamente diferenciado. Aunque en contradicción con su blog, Charity le dio peso a esta opinión durante un evento AskMeAnything que giró en torno a DevOps y SRE. En el evento Compartió una historia sobre un amigo que estaba contratando para una startup, que como experimento, publicó exactamente la misma descripción del trabajo dos veces, la única diferencia es que una lista se tituló "DevOps engineer" y la otra "SRE". el momento de relatar la historia, DevOps estaba ganando en un 10 o 20 por ciento.

Sin embargo, todo esto significa que el título del puesto es irrelevante y nombrar a un equipo de SRE, no le confiere mágicamente cualidades. En lugar de centrarse en el título, las organizaciones deben enfocarse en el trabajo que se está haciendo.

Para resumir, podemos citar a Matt Simmons, un tecnólogo con muchos conocimientos sobre este tema, quien dice: -"No todas las infraestructuras necesitan un SRE, pero cada infraestructura podría usar un administrador que actuara más como uno"-.

Para Usted, ¿SRE o DevOps?