Ahora que el lanzamiento de Dragonflight ha quedado atrás, queremos aprovechar para hablar sobre lo ocurrido estos últimos días desde un punto de vista técnico. Esperamos que esto ayude a comprender mejor qué se necesita para realizar un lanzamiento mundial como este, qué puede salir bien, qué contratiempos pueden surgir y cómo los gestionamos.
Internamente, llamamos «lanzamiento de contenido» a eventos como los del pasado lunes, porque lanzar una nueva expansión es todo un proceso, que no se agota en un solo día. Lejos de ser un juego estático que funciona de la misma manera que lo hacía hace dieciocho o dos año, World of Warcraft cambia y se expande constantemente, al igual que nuestros procesos de lanzamiento.
Ahora, las expansiones constan de varios lanzamientos más pequeños: primero se implementa el código con el contenido antiguo, luego se activan los eventos previos al lanzamiento, así como los nuevos sistemas y, finalmente, el día del lanzamiento de la expansión, se activan las nuevas zonas, misiones y mazmorras. Cada fase cambia cosas diferentes para que podamos encontrar y solucionar problemas, pero, como en cualquier sistema grande y complejo, pueden surgir imprevistos.
Uno de los cambios de esta expansión consistió en que los nuevos contenidos se activan mediante un evento programado, es decir, que pueden activarse múltiples cambios en el juego para que se produzcan todos en un determinado momento. Hacer estos cambios de forma manual conlleva el riesgo de que se produzca un error humano o la propia herramienta se vea interrumpida de forma interna o externa; mientras que un evento programado ayuda a mitigar esos riesgos.
Otro cambio cambio que se ha incluido con Dragonflight es una mayor compatibilidad con el cifrado de los registros de datos del juego. Los registros cifrados nos permiten enviar a nuestro cliente los datos que el juego necesita para mostrar escenas, compartir líneas de voz o desbloquear misiones, pero evitan que esos datos sean extraídos antes de que los jugadores puedan experimentarlos en el juego. Sabemos que a la comunidad le encanta este juego y que desea experimentar todo lo que WoW le puede ofrecer sin que se lo destripen, y los registros cifrados nos permiten ocultar los momentos críticos de la historia hasta que los jugadores hayan alcanzado ese momento dentro del juego.
Ahora sabemos que los retardos y la inestabilidad que vimos la semana pasada se debían a la forma en que interactuaban estos dos sistemas. El resultado fue el siguiente: obligaron al servidor de simulación (que mueve a tu personaje por el mundo y ejecuta sus hechizos y facultades) a recalcular qué registros debían ocultarse más de cien veces por segundo con cada simulación. Como se gastaba una gran cantidad de la capacidad de la CPU en hacer estos cálculos, las simulaciones se atascaban, retrasando las peticiones de otros servicios a esos servidores de simulación. Los jugadores ven esto en forma de retardos y mensajes de error del tipo «El servidor del mundo está inactivo».
Como descubrimos, los registros encriptados que dependían de un evento programado dejaban al descubierto un pequeño error lógico en el código: una línea de código mal colocada indicaba al servidor que debía recalcular qué registros ocultar aunque nada hubiera cambiado.
Así es cómo se llevo a cabo la investigación. En primer lugar, el reloj marcaba las 00:00 CET. Sabíamos por las pruebas que el barco de la Horda llegaría primero y el de la Alianza después. Muchos de nosotros nos habíamos conectado al juego con nuestros personajes esperando en los muelles de ambas ubicaciones, a la par que monitorizábamos registros y gráficos de mando en otras ventanas. También estábamos conectados en una misma llamada con compañeros de nuestros equipos de apoyo de toda Blizzard.
Antes del lanzamiento, habíamos creado planes de contingencia para situaciones que nos preocupaban como resultado de nuestras pruebas. Por ejemplo, para este lanzamiento, nuestros diseñadores crearon portales que los jugadores podrían usar para llegar a las Islas Dragón en caso de que los barcos no funcionaran.
A las 00:02 el barco de la Horda llegó como estaba previsto y los jugadores subieron a bordo, incluidos algunos empleados de Blizzard. ¡Viva! Otros emplearon se quedaron atrás para esperar (y así ser sujetos de prueba en caso de que tuviéramos que activar los portales). El barco zarpó hacia las Islas Dragón, y aunque algunos jugadores lograron llegar, muchos se desconectaron o se quedaron atascados.
Empezamos inmediatamente a investigar los registros. Había algunos jugadores en las Islas Dragón, pero no muchos. Los compañeros con problemas informaron dando como ejemplo sus personajes y servidores. Otros empezaron a informar de picos en la carga de la CPU y del NFS (el almacenamiento conectado en red) que utilizaban nuestros servidores. Mientras tanto, otros observaban el juego e informaban de lo que veían.
Ahora que el barco de la Horda había partido, volcamos nuestra atención a la llegada del barco de la Alianza. La mayoría no llegaron, y la mayoría de barcos de la Horda no parecían regresar.
De repente nos dimos cuenta: los barcos están atascados y los servidores de las Islas Dragón no funcionan como esperábamos. Es en este punto donde nos ponemos manos a la obra a solucionar el problema.[Text Wrapping Break][Text Wrapping Break]Los barcos ya nos habían dado problemas en el pasado, así que activamos los portales mientras seguíamos investigando. Nuestro NFS estaba claramente sobrecargado. Había una gran cola de red en el servicio responsable de coordinar los servidores de simulación, lo que le hacía pensar que las simulaciones no se iniciaban, así que lanzaba más hasta saturar nuestro hardware. Pronto descubrimos que activar los portales empeoraba esa carga, porque los jugadores podían hacer clic en los portales tantas veces como quisiera, por lo que tuvimos que desactivarlos.
Mientras los problemas persistían, trabajábamos en hacer frente al aumento de la carga y conseguir que el mayor número de jugadores pudiera jugar, pero el servicio no funcionaba como durante las pruebas previas al lanzamiento. Continuamos buscando soluciones y descartando cosas que sabíamos que no eran el problema basándonos en esas pruebas.
A pesar de que pasaban las horas, muchos miembros el equipo seguían trabajando mientras que otros se iban a descansar para volver temprano al día siguiente y relevar al equipo que trabajaría durante la noche.
El martes por la mañana logramos entender mejor el problema. Sabíamos que estábamos enviando más mensajes a los clientes sobre las misiones de lo que era habitual, aunque descubrimientos posteriores revelarían que esto no era la causa de los problemas. Una nueva API de almacenamiento que estábamos utilizando estaba afectando a nuestro almacenamiento de archivos más de lo habitual. Este servicio estaba tardando demasiado en enviar a los clientes todos los cambios de datos realizados en las revisiones, mientras que seguían llegando informes de los jugadores que experimentaban un enorme retardo al llegar a las Islas Dragón.
A mediados del martes se produce una coincidencia. Mientras se profundiza en el nuevo código encontramos problemas en el nuevo sistema de encriptado, lo que nos hace cuestionarnos el problema desde una nueva perspectiva: ¿podría la lentitud del sistema de encriptación explicar todos estos problemas? Resultaba que sí. La lentitud del sistema de cifrado explicaba los problemas de los cambios, el de almacenamiento de los archivos y el retardo que sufrían los jugadores. Una vez identificado el origen, el informático a cargo de esa parte del código pudo localizar el error y realizar la corrección necesaria.
Introducir una corrección en un código utilizado por tantos servicios no es tan fácil como pulsar un botón, e implica distribuir y activar nuevos binarios. Debíamos trasladar lentamente a los jugadores de las simulaciones antiguas a las nuevas para llevar a cabo la corrección. De hecho, en un momento dado intentamos trasladar a los jugadores demasiado deprisa e hicimos que otra parte del juego se resintiera. Algunos de los binarios afectados no podían corregirse sin reiniciar el servicio, que retrasamos hasta que hubiera el menor número de jugadores en línea para no interrumpir la experiencia de los que seguían conectados. El miércoles, la corrección se había implementado con éxito y la estabilidad de los servidores había mejorado notablemente.
Aunque costó cierto esfuerzo identificar el problema y solucionarlo, nuestro equipo estuvo increíblemente atento a la hora de investigar el problema y corregirlo lo antes posible. Una buena ingeniería de sistemas no consiste en no cometer errores nunca, sino en minimizar las posibilidades de cometerlos, detectarlos rápidamente y disponer de las herramientas para corregirlos de inmediato…
Y contar con un equipo increíble para hacerlo posible.[Text Wrapping Break]
El equipo de ingeniería de World of Warcraft