Manutenção de sistemas e sustentação de software

Sistema publicado não fica pronto para sempre. Dependências recebem correções, navegadores e APIs mudam, o volume cresce e o negócio cria novas regras. Sustentação é a disciplina de manter o serviço confiável, seguro e compreendido depois da entrega, com responsabilidades e prioridades explícitas.

Manutenção não significa apenas corrigir defeito. Ela inclui acompanhar operação, atualizar componentes, adaptar integrações, recuperar falhas e planejar mudanças. O modelo deve ser proporcional à criticidade: um site informativo e um sistema que coordena atendimento não exigem a mesma cobertura.

Tipos de manutenção

Tipo	Objetivo	Exemplo
Corretiva	Restaurar comportamento aceito	Corrigir cálculo que divergiu da regra
Preventiva	Reduzir risco antes do incidente	Atualizar dependência e testar restauração
Adaptativa	Acompanhar mudança externa	Adequar integração a nova versão de API
Evolutiva	Atender nova necessidade	Adicionar etapa validada ao processo

A classificação evita conflito. Uma função nova não deve ser tratada automaticamente como correção; uma regressão do critério aceito não deve consumir orçamento evolutivo sem explicação. Contrato e registro da demanda precisam indicar categoria, impacto e aceite.

Comece pelo inventário do serviço

Para assumir um sistema existente, identifique repositório, ambientes, domínio, DNS, hospedagem, banco, arquivos, filas, rotinas agendadas, integrações, credenciais, fornecedores e responsáveis. Confira como uma versão é publicada e restaurada. Não mude produção antes de obter backup e entender o caminho de volta.

Quais fluxos são críticos e quem percebe a falha?
Onde estão código, documentação e histórico de mudanças?
Quem é titular das contas e recebe cobrança ou alerta?
Quais versões e dependências estão sem suporte?
O backup inclui banco, arquivos e configuração? Já foi restaurado?
Quais integrações têm documentação, contato e ambiente de teste?
Como usuários relatam problema e acompanham a resposta?

Se não existem testes, crie primeiro cenários de caracterização para os fluxos que precisam ser preservados. Um diagnóstico pode revelar modernização necessária; o artigo sobre sistemas legados ajuda a decidir entre manter, integrar, refatorar ou substituir.

Severidade, prioridade e acordo de atendimento

Severidade mede impacto técnico e operacional; prioridade define a ordem considerando impacto, urgência, risco e alternativas. Um defeito visual pode ser urgente por campanha, enquanto uma falha grave em função ainda não usada pode permitir planejamento. Defina quem classifica e quem pode reavaliar.

O acordo de serviço deve separar tempo para reconhecer, iniciar diagnóstico, comunicar e restaurar. Prazo de solução definitiva nem sempre pode ser conhecido no primeiro contato. Também precisam estar claros horário de cobertura, canais, dependências externas, manutenção programada e responsabilidades do cliente.

Monitoramento e resposta a incidentes

Monitorar apenas se a página abre não confirma o fluxo. Acompanhe disponibilidade, erros, latência, filas, tarefas agendadas, banco, espaço, certificados e integrações relevantes. Alertas devem indicar ação possível; ruído constante faz a equipe ignorar o aviso importante.

Um incidente precisa de responsável, linha do tempo e atualizações. Primeiro contenha e restaure com segurança; depois investigue causa e correção permanente. Preserve evidências quando houver suspeita de segurança. Ao final, registre ações sem transformar a revisão em busca de culpado.

Detectar e confirmar o impacto.
Classificar, designar responsável e comunicar.
Conter o problema e proteger dados.
Restaurar por correção, reversão ou contingência.
Validar o fluxo com o negócio.
Analisar causa, lacunas de detecção e prevenção.

Backup e continuidade

Backup automático não basta. Defina frequência, retenção, proteção, responsável e objetivo de recuperação. Teste restauração em ambiente separado e registre resultado. Código em repositório não substitui cópia de banco, arquivos, configurações e dados necessários para reconstruir o serviço.

Crie procedimentos para cenários proporcionais: excluir registro por engano, corromper lote, perder credencial ou ficar sem provedor. Nem todo sistema precisa de redundância complexa, mas todo sistema importante precisa saber quanto dado e operação pode perder e quem decide a recuperação.

Atualizações e segurança

Mantenha inventário de dependências e versões suportadas. Avalie avisos de segurança pelo componente usado, exposição e impacto; não atualize produção cegamente nem deixe correção crítica sem decisão. Teste em ambiente separado, revise mudança incompatível e tenha plano de reversão.

NIST SSDF organiza práticas de desenvolvimento seguro e o OWASP ASVS oferece requisitos verificáveis para aplicações web. Use-os conforme o risco, junto a gestão de acesso, segredos, logs e resposta a incidente. Dados pessoais também exigem o processo descrito em LGPD para pequenas empresas.

Mudança e publicação

Toda alteração deve ter demanda, escopo, revisão, teste e registro. Automatizar publicação reduz passos manuais, mas não elimina aprovação ou verificação. Mudanças de banco precisam considerar compatibilidade e reversão; uma versão antiga pode não funcionar depois de transformação destrutiva.

Use lançamentos menores quando possível, com indicador de saúde e critério de rollback. Depois da publicação, valide o fluxo real e acompanhe erros. Documente decisões que mudam arquitetura ou regra de negócio para não concentrar conhecimento.

Modelos de contratação

Modelo	Quando avaliar	Cuidado
Por demanda	Uso pouco crítico e mudanças esporádicas	Disponibilidade e contexto não ficam reservados
Franquia ou capacidade recorrente	Fila contínua de manutenção e evolução	Definir prioridade, saldo e itens incluídos
Sustentação com cobertura	Operação depende do sistema e precisa de resposta	Acordar horário, escalonamento e terceiros

Compare escopo, não apenas quantidade de horas. Monitoramento, plantão, revisão preventiva e evolução são entregas diferentes. O artigo sobre custo de hospedagem e manutenção separa infraestrutura, serviços e suporte.

O que exigir no contrato e na operação

Sistemas, ambientes e horários cobertos.
Canal, severidade, comunicação e escalonamento.
Tipos de manutenção incluídos e forma de estimar evolução.
Responsáveis por contas, backups, segurança e fornecedores.
Acesso ao repositório, documentação e registro de mudanças.
Tratamento de incidentes, dados e confidencialidade.
Condições de encerramento, transição e entrega de acessos.

Indicadores úteis incluem incidentes por causa, tempo de detecção e restauração, mudança com falha, sucesso de backup e demandas acumuladas. Não há meta universal. Observe tendência, criticidade e se ações preventivas reduzem repetição.

Se um sistema novo ainda está sendo planejado, a página de desenvolvimento de sistemas em São Paulo ajuda a incluir operação desde o escopo, em vez de decidir manutenção apenas após a entrega.

Perguntas frequentes

Hospedagem já inclui manutenção do sistema?

Normalmente são responsabilidades distintas. O provedor mantém serviços contratados; código, integração, regra e atendimento dependem do acordo de sustentação.

Todo sistema precisa de contrato mensal?

Não. A escolha depende de criticidade, frequência e cobertura necessária. Sistemas pouco críticos podem usar demanda, desde que riscos e disponibilidade estejam claros.

Backup automático garante recuperação?

Não. É preciso verificar alcance, retenção, acesso e testar a restauração do conjunto necessário para operar.

Manutenção evolutiva é correção?

Não. Evolução altera ou adiciona capacidade; correção restaura um comportamento aceito. O contrato deve definir como cada categoria é tratada.