Un día en la vida de un administrador de sistemas de ingeniería de calidad

Permítanme comenzar diciendo que no fui contratado ni capacitado para ser administrador de sistemas. Pero estaba interesado en el lado de los sistemas de cosas como la virtualización, la nube y otras tecnologías, incluso antes de comenzar a trabajar en Red Hat. Soy un ingeniero de software sénior en pruebas (ingeniería de calidad de software), pero Red Hat, al estar en una posición tan única porque sus productos son utilizados principalmente por administradores de sistemas (o personas con responsabilidades laborales similares) y la mayoría de los productos de Red Hat están enfocados principalmente en el nivel del sistema backend en lugar del nivel de la aplicación del usuario. Nuestros esfuerzos de prueba incluyen la interacción de rutina con la virtualización de Red Hat, OpenStack, Ansible Tower y la infraestructura hiperconvergente.

Cuando me contrataron, solo me enfocaba en probar Red Hat CloudForms, que es un software de administración para los entornos antes mencionados. Pero cuando uno de nuestros antiguos ingenieros de software sénior se fue para asumir otro puesto en Red Hat, vi una oportunidad que me atrajo. Para entonces ya lo estaba ayudando y aprendiendo las tareas de administrador de sistemas, así que después de revisar mi progreso e interés, era un sucesor natural para el trabajo desde la perspectiva de mi equipo. Y como resultado, terminé convirtiéndome en un administrador de sistemas que trabaja en parte como ingeniero de software en pruebas.

Con este contexto, les explicaré cómo es mi día.

Todos los días, cuando entro, reviso el tablero de nuestro sistema de monitoreo para ver si alguno de nuestros 50 hosts principales se está quejando de las más de 490 verificaciones en curso. Si algo está mal, trato de arreglarlo o delego la tarea a alguien que pueda arreglarlo por mí. Cuando las cosas no se quejan, trato de mejorar nuestra configuración actual, escribir una automatización más completa para monitorear la infraestructura y pensar en cómo automatizar la reparación de las cosas cuando están rotas o salen mal.

Lo que quiero decir con una queja es realmente una alerta enviada por nuestra herramienta de monitoreo sobre el estado de un host o servicio determinado. Dado que vivimos a la vanguardia de la tecnología de Red Hat, siempre necesitamos que nuestros sistemas estén actualizados con las últimas versiones (principalmente internas) de Red Hat Virtualización y el software de nube de Red Hat.

Parte de este proceso ya se ha automatizado y estoy tratando de aprovechar la automatización para volver a implementar las cosas. Pero como señalé en una publicación anterior sobre la infraestructura como código, mi código puede fallar cuando se ejecuta en nuevas compilaciones, y necesito depurar y corregir la automatización cuando eso sucede. Parte de mi tiempo, a pesar de nuestra automatización, lo desperdician los miembros de mi equipo creando recursos y olvidándose de limpiar. Tenemos diferentes secuencias de comandos de limpieza para eliminar elementos, pero si los recursos no coinciden con las condiciones de limpieza, terminamos teniendo que eliminarlos manualmente.

Cuando no sucede nada de lo anterior, a veces encontramos errores o problemas que antes eran desconocidos y requieren una solución por parte del equipo de ingeniería para que los sistemas vuelvan a funcionar. En este caso, debo comprometerme con las personas interesadas para:

  • Demuestre que el problema es reproducible y que de hecho es un error.
  • Manténgase en contacto con ingeniería para preparar una solución y aplicar actualizaciones.
  • Utilice cualquier solución alternativa, si la hay, para evitar que los sistemas se vuelvan locos.

De vez en cuando, como puede adivinar, nos encontramos con un mal funcionamiento del hardware o limitaciones que debemos comprender y corregir cuidadosamente. Este problema incluye, pero no se limita a:

  • Diseñar y comprender los recursos materiales de que disponemos.
  • Determinar nuestras necesidades.
  • Piensa en un diseño.
  • Verificación de la viabilidad del diseño con el equipo del centro de datos.
  • Hable con los proveedores para comprar nuevos equipos.
  • Hable con soporte cuando las cosas no van bien.

De vez en cuando también tengo que educar a la gente sobre qué hacer y qué hacer con nuestros sistemas, ya que no necesariamente todos saben qué hace cada uno y por qué están diseñados y utilizados de la forma en que están. Si me queda tiempo, después de todo esto, trato de dedicarlo a automatizar pruebas para CloudForms usando Python y Selenium.

Lo que me gusta de mi trabajo es doble. Una de las razones es que nuestra infraestructura es interna y no requiere un buscapersonas, ya que las personas a menudo pueden esperar a que inicie sesión para arreglar las cosas. La otra razón es que mi equipo está repartido por todo el mundo, por lo que puedo confiar en otros (a pesar de ser el único administrador de sistemas) para tratar de solucionar problemas o crear soluciones provisionales mientras tanto.

En la ingeniería de calidad de CloudForms de Red Hat, mantenemos muchas infraestructuras ensambladas a partir de diferentes productos internos. Que yo sepa, ningún otro equipo tiene tanta diversidad en su infraestructura. Muchos equipos solo necesitan implementar su propio producto, o quizás uno o dos más. Esta distinción me dio muchas oportunidades de aprender.

Con todo, si las cosas no funcionan, la gente seguramente sabrá tu nombre y te encontrará. Además, cualquier falla en el sistema puede hacer que mi equipo pierda objetivos, retrase las fechas de lanzamiento y resulte en una pérdida de ingresos para Red Hat. Y cuando lanzamos las cosas a tiempo, puedo ver que he tenido un impacto al asegurarme de que nuestros sistemas estén disponibles las 24 horas del día, los 7 días de la semana.

La administración del sistema es una posición en la que tiene un gran poder con una gran responsabilidad. Me gusta pensar que lo uso sabiamente.

Artículos de interés

Subir