Leidet Ihr Engineering-Team unter Alarmmüdigkeit? Stellen Sie diese 8 Fragen

Alarmmüdigkeit ist ein häufiges Problem bei Ingenieurteams, die den Betrieb übernehmen und die Infrastruktur warten.

Das Problem rührt normalerweise von einem willkürlichen Ansatz zum Schreiben von Warnungen her, wenn Teams wachsen und beginnen, mehr Infrastruktur mit zunehmender Komplexität zu verwenden. Das ist ganz normal – wenn ein Unternehmen oder ein Team wächst, braucht es oft Zeit, bis eine Kultur der Beobachtbarkeit und solide Alarmierungspraktiken Gestalt annehmen.

Es ist einfach, Warnungen zu erstellen, die zu sensibel, zu laut und zu vorsichtig sind. Am Anfang scheint alles wachsam zu sein, einfach weil es besser ist, in den frühen Stadien eines Produkts vorsichtig zu sein und das Produktionssignal zu maximieren.

„Da die Anzahl und Komplexität von Funktionen und Infrastrukturen zunimmt, steht die Verbesserung von Warnmeldungen in der Regel ganz unten auf der Prioritätenliste.“

Natürlich lässt sich dieser Ansatz nicht sehr gut skalieren, aber mit zunehmender Anzahl und Komplexität von Funktionen und Infrastruktur steht die Verbesserung von Warnungen in der Regel ganz unten auf der Prioritätenliste. Das Ergebnis sind viele halbwegs sinnvolle Warnungen, Rauschen, Kontextwechsel und Multitasking für den Bereitschaftstechniker. In extremen Fällen brennen Teamkollegen aus, Warnungen werden ignoriert, und Ihr Bereitschaftsteam wechselt von der Verbesserung der Servicequalität zur ständigen Brandbekämpfung ohne nennenswerte Auswirkungen.

Wie alle Unternehmen ist auch Intercom nicht immun gegen diese Ineffizienzen. Also haben wir einen relativ leichten Prozess entwickelt, um die Alarmmüdigkeit zu bekämpfen.

Wie wir über Alarmierungsstrategien nachdenken

Das Konzept der „Warndisziplin“ ist der Kern, um Warnungen unter Kontrolle zu bekommen. Wie die Feature-Arbeit sollten auch Alerts und die Alerting-Strategie bewusst und strukturiert angegangen werden. Im Gegensatz zur Feature-Arbeit ist dies jedoch nicht etwas, das im Voraus gut geplant werden kann.

Schließlich ist es höchst unwahrscheinlich, dass Sie den Betriebszustand und die Geräuschentwicklung Ihrer neuen Funktion vorhersagen können, bevor Sie sie versenden. Sie müssen Warnungen regelmäßig und geplant überwachen, damit sich der Aufwand für Warnungen nicht auf ein unhaltbares Niveau steigert.

8 Fragen, die Sie sich stellen sollten, wenn Sie die Warnungen Ihres Teams bewerten

Wir haben regelmäßige Alert-Review-Sitzungen für Teams eingeführt, die mit häufigen Alerts zu tun haben. Diese fanden anfangs einmal – oder mehrmals – pro sechswöchigem Entwicklungszyklus statt, wurden aber mit zunehmender Verbesserung des Zustands der Warnungen und Überwachungen auf ein überschaubareres Niveau immer weiter voneinander entfernt.

Jede Warnungsüberprüfungssitzung beginnt mit einer geordneten Liste von Warnungen, die im vorherigen Zeitraum ausgelöst wurden, geordnet nach der Häufigkeit ihrer Auslösung. Wir verwenden die PagerDuty-Plattform als unsere Alarmquelle, und ihre Analysefunktionen liefern uns die Informationen, die wir benötigen, um die Häufigkeit und Reaktion von Alarmen aufzuschlüsseln. Die Warnungen, die am meisten zum Gesamtrauschen beitragen (dh am häufigsten Feuer) werden zuerst überprüft.

Jede Warnung wird dann durch eine Checkliste mit Fragen geleitet:

1. Ist die Warnung noch relevant?

Alle Warnungen, die durch veraltete oder nicht gewartete Systeme ausgelöst werden, sollten den Bereitschaftstechniker nicht stören und sollten sofort entfernt werden.

2. Ist die Warnung umsetzbar?

Wenn ein Bereitschaftstechniker die Benachrichtigung erhält, kann er sofort etwas unternehmen, um die zugrunde liegende Ursache zu beheben oder zu verbessern? Wenn die Warnung nicht umsetzbar und nützlich ist, sollte sie entfernt werden. Eine wöchentliche Zusammenfassung von Problemen oder Leistungseinbußen ist möglicherweise ein besserer Ort für die Informationen in der Warnung.

3. Sind die Informationen in der Warnung sofort nützlich, auch wenn sie nicht umsetzbar sind?

Wir können Warninformationen in zwei große Kategorien unterteilen.

• Signale: Diese Warnungen warnen vor einem System, das am Limit arbeitet, bedeuten aber nicht unbedingt, dass der Dienst beeinträchtigt wird. Ein Beispiel wäre einer Ihrer Server, der mit 100 % CPU läuft. Sollte der Bereitschaftsdienst wertvolle Zeit mit Nachforschungen verbringen, wenn der Dienst immer noch einwandfrei funktioniert? Schließlich arbeitet Ihr Server dann nur mit dem besten Arbeits-Kosten-Verhältnis!
• Symptome: Diese Warnungen werden ausgelöst, wenn das Kundenerlebnis beeinträchtigt wird. Ein Beispiel hierfür wäre die Anzahl der 5XX-HTTP-Fehler, die Ihr Dienst an die Aufrufer zurückgibt.

Diese beiden Kategorien funktionieren am besten zusammen. Eine Bereitschaftsperson sollte reagieren und die Symptome beheben und Signale nur als weitere Informationsquelle betrachten.

4. Wenn die Warnung umsetzbar ist und Paging ist, muss sie sofort behandelt werden?

Wenn das Problem nicht sofort behandelt werden muss, sollte es niemanden mitten in der Nacht aufwecken. Das Team sollte in diesen Situationen über alternative Wege entscheiden, um die Informationen in der Warnung anzuzeigen, z. B. eine Slack- oder Dashboard-Benachrichtigung oder eine geöffnete Aufgabe in einem Problemverfolgungsmechanismus.

5. Wenn es umsetzbar ist, gibt es ein Runbook oder einen Link zur Fehlerbehebung? Sind die Schritte klar genug, um von jedem Ingenieur im Team befolgt zu werden?

Eine der schlimmsten Erfahrungen als Ingenieur auf Abruf – insbesondere als neuer Ingenieur – ist die Menge an Stammeswissen, das sich im Laufe der Zeit in Ingenieurteams ansammelt. Es ist einschüchternd, sich auf einen schwerwiegenden Produktionsvorfall zu stürzen, nur um festzustellen, dass Sie mit diesem Bereich des Systems nicht vertraut und nicht gut dokumentiert sind.

„ Wenn Sie die Informationen zur Fehlerbehebung bei Warnungen klar, einfach und auf dem neuesten Stand halten, trägt dies erheblich dazu bei, Ihre durchschnittliche Zeit zur Behebung und Wiederherstellung eines Vorfalls zu verkürzen. “

Selbst wenn Sie über die entsprechende Erfahrung verfügen, haben Sie den Code möglicherweise schon so lange geschrieben, dass Sie sich nicht mehr genau erinnern, was er tun soll. Wenn Sie die Informationen zur Fehlerbehebung bei Warnungen klar, einfach und auf dem neuesten Stand halten, trägt dies erheblich dazu bei, Ihre durchschnittliche Zeit zur Behebung und Wiederherstellung eines Vorfalls (MTTM und MTTR) zu verkürzen.

6. Wenn es umsetzbar ist, gibt es einen Dashboard-Link und zeigt es alle bekannten potenziellen Ursachen?

Dashboards sind eine großartige Möglichkeit, große Mengen an Systeminformationen auf einmal anzuzeigen, was bedeutet, dass Ingenieure nicht in verschiedenen Protokollen, Metriken und Ablaufverfolgungen graben müssen, um die Ursache eines Problems herauszufinden. Das Sammeln von Daten in einem Dashboard und das Bereitstellen des Links als Teil der Warnung ermöglicht eine viel schnellere Fehlerbehebung.

7. Ist die Warnung zu sensibel oder nicht spezifisch genug? Würde es von einer Desensibilisierung oder Änderung des Geltungsbereichs profitieren?

Viele Warnungen sind nützlich, aber falsch kalibriert. Sie könnten entweder zu breit sein und nicht jedes Mal feuern, wenn sie sollten, oder zu spezifisch sein und mehrmals für denselben Vorfall feuern, was nur den Lärm verstärkt.

8. Muss schließlich ein Mensch die Abhilfe schaffen?

In gewisser Weise automatisiert jeder Computercode etwas, was ein Mensch tun kann. Warum also nicht die Behebung der Probleme automatisieren, die die Warnungen auslösen? Während bestimmte heiklere Warnungen schwer automatisch zu beheben sind, wie z. B. ein Fehler im Code oder ein Leistungsproblem im System, können automatisierte Aktionen viele häufige Probleme lösen.

Dies gilt insbesondere, wenn Sie auf einer Cloud-Plattform wie AWS arbeiten und Infrastruktur bereitstellen können, ohne sich Gedanken über die Anforderung zusätzlicher Hardware machen zu müssen. Wenn beispielsweise ein Knoten in Ihrem Suchcluster fehlerhafte Festplatten anzeigt, warum ersetzen Sie ihn nicht automatisch? Wenn der Dienst aufgrund von Traffic-Zunahme wenig Rechenressourcen hat, warum nicht skalieren und zusätzliche VMs oder Container hinzufügen? Details der Behebung können dann über Kanäle ohne Benachrichtigung an das Team gesendet werden, damit sie es in Ruhe überprüfen können.

Haben Sie eine dieser Fragen mit „nein“ beantwortet?

Die Beantwortung einer dieser Fragen mit Nein wirft eine Aufgabe mit hoher Priorität für das Team auf, um die Warnung zu verbessern – sei es, sie vom Paging abzuhalten, Schritte zur Fehlerbehebung zu verbessern, sie zu automatisieren oder einfach das zugrunde liegende Systemproblem zu beheben.

Der Kern des Ansatzes besteht darin, dies regelmäßig und geplant zu tun. Es hält den Geräuschpegel niedrig und Ihre Betriebs- und Bereitschaftstechniker zufrieden und produktiv. Sie können sich darauf konzentrieren, die Qualität zu verbessern und Wirkung zu erzielen, anstatt Brandbekämpfung zu betreiben.

Interessieren Sie sich für unsere Arbeitsweise bei Intercom? Wir würden uns freuen, mit Ihnen zu sprechen – sehen Sie sich unsere offenen Ingenieurstellen an.