En Zweicom ya llevamos varios años implementando el trabajo de DevOps con buenos resultados, sin embargo, aún queda mucho camino que recorrer para lograr una implementación en donde la metodología se conforme de manera consolidada. Con este paso ya seguro, es que ahora hemos puesto la mirada en el SRE para iniciar un cambio dentro de nuestro equipo de Soporte, acercándolo aún más a las soluciones productivas de una manera más directa, y con el menor costo posible. Este cambio será un nuevo desafío tanto para el equipo de Soporte, como para el resto de los equipos y la empresa, ya que claramente no es sólo un cambio de nombre de cargo, sino un cambio de rumbo y manera de enfrentar las diferentes situaciones operacionales.

La problemática tiene relación con que, en la actualidad, en muchas empresas, los administradores de sistemas son profesionales que han hecho carrera desde soporte de red u operadores para llegar a ser quienes conocen todo el tejemaneje en relación con la administración de los diferentes sistemas de la compañía (internos y externos). Conocen con exactitud cuando un sistema debe ser reiniciado, que servicios tienen errores recurrentes o cuando existen alarmas con falso positivo, o «errores buenos».

Muchos de los procesos se realizan manualmente, mientras que para otros se valen de scripts, complejos o no, que permiten lograr de mejor manera el manejo de las diferentes tareas rutinarias para los diferentes servicios que están bajo su responsabilidad.

Se puede ver como un problema el hecho de que bajo este escenario nadie más puede entrar en el mundo de producción, y cualquier cambio que se requiera necesita estar documentado como requerimiento y pasar por procesos burocráticos para su implementación siempre y cuando el Sysadmin esté de acuerdo.

A partir del año 2008, Google enfrentó el problema de la administración de servicios productivos tomando en cuenta que las motivaciones que tenían el equipo de desarrollo versus las del equipo de operaciones eran contrapuestas, y por tal motivo no existía sinergia ni menos colaboración. Entonces, surgió la propuesta de Treynor que no es otra cosa de que además de que Operaciones sea responsable de la estabilidad del entorno de producción, estén también comprometidos respecto a las nuevas funciones de los desarrollos y su forma de mejorar la operación. Así nace el rol del SRE (Site Reliability Engineering).

A diferencia de la metodología DevOps, en que una de sus tareas es la de plantear problemas para que el equipo de Desarrollo lo resuelva, en el caso del SRE muchos de los problemas encontrados deben ser resueltos por ellos mismos.

Uno de los objetivos a trabajar por un SRE es el de utilizar el código como infraestructura, pudiendo de este modo escalar soluciones hacia diferentes ambientes. El poder levantar diversos ambientes de la misma solución de software modificando únicamente variables de entorno y de conectividad es parte de lo que un SRE debe estar preocupado y lograr resolver.

Entonces, la gran diferencia entre un DevOps y un SRE es que el primero busca lograr la Integración Continua y la Entrega Continua, mientras que el segundo busca poder escalar dichos resultados para diversos ambientes, mejorando así también la resolución de problemas dentro de los espacios productivos. Sin embargo, ambos buscan la mejor forma de llevar a cabo la operación de los servicios digitales en conjunto con el equipo de desarrollo, llevando la fiabilidad del negocio al máximo.