Ahora que ha pasado un tiempo desde el lanzamiento de Dragonflight, queremos aprovechar esta oportunidad para contarles un poco más sobre qué ocurrió en estos últimos días desde un punto de vista de la ingeniería. Esperamos que así puedan entender más a fondo lo que se necesita para hacer realidad un lanzamiento global como este, lo que puede salir bien, los tropiezos que pueden ocurrir en el camino, y cómo los resolvemos.
Internamente, a los eventos como el del lunes pasado los llamamos “lanzamientos de contenido”, porque lanzar una expansión es un proceso, no algo de un solo día. World of Warcraft dista mucho de ser un juego estático que funciona de la misma forma que hace dieciocho años, o hace dos años. Es un juego que cambia y crece constantemente, y nuestro proceso de implementación muta de la misma forma.
Ahora las expansiones consisten en varios lanzamientos pequeños: el código primero se implementa sobre contenido viejo, luego se activan los eventos de prelanzamiento y los nuevos sistemas, y finalmente, el día del lanzamiento de contenido, se activan las nuevas áreas, misiones y calabozos. Cada fase cambia distintas cosas para que podamos detectar y solucionar los problemas. Sin embargo, como en cualquier sistema complejo y de gran tamaño, puede ocurrir imprevistos.
Un cambio de esta expansión fue que el lanzamiento de contenido se desencadenó con un evento programado: se pueden programar distintos cambios para que sucedan en el juego al mismo tiempo. Hacer estos cambios manualmente conlleva el riesgo del error humano, o de que una herramienta interna o externa no esté disponible. A través de un evento programado, podemos reducir estos riesgos.
Otro cambio en Dragonflight fue que mejoramos enormemente el cifrado de los registros de los datos del juego. Los registros cifrados nos permiten enviar el cliente con los datos que el juego necesita para reproducir escenas y líneas de voz o desbloquear misiones, pero de forma tal que no se puedan extraer los datos antes de que los jugadores puedan experimentarlos dentro del juego. Sabemos que la comunidad ama WoW, y que cuando uno está muy ansioso, a veces es difícil contenerse. Estos registros cifrados nos permiten esconder los momentos más importantes de la historia para que los jugadores solo los puedan ver cuando llega el momento indicado.
Sabemos que el lag y la inestabilidad que vimos la semana pasada fueron una consecuencia de la forma en que interactúan estos dos sistemas. El resultado fue que forzaron al servidor de simulación (que se encarga de mover a los personajes por el mundo y ejecutar hechizos y habilidades) a recalcular qué registros deberían esconderse más de cien veces por segundo, por simulación. Debido a que estos cálculos consumen una gran cantidad de los recursos de procesamiento, las simulaciones se ralentizaron, y las solicitudes de otros servicios para esas simulaciones quedaron en espera. Todo esto llegó a los jugadores en la forma de lag y del mensaje de error “El servidor del mundo está inactivo”.
Descubrimos que los registros cifrados exponían un pequeño error de lógica en el código hasta que cierto evento programado los desbloqueaba: una línea de código fuera de lugar indicaba al servidor que necesitaba recalcular qué registros esconder, aunque nada hubiera cambiado.
Así fue cómo se llevó a cabo la investigación. Primero, el reloj marcó las 3:00 p. m. PST. Gracias a nuestras pruebas, sabemos que los botes de la Horda llegan primero, y que los de la Alianza llegan después. Muchos estamos conectados al juego con nuestros personajes en los muelles de ambas ubicaciones en una misma ventana, y en otra ventana leemos registros, gráficos o mensajes. También estamos en una llamada con compañeros de los equipos de soporte de todo Blizzard.
Antes del lanzamiento, creamos planes de contingencia para las situaciones que creíamos que podían ocurrir según los resultados de nuestras pruebas. Por ejemplo, para este lanzamiento, nuestros diseñadores crearon portales que los jugadores podían usar para llegar a las Islas Dragón en caso de que los botes fallaran.
A las 3:02 p. m., los botes de la Horda llegaron en horario. ¡Viva! Los jugadores se suben, entre ellos algunos empleados de Blizzard. Otros empleados esperan (quieren ser casos de prueba por si es necesario activar los portales). Los jugadores a bordo de los botes zarpan, y si bien algunos llegan a las Islas Dragón, muchos se desconectan o quedan atascados.
Inmediatamente, empezamos a buscar registros o mensajes. Hay algunos jugadores en el mapa de las Islas Dragón, pero no muchos. Nuestros compañeros que están teniendo problemas nos informan los nombres de sus personajes y sus reinos como ejemplos específicos. Otros empiezan a informar de picos en la carga de la CPU y en el almacenamiento de archivos en red que usan nuestros servidores. Otros siguen observando la situación dentro del juego y nos informan lo que ven.
Ahora que hemos visto los botes de la Horda, empezamos a ver llegar a los de la Alianza. La mayoría nunca llegan, y la mayor parte de los de la Horda no regresan.
Entonces surge un panorama: los botes están atascados y los servidores de las Islas Dragón tardan mucho más de lo esperado en arrancar. Este es el momento en el que nos arremangamos y empezamos a resolver problemas.
Los botes han sido un problema en el pasado, así que activamos los portales mientras continuamos investigando. Nuestro almacenamiento de archivos en red está claramente saturado. Hay una larga fila de red en el servicio responsable de coordinar los servidores de simulación. Eso hace que piense que las simulaciones no están iniciando, por lo que lanza más y empieza a abrumar a nuestro hardware. Pronto descubrimos que cuando agregamos más portales, sobrecargamos todavía más el sistema porque los jugadores pueden hacer clic en los portales todas las veces que quieran, así que desactivamos los portales.
Los problemas persisten y empezamos a ocuparnos de la sobrecarga para que entren todos los jugadores que puedan, pero el servicio no funciona como en las pruebas prelanzamiento. Seguimos resolviendo problemas y vamos tachando las causas que descartamos a medida que hacemos pruebas.
A pesar de la hora, muchos continúan trabajando mientras que otros se retiran a descansar, para volver al temprano al día siguiente y relevar a los que trabajarán durante la noche.
Para el martes por la mañana, ya entendemos mejor el panorama. Sabemos que le estamos enviando al cliente más mensajes sobre misiones de lo normal, aunque más tarde descubriremos que esa no era la causa de los problemas. Una nueva API de almacenamiento de archivos está sobreexigiendo nuestro almacenamiento de archivos. Hay unas nuevas líneas de código que añadimos para que los personajes con misiones llamen a los jugadores que parecen funcionar más lento de lo que deberían. Este servicio está tomándose demasiado tiempo para enviarles a los clientes todos los cambios de datos aplicados en los hotfixes. Recibimos informes de que los jugadores que han llegado a las Islas Dragón están sufriendo un lag extremo.
A mitad de la mañana del martes, se produce una coincidencia: mientras investigábamos a fondo el nuevo código para llamar a los jugadores, encontramos hooks para el nuevo sistema de cifrado. Empezamos a analizar la pregunta desde otro punto de vista: ¿será que la lentitud del sistema de cifrado explica este problema y otros que estamos viendo? Y resulta ser que sí, así era. La lentitud del sistema de cifrado explica el problema de los hotfixes, el problema del almacenamiento de archivos, y el lag que los jugadores están sufriendo. Una vez que identificamos la fuente, el autor de la parte pertinente del sistema pudo identificar el error y realizar las correcciones necesarias.
Subir un arreglo del código que usan tantos servicios no es nada fácil, y es necesario subir y activar nuevos archivos binarios. Tenemos que trasladar a los jugadores de las simulaciones viejas a simulaciones nuevas lentamente para que la corrección surta efecto. De hecho, en un punto intentamos trasladarlos tan rápido que otra parte del servidor comenzó a funcionar mal. Algunos de los archivos binarios afectados no se pueden corregir sin reiniciar el servicio, lo que retrasamos hasta que hubiera la menor cantidad de jugadores conectados posible para no molestar a los jugadores que sí estaban dentro del juego. Para el miércoles, la corrección ya estaba implementada por completo y la estabilidad del servicio había aumentado drásticamente.
Si bien supuso un gran esfuerzo identificar el problema y arreglarlo, nuestro equipo se mantuvo atento en todo momento para investigar el error y arreglarlo lo más rápido posible. Una buena ingeniería de software no implica nunca cometer errores, sino minimizar las posibilidades de que surjan, encontrarlos rápidamente cuando ocurren, y disponer de las herramientas para arreglarlos cuanto antes…
… y contar con un equipo asombroso y unido para que todo esto pueda ser realidad.
El equipo de ingeniería de World of Warcraft