Existem duas direções para a mesma fórmula. Partindo de uma percentagem de SLA obtém-se a indisponibilidade que ela permite (é o que faz a nossa calculadora de disponibilidade). Partindo da indisponibilidade registada, como esta página faz, obtém-se a percentagem de disponibilidade que ela produziu: (janela − indisponibilidade) ÷ janela × 100. Acrescentamos os dois números que uma folha de cálculo não dá: quanto custou e para onde foram os minutos.

Divida a indisponibilidade pela janela e multiplique por 100. Uma interrupção de 43m 48s num mês de 30,42 dias: 2 628 s ÷ 2 628 000 s × 100 = 0,1% de indisponibilidade — ou seja, 99,9% de disponibilidade. Duas regras: some todos os incidentes da janela — sem fazer a média — e meça desde o primeiro pedido falhado até à recuperação verificada.

Entre duas e três noves é a faixa normal para serviços de produção pequenos a médios — entre 43 minutos e 7 horas por mês. Três noves (43m 48s/mês) é a meta de referência: alcançável com um bom alojamento, rollbacks rápidos e alguém de prevenção. Se o seu mês ultrapassar as 7 horas, a tabela de danos acima mostra a nota que está a entregar — e a secção da cronologia no resultado mostra onde recuperar minutos primeiro.

Ignore os valores por minuto divulgados em estudos empresariais — juntam bancos e padarias na mesma média. O seu teto é a sua própria aritmética: receita por hora × horas de indisponibilidade, mais as pessoas que largaram tudo, mais qualquer penalização contratual. A secção de custo do resultado calcula isto ao vivo com os seus números. Duas ressalvas. Alguns compradores interrompidos voltam mais tarde, por isso a receita perdida é um teto. E alguns custos nunca cabem numa folha de cálculo: confiança, SEO, a acumulação de pedidos de apoio.

Contam da forma que decidiu que contariam — antes do incidente. Prática comum: um caminho crítico avariado (checkout, início de sessão) conta na íntegra mesmo que a página inicial carregue; um estado degradado mas funcional conta à parte, ou não conta de todo. Escreva a definição e aplique-a sempre da mesma forma. As discussões sobre SLA giram em torno deste parágrafo, não da aritmética.

MTTR é o tempo médio de recuperação: indisponibilidade total ÷ número de incidentes. É a sua melhor alavanca, porque reduzi-lo para metade reduz a indisponibilidade para metade sem evitar um único incidente. MTBF é o tempo médio entre falhas, ou seja, com que frequência as coisas avariam. Depende da arquitetura e da disciplina nas alterações, não da velocidade de resposta. Juntos dão a disponibilidade: MTBF ÷ (MTBF + MTTR). O RTO é o MTTR que prometeu — quanto tempo uma interrupção pode durar antes de o plano de recuperação falhar. Teste-o antes que um incidente o faça.

Ataque o MTTR antes do MTBF — recuperar mais depressa é mais barato do que falhar menos. E dentro do MTTR, ataque primeiro a deteção: é a única fase que uma ferramenta consegue encurtar por completo. No nosso exemplo prático, a deteção demorou 11 minutos e a correção demorou 4. Verificações a cada trinta segundos limitam o silêncio antes da primeira verificação falhada a meio minuto — não conseguem encurtar o envio do alerta nem o tempo que alguém demora a atender o telefone, e é por isso que a deteção encolhe quatro minutos aqui, não onze. O diagnóstico encolhe com provas (resultados de várias localizações, marcas temporais exatas); a correção em si encolhe com rollbacks ensaiados — essa parte depende da preparação de cada equipa.

Não é possível calcular o que não foi detetado — o reinício das 3 da manhã no nosso registo de junho só existe porque algo estava a monitorizar. A monitorização independente fornece os dados de que esta calculadora precisa: horas exatas de início e fim, a partir de fora da própria infraestrutura. Isto cobre todos os incidentes, incluindo os que aconteceram enquanto ninguém estava acordado. A Uptimia verifica a partir de mais de 171 localizações em mais de 70 países — a cada 60 segundos no plano Basic, a cada 30 a partir do Professional — e mantém esse registo automaticamente.