Cómo documentar un runbook de operación del servidor de MU
Aprende a escribir un runbook de operación del servidor de MU Online que cualquier persona del equipo pueda seguir bajo presión, con estructura, procedimientos paso a paso y una plantilla lista para adaptar.
Todo servidor de MU Online eventualmente se cae a las 3 de la mañana, se traba en medio de un Castle Siege o corrompe un dato después de una actualización. En esos momentos, la diferencia entre un tropiezo de 10 minutos y un desastre de 6 horas no es cuánto sabes, sino qué tan rápido llega la inform
Todo servidor de MU Online eventualmente se cae a las 3 de la mañana, se traba en medio de un Castle Siege o corrompe un dato después de una actualización. En esos momentos, la diferencia entre un tropiezo de 10 minutos y un desastre de 6 horas no es cuánto sabes, sino qué tan rápido llega la información correcta a las manos de quien está frente al teclado, que muchas veces no eres tú. Un runbook es el documento que saca ese conocimiento operativo de tu cabeza: procedimientos directos, probados, que alguien competente puede seguir bajo presión sin llamarte. Este tutorial muestra cómo estructurar, escribir y mantener un runbook de operación para servidor de MU, con una plantilla lista para adaptar. Los nombres de servicio, rutas y horarios usados son ejemplo y varían por proveedor/versión de tu emulador y de tu infraestructura.
Requisitos previos
Documentar la operación presupone que exista operación para documentar, es decir, un servidor funcionando cuyos procedimientos ya ejecutas, aunque sea de memoria. Si el servidor aún no existe, móntalo primero siguiendo cómo crear un servidor de MU Online y vuelve para documentarlo. Para escribir un buen runbook necesitas:
- Conocimiento práctico de la operación actual: cómo reinicias, haces backup, aplicas evento, restauras un dato. El runbook formaliza lo que ya haces, así que necesitas hacerlo bien antes de documentar.
- Un lugar accesible desde fuera del servidor para guardar el documento: repositorio Git, wiki, documento en la nube. Si el runbook solo existe dentro del VPS y el VPS se cae, te quedaste sin runbook justo cuando más lo necesitas.
- Acceso a los datos de contacto y credenciales que los procedimientos van a referenciar, sin poner contraseñas en el runbook (eso va a una bóveda aparte).
- Disposición para probar cada procedimiento después de escribirlo. Un paso que "crees que funciona" no puede entrar en el runbook.
Qué debe cubrir un runbook de MU
Un runbook no es una redacción libre; es una estructura predecible. Alguien en pánico necesita encontrar el procedimiento en segundos. La tabla siguiente muestra las secciones esenciales de un runbook de servidor de MU y lo que responde cada una. La división exacta es ejemplo y varía por proveedor/versión y por el tamaño de tu equipo.
| Sección | Pregunta que responde | Prioridad |
|---|---|---|
| Visión general y arquitectura | De qué está hecho el servidor y dónde vive cada pieza | Alta |
| Contactos y responsabilidades | A quién avisar y quién decide qué | Alta |
| Procedimientos de rutina | Cómo reiniciar, levantar, tumbar, hacer backup | Crítica |
| Respuesta a incidentes | Qué hacer cuando algo se rompe | Crítica |
| Mantenimiento programado | Cómo aplicar actualización, evento, migración | Media |
| Monitoreo y alertas | Cómo saber que algo está mal | Alta |
| Recuperación | Cómo restaurar desde backup, plan de DR | Crítica |
| Referencia rápida | Puertos, rutas, comandos, credenciales (dónde están) | Alta |
El error más común es empezar por la "Visión general" y nunca llegar a los procedimientos. Invierte el orden: escribe primero los procedimientos de rutina y de incidente, que son los que salvan el servidor. La visión general puede venir después.
Paso 1 — Definir el encabezado y la metainformación
Todo runbook comienza con información sobre sí mismo. Esto no es burocracia: es lo que permite confiar (o desconfiar) del contenido. En la parte superior del documento:
# Runbook de Operación — Servidor ViciadosMU
- **Versión:** 3.2
- **Última revisión:** 2026-07-09
- **Responsable del documento:** Gabriel
- **Entorno:** Producción (VPS Windows Server, ejemplo)
- **Emulador/Season:** (indica aquí — varía por proveedor/versión)
> Este documento es operativo. Cada procedimiento tiene disparador,
> pasos numerados y resultado esperado. Los secretos NO van aquí.La fecha de la última revisión es el campo más importante de todo el runbook. Un procedimiento de hace dos años puede estar peligrosamente equivocado, y la fecha avisa al lector para que verifique antes de confiar ciegamente.
Paso 2 — Mapear la arquitectura en una página
Antes de los procedimientos, quien lee necesita saber de qué está hecho el servidor. No escribas un tratado: un mapa de una página basta. Lista los componentes, dónde corren y de qué dependen:
## Arquitectura (ejemplo — varía por proveedor/versión)
Componentes y orden de inicialización:
1. Base de datos (SQL Server) — puerto 1433 — base de todo
2. DataServer — depende de la base de datos
3. ConnectServer — puerto 44405 (ejemplo) — lista de servidores
4. JoinServer — puente entre Connect y Game
5. GameServer(s) — puerto 55901 (ejemplo) — el mundo del juego
6. Sitio/Panel web — depende de la base de datos
Rutas:
- Servidor: D:\MuServer\
- Backups: D:\Backups\
- Scripts: D:\Scripts\
- Logs: D:\MuServer\*\Logs\Un diagrama simple en texto ya ayuda mucho a quien nunca vio la estructura. El detalle crítico aquí es el orden de inicialización: quien levanta los componentes fuera de orden genera errores de conexión difíciles de diagnosticar.
Paso 3 — Escribir los procedimientos de rutina
Esta es el alma del runbook. Cada procedimiento sigue el mismo formato: título con el disparador, pasos numerados, resultado esperado. Ejemplo de un procedimiento de reinicio:
### PROC-01 — Reiniciar el GameServer
**Cuándo usar:** GameServer trabado, lag general, uso de memoria alto,
o reinicio programado.
**Impacto:** todos los jugadores caen por ~1-2 minutos. Evita durante
eventos (Castle Siege, invasiones).
**Pasos:**
1. Avisa en Discord/chat que habrá reinicio en X minutos.
2. Conéctate al VPS vía RDP.
3. Abre la carpeta D:\MuServer\GameServer\
4. Cierra la ventana del GameServer (o ejecuta Stop-Process).
5. Espera 5 segundos.
6. Ejecuta GameServer.exe (o ejecuta D:\Scripts\ReiniciarGameServer.ps1).
7. Confirma en la consola que el servidor cargó los mapas sin error.
**Resultado esperado:** GameServer en línea, los jugadores logran loguear,
consola sin mensajes de error en rojo.
**Si falla:** ver PROC-08 (GameServer no levanta).Fíjate en lo que hace que este procedimiento funcione bajo presión: el cuándo usar deja claro el disparador, el impacto evita que alguien reinicie en medio de un Castle Siege, los pasos numerados no dejan lugar a dudas, y el si falla encadena hacia el procedimiento de recuperación. Escribe todos los procedimientos de rutina en ese formato: levantar todo, tumbar todo, backup manual, aplicar evento, agregar ítem, crear cuenta GM.
Paso 4 — Escribir los procedimientos de incidente
Los incidentes son procedimientos de rutina al revés: en lugar de "quiero reiniciar", es "algo se rompió, ¿qué hago?". La clave es empezar por el síntoma, porque es lo que el operador observa. Ejemplo:
### PROC-08 — GameServer no levanta / se cae al iniciar
**Síntoma:** GameServer se cierra solo al abrir, o la consola muestra
error de conexión con la base de datos/DataServer.
**Diagnóstico rápido (en este orden):**
1. ¿La base de datos está activa? (verificar servicio SQL Server)
2. ¿El DataServer está corriendo? (debe levantar ANTES del GameServer)
3. ¿Los puertos están libres? (otro proceso puede haber trabado el puerto)
4. ¿Hay espacio en disco? (disco lleno tumba todo)
5. ¿El log del GameServer indica qué archivo/conexión falló?
**Acciones por causa:**
- Base de datos caída → levantar SQL Server, luego PROC-02 (levantar todo)
- DataServer caído → levantar DataServer, esperar, levantar GameServer
- Puerto trabado → identificar PID con netstat, terminar el proceso
- Disco lleno → PROC-11 (limpieza de emergencia de logs)
**Escalar a:** el admin responsable, si tras 15 min no se resuelve.Un buen procedimiento de incidente transforma el pánico en checklist. En lugar de "no levanta, ¿y ahora?", el operador sigue el diagnóstico rápido en orden y llega a la causa. Documenta los incidentes que ya te ocurrieron: esos son los más valiosos, porque van a ocurrir de nuevo.
Paso 5 — Referencia rápida y contactos
Cierra el runbook con la información de consulta constante: puertos, rutas, comandos frecuentes y la cadena de contactos. Aquí sí cabe una tabla compacta:
## Referencia rápida (ejemplo — varía por proveedor/versión)
| Componente | Puerto | Ruta |
|----------------|--------|--------------------------------|
| SQL Server | 1433 | (servicio de Windows) |
| ConnectServer | 44405 | D:\MuServer\ConnectServer\ |
| GameServer | 55901 | D:\MuServer\GameServer\ |
## Contactos y escalamiento
1. GM de guardia — resuelve rutina e incidentes leves
2. Admin técnico (Gabriel) — incidentes de infraestructura
3. Dueño del proyecto — decisiones de negocio (rollback, mantenimiento largo)
## Dónde están los secretos
- Contraseñas y claves: gestor de contraseñas del equipo (NO aquí)
- Acceso al VPS: bóveda X, entrada "VPS Producao"La cadena de escalamiento evita el peor escenario de un incidente: todos pensando que otra persona se está encargando, y nadie encargándose. Deja claro quién hace qué y a partir de qué punto se sube el nivel.
Cómo probar si el runbook realmente funciona
Un runbook no probado es ficción. La prueba es simple e implacable: pídele a alguien del equipo que nunca ejecutó ese procedimiento que lo siga, solo, guiándose únicamente por el texto, mientras tú observas en silencio. Cada vez que la persona dude, pregunte o se equivoque, encontraste un agujero en el runbook. Anótalo y corrígelo. Haz esto al menos con los procedimientos críticos: reiniciar, levantar todo, restaurar backup.
La segunda prueba es la del incidente real. La próxima vez que algo se rompa, resiste la tentación de resolverlo de memoria: abre el runbook y sigue el procedimiento. Si te llevó a la solución, perfecto. Si no, acabas de descubrir qué falta documentar; corrígelo con el incidente todavía fresco en la memoria.
Errores comunes y soluciones
| Error en la documentación | Consecuencia en el momento del apuro | Corrección |
|---|---|---|
| Runbook solo dentro del VPS | Desaparece junto con el servidor cuando se cae | Guardarlo fuera: wiki, Git, nube |
| Pasos vagos ("reinicia el servidor") | El operador no sabe qué componente ni cómo | Pasos numerados, específicos, con ruta |
| Sin fecha de revisión | Nadie sabe si el procedimiento aún vale | Fecha de revisión arriba, actualizada |
| Secretos escritos en el documento | Fuga al compartir/versionar | Referenciar la bóveda, nunca pegar la contraseña |
| Solo teoría, ningún procedimiento | Bonito de leer, inútil bajo presión | Priorizar procedimientos de acción |
| Nunca probado | Pasos que no funcionan en la práctica | Probar con alguien que no lo conoce |
| Sin cadena de escalamiento | Nadie sabe a quién recurrir | Definir contactos y cuándo escalar |
| Documento monolítico sin índice | Imposible encontrar nada rápido | Numerar procedimientos, índice arriba |
El error de guardar el runbook solo dentro del servidor es traicionero porque solo se manifiesta en el peor momento posible: el servidor se cayó, y con él el documento que te enseñaría a levantarlo. La redundancia aquí no es lujo, es lo mínimo.
Lista de verificación de lanzamiento
- Runbook guardado en un lugar accesible desde fuera del servidor
- Encabezado con versión, fecha de revisión y responsable completado
- Arquitectura mapeada en una página, con orden de inicialización
- Procedimientos de rutina escritos (levantar, tumbar, reiniciar, backup)
- Procedimientos de incidente escritos, empezando por el síntoma
- Cada procedimiento con disparador, pasos numerados y resultado esperado
- Tabla de referencia rápida (puertos, rutas, comandos)
- Cadena de contactos y escalamiento definida
- Ningún secreto escrito en el documento; solo referencia a la bóveda
- Procedimientos críticos probados por alguien que no los conocía
- Índice numerado en la parte superior para búsqueda rápida
- Fecha de revisión acordada (ej.: revisión mensual de los procedimientos críticos)
- Equipo avisado de dónde vive el runbook y cómo usarlo
Con el runbook en su lugar, tu servidor de MU deja de depender exclusivamente de ti. La operación se convierte en un proceso que el equipo puede seguir, los incidentes dejan de ser improvisación y el conocimiento deja de morir en tu memoria. Es el documento que transforma un proyecto de una sola persona en un proyecto que sobrevive a la ausencia de cualquier persona, incluida la tuya.
Preguntas frecuentes
¿Qué es un runbook y en qué se diferencia de un manual de instalación?
Un runbook es el documento de operación del día a día: qué hacer cuando el servidor se cae, cómo reiniciar cada componente, cómo aplicar un evento, a quién avisar en cada situación. El manual de instalación te enseña a montar el servidor una vez; el runbook te enseña a mantenerlo vivo todos los días. La diferencia práctica es el contexto de uso: el manual se lee con calma, el runbook se lee bajo presión, con jugadores reclamando. Por eso el runbook necesita ser directo, con pasos numerados y sin rodeos.
¿Quién debería poder usar mi runbook?
Idealmente, alguien competente que nunca haya montado ese servidor específico. Esa es la prueba real: si un GM de confianza logra seguir el procedimiento de reinicio a las 3 de la mañana, sin llamarte, el runbook está bien. Si cada paso exige el conocimiento que solo está en tu cabeza, está incompleto. Escribe para tu sustituto, no para ti mismo; tú ya sabes qué hacer, el runbook existe para cuando tú no estés disponible.
¿Con qué frecuencia debo actualizar el runbook?
Siempre que algo cambie en la operación y siempre que un procedimiento falle en la práctica. Cada vez que resuelvas un incidente nuevo, conviértelo en procedimiento antes de olvidarlo. Un runbook desactualizado es peor que ninguno, porque da falsa confianza: alguien sigue un paso que ya no vale y empeora la situación. Coloca la fecha de la última revisión en la parte superior y reserva unos minutos por mes para revisar los procedimientos críticos.
¿Necesito una herramienta especial para mantener el runbook?
No. Lo que importa es el contenido y la disciplina de mantenerlo, no la herramienta. Un archivo Markdown en un repositorio, un documento compartido o una página de wiki resuelven. Lo importante es que esté accesible desde fuera del servidor (si el VPS se cae, no puedes depender de un runbook que solo existe dentro de él), versionado de alguna forma y organizado para búsqueda rápida. Empieza simple; migra a algo más robusto cuando el equipo crezca.
¿El runbook no se va a convertir en un documento gigante que nadie lee?
Solo se convierte en eso si mezclas teoría con operación. El runbook es acción, no explicación: cada procedimiento tiene disparador, pasos numerados y resultado esperado. Las explicaciones largas de por qué las cosas son así van a otro documento. Mantén cada procedimiento corto lo suficiente para caber en una pantalla y usa un índice en la parte superior para navegar rápido. Un runbook bien estructurado es grande en total, pero cada consulta individual es corta.