FAQ de gerencia de administración de sistemas

Recien leo un post muy interesante "Es necesario más PhDs en administración de sistemas"

Al final del post veo algunas preguntas no tan técnicas sobre adm. de sistemas que quiero contestar:


¿Por qué las buenas prácticas son raramente adoptadas?
Esto se da porque las buenas prácticas responden a una estructura tipo general y normalmente los sistemas están insertos en estructuras muy particulares y pocas veces se corresponden con las estructuras generales; aplicar buenas prácticas a veces significa incluso hacer las cosas de un modo poco eficiente, eficaz y se vuelve anti-económico.

Este tema es extensivo, se puede hablar de todo tipo de razones (políticas, organizativas, económicas, sociales, etc.), en lo puramente técnico, lo anterior es lo usual.


¿Qué impide a un número constante de administradores de sistemas administrar recursos crecientes de máquinas y usuarios.?
Es un problema de escalabilidad de recursos, dadas X hs./hombre de trabajo requeridas para absorber una carga de trabajo X, si se añade carga de trabajo por encima del valor óptimo de "absorción", las tareas se desfasan de sus fechas previstas en instancias anteriores al aumento de la carga de trabajo.

Se suele estimar que un buen adm. de sistemas sabrá implementar la suficiente automatización de tareas como para absorber un aumento en la carga de trabajo; al mismo tiempo se suele ignorar el hecho de que no todas las cargas son automatizables, y en una infraestructura suficientemente madura, la carga de trabajo automatizable ya suele estar justamente cubierta (con herramientas, scripts, etc.), y que el incremento en la carga de trabajo no será en el 99% de los casos automatizable al 100% (si lo fuera permitiría mantener el status-quo de rendimiento hs./hombre anterior al aumento de la carga de trabajo).


¿Por qué es el debug tan complicado?
Porque la relación entre el conocimiento profundo de un ítem a debuggear incide directamente sobre la destreza en el manejo de cualquier herramienta que se use para ello (algunas son más adecuadas que otras), según el grado de conocimiento suele ser la complejidad que tenga el debugging para un adm. particular.

A la vez existe un factor clave inherente al debugging: la incertidumbre; este factor se maneja con mejor o mayor eficacia típicamente segun el grado de experiencia y conocimientos del adm. de sistemas.

La resolución de la incertidumbre suele llevar directamente a la definición clara del contexto del problema y a la definición exacta de la causa del problema, por lo que recien luego de desvelada la incertidumbre se puede realizar una estimación realista de recursos requeridos para la solución de un problema.

En la estimación de recursos reside la única información util para los gerentes fuera del contexto del trabajo técnico, como normalmente se accede a dicha estimación en un tiempo prudencial luego del inicio del debbuging, es lo que lleva generalmente a definir de "complicado" este tema, cuando en realidad un adm. de sistemas experimentado sabrá gestionar adecuadamente sus comunicaciones para minimizar la incertidumbre inmediatamente posterior a la aparición de la necesidad de debbugear "algo" (un problema en general: eventos de cese de prestación de servicios, disminuciones de niveles de prestación de servicios, etc.etc.)


¿Cómo organizar a equipos de administradores de sistemas para maximizar la eficiencia de los sistemas y personales?
En principio, la norma básica de la administración de recursos la dicta el sentido comun. Según la disponibilidad de recursos (personas, equipos, software, tiempos, etc.), y en relación con el trabajo y objetivos a cumplir se dispone la organización de dichos recursos.

En este sentido lo que se puede diseñar son "guidelines", lineamientos; no hay recetas. Por supuesto, esto parece diferir del enfoque del especialista con experiencia que casi inmediatamente después de apreciar las variables recursos/objetivos dictamina con mucha efectividad un boceto de organización y de proyectos de trabajo; de nuevo: no son reglas que el especialista conozca y los demás no, sino el punto de vista del conocimiento sumado a la experiencia.

Algo que normalmente se ignora es que las técnicas usuales de administración de empresas/organizaciones y que no son impartidas como parte de la capacitación IT en universidades (no es lo mismo que administración de recursos), suele brindar un marco teorico especialmente bueno a un administrador de sistemas.


¿Cómo delegar en los usuarios sin esperar que sean administradores de sistemas?
Es bastante más simple de lo que parece, los usuarios pueden ser evaluados en sus respectivos niveles de capacitación muy rápidamente y en relación directa con la comunicación del día a día dada por el troubleshooting típico de la adm. de sistemas.

Así se puede inferir en que grado los usuarios finales están acercados al mínimo de capacitación requerido para operar los tipos de herramientas que necesitan y por ende los administradores podemos determinar qué complejidad se puede "bajar" al usuario sin que se vuelva improductivo su uso de las herramientas informáticas.

El feedback entres adm. de sistemas y helpdesk (y el de estos con los usuarios finales), es crítico para la implementación de la idea anterior.


¿Qué rasgos comparten la administración de sistemas exitosa?
Hay muchos rasgos en realidad; básicamente se puede definir el mínimo perfil de una administración de sistemas exitosa en la situación en que el flujo de trabajo típico de una organización en relación con su infraestructura informática no es afectado negativamente de ninguna manera desde el desempeño de las tareas de administración de sistemas.

Ideas adicionales a lo anterior tienden rápidamente a la pura especulación sin tener constancia de los detalles reales y completos de cada situación particular.