Aprendiendo a garabatear diseños de infraestructuras

En este artículo comento acerca de enfoques recomendados para encarar el diseño de nuevas infraestructuras, también acerca de los motivos para adoptar distintos enfoques y ello acompañado de ejemplos de infraestructuras reales en las que trabajé (o estoy trabajando).


Ser Ordenados
Si me dieran un centavo por cada vez que escuché que hay que hacer y planificar las cosas ordenadamente cuando se diseña una infraestructura...lo que es correcto.

Sin embargo, vivimos en un mundo imperfecto, por ende es un caso muy común el que tengamos que diseñar infraestructuras de sistemas con los que no hemos trabajado nunca antes. Es una cuestión típica del trabajo en infraestructura IT, trabajar con tecnología desconocida.

Por ejemplo, esa nueva cabina SAN que se compra una organización en estos días de infraestructuras virtuales, que puede tener a un equipo completo de ingenieros experimentados sentados alrededor como si fueran pastores de ovejas mirando por primera vez el arca de Noé.

Los casos en que un profesional IT está fuertemente especializado en una tecnología están ligados casi exclusivamente a los altos niveles de skillset y de experiencia previa, y claro, sabemos que el equipo IT promedio no está compuesto en su totalidad por - digamos - 7 ingenieros con 10 años de experiencia en Windows Server (cada uno), sino por tal vez un par de ingenieros con mucha experiencia (2 Seniors), otro par con menos experiencia (2 SSr.), y varios ingenieros novatos (3 juniors).

La posibilidad de trabajar ordenadamente está fuertemente relacionada con el nivel de experiencia y conocimiento previo que se tenga sobre un sistema. Si el nivel es 0 o tendiendo a cero, tenemos que replantear la estrategia de diseño.

Así que cuando estamos diseñando infraestructuras de sistemas que no conocemos previamente ¿Cómo se puede proceder ordenadamente?


Enfoques
Hay dos enfoques típicos en general (no son los únicos):

1) Aprender todo primero y luego hacer el trabajo
Acá tenemos un problema, el tiempo, se tarda mucho tiempo en leerse 300-600 hojas de material técnico sobre el sistema a implementar. 300 a 600 hojas de libros/tutoriales es una cantidad estándar de material que abarca desde una introducción teórica, pasando por una instalación básica, llegando a la configuración básica, luego tratando temas avanzados y finalmente tratando con temáticas de recuperación y troubleshooting.

El enfoque 1) suele ser el enfoque a utilizar cuando se necesita implementar un sistema utilizando el grueso de sus capacidades técnicas (70% al 100% de sus opciones, etc.), normalmente para estos casos, si es que la planificación fue adecuada, tendremos incluída una capacitación en el costo de adquisición del sistema.

Por ejemplo, se compra una licencia de Windows Server para montar una infraestructura virtual basada en Hyper-V + System Center Virtual Machine Manager 2008 R2, donde vamos a montar un Active Directory, Exchange, SQL Server como backend - server separado - de una aplicación (también a instalar). Evidentemente, el nivel de conocimiento sobre Windows Server tiene que ser bastante alto para poder hacer todo esto en un tiempo razonable. 

2) Manos a la obra (Hands on)
Acá tenemos un foco más directo, agarramos buenos tutoriales de la red, los revisamos, adquirimos conceptos básicos (la terminología usada en el sistema por ejemplo, sumamente importante), luego podemos sentarnos tranquilos a leer las introducciones y explicaciones teóricas de los libros (de 50 a 100 hojas típicamente). Después podemos montar un entorno de prueba y empezar a testear los tutoriales básicos.

El enfoque 2) es más adecuado cuando ya se tiene una idea de que la implementación del sistema no va a utilizar - al principio al menos - demasiadas capacidades técnicas, así que lo que hace falta entender para poder configurarlo apropiadamente es poco en comparación con el caso 1).

Por ejemplo, se compra una licencia de Windows Server para utilizarlo como File Server, vean acá lo que hace falta hacer para configurar un Windows Server como file server (es un video de 5 minutos de duración):

http://www.youtube.com/watch?v=fBvi3giio-I


Pies en la tierra
Siendo realistas, la mayoría de las tecnologías informáticas nuevas que se suele introducir en una organización no tienen la urgencia de ser implementadas en un tiempo límite (por ej. "tiene que estar terminada y funcionando con fecha límite en marzo 2013"). 

Pocas veces la implementación de nueva tecnología informática no pasa por el ciclo de testeos y pruebas piloto, previas a un deployment piloto y antes de una implementación masiva final.

Menos veces aún la misma tecnología se implementa desde cero (nada implementado en la organización), hasta niveles de implementación donde se use el 70-100% de las capacidades técnicas de la tecnología, abarcando una solución organizativa completa: un sistema/servicio consumido masivamente por clientes internos distribuídos por toda la organización. Tal es el caso del ejemplo mencionado de Windows Server + Hyper-V + SCVMM + AD + Exchange + SQL Server + Aplicación.

Y es sumamente escaso el ejemplo de una implementación con tiempo límite + desde cero a todo.

[ Los casos de proyectos de implementación de tecnología informática que tengan características de "con tiempo límite", "de cero a todo" y sus combinaciones, se dan típicamente cuando hay al menos un Senior y/o varios SSr. conocedores y/o con experiencia previa - práctica y útil - en la tecnología a implementar. ]

El ejemplo típico de "con tiempo límite"+"desde cero a todo" esta ligado al 99% con hardware. O sea, no se puede implementar "de a poco" una SAN de 5 TB. Hay que comprarla, configurarla, migrar el uso de storage local de los servers a los volúmenes de la SAN, y pum!, ya se está amortizando el TCO. Caso contrario (NO recomendado por supuesto), el TCO crece paulatinamente mientras transcurre el tiempo de soporte (acercandose cada día el momento en que será descontinuado por el fabricante y tendremos que comprar tiempo de soporte adicional, entre otras varias circunstancias desfavorables y no recomendables para el proyecto "comprar SAN").


El caso más usual
En realidad, el caso usual donde se trabaja implementando tecnología informática nueva de infraestructura implica una adopción paulatina, relativamente limitada, y atendiendo a necesidades puntuales (es decir, donde no se va a utilizar más que una mínima cantidad de características técnicas del sistema).

Por ejemplo, se intenta elevar el grado de awareness de la organización respecto de un creciente número de servidores. Así que se estudia y decide implementar paulatinamente Nagios como solución de monitoreo básico.

- Se instala y configura Nagios, se carga una configuración básica que permita ping monitoring (ver si los servidores están "activos" pingueandolos cada cierto tiempo). Adicionalmente se configura el mecanismo de alerta para que envié mails en el evento de falla del ping monitoring de cualquier server.

- En una mejora subsiguiente de solución, se incorpora una estructura de autenticación vía SSH keys en el servidor Nagios, y se le agrega a Nagios el monitoreo de sistemas internos de los servidores (basado en acceso vía SSH). Esto mejora mucho la solución inicial de "ping monitoring only".

- En una tercera instancia, se incorpora el uso de agentes locales en los servidores a monitorear. Añadiendo así un nivel de sofisticación (y capacidades adicionales), muy superior al obtenido en la 2da. instancia vía monitoreo basado en acceso SSH.


Conclusiones
Como se puede deducir del ejemplo de implementar Nagios paulatinamente, el nivel de conocimiento de Nagios de los administradores de sistemas va a ir creciendo a medida que vayan trabajando con Nagios, recorriendo la curva de aprendizaje de a poco, sin por ello dejar de brindar e implementar la solución de monitoreo requerida por la organización.

Si tuviéramos que proceder en modo "de cero a todo", la curva de aprendizaje se hace mucho más grande (hay que aprender muchas cosas en poco tiempo), y por ende, *2 si los administradores no tienen el beneficio de un entrenamiento brindado por terceros (un curso, etc.), normalmente la organización va a quedarse *1 sin monitoreo para sus servidores por un tiempo muy largo hasta que los administradores de sistemas tengan los conocimientos necesarios para implementar Nagios "de cero a todo".

*1 Si además hay un tiempo límite, no implementar la solución de "cero a todo" por estar aprendiendo, ello podría tener repercusiones negativas en la organización; probablemente el monitoreo se estaba necesitando - con tiempo límite - por razones puntuales. Por ejemplo, reevaluación del ciclo de vida típico de los servers por apagado/reinicio contínuo por fallas en el suministro eléctrico.

*2 La capacitación de alto nivel técnico, especialmente orientada a capacitar administradores de sistemas a nivel "de cero a todo", y en poco tiempo (semanas, máximo meses), tiene costos tan altos que cuando se compra hardware de nivel industrial (SANs por ejemplo), el porcentaje de costo del entrenamiento suele ser de dos guarismos (10%, 15%, etc.), del costo de adquisición del hardware.

Por todo eso es que las implementaciones paulatinas son las más habituales.