Ein latenter Fehler verwandelte Gmails routinemäßige Wartung im Rechenzentrum in einen dreistündigen weltweiten Ausfall

Am 24. Februar 2009 fiel Gmail für Nutzer weltweit aus. Googles Vorfallbericht für seine Apps-Kunden bezifferte die Störung auf etwa 9 bis 12 Uhr GMT – rund drei Stunden –, wobei die Wiederherstellung gestaffelt erfolgte, sodass einzelne Nutzer unterschiedlich lange keinen Zugriff hatten. Es gingen keine Daten verloren.

Der Mechanismus war das Zusammenspiel zweier jüngster Entscheidungen. Google hatte neue Software bereitgestellt, um zu optimieren, wo Nutzerdaten gespeichert sind. An jenem Morgen begannen Techniker mit routinemäßigen Wartungsarbeiten in einem europäischen Rechenzentrum – ein Vorgang, der unsichtbar bleiben sollte, da der Traffic automatisch an andere Standorte verlagert wird. Doch die Verlagerung aktivierte einen latenten Fehler im neuen Code zur Datenlokalität: Das Ziel wurde überlastet, und da der Traffic automatisch erneut verlagert wurde, breiteten sich die Überlastungen stromabwärts von Rechenzentrum zu Rechenzentrum aus. Die Techniker brauchten etwa eine Stunde, um die Kaskade unter Kontrolle zu bringen, und länger, um alles wieder ins Gleichgewicht zu bringen.

Google ging mit der Nachbereitung für die damalige Zeit ungewöhnlich offen um: Gmail-Site-Reliability-Manager Acacio Cruz erklärte die Kaskade noch am selben Tag im offiziellen Gmail-Blog, und Google veröffentlichte einen formellen Vorfallbericht für Apps-Kunden. Außerdem verpflichtete sich das Unternehmen, etwas aufzubauen, das es für den Dienst noch nicht gab – ein öffentliches Status-Dashboard –, und erkannte damit an, dass ein Cloud-Anbieter seinen Kunden während eines Ausfalls schnelle Informationen schuldet, nicht nur Schweigen und eine Fehlerbehebung.

Gmail war am 24. Februar 2009 bis zu drei Stunden lang nicht erreichbar, wobei sich die Wiederherstellung je nach Rechenzentrum staffelte; es gingen keine Daten verloren

Der Failover-Pfad – der Traffic wurde auf ein zweites Rechenzentrum verlagert – war nicht gegen die neue Software zur Datenlokalität getestet worden, sodass der latente Fehler erst während der Wartung ausgelöst wurde.

Die Reaktion auf die Überlastung verstärkte den Ausfall: Da die Nutzer automatisch erneut verlagert wurden, traf jedes Ziel auf dieselbe Überlastungsbedingung, wodurch sie sich stromabwärts ausbreitete.

Das Wartungskonzept ging von sauberen Übergaben zwischen Rechenzentren aus, doch der neue Optimierungscode veränderte die Annahmen, auf denen der Failover aufgebaut war.

Die Kommunikation hinkte dem Vorfall hinterher: Googles eigene Nachanalyse räumte ein, dass Ausfälle schnell bestätigt werden müssen, was direkt zum Apps-Status-Dashboard führte.

Failover-Pfade verdienen ebenso viel Tests wie die primären Pfade: Neuer Code, der die Datenlokalität neu ordnet, verwandelte eine routinemäßige Wartung in eine Kaskade. Und ein Cloud-Ausfall erfordert einen veröffentlichten Vorfallbericht.

Google behob den Fehler und spielte Änderungen ein, veröffentlichte den Vorfallbericht und startete Wochen später das Google Apps Status Dashboard, wodurch die öffentliche Kommunikation bei Ausfällen institutionalisiert wurde. Die „gfail“-Episode wurde zu einer frühen Vorlage für die Berichterstattung über Cloud-Vorfälle – ein formeller, kundengerichteter Bericht über Ursache und Behebung – zu einer Zeit, in der die meisten Consumer-Webdienste überhaupt keine Erklärung boten.