Sistema crítico sem documentação: como manter um sistema que não pode parar

Resumo

• A falta de documentação aumenta o risco, mas não impede a transição.
• O sistema em produção guarda o que o manual perdeu: código, dados, logs e quem o usa.
• A entrada acontece em etapas, com acompanhamento e sem mudanças no começo.
• Quem assume precisa entregar rotina de chamados, monitoramento e conhecimento registrado.

Sem documentação não é sem saída

O desenvolvedor que construiu o sistema saiu. Ou o fornecedor encerrou o contrato. O sistema continua no ar, sustentando parte da operação, e ninguém sabe ao certo como ele funciona por dentro. O instinto mais comum é não mexer em nada e torcer para que nada quebre.

Essa cautela faz sentido, mas tem prazo. Um sistema sem dono acumula risco a cada semana: correções que ninguém sabe fazer, acessos que só uma pessoa tem, rotinas que ninguém lembra que existem.

A boa notícia é que a falta de documentação não impede a transição. Nós chamamos esse trabalho de sustentação: manter, hospedar e evoluir sistemas que já estão em produção. Quem pesquisa por “suporte” ou “manutenção” geralmente quer o mesmo resultado, mas a sustentação cobre a rotina inteira, não só o conserto quando algo quebra. Já falamos dos riscos de manutenção de sistemas legados. Aqui o foco é o caso mais difícil: o sistema crítico que ninguém explicou.

O sistema em produção guarda o que a documentação perdeu

O sistema que está rodando é a documentação mais fiel que existe. Ele só precisa ser lido. Cada fonte revela uma parte do quadro:

Fonte	O que revela
Código e repositório	Regras de negócio, dependências e o jeito como o sistema foi construído
Banco de dados	Que informações o sistema guarda, em que volume e quais tabelas mudam mais
Logs e monitoramento	O que roda, quando roda e onde costuma falhar
Rotinas agendadas e integrações	O que dispara sozinho e com quais outros sistemas ele conversa
Quem usa o sistema	O que o time faz todos os dias e o que nunca pode falhar
Histórico de chamados e e-mails	Falhas recorrentes e correções feitas no passado

Nenhuma fonte sozinha conta a história toda. É o cruzamento entre elas que mostra o que o sistema faz e do que ele depende.

Mapeie primeiro o que não pode parar

Antes de qualquer mudança, definimos o que não pode falhar. Esse recorte evita o erro de tentar entender tudo e não proteger nada. Quatro perguntas guiam o mapeamento:

• Quais fluxos geram prejuízo se pararem? Faturamento, pedidos, atendimento: o que o negócio sente primeiro.
• Quais acessos existem e funcionam? Hospedagem, banco de dados, repositório de código, domínio e certificados. Acesso perdido é o problema mais difícil de resolver depois.
• Com quem o sistema conversa? Integrações com outros sistemas, meios de pagamento e serviços externos.
• Onde há ponto único de falha? Uma rotina que só roda em uma máquina, uma senha que só uma pessoa conhece.

Documente só o mínimo que protege a operação

Parar tudo para escrever o manual completo é um erro comum. Demora, fica desatualizado e não protege a operação no primeiro dia. O que protege é um conjunto mínimo de registros:

• como o sistema sobe e como é restaurado em caso de falha;
• o mapa de integrações e de dependências externas;
• as rotinas agendadas e seus horários;
• quem usa o sistema, quem decide e a quem acionar;
• os problemas conhecidos e como foram resolvidos.

O restante da documentação cresce com o uso. Cada chamado resolvido deixa um registro, e com o tempo o sistema ganha o manual que nunca teve.

Entre em etapas: observar, acompanhar, só então mudar

A regra central é não mexer no que funciona antes de entender por que funciona. Uma entrada segura segue uma ordem:

1. Observar sem alterar nada. Ler código, dados e logs e acompanhar o sistema em operação.
2. Acompanhar em paralelo. Se alguém do time original ou da área usuária ainda puder explicar, o conhecimento dessa pessoa entra agora.
3. Garantir backup e plano de volta. Nenhuma alteração acontece sem um caminho para desfazê-la.
4. Começar por correções pequenas. Elas ensinam como o sistema reage antes de qualquer mudança maior.
5. Só então evoluir. Novas funcionalidades e melhorias entram depois que a operação estiver estável.

Cada etapa tem uma janela combinada com o negócio, para que a operação não pare nem seja surpreendida.

O que cobrar de quem assume a sustentação

Trocar “ninguém sabe” por “alguém sabe, mas não está claro quem” não resolve nada. Um bom contrato de sustentação para um sistema que não pode cair deixa explícito:

• SLA (acordo de nível de serviço): prazos de resposta e de solução por gravidade;
• esteira de chamados: onde os problemas são abertos, acompanhados e priorizados;
• monitoramento: alertas antes de o usuário perceber a falha;
• escalonamento: quem entra quando o problema é maior do que o previsto;
• equipe estável e conhecimento registrado, para que o sistema não volte a depender de uma pessoa só.

O que a Espresso leva para sistemas críticos sem documentação

Assumir um sistema que não pode parar e que ninguém explicou é o tipo de trabalho que a Espresso faz dentro do serviço de manutenção e sustentação. O ponto de partida não é um contrato: é entender o sistema primeiro.

• Diagnóstico técnico antes do contrato: entendemos o sistema, os riscos e o que precisa de atenção antes de propor a sustentação.
• Entrada em etapas, sem mudar o que funciona no começo.
• Esteira de chamados, monitoramento e SLAs formais, como nos sistemas que já mantemos.
• Equipe estável e conhecimento registrado a cada chamado resolvido.

Hoje a Espresso mantém mais de 57 sistemas sob manutenção contínua, e a parceria com um cliente do setor financeiro já passa de 5 anos.

Tem um sistema crítico que ninguém sabe explicar? Fale com quem entende de operação crítica ou chame a gente no WhatsApp. Fazemos uma conversa para entender o escopo e apontamos um caminho com estimativa, sem compromisso.

Perguntas frequentes

O que é sustentação de sistemas?

É manter, hospedar e evoluir um sistema que já está em produção. Inclui corrigir falhas, cuidar da segurança, monitorar o funcionamento e fazer melhorias. Muita gente procura por suporte ou manutenção, mas a sustentação cobre a rotina inteira, não só o conserto quando algo quebra.

É possível assumir um sistema crítico sem documentação?

É, desde que existam o código, os dados e os acessos. A documentação ausente é substituída por mapeamento: lemos código, banco de dados e logs, ouvimos quem usa o sistema e registramos o mínimo necessário. A entrada em etapas reduz o risco de mexer no que funciona sem entender por quê.

A operação precisa parar durante a troca de fornecedor?

Não deveria. Com observação inicial, acompanhamento em paralelo, backup e plano de volta antes de cada alteração, o sistema segue no ar enquanto o novo time aprende como ele funciona. As mudanças só começam depois, e em janelas combinadas com o negócio.

O que entregar ao novo fornecedor para ele começar?

O essencial são o código-fonte, os acessos à hospedagem, ao banco de dados e ao domínio, e a lista das integrações que você conhece. Ajudam também o histórico de chamados antigos e os contatos de quem usa o sistema no dia a dia. Se faltar algum acesso, ele aparece no diagnóstico.