LinuxParty

Ser un administrador de Unix o Linux tiende a ser un extraño tipo de trabajo: a menudo se pasan gran parte de su jornada de trabajo vagando (que no vagueando) por su cuenta, dedicando una gran cantidad de tiempo haciendo cosas aparentemente no específicas de sus tareas, marcadas por momentos de pánico donde tiene que hacer algo muy importante y de inmediato. Sandra Henry-Stocker, una veterana administradora de sistemas, ofrece 7 sugerencias sobre cómo estructurar su vida profesional si tiene este trabajo. Su consejo incluye el establecimiento de prioridades, a sabiendas de sus herramientas, y proporcionando explicaciones a los co-trabajadores a los que ayudan. "¿Qué hábitos has encontrado eficaces para los administración del sistema?

Hábito 1: No espere a que los problemas le encuentren

Una de las mejores maneras de evitar las situaciones de emergencia que pueden ocuparle el día entero, es estar alerta a los problemas en su inicio. He encontrado que la instalación de scripts en los servidores que notifican entradas de registro inusuales, comprueban las estadísticas de rendimiento y espacio de disco, errores de aplicación informe o procesos que faltan, y me envían por correo electrónico reportes cuando algo parece "fuera" de lo que sería un valor normal. Los riesgos son que cada vez con mayor frecuencia este tipo de correo no se lee y tienden a almacenarse en la carpeta de spam. No darse cuenta de que los mensajes NO llegan, no debería ser diferente a notar que su equipo de 12 personas o más no ha aparecido para una reunión.

Puede que te interese:

Biblioteca / Librería de Scripts Linux

 Debe ser proactivo, es probable detectar una serie de problemas mucho antes de que se conviertan en cortes y notar usted antes que los usuarios los problemas y ya no pueden hacer su trabajo.

También es muy beneficioso si usted tiene los recursos necesarios para planificar el desastre. ¿Se puede conmutar por error un servicio si uno de los servidores primarios se cae? ¿Se puede confiar en las copias de seguridad para reconstruir un entorno de servidor de forma rápida? ¿Prueba las copias de seguridad periódicamente para asegurarse de que están completas y utilizables? Tener preparados planes de recuperación de desastres para los servicios críticos (por ejemplo, el servicio de correo, con un servidor de repuesto en el centro de datos y así otros muchos

Hábito 2: Conozca sus herramientas y sus sistemas

Probablemente la mejor manera de reconocer que uno de los servidores está en problemas es saber como se ve el servidor en condiciones normales (por ejemplo lo que registran ficheros como /var/log/messagess). Si un servidor normalmente utiliza el 50% de su memoria y comienza a utilizar el 99%, usted va a querer saber que produce esa diferencia. ¿Qué proceso se está ejecutando ahora que no estaba antes? ¿Qué aplicación está utilizando más recursos de lo habitual?

Estar familiarizado con un conjunto de herramientas para buscar los problemas de rendimiento, uso de memoria, etc que utiliza y animar a otros a usar el comando sar de manera rutinaria, tanto para ver lo que está sucediendo ahora en un sistema como para hacer una mirada restrocpectiva en el tiempo para tener una idea cuando comenzaron los problemas. Uno de los scripts que tengo en mis servidores más críticos me envía datos suficientes para visualizarlos de forma rápida.

Es también una buena idea practicar todos los comandos que puede necesitar para ejecutar cuando se produce un problema. ¿Se puede construir un comando find que le ayuda a identificar los archivos sospechosos, archivos de gran tamaño, los archivos con problemas de permisos? Saber utilizar un buen depurador también puede ser un regalo del cielo cuando se necesita para analizar un proceso. Saber cómo controlar las conexiones de red también puede ser una cosa importante a hacer cuando sus sistemas podrían ser objeto de ataques.

Hábito 3: Priorizar, priorizar, establecer prioridades

Poner primero lo primero es algo que debe realizarse, como forma de organizar su trabajo, pero a veces la selección de lo que se califica como "un problema prioritario" y es el "primero" puede ser más difícil de lo que parece. Para priorizar adecuadamente sus tareas, se debe considerar el valor que se deriva de la revisión. Esto implica a menudo la cantidad de personas afectadas por el problema, pero también implica que se ve afectado. Su CEO podría ser poner el valor 1.000 cuando afecta a las personas en su equipo de desarrollo. Sólo usted (o su jefe) puede tomar esta decisión. También es necesario tener en cuenta cuánto afecta.

Otro elemento crítico en la priorización de las tareas es el tiempo que un problema se tardará en resolver. A menos que el problema en el que estoy trabajando está relacionado con un corte de luz, trato de "realizarlos rápido" aquellos que son rápidos de resolver. Para mí, esto es análogo a las cajas rápidas de en las que pone "diez artículos o menos" para pagar en el supermercado. Si puedo resolver un problema en cuestión de minutos y luego volver al problema más importante que es probable que me lleve el resto del día para resolver, lo haré.

Usted puede diseñar su propio sistema de numeración para el cálculo de las prioridades si encuentra este "truco" útil, pero no permita que se ponga demasiado complicado. Tal vez sus calificaciones de "valor" sólo deben ir de 1 (bajo) a 5 (crítico), el número de personas que puede ir de 1 (un individuo) a 5 (todo el mundo), y el tiempo requerido puede ser 1 (semanas), 2 (días), 3 (horas) o 4 (minutos). Pero de alguna forma de cuantificar y defender sus prioridades es siempre una buena idea.

Así, multiplicamos:

Criticidad * Personas_Afectadas * Tiempo_Requerido = PRIORIDAD

Crticidad * # personas afectadas * tiempo requerido = prioridad (mayor número = mayor prioridad)
5 * 2 * 2 = 12 problema #1
5 * 1 * 4 = 20 problema #2

Problema # 2 Es el problema más prioritario en este ejemplo.

Hábito 4: Realizar autopsias, pero no te pierdas en ellas

Algunos administradores de Unix se pierden con las autopsias. Es una buena idea saber qué produjo un problema, pero tal vez no debe ocupar muchas horas de su tiempo. Si un problema encontrado era una muy grave, un problema de alto perfil, podría suceder de nuevo, probablemente debería pasar el tiempo necesario para entender exactamente lo que sucedió. Los problemas mucho menos graves podrían no justificar ese tipo de escrutinio, por lo que probablemente debería poner un límite a la cantidad de tiempo que dedican a la comprensión de la causa de un problema que se resolvió con bastante facilidad y no tuvo consecuencias graves.

Si usted averigua por qué algo se rompió, no sólo lo que pasó, es una buena idea para mantener algún tipo de registro que usted o alguien más puede encontrar si lo mismo ocurre meses o años a partir de ahora. Por mucho que me gustaría aprender de los problemas que se han topado con los años, demasiadas veces me encontré frente a un problema y decir "ya he visto esto antes ..." y sin embargo, no se acordaron de la causa o lo que había hecho para resolver el problema. Mantener buenas notas y ponerlos en un lugar confiable puede ahorrarle horas.

También debe tener cuidado en asegurarse de que su solución realmente funciona. Trate de verificar que cualquier problema queda resuelto por completo antes de escribir "solucionado". A veces, necesitará la comprobación de el usuario final para ayudar con esto. A veces puede hacerlo con una cuenta del usuario y comprobar la solución usted mismo (siempre mi elección).

Hábito 5: Documentar su trabajo

En general, los administradores de Unix no les gusta documentar las cosas que ellos hacen, pero hay cosas que realmente justifican el tiempo y esfuerzo. He construido algunas herramientas complicadas, sin unas buenas notas, por lo que ahora tendría que volver sobre mis pasos sólo para recordar cómo funciona alguno de estos procesos. Por ejemplo, yo tengo algunos procesos que involucran a los scripts de Visual Basic que se ejecutan en un servidor virtual de Windows y envían archivos de datos a un servidor Unix que el formato de los archivos usando Perl, preparándolos para ser procesados.

Si alguien tuviera que asumir la responsabilidad de esta configuración, es posible que les lleve mucho tiempo comprender todas las piezas, en las que se ejecutan, lo que está haciendo, y cómo encajan entre sí. De hecho, a veces tengo que parar y preguntarme a mí mismo: "Espera un minuto, ¿cómo lo hace éste trabajo" Algunas de la mejor documentación que he preparado para mí mismo describe los procesos y que se ejecuta cada pieza, muestra muestras de datos en cada etapa del proceso e incluye detalles de cómo y cuando cada proceso se ejecuta.

Hábito 6: solucionar el problema y explicar

Los buenos administradores de Unix siempre son sensibles a las personas que están dando soporte, reconocen los problemas que han sido reportados y dejan a sus usuarios saber cuando están trabajando en ellos. Si se toma el tiempo para reconocer un problema cuando se informa, informar a la persona que reporta el problema cuando en realidad estás trabajando en el problema, permiten al usuario saber cuando el problema ha sido resuelto, los usuarios  tendrán a sentirse mucho menos frustrados y estarán más agradecidos por el tiempo que pasan ayudadándoles. Si ir más lejos, toma más tiempo, trate de explicar lo que estaba mal y por qué ocurrió el problema, es posible que les permite ser más autosuficientes en el futuro y que probablemente va a apreciar los puntos de vista que nos has proporcionado.

Hábito 7: Tómese un tiempo para usted mismo

Como he dicho en otras reseñas, no eres tu trabajo. Cuídese a sí mismo es una parte importante de hacer un buen trabajo. No se encadene a su escritorio. Camine alrededor de vez en cuando, tome descansos mentales, y mantenga el aprendizaje - sobre todo las cosas que le interesan. Si se ocupa de su bienestar, renovará su energía.

También debería leer:

* Los Enlaces que todo Administrador Linux debería tener en su bookmark

* Biblioteca / Librería de Scripts Linux