O SLA, ou "acordo de nível de serviço", é um acordo de garantia entre o cliente e o provedor de serviços sobre o que o cliente receberá em termos de atendimento. Ele também estipula compensações em caso de interrupções causadas pelo fornecedor e assim por diante. Basicamente, o SLA é um documento que garante ao potencial cliente que ele será bem tratado. A questão é que no SLA pode-se escrever qualquer coisa, e os eventos descritos nesse documento não ocorrem com frequência. O SLA não deve ser considerado um guia ao escolher um data center, e definitivamente não se deve contar com ele.
Todos nós estamos acostumados a assinar contratos que impõem certas obrigações. O SLA não é uma exceção — normalmente, é o documento mais desconectado da realidade que se pode imaginar. Provavelmente, só o NDA é mais inútil em jurisdições onde o conceito de "segredo comercial" não existe de verdade. O problema é que o SLA não ajuda o cliente a fazer a escolha certa do fornecedor, apenas dá uma impressão enganosa.
O que os provedores de hospedagem costumam incluir na versão pública do SLA que mostram ao público? Bem, a primeira frase geralmente menciona a "confiabilidade" do provedor — isso normalmente varia de 98 a 99,999%. Na verdade, esses números são apenas uma bela invenção dos profissionais de marketing. Antigamente, quando a hospedagem era cara e nova, e o conceito de nuvem era apenas um sonho distante (assim como o acesso de banda larga para todos), o indicador de uptime era extremamente importante. Hoje em dia, quando todos os fornecedores usam equipamentos muito semelhantes, estão em redes tronco comuns e oferecem pacotes de serviços semelhantes, o indicador de uptime é absolutamente irrelevante.
Existe um SLA "correto"?
Certamente existem versões ideais de SLA, mas todas elas são documentos atípicos e são elaboradas e firmadas manualmente entre o cliente e o fornecedor. Esse tipo de SLA geralmente se refere a trabalhos de contrato, mais do que a serviços.
O que deve constar em um bom SLA? Em resumo, um bom SLA é um documento que regula a relação entre duas entidades, conferindo ao cliente o máximo controle sobre o processo. Ou seja, como funciona na prática: há um documento que descreve os processos globais de interação e regula as relações entre as partes. Ele estabelece limites, regras e se torna um mecanismo de influência que ambas as partes podem utilizar plenamente. Assim, com um SLA adequado, o cliente pode exigir que o prestador de serviços trabalhe conforme acordado, e o prestador pode se proteger de pedidos excessivos de um cliente muito ativo. O cenário se apresenta assim: 'Está escrito no nosso SLA que assim e assado, pode sair, fazemos tudo como combinado.'
Portanto, 'SLA correto' = 'contrato de serviço adequado' que proporciona controle sobre a situação. E isso só é possível ao se trabalhar 'em igualdade'.
O que é escrito no site e o que se espera na realidade são coisas diferentes.
Na verdade, tudo o que discutiremos a seguir são truques de marketing típicos e um teste de atenção.
Se analisarmos os provedores de hospedagem nacionais populares, uma proposta é mais atraente que a outra: suporte 25/8, uptime de servidores de 99,9999999%, uma infinidade de seus próprios data centers em pelo menos toda a Rússia. Lembrem-se, por favor, do ponto sobre data centers, voltaremos a ele mais tarde.. Mas agora vamos falar sobre estatísticas ideais de resistência a falhas e o que uma pessoa enfrenta quando seu servidor realmente entra nos '0,0000001% de quedas'.
Com índices a partir de 98% ou mais, qualquer queda é um evento na iminência de uma margem de erro estatístico. O equipamento de trabalho e a conexão estão disponíveis ou não. Você pode usar um provedor com um índice de 'confiabilidade' de 50% (de acordo com seu próprio SLA) por anos sem um único problema ou 'ter quedas' uma vez por mês por alguns dias com aqueles que afirmam ter 99,99%.
Quando o momento da queda finalmente chega (e, lembre-se, um dia todos caem), o cliente enfrenta a máquina corporativa interna chamada 'suporte', e o contrato de prestação de serviços e o SLA vêm à tona. O que isso significa:
- Provavelmente, durante as primeiras quatro horas de inatividade, você não conseguirá reivindicar nada, embora alguns provedores de hospedagem comecem a recontar a tarifa (pagamento de compensação) a partir do momento da queda.
- Se o servidor estiver indisponível por mais tempo, pode ser que você consiga fazer uma solicitação para recontar a tarifa.
- E isso sob a condição de que o problema foi causado pelo fornecedor.
- Se o seu problema ocorreu devido a uma terceira parte (na rota principal), então ninguém é realmente culpado e a resolução do problema depende da sua sorte.
É importante entender que você nunca tem acesso à equipe de engenharia; na maioria das vezes, você é interrompido pela primeira linha de suporte, que se comunica com você enquanto os engenheiros reais tentam resolver a situação. Um cenário familiar?
Aqui, muitos esperam pelo SLA, que supostamente deve protegê-los de situações como essa. Mas, na prática, as empresas raramente ultrapassam os limites de seu próprio documento ou sabem como contornar a situação para minimizar seus próprios custos. A prioridade do SLA é tranquilizar e convencer que, mesmo em uma situação imprevista, 'tudo ficará bem'. O segundo objetivo do SLA é abordar os principais pontos críticos e dar ao fornecedor espaço para manobra, ou seja, a possibilidade de atribuir a falha a algo pelo que o fornecedor 'não é responsável'.
Além disso, os grandes clientes, na verdade, não se importam com as compensações previstas no SLA. 'Compensação de SLA' é um retorno de dinheiro dentro da tarifa proporcional ao tempo de inatividade do equipamento, que nunca cobrirá nem 1% das possíveis perdas financeiras e de reputação. Nesse caso, o cliente considera muito mais importante que os problemas sejam resolvidos rapidamente do que qualquer tipo de 'recontagem de tarifa'.
'Múltiplos data centers em todo o mundo' — um motivo de preocupação.
A situação com um grande número de data centers do fornecedor foi colocada em uma categoria à parte, porque além dos óbvios problemas de comunicação já descritos, surgem problemas não tão claros. Por exemplo, seu fornecedor não tem acesso aos 'seus' data centers.
Em nosso artigo anterior , cujo cerne é a revenda de recursos de terceiros sob sua própria marca. A grande maioria dos provedores de hospedagem modernos que alegam possuir "seus próprios data centers" em várias regiões são revendedores no modelo White Label. Ou seja, fisicamente eles não têm nenhuma relação com um hipotético data center na Suíça, Alemanha ou Países Baixos.
Aqui surgem colisões extremamente interessantes. Seu SLA com o prestador de serviços ainda está ativo e válido, mas de alguma forma, o prestador não consegue influenciar a situação em caso de emergência. Ele mesmo está em uma posição dependente de seu próprio fornecedor — o data center, do qual foram comprados os racks de recursos para revenda.
Assim, se você valoriza não apenas belas formulações no contrato e no SLA sobre confiabilidade e serviço, mas também a capacidade do prestador de serviços de resolver problemas rapidamente — vale a pena trabalhar diretamente com o proprietário dos recursos. Na verdade, isso implica uma interação direta com o data center.
Por que não consideramos situações em que vários DCs podem na verdade pertencer a uma única empresa? Bem, há muito poucas dessas empresas. Um, dois, três pequenos data centers ou um grande — isso é real. Mas uma dúzia de DCs, metade deles na Rússia e a outra metade na Europa — é praticamente impossível. Isso significa que há muito mais empresas revendedoras do que se pode imaginar. Aqui está um exemplo simples:
Avalie a quantidade de data centers do serviço Google Cloud. Na Europa, há apenas seis. Em Londres, Amsterdã, Bruxelas, Helsinque, Frankfurt e Zurique. Ou seja, em todos os principais pontos de infraestrutura. Porque o data center é caro, complexo e um projeto muito grande. E agora, lembre-se das empresas de hospedagem de Moscovo com "uma dúzia de data centers por toda a Rússia e Europa".
Não, claro, há bons provedores com parceiros no programa White Label, e eles oferecem serviços de primeira linha. Eles permitem alugar recursos na UE e na Rússia ao mesmo tempo através de uma única janela do navegador, aceitam pagamento em rublos, e não em moeda estrangeira, e assim por diante. Mas, diante das situações descritas no SLA, eles se tornam exatamente tão reféns da situação quanto você.
Isso nos lembra mais uma vez que o SLA é inútil se você não tem ideia da estrutura da organização e das capacidades do fornecedor.
E no final
A queda de servidores é sempre um evento desagradável e pode acontecer com qualquer um, em qualquer lugar. A questão é qual nível de controle da situação você deseja ter. Atualmente, há poucos fornecedores diretos de capacidade no mercado, e se falarmos dos grandes players, eles costumam possuir, em termos gerais, apenas um DC em algum lugar em Moscovo, entre dezenas por toda a Europa, aos quais você pode ter acesso.
Aqui, cada cliente deve decidir por si mesmo: eu escolho conforto agora ou perco tempo e esforço procurando um data center em um ponto aceitável na Rússia ou na Europa, onde posso hospedar meu equipamento ou comprar capacidade. No primeiro caso, soluções padrão disponíveis no mercado podem servir. No segundo, você terá que trabalhar duro.
Em primeiro lugar, é necessário determinar se o vendedor de serviços é o proprietário direto das capacidades/data center. Muitos revendedores no modelo White Label disfarçam sua situação, e nesse caso, você deve observar alguns sinais indiretos. Por exemplo, se "seus DCs europeus" tiverem nomes e logotipos específicos que diferem do nome da empresa fornecedora. Ou se em algum lugar surgir a palavra "parceiros". Parceiros = White Label em 95% dos casos.
Em seguida, é necessário se familiarizar com a estrutura da empresa e, de preferência, ver o equipamento ao vivo. Entre os data centers, não é nova a prática de excursões ou, no mínimo, artigos de excursão em seu próprio site ou blog (nós escrevemos alguns), e ), onde eles falam sobre seu data center com fotografias e descrições detalhadas.
Com muitos data centers, é possível combinar uma visita pessoal ao escritório e uma mini-excursão ao próprio DC. Lá, você pode avaliar a organização, e talvez consiga conversar com alguém dos engenheiros. É claro que ninguém fará uma excursão pela produção se você precisar de um servidor por 300 RUB/mês, mas se você precisar de capacidades sérias, o departamento de vendas pode muito bem atender ao seu pedido. Nós, por exemplo, realizamos essas excursões.
De qualquer forma, é importante seguir o bom senso e as necessidades do negócio. Por exemplo, ao precisar de uma infraestrutura distribuída (parte dos servidores na Rússia, a outra na União Europeia), será mais simples e vantajoso utilizar os serviços de provedores que têm parcerias com centros de dados europeus sob o modelo White Label. Se toda a sua infraestrutura estiver concentrada em um único ponto, ou seja, em um único data center, vale a pena dedicar algum tempo à busca por um fornecedor.
Porque um SLA padrão provavelmente não será útil para você. Mas trabalhar diretamente com o proprietário da infraestrutura, e não com um intermediário, pode acelerar significativamente a resolução de problemas potenciais.
Fonte: habr.com
