Auditoria de arquitetura de sistemas: quando é precisa e o que encontra

·8 min de leitura

Uma auditoria de arquitetura não é uma opinião sobre a sua stack. É um mapa de onde o sistema parte sob o plano que realmente tem.

As revisões de arquitetura têm má fama porque muitas são exercícios de gosto — um consultor a explicar que teria escolhido de outra forma. Uma auditoria útil responde a uma pergunta mais estreita e muito mais valiosa: dado onde este negócio pretende estar daqui a dezoito meses, o que parte, quando, e quanto custa corrigir?

Sinais de que precisa de uma agora

  • O desempenho degrada-se de forma notória à medida que o uso cresce, e ninguém sabe dizer exatamente porquê
  • Os custos de infraestrutura sobem mais depressa do que a receita
  • Um componente falha e arrasta consigo funcionalidades sem relação
  • Entregar uma funcionalidade pequena obriga a mexer em muitas partes do sistema
  • Está prestes a multiplicar o tráfego por dez — um lançamento, uma parceria, uma ronda
  • Um investidor perguntou se a arquitetura escala, e a resposta honesta é que ninguém sabe

O que a auditoria examina

A camada de dados, primeiro e mais difícil

Na maioria dos sistemas a base de dados é o teto real, e é a coisa mais cara de mudar depois. O que importa: separação leitura/escrita, indexação face aos padrões reais de consulta, consultas sem limite que crescem com a tabela, se um único master de escrita é o limite, e se o esquema pode evoluir sem interrupção.

Isolamento de falhas

  • O que acontece quando uma dependência externa está lenta em vez de em baixo — timeouts e circuit breakers, ou esgotamento de threads em cascata
  • Se um tenant ou um cliente pesado consegue degradar o serviço para todos
  • Se as tarefas em segundo plano podem sufocar o caminho dos pedidos

Velocidade de mudança

Arquitetura não é só carga. Um sistema que não pode ser mudado com segurança está a falhar a sua função, mesmo que nunca caia. Procuramos acoplamento que force alterações em vários módulos, ausência de costuras para testar, e estado partilhado que torna impossível raciocinar localmente.

Adequação ao tamanho da equipa

Como deve ser o resultado

Mau resultado de auditoriaResultado útil
«Considerem microsserviços»«A tabela Orders atingirá saturação de escrita perto de 4× o volume atual; o sharding por tenant são ~3 semanas-engenheiro»
«A cobertura de testes é baixa»«A reconciliação de pagamentos não tem testes; uma regressão aqui é silenciosa e financeira»
«A dívida técnica é significativa»«Três itens bloqueiam o roadmap do Q4; o resto pode esperar e eis porquê»
Um relatório de 60 páginasUm resumo de uma página, uma lista ordenada e um plano sequenciado
O propósito de uma auditoria de arquitetura é converter uma ansiedade vaga sobre escalar num pequeno número de decisões datadas e orçamentadas.

Testar uma hipótese concreta de crescimento

Um diagrama não comprova limites reais. Relacione uma mudança de utilização com dependências, capacidade e recuperação.

  1. Seguir um pedido crítico por serviços, filas e armazenamento.
  2. Identificar falhas partilhadas e pressupostos de capacidade por verificar.
  3. Comparar mudanças delimitadas pelo impacto e custo de verificação.

Perguntas frequentes

Quanto tempo demora uma auditoria de arquitetura de sistemas?

Uma a três semanas para a maioria dos sistemas. O trabalho consiste em ler o código e a infraestrutura, examinar métricas reais de produção e padrões de consulta, e entrevistar os engenheiros. Trabalhos mais longos significam normalmente que o âmbito derrapou para a implementação.

Vão dizer-nos para reconstruir tudo?

Muito raramente, e desconfie de quem recomenda por defeito uma reconstrução. A maioria dos tetos de escala sobe com alterações dirigidas — um índice, uma fila, uma cache, uma chave de sharding — e não com uma nova arquitetura.

Precisamos de uma auditoria de arquitetura antes de uma ronda?

Vale a pena se os investidores fizerem due diligence técnica, o que é padrão a partir da Série A. Encontrar os problemas por conta própria é muito mais barato do que deixar a outra parte encontrá-los durante a negociação.

É sempre necessário um teste de carga?

Só perante uma questão material de capacidade ainda aberta e com âmbito acordado. A telemetria existente pode responder a parte das questões.

Preocupado com o que parte a 10×?

Mapeamos os tetos, orçamentamos as correções e sequenciamo-las — normalmente em menos de três semanas.

Revisão de arquitetura →

Leitura complementar

Dívida técnica em startups: quanta é demasiada?

Todas as startups têm dívida técnica, e a maior parte foi a decisão certa. A pergunta não é como eliminá-la — é que partes cobram juros que já não consegue pagar.

Auditoria técnica de MVP: o que verificamos nas primeiras 48 horas

A maioria das auditorias de MVP produz um documento. Uma útil produz decisões: o que está a arder, o que pode esperar e quanto custa corrigir.