A los productores de software…

Esta es una traduccion rapida de un articulo muy bueno, que encuentran en http://queue.acm.org/detail.cfm?id=1921361

SI – Opción de “instalación silenciosa”. Un panelista (N.del T. esto salio de una conferencia llamada CHIMIT) comentaba el caso de la automatización de la instalación de un producto de software en 2000 PCs, excepto por UN paso de la instalación en la cual aparecía una ventanita donde habia que hacerle click al “OK”. Todas las demas interacciones podian evitarse usando un archivo de valores por defecto. Herramientas Linux/Unix como Puppet y Cfengine deberían poder automatizar no solo la instalación, sino la configuración. Los procedimientos de desinstalación no deberían borrar datos de configuración, pero debería haber una opcion “no dejar rastros” que elimine todo excepto la información generada por el usuario.

NO – La interfaz administrativa no debe ser gráfica (GUI). Los administradores de sistema necesitan una herramienta de linea de comandos para construir procesos repetibles. Los procedimientos son mejor documentados si se proveen comandos que se pueden copiar y pegar desde el documento hacia la linea de comandos. No podemos obtener la misma repetitibilidad cuando las instrucciones son: “Marcar la casilla 3 y 5 de las opciones, pero NO la numero 2, despues click a OK”. Los administradores de sistema no quieren una GUI que requiere 25 clicks por cada nuevo usuario. Queremos construir los comandos que serán después ejecutados en un editor de texto, o generarlos via Perl, Python, PowerShell, etc.

SI – Crear una API que permita al sistema ser remotamente administrado. Una API nos da la posibilidad de hacer cosas con su producto de las cuales usted no hubiera pensado. Eso es bueno. Los administradores se esfuerzan para automatizar, y automatizar para prosperar. [el resto es blahblah]

SI – Configuraciones en ASCII, no en un formato binario. De esta forma los archivos pueden ser integrados a un sistema de revision de código. Cuando el sistema está mal configurado es importante poder ver las diferencias con versiones previas de la configuración. Si el archivo no puede ser re-ingresado al sistema para recrear la mísma configuración, entonces no podemos confiar  en que nos estés dando toda la información. Esto previene que clonemos configuraciones para implementaciones masivas, o recuperación en caso de desastres. Si el archivo puede ser editado y subido al sistema, entonces podemos automatizar el proceso de creación de configuraciones. El archivado de copias de seguridad de configuraciones permiten un interesante analisis histórico.

SI – Incluir un metodo claramente definido para restaurar la información de todos los usuarios, un único usuario, e ítems individuales (por ejemplo, un email concreto). El método para hacer copias de respaldo es un prerequisito, obviamente, pero los procedimientos de recuperación son los que principalmente nos importan.

SI – Incorporar herramientas de instrumentación al sistema, para que podamos monitorear más que tan solo “anda o no?”. Necesitamos poder determinar latencia, capacidad, utilización, y debemos poder recolectar dicha información. No generen los gráficos ustedes. Permitannos recolectarlos y analizar los datos en crudo, de forma tal que podamos hacer graficos bonitos que nuestros gerentes no-tecnicos puedan entender. Si no estás seguro que instrumentar, imagina al sistema totalmente sobrecargado y lento: que parámetros podríamos necesitar para poder encontrar y corregir el problema?

SI – Cuentennos sus problemas de seguridad. Anúncienlos publicamente. Ponganlos en RSS. Digannos si no tienen un parche aún, necesitamos poder analizar el riesgo. Su departamento de marketing no entiende esto, y está bien. Es TU trabajo decirles que no molesten.

SI – Utilicen el sistema nativo de logs (Syslog en Unix y variantes, o el log de eventos de MS Windows). Esto nos permite aprovechar herramientas preexistentes para recolectar, centralizar y buscar en los logs. En forma similar, utilicen el subsistema de autenticación del sistema operativo y otros subsistemas estandar.

NO escriban archivos por todo el disco. Pongan los ejecutables/binarios en un lugar, archivos de configuración en otro, los datos en otro. Y listo. No escondan un archivo de configuración en /etc y otro en /var. No escondan cosas en \Windows. Si es posible, permitanme seleccionar el prefijo al path durante la instalación.

SI publiquen documentación en formato electrónico en su sitio web. Debe estar disponible, linkeable, encontrable (N del T, facilmente indexable por google) en la web. Si alguien bloguea una solución a un problema, deberian poder linkear a la documentación relevante. Dar un PDF es dolorosamente antiproductivo. Mantengan todas las versiones anteriores en linea. El procedimiento para recuperar de un desastre para la instalación de un software desactualizado, no soportado, de hace 5 años atrás puede depender de poder encontrar el manual en la web.

Les recomiendo leer el articulo original en:
http://queue.acm.org/detail.cfm?id=1921361

Artículos relacionados:

Si te gustó este articulo, ¿ Porque no dejas un comentario a continuación y continuas la conversación, o te suscribes a los feeds y recibes los artículos directamente en tu lector?

Comentarios

No comments yet.

Sorry, the comment form is closed at this time.