En mi organización, trabajo con un grupo de personal de NOC, ingenieros junior en ciernes y un puñado de ingenieros senior; todo con un enfoque en Linux. Un paso interesante en la forma en que la empresa genera talento es que existe un camino desde el NOC hasta los rangos superiores de ingeniería. Al considerar el grupo de talentos como relativamente nuevo, 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 concretas y están constantemente inmersos... por ejemplo MySQL, firewalls, almacenamiento SAN, balanceadores de carga...
- Hay otros que son generalistas y pueden navegar en 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 qué tan bien adoptan metodologías de scripting, automatización y gestión de configuración. Por ejemplo, tenemos dos ingenieros que hacen la mayor parte de Amazon.Formación en la nube de AWStrabajo, y otro que se encarga de la mayor parte delMarionetainfraestructura. Quizás una cuarta parte de los ingenieros sean expertos en scripts de shell BASH.
Mirando esto en el contexto de laincreíblementealta demanda deHabilidades de DevOps en el mercado laboralTengo curiosidad por saber 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 fácil de enseñar.
- ¿Cómo mejora un administrador de sistemas sus scripts de shell?
- ¿Todavía hay un lugar para los ingenieros que no pueden o no pueden mantenerse al día con el paradigma DevOps?
- ¿Debemos simplemente suponer que algunas personas quedarán rezagadas a medida que estas tecnologías evolucionen? ¿Está bien?
Respuesta1
Tengo el beneficio de comprender el tamaño y la complejidad de su entorno. Dado que trabaja para un proveedor de nube/hosting, es seguro asumir que tiene una gran cantidad de entornos pequeños y medianos (de 10 a 100 servidores). Ciertamente hay tareas diarias que realiza el jr. ingenieros y personal de NOC que son repetitivos (crear cuentas de usuario, configurar agentes de respaldo, etc.). De manera similar, probablemente haya algunas cosas manuales que hace el Sr. A los ingenieros les gusta instalar ESXi en hardware nuevo o configurar cosas como MPIO o instalar módulos VMware para conjuntos específicos de hardware. Todas estas cosas pueden y deben automatizarse.
Si su personal es capaz de realizar la mayor parte de su carga de trabajo sin automatizar, entonces, en mi opinión, tiene exceso de personal. Cualquier personal de TI que pueda trabajar un día completo y que consista principalmente en procesos manuales no tiene motivación para automatizar. ¿Por qué aprender una nueva habilidad que no se consideranecesarioe incluso podría seraterrador? 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 fracasará y se desmoronará, o comenzará a automatizar casi todo y sobresalir. Ciertamente, los ingenieros senior deberían liderar la carga aquí, y tal vez incluso trabajar con los ingenieros junior y el personal del NOC para automatizar parte de su carga de trabajo. Esto le da al jr. Los ingenieros tienen la oportunidad de tener el marco de muchos scripts con los que trabajar, que pueden modificar para cada inquilino y nueva revisión de hardware según sea necesario. Esto elimina el pensamiento desalentador de "Dios mío, ¿por dónde empiezo?" de la ecuación y les da un impulso para resolver unarealproblema. Lo cual me lleva a mi último punto. Los libros y los ejemplos están muy bien, pero no hay nada que pueda reemplazar la sensación de logro al resolver un problema.actualproblema que enfrentan. Déles un objetivo, como que todos los servidores nuevos para el inquilino x deberían tener ciertos módulos ESXi instalados y luego trabaje con ellos para lograrlo. Luego adapte el script para que funcione en un entorno multiinquilino.
¿Cómo mejora un administrador de sistemas sus scripts de shell?
Pornecesitandoa, como se describe anteriormente.
¿Todavía hay un lugar para los ingenieros que no pueden o no pueden mantenerse al día con el paradigma DevOps?
Claro, hay muchas organizaciones que no pueden o no quieren cambiar a la metodología DevOps. Parecen ser cada vez másaburridoopciones, pero son opciones de todos modos.
¿Debemos simplemente suponer que algunas personas quedarán rezagadas a medida que estas tecnologías evolucionen?
Como ocurre con cualquier tecnología nueva, sí.
tl;dr. Nunca nadie invertirá realmente en aprenderlo hasta que vea su valor. Si pueden realizar sus tareas diarias manualmente, entonces hay exceso de personal y no hay incentivos.
Respuesta2
• ¿Cómo mejora un administrador de sistemas sus scripts de shell?
Práctica, mezclada con impulso. Suena trillado, pero hay que hacerlo.desearpara mejorar, además de practicar. Si realmente no disfrutas con los scripts, puedes verte obligado a hacerlo durante años cuando sea necesario y nunca llegar a ser bueno en ello. Si no lo hacesdesearPara mejorar, podrías sentarte 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ías tener.
Conozco a esas personas que, a pesar de trabajar en TI, se niegan obstinadamente a aprender cualquier tipo de scripting. Pronto no habrá lugar para esas personas en esta industria. Son parte de una generación moribunda.
(No hablo de personas mayores, lo digo en sentido figurado. :PAG)
• ¿Existe todavía un lugar para los ingenieros que no pueden o no pueden mantenerse al día con el paradigma DevOps?
No. Todo lo que hacen puede automatizarse y eventualmente lo será.
Yo diría que, de todos modos, tal vez nunca deberíamos haberlos llamado "ingenieros". Ya es bastante malo que la industria de TI se haya apropiado de la palabra "ingeniero", lo que en mi opinión es un poco insultante para elactualingenieros que pasaron años en programas de educación superior y obteniendo certificaciones legales para poder diseñar puentes, rascacielos, colisionadores de hadrones, etc... esos son losrealingenieros.
Pero hay una similitud... Si quiere llamarse "ingeniero" en la industria de TI, al menos eso significa quecrearcosas. Eresinventivoy conectas los puntos de nuevas maneras en las que nadie había pensado antes. Construyes cosas que nadie más sabía lo valiosas que serían hasta que las creaste.
Si no codifica ni escribe scripts, entonces no hay forma de hacer mucho con las computadoras además de simplemente mantenerlas y tal vez instalar uno o dos paquetes de software. Tal vez coloque un disco duro nuevo en el viejo MSA. Y en ese caso, te llamaría administrador, claro, pero no necesariamente ingeniero. Y yo diría que gran parte de su trabajo corre el riesgo de ser automatizado.
• ¿Debemos simplemente asumir que algunas personas quedarán rezagadas a medida que estas tecnologías evolucionen?
El mercado se adaptará. Puede ser que algunas personas no ganen salarios de seis cifras cuando en realidad no los merecen, lo que sucede bastante en esta industria.
Considero que la creatividad, y no sólo la habilidad de codificar/escribir guiones, es un factor clave. Es esa creatividad la que necesitas decirte a ti mismo: "¡Oh, oye, podría automatizar esto!" y luego la habilidad sólo entra en juego después de eso. Si te encuentras escribiendo algosolodespués de que tu jefe te lo diga, 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.
Respuesta3
¿Cómo mejora un administrador de sistemas sus scripts 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 a escribir scripts que en aprender a cocinar o reparar un automóvil.
¿Todavía hay un lugar para los ingenieros que no pueden o no pueden mantenerse al día con 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 así será, 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 lo es a corto plazo.
¿Debemos simplemente suponer que algunas personas quedarán rezagadas a medida que estas tecnologías evolucionen?
Al ritmo actual como van las cosas, sí. Es probable que la mayoría de ustedes lo estén observando en sus propios lugares de trabajo. Definitivamente deberías estar al día con las ofertas de trabajo y saber qué exige el mercado actualmente. (¿Hay muchas ofertas de trabajo para Hadoop en su área? Aprenda Hadoop). Si no se mantiene al día con el mercado, corre el riesgo de quedarse atrás.
Respuesta4
¿Todavía hay un lugar para los ingenieros que no pueden o no pueden mantenerse al día con el paradigma DevOps?
"devops" es sólo una palabra nueva para algo que los administradores de sistemas han estado haciendo durante décadas.
¿Debemos simplemente suponer que algunas personas quedarán rezagadas a medida que estas tecnologías evolucionen?
Todo lo contrario. A medida que pasa el tiempo, la necesidad de personal técnico aumenta cada vez más. Cualquier persona con algún tipo de conocimiento de ingeniería y habilidades técnicas tendrá un lugar para trabajar.