Shortnews

Nachbetrachtung der Namensreservierung

Wir erinnern uns: Dienstag, der 13. Mai 2014, ab 20 Uhr. Eigentlich sollte die Namensreservierung losgehen. Doch statt dessen bekamen die meisten nur den Fehler 404. Da könnte man jetzt Grass drüber wachsen lassen. Doch wie wir es von Carbine gewohnt sind, wird nichts verheimlicht! So spricht Craig "Cougar" Turner dieses Mal über die Fehler bei der Namensreservierung.
Veröffentlicht von Pavnik am 19.Mai, 2014 um 20:37 Uhr
6 Kommentare
0

Was lief falsch am 13. Mai 2014? Wo es doch noch nicht mal ein Freitag war?


Wir erinnern uns: Dienstag, der 13. Mai 2014, ab 20 Uhr. Eigentlich sollte die Namensreservierung losgehen. Doch statt dessen bekamen die meisten nur den Fehler 404. Bis ca. 1 Uhr in der Früh blieb das auch so. Doch was war passiert? Waren die Server nicht vorbereitet? Oder war es gar eine DDos-Attacke?

Um uns nicht länger im Dunkel tappen zu lassen, äußerte sich Craig "Cougar" Turner heute im offiziellen Forum über alle aufgetretenen Probleme und bestätigt damit wieder einmal, dass Carbine sehr offen und ehrlich zur Community ist.

HIER gibt es den orginal Artikel von Craig "Cougar" Turner und HIER die ins Deutsche übersetzte Variante von Jan "Bronn" Sterl. Oder direkt zum vor Ort lesen bei uns:

Nachbetrachtung auf die Namensreservierung (CRB Bronn)
Liebe Helden und Schurken,

tja … das ging dann ja wohl ziemlich daneben. Ich denke, die Kritik, die wir nach den Problemen mit dem Namensreservierungssystem (NRS) am Dienstag einstecken mussten, war absolut berechtigt. Also wollten Gaff und das Team, dass ich mich hinsetze und der Community einen Einblick in die Probleme gebe, die wir hatten.

Ich habe nicht vor, mich für Carbine zu entschuldigen, aber wie viele von euch sicher wissen, ist so ein Start ziemlich chaotisch. Während wir in paar Dinge richtig gut hingekriegt haben, war das Namensreservierungssystem ein echtes Fiasko. Aber genauso, wie wir unsere Erfolge feiern, stehen wir zu unseren Fehlern.

Apropos Erfolge: Es war ausgerechnet einer dieser Erfolge, der uns fälschlicherweise in Sicherheit gewogen hat. Die Rede ist von unserer Website für die Verteilung von Codes für die offene Beta (http://wildstar-onli...om/en/openbeta/), die absolut reibungslos funktioniert hat. Und die hatten wir mit Klebeband und Gips in ein paar Wochen zusammengeschustert. Wir haben damals überlegt, wie wir den Spielern möglichst viele Codes zukommen lassen können, ohne uns allzu sehr verbiegen zu müssen. Ohne E-Mails und Partner. Wir wollten die Türen einfach nur so weit wie möglich öffnen. Besucht unsere Seite, holt euch einen Code und legt los. Das war die Idee.

Unser Team war auf den Ansturm von Spielern vorbereitet, als wir die Beta am 8. gestartet haben, und es gab mit dem gesamten System nicht das geringste Problem. Wir haben Hundertausende von Codes verarbeitet und auf der Website unfassbare Besucherzahlen abgewickelt, ohne dass das System in die Knie ging. Dazu einige technische Infos: Wir hosten den Großteil der Codeverteilungsseite (und unser Namensreservierungssystem) auf Amazon AWS-Instanzen. Wir waren also darauf vorbereitet, nach Bedarf aufzurüsten, aber zum damaligen Zeitpunkt war das einfach nicht nötig. Alles schien in bester Ordnung zu sein.

Was am Dienstag passiert ist, war eine Kette von Ereignissen, die mit der Veröffentlichung unseres DevSepaks über die Schlachtzüge am frühen Morgen begann. Das Team hat den DevSpeak durchgezogen und sich dann sofort auf die Veröffentlichung der NRS-Website vorbereitet. Im Nachhinein war das keine gute Idee. Unser QA-Team hat zu diesem Zeitpunkt schon unter Hochdruck gearbeitet, um beide Seiten im Rahmen der engen Deadlines vor dem Start zu testen. Mit dem Beitrag über die Schlachtzüge haben wir jede Menge Traffic auf unsere Seite gezogen und die Spieler ermutigt, die verschiedenen Multimedia-Objekte herunterzuladen, die wir für sie vorbereitet hatten. Und zu allem Überfluss hatten wir auf der Homepage von WildStar Online auch noch ein 13 MB großes Banner veröffentlicht.

Phase 1 -

Wir haben die Seite wie geplant um 20 Uhr MESZ live geschaltet und sie ist binnen Minuten zusammengeklappt. Auch wir sind Gamer. Uns war klar, dass alle auf diesen Moment warten. Wir hatten das NRS auf dem Amazon AWS und standen bereit, um die Power des Systems nach Bedarf zu erhöhen. Allerdings hatten wir unterschätzt, welche Auswirkungen das neue 13MB Banner auf die Fähigkeit unserer Server, alle unsere Clients mit Daten zu versorgen, haben würde. Dieses Problem wurde durch die Leute verstärkt, die wegen des DevSpeaks auf der Seite waren und von den Spielern, die dort bereits auf die Veröffentlichung des NRS warteten.

Ich hatte schon Wochen vorher ein fünfstündiges Meeting angesetzt, um im Rahmen einer “Leseprobe” unsere Veröffentlichungspläne durchzugehen. Kurz nach 11 unserer Zeit wurden die ersten Mitglieder des Teams aus dem Meeting geholt, um sich mit den NRS-Problemen zu befassen. Spätestens als Gaff und unser Web-Chef mit langen Gesichtern den Raum betraten, war mir klar, dass wir ein ernstes Problem hatten. Es wurde beschlossen, die Seite für 90 Minuten vom Netz zu nehmen, um herauszufinden, ob wir das Problem mit der Überlastung so beheben konnten.

Wir haben dieses „Phase-1-Problem“ gelöst, indem wir das 13-MB-Banner und viele unserer anderen Videos auf unser CDN verschoben haben, und fuhren alles um 13 Uhr PDT wieder hoch. Die Website hielt dem Traffic jetzt zwar stand, aber offenbarte dann das nächste Problem.

Phase 2 -

Diese Phase war schwierig für uns. Uns war schnell klar, dass wir zwei unterschiedliche Fehlerquellen hatten, die die Fehlerbehebung extrem erschwert haben. Team A konnte die Probleme nicht finden und dachte, dass Team B sie beheben kann. Dummerweise ging es Team B genauso. Tatsächlich gab es auf beiden Seiten Probleme, und das hatte für die Spieler RICHTIG ÜBLE Konsequenzen.

Durch die Zusammenarbeit beider Teams haben sich immer mehr Leute mit dem Problem befasst. Gleich nach dem Meeting habe auch ich versucht, aktiv zu helfen, wo ich konnte. Wir haben die Spieler informiert und gleichzeitig versucht, die richtigen Leute mit zusätzlichen Informationen über die Situation zu versorgen. Selbst das Management hat sich eingeschaltet und uns geholfen, weitere Ressourcen bereitzustellen. Spätestens jetzt waren wir alle voll im Krisenmodus.

Zu allem Überfluss tauchte nun ein weiteres Problem in Form eines ziemlich kritischen Designfehlers unserer NRS-Seite auf. Der RESERVIEREN-Button reagierte nicht auf Klicks und schickte außerdem bei jedem Klick eine Meldung an unsere Single Sign On (SSO) API. Jede dieser Meldungen hatte einen 30-sekündigen Timeout. Wir hatten also durch die ehrlichen Absichten unserer Benutzer einen DDoS-Angriff auf uns selbst inszeniert. Die Panik und Verwirrung von Spielern, die wissen wollten, ob ihre Namen erfolgreich reserviert wurden, erhöhte die Serverlast zusätzlich, da die Leute die Seite weiter bombardierten, um herauszufinden, ob ihre Namensreservierung erfolgreich war.

Wir haben dann zehn Minuten lang einen Fehler ausgegeben, der besagte, dass alle Clients eine Vorbestellung brauchen, und die Seite dann wieder eingeschaltet. Die Zahl der Klicks fiel durch diese Aktion zwar deutlich, ging nach der Reaktivierung der Seite aber endgültig durch die Decke. Jetzt waren wir endgültig davon überzeugt, dass uns irgendwelche übernatürlichen Mächte das Leben schwer machen wollen. Als wir später die Log-Dateien durchsucht haben, wurde dieser Verdacht übrigens bestätigt. Nein, der ganze Schlamassel war natürlich unser Fehler, den wir von Anfang an hätten verhindern sollen.

Während der ganzen Zeit wurde ernsthaft diskutiert, die Seite ganz vom Netz zu nehmen. Wir entschieden uns aber dafür, weiterzumachen, weil wir mittlerweile einige potenzielle Fehlerquellen gefunden hatten, die wir überprüfen wollten. Und das machte sich schließlich bezahlt.
Die Jungs, die das NRS entwickelt hatten, fanden eine falsche Konfigurationseinstellung. Nachdem wir diese korrigiert hatten, erwachten die Amazon AWS-Maschinen und die Datenbank sofort zum Leben und begannen plötzlich, ALLES zu verarbeiten. Die Zahl der in 10 Minuten verarbeiteten Namen stieg von einigen hundert auf mehrere tausend Namen. Das System funktionierte endlich … dachten wir.

Dann begann Phase 3 …

Nur noch mal zur Erinnerung: Es gab zwei Hauptprobleme. Nachdem wir das eine Hauptproblem nun gefunden und behoben hatten, wurde die gesamte Datenlast auf die zweite Schwachstelle verlagert: die F5 Load Balancer unserer Website. Vor der Korrektur der Konfigurationseinstellung war die Leistung unserer Website zwar Schwankungen unterworfen, aber immerhin hatte sie die meiste Zeit funktioniert. Nach der Korrektur wurden die Spieler mit Wartungsfehlern bombardiert, sobald sie versuchten, sich einzuloggen. Allerdings mussten sich alle Benutzer, die einen Namen reservieren wollten, einloggen, damit wir prüfen konnten, ob sie das Spiel vorbestellt hatten.

Zunächst lief die Verarbeitung der Namen ziemlich gut. Zu diesem Zeitpunkt zahlte sich die Beharrlichkeit der Spieler also aus, da sie ihre Namen endlich registrieren konnten. Etwa zur selben Zeit fingen wir an, die Accountverwaltung von WildStar (neue Kunden, die Einlösung neuer Beta-Codes), Aion und Lineage 2 abzuschalten (alle drei Spielen waren nicht betroffen). Es ist eine Sache, unser eigenes Zeug kaputt zu machen, aber wenn man die Systeme anderer Leute lahmlegt, macht man sich keine Freunde.

Nachdem wir die F5s ohne nennenswerten Erfolg neu gestartet hatten, beriefen wir ein weiteres Meeting ein. In diesem Meeting beschlossen wir, die Seite zu schließen. Wir wollten möglichst schnell eine Ersatzseite an den Start bringen. Dazu mussten wir allerdings ordentlich strampeln. Das Community-Team hatte in den Foren gerade einen entsprechenden Beitrag veröffentlicht, als wir feststellten, dass sich die Mitarbeiter im Büro problemlos einloggen konnten.

Unsere F5s hätten die Datenlast die ganze Zeit problemlos verarbeiten müssen (obwohl sie 10 Mal höher war als alles, was wir während der offenen Beta erlebt hatten). Obwohl der Neustart also nicht sofort geholfen hat, führten unsere Beharrlichkeit und der langsame Rückgang des Traffics schließlich dazu, dass die F5s endlich wie vorgesehen funktionierten. Dazu eine interessante Randnotiz: Der Traffic bei unserer Rückkehr ins Büro am Mittwoch Morgen war dreimal höher als der Traffic, den wir hatten, als die F5s Dienstag Nacht endlich zum Leben erwachten, und trotzdem lief alles ohne Probleme. Der Satz „Traffic gesenkt, jetzt haben wir alles im Griff“ greift also nicht.

Nachdem 90 Minuten lang keine Probleme auftraten, beriefen wir das letzte Meeting des Tages ein. Obwohl wir gerade alle Hebel in Bewegung gesetzt hatten, um die Seite abzuschalten, sah es plötzlich so aus, als würde endlich alles funktionieren. Wir beschlossen daher, die Seite nicht abzuschalten, da wir jedes Mal, wenn wir Stichproben durchführten, Tausende von Namen erhielten. Also machten wir Feierabend.

Ich möchte den Entscheidungsprozess bezüglich der Abschaltung der Seite nicht beschönigen. Allerdings waren sämtliche Abteilungen bei diesen Meetings vertreten, die mehr oder minder spontan in den Räumen des Web-Teams abgehalten wurden. Wir haben permanent mit den verschiedenen Abteilungen und Projektverantwortlichen gesprochen. Die Community hat uns mit ihrem Feedback und ihren Empfehlungen weitergeholfen, der Kundendienst hat die Lage aus seiner Perspektive geschildert, die Ops- und Web-Teams haben uns über ihre Fortschritte bei der Lösung der Probleme informiert, und wir kamen alle immer wieder als Team zusammen, um die nächsten Schritte zu besprechen. Ihr habt uns euer Feedback geschickt, und dieses Feedback ist in unsere Meetings eingeflossen. In Echtzeit.

Und so sieht es im Moment aus …

Das NRS funktioniert seit der Behebung der Phase-3-Probleme einwandfrei, und wir arbeiten mittlerweile an den in Phase 2 aufgetretenen Problemen. Das System hat immer noch einige Bugs, die korrigiert werden müssen oder behoben werden, während ihr diesen Artikel lest. Außerdem nehmen wir einige Optimierungen am Seitendesign vor.

Wir wissen, dass einige Leute aus Frust einfach irgendwelche Buchstaben eingegeben haben, von uns Namen mit „ss“ (und einigen anderen Buchstabenkombinationen) fälschlicherweise geblockt wurden, und dass bei Benutzern, die sich einen Computern mit anderen Benutzern teilen, die Session-Token nicht korrekt zurückgesetzt wurden, weshalb einige Namen unter den falschen Accounts gespeichert wurden.

Wir tun unser Bestes, um den Benutzern bei der Behebung ihrer Probleme zu helfen. Unser Support-Team müsste in der Lage sein, euch dabei zu helfen, „Asdfssdf“ in einen beliebigen anderen (noch verfügbaren) Namen umzuwandeln.

Es gibt allerdings eine offene Frage, die ich nicht beantworten kann: Warum haben wir globale Namensreservierungen angeboten? Tja, darauf habe ich im Moment leider keine Antwort. Obwohl ich die Informationen für Gaffs AMA hatte, weiß ich nur, warum wir keine Realm-spezifischen Namen angeboten haben. Der Hauptprogrammierer des Systems macht in China einen wohl verdienten Urlaub, den er vor einem Jahr geplant hat, lange, bevor unser Starttermin feststand. Sprich: Ich kann dazu im Moment nichts sagen.

Ich hoffe, ich habe euch mit diesem Blick hinter die Kulissen nicht gelangweilt. Wir hätte einiges besser machen sollen, und dafür möchte ich mich im Namen des gesamten Teams hier bei Carbine Studios entschuldigen.

LINK

Name Reservation Roll Out Post Mortem (CRB Cougar)
Hey all,

So ya… that didn’t go so well. I think the criticisms levied upon us are justified for Tuesday’s Name Reservation System (NRS) troubles. Gaff and the team wanted me to sit down, and give the community a peek into what the actual issues were that we faced.

I’m not going to make excuses for Carbine, but as many of you can respect, launch is chaotic. While we’ve done some things really well, we obviously didn’t knock the Name Reservation system out of the park. We’ll own our failures as much as we celebrate our successes.

Speaking of our successes, it was one of our successes that gave us a false sense of confidence. Namely, our Open Beta key distribution website (http://wildstar-onli...om/en/openbeta/) worked without a single problem. This was something we put together with duct tape and gumption in a few weeks’ time. We decided how best we could get as many keys to the players as possible, with very few, if any hoops to jump through. No emails, no partners, just make the doors as open as we could. Come to our site, get a key, and get playing.

Our team was poised for the crush of players when we opened the Beta on the 8th, and we didn’t have a single hiccup with that system at all. We’ve processed hundreds of thousands of keys and had a ton of concurrency on that website, and it always held up under the load. Some tech context; we are hosting most of the guts of the key distribution page (and our Name Reservation System) on Amazon AWS instances. So, we were prepared to scale up as need be, but at that time we just didn’t need to. Everything seemed fine.

What happened Tuesday was a series of events starting with the release of our Raids DevSpeak early in the morning. The team pushed that out the door, and then switched gears to ready themselves to publish the NRS webpage. In hindsight, this was a Bad Plan™. Our QA team was already stretched thin in order to get both pages tested on the already-tight, pre-launch deadlines. With the raids drop we drove lots of traffic to our site, and encouraged players to download the various multimedia assets we had available for them. We also published a 13MB banner asset on the WildStar-online homepage.

Phase 1 -

We published the page at 11am PDT as scheduled, and within minutes, the site buckled. We are gamers too; we knew everyone would be waiting for the moment it would be published. We had the NRS on the Amazon AWS and were ready to jump into action to give it more power. We just underestimated the impact the new 13MB banner asset would have on our web servers ability to push that data to all of our clients. This of course was compounded by everyone that was already on the site from the Raids Dev Speak, and everyone that was waiting for the NRS to go live.
Weeks prior, I had scheduled a five hour Operations meeting to go over our launch plans via a “Table Read” meeting. Shortly after 11am team members started getting called out of that meeting in order to deal with the NRS issues. I knew something was really wrong when Gaff, and our main web guy walked in with long faces. It was decided that we would take down the page for 90 minutes to see if we could get on top of the load issues.

We corrected this ‘Phase 1’ problem by putting the 13MB banner asset, and as many of our other video assets, on our CDN, and we brought everything back up at 1pm PDT, the website itself held under the load, but then revealed the next problem.

Phase 2 -

This phase was difficult for us. It turns out we had two different failure points, which made troubleshooting extremely difficult. Team A couldn’t find the problems, and thought that Team B could solve it. Team B couldn’t find the problems, and thought Team A could solve it. Truth is that there were problems on both sides, and that made things REALLY BAD for the players.

While both teams worked together, more and more people started to get involved. As soon as my meeting ended, I started actively helping out where I could. We got the message out to the players while trying to get the right people additional data on what was going on. Management was interested, and helping assess and leverage resources where needed. At that point, we were in full crisis mode.

Another problem that reared its ugly head, was that we had a pretty critical design flaw in our NRS page. The RESERVE button had no feedback for being clicked, and also sent a call to our Single Sign On (SSO) API for each click. Each of these had a 30s time out. We sort of DDoS’d ourselves through the honest actions of our users. Panic and confusion from clients as to if their names were successfully reserved added to the load, as people who would get through would stay hammering on the site trying to find out if it worked or not.

We briefly threw up an error for ten minutes that said all clients needed a pre-order, and then switched it back. Our clicks immediately dropped by a significant margin, and then immediately skyrocketed when it came back. At that point we were confident that we were dealing with some non-human activity making life harder for us. When searching the logs later on, we found this to be true – mind you, this is still our fault, we should have prevented this from the get go.

During all of this, there was serious discussion about whether to take the page down or not. We decided to keep going, as we had a few potential leads that were being actively investigated. One of them panned out.

The guys who made the NRS found a bad configuration setting. Once fixed, almost immediately the Amazon AWS machines, and the database came back to life and started processing ALL THE THINGS. We went from processing a few hundred names over a span of 10 minutes to a few thousand over the same time frame. It was starting to work…or so we thought.

Cue Phase 3….

If you remember, there were two major problems. Now that we found and corrected the one major problem, the entire load slammed into the remaining weak point; our website’s F5 load balancers. Before we corrected the configuration setting, our website’s performance was intermittent but it was working more often than not. As soon as the configuration change took, we were throwing maintenance errors to the users when they tried to login. Users wanting to reserve a name needed to login so we could check that they’d pre-ordered the game.

We started to process names at a good rate, so at this point persistence by the users was paying off in successful name registrations. It was also the time that we started taking down the account management of WildStar (new customers, Open Beta key redemptions), Aion, and Lineage 2 (all three games were unaffected). It is one thing to break our own stuff, but breaking someone else’s stuff does not a good corporate citizen make.

We rebooted the F5’s with no positive gains, and then called another meeting. It was here that we made the decision to take the page down. We wanted to get a replacement page up and localized. We had to scramble to start making that happen. The Community Team made their post on the forums, and we noticed that people around the office were logging in just fine.

Our F5’s should have always been able to have handled the load we saw (even if it was 10 times greater than anything we’d seen in Open Beta so far). So while the reboot didn’t immediately help, continual mucking with them, combined with a gradual decrease in traffic, allowed the F5’s to finally start working as they should have been. Interesting to note; the traffic we had when we got back in the office on Wednesday morning was three times what we had when the F5’s finally came back to life Tuesday night, and were running perfectly at that load. So it isn’t simply a case of “traffic subsided; now we can handle it.”

After running solid for 90 minutes, we called the final meeting of the day. Even though we had just scrambled to pull in resources from all over to take down the page, it looked like everything was working. We decided to keep the page up since every time we checked, we were gaining thousands of names, and called it a night.

I don’t mean to gloss over the decision making process about whether to keep going or to take it down. We had every discipline in these war room meetings, which were mostly stand-ups in and around the Web Team’s area. We polled the various disciplines/stakeholders each time. Community was educating us all on the feedback and their recommendation, Customer Support was reporting in from their perspective, Ops and Web weighed in on their progress towards resolutions, Brand had their input, and we all came together as a team to make the calls. You guys gave us your feedback, and that feedback got into those war room meetings. In real time.

Where we’re at now –

The NRS has been humming along perfectly since Phase 3 was resolved, and now we get to fix all of the problems caused during Phase 2. There are still a few bugs in the system that need correcting, or might be corrected by the time this is published. We have a few site design optimizations going in.

We know that there are people out there frustrated with the poor experience and just randomly typed in letters, that we are incorrectly blocking names with “ss” (and a few other letter combinations), and that there are people who were sharing computers whose session token wasn’t correctly clearing between users, causing names to be saved on the wrong accounts.

We will do what we can to help users resolve their problems. Our support team should have all the tools they need to help you change “Asdfssdf” to whatever name that is still available to you.

I think the one unanswered question that I cannot answer is, why we chose to do global name reservations? And the answer is that I don’t know at this time. Even though I had the information for Gaff’s AMA, I only know why we didn’t do realm specific names. The main engineer who designed the system is in China on a well-deserved vacation he had planned a year ago, before our launch date was finalized. So I don’t have an answer at this time.
I hope I haven’t bored you with this look behind the curtain. We should have done better, and for that you have my apologies, and that of the team here at Carbine Studios.

LINK
Theddy gefällt das!
6 Kommentare
0
DISKUSSION
editieren nicht länger möglich
done
error
  • jace
    jace
    22. Mai, 2014
    Carbine
  • Calaban
    Calaban
    20. Mai, 2014
    Es ist definitiv eine offenere Kommunikation als man von anderen Publishern/Studios gewohnt ist.
  • Yps
    Yps
    20. Mai, 2014
    Huch, ich hab doch schon einmal eines gelöscht. Die anderen 3 hab ich gar nicht gesehen.
  • Eruanne
    Eruanne
    20. Mai, 2014
    So gut, dass du gleich 3mal postest Yps

    Ich find den Artikel auch super. Dadurch bekommt man etwas mehr Einblick und Verständnis. Weiter so Carbine. :nailbiting: Der bittere Beigeschmack zum Thema bleibt allerdings.
  • Yps
    Yps
    20. Mai, 2014
    Japp. Ich finde es auch sehr gut, dass sie uns da einen Einblick gewähren!
  • ooky
    ooky
    19. Mai, 2014
    Ich weiss nicht, aber diese News macht die Firma bei mir noch sympathischer als sie es eh schon ist.