[ATENCIÓN: TOCHO] Hace un tiempo me crucé en la red con una historia real de un administrador de sistemas de Brooklin, Michael Gorsuch. Brevemente cuenta cómo una noche tuvo que desplazarse en dos ocasiones a su centro de datos, propiedad de una compañía importante de servicios IP e Internet llamada Peer1. Al parecer los servidores que él administraba no respondían desde fuera de la red hasta que finalmente tras varias horas lograron recuperar el servicio. El autor hace una reflexión sobre la utilidad y confianza en los servicios SLA y de si son o no válidos a la hora de tomarlos en cuenta.
| Uptime | Tiempo perdido (año) |
|---|---|
| 98% | 7.3 días |
| 99.0% | 3.7 días |
| 99.9% | 8 horas |
| 99.99% | 1 hora |
| 99.999% | 5 minutos |
En varias ocasiones he visto situaciones similares a las de Michael, pero en el lado opuesto, en el del ISP, donde trabajo. Primero debemos saber qué es SLA (en inglés). Básicamente es un contrato entre el proveedor de servicios y el cliente que establece la calidad del servicio contratado, así como las penalizaciones por imcumplimiento del mismo.
Para las empresas que requieren tener todos sus servicios funcionando 24h. al día, es algo vital contratar este tipo de servicios para tener la "garantía" de que su servicio no va a ser interrumpido, o al menos, el menor tiempo posible. La cuestión es: ¿es realmente fiable? ¿Nos va a garantizar lo que nos venden? Sinceramente: No. Para comprenderlo debemos saber qué tiempos comprende este servicio que vienen a ser desde el instante en que se produce el corte o interrupción del servicio, hasta que permanece estable, y el tiempo que cuenta es el del proceso realizado hasta conseguirlo. En el cuadro de arriba se ve claramente el tiempo que muchos proveedores de servicios garantizan, algo que dista mucho de la realidad.
Cuando un administrador de sistemas recibe el aviso del fallo del sistema que maneja (vía Nagios, Hobbit o clientes insatisfechos) lo primero que hace es comprobar si la alarma es real o un simple aviso falso (que ocurre y mucho). Algo importante es la localización de los equipos ya que no siempre se tiene acceso físicamente a los mismos, por lo que ya se pierde un tiempo importante para desplazarse a donde están ubicados (normalmente un data center). Después chequea si el equipo funciona correctamente y si sus servicios están activos. Ésto es algo que es rutina y en pocos segundos o minutos está solucionado si es local, pero ¿y si, a pesar de tenerlo todo correcto se sigue sin detectar el origen del fallo? El segundo paso sería comprobar la propia red (swithes o hubs, routers, firewalls, puntos de acceso, cableado) cosa que, dependiendo de la complejidad de la red, puede tomar más o menos tiempo. Si aún así se continúa sin acceder al exterior de la red es cuando se avisa al personal de tu proveedor de servicios para realizar las pruebas. Éste punto es importante, puesto que depende (y mucho) de la disponibilidad de los operarios que haya en ese momento, por lo que desde que se avisa de la falla de servicio hasta que se comienza a realizar pruebas pasa un tiempo importante que se suma al tiempo restante del SLA.
Si además, tu proveedor tiene subcontratos con otros proveedores más importante que llevan su tráfico y/o gestionan parte de su red, se debe esperar de nuevo a disponibilidad y agilidad en las pruebas con los técnicos de éstos. Si finalmente se encuentra que el problema residía en un equipo intermedio del operador debemos esperar a que éste realice la reparación o sustitución del equipo, además de la configuración del mismo (en caso de no tener disponible uno de backup) y de las pruebas necesarias para comprobar su estabilidad.
Normalmente los SLA´s se suelen indicar en esos valores, ya que a pesar de no haber ningún método fiable que garantice el 100% del servicio estable, las pocas o improbables causas que pueden provocar la pérdida de servicio se tiende a no tomarlas en cuenta. Es por ello que no debería considerarse un valor importante a la hora de decidir cómo administrar una red y/o servicio.
De los valores indicados, el que más se puede acercar a la realidad según mi experiencia es el del 98% uptime (unos 7 días y 8 horas). Cuando en alguna llama algún cliente para saber cuando va a estar solucionada una incidencia contesto con un simple: "no es posible saberlo, estamos haciendo todo lo posible pero estamos revisando la red para detectar el origen del fallo." Lo que la gran mayoría de personas no entiende es que es tal la cantidad de equipos y puntos de conexión entre el cliente y el servidor, que si bien la mayor parte de los fallos son detectados y reparados al momento, otras veces se desconocen las causas y hace falta un análisis más profundo y complejo que suele tirar por tierra el contato SLA, incluso de manera exagerada (he visto como una empresa de hoteles ha estado 3 días sin conexión con la central, impidiendo realizar reservas esos días, siendo indemnizados con 1000€ por contrato SLA ...).
¿Alguien se cree que en 5 minutos va a estar resuelta una avería que ni los técnicos conocen la causa? La única manera de conseguirlo es teniendo el sistema completo por duplicado, es decir, tener una réplica de cada máquina lista para ser conectada en caso de que fallase su gemela, y eso, cuesta demasiado dinero (además de tener que realizar el doble de trabajo). Es por eso que a las empresas les sale más barato pagar la indemnicación que poner medios (reales) suficientes para garantizar que se cumple ese 99,999% uptime. Algo muy común en empresas de varios sectores como puede ser compañías aéreas (recordáis Fight Club?), compañías de seguros (cómo no!) y un largo etcétera.
Por cierto, cuando os quedéis sin conexión a Internet en casa y sea causa de la operadora, tener en cuenta que el tiempo máximo para que se repare la incidencia es de 48h, sea lo urgente que sea, tanto cono ONO, Telefónica, Ya.com y restantes (aunque casi nunca se haga, la letra pequeña nos descubre mundos insólitos). Vamos, se reservan hasta 2 días para que no les puedas reclamar (aunque muchas veces te indemnizan con las horas que has estado sin poder conectarte).
Historia de Michael: SLA
Más info: What is 99% uptime?
