O teu sistema funciona muito bem. Até ao momento em que trabalha a pessoa que sabe porquê.
A empresa tem um sistema que foi construído ao longo de sete anos. Funciona. Atende clientes. Liga-se a outros sistemas. Executa processos sem os quais a empresa, na prática, não conseguiria funcionar normalmente.
Ao longo desses sete anos, cinco programadores trabalharam no projeto. Além disso, houve dois freelancers e uma agência. Parte da documentação está no Confluence, parte no Google Drive, parte nos tickets. Algures ainda existe um documento antigo sobre uma das integrações. E quando alguém pergunta por que razão um determinado fragmento do sistema funciona daquela forma, a resposta é: "Acho que o Michał se lembrava disso."
O Michał saiu há três anos.
E é precisamente aí que começa o verdadeiro problema.
Não porque o sistema esteja mal escrito. Não porque tenha deixado subitamente de funcionar. O problema é que a empresa deixou de ter conhecimento completo sobre o seu próprio sistema.
O sistema funciona, mas a empresa pode não o controlar
Esta é uma das formas mais subestimadas de dívida tecnológica.
Quando falamos de dívida tecnológica, normalmente pensamos em código antigo, bibliotecas desatualizadas, erros de arquitetura, falta de testes ou soluções que foram rápidas no passado, mas que hoje dificultam o desenvolvimento.
Entretanto, existe ainda outro tipo de dívida. Dívida de conhecimento.
Ela surge quando o sistema depende de informação que não está na documentação, no repositório, nos procedimentos nem na organização, mas apenas na cabeça de pessoas concretas.
E enquanto essas pessoas estão disponíveis, tudo pode parecer normal.
O problema aparece quando há mudança de equipa, saída de um programador, fim da colaboração com uma software house, falha de servidor, troca de administrador ou necessidade de implementar rapidamente uma nova solução.
De repente, percebe-se que a empresa tem código, mas não tem conhecimento.
Tem um servidor, mas não tem a certeza de quem tem acesso.
Tem uma integração, mas não se sabe em que conta foi criada.
Tem documentação, mas não se sabe qual versão está atualizada.
Tem um processo, mas não se sabe por que foi desenhado exatamente assim.
E então surge rapidamente a pergunta: quem é, afinal, o proprietário deste sistema?
Bus factor, ou o que acontece se uma pessoa desaparecer?
No mundo de IT existe o conceito de bus factor. Simplificando, ele indica o número de pessoas cuja indisponibilidade pode fazer com que a equipa deixe de conseguir desenvolver ou manter o projeto de forma eficaz.
Obviamente, não se trata de um acontecimento literal. É uma forma de pensar sobre a concentração de conhecimento.
Se apenas uma pessoa sabe como funciona uma integração crítica, o bus factor desse conhecimento é um.
Se apenas um administrador tem acesso à produção, o bus factor é um.
Se apenas uma pessoa sabe por que o sistema executa um determinado processo todas as noites, o bus factor pode ser um.
Se a empresa trabalha com uma software house externa e, do lado do cliente, ninguém entende a arquitetura da solução, surge um problema ainda maior - o conhecimento pode estar fora da organização.
Isto não significa que cada empresa precise de cinco especialistas em cada fragmento do sistema.
Trata-se de algo muito mais simples: a empresa deve saber onde está o conhecimento crítico e se consegue recuperá-lo sem uma pessoa específica.
O código mostra como. Nem sempre mostra porquê.
Um programador pode ler o código e perceber o que uma determinada função faz.
Nem sempre, porém, saberá por que razão foi escrita exatamente dessa forma.
É uma diferença enorme.
É possível encontrar o fragmento responsável por enviar dados para um sistema externo. É possível analisar o endpoint, os parâmetros, a autorização e o tratamento de erros.
Mas o código não responderá necessariamente a perguntas como:
- Por que razão os dados são enviados às 2:00 da madrugada?
- Por que razão este status específico é ignorado?
- Por que razão, após um erro, o sistema tenta novamente exatamente três vezes?
- Por que razão um valor é recalculado antes do envio?
- Por que razão não é possível alterar a ordem dessas operações?
- Por que razão esta integração usa uma conta específica?
A resposta pode estar no histórico do projeto, num ticket antigo, num e-mail de há seis anos ou - pior ainda - apenas na memória da pessoa que já não trabalha na empresa.
Por isso, uma boa documentação não deve ser apenas um manual de "o que clicar".
Deve também guardar o contexto e as decisões.
O maior problema pode ser uma integração da qual ninguém já se lembra
Um sistema moderno quase nunca funciona de forma completamente autónoma.
Liga-se a um sistema ERP. CRM. Gateway de pagamentos. Fornecedor de SMS. Sistema de entregas. API do parceiro. Serviço na cloud. Plataforma analítica. Sistema contabilístico. Mecanismo de autorização.
Cada uma dessas ligações faz parte de uma cadeia tecnológica.
E cada parte dessa cadeia pode ter o seu próprio proprietário, conta, chave API, certificado, contrato, limite, versão de API e ciclo de vida.
Depois de alguns anos, já ninguém pode lembrar-se de quem criou determinada conta.
E então basta a expiração de um certificado ou uma alteração na API para o sistema deixar de funcionar.
Pior ainda se a empresa nem sequer souber que essa dependência existe.
Por isso, numa abordagem madura aos sistemas, ganham cada vez mais importância a proveniência do software, a gestão de dependências e a transparência da cadeia de fornecimento de software. O NIST, nos seus materiais atuais sobre segurança da cadeia de fornecimento, destaca, entre outros aspetos, a importância da informação sobre componentes, a sua origem, o ciclo de vida e as dependências. SBOM, ou Software Bill of Materials, é uma das ferramentas que permite organizar o conhecimento sobre os componentes que compõem o software.
Isto já não é apenas um tema para a equipa de security.
É também um tema para a direção.
Porque, se a empresa não sabe de que é feito o seu sistema, tem mais dificuldade em avaliar o risco, o custo de manutenção e as consequências das mudanças.
A documentação não é um custo. É uma apólice.
Em muitas empresas, a documentação é tratada como algo que "se faz mais tarde".
Primeiro a funcionalidade.
Depois a implementação.
Depois as correções.
Depois o próximo projeto.
E a documentação?
"Quando houver tempo."
O problema é que o tempo para a documentação normalmente só aparece quando já é tarde demais.
A documentação deve funcionar como um seguro empresarial. Não porque alguém a vá ler todos os dias. Pelo contrário - oxalá seja necessária o mais raramente possível numa situação de emergência.
Mas quando surgir um problema, a empresa deve ter a possibilidade de responder a perguntas básicas:
- Como funciona o sistema?
- De que é composto?
- Onde fica o ambiente de produção?
- Quem tem acesso?
- Quais são as integrações críticas?
- Quais contas e serviços externos são utilizados?
- Quais são as dependências?
- Como são feitos os backups?
- Como é o processo de implantação?
- O que acontece durante uma falha?
- Quais elementos são críticos para o negócio?
- Por que foram tomadas as principais decisões arquitetônicas?
- Quem pode assumir a manutenção do sistema?
Isso não precisa significar centenas de páginas de documentação.
Uma boa documentação deve ser прежде de tudo útil, atualizada e acessível às pessoas certas.
"Melhor não mexer, porque funciona" nem sempre é uma má decisão
Há mais um problema muito comum.
O sistema funciona há anos, então a empresa adota o princípio: "Não mexemos. Funciona."
E às vezes isso é absolutamente sensato.
Nem toda tecnologia antiga precisa ser substituída imediatamente. Nem todo trecho de código antigo precisa ser reescrito. Nem toda biblioteca significa uma catástrofe. Nem toda arquitetura de alguns anos atrás está errada.
O problema começa quando "não mexer" também significa:
- "Não vamos analisar."
- "Não vamos documentar."
- "Não vamos verificar as dependências."
- "Não vamos perguntar quem tem acesso."
- "Não vamos verificar se ainda temos todas as contas."
- "Não vamos definir o que acontecerá quando o atual prestador deixar de estar disponível."
Nesse caso, a ausência de mudanças não é uma estratégia.
É apenas adiar o risco.
Às vezes, a melhor decisão técnica é realmente não reconstruir nada.
Mas essa decisão deve resultar do conhecimento sobre o sistema, e não da falta de conhecimento sobre o sistema.
O que deve incluir uma auditoria de um sistema herdado?
Quando uma empresa assume um sistema de outro software house, freelancer ou equipe interna, o primeiro passo não deve ser reescrever tudo automaticamente.
Primeiro é preciso entender o que, de fato, foi assumido.
A auditoria deve responder pelo menos a algumas áreas básicas.
Arquitetura. Como o sistema é construído? Quais são seus principais componentes? Onde os dados estão localizados? Como os elementos se comunicam entre si?
Código e repositórios. A empresa possui o código-fonte completo? Sabe-se qual branch e qual versão estão em produção? O processo de build e implantação pode ser reproduzido?
Infraestrutura. Onde roda a produção? Como é o ambiente de testes? Quem tem acesso? Como são o monitoramento e o backup?
Integrações. Com o que o sistema se comunica? Quais APIs utiliza? Quem é o proprietário de cada conta e chave?
Dependências. Quais bibliotecas, frameworks e componentes externos são utilizados? Estão atualizados? Têm problemas de segurança conhecidos? Como é o seu ciclo de vida?
Processo de implantação. Uma nova pessoa consegue preparar, testar e implantar uma alteração sem ligar para o antigo programador?
Conhecimento. O que está na documentação e o que ainda existe apenas na cabeça das pessoas?
Risco de negócio. O que acontece se um determinado componente parar de funcionar por uma hora, um dia ou uma semana?
A abordagem moderna à segurança da cadeia de fornecimento de software enfatiza cada vez mais justamente a necessidade de conhecimento sobre componentes, fornecedores, dependências, sua origem e seu ciclo de vida. O NIST também destaca a importância da due diligence em relação aos fornecedores de tecnologia e da avaliação da resiliência e do risco associados a toda a cadeia de fornecimento.
Auditoria não significa "vamos reescrever o sistema do zero"
Isso é importante, porque uma auditoria técnica muitas vezes é equivocadamente confundida com uma reconstrução.
Enquanto isso, a auditoria pode terminar com uma conclusão muito simples: "O sistema está em ordem. Só precisamos organizar o conhecimento e eliminar alguns riscos."
Também pode acontecer de o sistema precisar de modernização apenas em uma área.
Ou de o maior problema não ser o código, mas a falta de acesso à infraestrutura.
Ou de a aplicação estar bem escrita, mas ninguém ter conhecimento atualizado sobre o processo de implantação.
Ou de tudo funcionar, mas a empresa depender de um único fornecedor externo.
Por isso, uma boa análise de um projeto herdado deve responder à pergunta: "O que realmente precisa ser mudado e o que não precisa ser mexido?"
Só então é possível tomar decisões de investimento.
E se você mudar de software house?
Esse é um dos momentos em que o problema da dívida de conhecimento invisível vem à tona.
A empresa encerra a parceria com o prestador.
O novo parceiro recebe o repositório.
E começa a fazer perguntas:
- "Onde está a produção?"
- "Como executar o projeto localmente?"
- "Qual versão está atual?"
- "Para que serve este serviço?"
- "Quem possui a conta desta API?"
- "O que faz este cron?"
- "Por que esse processo é executado a essa hora?"
- "De onde vem esse parâmetro?"
- "O que acontece se o desativarmos?"
Se a resposta para a maioria das perguntas for "não sabemos", o novo software house não está assumindo o projeto. Antes, precisa descobri-lo.
E descobrir o sistema custa tempo. Tempo que depois é pago pelo cliente.
Por isso, a passagem do projeto entre equipes deve ser um processo, e não simplesmente um ZIP com o código e a senha de uma conta.
O sistema deve sobreviver às pessoas
Essa é provavelmente a regra mais importante.
As pessoas mudam. Os programadores trocam de emprego. Os freelancers encerram a colaboração. Os software houses mudam de clientes. Os administradores vão para outras empresas. As diretorias mudam.
O sistema permanece.
Por isso, o sistema deve ser projetado de forma que o conhecimento necessário para sua manutenção possa ser recuperado.
Isso não significa que cada funcionário precise saber tudo.
Significa que a organização deve ter um mecanismo de armazenamento do conhecimento:
- Repositórios.
- Documentação.
- Registro de integrações.
- Informações sobre a infraestrutura.
- Acessos gerenciados pela empresa.
- Descrição dos processos principais.
- Histórico das decisões importantes.
- Informações sobre dependências.
- Procedimentos de emergência.
- E, acima de tudo, pessoas que saibam usar essa documentação.
O NIST, nas diretrizes atuais sobre planejamento de segurança de sistemas, também chama a atenção para a definição formal das responsabilidades, do status operacional do sistema e dos papéis das pessoas que o administram, dão suporte a ele ou têm acesso a ele.
Isso mostra uma mudança mais ampla na forma de pensar sobre tecnologia.
Sistema não é apenas código. Sistema também são pessoas, processos, infraestrutura, dependências, dados, acesso e responsabilidade.
Na Web24, muitas vezes começamos justamente com a pergunta: "O que temos aqui, afinal?"
Assumir um projeto existente não deve começar com a promessa de que tudo será reescrito do zero.
Deve começar com a compreensão da situação:
- O que funciona?
- O que não funciona?
- O que é crítico?
- O que está obsoleto?
- Onde estão os maiores riscos?
- O que falta na documentação?
- Que dependências não são visíveis?
- É possível desenvolver o sistema existente com segurança?
- É necessária modernização ou apenas organização?
Só depois é que se pode decidir se o projeto deve ser desenvolvido, reconstruído, parcialmente reescrito ou simplesmente bem documentado.
Isto é especialmente importante em projetos que, ao longo dos anos, foram desenvolvidos por pessoas e empresas diferentes.
Porque um bom parceiro tecnológico não deve ser necessário apenas porque só ele sabe como o sistema funciona.
Deve ser necessário porque sabe desenvolver este sistema, protegê-lo e transmitir o conhecimento adiante.
O erro mais perigoso pode ser a pessoa que já saiu
Nem sempre o problema é o código antigo.
Nem sempre o problema é a tecnologia obsoleta.
Nem sempre o problema é a falta da framework mais recente.
Às vezes, o maior risco é a informação que ninguém escreveu.
Uma palavra-chave.
Uma decisão de arquitetura.
Uma integração.
Uma exceção no processo.
Uma pessoa que, durante anos, sabia como aquilo funcionava.
E depois saiu.
Por isso, hoje vale a pena fazer a si mesmo uma pergunta muito simples: Se amanhã desaparecesse da empresa a pessoa que melhor conhece o vosso sistema, ainda conseguiriam geri-lo?
Se a resposta for "sim" - ótimo.
Se for "não sei" - vale a pena verificar.
E se for "definitivamente não" - provavelmente acabaram de identificar uma das áreas mais importantes de risco tecnológico na vossa empresa.
O sistema deve ser maior do que a memória de uma única pessoa.
