O que é downtime, por que ele acontece e como reduzir a indisponibilidade

Todo time de TI já viveu a mesma cena. O telefone toca, o usuário avisa que o sistema não abre e o painel na parede continua verde. Nesse intervalo entre o que o monitoramento mostra e o que a pessoa do outro lado sente mora boa parte do prejuízo de uma parada.

O termo carrega uma armadilha. Ele sugere um estado binário, no ar ou fora do ar, quando a operação raramente funciona assim. Serviço lento, transação que falha uma vez a cada dez tentativas, fila que trava só no fechamento do mês: nada disso derruba o servidor, mas tudo isso derruba o negócio.

Neste artigo, você vê o que é downtime e como calculá-lo. Também vê quais causas aparecem com mais frequência na operação corporativa e quais controles realmente encurtam a parada. No caminho, uma tabela traduz cada nível de disponibilidade em minutos de serviço fora do ar.

O que é downtime?

Downtime é o período em que um sistema, serviço ou componente de TI fica indisponível para quem depende dele. A contagem começa no instante em que o serviço deixa de responder dentro do critério acordado e termina quando ele volta a operar dentro desse mesmo critério. O intervalo pode ser planejado, como uma janela de manutenção, ou não planejado, como uma falha.

Repare na expressão “critério acordado”. Ela separa uma definição útil de uma definição vaga. Sem critério escrito, cada área mede a parada de um jeito. A infraestrutura conta o tempo do servidor, o negócio conta o tempo do pedido que não entrou.

Por isso, a primeira decisão de qualquer programa de disponibilidade não é técnica. Antes de escolher ferramenta, a empresa precisa responder o que significa “disponível” para cada serviço crítico. Depois, precisa definir quem tem autoridade para declarar o início do incidente.

Downtime planejado e downtime não planejado

O downtime planejado acontece com data marcada, comunicação prévia e plano de retorno: atualização de versão, troca de disco, migração de link. Ele custa caro quando ninguém avisa o usuário, porém continua sendo trabalho previsto.

Já a parada não planejada chega sem aviso e concentra o prejuízo. Nela, o relógio corre enquanto a equipe descobre o que quebrou, discute de quem é a responsabilidade e negocia o que pode ser reiniciado.

Vale destacar uma diferença prática entre os dois casos. No planejado, você controla o horário e escolhe o menor impacto possível. No não planejado, o incidente escolhe por você, quase sempre no pior momento do calendário.

Downtime, degradação e falha parcial: por que “no ar” engana

A maioria dos conteúdos sobre o tema trata disponibilidade como uma chave de duas posições. A operação real tem três estados, não dois: funcionando, degradado e parado. O estado do meio é o que mais aparece nos chamados.

Um exemplo comum: o site responde, mas a página de checkout leva 14 segundos para carregar. O teste de HTTP 200 passa, o gráfico fica verde e a taxa de conversão desaba. Do ponto de vista de quem tenta comprar, aquilo é indisponibilidade.

Outro exemplo: a API responde rápido para nove em cada dez chamadas e devolve 500 na restante. Nenhum alerta de “serviço fora” dispara, porque o serviço está de pé. Ainda assim, uma fatia inteira dos clientes não consegue concluir a operação.

Existe um nome para esse comportamento no vocabulário de infraestrutura: brownout, em oposição ao blackout. Ele é traiçoeiro porque consome o orçamento de erro do serviço sem acionar nenhum dos gatilhos clássicos de indisponibilidade.

A consequência prática é direta. Se a sua medição olha apenas para o processo vivo ou para a resposta do ping, você mede a saúde do equipamento. A entrega do serviço fica de fora. Latência, taxa de erro e sucesso da transação de ponta a ponta precisam entrar no mesmo painel que o status do host.

Como calcular o downtime e a disponibilidade

O cálculo é simples e cabe em duas contas. O downtime acumulado é a soma dos minutos em que o serviço ficou fora do critério dentro do período medido. A disponibilidade é o complemento disso: (tempo total - downtime) / tempo total, expresso em percentual.

Um serviço que ficou 43 minutos indisponível em um mês de 30 dias entrega, portanto, três noves de disponibilidade. O número parece confortável no relatório. Traduzido para minutos, ele fica bem menos confortável, principalmente quando o contrato promete recuperação rápida.

Vale destacar que a tabela abaixo assume o mês médio de 30,44 dias, referência usada em contratos de arquiteturas de alta disponibilidade. Cada linha mostra quanto tempo de serviço fora do ar cabe em cada nível.

A tabela explica por que subir um nível custa tanto. Sair de dois para três noves ainda cabe em processo e disciplina operacional. Sair de quatro para cinco exige redundância ativa, automação de failover e ensaio periódico de recuperação.

Antes de prometer qualquer número desses no contrato, faça a conta ao contrário. Se a sua equipe leva 40 minutos apenas para descobrir que o serviço caiu, quatro noves não é uma meta. É uma promessa que a operação não consegue cumprir.

Quais são as causas mais comuns de downtime

Listar causas ajuda pouco quando cada uma vem solta. O que muda a operação é associar a causa ao sinal que ela produz e ao controle que a contém. A tabela abaixo faz esse mapeamento com as origens que mais aparecem em ambientes corporativos.

Repare que apenas duas dessas causas envolvem hardware quebrado. As demais nascem de processo, de capacidade mal dimensionada ou de dependência que ninguém estava observando. É por isso que comprar equipamento novo raramente resolve um histórico de paradas.

Vale dizer também que a maioria dos ambientes conhece essas causas de cor. O que costuma faltar é o inventário de qual serviço depende de quê. Essa informação sustenta qualquer decisão sobre onde investir primeiro na infraestrutura.

Qual é o impacto do downtime no negócio

O impacto direto aparece rápido: pedido que não entra, atendimento que não abre chamado, operação de loja parada. O indireto demora mais para chegar ao relatório, embora costume ser maior. Ele se chama confiança do cliente.

Uma pesquisa da Splunk com a Oxford Economics mediu esse custo nas empresas da Global 2000. O total agregado chegou a US$ 600 bilhões por ano, alta de 50% em dois anos.

A mesma pesquisa calcula um custo médio de US$ 15 mil por minuto parado. Para traduzir esse tipo de número na realidade da sua operação, vale acompanhar o detalhamento em quanto custa uma hora de parada.

Vale olhar também de onde a parada vem. Na análise anual de interrupções do Uptime Institute, problemas de TI e de rede responderam por 23% das interrupções com impacto registradas em 2024.

Números dessa escala pertencem a companhias gigantes. Ainda assim, a mecânica se repete proporcionalmente em qualquer porte: o prejuízo cresce com o tempo de parada, com a criticidade do serviço afetado e com o horário em que ele cai.

Como reduzir o downtime na prática

Reduzir parada não depende de uma compra única. Depende de quatro frentes que avançam juntas, cada uma atacando um pedaço diferente do tempo total em que o serviço fica fora.

Elimine o ponto único de falha antes de comprar ferramenta

Comece pelo mapa. Liste os serviços críticos, desenhe de quais elementos cada um depende e marque todo componente sem par. Esse desenho costuma revelar surpresas, como três sistemas diferentes apoiados no mesmo servidor de autenticação.

Em seguida, ataque por criticidade, não por facilidade. Redundância só vale quando alguém testa o chaveamento com data marcada. Deixar o incidente fazer esse teste sai muito mais caro, porque ele nunca escolhe um horário conveniente.

Monitore o serviço, não apenas o servidor

Um host verde diz muito pouco. O que interessa é se a transação do negócio completa dentro do tempo aceitável, medida do jeito que o usuário a executa. Isso significa somar três camadas: disponibilidade do recurso, desempenho da resposta e sucesso da jornada de ponta a ponta.

Na prática, a operação combina teste sintético periódico, coleta de latência real e alerta baseado em erro por transação. Serviços com essa cobertura descobrem a degradação antes do primeiro chamado, que é exatamente o objetivo de um monitoramento em tempo real bem calibrado.

Trate mudança como a causa mais provável

Quando o serviço cai, a primeira pergunta útil é: o que mudou nas últimas horas? Ambientes com registro de mudanças respondem em segundos. Ambientes sem registro gastam a primeira hora do incidente descobrindo isso por eliminação.

Além do registro, três hábitos reduzem muito o risco. São eles: janela definida para alterações sensíveis, rollback testado antes da execução e liberação gradual em vez de virada total. Nenhum deles exige ferramenta cara.

Reduza o tempo de detecção antes do tempo de reparo

O tempo total de parada tem duas metades. A primeira vai da falha até alguém perceber. A segunda vai da percepção até o serviço voltar. Times costumam investir toda a energia na segunda metade e esquecer a primeira.

Detecção lenta é o defeito mais barato de corrigir e o mais caro de ignorar. Meça as duas metades separadamente, com o apoio das definições de MTTR e MTBF. Depois, trate cada uma com iniciativas próprias.

Em uma das maiores redes de varejo do Brasil, o tempo fora do ar não vinha da falta de ferramenta. Vinha de ninguém enxergar o processo ponta a ponta: infraestrutura, aplicação e operação não conversavam entre si. Mapeamos os processos críticos com todas as dependências, de PDV e PIX até o orquestrador de transações. A troca do monitoramento por equipamento pelo monitoramento orientado a processo de negócio derrubou o MTTR e encerrou as salas de guerra.

Downtime no contrato: SLA, SLO e o que entra na conta

Duas siglas dominam essa conversa e elas não são sinônimos. O SLA é o acordo de nível de serviço, com o número prometido ao cliente e a penalidade associada ao descumprimento. Ele é um documento comercial, com peso jurídico.

Já o SLO funciona como meta interna, normalmente mais rígida do que a promessa contratual. A folga entre os dois números existe de propósito: ela dá margem para a engenharia agir antes que o cliente sinta o problema.

Essa mecânica aparece descrita em detalhe no capítulo sobre objetivos de nível de serviço do livro de SRE do Google. A ideia central é simples: a meta interna precisa estourar antes da promessa externa.

Resta a pergunta que mais gera discussão na renovação de contrato: a janela de manutenção entra na conta? Depende exclusivamente do que o contrato define. Na prática de mercado, a manutenção comunicada com antecedência acordada fica fora do cálculo de disponibilidade.

Cuidado com o efeito colateral dessa exclusão. Um fornecedor pode exibir números excelentes e ainda assim manter o serviço fora do ar com frequência, bastando classificar tudo como manutenção programada. Por isso, o contrato precisa limitar quantidade, duração e horário dessas janelas.

Conclusão

Downtime não é apenas o servidor apagado. É todo intervalo em que o serviço deixa de entregar o que prometeu. Isso inclui os períodos de lentidão e de falha parcial que o teste binário não enxerga. Definir esse critério por escrito, serviço a serviço, muda a conversa inteira.

A partir daí, o trabalho fica concreto. Você calcula a disponibilidade real e traduz o percentual em minutos. Em seguida, mapeia os pontos únicos de falha e mede separadamente o tempo de detecção e o tempo de reparo. Cada uma dessas frentes devolve resultado sem depender de um grande projeto.

Vale lembrar que quase nenhuma parada é surpresa completa. Quase sempre existiu um sinal antes: a fila que cresceu, o disco que encheu devagar, a latência que subiu por três semanas. Enxergar esse sinal é o que separa a operação que reage da operação que antecipa.

Quer ajuda para medir a disponibilidade real dos seus serviços críticos e reduzir a parada de forma mensurável? Fale com um especialista da OpServices e avalie o cenário do seu ambiente.