Wie einige von Ihnen wissen, war PagerDuty heute Morgen für insgesamt 15 Minuten ausgefallen. Wir nehmen die Zuverlässigkeit unserer Systeme sehr ernst und wir schreiben Ihnen dies, um Ihnen vollständige Offenlegung darüber zu geben, was passiert ist, was wir falsch gemacht haben, was wir richtig gemacht haben und was wir tun, um dazu beizutragen, dies in Zukunft zu verhindern.

Wir möchten Sie auch wissen lassen, dass wir diesen Ausfall sehr bedauern. Wir haben in den letzten 6 Monaten hart daran gearbeitet, unsere Systeme so umzugestalten, dass sie vollständig fehlertolerant sind. Wir sind verlockend nah dran, aber noch nicht ganz am Ziel. Lesen Sie weiter, um alle Einzelheiten und Schritte zu erfahren, die wir unternehmen, um sicherzustellen, dass dies nie wieder passiert.

Hintergrund

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

PagerDuty nutzt diese Verfügbarkeitszonen und verteilt seine Hosts und Datenspeicher auf mehrere AZs. Bei einem Ausfall einer einzelnen AZ kann PagerDuty sich schnell erholen, indem der Verkehr sehr schnell auf eine überlebende AZ umgeleitet wird.

Es ist jedoch ziemlich offensichtlich, dass es viele Situationen gibt, in denen alle Availability Zones in einer bestimmten EC2-Region gleichzeitig ausfallen. Erfahrungsgemäß treten solche Situationen etwa alle 6 Monate auf. Ein solcher regionsweiter Ausfall ereignete sich heute früh, als AWS gleichzeitig in der gesamten Region US-East-1 Probleme mit der Internetverbindung hatte.

Der Ausfall

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

Da Fallbacks innerhalb anderer AZs nicht ausreichen, verfügt PagerDuty über eine weitere voll funktionsfähige Replik seines gesamten Stacks, die in einem anderen (völlig unabhängigen) Rechenzentrum ausgeführt wird. Wir begannen mit dem Verfahren, auf diese Replik umzusteigen, nachdem wir über das Problem mit EC2 informiert wurden und klar wurde, dass EC2 einen regionenweiten Ausfall hatte.

Um 2:42 Uhr (15 Minuten nach Beginn des Ausfalls) tauchte die Region US-East-1 von EC2 wieder auf und unsere Systeme begannen, den Rückstand an eingehenden API- und E-Mail-basierten Ereignissen schnell zu verarbeiten, wodurch eine große Anzahl ausgehender Benachrichtigungen an unsere Kunden entstand. An diesem Punkt brachen wir den Wechsel zu unserem Fallback-Stack für externe Benachrichtigungen ab.

Was wir falsch gemacht haben

Fünfzehn Minuten zwischen dem Beginn unseres Stromausfalls und dem Zeitpunkt, an dem wir unseren Flip durchführen, scheinen eine lange Zeit zu sein. Und das ist es auch.

Wir verwenden mehrere externe Überwachungssysteme, um PagerDuty zu überwachen und uns alle zu benachrichtigen, wenn Probleme auftreten (leider können wir PagerDuty nicht selbst verwenden!). Nach sorgfältiger Prüfung wurden die Warnungen dieser Systeme um einige Minuten verzögert. Infolgedessen reagierten wir einige Minuten zu spät auf den Ausfall.

Dies ist natürlich ein Aktionspunkt, den wir so schnell wie möglich beheben müssen. Diese Minuten zählen. Wir wissen, dass sie für Sie sehr wichtig sind. Wir werden uns so schnell wie möglich um die Umstellung oder Erweiterung unserer Überwachungssysteme kümmern.

Ein weiteres Versäumnis unsererseits war, Sie alle nicht sofort über unseren Ausfall über unser Notfall-Massenrundfunksystem zu informieren (siehe http://support.pagerduty.com/entries/21059657-what-if-pagerduty-goes-down ). Dies lag an einer internen Fehlkommunikation darüber, wann die Verwendung dieses Systems angemessen ist. Wir werden in Kürze einen weiteren Blogbeitrag veröffentlichen, in dem wir genau beschreiben, wie wir dieses System in Zukunft verwenden, und eine Erinnerung daran geben, 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 bei ihrem Eintreten eindämmen zu können.

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

Ein weiterer Schritt, den wir unternommen haben, um diese groß angelegten EC2-Ereignisse abzumildern, besteht darin, sicherzustellen, dass unsere Systeme das sehr hohe Datenaufkommen bewältigen können, das auftritt, wenn ein Drittel unserer Kunden (alle auf EC2 gehosteten) gleichzeitig ausfallen. Wir haben in den letzten 6 Monaten viele Verbesserungen an unseren Systemen vorgenommen: Unser System stellt Ereignisse jetzt schnell in die Warteschlange, reduziert die Last bei hohem Datenverkehr auf intelligente Weise, um den Betrieb aufrechtzuerhalten, und stellt absolut sicher, dass keiner unserer Kunden eine Pager-Nachricht erhält. Diese Systeme haben heute Morgen sehr gut funktioniert und weitere Verzögerungen bei der Alarmierung verhindert.

Was wir tun werden

Ein Wechsel, egal wie schnell, bringt Ausfallzeiten mit sich. Das hinterlässt bei uns einen bitteren Nachgeschmack. Wir arbeiten (hart!) an unserer internen Neuarchitektur, um vollständig auf ein Benachrichtigungsverarbeitungssystem umzusteigen, das KEINE temporären Single Points of Failure beinhaltet, selbst wenn dieser SPOF „ganz EC2 Ost“ ist.

Unser neues System wird einen geclusterten Multi-Node-Datenspeicher verwenden, der auf mehreren Hosts in mehreren unabhängigen Rechenzentren bei unterschiedlichen Hosting-Anbietern bereitgestellt wird. Das neue System wird einen Rechenzentrumsausfall ohne jegliche Flips überstehen. Ganz richtig, wir verzichten auf Flips (weil das Wort „Flip“ gleichbedeutend mit „Ausfall“ ist). Wir arbeiten mit Hochdruck daran, dieses neue System aufzubauen und es so schnell wie möglich bereitzustellen, während wir gleichzeitig sicherstellen, dass wir während der Umstellung stabil bleiben. Dieser Reengineering-Aufwand ist ziemlich umfangreich, also machen Sie sich auf ein paar kurzfristigere Lösungen gefasst.

Während unserer internen Nachbesprechung heute Morgen haben wir einige Stellen identifiziert, an denen wir die Verfügbarkeit unserer externen Ereignisendpunkte sofort verbessern können. Dazu gehört der Einbau besserer Redundanz in unseren E-Mail-Endpunkt sowie unseren API-Endpunkt. Diese Änderungen priorisieren wir ganz oben auf der Liste.

Wir prüfen auch genauer, wie wir unsere primären Systeme von AWS US-East abziehen können. Kurzfristig werden wir US-East in gewissem Umfang weiter nutzen (vielleicht als sekundärer Anbieter). Längerfristig werden wir alle unsere kritischen Systeme vollständig von AWS abziehen.

Und schließlich werden wir, wie oben erwähnt, unsere eigenen Überwachungssysteme verbessern. Unsere externe Webüberwachung hat uns Warnmeldungen zu langsam übermittelt, und wir werden das so schnell wie möglich beheben. Wir werden auch unser Twitter-basiertes Notfallübertragungsverfahren verbessern, das uns hilft, Sie zu benachrichtigen, wenn wir interne Probleme haben. In den nächsten Tagen werden wir einen weiteren Blogbeitrag dazu veröffentlichen.