SLA: un difícil acuerdo
La elección de un proveedor de servicios no resulta una tarea sencilla, en especial cuando se tiene conciencia de lo que significa que parte de los recursos informáticos de la empresa residan en las instalaciones de un tercero. Por fortuna, existe una pieza clave que le ayudará a seleccionar al proveedor más indicado y que, además, le dará esas garantías que se deben tener antes de firmar un contrato con un ASP. Se trata de los acuerdos de nivel de servicio, que, cuando están bien definidos, valen su peso en oro.
Los abogados emplean con frecuencia el aforismo “más vale un mal acuerdo que un juicio ganado”. En el mundo de los xSP, un mal acuerdo sobre la calidad del servicio que debe garantizar el proveedor puede tener también una lectura positiva. Por una parte, un mal acuerdo es mucho mejor que no tener acuerdo alguno. Lo cierto es que firmar un acuerdo de nivel de servicio (Service Level Agreement o SLA) con un proveedor tiene mérito: la mayoría no contempla ese aspecto dentro de sus ofertas ni de sus planes presentes o futuros. De otro lado, un SLA deficiente es algo muy habitual, pues alcanzar un buen acuerdo no es tarea sencilla, y puede servir de base para descubrir qué puntos son incorrectos y qué se debe mejorar para lograr uno mejor.
No existe una fórmula general ni unas instrucciones a seguir que aseguren la firma del contrato de nivel de servicio adecuado para su empresa. Cada acuerdo se debe adaptar a las características particulares del servicio contratado, de la capacidad del proveedor que lo suministra y de las necesidades y requisitos del cliente que lo contrata. Cada caso es un pequeño mundo lleno de matices, pues lo que es admisible para una compañía no lo es para otra, y lo que es una necesidad imperiosa para aquélla no tiene ninguna importancia para ésta.
Los siguientes apartados abordan algunos de los requisitos más habituales que se incluyen en los contratos de nivel de servicio, además de las herramientas que se pueden emplear a la hora de controlar el verdadero cumplimiento de los acuerdos alcanzados. Estas útiles referencias deben ser personalizadas en cada caso particular y, como se explica en el último apartado, sin olvidar las limitaciones que el mercado español impone a los ASP.
REQUISITOS Y PROMESAS
Una vez que se ha verificado que un posible proveedor ofrece la infraestructura tecnológica que cumple con la funcionalidad deseada, y además ofrece las garantías suficientes de seguridad (se está relativamente “seguro de que es seguro”), es el momento de evaluar la calidad del servicio ofertado materializado en un SLA, y, en el mejor de los casos, negociarlo y adaptarlo a sus necesidades.
Si ya era complicado definir y monitorizar un SLA para una línea de comunicaciones con un proveedor de conectividad, imagine la complicación añadida de establecer puntos de medida y criterios de mal funcionamiento de una forma objetiva entre una aplicación basada en la consulta a un sistema transaccional y diferentes clientes que se pueden conectar desde los puntos más diversos.
Para comenzar, no se debe olvidar la postrera vocal del término que denomina la culminación de todos estos conceptos, la “A” de Agreement o “acuerdo”. Una de las cualidades asumidas de la expresión “acuerdo” es la bilateralidad que implica, más aún para los casos en los que el servicio se centre en la utilización de aplicaciones de forma remota. En estos escenarios, los criterios de calidad de servicio pueden depender de multitud de factores que van más allá de la disponibilidad temporal, siendo el objetivo el control extremo a extremo, y la prueba de funcionamiento la percepción del usuario final en el uso de dichas aplicaciones. Desgraciadamente, en la práctica será bastante difícil introducir modificaciones en las condiciones de servicio ofrecidas por los proveedores, estando éstas en muchos casos plagadas de una mezcla de puntualizaciones engañosas y limitaciones declaradas, cuyo único fin parece ser el descargo de la responsabilidad del proveedor ante cualquier problema.
En la negociación conviene revisar con sumo cuidado la inclusión y el tratamiento que se le presta a aspectos importantes para describir correctamente el contenido de los siguientes términos, teniendo en cuenta que el SLA estará ligado al contrato de servicios:
- Disponibilidad. Este factor es el “must” de los acuerdos de compromiso en la calidad de servicio, que ya se empieza a expresar con tres decimales (99,999 %). Al igual que con el paso del tiempo los servicios se vuelven cada vez más complejos y funcionalmente completos, este clásico se ha ido adornando con numerosas puntualizaciones para completar su definición, impensable a día de hoy en forma de un simple tanto por ciento.
Lo primero es establecer en qué periodo de tiempo se calcula el nivel de disponibilidad (diario, semanal, mensual, anual), pues obviamente no es lo mismo padecer una caída con un tiempo máximo de recuperación de 14 minutos y medio en un día, que sobrevivir a una parada de casi cuatro días. Para ello también se suele definir el tiempo máximo de restauración del servicio, y el tiempo máximo de recuperación de los niveles aceptables de rendimiento, respuesta, etc., puesto que lo que se busca es la reanudación total, y no un servicio “a medio gas”.
Al tiempo resultante de aplicar la regla de tres se debe añadir lo excluido en el contrato en referencia a paradas programadas para mantenimiento y actualización; causas que escapen al control del xSP, cuya definición debe ser lo más detallada posible (desastres naturales, fuerza mayor, terrorismo, etc.); caídas resultantes del mal uso o la incorrecta configuración por parte del cliente (con la complejidad que puede suponer determinar esta culpabilidad, sobre todo si no se ha comunicado o definido el “uso correcto” de los sistemas); condiciones de uso que sobrepasen los umbrales para los que el sistema se ha dimensionado (para el caso concreto del cliente); y algunas excepciones más cuya probabilidad de materialización conviene estudiar en cada caso concreto. Para el tiempo restante (quizá ya bastante lejos de los dos decimales) es conveniente que se definan los procedimientos de notificación de variaciones en la disponibilidad de un mes en concreto, dejando claro en qué condiciones debe ser aceptado sin más por el cliente o en cuáles ha de ser renegociado, así como los mecanismos para la comunicación, aceptación y compensación de los futuros cortes de servicio prolongados (donde prolongados está expresando de forma no ambigua) cuando se prevean necesarios por el proveedor (ampliaciones, etc.).
- Rendimiento y tasas de error. Frente al concepto absoluto de no disponibilidad del servicio se debe hacer un esfuerzo para identificar cuándo se tiene una disponibilidad útil del mismo. Sin este tipo de puntualizaciones un sistema que procese de forma correcta 3 de cada 10 operaciones podría considerarse disponible, hecho que podría provocar considerables pérdidas debidas a su improductividad.
Los detalles y parámetros técnicos dependerán en gran medida del tipo de sistema a comprobar (porcentaje de errores, latencia excesiva, etc.), así como de los mecanismos adecuados de medida, a los cuales se hace referencia en el apartado “La verificación de lo pactado”.
- Tiempos de respuesta. Este apartado no se refiere a parámetros t
Los abogados emplean con frecuencia el aforismo “más vale un mal acuerdo que un juicio ganado”. En el mundo de los xSP, un mal acuerdo sobre la calidad del servicio que debe garantizar el proveedor puede tener también una lectura positiva. Por una parte, un mal acuerdo es mucho mejor que no tener acuerdo alguno. Lo cierto es que firmar un acuerdo de nivel de servicio (Service Level Agreement o SLA) con un proveedor tiene mérito: la mayoría no contempla ese aspecto dentro de sus ofertas ni de sus planes presentes o futuros. De otro lado, un SLA deficiente es algo muy habitual, pues alcanzar un buen acuerdo no es tarea sencilla, y puede servir de base para descubrir qué puntos son incorrectos y qué se debe mejorar para lograr uno mejor.
No existe una fórmula general ni unas instrucciones a seguir que aseguren la firma del contrato de nivel de servicio adecuado para su empresa. Cada acuerdo se debe adaptar a las características particulares del servicio contratado, de la capacidad del proveedor que lo suministra y de las necesidades y requisitos del cliente que lo contrata. Cada caso es un pequeño mundo lleno de matices, pues lo que es admisible para una compañía no lo es para otra, y lo que es una necesidad imperiosa para aquélla no tiene ninguna importancia para ésta.
Los siguientes apartados abordan algunos de los requisitos más habituales que se incluyen en los contratos de nivel de servicio, además de las herramientas que se pueden emplear a la hora de controlar el verdadero cumplimiento de los acuerdos alcanzados. Estas útiles referencias deben ser personalizadas en cada caso particular y, como se explica en el último apartado, sin olvidar las limitaciones que el mercado español impone a los ASP.
REQUISITOS Y PROMESAS
Una vez que se ha verificado que un posible proveedor ofrece la infraestructura tecnológica que cumple con la funcionalidad deseada, y además ofrece las garantías suficientes de seguridad (se está relativamente “seguro de que es seguro”), es el momento de evaluar la calidad del servicio ofertado materializado en un SLA, y, en el mejor de los casos, negociarlo y adaptarlo a sus necesidades.
Si ya era complicado definir y monitorizar un SLA para una línea de comunicaciones con un proveedor de conectividad, imagine la complicación añadida de establecer puntos de medida y criterios de mal funcionamiento de una forma objetiva entre una aplicación basada en la consulta a un sistema transaccional y diferentes clientes que se pueden conectar desde los puntos más diversos.
Para comenzar, no se debe olvidar la postrera vocal del término que denomina la culminación de todos estos conceptos, la “A” de Agreement o “acuerdo”. Una de las cualidades asumidas de la expresión “acuerdo” es la bilateralidad que implica, más aún para los casos en los que el servicio se centre en la utilización de aplicaciones de forma remota. En estos escenarios, los criterios de calidad de servicio pueden depender de multitud de factores que van más allá de la disponibilidad temporal, siendo el objetivo el control extremo a extremo, y la prueba de funcionamiento la percepción del usuario final en el uso de dichas aplicaciones. Desgraciadamente, en la práctica será bastante difícil introducir modificaciones en las condiciones de servicio ofrecidas por los proveedores, estando éstas en muchos casos plagadas de una mezcla de puntualizaciones engañosas y limitaciones declaradas, cuyo único fin parece ser el descargo de la responsabilidad del proveedor ante cualquier problema.
En la negociación conviene revisar con sumo cuidado la inclusión y el tratamiento que se le presta a aspectos importantes para describir correctamente el contenido de los siguientes términos, teniendo en cuenta que el SLA estará ligado al contrato de servicios:
- Disponibilidad. Este factor es el “must” de los acuerdos de compromiso en la calidad de servicio, que ya se empieza a expresar con tres decimales (99,999 %). Al igual que con el paso del tiempo los servicios se vuelven cada vez más complejos y funcionalmente completos, este clásico se ha ido adornando con numerosas puntualizaciones para completar su definición, impensable a día de hoy en forma de un simple tanto por ciento.
Lo primero es establecer en qué periodo de tiempo se calcula el nivel de disponibilidad (diario, semanal, mensual, anual), pues obviamente no es lo mismo padecer una caída con un tiempo máximo de recuperación de 14 minutos y medio en un día, que sobrevivir a una parada de casi cuatro días. Para ello también se suele definir el tiempo máximo de restauración del servicio, y el tiempo máximo de recuperación de los niveles aceptables de rendimiento, respuesta, etc., puesto que lo que se busca es la reanudación total, y no un servicio “a medio gas”.
Al tiempo resultante de aplicar la regla de tres se debe añadir lo excluido en el contrato en referencia a paradas programadas para mantenimiento y actualización; causas que escapen al control del xSP, cuya definición debe ser lo más detallada posible (desastres naturales, fuerza mayor, terrorismo, etc.); caídas resultantes del mal uso o la incorrecta configuración por parte del cliente (con la complejidad que puede suponer determinar esta culpabilidad, sobre todo si no se ha comunicado o definido el “uso correcto” de los sistemas); condiciones de uso que sobrepasen los umbrales para los que el sistema se ha dimensionado (para el caso concreto del cliente); y algunas excepciones más cuya probabilidad de materialización conviene estudiar en cada caso concreto. Para el tiempo restante (quizá ya bastante lejos de los dos decimales) es conveniente que se definan los procedimientos de notificación de variaciones en la disponibilidad de un mes en concreto, dejando claro en qué condiciones debe ser aceptado sin más por el cliente o en cuáles ha de ser renegociado, así como los mecanismos para la comunicación, aceptación y compensación de los futuros cortes de servicio prolongados (donde prolongados está expresando de forma no ambigua) cuando se prevean necesarios por el proveedor (ampliaciones, etc.).
- Rendimiento y tasas de error. Frente al concepto absoluto de no disponibilidad del servicio se debe hacer un esfuerzo para identificar cuándo se tiene una disponibilidad útil del mismo. Sin este tipo de puntualizaciones un sistema que procese de forma correcta 3 de cada 10 operaciones podría considerarse disponible, hecho que podría provocar considerables pérdidas debidas a su improductividad.
Los detalles y parámetros técnicos dependerán en gran medida del tipo de sistema a comprobar (porcentaje de errores, latencia excesiva, etc.), así como de los mecanismos adecuados de medida, a los cuales se hace referencia en el apartado “La verificación de lo pactado”.
- Tiempos de respuesta. Este apartado no se refiere a parámetros t
