Como documentar a arquitetura do seu servidor de MU Online

Um servidor de MU Online não é um programa só — é um pequeno ecossistema de processos que conversam entre si. O ConnectServer recebe os jogadores e os direciona; o GameServer roda o mundo do jogo; o DataServer é a ponte com o banco de dados; o SQL Server guarda contas, personagens e itens; e o site publica rankings e a área do jogador. Cada peça escuta em portas específicas, depende de outras para funcionar e tem sua própria forma de iniciar, parar e falhar. Enquanto está tudo funcionando, essa complexidade fica invisível. O problema aparece no dia do incidente: o GameServer não sobe, e você não lembra em qual porta o DataServer escuta, nem qual componente depende de qual, nem a ordem certa de reinicialização. Documentar a arquitetura é justamente construir o mapa que você vai precisar exatamente nesse momento — e que qualquer pessoa que assuma o servidor no futuro também vai precisar. Este tutorial mostra como mapear cada componente, registrar portas e dependências em tabelas claras, escrever um runbook operacional que qualquer administrador consegue seguir e desenhar um diagrama de arquitetura legível. Os números de porta e nomes de componente citados são exemplos e variam por emulador/versão; o método de documentar, não.

Por que documentar vale o esforço

Documentação de arquitetura parece burocracia até a primeira vez que salva você. Os ganhos concretos:

• Resposta a incidentes mais rápida: com portas e dependências à mão, o diagnóstico deixa de ser adivinhação.
• Onboarding: um novo administrador entende o servidor em horas, não em semanas.
• Continuidade: se você precisar se afastar, o servidor não morre junto com o seu conhecimento.
• Prevenção de erros: ao mapear dependências, você enxerga pontos frágeis antes que virem incidentes.
• Base para automação: scripts de deploy e monitoramento nascem naturalmente de uma arquitetura bem documentada.

A documentação é, no fundo, a memória externa do servidor. E memória externa não esquece detalhes às três da manhã.

Pré-requisitos

• Acesso completo ao servidor para inspecionar processos, portas e arquivos de configuração.
• Conhecimento dos componentes que compõem o seu servidor (ou disposição para descobri-los).
• Um local versionado para guardar a documentação, de preferência um repositório Git privado separado da máquina do servidor.
• Uma ferramenta de diagrama: pode ser Mermaid (texto), draw.io, Excalidraw ou similar — todas gratuitas.
• Editor de texto ou Markdown para escrever as tabelas e o runbook.

Se você está montando o servidor agora, vale documentar em paralelo à construção, seguindo um guia de como criar servidor de MU Online. Documentar durante a montagem é muito mais fácil do que reconstruir o mapa depois, de memória.

Passo 1 — Inventariar os componentes

Comece listando tudo que compõe o servidor. Para cada componente, registre: o nome, a função, o executável ou serviço correspondente, a pasta onde vive e como ele é iniciado. Um servidor de MU típico tem esta espinha dorsal:

Preencha a coluna de executável com os nomes reais do seu emulador — eles variam por emulador/versão. Alguns emuladores fundem componentes, outros dividem ainda mais (por exemplo, separando um servidor de chat ou de ranking). O objetivo aqui é não deixar nenhuma peça de fora: tudo que precisa estar de pé para o jogador entrar deve constar na lista.

Passo 2 — Mapear as portas

Portas são o ponto onde a documentação mais paga na prática. Cada componente escuta em uma ou mais portas, e conflitos ou bloqueios de porta estão entre as causas mais comuns de servidor fora do ar. Monte uma tabela dedicada.

Duas regras de ouro aqui. Primeira: componentes internos como DataServer e SQL Server nunca devem ser expostos à internet. Se estiverem, é uma falha de segurança grave — o firewall deve bloqueá-los de fora. Segunda: documente as portas reais do seu servidor, verificando-as em vez de copiar valores de tutoriais. Para descobrir o que está escutando, no Windows use:

netstat -ano | findstr LISTENING

Cruze os PIDs retornados com o Gerenciador de Tarefas para saber qual processo abriu cada porta. Os valores da tabela acima são apenas exemplos comuns e variam por emulador/versão e por configuração.

Passo 3 — Documentar as dependências e a ordem de inicialização

Depois de saber o que existe e onde escuta, registre como as peças dependem umas das outras. Isso define a ordem de subida e de parada, que é crítica: subir na ordem errada faz componentes falharem porque aquilo de que precisam ainda não está pronto.

A cadeia de dependência típica é:

SQL Server  →  DataServer  →  GameServer  →  ConnectServer
                                   ↓
                          JoinServer / eventos

Traduzido em regras operacionais:

• Ordem de subida: SQL Server primeiro, depois DataServer, depois GameServer, por último ConnectServer. As fundações antes do que os jogadores tocam.
• Ordem de parada: exatamente o inverso — ConnectServer primeiro (fecha a porta de entrada), depois GameServer, depois DataServer.
• Pontos de falha: se o SQL Server cai, tudo cai atrás dele. Se o DataServer cai, o GameServer perde o banco. Documente esses efeitos em cascata para não perder tempo diagnosticando o sintoma quando a causa está na base.

Registre também dependências externas: o site depende do SQL Server; algum serviço de eventos pode depender de horário sincronizado; o registro de novas contas pode passar pelo mesmo banco. Cada seta no diagrama de dependências é uma pista de diagnóstico futura.

Passo 4 — Escrever o runbook operacional

O runbook é o manual de operação — o "como fazer" que complementa o "o que é" do inventário e do diagrama. Ele deve ser tão claro que alguém sob pressão consiga seguir sem improvisar. Estruture-o por procedimento.

Procedimento: iniciar o servidor do zero

1. Confirme que o serviço do SQL Server está em execução.
2. Inicie o DataServer e aguarde a mensagem de conexão com o banco.
3. Inicie o GameServer e confirme que ele se registrou no DataServer.
4. Inicie o ConnectServer e verifique que ele lista o GameServer.
5. Inicie os serviços auxiliares (eventos, join).
6. Suba o site.
7. Faça um login de teste com uma conta reservada.

Procedimento: parar o servidor com segurança

1. Anuncie a manutenção aos jogadores.
2. Pare o ConnectServer para bloquear novos logins.
3. Aguarde alguns minutos para os jogadores online saírem.
4. Pare o GameServer.
5. Pare o DataServer.
6. Só então, se necessário, pare o SQL Server.

Procedimento: diagnóstico rápido quando "o servidor caiu"

1. Verifique quais processos estão de pé (Get-Process).
2. Confira se as portas esperadas estão escutando (netstat).
3. Leia os logs de cada componente, começando pela base (SQL → DataServer → GameServer).
4. Identifique o componente mais "abaixo" na cadeia que falhou — a causa costuma estar ali.

Inclua no runbook os caminhos exatos de logs, as contas de teste, os comandos de verificação e os contatos de quem acionar em emergência. Um bom runbook responde perguntas antes que você precise pensar nelas.

Passo 5 — Desenhar o diagrama de arquitetura

O diagrama transforma tabelas em uma imagem que se entende num relance. Você não precisa de ferramenta cara; um diagrama em texto com Mermaid funciona muito bem e ainda pode ser versionado junto com o resto da documentação.

flowchart TD
    Jogador([Cliente do jogador]) -->|44405| CS[ConnectServer]
    Jogador -->|55901| GS[GameServer]
    CS -->|registro| GS
    GS -->|55960| DS[DataServer]
    DS -->|1433| SQL[(SQL Server)]
    Site[Site / Painel] -->|1433| SQL
    Jogador -->|80/443| Site

O que um bom diagrama de arquitetura mostra:

• Os componentes como caixas nomeadas.
• As conexões entre eles, idealmente anotadas com a porta usada.
• A direção do fluxo (quem inicia a conexão com quem).
• A fronteira de exposição: deixe visualmente claro o que é público (cliente, site) e o que é interno (DataServer, SQL). Um retângulo tracejado em volta dos componentes internos comunica isso bem.

Mantenha o diagrama simples. O objetivo é orientação rápida, não capturar cada detalhe. Detalhes vivem nas tabelas; o diagrama dá a visão de conjunto. E, crucialmente, atualize o diagrama sempre que a arquitetura mudar — um diagrama errado é pior que nenhum, porque induz a decisões equivocadas.

Passo 6 — Guardar e manter a documentação viva

Documentação não é um projeto que termina; é um organismo que precisa acompanhar o servidor.

• Guarde em local versionado e externo à máquina do servidor, como um repositório Git privado. Se a documentação vive só dentro do servidor e ele cai, você perde o mapa justamente quando mais precisa dele.
• Trate a atualização como parte da mudança: abriu uma porta nova? Documente no mesmo momento. Adicionou um componente? Atualize inventário, tabela de portas e diagrama antes de considerar a tarefa concluída.
• Revise periodicamente: marque uma revisão trimestral para pegar desvios que escaparam.
• Dê à equipe acesso de leitura: documentação que ninguém encontra não serve para nada.

Uma documentação viva vale por dez documentações perfeitas que congelaram no tempo. O critério de qualidade é simples: alguém que nunca viu o servidor consegue, só com esses documentos, entender a estrutura e operá-la com segurança?

Erros comuns e soluções

Checklist de lançamento

• Inventário completo de componentes com função e executável
• Tabela de portas com protocolo e exposição (público x interno)
• Portas verificadas com netstat, não copiadas de tutoriais
• Componentes internos (DataServer, SQL) confirmados como não expostos
• Cadeia de dependências documentada
• Ordem de subida e de parada registrada no runbook
• Procedimentos de iniciar, parar e diagnosticar escritos passo a passo
• Caminhos de logs e contas de teste incluídos no runbook
• Diagrama de arquitetura desenhado com portas anotadas
• Fronteira público/interno visível no diagrama
• Documentação guardada em repositório versionado e externo
• Processo definido para atualizar a doc a cada mudança

Documentar a arquitetura do servidor é um investimento cujo retorno chega no pior momento possível — e por isso é tão valioso. Quando o GameServer não sobe às três da manhã, a diferença entre resolver em cinco minutos e passar a madrugada tateando no escuro é justamente ter, à mão, o inventário de componentes, o mapa de portas, a cadeia de dependências e um runbook que diz o que fazer. Comece pelo inventário, verifique as portas de verdade, desenhe um diagrama simples e mantenha tudo vivo e versionado. Adapte cada porta e nome de componente à realidade do seu emulador, porque esses detalhes sempre variam por emulador/versão.

Perguntas frequentes