- Der 36-stündige Ausfall von CookieRun: Kingdom – der längste in der Geschichte von Devsisters
- Als zentrale verteilte DB wurde CockroachDB eingesetzt: 4 Nodes, 12 TB Storage, 7 Replikate
- Während einer Datenbank-Skalierung fiel die Hälfte der Nodes aus
- Dadurch kam es zu einem vollständigen Ausfall des gesamten Dienstes; der Support Engineer von CockroachDB kam zu dem Schluss, dass eine Wiederherstellung unmöglich sei
- Daher fasst dieser Beitrag die Bemühungen zusammen, die unternommen wurden, um die auf dem Storage gespeicherten Daten selbst aufzuspüren
24 Kommentare
Das ist wirklich ein besonders umstrittener Beitrag, oder..? Ich weiß nicht, wie es aus Sicht des Services wäre, aber die Entwickler, die daran gearbeitet haben, waren bestimmt unglaublich stolz.
Ich weiß nicht, wie die Nutzer darauf reagiert haben, aber allein dafür, dass man sich bemüht hat, einen Rollback des Servers zu verhindern, würde ich als Nutzer ein Lob aussprechen. Wenn man jedoch an die Nutzerabwanderung und die Kundenerfahrung in diesen 36 Stunden denkt, könnte der Schaden am Ende größer gewesen sein. Aus Entwicklersicht war es aber wohl eine interessante Herausforderung. Wie wäre es wohl gewesen, wenn das Unternehmen keine Spielefirma, sondern eine Bank gewesen wäre?
Es heißt, dass Pokémon Go Spanner von GCP verwendet (https://cloud.google.com/blog/topics/…), aber auf AWS scheint es keine wirklich passende Alternative zu geben.
Wenn man die Absicht des Entwicklungsteams auf Grundlage dieses Dokuments nachvollzieht, hätte in diesem Projekt CockroachDB wohl nicht verwendet werden sollen.
Welche DB hätte man verwenden sollen?
Je nach Dienst kann der Inhalt ziemlich beklemmend sein.
Hat Spaß gemacht, das zu lesen.
Wie ich sehe, hat der betreffende Blog zu diesem Ausfall eine ganze Artikelserie veröffentlicht. Als ich alles der Reihe nach gelesen habe, war ich besonders davon beeindruckt, was für ein mentaler Zusammenbruch die Leute erlebt haben müssen, die das wieder in Ordnung bringen sollten.
Ich bin mir nicht sicher, ob es aus geschäftlicher Sicht wirklich die richtige Entscheidung war, statt eines Rollbacks, das die Erfahrung einiger Nutzer beeinträchtigt und die Mehrheit schützt, über 36 Stunden hinweg alle Nutzerdaten wiederherzustellen. Aus Entwicklersicht ist der Inhalt aber interessant.
Im Haupttext steht Folgendes.
Unsere Mission war es, den Kundinnen und Kunden die bestmögliche Erfahrung zu bieten, und wir haben uns aufrichtig bemüht, das in die Praxis umzusetzen. Niemand ließ sich entmutigen oder gab auf.
Dass ich so etwas auch hier zu hören bekomme – dass man wegen des Geldes einige Nutzer ruhig fallenlassen könne –, zeigt mir erneut, wie in der koreanischen Spielebranche mit den Nutzern umgegangen wird.
Das scheint mir eine zu verdrehte Sichtweise zu sein, und rückblickend betrachtet hätte man, wenn das Problem nicht gelöst worden wäre, nur Zeit verschwendet und sich wegen des Rollbacks zusätzlich Vorwürfe eingehandelt.
Und auch der Blickwinkel, dass man die Nutzer in dieser Zeit im Stich lässt, wenn der Service nicht verfügbar ist, bleibt derselbe.
Dem stimme ich sehr, sehr nachdrücklich zu ...
Aus Entwicklersicht war das äußerst spannend zu lesen (einschließlich des reißerischen Titels), aber ich habe es auch aus einer ähnlichen Perspektive betrachtet. Da es sich um Inhalte aus einem schon etwas älteren Artikel handelt, kann es Unterschiede zur Realität geben, aber der Umsatz von CookieRun: Kingdom scheint über 300 Milliarden Won zu liegen, also war es wohl eine Entscheidung, bei der man den auf 36 Stunden Downtime umgerechneten erwarteten Umsatz mit der Höhe der Entschädigungszahlungen nach dem Rollback verglichen hat.
Ich denke, dass auch eine Organisation, in der eine stark auf Problemlösung ausgerichtete Entwicklerkultur herrscht, einen gewissen Einfluss darauf hatte.
Ich weiß immer noch nicht genau, welche Entscheidung ich selbst getroffen hätte.
Heutzutage ist ein Rollback in Spielen – insbesondere in Spielen mit zufallsbasierten Zieh-/Gacha-Mechaniken – wirklich nur im allerschlimmsten Fall einsetzbar … Es ist praktisch unmöglich, außer man kümmert sich wie Spiel L nicht um sein Image. Gerade in diesem Fall hat man nach meiner Erinnerung stattdessen bewusst auf ein Rollback verzichtet und später großzügige Entschädigungen vergeben, sodass die Nutzer sogar scherzhaft meinten: Wenn uns die In-Game-Währung ausgeht, crasht dann vielleicht der Server noch einmal? Ich finde, das war die richtige Entscheidung.
Da es um ein Spiel ging, hätte ein Rollback um 36 Stunden wegen Cache-Problemen vermutlich auch zu erheblichen finanziellen Verlusten führen können.
Ich stimme dafür, dass das geschäftlich wohl keine richtige Entscheidung war.
Ein unbeabsichtigter Konfigurationsfehler (das ist der kritischste und absurdeste menschliche Fehler. Auf diese Weise einen gravierenden Eingriff zu verursachen, der die Replik nicht mehr funktionsfähig macht – selbst wenn man alle Entwickler des DB-Designs zusammenholt, ist das nicht wiederherstellbar)
Also konnte man die Daten nicht einfach komplett verlieren lassen ... Also wurde, selbst unter Verzicht auf die Konsistenz der neuesten Daten, direkt nach den zuletzt gespeicherten DB-Daten im binären Format gesucht (7 TB), um diese in CSV umzuwandeln, und dafür ein Go-Programm geschrieben ... ?
Selbst wenn man so ein Go-Programm für die Konvertierung noch so gut baut – welchen Sinn hat das eigentlich ...
Puh ... Allein der Gedanke daran ist schon bedrückend. Warum musste es überhaupt so weit kommen ...
Am wichtigsten ist wohl, die Prozesse so zu verschärfen, dass solche menschlichen Fehler gar nicht erst passieren. Von den Mühen bei der Störungsbehebung und der binären Konvertierung sollte man besser gar nicht erst anfangen.
Gibt es noch einen besonderen Grund, warum man solche Geschichten nicht erzählen sollte? Schon die Veröffentlichung eines Postmortems an sich ist doch sinnvoll.
Meiner Ansicht nach müsste der Titel, wenn man wirklich einen hilfreichen Artikel schreiben wollte, nicht eher so lauten?
„Analyse der Ursachen und Lehren aus einem Fehler, der durch eine Fehlkonfiguration der Node-Einstellungen dazu führte, dass kein Cluster aufgebaut werden konnte“
So einen Text kann man separat schreiben; die „Analyse der Störungsursache“ und der „Prozess der Störungsbehebung“ sind eigene Themen, und beide sind wichtig. Deshalb ist es schwer nachzuvollziehen, warum man den Wert des Artikels abwertet, nur weil die „Analyse der Störungsursache“ gefehlt hat...
Man könnte doch einfach sagen, dass es noch besser wäre, wenn auch ein Folgeartikel zur Ursachenanalyse geschrieben würde. Aber schon vorher zu sagen, der Beitrag sei wertlos, ist keine gute Haltung.
Genau genommen war das kein „Prozess zur Behebung einer Störung“, sondern vielmehr Knochenarbeit zur „Wiederherstellung unvollständiger Daten“. Es hat nur den Umfang des Verlusts etwas reduziert? Etwa so.
Wo steht im obigen Artikel, dass die Datenwiederherstellung „unvollständig“ gewesen sei? Zumindest dem Inhalt des Artikels nach wurde die vollständige Wiederherstellung erfolgreich abgeschlossen. Und wenn die Wiederherstellung einer zerschossenen DB keine Störungsbehebung ist, was dann? Wurde der betreffende Dienst nach diesem Vorfall unverändert eingestellt?
Das ist doch kein Grund, diese Geschichte nicht zu erzählen, oder?
Sie machen sich das Leben wirklich schwer.