Uma falha em servidor não é medida apenas pelo tempo em que uma aplicação ficou indisponível. Ela pode interromper faturamento, atrasar expedições, comprometer backups, paralisar atendimento e expor falhas de controle. Este guia sobre contratos SLA TI ajuda a transformar uma promessa genérica de suporte em compromissos operacionais verificáveis, compatíveis com a criticidade da sua infraestrutura.
O que um contrato SLA de TI precisa proteger
SLA é a sigla para Service Level Agreement, ou Acordo de Nível de Serviço. Na prática, é a parte do contrato que define o padrão mínimo de serviço que o fornecedor deve entregar, como disponibilidade, horário de atendimento, prazo de resposta, prazo de solução, canais de escalonamento e consequências quando as metas não são cumpridas.
O erro mais comum é contratar um SLA com base apenas em uma porcentagem de disponibilidade. Um índice de 99,9% parece alto, mas permite cerca de 43 minutos de indisponibilidade por mês. Para uma operação que depende de ERP, banco de dados, virtualização ou atendimento contínuo, esse período pode gerar perdas relevantes. Além disso, disponibilidade não substitui tempo de resposta: um fornecedor pode cumprir a meta mensal e ainda deixar um incidente crítico sem assistência nas primeiras horas.
Um bom contrato precisa refletir a arquitetura real do ambiente. Um servidor Dell PowerEdge que hospeda uma aplicação interna de baixa prioridade exige cobertura diferente de um cluster HP ProLiant que concentra máquinas virtuais de produção. A regra é simples: quanto maior o impacto no negócio, mais objetivo e exigente deve ser o SLA.
Métricas que não podem ficar vagas
Termos como “atendimento rápido”, “suporte prioritário” e “melhor esforço” não protegem a operação. Eles abrem espaço para interpretações diferentes no momento em que o ambiente já está sob pressão. O contrato deve usar métricas mensuráveis, com início, fim e responsável claramente definidos.
Disponibilidade do serviço
A disponibilidade deve indicar o que está sendo medido: o hardware físico, o sistema operacional, a camada de virtualização, o storage, a conectividade, o backup ou a aplicação. Um contrato de manutenção de servidor, por exemplo, não deve assumir automaticamente responsabilidade pela internet do cliente ou por um software de terceiros.
Também é necessário definir se a janela de manutenção programada entra no cálculo. Manutenções previsíveis, aprovadas e comunicadas podem ficar fora da conta, mas não devem ser usadas como justificativa para intervenções recorrentes e mal planejadas.
Tempo de resposta e tempo de solução
Tempo de resposta é o prazo para o fornecedor acusar o chamado, iniciar a análise e assumir o atendimento. Tempo de solução é o prazo para restaurar o serviço ou aplicar uma correção definitiva. São indicadores diferentes e ambos precisam constar no documento.
Para incidentes críticos, uma resposta em até 30 minutos, com atuação 24×7, pode ser adequada. Já a substituição física de uma fonte, memória, disco ou controladora dependerá da localização, da disponibilidade de peças e do modelo do equipamento. Não arrisque aceitar um prazo de solução irrealista apenas porque ele parece comercialmente atraente. Exija que a cobertura logística e o estoque de peças sustentem o compromisso assumido.
Classificação de prioridade
As prioridades precisam ser construídas a partir do impacto e da urgência, não apenas da percepção de quem abre o chamado. Uma classificação funcional pode considerar quatro níveis:
- P1: indisponibilidade total de serviço crítico, sem contingência viável;
- P2: degradação relevante com impacto em muitos usuários ou processos essenciais;
- P3: falha parcial com alternativa temporária disponível;
- P4: solicitação, dúvida, ajuste planejado ou incidente sem impacto imediato.
Cada nível deve ter metas próprias de resposta, atualização e solução. Também vale registrar quem pode declarar um P1. Sem essa regra, qualquer solicitação tende a ser classificada como urgente, reduzindo a capacidade de resposta quando uma emergência real ocorrer.
Como definir escopo e responsabilidades
O SLA não substitui o escopo técnico do contrato. Ele depende dele. Antes de discutir porcentagens e multas, registre os ativos cobertos, os serviços incluídos e os limites de atuação do fornecedor.
Em uma operação on-premises, a relação de ativos deve trazer fabricante, modelo, número de série, localização, função e configuração relevante. Isso é particularmente importante em ambientes com equipamentos usados ou recondicionados, nos quais a padronização de componentes, o histórico de manutenção e a disponibilidade de reposição influenciam diretamente o prazo de recuperação.
Defina também quem é responsável por credenciais, backups, licenças, documentação de rede, acesso ao data center e aprovação de mudanças. Se o técnico não consegue entrar no ambiente, obter autorização ou localizar a configuração do ativo, o cronômetro não pode simplesmente ser ignorado. O contrato deve prever como impedimentos causados pelo cliente são registrados e como afetam os prazos.
Há ainda uma diferença decisiva entre restaurar e corrigir. Trocar um disco defeituoso pode restaurar o servidor, mas a reconstrução de um RAID, a validação da integridade dos dados e a análise da causa raiz exigem etapas adicionais. O SLA deve indicar quando o serviço é considerado restabelecido e em que prazo será entregue o relatório técnico do incidente.
Atendimento remoto, presencial e peças de reposição
O modelo de atendimento deve acompanhar a criticidade e a distribuição geográfica da empresa. Suporte remoto resolve grande parte dos eventos de sistema, monitoramento, configuração e diagnóstico inicial. Já falhas em fonte, ventoinha, bateria RAID, placa de rede, controladora ou disco normalmente exigem intervenção física.
Se o contrato prevê atendimento presencial, especifique a cobertura por cidade, o prazo de deslocamento, os horários, os custos fora de área e as condições de acesso. “Atendimento nacional” não significa necessariamente presença técnica em poucas horas em qualquer município brasileiro. O que importa é o prazo contratado para cada localidade e a capacidade real de cumpri-lo.
Para servidores críticos, a disponibilidade de peças é tão importante quanto a disponibilidade do técnico. Um SLA bem estruturado informa se há estoque dedicado, peças compatíveis homologadas, equipamento de contingência ou substituição temporária. Em muitos casos, manter componentes estratégicos no local, como fontes redundantes e discos compatíveis, reduz mais o tempo de parada do que negociar uma multa maior.
A MSServer trabalha com manutenção, monitoramento e fornecimento de componentes para infraestrutura corporativa, um modelo que faz sentido quando equipamento, reposição e suporte precisam responder como uma única operação.
Monitoramento: sem evidência, não há gestão de SLA
O contrato precisa determinar de onde virão os dados usados para apurar o SLA. Pode ser uma ferramenta do fornecedor, o sistema de chamados, a plataforma de monitoramento do cliente ou uma combinação dos dois. O ponto central é que as partes usem registros com horário confiável e histórico acessível.
Monitore disponibilidade, uso de CPU e memória, capacidade de storage, temperatura, alertas de hardware, status de RAID, falhas de fonte, execução de backup e conectividade. A lista exata depende do ambiente, mas o objetivo é antecipar incidentes, não apenas documentar que eles já aconteceram.
Relatórios mensais precisam apresentar chamados por prioridade, tempos de resposta e solução, indisponibilidade acumulada, causas recorrentes, manutenções executadas e pendências. Se o mesmo alerta de disco, temperatura ou backup falha todo mês, o contrato deve gerar uma ação corretiva. Medir sem corrigir transforma o SLA em burocracia.
Penalidades e créditos de serviço com equilíbrio
Créditos de serviço são úteis, mas não recuperam uma operação parada. Eles funcionam como mecanismo de responsabilidade e incentivo à melhoria, desde que sejam proporcionais e tenham regras transparentes. O contrato deve estabelecer a faixa de descumprimento, o percentual de crédito, o limite mensal e o processo para solicitação.
Evite tratar penalidade como o centro da negociação. Um fornecedor pode oferecer crédito elevado e, ainda assim, não ter equipe, peças ou processos para reduzir o impacto de uma falha. Para infraestrutura crítica, a prioridade deve ser prevenção, resposta rápida, escalonamento técnico e recuperação segura.
Inclua uma cláusula de revisão periódica. Mudanças de carga, expansão de máquinas virtuais, implantação de novos sistemas, migração para nuvem privada ou alteração de horários de operação podem tornar o SLA original insuficiente. Um contrato que não evolui deixa de representar o ambiente que deveria proteger.
Perguntas para validar antes da assinatura
Antes de aprovar o contrato, valide situações concretas com o fornecedor. Pergunte qual é o prazo para atendimento de uma falha P1 em seu endereço, como funciona a substituição de uma controladora RAID, quem assume o escalonamento fora do horário comercial e como será comprovido o cumprimento das metas.
Também confirme quais eventos estão excluídos, como ataques cibernéticos, desastres elétricos, falhas de terceiros ou problemas causados por alterações não autorizadas. Exclusões são legítimas quando são claras e coerentes. O risco começa quando elas são amplas o bastante para esvaziar a cobertura contratada.
O contrato certo não é o que promete disponibilidade perfeita. É o que mostra, com prazos, responsabilidades e evidências, como sua empresa será atendida quando a infraestrutura falhar. Use o último incidente relevante do seu ambiente como teste: se o SLA não descreve com precisão como aquela ocorrência seria tratada, ele ainda precisa ser ajustado antes de se tornar necessário.
