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

32

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?

Aurora0001
fuente
Debe hacer lo que sea más efectivo para su negocio, equipo y proyecto. Debes experimentar para descubrir qué es lo más efectivo. La agilidad está efectuando un cambio apropiado para su situación específica. Como dijo Kent Beck, "cualquier respuesta decente a una pregunta interesante comienza, 'depende ...'"
Adrian

Respuestas:

24

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.
Jiri Klouda
fuente
11
Me resulta difícil vincular su tl; dr con el resto de la respuesta donde da razones para contratar ...
Tensibai
El resto de las respuestas explican cómo ninguno de los roles relacionados con DevOps conduce a la creación de un equipo de esas personas. No contrate un nuevo equipo, incruste personas en lugares específicos de su organización según las necesidades.
Jiri Klouda
55
@JiriKlouda excelente respuesta, estoy casi 100% de acuerdo, menos el término "Operaciones del sistema (SRE)" - Operaciones del sistema = Ingeniero de confiabilidad del sitio, este último es el modelo de Google para DevOps que aún incorpora los principios básicos de DevOps pero conserva algunos de Las ventajas de contar con un equipo de operadores especializados.
Richard Slater
Lo que quise decir es equipo de operaciones en cualquier forma, ya sea tradicional o SRE o cualquier otra forma de infraestructura o administración de plataforma. Y confía en mí, puedes tener equipos de Site Reliabikity sin adoptar completamente DevOps :)
Jiri Klouda
1
Honestamente, simplemente no hay suficiente allí. El ingeniero de CI / CD debe saber lo suficiente para diseñar las tuberías. El arquitecto DevOps puede hacer el trabajo de alto nivel a nivel organizacional. He separado el rol de ingeniero DevOps porque tiene características diferentes. Es un trabajo de ingeniería orientado a herramientas, puede ser fácilmente parte de un equipo (herramientas / integración / equipo de aplicaciones internas). Esto sería lo que la gente confunde principalmente con los ingenieros de DevOps. Es la evolución de los ingenieros de lanzamiento, pero con automatización. En lugar de compuerta, ahora simplemente están construyendo y monitoreando la automatización.
Jiri Klouda
10

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.

Tensibai
fuente
1
¿Cómo sugeriría que uno distinga entre un administrador de sistemas que se siente cómodo leyendo el código para diagnosticar problemas, la infraestructura y la automatización de la nube, y los administradores de sistemas tradicionales que tienen mucha experiencia pero ninguna de esas habilidades?
avi
@avi por su currículum, el mío por el ejemplo con el que me siento más cómodo de comparar, tiene esos mientras todavía se titula Net / Sysadmin. Tengo referencias a la organización devops para algunos proyectos con los que he trabajado. Y, por lo general, no me postulo para la propuesta usando devops como palabra de moda debido a las advertencias que menciono en esta respuesta (
recibí
@Avi si te refieres a una propuesta de trabajo, en los detalles de la propuesta, las calificaciones requeridas son muy diferentes de las de la pregunta y las de la respuesta de Jiri para mantener los títulos de trabajo en mi humilde opinión
Tensibai
1
Me inclino a decir que un administrador de sistemas que no se siente cómodo con la automatización es solo un administrador de sistemas poco calificado, no un título de trabajo diferente. Ver también este ensayo de John Allspaw's .
Xiong Chiamiov
6

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

usuario2965205
fuente
Muy útil, gracias. Es interesante escuchar cómo te convertiste esencialmente en lo que otros podrían llamar un 'Ingeniero de DevOps' indirectamente, y creo (por lo que han dicho las otras respuestas) que tu camino está más en línea con la filosofía de DevOps de no tener un 'DevOps completamente separado ' Departamento. ¡Parece que te ha funcionado bien hasta ahora!
Aurora0001
¿Entonces básicamente manejas todo tú mismo? ¿Qué pasa si dejas la empresa? ¿El negocio podrá sobrevivir? ¿Cuál es el punto de vista de su gestión sobre esto?
030
La infraestructura se gestiona sola. Está completamente documentado, y usamos Terraform & Puppet para orquestar la infraestructura y administrar las configuraciones del servidor. Entonces, en realidad, cualquier ingeniero de títeres / terraformas con experiencia en AWS puede conectarse. Ahora soy un accionista en el negocio, y nuestro equipo de desarrollo ha crecido significativamente. Afortunadamente, ahora todos saben cómo fluye la infraestructura
usuario 2965205
4

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".

James Shewey
fuente
Entonces, ¿todas esas descripciones de trabajo son simples para ver quién solicita? Parecen querer todo en el mundo. Lo miro y pienso, sé esto, esto, aquello, y no eso, no eso, no eso ... Tal vez todos los negocios describan el mundo y vean lo que obtienen.
Johnny
1
@johnny He escuchado historias de empresas que requieren 7 años de experiencia en tecnologías que se crearon hace solo 5 años ... sí, son listas de deseos. No son requisitos difíciles.
James Shewey
Gracias. Lista de deseos es la frase que estaba buscando.
Johnny
3

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

Ian Margetts
fuente
3

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.

químico surrealista
fuente
1

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.

Erik Funkenbusch
fuente
1
Expanda un poco su posición, esta respuesta es demasiado corta para el tema de esta pregunta.
Tensibai
1
@Tensibai: mi único punto es que es solo un título. Llamar a alguien ingeniero de DevOps no importa si realmente no estás siguiendo los principios de DevOps
Erik Funkenbusch