Sustentação de software: o que vem depois do go-live

O go-live costuma ser tratado como a linha de chegada. O sistema entra em produção, o projeto é encerrado, o time é desmobilizado e alguém recebe a tarefa de “cuidar disso daqui pra frente”. É nesse momento que a maior parte do custo de um software começa. Sustentação de software é o nome do trabalho que vem depois, e é onde se decide se o sistema vai durar ou virar o próximo legado que ninguém quer tocar.

O problema não é falta de esforço. É que a sustentação quase sempre é desenhada como um apêndice do projeto: um contrato de horas para corrigir bugs, uma fila de chamados, um plantão informal. Funciona até o primeiro incidente sério de sexta à noite.

Neste texto falamos do que a sustentação precisa cobrir, de como medir se ela está funcionando e do que cobrar de quem opera o seu sistema.

Sustentação de software não é só corrigir bug

Quando se fala em sustentação, a imagem comum é a de um time atendendo chamados. Isso é uma parte pequena. Um sistema em produção pede pelo menos quatro frentes ao mesmo tempo:

• Operação: incidentes, plantão, rotinas agendadas, filas travadas, certificados que vencem.
• Correção: bugs que o uso real revela e que nenhum teste previu.
• Evolução: ajustes pedidos pelo negócio, que continuam chegando depois do go-live.
• Saúde técnica: atualização de dependências, patches de segurança, versões de runtime e banco que saem de suporte.

A quarta frente é a que some primeiro. Ninguém abre chamado pedindo para atualizar o framework. Ela só aparece quando já virou urgência: uma vulnerabilidade publicada, um provedor de nuvem descontinuando uma versão, uma biblioteca que não compila mais. Sistemas viram legado assim, não por idade, mas por anos de saúde técnica adiada.

Quem construiu deveria operar

Existe uma razão prática para preferirmos operar o que construímos. Quem vai ser acordado às três da manhã por um alerta escreve código diferente. Pensa em logs úteis, em mensagens de erro que dizem alguma coisa, em como reprocessar uma fila sem intervenção manual, em como fazer rollback.

Quando o time que constrói entrega para outro time operar, esse incentivo desaparece. A passagem de bastão vira um documento que ninguém lê, e o conhecimento real, aquele que explica por que uma rotina roda às 2h e não às 3h, fica com quem saiu.

Não é sempre possível manter o mesmo time. Mas quando a sustentação muda de mãos, a transição precisa ser tratada como uma fase com entregáveis próprios, com período de operação em paralelo. Descrevemos esse cuidado em como modernizar um legado sem parar a operação.

Medir o que importa: SLA, SLO e observabilidade

Contrato de sustentação costuma ter SLA de tempo de resposta: chamado crítico respondido em uma hora, por exemplo. É útil, mas mede o fornecedor, não o sistema. Um chamado pode ser respondido em dez minutos e o sistema continuar fora do ar por um dia.

O que vale acompanhar é o comportamento do sistema do ponto de vista de quem usa. É a lógica dos SLOs, bem descrita no livro de SRE do Google: escolher poucos indicadores (disponibilidade, latência, taxa de erro nas jornadas principais) e definir uma meta para cada um. A meta não é 100%. É o nível abaixo do qual o usuário percebe e o negócio sente.

Isso muda a conversa. Em vez de discutir quantas horas foram consumidas no mês, o time e o cliente olham para uma pergunta simples: o sistema cumpriu o combinado? Se não cumpriu, o que vem antes da próxima evolução é estabilidade.

Nada disso funciona sem observabilidade. Métricas, logs estruturados e rastreamento entre serviços são o que permite responder “o que está acontecendo agora” sem abrir o código. Um sistema sem isso é operado no escuro, e cada incidente começa com horas de investigação que poderiam ser minutos.

Para medir a saúde do processo de entrega, as métricas do DORA são um bom ponto de partida: frequência de deploy, tempo de entrega, taxa de falha em mudanças e tempo para restaurar o serviço. Elas mostram se o time consegue mudar o sistema com segurança, que é o que a sustentação precisa proteger.

O incidente é a parte fácil

Parece contraditório, mas o incidente em si raramente é o maior problema. Com alerta, acesso e alguém de plantão, a maioria se resolve. O que diferencia uma boa sustentação é o que acontece depois.

Todo incidente relevante deveria gerar uma análise curta, sem caça a culpados: o que aconteceu, por que não foi detectado antes, o que muda para não se repetir. A mudança pode ser um alerta novo, um teste, um ajuste de capacidade ou uma correção de raiz. Se a mesma falha aparece três vezes em um trimestre, a sustentação está tratando sintoma.

Há também o trabalho que não aparece em nenhum incidente: revisar alertas que disparam e ninguém olha, remover rotinas que não servem mais, documentar o procedimento de recuperação de cada integração. É trabalho pouco visível, e é ele que mantém o sistema previsível.

Quanto da capacidade reservar

Uma pergunta comum é como dividir o tempo do time entre evoluir e manter. Não existe número mágico, mas existe um erro frequente: reservar zero. Quando todo o tempo vai para funcionalidade nova, a saúde técnica é paga depois, com juros.

Nossa prática é deixar explícita uma fatia fixa da capacidade para saúde técnica e combinar isso com o cliente desde o início, em vez de negociar a cada sprint. Essa fatia sobe quando os SLOs são violados com frequência e pode cair quando o sistema está estável. O importante é que a decisão seja visível, não um custo escondido dentro das estimativas.

Na prática

O que cobrar de quem faz a sustentação de software do seu sistema:

• Indicadores de disponibilidade, latência e erro nas jornadas principais, com meta acordada e relatório periódico.
• Alertas que chegam a uma pessoa de plantão, com procedimento documentado para os cenários mais comuns.
• Análise pós-incidente para toda falha relevante, com ações concretas e responsáveis.
• Inventário atualizado de dependências, versões e datas de fim de suporte.
• Uma fatia de capacidade reservada para saúde técnica, visível no planejamento.
• Acesso do cliente a tudo: repositório, documentação, painéis e credenciais ficam com a empresa, não com o fornecedor.
• Capacidade de fazer deploy e rollback a qualquer momento, sem janela especial.

Um sistema construído para durar precisa de alguém que responda por ele depois da entrega. É assim que operamos a LetsSign, nosso próprio produto, e é o que oferecemos no serviço de sustentação e modernização: assumimos a operação do sistema em produção, com indicadores combinados, e evoluímos sem interromper o que já funciona.

Perguntas frequentes

Qual a diferença entre sustentação de software e suporte?

Suporte costuma se limitar a atender chamados e responder dúvidas de uso. Sustentação de software inclui operar o sistema em produção, corrigir falhas na raiz, manter dependências e infraestrutura atualizadas e acompanhar indicadores de saúde. O foco é o sistema continuar funcionando bem, não só o chamado ser fechado.

SLA de tempo de resposta não é suficiente?

Ajuda, mas mede a reação do fornecedor, não a experiência de quem usa o sistema. Complementamos com metas de disponibilidade, latência e taxa de erro nas jornadas principais. Assim a discussão passa a ser sobre o sistema cumprir o combinado, e não sobre horas consumidas.

Dá para trocar o fornecedor de sustentação sem risco?

O risco existe e está no conhecimento que não foi documentado. Por isso tratamos a transição como uma fase própria, com inventário de integrações, rotinas e incidentes recorrentes, e um período de operação em paralelo com quem está saindo. Isso reduz a chance de descobrir uma regra esquecida em produção.