Um contrato de serviços de TI sem SLA bem definido não é um contrato — é uma lista de intenções. A ausência de métricas claras e consequências definidas transforma qualquer desentendimento numa discussão subjectiva sobre o que foi prometido e o que foi entregue. Este artigo explica o que deve constar num SLA de infraestrutura e como medir as métricas que realmente importam para o negócio.
O que é SLA e por que a maioria dos contratos de TI falha neste ponto
SLA — Service Level Agreement, ou Acordo de Nível de Serviço — é a componente de um contrato que define, de forma mensurável, o nível de serviço comprometido. Não ‘seremos responsivos’ mas ‘tempo máximo de resposta inicial: 4 horas em dias úteis’. Não ‘garantimos alta disponibilidade’ mas ‘disponibilidade mínima: 99,5% mensal, excluindo janelas de manutenção agendada’.
Os contratos de TI falham sistematicamente neste ponto por duas razões: fornecedores preferem compromissos vagos que são difíceis de violar, e clientes aceitam esses compromissos por falta de experiência ou por não quererem complicar a negociação. O resultado são contratos que não protegem nenhuma das partes e não fornecem clareza quando surgem problemas.
Métricas obrigatórias num SLA de infraestrutura
Disponibilidade
A métrica mais fundamental. Expressa em percentagem mensal de tempo em que os sistemas estão operacionais. 99% parece bom mas representa 7,3 horas de downtime por mês. 99,9% representa 43,8 minutos. 99,99% representa 4,4 minutos.
A disponibilidade deve ser definida separadamente para sistemas críticos e não críticos, e deve especificar claramente o que conta como ‘downtime’ e o que está excluído (manutenções agendadas, falhas do ISP, eventos de força maior).
Tempo de resposta e resolução
MTTR (Mean Time To Respond) — tempo médio entre a detecção ou reporte de um problema e a resposta inicial. MTTR (Mean Time To Repair, usando o mesmo acrónimo) — tempo médio entre detecção e resolução completa. Estes devem ser definidos por prioridade de incidente.
| Prioridade | Critério |
| P1 – Crítico | Sistema em baixo, impacto total no negócio |
| P2 – Alto | Degradação significativa, impacto parcial |
| P3 – Médio | Problema menor, workaround disponível |
| P4 – Baixo | Pedido ou melhoria, sem impacto |
Disponibilidade, MTTR e MTBF: o que significam na prática
MTBF — Mean Time Between Failures — é o tempo médio entre falhas. Uma infraestrutura com MTBF de 6 meses tem uma falha a cada 6 meses em média. É uma métrica de fiabilidade que complementa a disponibilidade: um sistema pode ter 99% de disponibilidade com falhas frequentes mas curtas, ou com poucas falhas mas longas. Ambos os padrões têm implicações operacionais diferentes.
Para PMEs, as métricas mais relevantes são disponibilidade mensal, MTTR por prioridade e número de incidentes críticos por período. MTBF é mais relevante para componentes específicos como storage ou equipamentos de rede.
Como negociar SLAs realistas com fornecedores
O objetivo de um SLA não é criar armas legais contra o fornecedor — é criar clareza e alinhamento. Um SLA irrealista que o fornecedor não consegue cumprir é pior do que um SLA menos ambicioso mas cumprido consistentemente.
Na negociação, comece por perceber o que o fornecedor mede actualmente e qual o desempenho histórico. Um fornecedor que não mede disponibilidade não pode comprometer-se de forma credível com um número de disponibilidade. Exija dados históricos antes de aceitar compromissos.
Diferencie serviços por criticidade. Não é necessário ter os mesmos SLAs para todos os sistemas — e tentar aplicar SLAs de missão crítica a sistemas secundários aumenta o custo sem benefício proporcional.
Penalizações e incentivos: como estruturar
Penalizações em SLA devem ser proporcionais, automáticas e simples de calcular. O modelo mais comum é crédito de serviço: se o fornecedor não cumpre o SLA no mês, o cliente recebe crédito na fatura seguinte proporcional ao incumprimento.
Evite penalizações que exijam litigação para ser executadas — são ineficazes e destroem o relacionamento comercial. Prefira mecanismos automáticos baseados em dados de monitorização acordados previamente.
Template básico de SLA para PMEs
Os elementos mínimos de um SLA funcional para serviços de infraestrutura de TI:
- Definição de âmbito: que sistemas e serviços estão cobertos
- Horário de suporte: dias e horas em que os níveis de serviço se aplicam
- Métricas de disponibilidade por sistema ou serviço
- Prioridades de incidente com critérios de classificação
- Tempos de resposta e resolução por prioridade
- Processo de escalamento
- Mecanismo de medição e reporte mensal
- Consequências de incumprimento
- Exclusões e exceções
📌 Reveja o seu contrato de TI com a JL Suporte & Consultoria — identificamos lacunas, riscos e propomos SLAs adequados ao nível de criticidade real dos seus sistemas. Análise gratuita.
