Calculadora de Disponibilidade SLA

Visão geral

Metas de disponibilidade são citadas como porcentagens, e porcentagens são ruins para transmitir escala. 99% e 99,9% parecem vizinhos e diferem em mais de três dias por ano. Esta calculadora transforma a porcentagem em tempo, que é a forma em que o número realmente serve para alguma coisa.

Informe uma disponibilidade e você recebe a indisponibilidade permitida para um ano, um mês, uma semana e um dia.

Como usar

1. Informe uma porcentagem de disponibilidade, ou clique em um preset.
2. Leia a indisponibilidade permitida nas quatro janelas.

Os presets cobrem os patamares que aparecem em acordos reais: 90, 95, 99, 99.9, 99.95, 99.99 e 99.999.

A tabela de referência

Duas coisas merecem atenção. A coluna diária é aquilo dentro de que um único deploy ruim tem de caber. E abaixo de mais ou menos 99,99%, a indisponibilidade permitida para um dia é mais curta que o tempo que um humano tipicamente leva para notar um alerta, abrir um painel e decidir o que fazer — que é a fronteira prática em que confiabilidade deixa de ser um problema operacional e passa a ser um problema arquitetural.

Escolhendo uma meta

Trabalhe de trás para frente, a partir das consequências, e não para a frente, a partir da ambição.

Pergunte o que acontece durante a queda. Se um job em lote atrasa e depois se recupera, a meta pode ser baixa. Se um cliente não consegue concluir uma compra, a meta segue a receita. Se um serviço de emergência depende dela, a meta não é realmente a pergunta que você está fazendo.

Depois, confronte a meta com as suas dependências. Disponibilidade se compõe de forma multiplicativa para qualquer coisa em série: um serviço que precisa de três componentes, cada um a 99,9%, tem um teto de cerca de 99,7% antes de ele mesmo ter feito qualquer coisa errada. Você não pode prometer mais do que o seu caminho crítico permite, e acrescentar uma retentativa não muda a aritmética, a menos que as falhas sejam independentes.

Por fim, confronte a meta com o seu processo de recuperação. Uma meta de 99,99% com failover manual e um plantão que é acionado por e-mail não é uma meta, é um desejo. O número implica o mecanismo.

SLO e SLA são números diferentes

Mantenha o SLO interno mais apertado que o SLA contratual. A distância entre eles é a sua margem de operação: a região em que você já perdeu a sua própria meta e começou a reagir, mas ainda não incorreu em penalidade.

Um SLO interno de 99,9% atrás de um SLA contratual de 99,5% dá cerca de 2,9 horas de folga por mês entre o primeiro sinal (43 minutos) e o primeiro crédito em fatura (3,6 horas). Se os dois números são iguais, o instante em que você percebe é também o instante em que você passa a dever dinheiro, o que elimina qualquer chance de tratar o problema discretamente.

Leia também as exclusões. A maioria dos SLAs não conta manutenção anunciada, falhas causadas pela configuração do próprio cliente, nem eventos de força maior. Essas exceções significam que um serviço pode cumprir o SLA em um mês em que os usuários viveram indisponibilidade real — o que é um resultado jurídico, não um resultado de engenharia.

Decidindo o que conta como fora do ar

A porcentagem é aritmética; a parte difícil é a definição sobre a qual ela se aplica. Dois times podem reportar disponibilidades diferentes para o mesmo mês sem que nenhum dos dois esteja mentindo.

Medido de onde? Uma verificação feita de dentro da sua própria rede pula o CDN, o DNS e o caminho pela internet — que é exatamente onde acontece uma boa parte das falhas visíveis ao usuário. Medir de fora dá um número mais próximo do que os usuários viveram, e pior que aquele que o seu painel mostra.

Medido com que frequência? Uma sonda a cada cinco minutos não consegue detectar uma queda mais curta que cinco minutos, e ela atribui a uma queda de 30 segundos zero ou cinco minutos de indisponibilidade, dependendo do momento. Sondar de forma grosseira não te deixa mais confiável; deixa a sua medição menos capaz de ver.

Qual endpoint? Um health check que retorna 200 sempre que o processo está de pé vai reportar disponibilidade total durante uma queda em que toda requisição real falhou. A verificação tem de exercitar as dependências que importam.

Falha parcial. Se um endpoint de cada vinte está quebrado, o serviço está no ar? Uma definição baseada em tempo normalmente diz que sim. Os usuários daquele endpoint dizem que não. Essa é a principal razão para definir disponibilidade como uma razão de requisições bem-sucedidas, em vez de intervalos de uptime — veja a calculadora de error budget para esse enquadramento.

Escreva a definição antes de se comprometer com o número, porque a definição é onde a discordância vai aparecer depois.

Exemplos

• Justificar redundância. 99,9% permitem 43 minutos por mês; uma implantação em região única com failover manual gasta rotineiramente mais que isso em um só incidente.
• Dimensionar uma janela de manutenção. Uma janela de quatro horas está acima do orçamento para qualquer coisa a 99,9% ou melhor, se ela contar como indisponibilidade. Ou ela não conta, contratualmente, ou você precisa de uma migração sem downtime.
• Checar a sanidade da promessa de um fornecedor. Uma alegação de 99,99% sem nenhum failover automatizado descrito em lugar algum da documentação é um número de marketing.
• Definir um limiar de alerta. A 99,95%, um minuto de indisponibilidade por semana é um quinto do budget semanal. É nessa escala que o seu alertamento tem de resolver.

Observações

Aqui, um ano tem 365 dias e um mês tem 30 dias. Anos bissextos e meses de calendário deslocam ligeiramente os valores; se um contrato depende dessa diferença, use a definição escrita no contrato.

Esta ferramenta responde «quanta indisponibilidade esta porcentagem permite». Se você também quiser saber quantas requisições com falha individuais cabem no budget, e quanto dele você já gastou, use a calculadora de error budget — é a mesma aritmética aplicada a volume de requisições em vez de a tempo.