SLA e disponibilidade: o que sua empresa deve exigir de um sistema

Entenda como avaliar metas de disponibilidade, suporte, recuperação e evidências antes de contratar um sistema empresarial.

Quando um sistema deixa de receber pedidos, consultar informações ou atender clientes, a empresa precisa saber quem vai agir e quais compromissos foram assumidos. Uma promessa de estabilidade, sozinha, não responde a essas perguntas.

Avaliar SLA e disponibilidade antes da contratação ajuda a transformar expectativas em critérios verificáveis. O acordo deve explicar quais funções estão cobertas, como as falhas serão medidas e o que acontece quando as metas não são cumpridas.

Para empresas em Recife que dependem de sites, lojas virtuais ou sistemas internos, o ponto de partida é o impacto da interrupção na operação. A seguir, veja como traduzir essa necessidade em requisitos para comparar propostas.

O que é SLA e como ele se relaciona com a disponibilidade

SLA é a sigla de Service Level Agreement, ou acordo de nível de serviço. Ele estabelece compromissos entre cliente e fornecedor, com metas, regras de medição e responsabilidades. Pode abranger disponibilidade, atendimento do suporte e outros indicadores.

A disponibilidade de sistemas representa a proporção do período considerado em que o serviço atende aos critérios acordados. Para que o percentual tenha significado, é necessário definir o que conta como serviço funcionando.

Imagine uma loja virtual cuja página inicial abre normalmente, mas cujo checkout não permite concluir compras. Se a medição verificar apenas a página inicial, poderá indicar funcionamento enquanto a empresa perde pedidos. Por isso, as funções essenciais precisam fazer parte do escopo.

Disponibilidade, desempenho e suporte exigem critérios próprios. Um sistema pode estar acessível e apresentar lentidão excessiva; o suporte pode responder rapidamente e ainda demorar para recuperar a operação.

Também vale distinguir uma meta técnica interna de um compromisso com o cliente. Um objetivo usado pela equipe para orientar melhorias só integra o SLA quando isso estiver explicitamente acordado.

Quanto tempo de indisponibilidade cada percentual permite

Percentuais próximos podem representar diferenças importantes no tempo de interrupção. A fórmula básica é:

Disponibilidade = (tempo elegível − tempo de indisponibilidade contabilizado) ÷ tempo elegível × 100.

O tempo elegível é a janela considerada na apuração, conforme as regras do acordo. Em um mês ilustrativo de 30 dias, com cobertura contínua e sem exclusões, são 720 horas. Nesse cenário:

Esses valores são limites matemáticos para cumprir a meta. Não representam uma previsão de falhas nem uma autorização para programar interrupções com essa duração.

Se a cobertura incluir apenas o expediente ou se determinadas ocorrências forem excluídas, o cálculo muda. Também é preciso observar o período de apuração: meses com durações diferentes têm limites diferentes.

Para uma operação que recebe pedidos continuamente, comparar 99% com 99,9% significa comparar mais de sete horas com pouco mais de 43 minutos mensais. Ainda assim, uma média mensal pode esconder uma interrupção concentrada justamente na campanha mais importante da empresa.

Como definir a disponibilidade que sua empresa precisa

A meta deve acompanhar a criticidade do processo. Comece identificando quais funções, quando falham, interrompem vendas, atendimento ou trabalho interno.

Um site institucional de uma empresa em Recife pode tolerar uma interrupção curta em certos horários. Um sistema de pedidos usado durante todo o expediente pode exigir recuperação mais rápida, especialmente se não houver outra forma de registrar as solicitações.

Antes de negociar percentuais, levante:

• Funções indispensáveis e equipes ou clientes afetados.
• Horários de operação, picos, campanhas e fechamentos.
• Receita afetada, perda de produtividade e retrabalho.
• Dependências de pagamentos, autenticação e outros sistemas.
• Alternativas temporárias e por quanto tempo elas sustentam o trabalho.

Defina também se a cobertura deve ser contínua ou limitada a uma janela específica, com dias, horários e fuso documentados. Quando módulos têm impactos diferentes, pode fazer sentido negociar metas distintas.

Para transformar essas prioridades em evidências, a observabilidade com métricas, logs e rastreamento ajuda a investigar o comportamento da aplicação e suas dependências. Esses dados apoiam o diagnóstico, mas precisam ser associados aos critérios de serviço acordados.

Exigir uma meta mais alta geralmente implica recursos adicionais. A decisão deve considerar o custo da proteção e o impacto das falhas que ela pretende reduzir.

O que precisa estar definido no SLA

Um SLA de sistemas precisa permitir que cliente e fornecedor cheguem ao mesmo resultado ao analisar uma ocorrência. Expressões como “sistema sempre disponível” deixam perguntas essenciais sem resposta.

Confira se a proposta documenta os seguintes elementos:

• Escopo: ambientes, módulos, integrações e funções cobertos.
• Meta e janela: percentual, horários de cobertura e período de apuração.
• Medição: fonte dos dados e critérios para determinar o início e o fim da falha.
• Degradações: tratamento de falhas parciais, erros intermitentes e lentidão severa.
• Manutenção: antecedência do aviso, horários permitidos e limites de duração e frequência.
• Responsabilidades: quem cuida da aplicação, hospedagem, rede e dependências externas.
• Apuração: relatórios, contestação e consequências do descumprimento.

Por exemplo, uma meta de 99,9% pode ser acompanhada de apuração mensal, cobertura contínua e testes das funções de login e conclusão de pedidos. Ainda será necessário detalhar como os testes confirmam uma falha e como a manutenção entra no cálculo.

Exclusões precisam ser específicas. Retirar toda falha envolvendo terceiros pode deixar fora da apuração uma parte importante da experiência do cliente. Mesmo quando uma dependência não integra a meta, deve ficar claro quem investiga, comunica e coordena o incidente.

Se houver créditos de serviço, confira valores, limites, condições e prazo para solicitação. Um desconto na mensalidade não necessariamente cobre vendas perdidas ou o custo de uma equipe parada.

Suporte: diferencie resposta, restabelecimento e resolução

O tempo de resposta do suporte informa quando começa o atendimento definido no acordo. Ele não informa, por si só, quando o sistema voltará a funcionar.

Em uma interrupção total dos pedidos, o fornecedor pode responder em 15 minutos e levar horas para restabelecer o serviço. Negociar apenas o primeiro prazo deixa a recuperação sem um compromisso claro.

Classifique a severidade pelo impacto, pela abrangência e pela existência de alternativa operacional. Uma falha que impede todas as vendas merece tratamento diferente de um problema visual sem efeito na compra.

Para cada nível, defina cobertura, canais, prazos, responsáveis pelo escalonamento e frequência das atualizações. Registre quando os relógios começam e terminam, se contam horas corridas ou úteis e em quais situações podem ser suspensos.

A comunicação durante uma falha crítica deve informar o impacto conhecido, as medidas em andamento e o horário da próxima atualização. Estimativas de recuperação precisam ser apresentadas como estimativas quando ainda houver incerteza.

Como medir a disponibilidade e conferir os relatórios

Verificar se um servidor responde é útil, mas insuficiente para comprovar que o cliente consegue usar o sistema. O monitoramento de sistemas deve acompanhar jornadas essenciais, como entrar na conta, consultar informações e concluir pedidos.

Um teste automatizado pode identificar que o checkout falhou mesmo com a página inicial acessível. Para isso, a jornada testada precisa representar o uso real e ter regras claras para registrar sucesso ou falha.

Combine pontos de observação externos com dados da aplicação. Defina frequência das verificações, localização dos testes e quantas falhas consecutivas são necessárias para confirmar um incidente.

O intervalo entre verificações limita a precisão da medição. Testes a cada cinco minutos podem não detectar interrupções muito curtas ou determinar exatamente quando uma falha começou. O método precisa ser compatível com a meta prometida.

Além da disponibilidade, acompanhe erros e latência, isto é, o tempo de resposta. Se a lentidão passar a contar como indisponibilidade, documente o limite, as funções afetadas e a duração necessária para caracterizar o evento.

Solicite relatórios com início, fim, duração, impacto, exclusões justificadas e resultado da apuração. Incidentes relevantes também devem gerar análise de causa e ações corretivas com responsáveis e prazos.

Backup, RTO e RPO: o que exigir para a recuperação

Manter o serviço disponível no dia a dia e recuperá-lo após uma interrupção grave são necessidades relacionadas, mas diferentes. Para avaliar a recuperação, use dois objetivos:

• RTO: objetivo de tempo para recuperar o serviço após uma interrupção.
• RPO: objetivo de perda máxima de dados, medida em tempo. Indica quão recente precisa ser o ponto de recuperação.

Uma empresa pode definir RTO de duas horas e RPO de 15 minutos. Nesse caso, a proposta precisa explicar como pretende recuperar a operação em até duas horas e limitar a perda de dados ao intervalo acordado.

RTO e RPO exigem procedimentos, recursos e validação. A existência de um backup diário, isoladamente, não comprova um RPO de poucos minutos. Da mesma forma, ter uma cópia dos dados não demonstra que a restauração cabe no RTO.

Confira frequência, retenção, proteção, responsáveis e abrangência dos backups. Solicite evidências de testes de restauração que incluam o tempo gasto e a verificação da integridade dos dados e das funções recuperadas.

Backup é uma cópia recuperável. Redundância mantém componentes adicionais para sustentar o serviço diante de determinadas falhas. Recuperação de desastres reúne procedimentos e recursos para retomar a operação após eventos graves. Uma prática não substitui automaticamente as outras.

Esses objetivos devem integrar a continuidade de negócios, incluindo alternativas de atendimento e responsabilidades da própria empresa enquanto a recuperação acontece.

Quais práticas sustentam a alta disponibilidade

Alta disponibilidade depende de uma arquitetura e de uma rotina de operação capazes de lidar com falhas. Contar servidores não basta: dois servidores de aplicação podem continuar dependentes de um único banco de dados cuja falha interrompe tudo.

Peça ao fornecedor que identifique componentes capazes de parar o serviço e explique como cada risco relevante é tratado. A redundância deve vir acompanhada de mecanismos para transferir o trabalho a componentes saudáveis.

Também é necessário testar essa transferência. Verifique se ela é automática ou manual, quanto tempo leva e quais funções ficam afetadas durante o processo.

Outras práticas que sustentam as metas incluem:

• Capacidade adequada para picos previsíveis e acompanhamento dos limites de recursos.
• Atualizações com validação prévia e procedimentos de reversão.
• Manutenção preventiva e revisão das configurações.
• Monitoramento das dependências de pagamento, autenticação e mensagens.
• Procedimentos de recuperação conhecidos pelas equipes responsáveis.

Mais redundância aumenta custos e não elimina todas as causas de indisponibilidade. Erros de configuração, problemas nos dados e mudanças malsucedidas também precisam ser considerados. A proposta deve relacionar os recursos previstos às metas e aos testes que demonstram sua viabilidade.

Como comparar fornecedores e reconhecer promessas vagas

Compare propostas com uma matriz comum. Dois percentuais de 99,9% podem representar serviços diferentes se houver diferenças de escopo, janela, manutenção ou exclusões.

Uma operação que recebe pedidos à noite deve avaliar com cuidado uma proposta cujo suporte funciona apenas em horário comercial. O percentual mensal, sozinho, não demonstra que haverá atendimento no momento crítico.

Reconheça sinais de ambiguidade: disponibilidade absoluta sem medição, atendimento “imediato” sem definição, recuperação “rápida” sem prazo e backup sem evidência de restauração.

Peça exemplos de relatórios e resultados de testes compatíveis com o serviço proposto. Verifique também como incidentes recorrentes geram ações corretivas e revisão da operação.

Considere o custo total para cumprir as metas: infraestrutura, monitoramento, suporte, backups e manutenção. Uma comparação só é útil quando deixa claro o que cada preço inclui.

Checklist de SLA e disponibilidade antes da contratação

Use estas perguntas na contratação ou renovação. Para cada resposta, registre o compromisso e onde ele aparece na proposta ou no acordo.

• Quais funções, ambientes e horários precisam estar cobertos?
• Qual é a meta e quanto tempo de indisponibilidade ela representa na janela contratada?
• Quem mede o serviço, com qual frequência e quais falhas entram na apuração?
• Como são tratadas falhas parciais, lentidão e erros intermitentes?
• Quais são as regras de manutenção e as exclusões relacionadas a terceiros?
• Quais prazos de resposta, restabelecimento e resolução valem para cada severidade?
• Quais RTO e RPO foram definidos e quais testes demonstram sua viabilidade?
• Quem comunica incidentes, coordena a recuperação e entrega os relatórios?
• Quais responsabilidades, custos e consequências estão documentados?

Se a proposta informa disponibilidade, mas omite testes de restauração e prazos de restabelecimento, esses pontos ainda precisam ser esclarecidos. O checklist permite identificar a lacuna antes de depender do sistema em uma situação crítica.

Sua empresa em Recife precisa de um site ou sistema com requisitos claros de disponibilidade? Converse com a Codephix sobre seus processos, horários críticos e necessidades de suporte para definir o escopo do projeto e os compromissos que deverão constar na proposta.