Como este tema funciona na sua empresa
SLA é frequentemente implícito ou informal. Gestores negociam "conforme combinado" sem formalizar. Desafio: documentar minimamente para evitar discussões. Abordagem recomendada: SLA simples focado em uptime e tempo de resposta para itens críticos. Documento simples em email é suficiente.
SLA começa a ser obrigatório, mas pode estar ligado a um fornecedor apenas. Desafio: padronizar linguagem e métricas entre fornecedores. Abordagem: SLA estruturado por serviço, com diferenciação por prioridade. Contrato formal com anexo SLA claro.
SLA é peça de governança, exigido para todos os fornecedores, com escalação e penalidades. Desafio: gerenciar carteira de SLAs heterogêneos. Abordagem: SLA como contrato vivo, revisado periodicamente, integrado a dashboards de monitoramento contínuo.
Service Level Agreement (SLA) é acordo que especifica nível mínimo de desempenho que fornecedor se compromete a entregar (uptime, tempo de resposta, qualidade). Transforma promessas vagas em compromissos mensuráveis. Função: define expectativas, reduz ambiguidade, cria responsabilidade compartilhada[1].
Por que SLA importa: diferença entre promessa comercial vaga e compromisso mensurável
Promessa vaga: "Vamos oferecer bom suporte". Impossível cobrar se não cumpre. SLA mensurável: "Resposta em 2 horas, resolução em 4 horas para crítico". Mensurável. Se fornecedor violou, você tem base para ação (crédito, revisão de contrato, término). SLA também protege fornecedor: se acordado "resposta em 24 horas", fornecedor não é cobrado por resposta em 20 horas. Ambos ganham clareza.
Componentes essenciais de um SLA: escopo, métrica, meta, medição, período, escalação
Escopo: qual serviço é coberto? (ex: hospedagem web). Métrica: como mede? (uptime em %, tempo de resposta em horas). Meta: qual é alvo? (99% uptime, 2h resposta). Medição: quem mede? Como? (fornecedor relata, você monitora?). Período: qual é período de apuração? (mensal?). Escalação: o que acontece se violado? (quem você contata? Crédito automático?). Documentação: tudo em escrito; não deixe implícito.
SLA técnico vs. SLA de negócio: qual otimizar
SLA técnico: "Sistema teve 99.5% uptime". Mede máquina. SLA de negócio: "90% dos usuários conseguiram fazer transação". Mede impacto real. Ambos importam. Exemplo: sistema tem 99.5% uptime técnico (SLA OK) mas 70% dos usuários conseguem acessar (SLA negócio falhou). Medir ambos: técnico garante disponibilidade, negócio garante utilidade.
Diferença entre SLA, OLA e UC: estrutura de acordos em TI
SLA (Service Level Agreement): acordo com cliente externo sobre nível de serviço. OLA (Operational Level Agreement): acordo interno entre TI e departamento (ex: TI promete ao Financeiro que sistema estará 99.5% disponível). UC (Underpinning Contract): contrato com fornecedor externo que suporta SLA. Relação: SLA promete ao cliente X; para cumprir, TI precisa de OLA com departamento Y e UC com fornecedor Z. Todos alinhados.
SLA ultra-simples: "Sistema crítico: 99% uptime, resposta 4 horas, dias úteis (9-18)". Documento: uma página. Penalidade: se violar, crédito 5% na próxima nota (simples, sem disputa). Revisão: anual, durante renovação. Acompanhamento: você monitora (planilha) ou fornecedor envia resumo mensal.
SLA por nível: crítico 99.5%, importante 99%, suporte 98%. Resposta diferenciada. Documento: 2-3 páginas, claro, com exemplos. Dashboard: você monitora em tempo real (ferramentas grátis como Uptime Robot). Penalidade: progressiva (1ª vez 5%, 2ª vez 10%, 3ª vez revisão). Revisão: trimestral com fornecedor.
SLA sofisticado por sistema/tier. Métricas múltiplas: uptime, latência, throughput. Crítico: 99.95%, <10ms latência. Documento: 5+ páginas com definições detalhadas. Dashboard: integrado com SIEM, alertas em tempo real. Penalidade: automática (crédito gerado via sistema sem disputa). Revisão: mensal com ambas partes, ajustes semestrais conforme necessidade.
SLA como instrumento de governança: rastreamento, cumprimento, decisões estratégicas
SLA é instrumento de governança: permite rastrear desempenho ao longo do tempo, fundamentar decisões (renovação sim/não), justificar investimentos ("Preciso de R$500k para melhorar uptime de 99% para 99.9%"). Histórico de cumprimento é evidência de qualidade do fornecedor. Cumprimento consistente (>95% de SLA cumprido) = fornecedor confiável. Violações frequentes = risco = considerar alternativa.
LGPD, setor regulado e SLA: requisitos legais de disponibilidade
LGPD (Lei Geral de Proteção de Dados) não impõe SLA específico, mas exige "proteção apropriada de dados pessoais". Setores regulados (financeiro, saúde) têm requisitos: Resolução BACEN (banco: 99.8% uptime mínimo), HIPAA (saúde: 99.9%+). Se empresa está sob regulação, SLA é mandatório, não opcional. Fornecedor que não consegue cumprir SLA do setor é inviável. Sempre verificar requisitos regulatórios ANTES de negociar SLA.
Sinais de que seu SLA está inadequado ou ineficaz
Se três ou mais situações abaixo se aplicam, revise seu SLA.
- SLA é vago ("melhor esforço") sem métrica clara
- Violação de SLA ocorre regularmente; você não consegue cobrar
- Você não sabe de cor qual é seu SLA (é difícil encontrar em contrato)
- Fornecedor nega violação alegando "não era culpa nossa" sem base
- SLA é igual para todos os sistemas (crítico, suporte, teste); não reflete prioridade
- Não há penalidade por violação (crédito, revisão); SLA é apenas papel
- SLA foi assinado há 5+ anos; tecnologia mudou mas SLA não foi revisado
Caminhos para estruturar SLA eficaz
Você estrutura SLA internamente, baseado em necessidade.
- Perfil necessário: gestor de TI, conhecimento do serviço
- Tempo estimado: 2-4 semanas
- Faz sentido quando: serviço é simples, SLA é direto
- Risco principal: SLA pode ser impraticável (fornecedor não consegue cumprir)
Consultor ajuda a validar SLA com fornecedor e benchmark de mercado.
- Tipo de fornecedor: Consultores de contratos, especialistas em SLA
- Vantagem: SLA realista, validado, alinhado com indústria
- Faz sentido quando: serviço é crítico, SLA é complexo
- Resultado típico: 4-6 semanas, SLA estruturado com viabilidade validada
Precisa estruturar ou revisar SLA?
Se você quer garantir que SLA seja claro, mensuráveis e viável, o oHub conecta você gratuitamente com especialistas em SLA. Em menos de 3 minutos, descreva seu serviço e desafio. Receba guia de estruturação.
Encontrar fornecedores de TI no oHub
Sem custo, sem compromisso. SLA bem estruturado protege seu negócio.
Perguntas frequentes
Qual é diferença entre SLA e contrato de serviço?
Contrato é documento legal geral (termos, condiçõesresponsabilidades). SLA é seção específica do contrato que detalha níveis de desempenho (uptime, resposta). Contrato é contêiner; SLA é conteúdo específico.
SLA deve ter penalidade financeira (desconto) ou pode ser apenas alertas?
Penalidade é mais efetiva. Sem penalidade, fornecedor não tem incentivo para cumprir. Penalidade não precisa ser grande (5-10% crédito é suficiente). Automaticamente melhor (não precisa você pedir).
Como estabelecer SLA se fornecedor nunca teve esse serviço?
Comece com SLA aspiracional (mais alto que o que você espera). Fornecedor contra-propõe (mais baixo). Vocês negociam meio termo. Ou: "Qual SLA você consegue oferecer com infraestrutura atual?" Depois: "E com investimento em redundância?" Valida viabilidade.
Posso ter SLA diferente para diferentes usuários (clientes premium vs. básicos)?
Sim, é comum. SLA por tier: Premium 99.9%, Standard 99%, Basic 98%. Cada tier paga diferente. Isso é eficiente: você monetiza SLA premium e oferece basic barato.
Se eu não tenho SLA formalizado com fornecedor, qual é o risco?
Alto risco. Sem SLA, você não consegue cobrar por violação. Fornecedor não tem obrigação contratual de manter performance. Relacionamento fica informal; problema emerge quando falha. Sempre formalize SLA, mesmo que simples.
Como medir SLA se fornecedor não fornece dados?
Você pode monitorar via ferramenta externa (Uptime Robot, New Relic, etc). Se fornecedor não permite monitoring, red flag (falta transparência). Negocie: "Precisamos dados de uptime; ou você relata, ou a gente monitora via ferramenta".