Adoptar roles nuevos o redefinidos no es suficiente para una transformación exitosa de DevOps, pero es un primer paso fundamental. «En las implementaciones DevOps que no prosperan, las organizaciones no se dan cuenta de que las personas son la parte más importante de la ecuación», dice Gerry Leitao, vicepresidente de managed delivery services y plataformas para la consultora Capgemini North America. «Estas organizaciones a menudo incorporan miembros a sus nuevos equipos DevOps antes de que hayan entendido completamente las habilidades técnicas y soft que se requieren para un equipo DevOps de alto rendimiento. No se dan cuenta de que no todo el personal tiene la visión o las ganas necesarias para tener éxito en un entorno altamente colaborativo y fluido «.

Estos son los siete roles – y habilidades relacionadas, – que son esenciales para cualquier organización que quiera adoptar un enfoque DevOps con éxito».

1. El DevOps pionero “evangelist”

«Hay organizaciones de TI que han evolucionado para sacarle partido a las prácticas y capacidades de DevOps, y hay otras que están en proceso de hacerlo», dice Croker. «Esa evolución no va a producirse sola, y el role principal lo tiene la persona que va a liderar ese cambio». El evangelista de DevOps es tu líder.

Esta persona debe promover los beneficios de DevOps identificando y cuantificando los beneficios comerciales resultantes de la mayor agilidad que ofrece DevOps. Como agente de cambio, DevOps evangelist asegura la coordinación de los equipos de desarrollo y operativos, identifica los roles clave que apoyen los métodos de DevOps y se asegura de que los profesionales de TI estén capacitados para llevar a cabo esos cambios, dice Nagisetty. Además, el líder de tu movimiento DevOps necesita eliminar el miedo al fracaso de la organización, dice Antao. «Tienes que crear una cultura que sea de aprendizaje donde no pase nada por fracasar, se haga rápido, se aprenda y se mejore con ello».

Croker está de acuerdo. «En una organización dirigida por DevOps, hay algunos roles nuevos… pero es mucho más importante es que se logre un cambio cultural para afrontar los retos que surgen al proporcionar servicios TI y de las operaciones de TI», afirma.

2. El release manager

Tanto si llamas a este role release manager, release engineer o product stability manager, el enfoque es el mismo: «Los release managers se encargan de la gestión y coordinación del producto desde el desarrollo hasta la producción», dice Nagisetty. «Normalmente se centran en más detalles técnicos y obstáculos en los que un project manager típico no estaría involucrado». Los release managers supervisan la coordinación, la integración y el flujo de desarrollo, testing e implementación para apoyar la entrega continua del servicio. Están enfocados no solo en crear, sino también en mantener la cadena de aplicaciones de principio a fin, dice Antao.

3. El arquitecto de automatización

Debido a que DevOps depende en gran medida de los sistemas automatizados, este role es fundamental. A veces, se les conoce como especialistas en integración, los arquitectos de automatización analizan, diseñan e implementan estrategias para despliegues continuos, al tiempo que garantizan una alta disponibilidad en los sistemas de producción y preproducción, dice Nagisetty.

«Los arquitectos de automatización tienen un rol integral de automatización sobre las herramientas de DevOps y las plataformas cloud», dice Leitao. «Este rol también puede abarcar el lean thinking en los procesos clave de DevOps».

El rol de arquitecto de automatización se ha vuelto clave en el mundo de DevOps. «Las organizaciones DevOps deben crear un entorno de mucha confianza que esté completamente automatizado y libre de obstáculos», dice Mizrachi. «En determinadas circunstancias, todo el mundo tiene que disponer de vehículos 4×4 para conducir fuera de la carretera por terrenos difíciles. La función de la automatización de DevOps tiene la tarea de construir la carretera para que podamos usar coches rápidos».

El puesto es especialmente importante para las organizaciones que se organizan por aspectos geográficos, añade.

4. El developer/probador de software

El desarrollador de software es el corazón de la organización DevOps. En DevOps, la categoría de desarrollador de software puede seguir siendo la mismo, pero el nuevo rol del developer/tester de software aumenta drásticamente el alcance de las responsabilidades. Los desarrolladores son responsables no solo de convertir los nuevos requisitos en códigos, sino también en testing, implementación y monitoreo continuo. «No solo crean códigos para algo específico y lo pasan al equipo de control de calidad», dice Antao de PwC.

Así como DevOps implica una colaboración más amplia entre los equipos de desarrollo y operaciones, a veces también se lo denomina DevTestOps, lo que refuerza la idea de que el testing es una parte del proceso, dice Nagisetty.

Este cambio a menudo requiere que se realice un testing más automatizado para que la calidad no se vea perjudicada. «El problema es que los equipos aún piensan que pueden hacer los tests de forma manual y aun así ser ágiles. No se puede», dice Mizrachi. «Si necesitas testear nuevas versiones todos los días y lo haces de forma manual tardando dos semanas, es prácticamente imposible. La calidad del producto generalmente se deteriora hasta que la organización y los procesos cambian».

5. El profesional de experience assurance (XA)

Si bien la función de garantía de calidad (QA) a menudo forma parte del desarrollo de software, se necesita un nuevo tipo de control cuando las organizaciones adoptan el enfoque DevOps. La necesidad contar con los testers de control de calidad es reemplazada por la necesidad de que los expertos de XA se encarguen de garantizar que todas las características y funciones nuevas se lancen teniendo en cuenta la experiencia del usuario final. «Lo que se espera actualmente de los roles de QA es probar la funcionalidad, pero el rol debe evolucionar para incluir el testing de la experiencia del usuario», dice Mizrachi.

6. El ingeniero de seguridad

En el tradicional desarrollo en cascada, la seguridad del sistema ha surgido tarde. Es un «requisito no funcional» que, al igual que la garantía de calidad, a menudo se agrega al final del desarrollo del sistema, dice Antao de PwC.

El enfoque DevOps cuenta con ingenieros de seguridad que trabajan codo a codo con los desarrolladores, integrando sus recomendaciones mucho antes en el proceso. «Le dan seguridad al producto, no al final», dice Antao.

7. La importancia del technology player

Los profesionales de operaciones de TI o administración de sistemas tradicionales se centran en mantener los servidores en funcionamiento. «En general, sus máquinas funcionan mejor cuando hay pocos cambios», dice Perforce’s Warren. «Es probable que la causa más común de las interrupciones del servicio sean las aplicaciones que se ejecutan en estos servidores, por lo que los administradores incluyen controles muy estrictos sobre lo que está permitido ejecutar en sus servidores. Requieren un amplio control de calidad en un entorno de prueba, un gran delivery, documentación de operaciones y lanzamientos poco frecuentes». Los desarrolladores típicos han sido codificadores directos sin involucrarse en los sistemas de postproducción.

El entorno rápido de DevOps requiere un nuevo perfil. «Los expertos en operaciones o administración ahora se están involucrando a lo largo del proceso de desarrollo», dice Warren. «Hoy en día, no sería raro que estos expertos en operaciones, que a veces se conocen como ingenieros de DevOps, participen en la planificación de sprints para garantizar que se priorice una mejor calidad de servicio, gestión de recursos o seguridad por parte de la compañía».

Teniendo como antecedente el desarrollo o las operaciones de TI, «DevOps requiere miembros para su equipo que puedan operar de manera efectiva en plataformas de desarrollo, herramientas, redes, servidores y bases de datos, e incluso en desarrollo y soporte», dice Leitao.

Una transición efectiva al entorno de DevOps es más una cuestión de las personas que integran el equipo y de la manera en que trabajan juntas para ofrecer productos de una forma diferente que de la tecnología. Al reclutar o volver a formar a los profesionales de TI para ocupar estos siete roles de DevOps, los líderes de TI pueden dar un primer paso importante hacia el logro de un modelo DevOps exitoso.

Los y las especialistas en SRE se dedican a idear sistemas que presentan una alta tolerancia ante los fallos, utilizando estrategias como la degradación gradual (desactivación de algunos procesos para que el sistema siga funcionando, aun con incidencias); o la defensa en profundidad, que prevé vías para que los errores se corrijan por sí solos de manera automática.

Los y las especialistas en SRE se dedican a idear sistemas que presentan una alta tolerancia ante los fallos, utilizando estrategias como la degradación gradual (desactivación de algunos procesos para que el sistema siga funcionando, aun con incidencias); o la defensa en profundidad, que prevé vías para que los errores se corrijan por sí solos de manera automática.

Para limar estas asperezas nació lo que se conoce como la cultura DevOps, un modelo diseñado para derribar las barreras entre los equipos y equilibrar las diferencias entre desarrolladores, sistemas y otras áreas del trabajo en las empresas tecnológicas. Sin entrar en demasiados detalles, en resumen, las prácticas DevOps implican intentar reducir los problemas de la organización, entender que errar es parte del proceso, implementar los cambios de forma continua y gradual, utilizar herramientas de aprovisionamiento, de automatización de procesos, y, por supuesto, medirlo todo.

En un entorno como el de hoy, cambiante y permanente evolución, la presión por ser cada vez más ágiles en los tiempos de salida al mercado, manteniendo la estabilidad o la fiabilidad de los productos al 100%, va en aumento. La cultura DevOps, que se adopta en los equipos de TI –de los cuales el de SRE forma parte–, tiene como objetivo crear un ambiente colaborativo en función de una meta común, logrando que los departamentos de operaciones y desarrollo estandaricen procesos comunes, así como herramientas ágiles para la entrega de software.

Depende, fundamentalmente, del tamaño de la empresa, su actividad y de cuáles sean las prioridades de ésta. Por otra parte, aunque la posición es relativamente nueva para el mundo en general, en las empresas tecnológicas adquiere cada vez mayor protagonismo y todas las grandes del sector, como Dropbox, Twitter,
 Apple y, por supuesto, el pionero Google, incluyen el puesto entre sus filas.

Como ya hemos mencionado, no hay una descripción del cargo única para el puesto de SRE, lo que sí hay, no obstante, es coincidencia en que el SRE debe asegurar(se) de la disponibilidad, el rendimiento, la monitorización y la respuesta a incidencias de las plataformas y servicios que opera su organización. Los equipos SRE personifican la filosofía DevOps poniendo el foco en los objetivos antes mencionados.

Dentro de las tareas del equipo de SRE está, claramente, la mejora continua de los sistemas a través de la incorporación de nuevos servicios y funcionalidades. Además, por supuesto, de la resolución, cuando ocurren incidencias, de los problemas subyacentes para garantizar que todo vuelva rápidamente a la normalidad. Dada la escala a la que trabajan normalmente los equipos de SRE, es prácticamente imposible que no haya incidentes de vez en cuando. Sin embargo, hay una manera de que los mismos incidentes no se repitan: el postmortem. Este proceso que es, en rigor, una autopsia de lo ocurrido permite a los miembros del equipo de SRE formalizar el proceso de aprendizaje a partir de los errores o fallos del sistema. El concepto es bien conocido en el sector tecnológico y de acuerdo a la definición de John Lunney y Sue Lueder “es un registro escrito de un incidente, su impacto, las acciones tomadas para mitigarlo o resolverlo, la(s) causa(s) raíz y las acciones de seguimiento para evitar que el incidente vuelva a ocurrir”. En cualquier caso, es una parte importante del trabajo de los equipos de SRE.

Quienes lo conforman son personas proactivas e innovadoras que proporcionan diversos enfoques de ingeniería de software para resolver los desafíos que plantea tanto a nivel operativo como a nivel de desarrollo y mantenimiento de infraestructura. Cualquiera que forme parte de ese equipo desempeña un papel importante en el desarrollo de los productos y servicios de la empresa.

El SRE en Magnolia trabaja en el corazón de nuestro sistema de producción, supervisando el desempeño del servicio y que todo esté en orden, definiendo y administrando la infraestructura como código (IaC) en la nube, mejorando los pipelines de CI/CD, construyendo los sistemas de monitorización e implementando los sistemas de aprovisionamiento y orquestación.

Además, los miembros del equipo de SRE colaboran en el diseño, construcción y despliegue de servicios escalables, en las revisiones de la arquitectura, en las pruebas de vulnerabilidad y en las revisiones de seguridad.
 Para entrar a formar parte de este equipo hace falta tener un grado en Informática o en un campo técnico relacionado, o experiencia práctica equivalente, además de experiencia comprobada con infraestructura en la nube (AWS y Terraform), herramientas de administración de configuración (Ansible), entrega continua y tecnologías de contenedores (Docker, Kubernetes).

En una posición de SRE es muy importante la capacidad de análisis y solución de problemas distribuidos en la producción a gran escala. Es importante tener experiencia en programación con uno o más lenguajes relevantes: Java, Python, Bash, Go, JavaScript, así como en la operación, optimización y escalado de bases de datos SQL, tecnología de contenedores y clústeres gestionados con Kubernetes.
 Hay que estar familiarizado con los estándares de seguridad y operación, así como con las mejores prácticas sobre datos personales. Y en Magnolia, además valoramos mucho las habilidades de comunicación sólidas y la pasión por lo que hacemos.

 

Site Reliability Engineer (SRE) es un rol de gestion de proyectos que colabora con los procesos entre el desarrollo de software para la mejora de la estabilidad y el rendimiento; y la monitorización y resolución de problemas, con el fin de asegurar tanto la disponibilidad del servicio como el crecimiento y la innovación empresarial.

La ingeniería de confiabilidad del sitio (SRE) es un enfoque de ingeniería de software para las operaciones de TI. Los equipos de SRE utilizan el software para gestionar los sistemas, resolver los problemas y automatizar las tareas operativas.

La SRE asigna las tareas que siempre han realizado los equipos de operaciones, muchas veces de forma manual, a los ingenieros o a los equipos de operaciones, que utilizan el software y la automatización para resolver los problemas y gestionar los sistemas de producción.

DevOps es un modo de abordar la cultura, la automatización y el diseño de las plataformas para generar mayor valor empresarial y capacidad de respuesta, mediante la prestación ágil de servicios de alta calidad. La SRE puede considerarse una implementación de DevOps.

Ambos se basan en las relaciones y la cultura del trabajo en equipo, y tienen como objetivo acortar la brecha entre los equipos de desarrollo y de operaciones para prestar servicios con mayor rapidez. 

Algunos de los beneficios que ofrecen las prácticas de DevOps y de SRE incluyen ciclos de vida de desarrollo de las aplicaciones más rápidos, mayor calidad y confiabilidad de los servicios y menor tiempo de TI por cada aplicación desarrollada.

La SRE es diferente porque depende de los ingenieros de confiabilidad del sitio dentro del equipo de desarrollo, que también deben tener experiencia en operaciones, para eliminar los problemas de comunicación y de flujo de trabajo.

Su función requiere las habilidades tanto del equipo de desarrollo como del de operaciones, ya que superpone las responsabilidades. 

La SRE puede ayudar a los equipos de DevOps cuyos desarrolladores tengan demasiadas tareas operativas y necesiten a un especialista en dicho campo. 

En términos del código y las características nuevas, DevOps se concentra en aportar eficiencia a todo el proceso de desarrollo, mientras que la SRE se enfoca en equilibrar la confiabilidad del sitio con la creación de características nuevas. 

https://www.tecnologias-informacion.com/devops.html
https://www.redhat.com/es/topics/devops/what-is-sre#comparaci%C3%B3n-entre-devops-y-la-sre