La infraestructura tecnológica de una compañía debe soportar sus procesos de negocio y permitir ofrecer productos y servicios a los clientes. El fallo en el mantenimiento de esta infraestructura, incluyendo sus aplicaciones de soporte, puede tener un impacto negativo en el negocio. Por lo tanto, las compañías deben desarrollar planes para garantizar la disponibilidad continua de sus sistemas y procesos de negocio.

1. La infraestructura tecnológica de la compañía tiene un objetivo fundamental:
soportar los procesos de negocio que permiten a la corporación ofrecer productos y
servicios a los clientes. El fallo en el mantenimiento de una infraestructura de TI,
incluyendo sus aplicaciones de soporte, que deben estar completamente disponibles
y operando de forma óptima, se traduce en un impacto negativo para el negocio.
Una vez comprendida la relación entre los procesos de negocio y los servicios y
elementos de la infraestructura, una compañía puede desarrollar un plan de soporte
para garantizar la “disponibilidad del negocio”.
Aunque, desafortunadamente, la elaboración de un plan de disponibilidad del
negocio se ve limitada por la escasa disponibilidad de estándares de integración,
tales como servicios web, la explosión de algunas tecnologías y la ejecución en
entidades separadas (por ejemplo, aquellas empresas cuyos procesos se requieren
de manera sistemática para ofrecer conjuntamente un servicio), su trascendencia
está animando a las compañías a emprender tales proyectos, denominados “calidad
de servicio” y “gestión del nivel de servicio”. Y, además, con resultados positivos.
Dentro del esfuerzo global necesario para garantizar la continuidad del servicio y la
disponibilidad del negocio, la gestión de infraestructura y capacidad desempeña un
papel fundamental. Definido en términos generales, el objetivo de los proyectos de
gestión de la capacidad consiste en dar dimensión a la infraestructura para
garantizar la provisión consistente de los niveles de servicio acordados. Es el
balance entre el coste de la infraestructura y el nivel deseado de servicio el que
tiene un papel crucial en las decisiones de compra finales. Por ejemplo, la relajación
del requisito de tiempo de respuesta para las transacciones online de una aplicación
clave puede reducir la capacidad necesaria y sus gastos asociados. En este caso, el
ejercicio de la planificación de capacidad se enfocaría entonces en la identificación
de las alternativas de configuración que pueden ofrecer el servicio al menor coste
posible.
Debería ser obvio reconocer que una parte integral orientada a garantizar que los
sistemas están operando satisfactoriamente requiere un proceso de “verificación de
servicio”, que informa sobre cualquier desviación en la calidad de servicio ofrecido
de acuerdo con los niveles contratados. Además, la actividad de planificación
estratégica añade la dimensión de “previsión de servicio” para garantizar que los
niveles de servicio se mantendrán en el futuro.
Aunque muchas compañías realizan un ejercicio de gestión de capacidad una vez al
año al objeto de prepararse para el ciclo presupuestario, pocas reconocen la
importancia de este ejercicio en el contexto de un proceso bien descrito que implica
una actividad continua. De hecho, se puede hablar de que el proceso de gestión del
rendimiento comprende tres grandes fases:
- Observar las tendencias diarias e históricas en el comportamiento del sistema y
generar informes de seguimiento.
- Analizar los datos para identificar cuellos de botella que pueden afectar los niveles
de servicio o detectar recursos no utilizados.

2. - Predecir futuros niveles de servicio frente a un incremento en las cargas del
sistema o cambios en la configuración.
Seguimiento, análisis, predicción
Este proceso en tres fases tiene su base en un proceso de recolección continua de
datos que es exacto, completo, fiable y eficaz, y que tiene en cuenta no sólo datos a
nivel del sistema, sino también los de la aplicación. Es crucial que la metodología de
colección de datos seleccionados contemple estos cuatro criterios, pues hacer
recomendaciones sobre datos sospechosos (es decir, aquellos cuya exactitud no se
puede verificar por métodos probados) o incompletos (por ejemplo, los datos no
representan correctamente las relaciones intrínsecas entre las variables, o carecen
de granularidad y contenido), conducen a los fenómenos bien conocidos como
garbage-in y garbage-out. Además, a menos que la recolección de dichos datos sea
fiable y eficaz, no será parte de un proceso de producción bien sintonizado.
Las aplicaciones para este continuo proceso de “seguimiento-análisis-predicción”
son muchas y muy bien adecuadas al entorno actual de negocio. Sirvan como
ejemplo las de “workload balancing”, diagnóstico de problemas, análisis de cuellos
de botella, consolidación de servidores y estrategias de contingencia.
Un elemento común en cada una de estas aplicaciones es el de reportar sobre la
calidad del nivel de servicio que será proporcionado. Hacemos una parada en este
punto para formular la siguiente cuestión: “¿cómo se define la calidad del servicio?”.
Los actuales entornos tecnológicos son tan complejos que las herramientas de
medición no han sido capaces de soportar la representación de una transacción
entre múltiples capas de aplicaciones, plataforma y red. Mientras que la calidad es
sencilla de definir en términos de disponibilidad (por ejemplo, la infraestructura que
da soporte al servicio debe estar disponible el 100% del tiempo durante la actividad
online), la definición de la calidad en términos de valores de rendimiento, tales como
el tiempo de respuesta del usuario final, descansa en los avances realizados por los
fabricantes de hardware y software.
Las transacciones “robotizadas” ejecutadas desde varias estaciones de medición o
websites constituyen una de las diferentes técnicas utilizadas en la actualidad para
intentar medir la experiencia del tiempo de respuesta por el usuario final del servicio.
Sin embargo, el seguimiento de tales transacciones a medida que fluyen a través
del sistema con el objeto de identificar el peso de cada componente del sistema en
el tiempo total de respuesta no está bien descrito y es un área donde se está
llevando a cabo mucha labor de investigación. Aún así, todavía se puede hacer
mucho con las herramientas disponibles y establecer acuerdos de nivel de servicio
entre el departamento técnico y la consistencia del usuario no debería ser un
obstáculo.
Si algo va mal
Pero, ¿qué hacer si algo va mal? Por supuesto, esta cuestión lleva al tópico general
de planificación en caso de contingencias, un proceso que normalmente involucra
dos áreas principales. Por un lado, la identificación de los riesgos para los servicios

3. TI y la determinación de prioridades para la recuperación de servicios críticos y
datos; por otro, el desarrollo y verificación de los planes en una serie de escenarios
de contingencia.
De nuevo, la dimensión apropiada del sistema de backup que se utilizará para
absorber los servicios críticos constituye otro elemento donde la gestión de la
capacidad encaja perfectamente, ya que conlleva la comprensión de la carga de
trabajo (solamente ese subconjunto crítico basado en el análisis de
riesgos/prioridades) que estará operativa y el nivel de servicio que se ofrecerá (en
muchos casos, un nivel de servicio diferente se puede formalizar para abordar
situaciones de contingencia).
Enlazando con la anterior premisa, nuestro análisis nos lleva ahora a preguntarnos:
¿es la recuperación de los elementos de la infraestructura tecnológica un factor
básico para nuestro negocio?. De nuevo