Consejos para hacer buenos scripts (y backups)

Hoy toca fusilar a W. Curtis Preston y su excelente "Backup & Recovery" dónde da cuatro grandes consejos para usar en scripts relacionados con backups (aunque también valen para otras cosas):

• Chequear muchas, muchas veces. Controlar siempre el código de retorno de cualquier comando o programa que ejecutemos. Si puedes intenta solucionar el error.
• Notificar una y mil veces. Notificar sobre cualquier cosa anormal que se produzca. Usar 'grep -v' para eliminar líneas de salida no deseadas (que tenemos claras cuales son) y no 'grep' sobre las líneas de salida que queremos notificar (no mandaríamos las líneas raras que a veces salen). Nunca asumir nada, sendmail no tiene porque funcionar así que mejor busca siempre robustez. Si no hay correo, usa el log y sino el error estandar.
• Almacena la tabla de contenidos de cada volumen de backup que hagas. Si tu sistema de backup tiene un buen catálogo entonces lo que tienes que hacer es un buen backup adicional del backup.
• Comprueba bien las salidas de ssh o rsh. "$ ssh remote-system do_stuff ; echo $?" devuelve la salida de ssh, no de "do_stuff". Usa algo como:

rsh apollo "ls -l /tmp/* ; echo \$?>/tmp/ls. success"
SUCCESS=` rsh apollo cat /tmp/ls. success ; rm /tmp/ls. success`
if [ $SUCCESS -eq 0 ] ; then
#everything worked
echo "Everything worked. "
else
echo "Something bad happened! "
fi

Desarrolladores, esos malditos...

Voy a fusilar a Limoncelli, un administrador de sistemas cañón que ha escrito biblias como "Time Management for System Administrators" y comentar las seis cosas que debe tener un software para ser "sysadmin friendly":

• Interfaz de línea de comandos: desde la shell la programación de tareas y hacer scripts hacen que la vida sea automatizable y tranquila. La interfaz gráfica de escritorio está bien para conocer lo que hace el software y si es interfaz web aún mejor pero aunque suele ser posible automatizar en escritorio o web es más complejo, sobre todo para lo primero. Para la interfaz web conozco un producto muy bueno que llaman ITPilot. Curiosamente lo hace una empresa llamada Denodo en la que tengo el placer de trabajar (es que ayer fue la cena y estuvo muy rica...).
• Disponer de una API que permita administrar remotamente. Realmente si hay línea de comandos gracias a SSH ya se puede conseguir administrar, aunque es mejor usar cosas chulísimas que se pueden montar con servicios web, JMX o parecidos. Sobre todo si puedes integrarlo todo en un Nagios o similar y poder monitorizar los sistemas como si estuvieras en una consola de mandos de la NASA.
• Disponer de un modo de instalación silencioso que permita realizar instalaciones limpias. Es lo de siempre, poder automatizar todo y estandarizar los procesos. Un ejemplo bueno es el kickstart de Red Hat. Algunos dirían que con máquinas virtuales que se congelaran y se clonasen se puede hacer eso y más. Yo creo que no y algún día me desquitaré sobre los vicios que trae la virtualización y por qué no eres más alto ni más guapo por usar tu plataforma de virtualización favorita.
• Tener un fichero de configuración que sea un fichero de texto que se pueda mantener con un sistema de revisiones y que el fichero de configuración se pueda dar como argumento al sistema. Yo creo que se olvidó de incluir que el fichero de configuración debe permitir introducir comentarios (que el día de mañana puedas identificar porque se puso cualquier cosa). El sistema de versiones pues también sirve para añadir ese tipo de metainformación sobre los cambios (además de la parte policial de quién, cuándo, cómo y por qué hizo tal cosa) y extiende la posibilidad de versionado de configuraciones. Añade complejidad, no mucha porque los subversion, mercurial y demás alternativas son fáciles y baratos de usar. Si no te complicas la vida al menos sé lo suficientemente ordenado para guardar copias del fichero con la fecha del cambio añadida al nombre, comentar los cambios e incluso enviar un diff a tus compañeros sobre que has hecho en un servidor (FYI!).
• Tener una forma clara de poder realizar copias de seguridad y restaurar los datos. Parece increíble que haya software que no permita hacer esto, hasta la legislación española obliga a que el software provea de procedimientos de salvaguarda de datos, pero con tanta nube y servicios externalizados la gente se olvida. Por ejemplo, en Sales Force no hay "botón de backup" y "botón de restore". En principio, lo que tienes que hacer es extraer un inmenso zip con muchos csv's de datos y la carga es tu responsabilidad (muchas horas para hacerlo). No creo que Sales Force pierda tus datos pero esto es como lo del RAID, nadie te protege ante los errores de los usuarios y esos se producen a menudo y se detectan cuando más estorban.
• Tener un modo fácil para monitorizar los servicios y sus incidencias. Poder obtener estadísticas sobre las latencias y rendimiento de los servicios así como históricos que permitan evaluar la evolución del sistema (saber cuando va a petar algo en base a la demanda actual). Muy unido a lo de la automatización remota y a poder hacer presupuestos reales y no con la bola de cristal.

No era lupus

Era divertido verlo en la serie de televisión hasta que la ficción se aparece en tu vida y te das cuenta que no es un episodio de la tele sino que esta vez eres tú el protagonista. Te das cuenta de que todo tiene un final y que el tuyo puede estar cerca. La desesperación llega y entonces es cuando lo que cuentan en las películas empieza a ser tu realidad.

No lo puedes creer, pero es cierto, la medicina consiste en destruir a tu cuerpo para también acabar con el mal. De nada sirve quejarte porque sabes que es el único camino para salvar la vida.

Llegas a una sala donde una cómoda butaca te espera junto con bolsas de líquidos que entraran en tu sangre, algunos parecen que te queman por dentro. Las enfermeras sonríen, siempre atentas, consiguen hacer que aquello parezca más agradable. Hay muchas otras butacas, cada una con alguien, con una historia distinta, jóvenes o mayores todos sabemos lo que estamos haciendo allí. Los enfermos también sonreímos y todo el mundo intenta consolar a todo el mundo e incluso nos reímos de las mil y unas historias que te pasan cuando tienes esta enfermedad.

La medicina poco a poco te debilita. Empiezas a ver que hay un montón de cosas malas que te pueden pasar y tener que sufrir. Lo divertido es que para tus médicos no son importantes porque simplemente son efectos secundarios. Cada día piensas en cuando se acabará el maldito tratamiento y de vez en cuando piensas que a lo mejor no se acabará. Y te bloqueas.

Es ese momento en el que debes reaccionar. Piensa que pase lo que pase bloquearte sólo sirve para perder el tiempo y la vida es preciosa para malgastarla. Esta enfermedad es de las peores pero no deja de ser una enfermedad y se puede curar. Y para curarse se necesita un cuerpo y una mente fuerte que permita aguantar. Busca a la gente que te quiere porque te dará energía para recuperarte y escapa de aquella que no te ayude. Disfruta de la vida porque la vida es maravillosa, aprovecha cada día para encontrar cosas buenas como la alegría, el amor, la amistad y tantas otras. Saldrás fortalecido y la enfermedad lo tendrá más difícil.

Nunca te rindas. Si te rindes sólo conseguirás llegar al final de la partida. Nada más. La vida es maravillosa, lo más maravilloso que hay así que no renuncies a disfrutar ningún segundo de ella.

Make Things Happen

Por fin acabé con la trilogía de Scott Berkun, un informático muy interesante que aparte de dar buenas charlas también escribe buenos libros. El tercer libro que he leído es "Make Things Happen" que está dedicado a la gestión de proyectos informáticos. Berkun fue durante años un project manager en Microsoft cuya misión era sacar adelante proyectos relacionados con Internet Explorer y Windows. Así que sabe de lo que habla.

Su libro relata las cualidades que debe tener un jefe de proyecto informático para conseguir sacar adelante los objetivos del proyecto así como consejos para poder relacionarse adecuadamente con los miembros de su equipo, cliente y empresa. Huye con facilidad de los rollos teóricos y siempre recurre a ejemplos prácticas. Según las críticas de Amazon este libro es muy recomendable para formarse en cuanto la gestión de proyectos. Yo no soy experto en la materia pero puedo decir que me ha gustado y lo que he leído me parece muy correcto así como aplicable a mi vida profesional.

No soy jefe de proyecto así que el libro no tiene aplicación directa para mi pero sí como medio para "introducirme" en el saber hacer de una empresa informática y reconocer las tensiones que allí se producen (cliente, negocio, ingeniería, ...). Me he quedado con muchas ideas y herramientas que creo que me serán útiles.