Como este tema funciona na sua empresa
SLA é conversado informalmente: "vamos tentar manter sistema com 95% de uptime". Não há documento formal, não há penalidade se não-cumprido. Monitoramento é manual ou inexistente. Desafio: começar a registrar expectativas de forma clara, mesmo que simples.
SLA é estruturado e documentado, mas frequentemente é único (SLA = SLA). Não há diferenciação por criticidade de sistema. Monitoramento é com ferramentas, relatório trimestral. Penalidades são leves (documentação de não-compliance). Desafio: diferenciar SLA por criticidade e tipo de sistema.
SLAs são múltiplos: por tipo de sistema (crítico, importante, low), por cliente, por tipo de serviço (uptime, resposta, resolução). Monitoramento é em tempo real, alertas automáticos. Penalidades são financeiras (service credit, refund). OLA (Operating Level Agreement) entre times também é definido. Desafio: complexidade não resultar em overhead administrativo.
SLA (Service Level Agreement) é contrato entre TI e usuários/clientes que define expectativas de serviço: qual é o nível de disponibilidade prometido, tempo de resposta a problemas, tempo de resolução. É medível, monitorável, e frequentemente tem penalidade se não-cumprido. SLO (Service Level Objective) é o objetivo interno de TI (pode ser mais exigente que SLA). OLA (Operating Level Agreement) é acordo entre times internos de TI.
Por que SLA importa
Sem SLA, há ambiguidade: "qual é a expectativa de disponibilidade?" Cada um entende diferente. Usuário acha que sistema deve estar sempre disponível; TI acha que downtime de 4 horas/mês é aceitável. SLA resolve ambiguidade: define contrato claro, expectativa explícita. SLA bem-definido melhora satisfação (usuário sabe o que esperar) e reduz conflito (expectativa alinhada).
Componentes de SLA: o que incluir
SLA completo inclui:
- Métrica: o que está sendo medido? (uptime, tempo de resposta, tempo de resolução)
- Alvo: qual é o nível esperado? (99%, 99,5%, 99,9%)
- Período de medição: mensal, trimestral, anual? (mensal é mais comum)
- Penalidade: o que acontece se não-cumprido? (nada, documentação, refund, escalação?)
- Escopo: qual é o serviço incluído? (ex: uptime de aplicação, não uptime de internet do usuário)
- Exclusões: o que não está coberto? (manutenção planejada, ato de Deus, culpa do usuário?)
Diferenciação por criticidade: não há SLA único
Nem todos os sistemas têm mesma criticidade. Aplicação de vendas é crítica (downtime = receita perdida); sistema de relatório é importante (downtime = atraso em decisão); sistema de intranet é low (downtime = inconveniente). SLA deve variar por criticidade:
| Criticidade | Alvo de uptime | Tempo de resposta | Tempo de resolução |
|---|---|---|---|
| Crítico (receita/operação) | 99,5% (3,6h/mês downtime) | 15 min | 4h |
| Importante (eficiência) | 99% (7,2h/mês downtime) | 1h | 8h |
| Low (informação) | 95% (36h/mês downtime) | 8h | 24-48h |
SLA mais exigente (99,9%) custa significativamente mais (redundância, disaster recovery, monitoramento 24x7). Certifique-se de que o alvo é realista e justificado pelo custo do downtime.
Como definir SLA: passos práticos
Passo 1 — Baseline histórico: Qual é a disponibilidade real do sistema hoje? Se sistema tem 99,2% de uptime histórico, SLA de 99,9% é impossível sem investimento significativo. Use histórico como ponto de partida.
Passo 2 — Entender impacto do downtime: Qual é o custo de 1 hora de downtime para negócio? Se sistema de vendas offline custa R$ 50 mil/hora em receita perdida, SLA de 99,5% é razoável (máximo 3,6h/mês). Se sistema de intranet offline custa R$ 0 em receita direta, SLA de 95% é suficiente.
Passo 3 — Envolver negócio: Qual é a expectativa de negócio? "Sistema deve estar sempre disponível" (inviável) ou "pode ter 2 horas de downtime/mês"? (viável). Discussão deve ser facilitada por TI que entende custo de cada nível.
Passo 4 — Considerar infraestrutura: Qual é a infraestrutura hoje? On-premise com um servidor = difícil garantir 99,9%. Cloud com redundância automática = mais fácil. SLA deve ser realista dado infraestrutura.
Passo 5 — Documentar e comunicar: SLA deve estar em contrato ou documento formal. Comunicar para usuários "sistema tem SLA de 99,5%".
Monitoramento de SLA: como acompanhar
SLA sem monitoramento é apenas aspiração. Monitoramento requer:
Ferramentas: Sistemas de monitoramento (Datadog, New Relic, Prometheus) que medem uptime em tempo real. Integração com alertas (se sistema fica offline, alerta automático para TI).
Coleta de dados: Dados de uptime devem ser coletados continuamente. Uptime é calculado como: (tempo total - downtime) / tempo total. Exemplo: mês tem 43.200 minutos; downtime foi 180 minutos; uptime = (43.200 - 180) / 43.200 = 99,58%.
Período de medição: SLA é medido em períodos (mensal é comum). Ao final do período, calcular compliance: atingiu meta? Sim/não.
Exclusões: Manutenção planejada, "atos de Deus" (problemas de internet do data center) frequentemente são excluídas do cálculo de SLA. Documentar o quê é e o quê não é contado.
Relatório: Comunicar resultado ao usuário: "mês de junho, uptime foi 99,52%, meta era 99,5%. Cumprido." Se não-cumprido: explicar causa, comunicar plano de melhoria.
Diferenças: SLA de uptime vs. SLA de suporte
Não confundir. SLA de uptime (disponibilidade de aplicação) é diferente de SLA de suporte (tempo que TI responde a problema).
SLA de uptime: "Sistema está disponível 99,5% do tempo." Medido automaticamente, é responsabilidade de TI Infrastructure/Platform.
SLA de suporte: "Quando há problema, TI responde em 1 hora, resolve em 4 horas." Medido manualmente ou via ticketing system, é responsabilidade de TI Suporte.
Ambos importam. Uptime excelente de 99,9% mas SLA de suporte de 24 horas significa que quando algo quebra, demora tempo para resolver.
Penalidades de SLA
Penalidade motiva cumprimento. Tipos:
- Nenhuma (pequenas empresas): SLA é registrado mas não há penalidade formal. Confiança que TI vai cumprir.
- Documentação (médias empresas): Se não-cumprido, TI documenta causa, plano de melhoria. Pressão é reputacional.
- Service credit (grandes empresas): Se não-cumprido, usuário recebe crédito (ex: refund de parte do valor). Frequentemente "se uptime < 99%, cliente recebe 10% de refund; se < 95%, 25% de refund."
- Escala de severidade: Não-cumprimento < 5% = aviso. Não-cumprimento > 5% = revisão de contrato.
Penalidade deve ser apropriada ao porte. Startups não usam refund (custo proibitivo); grandes empresas usam como prática padrão.
Sinais de que você precisa revisar SLA
Se você se reconhece em dois ou mais cenários abaixo, é hora de revisar seus SLAs.
- Usuários e TI têm expectativas diferentes sobre disponibilidade
- Não há documento formal de SLA (conversado, mas não registrado)
- SLA é único para todos os sistemas (sem diferenciação por criticidade)
- Não há monitoramento de cumprimento de SLA (não sabe se está cumprindo ou não)
- Quando SLA é quebrado, não há conversa sobre causa e plano (apenas frustr não há consequência
- Há reclamações frequentes sobre "sistema deveria estar disponível mais"
- SLA está documentado mas ninguém o conhece ou segue
Caminhos para estabelecer ou melhorar SLAs
Definição de SLA pode ser conduzida internamente ou com apoio especializado.
Viável quando TI tem capacidade de análise histórica e acesso a ferramenta de monitoramento.
- Perfil necessário: gestor de TI com entendimento de impacto de downtime no negócio, capacidade de facilitar conversa com usuários
- Tempo estimado: 30-50 horas para definir + implementar monitoramento
- Faz sentido quando: empresa é pequena-média ou TI já tem ferramentas de monitoramento
- Risco principal: SLA pode ser irrealista (muito exigente ou muito fraco) se não há discussão bem facilitada com negócio
Indicado quando há debate entre TI e negócio sobre SLA, ou quando empresa tem múltiplos sistemas complexos.
- Tipo de fornecedor: Consultoria de ITSM/SLM, facilitadores de workshop, fornecedores de ferramentas de monitoramento
- Vantagem: perspectiva externa, facilitação de conversa TI-negócio, metodologia comprovada, ajuda a implementar
- Faz sentido quando: empresa é grande, há complexidade significativa, ou há desalinhamento TI-negócio sobre expectativa
- Resultado típico: em 4-6 semanas, SLAs definidos por sistema, monitoramento implementado, relatório piloto.
Precisa de apoio para estabelecer SLAs na sua empresa?
Se SLA é desafio ou você quer estabelecer SLAs realistas e monitoráveis, o oHub conecta você gratuitamente a consultores de ITSM e especialistas em gestão de SLA. Em menos de 3 minutos, você descreve sua situação e recebe 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 em TI?
SLA é contrato entre TI e usuários que define expectativa de serviço: nível de disponibilidade (uptime %), tempo de resposta, tempo de resolução. Se não-cumprido, há penalidade (documentação, crédito). Diferente de SLO (objetivo interno) e OLA (acordo entre times).
Como definir um SLA apropriado?
Passo 1: coletar baseline histórico de uptime. Passo 2: entender custo do downtime (impacto no negócio). Passo 3: conversar com negócio sobre expectativa. Passo 4: considerar custo de infraestrutura para atingir nível. Passo 5: documentar. SLA deve ser realista, não aspiracional.
Qual é um SLA realista para TI?
Depende de criticidade e infraestrutura. Crítico: 99,5% (3,6h/mês downtime). Importante: 99% (7,2h/mês). Low: 95% (36h/mês). On-premise com um servidor acha difícil garantir 99,9%. Cloud com redundância consegue mais facilmente.
Como monitorar SLA?
Use ferramenta de monitoramento (Datadog, New Relic) que meça uptime continuamente. Calcule: (tempo total - downtime) / tempo total. Mês tem 43.200 minutos; se downtime foi 180 min, uptime = 99,58%. Comunicar resultado e causa se não-cumprido.
O que fazer se TI quebra SLA?
Comunicar ao usuário honestamente. Explicar causa (infraestrutura falhou, patch mau sucedido, etc.). Documentar. Se há penalidade (service credit), aplicar. Mais importante: identificar raiz e plano de correção para não repetir.
SLA vs. SLO vs. OLA — qual a diferença?
SLA (Service Level Agreement) é contrato com usuário externo/cliente. SLO (Service Level Objective) é objetivo interno de TI (pode ser mais exigente que SLA, ex: 99,9% vs. SLA de 99,5%). OLA (Operating Level Agreement) é contrato entre times internos (ex: infra TI promete 99,9% ao suporte TI).