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

30

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?
ewwhite
fuente
14
Practicas. Intente automatizar todo, construir vms, etc.
Doon
2
@Doon He hecho esto durante 15 años, así que he tenido mucho tiempo para practicar, romper cosas y llegar a donde estoy. Para los ingenieros junior de hoy, y con el nivel de complejidad en algunas de las configuraciones automatizadas existentes, no parece haber suficiente tiempo o un lugar seguro para permitir esa experimentación en muchos entornos.
ewwhite
La tutoría de los adultos mayores, además de una buena documentación y otras prácticas sostenibles (no generar deuda técnica) es una muy buena manera de inculcar El Conocimiento en sus PFY.
mfinni
De hecho, creo que el lugar seguro hoy es en el vms, ya que no necesita todo el hardware físico. Ahora tiempo / etc. sí, eso es escaso :) Pero dada la disponibilidad de hipervisores gratuitos / de bajo costo y la maleabilidad de los sistemas operativos * nix. Puede construir algunas configuraciones bastante complejas para aprender.
Doon
1
Desafío interesante que se aplica a tantas cosas en el mundo de TI. No hay presupuesto para entrenamiento. No hay tiempo ni equipo para practicar. Las máquinas virtuales ayudan mucho, pero la brecha permanece.
Dave M

Respuestas:

9

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.

MDMarra
fuente
3
Leí esto:you'll start automating almost everything *in* excel.
mfinni
Sí, las macros Excel VB de 32 bits son las cosas sobre las que se construyen las nubes. ¿No lo sabías?
MDMarra
2
Tengo la sensación de que puedes estar en lo cierto ...
mfinni
2
Ese conocimiento no debería desaparecer. En lugar de documentar "Haz estos x pasos" en tu wiki interno (o lo que sea), dices "Estas líneas de código x instalan $ stuff" y también comentas mucho tu código en cosas como esta. No realizar scripts debido a la pérdida de conocimiento que puede ocurrir expone una inmadurez potencial en su proceso de documentación. No es una razón para evitar la automatización.
MDMarra
2
@MDMarra ¿Qué es un wiki ?
ewwhite
21

• ¿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.

Ryan Ries
fuente
Muy buena idea. Me temo que la mayoría de las personas en TI son los tipos que se quedan atrás. Yo estoy viendo esto ahora ... Pero también habla de conducir y la motivación ...
ewwhite
7

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

Aaron Copley
fuente
> Si no sigue el ritmo del mercado, corre el riesgo de quedarse atrás <¿No es eso una tautología?
Michael Martinez
5

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.

Daniel Widrick
fuente
Desarrollar habilidades en tecnología X en muchos casos es claro. Hay una ruta de certificación y capacitación para Cisco, VMware, EMC, Red Hat, etc. Es la mentalidad de scripting y las habilidades de desarrollo moderadas las que parecen ser menos entrenables .
ewwhite
55
Las secuencias de comandos son programación (espero que la gente de desbordamiento de pila no venga a comenzar una guerra). Hay una forma de pensar y una forma de ver y abordar problemas en los que no todos serán buenos. 'Enseñar la mentalidad de scripting' es lo que la gente espera obtener de la práctica. ... Y 'habilidades de desarrollo moderado' es lo suficientemente genérico como para no significar nada. ---- En cuanto a la programación de enseñanza, mire las universidades del área que ofrecen clases de programación de introducción. Una clase temprana de Ciencias de la Computación puede recorrer un largo camino en la enseñanza de "mentalidad".
Daniel Widrick
3
Demonios, UMass Lowell tiene cursos de "Bash Scripting" y "Administración de Unix / Linux". Los tomé a los dos. Enseñado por cangrejos de la vieja escuela que sin duda querían mostrar sus perfiles de emacs. (Clases en línea, así que simplemente estoy asumiendo la barba
gris
@mfinni no tenía ni idea! :)
ewwhite
Estoy trabajando en el programa UML BS in Information Technology en este momento. Todo en línea, desde que me transfirí en un AS en CompSci, con un año de primer año de ciencias de laboratorio, Calc, etc.
mfinni
1

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

Michael Martinez
fuente