Como documentar um runbook de operação do servidor de MU
Aprenda a escrever um runbook de operação do servidor de MU Online que qualquer pessoa da equipe consiga seguir sob pressão, com estrutura, procedimentos passo a passo e um modelo pronto para adaptar.
Todo servidor de MU Online eventualmente cai às 3h da manhã, trava no meio de um Castle Siege, ou corrompe um dado depois de uma atualização. Nessas horas, a diferença entre um soluço de 10 minutos e um desastre de 6 horas não é o quanto você sabe — é o quão rápido a informação certa chega às mãos d
Todo servidor de MU Online eventualmente cai às 3h da manhã, trava no meio de um Castle Siege, ou corrompe um dado depois de uma atualização. Nessas horas, a diferença entre um soluço de 10 minutos e um desastre de 6 horas não é o quanto você sabe — é o quão rápido a informação certa chega às mãos de quem está na frente do teclado, que muitas vezes não é você. Um runbook é o documento que carrega esse conhecimento operacional para fora da sua cabeça: procedimentos diretos, testados, que alguém competente consegue seguir sob pressão sem te ligar. Este tutorial mostra como estruturar, escrever e manter um runbook de operação para servidor de MU, com um modelo pronto para adaptar. Os nomes de serviço, caminhos e horários usados são exemplo e variam por provedor/versão do seu emulador e da sua infraestrutura.
Pré-requisitos
Documentar a operação pressupõe que exista operação para documentar — ou seja, um servidor funcionando cujos procedimentos você já executa, ainda que na base da memória. Se o servidor ainda não existe, monte primeiro seguindo como criar um servidor de MU Online e volte para documentá-lo. Para escrever um bom runbook você precisa de:
- Conhecimento prático da operação atual: como você reinicia, faz backup, aplica evento, restaura um dado. O runbook formaliza o que você já faz, então você precisa fazer bem antes de documentar.
- Um lugar acessível de fora do servidor para guardar o documento: repositório Git, wiki, documento na nuvem. Se o runbook só existe dentro do VPS e o VPS cai, você ficou sem runbook justo na hora que mais precisa.
- Acesso aos dados de contato e credenciais que os procedimentos vão referenciar — sem colocar senhas no runbook (isso vai para um cofre à parte).
- Disposição para testar cada procedimento depois de escrever. Um passo que você "acha que funciona" não pode entrar no runbook.
O que um runbook de MU precisa cobrir
Um runbook não é uma redação livre; é uma estrutura previsível. Alguém em pânico precisa achar o procedimento em segundos. A tabela abaixo mostra as seções essenciais de um runbook de servidor de MU e o que cada uma responde. A divisão exata é exemplo e varia por provedor/versão e pelo tamanho da sua equipe.
| Seção | Pergunta que responde | Prioridade |
|---|---|---|
| Visão geral e arquitetura | Do que o servidor é feito e onde cada peça mora | Alta |
| Contatos e responsabilidades | Quem avisar e quem decide o quê | Alta |
| Procedimentos de rotina | Como reiniciar, subir, derrubar, fazer backup | Crítica |
| Resposta a incidentes | O que fazer quando algo quebra | Crítica |
| Manutenção programada | Como aplicar atualização, evento, migração | Média |
| Monitoramento e alertas | Como saber que algo está errado | Alta |
| Recuperação | Como restaurar de backup, plano de DR | Crítica |
| Referência rápida | Portas, caminhos, comandos, credenciais (onde estão) | Alta |
O erro mais comum é começar pela "Visão geral" e nunca chegar aos procedimentos. Inverta: escreva primeiro os procedimentos de rotina e de incidente, que são os que salvam o servidor. A visão geral pode vir depois.
Passo 1 — Definir o cabeçalho e a metainformação
Todo runbook começa com informação sobre ele mesmo. Isso não é burocracia: é o que permite confiar (ou desconfiar) do conteúdo. No topo do documento:
# Runbook de Operação — Servidor ViciadosMU
- **Versão:** 3.2
- **Última revisão:** 2026-07-09
- **Responsável pelo documento:** Gabriel
- **Ambiente:** Produção (VPS Windows Server, exemplo)
- **Emulador/Season:** (informe aqui — varia por provedor/versão)
> Este documento é operacional. Cada procedimento tem gatilho,
> passos numerados e resultado esperado. Segredos NÃO ficam aqui.A data da última revisão é o campo mais importante do runbook inteiro. Um procedimento de dois anos atrás pode estar perigosamente errado, e a data avisa o leitor para checar antes de confiar cegamente.
Passo 2 — Mapear a arquitetura em uma página
Antes dos procedimentos, quem lê precisa saber do que o servidor é feito. Não escreva um tratado — um mapa de uma página basta. Liste os componentes, onde rodam e de que dependem:
## Arquitetura (exemplo — varia por provedor/versão)
Componentes e ordem de inicialização:
1. Banco de dados (SQL Server) — porta 1433 — base de tudo
2. DataServer — depende do banco
3. ConnectServer — porta 44405 (exemplo) — lista de servidores
4. JoinServer — ponte entre Connect e Game
5. GameServer(s) — porta 55901 (exemplo) — o mundo do jogo
6. Site/Painel web — depende do banco
Caminhos:
- Servidor: D:\MuServer\
- Backups: D:\Backups\
- Scripts: D:\Scripts\
- Logs: D:\MuServer\*\Logs\Um diagrama simples em texto já ajuda muito quem nunca viu a estrutura. O detalhe crítico aqui é a ordem de inicialização: quem sobe os componentes fora de ordem gera erros de conexão difíceis de diagnosticar.
Passo 3 — Escrever os procedimentos de rotina
Esta é a alma do runbook. Cada procedimento segue o mesmo formato: título com o gatilho, passos numerados, resultado esperado. Exemplo de um procedimento de reinício:
### PROC-01 — Reiniciar o GameServer
**Quando usar:** GameServer travado, lag geral, uso de memória alto,
ou reinício programado.
**Impacto:** todos os jogadores caem por ~1-2 minutos. Evite durante
eventos (Castle Siege, invasões).
**Passos:**
1. Avise no Discord/chat que haverá reinício em X minutos.
2. Conecte no VPS via RDP.
3. Abra a pasta D:\MuServer\GameServer\
4. Feche a janela do GameServer (ou rode Stop-Process).
5. Aguarde 5 segundos.
6. Execute GameServer.exe (ou rode D:\Scripts\ReiniciarGameServer.ps1).
7. Confirme no console que o servidor carregou os mapas sem erro.
**Resultado esperado:** GameServer online, jogadores conseguem logar,
console sem mensagens de erro em vermelho.
**Se falhar:** ver PROC-08 (GameServer não sobe).Repare no que faz esse procedimento funcionar sob pressão: o quando usar deixa claro o gatilho, o impacto evita que alguém reinicie no meio de um Castle Siege, os passos numerados não deixam dúvida, e o se falhar encadeia para o procedimento de recuperação. Escreva todos os procedimentos de rotina nesse formato: subir tudo, derrubar tudo, backup manual, aplicar evento, adicionar item, criar conta GM.
Passo 4 — Escrever os procedimentos de incidente
Incidentes são procedimentos de rotina de cabeça para baixo: em vez de "quero reiniciar", é "algo quebrou, o que faço?". A chave é começar pelo sintoma, porque é o que o operador observa. Exemplo:
### PROC-08 — GameServer não sobe / cai ao iniciar
**Sintoma:** GameServer fecha sozinho ao abrir, ou console mostra
erro de conexão com o banco/DataServer.
**Diagnóstico rápido (nesta ordem):**
1. O banco de dados está no ar? (checar serviço SQL Server)
2. O DataServer está rodando? (deve subir ANTES do GameServer)
3. As portas estão livres? (outro processo pode ter travado a porta)
4. Há espaço em disco? (disco cheio derruba tudo)
5. O log do GameServer aponta qual arquivo/conexão falhou?
**Ações por causa:**
- Banco fora → subir SQL Server, depois PROC-02 (subir tudo)
- DataServer fora → subir DataServer, aguardar, subir GameServer
- Porta travada → identificar PID com netstat, encerrar processo
- Disco cheio → PROC-11 (limpeza de emergência de logs)
**Escalar para:** o admin responsável, se após 15 min não resolver.O procedimento de incidente bom transforma pânico em checklist. Em vez de "não sobe, e agora?", o operador segue o diagnóstico rápido na ordem e chega à causa. Documente os incidentes que já aconteceram com você — esses são os mais valiosos, porque vão acontecer de novo.
Passo 5 — Referência rápida e contatos
Feche o runbook com a informação de consulta constante: portas, caminhos, comandos frequentes, e a cadeia de contatos. Aqui, sim, cabe uma tabela compacta:
## Referência rápida (exemplo — varia por provedor/versão)
| Componente | Porta | Caminho |
|----------------|--------|--------------------------------|
| SQL Server | 1433 | (serviço do Windows) |
| ConnectServer | 44405 | D:\MuServer\ConnectServer\ |
| GameServer | 55901 | D:\MuServer\GameServer\ |
## Contatos e escalonamento
1. GM de plantão — resolve rotina e incidentes leves
2. Admin técnico (Gabriel) — incidentes de infraestrutura
3. Dono do projeto — decisões de negócio (rollback, manutenção longa)
## Onde estão os segredos
- Senhas e chaves: gerenciador de senhas da equipe (NÃO aqui)
- Acesso ao VPS: cofre X, entrada "VPS Producao"A cadeia de escalonamento evita o pior cenário de incidente: todo mundo achando que outra pessoa está cuidando, e ninguém cuidando. Deixe claro quem faz o quê e a partir de que ponto se sobe o nível.
Como testar se o runbook realmente funciona
Um runbook não testado é ficção. O teste é simples e implacável: peça a alguém da equipe que nunca executou aquele procedimento para segui-lo, sozinho, seguindo apenas o texto, enquanto você observa em silêncio. Toda vez que a pessoa hesitar, perguntar ou errar, você achou um buraco no runbook. Anote e corrija. Faça isso pelo menos com os procedimentos críticos: reiniciar, subir tudo, restaurar backup.
O segundo teste é o do incidente real. Da próxima vez que algo quebrar, resista à tentação de resolver de cabeça: abra o runbook e siga o procedimento. Se ele te levou à solução, ótimo. Se não, você acabou de descobrir o que falta documentar — corrija ainda com o incidente fresco na memória.
Erros comuns e soluções
| Erro na documentação | Consequência na hora do aperto | Correção |
|---|---|---|
| Runbook só dentro do VPS | Some junto com o servidor quando ele cai | Guardar fora: wiki, Git, nuvem |
| Passos vagos ("reinicie o servidor") | Operador não sabe qual componente nem como | Passos numerados, específicos, com caminho |
| Sem data de revisão | Ninguém sabe se o procedimento ainda vale | Data de revisão no topo, atualizada |
| Segredos escritos no documento | Vazamento ao compartilhar/versionar | Referenciar cofre, nunca colar senha |
| Só teoria, nenhum procedimento | Bonito de ler, inútil sob pressão | Priorizar procedimentos de ação |
| Nunca testado | Passos que não funcionam na prática | Testar com alguém que não conhece |
| Sem cadeia de escalonamento | Ninguém sabe a quem recorrer | Definir contatos e quando escalar |
| Documento monolítico sem índice | Impossível achar nada rápido | Numerar procedimentos, índice no topo |
O erro de guardar o runbook só dentro do servidor é traiçoeiro porque só se manifesta no pior momento possível: o servidor caiu, e com ele o documento que te ensinaria a levantá-lo. Redundância aqui não é luxo, é o mínimo.
Checklist de lançamento
- Runbook guardado em local acessível de fora do servidor
- Cabeçalho com versão, data de revisão e responsável preenchido
- Arquitetura mapeada em uma página, com ordem de inicialização
- Procedimentos de rotina escritos (subir, derrubar, reiniciar, backup)
- Procedimentos de incidente escritos, começando pelo sintoma
- Cada procedimento com gatilho, passos numerados e resultado esperado
- Tabela de referência rápida (portas, caminhos, comandos)
- Cadeia de contatos e escalonamento definida
- Nenhum segredo escrito no documento; só referência ao cofre
- Procedimentos críticos testados por alguém que não os conhecia
- Índice numerado no topo para busca rápida
- Data de revisão combinada (ex.: revisão mensal dos procedimentos críticos)
- Equipe avisada de onde o runbook mora e como usá-lo
Com o runbook no lugar, o seu servidor de MU deixa de depender exclusivamente de você. A operação vira um processo que a equipe consegue seguir, os incidentes deixam de ser improviso e o conhecimento para de morrer na sua memória. É o documento que transforma um projeto de uma pessoa só num projeto que sobrevive à ausência de qualquer pessoa — inclusive a sua.
Perguntas frequentes
O que é um runbook e como ele difere de um manual de instalação?
Um runbook é o documento de operação do dia a dia: o que fazer quando o servidor cai, como reiniciar cada componente, como aplicar um evento, quem avisar em cada situação. O manual de instalação te ensina a montar o servidor uma vez; o runbook te ensina a mantê-lo vivo todos os dias. A diferença prática é o contexto de uso: o manual é lido com calma, o runbook é lido sob pressão, com jogadores reclamando. Por isso o runbook precisa ser direto, com passos numerados e sem enrolação.
Quem deve conseguir usar o meu runbook?
Idealmente, alguém competente que nunca montou aquele servidor específico. Esse é o teste real: se um GM de confiança consegue seguir o procedimento de reinício às 3h da manhã, sem te ligar, o runbook está bom. Se cada passo exige o conhecimento que só está na sua cabeça, ele está incompleto. Escreva para o seu substituto, não para você mesmo; você já sabe o que fazer, o runbook existe para quando você não estiver disponível.
Com que frequência devo atualizar o runbook?
Sempre que algo mudar na operação e sempre que um procedimento falhar na prática. Toda vez que você resolver um incidente novo, transforme a solução em procedimento antes de esquecer. Um runbook desatualizado é pior que nenhum, porque dá falsa confiança: alguém segue um passo que não vale mais e piora a situação. Coloque a data da última revisão no topo e reserve alguns minutos por mês para revisar os procedimentos críticos.
Preciso de uma ferramenta especial para manter o runbook?
Não. O que importa é o conteúdo e a disciplina de manter, não a ferramenta. Um arquivo Markdown num repositório, um documento compartilhado ou uma página de wiki resolvem. O importante é que esteja acessível de fora do servidor (se o VPS cair, você não pode depender de um runbook que só existe dentro dele), versionado de alguma forma e organizado para busca rápida. Comece simples; migre para algo mais robusto quando a equipe crescer.
O runbook não vai virar um documento gigante que ninguém lê?
Só vira se você misturar teoria com operação. O runbook é ação, não explicação: cada procedimento tem gatilho, passos numerados e resultado esperado. Explicações longas de por que as coisas são assim vão para outro documento. Mantenha cada procedimento curto o bastante para caber numa tela e use um índice no topo para navegação rápida. Um runbook bem estruturado é grande no total, mas cada consulta individual é curta.