SLA de disponibilidade: definir e reportar

Um cliente maior pede um SLA no contrato de manutenção. A reacção habitual é uma de duas: ou se escreve “99,9%” sem pensar no que isso obriga, ou se recusa a conversa por parecer coisa de empresa grande.

As duas são más. A primeira porque um SLA de disponibilidade que não consegues medir é uma promessa que só existe a teu desfavor. A segunda porque a conversa, bem conduzida, é uma das poucas em que a manutenção se justifica sozinha.

O que um SLA é, e o que não é.

Um SLA — service level agreement — é uma promessa quantificada sobre um nível de serviço, com uma forma de medir e uma consequência quando não é cumprida. As três partes são obrigatórias. Uma promessa sem medição é publicidade; uma medição sem consequência é um relatório.

Não é uma garantia de que nada vai correr mal. É a declaração do que acontece quando correr — e é por isso que assinar um SLA que não consegues cumprir é pior do que não assinar nenhum.

Os números, traduzidos para minutos.

A percentagem é abstracta e leva as pessoas a comprometerem-se com coisas que não percebem. Traduzida em tempo por mês, a conversa muda:

Disponibilidade	Falha tolerada por mês	Por ano
99%	7 h 18 m	3 d 15 h
99,5%	3 h 39 m	1 d 19 h
99,9%	43 m	8 h 45 m
99,95%	21 m	4 h 22 m
99,99%	4 m 22 s	52 m

Repara no que 99,9% quer dizer: quarenta e três minutos no mês inteiro. Um único reinício mal corrido do alojamento consome metade disso. Uma migração consome tudo.

Para um site alojado num plano partilhado, prometer 99,9% é assumir um risco cujo controlo está inteiramente noutra empresa. Para a maior parte das agências, o número honesto está entre 99% e 99,5% — e vale muito mais explicar porquê do que inflacionar para impressionar.

Há ainda uma armadilha aritmética que quase ninguém antecipa: 99,99% é impossível de medir com uma ferramenta de intervalo fixo. Quatro minutos e vinte segundos por mês é menos do que cinco verificações num intervalo de um minuto. Prometer um nível que a tua medição não consegue distinguir de zero é prometer no escuro.

O que excluir, e porquê isso não é batota.

Todos os SLA da indústria têm exclusões. Escrevê-las não é fugir à responsabilidade — é definir o que estás mesmo a prometer.

Janelas de manutenção agendadas, avisadas com antecedência combinada (48 horas é o costume). Sem esta exclusão, não consegues actualizar nada.
Falhas de terceiros fora do teu controlo: a rede do alojamento, o registo de domínio, um serviço externo de pagamentos. Podes prometer resposta, não podes prometer disponibilidade de infraestrutura que não é tua.
Alterações feitas pelo cliente. Um plugin instalado às onze da noite por alguém do lado de lá não pode contar contra ti.
Casos de força maior, na formulação habitual.

O que não deves excluir é a categoria “problemas que não conseguimos reproduzir”. É a cláusula que esvazia o contrato todo e qualquer cliente atento vai reparar nela.

A parte que ninguém combina, e é a que gera conflito: como se mede.

Duas agências podem reportar números diferentes para o mesmo mês e ambas terem razão. Estas quatro decisões explicam quase toda a diferença, e por isso ficam escritas no contrato:

De onde se verifica. Um site pode estar acessível de Lisboa e não de Frankfurt. Se o teu cliente e os visitantes dele estão em Portugal, a medição feita a partir de Portugal é a que descreve a realidade deles.
Com que intervalo. Cinco minutos e um minuto dão números diferentes para o mesmo mês: falhas curtas desaparecem da primeira medição.
O que conta como estar em baixo. Só a ausência de resposta? Um 500 também? E um 403? E uma resposta que demora quinze segundos — o site está de pé, mas para o visitante está em baixo.
Quantas falhas seguidas antes de contar. Se uma verificação falhada isolada conta como downtime, um soluço de rede tira-te 0,03% do mês. Confirmar com um segundo pedido é a prática normal, e tem de estar escrita.

Reportar sem uma plataforma cara.

Não precisas de uma ferramenta de mil euros por ano. Precisas de três coisas.

Um registo que não se apague. É aqui que a maior parte das ferramentas gratuitas te deixa mal: guardam sete ou trinta dias, e um SLA anual precisa de doze meses. Se a ferramenta que usas apaga, exporta todos os meses para uma folha de cálculo. É chato e é o suficiente.

Uma conta simples. Percentagem de disponibilidade é o tempo em que respondeu a dividir pelo tempo total do período. Não uses percentis nem médias de latência num relatório de SLA — não é isso que está no contrato.

Uma página por mês, escrita para quem paga. Uma frase com o número, a lista dos incidentes com data e duração, e o estado face ao compromisso. Nada mais:

O site esteve acessível 99,94% do tempo em Março. Houve uma interrupção, no dia 14, com a duração de 26 minutos. O compromisso do contrato é de 99,5%.

Essa página, anexada à factura da avença, faz mais pela renovação do contrato do que qualquer conversa sobre valor.

E a consequência quando falha.

Um SLA sem consequência não é um SLA. A prática comum em manutenção de sites é o crédito na avença seguinte, escalonado: 10% se ficar abaixo do compromisso, 25% se ficar abaixo por uma margem grande.

Duas notas práticas. Primeira: põe um tecto, normalmente o valor da avença do mês. Sem tecto, uma falha longa do alojamento pode custar-te mais do que o contrato inteiro vale. Segunda: o crédito não é automático — é pedido pelo cliente dentro de um prazo. Sem isso ficas com uma obrigação de auditoria mensal que não vais cumprir.

Onde isto normalmente falha.

Falha na medição, e falha sempre pela mesma razão: assina-se o SLA em Janeiro e descobre-se em Novembro que a ferramenta gratuita que se estava a usar só guarda trinta dias. O compromisso existe, o cliente pergunta pelo ano, e não há dados.

A De Olho está a ser construída com essa parte tratada — histórico que não expira nos planos pagos, verificação a partir de Portugal, e confirmação antes de contar uma falha. Abre em 2026 e ainda não tem preços. Quem entrar na lista de espera sabe primeiro.

Uma última coisa, que é justa dizer: um SLA não melhora a disponibilidade em nada. Não muda o alojamento, não previne falhas, não acelera resoluções. O que faz é obrigar-te a medir — e medir é que costuma mudar as decisões a seguir.

A forma de reportar isso todos os meses, com o texto pronto a copiar, está no template de relatório de disponibilidade.