Um sistema online pode funcionar por muito tempo porque uma pessoa conhece de memória suas telas, regras e exceções. O problema aparece quando ela não está disponível, muda de função ou deixa a organização: uma tarefa rotineira pode virar uma interrupção urgente, e uma alteração pequena pode parecer arriscada demais.
A resposta não é documentar cada detalhe nem criar burocracia que atrase o trabalho. É deixar acessível o conhecimento necessário para operar, corrigir e melhorar o sistema. Este guia propõe um método prático para reduzir a dependência de uma única pessoa.
O que significa depender de alguém para a manutenção
A dependência não se limita a quem escreve o código. Ela também existe quando só uma pessoa sabe como recuperar um acesso, onde investigar um erro, qual integração não deve ser alterada ou quem contatar durante uma interrupção. Se a equipe não consegue concluir uma tarefa normal sem perguntar a essa pessoa, há conhecimento concentrado.
O Secure Software Development Framework (SSDF), do NIST, organiza práticas de desenvolvimento seguro em preparação, proteção, produção e resposta a vulnerabilidades. Ele não prescreve um procedimento único para todas as organizações; oferece uma estrutura que deve ser adaptada ao contexto. A ideia prática aqui é que uma operação sustentável precisa de responsabilidades e procedimentos compreensíveis, além de tecnologia.
Comece pelas tarefas que não podem ficar bloqueadas
Não tente documentar todo o sistema de uma vez. Faça uma lista de tarefas que poderiam interromper uma operação importante ou atrasar uma resposta se ninguém mais soubesse executá-las. Por exemplo:
- Criar ou remover acessos e revisar quem tem permissões administrativas.
- Verificar se o sistema está disponível e onde consultar erros relevantes.
- Publicar uma alteração e conferir se o serviço continua funcionando.
- Contatar o fornecedor de uma integração ou encaminhar um incidente.
- Restaurar uma configuração aprovada ou iniciar uma recuperação autorizada.
- Responder a uma atualização de segurança ou a uma vulnerabilidade reportada.
Priorize pelo impacto operacional, pela frequência e pela dificuldade de substituir o conhecimento. Uma tarefa rara, mas crítica e sem alternativa conhecida, pode merecer atenção antes de uma tarefa diária simples.
Documente o necessário para agir
Um guia útil responde a perguntas concretas: qual é a tarefa, quem pode executá-la, o que precisa estar pronto antes, como verificar o resultado e a quem recorrer se algo falhar? Não inclua senhas, chaves privadas ou dados sensíveis em documentos compartilhados. Indique onde são gerenciados com segurança, não o conteúdo deles.
Para cada procedimento prioritário, registre pelo menos:
- Objetivo e escopo: o que o procedimento cobre e o que fica de fora.
- Responsável principal e substituto: quem executa, quem aprova e quem recebe avisos.
- Etapas e verificações: instruções claras e um modo de confirmar o resultado.
- Dependências: sistemas, fornecedores, permissões ou pessoas envolvidas.
- Escalonamento: o que fazer se o procedimento falhar e como registrar o ocorrido.
- Data de revisão: quando foi verificado pela última vez e quem deve atualizá-lo.
Use capturas de tela ou diagramas quando ajudarem a esclarecer uma sequência, mas não como substitutos das instruções. Uma imagem pode ficar desatualizada e não explica, por si só, o que fazer diante de uma exceção.
Distribua responsabilidades e prepare substitutos
Ter um substituto não significa que todas as pessoas precisam de acesso total. Defina quem pode consultar, alterar, aprovar e encaminhar um problema. Mantenha as permissões proporcionais à tarefa e revise-as quando as responsabilidades da equipe mudarem.
Peça a alguém que não escreveu o guia para testá-lo. Solicite que conclua uma tarefa segura em um ambiente apropriado e anote onde teve dúvidas. Esse teste revela instruções implícitas, permissões ausentes e etapas que só existiam na memória de quem escreveu. Em sistemas com ambientes separados, não faça experimentos em produção: as orientações do NIST incluem separar e proteger os ambientes de desenvolvimento, teste e produção como parte das práticas de segurança.
Transforme a manutenção em rotina
Um guia esquecido pode ser quase tão inútil quanto não ter guia. Programe revisões breves em momentos que já fazem parte do trabalho: uma atualização importante, uma troca de fornecedor, mudanças na equipe ou uma verificação periódica. Confira se os responsáveis continuam corretos, se as instruções funcionam e se os links para ferramentas ainda são válidos.
Use um registro simples para acompanhar alterações e problemas. Pode ser uma ferramenta de acompanhamento que a equipe já utilize. Cada registro deve indicar o problema ou a mudança, sua prioridade, quem é responsável, qual decisão foi tomada e como o encerramento foi verificado. O NIST recomenda identificar vulnerabilidades e responder a elas; suas orientações também descrevem avaliação, priorização e correção como atividades a organizar. Isso não significa que todo problema tenha a mesma urgência: defina critérios compatíveis com o risco e o impacto na operação.
Uma boa manutenção não depende de alguém lembrar de tudo: depende de a equipe encontrar a informação, decidir quem age e verificar o resultado.
Um plano inicial para esta semana
- Escolha três tarefas de manutenção cuja interrupção teria maior impacto.
- Defina uma pessoa responsável e um substituto para cada tarefa, com permissões adequadas.
- Escreva etapas breves, critérios de sucesso e um caminho de escalonamento.
- Peça a outra pessoa que teste as instruções sem ajuda de quem as escreveu.
- Corrija as lacunas e marque uma data para revisar o guia.
Uma equipe pequena não precisa virar um departamento de processos. Comece pelos pontos em que uma ausência poderia bloquear uma tarefa importante e amplie a documentação conforme o sistema e o trabalho mudarem. O objetivo é permitir que outra pessoa continue com segurança, não que todos saibam fazer tudo.
Antes de encerrar, responda a uma pergunta concreta: se amanhã a pessoa que mais conhece o software não estivesse disponível, qual tarefa ficaria bloqueada primeiro? Documente essa tarefa, indique um substituto e teste o procedimento. Esse primeiro passo transforma um risco difuso em uma melhoria que a equipe pode verificar.
Fonte: Appendix C SSDF Analysis — National Institute of Standards and Technology (NIST), NCCoE
