Im Anschluss an unsere vorherigen Post Wir möchten Ihnen seit gestern mitteilen, welche Maßnahmen wir auf Grundlage unserer ersten Ursachenanalyse ergreifen werden.

Primäre und sekundäre Ursachen

Als wir unsere Zeitleiste der Ereignisse während des Ausfalls durchsahen, stellten wir fest, dass es zwei Probleme gab:

1. Unser Failover-Ansatz bei DNS-Problemen
2. Die Qualität des Monitorings zur Bewertung des End-to-End-Kundenerlebnisses

Wie wir bereits in der Vergangenheit besprochen haben, bevorzugen wir zur Gewährleistung einer kontinuierlichen Verfügbarkeit eine Multi-Master-Architektur gegenüber einer Failover-Architektur für unsere Systeme. Dieser Ansatz erfordert zwar erhebliche Investitionen in die Systementwicklung, bietet jedoch folgende Vorteile: vorhersehbare Kapazität in beeinträchtigten Szenarien, erzwungene stärkere Automatisierung und einfachere und sicherere inkrementelle Änderungen. Für unsere DNS-Systeme hatten wir jedoch keine Multi-Master-Architektur im Einsatz. Stattdessen war während des Ausfalls ein manuelles Failover zu einem sekundären Anbieter erforderlich.

Die Messung der End-to-End-Kundenerfahrung ist bei DNS-Problemen immer eine Herausforderung. Wenn ein Kunde nicht mit Ihren Systemen kommunizieren kann, wie können Sie dann seine Erfahrung beurteilen? Wir verlassen uns stark auf die Überwachung und Warnmeldungen aller Teile der PagerDuty-Dienste. Wir haben Ingenieurteams, die sich darum kümmern, dass jeder Teil der Kundenerfahrung den Erwartungen unserer Kunden entspricht. Während dieses Ausfalls konnten wir die Kundenprobleme nicht richtig diagnostizieren, da die Kunden unsere Systeme nicht erreichen konnten. Dies führte zu einer längeren Lösungszeit für unsere Kunden.

Folgemaßnahmen

In den kommenden Wochen planen wir, mehrere Verbesserungen an unserer Infrastruktur, unseren Prozessen und unserer Automatisierung vorzunehmen. Diese Verbesserungen werden dazu beitragen, die Wahrscheinlichkeit eines systemweiten Ausfalls aufgrund der identifizierten Grundursachen zu verringern.

Ein Multi-Master-Ansatz für DNS

Unsere oberste Priorität ist derzeit die Neugestaltung und Implementierung einer neuen DNS-Architektur, die die Nutzung mehrerer DNS-Anbieter in einem Multi-Master-Ansatz ermöglicht. Wir aktualisieren unsere internen Tools und Automatisierungen, um sicherzustellen, dass sowohl unsere externen, kundenorientierten DNS-Einträge mehrere DNS-Anbieter nutzen, als auch, dass unsere internen Server ein ähnliches System nutzen.

Überprüfen aller DNS-TTLs

Wir haben mehrere Endpunkte, die unsere Kunden zur Interaktion mit PagerDuty verwenden: Unsere Website, unsere APIs und unsere mobilen Anwendungen. Um ein einheitliches Erlebnis über alle diese Punkte hinweg zu gewährleisten, werden wir die DNS-TTLs für unsere Zonen prüfen, einschließlich der NS- und SOA-Einträge für jede Zone.

Runbook zum Leeren des DNS-Cache

Viele öffentliche DNS-Anbieter bieten die Möglichkeit, Caches proaktiv zu leeren, wenn sich Datensätze geändert haben. Zum Beispiel: Google stellt diese Funktionalität über eine Weboberfläche bereit. Wir werden untersuchen, welche DNS-Anbieter unsere Kunden am häufigsten nutzen, und die Schritte festlegen, mit denen jeder Anbieter proaktiv Caches leeren kann, um möglichst schnell aktuelle Datensätze bereitzustellen.

Verbessern Sie die Überwachung realer Benutzer

Wir nutzen eine Kombination aus internen Überwachungssystemen und denen externer Anbieter. Während dieses Ausfalls haben wir diese Überwachungssysteme verwendet, um die Auswirkungen auf die Kunden zu bewerten und zu bestimmen, wie die Lösungsschritte am besten priorisiert werden können. Leider sind die meisten internen Systeme so konzipiert, dass sie eine Ansicht innerhalb unserer Infrastruktur darstellen und unser End-to-End-Benutzererlebnis nicht ausreichend beschreiben, insbesondere für unsere Kunden an der Ost- und Westküste der USA. Wir werden zusätzliche Ressourcen in eine globale Überwachung investieren, die eine externe und kundenorientierte Ansicht unserer Systeme und unseres gesamten Serviceangebots bietet. Dies umfasst unsere Website, APIs und mobilen Erlebnisse sowie unser Benachrichtigungserlebnis.

Priorisierung der Lösungsschritte verbessern

Bei PagerDuty nutzen wir eine serviceorientierte Architektur, um mehrere Funktionen zu unterstützen, die unsere Kunden nutzen. Bei den meisten unserer Kundenvorfälle ist nur ein Teil unseres Dienstes betroffen, wenn es zu einer Dienstunterbrechung kommt. Da eine zentrale Komponente wie DNS nicht verfügbar war, waren mehrere Komponenten unseres Dienstes betroffen. Wenn wir unsere Dienste in Zukunft wieder in Betrieb nehmen, müssen wir in der Lage sein, die kritischsten und wichtigsten Dienste zu priorisieren, die für unsere Kunden am wichtigsten sind.

Verbessern Sie den Multi-Team-Reaktionsprozess

Wie im vorherigen Abschnitt erwähnt, haben wir mehrere Teams, die ständig in Bereitschaft sind, damit PagerDuty richtig funktioniert. Obwohl wir unser eigenes Produkt nutzen, um uns bei unseren Personalkoordinationsbemühungen zu unterstützen, hatten wir für bestimmte beteiligte Teams nicht alle unterstützenden Tools zur Verfügung. Wir planen, Prozesse zu implementieren und unsere Best Practices zu verbessern, damit jedes Team Probleme in seinen eigenen Diensten effektiv lösen kann.

Abschluss

Der vergangene Freitag war für fast jeden Bereitschaftstechniker ein schwieriger Tag. Bei PagerDuty sind wir sehr stolz darauf, einen Service anzubieten, auf den sich Tausende von Kunden verlassen. Wir haben die hohen Erwartungen, die wir an uns selbst gestellt haben, nicht erfüllt und unternehmen wichtige Schritte, um die Zuverlässigkeit und Verfügbarkeit unserer Systeme kontinuierlich zu verbessern. Aufgrund dieser Erfahrung bin ich zuversichtlich, dass wir einen noch zuverlässigeren Service bieten werden, der da ist, wenn unsere Kunden uns am meisten brauchen.

Wenn Sie Fragen oder Bedenken haben, wenden Sie sich wie immer gerne an mich oder unser Support-Team unter support@pagerduty.com