Resumo executivo: software não é obra entregue; é ativo em operação. Sem contrato de sustentação, um sistema começa a degradar no dia seguinte à entrega — por vulnerabilidade de dependência, por mudança em sistema integrado e por acúmulo de pequenos ajustes que ninguém faz. Este artigo mostra como estruturar essa camada e quanto ela realmente vale.
O mal-entendido que gera o problema
A expectativa comum. “Vamos desenvolver o sistema, e depois é só usar.” A analogia mental é a de uma obra: entregou, acabou.
A realidade. Software vive em um ambiente que muda sem pedir licença. O navegador atualiza. O sistema operacional muda. A biblioteca usada ganha correção de segurança. O ERP integrado altera o formato de um campo. A legislação muda uma regra fiscal. Nada disso é culpa de ninguém — é a natureza do ativo.
A consequência de ignorar. Em doze meses, um sistema sem sustentação acumula vulnerabilidades conhecidas, integrações quebradas e uma lista de “coisinhas” que a operação contorna manualmente. Em dois anos, ele já é chamado de legado.
O que compõe a sustentação
| Frente | O que inclui | Se não for feito |
|---|---|---|
| Corretiva | Correção de erros que impedem ou distorcem a operação | A equipe cria contorno manual e o processo volta a ser planilha |
| Segurança | Atualização de bibliotecas, sistema operacional, banco e certificados | Vulnerabilidade conhecida sem correção — risco técnico e de conformidade |
| Adaptativa | Ajuste a mudanças externas: integração, legislação, versão de plataforma | Integração quebra em silêncio e o dado para de fluir |
| Evolutiva | Melhorias e novas funcionalidades priorizadas com o negócio | O sistema para no tempo enquanto a empresa muda |
| Operação | Monitoramento, backup testado, capacidade, desempenho | Falha descoberta pelo usuário, não pelo alerta |
O erro de contratar só a primeira linha. Muitos contratos cobrem apenas correção de erro. É a frente menos custosa e a que menos previne problema. Segurança e adaptativa são as que evitam a degradação silenciosa.
Como estruturar o contrato
SLA por criticidade — não por tipo de chamado
O que define o prazo é o impacto na operação, não a natureza técnica do problema.
| Criticidade | Definição | O que acordar |
|---|---|---|
| Crítico | Processo parado, sem alternativa | Resposta imediata, atuação contínua até restabelecer |
| Alto | Processo funciona com contorno manual relevante | Resposta no mesmo dia útil, solução em poucos dias |
| Médio | Incômodo sem impacto no resultado | Entra no ciclo regular de correções |
| Melhoria | Nova funcionalidade ou ajuste desejável | Priorização mensal com o negócio |
Cuidado com a classificação. Se tudo é crítico, nada é. Defina os critérios por escrito, com exemplos, e revise a classificação em conjunto nos primeiros meses.
Modelos de contratação
- Horas mensais com saldo. Pacote de horas para correções e melhorias, com relatório de consumo. Simples e transparente; exige disciplina para não virar fila sem prioridade.
- Mensalidade fixa por escopo. Cobre corretiva, segurança e adaptativa; evolutiva é orçada à parte. Previsível para o orçamento.
- Sob demanda. Aciona quando precisa. Parece econômico e costuma ser o mais caro: sem rotina preventiva, o problema chega grande, e sem contrato não há prazo acordado.
Recomendação. Mensalidade fixa cobrindo corretiva, segurança e adaptativa, com evolutiva priorizada mês a mês. Garante que a manutenção invisível — a que previne — seja feita, e mantém a evolução sob controle do negócio.
A parte invisível: manutenção preventiva de software
O que ninguém vê e todo mundo precisa.
- Atualização de dependências. Bibliotecas recebem correção de segurança continuamente. Atualizar aos poucos é rotina; atualizar depois de dois anos é projeto.
- Renovação de certificados. Certificado vencido derruba o sistema inteiro — e é a causa mais evitável de indisponibilidade que existe.
- Teste de restauração de backup. Backup que nunca foi restaurado é uma hipótese. Teste trimestral, com registro.
- Acompanhamento de capacidade. Crescimento de banco, disco e memória com projeção de esgotamento evita a surpresa de um sábado.
- Revisão de acessos. Contas de pessoas que saíram, permissões acumuladas, credenciais de integração antigas.
- Limpeza de dados por retenção. Base que só cresce fica lenta e amplia o risco de exposição de dados pessoais.
Objetivo → Ação → Resultado → Como validar
Objetivo: impedir a degradação silenciosa.
Ação: definir um calendário de manutenção preventiva com periodicidade por item e responsável nomeado.
Resultado esperado: nenhuma dependência com vulnerabilidade crítica em produção e nenhuma indisponibilidade causada por certificado ou disco cheio.
Como validar: relatório mensal com idade da dependência mais desatualizada, data do último teste de restauração e projeção de capacidade.
Dívida técnica: o juro que ninguém lança no orçamento
O que é. O custo futuro de atalhos tomados no presente — código duplicado, teste não escrito, correção improvisada. Como toda dívida, tem juros: cada mudança futura naquela área custa mais.
Quando contrair é legítimo. Prazo regulatório, janela de mercado, piloto de validação. O que não é legítimo é contrair sem registrar.
Como administrar. Mantenha uma lista visível de dívidas com impacto estimado e reserve uma fatia fixa de cada ciclo — algo entre 10% e 20% da capacidade — para quitar as mais caras. Sem essa reserva, a dívida só cresce, e a velocidade de entrega cai até o ponto em que “qualquer mudança é arriscada”. Esse ponto tem nome: legado.
Indicadores de uma sustentação saudável
- Tempo médio de solução por criticidade. Comparado ao SLA acordado, mês a mês.
- Chamados recorrentes. O mesmo problema voltando indica correção de sintoma, não de causa.
- Proporção corretiva x evolutiva. Sistema saudável consome mais capacidade em evolução do que em conserto. O inverso é alerta.
- Disponibilidade. Medida por serviço de negócio, não por servidor no ar.
- Idade da dependência mais desatualizada. O melhor indicador isolado de risco técnico acumulado.
- Defeitos que chegam à produção. Se cresce, o processo de teste precisa de atenção.
Onde esses números vivem. Na prática, no service desk e no monitoramento. Operamos essa camada com GLPI para chamados e SLA e Zabbix e Grafana para disponibilidade e capacidade — assim o relatório mensal é extraído do sistema, não montado à mão.
O relatório mensal que vale a reunião
Uma página, cinco blocos. Se o relatório não muda nenhuma decisão, ele está medindo a coisa errada.
- Disponibilidade do mês por serviço de negócio, com os incidentes que a afetaram e a causa raiz de cada um.
- Chamados por criticidade, com aderência ao SLA e destaque para o que estourou prazo — e por quê.
- Onde a capacidade foi consumida: corretiva, segurança, adaptativa, evolutiva. É este bloco que revela a saúde do sistema.
- Riscos técnicos abertos: dependência desatualizada, capacidade se esgotando, item de dívida técnica priorizado.
- O que entra no próximo ciclo, decidido na própria reunião e registrado.
Por que esse formato funciona. Ele conecta o técnico ao negócio sem exigir vocabulário técnico do gestor, e transforma a sustentação de custo invisível em serviço com resultado demonstrável — que é o que sustenta a renovação do contrato do lado de cá e a aprovação do orçamento do lado de lá.
Perguntas frequentes
Quanto custa a sustentação? Depende da criticidade do sistema, do SLA acordado e do volume de integrações. O ponto importante é orçá-la como despesa recorrente desde o primeiro ano — não como item eventual que aparece quando algo quebra.
Posso sustentar com equipe interna? Pode, se houver mais de uma pessoa com conhecimento do sistema e tempo alocado para a preventiva. O modelo que falha é o do “único desenvolvedor que conhece”, porque férias, saída ou sobrecarga interrompem tudo.
Preciso de sustentação se o sistema está estável? Especialmente nesse caso. Estabilidade é resultado de manutenção, não substituto dela. As vulnerabilidades de dependência aparecem independentemente de o sistema estar funcionando bem.
O que acontece se eu trocar de fornecedor? Se o código está no seu repositório, há documentação de arquitetura e as credenciais são da empresa, a transição é trabalhosa mas viável. Sem isso, é praticamente um reinício — por isso essas cláusulas importam desde o contrato de desenvolvimento.
Riscos e pontos de atenção
- Sistema sem dono nomeado. Sem responsável de negócio e responsável técnico, o backlog não é priorizado e a preventiva não acontece.
- Contrato só de corretiva. Cobre o visível e deixa o risco crescer no invisível.
- Acesso a produção sem controle. Sustentação exige acesso; acesso exige registro nominal e trilha de auditoria.
- Ambiente de homologação inexistente. Corrigir direto em produção funciona até o dia em que não funciona.
- Relatório que ninguém lê. Se o relatório mensal não muda nenhuma decisão, ele está medindo a coisa errada.
- Backup sem teste de restauração. É o item mais barato de verificar e o mais caro de descobrir na hora errada.
Próximos passos práticos
- Liste os sistemas críticos da empresa e marque quais têm contrato de sustentação com SLA por escrito.
- Para cada um, descubra a data da última atualização de segurança das dependências.
- Verifique quando foi o último teste de restauração de backup — se ninguém souber, considere que nunca houve.
- Nomeie um responsável de negócio e um responsável técnico por sistema.
Quer sustentação com SLA e relatório que serve para decidir? A Brazuca Informática desenvolve e sustenta sistemas corporativos em Mato Grosso, Goiás e em todo o Brasil. Fale com nosso time.
Premissas assumidas: as faixas de reserva de capacidade para dívida técnica (10% a 20%) são referências de prática de engenharia, não regra universal; prazos de SLA devem ser acordados caso a caso conforme criticidade e disponibilidade contratada; este artigo não apresenta valores de sustentação porque dependem de escopo, criticidade e nível de serviço.
Continue na série
- Software sob medida ou de prateleira: como decidir sem se arrepender
- Quanto custa desenvolver um software sob medida (e o que forma o preço)
- Low-code na prática: onde acelera de verdade e onde cobra a conta
- Desenvolvimento de sistemas corporativos — Brazuca Informática
Deixe um comentário