Como Desenhar O It

Um guia prático para desenhar diagramas de TI que realmente funcionam

Você já tentou explicar uma arquitetura de rede para um gerente que só quer saber se o servidor vai cair no próximo fim de semana? Eu passei seis anos acompanhando projetos de infraestrutura e aprendi que a maioria dos diagramas técnicos que vejo são incompletos demais para serem úteis ou tão detalhados que ninguém os lê. A diferença entre um rascunho que você guarda na gaveta e um documento que as pessoas realmente consultam é menor do que parece. O primeiro erro que eu cometi foi usar ferramentas muito pesadas para tarefas simples. Em 2018, fui contratar um consultor para redesenha o data center de uma empresa em São Paulo. Ele trouxe modelos Three.js impressionantes, interativos, com luzes e sombras. Perguntei qual era o servidor de banco de dados principal e ele não conseguia encontrar em trinta segundos. No final, usamos papel quadriculado porque funcionava melhor. Desde então, começo todo diagrama novo no menor denominador comum possível. Para criar um desenho técnico de TI, você precisa entender primeiro o que está representando. Não existe formato universal, mas existe um fluxo de trabalho que evita retrabalho. Anotação dos ativos, mapeamento de conexões, validação com a equipe operacional, e só depois escolha da ferramenta. Pule qualquer um desses passos e vai se arrepender quando precisar atualizar o diagrama seis meses depois e não conseguir rastrear o que mudou.

ferramentas que eu recomendo e as que evito

Draw.io continua sendo minha escolha padrão para a maioria dos projetos. Exporta para SVG, PDF, e até integra com Confluence e Google Drive. Um colega meu descobriu que o Draw.io perde informações de layer ao importar de arquivos Visio antigos, então sempre faço uma verificação cruzada. Se você trabalha em ambiente Microsoft pesado, o Visio ainda tem certas bibliotecas de ícones que não existem em nenhuma outra ferramenta. Mas a curva de aprendizado é mais íngreme e o licenciamento incomoda em equipes grandes. Lucidchart melhora o Draw.io em colaboração em tempo real, mas cobra por usuário adicional e o export para formatos abertos gera artefatos às vezes. Eu já vi diagramas ficarem ilegíveis depois de migrar de uma ferramenta para outra porque as fontes e espaçamentos eram interpretados de forma diferente. Documentação técnica depende de consistência visual. Se cinco pessoas usam cinco ferramentas diferentes, cada atualização gera uma versão nova e ninguém sabe qual é a oficial. Diagrams.net desktop version mantém compatibilidade com XML mais antigo do que a versão web, então para arquivos muito grandes ou com muitos elementos aninhados, eu prefiro o desktop. Custa nada e roda offline. Ferramentas como Enterprise Architect ou Visio Enterprise Edition são poderosas demais para diagramas operacionais comuns. Você gasta mais tempo configurando do que desenhando, e o resultado final muitas vezes parece um produto de vendas em vez de um documento técnico.

erros comuns que eu vejo todo dia

O maior problema é desenhar tudo como se o sistema fosse perfeito. Em 2021, estava em um projeto de migração cloud para uma loja virtual. O diagrama mostrava dois load balancers em active-active, três bancos de dados replicados, cache em camadas, tudo lindo. Quando fomos validar com o time de operações, descobriram que um dos balanceadores nunca foi configurado para monitoring, um dos bancos estava em modo read-only há quatro meses, e o cache tinha memória insuficiente para o pico de Black Friday. Diagramas bonitos que escondem problemas reais são piores do que diagramas feios que mostram a verdade. Outro erro clássico é misturar camadas sem separar visualmente. Rede, aplicação, banco de dados, storage — cada uma dessas camadas precisa de cores ou caixas diferentes para que qualquer pessoa consiga identificar onde algo falhou. Eu já corri para uma emergência às três da manhã porque alguém tinha ligado um cabo de rede em uma porta que não existia no diagrama. O diagrama tinha sido atualizado uma vez, em 2019, e ninguém mais sabia que a rede física tinha mudado dois racks para o lado oposto do data center. Detalhamento excessivo é o terceiro problema. Mostrar cada switch, cada porta, cada cabo Cat6 parece completo, mas aumenta o tempo de manutenção em quatro vezes. Eu costumo mostrar apenas os equipamentos que importam para decisões técnicas. Roteadores de borda, switches de acesso, firewalls, servidores principais, storage arrays. Links de WAN e conexões de management são importantes, mas detalhar cada patch panel só cria ruído visual.

um caso específico que mudou minha abordagem

Em 2022, precisei desenhar a arquitetura de um sistema de pagamentos para uma fintech em Curitiba. O regulador ia auditar a documentação técnica no mês seguinte. Meu primeiro rascunho tinha vinte páginas. Revi com o CTO e ele pediu para resumir em três páginas no máximo. A solução foi criar um diagrama mestre de alta nível, com links para anexos técnicos. Página um mostra fluxos de dados entre clientes e servidores. Página dois detalha a topologia de rede por data center. Página três explica os controles de segurança e criptografia. Isso parece óbvio agora, mas na época eu resisti porque achava que menos informação significava menos profissionalismo. A auditação passou sems e o auditor elogiou a clareza. Aprendi que diagramas técnicos servem para comunicação, não para exibição de conhecimento. Se o leitor precisa de dez minutos para entender onde algo falha, você falhou em comunicar.

validação com a equipe operacional

Depois de terminar qualquer diagrama, leve para o pessoal que vive no sistema. Eles vão encontrar três erros em cinco minutos que você levou três horas para finalizar. Em um projeto de virtualização, mostrei o diagrama para o administrador de Linux e ele apontou que eu tinha colocado o NFS mount point no mesmo switch que o tráfego de produção. Estávamos usando VLANs separadas, então tecnicamente estava correto, mas visualmente parecia um risco de broadcast domain gigante. Adjustei e ganhamos confiança com a equipe. Diagramas que não são atualizados viram mentiras úteis. Eu recomendo agregar uma revisão trimestral obrigatória no processo de change management. Toda mudança de infraestrutura precisa atualizar o diagrama correspondente antes de ser marcada como concluída. Isso custa aproximadamente cinco minutos por change e evita duas horas de troubleshooting quando algo quebra e ninguém sabe onde está. Ferramentas modernas permitem versionamento de diagramas. Eu uso Git para controlar alterações em arquivos .drawio e mantenho histórico de mudanças por seis meses. Quando precisava rastrear quando uma VLAN foi adicionada em outubro, consegui recuperar o commit exato com a data, o autor, e a motivação. Isso economizou uma reunião de quatro horas com o time de segurança que queria saber quem autorizou a mudança.

quando abandonar a ferramenta e voltar ao básico

Existe um momento em que qualquer software se torna obstáculo. Se você está explicando para cinco pessoas que nunca viram um diagrama técnico, começar no PowerPoint ou até em um caderno é mais rápido. Eu fiz isso em uma reunião com diretoria que precisava aprovar orçamento para upgrade de rede. O CEO pediu para ver onde o dinheiro ia entrar. Desenhei em quinze minutos num quadro branco fotografa do que levaria duas horas no Draw.io. Às vezes, a ferramenta mais simples é a correta. Eu desconfio de quem nunca usou lápis e papel. Ferramentas digitais são incríveis para documentação permanente, mas o pensamento técnico acontece antes do desenho. Eu esboço ideias no verso de um envelope ou num bloco de notas antes de abrir qualquer software. Isso me ajuda a decidir o que realmente importa mostrar antes de me perder em detalhes de formatação.

uma dica técnica que pouca gente conhece

A maioria das ferramentas permite exportar para formatos abertos, mas raramente as pessoas verificam se a exportação preserva todas as informações. Eu sempre abro o arquivo exportado em um leitor independente e verifico se textos, linhas, e conexões estão corretos. Já perdi duas horas tentando entender por que um diagrama importado em outra ferramenta tinha setas apontando para direções erradas. Era um bug de exportação em SVG que só aparecia com certos navegadores. Desde então, testo sempre em Chrome, Firefox, e Edge antes de considerar o arquivo pronto. Se você trabalha com múltiplas ferramentas, manter uma paleta de cores consistente entre elas reduz confusão em cinquenta por cento dos casos de erro humano. Eu uso vermelho para componentes críticos, verde para serviços saudáveis, amarelo para warnings, e cinza para elementos desativados ou legacy. Qualquer pessoa que entrar no projeto entende imediatamente o status sem precisar de legenda. Desenhar diagramas de TI é uma habilidade que melhora com prática, não com teoria. Comece simples, valide com quem usa o sistema, mantenha atualizado, e não tenha medo de apagar e começar de novo quando perceber que a primeira versão não comunicava o que você pensava. O melhor diagrama é aquele que ninguém precisa consultar porque todo mundo já sabe como o sistema funciona. Mas quando precisa, ele deve responder à pergunta certa em menos de trinta segundos.