O SLA, tamén coñecido como "acordo de nivel de servizo", é un acordo de garantía entre o cliente e o provedor de servizos sobre o que o cliente recibirá en termos de servizo. Tamén estipula indemnizacións en caso de parada por culpa do provedor, etc. En esencia, un SLA é unha credencial coa axuda da cal un centro de datos ou provedor de hospedaxe convence a un cliente potencial de que será tratado amablemente de todas as formas posibles. A cuestión é que podes escribir o que queiras no SLA e os eventos escritos neste documento non ocorren con demasiada frecuencia. O SLA dista moito de ser unha pauta para seleccionar un centro de datos e certamente non deberías confiar nel.
Todos estamos afeitos a asinar algún tipo de convenios que impoñan certas obrigas. O SLA non é unha excepción, normalmente o documento máis irreal que se poida imaxinar. O único que probablemente sexa máis inútil é un NDA en xurisdicións onde o concepto de "segredo comercial" non existe realmente. Pero todo o problema é que o SLA non axuda ao cliente a elixir o provedor correcto, senón que só bota po nos ollos.
Que escriben os hosters con máis frecuencia na versión pública do SLA que mostran ao público? Ben, a primeira liña é o termo "fiabilidade" do servidor: adoitan ser números do 98 ao 99,999%. De feito, estes números son só un fermoso invento dos comerciantes. Érase unha vez, cando o hospedaxe era novo e caro e as nubes eran só un soño para os especialistas (así como o acceso a banda ancha para todos), o indicador de tempo de actividade do hospedaxe era extremadamente importante. Agora, cando todos os provedores usan, máis ou menos, o mesmo equipo, sentan nas mesmas redes troncais e ofrecen os mesmos paquetes de servizos, o indicador de tempo de actividade é absolutamente nada destacable.
Hai mesmo un SLA "correcto"?
Por suposto, hai versións ideais de SLA, pero todos eles son documentos non estándar e están rexistrados e concluídos entre o cliente e o provedor manualmente. Ademais, este tipo de SLA refírese na maioría das veces a algún tipo de traballo por contrato en lugar de servizos.
Que debería incluír un bo SLA? Por dicilo TLDR, un bo SLA é un documento que regula a relación entre dúas entidades, que dá a unha das partes (o cliente) o máximo control sobre o proceso. É dicir, como funciona no mundo real: hai un documento que describe os procesos de interacción globais e regula as relacións entre as partes. Establece límites, regras e convértese en si mesmo nunha panca de influencia que ambas as partes poden utilizar ao máximo. Así, grazas ao SLA correcto, o cliente pode simplemente obrigar ao contratista a traballar segundo o acordado e axúdalle ao contratista a loitar contra os "queridos" dun cliente excesivamente activo que non están xustificados polo contrato. Parece así: "O noso SLA di isto e aquilo, sae de aquí, facemos todo segundo o acordado".
É dicir, "o SLA correcto" = "un contrato adecuado para a prestación de servizos" e dá control sobre a situación. Pero isto só é posible cando se traballa "como iguais".
O que está escrito na páxina web e o que agarda na realidade son dúas cousas diferentes
En xeral, todo o que comentaremos máis adiante son trucos típicos de mercadotecnia e unha proba de atención.
Se tomamos hosters domésticos populares, entón unha oferta é mellor que a outra: soporte 25/8, tempo de funcionamento do servidor o 99,9999999% do tempo, unha morea de centros de datos propios polo menos en Rusia. Lembra o punto sobre os centros de datos, voltaremos a el un pouco máis tarde. Mentres tanto, imos falar das estatísticas ideais de tolerancia a fallos e do que se enfronta unha persoa cando o seu servidor aínda cae no "0,0000001% de fallos".
Con indicadores do 98% ou superiores, calquera caída é un evento ao bordo do erro estatístico. Os equipos de traballo e a conexión están aí ou non. Podes usar un hoster cunha clasificación de "fiabilidade" do 50% (segundo o seu propio SLA) durante anos sen ningún problema, ou podes "fallar" unha vez ao mes durante un par de días cos mozos que reclaman o 99,99%.
Cando chega o momento da caída (e, lembrámosche, todos caen algún día), entón o cliente enfróntase a unha máquina corporativa interna chamada "soporte" e saen á luz o acordo de servizo e o SLA. Qué significa:
- O máis probable é que durante as catro primeiras horas de inactividade non poidas presentar nada, aínda que algúns hosters comezan a recalcular a tarifa (pago da indemnización) desde o momento do accidente.
- Se o servidor non está dispoñible durante un período de tempo máis longo, podes enviar unha solicitude de recálculo de tarifas.
- E isto está sempre que o problema xurdiu por culpa do provedor.
- Se o teu problema xurdiu debido a un terceiro (na autoestrada), entón parece que "ninguén ten a culpa" e cando se solucione o problema é cousa da túa sorte.
Non obstante, é importante entender que nunca accede ao equipo de enxeñería, a maioría das veces é detido pola primeira liña de apoio, que se corresponde contigo mentres os enxeñeiros reais intentan solucionar a situación. Soa familiar?
Aquí, moitas persoas confían no SLA, que, ao parecer, debería protexelo de tales situacións. Pero, de feito, as empresas raramente superan os límites do seu propio documento ou son capaces de cambiar a situación de forma que minimicen os seus propios custos. A tarefa principal dun SLA é calmar a vixilancia e convencer de que mesmo en caso de situación imprevista, "todo estará ben". O segundo propósito dun SLA é comunicar os principais puntos críticos e dar marxe de manobra ao provedor de servizos, é dicir, a capacidade de atribuír un fallo a algo do que o provedor "non é responsable".
Ao mesmo tempo, os grandes clientes, de feito, non lles importa nada a compensación dentro do SLA. A "compensación de SLA" é un reembolso de diñeiro dentro da tarifa en proporción ao tempo de inactividade do equipo, que nunca cubrirá nin sequera o 1% das perdas monetarias e de reputación potenciais. Neste caso, é moito máis importante para o cliente que os problemas se resolvan canto antes que algún tipo de "recalculo de tarifas".
"Moitos centros de datos en todo o mundo" é motivo de preocupación
Colocamos a situación cun gran número de centros de datos nun provedor de servizos nunha categoría separada, porque ademais dos obvios problemas de comunicación descritos anteriormente, tamén xorden problemas non obvios. Por exemplo, o teu fornecedor de servizos non ten acceso aos "seus" centros de datos.
No noso último artigo , cuxa esencia é a revenda de capacidades alleas baixo o seu propio disfraz. A gran maioría dos hospedadores modernos que afirman ter "os seus propios centros de datos" en moitas rexións son revendedores que usan o modelo White Label. É dicir, fisicamente non teñen nada que ver co centro de datos condicional en Suíza, Alemaña ou Holanda.
Aquí xorden colisións moi interesantes. O teu SLA co provedor de servizos aínda funciona e é válido, pero o provedor non pode influír radicalmente na situación en caso de accidente. El mesmo está nunha posición dependente do seu propio provedor: o centro de datos, do que se compraron os bastidores de alimentación para a súa revenda.
Así, se valoras non só a fermosa redacción do contrato e o SLA sobre a fiabilidade e o servizo, senón tamén a capacidade do provedor de servizos para resolver problemas rapidamente, deberías traballar directamente co propietario das instalacións. De feito, isto implica a interacción directa directamente co centro de datos.
Por que non consideramos opcións cando moitos DC poden pertencer realmente a unha empresa? Ben, hai moi, moi poucas empresas deste tipo. É posible un, dous, tres centros de datos pequenos ou un grande. Pero unha ducia de DC, a metade dos cales están na Federación Rusa e a segunda en Europa, é case imposible. Isto significa que hai moitas máis empresas revendedoras das que podes imaxinar. Aquí tes un exemplo sinxelo:
Estima o número de centros de datos do servizo de Google Cloud. Só hai seis en Europa. En Londres, Amsterdam, Bruxelas, Helsinki, Frankfurt e Zúric. É dicir, en todos os puntos principais da estrada. Porque un centro de datos é caro, complexo e un proxecto moi grande. Agora lembra as empresas de hospedaxe de Moscova con "unha ducia de centros de datos en toda Rusia e Europa".
Non hai, por suposto, bos provedores que teñan socios no programa White Label, hai suficientes e ofrecen servizos do máis alto nivel. Permiten alugar capacidade na UE e na Federación Rusa simultaneamente a través da mesma xanela do navegador, aceptar pagos en rublos, non en moeda estranxeira, etc. Pero cando ocorren os casos descritos no SLA, convértense exactamente nos mesmos reféns da situación que ti.
Isto lémbranos unha vez máis que un SLA é inútil se non entendes a estrutura organizativa e as capacidades do provedor.
Cal é o resultado?
Un fallo do servidor sempre é un evento desagradable e pode ocorrerlle a calquera, en calquera lugar. A pregunta é canto control sobre a situación quere. Agora non hai demasiados provedores directos de capacidade no mercado, e se falamos de grandes xogadores, entón son propietarios, relativamente falando, dun só DC nalgún lugar de Moscova dunha ducia de toda Europa á que podes acceder.
Aquí, cada cliente debe decidir por si mesmo: escollo a comodidade agora mesmo ou dedico tempo e esforzo a buscar un centro de datos nun lugar aceptable en Rusia ou Europa, onde poida colocar o meu equipo ou mercar capacidade. No primeiro caso son adecuadas as solucións estándar que hai actualmente no mercado. No segundo, terás que suar.
En primeiro lugar, é necesario determinar se o vendedor do servizo é o propietario directo das instalacións/centro de datos. Moitos revendedores que utilizan o modelo White Label intentan disimular o seu estado e, neste caso, cómpre buscar algúns sinais indirectos. Por exemplo, se "os seus DC europeos" teñen algúns nomes e logotipos específicos que difiren do nome da empresa subministradora. Ou se a palabra "socios" aparece nalgún lugar. Socios = marca branca no 95% dos casos.
A continuación, cómpre familiarizarse coa estrutura da propia empresa, ou mellor aínda, mirar o equipo en persoa. Entre os centros de datos, a práctica de excursións ou polo menos artigos de excursións no seu propio sitio web ou blog non é nova (escribimos tales и ), onde falan do seu centro de datos con fotos e descricións detalladas.
Con moitos centros de datos, pode organizar unha visita persoal á oficina e unha mini-excursión ao propio DC. Alí poderás valorar o grao de orde, quizais poidas comunicarte con algún dos enxeñeiros. Está claro que ninguén che dará un percorrido pola produción se necesitas un servidor por 300 RUB/mes, pero se necesitas unha capacidade seria, o departamento de vendas pode atoparte. Por exemplo, realizamos este tipo de excursións.
En todo caso, débese empregar o sentido común e as necesidades empresariais. Por exemplo, se necesitas unha infraestrutura distribuída (algúns dos servidores están na Federación Rusa, o outro na UE), será máis fácil e rendible utilizar os servizos de hospedadores que teñan asociacións con DC europeos mediante a Marca Branca. modelo. Se toda a túa infraestrutura estará concentrada nun momento, é dicir, nun centro de datos, paga a pena dedicar algún tempo a buscar un provedor.
Porque un SLA típico probablemente non che axude. Pero traballar co propietario das instalacións, e non cun revendedor, acelerará significativamente a resolución de posibles problemas.
Fonte: www.habr.com