Cómo documentar la arquitectura de tu servidor de MU Online

Un servidor de MU Online no es un solo programa, es un pequeño ecosistema de procesos que conversan entre sí. El ConnectServer recibe a los jugadores y los dirige; el GameServer corre el mundo del juego; el DataServer es el puente con la base de datos; el SQL Server guarda cuentas, personajes e ítems; y el sitio publica rankings y el área del jugador. Cada pieza escucha en puertos específicos, depende de otras para funcionar y tiene su propia forma de iniciar, detener y fallar. Mientras todo funciona, esa complejidad queda invisible. El problema aparece el día del incidente: el GameServer no arranca, y no recuerdas en qué puerto escucha el DataServer, ni qué componente depende de cuál, ni el orden correcto de reinicio. Documentar la arquitectura es justamente construir el mapa que vas a necesitar exactamente en ese momento, y que cualquier persona que asuma el servidor en el futuro también va a necesitar. Este tutorial muestra cómo mapear cada componente, registrar puertos y dependencias en tablas claras, escribir un runbook operativo que cualquier administrador consiga seguir y dibujar un diagrama de arquitectura legible. Los números de puerto y nombres de componente citados son ejemplos y varían según el emulador/versión; el método de documentar, no.

Por qué documentar vale el esfuerzo

La documentación de arquitectura parece burocracia hasta la primera vez que te salva. Las ganancias concretas:

• Respuesta a incidentes más rápida: con puertos y dependencias a la mano, el diagnóstico deja de ser adivinanza.
• Onboarding: un nuevo administrador entiende el servidor en horas, no en semanas.
• Continuidad: si necesitas ausentarte, el servidor no muere junto con tu conocimiento.
• Prevención de errores: al mapear dependencias, ves los puntos frágiles antes de que se vuelvan incidentes.
• Base para la automatización: los scripts de deploy y monitoreo nacen naturalmente de una arquitectura bien documentada.

La documentación es, en el fondo, la memoria externa del servidor. Y la memoria externa no olvida detalles a las tres de la mañana.

Prerrequisitos

• Acceso completo al servidor para inspeccionar procesos, puertos y archivos de configuración.
• Conocimiento de los componentes que componen tu servidor (o disposición para descubrirlos).
• Un lugar versionado para guardar la documentación, de preferencia un repositorio Git privado separado de la máquina del servidor.
• Una herramienta de diagrama: puede ser Mermaid (texto), draw.io, Excalidraw o similar, todas gratuitas.
• Editor de texto o Markdown para escribir las tablas y el runbook.

Si estás montando el servidor ahora, vale la pena documentar en paralelo a la construcción, siguiendo una guía de cómo crear un servidor de MU Online. Documentar durante el montaje es mucho más fácil que reconstruir el mapa después, de memoria.

Paso 1 — Inventariar los componentes

Empieza listando todo lo que compone el servidor. Para cada componente, registra: el nombre, la función, el ejecutable o servicio correspondiente, la carpeta donde vive y cómo se inicia. Un servidor de MU típico tiene esta columna vertebral:

Rellena la columna de ejecutable con los nombres reales de tu emulador: ellos varían según el emulador/versión. Algunos emuladores fusionan componentes, otros los dividen aún más (por ejemplo, separando un servidor de chat o de ranking). El objetivo aquí es no dejar ninguna pieza afuera: todo lo que necesita estar en pie para que el jugador entre debe constar en la lista.

Paso 2 — Mapear los puertos

Los puertos son el punto donde la documentación más rinde en la práctica. Cada componente escucha en uno o más puertos, y los conflictos o bloqueos de puerto están entre las causas más comunes de servidor caído. Arma una tabla dedicada.

Dos reglas de oro aquí. Primera: los componentes internos como DataServer y SQL Server nunca deben ser expuestos a internet. Si lo están, es una falla de seguridad grave: el firewall debe bloquearlos desde afuera. Segunda: documenta los puertos reales de tu servidor, verificándolos en vez de copiar valores de tutoriales. Para descubrir qué está escuchando, en Windows usa:

netstat -ano | findstr LISTENING

Cruza los PIDs retornados con el Administrador de Tareas para saber qué proceso abrió cada puerto. Los valores de la tabla de arriba son solo ejemplos comunes y varían según el emulador/versión y la configuración.

Paso 3 — Documentar las dependencias y el orden de inicio

Después de saber qué existe y dónde escucha, registra cómo las piezas dependen unas de otras. Esto define el orden de arranque y de parada, que es crítico: arrancar en el orden equivocado hace que los componentes fallen porque aquello que necesitan todavía no está listo.

La cadena de dependencia típica es:

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

Traducido en reglas operativas:

• Orden de arranque: SQL Server primero, luego DataServer, luego GameServer, por último ConnectServer. Los cimientos antes de lo que los jugadores tocan.
• Orden de parada: exactamente al revés: ConnectServer primero (cierra la puerta de entrada), luego GameServer, luego DataServer.
• Puntos de falla: si el SQL Server cae, todo cae detrás de él. Si el DataServer cae, el GameServer pierde la base de datos. Documenta esos efectos en cascada para no perder tiempo diagnosticando el síntoma cuando la causa está en la base.

Registra también las dependencias externas: el sitio depende del SQL Server; algún servicio de eventos puede depender de un horario sincronizado; el registro de nuevas cuentas puede pasar por la misma base de datos. Cada flecha en el diagrama de dependencias es una pista de diagnóstico futura.

Paso 4 — Escribir el runbook operativo

El runbook es el manual de operación, el "cómo hacer" que complementa el "qué es" del inventario y del diagrama. Debe ser tan claro que alguien bajo presión consiga seguirlo sin improvisar. Estructúralo por procedimiento.

Procedimiento: iniciar el servidor desde cero

1. Confirma que el servicio del SQL Server está en ejecución.
2. Inicia el DataServer y espera el mensaje de conexión con la base de datos.
3. Inicia el GameServer y confirma que se registró en el DataServer.
4. Inicia el ConnectServer y verifica que lista el GameServer.
5. Inicia los servicios auxiliares (eventos, join).
6. Levanta el sitio.
7. Haz un login de prueba con una cuenta reservada.

Procedimiento: detener el servidor con seguridad

1. Anuncia el mantenimiento a los jugadores.
2. Detén el ConnectServer para bloquear nuevos logins.
3. Espera algunos minutos para que los jugadores en línea salgan.
4. Detén el GameServer.
5. Detén el DataServer.
6. Solo entonces, si es necesario, detén el SQL Server.

Procedimiento: diagnóstico rápido cuando "el servidor cayó"

1. Verifica qué procesos están en pie (Get-Process).
2. Comprueba si los puertos esperados están escuchando (netstat).
3. Lee los logs de cada componente, empezando por la base (SQL → DataServer → GameServer).
4. Identifica el componente más "abajo" en la cadena que falló: la causa suele estar ahí.

Incluye en el runbook los caminos exactos de logs, las cuentas de prueba, los comandos de verificación y los contactos de a quién acudir en una emergencia. Un buen runbook responde preguntas antes de que necesites pensarlas.

Paso 5 — Dibujar el diagrama de arquitectura

El diagrama transforma las tablas en una imagen que se entiende de un vistazo. No necesitas una herramienta cara; un diagrama en texto con Mermaid funciona muy bien y además puede ser versionado junto con el resto de la documentación.

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

Lo que muestra un buen diagrama de arquitectura:

• Los componentes como cajas nombradas.
• Las conexiones entre ellos, idealmente anotadas con el puerto usado.
• La dirección del flujo (quién inicia la conexión con quién).
• La frontera de exposición: deja visualmente claro qué es público (cliente, sitio) y qué es interno (DataServer, SQL). Un rectángulo punteado alrededor de los componentes internos comunica esto bien.

Mantén el diagrama simple. El objetivo es la orientación rápida, no capturar cada detalle. Los detalles viven en las tablas; el diagrama da la visión de conjunto. Y, crucialmente, actualiza el diagrama siempre que la arquitectura cambie: un diagrama equivocado es peor que ninguno, porque induce a decisiones equivocadas.

Paso 6 — Guardar y mantener la documentación viva

La documentación no es un proyecto que termina; es un organismo que necesita acompañar al servidor.

• Guárdala en un lugar versionado y externo a la máquina del servidor, como un repositorio Git privado. Si la documentación vive solo dentro del servidor y este cae, pierdes el mapa justamente cuando más lo necesitas.
• Trata la actualización como parte del cambio: ¿abriste un puerto nuevo? Documéntalo en el mismo momento. ¿Agregaste un componente? Actualiza el inventario, la tabla de puertos y el diagrama antes de considerar la tarea concluida.
• Revisa periódicamente: marca una revisión trimestral para atrapar los desvíos que se escaparon.
• Dale al equipo acceso de lectura: una documentación que nadie encuentra no sirve para nada.

Una documentación viva vale por diez documentaciones perfectas que se congelaron en el tiempo. El criterio de calidad es simple: ¿alguien que nunca vio el servidor consigue, solo con esos documentos, entender la estructura y operarla con seguridad?

Errores comunes y soluciones

Lista de verificación de lanzamiento

• Inventario completo de componentes con función y ejecutable
• Tabla de puertos con protocolo y exposición (público vs interno)
• Puertos verificados con netstat, no copiados de tutoriales
• Componentes internos (DataServer, SQL) confirmados como no expuestos
• Cadena de dependencias documentada
• Orden de arranque y de parada registrado en el runbook
• Procedimientos de iniciar, detener y diagnosticar escritos paso a paso
• Caminos de logs y cuentas de prueba incluidos en el runbook
• Diagrama de arquitectura dibujado con los puertos anotados
• Frontera público/interno visible en el diagrama
• Documentación guardada en un repositorio versionado y externo
• Proceso definido para actualizar la doc en cada cambio

Documentar la arquitectura del servidor es una inversión cuyo retorno llega en el peor momento posible, y por eso es tan valiosa. Cuando el GameServer no arranca a las tres de la mañana, la diferencia entre resolver en cinco minutos y pasar la madrugada tanteando en la oscuridad es justamente tener, a la mano, el inventario de componentes, el mapa de puertos, la cadena de dependencias y un runbook que dice qué hacer. Empieza por el inventario, verifica los puertos de verdad, dibuja un diagrama simple y mantén todo vivo y versionado. Adapta cada puerto y nombre de componente a la realidad de tu emulador, porque esos detalles siempre varían según el emulador/versión.

Preguntas frecuentes