Contrato de sustentação e SLA de software: como estruturar

Um contrato de sustentação de software deve definir com precisão quais serviços estão incluídos (corretiva, preventiva, adaptativa e evolutiva), o horário de cobertura, os níveis de severidade com exemplos, os tempos de resposta e de solução para cada nível, como a disponibilidade é medida, os relatórios periódicos, os créditos por descumprimento, as exclusões e as regras de transição ao fim do contrato. Um SLA útil é mensurável, compatível com a infraestrutura usada e acompanhado mês a mês.

O que é sustentação de software e o que é SLA?

Sustentação é o conjunto de serviços que mantém um sistema funcionando, seguro e atualizado depois que ele entra em produção. Ela inclui corrigir defeitos, aplicar atualizações, monitorar, ajustar o sistema a mudanças externas e, quando contratado, fazer pequenas evoluções.

SLA (acordo de nível de serviço, do inglês service level agreement) é o compromisso contratual sobre como esse serviço será prestado: em quanto tempo a equipe responde, em quanto tempo resolve e qual disponibilidade o sistema deve ter. Dois termos complementares ajudam a estruturar o acordo:

• SLI (indicador de nível de serviço): a medida usada, como a porcentagem de requisições atendidas com sucesso ou o tempo até a primeira resposta a um chamado.
• SLO (objetivo de nível de serviço): a meta interna para esse indicador, normalmente mais exigente do que o SLA, para criar margem antes do descumprimento contratual.

Quais tipos de serviço entram na sustentação?

Misturar todos os tipos em uma única franquia é a origem de muitos conflitos. Separe-os no contrato.

Como definir severidades e tempos de atendimento?

A severidade deve ser definida pelo impacto no negócio do cliente, com exemplos escritos no contrato. Sem exemplos, cada chamado vira uma negociação sobre a classificação.

Uma estrutura comum tem quatro níveis:

1. Crítica. Sistema indisponível ou função essencial parada, sem alternativa. Exemplo: ninguém consegue emitir pedidos.
2. Alta. Função importante com falha, mas com contorno possível. Exemplo: um relatório gerencial não fecha, mas os dados podem ser extraídos manualmente.
3. Média. Falha que afeta poucos usuários ou uma função secundária.
4. Baixa. Dúvidas, ajustes visuais e problemas cosméticos.

Para cada nível, o contrato deve fixar três tempos distintos: tempo de resposta (primeira manifestação técnica), tempo de contorno (o sistema volta a funcionar, mesmo que provisoriamente) e tempo de solução definitiva. Defina também se o relógio corre em horário comercial ou em regime contínuo e quando ele para, por exemplo enquanto se aguarda uma informação do cliente.

Os valores dependem do que o cliente paga e da equipe disponível. Atendimento crítico fora do horário comercial exige escala de plantão, que tem custo próprio. Não prometa tempos que a equipe não consegue cumprir em todos os dias do mês.

Como calcular e medir a disponibilidade?

Disponibilidade é a porcentagem do tempo em que o sistema está funcionando no período medido. Em um mês de 30 dias, há 43.200 minutos. A conta mostra quanto tempo de indisponibilidade cada meta permite:

• 99% de disponibilidade: até 7,2 horas por mês fora do ar.
• 99,5%: até 3,6 horas.
• 99,9%: até 43,2 minutos.
• 99,95%: até 21,6 minutos.
• 99,99%: até 4,32 minutos.

Três cuidados evitam promessas impossíveis. Primeiro, a disponibilidade do sistema não pode superar a da infraestrutura em que ele roda; consulte os acordos do provedor de nuvem e da hospedagem. Segundo, defina como a disponibilidade é medida: qual verificação, de onde, com que frequência. Terceiro, liste as exclusões, como janelas de manutenção comunicadas com antecedência, falhas de serviços de terceiros e indisponibilidade causada pelo próprio cliente.

Como estruturar o preço da sustentação?

Os formatos mais usados combinam previsibilidade para o cliente e proteção para a software house:

• Valor fixo por escopo. Cobre corretiva, preventiva e operação de um sistema definido, com SLA.
• Franquia de horas. Um volume mensal de horas para adaptativa e evolutiva, com regra para horas não usadas e para excedentes.
• Banco de horas. Horas compradas antecipadamente e consumidas ao longo de um período.
• Por chamado. Útil para sistemas estáveis e de baixa demanda, menos previsível para os dois lados.
• Híbrido. Valor fixo para manter o sistema no ar e franquia para evoluções, o formato mais comum em sistemas de negócio.

O método para chegar ao valor da hora está em como precificar projeto de software.

Que métricas acompanhar todo mês?

O relatório mensal transforma o SLA de cláusula em prática. Inclua pelo menos:

• Chamados abertos, resolvidos e pendentes, por severidade.
• Cumprimento dos tempos de resposta, contorno e solução.
• Disponibilidade medida no período e incidentes relevantes, com causa e ação corretiva.
• Horas consumidas na franquia, por tipo de serviço.
• Atualizações de segurança aplicadas e pendentes.
• Mudanças implantadas em produção e quantas delas causaram falhas.

A estabilidade das entregas merece atenção especial quando a equipe usa IA para programar. O relatório DORA de 2024, do Google Cloud, associou um aumento de 25% na adoção de IA a uma redução estimada de 7,2% na estabilidade de entrega. O relatório de 2025 afirma que garantir que o software funcione como esperado antes da entrega continua sendo um desafio. Revisão de código e testes automatizados protegem o SLA. Veja também DevSecOps explicado para gestores.

Que cláusulas não podem faltar?

Além dos níveis de serviço, um contrato de sustentação deve tratar de:

1. Escopo: quais sistemas, módulos, ambientes e integrações estão cobertos.
2. Exclusões: o que não está coberto e como é orçado.
3. Canais e horários de abertura de chamados.
4. Severidades, tempos e regras de parada do relógio.
5. Medição da disponibilidade e janelas de manutenção.
6. Créditos ou descontos por descumprimento, com limite.
7. Relatórios e reuniões de acompanhamento.
8. Acessos, confidencialidade e segurança da informação, incluindo tratamento de dados pessoais conforme a LGPD.
9. Plano de resposta a incidentes e comunicação ao cliente.
10. Reajuste, prazo, renovação e rescisão.
11. Transição: entrega de documentação, acessos e código ao fim do contrato.

Para os dois últimos itens, veja código-fonte e propriedade intelectual no contrato de software e resposta a incidentes: o que ter pronto. Este texto não substitui orientação jurídica.

Como o SLA vira argumento comercial?

Para muitas software houses, a sustentação é a principal fonte de receita recorrente. Um SLA cumprido e documentado é prova de maturidade operacional.

Compradores corporativos tendem a pedir evidências. A ISO/IEC 27001 trata a disponibilidade como um dos três pilares da segurança da informação, ao lado de confidencialidade e integridade. O SOC 2, definido pelo AICPA, inclui disponibilidade entre as categorias que o relatório pode cobrir, e o tipo 2 avalia se os controles funcionaram ao longo de um período. Mesmo sem certificação, relatórios mensais consistentes e avaliações de clientes de sustentação demonstram o mesmo compromisso.

Próximo passo

Clientes satisfeitos com a sustentação são os mais indicados para avaliar a empresa, porque convivem com ela há meses. Peça essas avaliações e publique-as em fontes independentes. Crie ou reivindique o perfil gratuito na Citeo ou conheça a área para empresas.

Fontes

• Google Cloud — Announcing the 2024 DORA report — aumento de 25% na adoção de IA associado a redução estimada de 7,2% na estabilidade de entrega
• Google — How are developers using AI? Inside our 2025 DORA report — garantir que o software funcione antes da entrega segue como desafio
• ISO — ISO/IEC 27001:2022 Information security management systems — confidencialidade, integridade e disponibilidade como objeto do sistema de gestão de segurança da informação
• Microsoft Learn — System and Organization Controls (SOC) 2 Type 2 — disponibilidade entre as categorias dos Trust Services Criteria e avaliação de controles ao longo de um período