Siri
Hallo! Ich bin Robert Neckorcuk, Platform Team Lead bei ArenaNet, und heute darf ich euch von einem großangelegten, disziplinübergreifenden Einsatz berichten, der die Elite-Spezialisierungs-Beta von Guild Wars 2®: Visions of Eternity™ während des Release, der folgenden Probleme und schließlich der Lösung betreute. Beta-Events sind für gewöhnlich dazu da, dass die Entwicklerteams Feedback zu neuen Elementen, Fertigkeiten und Systemen erhalten; aber wie uns nun wieder klar geworden ist, sind diese Betas auch der erste Einsatz unter realen Bedingungen für neue Technologien, die verwendet werden, um neue Elemente, Fertigkeiten und Systeme zu erstellen. In diesem Beitrag erzähle ich euch vom holprigen Start dieses Beta-Events, und ich biete euch einen Blick hinter die Kulissen darauf, wie unser Team sich diesen Herausforderungen stellte und sie meisterte, und das mit euer aller Hilfe!
Ich möchte mit einem ganz besonderen Dank an alle Mitglieder unserer Community beginnen: Uns ist klar, dass diese Situation nicht ideal war, von den anfänglichen Spielabstürzen bis hin dazu, dass wir eure Hilfe beim Erheben zusätzlicher Daten benötigten, als wir absichtlich ein Ereignis auslösten, das zu einem Absturz führt. Die ganze Zeit über erhielten wir zahlreiche nette und verständnisvolle Nachrichten, die uns zeigten, dass ihr hinter uns steht. Im Namen des gesamten Teams möchte ich euch mitteilen, dass Worte gar nicht reichen, um unsere Dankbarkeit in diesem Zusammenhang auszudrücken. Also, vielen Dank euch allen.
Die „Alpha“-Beta
Am Mittwoch, 20. August, um genau 18:17 Uhr MESZ (9:17 Uhr PT) startete das Beta-Event-Wochenende, das die neuen Elite-Spezialisierungen für unsere sechste Erweiterung vorstellen sollte, Guild Wars 2: Visions of Eternity. Das war kein sonderlich toller Start, da die Beta eigentlich um 18 Uhr hätte beginnen sollen! Wir hatten uns bei den Zeitzonen verrechnet, und die Startzeit war eine Stunde zu spät geplant. Zum Glück konnten wir ein paar Konfigurationsdateien modifizieren und die Beta vor 19 Uhr ins Rollen bringen!
Es ist nie unsere Absicht, Inhalte mit Fehlern zu veröffentlichen, aber wir haben immer Pläne in der Hinterhand für den Fall, dass sie doch auftreten. Bald nach dem Release fanden wir drei Probleme, die wir so schnell wie möglich beheben wollten. Eines dieser Probleme konnten wir ganz einfach mithilfe von Konfigurationsdateien lösen. Ein zweites Problem, das nichts mit dem Beta-Event zu tun hatte, konnte gelöst werden, indem wir eine Änderung an einem unserer Backend-Server vornahmen. Für das dritte war ein Same-Day-Gamebuild erforderlich. Um 23 Uhr MESZ (14 Uhr PT) hatten wir uns um alle drei Probleme gekümmert, und wir freuten uns darauf, uns zurücklehnen zu können und Spaß an der Beta zu haben. Kurz darauf meldete sich der Community Manager im Chat; er wollte einen Statusbericht, da es im Spiel lichterloh brannte.
In unseren Remote-Offices sah man baffe Gesichter. Uns lagen keine Absturzberichte vor, und alle Diagramme sahen stabil aus. Wir wussten, dass wir der Sache nachgehen mussten, und stießen schließlich auf ein merkwürdiges Phänomen. Ein Client-Fehlerbericht zeigte wiederholt einen Code 1083. Jetzt bitte die mysteriöse Musik einspielen.
Alles gesperrt
Code 1083 ist ein höchst spezifischer Fehlercode, der nur einmal in unserer gesamten Server-Codebase auftaucht: „Auf Aufheben der Sperre warten“. In der Kern-Serverarchitektur von Guild Wars 2 sind „Sperren“ ein Teil der Organisation unserer Kartenkontexte, da Karten auf jeden Server unserer Hosting-Flotte erstellt werden können. Der Charakter-Sperrmechanismus stellt sicher, dass es immer nur einen Kartenkontext gibt, der berechtigt ist, in den Datensatz eines Charakters zu schreiben. Ein nützliches Tool gegen Exploits, das jedoch hauptsächlich dazu dient, dass Charakter- und Accountdaten konsistent bleiben. Für gewöhnlich wird beim Betreten einer Karte eine ausstehende Sperre in der Datenbank für den jeweiligen Charakter vorgenommen, die anzeigt, dass der Spielserver die Berechtigung übernehmen möchte. Eine Übergabe findet statt, wenn es entweder keine bestehende Sperre gibt oder sie von einem anderen Server aufgehoben wird; die ausstehende Sperre wird dann zur Berechtigungssperre.
Aber uns ist nicht immer eine perfekte Welt gegönnt: Programmfehler kommen vor und Karten stürzen ab. Als Entwickler möchten wir so viele Debugging-Infos zu diesen Ereignissen sammeln, wie wir nur können. Wenn also ein Kartenkontext abstürzt, können wir das Herunterfahren kurz unterbrechen, relevante Infos sammeln und diese per E-Mail ans Büro schicken, das dem Problem dann nachgeht und es behebt. Während dieses Vorgangs weiß der Spielserver, dass diese Karte abstürzt, und er kann der Datenbank auch mitteilen, dass sie alle vorhandenen Sperren aufheben soll.
An diesem Punkt war uns immerhin klar, warum wir den Vorgang nicht gesehen hatten, und nach welcher Art von Fehler wir suchen mussten. Da wir keine Berichte über diese Abstürze erhielten, wussten wir, dass kein Teil des „Aufräum“-Codepfads ausgelöst wurde; Sperren wurden also nicht sauber aufgehoben. Der Kartenkontext, der die Sperre verwendete, existierte nicht mehr, also gab es keine Entität, der man befehlen konnte, die Sperre aufzuheben. Am Ende lief die Sperre einfach per Timer ab. Wenn nach einer Weile kein Update vom bisherigen Inhaber der Sperre erfolgte, wurde die Sperre aufgehoben, und der Charakter konnte erneut eine Verbindung zu einem Kartenkontext aufbauen, die eine neue Sperre erwirken konnte.
Der Timer ist länger, damit er eine Reihe verschiedener Infrastrukturunterbrechungen abdeckt. Auch wenn uns bewusst ist, dass es nervig für Spieler ist, sich nicht einloggen zu können, ist dies doch das geringere Übel, da so die Integrität und die Konsistenz unserer Spielerdaten gewährleistet werden.
Nach einer Besprechung zwischen Team und Leitung waren wir der Ansicht, dass dies ein erhebliches Problem ist, das ein vorzeitiges Beenden des Beta-Events erfordert, damit Spieler ein besseres Spielererlebnis genießen können und unser Team der Ursache des Problems nachgehen kann. Da wir wussten, dass unser Anwendungscode abstürzte und weder den Datenerhebungs- noch den Berichtsprozess einleitete, legte der Occam-Schnitter nahe, dass es sich um ein Problem mit defektem Speicher handeln könnte. Dies bestätigte sich später am Abend durch die Protokolle des Betriebssystems.
Nadel im Nadelhaufen
Wir versuchten, dem Problem auf den Grund zu gehen und die kleinste Instanz zu finden, in der das Problem existieren könnte. Dadurch konnten wir zwar verhindern, Millionen und Abermillionen Zeilen Code durchforsten zu müssen, aber basierend auf unseren Informationen konnten wir die Möglichkeiten auch nicht sonderlich einschränken. Es gibt neun Elite-Spezialisierungen, und wir wussten nicht, welcher Beruf der Katalysator des Absturzes war (Achtung, Wortwitz).
Wir veröffentlichen ständig neuen Code, und obwohl die Beta im August stattfand, wurden die ersten Änderungen am Code für diese neuen Spezialisierungen schon letztes Jahr vorgenommen. Am Donnerstag machten sich mehrere Teammitglieder daran, das Problem von dieser Warte aus anzugehen, indem sie nach Schlüsselbegriffen in Einreichungskommentaren suchten und sich Änderungen genauer ansahen.
Andere Kollegen analysierten unsere Daten auf der Suche nach Mustern bezüglich bestimmter Karten, Klassen auf diesen Karten, Spielerzahlen auf Karten usw., um die Möglichkeiten des Problems weiter einzugrenzen.
Wir hatten noch einen weiteren Hinweis, der uns beim Einschränken unserer Suche half, und der hatte damit zu tun, wie unsere Spielserver verschiedene Arten von Speicher verwalten und gruppieren.
Das Gehirn eines Spielservers
Jedes Spiel benötigt Daten, damit es weiß, wie es zu funktionieren hat: Welche Kreaturen spawnen wo, wann werden dynamische Events ausgelöst, welche Geometrie wird am Boden für Kollisionserkennung eingesetzt und vieles mehr. Ein Spielserver kann viele Kartenkontexte erstellen, und jeder Kartenkontext beansprucht eine bestimmte Menge an Speicher, um alle lokalen Informationen unterbringen zu können, die er verwendet und aktualisiert.
Um die Speichernutzung zu minimieren und Duplikate zu vermeiden, erstellen unsere Spielserver zusätzlich einen Abschnitt mit gemeinsam genutztem statischen Speicher. Hier können wir Daten platzieren, die sich nicht verändern; sie sind schreibgeschützt und werden von allen Kartenkontexten verwendet. Die meisten Elemente, die an Identifikations-Tags gebunden sind, unter anderem Gegenstände, Erfolge, Kreaturentypen usw., sind hier gespeichert, und sie können von jedem Kartenkontext gelesen werden, da es immer dieselbe Information ist, unabhängig von der Karte, die gerade verwendet wird.
Basierend auf den Abstürzen aufgrund defekten Speichers, die wir gesehen hatten (oder eben nicht gesehen hatten), konnten wir uns sicher sein, dass es sich hierbei um ein Problem mit gemeinsam genutzten Speicherplätzen handeln musste. So konnten wir den Umfang unserer Suche ein weiteres Mal einschränken.
Versuch um Versuch
Im Zuge unserer weiteren Nachforschungen nahmen wir einen für Donnerstag geplanten internen Spieltest in Beschlag, an dem das gesamte Team beteiligt war, um den Absturz auf einem unserer Entwicklungsserver zu reproduzieren. Die Anweisungen waren absichtlich unklar: Erstellt einen Beta-Charakter, drückt auf Knöpfe und reicht einen Bericht ein, wenn es zu einem Absturz kommt. Aber es kam zu keinem Absturz.
Wir konnten keinen Absturz auslösen.
Code und Konfiguration unserer Entwicklungsserver unterscheiden sich leicht von den Elementen unserer Live-Server. Am Freitag hatten wir dann einen Plan für einen weiteren internen Spieltest auf unseren Staging Clients, die der Live-Umgebung am ehesten entsprechen.
Und wieder konnten wir keinen Absturz auslösen.
Unsere Optionen wurden weniger, und wir entschieden uns, das Beta-Event mit der Absicht, unsere Spieler einen Serverabsturz auslösen zu lassen, wieder im realen Spiel zu aktivieren.
Die „Beta“-Beta
Um genau 21 Uhr MESZ (12 Uhr PT) wurde das Beta-Event wieder aktiviert. In unserem Chat wurde es ein paar Minuten ruhig, als wir alle darüber nachgrübelten, was da wohl kommen würde. Wir hatten einige zusätzliche Vorbereitungen getroffen, bevor wir das Beta-Event neu aktivierten, indem wir spezifische Tools und Überwachungswerkzeuge bereitstellten, mit denen wir am besten Abstürze erkennen und Debug-Daten erheben konnten. Worauf wir uns nicht spezifisch vorbereitet hatten, war, welches Glück wir schon bald haben sollten.
Kurz vor dem Neustart um 21 Uhr gingen wir mit einem neuen Build online, der einen Programmfehler behob, der mit einer der neuen Spielerbeschwörungen zu tun hatte. Unser erster Glückstreffer war, dass ein neuer Build dafür sorgte, dass alle unsere Spielserver neue gemeinsame Speicherpuffer erstellen mussten, was die Speicherzuweisungen neu mischte. Um 21:11 Uhr meldeten unsere Überwachungstools den ersten Absturz. Unser zweiter Glückstreffer kam einen Augenblick später, als wir einen vollständigen Absturzbericht von unserem internen Diagnosetool erhielten. Der zweieinhalbte Glückstreffer war die Art des Absturzes, den dessen Dump-Datei belegte. Ein Stück Code versuchte, ein Stück gelöschten Speichers zu löschen.
„Warum löschen wir doppelt?“, fragten wir uns. „Moment, warum löschen wir überhaupt aus dem schreibgeschützten Speicher?“
Zuerst einmal wollten wir sichergehen, dass dies auch der Absturz war, nach dem wir suchten, und kein Zufall mit merkwürdigem Timing. Wir leiteten die Informationen des Absturz-Dumps an unser QA-Team weiter, und binnen 15 Minuten konnten wir den Programmfehler reproduzieren. In der Zwischenzeit hatte unser Team, das das laufende Spiel beobachtete, weitere Abstürze verzeichnet; einige schickten Absturzberichte, auf andere wurden unsere Speicherüberwachungs-Tools aufmerksam, die wir zuvor eingerichtet hatten. Alle Berichte zeigten ähnliche Informationen darüber, dass ein Abschnitt bereits gelöschten Speichers gelesen oder gelöscht werden sollte. Nach einer abschließenden Besprechung, bei der wir bestätigten, dass wir alles haben, was wir benötigen, deaktivierten wir das Beta-Event erneut.
Ingenieure verursachen das Problem, Techniker beheben es
Die neueste Elite-Spezialisierung des Ingenieurs, das Amalgam, führte eine irre neue Klassenmechanik namens „Verformung“ ein sowie einen neuen Codepfad, über den diese Fertigkeiten festgelegt und aktualisiert werden. Dieses neue Verhalten machte unsere Pläne einer erfolgreichen Beta zunichte und daraus wurde eine dreitätige Tortur.
Der Programmfehler war zurückzuführen auf ein Missverständnis einer Datenstruktur, die lokalen Kartenkontext-Speicher verwendete, oder den gemeinsam genutzten Speicher des Spielservers. Wenn ein Ingenieur-Spieler, der die Elite-Spezialisierung „Amalgam“ ausgerüstet hat, eine Verformung-Fertigkeit austauschte, wollte der Code diese Veränderung an der Fertigkeit und die daraus resultierende Mitnahme der Erholzeit in den Kontext dieses Spielers speichern. Diese Änderung wurde mit einem Pointer durchgeführt, der unwissentlich auf den gemeinsam genutzten Speicher verwies. So kam es, dass wir durch das Vorhaben, einen lokalen Verweis auf die vorherige Fertigkeit zu löschen, unbeabsichtigt die Fertigkeit aus dem gemeinsam genutzten Speicher löschten. Wenn das nächste Mal ein Spieler auf diesem Spielserver versuchte, auf die mittlerweile gelöschte Verformung-Fertigkeit zuzugreifen, kam es zu einem Absturz.
Zu unserem Glück stammten diese Datenstruktur und ihre Hilfsfunktionen aus unserer Feder, also war die Behebung technisch gesehen ein Einzeiler.
Um 21:53 Uhr reichten wir diese Fehlerbehebung bei unserer Entwicklungsabteilung ein und begannen mit unserem Prozess der Fehlertests, Regressionstests und der Weiterführung der Änderung durch unsere Staging-Phase bis zum schlussendlichen Live-Build.
Ich bin nach wie vor beeindruckt davon, wie schnell wir die Änderungen umsetzen konnten. Dies ist teilweise unserem schier magisch begabten Technikerteam zu verdanken, aber auch „E.“, der diesen ganz bestimmten Fehler behob. Allerdings hatte auch unsere Build-Pipeline ein paar Asse im Ärmel, mit deren Hilfe alles schnell ging. Für die meisten Dienstags-Releases benötigen wir einen vollständigen Build, der sämtlichen Code und alle Inhalte umfasst. Wenn wir jedoch lediglich ein Stück Servercode ändern wollen, können wir einen schnellen Build durchführen. Dieser ist deutlich kleiner und selektiver, und er braucht auch nur sehr wenig Zeit, sodass wir ihn schnell umsetzen können.
Die „Gamma“-Beta
Nur wenige Stunden später hatten wir die Fehlerbehebung in das laufende Spiel implementiert und konnten das Beta-Event erneut starten. Unser Technikerteam und unsere QA loggten sich ein, um Amalgam-Charaktere zu erstellen und zu überprüfen, ob die Behebung erfolgreich war. Zu unserer Erleichterung traten keine weiteren Abstürze infolge der Überprüfung auf.
Unser Team setzte die Überwachung mit denselben Tools fort, die wir schon zuvor am selben Tag verwendet hatten, und offenbar hatte die Fehlerbehebung geklappt. Wir freuten uns, unseren Spielern endlich das Erlebnis dieser neuen Spezialisierungen präsentieren zu dürfen, da nun alle neuen Fertigkeiten und Mechaniken wie erwartet funktionierten.
Zum Abschluss
Nach dem Vorfall und nachdem das Beta-Event eine Woche später beendet wurde, traf sich das Team erneut, um die Ereignisse zusammenzufassen, zu analysieren und einen Plan aufzustellen. Ist es möglich, solche Probleme intern und früher im Prozess abzufangen? Gibt es ein neues Tool oder eine neue Prozedur, um diese Arten von Problemen zu entschärfen? Wenn sich dieses Problem wiederholen würde, was würden wir anders machen? Wie können wir einen nominellen Spielerstatus schneller wiederherstellen?
Ich werde ähnliche Abschlussworte wie die verwenden, die ich 2020 für einen anderen Beitrag verfasst habe:
Unsere Bemühungen zielen immer darauf ab, unseren Spielern das beste Erlebnis und die beste Nutzbarkeit unserer Dienste zu bieten. Wir loben gern das, was die Leute vor uns entworfen haben, und die Tools und Abläufe, die wir nutzen, um die Weltklasse unserer Verfügbarkeit, unserer Spielmechaniken und unserer Events beizubehalten. Uns ist klar, dass wir vielleicht keine Perfektion erreichen, aber wir werden sie bei künftigen Vorgehensweisen und Entwicklungen bestimmt anstreben. Während wir den spannenden neuen Features und Projekten entgegensehen, die das Gameplay- und das Entwicklerteam euch bescheren, arbeiten wir ständig hinter den Kulissen daran, dass ihr immer alles erleben und genießen könnt, das Guild Wars 2 zu bieten hat.
Danke noch mal, und wir sehen uns in Tyria!
Quelle: https://www.guildwars2.com/de/news/resolv…tm_campaign=rss