SLA: Qué es, qué no es y qué debería ser

0

Hoy en día, con cada vez más compañías apostando por la externalización de servicios en la nube, los SLA’s han aumentado en importancia. Si seguímos las recomendaciones de ITIL, los SLA’s son, entre otras cosas, una manera de transferir el riesgo a nuestro proveedor. De esta manera quedamos libres del riesgo. Pero, ¿es eso cierto? ¿los SLA’s que firmamos nos dejan libres de todo riesgo?

En este artículo reviso el concepto habitual de SLA y añado mis comentarios sobre como deberían ser, desde el punto de vista del cliente.

El objetivo de un SLA

Un SLA es un Acuerdo de Nivel de Servicio (Service Level Agreement). Si no lo sabías, mal vamos si eres gestor en el mundo TI. Dicho de otro modo, un SLA es una definición del nivel de servicio que se debe proporcionar con un énfasis particular en el precio variable. Este precio variable vendrá determinado por el cumplimiento del acuerdo, y puede incluir premios y penalizaciones.

Los objetivos de disponer de un SLA son:

  • Una declaración de las expectativas de ambas partes (cliente y proveedor), de manera que cada uno entienda al otro y se encuentre un punto de acuerdo.
  • Una alineación de objetivos entre ambas partes, de forma que los intereses del proveedor sean los mismos que los del cliente.
  • Una transferencia de riesgo, de forma que las pérdidas derivadas de una mala provisión del servicio estén cubiertas.

Un SLA bien diseñado cumplirá estos tres objetivos. Pero ¿se diseñan bien los SLA’s?

El paradigma actual del SLA

Actualmente la gran mayoría de los CIO’s que contratan un servicio, exigen un SLA. Pero ¿qué tipo de SLA? ¿Qué es un SLA para un CIO? La respuesta en muchos casos es hacer creer al CIO que tiene la situación bajo control. Le permite dormir por las noches, pensando que el proveedor está bajo sus dominios y le garantiza que se portará bien. Realmente los SLA’s de hoy en día se limitan a definir la compensación por incumplimiento. ¿Esa compensación le da el control a ese CIO?

Vamos a dar un par de vueltas sobre este concepto de compensación. Hoy en día los servicios de TI proporcionan un valor muy superior al coste del servicio (si no, vaya negocio ruinoso sería invertir en TI). Si a esto le añadimos que las penalizaciones por incumplimientos del SLA suelen ser una fracción del coste del servicio, llegamos a que la penalización por incumplimiento es muy inferior al impacto que tendrá en el negocio ese incumplimiento. Pensemos en ello un poco. ¿Cuál es el coste de externalizar el correo? ¿Cuál es el valor que nos da ese correo? o dicho de otro modo ¿Cuánto puede perder tu compañía por día sin correo?

Vamos a trabajar esas preguntas con un caso práctico. El servicio de Google Apps for Work tiene un precio hoy en día de 4 € al mes por empleado. En su SLA definen que una disponibilidad mensual inferior al 95 % implica regalar medio mes de servicio, sin coste para el cliente. ¿qué valor tiene medio mes de serivio? dos tristes euros. Si Google tiene un problema con tu empresa y se queda sin correo una semana, te reembolsará 2 € por empleado. ¿Cuánto pierde un empleado al día sin correo? ¿Cubrimos los costes con 2 €? Claramente no. ¿De qué me sirve entonces tener ese SLA?

Resumiendo, la penalización de una pérdida de servicio no nos cubrirá los costes del cliente.

Otro ejemplo, un caso real que me ha pasado a mí. Hace tiempo trabajé en una empresa de desarrollo web como responsable técnico. No sólo desarrollábamos, sino que también proporcionábamos el software como servicio, de forma que proporcionábamos servicios a nuestros clientes. Dirigí la contratación de un servicio de hosting y administración, sobre el que descasaría el servicio proporcionado a uno de nuestros clientes: una central de reservas hoteleras on-line. El coste de ese servicio de hosting era menos del 1 % del coste del servicio para el cliente. El servicio para el cliente era crítico y los costes de una caída eran significantes ya en la primera hora. De esta manera le exigí al proveedor de hosting un SLA muy agresivo: Un 50 % de penalización por una disponibildiad inferior a 99,5 %. Hablamos de que con 4 horas de indisponibilidad en un mes, ya penalizaba. Con el cliente se acordó un SLA de que cada periodo de indisponibilidad implicaba el descuento de el doble de ese periodo en el mes. Es decir, 3 días de caída implicaba dejar de pagar 6 días, o lo que es lo mismo un 20 % del mes. Quedé muy satisfecho con los acuerdos, porque una caída de 4 horas implicaba un 50 % de descuento en el hosting y un 2 % de pérdidas en el servicio.

La realidad fue dolorosa cuando un domingo por la mañana la controladora RAID se rompió. Nuestro equipo de guardia contactó con la guardia del servicio de hosting contratado para descubrir que no tenían piezas de repuesto y tuvieron que esperar al lunes para comprar una y restaurar el servicio. Y la pesadilla empezó:

  1. Cuando llamé al proveedor para exigir la aplicación del SLA, me argumentaron que el retraso por no tener piezas de repuesto durante un fin de semana se escapaba de su control y que ese tiempo no aplicaba. Al final aceptaron, pero después de horas de conversación por teléfono.
  2. El importe de ese 50 % de reducción fue inferior al más del 6 % que se le redujo al cliente, quedando en ridículo en mi propia empresa tras haber alardeado de la transferencia de riesgo.
  3. Nuestra reputación sufrió. No sólo cobramos menos, sino que el cliente ya no nos miraba tan bien y la sobra de una rotura de acuerdo empezó a sobrevolarnos.
  4. El cliente se presentó en nuestra empresa diciendo que esa reducción no era comparable a las pérdidas que había tenído por tener un domingo de marzo el sistema caído, uno de los días con más ventas del año. El cliente se sintió decepcionado.

Volviendo al tema principal del artículo: Los SLA’s de hoy en día no transfieren el riesgo.

Qué debería ser un SLA

Ahora que ya tenemos claro qué es un SLA y qué no es, vamos a ver qué debería ser.

Un SLA debería ser lo que pretendamos que sea. Si queremos transferir el riesgo de la externalización al proveedor, el SLA debe cubrir nuestras pérdidas al 100 %. Y debe estar diseñado bajo ese punto de vista: el de transferir el riesgo. Esta manera es la única en la que el proveedor entiende perfectamente el impacto de su servicio. Si por una hora de caída perdemos 1.000 € en ventas, esa tendría que ser la penalización.

Pero claro, conseguir un SLA de ese tipo no siempre es posible. ¿Y qué podemos hacer entonces como clientes?

Qué debes hacer

Siempre hay que evaluar el riesgo de tu servicio con el SLA actual. Con los SLA’s de hoy en día no podemos irnos a dormir tranquilos, no se trata de un traga-riesgos que nos deja tranquilos. La gestión de riesgos debe ponerse en marcha y tratar los riesgos. Las medidas para afrontar estos riesgos van desde admitirlos (negocio debe asumirlos) o tomar medidas para mitigarlos, como:

  • Auditar al proveedor para asegurar que la probabilidad del riesgo está controlada.
  • Redundar al proveedor (como múltiples contratos de energía o comunicaciones).
  • Contratar seguros.

Entonces, ¿Los SLA no sirven de nada? Claro que sirven. Volviendo al comienzo del articulo hay tres objetivos para los SLA’s: gestión de expectativas, alineación de objetivos y transferencia del riesgo. Que no se cumpla el último de ellos, no significa que los otros dos no. Ojo, que tenemos que asegurarnos de que se cumplan con SLA’s que aseguren:

  • Que nuestro deseo o necesidad de nivel de servicio sale reflejado en el SLA. Una manera es alineándolo con una correcta priorización de incidencias.
  • Que el impacto de incumplimiento, aunque no nos cubra el riesgo, sea importante para el proveedor.

Yo he proporcionado servicios con SLA’s ridículos en los que lo que menos me preocupaba de incumplir era la penalización. Realmente me salía más barato no pagar un servicio de guardia las noches y pagar por sistema la penalización. Como cliente no debemos permitir nunca eso, o será como no tener SLA.

About author

Jose M. Huerta

Jose es Gestor de Proyectos y Gestor de Servicios en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información. Está certificado como ITIL Expert y va en camino de certificarse como PMP. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de proyectos, usando metodologías clásicas y ágiles, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector. Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo. Actualmente trabaja en Idiso, empresa de servicios de distribución hotelera, como responsable del equipo de desarrollo web.

No comments

Te puede interesar...

Segundos, Neuronas y Tornillos

Hace no muchos años un buen programador se definía por su capacidad para hacer código eficiente. El hardware imprimía unas limitaciones importantes y el buen ...