Wie einige von Ihnen wissen, war PagerDuty heute Morgen insgesamt 15 Minuten lang nicht erreichbar. Die Zuverlässigkeit unserer Systeme liegt uns am Herzen. sehr Wir meinen es ernst und schreiben Ihnen dies, um Ihnen vollständig offenzulegen, was passiert ist, was wir falsch gemacht haben, was wir richtig gemacht haben und was wir tun, um dies in Zukunft zu verhindern.

Wir möchten uns außerdem für den Ausfall entschuldigen. Wir haben in den letzten sechs Monaten intensiv an der Umgestaltung unserer Systeme gearbeitet, um sie vollständig ausfallsicher zu machen. Wir sind dem Ziel schon sehr nahe, aber noch nicht ganz erreicht. Lesen Sie weiter, um alle Details und die Maßnahmen zu erfahren, die wir ergreifen, um sicherzustellen, dass dies nie wieder vorkommt.

Hintergrund

Die Hauptsysteme von PagerDuty werden auf Amazon Web Services EC2 gehostet. AWS kennt das Konzept der „Verfügbarkeitszonen“ (Availability Zones, AZs), in denen Hosts unabhängig von Hosts in anderen Verfügbarkeitszonen innerhalb derselben EC2-Region ausfallen sollen.

PagerDuty nutzt diese Verfügbarkeitszonen und verteilt seine Hosts und Datenspeicher auf mehrere Verfügbarkeitszonen. Im Falle eines Ausfalls einer einzelnen Verfügbarkeitszone kann PagerDuty den Datenverkehr schnell auf eine verbleibende Verfügbarkeitszone umleiten und so eine rasche Wiederherstellung erreichen.

Es ist jedoch offensichtlich, dass es viele Situationen gibt, in denen alle Verfügbarkeitszonen einer EC2-Region gleichzeitig ausfallen. Erfahrungsgemäß treten solche Situationen etwa alle sechs Monate auf. Ein solcher regionsweiter Ausfall ereignete sich heute Morgen früh, als AWS in der gesamten Region US-East-1 gleichzeitig mit Internetverbindungsproblemen zu kämpfen hatte.

Der Ausfall

PagerDuty war heute Morgen um 2:27 Uhr nicht mehr erreichbar.

Da Ausweichlösungen innerhalb anderer Verfügbarkeitszonen nicht ausreichen, betreibt PagerDuty eine weitere, voll funktionsfähige Replik seines gesamten Stacks in einem anderen (völlig unabhängig betriebenen) Rechenzentrum. Wir leiteten die Umschaltung auf diese Replik ein, nachdem wir über das Problem mit EC2 informiert wurden und sich herausstellte, dass EC2 einen regionsweiten Ausfall hatte.

Um 2:42 Uhr (15 Minuten nach Beginn des Ausfalls) war die EC2-Region US-East-1 wieder verfügbar, und unsere Systeme begannen umgehend, die eingehenden API- und E-Mail-basierten Ereignisse abzuarbeiten. Dadurch wurden zahlreiche Benachrichtigungen an unsere Kunden versendet. Daraufhin brachen wir die Umschaltung auf unser Ausweichsystem für externe Benachrichtigungen ab.

Was wir falsch gemacht haben

Fünfzehn Minuten scheinen eine lange Zeit zu sein, zwischen dem Beginn unseres Ausfalls und dem Zeitpunkt, an dem wir die Umschaltung durchführen. Und das sind sie auch.

Wir nutzen mehrere externe Überwachungssysteme, um PagerDuty zu überwachen und uns bei Problemen benachrichtigen zu lassen (wir selbst können PagerDuty leider nicht nutzen). Nach genauer Prüfung stellten wir fest, dass die Benachrichtigungen dieser Systeme einige Minuten verzögert eintrafen. Daher reagierten wir einige Minuten zu spät auf den Ausfall.

Dies ist selbstverständlich ein Punkt, den wir schnellstmöglich beheben müssen. Jede Minute zählt. Wir wissen, wie wichtig sie Ihnen ist. Wir werden unsere Überwachungssysteme umgehend umstellen oder erweitern.

Ein weiterer Fehler unsererseits war, dass wir Sie nicht alle sofort über unseren Notfall-Massenrundfunkdienst über den Ausfall informiert haben (siehe https://support.pagerduty.com/entries/21059657-what-if-pagerduty-goes-down Dies beruhte auf einem internen Missverständnis bezüglich des angemessenen Einsatzes dieses Systems. Wir werden in Kürze einen weiteren Blogbeitrag veröffentlichen, der detailliert beschreibt, wie wir dieses System zukünftig nutzen, und Sie daran erinnert, wie Sie sich dafür registrieren können.

Was wir richtig gemacht haben

Wir haben bereits Maßnahmen ergriffen, um diese groß angelegten EC2-Ereignisse im Bedarfsfall abmildern zu können.

Ein solcher Schritt ist die Existenz unserer extern gehosteten PagerDuty Ausweichumgebung. Dies ist eine (kostspielige) Lösung für dieses seltene Problem. Wir führen regelmäßig interne Notfallübungen durch, in denen wir das Umschalten auf diese Umgebung testen und üben. Wir werden diese Übungen fortsetzen.

Um diese großflächigen EC2-Ereignisse abzumildern, haben wir außerdem sichergestellt, dass unsere Systeme die extrem hohen Datenverkehrsmengen bewältigen können, die auftreten, wenn ein Drittel unserer Kunden (alle auf EC2 gehosteten) gleichzeitig ausfällt. In den letzten sechs Monaten haben wir unsere Systeme umfassend verbessert: Sie verarbeiten Ereignisse nun schnell, reduzieren die Last bei hohem Datenverkehr intelligent, um den Betrieb aufrechtzuerhalten, und stellen sicher, dass kein Kunde versäumt wird, benachrichtigt zu werden. Diese Systeme haben heute Morgen einwandfrei funktioniert und weitere Verzögerungen bei der Alarmierung verhindert.

Was wir tun werden

Ein Systemwechsel, egal wie schnell, führt zu Ausfallzeiten. Das ist sehr ärgerlich. Wir arbeiten intensiv an unserer internen Umstrukturierung, um vollständig auf ein Benachrichtigungssystem umzustellen, das keine temporären Single Points of Failure (SPOF) aufweist, selbst wenn diese SPOF „das gesamte EC2-Netzwerk im Osten“ betrifft.

Unser neues System nutzt einen geclusterten Multi-Node-Datenspeicher, der auf mehreren Hosts in verschiedenen unabhängigen Rechenzentren unterschiedlicher Hosting-Anbieter bereitgestellt wird. Das neue System übersteht einen Rechenzentrumsausfall ohne jegliche Umstellung. Wir verzichten also komplett auf Umstellungen (denn „Umstellung“ bedeutet ja bekanntlich „Ausfall“). Wir arbeiten mit Hochdruck an der Entwicklung und schnellstmöglichen Bereitstellung dieses neuen Systems und gewährleisten gleichzeitig die Stabilität während der Umstellung. Diese Umstellung ist recht umfangreich, daher bitten wir Sie um Verständnis, dass wir vorübergehend einige Lösungen anbieten müssen.

Im Rahmen unserer internen Nachbesprechung heute Morgen haben wir einige Stellen identifiziert, an denen wir die Verfügbarkeit unserer externen Ereignis-Endpunkte umgehend verbessern können. Dazu gehört der Aufbau einer besseren Redundanz sowohl unseres E-Mail-Endpunkts als auch unseres API-Endpunkts. Diese Änderungen haben für uns höchste Priorität.

Wir prüfen derzeit auch die Möglichkeit, unsere primären Systeme von AWS US-East zu verlagern. Kurzfristig werden wir US-East weiterhin in gewissem Umfang nutzen (möglicherweise als sekundären Anbieter). Längerfristig werden wir alle unsere kritischen Systeme vollständig von AWS abziehen.

Abschließend möchten wir, wie bereits erwähnt, unsere Überwachungssysteme verbessern. Unsere externen Webüberwachungssysteme haben Warnmeldungen zu langsam übermittelt, und wir werden dies schnellstmöglich beheben. Wir werden außerdem unser Twitter-basiertes Notfallbenachrichtigungsverfahren optimieren, mit dem wir Sie über interne Probleme informieren können. In den nächsten Tagen erscheint dazu ein weiterer Blogbeitrag.