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.