Como este tema funciona na sua empresa
SLA simples: 99% uptime para sistemas core (R$ 3,6h/mês de downtime permitido), MTTR 8h. Monitoramento básico (confia em fornecedor relatar). Desafio: quer resolução rápida quando sistema cai mas não quer pagar por SLA 99.9%. Abordagem: definir SLA realista, comunicar expectativa clara ao fornecedor.
SLA estruturado por sistema: core 99.5%, infraestrutura 99%, suporte 99.9% uptime. MTTR tiered: P1 = 1h, P2 = 4h, P3 = 8h. Monitoramento automático (dashboard). Desafio: balancear ambição com realidade (SLA alto custa). Abordagem: usar ferramenta de monitoramento que ambas partes conheçam, relatório mensal.
SLA muito estruturado (por sistema, por cliente se houver), com penalidades. MTTR rigoroso: P1 = 15min resposta, 1h resolução. Monitoramento contínuo 24/7. Desafio: governança de SLA é complexa. Abordagem: portar SLA como tabela de prioridades, vincular a remuneração variável do fornecedor.
SLA (Service Level Agreement) é um contrato que especifica nível de serviço esperado, como medir (uptime %, MTTR), o que fazer se não cumprir (crédito de serviço, multa). É o "contrato dentro do contrato" de outsourcing — deixa clara a expectativa de ambas as partes.
Métricas fundamentais: uptime, MTTR, response time
SLA claro define métricas mensuráveis. As principais:
- Uptime %: Tempo sistema está disponível / tempo total * 100. Exemplo: 99% = 7.2h/mês downtime permitido, 99.5% = 3.6h/mês, 99.9% = 43 minutos/mês.
- MTTR (Mean Time To Recover): Tempo médio para resolver problema após detecção. P1 (crítico) = 1h, P2 (importante) = 4h, P3 (menor) = 8h. Mede velocidade de resolução.
- Response Time: Tempo para responder ao incidente (não resolver, apenas responder). P1 = 15min, P2 = 1h, P3 = 4h. Reduz sensação de abandono.
- Ticket First Response: Primeira resposta ao ticket de usuário. Exemplo: dentro de 2h. Mostra presteza do suporte.
- Quality/FCR: % de tickets resolvidos na primeira tentativa (sem retrabalho). Exemplo: 95% em primeira. Indica qualidade verdadeira.
Escalas de severidade: como classificar incidentes
Prioridade determina SLA exigido:
- P1 (Crítico): Sistema down, múltiplos usuários afetados. Impacto alto no negócio. Resposta: 15 min, Resolução: 1h.
- P2 (Alto): Sistema degradado, alguns usuários afetados. Impacto médio. Resposta: 1h, Resolução: 4h.
- P3 (Médio): Impacto menor, workaround existe. Resposta: 4h, Resolução: 8h.
- P4 (Baixo): Melhoria, não afeta operação. Resposta: 24h, Resolução: próxima janela manutenção.
Medição de SLA: não confie em palavras, meça
Monitoramento automático (ferramenta) é melhor que manual (evita disputa). Requisitos:
- Sistema monitora de fora (não confiar em dados internos fornecedor)
- Frequência: ping/check a cada 5–10 min
- Alertas automáticos quando SLA é quebrado
- Relatório mensal: uptime %, incidentes > SLA, trends
Exclusões de SLA: o que NÃO conta como falha
Contrato deve listar o que não é responsabilidade do fornecedor:
- Outage de ISP (Internet Service Provider)
- Ataques de hacker/DDoS (fora do controle)
- Mudanças não autorizadas do cliente
- Hardware cliente defeituoso
- Janelas planejadas de manutenção (comunicadas com antecedência)
Deixar muito claro para evitar disputa subsequente.
Sinais de que seu SLA está inadequado
Se você se reconhece em dois ou mais cenários abaixo, SLA precisa ser revisado.
- Fornecedor frequentemente não cumpre SLA, mas disputa quanto a causa
- Você não consegue medir SLA (não tem ferramenta, depende de relatório verbal)
- Downtime do sistema afeta negócio significativamente, mas SLA permite muitas horas/mês
- SLA não diferencia por criticidade (tudo é 99%, sistema crítico ou não)
- Contrato não especifica o que é exclusão de SLA (muita ambigüidade)
- MTTR é muito longo ou não existe no contrato (fornecedor prioriza por tamanho, não por crítica)
Caminhos para estruturar SLA de outsourcing
Viável se a empresa tem equipe de TI que entende operação e métricas.
- Perfil: Gerente de TI / SRE com experiência em operação e SLA
- Tempo: 4–6 semanas para mapear sistemas, definir SLAs realistas, negociar com fornecedor
- Faz sentido quando: Empresa tem 1–2 fornecedores, SLA é simples
- Risco: SLA muito ambicioso que fornecedor não consegue cumprir (leva a disputa contínua)
Recomendado para empresas que querem SLA bem estruturado baseado em best practices.
- Tipo de fornecedor: Consultoria ITIL / MSP com experiência em SLA e negociação
- Vantagem: Benchmark de mercado, SLA realista, matriz de responsabilidade clara
- Faz sentido quando: Empresa tem múltiplos fornecedores, quer SLA consistente
- Resultado: Template de SLA tiered, matriz de prioridades, contrato revisado
Precisa definir ou revisar SLA de outsourcing de TI?
Se a empresa quer estruturar SLA clara baseada em best practices ITIL, o oHub conecta você com consultores ITIL e especialistas em service management. Em menos de 3 minutos, descreva seus sistemas críticos e SLAs atuais, e receba propostas, sem compromisso.
Encontrar fornecedores de TI no oHub
Sem custo, sem compromisso. Você recebe propostas e decide se e com quem avançar.
Perguntas frequentes
O que é SLA e por que é importante?
SLA (Service Level Agreement) é contrato que especifica nível de serviço esperado — uptime %, MTTR, response time, etc. É importante porque deixa clara a expectativa de ambas as partes (você e fornecedor), reduz disputa quando problema acontece.
Qual é uptime de SLA realista?
Depende de criticidade: 99% é realista para PME (7.2h/mês downtime), 99.5% para média (3.6h/mês), 99.9% para grande (43 min/mês). Ninguém consegue 100%. Quanto maior %, mais caro (fornecedor precisa redundância, backup, equipe 24/7).
Como medir MTTR (Mean Time To Recover)?
Tempo do início do incidente até resolução. Exemplo: problema detectado 10h, resolvido 11h = MTTR 1h. Média de múltiplos incidentes = MTTR médio. Contrato deve especificar MTTR máximo aceitável por severidade (P1 = 1h, P2 = 4h).
SLA deve ser igual para todos os sistemas ou variar por criticidade?
Deve variar. Sistema crítico (ERP, email) merece SLA 99.5%–99.9%. Sistema não-crítico (wiki interna) pode ter SLA 99%. SLA único para tudo é preguiça — cria custo desnecessário ou expectativas quebradas.
Como monitorar SLA para ter certeza que fornecedor cumpre?
Use ferramenta de monitoramento (Datadog, New Relic, Uptime.com) que vocês duas usam. Dashboard transparente mostra uptime em tempo real. Relatório mensal automático. Não confie em "fornecedor me avisa se problema" — meça.
O que fazer se fornecedor recorrentemente não cumpre SLA?
Contrato deve prever: (1) Reunião de escalação com diretor, (2) Task force — equipes trabalham juntas para melhorar, (3) Multa ou crédito de serviço (compensação), (4) Mudança de escopo ou término se continuar. Não deixe passar sem ação.