Blog

Jun 30, 2023

Zuverlässigkeit neu denken: Was Sie aus Vorfällen lernen können (und was nicht).

InfoQ-Homepage-Präsentationen „Zuverlässigkeit neu denken: Was Sie aus Vorfällen lernen können (und was nicht)“ Courtney Nash bespricht Forschungsergebnisse aus dem VOID, die die Standardpraktiken der Branche in Frage stellen

InfoQ-Homepage-Präsentationen Zuverlässigkeit neu denken: Was Sie aus Vorfällen lernen können (und was nicht).

Courtney Nash erörtert die im Rahmen des VOID gesammelten Forschungsergebnisse und stellt dabei branchenübliche Praktiken für die Reaktion und Analyse von Vorfällen in Frage, etwa die Verfolgung der MMTR und die Verwendung der RCA-Methodik.

Courtney Nash ist eine Forscherin, die sich auf Systemsicherheit und Ausfälle in komplexen soziotechnischen Systemen konzentriert. Sie war schon immer fasziniert davon, wie Menschen lernen und wie das Gedächtnis die Art und Weise beeinflusst, wie sie Probleme lösen. In den letzten zwei Jahrzehnten hatte sie verschiedene Redaktions-, Programmmanagement-, Forschungs- und Managementfunktionen bei Holloway, Fastly, O'Reilly Media, Microsoft und Amazon inne.

QCon Plus ist eine virtuelle Konferenz für erfahrene Softwareentwickler und -architekten, die die Trends, Best Practices und Lösungen der innovativsten Softwareunternehmen der Welt behandelt.

Treffen Sie die richtigen Entscheidungen, indem Sie herausfinden, wie leitende Softwareentwickler bei Early-Adopter-Unternehmen neue Trends übernehmen. Jetzt registrieren!

Nash: Ich bin Courtney Nash. Ich bin hier, um mit Ihnen über das Überdenken der Zuverlässigkeit zu sprechen und darüber, was wir aus Vorfallmetriken lernen können und was nicht. Ich bin Incident Internet Librarian bei Verica. Ich bin ein Forscher mit langjähriger Erfahrung an verschiedenen Orten. Ich habe das Gehirn studiert. Ich denke, Mountainbikes sind die coolste Technologie, die wir je erfunden haben.

Ich bin hier, um mit Ihnen über dieses Ding zu sprechen, das ich VOID genannt habe. Die Verica Open Incident Database ist ein Ort, an dem öffentliche softwarebezogene Vorfallberichte gesammelt und für jedermann verfügbar gemacht werden. Unser Ziel ist es, das Bewusstsein und das Verständnis für softwarebasierte Fehler zu schärfen, um das Internet widerstandsfähiger und sicherer zu machen. Warum interessiert uns das? Denn Software hat sich längst über das Online-Hosting von Katzenbildern hinaus auf den Betrieb von Transportmitteln, Infrastruktur und Hardware in Gesundheitssystemen sowie auf Geräte in Wahlsystemen und autonomen Fahrzeugen ausgeweitet. Von diesen modernen Online-Systemen wird erwartet, dass sie rund um die Uhr und 365 Tage im Jahr laufen. Der erhöhte Druck, mit dem Sie alle konfrontiert sind, hat in Kombination mit Softwaremodellen miteinander verbundener, zunehmend automatisierter Dienste, die in der Cloud ausgeführt werden, die Komplexität dieser Systeme beschleunigt. Wie Sie wahrscheinlich bereits aus eigener Erfahrung wissen, versagen diese komplexen Systeme auf unerwartete und chaotische Weise, wenn sie ausfallen. Wir alle haben Zwischenfälle. Ja, das ist ein Müllcontainerfeuer mit einem Drachen, der einen Vulkan in Brand setzt. Ich denke, dass das, was einem bevorsteht, wahrscheinlich eher wie bei Calvin und Hobbes ist, wo es sich wie ein Monster unter dem Bett befindet und man nie sicher ist, wann es herauskommen wird.

Der wirklich wichtige Punkt ist, dass die Technologiebranche über einen immensen Bestand an kommerzialisiertem Wissen verfügt, das wir teilen könnten, um voneinander zu lernen und die Ausfallsicherheit und Sicherheit von Software voranzutreiben. Wenn Sie diesbezüglich überhaupt skeptisch sind, verstehe ich das vielleicht. Dafür gibt es einen historischen Vorrang. Es ist nicht unsere Branche, es ist eine andere Branche. In den 1990er Jahren befand sich unsere Luftfahrtindustrie in den Vereinigten Staaten in einer kleinen Krise, wir hatten eine schreckliche Sicherheitsbilanz. Regelmäßig kam es zu erheblichen Unfällen mit schweren Folgen. Die Branche hat gemeinsam und von Grund auf beschlossen, zusammenzukommen und zu versuchen, etwas dagegen zu unternehmen. Zunächst kamen verschiedene Piloten verschiedener Fluggesellschaften zusammen und begannen, ihre Vorfalldaten auszutauschen. Sie begannen, ihre Geschichten und Muster dessen, was sie sahen, zu teilen. Schließlich beteiligten sich weitere Vertreter dieser Branche, die Regulierungsbehörden, die Fluglotsen und eine große Anzahl von Menschen, um ihre Vorfälle zu teilen und Gemeinsamkeiten und Muster zu finden. Im Laufe dieser Maßnahmen und natürlich auch anderer Aktivitäten hat sich die Sicherheitsbilanz unserer Luftfahrtindustrie erheblich verbessert. Tatsächlich hatten wir keinen nennenswerten Vorfall, bis einige der Boeing MAX-Sachen der letzten Jahre passierten. Es ist möglich, dies von Grund auf als Praktiker durchzuführen, bevor überhaupt Aufsichtsbehörden auftauchen. Das ist wichtig.

Wir versuchen, solche Vorfälle zusammenzufassen. Es gab in der Vergangenheit noch keinen Ort, an dem wir alle diese sogenannten Verfügbarkeitsvorfälle hatten. Es gibt eine Reihe von Menschen, die diesen Weg vor mir gegangen sind. Ich behaupte nicht, dass das meine Idee war. Ich hatte einfach das Glück, vielleicht mehr davon an einem Ort zusammenzubringen. Derzeit verfügen wir über fast 10.000 öffentliche Vorfallberichte von über 600 Organisationen aus der Zeit von etwa 2008 bis heute in verschiedenen Formaten. Das ist wichtig. Wir sammeln sie in Social-Media-Beiträgen, Statusseiten, Blogbeiträgen, Konferenzvorträgen, Tweets und vollständigen, umfassenden Nachberichten zu Vorfällen, in denen Sie sich alle zusammensetzen und noch viel mehr Informationen zu diesen Dingen aufschreiben . Wir wollen all das, weil wir ein wirklich umfassendes Bild davon haben wollen, nicht nur, wie Sie diese Dinge sehen, sondern auch, wie andere Menschen sie sehen. Dort sind auch Dinge wie Medienartikel enthalten.

Darin sind eine Reihe von Metadaten enthalten, die wir gesammelt haben, beispielsweise die Organisation, das Datum des Vorfalls, das Datum der Meldung und vieles mehr. In diesem Vortrag konzentrieren wir uns vor allem auf die Dauer und ihre Beziehung zu einer Kennzahl, die in unserer Branche sehr einflussreich ist, nämlich der mittleren Reaktionszeit (MTTR). Schauen wir uns zunächst die Dauer an. Die Dauer nenne ich gerne graue Daten. Die Variabilität ist hoch, die Wiedergabetreue gering. Es ist unklar, wann beginnt es, wann endet es? Wie werden diese Dinge entschieden und aufgezeichnet? Manchmal ist es automatisiert, oft nicht. Manchmal wird es aktualisiert, manchmal nicht. Letztlich ist es ein nachlaufender Indikator dafür, was in Ihren Systemen passiert ist. Es ist von Natur aus subjektiv. Wir entscheiden über diese Dinge. Wir glauben, dass sie aus unseren Systemen ausgespuckt wurden, aber das stimmt nicht ganz. Die Realität sieht so aus: Wenn man alle diese Grauzonen als Objektive betrachtet, sie mittelt und versucht zu glauben, dass dies ein wichtiger Indikator für die Leistung ist, erhält man einen großen grauen Fleck. Darauf kann man sich nicht verlassen.

Ich möchte Ihnen einen kleinen Teil dieser grauen Daten in Aktion zeigen. Hierbei handelt es sich um mittlere Reaktionszeiten, die wir auf der Grundlage von Daten zur Vorfalldauer im Wert von fast 7.000 Sekunden von der VOID erfasst haben. Es ist wirklich verlockend, sich diese anzusehen und zu versuchen, sie als Indikator zu verwenden. Vielleicht sind Cloudflare und New Relic einfach besser in der Reaktion auf Vorfälle, vielleicht sind ihre Systeme weniger komplex, oder sie haben häufiger Glück. Nein, diese Daten geben keinen Hinweis auf all diese Dinge. Wie Sie sehen, gibt es selbst innerhalb eines Unternehmens über einen bestimmten Zeitraum große Schwankungen, je nachdem, in welchem ​​Zeitfenster Sie versuchen, so etwas wie einen Mittelwert über diese Daten zu berechnen. Das Problem beim Versuch, Zahlen wie diese zu verwenden, die aus den grauen Daten der Dauer abgeleitet werden, wird durch die inhärente Verteilung dieser Dauerdaten verschärft.

Ich weiß nicht, wie viele von Ihnen sich tatsächlich die Verteilung angesehen und ein Histogramm Ihrer Daten zur Vorfalldauer erstellt haben, sofern Sie diese sammeln. Lassen Sie uns ein wenig zurückgehen. Dies ist eine Normalverteilung, etwas, an das Sie sehr gewöhnt sind. Es ist Ihre klassische Glockenkurve. Es gibt eine wirklich klare Mitte. Auf beiden Seiten gibt es ähnliche Kurven. Sie können den Mittelwert in der Mitte festlegen. Sie können Standardabweichungen erhalten. Damit können Sie alle möglichen tollen statistischen Dinge tun. So sahen Ihre Daten nicht aus, basierend auf fast 10.000 Vorfällen, die wir im VOID haben. So sehen Ihre Vorfalldaten tatsächlich aus. Dabei handelt es sich um Histogramme der Verteilung von Dauerdaten über eine Vielzahl von uns vorliegenden Unternehmen, die über genügend Daten verfügen, um dies tatsächlich durchzuführen, zumindest Hunderte von Vorfällen. Sie sind schief, wie Sie vielleicht bemerken. Sie sind auf der linken Seite des Diagramms hoch, fallen dann ab und haben dort einen schönen langen Schwanz. Das Problem bei solchen verzerrten Verteilungen besteht darin, dass sie nicht gut durch zentrale Tendenzmetriken wie den Mittelwert beschrieben werden können. Einige von Ihnen werden anfangen zu denken: Wir verwenden den Median und dann kommen wir ans Ziel. Selbst wenn Ihre Daten so unterschiedlich sind, ist es sehr schwierig, die Unterschiede zu erkennen. Das ist es, was wir oft versuchen. Wir versuchen zu sagen, dass unsere MTTR besser geworden ist. Unsere MTTR hat sich verschlechtert. Was ist passiert? Es stellt sich heraus, dass das einfach keine Bedeutung hat.

Wir hatten uns letztes Jahr einen Bericht eines Ingenieurs bei Google angesehen, der viele Daten hatte, die unseren sehr ähnlich sahen. Er hat in diesem Bericht, der im O'Reilly-Bericht enthalten ist, den ich dort gezeigt habe, eine Reihe von Monte-Carlo-Simulationen durchgeführt. Als er einen Rückgang der MTTR in einem großen Teil der Monte-Carlo-Simulationen simulierte, stellte er fest, dass die Daten so stark schwankten, dass diese Veränderung tatsächlich nicht mehr erkannt werden konnte. Tatsächlich subtrahieren Sie 10 % von Ihrer Laufzeit und verkürzen so Ihre MTTR. Sie führen eine Reihe von Simulationen der Originaldaten für diese kürzeren Zeiträume durch und können tatsächlich keinen Unterschied feststellen. Ich zeige Ihnen eine Grafik davon. Was er herausgefunden hat und was wir auch wiederholt haben, als wir das Gleiche bei noch mehr Unternehmen bei noch mehr Vorfällen gemacht haben, war, dass selbst bei der Einführung von Verbesserungen festgestellt wurde, dass die festgestellte Änderung der MTTR in fast einem Drittel der Fälle negativ war. Es ist ein wenig kontraintuitiv, aber sagen wir einfach, das bedeutet, dass die Dinge schlimmer geworden sind. So sehen diese Daten aus. Sie subtrahieren die Originaldaten von den geänderten Daten. Ein positives Ergebnis bedeutet, dass die Dinge besser geworden sind. Dies sind unsere Ergebnisse, die Davidovics Monte-Carlo-Simulationen nachbilden. Alles auf der rechten Seite bedeutet, dass es besser geworden ist, und alles auf der linken Seite bedeutet, dass es schlechter geworden ist, dass Ihre MTTR tatsächlich gestiegen ist. Was Sie sehen werden, ist, dass es bei einem großen Teil der meisten Kurven, die Sie sehen, Stellen gibt, bei denen Sie denken, dass Sie sogar besser als 10 % abgeschnitten haben, und Stellen, bei denen Sie möglicherweise sogar schlechter als 10 % abgeschnitten haben. Das ist wirklich das Wichtigste. Die Varianz ist zu groß, als dass man sich auf den Mittelwert verlassen könnte. Diejenigen unter Ihnen, die sich mit der Verteilung befasst haben und ein wenig oder sogar viel über diese Dinge wussten, könnten sagen, wir könnten den Median verwenden. Wir haben diese Simulationen mit den Mediandaten durchgeführt und die Ergebnisse waren unglaublich ähnlich. Bei den meisten dieser Daten gibt es einfach immer noch zu große Variabilität und nicht genügend Stichprobengröße, um tatsächlich etwas zu erkennen.

Lassen Sie uns über die Stichprobengröße sprechen. Die Firma, die den großen Roten hatte, hat nach allen uns vorliegenden Daten die meisten Vorfälle von allen. Sie verfügen über genügend Daten, sodass Sie möglicherweise eine gewisse Genauigkeit aus Dingen wie dem Mittelwert und der Durchführung dieser Art von Monte-Carlo-Simulationen und all diesen Dingen gewinnen können. Das bedeutet wirklich, dass die einzige Möglichkeit, eine bessere Genauigkeit Ihrer Vorfalldaten zu erreichen, darin besteht, mehr Vorfälle zu haben. Das ist wirklich nicht das, was irgendjemand von uns will. Man muss in die oberen Hunderter, fast Tausende vordringen, um engere Kurven zu erkennen und Unterschiede zwischen den Dingen erkennen zu können. Das will niemand. Wir wollen nicht, dass es noch mehr Vorfälle gibt.

Um es kurz zusammenzufassen: MTTR ist kein Indikator für die Zuverlässigkeit Ihres Systems. Ich denke, das ist ein in unserer Branche weit verbreiteter Mythos, der einem sagt, wie zuverlässig man ist. An den Daten, die Sie gerade gesehen haben, ist nichts Verlässliches. Sie möchten keine unzuverlässige Metrik verwenden, um über die Zuverlässigkeit oder Belastbarkeit oder irgendetwas anderes Ihrer Systeme zu sprechen. Es kann Ihnen nicht sagen, wie agil oder effektiv Ihr Team oder Ihre Organisation ist, da Sie diese Dinge nicht vorhersagen können. Man kann definitiv nicht vorhersagen, welche überraschend sind, und sie sind alle überraschend. Das MTTR sagt Ihnen nicht, ob Sie besser auf Vorfälle reagieren können, ob der nächste länger oder kürzer sein wird oder wie schlimm ein bestimmter Vorfall ist. Ich möchte ein wenig Zeit damit verbringen, nur eine kleine Abwechslung. Weil die meisten Leute einen gewissen Verdacht hegen, dass die längeren schlechter sind oder dass die längeren nicht so schlimm sind, weil wir alle auf die schlechten werfen und diese schneller erledigt sind. Die längeren sind so, wie auch immer, wir können sie einfach laufen lassen. Auch das zeigen unsere Daten nicht. Wir hatten etwa 7000 Vorfälle, bei denen wir die Dauer und den Schweregrad erfassen konnten. Dabei handelte es sich größtenteils um Statusseiten dieser Unternehmen. Was Sie in dieser Grafik sehen, ist, wie es für die meisten Menschen wirklich aussieht. Es gibt lange, die schwerwiegender sind. Sie sind in den Farben Gelb, Rot. Es sind die 1er und 2er. Es gibt kurze Einsen- und Zweier-Sätze. Es gibt lange Exemplare, die 3er und 4er lang sind, sie sind grün und blau, sie sind nicht so schlecht. Das Aussehen dieses Diagramms entspricht unserem statistischen Ergebnis. Wir haben eine Spearman-Rangkorrelation für jeden, der sich wirklich ins Zeug legen will, über den Schweregrad und die Dauer hinweg durchgeführt, und nur zwei der von uns untersuchten Unternehmen zeigten eine Korrelation zwischen Dauer und Schweregrad, die jeder für sehr schwach halten würde: -0,18 , -.17 R-Werte, sie hatten signifikante p-Werte. Im Bereich von Korrelationsanalysen bis zu 0,2 und 0,3 handelt es sich um einen sehr geringen Effekt. Manches sieht man vielleicht ein wenig, aber man muss auch über viele Daten verfügen, damit ein solcher Effekt sichtbar wird.

Diese Dinge, Dauer, MTTR, Schweregrad, bezeichnen John Allspaw und viele von uns mittlerweile als oberflächliche Kennzahlen, weil sie die chaotischen Details verschleiern, die über Vorfälle wirklich informativ sind. Ich wollte dazu nur eine Metapher verwenden, die wahrscheinlich für jeden von uns, der derzeit im Westen der USA lebt, ziemlich relevant ist. Ihre Systeme sind von Natur aus komplex, und der Versuch, die Reaktion auf Vorfälle für diese Systeme anhand von Dingen wie Dauer oder MTTR zu messen, ist so, als würde man beurteilen, wie Teams Waldbrände im Westen der USA bekämpfen, indem man die Anzahl der Brände zählt oder wie lange es dauert, sie zu löschen , im Gegensatz dazu, zu verstehen, was in der Realität für die Teams vor Ort passiert, und jedes einzelne ist so bemerkenswert anders. Das ist nicht die Antwort, die Sie wollen. Ich verstehe. Wenn es nicht MTTR ist, geraten Sie nicht in Panik. Wenn es nicht MTTR ist, was ist es dann? Die Antwort darauf ist aus meiner Sicht die Vorfallanalyse. Du wirst richtig sauer auf mich werden und schreien, das ist kein Maßstab. Nein, ist es nicht. Es ist das Beste, Ihnen etwas über die Belastbarkeit und Zuverlässigkeit Ihrer Systeme zu sagen.

Wie sehen solche Dinge aus? Welche Daten erhalten Sie aus der Analyse von Vorfällen? Ich weiß, dass wir denken, Daten seien Zahlen, Beobachtbarkeit und das, was aus Grafana herauskommt. Wir haben diese Erwartungen darüber, wie das aussehen wird. Es gibt immer noch Zahlen und Kennzahlen, die Sie aus solchen Ansätzen zur Untersuchung Ihrer Systeme gewinnen können. Ihre Systeme sind soziotechnisch. Sie sind eine Kombination aus Menschen und Computern und dem, was wir von ihnen erwarten, was bedeutet, dass Sie soziotechnische Daten sammeln müssen. Einige der Dinge, die ich hier zusammengestellt habe, damit Sie darüber nachdenken können, sind die Koordinierungskosten. Wie viele Personen waren daran beteiligt? Wurden sie über Nacht ausgerufen? Mussten sie mitten in der Nacht aufwachen, um damit klarzukommen? Wie viele einzigartige Teams gab es? Wie viele Personen waren dort beteiligt? Mussten sich PR und Kommunikation einmischen? Wie viele Tools, wie viele Kanäle? Es gibt so viele Dinge, die Aufschluss darüber geben, ob ein bestimmter Vorfall große interne Auswirkungen hat, außerdem, was Ihrer Meinung nach die externen Auswirkungen sind und wie gut Ihre Teams damit umgehen oder wie viel Ihr Unternehmen dafür aufwenden muss Komm damit klar.

Studieren Sie Beinaheunfälle. Wie viele Beinaheunfälle haben Sie im Vergleich zu wie vielen Vorfällen? Es ist viel mehr, was bedeutet, dass Ihr Erfolgs-Misserfolg-Verhältnis viel höher ist, als Sie denken. Sie verraten Ihnen Dinge, die Sie anhand von Kennzahlen wie Dauer oder MTTR nicht erfahren. Dann gibt es noch andere wirklich interessante Nebenwirkungen der Investition in die Analyse von Vorfällen, und zwar: Wie viel beginnen die Leute, in diese Dinge zu investieren und sich daran zu beteiligen? Wie viele Leute lesen diese? Sie können das völlig nachvollziehen und müssen sich keine Sorgen machen. Wie viele Menschen kommen tatsächlich zu solchen Nachberichten nach einem Vorfall und hören zu, was passiert? Werden diese Dinge geteilt? Wo sonst tauchen sie auf? Werden sie in PRs erwähnt? Werden sie in Codeüberprüfungen erwähnt? Es gibt alle möglichen Orte, und Sie können jede davon mit einer Nummer versehen, wenn Sie wirklich eine Nummer für jemanden weiter oben in der Kette auf eine Folie setzen müssen.

Ich möchte etwas mehr über den Aspekt der Beinahe-Unfälle sprechen, nämlich dass Beinahe-Unfälle Erfolge sind. Wenn man sich die Aufzeichnungen dieser wenigen Beinaheunfälle ansieht, haben wir fast keine davon, bei weitem weniger als ein Prozent davon im VOID. Sie sprechen über die Art von Dingen, die sie bei Beinaheunfällen finden, die sie nicht einmal in Vorfallberichten finden. Hierbei handelt es sich um umfangreiche Datenquellen darüber, wo in Ihrer Organisation oder in Ihrem Team Anpassungsmöglichkeiten bestehen. Carl Macrae hat dieses wirklich großartige Buch mit dem Titel „Close Calls“, in dem er über Beinahe-Unfälle als Quellenmaterial für die Befragung des Unbekannten spricht. Sie können Annahmen testen und Erwartungen validieren, sich der Unwissenheit bewusst werden und auch beobachten, wie sich Erfahrungen in Ihrem Unternehmen auswirken. Sie verdeutlichen auch, wo Menschen ihr Fachwissen einsetzen und Anpassungsfähigkeit bereitstellen, wenn sich ihr System auf unvorhergesehene oder erwartete Weise verhält, was bei Vorfällen der Fall ist. Sie enthalten oft viel umfassendere Informationen über soziotechnische Systeme, einschließlich Dinge wie Wissenslücken und Störungen in der Kommunikation und sogar Dinge wie kulturelle oder politische Kräfte auf Ihren Systemen.

Als nächstes möchte ich über eine weitere Sache sprechen, die wir bisher im VOID verfolgen, nämlich die Analysemethoden, die die Leute verwenden. Wir sind sehr an der Verwendung der Ursachenanalyse (RCA) interessiert. Ich werde darüber sprechen, warum. Letztes Jahr haben wir gesehen, dass etwa 26 % der Organisationen entweder offiziell erklärt haben, dass sie eine Ursachenanalyse verwenden, oder in ihren Berichten eine bestimmte Ursache identifiziert haben. Diese Zahl ist dieses Jahr deutlich zurückgegangen. Ich möchte nur klarstellen, dass wir von etwa 2.000 Vorfällen auf etwa 10.000 Vorfälle gestiegen sind, also hat sich der Nenner geändert. Diese 6 %-Zahl haben wir in derselben Berichtsreihe nicht gesehen. Ich möchte hier ganz klar sein. Wir fangen an, dieses Korpus im VOID aufzubauen. Das ist ein falsches Ergebnis. Ich möchte darüber sprechen, warum uns die Grundursache am Herzen liegt, und über einige interessante Entwicklungen, die seit dem letzten VOID-Bericht stattgefunden haben. Eine sehr formelle Ursachenanalyse geht davon aus, dass ein Vorfall eine einzige spezifische Ursache oder einen einzigen Auslöser hat, ohne den er nicht passiert wäre. Es ist sehr linear. Sobald der Auslöser erkannt wird und daraus eine Lösung entsteht, kann die Organisation Maßnahmen ergreifen, um sicherzustellen, dass so etwas nie wieder passiert. Diese Denkweise mit linearer Abfolge von Ereignissen, die auch als Domino-Modell bekannt ist, hat ihren Ursprung in der Theorie von Arbeitsunfällen. Wir haben es übernommen, wir haben das übernommen. Weil wir sie erst im Nachhinein suchen, ist die Realität so, dass wir keine Ursachen finden, sondern sie konstruieren. Wie Sie sie konstruieren und auf welche Beweise Sie zurückgreifen, hängt davon ab, wo Sie suchen, wonach Sie suchen, mit wem Sie sprechen, wen Sie schon einmal gesehen haben und wahrscheinlich für wen Sie arbeiten.

Zwischen dem letzten Bericht und diesem ist etwas Lustiges passiert, denn wir hatten letztes Jahr zwei wirklich große Unternehmen im VOID, die Ursachenanalysen durchführten, es waren Google und Microsoft, wir haben dieses Jahr Atlassian hinzugefügt, was die Zahl zumindest beibehalten hat etwas höher. Zwischen diesem letzten Bericht und Juni dieses Jahres hat Microsoft die Ursachenanalyse eingestellt. Ich finde das faszinierend, denn wenn eine Organisation von der Größe von Microsoft Azure, eine sehr große Organisation, ihre Denkweise und Herangehensweise ändern kann, kann das jeder von uns. Jeder von uns kann seine Denkweise und Herangehensweise an die Art und Weise ändern, wie wir darüber nachdenken und wie Vorfälle uns über unsere Organisationen informieren. Ich denke, Sprache ist wichtig. Microsoft hat das erkannt. Sie erkannten, dass Sie, wenn Sie eine Reihe von Einflussfaktoren identifizieren, insbesondere wenn diese soziotechnischer Natur sind, einen ganz anderen Ansatz dafür verfolgen, wie Ihr Team über die Systeme denkt, mit denen es zu tun hat. Wenn Sie diese neuen Berichte lesen, nennen sie sie Post-Incident Reports, PIRs, weil wir alle immer noch ein Akronym brauchen. Sie sind auch sehr unterschiedlich, da sich die Details in diesen Berichten, die Herangehensweise und die Denkweise über ihre Systeme verändert haben. Ich sage das nicht nur, weil das Microsoft Azure-Team plötzlich sagte: „Wir werden uns nicht um die Ursache kümmern“, das war alles nur ein Teil der Art und Weise, wie sie ihren Ansatz geändert haben. Ich muss nur sagen: Wenn Microsoft das kann, können Sie das auch.

Wir brauchen einen neuen Ansatz dafür, wie wir über Vorfälle nachdenken, sie analysieren, darüber reden und sie untersuchen und wie wir die daraus gewonnenen Informationen weitergeben. Der größte Teil davon besteht darin, Vorfälle als Gelegenheit zum Lernen zu betrachten und nicht als Scham oder Schuldzuweisungen. Ich freue mich so sehr, dass so viele weitere Unternehmen ihre Vorfälle teilen und das nicht als einen Ort betrachten, an dem PR oder Marketing herumlaufen und sich Sorgen machen müssen. Sie bevorzugen außerdem eine tiefgehende Analyse gegenüber oberflächlichen Kennzahlen. Wir werden die MTTR hinter uns lassen und uns Gedanken über die Dauer und den Schweregrad machen, um dann tiefer in das Geschehen einzutauchen. Wir werden uns die Geschichten der Praktiker anhören, die an der Spitze stehen und nah dran sind, wie diese Systeme funktionieren. Wir werden das nutzen, um diese Systeme besser zu verstehen. Wir werden diese Praktiker und Menschen als Lösungen und nicht als Probleme betrachten und untersuchen, was richtig und was falsch läuft. Ich vermute, dass dieser neue Ansatz einen Wettbewerbsvorteil hat. Ich bin davon überzeugt, dass Unternehmen, die dies tun, in gewisser Weise reaktionsfähiger sein und über Anpassungsfähigkeiten verfügen werden, die andere nicht haben, was ihnen einen Vorteil gegenüber Unternehmen verschaffen wird, die die Welt nicht so sehen.

Ich möchte Sie dazu ermutigen, Ihre Vorfälle zu analysieren. Hier finden Sie einige Ressourcen zum Nachdenken darüber, wie das geht. Ich würde mich freuen, wenn Sie sie bei VOID einreichen. Es gibt ein Forum, ein praktisches Forum. Wenn Sie nicht viele haben, wenn Sie viele haben, können Sie sich an uns wenden und wir helfen Ihnen, diese dort einzuführen. Sie können tatsächlich Mitglied werden und sich auf verschiedene, engagiertere Weise beteiligen, wenn Sie Interesse daran haben. Einige dieser Daten habe ich auf den vorherigen Bericht vom letzten Jahr zurückgeführt, ein paar der Dinge, über die ich gesprochen habe, und noch ein paar mehr werden tatsächlich im nächsten Bericht enthalten sein, der bald erscheint.

Rosenthal: Sie haben erwähnt, dass bald ein weiterer VOID-Bericht herauskommt. Haben Sie jetzt einen Termin?

Nash: Das tue ich. Die Welt arbeitet jetzt zu meinen Gunsten. Es erscheint am 13. Die Leute können auf die VOID-Website gehen und dort gibt es einen praktischen, großen Button, um den Bericht herunterzuladen.

Rosenthal: Sie haben in Ihrer Präsentation grundsätzlich dargelegt, dass es keine Kennzahl gibt, anhand derer Sie die Zuverlässigkeit oder Belastbarkeit einer Website oder einer Anwendung kommunizieren können. Gibt es eine Möglichkeit, eine kombinierte Metrik zu erstellen, um sie auf eine Zahl oder etwas herunterzurechnen, mit dem Sie die Belastbarkeit oder Zuverlässigkeit Ihrer Website oder Anwendung darstellen können?

Nash: Nein. Ich wünschte. Wäre das nicht magisch und würden wir nicht alle diese Nummer haben und diese Nummer sammeln und diese Nummer feiern wollen? Leider nein, wir müssen uns die Mühe machen, uns mit diesen Dingen auseinanderzusetzen.

Rosenthal: Sie haben erwähnt, dass Sie die Monte-Carlo-Simulation nachgebildet haben, die jemand bei Google durchgeführt hat. Können Sie etwas mehr darüber sagen, wie Sie das reproduziert haben? Gab es ein Team, das das gemacht hat? Was ist da drin?

Nash: Ja, das haben wir. Erstens war es jemand anderes, der besseren R-Code schreibt als ich. Wir hatten tatsächlich einen Praktikanten von der University of British Columbia, dessen Name William Wu ist. Er hat uns tatsächlich dabei geholfen. Er macht seinen Doktortitel in Evolutionsökologie und studiert große, komplexe biologische Systeme, was wirklich cool ist. Er interessierte sich wirklich dafür, wie unsere komplexen soziotechnischen Systeme funktionieren. Wir haben alle diese Vorfalldaten genommen und sie in zwei Gruppen eingeteilt. Anschließend können Sie damit Experimente durchführen, beispielsweise A/B-Tests. Dafür braucht es nicht viele Leute. Ich hatte eine Person, die wirklich großartigen Code geschrieben hat, und das hat uns auch ermöglicht, viel herumzustöbern. Wir haben uns die Verteilungen genau angesehen. Er versuchte, Machtgesetze an die Dinge anzupassen. Sobald wir alle diese Daten hatten, konnten wir sie in verschiedene Gruppen einteilen und dann alle diese Theorien an ihnen testen, aber leider scheiterten einige davon.

Rosenthal: Sie haben erwähnt, dass Microsoft zumindest bei Azure kein RCA mehr macht.

Nash: Die Azure-Gesundheitsstatusseite für alle ihre verschiedenen Dienste, ja.

Rosenthal: Wenn ich bei einem Unternehmen arbeite, das nicht Microsoft Azure verwendet, was würden Sie mir dann als einziges empfehlen, um meinen Verfügbarkeitsprozess zu verbessern, nicht MTTR? Wenn ich nur eine Sache ändern könnte, wäre es, mit RCA aufzuhören oder etwas anderes?

Nash: Hier sage ich, dass Sprache wichtig ist. Selbst wenn Sie das tun, was Ihr Team offiziell RCA nennt, möchten Sie wirklich jemanden oder jemandes Leute haben, der über die entsprechenden Fähigkeiten verfügt, sich mit solchen Vorfällen zu befassen. Ich habe gesehen, dass Menschen in der Lage sind, diese Arbeit in Umgebungen durchzuführen, in denen immer noch der Glaube herrscht, dass man eine Ursache finden kann. Wir beobachten einen Trend dahingehend, dass Leute Vorfallanalytiker einstellen oder Leute einstellen, die schon einmal im SRE-Team waren oder was auch immer. Die Fähigkeiten, die Sie in die Untersuchung Ihrer Vorfälle investieren müssen, unterscheiden sich stark von den Fähigkeiten, die zum Aufbau und Betrieb dieser Systeme erforderlich sind. Wenn ich etwas tun müsste, würde ich in eine Person oder ein Team von Leuten investieren, die in der Lage sind, Vorfälle zu untersuchen und diese Informationen an die Organisation weiterzuleiten, damit die Leute daraus lernen können. Diese Fähigkeiten entwickelten sich innerhalb des Azure-Teams und führten zu einem größeren Bewusstsein dafür. Ich denke, dass die Veränderung in der Denkweise dort auf die Investition in die Menschen und einen wirklich anderen Ansatz beim Lernen aus Vorfällen zurückzuführen ist. Dann, sagten sie, machen wir jetzt etwas anderes. Wir können es anders nennen und wir werden sehen, was die Welt darüber denkt. Sie haben tatsächlich um Feedback dazu gebeten, was ich faszinierend finde. Das Einzige ist, Leute zu haben, die wirklich gut darin sind, Vorfälle zu untersuchen.

Rosenthal: Was denken Sie über den Fehlerkorrekturansatz, den Amazon verwendet? Haben Sie irgendwelche Gedanken dazu im Zusammenhang mit RCA?

Nash: Wenn Sie einen Vorfall untersuchen, korrigieren Sie keine Fehler. Sie lernen, wie Ihre Systeme funktionieren. Unterwegs können Sie einige technische Dinge reparieren und hoffentlich einige soziotechnische Dinge ändern. Ich denke, dass die Sprache eine ähnliche Denkweise hat wie RCA. Wir werden die Fehler korrigieren und die Fehler korrigieren. Was waren das für Fehler? Ich denke, es ist eine sehr enge Sichtweise, die die Sprache widerspiegelt.

Rosenthal: Es enthält fünf Gründe, Aktionspunkte und andere Dinge, die in anderer Form gezeigt wurden, dass sie nicht unbedingt die Zuverlässigkeit eines Systems verbessern, obwohl sie uns beschäftigen.

Was halten Sie von der vom Unternehmen wahrgenommenen Zuverlässigkeit im Vergleich zu Vorfalldaten?

Nash: Ich habe diesen Ausdruck im Vortrag verwendet, und es handelt sich um einen Begriff aus der Sicherheitswissenschaft. Es ist vielleicht etwas stumpf. Wir reden über Menschen mit der scharfen Spitze und dann mit der stumpfen Spitze, es ist ein Keil. Die Leute am oberen Ende haben typischerweise eine andere Wahrnehmung und ein anderes Verständnis von der Zuverlässigkeit ihrer Systeme als die Leute am eher stumpfen und weiter entfernten oder geschäftlichen Ende. Zwischen diesen beiden besteht oft eine große Diskrepanz. Ich spreche mit vielen SRE-Leuten. Ich spreche mit vielen einfachen Leuten, die diese Art von Systemen betreiben und oft sehr frustriert sind über das mangelnde Verständnis der geschäftlichen Seite der Dinge. Im Idealfall zielen einige SRE-Praktiken darauf ab, diese etwas besser zu verbinden, indem sie Dinge wie SLOs verwenden, die theoretisch darauf ausgelegt sind, die Leistung Ihres Systems an die Erwartungen seiner Kunden anzupassen, was auch immer diese sein mögen, wie interne Kunden oder so weiter. Normalerweise ist es ziemlich unzusammenhängend. Das Interessante an Unternehmen, die wirklich in diese detaillierte Analyse von Vorfällen investieren, ist, dass sie diese Realität offenbaren, wenn Sie die Arbeit leisten können, um diese Informationen weiter zurück in Ihr Unternehmen zu bringen.

Mein Lieblingsbeispiel dafür ist David Lee von IBM. Er ist im Büro des CIO, einer gigantischen Organisation innerhalb einer gigantischen Organisation. IBM ist riesig. Das Büro des CIO umfasst meiner Meinung nach letztendlich etwa 12.000 Personen. Es ist ihm gelungen, die Vorfallanalyse und den Überprüfungsprozess zu übernehmen und eine Umgebung zu schaffen, in der Führungskräfte zu diesen Erkenntnissen aus Vorfallüberprüfungen kommen, ich glaube, sie finden monatlich statt. Er verfolgt tatsächlich einige der Daten, über die ich gesprochen habe, etwa darüber, wie viele Leute zu den Meetings kommen, wie viele Leute die Berichte lesen und so weiter? Er beobachtet, wie sich dies innerhalb der CIO-Organisation durchsetzt. Er nimmt die Daten von der Spitze und bringt sie in das Unternehmen, und sie beginnen zu erkennen, wie die Realität vor Ort aussieht. Es erinnert mich an die Anfänge von DevOps, als wir versuchten, diese beiden Seiten der Organisation zu verbinden. Ich sehe immer noch so viel Kraft darin, eine Kultur rund um diese Vorfallanalysen aufzubauen, sie enthüllen so viel, dass man es normalerweise in einer gewissen Distanz zu dem, was auf der geschäftlichen Seite des Hauses geschieht, selten sieht. Da gibt es eine Lücke, die die Menschen schließen müssen. Es gibt noch viel zu tun, um diese beiden Gruppen in Einklang zu bringen.

Rosenthal: Sie haben zwei Möglichkeiten erwähnt, es nicht zu tun. Sie haben einen etwas besseren Prozess für die Investition in die Vorfallanalyse beschrieben. Ich werde das Howie-Dokument veröffentlichen, das die Meinung eines Unternehmens zu einem besseren Prozess zur Vorfallanalyse darstellt.

Nash: Der beste Prozess ist der, den Sie sich für Ihr eigenes Unternehmen ausdenken. Es gibt keine Vorlage. Es gibt kein Forum. Das ist auch sehr frustrierend. Ich habe beobachtet, dass dies in einigen Organisationen passiert, in denen man gerade erst damit anfängt, und einen Prozess, den man entwickelt, wenn man darin investiert, indem man aus Vorfällen lernt, wird der Prozess sein, den man weiterentwickeln, verfeinern und ändern kann Arbeit für Ihr Unternehmen. Das ist die Meinung eines Unternehmens, das darin sehr gut ist. Das heißt aber auch nicht, dass Sie es genau so machen müssen. Du musst einfach anfangen.

Weitere Präsentationen mit Transkripten ansehen

Aufgenommen am:

31. August 2023

von

Courtney Nash

Redis Enterprise. Die ideale Caching- und asynchrone Messaging-Lösung für Microservice-basierte Anwendungen. Laden Sie jetzt den Lösungsbrief herunter.