Grobe Pixel

Wir spielen Woche für Woche Retro-Games mit einem Schwerpunkt auf Adventures. Unsere aktuellen Eindrücke, vermischt mit nostalgischen Erinnerungen sowie knallharten Recherchen besprechen wir in diesem Podcast.

https://grobepixel.de

subscribe
share





episode 6: Fehlerkultur [transcript]


  • Wolfgang Schoch
    • Xing
    • Twitter
    • Linkedin
  • Christoph Petrausch
    • Twitter

Was ist eigentlich eine gesunde Fehlerkultur und wie kann man diese in einem Team oder Unternehmen voranbringen? Zu diesem Thema unterhalte ich mich mit Christoph Petrausch.

Christoph sorgt als Cloud Engineer dafür, dass die Infrastruktur von großen IT Systemen läuft. Bei seiner Arbeit ist ihm wichtig, dass man konstruktiv und offen mit Fehlern umgeht. Wir sprechen darüber, wie das im Alltag aussieht und gehen am Beispiel des Blameless Post Mortem darauf ein, wie man eine solche Fehlerkultur konstruktiv und zielgerichtet angehen kann.

Wenn dir der Podcast gefällt, dann bewerte ihn doch bei Apple Podcasts. Am liebsten natürlich mit einer kleinen Rezension. Das wäre eine Win-Win-Situation für uns! Denn mir hilft es, den Podcast ein bisschen bekannter zu machen und du wirst Teil von der nächsten Episode, wenn ich deinen Text vorlese. Deal? Hier gehts zu Apple Podcasts.

Shownotes
  • Kubernetes Failure Stories
  • Post-mortem-Analyse – Wikipedia
  • Google - Site Reliability Engineering
  • (Humor) Klingonische Softwareentwickler | C++ Community
  • Freitag, der 13. im Rechenzentrum | Die wunderbare Welt von Isotopp
Credits

Sprecher & Produktion: Wolfgang Schoch
Musik: BACKPLATE von https://josephmcdade.com


share







 2021-05-27  43m
 
 
00:07  Wolfgang
Hallo und herzlich willkommen bei digitale Anomalin. Mein Name ist Wolfgang Schoch und in diesem Podcast erzähle ich Geschichten von Computern und Katastrophen. Und von allem, was irgendwo dazwischen stattfindet.
00:17
Hier geht's um die wunderbare Welt der Technik und um all die Geschichten von Fehlern und vom Scheitern.
00:22
Der heutigen Folge Nummer sechs gibt's eine Premiere. Ich habe nämlich einen Gast, mit dem ich mich heute über das Thema Fehlerkultur unterhalte.
00:29
Hallo und herzlich willkommen Christoph. Stell dich doch bitte mal ganz kurz vor.
00:33  Gast
Ich bin Christoph Petrausch, ähm ich arbeite bei der Firma Enovex im Bereich IT-Engineering und Operations in allen
00:42
Klassischerweise Operations, also der Betrieb von Hardware und Services bei uns in letzter Zeit immer mehr in Richtung Cloud Services und da sind wir nicht nur im klassischen Betrieb,
00:53
Was ich mache ist so quasi ich bekomme eine Anwendung über den Zaun geschmissen und das,
00:57
dafür sorgen, dass sie läuft, sondern ich baue Plattform, sprich die Plattform, wo der Entwickler selber was draufschmeißen kann und dadurch entwickle ich auch viel Software selber, einfach um eine
01:08
sehr hohen Grad Automatisierung zu erreichen, den man mit Standardtools wie oder nicht erreichen kann. Deswegen baue ich viel Software selber und go.
01:16  Wolfgang
Könnte man das vereinfacht sagen, was du machst, du betreibst so was ähnliches wie die Cloud, die ominöse, von der man immer so hört.
01:23  Gast
Ja, wir bauen Clouds, ich baue Cloud selber, in meiner Twitter-Biografie habe ich stehen. Ich versuche schon, zu Software zu bauen, aber auch zu betreiben. Und aus der Betriebsbrille kommt halt der innere Rente Zwang, auch eine Fehlerkultur zu betreiben.
01:37  Wolfgang
Ja, da wären wir ja schon beim guten Stichwort
01:39
Fehlerkultur, äh das habe ich ja auch versucht in den ganzen letzten Episoden mal ein bisschen durchklingen zu lassen, dass ich das super wichtig finde, den den Umgang mit Fehlern und ich find's äh sehr wichtig, damit positiv umzugehen, weil ich glaube,
01:51
man da sehr viel draus lernen kann,
01:53
Und wir hatten uns ja im Vorfeld auch mal über das Thema Fehlerkultur unterhalten und äh dabei festgestellt, dass wir da eine eine ähnliche Meinung vertreten und äh deswegen habe ich dich hier auch eingeladen und freue mich, dass du heute da bist.
02:06
Ähm was bedeutet für dich eigentlich Fehlerkultur, Christoph?
02:10  Gast
Das Hauptding ist, ähm was man sehr schnell lernt, wenn man Software betreibt, ist äh dass Menschen Fehler machen, aber auch Fehler passieren in,
02:20
Maschinen oder in Software, dass da irgendwo ein Fehler passiert, irgendwas passiert, was nicht erwartet worden ist, meistens formt derjenige, der das programmiert oder zusammengesteckt hat, nicht erwartet und andererseits auch
02:30
berühmte Fettfinger. Ich habe einfach mal Inter zu schnell gedrückt und ähm habe jetzt einfach mal meine Datenbank gelöscht, wie die Jungs von zum Beispiel aus Versehen. Und sowas passiert einfach
02:40
Damit muss man versuchen umzugehen. Entweder
02:42
zwei Möglichkeiten, entweder ich bestrafe jemanden, der einen Fehler macht und er kriegt aufn Deckel und darüber versuche ich zu sorgen, dass derjenige keine Fehler macht, weil er weiß, dass er eine Strafe bekommt, wenn er einen Fehler macht. Das
02:54
führt aber dazu, dass die Leute sehr unglücklich werden, weil sie Fehler machen und auf den Deckel bekommen. Was man ja eigentlich möchte, ist, dass wenn ein Fehler passiert, den nie wieder passiert,
03:03
Und deswegen muss man sich eine Kultur aneignen, die A den Fakt eingesteht, dass man äh das Fehler passiert und dass die.
03:13
Immer passieren werden, egal wie gut man wird,
03:16
wie viel man äh an sicher ist, Mechanismen einbaut, einen gewissen Restfehler bleibt. Und dann muss man sich den Mechanismus überlegen, wie man diese Fehler, ähnlich wie im Scrum zum Beispiel, so ein Inspekt und Adapt macht,
03:30
Also sich guckt, warum ist der Fehler passiert und dann sein Vorgehen, seine Prozesse, seine Automatisierung, seine Software daran adaptiert, an dieser Art von Fehler. Genau, das ist eigentlich für mich eine Fehlerkultur, eine ordentliche.
03:41  Wolfgang
Jetzt könnte man natürlich sagen, hey, wenn jetzt irgendwo vielleicht in deinem Bereich, im Betrieb von so großen Softwareplattformen, wenn da jetzt eine Mitarbeiterin oder ein Mitarbeiter irgendwie äh
03:52
was dich nicht aufmerksam ist und äh deswegen vielleicht eine Warnung übersieht oder wie du's gerade gesagt hast. Ähm auf den falschen Knopf drückt und deswegen wie eine Datenbank löst, auf der halt lauter Produktivaten grad,
04:04
könnte man natürlich jetzt auch erstmal zuhause vielleicht aus dem Impuls raus sagen, hey, die Person hat jetzt was falsch gemacht, die war unaufmerksam, man könnte vielleicht auch ganz böse würde ich sagen.
04:12
Die ist zu dumm für diesen Job.
04:15
Kommt vielleicht dieser Impuls, man möchte jemand bestrafen, weil ich meine, hey, sowas habe ich in meinem ganzen Leben ja gelernt, schon als Kind, wenn ich was falsch gemacht habe, bin ich bestraft worden, wegen der Schule, was falsch gemacht habe, dann musste ich vor die Tür, ich war ab und zu mal vor der Tür
04:28
und ich könnte, ich könnte jetzt sagen, hey, puh, gesellschaftlich ist es mir total tief drin, wenn jemand einen Fehler macht, muss die Person bestraft werden.
04:37  Gast
Ja, aber wir gehen ja erstmal davon aus, dass jede Person das Beste gibt. Also es sie versucht das Beste zu machen und äh dadurch halt äh wenn ein Fehler passiert ist einfach.
04:49
In der Regel unabsichtlich. Es gibt natürlich noch absichtliche Fehler, dass es, wenn jemand absichtlich versucht, die Plattform zu sabotieren.
04:57
Aber auch dann kann man äh nachfolgend die Frage stellen, warum haben meine Prozesse es zugelassen, dass eine einzelne Person meine Plattform sabotieren konnte?
05:06
Konzept richtig.
05:08
Durchleuchte ich meine Mitarbeiter ordentlich? Habe ich als Manager einen guten Draht zu meinen Mitarbeitern und weiß, wie's ihnen geht? Also wenn da einer.
05:18
Quasi in sich hineinfrisst und irgendwann aus Wut alles kaputt macht,
05:23
Dann sollte ich mich vielleicht als der Manager oder der Vorgesetzte fragen, ähm warum habe ich das nicht erkannt? Warum.
05:30
Auf seine Arbeit. Wenn er doch gleichzeitig so hohe Privilegien hat, weil es gibt immer Menschen, die sehr hohe Privilegien in einem System haben.
05:40
Hat man nämlich mal die Abwägung zwischen ähm.
05:43
Man darf ganz viel.
05:45
Jemand, ich muss für jeden Schritt, den ich mache, einen zweiten haben, der das absegnet, das verlangsamt mich halt als Organisation in meiner Entwicklung.
05:55  Wolfgang
Also was du da sagst, finde ich super spannend. Ich habe das natürlich gerade auch ein bisschen provokant formuliert
06:01
Ich glaube, die Grundannahme, dass äh dass jeder im Team sein Bestes gibt und äh erstmal gute Absichten hinter den Handlungen stehen. Das finde ich, das ist was Elementares und.
06:14
Wenn jetzt jemand aus aus Boshaftigkeit was sabotieren möchte, dann hat es meiner Meinung nach auch mit Fehlern erstmal gar nichts zu tun. Das ist dann halt irgendwie Sabotage oder oder der kriminelle Handlung oder so. Ich glaube, das ist was, was man auch über
06:27
wirklich ganz gesondert irgendwo betrachten muss. Aber wenn's wenn's um Fehler geht, ja, es,
06:33
Es kann jedem ja passieren, dass dass man irgendwas falsches macht. Also es kann mir ja auch passieren, dass ich unaufmerksam bin wegen was anderem vielleicht und äh aus Versehen dann irgendwie ein Fehler, ein Fehler macht.
06:44
Und was du gerade noch gesagt hast, finde ich auch super spannend. Wenn Leute vielleicht so super gefrustet sind oder vielleicht super äh frustriert sind von ihrem Job und
06:53
und deswegen unaufmerksam sind oder ihre Aufgabe, nicht mehr diese Aufmerksamkeit entgegenbringen, die sie eigentlich bräuchten, um die jetzt wirklich zuverlässig zu äh zu erfüllen und deswegen dann Fehler passieren, dann ist das ja auch vielleicht ein
07:07
elementares, kulturelles Problem, dass es irgendwo im in der Unternehmung oder in der Firma irgendwo gibt.
07:13  Gast
Ein anderes gutes Beispiel ist ja auch ähm.
07:15
Wenn ich Mitarbeiter durch Bestrafung unter Stress setze, agieren sie quasi dauerhaft unter unter so einem latenten Stress, wer mag mich hoch sein, aber es ist immer im Hinterkopf der Stress, wenn ich jetzt was falsch mache, dann kriege ich aufn Deckel.
07:28
Wie wir alle wissen, unter Stress machten Menschen mehr Fehler.
07:32
Und wenn ich mich einfach sicher fühle, hey, ich kann das machen. Ich arbeite nach meinem besten Wissen und Gewissen und wenn's schief läuft, bringen wir das als Firma wieder ins ins Gerade.
07:42
Zusammen. Danach gucken wir, wie das passiert ist und danach wird mir das hoffentlich und auch keinem Kollegen je wieder passieren.
07:48
Das auch, wenn ich dieses diese Kultur in meiner Firma äh etabliere,
07:52
Habe ich auch noch den Effekt, dass wenn so was passiert ist, vielleicht irgendein älterer Mitarbeiter mal einem jüngeren oder anderen Mitarbeitern abends bei einem Bier, einem Lagerfeuer irgendeine Story erzählt, so weiß noch damals, als ich aus Versehen die falsche Umgebungsvariabel gesetzt habe und ganze Produktion gelöscht habe?
08:07
Noch, als wir da freitags abends statt Bier trinken, äh unter Schweiß, die Datenbank wiederhergestellt haben. Und das das sorgt halt dafür, dass A,
08:17
Der jüngere Mitarbeiter, der vielleicht noch nicht so erfahren ist, merkt, oh, Umgebungsvariablen, ich kann aus Versehen Produktionen löschen,
08:24
Muss ich vielleicht mal gucken. Muss vielleicht mal aufpassen und da muss er diesen Fehler nicht machen, der jüngere Mitarbeiter. Und das passiert dann, ohne dass ich.
08:33
Irgendwelche Schulungen machen musst, sondern es einfach am Lagerfeuer quasi. So eine informelle Wissensweitergabe.
08:40  Wolfgang
Ja, also ich könnte da, glaube ich, auch die ein oder andere Geschichte beisteuern. Also, wenn man, wenn man nicht mal irgendwann in der Zukunft am Lagerfeuer trifft, äh gerne mal drauf ansprechen, ähm da gibt's so einiges.
08:52
Ich finde, eine super wichtige Voraussetzung dafür ist äh Transparenz. Das heißt äh,
08:58
Es muss gewollt sein, dass man über alle möglichen Themen spricht, ohne dass da irgendwie eine Angst oder vielleicht auch eine Scham da ist, also so boah, ich habe hier irgendwas falsch gemacht, aber ich traue mich nicht drüber zu sprechen, weil die anderen, die denken vielleicht, ich bin dumm oder so.
09:12
Diese Art von Transparenz und Vertrauen, finde ich, ist halt die absolute Grundlage, äh damit du halt wirklich über so Dinge auch sprechen kannst. Und ich weiß nicht, wie's dir geht
09:21
Ich selber, ich mache natürlich ungern Fehler, weil für mich fehlt, fühlt sich's immer blöd, also.
09:27
Egal wie eine Fehlerkultur, egal wie alles Mögliche ist, im Unternehmen oder auch im privaten Umfeld, wenn ich irgendeinen Fehler mache, der erste Impuls, den ich habe, ist, oh Mist, hey, ah
09:37
Warum hast du das nicht gesehen? Oder warum oder so? Also habe ich immer,
09:42
aber ähm ich finde Fehler super lehrreich, weil ähm es ist ja auch eine totale Hybris anzunehmen,
09:48
Egal, was du tust, es funktioniert immer und es funktioniert auf Anhieb und beim ersten Mal.
09:54
Und äh es gibt, ich weiß nicht, ob das wirklich stimmt, aber es gibt diese Legende zumindest,
09:59
der diese mega Staubsauger und alle möglichen anderen Geräte entwickelt hat,
10:06
der irgendwie zwotausend Prototypen gebaut hat, bis er ein äh entwickelt hatte mit diesem, keine Ahnung, bin kein Staubsaugerexperte. Mit diesem Spezialprinzip, das irgendwie so phänomenal ist und ihn so reich gemacht,
10:18
und äh es gibt zumindest diese Legende auch, dass der Herr Edison damals zweitausend oder fünftausend Glühbirnen gebaut hat,
10:26
bis er eine hatte, die wirklich funktionierte, wo dann keine Ahnung der richtige Wolfram-Draht drin war und ich kein Glühbirnenexperte,
10:34
Da haben diese Erfinder ja auch gesagt, ja, ich habe zweitausend Möglichkeiten herausgefunden, wie's nicht funktioniert und jetzt weiß ich, wie's geht. Und ich finde das auch super inspirierend, weil.
10:43
Ja, du probierst was aus und äh,
10:46
gibst dein Bestes und bestes Wissen und Gewissen, alles cool. Und äh oftmals funktioniert's wahrscheinlich und manchmal funktioniert's nicht und
10:54
dann zu sagen, ha shit, hey, hat das nicht funktioniert? Ich hoffe mal, das hat keiner gesehen und ähm ich kann's unter den Teppich kehren und verheimlichen.
11:02
Ist ja total verschwendete Energie eigentlich, weil du hast ja so viel gelernt und wenn du das jetzt nur für dich behältst und selbst äh du selbst nix draus machst, weil du es vergessen möchtest, dass es eigentlich Verschwendung, finde ich.
11:16  Gast
Ja, ja, also es hat äh Devin Caroway meistens schön gesagt, äh the Cost of Failia ist Education. Durch Fehler kann ich lernen.
11:25
Also oder das Beste ist, wenn der Fehler passiert ist, habe ich ja eingangs gesagt, Fehler passieren immer und ich kann's halt jederzeit als als Lernmethode oder als als,
11:34
Lernmöglichkeit sehen, weil das, was ich an Fehler gemacht habe, will ich ja nicht noch mal machen. Im im technischen Umfeld, also wenn man irgendein System betreibt, wenn so ein Fehler passiert, sind's ja meistens nicht sehr offensichtliche Fehler, sondern das ist irgendwas.
11:48
Ganz vertrackt ist, irgendwas wie wo drei, vier Sachen zusammenkommen, zum Beispiel bei deiner Story mit dem Börsenunternehmen, was dann innerhalb von wenigen Sekunden äh.
11:58
Bis ihr ganzes Kapital äh vernichtet haben. Die Entwickler, die das dann Dieter Backen mussten, für die war das quasi ein, ich sage immer so schön, an
12:08
mussten das nämlich gebacken und sich sehr tief ins System absteigen. Und dabei lernt man auch was. Dabei lernt man Dinge kennen, die man sonst im normalen Programmieren oder anschauen des Kodes oder des Systems halt einfach
12:18
nicht sieht, weil man da nicht hingestupst wird. Wenn ich schon diese Fehler mache und diese Möglichkeit habe zu lernen, muss ich halt ja auch ergreifen. Und was wir da ganz gerne mal machen, im Betrieb von so Projekten,
12:27
ist halt
12:29
das ist unter anderem durch das erste Rebook von Google die Breite getreten worden, dies vorgehen. Ich weiß nicht, ob die's erfunden haben oder das so eine typische Evolution ist, äh jemanden wach. Du hast, erzählt was auf Brownbacks oder Meetups und,
12:42
dann machen's andere auch und dann wickelt sich halt so was raus.
12:47  Wolfgang
Jetzt mussten wir erstmal kurz erklären, was das SAE-Book von Google ist, weil ähm mir sagt das spontan gar nix.
12:53  Gast
Das ist ein Buch, ähm die haben mal, ich weiß, klappt das mittlerweile schon fünf Jahre alt, mal aufgeschrieben, wie sie ihr ihre Plattform und ihr ihre ganze Software betreiben,
13:05
bei Google gibt's quasi zwei große Softwareentwicklerrollen. Es gibt quasi keinen Entwickler.
13:12
Oder Betriebler, sondern es gibt äh die ähm Software-Engineers, die SVEs und die SREs, die Side-Rey-vility-Engineers.
13:21
Haben quasi als oberstes Ziel die Software und die Plattform stabil zu halten und machen dafür halt Engineering als entwickeln, eigene Software oder.
13:32
Entwickeln die Architektur so, dass sie schön, wenn ein Fehler passiert, schön kaputt geht oder so kaputt geht, dass nichts ganz so schlimm ist.
13:41
Sie haben in diesem SOE-Book halt mal ihre ganzen Methodiken und Tools beschrieben und aufgeschrieben.
13:47  Wolfgang
Also ihre Best Practice ist die äh tagtäglich da verwenden, okay.
13:52  Gast
Da gibt's halt auch einen Abschnitt zu Posmaltemps und Kultur.
13:57  Wolfgang
Herr Post-Mortem, das klingt jetzt für mich irgendwie nach so einer, nach so ungeklärten Verbrechen abends im Spätfernsehen, wo man sich dann nochmal irgendwelche Gerichtsmediziner anschaut, die
14:08
dann nochmal irgendwelche Knochen anschauen, um herauszufinden, was ursprünglich passiert ist.
14:13
Aber ich vermute mal, wenn du davon erzählst, hat's wahrscheinlich eher was mit mit Softwareentwicklung oder mit dem Betrieb von Softwaresystem zu tun.
14:22  Gast
Ja. So, wenn wenn so ein Software die Betrieb wird als Internetservice zum Beispiel ein Fehler passiert, dann.
14:29
Gibt's tatsächlich meistens so zwei Phasen-Scammern, die heiße Phase. Dann, wenn ein Fehler auftritt, weil zum Beispiel gerade äh irgendwie der Datenbank-Connection-Pool vorläuft oder sowas, dann wird halt meistens ein Entwickler oder,
14:43
SRE oder Admin, wie auch immer das in der Organisation organisiert ist,
14:48
kommt halt jemand und muss dieses Problem akut beheben. Der wird dann irgendeine Problembehebung machen. Das ist quasi dann die heiße Phase.
14:55
Nachdem das Problem behoben ist, wird er ein also nach, wie du schon sagst, wie der Gerichtsmediziner versuchen zu analysieren, warum ist es dazu gekommen, dass diese Datenbank-Connections volllaufen? Meistens ist auch schon,
15:08
So grob beim Debatten, weil man macht ja, stellt sich meistens eine Hypothese auf,
15:14
verifiziert die und wenn das diese Hypothese wahr ist, sucht man eine Gegenmaßnahme. Und dieses ist quasi eine strukturierte,
15:23
dieser ganzen Erkenntnisse, die man während dieser meistens sehr heißen Phase hatte. Und man nimmt sich auch in der Regel Zeit danach, also meistens, wenn's,
15:33
Zum Beispiel abends passiert am nächsten Tag oder wenn's halt morgens passiert ist, den Rest vom Tag, nimmt man sich einfach Zeit und schreibt das sehr strukturiert nieder. In diesem
15:41
Hat für mich eigentlich vier Dinge, das ist einmal das Beschreibende, also wie wie sieht jetzt der also wie sieht der Fehler aus?
15:50
Dann eine Analyse, also wie ist der der Fehler genau passiert, also technisch tiefe technische Analyse,
15:56
danach, ganz wichtig, ähm ich habe ja am Anfang gesagt, dass man Inspekt, also das war bisher, man beschreibt und analysiert, dass es das quasi mal ein Inspekted, also guckt rein.
16:07
Und dann adapt, kommt als nächstes Punkt die Action Items. Also ich schreibe mir ein paar smarte auf, was mache ich? Dass mir das, was ich hier gesehen habe, nicht wieder passiert.
16:16
Das schreibe ich dann auf quasi, was will ich an meinem Monitoring verbessern, was muss ich an meiner Software verbessern? Und ganz zum Schluss kommt noch so eine kleine Retro.
16:25
Schreibe ich dann auf, wo hat mir zum Beispiel Glück? Kann ja sein, dass die Connection-Pools morgens um sechs vollgelaufen sind, wo es sowieso keiner meine Software nutzt.
16:33
Und nicht mittags um zwölf, wenn grad alle Mittagspause machen wollen und jetzt ihr ihr Land spuchen wollen über meine Essensbuchplattform.
16:41  Wolfgang
Das heißt, äh um um das vielleicht nochmal ein bisschen zu zusammenzufassen
16:44
Du hast so zwei, du hast so zwei Phasen, wenn wenn irgendwo was was passiert, also du hast du hast deine, ja, vielleicht so, keine Ahnung
16:52
Christophs Essens Delivery Plattform, wo ich mir mittags irgendwie was bestellen kann und ich bekomme's dann geliefert von dir und deinen Freunden und Freundinnen per Fahrrad zum Beispiel, wenn man sowas mal als Beispiel hat
17:02
und da funktioniert irgendwas nicht. Die die Webseite ist nicht erreichbar. Bei euch leuchten irgendwelche roten Lampen im Betriebsraum
17:10
und äh da geht erst mein Team ran und schaut sich das an,
17:14
wahrscheinlich Leute, die sich mit der ganzen Materie auskennen, weil die das jeden Tag irgendwie betreiben oder weil sie's aufgebaut haben, sprich Leute, die genau wissen, okay, wenn's hier rot leuchtet, dann müssen wir da mal reingehen und uns das mal anschauen. Und das ist so diese, diese erste Phase, wenn Fehler auftritt,
17:28
nachvollziehbar, okay? Es es hakt irgendwo und man man möchte das wieder zum Laufen bringen. Dabei
17:34
macht man sich natürlich auch ein paar Notizen und sagt, okay, hier äh da ist eine Datenbank, die ist total voll, überall überlaufen, war kein Platz mehr drin.
17:42
Bla, bla, bla und und dann schraubt man da vielleicht eine neue Festplatte rein, dass das wieder funktioniert
17:47
und äh irgendwann dann nach nach acht Stunden läuft wieder alles ähm dann atmen da erstmal durch und und trinkt vielleicht ein kaltes Bier.
17:56
Stoßt mal an und sagt, ja, geil, wir haben's geschafft, keine Ahnung warum, aber es funktioniert wieder
18:02
im Nachgang vielleicht am nächsten Tag, wenn alle mal geschlafen haben und wieder ein bisschen fit sind, dann setzt man sich so zusammen an den Tisch und schaut sich das komplette
18:10
das komplette Problem nochmal an und rekapituliert, was was da überhaupt passiert ist. Um draus zu lernen.
18:17
Man hört quasi nicht auf bei diesem äh bei diesem Bier oder bei dem Glas Sekt, wo man gemeinsam anstößt, wo man sagt, ja geil, wir haben's geschafft, wir sind wir sind ein cooles Team, tschakka
18:27
sondern äh man geht das nun mal richtig tief rein in das Problem und zertröselt, weiß nicht, gibt's das Wort zertröselt, keine Ahnung.
18:35
Ansonsten habe ich's jetzt erfunden, okay, man zerdröselt das und sagt, okay, wir haben jetzt so eine Methode, diese Postmordenanalyse,
18:44
Das ist ein Werkzeug, das uns hilft, dieses Problem genau zu analysieren und vielleicht so diese implizite Fehlerkultur, die wir jetzt haben, vielleicht mit Hilfe zu dem Tool auch ein bisschen zu unterstützen,
18:55
Könnte man das so sagen?
18:57  Gast
Genau, es kann's damit unterstützen und den Namen und ich habe halt ein methodisches Vorgehen, also die Backen ist ja meistens eher.
19:06
Kaotisch und und äh Ereignis getrieben. Also ich habe eine neue Erkenntnis, versuche, dass versuche das dann umzusetzen,
19:14
Und was bei uns ab und zu auch manchmal rauskommt bei bei der Analyse ist, dass wir zwar den Fehler behoben haben.
19:20
Aber wir werden, dass die Banks äh eine ganz falsche Annahme getroffen haben, warum dieser Fehler überhaupt eingetreten ist. Wir haben zwar dieses richtige die richtige gewählt, also es ist,
19:30
Quasi das Richtige gemacht, aber warum's jetzt passiert ist, die den die Wut Kurses
19:35
das kommt dann quasi Tage später so, okay, deswegen war's, deswegen ist es passiert.
19:41  Wolfgang
Ja, ich kenne das auch noch aus meiner Zeit. Ich habe ja auch viele Jahre Software entwickelt und äh auch viele Jahre erfolgreich Fehler entwickelt. Wenn da irgendwo mal was gebrannt hat,
19:50
hey, man wollte halt den Fehler finden, man wollte das System wieder zum Laufen bringen und die Methoden, also zumindest bei mir und den Teams, in denen ich gearbeitet habe,
19:59
man da vorgegangen ist, ja so mega strukturiert war das nicht immer, das war oft auch einfach Chaos, Panik getrieben, so hey
20:06
Live-System, das steht schon 'ne Stunde, wir müssen's irgendwie hinbekommen und da hat man auch mal irgendwelche esoterischen Thesen genommen, OK, heute ist, äh, wir haben ein Schaltjahr und heute ist Freitag und es ist ein ungerader Tag, es könnte doch eventuell XY sein und
20:23
Manchmal hat's funktioniert, oftmals war's Blödsinn, aber war immer super froh, wenn man's, äh wenn man's irgendwie behoben hatte.
20:29  Gast
Genau, aber das ist halt dann Nachteil muss man halt dann strukturierter und vielleicht auch ein bisschen, ja, mit seiner Hypothese auch hinterfüttern.
20:38
Also, das deswegen passiert bei uns das auch immer als geschriebenes Dokument. Wir benutzen einfach Google Docs dafür, weil man da alle zusammen dran editieren können.
20:48
Bei uns ist es meistens mittlerweile so ein Bauchgefühl, okay, dieser Ausfall ist eine Postmorde wert, weil bestimmt viele Kunden getroffen worden sind. Also der Kundenpakt,
20:56
Ist groß genug oder für uns selber, der der Fehler ist groß genug, dann wird einfach während des Inzidens schon so ein so ein Google Dogs aufgemacht,
21:04
Einfach irgendwelche Screenshots oder irgendwelche Sachen, die er hat da rein.
21:09  Wolfgang
Sammelt da quasi schon Daten dann während dem ihr dran arbeitet.
21:12  Gast
Beschreiben auch meistens so eine Timeline auf, wer was wann gemacht hat, auch mit Namen. Aber was wir halt meistens machen in der Analyse und in der Beschreibung lassen wir die Namen weg. Da steht dann, wenn jetzt zum Beispiel der,
21:26
Wolfgang äh seine Unittests, die die Datenbankgruppen gegen Pott laufen lassen hat, steht dann in der Beschreibung nicht drin, der Wolfgang hat das gemacht, sondern.
21:32  Wolfgang
Es stimmt auch nicht. Ich habe nie Tests geschrieben, also.
21:35  Gast
Genau, also wer wer keine Fehler macht, braucht keine Tests, ne.
21:42  Wolfgang
Das ist die klingonische Softwareentwicklung. Wer sich dafür interessiert, einfach mal googeln, findet man wahrscheinlich noch klingonische Softwareentwicklung, da stehen genau diese Tipps drin.
21:52  Gast
In der Beschreibung lässt man halt den Namen weg, einfach, damit man nicht, also das könnte halt jedem passieren. Wenn's dann Beschreibung ist, quasi ein Entwickler oder einer der Entwickler hat seine Unitesse gegen Pott laufen lassen. Ist egal, ob der Wolfgang das war oder der Christoph oder
22:06
sonst wäre, dass es jemandem passiert, das hätte jedem passieren können. Klar und in der Timeline kann man noch den Namen aufschreiben, wenn man möchte,
22:14
Manchmal ist schon wichtig, wer was gemacht hat, um dann noch nachfragen zu können,
22:17
Hey, was hast du dann da gesehen? Aber eigentlich ist halt der Fokus das Display-Game wegzulassen, dies Fingerpointing.
22:24  Wolfgang
Deswegen ja auch äh Blaim Lastern im Namen. Jetzt äh stellt sich mir die Frage, eventuell könnte es natürlich schon relevant sein, welche Person das war, weil,
22:33
der Christoph dafür verantwortlich ist, der jetzt jeden Tag mit den ganzen Systemen arbeitet,
22:38
vielleicht ja die Ursache wieso dir der Fehler unterlaufen ist, ja ein anderer wie wenn jetzt,
22:44
Du hast eine neue Kollegin beispielsweise, die jetzt erst seit zwei Wochen dabei ist und die jetzt vielleicht diese Verantwortung hatte, aber noch gar nicht die Zeit hatte, um diese Systeme kennenzulernen und deswegen was übersehen hat, weil sie vielleicht nicht das nicht wusste, et cetera,
22:57
dann wäre ja die Ursache eigentlich eine andere, weil bei dir müsste man sagen, okay
23:02
Hat vielleicht Christoph diese Verantwortung gehabt? Warum konnte er das vielleicht tun? Keine Ahnung. Und wenn jetzt die, nennen wir es denn mal, keine Ahnung, die Tanja das macht, die jetzt seit einer Woche dabei ist und jetzt direkt hier irgendwie am Wochenende äh den Betrieb machen muss, bla, bla, bla,
23:16
dann ist es ja vielleicht einfach ein ganz anderes Problem, könnte man sagen, OK, dann haben wir hier ein Problem in unserem Prozess, wir
23:22
Müssen Leute, die jetzt so eine Verantwortung übernehmen, die müssen vielleicht ein halbes Jahr dabei sein, um das wirklich auch gelernt zu haben, um die Erfahrung gesammelt zu haben, damit man hier vielleicht solche
23:32
solche Probleme irgendwie reduzieren kann oder die Wahrscheinlichkeit, dass was passiert, vielleicht reduzieren kann. Keine Ahnung, wenn ich jetzt deinen Job machen müsste, könnte ich wahrscheinlich.
23:41
Wahrscheinlich könnte ich einfach nicht und ich sitze da vor so einer vor so einem Monitor mit lauter Lichtern, die es vielleicht, also so stelle ich es mir zumindest vor, was du so machst. Die ganzen roten Lampen überall. Ja, puh, ich gönne da mein Handy nehmen und anrufen und sagen, oh äh also jetzt haben wir schon zwölf rote Lampen.
23:56
Ist es schlecht?
23:58
Ist es da relevant, dann vielleicht doch in dem Hinblick, um uns herauszufinden, ist das ein technisches Problem, ist es ein Problem in unserem Prozess? Es hat unser Management hier vielleicht einen Fehler gemacht oder was übersehen, et cetera, also um diesen Bereich zu identifizieren.
24:13  Gast
Also ich würde halt schon schreiben, dass äh unerfahrene Entwickler das das passiert ist. Aber den Namen, ob's jetzt Tanja war oder Christoph, ich kann ja auch unerfahren sein.
24:22
Eine neue Technologie ist, ist ja eigentlich egal, wem es passiert ist.
24:25
Was natürlich relevant ist, auf so Eigenschaften, wie der der Entwickler hat oder die Entwicklerin, hatte einfach noch nicht genug Erfahrung oder war untrainiert. Das soll, muss man natürlich aufnehmen.
24:38
Aber der Name ist doch egal.
24:40  Wolfgang
Stimmt ja.
24:42  Gast
Also.
24:45
Wir haben meistens unterscheiden wir auch zwischen Root Corses und Trigger. Der Trigger ist quasi was zum Beispiel ausgelöst hat hier.
24:54
Zum Beispiel in deinem Beispiel wär's ein Root Cars wäre oder einer der Hut Corses, meistens sind's ja mehr als einer, was wir schon.
25:02  Wolfgang
Vielleicht kann man ganz kurz mal erklären, was ein ist.
25:06  Gast
Es ist das Englisch Wurzel Case, also Wurzelfall ist.
25:11  Wolfgang
Der Wurzelcase ist die deutsche Übersetzung für.
25:16  Gast
Das ist quasi die die Wurzel des Problems. Hoff, warum ist, also was ist eigentlich der der Kern des Problems? Was hat das Problem ausgelöst? Beziehungsweise nicht, was hat das aufgelöst, sondern was ist das Problem eigentlich.
25:28  Wolfgang
Die eigentliche Ursache, also
25:30
Ich ich kenne ich kenne so eine Methode, die heißt five wise, also wenn man das man fünfmal fragt, sodass fünfmal sich die Frage stellt, warum ist denn was passiert und von der Oberfläche so ein bisschen nach unten zu drehen, weil vielleicht kann man's ja der Grund ist, die Webseite ist nicht erreichbar,
25:44
Und wenn man dann bisschen reinbohrt, sieht man die Software, die diese Website ausliefert,
25:50
Die hat nicht mehr reagiert, okay und warum hat die nicht mehr reagiert, weil die Datenbank vielleicht nicht mehr reagiert hat? Also, dass man's so ein bisschen so reinbohrt, bis es nimmer weitergeht.
25:58  Gast
Ja und meistens kommt man halt dann irgendwann auch ähm zu zu mehr als einem Grund, zum Beispiel die Datenbank äh.
26:06
In diesem Fall war's zum Beispiel die Datenbank, die nicht reagiert hat, weil sie überlastet war und.
26:13
Dann gibt's halt noch das Problem, warum war meine Webseite meine meine Webseite down, wenn die Datenbank
26:19
Offline ist, weil eigentlich will ich dann doch eine Fehlermeldung haben, wie kommen sie bitte ins fünf Minuten wieder? Wir haben grad unsere Wichtel sind gerade am Arbeiten. Sie brauchen mal eine kurze Pause.
26:28  Wolfgang
Ich will eine zweite Datenbank, dass, wenn die eine kaputt ist, sich noch eine zweite habe, die die dann einspringen kann.
26:35  Gast
Genau sich da meistens kommt man halt dann irgendwie zu mehr als einem.
26:39
Oder zum Beispiel in dem Fall die die unerfahrene Entwicklerin muss jetzt diese Datenbank äh überlasst äh analysieren und macht dabei einen Fehler, was das Problem noch schlimmer macht. Und da gibt's eigentlich zwei,
26:53
Also,
26:54
letztendliche Ausfall, der du dann zum Beispiel dafür gesorgt hat, dass meine Webseite für fünf Stunden, statt für zwei Minuten offline war, gibt's einerseits den Wutkurs, meine Datenbank war überlastet.
27:06
Andererseits aber auch den Wutkurs. Meine Entwicklerin wusste nicht, was sie tun soll oder mein Entwickler.
27:12  Wolfgang
Weil die Erfahrung noch gefehlt hat.
27:14  Gast
Genau, das sind dann die beiden Fehler, die zusammengekommen sind,
27:17
Und dann gibt's, wir unterscheiden in unseren Trigger, dass wir dann zum Beispiel der Trigger wäre gewesen, wir hatten mehr Last als sonst, weil zum Beispiel nach den
27:28
Ferien gerade alle Kinder wieder Essen bestellen in unserer Plattform, weil wir das Schulmenz essen machen.
27:33  Wolfgang
Und dann kommen einfach ganz viele Dinge zusammen, die die dafür verantwortlich sind, dass dass so eine.
27:40
Das ist für einen Ausfall gibt oder dass äh dass das irgendwie so ein Problem auftritt, dann,
27:45
dass man auch wirklich spürt. Ich fand das auch super spannend. In den ganzen anderen Themen, die ich in den in den anderen Podcast Folgen so erwähnt habe, da war's ja auch oft so
27:54
Es kamen ganz viele Dinge zusammen und dann kam noch Pech dazu und äh das hat sich dann irgendwie so hochgeschaukelt, dass es dann äh zu zu einer Technikkatastrophe kam
28:04
So eine Sache, die ich noch äh noch spannend finde, du hattest mal irgendwann ein Gespräch erwähnt, dass Personen niemals die die Ursache sind für solche für solche Ausfälle oder für solche Probleme,
28:17
so sinngemäß hattest du das mal gesagt.
28:19  Gast
Genau, also ich ich bin so ein Fan von äh Human Aeros never the you root Course. Also man man liest ja häufig auch quasi,
28:28
Zugunglück wurde durch menschliches Versagen äh herbeigeführt.
28:34
Das ist halt die Frage, die man sich stellen konnte, warum konnte jetzt zum Beispiel der Lokführer in diesen Gleisabschnitt fahren, der gesperrt war durch ein Signal.
28:43
Kann man jetzt sagen, okay, er hat einen Sicherheitsmechanismus überbrückt, weil mittlerweile sind wir soweit, in der Zug-, in der Eisenbahntechnik, die machen auch immer sehr viele tiefgreifende Fehleranalysen, dass ich.
28:53
Technisch eigentlich nicht in der Lage bin, einen Zug über ein gesperrtes Signal zu fahren. Da bremst der Zug automatisch. Da muss ich als Fahrer schon aktiv sagen, ja, ich weiß, das Signal ist rot und ich möchte jetzt ganz schlimme Dinge tun.
29:06
Dann ist halt die Frage, warum A,
29:09
Warum hat er diese schlimmen Dinge getan? Was stand er unter Stress? Passiert das zum Beispiel immer? Das ist auch, sagen wir mal, in diese Berichte reinschaut, sieht man häufig, ah ja, das wurde immer so gemacht.
29:21  Wolfgang
Also Klassiker, oder? Das haben wir schon immer so gemacht.
29:24  Gast
Genau, weil zum Beispiel die Signal dauernd rot ist, obwohl's eigentlich nicht rot sein sollte und jemand das Signal nicht gefixt hat,
29:31
Das ist dann halt, ja, ist im gewissen Sinne ein menschliches Versagen, weil er hat halt diesen Fehlermechanismus überbrückt, obwohl er es nicht sollte. Andererseits wurde es ihm halt antrainiert, dass er es immer so macht, weil das passiert halt immer so.
29:42
Und das ist ganz, ganz selten, dass
29:44
Nur der Mensch den Fehler gemacht hat, sondern das sind meistens andere Umstände, die dazu geführt hat, dass dieser Mensch diesen Fehler gemacht hat. Und die will man ja eigentlich beseitigen, weil ob's jetzt
29:55
Hans oder der der Peter äh diesen Zug führt, ist ja eigentlich egal. Es war halt zum Beispiel in dem Fall der Handzahl der Unglückliche, der jetzt grad am Steuer saß.
30:04
Aber es hätte zwei Wochen später auch den Peter passieren können.
30:06  Wolfgang
Ich finde das super gut und ich finde es auch superwichtig, dass man sich das klar macht. Ich finde, Menschen haben sicherlich auch einen Anteil, wenn irgendwas passiert. Aber ob das jetzt
30:15
die einzelne Person ist, die jetzt auf den falschen Knopf drückte, oder ob's die Person oder die Person sind, die jetzt in dem Gremium irgendwelche Prozesse festgelegt haben, wie man jetzt irgendwie was was tun soll. Klar
30:27
ist es nicht so, dass das Menschen gar keinen Einfluss haben auf NW-Fehler. Aber ich finde, es ist oft halt so eine Art Kollektiv Verantwortung, die man hat.
30:34
Und wenn viele Menschen nicht aufpassen
30:37
Dinge schleifen lassen, dann können da schon Fehler draus entstehen. Also so ganz aktuell gab's ja vor zwei, drei Wochen gab's so eine Meldung
30:46
dass es irgendwie
30:48
ich weiß gar nicht mehr, in was war Nordrhein-Westfalen oder in Hessen, dass es da irgendwelche Fehlern zu einer Plattform gab, wo man sich so Arzttermine
30:57
holen konnte
30:58
und der Chef dann in so einem Pressestatement irgendwie sagte, ja, die eine Entwicklerin, die das verbockt hat, die hat dann auch geweint und so. Und ich glaube, das war auch der Anlass, dass wir mal über das Thema gequatscht haben, weil ich mir dachte,
31:12
pur, ich kann mir das schon gut vorstellen, dass vielleicht die eine Entwicklerin, die dann gesagt hat, oh Mist, ich habe das verbockt, ich habe hier einen Fehler gemacht, die vielleicht dann irgendwie emotional drauf reagiert hat
31:22
Das kann ja schon gut sein und ist auch völlig normal, also ich find's auch völlig okay und normal, wenn jemand mal im Büro weint, weil irgendwie was was Kacke ist einfach. Aber der adäquate Reaktion ist dann halt hinzugehen und zu sagen, hey.
31:34
Ist nicht so schlimm. Jetzt das kriegen wir jetzt irgendwie hin. Das überlegen wir uns, wie wir beide machen. Jetzt überlegen wir uns, wie wir das wieder hinbekommen, dass es funktioniert und im Nachgang trinken wir mal einen Kaffee und überlegen wir uns
31:44
überhaupt passiert ist. Also das ist oder vielleicht auch mal jemand den Arm nehmen, keine Ahnung. Aber
31:50
Pressestatement abzugeben und äh zu sagen, ich glaube den Namen haben die gar nicht genannt, aber trotzdem, also so ein Statement, hey, wer hat denn Bock, bei so einer Firma zu arbeiten
32:00
Also das ist ja so eine so eine Arschloch-Mentalität. Wir möchten da arbeiten, ne.
32:06  Gast
Genau das, das ist halt das andere, wenn ich hier so ein ähm ich brauche halt auch ein gewisses Vertrauen, weil dies in dem Team ist ja kein Vertrauen da, dass es wenn ich wenn ich einen Fehler mache, bin ich das Bauernopfer und werde nach draußen.
32:16
Auch noch so kommuniziert. Klar muss man im im herausfinden, wer den Fehler gemacht hat. Und da fallen auch Namen, aber ich muss dann ja gucken, okay, warum konnte diese eine Entwicklerin äh auf Produktion so einen großen Schaden anrichten?
32:31
Warum gibt's kein äh Vier-Augen-Prinzip? Warum gibt's keine keine Unittests oder Integration-Tests, die das Fehler gefunden haben? Und der Fakt ist, dass diese Entwicklerin geweint hat oder ob die Zeitung, vielleicht hat die Zeitung das sogar dazu erfunden, was ich noch viel schlimmer finde,
32:45
ist halt einfach, das das bleibt im Team, da stellt man sich als Team hin und sagt, okay, uns ist bei der Entwicklung ein Fehler passiert. Wir haben.
32:55
Äh durch eine vorschnelle Änderung, die vielleicht auch unter Druck, weil es geht hier um ging bei der Plattform um Corona Impftermine, die auch eher eher improvisierter sind, diese Plattform,
33:05
Wo man sagt, hey ja unter Zeitdruck ist das halt passiert, das das wir haben jetzt geguckt, wie wir das in Zukunft nicht mehr machen, wie wir solche Fehler abfangen, aber das ist passiert. Man kann ja sagen, wir haben nicht den Schuldigen gefunden oder den Schuldigen ermittelt, sondern,
33:18
Wir haben den Fehler gefunden. Wir haben die Ursache gefunden und.
33:21
Vielleicht auch noch nicht behoben, aber wir haben auf jeden Fall die richtigen Schritte äh veranlasst, dass diese behoben werden, was ja, was ich finde, der wichtigste Punkt von so einem und auch verbindliche,
33:33
Wenn man dann zum Softwareprojekt arbeitet, sollten sie Action Items auch ins ins Backlock wandern. Und mit einer recht hohen Priorität.
33:40  Wolfgang
Also solche Action Items sind, was was kann ich mir da drunter vorstellen? Sind das so so Dinge
33:45
was kann ich tun, um um so eine Art von Fehler in Zukunft zu vermeiden, also gerade wenn es diese eine Datenbank irgendwie abgeraucht ist, kann ich beispielsweise eine eine zweite Datenbank neben dran stellen als als Backup-System. Wer sowas in Action ITIM?
33:59  Gast
Zum Beispiel oder ich oder meine Datenbank Connections sind halt vollgelaufen durch einen Pack, dann wäre das das das Action ITOM mit der höchsten Priorität halt diesen.
34:08
Nächste ist dann ähm vielleicht äh,
34:12
Bin ich erst beim Keeper drauf gestoßen, dass die Connection, dass die Datenbankpools voll sind und nicht während ähm,
34:19
Bin erst drauf, das Problem aufmerksam geworden, weil meine Webseite down ist, dann werden anderes Action Item mit dem Fokus Monitoring, halt Monitoring aufbauen für meine Connection-Pools, damit ich alarmiert werde, wenn die Connection-Pools volllaufe.
34:30  Wolfgang
Also damit das das rote Lämpchen nicht angeht, wenn die Website äh nicht mehr funktioniert, sondern wenn das rote Lämpchen oder vielleicht ein orangenes Lämpchen angeht, wenn hier irgendwo was in äh gefährlichen Bereich ist, also wenigstens noch ein bisschen Zeit habt zum Reagieren.
34:43  Gast
Genau, also so was sind dann halt so typische Action Items, quasi Richtung Monitoring und Alerting, also wie kann ich mir dieses Problem nächste Mal eher bewusst machen
34:52
Und nicht erst, wenn das Kind in den Brunnen gefallen ist, aber auch,
34:56
Behebung, wie kann ich das langfristig beheben, weil meistens hat man in diesen Response, also wenn man den akuten Fehler behebt, der meistens eher Notlösungen getroffen.
35:05  Wolfgang
Ja, man macht halt ein großes Pflaster drauf, damit's irgendwie wieder weiter funktioniert dann, ja.
35:10  Gast
Es ist halt genau ist halt äh wie beim wenn ich einen Verkehrsunfall habe, dann werden die Wunden auch notdürftig verbunden, geguckt, dass der,
35:19
Patient nicht ausblutet und im Krankenhaus wird dann halt mal ordentlich zusammengenäht. Und das sind dann halt so so Action Items. Vielleicht muss ich auch, kommt halt raus, okay, meine ganze Architektur ist kaputt.
35:29
Muss dann halt mal äh größere Runde drehen. Das kann ich halt nicht direkt im Insevens Resp.
35:35  Wolfgang
Sehr nachvollziehbar, also wenn ich beispielsweise so ein System habe und das wird jetzt über Nacht irgendwie super bekannt und ich habe jetzt halt nicht mehr tausend Besucher am Tag, sondern eine Million, dann funktioniert das vielleicht meine ursprüngliche Lösung gar nicht mehr, weil weil die mit dieser Last nicht äh zurechtkommt oder so.
35:50
Das wäre ja vielleicht so ein Fall, wo ich sagen würde, okay, puh, was ich mir jetzt so damals gebastelt habe hier auf meinem Laptop. Ja, das das funktioniert jetzt nicht mehr. Jetzt muss ich jetzt auch beim beim Christoph mich ja so eine Cloud äh bestellen und das entsprechend meine
36:02
mein System entsprechend umbauen, damit's da drauf gut laufen kann und und skaliert.
36:07
Ich persönlich als alter, unverbesserlicher Weltverbesserer, ähm fänd's natürlich noch super schön.
36:14
Firmen, die äh so große Fehler haben und da so viel draus lernen
36:19
Fehler noch irgendwie veröffentlichen oder publik machen, damit sich so der geneigte äh Mensch, der äh vielleicht in der ähnlichen Branche arbeitet, sich sowas anschauen kann und noch von anderen Fehlern lernen kann, weil,
36:32
war früher als man auf Konferenzen gehen konnte, auch sehr gerne auf Konferenzen und habe mir da,
36:37
Vorträge angehört und neunundneunzig Prozent aller Vorträge, da waren halt irgendwelche Leute auf der Bühne, die erzählt haben, was für geile Sachen die gemacht haben. Also,
36:45
geile Software entwickelt und in Firmen geile Sachen gemacht und Shaker und also geil alles so
36:52
Es gab ganz, ganz selten Vorträge, wo Leute erzählt haben, ja, schaut mal, wir wollten XY machen und es ging alles in die Hose und ich erzähle heute mal in einer halben Stunde, warum. Äh solche Vorträge fand ich immer richtig spannend, gibt's ganz wenige,
37:05
weil ich den Eindruck habe, dass äh viele sich dafür ja immer ein bisschen schämen, weil gerade in der in der, also ich kenne ja vor allem die die
37:12
die ganze Branche. Da habe ich immer den Eindruck, da möchte man sich vor allem immer damit äh profilieren, was für tolle Sachen man macht und wie viel besser und cleverer ist man als die als die anderen Mitbewerber aufm Markt.
37:24
Aber wenn man jetzt anfangen würde und das vielleicht etablieren könnte, zu sagen, hey, schaut mal, wir zeigen euch mal, was im letzten Jahr bei uns alles nicht so gut funktioniert hat und was wir daraus gelernt haben, das fände ich super inspirierend und.
37:35  Gast
Also in der Community ist es tatsächlich sehr verbreitet, also ist dann auch auf der Cube Corn immer recht viele Talks zu Fail Your Stories, also was halt nicht funktioniert hat und es gibt auch eine Webseite, die heißt äh.
37:49
K acht S.
37:51
Also die acht als Zahl geschrieben, Punkt AF. Das ist äh Stories. Das ist eine korrektierte Liste mit Blogpost, wo jemand beschrieben hat, was bei seinem kaputt gegangen ist, wo Leute einfach ihre Post Mottos posten.
38:05  Wolfgang
Sehr cool.
38:05  Gast
Artikel et cetera PP. Und ähm ich habe auch das Gefühl, dass ein bisschen second Valley.
38:12
Teilweise viele Firmen auch zu anderen Sachen posten. Also nicht nur zur, sondern auch einfach mal, was bei denen nicht geklappt hat.
38:20  Wolfgang
Und sowas auch veröffentlichen dann.
38:22  Gast
Ja, also ich ich man kann das auch sehr spannend schreiben oder zum Beispiel Story, die die ich immer.
38:29
Ich wirklich amüsant finde, ist ähm der Christian hat mir ausgeschrieben, wie sie an einem Freitag den dreizehnten Webde ausfallen lassen haben.
38:37
Wie das ausgefallen ist, weil äh ein Klimaanlagenventil zugegangen ist, obwohl's nicht sollte. Man schreibt halt ganz schön, wie sie halt irgendwie.
38:47
Das Ganze RZ runterfahren mussten, weil denen die äh die Klimahandgeräte ausgefallen sind, damit die Server kein Hitzetod sterben und weil sie dann
38:55
Ganz schnell alle Server ausgeschaltet haben, sind ihn auf einmal angefangen, die Klimaanlagen zuzufrieren, weil die Klimaanlagen noch liefen, die übrig gebliebenen und jetzt auch.
39:03  Wolfgang
Keine Wärme erzeugt wurde.
39:05  Gast
Keine Wärme mehr erzeugt hatten, die sie abtransportieren mussten und dann mussten sie da gegensteuern und,
39:11
Der hat's halt auch mal in so einem Blogpost sehr schön aufgeschrieben, was da einfach an diesem Abend passiert ist.
39:17  Wolfgang
Ja, den verlinke ich auf jeden Fall, genauso wie diese äh Stories, dass man sich die mal anschauen kann.
39:23
Ja, sehr cool. Ähm Christoph, zum Ende, hast du vielleicht noch zum Thema Fehlerkultur noch einen Ratschlag oder eine Weisheit oder ein cooles Zitat
39:34
oder irgendwas anderes.
39:36  Gast
Also einen Ratschlag ist, wenn's vielleicht nicht im ganzen Unternehmen so ist, versucht's erstmal bei euch im Team. Ähm.
39:46
Ist meistens eine kleinere Gruppe. Versucht da vielleicht einfach das strukturiert aufzuschreiben. Macht euch da bei dem auch nicht zu viel Druck, dass das jetzt formal korrekt richtig ist, reichen einfach zwei halbwegs ordentlich zusammengeschriebene DIN A4 Seiten, das reicht meistens schon.
40:02
Nehmt euch dafür Zeit. Man muss das auch mal durchdenken und überlegen, ob jetzt das, was man aufgeschrieben hat, wirklich so stimmig sein kann.
40:11
Und ähm.
40:13
Was wir meistens machen, ist ein ist erst dann fertig, wenn's in Teamreview einmal vorgestellt worden ist. Also wir machen einmal im Monat so einen äh Meeting und da müssen wir halt einfach, da gucken wir drüber und gucken, ob's äh.
40:28
Stellst einmal im Team vor, das Postmotte, damit's auch alle wissen.
40:31  Wolfgang
Am besten ist natürlich, wenn man zu einem monatliches Team-Meeting hat, wenn man da jeden Monat nicht einen großen Stapel an solchen Postmortems mitbringen muss. Das ist natürlich der Idealfall. Also auch, egal wie schön das ist, diese ganzen Post Mothems zu schreiben.
40:44  Gast
Meine Erfahrung ist das tatsächlich einfach, es wird weniger, wenn man's anfängt. Es wird auch vor allen Dingen nicht mehr so schlimm.
40:50  Wolfgang
Glaube ich dir. Also was ich spannend finde, was du grad gesagt hast noch, ist äh im Team mit sowas zu beginnen. Finde ich super spannend, weil man dann vielleicht wie so eine kleine Keimzelle
41:00
ähm so mit gutem Beispiel vorangehen kann
41:03
und ähm vielleicht sehen die anderen Teams das dann, dass man sowas macht und sich dadurch vielleicht auch irgendwie verbessert, indem man vielleicht weniger Fehler hat oder vielleicht auch eine bessere Stimmung im Team hat, weil das Vertrauen wächst. Und ich kann mir gut vorstellen, dass das ansteckt es auf andere Teams.
41:18
Graswurzelbewegung. Christoph, vielen Dank, war super spannend.
41:24  Gast
Ja, bitte?
41:26  Wolfgang
Und äh ja.
41:28
Ich äh bin gespannt, ob äh andere Leute auch schon Erfahrungen haben mit solchen Postmortemanalysen. Ich finde das auf jeden Fall ein super spannenden Ansatz
41:36
um so eine Fehlerkultur einfach zu strukturieren und von diesem äh Impliziten ja, wir verstehen uns ja alle ganz gut und ja, wir sprechen ja ganz offen. Ja, zu einem expliziten Prozess, ein bisschen rüber zu wuchten
41:50
wo man sich dann halt auch wirklich strukturiert mit beschäftigt und das dann auch umsetzt. Also ich finde das einen coolen Ansatz auf jeden Fall.
41:56  Gast
Nichts anderes sind ja deine Podcastfolgen. Schaut sich einen Fehler an und versucht, draus zu lernen.
42:01  Wolfgang
Ja, finde ich auch super spannend,
42:03
Man kann aus Fehlern ja auch immer total viel lernen. Ich mag Fehlergeschichten, weil die oftmals so unterhaltsam sind und manche sind ja richtige Technikkrimis. Spannend ist es dann am Ende immer, wenn man sich die Frage stellt, hey, was kann ich denn daraus lernen? Und oftmals ist das eine ganze Menge.
42:19
Was du sagst, kann ich übrigens total unterstreichen. Es sind eigentlich nie die einzelnen Personen, die aus einer Unachtsamkeit für ein großes Problem verantwortlich sind.
42:27
Problem, das war immer schon da und die Person ist dann halt der eine Tropfen, der das Fass zum Überlaufen bringt. Aber das Problem ist halt das Fass und nicht der Tropfen.
42:38  Gast
Mal gucken, das Loch groß genug ist.
42:41  Wolfgang
Super, Christoph, vielen Dank. Ich wünsche dir noch eine schöne Zeit und bis bald.
42:48  Gast
Bis bald, ciao.
42:50  Wolfgang
So, das war die sechste Folge von den digitalen Anomalin. Ich hoffe, es hat euch Spaß gemacht. Die nächste Folge erscheint in zwei Wochen und ich freue mich, wenn ihr wieder mit dabei seid.
43:00
Genauso freue ich mich natürlich auch über viele.
43:02
Sehr gerne per E-Mail an Feedback at digitale Anomalien Punkt DE oder als Kommentar zufolge auf digitale Anomalin Punkt DE. Und wenn ihr Lust habt, dann folgt mir doch auf Instagram unter at digitale Anomalie,
43:15
Ach ja und falls ihr mir eine Bewertung bei Apple Podcast oder sonst irgendwo geben wollt, dann wäre das natürlich auch total cool. Bleibt gesund und tschüss bis zum nächsten Mal.