Blogpost: Inside ArenaNet – Spielausfall-Analyse

Hallo! Ich bin Robert Neckorcuk, Platform Team Lead bei ArenaNet. Mein Team betreibt einige Back-End-Netzwerkdienste für die Guild Wars® Reihe: Login-Server, Chat-Server, Webseiten und mehr. Wir arbeiten sehr eng mit zwei anderen Teams zusammen, Game Operations und Release Management, und bilden gemeinsam die Back-End-Servicegruppe. Zudem arbeiten wir mit Gameplay, Analytics, Support und so weiter zusammen, doch unser Schwerpunkt ist es, dafür zu sorgen, dass die Spiele und ihre Infrastruktur erreichbar bleiben. Die Guild Wars-Reihe hat eine anerkannt hohe, beeindruckende Online-Verfügbarkeit. Auch wenn wir uns über den Erfolg unserer Infrastruktur freuen, standen wir dennoch schon vor einigen Herausforderungen. Heute möchte ich euch von den Einzelheiten des letzten großen Zwischenfalls berichten und welche Lehren wir aus ihm gezogen haben, um noch besser für euch da zu sein.

Am Montag, den 11. Mai 2020 um 6:00 Uhr Ortszeit erhielt ich einen Anruf. Ich kann euch versichern, dieses Datum musste ich nicht nachschlagen – ich habe noch sehr lebhafte Erinnerungen daran. Unser Game-Operations-Team sah auf einer Speicherseite, dass eine im Spielbetrieb befindliche Guild Wars 2-Datenbank zurückgesetzt worden war, dass Spieler uneinheitliche Informationen von den Spiel-Servern erhielten und dass unsere internen Tools einen Haufen anderer, damit in Verbindung stehender Alarme und Fehler anzeigten.

Oh, verflixt.

Ich hatte schon weniger aufregende Montage. Eigentlich sind mir weniger aufregende Montage auch lieber. Ich loggte mich auf meinem Arbeitsrechner ein und untersuchte mit den anderen, was vorgefallen war und was wir tun konnten, um das Spiel wieder in seinen normalen Zustand zu bringen. Für ein Team und eine Firma, deren Ziel es ist, immer online zu sein, führte die Untersuchung zu unseren schlimmsten Befürchtungen: Wir würden das Spiel abschalten müssen, um die Daten eines guten Zustands wiederherzustellen. Da ich einen solchen Zwischenfall zum ersten Mal erlebte, brauchte ich ein bisschen, um herauszufinden, welche Genehmigungen nötig waren. Kurz nach 9:00 Uhr nahm ich die Änderungen vor, die den Login ins Spiel deaktivierten und die Server für Guild Wars 2 in Europa abschalteten.

Ständige Iterationen

Während dieser Unterbrechung war Guild Wars 2 in unseren europäischen Datenzentren für etwas mehr als 20 Stunden nicht erreichbar. Abgesehen von einigen minutenlangen Aussetzern war es zur letzten Abschaltung von Guild Wars 2 am 23. August 2016 gekommen. Obwohl Probleme mit der Erreichbarkeit nie Spaß machen, können wir solche Vorfälle als Gelegenheiten nutzen, um zu lernen, wie wir unsere Infrastruktur und unsere Abläufe verbessern. Unsere Vorgehensweise bei Störungen entspricht der vieler Anbieter von Live-Diensten, sowohl in der Spielebranche als auch außerhalb:

• Das Ausmaß des Problems ermitteln – betrifft es einen Server, ein Datenzentrum oder einen Build? Wir finden heraus, ob wir unsere Untersuchung auf eine kleinere Gruppe von Diensten oder Regionen eingrenzen können.
• Einen Weg ermitteln, den Dienst so bald wie möglich wieder zum Laufen zu bringen – hier muss zwischen Korrektheit und Verfügbarkeit abgewogen werden. Wenn wir etwas zusammenbasteln, damit der Dienst wieder funktioniert, machen wir dann etwas anderes kaputt?
• Einen Bericht über den Vorfall schreiben, sobald der Dienst wieder läuft – in diesem Bericht sollte ausführlich beschrieben werden, was vorgefallen ist, wer uns über das Problem informiert hat, welche Maßnahmen wir ergriffen haben und wer betroffen war.
• Später, während der normalen Geschäftszeiten, ein Treffen mit den wichtigsten Projektbeteiligten einberufen, bei dem der Bericht über den Vorfall besprochen wird und Aufgaben für etwaige Folgemaßnahmen erstellt werden – etwa Warnungen oder Abfragen zu verbessern, die Dokumentation oder automatisierte Abläufe zu aktualisieren oder ein neues Tool zu erstellen.

Wir sehen uns unsere Abläufe und Verfahren aber nicht nur während Zwischenfällen an und nehmen Änderungen vor. 2017 hat ArenaNet die Entscheidung getroffen, von einem Datenzentrum vor Ort zu einem cloudbasierten zu wechseln und die Infrastruktur von AWS zu nutzen (ohne jede Ausfallzeit!). 2020, nach der Home-Office-Umstellung, sind wir mit unserer Analyselog-Leitung endgültig von einem Hardware-Anbieter zu einem Cloud-Anbieter umgestiegen.

Der Grund für die ganzen Cloud-Umstellungen ist die größere Flexibilität – wir können unsere Infrastruktur ständig, rasch und nahtlos verändern und anpassen. Anfang 2020 haben wir ein umfassendes internes AWS-Upgrade in Angriff genommen und uns die Kosten und Optionen für jeden in Betrieb befindlichen Server angesehen, von unseren Entwickler-Handelsservern bis zu den Live-PvP-Planungsservern. AWS bietet ständig neue Dienste und neue Hardware-Bauarten an, und wir hatten seit 2017 keine vollständige Prüfung mehr vorgenommen. Im Rahmen dieser Planungen änderten wir Dinge, um das Spielerlebnis zu verbessern, wir passten unsere Entwicklungsumgebungen an das aktuelle Spiel an und optimierten mehrere Back-End-Tools. Zudem aktualisierten wir ein paar Server, die seit der Umstellung 2017 nie verändert – oder auch nur neu gestartet – worden waren!

Wenn man ein so großes Projekt angeht, gehört es zu den effektivsten Strategien, es in kleinere, besser handhabbare Stücke aufzuteilen … als würde man eine große Pizza in Stücke schneiden! Wir wollten jede AWS-Instanz durchgehen und zum Glück hatten wir schon mehrere „Eimer“ mit verschiedenen Instanztypen – Spiel-Server, Datenbank-Server, Handelsserver usw. Wir hatten vor, sie der Reihe nach abzuhandeln, die Änderungen vorzunehmen und uns dann der nächsten Gruppe zu widmen. Für jeden Satz Änderungen würden wir mit der Umstellung unserer internen Entwicklungsserver beginnen. Wir würden ein Betriebshandbuch schreiben, um den Ablauf zu dokumentieren, das Verhalten zu überprüfen und dann unsere Arbeits- und Live-Umgebungen nach den Schritten des Betriebshandbuchs umzustellen.

Für jedes Produkt und jede Firma ist die Fähigkeit, Überarbeitungen vorzunehmen, absolut entscheidend. Man baut im eigenen Garten etwas zusammen, schlägt es in Stücke und macht es so oft und auf so seltsame Weise kaputt, wie man kann. Sobald man intern alles ausgebessert hat, sollte das Ganze ziemlich belastbar sein, wenn man es der Öffentlichkeit vorstellt. Für das Platform- und das Game-Operations-Team ist dieser Vorgang des „Übens, wie wir spielen“ ein weiteres Werkzeug im Gürtel, das unserer Servicequalität zugutekommt. Allerdings unterscheiden sich die Entwicklungs- und Spiel-Server enorm, was Kosten und Umfang angeht, und so sehr wir uns auch wünschen würden, dass alles sich gleich verhielte – sie haben ihre Besonderheiten.

Ein paar (stark vereinfacht!) Hintergrundinformationen zu unseren Datenbanken: Wir haben zwei Server, einen primären und einen sekundären. Wenn wir in die Datenbank schreiben, wird eine Meldung „Nimm diese Änderung vor“ an die primäre Instanz geschickt. Die primäre schickt der sekundären (dem Spiegelserver) dann eine Meldung „Nimm diese Änderung vor“ und wendet die Änderung bei sich an. Wenn auf der primären Instanz „schlimme Dinge“ passieren, übernimmt automatisch die sekundäre und meldet sich als die primäre. Dadurch gibt es keine Ausfallzeit und keinen Datenverlust, und die neue primäre Instanz baut eine Warteschlange von Meldungen auf, die sie an die „neue sekundäre“ schickt, sobald diese sich von den „schlimmen Dingen“ erholt hat. Beim Aktualisieren von Instanzen trennen wir die Verbindung zwischen primärer und sekundärer Datenbank manuell, aktualisieren die sekundäre und verbinden sie wieder.

Einer der wichtigen Datenpunkte, die wir erfassen können, ist die Zeit, die es dauert, bis die sekundäre Instanz alle Meldungen in der Warteschlange von der primären erhalten hat und wieder Datenparität hergestellt ist. In Verbindung mit anderen Lade- und Zustandskenngrößen kann uns das sagen, ob der Server in Ordnung ist oder nicht – und ich persönlich finde Diagramme recht faszinierend. Dann tauschen wir primäre und sekundäre Instanz, wiederholen das Ganze und bekommen noch mehr schöne Diagramme sowie eine vollständig aktualisierte Umgebung.
Bei der Entwicklungsumgebung lief alles glatt. Unsere Arbeitsumgebung bot uns eine weitere Gelegenheit, den Vorgang lückenlos ablaufen zu lassen, und auch dort ging alles glatt. Wir begannen mit der Aktualisierung des Spiels auf den europäischen Servern am Mittwoch, 6. Mai 2020.

Wo die schlimmen Dinge sind

Am 6. Mai verlief die eigentliche Aktualisierung genau nach Plan. Wir trennten die Verbindung, aktualisierten die sekundäre Instanz und stellten wieder eine Verbindung her. Die Meldungen in der Warteschlange wurden rüberkopiert, wir tauschten primäre und sekundäre Instanz und wiederholten das Ganze. Das Kopieren der Meldungen verlief etwas langsamer als bei unseren Testdurchgängen in der Entwicklungsumgebung, doch wegen des hohen Datenaufkommens auf dem Spiel-Server gab es auch eine wesentlich längere Warteschlange.

Am Donnerstag, 7. Mai, erhielten wir einen Alarm „Speicherplatz fast belegt“. Wir hatten kurz zuvor eine zusätzliche Sicherheitskopie der Daten angelegt, die einigen Platz verbrauchte, doch die bewährte Vorgehensweise schrieb vor, den Speicherplatz trotzdem zu vergrößern. Speicherplatz ist nicht teuer, und bei AWS konnten wir mit ein paar Mausklicks die Größe unseres Log- und Sicherungslaufwerks verdoppeln. Ein Mitglied des Game-Operations-Teams klickte also ein paarmal, doch der größere Speicherplatz erschien nicht plötzlich auf magische Weise. Am Freitag schickten wir ein Support-Ticket an AWS, die uns einen Neustart empfahlen, um das Problem zu beheben. Da dieser Server aktuell der primäre war, mussten wir ihn mit dem sekundären tauschen, bevor wir ihn neu starten konnten.

Es ist sehr einfach, auf die Dinge zurückzublicken und die offensichtlichen Fehler zu erkennen, aber zu der Zeit wussten wir nicht, was wir nicht wussten. Am Freitagnachmittag versuchten wir, den primären und den sekundären Server zu tauschen, um einen schnellen Neustart vornehmen zu können. Zu diesem Zeitpunkt war die Warteschlange mit Meldungen vom primären an den sekundären jedoch nicht leer, und es wurde noch langsam kopiert. Ein paar Berechnungen sagten uns, dass die Festplatte sich über das Wochenende nicht vollständig füllen würde, wir könnten also am Montagmorgen zurückkehren, uns auf die Meldungen in der Warteschlange stürzen, die Server tauschen und den Neustart vornehmen.

Und am Montag kehrten wir in der Tat zurück …

Wir erkannten zwar, dass die Meldungen in der Warteschlange langsam verschickt wurden (denkt an „Schneckentempo“), wir berücksichtigten jedoch nicht das Tempo, mit dem die Warteschlange anwuchs (denkt an „Raketentempo“!). Erinnert euch jetzt an die weitgehend zutreffende Aussage, dass die sekundäre Datenbank automatisch als neue primäre übernimmt, wenn mit der primären „schlimme Dinge“ passieren. Wie es sich trifft, ist eines der „schlimmen Dinge“, bei denen die automatische Ausfallsicherung greift, ein zu starkes Anwachsen der Warteschlange mit Meldungen.

Um 2:41 Uhr am Montag, 11. Mai, war die Schwelle der „schlimmen Dinge“ überschritten, die primäre Datenbank und der Spiegelserver wurden getauscht. Da sich beim Tausch der Server die Datenbank-Änderungsmeldungen alle in einer Warteschlange auf dem anderen Server befanden, erlebten die Spieler plötzlich eine Zeitreise (und nicht von der guten Art), da ihre gesamten Fortschritte seit Freitagabend verschwanden. Drei qualvolle Stunden später, um 5:40 Uhr, wurde unser Game-Operations-Team gerufen, da sich die Spielermeldungen häuften. Ich wurde um 6:00 Uhr angerufen, und das Spiel wurde um 9:00 Uhr abgeschaltet.

Als das Spiel nicht mehr lief, war einer unserer ersten Schritte ein Neustart des primären Servers, und wie vorausgesagt erschien der zusätzliche Speicherplatz! Gute Neuigkeiten, wenn auch sonst nichts. Auf der frisch erweiterten Festplatte fanden wir die aktuellste automatische Sicherungsdatei und Logs mit allen Meldungen in der Warteschlange – bis um 2:41 Uhr.

Das Anlegen von Sicherungsdateien ist eine ausgezeichnete Vorgehensweise. Speicherplatz ist billig, die Wiederherstellbarkeit von Daten lässt einen ruhig schlafen und es ist kinderleicht, automatische Sicherungen festzulegen. Die Daten mit der Sicherungsdatei dann wirklich wiederherzustellen … das ist allerdings eine andere Sache, hauptsächlich deswegen, weil wir es nicht oft machen. Einerseits gab es keine Last auf den Datenbanken, wir konnten bei Bedarf also alles niederreißen und neu anfangen. Andererseits war das Spiel abgeschaltet und wir verspürten einen gewaltigen Druck, die Daten schnell und korrekt wiederherzustellen, um das Spiel hochfahren zu können.

(Randnotiz: Ich werde mich hier auf den wichtigsten Handlungsstrang konzentrieren, doch selbst zu diesem Zeitpunkt fanden schon ergänzende Untersuchungen statt, welche Auswirkungen auf den Handelsposten, den Edelsteinshop, die Account-Erstellung und anderes haben würden. Während des Zwischenfalls geschah eine Menge, und viele verschiedene Teams beteiligten sich. Mir kommt es vor, als könnte ich ein ganzes Buch mit kleinen Geschichten über dieses eine Ereignis schreiben!)

Ehrlich gesagt war der Vorgang der Datenwiederherstellung ziemlich langweilig, und wir hielten uns einfach an einen Leitfaden zu bewährten Vorgehensweisen. Ein paar Klicks im Verwaltungsprogramm, und der Server begann, vor sich hin zu arbeiten. Bevor wir loslegen konnten, mussten wir die Sicherungsdatei und die Logdateien auf den zweiten Server kopieren, denn nur so konnten wir dafür sorgen, dass wir dieselben Daten auf beiden wiederherstellten. Der Server setzte dann den Zustand der Datenbanken auf das, was die Sicherungsdatei enthielt. Dieser Vorgang dauerte mehrere Stunden. Dann wendete er alle protokollierten Meldungen an, sodass schließlich beide Datenbanken bis 2:41 Uhr korrekt waren. Auch das dauerte lange. Der erste Server war um 1:37 Uhr fertig, der zweite um 4:30 Uhr.

(Randnotiz 2: Neben der eigentlichen Arbeit sind die Leute, mit denen man arbeitet, wahrscheinlich das wichtigste Kriterium bei der Wahl einer Firma oder eines Teams. Wir waren eine Handvoll Leute, online seit 5:30 oder 6:00 Uhr, und machten nur kurze Nickerchen, arbeiteten uns ansonsten aber bis in die frühen Morgenstunden des nächsten Tages durch den Ablauf. Das war definitiv eine Menge Server-Babysitting! Dass jeder in der Krisenzentrale die Situation ernst nehmen, aber zurechtkommen und sich ein bisschen Verspieltheit bewahren kann, damit wir alle dieses Ereignis durchstehen, darf dabei nicht unterschätzt werden. Dieses Team ist fantastisch in dem, was es macht und wie es das macht.)

Die Infrastruktur von Guild Wars 2 ist ebenfalls große Klasse. Sie ermöglicht Aktualisierungen ohne Ausfallzeit und hat viele Regler und Hebel, die man drehen und ziehen kann, um verschiedene Funktionen oder Inhalte im Spiel zu beeinflussen, Exploits oder Abstürze zu verhindern oder sogar die Schwierigkeit dynamischer Events zu ändern, ohne dass ein neuer Build nötig ist! Am 12. Mai nutzten wir eine weitere Funktion im Spiel, die seit 2016 nicht mehr zum Einsatz gekommen war – die Fähigkeit, online zu gehen, ohne online zu gehen. Das Spiel lief vollständig, ließ aber nur Entwickler rein, keine normalen Spieler.

Um 4:55 Uhr „schalteten wir das Spiel ein“, und jede Menge Entwickler, Qualitätssicherungsanalysten und eine Handvoll EU-Partner loggten sich ein. Ich war äußerst beeindruckt davon, dass Spieler schon nach Minuten herausgefunden hatten, dass das Spiel live getestet wurde und ihre Fortschritte auf dem Stand von Montagmorgen wiederhergestellt wurden. Ich schätze, das passiert, wenn wir unsere APIs verfügbar machen!

Nach einem Smoke-Test der Live-Umgebung, bei dem die ordnungsgemäße Funktion der Datenbanken und die Warteschlangen mit Meldungen überprüft wurden, machten wir die Server um 5:37 Uhr öffentlich zugänglich, mehr als 20 Stunden nach der Abschaltung. Jeder im Team war dankbar, den Leuten in die Welt zurückhelfen zu können, die sie lieben – auch ich. Und ich war froh, ein paar Stunden Schlaf zu bekommen.

Puh.

Nachdem wir uns ein paar Stunden ausgeruht hatten, loggten wir uns alle wieder bei der Arbeit ein, um nachzuvollziehen, was die eigentliche Ursache des Ausfalls gewesen war. An diesem Nachmittag wurde in unserer EU-Region ein Alarm ausgelöst – die Warteschlange mit Datenbankmeldungen war zu groß.

Verflixt. Schon wieder.

Wir hatten die neu entdeckten Ausfallstellen korrekt identifiziert und ein paar Warnmechanismen dafür eingebaut. Während der nächsten beiden Tage verwalteten wir die Datenbankspiegelung und die Verbindungen zwischen primärem und sekundärem Server manuell. Wir sprachen mit Datenbank-Administratoren, Netzbetreibern und unseren technischen Account-Managern von AWS. Wir konfigurierten jede mögliche Einstellung, die mit der Warteschlange der Meldungen, Datenträgern, Speicherplatz und den Logs zu tun hatte. Nachdem wir tagelang Unterlagen gelesen, Wissen von Experten gesammelt und Änderungen ausprobiert hatten, gelang uns am Freitag endlich der Durchbruch.

Trommelwirbel, bitte!

Die eigentliche Ursache waren die Treiber.

Treiber sind das, was es Software-Betriebssystemen ermöglicht, mit angeschlossenen Geräten zu kommunizieren – wenn ihr Peripheriegeräte wie eine Gaming-Maus oder ein Grafiktablett habt, dürftet ihr euch spezielle Treiber für sie heruntergeladen haben.
In diesem Fall verfügte das Betriebssystem des Servers nicht über die aktuellste Kommunikationsmethode, um sich mit der Festplatte zu verbinden. Nicht gerade toll für eine Datenbank, bei der das Lesen und Schreiben von Daten auf der Festplatte 99 % des Grundes ausmachen, warum sie überhaupt existiert … (Die übrigen 1 % sind der „Wow-Faktor“. Wow, ihr habt eine Datenbank? Cool.)

Als wir die Server aktualisierten, zogen wir von der vierten Generation der AWS-Server auf ihre fünfte Generation um, und dadurch änderte sich, wie die Server mit angeschlossenen Geräten interagieren (wie das System funktioniert, kann ich nicht ganz nachvollziehen, doch AWS hat einen coolen Namen für die zugrundeliegende Technik: Nitro!). Unsere Treiberversion war der von AWS angebotenen Basisversion voraus, daher rechneten wir nicht damit, weitere Updates zu brauchen. Außerdem war das in unseren Entwicklungsumgebungen überhaupt kein Problem gewesen! Allerdings hatten wir dort auch nicht im Entferntesten die Last wie auf dem Live-Server. Obwohl es wieder Freitag war und wir die Folgen eines missglückten Treiber-Updates kannten, entschlossen wir uns, die Sache in Angriff zu nehmen.
Wie zuvor trennten wir die Verbindung zwischen den Datenbanken, nahmen die Treiber-Updates vor und stellten die Verbindung wieder her.

Die Warteschlange leerte sich fast sofort.

Die Daten-Schreibgeschwindigkeit betrug 100.000 Kilobit pro Sekunde, wohingegen wir zuvor 700 Kbps erreicht hatten.

Ich grinste. Ich lachte (ziemlich hemmungslos).

Wir wiederholten den Vorgang beim anderen Server. Erneut war die Warteschlange in ein paar Augenblicken leer.

An diesem Wochenende schlief ich. Und seitdem habe ich so viele gute Montagmorgen gehabt.

Der Blick zurück und nach vorn

Jetzt wisst ihr, was wirklich geschah, was wir übersehen hatten und warum es zu dem Zwischenfall kam. Nun zu dem Teil, den ich persönlich an meinem Beruf liebe: Welche Lektionen haben wir daraus gelernt? Wie haben wir das genutzt, um zu wachsen und besser zu werden? Welche Freunde haben wir dabei kennengelernt?

Nun, zuallererst war das eine massive Erinnerung daran, wie sehr sich die Entwicklungs- und die Live-Umgebung unterscheiden. Die Entwicklungsumgebung eignet sich prima zum Ausprobieren, zum Aufnehmen bestimmter Leistungskenngrößen und anderem. Für manche Änderungen sind jedoch weiterhin wichtige Hilfsmittel wie Last- und Stresstests auf mehreren Geräten notwendig.

Zweitens wurden wir daran erinnert, Annahmen immer zu überprüfen und einen Schritt zurückzugehen, um einen größeren Blickwinkel zu haben, wenn etwas nicht wie erwartet läuft. In den Tagen vor dem Ausfall waren wir zwar mit der nötigen Sorgfalt vorgegangen, hatten uns aber auf den falschen Teil des Problems konzentriert. Beim Austausch mit jemand anderem wären wir mit einer anderen Perspektive konfrontiert worden und hätten die auftretende Unregelmäßigkeit erklären müssen, um festzustellen, ob sie ein Problem sein könnte.

Die größte Änderung für unsere Datenbanken bestand darin, dass wir Warnungen auf wichtige Datenbank-Kenngrößen ausweiteten, statt sie auf System-Kenngrößen wie CPU oder Festplattenplatz zu beschränken. Für den Live-Betrieb fügten wir einem Drittanbieter-Tool einige Warnungen hinzu, um bei zukünftigen Problemen schneller reagieren zu können. Und für den allgemeinen Betrieb verbesserten wir die Dokumentation unserer AWS-Infrastruktur, indem wir mehr als nur den Instanztyp nachverfolgen. Unsere Protokolle enthalten jetzt Instanztypen, Generation, Treiber und Speichertypen. Wir haben ein Software-Paket zusammengestellt, das auf allen neuen Servern installiert wird und bestimmte Treiberversionen enthält. Bei allen zukünftigen Umstellungen wird dieses Software-Paket aktualisiert, damit ein solches Problem nicht noch einmal auftritt.

Wir haben die Umstellung aller übrigen Datenbank-Instanzen abgeschlossen und noch mehr, was eine höhere Leistung für besseren Service zur Folge hatte. In den letzten vierzehn Monaten verzeichneten wir eine Verfügbarkeit von 99,98 %, wobei nur fünf kleinere Serviceunterbrechungen die Benutzer-Logins beeinträchtigten.

Unsere Bemühungen zielen immer darauf ab, euch 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 unsere Weltklasse-Verfügbarkeit beizubehalten. Und es freut uns, unsere aktuelle Verfügbarkeitsspanne wieder über die Ein-Jahres-Marke zu bringen. 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 Design-Team von Guild Wars 2 euch bescheren, arbeiten wir ständig hinter den Kulissen daran, dass ihr euch immer einloggen und Spaß haben könnt.

Wow, ich weiß ja, dass ich eine Menge Code schreiben kann, aber anscheinend kann ich auch einen ziemlich langen Blogbeitrag verfassen. Ich hoffe, ihr habt ihn gern gelesen. Für einige mag sich die Erstellung dieses Beitrags ziemlich hingezogen haben, doch eigentlich freut es mich sehr, solche Geschichten mit euch teilen zu können. Wir würden gern eure Gedanken und Rückmeldungen zu dieser Art von Beiträgen lesen, deswegen haben wir einen Diskussions-Thread in unseren offiziellen Foren eingerichtet!

Wir sehen uns online in Tyria,
Robert