paint-brush
Ein Dutzend (oder so) Erkenntnisse aus 15 Jahren Software-Vorfallmanagementvon@arjunrao1987
1,439 Lesungen
1,439 Lesungen

Ein Dutzend (oder so) Erkenntnisse aus 15 Jahren Software-Vorfallmanagement

von Arjun 9m2024/04/11
Read on Terminal Reader

Zu lang; Lesen

Das alles ist so ERNST! Geld geht verloren! Kunden machen schreckliche Erfahrungen! Trotzdem habe ich festgestellt, dass es bei all dem entscheidend ist, einen Sinn für Humor zu haben. Wir sollten nicht vergessen, dass jeder in diesem Prozess ein Mensch ist und unterschiedlich starkem Stress ausgesetzt ist. Wenn man an den richtigen Stellen eine Dosis Humor einbringt, kann man diesen Druck etwas abbauen.
featured image - Ein Dutzend (oder so) Erkenntnisse aus 15 Jahren Software-Vorfallmanagement
Arjun  HackerNoon profile picture

Als Softwareentwickler ist es ätzend, sich mit Vorfällen auseinanderzusetzen. Samstagmorgens um 3 Uhr morgens die Bereitschaftsseite zu erhalten? Das kann furchterregend, seelenzermürbend und insgesamt ein abscheuliches Erlebnis sein. Wenn das an Ihrem Arbeitsplatz häufig vorkommt, kann es buchstäblich eine PTBS auslösen.


Leider ist dies ein fester Bestandteil des Software-Zeitgeists. Wenn überhaupt, sind dies die Feuer, durch die echte Ingenieurskunst geschmiedet wird. Diese Vorfälle lehren Sie, wie Sie robuste Systeme entwerfen und in vielen Fällen auch, wie Sie es nicht tun.


Dieser Artikel geht auf zwei Aspekte des Umgangs mit Softwarevorfällen ein:

  • 🛠️ Die Praktiken, die man in seine Softwareplattform und Teams einführen muss, um diese Erfahrungen zu verhindern und daraus zu lernen.


  • 🧘 Die Einstellung, die man braucht, um widerstandsfähig zu sein und aus diesen Erfahrungen nicht nur unbeschadet hervorzugehen, sondern auch mit mehr, als man hineingesteckt hat.


Die Themen, die wir ansprechen werden, sind:

  1. Automatisieren Sie Ihre Systeme so weit wie möglich
  2. Verfolgung von Früh- und Spätindikatoren
  3. „Umsetzbare“ Warnungen sollten selbsterklärend sein
  4. Etablieren Sie klare Anrufketten und Eskalationswege
  5. Befähigen Sie die Frontlinien, wichtige Entscheidungen zu treffen
  6. Nicht alle Vorfälle sind gleich
  7. Erst lösen, dann Fragen stellen
  8. Stellen Sie sicher, dass eine Person die Verantwortung übernimmt
  9. Kommunizieren Sie klar und häufig
  10. Schuldfreie Obduktionen sind entscheidend
  11. Nachuntersuchungen sind entscheidend
  12. Vorfälle sind nicht schlimm, solange die MTTD niedrig ist
  13. Humor ist der große Gleichmacher


Lassen Sie uns in einige Einzelheiten eintauchen!

Automatisieren Sie Ihre Systeme so weit wie möglich

Sie möchten wirklich die Anzahl der Vorfälle minimieren, von denen Sie entweder durch Ihre Kunden oder durch schwerwiegende Buchhaltungsdiskrepanzen Tage oder Wochen nach Beginn des Vorfalls erfahren. Während „Automatisierung“ in der Technik ein überstrapaziertes Wort ist, ist dies einer der Bereiche, in denen Sie wirklich das richtige Gleichgewicht des Signal-Rausch-Verhältnisses finden und sicherstellen möchten, dass Sie und Ihr Team Warnmeldungen erhalten, ohne dass ein menschliches Eingreifen erforderlich ist.


Wenn Sie zu viele Dinge zur Auswahl haben, gehen Sie auf die oberste Ebene. Welche Kennzahl auf höchster Ebene könnten Sie auswählen? Diejenige, die von der Norm abweicht, wenn die Komponentensysteme nicht wie erwartet funktionieren? Dies könnte die Verfolgung der Einnahmen sein, die über die Plattform fließen (bei einer E-Commerce-, Finanz- oder Dollar-basierten Plattform) oder die Anzahl der aktuell aktiven Benutzer (bei Social-Media-Plattformen).


Wenn Sie sehen, dass die Zahlen einbrechen oder um eine oder zwei Standardabweichungen sinken, benachrichtigen Sie sofort das Entwicklungsteam. Die ersten (oder wichtigsten) Benachrichtigungen auf den Puls des Unternehmens oder die zentrale Benutzererfahrung zu konzentrieren, ist eine hervorragende Messgröße für die Überwachung. Wenn Sie anspruchsvoller werden und das System besser verstehen, können Sie beginnen, aus Sicht der Beobachtbarkeit tiefer in den Stapel einzudringen.
Foto von Markus Spiske auf Unsplash

Verfolgung von Früh- und Spätindikatoren

Frühindikatoren sind prädiktiver Natur und weisen wahrscheinlich auf ein bevorstehendes Problem hin, während Spätindikatoren nachträglich auftreten und die Folgen darstellen, wenn das Problem bereits weit fortgeschritten ist. Wenn Sie zusätzlich zu oder anstelle von Spätindikatoren (wie etwa „Anzahl der aufgegebenen Bestellungen sinkt“) Frühindikatoren (wie etwa „Sitzungsdauer“ beginnt zu sinken) nutzen können, können Sie wahrscheinlich etwas ziemlich Katastrophales abwenden.

„Umsetzbare“ Warnungen sollten selbsterklärend sein

Ihre Warnungen müssen selbsterklärend sein, damit es völlig klar ist, welche nächsten Schritte zu unternehmen sind, wenn sie ausgelöst werden. Ob es darum geht, die Schwere des Problems festzustellen, den Vorfall zu beheben oder das Problem zu beheben, die Warnung sollte genügend Details enthalten. Sie möchten sicherstellen, dass nicht im Vorfeld viel diskutiert werden muss, um zu bestimmen, was mit der Warnung zu tun ist.


Sie können diese Details in den Inhalt der Warnung selbst einfügen oder, wenn diese relativ ausführlich ist, auf ein oder mehrere Runbooks verweisen, die das Team für diese Art von Problemen verwaltet.

Etablieren Sie klare Anrufketten und Eskalationspfade

Um eine schnelle Reaktion zu gewährleisten, ist es wichtig, klar zu definieren, was passiert, wenn eine Warnung ausgelöst wird, einschließlich der Informationen darüber, an wen sie weitergeleitet wird, basierend auf Faktoren wie Serviceeigentümerschaft, Zeitzonenbewusstsein usw. Über diese unmittelbare erste Verteidigungslinie hinaus ist es ebenso wichtig, Klarheit darüber zu schaffen, wie und an wen der Incident Responder den Vorfall eskalieren kann.


Wenn das Problem komplex ist oder einen viel größeren Umfang hat, als eine Person bewältigen kann, kann es oft notwendig sein, erfahrenere Mitarbeiter (oder mehrere Personen aus dem Team) sowie abteilungsübergreifende Stakeholder hinzuzuziehen. All dies mithilfe von Tools (wie PagerDuty, OpsGenie) oder kristallklarer Dokumentation (Runbooks, Wiki-Seiten, Repository-READMEs) leicht zugänglich zu machen, kann den Unterschied zwischen einem katastrophalen Vorfall und einem Nichtstun ausmachen.
Beispiel einer Aufrufkette

Befähigen Sie Mitarbeiter an der Front, wichtige Entscheidungen zu treffen

Sie brauchen zwar klare Eskalationspfade, aber das sollte nicht die Standardreaktion sein. Sie müssen die Ersthelfer befähigen, echte Maßnahmen zu ergreifen, um die Situation zu stoppen oder vor Ort Entscheidungen zur Behebung zu treffen, ohne die Geschäftsleitung konsultieren zu müssen. Das ist sowohl für das Unternehmen im Hinblick auf die Begrenzung der Auswirkungen von Vorteil als auch für die Mitarbeiter, denen eine hohe Verantwortung übertragen wird und denen man zutraut, wichtige Entscheidungen zu treffen. Reduzieren Sie den bürokratischen Aufwand und stärken Sie die Handlungsfreiheit der einzelnen Mitarbeiter.

Nicht alle Vorfälle sind gleich

Neben Dingen wie Anrufketten und Eskalationspfaden ist eine Prioritätsskala für Vorfälle ein weiteres wichtiges Hilfsmittel. Diese dient in der Regel als Kurzreferenz für den Ersthelfer oder Einsatzleiter. Sie hilft ihnen dabei, schnell zu erkennen, wie schwerwiegend der Vorfall ist, und ihn entsprechend zu kennzeichnen, da er möglicherweise unterschiedliche Reaktionsstufen erfordert.


Die Unterscheidung zwischen kritischen Vorfällen (wie Systemausfällen oder Beschädigungen von Finanzdaten) und kleineren Problemen (wie Farbpalettenfehlern) ist für Einsatzkräfte unerlässlich, um Fehlalarme zu vermeiden. Außerdem wird dadurch sichergestellt, dass die Reaktion des Teams effektiv und zielgerichtet bleibt.
Beispiel einer Priorisierungsmatrix (Quelle)

Erst lösen, dann Fragen stellen

Eines der wichtigsten Dinge ist zweifellos, den Vorfall so schnell wie möglich zu lösen. Sie möchten keine Zeit damit verbringen, zu philosophieren, warum etwas passiert ist oder wie es hätte verhindert werden können, während der Vorfall noch im Gange ist. Das können Sie sich für die Nachbesprechung aufheben. Konzentrieren Sie sich im Moment einfach unerbittlich auf die Lösung des Vorfalls und stellen Sie die schwierigen Fragen später.

Stellen Sie sicher, dass eine Person die Verantwortung übernimmt

Manchmal können Vorfälle zu groß werden. Sie betreffen zu viele Dienste, sie erstrecken sich über mehrere Geschäftsbereiche oder sie haben einfach große Auswirkungen auf Umsatz oder Ruf. In solchen Fällen ist es absolut entscheidend, dass eine Person damit beauftragt wird, den gesamten Vorfall „auf den Weg zu bringen“. Bei Place Exchange haben wir „Einsatzleiter“ eingesetzt, eine kleine Gruppe von Personen, die in der Reaktion auf komplexe Vorfälle geschult sind.


Der Grund, warum diese Art von Rolle so wichtig ist, liegt darin, dass, wenn mehrere Parteien beteiligt sind, jemand den Verkehr regeln muss. Oftmals geraten Ingenieure ins Grübeln über die Komplexität des Problems oder versuchen zu verstehen, wie das Problem zu lösen ist.


Die Rolle des Einsatzleiters besteht darin, den Fokus der Gruppe auf eine schnelle Lösung des Vorfalls zu lenken. Er stellt sicher, dass jeder eine Handlungsorientierung hat, und obwohl Nebenuntersuchungen wichtig sein können, ist es noch wichtiger, eine Vorwärtsdynamik sicherzustellen. Er ist auch dafür verantwortlich, eine klare und konstante Kommunikation mit internen und externen Stakeholdern und Partnern sicherzustellen.


Einsatzleiter starten normalerweise eine synchrone Sprachkommunikationslinie, beispielsweise ein Slack-Huddle oder ein Google Meet-Meeting. Dadurch wird sichergestellt, dass die für die Lösung des Vorfalls wichtigen Personen in ständigem Kontakt bleiben. Es ist erstaunlich, wie effektiv diese kleine Sache ist, verglichen damit, dass man den Leuten erlaubt, Dinge einfach asynchron per Chat zu lösen.


Einsatzleiter müssen außerdem eine klare Delegation der zu erledigenden Aufgaben sicherstellen und dafür sorgen, dass für die Beantwortung dieser Aufgaben oder die Ergebnisse eine Rechenschaftspflicht besteht.


Wie heißt es so schön: Wenn man zwei Leute bittet, ein Pferd zu füttern, stirbt das Pferd. Ein Einsatzleiter verhindert, dass das passiert, und ist letztlich für die schnelle Lösung des Vorfalls verantwortlich.

Kommunizieren Sie klar und häufig

Die Leute verzeihen es oft, wenn ihre Lieblings-App oder -Software ausfällt, wenn sie darüber informiert werden, wie hart das Team an der Lösung des Vorfalls arbeitet. Der Versuch, Dinge geheim zu halten, entweder weil Sie das Gefühl haben, den Vorfall nicht vollständig im Griff zu haben, oder weil es Ihnen und Ihrem Team peinlich ist, ist kein Grund, die Kommunikation nach außen zu unterbrechen.


Stellen Sie sicher, dass die Kommunikation gegenüber Ihren internen und externen Partnern präzise, häufig und transparent ist, da dies zum Aufbau von Goodwill beiträgt.
Quelle

Schuldlose Obduktionen sind entscheidend

Post-Mortem-Analysen oder Retrospektiven nach Vorfällen sind wichtig, um eine Kultur des Lernens aufzubauen, und sie müssen unbedingt schuldfrei sein. Seien Sie kritisch gegenüber dem Prozess, nicht gegenüber der Person. Niemand ist strenger zu sich selbst als die Person(en), die dies verursacht haben könnten, und Sie gewinnen nichts, wenn Sie sie in der Öffentlichkeit geißeln. Wenn überhaupt, deuten alle Untersuchungen darauf hin, dass Sie dadurch tatsächlich verlieren. Die Leute bei Etsy können viel besser darüber sprechen, also lesen Sie https://www.etsy.com/codeascraft/blameless-postmortems , wenn Sie mehr erfahren möchten.
Quelle

Nachuntersuchungen sind entscheidend

Während die Durchführung von Post-Mortem-Analysen wichtig ist, um Bewusstsein zu schaffen und Feedbackschleifen zu schaffen, um aus diesen Vorfällen zu lernen, sind die besprochenen Maßnahmen, um diese in Zukunft zu verhindern, vielleicht noch wichtiger. Wenn die Gruppe eine Reihe von Lücken oder Schwachstellen im System identifiziert hat, ist es äußerst wichtig, dass der Fokus und die Aufmerksamkeit darauf gerichtet werden, diese zeitnah zu beheben, um zu verhindern, dass das gleiche Problem erneut auftritt.


Es ist schwierig, Vorfälle zu verhindern, und das ist im Allgemeinen ein schwieriges Thema mit Ihrem Unternehmen und Ihren Kunden. Wenn derselbe Vorfall jedoch immer wieder auftritt, ist dies nicht nur viel schwieriger zu verteidigen, sondern weist auch auf ein schwerwiegendes Problem mit der Gesundheit und den Fähigkeiten des Teams hin.

Vorfälle sind nicht schlimm, solange die MTTD niedrig ist

Jeder versteht es. Sogar die Geschäftsleute verstehen es. Software zu entwickeln ist SCHWER, und in einer Welt, in der all unsere Software Hunderttausende von Abhängigkeiten hat, ist es unmöglich vorherzusagen, wo die Bruchlinien reißen könnten. Es wird Kacke am Dampfen sein, und das ist OK. Wir können Vorfälle nicht verhindern. Was jedoch wirklich hilft, ist sicherzustellen, dass die MTTD für Ihre Vorfälle wirklich niedrig ist.


Die mittlere Erkennungszeit (MTTD) ist ein Leistungsindikator (Key Performance Indicator, KPI), der die durchschnittliche Zeit misst, die eine Organisation benötigt, um einen Vorfall oder eine Sicherheitsbedrohung zu erkennen. Angesichts der Geschäftsdomäne, der Schwere der Auswirkungen usw. ist es schwierig, allgemeine Aussagen zu treffen. Wenn Sie jedoch Ihre MTTD auf Sekunden oder Minuten reduzieren können, können Sie die Auswirkungen eines Vorfalls wahrscheinlich deutlich verringern, im Vergleich zu Stunden oder Tagen (ganz zu schweigen von Wochen oder Monaten, was leider durchaus möglich ist).
Beispiel eines MTTD/MTTR-Diagramms (Quelle)

Humor lindert den Schmerz des Augenblicks

Das alles ist so ERNST! Geld geht verloren! Kunden machen schreckliche Erfahrungen! Trotzdem habe ich festgestellt, dass es bei all dem entscheidend ist, einen Sinn für Humor zu haben. Wir sollten nicht vergessen, dass jeder in diesem Prozess ein Mensch ist und unterschiedlich starkem Stress ausgesetzt ist. Wenn man an den richtigen Stellen eine Dosis Humor einbringt, kann man diesen Druck etwas abbauen.


Dadurch entsteht ein Gefühl der Kameradschaft, das dem Team das Gefühl gibt, alle im selben Boot zu sitzen und nicht, als ob sie auf einer Hölleninsel wären.


Das war's. Danke fürs Lesen!


⭐ Wenn Ihnen diese Art von Inhalten gefällt, folgen Sie mir oder abonnieren Sie https://a1engineering.substack.com/subscribe ! ⭐


Titelfoto von Julien L auf Unsplash