GNU/Linux >> Tutoriales Linux >  >> Linux

Carreras de administrador de sistemas:la correlación entre los mentores y el éxito

Nota del editor: En este segmento, la reunión de Sudoer, planteamos preguntas a pequeños grupos de profesionales de la industria. Obtiene respuestas y opiniones reales de personas reales (usuarios, operadores, administradores, desarrolladores, etc.), cada uno de los cuales ofrece una perspectiva variada y valiosa a las preguntas relacionadas específicamente con la industria de TI y la administración de sistemas.

La premisa

Por lo general, cuanta más información tenga sobre una situación, más éxito tendrá al manejarla. Lo mismo se puede decir sobre el nivel de experiencia que tiene en el tratamiento de problemas específicos. Esto es lo que me inspiró a explorar la experiencia de otros profesionales de la industria. Tuve varios mentores excelentes a lo largo de los años, y siempre sentí que el tiempo dedicado a aprender de ellos valía la pena exponencialmente. No siempre es una bomba atómica intelectual la que remodela tu conjunto de habilidades. Muchas veces, las lecciones más poderosas están en la sabiduría adquirida con el tiempo. Tener la habilidad para actuar es genial, pero también ayuda saber cuándo y cómo actuar.

Le preguntamos a un grupo de nuestros principales colaboradores sobre sus mentores y el impacto de estas experiencias en sus carreras. Algunos tenían personas específicas en mente; sin embargo, un número igual indicó que un equipo muy unido puede ser tan valioso como una sola fuerza de guía.

La discusión

Joachim Haller (Gerente sénior de proyectos, Capgemini)

A lo largo de mi carrera, he tenido un mentor fantástico y, durante algunos años, cuando tuve momentos muy difíciles, tuve un segundo. Contaré la historia de ambos.

Mi primer mentor surgió cuando estaba trabajando mi año principal como administrador de sistemas para Lotus Notes. Había aprendido a administrar los servidores y las bases de datos a través de los estudios, pero era un novato en lo que respecta a las redes y, a menudo, los ingenieros de infraestructura me decían que la pérdida de conectividad se debía a errores en Lotus Notes. Sabía que tenía que aprender sobre la creación de redes, o siempre terminaría con el extremo corto del palo en estas discusiones. Así que salí y compré un libro de 500 páginas sobre TCP/IP y, sin saberlo, comencé la siguiente etapa de mi viaje como administrador de sistemas. Mi objetivo no era convertirme en administrador de red. Tenía muchas ganas de poder tener discusiones calificadas con los chicos de infraestructura en lugar de ser descartados como una molestia ignorante.

Efectivamente, las cosas cambiaron. Encontré herramientas y métodos para mostrar exactamente lo que estaba mal, dónde salió mal y, en varios casos, por qué había salido mal. Aprendí el sombrío mundo de los cortafuegos y los trucos de los enrutadores inteligentes que jugarían a medida que crecieran las redes y se conectaran nuevos países. Los módems fueron reemplazados por la magia de Internet y surgieron nuevos desafíos de conectividad. Al ponerme en contacto con nuevos administradores de sistemas, aprendí a ser curioso en lugar de un sabelotodo.

Al ser curioso, podía aprender más, comprender mejor las cosas y obtener una perspectiva más amplia de por qué ciertas cosas se hacían de diferentes maneras. Ser curioso también me llevó a hacer preguntas exploratorias; por ejemplo, con frecuencia desafiaba a las personas a explicar las abreviaturas que usaban en las presentaciones y, a menudo, no las sabían, así que las buscábamos juntos. Dejándome guiar por la curiosidad, me he calificado para nuevos roles y responsabilidades, y el diálogo con colegas de otras disciplinas se ha vuelto mucho más interesante. Estoy extremadamente agradecido y espero que la misma curiosidad me acompañe hasta el final de mis días.

[ Consulte el primer artículo de esta serie: Necesidad de conocer las tecnologías para administradores de sistemas junior ]

Mi segundo mentor en realidad no sabía que lo había seleccionado como mi faro guía durante lo que fue un momento muy desafiante y confuso para mí. Me enviaron a Asia para construir la red corporativa y migrar los sistemas de correo electrónico y las herramientas de colaboración que tenían a Lotus Notes. Estaba estacionado en Bangkok con mi familia y tenía 16 países que cuidar. Aunque había estado trabajando con algunos de ellos en línea, era un juego de pelota completamente diferente estar en los palos, mirando un servidor en un gabinete de ducha y teniendo que arreglarlo. Estaba construyendo un centro de datos como parte de la infraestructura global, trabajando en equipos con administradores de sistemas locales. Estos eran tipos que estaban acostumbrados a ser los reyes de la colina, y ahora tuve que degradarlos suavemente para verificar los archivos de registro sin ningún acceso de administrador a los servidores. Además del trabajo técnico práctico, también fui gerente de TI para Asia y, aunque soy una persona muy sociable, tenía mucho que aprender sobre cultura y administración.

Fue entonces cuando conocí a Liam, el gerente de la planta de producción en Singapur. Era un personaje con los pies en la tierra que conocía hasta el último rincón de su enorme planta técnica. Caminaba hasta el patio de comidas local y tomaba su almuerzo, a diferencia de otros gerentes a los que sus secretarias les llevaban el almuerzo al comedor (solo para gerentes). Liam habló con todos y se mostró inflexible en lo que respecta a la seguridad de la tripulación. Era un profesional trabajador con altas exigencias y, sin embargo, había un lado muy humano en todo lo que hacía. Si había algún problema, él estaba allí, en el suelo, hablando con la gente, ayudando, discutiendo, revisando. Todos le tenían el mayor respeto, pero no tenían miedo de hacer oír su voz. La junta ejecutiva lo enviaba a las plantas de producción de todo el mundo cada vez que había que arreglar las cosas o cuando compraban una nueva planta, como había sido el caso en Singapur, donde ya llevaba algunos años.

Luego sucedió:un accidente fatal en una planta cercana. La junta lo llamó y estuvo en el lugar al día siguiente. Cuidó a los familiares, preparó el funeral, presentó sus respetos y de la manera más sincera, se atribuyó la responsabilidad de lo sucedido, aunque no era el encargado cuando ocurrió el horrible incidente. Lo siguiente que hizo fue pedir a los oficiales de seguridad que le proporcionaran una lista completa de todo lo que necesitaba atención en la planta. La planta en cuestión era relativamente pequeña y nunca le había ido particularmente bien en el mercado. Los números rojos habían dado como resultado ahorros que finalmente comprometieron la seguridad del personal. La lista de cosas por arreglar era larga y comenzó a atender metódicamente todos y cada uno de los elementos de línea. Al mismo tiempo, revisó la cartera de productos vegetales y decidió descontinuar algunos productos en favor de otros. Entendía el mercado y sabía qué productos tenían demanda y no requerían transportes de larga distancia. Seis meses después, la planta mostró ganancias Y la seguridad de la tripulación fue de primera categoría. Liam era respetuoso, decidido, informado y curioso. No fue hasta que se jubiló que le dije que había sido mi mentor. Me sonrió y dijo que había sido un buen estudiante.

Damon Garn (Propietario, Cogspinner Coaction, LLC)

En realidad, nunca tuve un solo mentor, per se, pero trabajé con un grupo muy sólido de capacitadores técnicos durante más de 20 años. Entre nosotros, todos teníamos una gran cantidad de experiencia en el aula y conocimiento de TI del mundo real. Nos ayudamos mutuamente a prepararnos para nuevos cursos, nos capacitamos mutuamente a través de nuevas tecnologías e intercambiamos ideas sobre presentaciones exitosas en el aula (tanto en persona como en línea). Era un grupo maravilloso, y todavía nos reunimos periódicamente y nos reímos de los viejos tiempos (como el gerente que habló una y otra vez sobre los beneficios de IPv5).

Contar con un equipo tan bien informado hizo que fuera más fácil asumir nuevos desafíos. Fui el primero de nosotros en comenzar a trabajar con Linux a principios de la década de 2000, por lo que podía usar mi conocimiento para ayudar a los capacitadores de seguridad a medida que avanzaban con varias herramientas de seguridad, como Kali Linux (llamado Backtrack en ese momento). Más tarde, esos mismos muchachos me ayudaron a comprender mejor la configuración de conmutadores y enrutadores de Cisco. Confiar unos en otros hizo que un trabajo difícil fuera más fácil y agradable. No puedo decir que extraño esos días, pero me alegro de haberlos experimentado con personas tan grandiosas.

Nate Lager (Administrador técnico de cuentas, Red Hat)

En mi primera función como administrador real (administrador de red junior, aunque el trabajo real consistía en muchos más sistemas que redes), el administrador senior que estaba allí cuando me contrataron era un tipo muy paciente y servicial. Me encantaría localizarlo hoy y preguntarle qué pensaba realmente de mí cuando era un administrador tan ecológico. Nunca pareció impacientarse o frustrarse con mis habilidades (o la falta de ellas), incluso cuando se trataba de servidores Windows, con los que tenía muy poca experiencia. Él y yo trabajamos juntos durante unos seis a ocho meses, y luego se fue a pastos más verdes. Por lo demás, el ambiente de trabajo allí era bastante pobre, así que no puedo culparlo. Aprendí mucho de él que simplemente no se puede aprender en la escuela:cómo ser un buen administrador, cómo minimizar el cambio, cómo trabajar con clientes, sin mencionar las habilidades técnicas. Mi primera introducción real a la programación provino en gran parte de él. Mi experiencia con él realmente me dio algo sobre lo que reflexionar más adelante en mi carrera cuando ya no era un novato y estaba repartiendo consejos a los nuevos administradores de sistemas.

Hubo una segunda experiencia con mentores que realmente me queda grabada, pero no fue solo una persona. Cuando finalmente dejé ese primer trabajo, pasé a la educación superior, una pequeña universidad de artes liberales. El equipo ya estaba formado por una serie de personas muy capacitadas en redes y sistemas. Ya conocía a algunos de ellos, ya que todos habíamos trabajado juntos en un proveedor local de servicios de Internet, y eso es parte de cómo me enteré del trabajo. Llegué con una riqueza de mi propio conocimiento y experiencia, y en unos pocos años, aprendí mucho más de estas estrellas de rock de TI. Nuevamente, nunca hubo un caso en el que sentí que no podía preguntarle a un tonto pregunta, e incluso mis errores fueron manejados con gracia. Siempre he visto el valor de compartir mi experiencia con los demás, pero mis experiencias al principio de mi carrera realmente me ayudaron a convertirme en la persona que soy hoy.

Joerg Kastning (Administrador de sistemas, Universidad de Bielefeld)

Comencé mi carrera con tres años de formación profesional. Durante este tiempo, aprendí de colegas experimentados todo lo que necesitaba para mis futuros trabajos, incluidas redes, administración de sistemas y gestión de proyectos simples. Mis entrenadores/colegas fueron pacientes y comprensivos, y fue un ambiente muy agradable en el que aumentar mis conocimientos de TI. Debido a que era un aprendiz, mis fallas fueron toleradas, a menos, por supuesto, que las repitiera. Teníamos muchos clientes diferentes de varias industrias en ese entonces, lo que me brindó una gran oportunidad para ampliar mis conocimientos y eventualmente convertirme en administrador de sistemas.

[ También le puede interesar: ¿Cuál es la causa de la lentitud en el avance profesional de los administradores de sistemas Linux? ]

Algunos años más tarde, después de obtener mi licenciatura y comenzar a trabajar para otra empresa, conocí a un chico al que me gusta llamar mi desarrollador favorito y que desde entonces se ha convertido en un buen amigo. Él era (y sigue siendo) un desarrollador, y yo era un administrador de sistemas. Compartimos nuestra experiencia entre nosotros, aprendimos unos de otros y finalmente nos convertimos en DevOps, que era la nueva palabra de moda en tecnología en ese entonces. Había otro chico joven que comenzó como desarrollador al mismo tiempo y que también se convirtió en un gran administrador de sistemas con el tiempo. Hoy los tres trabajamos para diferentes empresas en diferentes países, pero hemos logrado mantenernos en contacto. Y cuando nos reunimos para algún tipo de charla técnica, seguimos aprendiendo unos de otros. Mi esperanza es que les ponga una pequeña sonrisa en la cara cuando lean esto.

Anthony Critelli (Ingeniero de sistemas sénior, Datto Inc.)

Siempre me ha costado encontrar una buena historia de mentoría cuando surge este tema. Tengo la suerte de haber trabajado con grandes personas durante mi carrera, pero no he tenido una sola persona en la que haya confiado como mentor. Sin embargo, cuanto más pienso en esto, más me doy cuenta de que está bien; las lecciones combinadas que me han enseñado muchas personas diferentes son tan valiosas como las que se pueden aprender de una sola persona. Con eso en mente, compartiré una de mis anécdotas favoritas.

Estaba a punto de terminar un turno de noche durante una pasantía en operaciones de TI cuando tuvimos una interrupción repentina de un sistema crítico. Parecía que algún hardware había fallado de una manera extraña que no provocó una conmutación por error. El turno de la mañana (incluido el personal de ingeniería) estaba llegando, así que todos caminamos hacia el centro de datos para inspeccionar el hardware cuestionable. Mientras estábamos parados alrededor de las partes de la computadora esparcidas en un carrito, un gerente senior entró al centro de datos para echar un vistazo. Le sonreí nerviosamente y le dije:"¿Ya te diviertes?" Se rió y dijo:"Anthony, trabajamos en el comercio minorista. Necesitamos arreglar esto, pero nadie se está muriendo porque este sistema no funciona. Todo estará bien".

Siempre la he recordado como una de mis lecciones de TI más valiosas porque contrasta marcadamente con la forma en que normalmente funcionan las organizaciones de TI. Muy, muy pocas industrias operan una infraestructura de TI que realmente debe estar altamente disponible, sin embargo, lanzamos la frase misión crítica como si se aplicara a todo. Los apagones requieren que convoquemos salas de guerra y trabajar todo el fin de semana para averiguar qué está pasando. Cada vez que estoy lidiando con un problema y alguien comienza a ponerse demasiado nervioso, solo recuerdo el realismo tranquilo de ese gerente senior de hace años.

[ ¿Quiere poner a prueba sus habilidades de administrador de sistemas? Tome una evaluación de habilidades hoy. ] 

Resumen

Si ha leído hasta aquí, habrá notado que surgen varios temas de los relatos anteriores, a pesar de que cada colaborador tiene un viaje único. Si tuviera que resumir la información que han compartido estos profesionales, sería esta:

Ser una esponja. Si trabaja con profesionales experimentados, ellos tienen habilidades tangibles para enseñar, pero más que eso, tienen conocimientos de los que usted puede aprender. Trate de no hacer las mismas preguntas repetidamente. Un espacio seguro para hacer preguntas menores es una necesidad para el crecimiento profesional temprano. No es necesario que hable formalmente sobre la tutoría; puede simplemente observar y mostrar interés en aprender, y el resultado será efectivamente el mismo. Finalmente, en situaciones estresantes, mantenga la calma y recurra a las habilidades que conoce. La mayoría de las veces, los problemas críticos se manejan mejor con una aplicación rápida y precisa de la solución adecuada.


Linux
  1. ¿Cuál es la diferencia entre InnoDB y MyISAM?

  2. ¿La diferencia entre [[ $a ==Z* ]] y [ $a ==Z* ]?

  3. ¿La diferencia entre .exrc y .vimrc?

  4. La diferencia entre '$ . Foo' y '$ ./foo'??

  5. Diferencia entre el montón de Java y el montón de C nativo

¿Cuál es la diferencia entre Linux y Unix?

¿Qué es un Hipervisor? ¿Cuál es la diferencia entre el tipo 1 y 2?

¿Cuál es la diferencia entre curl y Wget?

¿Cuál es la diferencia entre strtok_r y strtok_s en C?

¿Cuál es la diferencia entre fsck y e2fsck?

¿Cuál es la diferencia entre unlink y rm?