Quanto custa manter um sistema depois que ele entra em produção?

Publicar um sistema não encerra o investimento em tecnologia.

A partir daquele momento começam custos de operação, manutenção e evolução.

A dimensão desses custos depende da criticidade, quantidade de usuários, infraestrutura, integrações e ritmo de mudança do negócio.

Por isso, um projeto deve considerar desde o início como será mantido depois do lançamento.

Infraestrutura

A aplicação precisa rodar em algum lugar.

Os custos podem incluir:

servidores ou cloud;
banco de dados;
storage;
CDN;
backup;
monitoramento;
serviços de e-mail;
filas;
APIs externas;
observabilidade.

Alguns são fixos. Outros variam conforme utilização.

Manutenção corretiva

Mesmo sistemas estáveis podem apresentar problemas.

Mudanças em navegadores, sistemas operacionais, APIs e dependências externas podem gerar situações que não existiam no momento do desenvolvimento.

É importante existir um processo para registrar, priorizar e corrigir incidentes.

Manutenção preventiva

Esperar algo quebrar não é uma estratégia eficiente para plataformas importantes.

Trabalho preventivo pode incluir:

atualizações;
revisão de logs;
capacidade;
backups;
certificados;
segurança;
dependências;
banco de dados;
monitoramento.

O objetivo é reduzir riscos antes que virem incidentes.

Evolução funcional

O negócio continua mudando.

Novas regras, produtos, integrações e necessidades dos usuários aparecem.

Separar orçamento de manutenção do orçamento de evolução ajuda a empresa a enxergar quanto está sendo gasto para manter a operação e quanto está sendo investido para melhorá-la.

Quanto reservar?

Não existe um percentual universal que sirva para qualquer sistema.

Uma plataforma pequena e pouco alterada possui dinâmica diferente de um sistema crítico utilizado diariamente por milhares de pessoas.

Para estimar, considere:

criticidade;
horário de operação;
quantidade de usuários;
volume;
número de integrações;
infraestrutura;
velocidade de evolução;
qualidade do código existente;
documentação;
nível de atendimento necessário.

SLA influencia custo

Atender um problema apenas em horário comercial é diferente de manter cobertura estendida.

Tempos de resposta e resolução também afetam a estrutura necessária.

Por isso, SLA deve ser definido de acordo com impacto real da indisponibilidade e formalizado no contrato.

Sistemas legados podem exigir uma fase inicial diferente

Quando uma nova equipe assume uma plataforma existente, pode existir um período maior de diagnóstico e estabilização.

Depois que ambiente, código e processos são conhecidos, a sustentação tende a se tornar mais previsível.

Custo de não manter

Adiar manutenção também possui custo.

Dependências muito antigas, ausência de backup testado, falta de monitoramento e acúmulo de dívida técnica tornam futuras mudanças mais arriscadas e caras.

Manutenção não elimina todo incidente, mas reduz exposição desnecessária.

Conclusão

O custo real de um sistema é seu ciclo de vida.

Desenvolvimento inicial, infraestrutura, manutenção e evolução precisam ser considerados como partes do mesmo produto.

Empresas que planejam essa continuidade conseguem tomar decisões melhores sobre arquitetura e investimento desde o começo.

Seu sistema já está em produção e precisa de continuidade?

A Jumps pode assumir sustentação e evolução de plataformas digitais após uma avaliação técnica do ambiente.

Falar sobre sustentação →

Relacionado: Sustentação e Evolução · Como assumir um sistema legado sem parar a operação.

Como assumir um sistema legado sem parar a operação

Trocar a equipe responsável por um sistema em produção exige cuidado.

O maior erro é começar alterando código antes de entender como a plataforma funciona.

Um sistema legado pode possuir tarefas agendadas, integrações, servidores, chaves, rotinas manuais e dependências que não aparecem no repositório.

Por isso, a primeira fase deve ser de descoberta.

Comece pelo inventário

Mapeie:

repositórios;
servidores;
banco de dados;
DNS;
domínios;
certificados;
storage;
backups;
cron jobs;
filas;
integrações;
serviços externos;
contas;
credenciais;
monitoramento;
processos de deploy.

O inventário cria uma visão do ambiente antes de qualquer mudança.

Descubra como produção é publicada

Perguntas simples podem revelar riscos importantes:

existe CI/CD?
deploy é manual?
alguém edita arquivos diretamente no servidor?
existe rollback?
banco é migrado automaticamente?
staging representa produção?
código em produção está no Git?

Não presuma que o repositório contém exatamente o que está rodando.

Acesso é parte da transição

Identifique quem possui acesso a:

servidores;
Git;
cloud;
DNS;
banco;
painel administrativo;
serviços de terceiros.

A saída de fornecedores antigos precisa ser planejada para remover acessos sem quebrar automações que dependam das mesmas credenciais.

Backup antes de mudanças

Antes de uma intervenção relevante, confirme se existe backup e se a estratégia de restauração é conhecida.

“Existe um arquivo de backup” e “conseguimos restaurar o sistema” são afirmações diferentes.

Observe antes de otimizar

Código antigo pode parecer estranho porque resolve uma condição que não está documentada.

Antes de remover processos ou refatorar grandes áreas, acompanhe logs, jobs, tráfego e comportamento.

Mudanças iniciais devem priorizar riscos conhecidos e problemas comprovados.

Classifique as pendências

Uma forma útil é separar:

Crítico: risco imediato de indisponibilidade, perda de dados ou segurança.

Alto: problema relevante que deve entrar rapidamente no plano.

Médio: dívida técnica ou melhoria operacional.

Baixo: otimizações sem urgência.

Isso evita transformar a transição em uma tentativa de “corrigir tudo”.

Documente enquanto descobre

Documentação de legado não precisa começar perfeita.

Registre:

arquitetura atual;
hosts;
serviços;
portas;
caminhos;
rotinas;
contatos;
dependências;
procedimentos;
pendências.

O documento evolui conforme o conhecimento aumenta.

Estabilize antes de modernizar

Quando o ambiente apresenta incidentes recorrentes, pode ser melhor separar o trabalho em fases:

inventário;
estabilização;
documentação;
melhorias;
modernização.

Refatorações profundas durante uma crise aumentam risco.

Conclusão

Assumir um sistema legado é um processo de redução gradual de incerteza.

Quanto melhor o inventário e a observação inicial, menor a chance de uma mudança aparentemente simples produzir um incidente.

Precisa assumir ou estabilizar uma plataforma existente?

A Jumps atua em sustentação, infraestrutura e evolução de sistemas já em produção.

Conversar sobre sustentação →

Relacionado: Sustentação e Evolução · Quanto custa manter um sistema depois que ele entra em produção?.

Backups que funcionam: teste de restauração, RPO e RTO

Quase toda empresa tem backup. Pouquíssimas sabem, com precisão, quanto tempo levaria para voltar a operar depois de um incidente sério — e essa é a pergunta que realmente importa. Backup não é um fim em si; é um meio para a recuperação. Se a restauração não foi testada, o backup é uma esperança, não um plano.

Este artigo cobre os dois números que definem uma estratégia de backup (RPO e RTO), a regra prática de onde guardar as cópias, o teste de restauração e os erros mais comuns.

RPO — quanto de dado você aceita perder

RPO (Recovery Point Objective) é a quantidade de dados que a empresa aceita perder em um incidente, medida em tempo. Um RPO de 1 hora significa que, no pior caso, você perde a última hora de trabalho — e portanto o backup precisa rodar pelo menos de hora em hora.

Sistemas transacionais, com pedidos e pagamentos, costumam exigir RPO de minutos, o que leva a técnicas de replicação contínua. Um site institucional pode tolerar um RPO de 24 horas. Definir o RPO é uma decisão de negócio: quanto custa recriar o que foi perdido versus quanto custa a infraestrutura para reduzir a janela.

RTO — quanto tempo você aceita ficar fora do ar

RTO (Recovery Time Objective) é o tempo máximo aceitável entre o incidente e a volta à operação. Um RTO de 4 horas significa que, do momento em que o sistema cai até estar de volta, não podem passar mais de 4 horas.

O RTO define o quão pronta a restauração precisa estar. Um RTO curto exige ambientes de espera, automação de restauração e procedimentos ensaiados. Um RTO longo permite processos mais manuais. Assim como o RPO, é uma decisão de negócio baseada no custo de cada hora parado.

A regra 3-2-1

Uma diretriz consagrada para onde guardar backups:

3 cópias dos dados — a original e pelo menos duas de backup.
2 mídias ou tecnologias diferentes — para não depender de um único tipo de falha.
1 cópia fora do local — em outra região, outro provedor ou fisicamente separada, para sobreviver a um desastre que afete o site principal.

Uma extensão moderna acrescenta o “1 imutável” — uma cópia que não pode ser alterada nem apagada por um período, para resistir a ransomware, que hoje ataca justamente os backups.

O teste de restauração: o que realmente importa

Um backup só conta como válido depois de ter sido restaurado com sucesso em um ambiente limpo. O teste consiste em pegar o backup, restaurá-lo do zero em um ambiente separado, verificar que os dados estão íntegros e completos, e cronometrar quanto tempo levou.

É nesse teste que se descobre o que estava errado o tempo todo:

Faltava um arquivo de configuração que não entrava no backup.
A senha do banco no procedimento de restauração estava desatualizada.
O backup estava sendo feito, mas de uma pasta errada, e parte dos dados nunca foi copiada.
A restauração levava o dobro do RTO combinado.
O backup estava corrompido e ninguém sabia, porque nunca tinha sido aberto.

O teste deve ser periódico — trimestral é uma frequência razoável para a maioria dos casos — e documentado, com o tempo medido e comparado ao RTO.

Backup não é versionamento, nem arquivamento

Três conceitos que costumam ser confundidos: backup serve para recuperar de uma falha recente (dias ou semanas). Arquivamento serve para guardar dados por obrigação legal ou histórica (anos), com acesso raro. Versionamento de código é outra coisa ainda. Cada um tem uma política e uma ferramenta própria; usar backup como arquivo, ou vice-versa, costuma sair caro e não atender bem a nenhum dos dois.

Retenção: por quanto tempo guardar

A retenção deve cobrir o tempo até um problema ser percebido. Se um dado corrompido só é notado depois de um mês, um backup de sete dias não ajuda. Uma política comum combina granularidades: backups diários dos últimos 30 dias, semanais dos últimos 3 meses, mensais do último ano. Ajuste conforme o custo e o risco do seu caso.

Erros comuns

Nunca ter restaurado o backup.
Guardar todas as cópias no mesmo lugar da produção.
Não incluir configurações, segredos e infraestrutura no backup — só o banco.
Retenção curta demais para o tempo de detecção de problemas.
Backup sem monitoramento — ninguém é avisado quando ele falha.
Não proteger os backups contra exclusão, deixando-os vulneráveis a ransomware.
Documentação do procedimento de restauração desatualizada ou inexistente.

Ransomware mudou as regras

Ataques de ransomware hoje procuram e criptografam os backups antes de acionar o resgate, justamente porque um backup íntegro elimina o poder de barganha do atacante. Isso tornou obrigatório o que antes era recomendação: pelo menos uma cópia imutável (que não pode ser alterada nem apagada por um período definido) e, idealmente, uma cópia isolada, em outra conta ou provedor, com credenciais separadas.

Também vale ter um plano de recuperação que assuma o pior cenário — não “um disco falhou”, mas “toda a infraestrutura foi comprometida” — e saber quanto tempo levaria para reconstruir a partir de uma cópia isolada.

O que entra no backup além do banco de dados

Um erro comum é fazer backup apenas do banco de dados e descobrir, na restauração, que falta metade do necessário para o sistema funcionar. O escopo completo costuma incluir:

O banco de dados.
Arquivos enviados por usuários (documentos, imagens, anexos).
Arquivos de configuração e variáveis de ambiente.
Segredos e credenciais (guardados de forma segura).
A definição da infraestrutura, se ela é gerida como código.
Certificados e chaves.

Automação e monitoramento do backup

Backup manual é backup que uma hora não acontece. A rotina precisa ser automática, e precisa haver um monitoramento que avise quando ela falha — o que é mais comum do que parece: um disco cheio, uma credencial expirada, uma mudança de estrutura que quebrou o script. Um backup que falha silenciosamente por semanas é pior do que não ter backup, porque gera uma falsa sensação de segurança.

Backup de serviços gerenciados: não terceirize a responsabilidade

Ao usar um banco de dados gerenciado na cloud, é fácil assumir que “o provedor faz backup”. Ele faz — dentro dos limites do plano contratado, com uma janela de retenção que pode ser curta, e sujeito a você não apagar o recurso por engano (o que costuma apagar os backups junto). Vale conhecer exatamente a política do provedor e complementar com uma exportação periódica para um local sob seu controle, especialmente para os dados mais críticos.

Restauração parcial e granular

Nem todo incidente exige restaurar tudo. Um caso comum é alguém apagar ou corromper um conjunto específico de dados — uma tabela, os registros de um cliente, um período. Um bom desenho de backup permite restaurar só o que foi afetado, para um ambiente separado, extrair o necessário e reinserir na produção, sem derrubar o sistema inteiro nem reverter o trabalho de todos os outros usuários daquele dia.

Documentar e ensaiar o plano de recuperação

O procedimento de restauração precisa estar escrito, passo a passo, e guardado em um lugar acessível mesmo se o sistema principal estiver fora — não adianta o manual de recuperação estar hospedado no servidor que caiu. Além de escrito, precisa ser ensaiado: a primeira vez que alguém executa o procedimento não pode ser no dia do desastre, sob pressão, descobrindo os erros na hora.

Um checklist mínimo

RPO e RTO definidos e acordados com o negócio.
Backup automático na frequência que atende o RPO.
Cópias seguindo a regra 3-2-1, com pelo menos uma imutável.
Configurações, segredos, arquivos de usuário e definição de infraestrutura incluídos, não só o banco.
Monitoramento que alerta quando um backup falha.
Teste de restauração periódico, cronometrado e documentado.
Procedimento de restauração escrito e acessível fora do sistema principal.
Retenção que cobre o tempo de detecção de problemas.
Uma cópia isolada, resistente a um comprometimento total da infraestrutura.

Como a Jumps trata

A Jumps inclui backup testado no escopo de sustentação e evolução: RPO e RTO definidos com o cliente, cópias em locais separados, monitoramento das rotinas e teste de restauração periódico com o tempo medido. Backup que nunca foi restaurado não é considerado backup.

Se você não sabe quanto tempo levaria para recuperar o seu sistema depois de um incidente, fale com a Jumps.

Contrato de sustentação de software: o que precisa estar previsto

Sustentação de software é um compromisso contínuo com um produto que está no ar. Diferente de um projeto de escopo fechado, ela não tem uma lista de entregáveis, e sim um conjunto de responsabilidades recorrentes. Por isso, o contrato precisa ser explícito sobre o que está e o que não está incluído — a maior parte dos conflitos em contratos de sustentação vem de expectativas que nunca foram escritas.

Este artigo lista os pontos que precisam estar claros antes de assinar, do escopo à cláusula de saída.

Escopo: o que é manutenção e o que é evolução

A linha mais importante de definir. Manutenção corretiva é consertar o que deveria funcionar e parou. Evolução é adicionar ou mudar funcionalidade. O contrato precisa dizer:

O que conta como correção (incluída) e o que conta como melhoria (contabilizada à parte ou dentro de uma capacidade de evolução).
Se a atualização de plataforma, framework, bibliotecas e dependências de segurança está incluída — e deve estar.
Se ajustes de conteúdo e configuração feitos a pedido entram, e em que volume.
Se o suporte a mudanças de terceiros (uma API integrada que mudou) é corretivo ou evolutivo.

Sem essa definição, toda demanda vira uma negociação sobre “isso é bug ou é melhoria”.

Níveis de serviço (SLA)

Nem todo problema tem a mesma urgência. O contrato deve classificar as ocorrências por severidade e definir, para cada uma, o tempo de resposta (quando alguém começa a olhar) e o tempo de solução ou de contorno esperado. Um exemplo de classificação:

Crítica — sistema fora do ar ou funcionalidade essencial inoperante. Resposta em minutos, trabalho contínuo até resolver.
Alta — funcionalidade importante degradada, com contorno possível. Resposta em horas.
Média — problema que incomoda mas não impede o uso. Resposta em um a dois dias úteis.
Baixa — ajuste cosmético, melhoria pequena. Entra na fila de evolução.

O contrato também deve definir o canal de abertura de chamados, o horário de cobertura (comercial ou estendido) e quem, do lado do cliente, pode acionar cada nível.

Infraestrutura: dentro ou fora

Deixe claro se a gestão da infraestrutura — servidores, cloud, domínios, certificados — está incluída na sustentação e se os custos de infraestrutura são repassados ou fazem parte do valor. Defina também quem responde por incidentes de infraestrutura fora do horário e se há acompanhamento do custo de cloud.

O que não deve entrar no contrato de sustentação

Assim como é importante definir o que está incluído, vale delimitar o que não está, para evitar expectativa frustrada:

Projetos de grande porte — um módulo novo, uma reformulação de área — que merecem escopo e orçamento próprios.
Suporte a usuários finais do sistema (help desk de primeiro nível), que é diferente de suporte técnico à plataforma.
Recuperação de dados perdidos por erro de uso, quando não há relação com falha do sistema.
Consultoria estratégica ampla não relacionada à operação do produto.

Nada impede que o mesmo fornecedor faça essas coisas — mas em outro instrumento, com outra precificação.

Modelos de precificação

Contratos de sustentação costumam seguir um de três modelos, ou uma combinação:

Valor fixo mensal — cobre a sustentação e uma capacidade definida de evolução. Previsível para os dois lados; exige um escopo bem delimitado.
Pacote de horas — um volume mensal de horas usado conforme a demanda, com regras para o que sobra ou falta. Flexível, mas menos previsível.
Fixo + variável — uma base fixa para a sustentação essencial (monitoramento, atualizações, SLA) mais um variável para evolução sob demanda.

Sinais de um contrato ruim

Escopo descrito em uma frase genérica (“manutenção do site”).
Sem SLA, ou SLA sem consequência.
Nenhuma menção a atualização de segurança.
Sem relatório periódico previsto.
Propriedade de código ou acessos ambíguos.
Sem cláusula de transição.
Reajuste ou revisão de escopo não previstos, virando fonte de conflito anual.

Capacidade de evolução

Um bom contrato de sustentação reserva capacidade para evolução — um pacote de horas mensais ou um valor dedicado — com a lista de melhorias priorizada em conjunto a cada ciclo. Isso evita que cada mudança pequena vire um contrato novo, com orçamento e espera. Defina como a capacidade não usada em um mês é tratada (acumula, expira) e como pedidos maiores que a capacidade mensal são conduzidos.

Transparência e relatórios

A sustentação bem-feita é visível. O contrato deve prever um relatório periódico com:

As ocorrências do período, com severidade e tempo de resolução.
As atualizações de segurança aplicadas.
O que foi evoluído e o que está na fila.
O estado dos backups e dos testes de restauração.
O custo de infraestrutura, quando aplicável.
Riscos técnicos no radar — uma dependência que vai sair de suporte, um gargalo se aproximando.

Acessos e propriedade

O código, os designs e a documentação são da sua empresa. Os acessos a repositório, servidores, contas de cloud e serviços de terceiros ficam em nome da sua empresa, com o fornecedor como usuário. Isso não é desconfiança — é higiene contratual que protege a continuidade do negócio independentemente da relação com o fornecedor.

Cláusula de transição e saída

O contrato precisa prever, desde o início, o que acontece se a relação terminar: um prazo de aviso, um período de transição durante o qual o fornecedor apoia a passagem para outro time, a entrega de documentação atualizada e de um inventário de acessos, e idealmente uma sobreposição em que o time novo acompanha o antigo antes de assumir sozinho.

Fornecedores que resistem a essa cláusula estão construindo uma trava de saída. É um sinal de alerta forte, independentemente da qualidade técnica.

Reajuste e revisão

Defina o índice e a periodicidade de reajuste do valor, e preveja uma revisão de escopo anual — o sistema muda, a carga muda, a criticidade muda, e o contrato deve poder acompanhar sem virar uma renegociação tensa.

Onboarding: as primeiras semanas de um contrato de sustentação

Quando um fornecedor assume a sustentação de um sistema que não construiu, as primeiras semanas são de apropriação: revisar a arquitetura, mapear as dependências, avaliar backups e monitoramento, listar as dívidas e os riscos, garantir acessos. Um bom contrato prevê essa fase — com um diagnóstico inicial entregue por escrito — em vez de assumir que o fornecedor já sabe tudo no primeiro dia.

Esse diagnóstico costuma revelar surpresas: um backup que nunca foi testado, uma dependência sem atualização há anos, um certificado prestes a vencer. Tratá-las é o primeiro valor entregue pela sustentação.

Como medir se a sustentação está funcionando

Os SLAs estão sendo cumpridos, medidos e reportados.
As atualizações de segurança estão em dia.
Os testes de restauração de backup acontecem e passam.
O número de incidentes cai ao longo do tempo, não sobe.
A fila de evolução anda; os pedidos não ficam parados por meses.
Você entende os relatórios e eles chegam sem precisar cobrar.

O erro de contratar sustentação só depois do problema

Muitas empresas só procuram um contrato de sustentação depois de um incidente sério — o site fora do ar por um dia, um vazamento, uma perda de dados. Nesse ponto, a contratação é às pressas, a negociação é ruim e o estrago já aconteceu. Sustentação é um seguro: o momento de contratar é antes, quando o sistema está funcionando e você tem tempo de escolher bem.

Um checklist do contrato

Definição clara de manutenção corretiva versus evolução.
Atualização de plataforma e dependências incluída.
Classificação de severidade com tempos de resposta e solução.
Canal, horário de cobertura e quem pode acionar.
Infraestrutura: escopo e tratamento dos custos.
Capacidade de evolução reservada e como é priorizada.
Relatório periódico com conteúdo definido.
Propriedade de código e acessos em nome da sua empresa.
Cláusula de transição e saída.
Regras de reajuste e revisão anual de escopo.

Como a Jumps estrutura

A sustentação e evolução da Jumps é montada exatamente sobre esses pontos: escopo explícito, SLA por severidade, atualização de segurança como rotina, backup testado, capacidade de evolução priorizada com o cliente, relatório periódico e cláusula de transição desde o primeiro dia.

Se você vai contratar sustentação para um produto no ar, ou revisar um contrato existente, fale com a Jumps.