¿Qué significa para usted el término "administrador de sistemas" o "administrador del sistema"? ¿Qué hace un administrador de sistemas? ¿Cómo sabes que eres uno?
Las preguntas existenciales como esta rara vez tienen respuestas concretas, y las respuestas que se presentan pueden ser bastante fluidas. Las respuestas también son significativamente diferentes para diferentes personas y dependen de su experiencia laboral.
¿Eres administrador de sistemas?
En mi libro, “La filosofía de Linux para administradores de sistemas , Intento responder a la última pregunta. Creé esta breve lista para ayudarlo a determinar si es un administrador de sistemas. Podrías ser un administrador de sistemas si:
- Crees que mis libros pueden ser una lectura divertida.
- La gente te pide con frecuencia que los ayudes con sus computadoras.
- Revisas los servidores todas las mañanas antes de hacer cualquier otra cosa.
- Usted escribe scripts de shell para automatizar incluso tareas simples.
- Usted comparte sus scripts de shell.
- Usted licencia sus scripts de shell con una licencia de código abierto.
- Sabes lo que significa código abierto.
- Usted documenta todo lo que hace.
- Ha pirateado el enrutador inalámbrico para instalar el software de Linux.
- Te resulta más fácil interactuar con las computadoras que con la mayoría de los humanos.
- Entiendes :(){ :|:&};:
- Piensas que la línea de comandos es divertida.
- Te gusta tener el control total.
- Eres root.
- Siempre dices "no" cuando alguien pregunta si se puede hacer algo o no.
- Después de discutir y descubrir lo que la persona realmente quiere lograr, sabe que puede hacerlo en 30 segundos con un script de shell que ya ha escrito, pero le dice que pasarán "unos días" antes de que pueda llegar a eso.
- Entiendes la diferencia entre "gratis como en la cerveza" y "gratis como en el habla" cuando se aplica al software.
- Ha instalado una computadora en un gabinete de rack.
- Ha reemplazado el ventilador de refrigeración estándar de la CPU por uno que disipa más calor.
- Usted compra las piezas y construye sus propias computadoras.
- Usas refrigeración líquida para tu CPU.
- Instalas Linux en todo lo que puedes.
- Tienes una Raspberry Pi conectada a tu televisor.
- Utilizas una Raspberry Pi como cortafuegos para tu red doméstica.
- Usted ejecuta sus propios servidores de correo electrónico, DHCP, NTP, NFS, DNS y/o SSH.
- Ha pirateado la computadora de su hogar para reemplazar el procesador por uno más rápido.
- Ha actualizado el BIOS en una computadora.
- Dejas las cubiertas fuera de tu computadora porque reemplazas los componentes con frecuencia.
- El enrutador proporcionado por su ISP está en modo de "paso a través".
- Utiliza una computadora con Linux como enrutador.
Entiendes la idea. Podría enumerar muchas más cosas que podrían convertirlo en un administrador de sistemas, pero habría cientos de elementos. Estoy seguro de que puede pensar en muchos más que se aplican a usted.
Esa lista es sobre usted como alguien que hace todas las cosas de administrador de sistemas en lugar de una definición real. Pero, ¿existe realmente una definición única que sirva para todos? Mi propia experiencia dice que los administradores de sistemas no se pueden definir fácilmente.
Mi historia
Trabajé para el gobierno de mi estado natal durante unos cinco años, contratado para mantener y hacer una reescritura casi completa de un conjunto entrelazado de programas Perl existentes. Había alrededor de veinticinco de estos programas ejecutándose en una pequeña computadora de escritorio Intel. Estos programas generaron páginas web CGI basadas en datos almacenados en archivos planos. Estas páginas web eran la interfaz de administración para el sistema de correo electrónico estatal que abarcaba varias agencias grandes de todo el estado. El propio sistema de correo electrónico se ejecutaba en varios servidores de Sun Microsystems.
Dado que esto comenzó como un proyecto piloto, solo se usó una computadora para mi parte del proyecto. Esa computadora era una vieja desechada de otro departamento cuando fue "dotada" para el proyecto y configurada en mi escritorio. También sirvió como mi estación de trabajo personal. No recuerdo las especificaciones exactas, pero tenía un procesador Pentium original de 32 bits que funcionaba a 33 MHz con 16 MB de RAM y dos discos duros. Ejecutó una versión anterior de Red Hat Linux.
Se estaba volviendo imposible mantener estos programas para agregar nuevas funciones y localizar y corregir errores debido a la complejidad del código. Mi tarea asignada fue corregir los errores y agregar alguna funcionalidad adicional a estos programas.
Cuando comencé a tratar de dar sentido a la complejidad del código, quedó claro que mi primera prioridad tenía que ser simplificar el código. Después de comentar profusamente el código y corregir algunos errores a medida que avanzaba, comencé a recopilar algunos códigos que se habían insertado en dos o más de estos programas y los recopilé en las bibliotecas de Perl. Esto facilitó la resolución de problemas porque solo tenían que solucionarse en un lugar:la biblioteca. Enderecé otro código, simplificando las rutas de ejecución comunes.
Pero también era responsable del mantenimiento de los sistemas más antiguos, tanto de hardware como de software. Instalé actualizaciones, actualicé a un par de versiones más nuevas de Red Hat Linux a lo largo de los años y resolví una buena cantidad de problemas de configuración de Linux causados por la falta de conocimiento por parte del administrador anterior. Observé los registros y el rendimiento del sistema continuamente y realicé ajustes en la optimización con la frecuencia necesaria.
También gestioné la seguridad de este host. Hice todo esto con solo esa computadora, sin respaldo, en vivo, en línea, con clientes que aún usan el sitio web. Finalmente, convencimos a la gerencia de que necesitábamos una segunda computadora que pudiéramos usar para un entorno de prueba. Fueron tiempos divertidos.
Gran empresa
Trabajé durante unos cinco años en una gran empresa, bastante tarde en mi carrera. Ese fue un trabajo divertido en parte porque tenía dos componentes relacionados.
Una parte del trabajo era escribir casos de prueba para dispositivos basados en Linux que la empresa estaba desarrollando. Usé Tcl/Expect, que se integró bien con la infraestructura de prueba que ya estaba instalada. Como evaluador, escribí código durante una buena parte del tiempo, pero luego también tuve que probar el conjunto de pruebas y luego ejecutar las pruebas reales.
La segunda parte de este trabajo fue como asistente del administrador de laboratorio de varias filas de bastidores que componían nuestro laboratorio de pruebas, aproximadamente la mitad de mi tiempo. Allí se encontraban equipos de todo tipo, desde servidores Linux 1U hasta enormes enrutadores que ocupaban un rack completo y docenas de hosts Linux y Solaris.
Mis tareas como administrador del laboratorio me obligaron a pedir nuevos equipos, montarlos y cablearlos cuando llegaron, e instalar Linux en todas las cajas de Intel. No teníamos la responsabilidad de la administración de redes en el laboratorio, pero los distintos departamentos trabajaron bien juntos y el grupo de redes nos brindó su propia automatización. Completamos un formulario web solicitando una dirección IP de la lista administrada por DHCP de direcciones estáticas y una entrada de DNS, configurando esos dos elementos de inmediato y luego pudimos continuar con nuestras instalaciones de Linux.
Para acelerar la instalación de la configuración especial de Red Hat Linux, escribí un script para automatizar ese proceso. Escribí sobre eso en un artículo publicado en Linux Magazine en junio de 2008. Ese artículo ahora está disponible en mi sitio web personal: Complete Kickstart y en Linux Today.
Usando estos procedimientos desarrollados con los otros grupos, pudimos desempacar, colocar en rack, cablear e instalar Linux en seis a ocho nuevos servidores en un día.
También creé varias sesiones de capacitación de Lunch-n-Learn para ayudar a que otros empleados se familiaricen con Linux.
Silos
El último trabajo W-2 que tuve como administrador de sistemas fue durante aproximadamente un año en una organización en particular que es un ejemplo fantástico del fracaso de la metodología tradicional de "equipo" llevada al extremo. Lo peor es que también era un viaje diario horrible.
En esta organización, que permanecerá sin nombre, la gerencia había creado silos muy estrechos y muy altos para contener todo.
Había varios equipos, el equipo de Unix, el equipo de aplicaciones, el equipo de red, el equipo de hardware, el equipo de DNS, el equipo de rack, el equipo de cable, el equipo de energía, prácticamente cualquier equipo que se pueda imaginar. Y los procedimientos eran alucinantes. Por ejemplo, uno de mis proyectos fue instalar Linux en varios servidores que se utilizarían para varios aspectos del sitio web de la organización. El primer paso fue solicitar los servidores, pero la solicitud tardó semanas en abrirse camino a través de la burocracia administrativa.
Una vez entregados los servidores, el equipo de Unix los colocaría en el laboratorio de instalación e instalaría el sistema operativo. Tuvimos esa parte muy bien. Pero primero, tuvimos que solicitar una dirección IP. No pudimos hacer eso antes de entregar los servidores porque la solicitud de una dirección IP requería los números de serie de los servidores y las direcciones MAC de las NIC.
El problema aquí era que cada silo tenía que tener un Acuerdo de Nivel de Servicio (SLA) con todos los demás silos y el tiempo de respuesta definido por el SLA era un mínimo de dos semanas. Y cada silo no tardó menos en responder que el especificado en el SLA. Sin embargo, no pudimos obtener la dirección IP hasta que se asignó una ubicación de rack en la sala de servidores porque las direcciones IP se asignaron por rack y ubicación en el rack. Así que tuvimos que enviar una solicitud para una asignación de bastidor y esperar dos semanas para que se proporcionara.
Entonces, el siguiente paso después de obtener la dirección IP fue enviarla al silo que manejaba la configuración de DHCP. Luego fue al menos dos semanas después de obtener la dirección IP que tuvimos que esperar antes de que se configurara el DHCP.
Solo cuando los datos de configuración de red para el servidor se configuraron en el servidor DHCP, se pudo enviar la solicitud para mover el servidor de nuestro rack a la sala de servidores. Otro cambio de dos semanas.
Después de que se aprobó la solicitud de traslado, y solo después, pudimos enviar una solicitud para instalar la computadora en el bastidor. Una vez que se completó la instalación, pudimos enviar la solicitud para cablear el servidor con red y energía. Cuando se completó, pudimos enviar una solicitud para encender el servidor.
Excepto para instalar el sistema operativo, no pudimos tocar el servidor. Ni siquiera se nos permitía entrar en la sala de servidores. Nunca.
No hace falta decir que tomó meses instalar cada servidor y ponerlo en funcionamiento y listo para que los equipos de producción se hicieran cargo. Podría continuar con muchas más formas en las que este lugar fue un desastre funcional, pero creo que entiendes la idea. Sus equipos eran principalmente feudos políticos protegidos por silos impenetrables.
Autoempleo y consultoría
A lo largo de los años, he tenido dos empresas propias que utilicé para consultar mientras estaba entre otros trabajos. Esto evitó agujeros en mi currículum que generarían preguntas durante las entrevistas. Tuve algunos buenos clientes durante este tiempo y aprendí mucho.
En este rol, hice casi todo, desde planificar nuevas instalaciones hasta capacitar y realizar actualizaciones. Cobré tarifas escandalosas para pasar unos minutos restableciendo la contraseña de root en algunos sistemas Linux en más de un caso. Parece que los jefes de pelo puntiagudo tienden a despedir a los administradores de sistemas sin comprender la necesidad de una transición fluida durante la cual obtendrían todas las contraseñas.
Jubilación:una especie de
Ahora supuestamente estoy jubilado, pero parece que estoy más ocupado que nunca. Escribo artículos y libros y tengo algunas computadoras con Linux a las que dar soporte.
He mantenido entre cuatro y diez computadoras que me pertenecían a mí o a una de mis empresas en el laboratorio de mi propia casa. Por supuesto, todos ejecutan Linux. Actualmente, tengo 12 computadoras en el laboratorio de mi casa, pero eso incluye tres en las que estoy trabajando en varios proyectos para mi iglesia. También administro las computadoras y la red en mi iglesia y para un par de amigos a quienes convencí de probar Linux.
Entonces, soy el administrador de sistemas para la mayoría de estas computadoras, soporte completo de hardware y software para las demás. También brindo capacitación para varias personas en mi puesto actual.
Conclusión
Un administrador de sistemas es muchas cosas, a veces todas al mismo tiempo.
Mi experiencia ha recorrido toda la gama. Nunca he tenido un trabajo que consideraría un trabajo de administrador de sistemas "puro". Cada organización tiene necesidades únicas y, la mayoría de las veces, el administrador del sistema se ofrece como voluntario para desempeñar funciones que nunca se mencionan en la entrevista o en la descripción del trabajo. Los administradores de sistemas tienden a tener el conocimiento y las habilidades para hacer casi todo lo necesario. Las personas con las que trabajamos y para las que generalmente lo entienden, por lo que nos imponen esas tareas difíciles.
Me gusta.