Wie Sie vielleicht bereits wissen, war PagerDuty gestern 30 Minuten lang ausgefallen, woraufhin die Alarmübermittlung länger dauerte. Wir nehmen die Ausfallzeit sehr ernst, insbesondere angesichts der Tatsache, dass sie sich mit der Ausfallzeit vieler unserer Kunden überschnitt.

Bitte haben Sie Verständnis dafür, dass wir die Schuld nicht auf andere abwälzen wollen, es aber zu unseren Prozessen gehört, Verständnis für etwaige gravierende Ausfallzeiten zu haben und offen damit umzugehen.

Was passiert ist: 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 von Ausfällen in anderen Availability Zones isoliert sind und eine kostengünstige Netzwerkverbindung mit geringer Latenz zu anderen Availability Zones in derselben Region bieten“.

Wie viele Hochverfügbarkeitsanwendungen nutzt PagerDuty mehrere Availability Zones, um unsere Anwendung vor Ausfällen auf Rechenzentrumsebene zu schützen. Die schnellen 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. rechenzentrumsweiten) Ausfalls den gesamten Datenverkehr innerhalb von 60 Sekunden auf eine der verbleibenden AZs umleiten, ohne dass eingehende Ereignisse verloren gehen.

Leider funktionierte das System gestern nicht wie geplant. Wir freuen uns auf die offizielle Nachbesprechung von AWS, aber unsere eigene Untersuchung zeigt, dass mindestens drei nominell unabhängige AZs in US-Ost-1 gleichzeitig für 30 Minuten vom Internet getrennt waren. Dadurch fehlte uns die Hardware, um eingehende Ereignisse zu empfangen oder Benachrichtigungen für bereits empfangene Ereignisse zu versenden.

Was geschah: Die Folgen

Der regionale Ausfall von EC2 betraf einen Großteil unserer Kunden. Nach Wiederherstellung der Verbindung erhielten wir eine extrem hohe Last an eingehenden Ereignissen und E-Mails, und unsere (nur teilweise wiederhergestellte) Infrastruktur konnte den Rückstand nicht schnell genug verarbeiten. Die hohe Belastung deckte auch einige leistungsbezogene Probleme in unserem Benachrichtigungssystem auf. Zukünftig wird unser Lasttest-Framework ein Szenario testen, in dem wir mit einem ähnlichen Datenaufkommen und einer ähnlichen Verteilung konfrontiert sind.

Prävention: Sofortmaßnahmen

Wir bemühen uns sicherzustellen, dass PagerDuty jede Warnung innerhalb von 3 Minuten nach dem geplanten Zustellungstermin ü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 regionales 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 ist zwar nicht so schnell und transparent wie die 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 Auslastung von PagerDuty von Natur aus sehr variabel. Fällt ein großer Hosting-Anbieter aus, muss ein großer Teil unserer Kunden gleichzeitig benachrichtigt werden. Daher kann es innerhalb weniger Augenblicke passieren, dass unser System deutlich unterbelastet ist und dann stark unterversorgt ist. Wir überlegen, wie wir dieses Problem in Zukunft besser lösen können, haben aber zunächst die Kapazität unseres Systems erhöht, um die zusätzliche potenzielle Auslastung 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 einer gefährlichen korrelierten Ausfallsituation: Die Zeiten, in denen unsere Auslastung wahrscheinlich ungewöhnlich hoch ist, sind wahrscheinlich auch Zeiten, in denen wir selbst Betriebsprobleme haben. Selbst wenn ein Ausfall nur auf eine einzige AZ beschränkt ist, führt dies zu Problemen, da wir dadurch redundante Kapazitäten verlieren, wenn wir sie am dringendsten benötigen.
2. Wir werden PagerDuty bei mehreren Anbietern hosten. Die Nutzung 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 zum anderen migriert werden können. Unserer Meinung nach ist die Fehlerkopplung, die solche Funktionen in die Umgebung bringen, das Risiko jedoch nicht wert. Bei der Nutzung mehrerer Hosting-Anbieter ist das Potenzial für einzelne Fehlerquellen deutlich geringer.
3. Wir gehen bei der Bereitstellung und den Tests davon aus, dass wir jederzeit 33 % unserer Kunden innerhalb von fünf Minuten benachrichtigen müssen. So sind wir für den Fall eines „Perfect Storm“ gerüstet, bei dem ein Ausfall auf Providerebene Ausfälle bei einem sehr großen Teil unserer Kunden auslöst. In der Vergangenheit konzentrierten sich unsere Belastungstests auf große Datenmengen von einer kleineren Anzahl von Kunden. Wir werden außerdem Maßnahmen ergreifen, um sicherzustellen, dass unsere Systeme zur Ereigniswarteschlangen- und Benachrichtigungsverteilung bei Überlastung reibungslos funktionieren.

Notfallmaßnahmen

Ein weiteres Problem, das der gestrige Ausfall aufgedeckt hat, ist, dass wir unsere Kunden nicht effektiv über die Lücke in der PagerDuty-Abdeckung informieren konnten. 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 über Ausfallzeiten von PagerDuty informieren. Wenn Sie diesen Twitter-Feed auf Ihrem Mobiltelefon abonnieren, werden Sie benachrichtigt, sobald Ihre PagerDuty -Abdeckung unterbrochen ist. Weitere Informationen zur Einrichtung finden Sie in unserem vorheriger Blogbeitrag .

Darüber hinaus planen wir die Einrichtung einer benutzerdefinierten Funktion, mit der sich Nutzer telefonisch benachrichtigen lassen können, falls PagerDuty erneut einen systemweiten Ausfall erleidet. Natürlich ist es unser Ziel, dieses System nie zu benötigen. Wir möchten jedoch sicherstellen, dass wir interessierte Kunden schnell über Lücken in ihrer PagerDuty Abdeckung informieren können. Selbstverständlich stellen wir sicher, dass dieses Notfallsystem nicht von unserem Hauptbenachrichtigungsdienst abhängig ist.

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 weitere Schritte unternehmen.

Bei Fragen oder Anliegen stehen wir Ihnen gerne zur Verfügung. Wir freuen uns darauf, Ihr Vertrauen zurückzugewinnen.