Versión: 02 de Junio de 2012
Licencia: derechos reservados
Presentación: Considero este texto un estudio/idea en evolución, espero ir modificándolo y corrigiendolo según sea necesario a medida que progreso en la investigación.
Temáticas tratadas: expansión de número de servers en organizaciones, infraestructuras ágiles, virtualización, planificación de personal de administración de sistemas, beneficios del uso de configuration management soft, cadena de herramientas.
El problema
Cuando una infraestructura informática se pone en producción en una organización, hay muchas chances de que solo sea un punto de inicio desde el cual va a ir creciendo junto con la organización.
Acortando explicaciones para sysadmins: vamos a tener cada vez más servidores que atender, más aún, el ciclo de mantenimiento de los viejos servers va a entrometerse cada vez más en las tareas diarias.
Además, en las infraestructuras típicas, la implementación inicial no justifica una inversión masiva en nada, es decir, grandes plataformas de infraestructura integrada como Oracle Exadata o Cisco UCS siemplemente no son necesarias en ese punto de la vida de la infraestructura (al menos aún). Por ende la fragmentación de plataformas de hardware y software suele ser fuerte, lo que deriva en necesitar más horas/hombre de trabajo de administración de sistemas.
Desde el punto de vista del software, dados los típicos casos de uso en organizaciones es casi imposible disponer de plataformas de software totalmente homogéneas, probablemente vamos a estar corriendo alguna combinación de Unix/Linux y Windows Server.
Las plataformas de hardware homogéneas sí son posibles de implementar (blade servers, por ejemplo), pero no hay que dejarse llevar por las promesas de que eso "lleve", "tienda" a homogeneizar el software (vía licencias incluídas con la compra de hardware por ejemplo), ya que el uso de soft se basa en requerimientos y necesidades de la organización, no en el hardware en el que corre.
Planes: el ejemplo de un Poder Judicial
Volviendo a los servers: a poco de iniciado el montaje de una nueva infraestructura vamos a empezar a poner más servers en producción, los que hay que administrar, ello plantea la necesidad de planificar la gestión del personal que lo hará: los administradores de sistemas (sysadmins).
Un Poder Judicial como ejemplo de organizaciones de crecimiento contínuo
Las organizaciones provinciales y nacionales del estado que cubren las necesidades de provisión de servicio del estado para con la población son un ejemplo claro y general donde se va a encontrar la necesidad de realizar una óptima gestión del personal destinado a administrar sistemas.
Los servicios informáticos de un Poder Judicial (provincial, nacional), son un ejemplo puntual. Bien, sigamos con el ejemplo de las necesidades de servicios de un Poder Judicial provincial típico - y debo mencionar, tengo varios años de experiencia específica en este tema (ar.linkedin.com/in/dardovaldez):
A medida que crece la población, se debe ir incorporando más empleados al Poder Judicial, para poder mantener su capacidad de provisión de servicios para con su creciente número de clientes debido a que la población crece y el número de horas/hombre que provee el servicio de justicia debe ser el necesario para esa población incrementada.
Es bastante remoto que la cantidad de horas hombre totales disponibles en casi cualquier dependencia del estado tenga horas/hombre libres disponibles, tal que le permita no contratar más empleados por varios años, de hecho, la mayoría de las dependencias del estado - entre ellas el Poder Judicial - contratan personal casi constantemente.
El problema [horas/hombre-capacidad de servicio a la población] de un Poder Judicial típico, se está resolviendo hoy en Argentina mediante la incorporación masiva de software al trabajo interno del Poder Judicial. Ello multiplica la capacidad productiva de la fuerza laboral, y por ende crea un escenario donde:
- Se introduce herramientas informáticas - software - en los procesos internos, modificandolos, en gral. haciendo que tareas que llevaban horas - literalmente - se realicen en minutos, produciendo un impacto fuerte en la productividad organizacional.
- Se puede contratar menos gente anualmente, disminuyendo el costo de personal
- Se implementa una plataforma fuertemente documentada formal e informalmente que permite un aprendizaje bastante más rápido para los nuevos empleados.
- Adicionalmente - mientras la capacidad productiva "extra" - respecto a antes de utilizar software - recien adquirida no esté completamente utilizada - los servicios de justicia se vuelven más rápidos.
Planificación reactiva
Volvemos ahora al escenario de gestión de personal de administración de sistemas.
El escenario es una organización en crecimiento constante, que añade servidores y software casi constantemente, lo que conlleva la necesidad de tener personal de administración de sistemas adecuado.
Si vemos el tema desde la óptima de la planificación reactiva - y con un ejemplo práctico - se entiende mejor el dilema a resolver, el ejemplo es:
"El primer año contrato un sysadmin Jr., luego de un par de años contrato dos sysadmins SSr., al cabo de otro año más, se "prevee" la necesidad y contrato un sysadmin Sr."
En algun punto luego de arrancada la historia del ejemplo, nos damos cuenta que los sysadmins Jr. y SSr. no van lograrlo: luego del primer año la infraestructura ya creció al punto en que un SSr. apenas tiene skills para manejarla, y aunque nuestro Jr. original ya es SSr. en este punto, ya trabaja codo a codo junto a sus compañeros, mientras esperan el support de un nuevo sysadmin, Sr. en esta oportunidad.
Es decir, la complejidad creciente de la infraestructura va incrementando rápidamente algunos factores:
- El skillset necesario para administrarla (implica mayor costo en personal, sueldos a pagar más elevados)
- La cantidad de personas necesarias para el trabajo
Más problemas
Hay varios sucesos colaterales, uno importante es que al crecer la infraestructura y las horas de trabajo, si no se planificó bien desde management y si los administradores no lo propusieron (lo que es de esperar, ya que eran básicamente Juniors y Semiseniors en skillset), el nivel de automatización de la infraestructura va a ser muy bajo, las tareas van a ser excesivamente repetitivas e inapropiadas para una infraestructura grande. Las tareas de emergencia - inevitables - van a ser cada vez más numerosas y con mayores tiempos hasta lograr soluciones.
Todo lo anterior acarrea costos no económicos, un stress muy alto para la estabilidad de los administradores en sus puestos y para los mismos administradores (problemas de salud importantes por stress por ejemplo), que pueden empezar a buscar oportunidades en infraestructuras con menos stress y mejor diagnóstico a futuro (ya que si algo funciona mal en el presente y no hay una evolución en la infraestructura, va a funcionar peor en el futuro).
Conclusión
Una expansión gradual y esperable del parque de servidores en una infraestructura va absorbiendo la capacidad productiva de los sysadmins mucho más rápido de lo que se puede incorporar nuevos sysadmins. El skillset técnico requerido va subiendo constantemente y luego de cierto tiempo, ningun sysadmin que tenga un nivel de skillset por debajo de Senior va a ser viable para contratar. Otros problemas relacionados con el exceso de trabajo y el stress, pueden incrementar más aún varios costos en la infraestructura (personal fuera de oficina con frecuencia por problemas de salud, sueldos, tiempos perdidos por renuncias imprevistas).
La solución
El problema de arriba es el mismo que enfrentan muchas organizaciones, y la solución es simple, se hace lo mismo que se hizo en el ejemplo del Poder Judicial usando software para multiplicar la capacidad productiva por persona.
La solución es elevar el nivel automatización de la infraestructura: usar software automatizando tareas a gran escala, permitiendo así que pocos administradores de sistemas puedan manejar de centenares a miles de servidores con - relativamente - muy pocas horas de trabajo dedicadas.
Las bases prácticas de la solución son:
- Modernizar las herramientas de configuración en los datacenters (software de configuration management), y los procedimientos de automatización de operaciones (metodologías ágiles en Operations; filosofía Devops),
- Explotar a gran escala el uso de virtualización vía provisión IaaS (Infraestructura como Servicio), usando cloud services.
- Mejorar el monitoreo para que lleve a entender mejor cómo se comporta la infraestructura y permita maximizar el mejor uso de los recursos disponibles.
Cadena de herramientas
La idea de fondo hoy, es migrar a una "cadena de herramientas", siguiendo la noción de arquitecturas DevOps, adoptando herramientas pequeñas e interrelacionarlas para realizar funciones puntuales.
Una "cadena de herramientas" muy usada en plataformas Linux es:
- IaaS cloud provisioning: Openstack
- Configuration Management: Puppet, Chef
- Monitoreo: Nagios (o derivados),
* La versión comercial de Puppet permite gestionar configuration management en Windows.
Es fácil verlo mejor con un ejemplo práctico típico: los pasos necesarios para instalar un nuevo servidor. En este caso, vemos la secuencia de acciones para añadir un server (nodo) a la infraestructura de virtualización/cloud:
- Se instala físicamente un servidor y se la registra.
- Es arrancada por el técnico de campo
- El server bootea vía red y el sistema operativo se instala automáticamente (vía PXE)
- El sistema operativo se configura vía Puppet (en muy poco comandos y en forma remota)
- El servidor se registra automáticamente en la nube Openstack
- El servidor queda listo para aceptar máquinas virtuales
Una cadena de herramientas propia de la plataforma Windows
La automatización en plataformas Windows, en lo específico ofrece opciones nativas de la plataforma, en un ejemplo, una cadena de herramientas completa está disponible vía productos de Microsoft en este conjunto de herramientas:
- IaaS cloud provisioning: Openstack
- Configuration Management: System Center Configuration Manager (SCCM)
- OS Windows
- Monitoreo: System Center Operations Manager (SCOM)
Razones para utilizar Configuration Management
Algunas razones para usar software de Configuration Management son:
- Documentación: toda la información de cómo construir esos sistemas va a quedar finamente detallada en el software: Puppet, Chef, SCCM (Microsoft System Center Configuration Manager), etc.
- Infrastructure as Code: que por ejemplo, va a permitir..
- Hacer builds rápidos y replicados exactos de sistemas que ya tengas en producción. Algo útil si quieres montar una máquina virtual para testing (como instalar una app "rara" en versión demo, que no saben si se llevará muy bien con el consumo de recursos de una DB corriendo en el mismo server, etc.)
- Montar y resolver dependencias de deployments: cuando tienes que configurar "algo", pero ese "algo" necesita de otros dos componentes (A y B), exactamente instalados en secuencia (primero A, luego B). Así evitarás repeticiones y algun sysadmin novato va poder hacerse cargo del build.
- Training y recursos: al montar una herramienta de configuration management, se hace menos pronunciada la curva de entrenamiento de sysadmins nuevos. Se los puede destinar a aprender a manejar la herramienta en principio, cuando aprendan a hacer "recetas", inmediatamente van a acceder a entender cómo es la arquitectura global de la infraestructura.
Al usar herramientas estándares del mercado (Puppet, Chef, SCCM, etc.), es más probable encontrar sysadmins que ya estén entrenados en ellas, incluso tal vez con experiencia.
No hay comentarios:
Publicar un comentario