Como este tema funciona na sua empresa
Contratam suporte genérico com SLA único. Desafio: não conseguem diferenciar responsabilidades de suporte, infraestrutura e aplicações. Começar com SLA separado por tipo: suporte usa tempo de resposta/resolução; infraestrutura usa uptime (ex: 99,5%); aplicação usa disponibilidade. Mesmo contrato pode ter anexos diferenciados.
Separam suporte (interno ou terceirizado), infraestrutura (parcialmente) e aplicações (internas). Múltiplos SLAs necessários. Desafio: garantir consistência de nível entre fornecedores. Definir SLA por tipo com benchmark de mercado como referência. Suporte: 1h resposta P1, 4h P2. Infraestrutura: 99,9% uptime. Aplicação: 99% transações completas em <2s.
Carteira sofisticada com diferenciação por tipo de serviço e criticidade. Suporte terceirizado (L1-L2), infraestrutura gerenciada, aplicações críticas com SLA de negócio. Matriz SLA x criticidade x fornecedor com dashboard integrado. P1 suporte <30min, infraestrutura 99,99%, aplicação 99,9% uptime.
SLA por tipo de serviço é diferenciação de níveis de serviço adequados a cada tipo de contratação de TI (suporte, infraestrutura, aplicações), usando métricas e tempos específicos a cada um[1].
Por que SLA único não funciona
Serviço de suporte tem dinâmica diferente de infraestrutura, que é diferente de aplicações. Suporte é reativo (problemas que surgem); infraestrutura é preventivo (disponibilidade); aplicação é proativo (performance). Aplicar mesmo SLA a serviços heterogêneos gera frustração (fornecedor não consegue cumprir) ou perda de controle (SLA tão fraco que não governa).
Tipos de serviço e suas métricas apropriadas
Suporte técnico usa tempo de resposta e resolução. Infraestrutura usa uptime e MTTR (tempo médio para reparar). Aplicações usam latência, throughput e disponibilidade. Cada tipo tem ciclo de medição diferente: suporte é por chamado; infraestrutura é por período (mês); aplicação pode ser em tempo real.
Suporte: resposta 1h (P1), 4h (P2), 8h (P3); resolução 4h, 24h, 5 dias. Infraestrutura: 99,5% uptime (servidor), 99% (rede). Aplicação (se houver): 99% uptime durante horário de negócio. Período de medição mensal. Repouso: suporte 24/5 (segunda-sexta), infraestrutura 24/7. Simples. Incluir no contrato qual é SLA por tipo.
Suporte: resposta <1h P1, <4h P2, <8h P3; resolução <4h, <24h, <5 dias. Infraestrutura: 99,9% uptime (produção), 99,5% (desenvolvimento); MTTR <1h. Aplicação: 99% transações completas em <2s, 99,9% uptime em horário crítico. Suporte conta horas úteis; infraestrutura/aplicação 24/7. Diferenciação por criticidade ajuda. Matriz SLA clara documentada.
Suporte: resposta <30min P1, <2h P2, <4h P3; resolução <2h, <8h, <24h. Infraestrutura: 99,99% produção crítica, 99,9% resto. MTTR <30min crítico, <4h resto. Aplicação: 99,95% uptime crítica, latência <100ms. Diferenciação por componente e cliente. SLA de negócio sobreposto (ex: se cliente paga premium, maior prioridade). Dashboard de SLA. Revisão mensal de cumprimento. Penalidade por violação estruturada.
Cascata de SLAs: dependência entre tipos
SLA de aplicação depende de SLA de infraestrutura que depende de SLA de datacenter. Se infraestrutura está 95% disponível e aplicação promete 99% uptime, há conflito. Mapear dependência: infraestrutura deve estar nível acima de aplicação. Exemplo: aplicação 99% uptime requer infraestrutura 99,9%.
Sinais de que seu SLA por tipo precisa ser revisto
Se você reconhece cenários abaixo, sua estrutura de SLA carece de diferenciação.
- SLA de suporte é igual ao SLA de infraestrutura
- Fornecedor reclama que SLA é impossível de cumprir
- Violações de SLA são frequentes mas você não consegue culpar fornecedor (SLA não é claro)
- Aplicação crítica tem mesmo SLA que aplicação de teste
- Métrica de SLA não é apropriada ao tipo de serviço (ex: medindo uptime de consultoria)
- Período de medição não reflete realidade (ex: contando finais de semana em serviço de negócio)
- Não há escalação entre tipos (suporte e infraestrutura trabalham isolados)
Caminhos para estruturar SLA por tipo de serviço
Viável se você tem expertise em SLA ou referência de contrato anterior.
- Perfil necessário: gestor de TI com experiência em SLA
- Tempo estimado: 2-3 semanas para mapear tipos e definir SLAs
- Faz sentido quando: você sabe o que precisa e fornecedor é conhecido
- Risco principal: SLA pode estar desalinhado com benchmark (muito frouxo ou muito rígido)
Recomendado para validar SLAs contra benchmarks e capacidade real.
- Tipo de fornecedor: consultor ITIL, especialista em gestão de TI
- Vantagem: SLAs baseados em benchmarks, validados com fornecedor
- Faz sentido quando: contratação é estratégica ou SLA anterior não funcionou
- Resultado típico: 4-6 semanas, SLAs ajustados, contrato renegociado
Precisa estruturar SLA diferenciado por tipo de serviço?
Se definição de SLA por tipo é desafio, o oHub conecta você gratuitamente a consultores de ITSM e fornecedores experientes. Em menos de 3 minutos, descreva seus serviços (suporte, infraestrutura, aplicações) e receba propostas de SLAs benchmark, 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
Qual é a diferença entre SLA de suporte, infraestrutura e aplicações?
Suporte usa tempo de resposta e resolução (reativo: problema surge, você resolve). Infraestrutura usa uptime e MTTR (preventivo: servidores/rede disponíveis). Aplicação usa latência e throughput (proativo: sistema rápido e disponível). Métricas, ciclos de medição e repouso diferem significativamente.
Como definir uptime de infraestrutura se ela é 24/7?
Uptime é calculado por período (mês). Exemplo: 99,9% uptime em um mês significa máximo 43 minutos de downtime. 99,5% permite 3,5 horas. Usar uptime como métrica mesmo em 24/7. Diferenças: infraestrutura crítica requer 99,9%+; desenvolvimento pode aceitar 99%.
Por que SLA de aplicação depende de SLA de infraestrutura?
Aplicação roda na infraestrutura. Se infraestrutura está 95% disponível, aplicação não consegue estar 99% disponível. Mapear dependência: infraestrutura deve estar nível acima. Se aplicação promete 99% uptime, infraestrutura deve ser 99,9%. Evita conflito futuro.
Como diferenciar SLA entre infraestrutura crítica e não-crítica?
Crítica: servidores de produção, rede, firewall. SLA: 99,9%+ uptime. Não-crítica: ambiente de desenvolvimento, teste, backup. SLA: 99,5% ou menor. Documentar no contrato qual infraestrutura é crítica. Fornecedor pode ter modelo diferenciado (crítica mais caro, maior SLA).
Pode aplicação ter SLA diferente por módulo?
Sim. Módulos críticos (pagamento, acesso) devem ter SLA mais rigoroso. Módulos não-críticos podem ter SLA menor. Documentar SLA por módulo em contrato. Exemplo: módulo de pagamento 99,9% uptime; módulo de relatório 95%. Evita sobre-especificação e custo desnecessário.
Como incluir SLA de aplicação em contrato com fornecedor de infraestrutura?
Se fornecedor de infraestrutura é responsável por aplicação rodar nela, incluir SLA de aplicação no anexo. Se responsabilidade é dividida (você gerencia aplicação), deixar claro que SLA de aplicação é contingente em SLA de infraestrutura. Matriz RACI clara evita disputa.