Se você está colocando uma rede de proxies em um pipeline de produção, alguém do departamento de compras ou da engenharia de plataforma vai eventualmente perguntar qual é o SLA. É a pergunta certa, e as respostas que você recebe costumam ser menos informativas do que parecem, porque um número como 99,9% não significa nada até que você saiba contra o que ele é medido, em qual janela de tempo, e o que acontece quando ele não é cumprido.
Há também uma armadilha específica nessa categoria. Um SLA de proxy promete que o gateway está acessível. Ele não promete que os sites dos quais você coleta dados vão deixar suas requisições passarem, e essas são coisas muito diferentes. Entender esse limite é a maior parte do que você precisa saber antes de assinar qualquer coisa.
O que um número de uptime realmente significa
Três variáveis estão por trás de cada porcentagem, e um provedor que só te dá a porcentagem te deu a parte menos útil.
A primeira é a janela de medição. Um SLA mensal de 99,9% permite aproximadamente 43 minutos de indisponibilidade por mês. O mesmo 99,9% medido anualmente permite cerca de 8 horas e 45 minutos, e permite que essas horas sejam consecutivas. O mensal é significativamente mais rigoroso, e um provedor que cita um número anual está citando uma promessa mais fraca com a mesma linguagem.
A segunda é a definição de indisponibilidade. O serviço está fora do ar quando o gateway recusa conexões, ou também quando ele está tecnicamente respondendo mas a taxa de erro disparou, ou a latência degradou a ponto de se tornar inútil? Muitos SLAs contam apenas a indisponibilidade completa, o que significa que um período em que toda requisição retorna erro mas o endpoint ainda está aceitando conexões pode não ser registrado como indisponibilidade de forma alguma.
A terceira é quem mede isso. Se o provedor é a única fonte de verdade e não publica nenhum registro independente, o número é autodeclarado. Uma página de status pública com histórico de incidentes é o que torna isso verificável.
A distinção mais importante: uptime do gateway não é taxa de sucesso
Essa é a parte que pega as equipes desprevenidas, e vale a pena ser direto sobre isso.
Um SLA de uptime cobre a infraestrutura do provedor: o gateway aceita sua conexão, autentica você e roteia sua requisição. Isso é o que eles controlam e é o que estão prometendo.
O que ele não cobre é se o site de destino aceita a requisição. Se um site bloqueia o endereço de saída, apresenta uma página de desafio, ou retorna um resultado vazio, isso não é indisponibilidade. O proxy fez o trabalho dele. Sua coleta ainda assim falhou. Nenhum provedor de proxy pode prometer uma taxa de sucesso contra sites de terceiros, porque os sites decidem, eles mudam suas defesas sem aviso prévio, e o mesmo pool que passa por um alvo na segunda-feira pode ter dificuldades na sexta-feira. Qualquer provedor que garanta uma taxa de sucesso em alvos arbitrários está prometendo algo fora do seu controle.
Então a consequência prática para o departamento de compras é que o SLA te protege contra o provedor estar quebrado, e o seu próprio monitoramento te protege contra tudo o mais. Você precisa dos dois, e confundi-los leva a equipes que estão contratualmente cobertas e operacionalmente cegas. É para isso que serve monitorar seu pipeline, medindo a taxa de sucesso validada por alvo e por região em vez de assumir que o SLA cobre isso, e é por isso que detectar conteúdo bloqueado ou falso importa: uma página de desafio retornada com um 200 é uma resposta compatível com o SLA e uma falha de dados ao mesmo tempo.
Créditos de serviço, e o que eles realmente valem
Quando um SLA não é cumprido, o remédio padrão é um crédito de serviço, geralmente uma porcentagem da mensalidade escalonada de acordo com o quanto a meta foi descumprida, aplicada a uma fatura futura.
Seja realista sobre o tamanho disso. Um crédito é calculado com base no que você pagou ao provedor, não com base no que a interrupção custou a você. Se uma interrupção de gateway de quatro horas paralisa um feed de preços que orienta suas próprias decisões comerciais, o crédito será uma pequena fração de uma fatura mensal de proxy e o impacto no negócio é seu. Créditos são um mecanismo de responsabilização e um sinal de que o provedor leva o compromisso a sério; eles não são um seguro.
Dois detalhes mecânicos valem a pena verificar. Créditos geralmente não são automáticos: muitos contratos exigem que você reivindique dentro de uma janela, frequentemente 30 dias, com suas próprias evidências. E créditos costumam ter um teto de algum percentual da mensalidade. Ambos são normais, mas você deve conhecê-los antes de precisar deles.
As exclusões que devem ser lidas com atenção
A seção de exclusões é onde um SLA é realmente definido. Exclusões padrão e razoáveis incluem manutenção programada anunciada com antecedência, força maior, e falhas em redes que o provedor não opera. Fique atento a estas:
Manutenção programada sem teto ou sem período de aviso, o que efetivamente permite que o provedor exclua qualquer indisponibilidade que declare com antecedência. Exclusões por “configuração incorreta do cliente” amplas o suficiente para cobrir o uso comum. Exclusões de terceiros redigidas de forma tão ampla que problemas de rede a montante, que são a maior parte do que realmente quebra, ficam fora da promessa. E exclusões para degradação como algo distinto de indisponibilidade, que é como um serviço lento mas ativo evita ser contabilizado.
Verifique também se o SLA cobre os componentes dos quais você realmente depende. Um negócio de proxy tem vários: o gateway, o painel e a autenticação, o faturamento, e quaisquer APIs. Um SLA que cobre o gateway mas exclui a autenticação não é muita proteção, já que você não pode usar um gateway acessível contra o qual não consegue se autenticar.
Como verificar uma afirmação antes de assinar
Um SLA é uma promessa sobre o futuro; as coisas verificáveis são o presente e o passado.
Comece pela página de status. Status em tempo real e, mais importante, um histórico público de incidentes te dizem com que frequência as coisas quebram, com que rapidez são reconhecidas, e se as análises pós-incidente são honestas. Um provedor sem página de status pública está pedindo que você aceite o uptime por fé. A Shifter publica uma em status.shifter.io com o gateway, IPs de ISP, as APIs, painel e autenticação, e faturamento rastreados como subsserviços separados, o que é a granularidade que você quer, já que permite ver qual componente falhou.
Depois meça você mesmo durante a avaliação. Execute uma verificação de disponibilidade de baixa frequência contra o gateway a partir da sua própria infraestrutura durante um período de teste, e você terá um registro independente em vez de um número de marketing. Combine isso com um teste adequado de taxa de sucesso nos seus alvos reais, como em testar velocidade, taxa de sucesso e precisão de localização, e você saberá os dois números: se o serviço está no ar, e se ele funciona para você.
Por fim, observe os tempos de resposta do suporte, porque na prática eles importam mais do que o crédito. Quando algo quebra às 02:00, o que determina sua recuperação é a rapidez com que um humano responde, não o percentual que aparece na fatura do mês seguinte.
O que a Shifter publica
Para referência, os níveis publicados são: melhor esforço do Starter ao Growth, tipicamente 99,5% ou melhor; 99,9% de uptime mensal do Business ao Pro sem um mecanismo formal de crédito; e 99,9% no Enterprise com créditos de serviço conforme o contrato assinado, calculados com base no gasto mensal e pagos como crédito na conta na fatura seguinte. Os tempos de resposta do suporte são escalonados junto, desde chat de melhor esforço nos planos iniciais até um canal dedicado e um gerente de contas nomeado no Enterprise. Os detalhes estão na documentação de suporte e SLA.
A razão para afirmar isso claramente é que a escalonagem por níveis é normal nesse setor e vale a pena entender: um SLA formal, respaldado por créditos, é geralmente um recurso de contrato enterprise, e se o seu processo de compras exige um, essa é a conversa a ter logo de início em vez de assumir que um plano self-serve o inclui.
As perguntas a fazer no processo de compras
Pergunte pela janela de medição e se ela é mensal ou anual. Pergunte pela definição de indisponibilidade, especificamente se taxas de erro elevadas ou latência degradada contam. Pergunte quais componentes o SLA cobre, gateway, autenticação, painel, APIs, e se são medidos separadamente. Pergunte se os créditos são automáticos ou baseados em reivindicação, qual é a janela de reivindicação, e qual é o teto. Peça o histórico de incidentes dos últimos doze meses. Pergunte qual é o compromisso de tempo de resposta do suporte para um incidente de produção fora do ar, e por qual canal. E pergunte o que é explicitamente excluído.
Um provedor confortável em responder tudo isso por escrito está te dizendo algo útil, independentemente do número em si.
Conclusão
Trate a porcentagem como a parte menos informativa de um SLA. A janela, a definição de indisponibilidade, os componentes cobertos e as exclusões são o que determina se a promessa significa alguma coisa, e créditos de serviço são responsabilização, não compensação pelas suas perdas. Mais importante, lembre-se do limite: um SLA de uptime cobre a disponibilidade do gateway, nunca se os alvos de terceiros aceitam seu tráfego, então você ainda precisa do seu próprio monitoramento de taxa de sucesso para saber se sua coleta está realmente funcionando. Verifique com um histórico público de incidentes e suas próprias medições durante um teste, e pese a capacidade de resposta do suporte pelo menos tanto quanto o número em si.
Se você está avaliando com base nisso, as escolhas em nível de plano estão cobertas em como escolher o plano de proxy residencial certo, e os critérios em nível de provedor em como escolher uma rede de proxy. O serviço em si é proxies residenciais, com níveis e preços por GB que escalam do self-serve até termos contratados de Enterprise.