El interesado descuidado, también conocido como administrador del sistema

Question

Hace algún tiempo me di cuenta de que casi todos los proyectos de clientes en los que he estado trabajando hasta ahora han descuidado a un grupo importante de partes interesadas: los administradores del sistema.

Estos héroes silenciosos generalmente solo están involucrados al final de un proyecto y se quedan con una caja negra de bits ejecutables que tienen que instalar, mantener y mantener en los años venideros. Cada vez que se produce un problema con este cuadro negro, tienen que encontrar una manera de resolverlo utilizando cualquier información aleatoria y soporte de herramientas que el cuadro negro o la plataforma subyacente les proporcionen, y si esto no es suficiente, tienen que improvisar .

Si hubieran estado involucrados como parte interesada en el proyecto desde el principio, habrían tenido la oportunidad de predecir posibles problemas e informar al equipo del proyecto al respecto. Pero la realidad es diferente y aunque a mí como desarrollador me encantaría involucrar al administrador del sistema como parte interesada adicional, los factores externos pueden evitar que esto suceda.

En estas situaciones me gustaría ayudar a nuestros héroes silenciosos lo mejor que pueda. Entonces mi pregunta es:

¿Qué desearía un administrador de sistemas de nosotros los desarrolladores cuando desarrollemos los sistemas que tendrán que mantener?

Si usted es administrador del sistema cuente una historia de guerra sobre un problema difícil que alguna vez tuvo y lo que los desarrolladores pudieron haber hecho para que sea más fácil resolverlo.

Answer 1

Varias cosas, incluidas (pero que probablemente no se limitarán a), que no están en orden de prioridad:

• No es necesario utilizar la instalación privilegiada
• Opción para usar instalación privilegiada
• Opción para instalación distribuida (para que pueda instalarse en un servidor y usarse en otras máquinas)
• Desinstalación limpia
• Patrones de actualización sensibles
• Opción para elegir la ubicación de instalación
• Dependencias mínimas en otro software
• Dispersión mínima de datos alrededor del sistema (no arroje cosas en / etc, / usr / lib, / var / adm, ...)
• No hay troncos en constante crecimiento
• Instalación silenciosa
• Instalación por script
• Documentación en línea (en la máquina, así como en Internet)
• Páginas de manual tal vez
• Fácil de configurar
• Fácil de hacer accesible para los usuarios finales
• Sin riesgos de seguridad
• No hay usuarios o grupos especiales (o número limitado; a lo sumo un usuario especial, un grupo especial es un objetivo, aunque no siempre alcanzable)
• No hay funcionalidad de 'teléfono en casa' o solo si está configurado explícitamente (no debe ser predeterminado)
• Buen registro de diagnósticos cuando hay un problema
• Buen soporte técnico disponible si hay un problema
• No es necesario obtener el código de activación durante la instalación
• No es necesario reiniciar la máquina después de una instalación
• Capacidad para ejecutar en paralelo versiones antiguas y nuevas

Mucho depende de qué es el software y cómo se usa. Los requisitos para un programa GUI que funciona en Windows, Linux y MacOS X son radicalmente diferentes de los requisitos para un demonio de red, pero el objetivo debe ser un software estable, confiable y fácil de administrar.

Tenga en cuenta que existen grandes diferencias entre el software preparado por un departamento interno para su uso dentro de una empresa y el software preparado para ser utilizado por clientes externos a la empresa que desarrolla el software.

Answer 2

Cuando ocurre un problema inevitablemente, presta atención a lo que dice el administrador del sistema y créelo. No lo descarte de inmediato si no se ajusta a su evaluación inicial.

Historia de guerra: Hace unos 6 años atrás, estaba administrando sistemas para una pequeña empresa de fabricación y decidieron comprar algún software para gestionar la programación del mantenimiento preventivo de sus equipos. Una de sus características era la importación de solicitudes de mantenimiento desde el correo electrónico, pero tuvimos problemas ocasionales con errores al hablar con el servidor de correo durante este proceso y finalmente me llamaron para que lo revisara durante una llamada telefónica con el desarrollador. La conversación involucró múltiples iteraciones de

  

Desarrollador: nunca he oído hablar de nadie   teniendo ese tipo de problemas para hablar   El servidor de correo. Tiene que ser un   problema del cortafuegos.

     

Yo: estoy conectado al firewall,   ejecutando un sniffer de paquetes y mirando   el tráfico de su aplicación pasa sin ningún   problemas. Está atravesando el firewall muy bien.

     

Desarrollador: No, no, tiene que ser un   problema del cortafuegos.

(Al final, resultó que el problema era que la aplicación abrió una conexión POP3, leyó todo el correo, esperó a que el usuario programara las tareas y luego envió un comando POP para eliminar el correo después de que todas las solicitudes hubieran programado. Si el usuario tardó más de 15 minutos en hacer la programación, la conexión POP expiró y la aplicación no pudo recuperarse, por lo que murió en su lugar. Y luego el usuario tuvo que repetir la programación, lo que significa que probablemente Tómese el tiempo suficiente para volver a esperar ...)

Answer 3

Creo que es una combinación de lo siguiente:

1) Umbral de capacidad - > ¿Qué máquinas se necesitan para ejecutar este software y qué métricas deberían usarse para determinar cuándo puede cambiar este número? yendo de 2 a 3 servidores de bases de datos o yendo de 10 a 15 servidores web. Qué tan robusto debe ser el hardware y si una parte importa más que otra, p. ¿La CPU importa más que la RAM? ¿Qué pasa con la configuración del disco duro y el espacio?

2) Solución de problemas de estilo de libro de cocina - > Si algo sale mal, ¿con qué facilidad se puede clasificar en código, datos o error de red?

3) Diagrama de entornos - > ¿Cómo son las instancias de desarrollo, prueba y producción de este software? ¿Hay estos y posiblemente otros entornos ejecutándose en este momento?

4) Mantenimiento - > ¿Hay archivos de registro para analizar en informes, registros de errores semanales para enviar o algún tipo de mantenimiento relacionado con el software, p. reinicie el servidor semanalmente.

5) Seguridad - > ¿Hay cuentas para crear y administrar y una política de seguridad para describir quién tiene qué nivel de autoridad en el sistema?

Esos serían los principales que se me ocurren.

Answer 4

Los administradores del sistema generalmente quieren lo siguiente:

• Transparencia en la operación del sistema. Entonces, algún tipo de GUI que muestra la configuración del sistema y tal vez un historial de problemas del sistema, así como listas de lo que el sistema ha procesado correctamente.
• Una ruta de escalada clara sensible al contexto para problemas. Con esto quiero decir que cada tipo de problema tiene algunas notas sobre la solución, y una persona o equipo con el que se puede contactar si el problema no se puede solucionar rápidamente y se requiere una escalada.
• Ser proactivo, es decir, informar a los usuarios finales sobre un problema del sistema antes de que un usuario final le informe. Entonces, algún tipo de alerta inmediata para cualquier problema del sistema donde sea factible,
• No ser inundado por alertas. Entonces, una vez que llega una alerta, no más alertas para el mismo problema; solo otro mensaje cuando el sistema vuelva a estar operativo.
• Registro detallado utilizando algo como el registro de eventos (en Windows) para una investigación más profunda de un problema.

Answer 5

Que el sistema simplemente funciona para que pueda ir a casa con los niños.

Answer 6

Dependencias bien documentadas que vienen empaquetadas con el software, si mi experiencia de administrador en casa es algo para pasar.

Answer 7

Bueno, más un horror que una historia de guerra: mantener una aplicación que, sin razón aparente, exige ejecutarse bajo una cuenta de usuario administrador.

Algunas cosas aleatorias que creo que sería bueno tener en una aplicación:

• Argumentos significativos de línea de comando
• Algún tipo de capacidades de secuencias de comandos (si corresponde)
• Cualquier tipo de indicador de progreso para operaciones de larga duración
• Error de registro
• IU consistente

Answer 8

¡Mantenimiento sencillo del paquete!

Debería ser extremadamente simple instalar y actualizar el software, y eso también se aplica a las dependencias. Si hay muchas dependencias y subdependencias, y no está dispuesto a dominar los matices de la metodología de gestión de paquetes de cada sistema operativo, sería bueno ofrecer una versión de paquete con todas las dependencias necesarias agrupadas en un tarball gigante . Ejecute el script, envíelo todo a / usr / local / yourproject y dígales dónde está el script de inicio / apagado / reinicio.

Answer 9

Cada proyecto tiene 'Planificación de capacidad' junto con su arquitectura de sistema. Los administradores del sistema deben participar en el proceso de Planificación de la capacidad, así como en la revisión final de la Arquitectura del sistema. Esto lo ayudará a comprender mejor el sistema y estar preparado para la implementación y el soporte.