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 Themen, die wir ansprechen werden, sind:
Lassen Sie uns in einige Einzelheiten eintauchen!
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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