Wie Sie vielleicht bereits wissen, war PagerDuty gestern 30 Minuten lang ausgefallen, woraufhin es zu einer Phase mit längeren Alarmübermittlungszeiten kam. Wir nehmen die Ausfallzeit sehr ernst, insbesondere angesichts der Tatsache, dass sie sich mit Ausfallzeiten überschnitt, mit denen viele unserer Kunden zu kämpfen hatten.

Bitte haben Sie Verständnis dafür, dass wir keine Schuld auf andere schieben wollen, es aber zu unseren Prozessen gehört, Verständnis für etwaige gravierende Ausfälle zu haben und offen damit umzugehen.

Was geschah: Der Ausfall

PagerDuty wird derzeit auf Amazon Web Services (AWS) gehostet Elastischer Computing-Cluster (EC2). Eine der attraktivsten Funktionen von AWS sind „Availability Zones“. Dabei handelt es sich um „unterschiedliche Standorte, die so konzipiert sind, dass sie vor Ausfällen in anderen Availability Zones geschützt sind und eine kostengünstige Netzwerkverbindung mit geringer Latenz zu anderen Availability Zones in derselben Region bieten“.

Wie viele Anwendungen mit hoher Verfügbarkeit verwendet PagerDuty mehrere Verfügbarkeitszonen, um unsere Anwendung vor Ausfällen auf Rechenzentrumsebene zu schützen. Die Hochgeschwindigkeits-Inter-AZ-Netzwerke von AWS ermöglichen es uns, jedes Ereignis, jede Benachrichtigung und jeden Vorfall, den wir verarbeiten, synchron an mindestens zwei physisch getrennte Standorte zu replizieren. Unter normalen Umständen können wir im Falle eines AZ-weiten (d. h. Rechenzentrums-)Ausfalls den gesamten Datenverkehr innerhalb von 60 Sekunden auf eine der überlebenden AZs umleiten, ohne dass eingehende Ereignisse verloren gehen.

Leider funktionierte das System gestern nicht wie geplant. Wir freuen uns schon darauf, die offizielle Nachbesprechung von AWS zu lesen, aber unsere eigene Untersuchung zeigt, dass mindestens drei nominell unabhängige AZs in US-East-1 gleichzeitig für 30 Minuten vom Internet getrennt waren. Dadurch hatten wir keine Hardware mehr, um eingehende Ereignisse anzunehmen oder Benachrichtigungen für Ereignisse zu versenden, die wir bereits erhalten hatten.

Was geschah: Die Folgen

Der regionale Ausfall von EC2 betraf einen großen Teil unserer Kunden. Nachdem die Verbindung wiederhergestellt war, erhielten wir eine extrem hohe Last an eingehenden Ereignissen und E-Mails, und unsere (nur teilweise wiederhergestellte) Infrastruktur war nicht in der Lage, den Rückstand schnell genug zu verarbeiten. Die Last brachte auch einige leistungsbezogene Probleme in unserem Benachrichtigungsversandsystem ans Licht. In Zukunft wird unser Lasttest-Framework ein Szenario testen, in dem wir mit einem ähnlichen Verkehrsaufkommen und einer ähnlichen Verteilung konfrontiert sind.

Prävention: Sofortpläne

Wir bemühen uns sicherzustellen, dass PagerDuty jede Warnung innerhalb von 3 Minuten nach dem geplanten Zustellungsdatum übermittelt. Ein systemweiter Ausfall von 30 Minuten ist natürlich völlig inakzeptabel. Wir haben bereits die folgenden Schritte unternommen, um sicherzustellen, dass ein ähnliches regionenweites Ereignis keinen längeren Ausfall verursacht:

1. Wir haben eine Replik unseres gesamten Stacks bei einem zusätzlichen Hosting-Anbieter bereitgestellt. Im Falle eines ähnlichen AWS-Ausfalls werden wir unsere DNS-Einträge auf den alternativen Stack umstellen und die Verarbeitung dort fortsetzen, wo wir aufgehört haben. Der Umstellungsprozess wird zwar nicht so schnell oder transparent sein wie mit der Elastic-IP-Funktionalität von AWS, aber dieser alternative Stack bietet uns ein Maß an Redundanz, das wir mit AWS allein nicht erreichen können.
2. Wir haben unsere Front-End-Kapazität verdoppelt. Leider ist die Belastung von PagerDuty von Natur aus sehr variabel. Wenn ein großer Hosting-Anbieter ausfällt, muss ein großer Teil unserer Kundenbasis gleichzeitig benachrichtigt werden. Daher kann es innerhalb von Sekunden passieren, dass wir von einem System, das deutlich unterbesetzt ist, zu einem System wechseln, das stark unterversorgt ist. Wir haben einige Ideen, wie wir dieses Problem in Zukunft besser angehen können, aber vorerst haben wir unserem System mehr ungenutzte Kapazität hinzugefügt, um die zusätzliche potenzielle Belastung zu bewältigen.

Prävention: Zukunftspläne

In den kommenden Monaten planen wir eine Reihe weiterer Verbesserungen an unserer Infrastruktur. Diese Änderungen werden die Wahrscheinlichkeit eines systemweiten Ausfalls weiter verringern.

1. Wir beabsichtigen, AWS EC2 vollständig abzuschalten. Ein sehr großer Teil unserer Kunden hostet seine Dienste auf AWS. Dies führt zu einem gefährlichen korrelierten Ausfallzustand, bei dem die Zeiträume, in denen unsere Auslastung wahrscheinlich ungewöhnlich hoch ist, wahrscheinlich auch Zeiten sind, in denen wir selbst Betriebsprobleme haben. Selbst wenn ein Ausfall auf nur eine einzige AZ beschränkt ist, führt dies zu Problemen, da wir dadurch redundante Kapazität verlieren, wenn wir sie am dringendsten benötigen.
2. Wir werden PagerDuty bei mehreren Anbietern hosten. Die Verwendung eines einzigen Hosting-Anbieters mit mehreren Rechenzentren ist verlockend – es ist viel einfacher, eine verteilte App mit Tools wie virtuellen IPs zu schreiben, die von einem Rechenzentrum in ein anderes migriert werden können. Unserer Meinung nach sind die Fehlerkopplungen, die solche Funktionen in die Umgebung einbringen, das Risiko jedoch nicht wert. Bei der Verwendung mehrerer Hosting-Anbieter ist das Potenzial für einzelne Fehlerpunkte viel geringer.
3. Wir gehen bei der Bereitstellung und beim Testen davon aus, dass wir jederzeit 33 % unserer Kunden innerhalb von 5 Minuten benachrichtigen müssen. So können wir mit „Perfect Storm“-Szenarien umgehen, bei denen ein Ausfall auf Anbieterebene Ausfälle bei einem sehr großen Teil unserer Kundenbasis auslöst. In der Vergangenheit konzentrierten sich unsere Belastungstests auf große Verkehrsspitzen von einer kleineren Anzahl von Kunden. Wir werden auch Maßnahmen ergreifen, um sicherzustellen, dass unsere Systeme zur Ereigniswarteschlangenbildung und Benachrichtigungsübermittlung in Überlastungsszenarien ordnungsgemäß abgebaut werden.

Notfallmaßnahmen

Ein weiteres Problem, das durch den gestrigen Ausfall aufgedeckt wurde, ist, dass wir keine effektive Möglichkeit hatten, unsere Kunden auf eine Lücke in der Abdeckung von PagerDuty aufmerksam zu machen. Obwohl wir natürlich verhindern wollen, dass eine solche Lücke jemals wieder auftritt, halten wir es für wichtig, für alle Eventualitäten vorzusorgen.

Zu diesem Zweck haben wir einen Twitter-Account eingerichtet, auf dem wir ausschließlich Ausfallzeiten von PagerDuty bekannt geben. Wenn Sie diesen Twitter-Feed auf Ihrem Mobiltelefon abonnieren, werden Sie jedes Mal benachrichtigt, wenn es eine Lücke in Ihrer PagerDuty Abdeckung gibt. Weitere Informationen zur Einrichtung finden Sie in unserem vorheriger Blogbeitrag .

Darüber hinaus beabsichtigen wir, eine benutzerdefinierte Einrichtung zu schaffen, bei der Benutzer sich für den Empfang von Telefonbenachrichtigungen anmelden können, wenn PagerDuty erneut einen systemweiten Ausfall erleidet. Natürlich ist es unsere Absicht, dieses System nie nutzen zu müssen. Wir möchten jedoch sicherstellen, dass wir interessierte Kunden schnell über Lücken in ihrer PagerDuty Abdeckung informieren können. Natürlich werden wir sicherstellen, dass dieses Notfallsystem keine Abhängigkeiten zu unserem Hauptbenachrichtigungsversanddienst aufweist.

Schlussfolgerungen

Es tut uns natürlich leid, Sie alle enttäuscht zu haben. Wir haben bereits mehrere Schritte unternommen, um sicherzustellen, dass dies nicht noch einmal passiert, und wir werden in den kommenden Wochen noch weitere unternehmen.

Bitte zögern Sie nicht, uns zu kontaktieren, wenn Sie Fragen oder Bedenken haben. Wir freuen uns darauf, Ihr Vertrauen zurückzugewinnen.