Acabo de hablar con un tipo de DevOps que planteó algunos puntos realmente buenos sobre las dificultades de ser un ingeniero de DevOps y sentirse a veces como un ejército de un solo hombre, a pesar de que está en un equipo de 16 ingenieros.

Lleva muchos sombreros diferentes, pero se sienta en el equipo de Desarrollo haciendo trabajo de infraestructura. Le encanta la tecnología genial con la que trabaja: cargas de automatización, nube, contenedorización, etc. Pero le cuesta que él sea la única persona que hace ops, en un devequipo. Reporta al Gerente de Desarrollo, pero trabaja más estrechamente con el Gerente de Infraestructura.

Este parece ser el caso con muchos profesionales de DevOps con los que hablo. ¿Qué se podría hacer para ayudar a los ingenieros de DevOps a sentirse menos como un lobo solitario?

Mi primer pensamiento es "¿por qué es él la única persona que realiza operaciones, en un equipo de desarrollo, especialmente cuando trabaja con mucha automatización?". Creo que hay una oportunidad para abordar el síndrome del lobo solitario; particularmente en un entorno de desarrollo, la infraestructura como código proporciona un gran marco para compartir la carga. Las personas de operaciones deberían ser expertos en determinar y definir las necesidades de infraestructura para la aplicación, pero también deberían ser capaces de construir una plataforma para permitir que los roles de desarrollo hagan tanto como puedan independientemente.

Suena como un silo dentro de un equipo; los viejos hábitos tardan en morir. Es posible que un codificador no se sienta cómodo haciendo girar y fortaleciendo un servidor, pero en un modelo devops puro, debería tener las herramientas para hacerlo. Una persona de operaciones en un equipo de DevOps no debería ser responsable de entregar la infraestructura para la aplicación en sí, pero debe proporcionar una idea de lo que se necesita y una guía sobre cómo los desarrolladores de la aplicación pueden hacerlo ellos mismos. Es casi un modelo de meta-infraestructura; Los ingenieros de operaciones construyen infraestructura que puede construir infraestructura bajo demanda cuando lo solicita el equipo de desarrollo.

La consulta, la comunicación y la combinación de responsabilidades son cruciales para el éxito de un equipo devops.

Creo que el primer defecto está en esta oración:

Reporta al Gerente de Desarrollo, pero trabaja más estrechamente con el Gerente de Infraestructura.

DevOps es un cambio cultural que apunta a eliminar los silos. Si quedan silos, entonces este ingeniero es lo que quieras llamarlo; un ingeniero que realiza desarrollo operativo, un experto en automatización, un desarrollador que automatiza la infraestructura, pero este ingeniero no es un ingeniero de DevOps.
De hecho, "DevOps Engineer" no es un rol real , es más un "chapeau", ya que puede abarcar a desarrolladores, administradores de sistemas, evaluadores de calidad y arquitectos que trabajan en un equipo común.

Un problema que a menudo veo es que las personas caen en el uso de la palabra de moda de DevOps, viéndolo como un título de trabajo, pero realmente no entienden qué es DevOps. Al ver DevOps de esta manera, a menudo terminan aislados y se sienten solos, culpando a los fracasos y las deficiencias de ser un "lobo solitario" sin aceptación administrativa y organizacional.

Como lo describe, este ingeniero es el único que realiza operaciones en un equipo de desarrollo. Eso no lo convierte en un "ingeniero de DevOps". (Lo que sea que eso signifique en su organización) Está trabajando de manera aislada porque el trabajo se presenta como "Ingeniero DevOps", pero parece que otras personas en su equipo no desean trabajar en las operaciones.

Seamos honestos, siempre habrá operaciones y desarrolladores, la idea principal detrás de los desarrolladores es compartir las responsabilidades de tal manera que no haya una transferencia de un producto de los desarrolladores a las operaciones o simplemente el suministro de plataformas por operaciones para los desarrolladores. El objetivo principal es traer más colaboración a un equipo. Llamar a este rol "Ingeniero de DevOps" es romper esta idea al sugerir en el nombre que puede hacer ambas cosas al mismo nivel de experiencia, lo cual rara vez es cierto.

Lo primero que debo hacer en mi opinión sería presentar las herramientas operativas al equipo y dar a todos un conocimiento básico sobre las herramientas, luego transferir la responsabilidad de configurar / codificar las herramientas operativas a todo el equipo. La idea principal detrás de esto es pasar de "el que hace todas las operaciones" a "el que apoya y da implementaciones de referencias al equipo".

Esto complementa las otras respuestas al proporcionar algo procesable de una manera más simple como primer paso que una reorganización de la gestión.

Lo más importante para los ingenieros de DevOps en este tipo de situaciones es obtener (a) Compromiso de gestión y (b) Presupuestos obligatorios . Siga leyendo para obtener más detalles sobre ambos ...

Obtener compromiso de gestión

Una vez que está en su lugar, las cosas se vuelven fáciles para tales ingenieros de DevOps. Especialmente cuando la resistencia (de todo tipo de partidos) entra en juego. Confía en mí, habrá tal resistencia, que desafíos tales como:

• ¿Por qué tenemos que cambiar? ¡Quiero seguir haciendo lo que hice durante X años ya!
• No quiero perder la potencia (técnica) que tengo, y completar todo tipo de procedimientos de flujo de trabajo, para obtener una solución tonta en la producción que me lleve unos 5 minutos en lugar de 5 horas (o días ...).
• ... (Podría agregar otra docena de balas aquí ...).

Cada vez que surgen esos desafíos, todo lo que un ingeniero de DevOps debería decir es como:

Lo siento, solo estoy haciendo mi trabajo ... según las instrucciones de la alta gerencia.

Obtenga presupuestos requeridos

Una forma efectiva de obtener los Presupuestos Requeridos es crear / presentar un caso de negocios apropiado que explique los beneficios tangibles e intangibles de varias prácticas de DevOps al aplicarlos a algunos casos del mundo real que se aplican a la propia empresa.

A continuación se presentan algunos casos del mundo real que experimenté yo mismo, como consultor de SCM contratado por algunas compañías donde sucedieron estas cosas. Lo sé, SCM es solo una parte de DevOps, pero es el área donde tengo algo de experiencia ...

1. Beneficios de la automatización.

Debido a una huelga de solo 2 (!!!) operadores de computadoras (que ya no escribieron los comandos de la consola que esperaban que escribieran), los trenes tuvieron que detenerse en algún lugar a la mitad del camino entre 2 fábricas (ya que el sistema en la fábrica hacia dónde se dirigía el tren hacia abajo, los datos cruciales sobre el manejo del tren no estaban disponibles).

Al implementar un sistema SCM, muchos comandos del operador se automatizaron.

2. Reduzca los costos de licencia de software

Algunos proveedores de software habían decidido aumentar algunas tarifas anuales para el software SCM (obsoleto), que la administración no acordó. Por lo tanto, crearon un proyecto especial para reemplazarlo por algún software SCM alternativo.

El presupuesto del proyecto era igual a la tarifa anual que no querían seguir pagando. Eso incluyó volar en ingenieros de otros continentes (como yo) para que el proyecto tuviera éxito.

3. Reduce los costos operativos

Algunas de las principales compañías de seguros estaban utilizando algún software FTP para transferir arreglos de software a aproximadamente 13,000 computadoras de rango medio (AS / 400) en todo el país, y esto siempre que estaba disponible un "arreglo". El costo de 1 de tales transferencias fue de aproximadamente 4 USD (13,000 x 4 = 52,000 USD por una sola transferencia ...). El software constaba de 120,000 componentes, desarrollados / mantenidos por unos 150 desarrolladores. Haga los cálculos sobre la probabilidad de que 1 desarrollador haya cometido 1 error (pequeño) en cualquiera de estos 120,000 componentes, que llegaron a producción, y requirieron una solución urgente, que costaría otros 52,000 USD (¡solo para la transferencia!).

Al implementar un sistema SCM adecuado (con entornos de prueba administrados, aprobaciones, etc.), esta compañía logró una reducción importante de costos. Piénselo, si el sistema SCM podría evitar la necesidad de solo 20 transferencias de arreglos urgentes, resultaría en una reducción de costos de 52,000 x 20 = 1.040,000 USD (todo un presupuesto para implementar un sistema SCM, solo necesitaban una fracción de esa cantidad para hacer el trabajo).

4. Reduce los costos de indisponibilidad

Si los casos anteriores no son lo suficientemente convincentes, piense en los sistemas de una de las principales compañías de tarjetas de crédito que no están disponibles en todo el mundo. Me han dicho que 1 segundo de indisponibilidad les cuesta 1,000,000 USD.

Esa es probablemente también la razón por la cual, durante mucho tiempo, estas compañías tienen herramientas sofisticadas de DevOps en su lugar, durante muchas décadas. Porque cada segundo que no están en el negocio les cuesta una fortuna.

TL; DR: Dado que la alta gerencia suele ser voluble y propensa a la ira, sugeriría que trate de doblar su mente un poco para obtener una perspectiva diferente, mientras cambia las cosas para mejor, gradualmente.

(Estoy asumiendo que su problema es sobre todo con los reacios desarrolladores , no sus otros ops colegas que parecen hacer operaciones clásicas, principalmente).

OMI, incluso si tienes DevOps funcionando, eso no significa necesariamente que cada desarrollador deba ser un gurú completo de DevOps. Me parece bastante normal que haya uno o dos verdaderos expertos en un grupo determinado de personas, y el resto más o menos. Mientras la carga de trabajo no sea demasiado grande para ese tipo, y mientras logre resumir su conocimiento en scripts, etc., en lugar de construir su propio silo, está bien para mí.

Lo único que no debería estar sucediendo es que el tipo DevOps hace su automatización, y todos los demás hacen todo lo posible para evitar dicha automatización (es decir, pasar la tubería de CI / CD y hacer cosas manualmente en uno de los entornos). Esto, la OMI es lo principal que tiene que parar. Una solución para eso sería presionar mucho para que el enfoque de ganado no sea mascota, es decir, derribar implacablemente máquinas virtuales o contenedores a la izquierda y a la derecha tan pronto como sea posible, y girar nuevos continuamente.

En segundo lugar, por supuesto, todo el mundo necesita estar al tanto de lo que está haciendo la automatización, y al menos en teoría, con un poco de investigación, quizás sea capaz de iniciar la maquinaria de automatización (es decir, si todo funciona desde un commit / push, entonces los desarrolladores deben ser conscientes y estar muy actualizados con el hecho de que habrá cosas que sucederán en segundo plano cuando se comprometan). La canalización de CI (/ CD) debe ser bastante visible y debe ser algo de lo que todos estén constantemente conscientes (es decir, cuando un desarrollador lo rompe).

En tercer lugar, el "individuo", por supuesto, tiene que tener cuidado de no hacer tareas domésticas cotidianas para sus colegas (por ejemplo, crear Dockerfile después de Dockerfile para sus artefactos ...).

En cuarto lugar, las soluciones que el tipo DevOps crea, por supuesto, tienen que ser superiores a los enfoques manuales del pasado de alguna manera medible. En ese caso, debería ser posible para él demostrar sus mejoras; es decir, demuestre cómo las cosas se vuelven más fáciles para todos, o cómo parece imposible introducir errores en las etapas posteriores de la tubería, etc. Si esto no parece posible, entonces el tipo DevOps debe analizar detenidamente Él está haciendo. Si es posible, eso requiere sesiones de bolsa y mucha evangelización en su equipo.

Obviamente, en un entorno tan reacio, es probable que no llegue a una solución de CD totalmente automatizada, o al desarrollo basado en troncales en el corto plazo. Pero no me preocuparía demasiado por ser seleccionado. Él es el experto, y si está haciendo bien su trabajo, todo el equipo mejorará gradualmente.

Y finalmente, si después de años y años de trabajo no hay una mejora visible con sus colegas, siempre es posible buscar otras vías (ya sea dentro o fuera de la empresa). Tener toda esa experiencia de DevOps en su haber es una base excelente para buscar trabajo en estos días ...

Veo muchas respuestas excelentes aquí hablando de DevOps como una cultura, sugerencias sobre cómo trabajar con la administración y ayuda para definir qué hacer y qué no hacer de un equipo o ingeniero de DevOps. Creo que cada uno de ellos es genial, y realmente ilustrativos de muchas respuestas pueden ser 100% correctas, y aún así ser muy diferentes, o incluso completamente ambiguas entre sí ... ¡Eso es DevOps!

Esta respuesta es solo mi perspectiva única desde la experiencia, y puede no ser indicativa de normas o mejores prácticas ...

Pero de lo que se quejaba su colega DevOps es de la naturaleza misma de lo que hace que DevOps sea desafiante y difícil , especialmente cuando se le asigna el rol de ingeniero DevOps, y no simplemente una mentalidad cultural.

Personalmente, me gusta ser un lobo solitario, porque sigo haciendo valiosas contribuciones, pero también puedo establecer mis propios límites, al tiempo que persuado a otros para que se ayuden a sí mismos, ayudándome así a romper los silos de TI.

Algunos silos permanecen intactos , y está bien, es misión de DevOps solucionar eso e intentar hacer que los silos sean lo más insignificantes o invisibles posible.

Es posible que su compañero de trabajo se esté dando cuenta, o aún no se haya dado cuenta, de que no le gusta ser ingeniero de DevOps .

Relativamente hablando, el concepto de devops es nuevo y todavía se define en mi opinión. Actualmente cumplo un rol de ingeniero devops. Para mí, esto significa que facilito y desarrollo las herramientas y procesos utilizados por nuestros equipos de desarrollo y operaciones, liberándolos para centrarse en el producto que genera ingresos para la empresa. Los equipos de operaciones y desarrollo ponen en marcha sus propios servidores y según sea necesario. Solo conecto el CI para nuestros productos, me aseguro de que nuestros procesos tengan sentido y busco qué proceso se puede mejorar / automatizar. Me reúno con todos nuestros departamentos, desde ventas, almacén, desarrolladores y operaciones (control de calidad y gerentes de lanzamiento) para ver qué están haciendo y cómo puedo mejorar su proceso.

Para mí, DevOps significa que el desarrollo y la operación de un sistema de software se convierte en responsabilidad de un equipo, en lugar de equipos de desarrollo y operaciones separados. Esta es una calle de doble sentido. Los mejores equipos están formados por personas "en forma de T " que son expertos en un campo y están familiarizados con varios campos relacionados.

• Se espera que los miembros del equipo con experiencia en operaciones hagan lo que mejor hacen (es decir, operaciones), que enseñen los fundamentos de lo que hacen mejor (es decir, operaciones) a los demás y que aprendan y realicen trabajos en campos relacionados (es decir, tareas de desarrollo).
• Se espera que los miembros del equipo con experiencia en Dev hagan lo que mejor hacen (es decir, Dev), que enseñen los fundamentos de lo que hacen mejor (es decir, Dev) a los demás y que aprendan y realicen trabajos en campos relacionados (es decir, tareas de Ops).

Entonces, para que el ingeniero DevOps se sienta menos como un lobo solitario, invítelo a enseñar a los desarrolladores cómo ejecutar los sistemas, al tiempo que reconoce que él es el experto en cómo diseñar la infraestructura.

Haga que lo invoquen en la arquitectura de alto nivel desde el principio, para que pueda presentar las preocupaciones de su especialidad. (Antes de tener DevOps, nuestros dibujos de arquitectura siempre pasaban por alto "pequeñas cosas" como equilibradores de carga y servidores redundantes. Ahora, esas cosas son parte de los primeros bocetos).

Espere que los desarrolladores tomen algunas de las tareas diarias de rutina de operaciones, tanto para generar redundancia en el equipo como para distribuir los trabajos de "trabajo pesado" de manera justa.

Espere que contribuya al esfuerzo de desarrollo si no hay tareas similares a Ops que hacer. Algunos DevOps que conozco parecen encontrar que la base de datos funciona como una extensión natural de su área de especialización, no estoy seguro de si eso puede generalizarse.

¿Qué se podría hacer para ayudar a los ingenieros de DevOps a sentirse menos como un lobo solitario?

Parafraseando - qué puede hacer un ingeniero DevOps a sí mismo / a sí misma a sentir menos como un lobo solitario?

La falta de cultura y apoyo administrativo es solo una parte de la ecuación. La otra parte es, en mi opinión, que el conocimiento detallado de DevOps a menudo se refiere a contextos complejos y es importante tener consejos y referencias a ejemplos de trabajo.

Por lo tanto, no te sientas como un lobo solitario; participe en comunidades DevOps como esta aquí o grupos específicos de herramientas y GitHub: la sensación es que al menos no es el único lobo solitario ;-)