Presentado por: Asesor:

(1)

DEPARTAMENTO DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN PROYECTO DE GRADO

Caracterización y Modelado de Variables Para el Cálculo de SLT de Disponibilidad

Presentado por:

Juan Carlos Ruiz Casallas

Asesor:

Oscar Javier Ávila Cifuentes

Universidad de los Andes 2016-1

(2)

(3)

Tabla de Contenido

Resumen ...5

1. Introducción ... 6

2. Descripción y Problema ... 9

2.1 Contexto... 9

2.2 Problema e Importancia ... 9

2.3 Objetivos ...10

2.3.1 Objetivo General ...10

2.3.2 Objetivos Específicos ...10

2.4 Alcance ... 11

3. Estado del Arte ... 12

3.1 Métodos Existentes ... 12

3.2 Negociación de SLA ... 15

4. Diseño ... 17

4.1 Recolección de Información ... 17

4.1.1 Síntesis de Enfoques Teóricos: Cálculo de SLAs ... 17

4.1.2 Síntesis de Enfoques Teóricos: Negociación de SLAs ... 18

4.1.3 Síntesis de Fuentes de la Industria ... 18

4.2 Alternativas de Diseño ... 19

4.2.1 Alternativas de Descripción de Variables ... 19

4.2.2 Alternativas de Representación de Relaciones Causales ... 19

4.2.3 Alternativas de Representación de Dominio ... 20

5. Metodología ... 22

5.1 Revisión Bibliográfica ... 22

5.2 Unificación y Selección de Variables ... 22

5.3 Definición del Gap ... 22

5.4 Clasificación de Variables ... 23

5.5 Desarrollo de Esquemas ... 23

5.6 Verificación ... 23

6. Resultados ... 24

6.1 Tabla de Variables ... 24

6.2 Gap ... 33

6.3 Diagrama de Ciclos Causales ... 34

6.4 Modelo Instanciable ... 38

7. Validación ... 41

(4)

7.1 Métodos ... 41

7.2 Caso de Estudio... 41

7.3 Instanciación del Modelo ... 43

7.4 Validación de Resultados ... 45

8. Conclusiones ... 47

8.1 Discusión ... 47

8.2 Trabajo Futuro... 48

9. Referencias ... 49

(5)

Resumen

Actualmente existe entre las empresas una tendencia a tercerizar servicios en la nube.

Esto ha incrementado la importancia de los Acuerdos de Nivel de Servicio (SLA), los cuales definen, a través de un proceso de negociación, los compromisos entre cliente y proveedor y los niveles del servicio. Entre los factores decididos está la disponibilidad del servicio. Existen propuestas desde la academia para el cálculo de la disponibilidad y modelos para estimarla o predecirla. Pero estos no están unificados, y en su mayoría abordan la disponibilidad como una cualidad técnica de una infraestructura, no la sitúan en el proceso de negociación, ni para calcularla tienen en cuenta variables relacionadas con el cliente. Así, en este proyecto se analizan las propuestas actuales; y se identifican, clasifican y relacionan las variables útiles a la hora de calcular la disponibilidad en un contexto de negociación de acuerdos de nivel de servicios en la nube.

(6)

1. Introducción

Hoy en día, una alta disponibilidad es un imperativo para los proveedores de servicios de TI [1]. De hecho, se ve como una necesidad creciente si se tiene en cuenta la tendencia en las empresas a adoptar plataformas, infraestructura y servicios en la nube [5]. Con la adquisición de un servicio de TI por parte de una empresa viene la aceptación o negocia- ción de SLAs. Los SLAs abordan la disponibilidad del servicio como una métrica que indica la habilidad de un servicio de TI u otro elemento de configuración para realizar la función acordada cuando es requerido [6], y para esta definen un nivel esperado.

Algunos proveedores no son abiertos a negociación e imponen sus propios acuerdos de nivel de servicio, limitando al cliente a dos opciones: aceptarlos o no contratar el servicio;

mientras que otros sí permiten negociar. Los procesos de negociación para servicios en la nube son importantes dado que las partes involucradas son independientes, y poseen objetivos y requerimientos de calidad del servicio distintos [1]. Sin embargo, a pesar de la existencia de múltiples proveedores de servicios en la nube, aún es imposible ver claramente cuáles garantizan, o al menos ofrecen, un acuerdo acorde a los intereses o necesidades del cliente [3]. Y muchas veces los valores acordados no son suficientes para el cliente, o exceden sus necesidades. Esto teniendo en cuenta que la mayoría de los com- pradores con aplicaciones sensibles al desempeño requieren mínimo 99.9%, existiendo muchos que buscan proveedores con 99,99% o más [36].

Y es que es entendible la poca alineación entre los valores contratados y los necesitados.

A pesar de la existencia de gran variedad de propuestas para el cálculo de la disponibilidad, la mayoría de estas se enfocan en aspectos técnicos y dejan a un lado otros factores [1]. Los métodos de estimación resultan complejos en términos de su aplicabilidad y no contemplan el contexto de negociación. Estos modos de abordar la disponibilidad pueden ser correctos al considerar un proveedor interno o una infraestructura propia, pero resultan infactibles e insuficientes si se trasladan a los modelos de negocio en la nube actuales.

Por otro lado, es pertinente resaltar que, si bien los métodos existentes para el cálculo y la predicción de la disponibilidad postulan una amplia gama de variables, no hay unidad entre ellas. Es decir, son definidas, medidas y utilizadas de manera distinta [2]. Unas sólo son pertinentes en los modelos propuestos o en las situaciones contextuales limita- das por el estudio. Mientras que otras variables, no son siquiera tenidas en cuenta, pues como se mencionó anteriormente, el grueso de los estudios aborda la disponibilidad como una métrica del proveedor y no involucran variables relativas al cliente. Para la

(7)

construcción de un modelo que sea útil y acertado en el cálculo de la disponibilidad se debe tener en cuenta un conjunto de variables relevantes alusivas tanto a cliente como proveedor, el cual actualmente no existe de manera explícita.

Es de tener en cuenta que el alcance de este proyecto de grado se limita a las variables y sus relaciones, dado que es desarrollado como parte de un proyecto de investigación de mayor tamaño. Por esto, en aspectos de diseño no se ahonda en los modelos de estima- ción o predicción de la disponibilidad, sino en las variables, su uso y sus relaciones.

En este orden de ideas, y con el objetivo de caracterizar este grupo de variables, clasifi- carlas, y modelar escenarios de negociación de SLAs. Para esto se crean tres entregables:

una tabla de variables, un diagrama de ciclos causales y un modelo instanciable. La me- todología seguida para la obtención del conjunto de variables se divide cuatro fases: re- visión bibliográfica de fuentes múltiples, unificación, selección y clasificación. Luego, se analizan las relaciones entre las variables identificadas a partir del diagrama de ciclos causales y del modelo instanciable, igualmente soportados en la literatura. Finalmente, el modelo instanciable se verifica con un caso de estudio.

Como resultados se evidencian un grupo de 14 variables relevantes propuestas con base en las fuentes de información consultadas y el análisis de los procesos de negociación de SLAs, además de cinco variables extra no contempladas anteriormente pero igualmente importantes al contexto del problema. Estas se clasifican según su naturaleza en variables referentes al proveedor o al cliente, y según los modelos de negocio en la nube (SaaS, PaaS, IaaS). Además, se identifican las relaciones de dependencia y causalidad entre las variables por medio del diagrama de ciclos causales. El modelo instanciable, a su vez, busca ser una base para la creación de un método de predicción de la disponibilidad.

Entre las conclusiones de este estudio, se encuentra que el diagrama de ciclos causales es una herramienta útil para modelar las relaciones entre las variables que afectan la disponibilidad, y que este se podría extender con un modelo matemático en un futuro.

Con respecto al modelo instanciable, se corrobora, a partir de un caso de estudio, que permite el mapeo y la instanciación de escenarios de negociación teniendo en cuenta las variables encontradas. Ambos entregables están orientados a la generación de reglas de decisión basados en estos y a la construcción futura de modelos de predicción o estima- ción de la disponibilidad. Siempre primando la aplicabilidad y fácil uso de los modelos propuestos.

El presente documento está estructurado de manera que se entienda a cabalidad el proceso de obtención del conjunto de variables relevantes para el cálculo de la disponibilidad en contextos de negociación de SLAs, y el desarrollo de los diagramas. En las siguientes secciones se encuentra el desarrollo de la problemática tratada, los objetivos, anteceden-

(8)

tes, la metodología, las fuentes de información, los resultados obtenidos y las conclusiones que abordan tanto una discusión sobre el trabajo realizado como un posible trabajo futuro.

(9)

2. Descripción y Problema

2.1 Contexto

Anteriores formas de tercerizar, caracterizadas por enfocarse únicamente en reducción de costos, están dando paso a nuevas oportunidades creativas de generación de valor [4].

Son los consumidores los que no se están enfocando en tener servicios en infraestructura propia, sino en optimizar las relaciones con sus proveedores y en mejorar la flexibilidad operacional [5]. De hecho, para los próximos años se proyecta un crecimiento del mercado de la tercerización de tecnologías de la información en varias dimensiones, inclu- yendo funcionalidades, servicios y localización [5].

Sin embargo, el crecimiento de la tercerización también acarrea riesgos. Una baja inver- sión en gestión de proveedores y de servicios podría llevar fácilmente a pérdida de valor, desgaste del talento humano y problemas con la calidad de los servicios [5]. Por lo anterior, clientes y proveedores deben trabajar de manera conjunta. Por parte del proveedor, es necesaria una mayor atención en tener las capacidades correctas, ideas innovadoras y la experticia en la industria que es requerida. Y por parte del cliente, iniciativas de gestión y gobierno de capacidades. Así, son estas relaciones colaborativas entre proveedores y compañías las que contribuyen a la calidad del servicio [5].

Y es que estas relaciones entre proveedor y cliente se identifican desde la adquisición del servicio en la nube, independientemente de su naturaleza (IaaS, PaaS o SaaS). Entre los múltiples contratos y documentos propios de estas dinámicas están los Acuerdos de Ni- vel de Servicios. Los SLAs son acuerdos entre el cliente y proveedor de servicios de TI, que documentan los niveles de servicio a alcanzar y especifican las responsabilidades de ambas partes [6]. Uno de los aspectos cruciales definidos en un SLA es el nivel de disponibilidad. La cual es la habilidad de un servicio de TI u otro elemento de configuración para realizar la función acordada cuando es requerido [6].

2.2 Problema e Importancia

Este proyecto se establece a la par de un proyecto de investigación de mayor magnitud, por lo que para entender el problema que se intenta resolver hay que contemplar dos dimensiones: primero la de un problema global, y luego sí la de un problema específico contenido en este, el cual respecta a este proyecto.

A pesar de la existencia de múltiples modelos para estimar la disponibilidad, estos no son aplicables a la industria, específicamente bajo el contexto de negociación de SLA de servicios en la nube. Esto principalmente ocurre por la complejidad tanto en término de

(10)

método como de variables tomadas en cuenta para su cálculo. Y no es de extrañarse, pues la gran mayoría de estos métodos son propuestos para condiciones distantes a la reali- dad. Así, el problema global es la inexistencia de un método para el cálculo de la dispo- nibilidad, el cual se caracterice por su aplicabilidad, certeza y conveniencia en procesos de negociación.

Como se mencionó, parte de la baja aplicabilidad de los modelos se debe a las variables que estos usan. En general, las variables involucradas difieren de modelo en modelo, y no contemplan variables relativas a los clientes sino solo al proveedor.

Más aún, es posible que solo sean aplicables para modelos particulares y bajo escenarios específicos. De este modo, el problema particular, abordado en este proyecto de grado, se resume en que el conocimiento de las variables es limitado, sesgado a los proveedores y hasta cierto punto contaminado por la presencia de variables no relevantes.

Ambos problemas, tanto el global como el particular, son relevantes en el contexto ac- tual. La tendencia a tercerizar servicios de TI, así como la carencia latente de métodos aplicables para el cálculo de la disponibilidad causan que el número de clientes insatis- fechos tras procesos de negociación crezca día a día. Si bien los servicios en la nube han tenido un rápido crecimiento dirigido por la combinación de macro tendencias del mercado, todo negocio debe prestar más atención al cambio de las necesidades de sus consumidores para retener su mercado y expandir sus relaciones [7]. Y cómo no, tener estas necesidades en cuenta desde el inicio de la relación con el cliente, cuando se establecen los SLA. Pues no solo se podría estar arriesgando un contrato, sino una relación cliente- proveedor a largo plazo. De este modo, la existencia de un método acertado y fácil de usar es relevante, al igual que un conjunto de variables claramente definido para la cons- trucción de este.

2.3 Objetivos

2.3.1 Objetivo General

 Plantear las bases para la proposición de un marco de referencia que permita el cálculo de las metas de nivel de servicio SLT relacionadas con la disponibilidad.

2.3.2 Objetivos Específicos

 Analizar y extraer variables que afecten la disponibilidad tanto de fuentes acadé- micas como de la industria

 Perfilar y agrupar las variables que afectan la disponibilidad encontradas

 Generar una tabla de descripción y clasificación de variables clave en el proceso de negociación de SLT de disponibilidad

 Identificar las relaciones entre las variables propuestas

(11)

 Formular un modelo útil para el mapeo de escenarios de negociación de SLAs de disponibilidad

2.4 Alcance

Este proyecto se ve enmarcado en otro proyecto de investigación que se encarga del mé- todo de estimación de la disponibilidad en escenarios de negociación de SLA. De este modo, y como se puede evidenciar en los objetivos, este proyecto se limita a la identifi- cación, selección, clasificación y relacionamiento de las variables clave, que a su vez se- rían la base para el modelo.

(12)

3. Estado del Arte

Teniendo en cuenta el alcance del proyecto, el estado del arte se puede analizar desde dos perspectivas. Una primera que abarca una muestra representativa de los métodos existentes para el cálculo de la disponibilidad (y con estos sus variables, que serían lo pri- mordial para este estudio); y otra que aborda la definición y negociación de los acuerdos de nivel de servicio.

3.1 Métodos Existentes

Se presenta a continuación un recuento de 15 métodos distintos propuestos para el cálculo de la disponibilidad. Los métodos presentados son vigentes y publicados en ar- tículos de investigación de fuentes indexadas.

Rodrigues, Rosenbaum y Uchitel [8] usan escenarios para la predicción de la disponibilidad de componentes concurrentes. Los escenarios les permiten ver cómo interactúan los elementos de un sistema para proveer el nivel de funcionalidad deseado. Toman como base las probabilidades de fallo de cada componente, y las probabilidades de transición.

Para la predicción de la disponibilidad del software usan el modelo Cheung a partir del esquema de comportamientos del sistema. Su aporte radica en tener en cuenta la estruc- tura de componentes que tienen los escenarios y la naturaleza concurrente que se presenta en estos [8].

Ghafarian y Deldan [9] se enfocan en el cálculo de la disponibilidad bajo un ambiente de grid computing, caso interesante dada la volatilidad y la heterogeneidad de los compo- nentes de este tipo de topologías. Ellos proponen dos enfoques, el primero basado en un autómata celular y el segundo en una red bayesiana. Tras comparar ambos enfoques indican que es el autómata celular el que logra una predicción más acertada de la disponibilidad.

Immonen y Niemelä [10] abordan el cálculo de la disponibilidad desde la perspectiva de la arquitectura de software. Dado que es en la fase de definición de la arquitectura donde se puede evaluar el grado de cumplimiento de los requerimientos funcionales y no funcionales. Así, proponen un marco de referencia para comparar métodos de estimación de la confiabilidad y la disponibilidad de arquitecturas de software. Además de identificar el método más adecuado para cada arquitectura. Concluyen que ningún método de estimación es completo, y que son necesarias otras actividades de investigación para su- perar estas falencias.

(13)

Bartsch, Mevius y Oberweis [11] van más allá que otros estudios antes mencionados, ata- cando la disponibilidad no como una cualidad de una infraestructura sin mayor contexto, sino como una cualidad propia de las capacidades de un proveedor de servicios. Ellos postulan un enfoque basado en redes de Petri para modelar y simular servicios en térmi- nos de los niveles de disponibilidad. A pesar de que señalan que su metodología podría asistir a proveedores de servicios y sus clientes al negociar SLAs, en sus estudios no se ven reflejadas variables referentes a estos últimos. Además, si bien se rescata el hecho de la simulación de procesos enfocada en la disponibilidad, ellos admiten que se encuentra en una etapa temprana, inmadura, y que es necesaria mayor investigación [11].

Bosse [12] también aborda el problema teniendo en cuenta a los proveedores de servicio, e incluye entre sus variables los errores del operario. Con esta, plantean un nuevo diseño para la predicción de la disponibilidad de servicios de TI, también basado en redes de PETRI [12]. No son ellos los primeros en tener en cuenta esta variable humana. Tokuno y Yamada [13] modelan la disponibilidad de un sistema integrando tanto hardware como software en un proceso de Markov. En su modelo, también integran los errores del operario, pero estos no son modelados directamente. Es por esto que Bosse plantea este nuevo enfoque, e incluso señala que el uso de redes de Petri estocásticas para la simula- ción garantiza la flexibilidad de método para futuras extensiones [12].

Rahman, Hassan y Buyya [15] proponen un enfoque de predicción basado en un índice de Jaccard soportado por un algoritmo de aprendizaje lento que busca por la mejor coin- cidencia en una secuencia dentro de los datos históricos. Todo esto con el fin de predecir la disponibilidad de una máquina específica en el sistema. Su método sobrepasa a otras tres técnicas en una comparación por simulación. Y se rescata de este enfoque la importancia que se le asigna al comportamiento histórico de un componente del sistema.

Por su parte, Benlarbi se enfoca en investigar los desafíos de medir una disponibilidad de punto a punto, dadas las distintas capas de resiliencia en una arquitectura jerárquica de la red [16]. Para su medición, propone un enfoque de cuatro capas y modelos analíti- cos de agregación de medidas de disponibilidad y confiabilidad. Es claro que este aporte al problema tuvo un contexto particular, pero que se enfoca a profundidad en la infraestructura y arquitectura de red como variables clave al momento de estimar la disponibilidad de servicios ofrecidos por un proveedor.

Koutras, Platis y Limnios [17] proponen un modelo de mantenimiento de software, e incluyen el concepto de una falla del sistema inducida por una acción de mantenimiento mal realizada. Como herramientas predictivas usan cadenas de Markov de tiempo continuo, y estimadores de máxima verosimilitud para los parámetros. Estos últimos se proponen dado que se ha demostrado que son más eficientes que los usuales estimadores empíricos usados en el estudio del mantenimiento de software, siendo esta la mayor in- novación que propone el estudio [17]. Con el modelo pueden extraer estimados para la disponibilidad y la confiabilidad de un sistema. Sin embargo, se identifican limitaciones

(14)

prácticas en este enfoque, no solo por la complejidad de sus modelos, sino por el sesgo a el área del mantenimiento de software.

Goseva-Popsojanova y Trivedi [18] abordan la estimación y predicción de la disponibilidad de un sistema desde la arquitectura basada en componentes. Postulan que este tipo de enfoque es relevante dado que va más allá de la costumbre de ofrecer únicamente enfoques de caja negra, ajenos a la tendencia de reusar componentes autónomos pero interrelacionados [18]. Así, se trata de unificar los métodos de predicción de la disponibilidad basados en arquitecturas de software, y postulan aspectos a tener en cuenta como los fallos codependientes, la validez de las suposiciones en modelos que involucren proceso de Markov, o la consideración de múltiples atributos de calidad; pues pueden con- llevar a predicciones inexactas [18].

Immonen y Niskanen [23] atacan el problema de la detección de incidentes en la disponibilidad y la confiabilidad de los sistemas después de su implementación, cuando la co- rrección de fallas y modificaciones es tanto difícil como costosa. De este modo, se enfocan en la predicción de la disponibilidad desde los modelos arquitecturales. Para esto no solo plantean un modelo, sino que desarrollan una herramienta que permite la representa- ción de la disponibilidad en la arquitectura [23].

Gokhale y Trivedi [19] postulan que la predicción de la disponibilidad de un sistema de software basada en su arquitectura, y en el fallo de sus componentes es esencial. Además, explican que los avances en el área de la predicción de la disponibilidad en este tipo de sistemas se enfocan en modelos analíticos o dependientes del estado. Por la falta de uni- cidad de estos modelos, ellos proponen un marco de referencia para modelos de este tipo que buscan la predicción de la confiabilidad y la disponibilidad basándose en arquitecturas [19]. Dada la gama de modelos, limitan el alcance del marco de referencia a modelos que usan cadenas de Markov de tiempo continuo o de tiempo discreto.

Franke, Johnson y König [20] desarrollaron un marco de referencia de arquitectura em- presarial para el modelado y evaluación cualitativa y cuantitativa de los servicios empre- sariales de TI. Rompen el paradigma de enfocarse en métodos únicamente cuantitativos como árboles de fallos o métodos cualitativos como la evaluación de modelos de madu- rez. Su marco de referencia se compone de modelos, meta-modelos relaciones y atributos correctos para representar la disponibilidad. Ellos no se limitan a proponerlo, sino que lo prueban en nueve casos de estudio. Concluyen que su propuesta destaca por su preci- sión y carácter único (dada la combinación de enfoques) [20].

Bocciarelli y D’Ambrogio [21] se enfocan en la computación orientada a servicios, en la que se ven procesos de negocio compuestos de funciones provistas por servicios modu- lares y estandarizados [21]. De este modo, se enfocan en un método dirigido por modelos que permite describir y predecir de manera automática los niveles de calidad en servicios

(15)

web. Este modelo se basa en WSDL, BPEL y UML [21]. Punto importante de esta inves- tigación fue la inclusión de arquitecturas orientadas a servicios y el relacionarlas con los atributos de disponibilidad y confiabilidad.

Mohanta, Vinod, Ghosh y Mall [22] se enfocan en la etapa de desarrollo de software como base principal para la predicción de la confiabilidad de un sistema. Primero predicen, como también lo hacen otros, la disponibilidad de cada componente. Luego, construyen una red bayesiana de creencias para la predicción de la confiabilidad de los componen- tes usando métricas propias del software como cohesión de los métodos, empareja- miento entre objetos o factores de polimorfismo [22]. Tras la prueba de su modelo en un caso de estudio confirman su efectividad.

3.2 Negociación de SLA

Así como existen métodos para la predicción o estimación de la disponibilidad en contextos específicos, también han sido propuestos esquemas de negociación de SLA. Estos esquemas se caracterizan por su generalidad, pues no se enfocan en un atributo de calidad o métrica específica, como lo es la disponibilidad del servicio. Así pues, a continua- ción, se presenta una muestra de los distintos enfoques existentes dentro del marco de la negociación de SLA.

La fuente para la consecución de los siguientes trabajos fueron las bases de datos: Sprin- ger, IEEE y ACM. Además de la búsqueda en Google Scholar. Se tuvo en cuenta la relevancia usando para la búsqueda términos referentes a la negociación de SLAs como: sla, negotiation, framework, methodology, estamation o cloud.

Existen propuestas de sistemas de soporte para la definición y gestión de los SLA, como el planteado por Machado y Stiller [24]. Su modelo preliminar es un enfoque para la construcción de un sistema de soporte de SLA en escenarios de computación en la nube.

Si bien el objetivo de este es correcto, e incluso alineado en cierta medida con el de este proyecto (pues buscan un incremento de la especificidad de los SLA según el cliente), toma las distintas consideraciones desde un muy alto nivel, limitando y dejando su aplicabilidad relegada a futuros estudios.

Por su parte, Dingle Knottenbelt y Wang [25] atacan las ambigüedades de las que sufren los SLA en su especificación, y las falencias de monitoreo de los mismos. Para esto, proponen el uso de un árbol de desempeño, el cual es un esquema gráfico para la cuantifica- ción y verificación de propiedades de desempeño [25]. Y entre las métricas que analizan están la disponibilidad, el tiempo de respuesta, la utilización de los recursos y el throughput [25].

Con el mismo objetivo de Dingle et al., trabajan Comuzzi, Kotsokalis, Spanoudakis y Yahyapuor, quienes buscan establecer y monitorear SLAs en sistemas complejos basados en servicios [26]. Muestran cómo los procesos de establecimiento y monitoreo de SLA

(16)

están ligados. Para esto siguen un Marco de Referencia de Gestión de SLA definido en SLA@SOI EU FP7 Integrated Project [26]. Resalta de este estudio el uso de datos histó- ricos para la evaluación de las ofertas de SLAs y para la evaluación de la capacidad de medición de SLA que posee el proveedor de servicios.

Leitner, Ferner, Hummer y Dustar se enfocan en la predicción automática de violaciones a los SLAs en servicios compuestos [27]. Este aspecto tiene relevancia si se tiene en cuenta la estrecha relación existente entre los incumplimientos de SLA de disponibilidad y las penalizaciones que presentan los proveedores. El marco de referencia propuesto permite la prevención de incumplimientos, asociando a cada tipo de suceso el tipo de modelo predictivo más apropiado [27]. Sin embargo, admiten que la verosimilitud de los resultados arrojados por sus modelos no es clara, y que estos deben estudiarse a mayor profundidad [27].

Cambiando de enfoque; Skene, Lamanna y Emmerich proponen un lenguaje basado en XML para la definición de SLAs llamado SLAng [28]. Primero desarrollan la sintaxis de este en UML y luego lo relacionan con un modelo descriptivo del comportamiento de los servicios. En este último se esquematizan los comportamientos tanto de las partes (cliente/proveedor) como de los servicios. Pese a esto, SLAng no fue lo suficientemente validado por sus creadores, por lo que se considera que su aplicabilidad es limitada [28].

En términos de negociación, Köppel, Böning y Abeck abordan el problema del gap de conocimiento entre el proveedor y el cliente [29]. Siendo este la falta mutua de conocimiento sobre estructuras organizacionales y sobre aspectos técnicos del entorno de apli- caciones. A partir de la naturaleza y el tamaño de este gap, un asignador de SLA revela las partes del SLA que se deben negociar [29]. Su trabajo incluye múltiples referencias a variables por parte de cliente y proveedor, pero falla al no profundizar en los atributos de calidad del servicio.

Wu, Garg y Buyaa, por su parte, proponen un marco de referencia para la negociación automática de SLAs de servicios de computación en la nube [30]. Ellos atacan el problema de la complejidad de la negociación cuando existen múltiples proveedores [30].

Frente a esto, plantean el uso de un mediador basado en heurísticas que tienen en cuenta el tiempo, las limitaciones mercado y los parámetros de calidad del servicio. En cuanto a resultados, las funciones objetivo del método propuesto son la maximización de utilidades y en la mejora de la satisfacción del cliente, ambas probadas [30].

(17)

4. Diseño

En esta sección se presenta un resumen de la información utilizada para la generación del conjunto de variables, además de un análisis y selección de los modelos de represen- tación de dominios a utilizar.

4.1 Recolección de Información

Se tuvieron en cuenta dos tipos de fuentes: artículos académicos, y documentos de proveedores y empresas consultoras. Como base teórica académica se tomaron los enfoques presentados en la sección previa. Si bien se entiende que en trabajos de investigación lo ideal es una base teórica académica y corroborada, se encuentran pertinentes fuentes externas dado que aterrizan la búsqueda de variables a un contexto real.

4.1.1 Síntesis de Enfoques Teóricos: Cálculo de SLAs

Como se presentó en el estado del arte, los artículos académicos se enfocan en dos áreas.

Primero, artículos relacionados con métodos de cálculo de la disponibilidad; y segundo, artículos relacionados con la negociación de SLA. La razón de ser de elegir estas dos perspectivas fue que la mayoría de los artículos del primer grupo no contemplan variables relativas al cliente, sí contempladas por los segundos. A continuación, se presenta enton- ces una condensación de los métodos de disponibilidad, apoyado también en la revisión bibliográfica hecha por Bosse, Spileth y Turowski [31].

Figura 1. Clasificación de los enfoques para la predicción de la disponibilidad con métodos de ejemplo. [31]

Se ve una diferencia entre los enfoques de caja blanca y de caja negra. Los primeros se basan en datos medidos mientras que los segundos en información de la arquitectura.

Los enfoques de caja blanca se subdividen en tres categorías: combinatorios, basados en un espacio de estados y de carácter jerárquico [32].

Caja blanca

Caja Negra

Combinatorio

Jerárquico Espacio de Estados

 Diagrama de dependencia de la confiabilidad

 Árbol de fallos

 Cadenas de Markov

 Redes de Petri

 Diagrama de dependencia dinámico de la confiabilidad

 Árbol de fallos dinámico

(18)

En los métodos con enfoque combinatorio, se modelan los servicios como conjuntos de elementos independientes. Si bien este tipo de enfoque da resultados rápidos en térmi- nos computacionales, se rezaga al impedir el modelamiento de relaciones más complejas [31]. Por lo que se considera limitada su capacidad de predicción [31] [32].

Los enfoques basados en espacios de estados son más poderosos en términos de modelamiento y predicción, pues permiten mapear relaciones complejas entre los componentes de un sistema [31]. Sin embargo, este mayor poder también implica un incremento de la complejidad de los mismos, y como no, una reducción de su usabilidad [32]. Por otro lado, los enfoques jerárquicos separan el modelamiento de disponibilidad y de componentes. Este aspecto ayuda a reducir la complejidad frente a los basados en espacios de estados [31].

4.1.2 Síntesis de Enfoques Teóricos: Negociación de SLAs

Con respecto a los artículos de negociación de SLA se evidencia que la gran mayoría están enfocados en hacer que una herramienta o soporte tecnológico facilite la definición de los SLA. Entre estas herramientas destacan sistemas de negociación de SLAs, asignado- res de SLAs, mediadores, y lenguajes descriptivos de SLA en XML. Todos los enfoques estudiados tienen en cuenta tanto a proveedor como cliente, y contemplan variables de cada uno.

Otros aspectos que son igualmente estudiados son la relación entre el establecimiento y el monitoreo de SLAs, para lo que se usan árboles de desempeño basados en datos histó- ricos; o la relación entre violaciones de SLAs y los niveles de estos establecidos en un comienzo.

4.1.3 Síntesis de Fuentes de la Industria

Entre las fuentes externas, se eligieron para analizar los acuerdos de nivel de servicios de proveedores reconocidos como Oracle, IBM, Amazon, HP, etc., para los tres modelos de servicios en la nube (SaaS, IaaS, PaaS) según los ofrecieran. Además de artículos publicados por estos o por empresas consultoras como Deloitte o Gartner, y revistas en temas de TI reconocidas y de publicación periódica.

Los SLAs de grandes proveedores fueron útiles para ampliar el rango de variables. Pues si bien los estudios contemplan elementos que desde el sistema y la arquitectura afectan la disponibilidad, no tienen en cuenta factores extras que pueden verse involucrados y pactados en términos de la negociación [33, 34, 35, 36, 37].

Los SLAs de los proveedores difieren incluso en servicios que podrían considerarse comparables. Pero el objetivo de este estudio no la comparación de proveedores, ni de los términos contractuales de sus SLAs. De hecho, Gartner en 2012 indicó que debido a cláu-

(19)

sulas y trucos contractuales de los proveedores los SLAs podrían estar perdiendo signifi- cado [42]. Por lo que se usaron únicamente para identificar factores comunes que pudie- ran ser pactados en contextos normales de negociación. Entendiendo a estos últimos como contextos en los que se parte de que existen aspectos predefinidos por el proveedor y que solo existe un conjunto limitado de puntos de negociación, entre los que se encuentra el nivel de disponibilidad del servicio.

Así pues, se identificó que entre puntos de los SLAs que los proveedores establecen pre- viamente están: métodos de soporte técnico, modos de medición de la disponibilidad, porcentajes máximos de disponibilidad, frecuencia de medición y la mesa de ayuda. Pero en aspectos como número de usuarios concurrentes, precio, sanciones o porcentajes mí- nimos de disponibilidad; los clientes podrían (y deberían) tener la potestad de negociar.

Claro, teniendo en cuenta que la mayoría de proveedores de gran tamaño, como los analizados, dejan sus SLAs en un “tómalo o déjalo” para el cliente.

4.2 Alternativas de Diseño

4.2.1 Alternativas de Descripción de Variables

Dada la existencia de distintas maneras de exponer la caracterización de variables se pre- firió la que tuviera una representación fácil de interpretar y pudiera ser de rápida aplica- ción. Por esto, frente a la realización de un manual de variables o el desarrollo de una tabla descriptiva se optó por esta última. Esta no solo permite caracterizarlas sino tam- bién facilita su clasificación y rápida depuración.

4.2.2 Alternativas de Representación de Relaciones Causales

Tras definir el grupo de variables es necesario representar sus relaciones causales. Para esto se contemplaron tres distintos modelos causales, siendo estas representaciones abs- tractas que describen los mecanismos de un sistema, las cuales van más allá de una co- rrelación entre los elementos [38]. Los tres modelos en consideración fueron: diagrama de ciclos causales, diagramas de Ishikawa y redes bayesianas.

Los diagramas de ciclos causales buscan facilitar la visualización de cómo distintas variables de un sistema se relacionan [39]. Se componen de nodos y relaciones. Los nodos representan las variables; y las relaciones pueden ser positivas o negativas. Si son positivas cuando una variable aumenta o disminuye la otra también, mientras que si son negativas la relación es inversa. Con estas relaciones se construyen ciclos que pueden ser de refuerzo o de balance, de este modo se modelan relaciones cíclicas no visibles a simple vista [39].

Por otro lado, los diagramas de Ishikawa, también llamados diagramas de espina de pes- cado, muestran las causas de un evento específico (en este caso, un nivel de disponibilidad [40]. Las causas o variables causales son agrupadas en distintas categorías, y luego

(20)

ubicadas en las vertientes de un árbol horizontal. Sin embargo, estos diagramas se utili- zan en mayor medida en el diseño de productos, y podrían llegar a ser insuficientes para este estudio [40].

Las redes de Bayes son modelos gráficos probabilísticos que representan un conjunto de variables aleatorias y sus dependencias condicionales por medio de un grafo acíclico directo [41]. Partiendo tan solo de esta definición se puede encontrar ya un inconveniente, pues para el cálculo de la disponibilidad puede que existan variables no probabilísticas, y puede que existan ciclos subyacentes entre estas. Y aunque claro, se podrían transfor- mar las variables de modo que su uso en este tipo de diagramas fuera correcto, y se po- drían tener modelos alternos y equivalentes a aquellos con ciclos causales, esto agrega una carga de trabajo significativa.

Se optó por relacionar las variables por medio de un diagrama de ciclos causales debido a que este cumple con el objetivo de representar las codependencias de manera gráfica.

Modela de manera sencilla pero poderosa las relaciones complejas entre variables. Y ade- más existen herramientas que no solo los grafican, sino que permiten incluir en ellos modelos matemáticos, que aunque no sean del alcance de este proyecto, pueden posibi- litar su extensión.

4.2.3 Alternativas de Representación de Dominio

También se busca modelar el dominio del problema en un esquema que permita describir casos reales y que sirva como base para la construcción de un modelo de estimación de la disponibilidad. En este orden de ideas, las dos alternativas que se contemplaron fueron el desarrollo de un metamodelo/modelo instanciable o de una ontología.

Un metamodelo o modelo instanciable es el modelo de un modelo. Se puede definir como un arquetipo explícito de los bloques constructivos y las reglas necesarias para la cons- trucción de modelos específicos dentro de un dominio de interés [47]. Los metamodelos están estrechamente relacionados con las ontologías, pues ambos se usan para describir y analizar las relaciones entre conceptos.

Una ontología se define como una colección de términos interrelacionados y el conjunto de reglas de inferencia sobre estos [44]. En otros términos, las ontologías expresan algo importante dentro de un dominio utilizando una gramática [47]. Las ontologías de dominio se caracterizan por representar los conceptos de una manera muy específica, por lo que en ocasiones son incompatibles entre ellas [45]. De hecho, conforme los sistemas soportados en ontologías se expanden, se suelen unir las ontologías de dominio a una representación más general [45].

Luego de entender ambas alternativas se decidió desarrollar un modelo instanciable y no una ontología. Si bien ambos facilitan el modelamiento del escenario de negociación de SLAs, los metamodelos permiten una instanciación directa y no caen en el problema de

(21)

la sobre especificación del contexto. Más información se encuentra disponible sobre procesos de meta-modelado y modelado, que sobre desarrollo de ontologías. Además, se considera que los modelos son menos abstractos y más aplicables, que lo que podría ser una ontología para este proyecto.

Tras elegir un metamodelo como medio de representación del contexto de la negociación de SLAs, se define UML como su lenguaje. Si bien se podría usar un lenguaje ad-hoc, si se tiene en cuenta el postulado de Piotrowski y Krawczyk [43] es visible que UML no sólo resulta apropiado, sino que brinda ventajas frente a otros lenguajes. Primero, UML al ser un lenguaje de uso común en las ciencias de la computación permite el entendimiento rápido del metamodelo sin pasar antes por una curva de aprendizaje. Y segundo, el modelamiento de escenarios de negociación ya está probado con UML, lo que da una garan- tía previa de su efectividad [43].

(22)

5. Metodología

Como resultados de este proyecto se tienen: una tabla descriptiva con las variables finales que se encontraron útiles para el cálculo de la disponibilidad según las fuentes de información consultadas, un diagrama de ciclos causales que relaciona estas variables, y finalmente un modelo instanciable que sitúa las variables de manera abstracta en el escenario de negociación de SLA.

Los entregables anteriormente mencionados fueron fruto de una implementación por fases: revisión bibliográfica, unificación de variables, selección de variables, definición del GAP, clasificación de variables y desarrollo de esquemas. Se presenta a continuación la descripción de cada una.

5.1 Revisión Bibliográfica

Esta etapa abarcó la revisión de las fuentes descritas en la sección de Recolección de In- formación. Se llevó una lectura juiciosa de estas, haciendo especial énfasis en las variables que cada autor propone, y en las identificadas de los documentos de proveedores.

Las variables se organizaron en una tabla descriptiva. Las variables que de manera explí- cita son iguales se asumen como una sola, y se recopila para cada variable a los autores que la toman en cuenta para sus modelos.

5.2 Unificación y Selección de Variables

Esta etapa abarcó la unificación de variables de naturaleza similar, lo que permitió la reducción del número de variables casi a la mitad. Así como la eliminación de variables relacionadas directamente con los modelos específicos de cada autor, dado que no eran relevantes fuera de estos. Además, también hubo una eliminación de variables que según la bibliografía tenían poca influencia o solo eran relevantes en contados escenarios [31].

5.3 Definición del Gap

¹

Tras definir claramente las variables, se analizó a mayor profundidad el desfase existente entre las usadas por las metodologías propuestas en los estudios analizados que busca- ban el cálculo o predicción de la disponibilidad, y las establecidas por este proyecto. Así

1 Se mantiene la palabra gap para hacer referencia a la diferencia entre el estado actual y un estado deseado alcanzado al desarrollar este proyecto

(23)

como también se justificó la relevancia de cada una de estas, teniendo en cuenta el aná- lisis de fuentes externas y de los estudios que tenían un enfoque orientado a la negocia- ción de los SLAs y no al cálculo de la disponibilidad.

5.4 Clasificación de Variables

En esta etapa el conjunto de variables se clasificó según si era el cliente o el proveedor quien tenía poder de decisión o de cambio sobre la variable al momento de negociar, esto para cada tipo de servicio (SaaS, IaaS y PaaS). Todo sobre la misma tabla descriptiva.

Esta clasificación se encuentra útil dado que un modelo que prediga la disponibilidad debe contemplar las distintas influencias de los involucrados en el proceso de definición de los aspectos del SLA.

5.5 Desarrollo de Esquemas

Se desarrollaron dos esquemas, un diagrama de ciclos causales y un modelo instanciable.

El primero relaciona las variables con la disponibilidad, y expone las relaciones entre estas. El segundo, abstrae el contexto de negociación de manera que un caso de negocia- ción pudiera ser descrito y modelado con este.

5.6 Verificación

Se tomaron dos procesos de verificación, una verificación continua y una verificación final. La verificación continua se desarrolló a lo largo del desarrollo iterativo de los entregables, comparando las distintas fuentes de información, las tablas y los diagramas contra la realidad visible. Por otro lado, la verificación final se desarrolló sobre los entregables finales y su objetivo era validar el cumplimiento de los objetivos del proyecto y la viabilidad de estos para ser la base de un modelo de estimación de la disponibilidad. Para esto se partió de un caso de negociación de disponibilidad el cual luego se mapeo como una instanciación del modelo.

(24)

6. Resultados

Se presentan a continuación las versiones finales de cada uno de los entregables, su ex- plicación e importancia para el proyecto.

6.1 Tabla de Variables

La Tabla 1 detalla los siguientes aspectos sobre las variables:

● Nombre: nombre de la variable, consensuado entre los distintos postulados por la literatura y luego de unificar variables.

● Descripción: Breve descripción de la variable para contextualizarla. Algunas por ser compendios de variables por lo que se define el grupo, las características en común.

● Negocio o tecnología: Clasificación de las variables en estas dos naturalezas, importante para la creación del modelo instanciable.

● Proveedor o cliente: Clasificación según quién controla, se ve afectado o es dueño directo de la variable.

● Autores: serie de autores que han hablado de la variable, algunas variables son nuevas por lo que no todas tienen este campo.

● Unidad de medida: Unidad utilizada en los estudios, dada la variedad de mé- todos se proponen para varias de las variables escalas ad-hoc.

● SC/SP/IC/IP/PC/PP: Clasificación según los modelos de servicio en la nube SaaS, IaaS y PaaS. Y quién tiene poder de decisión sobre la variable, el cliente o el proveedor. No se tienen en cuenta intereses sino potestades de cambio.

La importancia y el uso de esta tabla de variables se ve en la construcción de los modelos de estimación de la disponibilidad. El conocer las variables pertinentes y su naturaleza permitirá el planteamiento de modelos más adecuados según el escenario que se esté manejado, y además aumentará la completitud de estos dado que se incluyen variables antes no contempladas.

(25)

Nombre Descripción Negocio o

Tecnología Proveedor

o Cliente Unidad de medida SC SP IC IP PC PP Autores Calidad de métodos de medición de

la disponibilidad Sistemas, herramientas y procesos para medir las métricas

acordadas Tecnología Cliente Escala ad-hoc SC SP IC IP PC PP Stuart Rance, Hewlett Packard

Mejores Prácticas Mejores prácticas en almacenamiento y redundancia: pre- vención de fallos de aplicaciones y red; monitoreo; infraes-

tructura física, backup, etc. Tecnología Proveedor Puntaje de mejores prácti-

cas SC SP IC IP PC PP Franke, U; Johnson P & König J Complejidad Complejidad del servicio en término de tamaño o funciona-

lidades. Negocio Cliente Escala ad-hoc SC SP IC IP PC PP Köppel A.

Costo Costo del proveedor de dar el servicio Negocio Proveedor Unidades monetarias SC SP IC IP PC PP Immonen A & Niemelä E.

Presupuesto Presupuesto máximo del cliente Negocio Cliente Unidades monetarias SC SP IC IP PC PP Stuart Rance, Hewlett Packard

Recurso Humano Habilidades del recurso humano involucrado en la gestión

del servicio Negocio Proveedor Estimador numérico de ca-

pacitación de RH SC SP IC IP PC PP -

Tiempo medio entre fallas Tiempo medio para que un sistema en estado activo pase a

estado inactivo Tecnología Proveedor Unidades de tiempo SC SP IC IP PC PP -

Tiempo medio de restablecimiento del servicio

Tiempo medio para que un sistema en estado inactivo sea reparado. Agregado de tiempos de reparación de compo-

nentes individuales Tecnología Proveedor Unidades de tiempo SC SP IC IP PC PP

Franke, U; Johnson P & König J |Gokhale S &

Trivedi K. |Dingle N; Knottenbelt W. & Wang L.

|Bartsch C; Mevius M. & Oberweis A. | Stuart Rance, Hewlett Packard

Ubicación física Grado de distribución de las ubicaciones físicas de los ser-

vidores Tecnología Cliente Escala ad-hoc SC SP IC IP PC PP

Franke, U; Johnson P & König J | Machado G &

Stiller B. | Dingle N; Knottenbelt W. & Wang L. | Bartsch C; Mevius M. & Oberweis A. | Stuart

Rance, Hewlett Packard Tiempo de inactividad planeado Tiempo fuera de servicio planeado del servicio Negocio Cliente Unidades de tiempo SC SP IC IP PC PP Stuart Rance, Hewlett Packard

Tiempo de respuesta Tiempo desde que un usuario envía una petición hasta que

recibe una respuesta. Negocio Cliente Media, varianza y percentil SC SP IC IP PC PP Stuart Rance, Hewlett Packard Sanciones Sanciones que debería pagar el proveedor en caso de in-

cumplimiento Negocio Cliente Unidades monetarias SC SP IC IP PC PP Leitner P; Ferner J; Hummer W. & Dustdar S. | Dingle N; Knottenbelt W. & Wang L. | Benlardi S.

|Köppel A | Stuart Rance, Hewlett Packard Criticidad del servicio e impacto Qué tan importante es la disponibilidad de ese servicio Negocio Cliente Escala ad-hoc SC SP IC IP PC PP -

Comportamiento de la demanda Comportamiento de la demanda del servicio Negocio Cliente Vector de demandas prome-

dio anuales SC SP IC IP PC PP Köppel A. | Stuart Rance, Hewlett Packard Procedimientos de soporte Grado de efectividad de los procedimientos de soporte para

el servicio Negocio Cliente Escala ad-hoc SC SP IC IP PC PP Köppel A.

Tamaño de la infraestructura del

proveedor Tamaño de la infraestructura del proveedor en términos de

calidad y buenas prácticas que siga este Tecnología Proveedor Escala cualitativa SC SP IC IP PC PP -

Throughput Tasa promedio en la que ocurren una serie de actividades Tecnología Cliente Unidades/tiempo SC SP IC IP PC PP Machado G & Stiller B.

Usuario Tipos de usuarios que interactuarán con el servicio, su pro-

porción y necesidades de disponibilidad Negocio Cliente Porcentaje SC SP IC IP PC PP Dingle N; Knottenbelt W. & Wang L.

Elasticidad del servicio Capacidad del servicio para adecuarse a la demanda del

momento Tecnología Proveedor Escala ad-hoc SC SP IC IP PC PP Immonen A & Niemelä E.

Convenciones:

SC Saas Cliente

SP Saas Proveedor PC Paas Cliente

PP Paas Proveedor IC Iaas Cliente IP Iaas Proveedor

Tabla 1. Tabla de varaibles causales y clasificación de poderes en modelos de la nube

(26)

Además de lo anterior se define de manera clara cada variable y su unidad de medida, la cual es un factor fundamental para una instanciación correcta del modelo.

Nombre Calidad de métodos de medición de la disponibilidad

Descripción

Cada proveedor tiene entre sus procesos métodos para medir la disponibilidad de los servicios que ofrece. Estos están relacionados con la identificación de posibles fallos y con la garantia de una me- dición correcta para el cliente.

Unidad de medida Escala ad-hoc

Descripción unidad de medida / Cálculo

La escala ad-hoc para esta variable se define de la siguiente manera:

0 No hay sistemas de medición fiables

1 Existe un único sistema de medición sin fiabilidad del mercado

2 Existen buenas prácticas y redundancia en sistemas de medición

3

Se aplican los mejores estándares a los sistemas de medi- ción y permite la integración de sistemas de medición por parte de los clientes.

Nombre Mejores prácticas

Descripción

Esta variable retoma todas las mejores rpácticas en procesos que debe tener un proveedor según ITIL. Entre estas están mejores prácticas en operaciones, control de ccambios , almacenamiento de datos, etc.

Unidad de medida Puntaje de falta de mejores prácticas Descripción unidad de medida / Cálculo

El puntaje de falta mejores prácticas se calcula con base en 14 elementos que debería tener un proveedor. Y a cada uno de estos se le asigna un peso distinto [20]. Se presentan los factores con su peso porcentual.

 Redundancia en entorno físico e infraestructura [10%]

 Solución técnica de backup [7%]

(27)

 Prevención de fallos en servicios externos [8,7%]

 Soluciones cliente servidor resilientes [3,6%]

 Requerimientos y entrega [25,2%]

 Solución de procesos de backup [3,6%]

 Redundancia en la red [7,6%]

 Monitoreo de componentes relevantes [26,1%]

 Operaciones [23%]

 Redundancia de arquitectura de datos y almacenamiento [9,6%]

 prevención de fallos de red [18,3%]

 Control de cambios [28,1%]

 Prevención de fallos en aplicaciones internas [16,9%]

 Locación física [3,3%]

Para obtener le puntaje simplemente se suman los porcentajes teniendo en cuenta que un valor bajo es lo más deseable, y uno cercano a 100% lo menos deseable.

𝐸𝑠𝑡𝑖𝑚𝑎𝑑𝑜𝑟 = ∑ 𝑖

𝐹𝑎𝑐𝑡𝑜𝑟 𝑖∈ 𝐹𝑎𝑐𝑡𝑜𝑟𝑒𝑠

Nombre Complejidad

Descripción

Grado de uso que da el servicio a la infraestructura, software nece- sarios para su funcionamiento y las distintas interrelaciones que posee.

0 No existe complejidad alguna en el servicio o es muy baja

1

Hay una complejidad baja. El servicio es casi indiferente para el proveedor, en ningún sentido es una dificultad pro- veerlo.

2 Hay una complejidad media. El servicio usa mediana- mente la infraestructura.

3

Hay una alta complejidad. El servicio utiliza de manera in- tensiva la infraestructura del proveedor y posee un alto acoplamiento entre componentes

(28)

Nombre Costo

Descripción

El costo que puede cobrar el proveedor teniendo en cuenta su mar- gen de utilidades. Se divide en costo de uso anual del servicio y costo de implementación

Unidad de medida Unidades monetarias

El proveedor tiene un monto monetario a ganar mínimamente por cada servicio que ofrece.

Nombre Presupuesto

Descripción Presupuesto del cliente. Se divide en presupuesto de uso anual del servicio y presupuesto de implementación

El cliente tiene destinada un presupuesto para un servicio en particular por un periodo de tiempo estimado, o a largo plazo sin estimar un periodo de tiempo, pero estando acorde a sus capacidades de inversión.

Nombre Recurso humano

Descripción

Grado de capacitación del recurso humano involucrado en la mesa de servicios del proveedor o en general en sus procesos internos relacionados al servicio

Unidad de medida Estimador numérico de capacitación de recurso humano Descripción unidad de medida / Cálculo

El estimador se construye a partir de las áreas en las que se involucra el recurso humano, cada una de estas tiene un grado de involucramiento (numérico de 0 a 1) y un factor de importancia (numérico de 1 a 3). Para cada área se estima en una escala de 1 a 5 el grado de capacitación. El estimador se obtiene de la siguiente manera:

𝐸𝑠𝑡𝑖𝑚𝑎𝑑𝑜𝑟 = ∑ 𝑖𝑛𝑣𝑜𝑙𝑢𝑐𝑟𝑎𝑚𝑖𝑒𝑛𝑡𝑜𝑎𝑟𝑒𝑎∗ 𝑖𝑚𝑝𝑜𝑟𝑡𝑎𝑛𝑐𝑖𝑎𝑎𝑟𝑒𝑎∗ 𝑔𝑟𝑎𝑑𝑜𝐶𝑎𝑝𝑎𝑟𝑒𝑎 𝐴𝑟𝑒𝑎 𝑎𝑟𝑒𝑎

Según este estimador, calculado por el proveedor, entre mayor sea el valor, mejor. Claro, los valores del indicador dependen del número de áreas del proveedor y son comparables dentro de este.

(29)

Nombre Tiempo medio entre fallas (MTBF)

Descripción

El MTBF es el tiempo promedio en que un servicio de TI u otro elemento de configuración pueden llevar a cabo la función que se ha acordado en forma ininterrumpida [6]. Esto se mide desde el momento en el elemento de configuración comienza a trabajar, hasta su próxima falla. [6]

Unidad de medida Unidades de tiempo

Este es un cálculo reconocido en la industria que los proveedores pueden tomar con base en sus registros históricos de comportamiento del servicio.

Nombre Tiempo promedio de restablecimiento del servicio (MTRS)

Descripción

Es el tiempo promedio necesario para restablecer un servicio de TI u otro elemento de configuración después de una falla. El MTRS se mide desde el momento en el elemento de configuración falla hasta que quede completamente restaurado y realiza su función en forma normal.[6]

Descripción unidad de medida

Este es un cálculo reconocido en la industria que los proveedores pueden tomar con base en sus registros históricos de comportamiento del servicio.

Nombre Ubicación física

Descripción Grado de replicación y mejores prácticas en la ubicación de servidores que soportan el servicio.

0 No hay redundancia de datos, un mismo servidor sin es- tándares claros

1 Existe redundancia pero dentro de un mismo territorio.

2 Existe redundancia de servidores en distintos países o continentes. Se presentan altos estándares de calidad.

(30)

3 Hay una redundancia territorial compleja, sincronización de datos en tiempo real, altos estándares

Nombre Tiempo de inactividad planeado

Descripción

Tiempo que según el proveedor es tiempo de mantenimiento y no se tiene en cuenta entre los cálculos de la disponibilidad. Lo define el proveedor y entre más grande sea este tiempo se podría estimar una mayor disponibilidad en términos contractuales.

Definida por el proveedor con base en sus procesos internos de mantenimiento de la infraestructura.

Nombre Tiempo de respuesta

Descripción

Tiempo desde que un usuario realiza una petición al sistema hasta que recibe la respuesta. Se estiman tiempos promedio y umbrales permitidos

Unidad de medida Tiempo máximo de respuesta Descripción unidad de medida

Definido por el proveedor con base en sus procesos y capacidades de TI.

Nombre Sanciones

Descripción

Las sanciones en dinero que se definen en un acuerdo de SLAs.

Estas pueden influir en el valor de la disponibilidad negociada, y forzar en cierta medida al proveedor a cumplir los acuerdos

El proveedor tiene una experiencia previa con respecto a los valores que podrían generar san- ción y a las sanciones que estaría dispuesto a pagar. El cliente, sabe la retribución económica a la que equivale la no disponibilidad de su servicio.

Nombre Criticidad del servicio e impacto

(31)

Descripción

Para el cliente qué tan importante es el servicio contratado, en tér- mino de las capacidades que este soporta. Y cuál es el impacto que tendría una no disponibilidad o una disponibilidad parcial de este.

0 El servicio no es crítico en ninguna medida, casi que se ad- quiere por deber

1 Hay una baja criticidad, no habría perdidas en caso de no funcionar

2

Existirían pérdidas significativas en caso de no funcionar pero el servicio no soporta procesos centrales de la empresa

3 El servicio es completamente crítico y su fallo podría aca- rrear un alto impacto al negocio del cliente

Nombre Comportamiento de la demanda

Descripción

Cómo es el comportamiento de la demanda del servicio en término del número de usuarios por unidad de tiempo. Su relevancia radica en que comportamientos no esperados en términos de carga en el servicio podría causar problemas con la disponibilidad.

Unidad de medida Vector de demanda

Se define un vector que indica cada hora cómo es la demanda en todo un año, en término de usuarios concurrentes. Así pues, los ciclos del negocio se ven correctamente mapeados en una función discreta. Para esto es necesario un trabajo predictivo de la demanda o los datos históri- cos de esta.

Nombre Procedimientos de soporte

Descripción

Los procedimientos para el soporte con los que lidiarían los clientes, los que pertenecen al proveedor. Unos malos procesos podrían influir en mayores periodos de no disponibilidad o disponibilidad limitada llegado el caso de un error.

(32)

0 Los procedimientos de soporte no son claros y no están estandarizados

1 Procedimientos claros pero en unos lapsos de tiempo no aceptables para la disponibilidad deseada

2 Hay procedimientos de soporte aceptable, están documentados y estandarizados

3

Se garantiza un soporte completo para las necesidades, los procesos están documentados y estandarizados. La disponibilidad no se vería comprometida.

Nombre Tamaño de la infraestructura del proveedor

Descripción

Entre más robusta sea la infraestructura del proveedor sus servicios estarán mejor soportados. Así los procedimientos de soporte, y las probabilidades de fallo del servicio se ven disminuidas.

El tamaño de la infraestructura se mide de manera relativa con respecto al servicio. De modo que es factible que una misma infraestructura tenga distintas clasificaciones para distintos servicios.

0 La infraestructura es insuficiente para soportar de manera óptima el servicio.

1 Infraestructura suficiente, pero con posibles fallos y falta de redundancia.

2 Infraestructura más que suficiente de un proveedor reconocido, pero posibles errores si se exceden los umbrales esperados de uso del servicio

3 Infraestructura que supera las necesidades del servicio de modo que en periodos de mayor utilización los riesgos de fallo son mínimos

Nombre Throughput

Descripción

Tasa en la que suceden las transacciones, de modo que si es muy alta pueden impactar el rendimiento y la disponibilidad del sistema. Por lo que los requerimientos del cliente deben ser cubiertos por las capacidades del proveedor.

Unidad de medida Operaciones por Unidad de tiempo Descripción unidad de medida

(33)

Este valor debe ser definido por ambas partes, de modo que el proveedor expone su máximo y el cliente el mínimo necesario.

Nombre Usuario

Descripción Usuario que va a usar el servicio, qué tan relevante es este usuario y cuántos como él hacen uso del servicio.

Unidad de medida Tipo de usuario y proporción Descripción unidad de medida

Cada tipo de usuario tiene una proporción y una importancia para el negocio en una escala de 1 a 5.

Nombre Elasticidad del servicio

Descripción

Si el proveedor para este servicio ofrece opciones de elasticidad de capacidades. Este factor permitiría altos periodos de solicitudes sin impactar negativamente el rendimiento o la disponibilidad. Al igual que permitiría disminuir costos para el cliente.

0 No se ofrece elasticidad

1 Elasticidad parcial en ciertos momentos 2 Elasticidad completa con costo adicional 3 Elasticidad completa sin costo adicional

6.2 Gap

Parte del objetivo de este proyecto es identificar variables que no se tienen en cuenta en los estudios enfocados en el cálculo de la disponibilidad. El grupo antes mencionado con- tiene tanto variables contempladas como no contempladas. Las variables no contempladas surgen de los estudios enfocados en la Negociación de SLAs, y de las fuentes externas (proveedores y consultoras) también ya expuestas.

Así pues, luego de realizar el análisis de brecha se encontró que las variables: dinero (costo o presupuesto), elasticidad, comportamiento de la demanda, criticidad del ser- vicio y sanciones por incumplimiento del contrato, no se tienen en cuenta en la literatura que plantea modelos de cálculo de la disponibilidad. Más aún, estas variables son importantes para el cálculo de esta métrica en el contexto de la negociación de SLAs. Es enten-

(34)

dible que estos modelos no las incluyeran, pues como se mencionó, tratan la disponibilidad como una cualidad del proveedor o el dueño de la infraestructura y no como una variable a negociar entre dos partes.

El dinero limita tanto al cliente como al proveedor, y la disponibilidad del servicio debe estar claramente ligada a lo que el cliente está dispuesto a pagar, y ser acorde a lo que el proveedor espera recibir. Por su parte, la criticidad del servicio y el comportamiento de la demanda determinan los rangos en los valores mínimos y máximos de la disponibilidad a través del tiempo. Ligado a esto está la posibilidad de que el sistema sea elástico, lo que impacta directamente costos.

A su vez, las sanciones cobran importancia al ser un factor que hacen que el proveedor ofrezca menos y tienda a cobrar más, y que el cliente también esté dispuesto a pagar más (sabiendo que en caso de un fallo no contemplado estaría protegido). De modo que puede acordarse un costo bajo, pero con altas sanciones asociadas a un umbral de incumplimiento.

6.3 Diagrama de Ciclos Causales

El diagrama de ciclos causales realizado es una representación gráfica de las relaciones de interdependencia entre las variables. Las flechas indican la dirección del efecto y el signo (positivo o negativo) indica el tipo de relación entre las variables. Si es positivo hay una relación directa, por lo que si una incrementa la otra también; mientras que si es negativo la relación es inversa, y si una aumenta la otra disminuye.

Por su parte, las líneas punteadas reflejan asociaciones de negocio, no necesariamente causales. Por ejemplo, se reconoce que el tipo de usuario impacta el comportamiento, pero no tiene sentido establecer esta relación como positiva o negativa. Como eje central se encuentra la disponibilidad, de manera que se muestra cómo las distintas variables la afectan de manera directa o indirecta.

(35)

Figura 2. Diagrama de ciclos causales.

Variable Impactante

Variable

Impactada Relación Justificación

Recurso Humano Disponibilidad Positiva Directa

Entre mejor esté capacitado el recurso humano mayor es la disponibilidad, pues los tiempos de solu- ción de errores y la posibilidad de caída del servicio por error humano disminuyen.

Mejores Prácticas Recurso Hu- mano

Positiva Directa

Las mejores prácticas ayudan a for- malizar los procesos internos del proveedor entre los que se ven afec- tados los de soporte y demás recursos humanos intervinientes en el ci- clo de vida del servicio.

Mejores Prácticas Procedimien-

tos De Soporte Positiva Directa

Mejores prácticas en las operaciones impactan los procesos de soporte.

Métodos De Medi- ción De La Dispo-

nibilidad

Procedimien-

tos De Soporte Positiva Directa

Ante mejores mediciones es más fá- cil la labor de la mesa de servicios y del personal de soporte.

(36)

Mejores Prácticas Costo Positiva Directa

La implementación de las mejores prácticas es costosa. Al igual que proveedores certificados cobran más.

Mejores Prácticas MTRS Negativa Directa

Mejores prácticas disminuyen los tiempos de restauración porque se soportan en los mejores procesos y soluciones para este fin; y contemplan la resiliencia de la arquitectura del proveedor.

Sanciones Costo Positiva

Directa

El proveedor cobra más si el cliente demanda sanciones más altas. Al igual que el cliente está dispuesto a pagar más si se le compensa con sanciones altas en caso de incumplimiento.

Ubicación Física Disponibilidad Positiva Directa

Entre mayor grado de replicación y mejores prácticas en la ubicación de servidores que soportan el servicio también es mayor la capacidad de responder en caso de un fallo.

Disponibilidad Costo Positiva Directa

Pues la infraestructura usada será mayor, al igual que los recursos in- vertidos por el proveedor para ga- rantizar niveles mayores.

Tiempo De Inacti-

vidad Planeado Disponibilidad Negativa Directa

Porque el sistema estará menos tiempo al aire.

MTBF Disponibilidad Positiva Directa

Porque de disminuir el MTBF sería más posible que el servicio fallara.

Y así se podría llegar más fácil- mente a un estado de inactividad.

Mejores Prácticas Disponibilidad Positiva Directa

A nivel de procesos y manejo de capacidades se reducen los riesgos que causan la indisponibilidad

Complejidad Del

Servicio Disponibilidad Negativa Directa

Si aumenta la complejidad aumenta la dependencia de este de la confiabilidad de los componentes. Y asi- mismo aumentan los posibles puntos de fallo.

Tiempo De Res- puesta

Complejidad

Del Servicio Positiva Directa

Ante mayores requerimientos se deben usar arquitecturas más ro- bustas.