SLA, también es un "acuerdo de nivel de servicio", un acuerdo de garantía entre el cliente y el proveedor de servicios sobre lo que el cliente recibirá en términos del servicio. También estipula una compensación en caso de tiempo de inactividad debido a la falla del proveedor, etc. En esencia, un SLA es una credencial con la cual un centro de datos o proveedor de alojamiento convence a un cliente potencial de que será tratado amablemente en todos los sentidos y en general. La pregunta es que puede escribir cualquier cosa en SLA, y los eventos descritos en este documento no ocurren con demasiada frecuencia. El SLA está lejos de ser una guía en la selección de un centro de datos y ciertamente no debe confiar en él.
Todos estamos acostumbrados a firmar algún tipo de acuerdos que imponen ciertas obligaciones. El SLA tampoco es una excepción, generalmente el documento más divorciado de la realidad. Probablemente más inútil es probablemente solo el NDA en jurisdicciones donde el concepto de "secreto comercial" realmente no existe. Y todo el problema es que el SLA no ayuda al cliente en la elección correcta del proveedor, sino que solo derrocha.
¿Qué escriben los hosters con más frecuencia en la versión pública de SLA que muestran al público? Bueno, la primera línea es un término que se denomina "confiabilidad" del host; estos generalmente son números del 98 al 99.999%. De hecho, estos números son solo un hermoso invento de los vendedores. Érase una vez, cuando el alojamiento era joven y costoso, y solo los especialistas soñaban con las nubes (así como el acceso de banda ancha para todos), el indicador del tiempo de actividad del alojamiento era extremadamente y extremadamente importante. Ahora, cuando todos los proveedores usan el más o menos uno y el mismo equipo, se sientan en las mismas redes troncales y ofrecen los mismos paquetes de servicios, el indicador de tiempo de actividad no es indicativo.
¿Existe un SLA "correcto"?
Por supuesto, existen versiones ideales de SLA, pero todos ellos son documentos no estándar y están escritos y concluidos entre el cliente y el proveedor en modo manual. Además, es este tipo de SLA el que más a menudo se relaciona con algún tipo de trabajo por contrato en lugar de servicios.
¿Qué debería estar en un buen SLA? Si le da TLDR, entonces un buen SLA es un documento que regula las relaciones entre dos entidades, lo que le da a una de las partes (el cliente) el máximo control sobre el proceso. Es decir, cómo funciona en el mundo real: hay un documento que describe los procesos globales de interacción y regula la relación entre las partes. Establece límites, reglas y, en sí mismo, se convierte en una palanca de influencia que ambas partes pueden aprovechar al máximo. Entonces, gracias al SLA correcto, el cliente puede simplemente hacer que el contratista trabaje según lo acordado, y el contratista puede ayudar a luchar contra un cliente demasiado activo que no está justificado por el contrato. Se ve así: "En nuestro SLA está escrito de esta manera y que, a partir de aquí, hacemos todo lo acordado".
Es decir, "el SLA correcto" = "contrato adecuado para la prestación de servicios" y da control sobre la situación. Y quizás esto es solo cuando se trabaja en igualdad de condiciones.
Lo que escriben en el sitio y lo que les espera en realidad son dos cosas diferentes.
En general, todo lo que discutiremos más a fondo son los típicos trucos de marketing y una verificación de atención.
Si tomamos servidores domésticos populares, entonces una sugerencia es más hermosa que la otra: soporte 25/8, tiempo de actividad del servidor el 99.9999999% del tiempo, muchos de sus centros de datos están al menos en Rusia. Recuerde el momento sobre los centros de datos,
volveremos sobre él un poco más tarde . Mientras tanto, hablemos sobre las estadísticas ideales de tolerancia a fallas y lo que una persona encuentra cuando su servidor, sin embargo, cae en “0.0000001% de fallas”.
Con indicadores del 98% y superiores, cualquier caída es un evento al borde del error estadístico. El equipo de trabajo y la conexión están allí o no. Durante años, puede usar el alojamiento con una tasa de "confiabilidad" del 50% (de acuerdo con su SLA) sin un solo problema o "caída" una vez al mes durante un par de días en los tipos donde se declara el 99.99%.
Sin embargo, cuando llega el momento de la caída (y todo cae, recordamos, algún día), el cliente se encuentra con una máquina corporativa interna llamada "soporte", y el contrato para la prestación de servicios y SLA sale a la luz. ¿Qué significa esto?
- lo más probable es que durante las primeras cuatro horas de tiempo de inactividad no pueda presentar nada, aunque algunos proveedores de alojamiento comienzan a recalcular la tarifa (pagando una compensación) desde el momento en que caen.
- Si el servidor no está disponible por más tiempo, puede enviar una solicitud de recuento de tarifas.
- Y esto se establece que el problema surgió por culpa del proveedor.
- Si su problema surgió debido a un tercero (en la carretera), parece que "nadie tiene la culpa" y cuando se resuelve el problema, la cuestión de su suerte.
Es importante comprender que nunca tiene acceso al equipo de ingeniería, la mayoría de las veces se detiene en la primera línea de soporte, que se corresponde con usted, mientras que los verdaderos ingenieros intentan corregir la situación. El escenario familiar?
Aquí, muchos confían en el SLA, que, al parecer, debería protegerlo de tales situaciones. Pero, de hecho, las empresas rara vez van más allá de los límites de su propio documento o pueden cambiar la situación para minimizar sus propios costos. El objetivo principal del SLA es calmar la vigilancia y convencer de que incluso en el caso de una situación imprevista, "todo estará bien". La segunda tarea del SLA es discutir los puntos críticos clave y darle al proveedor de servicios espacio para maniobrar, es decir, la capacidad de atribuir la falla a algo de lo que el proveedor "no es responsable".
Al mismo tiempo, a los grandes clientes, de hecho, no les importa la compensación bajo el SLA. "Compensación por SLA" es un reembolso dentro de la tarifa en proporción al tiempo de inactividad del equipo, que nunca cubrirá ni siquiera el 1% de las posibles pérdidas de efectivo y reputación. En este caso, es mucho más importante para el cliente que los problemas se solucionen lo antes posible, en lugar de algún tipo de "recuento de tarifas".
"Muchos centros de datos en todo el mundo" - motivo de preocupación
Hemos ubicado la situación con un gran número de centros de datos en el proveedor de servicios en una categoría separada, porque además de los problemas de comunicación obvios descritos anteriormente, también surgen problemas no obvios. Por ejemplo, su proveedor de servicios no tiene acceso a "sus" centros de datos.
En nuestro último artículo,
escribimos sobre los tipos de programas de afiliación y mencionamos el modelo White Label , cuya esencia es la reventa de las capacidades de otras personas bajo su propia apariencia. La gran mayoría de los albergues modernos que afirman tener "sus centros de datos" en muchas regiones son revendedores que utilizan el modelo White Label. Es decir, físicamente no tienen nada que ver con un centro de datos condicional en Suiza, Alemania o los Países Bajos.
Aquí surgen colisiones extremadamente interesantes. Su SLA con el proveedor de servicios aún funciona y está operativo, pero el proveedor no puede afectar de manera radical la situación en caso de accidente. Él mismo está en una posición dependiente de su propio proveedor: un centro de datos, desde el cual se compraron capacidades de estante para reventa.
Por lo tanto, si no solo es importante para usted una redacción hermosa en el acuerdo y el acuerdo de nivel de servicio (SLA) sobre confiabilidad y servicio, sino también la capacidad del proveedor del servicio para resolver rápidamente los problemas, vale la pena trabajar directamente con el propietario de las instalaciones. De hecho, esto implica una interacción directa directamente con el centro de datos.
¿Por qué no consideramos las opciones cuando muchos DC pueden pertenecer a una sola empresa? Bueno, hay muy, muy pocas empresas de este tipo. Uno, dos, tres centros de datos pequeños o uno grande: esto es real. Pero una docena de DC, la mitad de los cuales están en la Federación de Rusia, y la segunda en Europa son casi imposibles. Y esto significa que hay muchas más empresas de reventa de las que puedas imaginar. Aquí hay un ejemplo simple:
Estime la cantidad de centros de datos del servicio Google Cloud. En Europa solo hay seis. En Londres, Amsterdam, Bruselas, Helsinki, Frankfurt y Zurich. Es decir, en todos los puntos troncales principales. Porque el centro de datos es un proyecto costoso, complejo y muy grande. Ahora recuerde las compañías de hosting de algún lugar de Moscú con "una docena de centros de datos en toda Rusia y Europa".Por supuesto, no hay suficientes buenos proveedores que tengan socios en el programa White Label y brindan servicios de primer nivel. Permiten alquilar capacidades en la UE y la Federación de Rusia al mismo tiempo a través de la misma ventana del navegador, aceptar pagos en rublos, no en moneda, etc. Pero al ocurrir los casos descritos en el SLA, se convierten exactamente en los mismos rehenes de la situación que usted.
Una vez más, esto nos recuerda que un SLA es inútil a menos que tenga una pista sobre la estructura de la organización y las capacidades del proveedor.
Cual es el resultado
Los bloqueos del servidor son siempre un evento desagradable y pueden sucederle a cualquiera, en cualquier lugar. La pregunta es qué grado de control sobre la situación que desea. Ahora el mercado no tiene demasiados proveedores directos de capacidades, y si hablamos de grandes jugadores, ellos poseen, por convención, solo un DC en algún lugar de Moscú de una docena en toda Europa, al que puede acceder.
Aquí, cada cliente debe decidir por sí mismo: elijo la comodidad en este momento o paso tiempo y energía buscando un centro de datos en un punto aceptable en Rusia o Europa, donde puedo colocar mi equipo o comprar capacidades. En el primer caso, las soluciones estándar que están actualmente en el mercado funcionarán. En el segundo, tienes que sudar.
En primer lugar, es necesario identificar si el vendedor de servicios es el propietario directo de las instalaciones / centro de datos. Muchos revendedores de White Label enmascaran su estado con todas sus fuerzas, y en este caso necesitamos observar algunos signos indirectos. Por ejemplo, si "sus DC europeos" tienen algunos nombres y logotipos específicos que difieren del nombre de la empresa proveedora. O si en algún lugar la palabra "socios" parpadea. Socios = White Label en el 95% de los casos.
A continuación, debe familiarizarse con la estructura de la empresa, pero es mejor mirar el equipo en vivo. Entre los centros de datos, la práctica de excursiones o al menos artículos de excursiones en su propio sitio web o blog no es nueva (los escribimos
una y
dos veces ), donde hablan sobre su centro de datos con fotos y descripciones detalladas.
Con muchos centros de datos, puede organizar una visita personal a la oficina y mini-excursiones a la propia DC. Allí puede evaluar el grado de orden, tal vez pueda comunicarse con uno de los ingenieros. Está claro que nadie organizará una excursión a la producción si necesita un servidor por 300 RUB / mes, pero si necesita una gran capacidad, el departamento de ventas puede encontrarse con usted. Por ejemplo, realizamos tales excursiones.
En cualquier caso, debe guiarse por el sentido común y las necesidades del negocio. Por ejemplo, si necesita una infraestructura distribuida (algunos servidores en la Federación de Rusia, el segundo en la UE), será más fácil y rentable utilizar los servicios de los proveedores de alojamiento que tienen asociaciones con centros de distribución europeos según el modelo White Label. Si toda su infraestructura se concentra en un punto, es decir, en un centro de datos, entonces debe dedicar un tiempo a la cuestión de encontrar un proveedor.
Porque un SLA típico probablemente no lo ayudará. Pero trabajar con el propietario de las instalaciones, y no con el revendedor, acelerará significativamente la solución de posibles problemas.