Der Blog

8 Möglichkeiten zur Reduzierung der Alarmmüdigkeit

von Chris Riley 24. Mai 2016 | 6 Minuten Lesezeit

battle-alert-fatigue Isolierte Zuständigkeiten haben die Teamkommunikation stark beeinträchtigt und es den verschiedenen Abteilungen erschwert, bei Krisensituationen den gesamten Kontext einer Situation zu erfassen. Dies hat nicht nur die Qualität der Kommunikation innerhalb der gesamten Entwicklungsteams beeinträchtigt, sondern auch ein ernstes Problem geschaffen, das viele auf der operativen Seite plagt: Alarmmüdigkeit. Alarmmüdigkeit ist nicht nur ein Problem unzufriedener Teammitglieder – sie beeinträchtigt auch das Wachstum der Softwarelieferkette.

 

Das Tolle an DevOps ist, dass es Kommunikationsbarrieren abbaut und Abläufe optimiert. DevOps-Teams gibt es in zwei Varianten: zentralisierte Teams für alle Anwendungen, die größer, aber immer noch kleiner als herkömmliche NOC-Umgebungen sind; und dezentrale Teams, die aus einem sehr kleinen Team für jede Anwendung oder jeden Kerndienst bestehen.

Diese Teams sind nicht nur für die Bereitstellung der Infrastruktur und manchmal auch für den Release-Prozess verantwortlich, sondern tragen auch die Verantwortung für die Aufrechterhaltung der Produktion. Dies ist nervenaufreibend, zeitaufwändig und beeinträchtigt die gesamte Umgebung, wenn es nicht richtig gemacht wird. Niemand möchte Bereitschaftsdienst leisten, aber wir tun es, weil wir wissen, dass eine schnellere mittlere Lösungszeit (MTTR) und eine schnelle Reaktion auf Probleme die kommenden Tage und Wochen für alle deutlich erleichtern – ganz zu schweigen davon, dass es den Geschäftsbetrieb am Laufen hält. Wenn sich Bereitschaftsdienst jedoch negativ auf die Stimmung eines Teams auswirkt und den Großteil der Zeit des Betriebsteams in Anspruch nimmt, birgt dies ein enormes Risiko.

Sowohl zentralisierte als auch dezentrale Konfigurationen sind anfällig für Alarmmüdigkeit, wobei es jeweils leichte Unterschiede gibt. Bei der zentralisierten Variante ist die Anzahl der aggregierten Alarme über alle Anwendungen hinweg nicht nur ermüdend; es ist auch schwierig zu wissen, wer die richtige Person für das Problem ist, da die Wahrscheinlichkeit groß ist, dass es sich nicht um die diensthabende Person handelt. Bei dezentralen Konfigurationen entsteht Alarmmüdigkeit einfach durch eine hohe Anzahl von Alarmen für ein kleines Team.

Die Auswirkungen der Alarmmüdigkeit auf DevOps- und IT-Ops-Teams sind vierfach:

    • Niedrige Moral: Wenn Sie den Großteil Ihrer Zeit mit der Problemlösung verbringen, beschäftigen Sie sich nicht nur Tag und Nacht mit Vorfällen, sondern verbringen auch Ihre Zeit mit weniger interessanten Dingen. Sie geraten in den Teufelskreis des bloßen Löschens von Problemen, was die Kommunikation im Team beeinträchtigen und es schwierig machen kann, effektiv zu bleiben.

 

    • Einzelner Fehlerpunkt: Im zentralisierten Szenario hängt die mittlere Reaktionszeit (MTTR) von der Geschwindigkeit ab, mit der eine begrenzte Anzahl von Bereitschaftsmitarbeitern auf ein Problem reagieren und die Ursache ermitteln kann. Im dezentralen Szenario verlängert sich zwar die Zeit zur Ursachenermittlung, die Abdeckung reicht jedoch nicht aus, um Probleme zu priorisieren und schneller zu lösen. Da zudem die Anrufliste kürzer ist, steigt das Risiko, dass das Problem überhaupt nicht behoben wird. All dies führt zu Engpässen und einer zentralen Ausfallquelle für jedes auftretende Problem.

 

    • Opportunitätskosten: Dies ist die am wenigsten beachtete Auswirkung von Alarmmüdigkeit – die Kosten für das gesamte Team und die Lieferkette. Wenn Ihr DevOps-Team durch den Alarmprozess überlastet und ausgelaugt ist, kann es die Lieferkette nicht innovativ gestalten und verbessern. Da es nur reagieren kann, ist es nicht in der Lage, bessere Releases und Infrastrukturautomatisierungsprozesse zu entwickeln oder proaktiv zu handeln, um zukünftigen Problemen vorzubeugen. Dies verhindert nicht nur Verbesserungen, sondern kann auch die technische Verschuldung erhöhen, da häufig wiederkehrende Probleme nie durch langfristige Lösungen behoben werden.

 

  • Langsamere Veröffentlichungsfrequenz: Je länger die Behebung von Problemen dauert, desto größer ist die Auswirkung auf die Veröffentlichungsdynamik. Wie oft hat Ihr Team eine Veröffentlichung verschoben?

 

Die einfachste Antwort auf die Alarmmüdigkeit besteht darin, das Betriebsteam zu vergrößern. Dies ist jedoch nicht unbedingt die beste Option, da diese „Lösung“ letztendlich die Vorteile eines kleineren DevOps-Teams zunichte macht.

Zur Bekämpfung der Alarmmüdigkeit gibt es noch mehrere weitere Optionen:

    1. Erstellen Sie bessere Eskalationsrichtlinien: Planen Sie. Erstellen Sie nicht einfach eine Anrufliste für Ihr Team. Planen Sie und berücksichtigen Sie die möglichen Auswirkungen auf die Ressourcen und die Moral Ihres Teams. Ein wenig Strategie kann hier viel bewirken. Ein einfacher Trick ist beispielsweise, Rotationen aufzuteilen.

 

    1. Stellen Sie QA und Entwickler auf Abruf bereit: Dies erfordert die Mitarbeit des gesamten Teams, was sehr schwierig sein kann. Durch die Einbeziehung von Entwicklern und QA-Teams in die Rotation erreichen Sie jedoch eine bessere Abdeckung und schnellere Problemlösungszeiten. Selbst wenn dies parallel mit einem Mitglied des Betriebsteams geschieht, kann eine breitere Unterstützung die Transparenz bei Produktionsproblemen verbessern, Entwicklern bei der Lösung anwendungsbezogener Probleme helfen und das Verständnis verbessern, um zukünftige Probleme zu vermeiden.

 

    1. Verfügen Sie über eine detaillierte Vorfallanalyse: Durch die Transparenz der Effektivität Ihres Alarmsystems können Sie es im Laufe der Zeit verbessern und erkennen, wo Ihre aktuellen Engpässe liegen. Die Daten zeigen Ihnen auch wiederkehrende Probleme auf. Lassen Sie sich von den Daten leiten.

 

    1. Nehmen Sie sich Zeit, um wiederkehrende Probleme zu vermeiden: Nehmen Sie sich Zeit, Probleme zu identifizieren, die schnell behoben werden konnten, und beheben Sie diese, damit sie in Zukunft nicht wieder auftreten. Das Problem muss zwangsläufig behoben werden, ebenso wie jedes weitere Problem. Dies stellt eine enorme Belastung für das Betriebsteam dar.

 

    1. Benachrichtigungsregeln standardisieren: Lassen Sie nicht zu, dass Bereitschaftsteammitglieder willkürlich eigene Regeln aufstellen. Standardisieren oder erstellen Sie Musterregeln, um Konsistenz und Verantwortlichkeit zu gewährleisten.

 

    1. Parallele Alarme zulassen: Es gibt den vertikalen Call-Down, aber es kann auch horizontale Warnungen geben, bei denen mehrere Teammitglieder Probleme gemeinsam angehen können, um die MTTR zu verkürzen.

 

    1. Nutzen Sie die Tools: Tools für das Incident-Management helfen dabei, Alarmmüdigkeit zu bekämpfen. Eine gute Incident-Management-Lösung, wie PagerDuty Automatisiert Warnmeldungen und hilft Ihnen, die Alarmflut zu durchleuchten – so werden Sie nicht von unkritischen Warnmeldungen überflutet. So können Sie Ihre Warnmeldungen gezielter einsetzen und Ihren Bereitschaftsdienst effektiver gestalten. Wenn es dann nachts klingelt, wissen Sie, dass ein echtes Problem vorliegt.

 

  1. Schreiben Sie besseren Code: Zeit in Qualität zu investieren reduziert Ausfälle. Es ist so einfach, doch die Qualität wird allzu oft vernachlässigt. Investieren Sie mehr Zeit in die Verbesserung der Codequalität, eine bessere Testabdeckung, bessere Systemtests und eine bessere Testautomatisierung, um allen die Vorteile aufzuzeigen.

 

All dies ist Teil einer umfassenderen Strategie zur Optimierung der Betriebsleistung und kommt allen zugute. Alarmmüdigkeit ist real und wirkt sich nicht nur auf Ihre DevOps Und ITOps Die Zufriedenheit des Teams, aber auch die Fähigkeit des gesamten Entwicklungsteams, innovativ zu sein und den Release-Code zu verbessern.