Las soluciones IT completas y un ejemplo con infraestructura virtual vSphere

En este artículo cuento cómo en gral. las soluciones "completas" no lo son, y hay que completarlas para que realmente cumplan con el objetivo para el cual fueron pensadas. Hay además comentarios sobre los ámbitos de responsabilidad de provedores IT terceros y la relación de los proveedores IT internos de una organización con su cliente principal (la organización).


Soluciones buenas, pero parciales
Es común ver en infraestructura que al comprar una solución IT, la empresa acuerda el trabajo a realizar, viene a la empresa/organización, realiza el trabajo y luego se va. Dejando garantías vigentes, por un tiempo, bajo ciertas condiciones, etc.

Por ejemplo, la instalación de una infraestructura vSphere: se instalan los hipervisores, se monta el server vCenter, se agrega los hipervisores al vCenter, se deploya algunas máquinas virtuales - probablemente no?, y listo (hasta ahí es el trabajo acordado con el proveedor de servicios IT en este ejemplo). El cliente luego toma la posta desde ahí, administrando todo la infraestructura - virtual ahora. Instalando, migrando sistemas operativos de físico a virtual, etc. etc.

El precio de un trabajo puntual de infraestructura y sus límites son indispensables, sino la empresa proveedora va a hacerse cargo hasta el infinito de cualquier cuestión relacionada con lo que instaló/configuró inicialmente.


Soluciones IT completas
Ahora, el caso de las áreas de sistemas internas en la organización es bien diferente. Cada área IT interna en una organización tiene la obligación de sostener la continuidad de la infraestructura en el tiempo, a largo plazo. 

Lo que es muy diferente de la obligación de proveedor IT comercial, sin embargo es común encontrar el caso de que las soluciones IT internas en una organización se implementan "por única vez", y luego se las abandona "como están" y sin tomar en cuenta la prerrogativa de mantenimiento y mejora contínua (que es en gral. un requerimiento del puesto para los empleados del área IT interna por cierto).

Siguiendo el ejemplo de la infraestructura vSphere, algunos pasos posteriores a la "simple" instalación y configuración de una infra virtual vSphere podrían ser (más o menos en orden de importancia estratégica-técnica): 

1) Implementar backup automatizado de la configuración del vCenter (y su DB de backend)

2) Implementar backup automatizado de la configuración de los ESXi,

3) Deployar (comprar en gral.) una solución de backup virtual (Veem, etc.), para las máquinas virtuales en sí,

4) Implementar chequeo de configuraciones automatizado (extraer toda la configuración de vSphere, volcar a un GIT o similar, y luego ir haciendolo regularmente, para tener un registro centralizado exacto de cada cambio en la configuración), AKA "configuration management".

5) Implementar monitoreo de la infraestructura virtual (hay varias maneras)

6) Deployar un vSphere Update Manager (para mantener todos los hipervisores actualizados/parcheados), 

7) Implementar alta disponibilidad para vCenter (o sea, montar otro server vCenter, de alguna de las varias maneras posibles),

8) Implementar automatización en el mantenimiento necesario para vCenter (tip: la DB de backend necesita atención de a ratos).

9) Cómo proceder, y qué hacer exactamente desde lo técnico para recuperar la caída/cuelgue/fuera de servicio de cualquier componente de la infraestructura virtual vSphere (incluye tener instaladas y configuradas las herramientas necesarias, los planes, y que los que vayan a haber la recuperación, hayan realizado prácticas y pruebas de campo para saber que toda las políticas/procedimientos/herramientas funcionan realmente como deberían).

Etc.


Si se fijan, extrapolando la idea general del ejemplo, cualquier infraestructura necesita básicamente (además de la instalación, configuración y puesta en producción inicial): 

- Backup, 
- Configuration Management, 
- Monitoreo y Optimización/Mantenimiento/Mejora Contínua.
- Añadir redundancia/resiliencia adicional (como parte de la mejora contínua)
- Plan de acción de recuperación de desastres.

Sin todos esos detalles (y varios más no mencionados), la solución puede "estrellarse" con mucha facilidad y dejar de funcionar apropiadamente, y con algo de mala suerte además, inesperadamente (por ejemplo: madrugada de año nuevo, 3 de la mañana, llamada del dueño de la empresa al personal IT, cayendo a las 3.10 cuando el personal que usa el sistema le acaba de avisar de que no anda. "Casos de uso": clínica de guardia, farmacia de guardia, empresa de seguridad, polícia, etc.).


Completar la solución
Si una solución integral no incluye lo anterior, habría que ir preguntando al proveedor cuanto saldría implementar backup, config management, monitoreo, y disaster recovery...o pensar cómo se hace internamente para completar la solución de infraestructura. Normalmente esas tareas tercerizadas implica un precio mayor que la instalación/configuración inicial, ese precio más alto es realmente una mejor aproximación al TCO real de la solución.

TCO:
http://es.wikipedia.org/wiki/Coste_total_de_propiedad

* Esto es cuestión de opiniones, pero para completar más el TCO de la solución, se podría agregar la previsión/estimación de costos futuros del lifecycle management, por ejemplo, previendo una migración de plataforma. 

Siguiendo el ejemplo: preveer un posible/eventual path de migración de Vmware vSphere 5.1 (+ ESXi) hacia Microsoft Hyper-V 2012 + System Center 2012 Virtual Machine Manager .

Por ejemplo: tener que comprar una SAN "ahora":
- aumenta el TCO de la solución vSphere, pero 
- baja el TCO de la - posible a futuro - solución Hiper-V 2012, pero, 
- en gral. hace disminuir el TCO de la solución "Infraestructura Virtual" 
(que es lo que le interesa a la organización en realidad), y por lo tanto genera un "path de migración" aceptable, y se concluye que comprar la SAN "estaría bueno" :-)


Ambitos y tiempos limitados
Las áreas IT internas tienen un ámbito de injerencia y obligaciones para con la infraestructura IT por lejos mucho mayor que casi cualquier solución "llave en mano" que pueda proveer un tercero, ya que inclusive con el mejor presupuesto disponible, el ámbito de injerencia de un proveedor IT tercerizado siempre - pero siempre - está limitado a determinadas tareas y obligaciones, y a un rango de tiempo - contratado - durante el cual le va a responder al cliente. Y luego del cual, ya no va a tener obligación de responderle al cliente. 

El área IT interna por otra parte no está limitada en absoluto de sus obligaciones para con la organización, a la que debe responder por obligación organizacional (o sea, independientemente de quién/es estén integrando esa área como empleados/responsables), de modo contínuo, y tiene la responsabilidad de completar y subsanar cualquier limitación que exista en la infraestructura. 

Siguiendo el ejemplo: el que en la solucion "llave en mano" no haya previsto un mecanismo de backup para los hipervisores ESXi. Si no lo hace el proveedor, es obligación del área IT interna completar la solución.


La obligación contractual del proveedor IT, siempre tiene un límite práctico: el tiempo máximo contratado y qué tanto trabajo se puede hacer durante ese tiempo. Aunque y a pesar de que se suele contratar: 
- "soluciones completas", 
- "soluciones llave en mano", 
- "soluciones integrales", 

y demás buena jerga de vendedor IT, por más que esté "prometido" las soluciones provistas por un tercero nunca van a poder ser integralmente completas, sino solamente van a estar de acuerdo a lo contratado (una lista de tareas que figura en el contrato), cualquier tarea adicional, paga o no, es a discreción y buena voluntad del tercero proveedor. 

...A menos que directamente se los contrate permanentemente para hacer el trabajo del área interna IT...ooops, pero ese contrato también tiene una duración máxima, así que no, no es posible sostener la tercerización ilimitada, siempre va a haber que pagar más o contratar servicios adicionales para poder tener una tercerización ilimitada (por eso es tan buen negocio por cierto :-).


Conclusión
Es bastante seguro decir, falta de presupuestos infinitos mediante, que eventualmente toda organización/empresa se va a volver a hacer cargo de sus propias necesidades de informatización, y lo mejor es que sea lo antes posible y con el mejor grado de previsión y responsabilidad.