Resumo

  • Um SLA de disponibilidade é melhor entendido como um mecanismo limitado de alocação de risco do que como uma promessa econômica de ressarcimento por indisponibilidade. O número no título só ganha significado depois que se identificam o que é medido, qual arquitetura habilita o compromisso, qual gasto forma a base do crédito, qual recurso precisa ter falhado, quais incidentes são excluídos, que prova deve ser preservada e qual teto ou regra de não acumulação se aplica.

  • Os exemplos de Cloudflare, AWS, Google Cloud, Oracle e IBM não formam um ranking de confiabilidade. Eles mostram desenhos diferentes para transformar falhas técnicas em eventos contratuais mensuráveis. Em todos os casos, há uma distância entre a disponibilidade de um componente da nuvem e a disponibilidade ponta a ponta de uma carga de trabalho. Parte dessa distância permanece sob controle — e portanto sob risco — do cliente.

  • A consequência prática é que a engenharia do SLA não termina na negociação jurídica. Monitoramento, topologia, retenção de logs, identificação de recursos, procedimentos internos de incidente e decisões de redundância determinam se um evento poderá ser medido, atribuído e convertido em crédito. A organização que não consegue reproduzir o incidente pode descobrir que possuía um direito nominal, mas não um direito operacionalmente exercível.

O crédito não mede o prejuízo

O exemplo da Cloudflare é útil porque torna a separação explícita. O compromisso publicado para o Enterprise Service fala em 100% de uptime; o próprio SLA define o crédito como uma porcentagem das mensalidades mensais do Service e restringe o cálculo às mensalidades recorrentes associadas a ele. O total anual de créditos não pode exceder seis meses de mensalidades cumulativas, e o crédito é apresentado como o remédio exclusivo para violações desse SLA. (Cloudflare)

Isso cria duas quantidades que podem se mover de maneira quase independente. A primeira é a perda econômica da empresa: pedidos não concluídos, operadores parados, custos de recuperação, multas perante terceiros, churn, dano reputacional ou qualquer outra consequência da indisponibilidade. A segunda é o crédito contratual. A primeira depende do negócio. A segunda depende da fórmula.

É por isso que uma hora pode produzir 3,47% da mensalidade pertinente sem que 3,47% tenha qualquer relação necessária com a perda ocorrida naquela hora. Se uma aplicação gerar em sessenta minutos uma margem muito maior do que seu gasto mensal naquele componente de nuvem, o crédito cobrirá apenas uma fração da exposição. Se a carga tiver pouco valor econômico naquele horário, o oposto também pode ocorrer. O SLA não está tentando calcular o prejuízo integral; está especificando antecipadamente um remédio limitado.

A distinção é central para a leitura econômica do contrato. O percentual de disponibilidade é o rótulo nominal. A infraestrutura que precisa funcionar para a aplicação entregar seu resultado é a dependência. O crédito, seu denominador e seu teto constituem o remédio. Misturar os três transforma uma especificação estreita em uma impressão de proteção muito mais ampla do que a redação sustenta.

O perímetro é parte da promessa

Na Cloudflare, o perímetro aparece já na variável usada para medir impacto. A Affected Customer Ratio é a proporção entre visitantes únicos afetados e visitantes únicos totais. A disponibilidade programada é o número de minutos do mês menos parada planejada pelo cliente e indisponibilidade atribuível a força maior. Um Unscheduled Service Outage também é definido pelo efeito sobre a aplicação do cliente, sujeito às exclusões do SLA. (Cloudflare)

A fórmula, portanto, não pergunta simplesmente: “a internet estava funcionando?”. Ela pergunta algo muito mais delimitado: houve um período qualificável de interrupção do Service, durante quanto tempo, qual fração mensurável dos visitantes foi atingida e qual era o denominador contratual de disponibilidade programada?

Essa granularidade importa. Dois incidentes visualmente semelhantes para o usuário final podem gerar resultados diferentes se atingirem proporções diferentes de tráfego, recursos distintos ou segmentos fora do perímetro coberto. E duas empresas com o mesmo fornecedor podem ter exposições diferentes sem que isso revele qualquer diferença na qualidade subjacente da infraestrutura: basta que arquitetura, tráfego, preço contratado ou dependências sejam diferentes.

A metodologia também aloca trabalho. A Cloudflare afirma que o monitoramento abrangente do conteúdo do cliente é responsabilidade do próprio cliente e diz que considerará sistemas independentes de medição comercialmente razoáveis. Para calcular a razão afetada, usa as informações razoavelmente disponíveis, inclusive dados de serviço anteriores ao período relatado. (Cloudflare) O controle da evidência, portanto, é compartilhado de maneira assimétrica: o fornecedor dispõe de telemetria de sua superfície; o cliente precisa conservar uma visão suficientemente independente da experiência que pretende provar.

Arquitetura também é uma cláusula

O AWS EC2 torna ainda mais visível a relação entre topologia e direito contratual. Seu SLA regional de 99,99% exige que todas as instâncias em execução estejam simultaneamente distribuídas por pelo menos duas Availability Zones na região. Para uma única instância, o compromisso publicado é 99,5%. As faixas de crédito são 10%, 30% e 100%, conforme o nível de disponibilidade mensal observado. (Amazon Web Services, Inc.)

Isto não é uma pequena nota arquitetural depois da porcentagem. É condição para saber qual porcentagem é aplicável.

A base financeira também muda com o perímetro. No SLA regional, o crédito é calculado sobre a conta mensal de EC2 da região afetada; no nível de instância, sobre a instância que não cumpriu o compromisso. Pagamentos únicos, como valores antecipados de Reserved Instances, são excluídos dessa base. Em regra, o crédito é aplicado a pagamentos futuros. (Amazon Web Services, Inc.)

Além disso, o cliente não pode acumular um pedido regional e um pedido de instância para a mesma instância. A AWS exige que a solicitação chegue até o fim do segundo ciclo de faturamento posterior ao incidente e pede datas, horários, região ou zona, IDs de recursos e logs que sustentem a indisponibilidade. (Amazon Web Services, Inc.)

O efeito econômico é simples: a organização não “compra 99,99%” apenas pagando por EC2. Ela precisa manter a configuração que torna esse compromisso aplicável. A redundância é simultaneamente uma decisão de resiliência e uma condição de enquadramento contratual.

A IBM explicita a mesma ideia por outra via, distinguindo SLO de SLA. Seu guia afirma que SLO é objetivo, não garantia contratual, enquanto um SLA pode gerar créditos. No exemplo de IBM Cloud VPC, aproveitar plenamente o SLO de 99,999% requer no mínimo três servidores, um em cada zona da região multizona, e um balanceador de carga. (IBM Cloud)

A IBM formula ainda a divisão de responsabilidade de maneira particularmente clara: em termos gerais, ela responde pela resiliência e recuperação da nuvem; o cliente, pela resiliência e recuperação da carga de trabalho. (IBM Cloud) Não há contradição entre uma infraestrutura altamente resiliente e uma aplicação pouco resiliente. Uma é insumo da outra, não seu substituto.

O relógio também tem fronteiras

O Compute Engine do Google acrescenta outra dimensão: o tamanho do intervalo que conta como falha. A disponibilidade mensal e o crédito são determinados por projeto e região ou, para uma instância única, por instância. Um período de indisponibilidade precisa ter pelo menos um minuto consecutivo; minutos parciais ou intermitência inferior a um minuto não entram como Downtime Period. (Google Cloud)

Para instâncias em múltiplas zonas e balanceamento nas regiões cobertas pelas condições gerais mostradas na página, as faixas de crédito são 10%, 25% e 100%, com compromissos que também variam segundo implantação, região e nível de rede. A página registra sua versão anterior como modificada em 4 de março de 2025. (Google Cloud)

Esse limite de um minuto mostra por que uma medição comum precisa ser fina, determinística e reproduzível. Para a aplicação, dez interrupções de quarenta segundos podem ser operacionalmente importantes. Para um mecanismo que define períodos apenas a partir de um minuto consecutivo, a classificação pode ser outra. Não é necessário julgar qual métrica é “melhor”. O ponto é que o comprador precisa saber qual fenômeno o contrato decidiu contar.

Também aqui o direito depende de procedimento. O cliente tem 60 dias a partir do momento em que se torna elegível para pedir o crédito e deve fornecer arquivos de log com os períodos, datas e horários de indisponibilidade. O crédito total do mês não excede o valor devido pelos serviços cobertos pertinentes nas regiões que não atingiram o SLO e é aplicado a uso futuro. Uma mesma máquina não recebe simultaneamente crédito como instância única e como parte de uma implantação multizona. (Google Cloud)

A base monetária decide o alcance

O documento PaaS/IaaS da Oracle torna o denominador financeiro especialmente visível. Um serviço pode ter SLA de disponibilidade, gerenciabilidade e, em determinados casos, desempenho. Mas o crédito é concedido para o serviço específico que não cumpriu o compromisso e é calculado como porcentagem das taxas líquidas pagas pela quantidade relevante do serviço não conforme efetivamente utilizada durante o período medido. (Oracle)

Esse detalhe é economicamente mais importante do que parece. Uma falha de um componente pequeno pode interromper um sistema grande. A consequência para o negócio pode se propagar por banco de dados, filas, APIs, identidade, faturamento e atendimento. O denominador contratual, porém, pode continuar sendo apenas o serviço específico não conforme.

O processo de pedido reforça essa delimitação. A Oracle requer, entre outros elementos, a região, os OCIDs relevantes — incluindo tenancy, compartimentos e recursos afetados —, descrição das tentativas de resolução e documentação ou logs pertinentes. O pedido deve chegar em até 60 dias do evento qualificável. (Oracle)

Quando mais de um SLA poderia produzir crédito sobre o mesmo incidente e o mesmo serviço, a regra geral do documento é receber apenas o maior crédito aplicável, sem acumular créditos de múltiplas cláusulas para o mesmo evento. (Oracle) O documento ainda caracteriza os créditos como remédio exclusivo e responsabilidade integral da Oracle por não cumprimento do compromisso coberto. (Oracle)

O modo de consumo também importa: uso e expiração dos créditos variam segundo a modalidade de compra. Assim, dois clientes que experimentem o mesmo incidente técnico não necessariamente enfrentam a mesma economia de recuperação contratual. O desenho comercial permanece dentro do mecanismo do SLA.

O pedido é parte do produto

Um crédito que exige iniciativa do cliente não é apenas uma fórmula financeira. É também um processo operacional.

A Cloudflare exige que o suporte seja avisado do incidente em cinco dias úteis. O pedido deve trazer detalhes como duração, traceroutes, URLs atingidas e tentativas de solução; evidência suficiente precisa ser enviada até o fim do mês de faturamento seguinte ao mês do incidente. A empresa então valida o pedido com as informações razoavelmente disponíveis. (Cloudflare)

A AWS exige um caso no Support Center e um conjunto estruturado de horários, recursos e logs. O Google exige solicitação e logs dentro de 60 dias. A Oracle também trabalha com janela de 60 dias e identificação precisa de região e recursos. (Amazon Web Services, Inc.)

A conclusão não é que esses procedimentos sejam excepcionalmente rigorosos. É que o procedimento faz parte da transferência de risco. Se a organização descobre depois do incidente que logs relevantes já expiraram, que os horários não foram normalizados, que ninguém preservou IDs de recursos ou que o time financeiro não sabe qual fatura corresponde ao serviço afetado, o problema não é somente de observabilidade. É também de exercibilidade contratual.

Por isso a fronteira mais útil não é “jurídico versus engenharia”. É “controle versus dependência”. Quem controla uma superfície de falha deve conseguir torná-la observável. Quem pretende transferir parte de seu risco precisa conseguir produzir a evidência especificada para acionar o remédio.

Entre a nuvem e a aplicação existe uma empresa

Uma carga de trabalho real raramente termina na borda do serviço coberto por um único SLA. Ela pode depender de DNS, conectividade, identidade, compute, armazenamento, banco de dados, serviços de terceiros, código próprio, implantação, configuração, credenciais e procedimentos humanos. Um contrato pode cobrir um elo e ainda deixar quase toda a cadeia econômica fora de seu denominador.

É nessa distância que os princípios de Heng Lu são mais úteis: separar rótulo nominal, dependência e remédio; manter a medição comum suficientemente fina, determinística e reproduzível; mostrar quem controla a superfície em que a falha pode ocorrer; e precificar o risco não transferido por meio de arquitetura, seguro, contratação e capacidade de saída.

O comprador, portanto, precisa construir duas representações do mesmo sistema. A primeira é técnica: quais componentes precisam funcionar para que uma transação seja concluída? A segunda é contratual: quais desses componentes possuem compromisso aplicável, sob qual topologia, com qual definição de indisponibilidade e com crédito sobre qual valor?

A diferença entre os dois mapas é a exposição residual.

Um SLA forte não elimina essa diferença. Ele a torna mensurável.

Não é um ranking de confiabilidade

Colocar Cloudflare, AWS, Google, Oracle e IBM lado a lado pode produzir a tentação de ordenar percentuais. Isso seria comparar objetos diferentes.

Na Cloudflare, a fórmula combina duração e proporção de visitantes afetados. No EC2, a implantação simultânea em múltiplas zonas determina se o compromisso regional de 99,99% se aplica. No Compute Engine, o cálculo é por projeto e região ou por instância e adota uma granularidade temporal mínima. Na Oracle, serviço específico, consumo efetivo e tipo de SLA moldam o crédito. A IBM usa seu guia de resiliência para separar explicitamente objetivo de serviço, compromisso contratual e responsabilidade da carga. (Cloudflare)

Essas diferenças dizem algo sobre desenho de medição e remédio. Não demonstram, por si, qual plataforma terá menos falhas futuras.

A pergunta profissional mais produtiva não é “quem tem mais noves?”. É: qual evento está sendo medido, quem controla as condições necessárias para ele ser qualificável e quanto dinheiro realmente muda de mãos quando o compromisso falha?

Quando essas três respostas estão claras, o SLA deixa de ser uma porcentagem de marketing e volta a ser aquilo que economicamente pode ser: uma cláusula precisa de distribuição de risco.

Fontes

Cloudflare — Enterprise Subscription Agreement / Enterprise SLA: https://www.cloudflare.com/__esa/

Cloudflare — Affected Customer Ratio: https://cf-assets.www.cloudflare.com/slt3lc6tev37/3JCTPcRmyFI8da4CGg6oh9/b51d2247a56b839661f2279a2eef59fc/affected_customer_ratio.png

Cloudflare — Service Credit Ratio: https://cf-assets.www.cloudflare.com/slt3lc6tev37/Eg51h7yYURjkFxzam0M0y/631a17a4a4db6cbce9de1c410a45c955/service_credit_ratio.png

AWS — Amazon Compute Service Level Agreement: https://aws.amazon.com/compute/sla/

Google Cloud — Compute Engine Service Level Agreement: https://cloud.google.com/compute/sla

Oracle — PaaS and IaaS Public Cloud Services Pillar Document: https://www.oracle.com/africa/contracts/docs/paas_iaas_pub_cld_srvs_pillar_4021422.pdf

IBM Cloud — Resiliency in IBM Cloud: https://cloud.ibm.com/docs/resiliency?topic=resiliency-resiliency-overview