Pandora Tech Blog

¿Qué es un SLA y cómo se calcula?

por | Last updated Aug 20, 2026 | Tecnología

Contenido:

En el episodio Reliquias de Star Trek: La nueva generación, La Forge descubre el secreto de Scotty y su fama de ingeniero obrador de milagros en la legendaria serie original. Cuando alguien le pregunta cuánto tardará una reparación, multiplica por cuatro su estimación real. Si termina antes, el genio lo ha vuelto a hacer y si se complica, sigue llegando a tiempo de todos modos. El truco IT de toda la vida, que se nos vuelve inservible cuando alguien escribe esa promesa en un documento junto a un número. Ese documento es el SLA, el Service Level Agreement o acuerdo de nivel de servicio.

Este fija tres cosas:

  • Qué nivel de servicio se espera de lo que proveemos.
  • Cómo se mide.
  • Qué ocurre si no se cumple.

De ese modo, el SLA se convierte en la «ley» a cumplir en gestión de TI por cualquier organización que preste servicios a alguien… y nos impide improvisar como Scotty y parecer genios, teniendo que ceñirnos a lo que diga ahí.
Por eso vamos a conocer íntimamente esas leyes de nuestro terreno profesional, ya que el beneficio dependerá de ello.

¿Qué es un SLA?

Como siempre, es necesario empezar abriendo el diccionario y un SLA es el acuerdo en el que un proveedor y un cliente concretan el nivel de servicio comprometido y la forma de comprobarlo.
«Físicamente» puede ser un anexo contractual, un documento interno entre el departamento IT y el resto de la empresa o una página de dos párrafos en la propuesta de un integrador.
Son las condiciones expresadas de forma medible (y no un sello de abogado) las que convierten algo en un SLA, de modo que uno mínimamente serio establecerá:

  • Servicios incluidos. Correo corporativo, app de facturas, provisión de e-commerce… Puede incluir cualquier cosa, pero cuanto más difuso el alcance, más discusiones en la inevitable primera caída.
  • Nivel esperado de servicios. Como un 99,9% de disponibilidad mensual, una primera respuesta a incidencias críticas en 30 minutos, latencia por debajo de cierto umbral… El indicador concreto depende, pero debe ser consensuado.
  • Cómo se mide. Desde dónde, con qué frecuencia y qué herramienta recoge la verdad numérica. Sin esto, el SLA es literatura y nada más.
  • Durante qué periodo. Mensual, trimestral, anual… El período cambia el resultado más de lo que parece, como veremos después con números.
  • Responsabilidades de cada parte. Incluyendo las del cliente, que se suele olvidar de abrir el ticket con información suficiente, cuando forma parte del trato. Así, el juego de la culpa es una calle de dos direcciones y no solo hacia el gestor técnico.
  • Consecuencias de incumplimiento. Un SLA es un «pacto de sangre», no mi diario de buenas intenciones, por eso incluye las repercusiones reales por no satisfacerlo. Las habituales son penalizaciones, descuentos, un plan de acción o revisión del servicio.

Veamos un ejemplo sencillo.
Contratamos a un MSP (proveedor de servicios gestionados) para gestionar nuestros servidores virtualizados y el SLA firmado dice que:

  • La infraestructura estará disponible el 99,9% del tiempo cada mes.
  • Las incidencias críticas se atenderán en 30 minutos o menos, 24×7.
  • Las ventanas de mantenimiento se avisarán con 72 horas de antelación.
  • Se entregará un informe mensual con los datos.

Gracias a esto, la conversación orbita alrededor de indicadores tangibles, en lugar de sensaciones subjetivas.

¿Para qué sirve un SLA?

Para que ambas partes discutan arrojándose datos a la cabeza, en lugar de percepciones (una batalla que nunca gana nadie), pero también para optimizar la relación y el trabajo.
Así, el SLA da al proveedor un criterio objetivo para prestar su servicio. Sabe qué tiene que sostener, puede dimensionar adecuadamente su equipo y posee argumentos en esas llamadas de «esto va lento», cuando los datos dicen que el servicio estuvo disponible el 99,97% del mes, por encima del 99,9% comprometido en el SLA del ejemplo.
Sin SLA, las expectativas del cliente crecen hasta el infinito y más allá, culminando siempre en: «Pues yo pensaba que esto estaba cubierto».
Al otro lado de la trinchera, al cliente le aclara qué puede esperar y, sobre todo, cómo comprobarlo.
Esto influye principalmente en los proveedores de servicios gestionados (MSP), porque su producto es el nivel de servicio.
Todo esto también afecta a los departamentos IT internos, porque aunque no haya penalizaciones económicas de por medio, un SLA evita que la prioridad tecnológica la marque el ticket que berrea más fuerte.

Qué incluye normalmente un SLA

Es imposible cubrir cada requisito que se incluyó alguna vez en un acuerdo de este tipo, pero hay elementos que aparecen una y otra vez en los SLA y cuya ausencia pagaremos cara.

  • El alcance del servicio. Es decir, qué sistemas, aplicaciones y componentes entran y cuáles no, algo igual de importante.
  • La disponibilidad comprometida. Expresada en porcentaje, con su periodo de medición y su método de cálculo (veremos un ejemplo).
  • El horario de cobertura. Porque aunque el cliente sea miope para distinguir estas cosas, no es lo mismo prometer «24×7» que «lunes a viernes de 9 a 18». Muchos incumplimientos aparentes son en realidad incidencias abiertas fuera del horario acordado en el SLA.
  • Tiempo de primera respuesta. O cuánto tarda alguien en hacerse cargo del incendio que surja.
  • Tiempo de resolución. Cuánto tarda en apagarse el incendio anterior y que el servicio vuelva a funcionar. Ojo, porque confundir esto y lo anterior es un clásico habitual, así que es importante distinguirlos bien en el SLA.
  • Prioridades y clasificación. Con criterios para decidir qué es crítico, alto, medio o bajo con ejemplos concretos. Si no, solo existe una clasificación para el cliente y es «todo crítico».
  • Mantenimientos programados. Que determinan las ventanas previstas, el preaviso y si computan en el cálculo del SLA en cuanto a disponibilidad (otro de esos detalles inocentes que marcan toda la diferencia).
  • Método de medición e informes. Definiendo qué herramienta genera el dato, con qué granularidad y en qué formato se entrega.
  • Consecuencias de incumplimiento. Y si son compensaciones económicas, descuentos futuros, revisiones de servicios, un plan de mejora firmado…
  • Procedimiento de escalado. ¿Qué pasa cuando el primer nivel no tiene un extintor lo bastante grande? Debemos determinar ese escalado con nombres, canales y tiempos.
  • Exclusiones. Como sucesos de fuerza mayor, fallos de terceros, cortes del operador o cambios solicitados por el propio cliente.

    • Estas exclusiones merecen párrafo propio, porque son la parte del documento que más se parece a la pata de mono de Homer en Los Simpson, episodio en el que los deseos se cumplen exactamente como se piden y nunca como se esperan.

Es fundamental entender que un SLA con exclusiones difusas concede literalmente lo escrito, y no lo imaginado por nosotros, de modo que, si el acuerdo excluye «incidencias derivadas de terceros» expresadas tal cual, entonces el proveedor de nube, el operador de Internet o el fabricante del firewall son terceros y por esa puerta cabe casi cualquier caída.
Marcos de trabajo como ITIL en la gestión de servicios IT llevan años ordenando estos elementos, de modo que conviene apoyarse en ellos, aunque solo sea para no reinventar la fatigosa rueda de clasificación de prioridades cada vez que firmemos un contrato.

Métricas habituales en un SLA

Comencemos aclarando EL malentendido más extendido del tema, porque un SLA no consiste en un porcentaje de disponibilidad con un contrato alrededor rellenando la hoja, pues dicha disponibilidad es apenas una métrica más y, en muchos servicios, ni siquiera es la que mejor describe la experiencia real del usuario.
Por eso, las métricas que veremos más a menudo en un SLA serán:

  • Disponibilidad o uptime. Que se calcula como el porcentaje de tiempo que el servicio ha estado operativo dentro del periodo que establecemos, mensual o el que sea.
  • Tiempo de primera respuesta. Que, como hemos visto antes, es lo que se tarda desde la apertura del ticket hasta que un técnico recoge el marrón en su regazo. Los SLA inteligentes comprenden que esta es la métrica que más percibe el usuario, y la percepción es lo más importante en este mundo obsesionado por lo externo, pues el silencio ante la petición de ayuda es lo que desespera de verdad.
  • Tiempo de resolución. Desde la apertura de la incidencia, hasta el restablecimiento del servicio.
  • MTTR. Que significa tiempo medio de reparación, la media de los tiempos de reparación de un periodo, y nos da una foto de la capacidad real del equipo a lo largo del tiempo, en lugar de en casos concretos.
  • Latencia o rendimiento. Clave en aplicaciones web, API o servicios de datos, porque un sistema que responde en ocho segundos está técnicamente disponible y prácticamente inservible a la vez.
  • Tasa de incidencias. Que mide cuántas se abren por periodo y de qué tipo. Así detectaremos cosas como si el problema es de operación o de diseño.
  • Porcentaje de cumplimiento. Calculando qué proporción de las incidencias se atendió y resolvió dentro de los tiempos comprometidos.

Como es costumbre en el mundo real, la combinación de varias métricas es lo que hace útil un SLA. Un servicio puede cumplir su 99,9 % de disponibilidad y ser un desastre a pesar de todo si, cada vez que falla, nadie contesta en seis horas.

SLA y uptime: diferencias

Antes he comentado una confusión habitual de «la parte por el todo» cuando hablábamos de disponibilidad y SLA, siendo otra de esas cosas que merece apartado propio.
El uptime o disponibilidad es un dato que se monitoriza, una «parte» del «todo» que es el SLA, pero no es el SLA. Este consiste en el acuerdo completo que incluye al uptime como una de sus métricas junto con tiempos de respuesta, resolución, cobertura horaria y el resto de lo que hemos analizado.
Eso sí, entre los indicadores del SLA, la disponibilidad suele ser la reina. Se puede medir y gestionar el uptime sin un SLA y, de hecho, es habitual en cualquier operación IT, pero tener un SLA sin la capacidad de medir uptime es firmar un cheque sin mirar el saldo de la cuenta.

Cómo se calcula un SLA

Si bien las métricas de un acuerdo de nivel de servicio van más allá de la disponibilidad del servicio contratado, casi todo gira alrededor de esta y es lo primero a considerar en el cálculo de un SLA.
En este caso, y sin que sirva de precedente en IT, no serán necesarios cálculos de la NASA, porque nos bastará un poco de aritmética elemental:

Disponibilidad = (tiempo disponible / tiempo total medido) × 100

Apliquemosla con un ejemplo. Un mes de 30 días son 720 horas, es decir, 43.200 minutos. Si el servicio estuvo caído 65 minutos, entonces:
Disponibilidad = (43.200 − 65) / 43.200 × 100 = 99,85 %
Con un compromiso del 99,9 %, ese mes hay incumplimiento porque el margen del 99,9 % en un mes de 30 días es de 43,2 minutos aproximadamente, pero aquí hemos consumido 65.
Sin embargo, analicemos ahora la parte interesante, que muestra por qué es fundamental afinar bien la disponibilidad en el SLA.
Supongamos que 30 de esos 65 minutos ocurrieron dentro de una ventana de mantenimiento programada de dos horas, avisada con antelación y excluida del cálculo según el acuerdo.
En este caso, el tiempo total medido baja a 43.080 minutos (al descontar las dos horas de la medición, 120 minutos) y la indisponibilidad computable mediante SLA desciende a 35 minutos:
(43.080 − 35) / 43.080 × 100 = 99,92 %
Mismo mes, mismos cortes, pero ahora el resultado pasa de incumplimiento a cumplimiento.
En este ejemplo no habría trampa por parte del proveedor y el SLA lo deja claro. Por eso la letra pequeña sobre exclusiones y ventanas de mantenimiento pesa tanto como el porcentaje y por eso es interesante leer cómo lo redactan grandes empresas, desde los acuerdos de nivel de servicio de AWS hasta los SLA de servicios online de Microsoft, donde cálculo, exclusiones y procedimiento de reclamación ocupan más espacio que la cifra de disponibilidad.
Como indicación básica, esta es la traducción de cada porcentaje a tiempo de indisponibilidad permitido, tomando meses de 30 días y años de 365:

Disponibilidad

Al mes

Al año

99 %

7 h 12 min

3 días 15 h 36 min

99,9 %

43 min 12 s

8 h 45 min 36 s

99,99 %

4 min 19 s

52 min 34 s

Ahí se ve por qué cada nueve adicional multiplica el precio. Pasar de 99 % a 99,9 % es una cuestión de operación disciplinada, pero pasar de 99,9 % a 99,99 % implica redundancia real, conmutación automática y un equipo capaz de reaccionar dentro de un presupuesto de cuatro minutos de caída al mes.
Ahí es donde demasiados comerciales prometen ese nueve más que no parece gran cosa a ojos no técnicos, pero es fácil que no podamos sostener con nuestra infraestructura.
Las otras métricas del SLA se evalúan contra casos en lugar de con el reloj del servicio, como las incidencias que atendimos dentro del plazo comprometido (divididas entre el total y multiplicadas por cien). En esos casos es la misma aritmética, aunque contando marrones en lugar de minutos.

Ejemplo práctico de SLA en IT

Para bajar más a tierra todos estos conceptos, veamos un acuerdo típico para una aplicación de negocio, resumido en su tabla de condiciones.

Concepto

Compromiso

Servicio

Aplicación empresarial de gestión

Disponibilidad

99,9 % mensual

Primera respuesta (crítica)

30 minutos

Resolución objetivo (crítica)

4 horas

Cobertura para incidencias críticas

24×7

Mantenimiento programado

Ventana mensual avisada con 72 h, excluida del cálculo

Informe

Mensual, con detalle de cortes e incidencias

El aprendizaje de este cuadro es que ninguna línea de la tabla significa gran cosa por separado.
Por ejemplo, ese 99,9 % sin cobertura 24×7 deja las noches al descubierto. O la resolución en cuatro horas sin una definición clara de qué es esa «crítica» de los paréntesis se convierte en una negociación cada vez que suena el teléfono.
La clave es que un SLA es el conjunto y funciona cuando todas sus condiciones apuntan en la misma dirección.

SLA de soporte y tiempos de respuesta

En soporte y helpdesk tenemos una muestra inconfundible de cómo el foco de un SLA se desplaza de disponibilidad a tiempos, con cuatro conceptos que conviene no mezclar.

  • Primera respuesta. El tiempo hasta que un técnico confirma la recogida de la incidencia y que se hace cargo. Ojo, porque no implica solución, solo que alguien ha cogido el volante del coche que se despeña.
  • Respuesta durante el ciclo. Contemplemos la métrica olvidada que más quejas evita y que establece cada cuánto se actualiza el estado de la incidencia mientras siga abierta. El cliente quiere sentir que el del volante hace algo más que agarrarlo.
  • Tiempo de resolución. El que transcurre hasta que el servicio vuelve a estar operativo, con o sin solución definitiva. Conviene distinguir entre parche temporal y cierre completo, porque el cliente no los vive igual.
  • Escalado. Cuándo sube de nivel una incidencia, a quién le cae el marrón y el proceso automático que lo implementa, porque si elevar la incidencia depende de que alguien se acuerde… entonces no es un escalado.

Además, todo esto debe apoyarse en un esquema de prioridades o el proveedor de servicios IT vivirá corriendo como un pollo sin cabeza.
Lo habitual para esto es cruzar impacto (cuánta gente o cuánto negocio se ve afectado) con urgencia (cuánto puede esperar algo sin que todo se venga abajo) para obtener el nivel. Luego, asociaremos tiempos a cada nivel.
Aquí es donde una herramienta de gestión de incidencias y SLA deja de ser un lujo, pues los relojes deben correr solos dentro del sistema de tickets, pausarse cuando la incidencia esté a la espera de datos del cliente y avisar antes de que el plazo se agote.

Diferencia entre SLA, SLO y SLI

Una letra marca toda la diferencia. Zara logró anular el registro de la marca Zora en la India, por el parecido que podía confundir al comprador, mientras que Google se apresuró a poseer dominios como «Goggle» para evitar el desvío del tráfico de erratas a dominios maliciosos o con publicidad engañosa.
Aquí pasa igual con tres siglas que se confunden por esa vocal solitaria, pero para evitarlo…

  • SLI (Service Level Indicator o indicador de nivel de servicio): es el indicador que se mide, el dato crudo, como el porcentaje de peticiones servidas correctamente.
  • SLO (Service Level Objective u objetivo de nivel de servicio): es la meta interna que el equipo quiere alcanzar.
  • SLA: lo que hemos visto, el compromiso acordado con el cliente y sus consecuencias asociadas.

La regla práctica es que el SLO siempre debe ser más exigente que el SLA, para que IT tenga margen de reacción antes de incumplir lo prometido.
Todo esto deriva de la práctica de Site Reliability Engineering que Google formalizó en su capítulo sobre objetivos de nivel de servicio, algo que da para mucho más de lo que me cabe aquí sin convertir esto en el tomo perdido de Harry Potter.
Para quienes deseen el desarrollo completo, está en nuestra guía sobre las diferencias entre SLA, SLO y SLI.

Cómo monitorizar el cumplimiento de un SLA

Un SLA que se comprueba a final de mes preguntando por ahí cómo ha ido es una encuesta de satisfacción, pero parafraseando (muy) libremente a Malraux, el cumplimiento debe ser continuo o no será y su medición también debe ser ininterrumpida.
Eso implica varias cosas y encima, todas a la vez.

  • Hace falta medir la disponibilidad de forma constante y desde un punto que tenga sentido, porque comprobar un servicio web desde el mismo centro de datos que lo aloja es un examen corregido por el alumno que lo hace.
  • Es necesario registrar las incidencias con marcas de tiempo fiables de apertura, toma, escalado y cierre.
  • Hay que guardar históricos, porque el dato del mes no sirve para detectar degradación progresiva.
  • Como todo esto es para mejorar la gestión y no solo cuestión de vanidad, son imprescindibles alertas que salten cuando el margen que queda se acerque al límite.

Con la monitorización de servidores e infraestructura resuelta, el cumplimiento se convierte en un cálculo automático por periodos y el informe deja de ser una ingrata tarea manual al día 30 del mes.
Y he aquí otro detalle que se pasa por alto bastantes veces, que el sistema de monitorización también cae.
Si nuestro vigilante se queda ciego dos horas, ese hueco tiene que interpretarse como algo y conviene decidir de antemano si cuenta como indisponibilidad para el SLA o como dato desconocido.
Dejar ese hueco al criterio del redactor del informe es una tentación innecesaria, porque prevalecerá lo que más le convenga, en lugar de lo más real.

Cómo ayuda Pandora FMS a medir SLA

Creemos en Pandora FMS sobre todas las cosas, porque para eso es la materialización de nuestra experiencia de más de 20 años, pero tranquilidad, porque no soy vendedor ni voy a jugar a serlo, así que hablemos de hechos y no de discursos de ventas.
¿Ayuda Pandora FMS a gestionar SLA?
Rotundamente sí.
Pandora FMS resuelve la papeleta de calcular el cumplimiento de SLA a partir de datos objetivos que recopila de la infraestructura.
Para Pandora no hay capa adicional de maquillaje ni la añade, lo que permite extraer la verdad que interesa a los dos firmantes del contrato de servicio. Así, Pandora FMS es vigilante, analista, repositorio y notario.
Los informes SLA nos permiten definir el objetivo (ya sea por módulo o servicio), además del periodo de medición y los intervalos que se consideran válidos. Con eso, devuelven el porcentaje alcanzado, junto con el detalle de cada corte experimentado en el periodo.
La documentación técnica sobre tipos de informe desarrolla las variantes a nuestro alcance y cómo se comporta cada una con el histórico.
Con todo eso, los puntos más usados para SLA en Pandora FMS:

  • Periodos de actividad. Limitando el cálculo al horario de cobertura acordado para que un corte a las 3:00 a.m. no penalice un SLA que debe medirse por contrato de 9 a 18.
  • Mantenimientos planificados. Las ventanas de parada de servicio se declaran en el sistema y el informe las contabiliza como tiempo válido, de modo que no penalizan el SLA. Exactamente lo que exigía el ejemplo de cálculo comentado más arriba.
  • Vista de servicios. El SLA se puede definir sobre un servicio compuesto y no solo sobre una máquina, incluso con pesos por elemento. Ahí radica la diferencia entre evaluar un servidor o medir lo que importa realmente al negocio.
  • Históricos y tendencias. Los datos en Pandora FMS se guardan para comparar periodos y detectar una posible degradación paulatina, esa que no dispara una alarma, pero nos devora el margen mes a mes.
  • Informes programados. El informe mensual se genera y envía solo con el formato que se haya determinado, convirtiendo el reporting en automático y sostenible cuando gestionas cuarenta clientes.

Eso sí, Pandora FMS no hace magia (todavía) y no sustituye a un acuerdo bien redactado. Si el SLA define objetivos que nadie puede medir, la mejor herramienta solo documentará con precisión que no se sabe si se cumple nada.
Lo cual nos lleva al siguiente punto fundamental, porque una herramienta es tan buena como el proceso que tiene detrás, así que veamos cómo optimizarlo.

Buenas prácticas a la hora de definir un SLA

Este es el momento de la verdad (tanto para cliente como para el proveedor IT), en el que no querremos entramparnos en un pacto fáustico que parece genial sobre el papel, pero nos morderá la mano en el día a día.
Para evitarlo debemos:

  • Comprometernos solo a métricas medibles. Porque si no existe forma automática de obtener el dato, esa cláusula no debería estar en el contrato.
  • Escribir cómo se calcula cada indicador. Lo que incluye fórmula, origen del dato, periodo del mismo y punto de medición. Dos partes con la misma cifra y método diferente de obtención van a acabar discutiendo.
  • Fijar claramente el periodo de medición. Una caída de 40 minutos implica un 99,91 % mensual y, a la vez, un 99,60 % semanal. ¿Cuál de ambos periodos cuenta? Porque con el mismo corte cumplimos o incumplimos según el periodo considerado, de modo que este nunca resulta un detalle administrativo.
  • Definir exclusiones con nombre y apellidos. Porque «fallos de terceros» a secas es ese cheque en blanco que comenté al principio.
  • Separar bien respuesta de resolución. Ya que son compromisos distintos con equipos, costes e indicadores diferentes.
  • Revisar los niveles cuando cambia el servicio. Si efectuamos una mudanza a la nube, los usuarios crecen mucho o actualizamos los equipos, estas nuevas circunstancias invalidan los supuestos originales que se firmaron y esas eventualidades deben especificarse por contrato.
  • Evitar objetivos no monitorizables. Lo cual constituye la Primera Directiva, que resume todas las anteriores.

Y por experiencia, un pequeño consejo que no suele aparecer por ahí.
No prometamos el nueve que no podamos sostener en nuestros indicadores. Es tentador, pero no, stop. Los martes de mantenimiento en cualquier MMO llevan enseñando desde hace veinte años la misma lección probada en millones de jugadores, que una parada anunciada, previsible y respetada genera muchas menos quejas que diez minutos de caída a traición.
Sobre el equilibrio entre lo prometido y lo sostenible hemos escrito más cuando tratamos cómo reducir horas de soporte sin perder SLA, aumentar la eficiencia operativa en IT, así como en la guía sobre tipos de SLA y mejores prácticas.

Preguntas frecuentes

Recompongamos el mapa del territorio recorrido con las preguntas más habituales sobre el mismo:

¿Qué significa SLA?

Service Level Agreement o acuerdo de nivel de servicio, el documento donde se fija qué nivel de dicho servicio se compromete a prestar, cómo se mide el cumplimiento y qué ocurre si este no se da.
Un SLA se puede firmar para muchas actividades, pero para lo que nos interesa aquí…

¿Qué es un SLA en informática?

El acuerdo formal que regula el nivel de un servicio IT y que detalla el porcentaje de disponibilidad de sistemas, los tiempos de atención de incidencias, horarios de cobertura y la forma de comprobar que se cumplen.
El SLA se aplica tanto a proveedores externos como a departamentos IT internos.

¿Cómo se calcula un SLA?

Su cumplimiento se mide de acuerdo a los diversos indicadores clave definidos en el mismo y que pueden variar, pero cuando la mayoría se hace esta pregunta, está pensando realmente en disponibilidad y cómo evaluarla, ya que suele ser uno de los componentes principales del SLA global.
Dicha disponibilidad se calcula como tiempo disponible dividido entre tiempo total medido, multiplicado por 100. De ese tiempo total se descuentan exclusiones pactadas, como ventanas programadas de mantenimiento.
El resto de métricas del SLA (como posibles tiempos de respuesta) se calculan como porcentaje de casos atendidos dentro del plazo comprometido.

¿Qué diferencia hay entre SLA y uptime?

Derivado de lo anterior, el uptime es una métrica, el porcentaje de tiempo que el sistema ha estado disponible, mientras que el SLA es el acuerdo completo.
Este puede incluir el uptime entre sus indicadores, junto a tiempos de respuesta, resolución y cobertura.

¿Qué es un SLA de tiempo de respuesta?

El compromiso sobre cuánto se tarda en atender una incidencia, según su prioridad.
Aquí se suele diferenciar entre primera respuesta, actualizaciones durante el ciclo y resolución, con plazos distintos para cada nivel de criticidad.

¿Qué ocurre si se incumple un SLA?

Depende de lo pactado en el contrato. Lo habitual son compensaciones económicas o descuentos en la factura, aunque en muchos acuerdos internos la consecuencia es un plan de acción documentado y una revisión del servicio.

¿Cuál es la diferencia entre SLA, SLO y SLI?

El SLI (Service Level Indicator) es el indicador que se mide, el SLO es el objetivo interno sobre ese indicador, mientras que el SLA es el compromiso acordado con el cliente.
El SLO debe ser, obviamente, más exigente que el SLA, para que IT tenga un margen de cara al cliente.

El acuerdo es la parte fácil

Como vemos, un SLA convierte expectativas en compromisos con número, periodo, método de cálculo y consecuencias de incumplimiento. Esto cambia la conversación entre proveedor y cliente porque dejamos de discutir sobre si el servicio «va bien» en términos nebulosos y pasamos a comprobar datos objetivos acordados que dan la respuesta real.
Lo que sustenta dicho dato es la monitorización continua, el histórico y los informes, pues sin ellos el acuerdo solo es un brindis al sol en formato tabla.
Antes del SLA, Scotty podía multiplicar por cuatro sus estimaciones ingenieras porque nadie las medía en la Enterprise, pero en cuanto alguien saca la regla… entonces el servicio deja de ser un truco de reputación para convertirse en ingeniería pura que se calcula, vigila y defiende con datos.

Shares