Português 
English
Manter a disponibilidade de um sistema exige combinar arquitetura sem ponto único de falha, metas de serviço (SLO) monitoradas, mudanças reversíveis e uma equipe preparada para corrigir a causa raiz dos incidentes. Nenhuma dessas frentes funciona sozinha, e todas dependem de rotina, não de um projeto pontual.
Em resumo
- Disponibilidade é o percentual do tempo em que a aplicação está acessível e funcionando como esperado; 99,9% ainda permite cerca de 43,8 minutos de parada por mês.
- O custo de um sistema parado vai além da receita perdida: inclui suporte, reputação e, em alguns setores, multas.
- As práticas mais eficazes são simples de descrever e difíceis de manter: eliminar pontos únicos de falha, medir o que o usuário sente, mudar em pequenos passos e tratar incidentes como processo.
- Quando a equipe interna não consegue sustentar essa rotina, um modelo de sustentação contínua (AMS) passa a ser uma alternativa concreta.
O que é disponibilidade de sistema?
Disponibilidade de sistema é o percentual do tempo, em um período (em geral um mês ou um ano), em que uma aplicação está acessível e funcionando como esperado. Ela não se confunde com confiabilidade, que mede a capacidade de o sistema executar sua função sem falhas durante um intervalo definido (Fonte: Atlassian).
O mercado costuma expressar a disponibilidade em “noves”. A tabela mostra quanto tempo fora do ar cada patamar permite (base de 365 dias):
| Disponibilidade | Parada permitida por ano | Parada permitida por mês |
|---|---|---|
| 99% | 3,65 dias | cerca de 7,3 horas |
| 99,9% (“três noves”) | 8,76 horas | cerca de 43,8 minutos |
| 99,99% (“quatro noves”) | cerca de 52,6 minutos | cerca de 4,3 minutos |
| 99,999% (“cinco noves”) | cerca de 5,3 minutos | cerca de 26 segundos |
Cada “nove” adicional reduz o tempo de parada permitido em cerca de dez vezes, e o custo de engenharia cresce na mesma direção. Há ainda um detalhe que costuma passar despercebido: as dependências somam riscos. Três serviços de 99,9% em sequência entregam, juntos, 99,7%, o que representa mais de um dia parado por ano. A AWS mostra a mesma lógica: um sistema projetado para 99,99%, com duas dependências rígidas também de 99,99%, tem disponibilidade teórica de 99,97%.
Quanto custa um sistema fora do ar
Segundo a pesquisa The Hidden Costs of Downtime, da Splunk em parceria com a Oxford Economics, a indisponibilidade não planejada custa US$ 600 bilhões por ano às empresas da lista Global 2000, alta de 50% em dois anos. O custo médio chegou a cerca de US$ 15 mil por minuto, e a perda média de receita é de US$ 95 milhões por empresa ao ano (TI Inside; eeNews Europe). Para as empresas da América Latina, a média informada é de US$ 197 milhões por ano. São números de grandes corporações; no médio porte a escala é menor, mas a lógica é a mesma.
Na indústria, a pesquisa Value of Reliability, da ABB, aponta uma mediana de cerca de US$ 125 mil por hora de parada, e a Siemens estima até US$ 2,3 milhões por hora na fabricação automotiva (Acronis).
Para estimar o impacto no seu negócio, use uma conta simples: receita por hora × horas de parada, somada aos custos de reparo emergencial, mão de obra ociosa e penalidades contratuais. Os custos ocultos entram depois: aumento de chamados no suporte, perda de confiança do cliente e desgaste da marca.
Esse custo cresce a cada hora, e a falha raramente fica restrita à TI: ela chega à operação, ao financeiro e ao cliente final. Por isso, sistemas críticos pedem gestão contínua de aplicações, não apenas um chamado aberto quando algo quebra.
10 práticas para manter um sistema disponível, segundo quem desenvolve
1. Elimine pontos únicos de falha
Um ponto único de falha é qualquer componente cuja queda derruba o sistema inteiro (Red Hat). Para eliminá-lo, mapeie a arquitetura, identifique o que não tem reserva (servidor, banco de dados, link de rede, serviço de terceiros) e adicione redundância, balanceamento de carga e distribuição em mais de uma zona de disponibilidade. A AWS recomenda ainda reduzir dependências e escolher as que tenham meta de disponibilidade igual ou maior que a do seu sistema.
Na prática: “Quase sempre o ponto único de falha está onde ninguém olha: uma integração externa, um certificado, um job agendado. Quando mapeamos a arquitetura, a pergunta é sempre a mesma: se isso parar, o que para junto com ele?”
Matheus, desenvolvedor full-stack da NextAge
Erro comum: investir em servidores redundantes e deixar o banco de dados ou uma integração externa como ponto único.
2. Defina SLI, SLO e orçamento de erro
O SLI é o indicador medido (por exemplo, a proporção de requisições bem-sucedidas), o SLO é a meta para esse indicador e o orçamento de erro é o que sobra: 1 menos o SLO. Com um SLO de 99,9% em 30 dias, o orçamento é de cerca de 43 minutos de falha. A prática vem do Google SRE: 100% de disponibilidade é irrealista e fica exponencialmente mais caro a cada melhoria marginal, e, quando o orçamento se esgota, as mudanças não urgentes são congeladas até que a confiabilidade seja recomposta (Google Cloud; isDown).
Na prática: “Meta de disponibilidade precisa ser uma conversa com o negócio, não uma decisão só da TI. Quando todo mundo entende quantos minutos de parada o processo tolera, fica mais fácil priorizar o que entra na entrega e o que pode esperar.”
Pedro, desenvolvedor back-end da NextAge
Erro comum: adotar uma meta de “cinco noves” sem custear a arquitetura que ela exige.
3. Monitore o que o usuário sente
Monitorar apenas CPU e memória não mostra se o cliente consegue concluir uma compra ou emitir uma nota. Meça tempo de resposta, taxa de erro e disponibilidade das jornadas críticas, e configure alertas a partir do SLO, não de limites isolados de infraestrutura. A AWS recomenda verificações de integridade granulares, que permitem failover rápido quando um componente degrada (AWS).
Na prática: “Alerta bom é o que faz alguém agir. Se a equipe recebe dezenas de avisos por dia, aprende a ignorar todos. Prefiro poucos alertas, ligados ao que o usuário sente, como erro na jornada de compra ou lentidão no login.”
Felipe, tech lead da NextAge
Erro comum: criar tantos alertas que a equipe passa a ignorá-los.
4. Faça mudanças pequenas e reversíveis
Mudanças são uma das principais origens de incidentes. Entregas frequentes e de baixo risco, com integração e entrega contínuas (CI/CD), flags de funcionalidade, implantação gradual e plano de reversão (rollback), reduzem o impacto de cada erro. As métricas DORA acompanham exatamente isso: a taxa de falha nas mudanças e o tempo de recuperação, hoje chamado de “tempo de recuperação de implantação com falha” (Pulse). No relatório DORA 2025, 21,3% das equipes de topo restauram o serviço em menos de uma hora e 56,5% em menos de um dia, segundo a Axify.
Na prática: “Mudança grande é incidente esperando para acontecer. Entregas pequenas, com plano de reversão pronto, permitem voltar atrás em minutos e investigar com calma. Nenhuma alteração deveria ir para produção sem responder: como desfazemos isso se der errado?”
Felipe, tech lead da NextAge
Erro comum: acumular muitas alterações em uma única entrega de fim de trimestre.
5. Teste antes e depois de chegar à produção
Testes automatizados, ambiente de homologação fiel à produção e testes de carga pegam falhas antes do cliente. Para sistemas críticos, a AWS recomenda ir além, com engenharia do caos e injeção de falhas, que provocam problemas de forma controlada para validar se o sistema se recupera como esperado (AWS).
Na prática: “O teste que mais vale é o que se parece com o uso real. Muita falha só aparece com volume, com dados reais ou com uma integração lenta. Quanto mais fiel for a homologação, menos o cliente vira o primeiro testador.”
Matheus, QA tester da NextAge
Erro comum: testar bem a funcionalidade nova e esquecer a regressão do que já funcionava.
6. Tenha backup e plano de recuperação testados
Dois números orientam o plano: o RTO (tempo máximo aceitável para colocar o sistema de volta) e o RPO (quanto de dado a empresa aceita perder). A Red Hat dá um exemplo claro: se os backups são diários, pode haver até 24 horas de dados perdidos no sistema recuperado. Defina RTO e RPO por sistema, automatize os backups e ensaie a restauração; backup que nunca foi restaurado é só uma hipótese.
Na prática: “Backup só vale depois que alguém consegue restaurá-lo. Eu trato a restauração como parte da rotina, com data marcada e responsável. É nesse ensaio que aparecem os problemas que ninguém queria descobrir durante uma emergência.”
Pedro, desenvolvedor back-end da NextAge
Erro comum: medir o sucesso pelo backup concluído, não pela restauração validada.
7. Trate incidentes como processo
Incidente bem tratado tem plantão definido, roteiros de atendimento (runbooks), comunicação clara e, depois, análise de causa raiz em formato de post-mortem sem busca de culpados. O objetivo é corrigir o problema que gerou a falha, não apenas restabelecer o serviço. Sem esse ciclo, o mesmo incidente volta com outro nome.
Na prática: “Corrigir o sintoma resolve o dia; encontrar a causa raiz resolve o trimestre. Depois de cada incidente, registramos o que falhou, por que não detectamos antes e qual ação evita a repetição, sem procurar culpados.”
Felipe, tech lead da NextAge
Erro comum: encerrar o chamado quando o sistema volta, sem investigar por que caiu.
8. Pague a dívida técnica e mantenha tudo atualizado
Versões de linguagem, banco de dados, servidor de aplicação e bibliotecas fora de suporte acumulam vulnerabilidades e incompatibilidades. A manutenção adaptativa, que atualiza essas camadas, é parte reconhecida da sustentação de software, inclusive em normas públicas (Portaria SGD/ME nº 5.651/2022). Quando a disponibilidade é crítica, a AWS recomenda favorecer a estabilidade em vez do lançamento de novos recursos (AWS).
Na prática: “Atualização adiada costuma cobrar com juros. Versão sem suporte, biblioteca desatualizada, banco antigo: cada item parece pequeno até virar parte de um incidente. Reservar um tempo recorrente para manter tudo em dia sai mais barato do que apagar incêndio.”
Felipe, tech lead da NextAge
Erro comum: tratar atualização como “tarefa para quando sobrar tempo”.
9. Planeje a capacidade
Picos de uso (fechamento, campanhas, sorteios, folha de pagamento) derrubam sistemas que funcionam bem no dia a dia. Acompanhe a tendência de consumo, dimensione limites de banco de dados e de integrações e use escalonamento automático quando fizer sentido: dimensionar servidores para mais ou para menos conforme a carga é uma das formas de sustentar a disponibilidade (Kaseya).
Erro comum: descobrir o limite do sistema durante o pico.
10. Documente e preserve o conhecimento do sistema
Se só uma pessoa sabe como o sistema funciona, a disponibilidade depende da agenda dela. Mantenha documentação viva (arquitetura, integrações, procedimentos de recuperação, decisões passadas) e distribua o conhecimento entre a equipe. Em sistemas legados ou muito customizados, esse é frequentemente o risco menos visível.
Na prática: “O risco mais silencioso é o conhecimento concentrado em uma pessoa. Se só um desenvolvedor entende como o sistema funciona, a disponibilidade depende da agenda dele. Documentação viva e conhecimento dividido são parte da infraestrutura.”
Juliano, CEO da NextAge
Erro comum: deixar a documentação para o fim do projeto, quando ninguém mais a escreve.
Do conhecimento à rotina. As práticas 7, 8 e 10 não se resolvem com um projeto: são trabalho recorrente. Na Sustentação AMS (Application Managed Services) da NextAge, um terço do pacote de horas é reservado a monitoramento, governança técnica e acompanhamento de indicadores operacionais.
Disponibilidade é projeto ou rotina? Suporte reativo versus sustentação contínua
Muitas empresas ainda tratam a disponibilidade como consequência do suporte: o sistema cai, abre-se um chamado e alguém corrige. Esse modelo é reativo e deixa a empresa sem visibilidade sobre o que está em risco. A sustentação contínua, conhecida pela sigla AMS (Application Managed Services), propõe outra lógica: gerir a aplicação como um ativo estratégico, com acompanhamento permanente.
| Aspecto | Suporte reativo | Sustentação AMS |
|---|---|---|
| Atuação | Espera o problema acontecer | Monitora, antecipa e evolui |
| Foco da correção | Restabelecer o serviço | Causa raiz |
| Contrato | Chamados avulsos | Pacote de horas, SLA e escopo definidos |
| Evolução | Fora do escopo | Planejada, dentro do contrato |
| Governança | Pouca visibilidade | Relatórios e reuniões periódicas |
Na NextAge, a Sustentação AMS se organiza em quatro frentes: corretiva (correção de falhas), adaptativa (adequações e atualizações), evolutiva (melhorias) e governança (gestão técnica e acompanhamento executivo). O serviço atua em diversas tecnologias (Java, Node.js, .NET, React, Angular, APIs REST, bancos relacionais e NoSQL) e em ambientes de nuvem como Azure, AWS e GCP, e pode funcionar como extensão do time interno de TI, sem substituí-lo.
Um exemplo vem de uma das maiores associações de pecuária leiteira do Brasil (APCBRH). O sistema sofria com instabilidades na nuvem, faturamento manual e limitações na coleta de dados. A NextAge assumiu a sustentação, migrou o ambiente para uma estrutura mais estável, integrou o faturamento ao sistema bancário por API e criou uma nova forma de coletar os dados de produção. O resultado foi menos quedas e 100% do faturamento automatizado.
A decisão entre continuar sustentando e modernizar também faz parte da rotina. Vale avaliar a modernização quando o custo e o risco de manter superam os de evoluir; sinais típicos são dívida técnica alta, linguagens com escassez de profissionais e arquitetura que limita a escala. O caminho mais seguro costuma ser a modernização incremental, que substitui partes do sistema e valida cada etapa, sem a exposição de uma reescrita completa.
Sua equipe dá conta? Autoavaliação em 7 perguntas
Responda sim ou não:
- Sabemos, em minutos, quanto tempo nossos sistemas críticos ficaram fora do ar no último trimestre?
- Temos metas de disponibilidade (SLO) definidas e acompanhadas por sistema?
- Os alertas avisam a equipe antes que o cliente perceba o problema?
- Cada mudança em produção tem plano de reversão?
- Os backups foram restaurados com sucesso nos últimos seis meses?
- Os incidentes passam por análise de causa raiz, e as ações resultantes são concluídas?
- Mais de uma pessoa domina cada sistema crítico?
Três respostas “não” ou mais indicam risco relevante. Nesse caso, uma conversa diagnóstica, sem custo e sem compromisso, mapeia os riscos dos seus sistemas e propõe um plano de ação: fale com a NextAge.
Um ponto de honestidade: se o seu sistema é simples e de baixo risco, as práticas de 1 a 6 podem bastar com a equipe interna. A sustentação contínua faz mais sentido quando a operação depende de aplicações próprias ou muito customizadas, e o time de TI é enxuto para cobrir todas as frentes.
Perguntas frequentes
O que é disponibilidade de um sistema?
É o percentual do tempo em que uma aplicação está acessível e funcionando como esperado em um período, normalmente um mês ou um ano. Quanto maior o percentual, menor o tempo parado permitido. Difere de confiabilidade, que mede se o sistema executa sua função sem falhas durante um intervalo.
Quanto tempo fora do ar 99,9% de disponibilidade permite?
Cerca de 8,76 horas por ano, ou 43,8 minutos por mês. Com 99,99%, o limite cai para cerca de 52,6 minutos por ano; com 99%, sobe para 3,65 dias. Cada “nove” a mais reduz o tempo parado permitido em aproximadamente dez vezes.
Qual a diferença entre SLI, SLO e SLA?
O SLI é o indicador medido, como a proporção de requisições bem-sucedidas. O SLO é a meta interna para esse indicador. O SLA é o compromisso contratual com o cliente, com consequências em caso de descumprimento. Em geral, o SLA é mais folgado que o SLO interno, para deixar margem de segurança.
O que é orçamento de erro (error budget)?
É a quantidade de falha que o SLO permite em um período: 1 menos o SLO. Com SLO de 99,9% em 30 dias, sobram cerca de 43 minutos. Quando o orçamento acaba, muitas equipes congelam mudanças não urgentes e focam em confiabilidade até recompô-lo.
Qual a diferença entre suporte técnico tradicional e Sustentação AMS?
O suporte tradicional é reativo: espera o problema acontecer para corrigir. A Sustentação AMS monitora, antecipa e evolui a aplicação de forma proativa, com governança, SLA definido e evolução planejada dentro de um contrato recorrente, cobrindo manutenção corretiva, adaptativa, evolutiva e governança.
Quando vale modernizar um sistema legado em vez de continuar sustentando?
Quando o custo e o risco de manter superam o de evoluir. Sinais comuns: dívida técnica alta, poucos profissionais disponíveis na tecnologia e arquitetura que limita a escala. O caminho mais seguro costuma ser a modernização incremental, trocando partes do sistema e validando cada etapa.
Conclusão
Manter a disponibilidade de um sistema é uma disciplina contínua: arquitetura sem pontos únicos de falha, metas medidas, mudanças reversíveis, incidentes tratados até a causa raiz e conhecimento distribuído. Nenhum “nove” a mais compensa a falta de rotina. Se a sua equipe não consegue sustentar essa rotina com a profundidade necessária, vale conhecer a Sustentação AMS da NextAge e pedir um diagnóstico sem custo.
