¿Por qué no debería intentar contratar a un "ingeniero de DevOps"?

La idea de tener un ingeniero de DevOps se ha vuelto bastante popular recientemente , y parece atractivo tener una persona que pueda ingresar y proporcionar muchos de los beneficios de DevOps, como se describe en el blog de Puppet :

Las organizaciones que utilizan las prácticas de DevOps tienen un funcionamiento abrumadoramente alto: implementan código hasta 30 veces más frecuentemente que sus competidores, y 50 por ciento menos de sus implementaciones fallan, según nuestro informe del Estado de DevOps de 2015.

Sin embargo, he notado una gran oposición vocal a la idea de un ingeniero de DevOps para intentar hacer estas mejoras:

Incluso con un amplio acuerdo sobre los atributos centrales de DevOps, la controversia rodea el término "ingeniero de DevOps". Algunos dicen que el término en sí contradice los valores de DevOps. Jez Humble, coautor de Continuous Delivery, señala que solo llamar a alguien ingeniero de DevOps puede crear un tercer silo además de dev y ops - "... claramente una forma pobre (e irónica) de tratar de resolver estos problemas ".

¿Por qué podría no ser una gran idea para una empresa contratar a un ingeniero de DevOps para que intente e 'implemente DevOps', a diferencia del cambio organizativo que promueven blogs como este ? ¿Se negarán los beneficios simplemente teniendo un rol DevOps aislado?

TL; DR : nunca debe intentar contratar un equipo de DevOps

Básicamente, hay tres roles más comunes para contratar:

1. Arquitecto / Evangelista de DevOps
2. Ingeniero DevOps
3. Ingeniero de CI / CD

Estos roles son distintos de sus 6 roles esenciales de desarrollo de software que componen tradicionalmente la organización de ingeniería de software:

1. Gestion de producto
2. Desarrollo de software
3. Desarrollo de herramientas
4. Seguridad y cumplimiento
5. Calidad y pruebas
6. Operaciones del sistema (SRE)

Veamos los tres roles uno por uno y veamos cómo encajan

Arquitecto o evangelista de DevOps

• Por qué : si estás perdido, lento, roto y no sabes qué hacer.
• Cuándo : al comienzo del proceso en etapas de planificación.
• Qué : Rol de nivel de gestión para guiar a todos los gerentes y líderes en toda la organización de Ingeniería de Software. Esta persona planificará la transformación completa de su organización de ingeniería a un estado altamente funcional.
• Quién : Miembro consultor bien versado en teoría, prácticas de gestión, temas culturales y operaciones que informa directamente al Vicepresidente de Ingeniería de Software.

En algunos casos y para pequeñas y medianas empresas, puede comenzar el proceso contratando una organización de consultoría, como DORA.

Ingeniero DevOps

• Por qué :
  1. Para cerrar las brechas entre los equipos si están organizados a lo largo de los roles funcionales mencionados anteriormente para garantizar la cooperación entre niveles funcionales.
  2. Para integrarse con equipos orientados al producto, que tienen cada uno de los 6 roles tradicionales incluidos en el equipo, para ayudar a cerrar las brechas de conocimiento y ayudar con la implementación y adopción de las prácticas y herramientas novedosas.
• Cuándo : Una vez que haya presentado sus planes y comience la transformación organizacional y todo el equipo de gestión esté a bordo.
• Qué : Habilite la cooperación entre funciones, asegúrese de que los límites del equipo se desglosen, que las optimizaciones locales dentro de los equipos no creen una barrera para el alto rendimiento del trabajo en todas las cadenas de valor, desde los deseos del cliente hasta las entregas del cliente.
• Quién : Ingeniero experimentado con habilidades tanto en desarrollo de software como en operaciones de sistemas. Debe ser experto en las mejores prácticas, procesos y cambios culturales relacionados con la transformación de DevOps.

Ingeniero de CI / CD

• Por qué : para ayudar a implementar las canalizaciones de CI / CD, integre su cadena de herramientas, incorpore las herramientas que permitirán un mejor funcionamiento de la empresa.
• Cuándo : durante la transición en una organización más grande, mientras que los roles anteriores ya se han cumplido.
• Qué : Ingeniero, que es esencialmente parte del equipo de herramientas que podrá configurar tuberías de CI / CD y comenzar a integrar sistemas internos de una manera que elimine la fricción del rendimiento del trabajo.
• Quién : Ingeniero con experiencia en herramientas, proceso de integración, gestión de versiones y prácticas de DevOps. Alguien que entiende que está reemplazando el bloqueo humano en el proceso de liberación por Automation.

Yo diría que el Ingeniero Devops como se describe en el enlace de su pregunta es principalmente un rol de administrador de sistemas. Citando las habilidades aquí para conocer los antecedentes de esta respuesta:

Tu equipo de escalada.

• Experiencia sólida en la experiencia de administración de Linux / Unix con gestión de automatización / configuración usando Puppet, Chef o un equivalente
• Capacidad para utilizar una amplia variedad de tecnologías de código abierto y servicios en la nube (se requiere experiencia con AWS)
• Gran experiencia con SQL y MySQL (la experiencia NoSQL también es una ventaja, ya que también utilizamos Redis)
• Una comprensión funcional del código y script (PHP, Python, Perl y / o Ruby)
• Conocimiento de las mejores prácticas y operaciones de TI en un servicio siempre disponible y siempre disponible.

En esta descripción de trabajo de ejemplo, DevOps Engineer es solo una palabra de moda para un administrador de sistemas que se siente cómodo con la infraestructura basada en la nube, la automatización, es capaz de leer el código para ayudar en el diagnóstico y conoce las prácticas y soluciones de alta disponibilidad.

Esto está vagamente relacionado con las prácticas de DevOps y la cultura de ruptura del silo entre dev y ops como se ve en esta pregunta ¿Cuál es la diferencia entre Sysadmin y DevOps Engineer?

No será una buena idea porque un administrador de sistemas, lo cómodo que puede estar con la práctica y cultura de DevOps, no es la persona adecuada para impulsar una transformación de la empresa. No contratará a esta persona con un cambio de cultura en mente, sino con una vista de configuración de herramienta, que realmente no ayudará a romper los procesos. Esto también puede ser mal recibido por sus colegas y solo traerá resistencia al cambio si no hay un cambio cultural planificado de antemano

Para un patrón exitoso hacia las ganancias de los devops, la respuesta de @ Jiri Klouda brinda una excelente visión general sobre un rol aceptable de Ingeniero DevOps junto con el paso en el cambio que aportaría valor y ayuda al éxito.

Me doy cuenta de que esta respuesta puede no ser perfecta para ti, pero esto es lo que hice

Fui el primer desarrollador que trabajaba en una startup de comercio electrónico muy ocupada, con un tráfico increíblemente alto. Me doy cuenta de que la empresa aún era joven y que, por un tiempo, sería el único recurso técnico interno.

Sabiendo esto, decidí estructurar mi infraestructura de tal manera que tendría que hacer la administración de sistemas CERO.

Decidí alojar en la nube, porque hacerlo me liberó del mantenimiento de los sistemas. Busqué un ingeniero de AWS, con experiencia en títeres. Juntos, diseñamos una infraestructura autoescalable, escrita como código en la formación en la nube. Todos los archivos de configuración fueron versionados dentro de la marioneta.

Esto me permitió, como desarrollador, asumir este rol devops. Construí herramientas de liberación de código, en python, fabric. Utilicé el mismo script para iniciar mi aplicación en nuevos servidores que se escalan automáticamente.

Esto funcionó muy bien, y hoy, 3 años después, todavía no hago ningún mantenimiento del sistema. Tenemos un administrador de sistemas (el mismo ingeniero de AWS) durante 10 horas al mes, y trato de estructurar sus sprints de tal manera que no me convierta en una molestia para él. De esa manera respeto su tiempo y manejo sus sprints de la mejor manera que puedo.

Si un sistema tiene un rendimiento degradado, simplemente lo finalizo, y otro gira en su lugar.

Espero que esta respuesta te pueda beneficiar de alguna manera

No debe contratar a un ingeniero de DevOps porque DevOps abarca una variedad tan amplia de disciplinas que un individuo no puede ser un experto en todos los aspectos de estas disciplinas. Al contratar un jack de todos los oficios, estaría contratando a un maestro de ninguno.

DevOps es necesariamente un esfuerzo basado en el equipo y no puede esperar que un individuo respalde las expectativas de todo un equipo. Considere el alcance de DevOps. Una persona no puede:

• Sé un desarrollador de rockstar en [idioma]
• Sea un gurú de redes, conociendo todos los RFC necesarios
• Sé un administrador de sistemas
• Sea un experto probador de control de calidad
• Ser un administrador de bases de datos
• Especializados en almacenamiento y respaldo
• Conozca la ingeniería de confiabilidad del sitio
• Potencialmente otras disciplinas también

Algunos de los anteriores incluso tienen subdisciplinas , como Windows Systems Admin vs. Linux / Unix System admin o tal vez use más de un lenguaje de codificación en su.

Ninguna persona puede ser experta en todo esto, lo que significa que si está anunciando un ingeniero DevOps, cuando el área más débil de su equipo DevOps es Networking, no está haciendo un muy buen trabajo publicitando su necesidad de un especialista en redes para su equipo DevOps . Si bien ningún individuo debe ser encasillado para un rol específico en el equipo de DevOps, usted perjudicaría a su equipo al pretender que no hay especialistas o expertos en la materia (PYME) dentro del alcance de DevOps. Balancear el péndulo de un extremo al otro, desde hacer silos hasta fingir que todos los roles de su equipo DevOps son iguales, puede causar la misma cantidad de problemas.

Si bien hacer que los miembros del equipo entrenen en más de una disciplina, particularmente en las áreas superpuestas es bueno, esperar que sean capaces de dominar un volumen tan amplio de conocimiento simplemente no es práctica.

Esto significa que cualquiera que le diga que conoce todos los aspectos de DevOps probablemente le está mintiendo. Contrata a un especialista en el área en la que seas más débil que haya trabajado en un equipo DevOps, no un "Ingeniero DevOps".

Tuve este desafío exacto al implementar en ASOS. El objetivo para nosotros es tener equipos que sean autosuficientes y, por lo tanto, tener un rol dedicado puede ser un antipatrón, sin embargo, vivimos en el mundo real y para muchos desarrolladores pensar en buenas prácticas de DevOps no es lo principal, por lo que necesitan ayuda llegar allí.

Lo que hicimos fue:

• perder el término de ingenieros de DevOps, DevOps es algo que todos deberíamos hacer, no nuestro título de trabajo, por lo que los llamamos algo diferente.

• los desplegó en equipos, pero solo 1 de cada 3, esto significaba que no podían ser buenos, sino que tenían que verse como una competencia para ayudar a los equipos a mejorar y resolver sus propios problemas (con orientación)

• mantuvo también una función central para actuar como centro de competencia y manejar las consideraciones empresariales, cualquier cosa que afecte a todos los equipos

A medida que evolucionamos, revisamos este modelo, pero para nosotros funciona de manera efectiva hasta ahora

No creo que pueda obtener una respuesta definitiva para esto porque parece que muchas cosas tienen en cuenta.

• Cómo a bordo está la compañía con la práctica de DevOps
• ¿Qué tipo de aplicación o servicio proporciona la empresa?
• La estructura de su empresa

Acabo de terminar la entrevista para los puestos y terminé con un título de ingeniero DevOps, pero parte de lo que estoy haciendo es trabajo de administrador de sistemas. Eso es solo por necesidad debido al tamaño de la empresa y la naturaleza de lo que se está administrando de manera inteligente. Algunos puestos para los que entrevisté tenían un título similar y buscaban más a alguien desde el lado del desarrollo de las cosas con experiencia. Esperaban más escritura de código y no un administrador del sistema que realiza la automatización. SRE parece ser un título que está ganando popularidad, por lo que ese podría ser el camino a seguir. Tuve mi mismo trabajo como Administrador del Sistema e Ingeniero de Automatización como mi último trabajo porque estaba escribiendo ansible y el chef acumulaba parte del tiempo. La compañía seguía un modelo bastante bueno de desarrolladores donde todos estaban a bordo y los desarrolladores trabajaban junto a las operaciones, pero creo que su futuro no

Ahora que estoy en esta posición, estoy tratando de calzar la bocina con cierta automatización y tenemos algunos problemas con las personas que tendremos que resolver. La gente va y viene y algunos de los flujos de trabajo se diseñaron porque alguien más lo diseñó de esa manera y no porque se ajuste a la forma en que las personas trabajan.

Básicamente, creo que deberías averiguar la descripción del trabajo y no preocuparte tanto por el título a menos que esté vinculado a pagar de alguna manera o creas que uno u otro atraería al tipo correcto de personas.

Si le preocupa el significado de DevOps y sigue un "camino verdadero". No debe contratar a un ingeniero de DevOps. Debe contratar a un ingeniero de automatización, un ingeniero de implementación, un arquitecto de plataforma o una serie de otros roles que hagan lo que necesita.

Si ser un verdadero profesional de DevOps no es importante para usted, puede llamarlo como quiera.