¿Cómo puede un administrador de Linux mejorar sus habilidades de scripting y automatización de shell?

En mi organización, trabajo con un grupo de personal NOC, ingenieros junior incipientes y un puñado de ingenieros senior; todo con un enfoque en Linux. Un paso interesante en la forma en que la compañía aumenta el talento es que hay un camino desde el NOC hasta los niveles superiores de ingeniería. Al ver el grupo de talentos como un recién llegado relativo, veo que hay una división en los conjuntos de habilidades que tiende a crecer con el tiempo ...

• Hay ingenieros que conocen bien una o varias tecnologías particulares y están constantemente inmersos ... por ejemplo, MySQL, firewalls, almacenamiento SAN, equilibradores de carga ...
• Hay otros que son generalistas y pueden navegar por múltiples tecnologías.
• Todos aprenden suficiente Linux (comandos, procesos) para hacer lo que necesitan y usan a diario.

Un factor diferenciador entre algunos miembros del personal es cuán bien adoptan las metodologías de administración de scripts, automatización y configuración. Por ejemplo, tenemos dos ingenieros que realizan la mayor parte del trabajo de Amazon AWS CloudFormation , y otro que maneja la mayor parte de la infraestructura de Puppet . Tal vez una cuarta parte de los ingenieros son expertos en secuencias de comandos de shell BASH.

Mirando esto en el contexto de la increíblemente alta demanda de habilidades de DevOps en el mercado laboral , tengo curiosidad de cómo otras organizaciones fomentan el desarrollo de estas habilidades y hacen crecer su talento interno. Las secuencias de comandos no parecen un concepto particularmente enseñable.

• ¿Cómo mejora un administrador de sistemas su script de shell?
• ¿Todavía hay un lugar para los ingenieros que no pueden / no pueden mantenerse al día en el paradigma DevOps?
• ¿Debemos simplemente asumir que algunas personas se quedarán atrás a medida que estas tecnologías evolucionen? Esta bien?

Tengo la ventaja de comprender el tamaño y la complejidad de su entorno. Dado que trabaja para un proveedor de cloud / hosting, es seguro asumir que tiene una gran cantidad de entornos pequeños y medianos (10-100 servidores). Ciertamente, hay tareas diarias que realiza el jr. ingenieros y personal NOC que son repetitivos (crear cuentas de usuario, configurar agentes de respaldo, etc.). Del mismo modo, probablemente hay algunas cosas manuales que hace el sr. A los ingenieros les gusta instalar ESXi en un nuevo hardware o configurar cosas como MPIO o instalar módulos VMware para conjuntos específicos de hardware. Todas estas cosas pueden y deben ser automatizadas.

Si su personal es capaz de llevar a cabo la mayor parte de su carga de trabajo sin automatizar, entonces, en mi opinión, tiene demasiado personal. Cualquier personal de TI que pueda trabajar un día completo que consista principalmente en procesos manuales no tiene motivación para automatizar. ¿Por qué aprender una nueva habilidad que no se considera necesaria e incluso puede dar miedo ? Después de todo, la necesidad es la madre de la innovación.

Entonces, en algún momento de su organización, crecerá hasta un tamaño en el que se tambaleará y se desmoronará, o comenzará a automatizar casi todo y sobresalir. Ciertamente, los ingenieros superiores deberían liderar la carga aquí, y tal vez incluso trabajar con los ingenieros junior y el personal de NOC para automatizar parte de su carga de trabajo. Esto le da al jr. Los ingenieros tienen la oportunidad de tener el marco de trabajo de muchos scripts para trabajar, que pueden ajustar para cada inquilino y una nueva revisión de hardware según sea necesario. Esto elimina el pensamiento desalentador de "Oh, Dios mío, ¿por dónde empiezo?" de la ecuación y les da un buen comienzo para resolver un problema real . Lo cual me lleva a mi último punto. Los libros y los ejemplos son buenos y buenos, pero hayproblema que enfrentan. Déles un objetivo, como todos los nuevos servidores para el inquilino x deben tener ciertos módulos ESXi instalados, y luego trabajar con ellos para lograrlo. Luego, adapte la secuencia de comandos para que funcione en un entorno multiinquilino.

¿Cómo mejora un administrador de sistemas su script de shell?

Al necesitarlo , como se describió anteriormente.

¿Todavía hay un lugar para los ingenieros que no pueden / no pueden mantenerse al día en el paradigma DevOps?

Claro, hay muchas organizaciones que no pueden o no cambiarán a la metodología DevOps. Parecen ser opciones cada vez más aburridas , pero no obstante son opciones.

¿Debemos simplemente asumir que algunas personas se quedarán atrás a medida que estas tecnologías evolucionen?

Como con cualquier tecnología nueva, sí.

tl; dr Nunca tendrás a nadie que realmente invierta en aprenderlo hasta que vea el valor en él. Si pueden realizar sus tareas diarias de forma manual, entonces está sobrecargado de personal y no hay incentivos.

• ¿Cómo mejora un administrador de sistemas su scripting de shell?

Práctica, mezclada con impulso. Suena trillado, pero tienes que querer mejorar, además de practicar. Si realmente no disfruta de las secuencias de comandos, puede verse obligado a hacerlo durante años cuando sea necesario y nunca ser bueno en eso. Si no quiere mejorar, puede sentarse al lado del mejor guionista del mundo todos los días en el trabajo y no adquirir una fracción de la habilidad que podría tener.

Conozco a esas personas que, a pesar de trabajar en TI, se niegan obstinadamente a aprender cualquier tipo de script. Pronto no habrá lugar para esas personas en esta industria. Son parte de una generación moribunda.

( No estoy hablando de personas mayores, lo digo en sentido figurado.: P )

• ¿Todavía hay un lugar para los ingenieros que no / no pueden mantenerse al día en el paradigma DevOps?

No Todo lo que hacen puede ser y eventualmente será automatizado.

Yo diría que tal vez nunca deberíamos haberlos llamado 'ingenieros' de todos modos. Ya es bastante malo que la industria de TI se apropió de la palabra 'ingeniero' por nosotros mismos, que en mi opinión es una especie de insulto a los actuales ingenieros que los años pasados en programas de educación superior y obtener certificaciones legales para que puedan diseñar puentes, rascacielos, colisionadores de hadrones , etc ... esos son los verdaderos ingenieros.

Pero hay una similitud ... Si quieres llamarte a ti mismo un "ingeniero" en la industria de TI, eso al menos significa que creas cosas. Eres inventivo y conectas los puntos de formas nuevas en las que nadie había pensado antes. Construyes cosas que nadie más sabía lo valioso que sería hasta que lo hicieras.

Si no codificas ni escribes, entonces no hay forma de que hagas mucho con las computadoras además de mantenerlas, y tal vez instalar un paquete de software o dos. Tal vez arroje un nuevo disco duro al viejo MSA. Y en ese caso, te llamaría administrador, claro, pero no necesariamente ingeniero. Y diría que gran parte de su trabajo está en peligro de ser automatizado.

• ¿Debemos suponer que algunas personas se quedarán atrás a medida que evolucionen estas tecnologías?

El mercado se adaptará. Puede ser que algunas personas no ganen salarios de 6 cifras cuando en realidad no los merecen, lo que sucede bastante en esta industria.

Creo que la creatividad, y no solo la habilidad de codificación / scripting, es un factor clave. Es esa creatividad la que tienes que decirte a ti mismo, " ¡Oh, oye, podría automatizar esto! " Y luego la habilidad solo entra en juego después de eso. Si te encuentras escribiendo algo solo después de que tu jefe te lo diga, entonces es posible que no tengas ese impulso o esa creatividad de la que estaba hablando ... y esas son dos cualidades que son muy difíciles, tal vez imposibles de enseñar.

¿Cómo mejora un administrador de sistemas su script de shell?

¿Cómo se puede mejorar en algo? Lea libros, asista a clases y luego aplique los principios aprendidos. (O una combinación de los métodos). Esto se simplifica demasiado intencionalmente ya que no hay nada especial en aprender las secuencias de comandos sobre aprender a cocinar o cómo reparar un automóvil.

¿Todavía hay un lugar para los ingenieros que no pueden / no pueden mantenerse al día en el paradigma DevOps?

Esto es difícil de responder dentro del alcance de este sitio (donde existe el requisito de respuestas claras / definidas a las preguntas formuladas). Podemos predecir que lo hará, pero hay problemas con el modelo DevOps. Siento que es muy difícil para una persona ser extremadamente competente en ambas disciplinas. El ahorro de costos de un empleado 2 por 1 es muy atractivo para las empresas en este momento, pero es difícil decir si esta tendencia llegó para quedarse. Ciertamente es a corto plazo.

¿Debemos simplemente asumir que algunas personas se quedarán atrás a medida que estas tecnologías evolucionen?

Al ritmo actual de cómo van las cosas, sí. La mayoría de ustedes probablemente lo estén observando en sus propios lugares de trabajo. Definitivamente debe mantenerse al día con las ofertas de trabajo y saber lo que el mercado está demandando actualmente. (¿Hay muchas ofertas de trabajo para Hadoop en su área? Aprenda Hadoop). Si no se mantiene al día con el mercado, se arriesga a quedarse atrás.

Generalmente, no se envían ingenieros junior a un entorno de producción complejo que es de misión crítica. Tienes ingenieros superiores para eso. Se debe permitir que los rangos junior trabajen en entornos limitados de desarrollo / prueba.

Si necesita un ingeniero para Tecnología X y desea desempeñar el papel internamente, encuentre a alguien dispuesto a aprenderlo, encuentre capacitación estructurada y combine los dos.

Averigua qué habilidades necesitas en un departamento. Encuentra a alguien dispuesto a aprenderlos. Enseñar / repartir dinero para el entrenamiento.

¿Todavía hay un lugar para los ingenieros que no pueden / no pueden mantenerse al día en el paradigma DevOps?

"devops" es solo una nueva palabra para algo que los administradores de sistemas han estado haciendo durante décadas.

¿Debemos simplemente asumir que algunas personas se quedarán atrás a medida que estas tecnologías evolucionen?

Todo lo contrario. A medida que pasa el tiempo, solo hay una necesidad cada vez mayor de personal técnico. Cualquier persona con algún tipo de conocimiento de ingeniería y habilidades técnicas tendrá un lugar para trabajar.