#17 Was können wir beim Incident Management von der Feuerwehr lernen?

Was haben die Methoden der Feuerwehr zur Bekämpfung von Großschadensereignissen mit dem Incident Management von IT-Systemen gemeinsam?

Diese Frage klären wir in der folgenden Episode. Wolfgang, als Mitglied der freiwilligen Feuerwehr, gibt einen Einblick in das Prozedere, wenn die Feuerwehr ausrückt. Andy vergleicht dies mit dem Incident Management von Cloud-Systemen. Wir klären wie man den Schaden eines Incidents misst, was dies mit dem Vertrauen von Kunden zu tun hat, wie ordentliche Prävention aussehen kann und warum es dafür wenig Ruhm gibt, was man unter War- und Peacetime versteht, wie ein moderner “Schreiberling” aussieht, wie dreist Presseleute sein können und was eine kleine Konferenz in Kalifornien damit zu tun hat.

Bonus: Was Gartenschläuche und Stahl-Hochöfen damit zu tun haben und wieso Kaffee holen doch eine Strategie sein kann.

Feedback an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk

Sprungmarken

(00:00:00) Intro

(00:01:21) Wie viel Feuerwehr-Leute gibt es in Deutschland?

(00:02:58) Was ist Incident Management im DevOps/Infrastruktur-Bereich

(00:07:33) Firmen-Interne Incidents können ebenfalls richtig teuer werden

(00:09:14) Wie wichtig ist Prävention und Monitoring?

(00:10:26) Wie agiert ein Unternehmen bei einem IT-Incident? Chaotische Hilfe

(00:12:33) Inwieweit kann ein IT-Incident mit einem Großschadensereignis verglichen werden?

(00:14:14) Was ist ein Großschadensereignis?

(00:15:57) Wie bekommen denn alle mit, dass ein Incident gerade eintritt? Und welche Strukturen sind notwendig?

(00:17:43) Wer übernimmt die Rolle des (Incident) Commanders?

(00:19:21) Was beinhaltet denn die Übernahme eines Incidents?

(00:21:23) Vergleich von der Übernahme eines Incidents zwischen der Feuerwehr und einem IT-System

(00:23:43) Strategie der Feuerwehr bei Incidents und Hierarchien

(00:26:14) Ist der Einsatzleiter ein aktiver Teil des Incidents? Und welche Rollen gibt es noch?

(00:30:09) Kommunikationsstrukturen in IT-Incidents

(00:33:01) Der aktuelle Atlassian-Incident

(00:34:44) Die Rollen von Logistik und Administration in der Feuerwehr und in der IT

(00:37:16) (Essens)-Logistik bei Remote-Incidents

(00:40:19) War-Rooms: Anti-Pattern oder Must-Have + Pro-Aktive Kommunikation

(00:43:26) War- und Peace-Time

(00:44:19) Incident Commander, Rollen und Rollen-Rotation im IT-Bereich

(00:45:53) Die Rolle des Protokollführers / Schreiberlings

(00:50:46) Post Mortems und Nachbesprechungen: Warum machen die Sinn?

(00:54:21) Vorbereitungen, Prävention und Training in der Friedenszeit

(00:57:51) Lernen aus Incidents und die Post Mortem-Struktur

(01:00:09) Employer Branding mit Post Mortems

(01:01:45) Happy-Path in Post Mortems

(01:02:35) Nachbesprechung bei der Feuerwehr und Post Mortem Conferences

(01:06:45) Web-Ops / Fire-Ops-Conference

(01:09:40) Outro

Hosts

Wolfgang Gassler (https://twitter.com/schafele)
Andy Grunwald (https://twitter.com/andygrunwald)

Engineering Kiosk Podcast: Anfragen an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk

Transkript

Das Transkript wurde automatisiert per Speech-to-Text erstellt und kann daher Fehler enthalten.

Andy Grunwald (00:00:00 - 00:01:16)

Hey, wir sind's wieder. Wolfgang und Andi vom Engineering-Kiosk mit einer neuen Episode. Jeder von uns versucht den perfekten Code zu schreiben. Bugfrei, super performant und hochverfügbar sowieso. Doch früher oder später kommt es unausweichlich zu der Situation, dass ihr das Produktionssystem in irgendeiner Art und Weise abgeschossen habt. Und dabei ist es völlig egal, ob ihr Junior Software Engineer seid, die erste Version von Amazon S3 geschrieben habt oder euer Name Linus Torvalds ist. Wenn es noch nicht passiert ist, wird es bald passieren. Euer Code erzeugt einen Inzident. Ein Systemausfall. Nix geht mehr. So oder so ähnlich ist das, wenn ich versuche zu kochen. Ich bin nicht besonders gut darin, mache es aber gerne und ich weiß, dass irgendwann eine Pfanne brennen wird. Und dann kommt die Feuerwehr. Also hoffentlich. Und genau das sind unsere beiden Themen für die heutige Episode. Hä? Beide Themen? Du hast doch nur von Production Outfitters gesprochen. Ja und Nein. Heute klären wir die Frage, was das Internetmanagement in IT-Systemen und Cloud-Systemen von den Einsätzen der Feuerwehr lernen kann, was gleich läuft, wo die Unterschiede liegen und wie man aus solchen, doch recht doofen Ereignissen lernen kann, um das System zu stabilisieren. Und das ist nicht nur eine Folge für die Leute aus dem Infrastrukturbereich, sondern auch für Software Engineers, Product Owner und allen anderen. Springen wir direkt rein und los geht's.

Wolfi Gassler (00:01:21 - 00:01:25)

Andi, wie viele Feuerwehrleute gibt es in Deutschland?

Andy Grunwald (00:01:25 - 00:01:28)

Freiwillige Feuerwehr oder berufliche Feuerwehr?

Wolfi Gassler (00:01:28 - 00:01:31)

Ja, die berufliche ist zu vernachlässigen, mengenmäßig.

Andy Grunwald (00:01:31 - 00:01:38)

82 Millionen Einwohner circa. Wie viele Leute sind in der freiwilligen Feuerwehr? 70.000.

Wolfi Gassler (00:01:38 - 00:02:23)

Knapp daneben, es sind ungefähr eine Million. Wirklich? Inklusive THW, es macht jetzt auch nicht so viel aus, aber man geht ungefähr so von zwei Prozent aus. Ich habe das mal gecheckt in Deutschland und in meinem Heimatland in Tirol. Sind scheinbar sehr ähnlich, sind so um die zwei Prozent der Bevölkerung. Ich habe mich immer gefragt, weil wir ja einige Hörerinnen haben, die bei der Feuerwehr sind, die uns das schon geschrieben haben und einige kenne ich auch persönlich davon, ob das irgendwie mehr Leute im IT-Wesen sind, die auch bei der Feuerwehr sind, weil wir so viele haben, aber dann haben wir ausgerechnet, die sind alleine bei unseren Hörern sicher mal über zehn Hörerinnen bei der Feuerwehr. So viel kenne ich gar nicht unter den Hörerinnen, also scheinbar ist das doch der normale Schnitt und die IT-Leute sind nicht irgendwie Feuerwehr-Fanatische.

Andy Grunwald (00:02:24 - 00:02:35)

Wie kommst du auf die These, dass viele ITler bei der Freiwilligen Feuerwehr sind? Also ich meine, hat die Mitgliedschaft bei der Freiwilligen Feuerwehr irgendwas IT-Technisches?

Wolfi Gassler (00:02:35 - 00:03:12)

Ja, das war eben meine Frage und wir haben ja auch schon öfters gedacht, gibt es dort Parallelen zwischen Feuerwehr und Incident Management zum Beispiel? Da haben wir ja oft drüber diskutiert und eigentlich wollten wir da immer einen coolen Vortrag drüber machen, aber wir haben es ja irgendwie nie geschafft, da mal in die Tiefe zu gehen. Und darum können wir das ja heute in der Episode mal probieren, zumindestens, ob wir da Parallelen finden. Aber bevor wir in das Thema reinstarten, Andi, du bist ja Profi im ganzen DevOps-Bereich, also erklär mal, was ist denn Incident Management vor allem für alle Hörerinnen, die keinen Tau haben, die jetzt keine DevOps sind und vielleicht in den Themen nicht so tief drin sind?

Andy Grunwald (00:03:12 - 00:03:27)

Incident Management ist eigentlich die Art und Weise, der Prozess und alles was dazu führt, eine Applikation, die sich nicht so verhält, wie sie sich verhalten soll, wieder in den Ursprungszustand, auf den sogenannten Happy Path zu bringen.

Wolfi Gassler (00:03:27 - 00:03:36)

Das ist gar nicht unbedingt klassisches Outage oder dass halt was nicht erreichbar ist oder irgendwie abstürzt, sondern es kann auch irgendwas anderes sein, wie irgendwas ist zu langsam.

Andy Grunwald (00:03:36 - 00:04:04)

Ja, nehmen wir einfach mal einen Webshop. Also die Webseite kann ja super funktionieren und du kannst dir alle Artikel ansehen und du kannst dir auch die Artikel in den Warenkorb legen, aber dann funktioniert die Zahlungsstellenstelle nicht. Das ist trotzdem ein Inzident, weil in diesem Beispiel verliert die Firma entsprechend Geld, weil keine Bezahlungen mehr durchgehen können. Oder vielleicht sogar noch schlimmer, alle Bestellungen, die in dem Zeitraum gemacht werden, werden bereits als bezahlt markiert, ohne dass irgendwie eine Zahlungstransaktion durchgeführt wurde.

Wolfi Gassler (00:04:04 - 00:04:07)

Das heißt die Firma verliert Geld und natürlich auch Vertrauen in dem Fall.

Andy Grunwald (00:04:07 - 00:04:50)

Es kommt immer natürlich ganz auf die Firma an. Zum Beispiel eine Firma wie Amazon oder Google Cloud, ein Cloud Anbieter, der braucht natürlich auch Vertrauen. Da geht es ja nicht nur darum, die managen deine Infrastruktur, sondern die vertrauen dir natürlich auch, also dein Kunde vertraut dir, dass du mit deren Daten auch gut umgehst. Nehmen wir mal zum Beispiel Hetzner. Hetzner hat jetzt die Tage einen Inzident gehabt, wo sie teilweise Snapshots verloren haben, weil Festplatten in einem Raid zeitgleich abgestürzt sind und nicht wiederherstellbar waren. Den Artikel können wir gerne verlinken. Das bedeutet eigentlich, dass Hetzner einen Datenverlust hatte. Da wird natürlich das Vertrauen zum Kunden natürlich auch zerstört.

Wolfi Gassler (00:04:50 - 00:05:01)

Da gab es sogar ein Ceph-Datensystem. Also da sind irgendwie zwei Platten in dem Ceph-Datensystem, die halt gespielt waren, genau die zwei Platten irgendwie gleichzeitig ausgefallen.

Andy Grunwald (00:05:01 - 00:05:33)

Ich glaube auch während der während der Wiederherstellung von einer einer kaputten Festplatte irgendwie sowas ein sehr sehr seltenes Ereignis ist auf jeden Fall eingetreten und da sind da haben ein paar Kunden ein paar Daten verloren und sowas sowas zerstört das Vertrauen bei einem klassischen E-Commerce Shop, da verliert dann die Firma zum Beispiel nur Geld. Natürlich braucht ein E-Commerce-Shop nicht so viel Vertrauen in der Regel, weil den einen Pulli von Vans, den kriegst du vielleicht im Titus-Geschäft, aber vielleicht auch bei About You oder ähnliches oder bei Zalando, dann gehst du einfach zum nächsten.

Wolfi Gassler (00:05:33 - 00:05:54)

Aber man verliert dann natürlich vielleicht den Kunden, weil er zum nächsten Shop geht, dort glücklich ist und das nächste Mal wieder dort bestellt. Also es ist schon bei dem Shop auch, glaube ich, ein ganz gutes Beispiel der Vertrauensverlust, dass du vielleicht Kunden verlierst auf lange Sicht und Das ist glaube ich auch was, was viele unterschätzen, wie groß der Schaden sein kann, wenn irgendeine Kleinigkeit ausfällt.

Andy Grunwald (00:05:54 - 00:07:06)

Ab und zu ist der Schaden aber auch gar nicht so wirklich messbar. Da sind wir bei den Opportunitätskosten. Theoretisch müsstest du ja zwei Realitäten haben. Du müsstest einmal die Realität haben, wo du den Ausfall hast und einmal die Realität, wo das System ordentlich funktioniert. Und nur wenn das System ordentlich funktioniert, weißt du ja wie viele, Bestellungen du eigentlich bekommen hättest. Natürlich kannst du das auf vorherige Zahlen irgendwie hochrechnen, das ist und bleibt aber immer eine Schätzung. Kannst du zum Beispiel immer nur, weiß ich nicht, den selben Dienst, also angenommen du hast an einem Dienstag den Outage, dann nimmst du zum Beispiel den Dienstag von letzter Woche, um zu gucken, wie performt denn ein Dienstag in meinem Webshop, sofern du verschiedene Traffic-Patterns hast. Und dann kannst du ungefähr schätzen, was du für einen finanziellen Verlust gemacht hast. Aber zum Beispiel den Verlust an Reputation und Vertrauen, der ist halt sehr, sehr schwer messbar. Natürlich kannst du da irgendwie so einen Net Promoter Score oder sowas machen, aber ich glaube, das führt alles so ein bisschen zu weit, wenn du einen Ausfall hast. Punkt ist aber auf jeden Fall, ein Ausfall oder ein Inzident ist nicht immer, wenn das System komplett nicht verfügbar ist, sondern es kann alles sein, dass das System in irgendeiner Art und Weise beeinträchtigt wird. Ein Inzident heißt auch nicht immer, dass der Kunde davon was merken muss. Ein Inzident kann auch intern sein.

Wolfi Gassler (00:07:06 - 00:07:11)

Ich glaube, das ist ja das Beste, wenn der Kunde nichts davon merkt und man schon frühzeitig irgendwas auflösen kann.

Andy Grunwald (00:07:12 - 00:07:46)

Ja das ist das beste es macht aber nicht weniger arbeit und bedarf auch nicht weniger incident management weil im endeffekt ist es ein ausfall ist es eine abweichung von dem sogenannten happy pass und du packst ja da auch enorme ressourcen und menschen drauf die ganz viel arbeiten um das system stabil zu halten also von daher bedarf es dann auch in internen ausfällen nicht. Nicht weniger Insidermanagement. Und je nach Firma muss man ja auch sagen, dass interne Ausfälle vielleicht sogar deutlich teurer sind als der Ausfall des Webshops. Nehmen wir mal Google.

Wolfi Gassler (00:07:46 - 00:07:49)

Google hat wie viele Engineers?

Andy Grunwald (00:07:49 - 00:07:52)

230.000. Jetzt stell dir mal vor... Moment, stimmt das?

Wolfi Gassler (00:07:52 - 00:07:54)

Das war nur geraten.

Andy Grunwald (00:07:54 - 00:07:56)

Weiß ich jetzt auch nicht. Google doch mal eben bitte kurz.

Wolfi Gassler (00:07:56 - 00:08:09)

Google, Google. Google Anzahl Developer. Naja okay, es sind so ungefähr 160.000 Mitarbeiter. Ich schätze mal, dass da weniger als die Hälfte Developer sind oder vielleicht ungefähr die Hälfte. Dann sind wir eher bei so 70-80.000.

Andy Grunwald (00:08:09 - 00:09:21)

70-80.000. Jetzt stell dir mal vor, Google hat einen internen Inzidenz, wo das Versionskontrollsystem ausfällt. Für, sagen wir, 24 Stunden, damit das einmal durch alle Zeitzonen geht. Dann könnten ca. 80.000 Leute Minus denen, die krank sind und im Urlaub sind, nicht arbeiten. Da würde ich schon fast sagen, das ist ein unglaublich großer finanzieller Schaden für einen internen Inzidenz, oder? Oder ein anderes Beispiel. Thyssenkrupp, Stahlunternehmen hier im Pott. Wenn die eine Störung mit ihrem Hochofen haben, dann ist der interne Ausfall nicht nur die Störung des Hochofens, weil wenn die nämlich zum Beispiel den Hochofen runterfahren müssen, die Störung beheben und dann der Hochofen wieder hochfahren muss, der ist ja nicht wie ein Computer, da machst du aus und wieder an und zwei Minuten später ist das Ding wieder oben, sondern dass so ein Hochofen runterfährt und so ein Hochofen wieder hochfährt, das dauert ein paar Stündchen und vielleicht sogar Tage. Also da zieht sich dann der finanzielle Schaden natürlich auch noch weit über den eigentlichen Ausfall. Deswegen bin ich mir gar nicht sicher, ob was immer schlimmer ist, ein externer Inzidenz, der den Kunden wirklich betrifft oder ein interner. Ich glaube, es kommt auf die Art der Firma an und was es dann wirklich ist.

Wolfi Gassler (00:09:22 - 00:10:07)

Das Beste ist natürlich, wenn man das im Vorhinein schon verhindern kann. Das ist eh klar. Ich glaube, da müssen wir auch mal eine eigene Folge machen über Monitoring und wie man da am besten vorgeht. Das Problem ist ja auch immer, wenn man irgendwas verhindert, dann bekommt das Management das halt auch überhaupt nicht mit. Und wenn man extrem viel Zeit investiert in die Prävention, es gibt ja diesen Spruch, da ist nur Glory in Prevention. Also es gibt keinen Ruben. für Prävention. Also das gleiche ist bei Brandmeldern. Wenn ich die Feuer schon frühzeitig erkenne und vielleicht einfach löschen kann, irgendwann denke ich mir dann auch, brauche ich überhaupt noch so viel Feuerwehr und es brennt ja irgendwie nie. Aber es ist halt auch, weil die Prävention Aufgabe der Feuerwehr zum Beispiel ist und man da in letzter Zeit viel entwickelt hat mit Brandmeldern und Rauchmeldern.

Andy Grunwald (00:10:07 - 00:10:28)

Ich meine, ich glaube, das Thema Security ist immer so das beste Beispiel. Keine Firma investiert in Security und dann kommt ein Hack und auf einmal ist das ganze Budget umgeschifft und auf einmal hat man wieder Geld für Security. Oder nehmen wir mal jetzt hier Corona, Covid und Digitalisierung. Der Running Gag ist ja, wer treibt die Digitalisierung in deiner Firma voran? Der CTO oder Covid? Das wird mit hoher Wahrscheinlichkeit Corona sein.

Wolfi Gassler (00:10:28 - 00:10:51)

Das sind die klassischen Notfallpläne auch. Wie schnell kann man auf irgendwas reagieren? Aber kommen wir mal zurück zum Incident Management und Feuerwehr. Andi, jetzt würde mich schon interessieren, du als Nicht-Feuerwehrler, was stellst du dir denn vor, wo die Feuerwehr irgendwie gleich agiert bei so einem, im Vergleich zu dem Incident Management von einer klassischen IT-Firma mit Developern?

Andy Grunwald (00:10:51 - 00:11:15)

Fangen wir anders an. Eine IT-Firma hat einen Outage. Das System verhält sich nicht so, wie es soll. Was passiert denn in der Regel? In der Regel wird ein Slack-Channel aufgemacht von der Person, die das festgestellt hat. Die Person lädt ein paar andere Leute ein und schreibt einfach rein, hey, das Zahlungssystem ist down. Wir kriegen keine Zahlungen mehr. Dann die Nachricht verbreitet sich wie ein, Achtung, Lauffeuer durch die Firma.

Wolfi Gassler (00:11:15 - 00:11:16)

Was für ein Wortwitz.

Andy Grunwald (00:11:16 - 00:13:24)

Und mehr und mehr Leute joinen den Channel. Und weil das natürlich auch eine Situation ist, wo eine hohe Sichtbarkeit drauf ist, auch das Management, jeder Chef guckt da drauf, will natürlich jeder irgendwie helfen. Und vielleicht meint das auch jeder einfach nur gut, verstehe mich nicht falsch. Auf jeden Fall sind dann dann auf jeden Fall viel zu viele Leute, In diesem Channel hauen irgendwelche Gedanken, Assumptions in den Channel, wo dran es liegen könnte. Du hast innerhalb kürzester Zeit 20, 30, 40 Nachrichten. Man verliert recht schnell den Überblick, wo wir grade sind, wer eigentlich an was arbeitet, wer hat grad den aktuellen Stand, wer hat überhaupt Rechte, aufs Produktionssystem zu gehen. Das ist ja dann bei 20, 30 Leuten, die da hin- und herschreiben, ja auch nicht immer einfach. Und neben den Hauptnachrichten im Slack gibt es natürlich dann auch noch die Threads, und dann verteilt sich die ganze Kommunikation in so einen Baum. In Firmen, die kein ordentliches Incident-Management-System haben, führt das meist zu totalem Chaos. Und ich habe auch schon alles erlebt. Ja, bei Trivago war es natürlich am Anfang auch so. Und je mehr Incidents man macht, umso professioneller wird man da. Dann merkt man, na hey, vielleicht ist das besser, eine kleine Anzahl an Leuten da zu haben, anstatt 25. Und irgendjemand muss auch mal den den hut hier auf haben und jemand muss die ganze sache managen irgendjemand muss die kommunikation zu den stakeholder also zu dem zu deinem chef zum sales und so weiter haben und dann habe ich mir irgendwann mal beim rasenmähen gedacht ja feuerwehr irgendwie haben die auch einen ausfall. Ja, und da hab ich mich gefragt, Wolfgang, ist das nicht genau das Gleiche, wie wenn ein Auto brennt oder ein Haus brennt? Da kommen dann ganz viele Feuerwehrautos von ganz vielen Feuerwehrstationen aus allen Dörfern. Was passiert dann? Springen die alle raus und nehmen einfach einen Schlauch und halten drauf, so wie alle Leute springen in den Slack-Channel und sagen irgendwas? Also, ich hab mich gefragt, was kann das IT-Umfeld von professionellem Brand löschen, der Feuerwehr lernen.

Wolfi Gassler (00:13:25 - 00:14:24)

Es ist immer schön zu sehen, wie andere die Feuerwehr sehen. Diese mindestens zehn Leute, die in unserer Hörerschaft bei der Feuerwehr sind, finden es sicher auch sehr nett, wenn man denkt, dass zu einem Autobrand ganz viele Feuerwehrautos aus ganz vielen Orten kommen. Meistens ist es wahrscheinlich nur ein Feuerwehrauto aus demselben Ort und dann steigen da vier Leute aus und löschen das Feuer und zehn Minuten später ist es aus. That's it. Am ehesten, wenn wir was mit Incident Management vergleichen, Ich glaube, könnte man die ganze Organisation der Feuerwehr sehen, vor allem bei Großschadensereignissen oder auch Militär, ich glaube, das Ganze hängt ja auch sehr stark zusammen. Wie organisieren sich einfach solche größeren Organisationen oder das Technische Hilfswerk? Bei einem größeren oder Großschadensereignis, wie man es so nennt, wie organisiert man da dann wirklich viele verschiedene Leute und da hast du dann auch Stakeholder zum Beispiel, da hast du Presseleute, da will dann jeder wissen, was ist los, da hast du Anwohner, fünf verschiedene Zeitungen, alles mögliche.

Andy Grunwald (00:14:25 - 00:14:33)

Gib mir mal kurz ein Beispiel, was ist ein Großschadensereignis? Weil wenn ein Haus brennt, hat man einen großen Schaden. Ist das ein Großschadensereignis?

Wolfi Gassler (00:14:33 - 00:14:52)

Also Großschadensereignis ist meistens, zumindest versteht man das eher darunter, wenn halt wirklich dann viele Feuerwehren zur Hilfe gerufen werden. Also nicht nur die Ortsfeuerwehr, die kleine Feuerwehr mit zwei Autos oder auch mit fünf Autos, sondern wenn halt da wirklich mehr Ressourcen dann gebraucht werden. Wenn das irgendwie, keine Ahnung, ein Chemieunfall.

Andy Grunwald (00:14:52 - 00:14:54)

Ist oder... Meinst du Chemie?

Wolfi Gassler (00:14:55 - 00:15:43)

Nein, ich meine Chemie. Oder zum Beispiel ein Busunfall auf der Autobahn, wo es halt dann wirklich viele Leute auch betrifft, wo jetzt vielleicht der klassische technische Schaden gar nicht sehr groß ist, aber da waren halt vielleicht 200 Leute in dem Bus. Das heißt, da arbeitet man dann mit anderen Hilfsorganisationen, Rettung und so weiter auch zusammen. Also wo einfach dann viele Leute zusammenarbeiten und kannst dir vorstellen, wenn irgendein Bus jetzt auf der Autobahn verunglückt mit vielen Leuten, da hast du sofort die Zeitungen da, da hast du irgendwelche Leute, die womöglich dann schaulustig auf der Autobahn herumlaufen und da hast du plötzlich ganz, ganz viele Leute und die musst du irgendwo unter Kontrolle bringen, um möglichst schnell zu helfen und das Problem zu lösen, das du dort hast. Und das ist dann im klassischen Sinne einfach Incident Management.

Andy Grunwald (00:15:44 - 00:16:04)

Okay, das hört sich ja erstmal fast genauso an. Du hast ein Schadensereignis, du hast verschiedene Leute, die kommen zur Hilfe aus gegebenenfalls verschiedenen Bereichen. In der IT sei es dann ein Entwickler, ein Systemadministrator, vielleicht sogar ein Data Scientist oder ähnliches. In der Feuerwehr ist es halt verschiedene Autos aus verschiedenen Dörfern.

Wolfi Gassler (00:16:04 - 00:17:14)

Vielleicht, wenn man sogar einen Schritt zurückgeht, man muss erstmal sicherstellen, dass diese ganzen Hilfsorganisationen und Leute überhaupt zu diesem Busunglück kommen. Und so ähnlich ist es auch, glaube ich, bei einem Incident in einer IT-Firma. Du musst erstmal diese ganzen Strukturen haben, dass du entdeckst, da ist ein Problem, das ist Monitoring, wollen wir ja heute nicht behandeln. Aber danach, was passiert denn überhaupt? Wer ist denn verantwortlich? Das heißt, du musst mal überhaupt definiert haben, wer kümmert sich denn um den Inzidenz? Wer übernimmt da überhaupt die Führung? Das heißt, du brauchst schon ganz klare Strukturen, die du im Vorhinein definierst, weil wenn du das erst definierst, wenn einmal was passiert, ist es viel zu spät. Das heißt, du musst im Vorhinein wirklich schon überlegen, wenn xy passiert, Wie gehe ich vor? Wenn ich jetzt nur ein Personenteam bin, ist es relativ einfach oder zwei Personen. Da ist immer jeder verantwortlich. Aber sobald es ein größeres Team ist, musst du wirklich definieren, wer, wann, wie, wie ist die Kommunikation und wie gehen wir überhaupt vor? Also es ist ganz viel zu definieren im Vorfeld, meiner Meinung nach. Damit ein Incident überhaupt gut abgearbeitet werden kann.

Andy Grunwald (00:17:14 - 00:17:25)

Sagst du jetzt, dass jede Firma, die irgendwie Software betreibt, sich jetzt gerade hinsetzen muss und sagen, okay, wenn wir einen Ausfall haben, dann ist der Gerd immer der Kollege, der den Hut auf hat? Oder kann das auch dynamisch sein?

Wolfi Gassler (00:17:25 - 00:17:49)

Ja, ich glaube, es muss halt klar sein, was passiert. Bei einer Feuerwehr, gerade bei einer freiwilligen Feuerwehr, da kommen auch immer andere Leute. Du weißt ja nie, wer hat da jetzt gerade Zeit. Die freiwillige Feuerwehr, da arbeiten ja alle. Und jetzt brennt irgendwo etwas, dann kommen die Leute. Aber es gibt natürlich ein im vorhinein definiertes System, wie entschieden wird, wer jetzt zum Beispiel den Einsatz übernimmt, wer da die Einsatzführung übernimmt.

Andy Grunwald (00:17:49 - 00:17:59)

Wie funktioniert das System? Wie läuft das? Also woran wird das entschieden? Jetzt kommen fünf Autos aus fünf Lörfern. Was passiert dann? Wie wird entschieden, wer den Hut auf hat? Wer als erster da ist?

Wolfi Gassler (00:17:59 - 00:19:00)

Also das sind jetzt zwei unterschiedliche Dinge, also wenn jetzt mehrere Feuerwehren zusammenarbeiten, das ist dann ein komplexes System, ich will jetzt gar nicht so in die Tiefe gehen, meistens ist es eigentlich die Feuerwehr, dessen Gebiet es einfach ist, das heißt die halt die Ortskenntnis hat. Aber ich spreche auch schon davon, wenn jetzt einfach die ganzen Feuerwehrmitglieder zum Feuerwehrhaus rennen, zu einem Brand, dann musst du entscheiden, wer von diesen zehn Hanseln da, die jetzt da gekommen sind oder auch mittlerweile, Gott sei Dank, auch Frauen bei der Feuerwehr, wer übernimmt jetzt den Einsatz, wer übernimmt die Einsatzführung. Weil vielleicht der klassische Kommandant, der Kommandant der Feuerwehr ist, der hat gerade keine Zeit oder ist gerade nicht im Ort, ist gerade auf Urlaub, whatever. Da muss ja trotzdem irgendwo ein System sein, wer übernimmt den Einsatz. Und da gibt es natürlich ein System, beziehungsweise wird entschieden, wer hat am meisten Erfahrung, wer ist ausgebildet dafür und derjenige übernimmt dann, der halt verfügbar ist, die besten Kenntnisse hat, Erfahrung drin hat in der Führung von solchen Einsätzen, der übernimmt das dann.

Andy Grunwald (00:19:00 - 00:19:04)

Okay, da gibt es ein paar Kriterien, die spielen da eine Rolle halt mit der Erfahrung.

Wolfi Gassler (00:19:04 - 00:19:21)

Es ist die klassische Erfahrung und Ausbildung, würde ich sagen. Also du wirst jetzt auch, wenn das System down ist, wirst du jetzt auch nicht den Praktikanten sagen, hey, du übernimmst jetzt diesen Incident, du bist Praktikant und du organisierst jetzt das. Du hast es zwar noch nie gemacht, hast keine Ahnung, wie es funktioniert, aber du managst jetzt den gesamten Incident. Machst du wahrscheinlich auch nicht.

Andy Grunwald (00:19:21 - 00:19:35)

Was heißt denn Incident übernehmen? heißt das der kollege mit der meisten erfahrung darf nur den schlauch halten für das wasser oder also was heißt das denn was was beinhaltet denn die übernahme eines eines eines groß schaden ereignisses.

Wolfi Gassler (00:19:35 - 00:19:57)

Oder auch von einem normalen einsatz in dem fall ist einfach die die koordination von dem ganzen also da steht natürlich dann niemand am strahlrohr heißt es übrigens, vorne am am wasser sondern der ist natürlich freigespielt und der macht hauptsächlich kommunikation und organisation das heißt der teilt ein der überlegt sich die strategie was machen wir aber der execute nicht also der steht jetzt nicht am schlauch ganz kurz.

Andy Grunwald (00:19:57 - 00:20:00)

Also der schlag der wasserschlauch heißt strahlrohr.

Wolfi Gassler (00:20:00 - 00:20:07)

Das ding vorne heißt strahlrohr dieses endstück. was am Ende vom Schlauch dran hängt, damit es ein guter Strahl wird.

Andy Grunwald (00:20:07 - 00:20:09)

Ist das nicht nur eine Schlauchkupplung?

Wolfi Gassler (00:20:09 - 00:20:14)

Nein, das verjüngt sich ja. Also vorne wird es enger, damit du möglichst weit das Wasser werfen kannst.

Andy Grunwald (00:20:14 - 00:20:16)

So wie bei meinem Gardena Gartenschlauch, oder?

Wolfi Gassler (00:20:16 - 00:20:21)

Ja, ja, genau, ganz gleich. Nur aus Metall und nicht aus deinem billigen Plastik.

Andy Grunwald (00:20:21 - 00:20:33)

Okay, aber okay, das Auto kommt jetzt da an. Die ganzen Leute steigen aus. Du bist jetzt der mit der meisten Erfahrung. Stehen dann Neun Leute um dich rum und warten auf eine Anweisung oder was passiert dann?

Wolfi Gassler (00:20:33 - 00:21:20)

Im Normalfall steigen die nicht mal aus, sondern du als Kommandant oder als Einsatzleiter steigst aus und checkst mal die Lage, weil vielleicht musst du das Auto ja umstellen, vielleicht steht es falsch. Das heißt, du checkst mal die Lage, nimmst dir vielleicht auch einen zweiten mit noch und dann checkt man zusammen die Lage und dann entscheidet man, welche Strategie macht man. Das ist so ähnlich, du hast das, glaube ich, mal in einer Episode schon erwähnt. Wenn es ein Incident gibt, holst du dir mal einen Kaffee und überlegst dir, was man machen könnte. Das ist so ähnlich, man steigt aus, schaut mal die Runde, auch da brennt ein Haus, aber man schaut mal um das Haus herum, was ist denn da überhaupt, ist da vielleicht ein zweites Haus, sind da Personen, gibt's da irgendwelche Leute, wo man Informationen bekommen kann, also man checkt einfach mal die Lage und dann wirklich entscheidet man die Strategie und teilt ein, wer übernimmt welchen Teil und wie geht man wirklich vor.

Andy Grunwald (00:21:21 - 00:22:02)

Ziehen wir mal kurz den Vergleich zu IT-Systemen. Was wir bei der Feuerwehr haben, irgendjemand hat ein Schadensereignis oder ein Brand gemeldet. Ihr seid losgelaufen, ins Auto gesprungen und zum Ort gefahren. Im IT-System wäre das, irgendwer, irgendwas hat festgestellt, dass irgendetwas im System nicht funktioniert. Das kann ein automatisches Monitoring-System sein, das kann auch einfach sein, der Kunde, der angerufen hat und sagte, meine Zahnung geht nicht durch, oder der Chef hat mal wieder auf der Webseite rumgeklickt und dann muss das nicht funktionieren. Dann wird irgendwie ein Channel aufgemacht, ein Kommunikationskanal, und ein paar Leute werden da reingeholt, die sich mit hoher Wahrscheinlichkeit da auskennen. Das wäre dann jetzt das Pendat da, alle laufen zur Feuerwehr und steigen ins Auto und sind jetzt da.

Wolfi Gassler (00:22:02 - 00:22:19)

Ich glaube, wichtig ist aber, die Leute, die sich auskennen. Das hast du schon richtig gesagt. Also ich nehme da im ersten Moment oder in diesem technischen Channel, nehme jetzt keine POs oder sonstige Leute mit rein, da geht es wirklich um die Problembehebung, um die technische Zusammenarbeit, würde ich sagen.

Andy Grunwald (00:22:19 - 00:22:38)

Ja das ist das korrekt ich meine die die pos und ko natürlich können die sich auch auskennen ja je nach je nach ausfall aber ich glaube die würde ich eher mit den schaulustigen vergleichen wenn ich die ganze sache rum spricht und falls die polizei mal eine barrikade aufgestellt hat die die sich dann auch beim brandort dann da rumwimmeln oder.

Wolfi Gassler (00:22:38 - 00:22:56)

Oder die Presseleute zum Beispiel, die einfach unbedingt Informationen haben wollen, weil die wollen ja irgendwas online stellen oder Fotografen oder ähnliches. Mit denen arbeitet man auch zusammen natürlich, aber in gewisser Weise, wenn man denen nichts in die Hand gibt, dann holen sich die halt die Informationen selber und das ist dann eher problematisch meistens.

Andy Grunwald (00:22:56 - 00:23:12)

Ich entschuldige mich jetzt schon mal für alle Product Owner oder Product Manager. Ihr seid natürlich nicht die Schaulustigen. Doch in manchen Situationen, wie zum Beispiel in so einem Incident, wenn man nichts Gutes beizutragen hat, dann lässt man die Leute ein bisschen arbeiten. Aber ich meine, das Wissen.

Wolfi Gassler (00:23:12 - 00:23:16)

Jetzt hast du dich wieder gerettet und der Shitstorm bleibt aus. Leider. Noch mal Glück gehabt.

Andy Grunwald (00:23:16 - 00:23:51)

Ach, ich glaube, einen Shitstorm kriege ich so oder so. Naja, egal. Zurück zum Thema. Okay, dann steigt der Commander aus, hast du gerade gesagt. Ist hier eigentlich genau das Gleiche. Man versucht erstmal kurz herauszufinden, okay, was ist eigentlich down? Was ist betroffen? Und schreibt dann eine kurze Beschreibung, so nach dem Motto, das ist der Stand. Das wissen wir zum aktuellen Zeitpunkt. Das Zahlungssystem funktioniert gerade nicht. ohne irgendwelche großen Details. Und jetzt hast du gesagt, okay, das passiert bei euch auch, ihr checkt die Lage, müsst das Auto umparken. Was passiert dann? Die Leute sitzen noch im Auto, was passiert dann?

Wolfi Gassler (00:23:51 - 00:24:52)

Ja, also der Einsatzleiter überlegt sich eine Strategie und diese Strategie ist normalerweise standardisiert, mehr oder weniger. Natürlich ist man da immer flexibel, aber man hat natürlich im Vorfeld eine Ausbildung, man trainiert ständig Sachen, man hat Runbooks quasi, weil es passiert, wenn es einen Brandmelder gibt, was mache ich da, Schritt 1, Schritt 2, Schritt 3, wie geht er vor, wen muss ich informieren, also ich gehe da wirklich eine Liste durch, natürlich kann ich das dynamisch dann zusammenstückeln und es gibt natürlich Einsätze, die weniger Standard sind als andere und dementsprechend muss ich mit meiner Erfahrung und den ganzen Tools, die mir an die Hand gelegt wurden, durch die Vorbereitung, durch das gute Training, kann ich dann entscheiden, was machen wir, was für Strategie wählen wir, welchen Schlauch verwenden wir, was machen wir eigentlich, löschen wir, löschen wir mit Schaum, löschen wir mit Wasser, konzentriere mich zuerst auf Personenrettung, wenn es natürlich Personen gibt, also ich überlege mir einfach, wie gehe ich vor und dann im Team wird es umgesetzt gemeinsam.

Andy Grunwald (00:24:53 - 00:25:20)

Habt ihr habt ihr dann auch mehrere level in den strategien wie zum beispiel du sagst es gerade personen rettung und löschen ich hoffe, dass die personen rettung allerhöchste priorität hat und wenn alle personen gerettet werden dann wird erst das hab und gut gelöscht also sind das sind das so short term mit term strategien oder oder sagt ihr, Nee, die einen löschen schon mal und dann rennen da, während das Wasser fließt, zwei Leute rennen rein und holen die Personen raus.

Wolfi Gassler (00:25:21 - 00:26:10)

Es kommt natürlich drauf an, wie viele Leute du hast. Also umso größer das Ganze und umso mehr Leute du hast, umso mehr kannst du natürlich parallelisieren. Personenrettung hat natürlich höchste Priorität, ist klar, aber es hilft dir nichts, wenn du jetzt 100 Leute auf eine Personenrettung schickst. Also das teilst du dann natürlich auch auf, dass du sagst, okay, diese Gruppe übernimmt die Personenrettung, der Rest probiert schon mal zu löschen. da dritte teil probiert das feuer von den umgebenden häusern abzuhalten solche dinge also du da ist dann natürlich schon ein wenn du die kapazitäten hast also das kann natürlich dann schon wenn es ein großer einsatz ist wirklich in die hunderte leute gehen, Und dann wird's natürlich sehr sehr hierarchisch und du hast extrem viele Levels, aber es ist stark hierarchisch natürlich von oben nach unten koordiniert, weil im Einsatzfall muss das einfach hierarchisch sein, weil da extrem schnell entschieden werden muss.

Andy Grunwald (00:26:10 - 00:26:25)

Der Einsatzleiter, macht der da selbst mit oder hält der sich im Hintergrund und steht immer bereit für Fragen von den Leuten und Strategie wechseln und kommuniziert die? Also hat der auch einen Löschrohr in der Hand oder?

Wolfi Gassler (00:26:27 - 00:28:53)

Der hat natürlich normalerweise, der muss ja frei und flexibel sein, der muss sich ja bewegen können, der muss jederzeit, wenn sich irgendwas ändert, muss der reagieren können. Das heißt, der kann natürlich nicht vorne an einem Strahlrohr stehen und Wasser aufs Haus spritzen, weil wenn sich da irgendwas ändert und plötzlich hört man, es wird eine Person vermisst, Dann musste er das ja organisieren, dass die Person gesucht wird und der würde am Strahlrohr hängen bleiben, weil er ja das Feuer löschen muss. Und ich glaube, das ist ganz wichtig, dass es so eine Person gibt, die diese Flexibilität hat. Und die kann dann natürlich auch zum Beispiel Kommunikation übernehmen. Bei ganz großen Schadensereignissen gibt es normal eine eigene Person, die sich nur an die Kommunikation kümmert. Da gibt es also den Einsatzleiter, der den Incident übernimmt oder den Einsatz und wirklich die Operationen koordiniert, die wirklich die Feuerwehrleute und wie die Strategie umgesetzt wird, der exekutiert und dann gibt es eine Person, die nur die Kommunikation übernimmt und das ist extrem wichtig, Weil das Problem ist ja, wenn der Einsatzleiter, der die Strategie macht und sich überlegt, was machen wir denn mit dem Incident? In welche Richtung probieren wir den zu beheben, wenn es jetzt irgendeine DDoS-Attacke gibt zum Beispiel? Was machen wir denn überhaupt? Was probieren wir? dann ist der wahrscheinlich mit dem so eingedeckt, dass er nicht auch noch die gesamte Stakeholder-Kommunikation übernehmen kann. Dass der einen eigenen Channel pflegt, dort Informationen reinschreibt, vielleicht sogar noch für die Kunden irgendwie auf Twitter schreibt, was denn gerade aktuell passiert. Der hat vermutlich die Kapazität nicht. Das heißt, es gibt nochmal eigene Kommunikationsleute oder einen Kommunikationsofficer oder wie man auch immer nennt, der wirklich die Kommunikation übernimmt und dann Ansprechpartner ist. Und der verhindert eigentlich, dass dir zum Beispiel die ganzen Presseleute, die Zeitungsleute, deinen Einsatzleiter stören, weil der muss sich um das Feuer kümmern oder um das, was es auch immer ist, und der hat keine Zeit jetzt mit den Presseleuten zu sprechen. Und wenn du aber den Presseleuten, wie erwähnt, eben nicht die Informationen gibst, dann holen sich die die Informationen und laufen halt einfach los und probieren die Informationen zu bekommen, egal wo. Und darum ist halt Kommunikation so wichtig. Erfahrungsgemäß ist es auch eine gute Variante, dass man das wirklich splittet. Auch bei klassischen IT-Incidents, dass man die Kommunikation wirklich auf eine eigene Person auslagert, weil es halt extrem viel Arbeit ist und das sollte nicht die eigentlichen Leute stören, die an der Problembehebung arbeiten.

Andy Grunwald (00:28:53 - 00:29:18)

Zu der Kommunikation und zu der Kommunikationsrolle im IT-Incident komme ich jetzt gleich, aber ich habe noch mal eine Frage zu der Kommunikationsrolle innerhalb eines Feuerwehreinsatzes. Du sagtest gerade, okay, Kommunikation zu den Stakeholder und Presse. Presse ist ja dann eher ein externer Stakeholder. Gibt es auch irgendwie einen Kommunikationskanal zu den internen Leuten, also zu den Feuerwehrleuten oder passiert das dann alles, macht das der Inzidenzkommander dann über Funk und teilt die neue Strategie mit?

Wolfi Gassler (00:29:18 - 00:29:54)

Das passiert normal klassisch hierarchisch von dem Einsatzleiter aus. Der hat weder Gruppenkommandanten oder in Deutschland heißt es immer Führer, eigenartigerweise. Wir in Österreich sind von dem Führerwort abgekommen, bei uns heißt es immer Kommandant, Gruppenkommandant, nicht Gruppenführer. Eigenartigerweise. Auf jeden Fall wird es über diese klassischen hierarchischen Strukturen gespielt und einfach nach unten verteilt, weil der, der schlussendlich am Strahlrohr steht, muss ja vielleicht nicht alle Details wissen von dem Gesamteinsatz, aber natürlich der Einsatzleiter sollte alle Informationen haben und der macht es per Funk oder klassisch über die hierarchischen Strukturen nach unten.

Andy Grunwald (00:29:54 - 00:30:53)

Bei IT-Inzidenz ist das nämlich ähnlich. Man sollte eine Kommunikationsperson haben und je nach Auslegung, was ihr für eine Firma habt, was ihr für ein Business habt, gibt es dann natürlich verschiedene Kommunikationsleute. Nehmen wir mal eine klassische Website, E-Commerce Shop, dann ist es oft so, dass die Kommunikation primär nach innen gerichtet ist, dass das Management, das Board oder irgendwelche, dein Vorgesetzter, wissen möchte, was los ist, in welchem Stand haben wir, wann läuft das System wieder, wann können wir wieder Zahlungen akzeptieren, da ist die Kommunikation meist nach innen gerichtet. Wohingegen, wenn du eine Software hast, die zum Beispiel ein Whitelabeling-Angebot hat, nehmen wir mal Trivago zum Beispiel, dass die Hotelsuche an andere Firmen als Whitelabel angeboten wird, da packen die ihr Firmenlogo drauf, aber hinten dran wird die Technologie, die Hotelsuchen-Maschine von Trivago genutzt, dann kann das natürlich sein, dass deren Website, deren Service auch betroffen ist. Dann ist die Kommunikation natürlich auch ein bisschen nach außen gerichtet zu den sogenannten Partnern.

Wolfi Gassler (00:30:53 - 00:31:21)

Ich würde ganz allgemein sagen, in allen Bereichen, du musst die Kunden informieren. Im B2B-Bereich ist das vielleicht noch wichtiger, weil du halt wirklich große zahlende Kunden hast und auch bei der White-Label-Lösung sind das ja eigentlich deine Kunden. B2B, ganz einfach, aber auch B2C. Es gibt nichts Schlimmeres, als du gehst auf irgendeine Webseite und die Hälfte funktioniert nicht. Meiner Meinung nach gehört da auch sofort irgendwie eine Nachricht, wir haben ein Problem, wir arbeiten daran, dass auch die normalen Kunden informiert sind.

Andy Grunwald (00:31:21 - 00:32:00)

Es kommt aber ganz drauf an, wie du deine Kunden informierst und ob du sie aktiv informierst oder ob du die Informationen irgendwo zur Verfügung stellst und die Kunden können die Informationen abrufen. Also nehmen wir mal diese White-Label-Geschichte zum Beispiel, da würde ich jetzt nicht die Kunden informieren, sondern nur meine Partner, die man White-Label beziehen. Wohingegen eine Software-as-a-Service-Lösung, da muss man dann gegebenenfalls schon die betroffenen Kunden informieren. Oder man hat vielleicht sogar eine eigene Statuspage. Man kennt diese Statuspages von den Public-Cloud-Providern. Die informieren mich ja auch nicht jedes Mal, wenn die ein Outage irgendwo haben in der Region, in der ich tätig bin, kriege ich ja auch keine E-Mail.

Wolfi Gassler (00:32:00 - 00:32:22)

Ganz wichtig übrigens als kleiner Einwurf, wenn man so eine Statuspage macht, sollte die bei einem anderen Provider gehostet sein und nicht auf der klassischen eigenen Infrastruktur, sondern die sollte möglichst abgeschottet irgendwo ganz anders gehostet sein und zugänglich sein, auch mit anderen Zugangssystemen, weil wenn das Zugangssystem ausfällt, dann kommt man auch dort nicht mehr hin. Also ihr solltet wirklich komplett eigenständig sein. Nur ein kleiner Tipp.

Andy Grunwald (00:32:22 - 00:33:00)

Ich meine, zum Thema Reliability und Resilience können wir natürlich auch noch mal irgendwann mal eine Folge machen, was für Strategien es da gibt, welche Systeme man wo hosten sollte. Das, was Wolfgang gerade mit der Status-Patch gesagt hat, das gilt natürlich dann auch mit dem Monitoring-System. Und da können wir auch mal Eat-Your-Own-Dog-Food besprechen. Wie viel sollte man seine eigene Plattform eigentlich nutzen? Ist ein anderes Thema, wie dem auch sei. Wir haben gerade über die Status-Patch besprochen bei dem bei dem Software-as-a-Service. Da kann es natürlich auch sein, dass durch den Ausfall bestimmte Kunden betroffen werden, betroffen sind. Nehmen wir mal als Beispiel der aktuelle Ausfall von Atlassian.

Wolfi Gassler (00:33:01 - 00:33:04)

Jetzt habe ich gehofft, wir schaffen es ohne dem Atlassian Ausfall, aber natürlich.

Andy Grunwald (00:33:04 - 00:33:22)

Er ist so top aktuell, den holen wir rein. Zum Beispiel die Firma, in der ich aktuell arbeite, die nutzt Atlassian Jara in der Cloud. Wart ihr betroffen? Nein, das ist ja irgendwie das komische. Irgendwann hat mal irgendjemand im Slack einen Link gepostet, hör mal, auf Twitter geht gerade alles steil, Atlassian ist seit einer Woche down.

Wolfi Gassler (00:33:22 - 00:33:27)

Es waren ja nur unter Anführungszeichen so 500 Unternehmen oder so, aber es waren halt auch einige große dabei.

Andy Grunwald (00:33:28 - 00:33:33)

Genau. Fünfhundertunternehmen von, weiß ich nicht, was schätzt du, wie viele Leute nutzen Atlassian Jira in der Cloud?

Wolfi Gassler (00:33:33 - 00:33:35)

Keine Ahnung, wie viele? Tausende wahrscheinlich.

Andy Grunwald (00:33:35 - 00:34:32)

Schon eine ganze Menge. Ich habe jetzt gerade gelesen, die verkaufen seit letztes Jahr schon gar keine neuen On-Premise-Lizenzen mehr. Das bedeutet, die zwingen ihre Kunden nach und nach in die Cloud zu moven. Auf jeden Fall in einem solchen Fall, wenn ein Kunde, aktiv betroffen ist. Dann muss man den Kunden natürlich aktiv ansprechen und dann heißt es nicht nur Customer Support aktivieren, sondern auch das ganze, dein ganzes Sales Team, weil du möchtest ja nach dem Ausfall die Kunden, die betroffen waren, nicht verlieren. Da muss das Sales Team natürlich auch aktiv werden und das Vertrauen wieder aufbauen. Deswegen sollte man, sollte die Kommunikationsperson oder Personen, je nach Service, wie wir gerade besprochen haben, Die kommunikation natürlich entsprechend entsprechend in die in die richtigen wege leiten damit das auch alles nicht nur beim incident jeder up to date ist sondern auch danach und auch natürlich auch noch irgendwelche nachwehen lösen können.

Wolfi Gassler (00:34:32 - 00:36:13)

Was es bei der Feuerwehr sonst noch gibt, also gerade bei Großschadensereignissen, Katastrophenfall auch. Also wir haben schon gehabt die Leute, die quasi wirklich die Execution machen, die Operation. Es gibt Leute, die die Strategie machen oder den Einsatzleiter. Es gibt die Kommunikationsleute. Und dann gibt es noch, was ganz ein wichtiger Bereich ist, ist die Logistik. die Logistik auf der einen Seite und die Administration auf der anderen Seite. Administration ist jetzt wahrscheinlich weniger wichtig im IT-Bereich, aber Logistik ist durchaus ein wichtiger Punkt. Da ist natürlich bei der Feuerwehr viel, viel größer. Da geht es darum dann, woher bekomme ich irgendwie Spezial-Equipment zum Beispiel oder muss ich keine Ahnung, einen Bagger organisieren in einem Katastrophenfall. Also die Logistik ist ja bei so klassischen Sachen im echten Leben ein großes Problem, würde ich mal sagen. Im IT-Bereich ist es ein bisschen einfacher, aber es geht auch um so klassische Sachen wie, habe ich genug Essen für alle meine Einsatzkräfte? Wenn der Einsatz sich über mehrere Tage zieht, Waldbrand zum Beispiel, habe ich genug Getränke, Flüssigkeit für meine Leute. Wie kann ich denn das logistisch überhaupt planen? Brauche ich ablösen, wenn das ein langer Brand ist zum Beispiel oder eben auch ein Waldbrand? Ich kann die Leute nicht 48 Stunden im Einsatz halten. Und das kann man im IT-Bereich natürlich genauso passieren. Ich muss mich darum kümmern, sind die versorgt? Haben die Essen? Sind die abgeschottet, sodass sie in Ruhe arbeiten können? Brauchen die sonst irgendwas? Wie schaut es mit der Ablöse aus, wenn ich das Problem nicht lösen kann nach acht Stunden? Was mache ich denn dann? Die müssen irgendwann schlafen. Es kann ja nicht jemand acht Stunden hart durcharbeiten und dann vielleicht nochmal acht Stunden.

Andy Grunwald (00:36:13 - 00:37:17)

Als ich früher in einer Webagentur gearbeitet habe, da haben wir eine Multimaster-MySQL-Replikation betrieben für den Kunden. Und wir hatten zwar einen Hosting-Provider, weil wir nur die klassische Webagentur waren, aber mit der Hosting-Agentur haben wir sehr, sehr eng zusammengearbeitet und auch in solchen Ausfällen dann immer, ich nenne es mal, eine Standleitung gehabt und den Ausfall zusammengelöst. Und da war das wirklich genau so, wie du gerade beschrieben hattest. Ich war in dem Ausfall dran, habe da geholfen mit meinem damaligen Chef und einer der geschäftsführer sagte irgendwann war wie freitagabend super spät wir sind halt immer noch im auswahl dran sagte. Wollen wir mal was essen ich ich würde pizza besorgen und das ist glaube ich dann genau dieser logistik teil den du hier halt beschreibst er ist dann losgezogen hat einfach pizza besorgt und irgendwann hatte ich dann eine pizza stehen, wir haben da wir haben da weiter das das ding gelöst jetzt habe ich mich gerade gefragt damals, In Bürozeiten, wo jeder noch ins Büro ging, war das ja alles super. Wie wird man solche Essenslogistik bei Remote-Incidents gerade so machen? Macht man dann irgendwie Uber Eats oder Deliveroo für jeden? Oder wie läuft das?

Wolfi Gassler (00:37:17 - 00:39:22)

Das ist eine wirklich spannende Frage. Das habe ich noch gar nie gedacht. Aber ich glaube grundsätzlich, es geht darum, dass sich einfach jemand darum kümmert. Es sollte ja, gerade beim größeren Incident arbeiten ja vielleicht auch mehrere Leute dran. Ist ja auch okay, wenn man da mal fünf Minuten irgendwie auf Uber Eats was bestellt. Aber es wäre zum Beispiel eine gute Sache, wenn einfach jemand sagt, okay, da hast du den Uber Eats Gutschein oder gib uns deine Adresse und wir übernehmen den Rest oder so, wobei beim Essen musst du fast selber aussuchen mittlerweile. Aber dass sich jemand einfach darum kümmert und vielleicht sogar die Leute anstoßt. Wie schaut es mit Essen aus? Brauchst du irgendwas? Oder es gibt ja auch andere Sachen, dass man halt einfach abklärt, können die Leute zum Beispiel überhaupt acht Stunden durcharbeiten, vielleicht müssen die irgendwie das Kind vom Kindergarten abholen oder und da gibt es niemand anderen. Also, dass sich jemand einfach um diese Möglichkeiten, die da entstehen können oder die Probleme, die da entstehen können, einfach kümmert und sich überlegt, gibt es diese Probleme und das muss fast eine Person sein, die nicht aktiv mitarbeitet, weil sonst hast du keinen freien Kopf, um dir genau diese Sachen zu überlegen. Das ist übrigens ganz klassisch meiner Meinung nach Lead-Aufgabe. Die Leute arbeiten an einem Inzident und irgendein Lead von dem Team zum Beispiel, der kümmert sich um so logistische Sachen, um Essen, auch um die Kommunikation, wenn es keine eigene Person gibt. Der muss einfach dieses Team abschotten, am besten, ich habe das immer so gemacht, am besten in irgendeinen Raum sperren, das Team, und niemand weiß, wo das Team überhaupt sitzt, weil in einem Großraumbüro kommen sonst die POs und andere Leute und nerven dieses Team. Also wenn das möglich ist, vielleicht sogar abschotten, irgendwohin verfrachten und dann denen hin und wieder einfach helfen oder halt nachfragen. Also hin und wieder nachfragen, brauchen sie irgendwas, eben Essen oder sonst irgendwas, Informationen einholen, wie ist der aktuelle Stand, aber auch nicht nerven. Und du bist dann verantwortlich als Lead oder als Kontaktperson zur Außenwelt, um die Stakeholder zu informieren. Ich glaube, in den meisten Firmenstrukturen von der Größe her übernimmt das wahrscheinlich ein Lead oder eine andere Spezialistin.

Andy Grunwald (00:39:22 - 00:41:07)

Ich möchte nochmal ganz stark darauf hinweisen, dass dies keine schlimme Arbeit ist oder ähnliches, sondern eine unglaublich wertvolle Arbeit, sich in solchen Zeiten um das Team zu kümmern und auch um deren leibliches Wohl. Also es ist keine Assistentarbeit oder ähnliches, das sollte wirklich jemand tun, weil diese Menschen retten eurer Firma gerade eigentlich, auf gut Deutsch gesagt, den Arsch. Und einfach mal ne Pizza oder Chinesisch oder Sushi zu bestellen oder mal Kaffee bringen oder vielleicht mal ne Fritz Cola oder ähnliches, ja. Da brecht ihr euch keinen Zacken aus der Krone, sondern ihr haltet die Leute am Leben sozusagen, ja. Die geben da ihr Größtes. Und ne andere Sache, das was du gerade erwähnt hast, das ist ja jetzt gerade total lustig. Wir reden zwar jetzt gerade über die Bürozeiten mit Abschotten und Großraumbüro und die alle in einem Raum. Diesen Raum nennt man eigentlich War Room. Und in der ganzen DevOps-Philosophie ist dieser War Room eigentlich ein Anti-Pattern. Und, das ist lustig. Der Punkt ist aber, dieser Raum, mehr oder weniger, ist supersinnvoll, weil da hat man einen offenen Kommunikationskanal, ja? Natürlich muss man sich hier und da mal konzentrieren, wenn man sich Loglines durchschaut oder ein paar Befehle in die Shell tippt oder Ähnliches, und dann quatscht da jemand rein, hey, pass mal auf, ich hab jetzt diese neue Erkenntnis, wie denkt ihr darüber? Natürlich stört das in irgendeiner Art und Weise. Aber du brauchst halt diesen offenen Kommunikationskanal. Und wie sieht sowas im Remote aus? Im Remote sieht sowas ganz oft aus, dass du entweder einen Slack-Huddle startest, das ist eine Slack-Telefonie, wenn man so möchte, oder einen Google Meet oder einen Zoom. Und alle Leute sind da einfach und schalten sich auf Stumm oder reden einfach und halten einfach den Ball am Rollen.

Wolfi Gassler (00:41:07 - 00:42:25)

Ich glaube, das ist auch wichtig, wie du gesagt hast, das Ganze proaktiv zu machen, die Kommunikation und die Kommunikation nach außen, sei es jetzt durch einen Slack-Channel, also im Idealfall einen Slack-Channel eben, wo nicht die Leute drin sind, die daran arbeiten, sondern einen reinen Kommunikations-Slack-Channel. Natürlich bei der Feuerwehr wird das klassisch über irgendwelche Lichter oder Markierungen gemacht, wo halt ein großes Pressesprecher oder so steht, bei der Polizei ist ja dasselbe. Die Leute kennt man dann auch, die kann man fragen, aber man muss natürlich proaktiv nach draußen gehen und sagen, hey, wenn ihr Informationen wollt, ich bin der Ansprechpartner und ganz allgemein der aktuelle Status ist XY. Dass man also wirklich das proaktiv nach außen sendet. Und man darf sich nicht erwarten, dass die Leute den Slack-Channel oder alle Informationen bekommen. Ich kann mich an so eine Situation erinnern, wo mich dann irgendwie mein Chef mal gefragt hat, was ist jetzt eigentlich mit diesem Incident los? Da arbeitet ja niemand dran. Ich habe gesagt, natürlich arbeitet unser ganzes Team daran, die sitzen nur in einem anderen Raum. Und ich habe mir gedacht, er hat das irgendwie mitbekommen über die Slack-Channel und so weiter, weil er war ja überall drin. Aber der hat das halt einfach nicht gelesen oder überlesen und da muss man halt einfach proaktiv auch wirklich auf die Stakeholder zugehen und die Stakeholder informieren und wirklich sagen, okay, das ist der aktuelle Stand und wirklich abchecken, haben die das auch alle mitbekommen.

Andy Grunwald (00:42:25 - 00:43:05)

Und wenn ihr ein Stakeholder seid, ihr seht, es gibt einen Inzident in der Firma, Tut allen beteiligten gefallen springt nicht in den channel äußert nicht einfach irgendwelche vermutungen wenn ihr euch nicht sicher seid ich weiß ihr meint das alle sehr gut doch im endeffekt stört ihr mehr und bringt mehr unruhe rein weil jede vermutung sofern, die grundursache noch nicht klärt es jede vermutung ist ein neuer pfad ein neuer ast der aufgemacht wird der investiert wird und das kann natürlich auch sogenannte rauchbomben sein wo man natürlich vielleicht sogar minuten oder, wenn es hart auf hart kommt stunden investiert um das dann halt später festzustellen dass das nicht der.

Wolfi Gassler (00:43:05 - 00:43:55)

Fall war, Ich glaube, da ist es auch ganz wichtig, dass es wirklich Hierarchien gibt oder klar gekennzeichnete Hierarchien, zumindest in so einer Kriegssituation, wenn man das noch so nennen sollte. Aber in der klassischen Literatur wird es halt immer als war or peacetime so angesehen. Und da muss einfach klar sein, wer ist der Ansprechpartner. Bei der Feuerwehr ist das halt klassisch, hinten am Rücken ist ein großes Schild, da steht halt Einsatzleiter. Der hat meistens eine andere Farbe oder eine andere Helmfarbe. Dann ist sofort klar, der ist Einsatzleiter, der ist zuständig. Und wenn ich irgendwie ein Problem habe, gehe ich zu demjenigen. Und das muss halt bei einem Incident, über dem Incident Manager auch klar definiert sein, wer ist denn Incident Manager. Das kann immer der gleiche sein oder ist es vielleicht der Lead, aber es sind sicher nicht die Leute, die das Problem gerade beheben.

Andy Grunwald (00:43:55 - 00:45:37)

Das Lustige ist, Einsatzleiter wird im Englischen im IT-Spektrum auch wirklich Incident Commander genannt, abgekürzt auch IC. IC steht hier nicht für Individual Contributor, sondern wirklich Incident Commander. Und bei uns in der Firma ist das auch wirklich so, jeder Inzident hat einen Inzident Commander. Der Inzident Commander wird auch durchrotiert. Wir haben auch Tooling, das uns nach 2, 3, 4 Stunden daran erinnert, hey, rotiert doch mal bitte die Rollen durch, weil die Konzentration einfach wegbricht. Aber wenn du nämlich drei, vier Stunden Incident Commander bist, das ist schon sehr energieraubend und du brauchst einfach mal eine Pause. Das gilt aber nicht nur für den Incident Commander, sondern das gilt auch für den Mitigator und für den Investigator. In deinem Feuerwehrbeispiel wären das jetzt zum Beispiel die Leute, die auf der einen Seite schauen, dass sie den Brand löschen, auf der anderen Seite natürlich auch schauen, dass der Brand nicht auf weitere Häuser überspringt oder ähnliches. versucht natürlich erstmal das Problem zu mitigaten, also erstmal zu beheben, auf gut deutsch auch Duct Tape dran zu packen, was auch immer hilft, das um das System wieder einigermaßen stabil und nutzbar zu kriegen. Der Investigator schaut natürlich, okay was ist da los, wie kam es zu dieser Situation und gibt es vielleicht irgendeine Methode, wo wir das System mit relativ wenig Aufwand auf einen sehr stabilen Stand heben. Das sind auch diese Aktionen, die die zum Beispiel wie im IT-Bereich dann auch parallelisieren, so wie der Wolfgang das bei der Feuerwehr auch beschrieben hat, mit der Menschenrettung und mit dem Löschen, Vorbereiten und schon mal den Schlauch anschließen oder ähnliches. Manche Aktionen kann man halt parallelisieren. wie sieht das habt ihr habt ihr bei der feuerwehr irgendwie so eine art protokollführer so ein schreiberling in der klassischen.

Wolfi Gassler (00:45:37 - 00:46:52)

Strukturierung gibt's gibt's eine position in einer gruppe in einer feuerwehrgruppe, die nennt sich melder und die kommt aus der zeit eigentlich wo man noch keine funkgeräte hatte und da gab es auch eine melder tasche immer in dem auto das war eigentlich nur so eine ledertasche die man sich umhängen hat können da waren block und kugelschreiber oder so drin, Und der war eigentlich verantwortlich, um so Nachrichten zu transportieren und auch das Ganze irgendwo aufzuschreiben, wenn es irgendwo ein Problem gibt. Die Rolle gibt es noch immer eigenartigerweise, hat sich natürlich stark gewandelt. Mittlerweile ist er eigentlich so der Stellvertreter von einem Einsatzleiter oder Gruppenkommandant. Aber es gibt natürlich definitiv Rollen, die so Schreiberlinge, wie du sie nennst, sind und die das Ganze dokumentieren, klarerweise. Und umso größer der Einsatz, umso mehr Leute, beziehungsweise umso dedizierter ist die Rolle natürlich dann von der Dokumentation. Und die Dokumentation ist extrem wichtig, weil du natürlich im Nachhinein die ganze Sache durchbesprichst, eine Nachbesprechung hast und auch daraus lernen willst. Ganz abgesehen davon, dass du natürlich auch zusammenfassen musst, was ist denn passiert, was haben wir gemacht, die Versicherung will ein Report haben, wenn jetzt irgendwas passiert ist, die Presse will ein Report haben. Also die Nachbearbeitung ist eigentlich ein sehr großer Teil von so einem Einsatz.

Andy Grunwald (00:46:53 - 00:47:01)

Was sind so ein paar Key-Punkte, die der Melder oder Schreiberling für die Nachbesprechung dann protokollieren sollte, während des Einsatzes?

Wolfi Gassler (00:47:01 - 00:47:56)

Mittlerweile läuft dann natürlich auch viel über Software, klarerweise einfach wer, wo, was gemacht hat, was durchgeführt worden ist, eben die Personenrettung oder ob dann irgendwelche Atemschutztrupps eben mit diesen Atemschutzmasken reingegangen sind oder was man dann eben gemacht hat, das Dach aufgebrochen hat oder Das halt einfach so dokumentiert ist, was man gemacht hat. Ganz, ganz wichtig eben auch für Versicherungsgeschichten natürlich. Und einfach daraus zu lernen im Team dann, dass man einfach im Nachhinein auch bespricht, was hat man denn gemacht, was hat gut funktioniert, was hat schlecht funktioniert. Eine ganz klassische Nachbesprechung. Und daraus einfach dann wieder abzuleiten, okay, müssen wir was ändern? Müssen wir unsere Runbooks updaten? Müssen wir uns was überlegen? Brauchen wir neue Tools zum Beispiel, wenn sowas nochmal passiert? ganz klassisch ist was kaputt gegangen müssen wir was ersetzen müssen wir irgendwas ändern also dass man da einfach seine schlüsse daraus zieht aus so einer ganzen aktion.

Andy Grunwald (00:47:57 - 00:50:20)

Das ist wirklich wirklich faszinierend umso mehr wir darüber sprechen desto mehr stelle ich fest das ist eigentlich genau dasselbe und weil in der it gibt es halt im perfekten in der perfekten geld gibt es auch einen schreiber linken sogenannten scribe protokoll land, der auch während des Incidents immer mitschreibt. Und diese Person dokumentiert dann zum Beispiel, okay, was wurde wann, wie, wo gemacht, beschlossen, diskutiert, welche These wurde bewiesen oder verworfen, welche Entscheidung wurde wann, wie, unter welchen Voraussetzungen getroffen, welche Aktion wurde auf den Servern getätigt oder auf der Applikation. Und auch wie du sagtest, ziemlich viel kann man natürlich je nach Maturity der eigenen Infrastruktur durch Software automatisieren. Nehmen wir mal als Beispiel, welche Befehle wurden zu welcher Uhrzeit auf welchen Notes ausgeführt. Da kann man sich ein klassisches Log ziehen vom AuditD, was mit RSYS-Log irgendwo hingepiped wird. Und dann hat man automatisch jeden einzelnen Befehl, den vom Mitigator oder vom Investigator wirklich auf den Notes ausgeführt wird, ohne irgendwelche Fehler. Und das wird natürlich dann auch später für, du hast es Nachbesprechung genannt, ja, so heißt das, glaube ich, eigentlich auch im IT-Bereich, Postmortem, ja, ist dies gegebenenfalls nicht immer eine Besprechung, je nach Größe des Inzidents, ab und zu auch einfach nur ein Dokument, aber in der Regel hat man dann ein Meeting, das Postmortem-Meeting, wo dann als Artefakt ein Postmortem-Dokument rausfällt. Da sprechen wir aber gleich nochmal drüber. Je nach Größe der Firma kann es natürlich auch sein, dass der Incident-Commander der Schreibling ist. Je nach Größe und je nach Auslastung des Incident-Commanders. Aber du kannst natürlich auch Tooling einsetzen. Im IT-Bereich zum Beispiel. Es gibt ein Tool, das nennt sich Incident.io. Incident.io ist ein Software-as-a-Service. Und die haben zum Beispiel auch ein Slackbot. Immer wenn ein neuer Incident deklariert wird, wird ein eigener Stack-Channel aufgemacht, der Incident-Bot joint automatisch und da kannst du schreiben, schreiben, schreiben und wenn du manche Nachrichten mit gewissen Emojis belegst, dann werden die automatisch in der Zeitleiste, in der Timeline von dem Incident-Aerosystem dargestellt oder als Aktion oder Follow-Up markiert. Also mittels Emojis kannst du dann recht schnell dir deine Informationen für deine Postmortem-Dokumente Ja, wie soll man sagen, zusammen Emojien.

Wolfi Gassler (00:50:20 - 00:50:29)

Zu Postmortems hast du ja auch mal einen schönen Blogartikel geschrieben, können wir auch gerne verlinken. Du bist ja großer Fan von Postmortems, warum?

Andy Grunwald (00:50:29 - 00:54:08)

Postmortems selbst sind erstmal nur die Dokumentation zu der Frage, was ist eigentlich passiert, wie ist es dazu gekommen, wie haben wir es gelöst und was lernen wir daraus, ja? Warum bin ich davon mega Fan? Ich denke, das ist das wertvollste Dokument, was du als Team erzeugen kannst. Und wenn du das auch wirklich ernst nimmst, und das meine ich jetzt wirklich so, du musst das ernst nehmen, du musst deine Zeit investieren, um eine komplette Analyse zu machen. Du musst verstehen, wie es zu diesem Ausfall, zu diesem Ereignis kam. Und das bedeutet nicht, wir haben irgendeinen Bug in der Software gehabt. Das ist nicht ein Postmortem. Ein Postmortem sagt dann auch, dieser Bug ist seit dem 23. Dezember in der Codebase. Der wurde implementiert, als wir eine Änderung wegen diesem JIRA-Ticket gemacht haben und und und. Und dann sollte man sich auch fragen, wieso haben wir den Bug übersehen? Entweder war der Code Review fehlerhaft, oder es war kein Unit Test, oder kein Integration Test, oder, oder, oder. Und wie kommt man dazu? Woher weiß man, wann man aufhören sollte zu fragen, wenn wirklich alle Leute ein unglaublich klares Verständnis haben, wie es dazu kam? klassische strategie sind die five wise mein auto geht nicht warum weil die batterie leer ist warum ist die batterie leer und so weiter und so fort ja du gehst immer tiefer so ähnlich wie inception der kam die kagel wieder im fernsehen. Aber wirklich fragt 5689 mal warum hintereinander ich verstehe das kann nerven sein ich verstehe das doch es ist das wichtigste dass ihr das versteht weil nur so könnt ihr als team wachsen, Und wirklich zukünftige Ausfälle vermeiden. Ich mein, das ist auch der Grund, wie zum Beispiel, es gab mal, es gab jetzt die Tage, was heißt die Tage, vor ein paar Wochen, ich glaub, das ist ein Spiel, eine große Gaming-Plattform, Roblox heißt die. Die waren, ich glaub, über eine Woche, anderthalb Wochen waren die, glaub ich, down. Und irgendwann waren die wieder online, und jeder so, was ist da passiert? Ja und dann haben die glaube ich drei monate oder so gebraucht um postmortem zu schreiben dieser postmortem der ist öffentlich den verlinken wir auch gerne in den show notes ist so unglaublich gut und detailliert, weil die sich die ganze zeit genommen haben um das reale problem zu verstehen und darunter war es dann war es dann der der mehr oder weniger falsche einsatz von der software, Ja, aber die haben die ganze Zeit gebraucht, um den ganzen Inzident halt zu verarbeiten und es zu verstehen. Und die Praxis sieht aber in der Regel so aus, du hast den Inzident, der Inzident ist gelöst, irgendjemand schreibt sich auf seinen Post-it, ich muss ein Postmortem schreiben und dann ist Business as usual, ja, weil wieder die nächste Sache brennt, das nächste, der nächste Bug irgendwie gehittet wurde oder oder oder und dann dieser Postmortem hinten runterfällt. Und das ist so eine Art wie, Wie ein rotes CI-System. Wenn die Unit-Tests konstant fehlen und du dauerhaft eine E-Mail kriegst, dass deine Unit-Tests fehlschlagen, dann ist das die neue normale Welt. Und keiner kümmert sich mehr darum, ein grünes CI-System zu kriegen. Und so ist das auch bei Postmortems. Ihr müsst wirklich eurem Vorgesetzten und dem Management klarmachen, wenn ihr wirklich wollt, dass solche Inzidenz weniger werden oder einen geringeren Blast-Radius haben, einen geringeren Impact, dann müssen wir die Zeit investieren, diesen zu verarbeiten.

Wolfi Gassler (00:54:08 - 00:56:22)

Und das ist extrem viel Zeit. Auch bei der Feuerwehr, wenn man sich überlegt, es brennt halt gerade bei kleinen freiwilligen Feuerwehren, es brennt vielleicht teilweise mittlerweile durch die gute Prävention alle paar Jahre unter Umständen. Es gibt natürlich andere Einsatzarten, aber es brennt alle paar Jahre mal. Aber trotzdem trifft man sich wöchentlich, um das Ganze zu trainieren, um die Vorgehensweisen durchzugehen, um vielleicht auch eben aus den Nachbesprechungen Sachen zu lernen, zu ändern, auszuprobieren, neue Sachen auszuprobieren. Also es spielt sich ganz viel rundherum um den eigentlichen Einsatz ab. Also davor und danach, das ist ganz, ganz wichtig. Und da lohnt es sich, glaube ich, auch die Zeit zu investieren. Und das vergessen halt viele. Das ist so wie das klassische mit einem Backup einspielen. Wir haben ja Backup, aber wir haben halt nie getestet, ob das Backup einspielen funktioniert. Das muss man halt einfach, wie wenn man einen Feuerwehreinsatz trainiert jede Woche, so muss man halt auch das Backup einspielen, jede Woche einmal trainieren zum Beispiel. Zumindest testen, ob es funktioniert. Kann man ja auch automatisiert testen, aber dass das halt durchläuft, ob das funktioniert. Und so muss man sich halt einfach auch seinen Baukasten zurechtlegen. Was für Tools habe ich denn überhaupt? Auch wenn ihr das Incident Management Tool dann die halbe Zeit nicht verwendet, weil es keine Inzidenz gibt. Wenn es halt dann mal ist, dann muss alles klappen und laufen und drum wird ja auch gerne unterschieden zwischen Wartime und Peacetime. Ich bin ja kein Freund von dem ganzen militärischen Zeug, ich bin ja ein Zivildiener, habe übrigens Zivildiener bei der Feuerwehrschule gemacht, ganz nebenbei. Aber es gibt halt, ich weiß nicht, vielleicht gibt es da schon bessere Begriffe, aber es gibt halt die Zeit, wo man in Ruhe einfach Sachen sich überlegen kann, da kann das Team auch super zusammenarbeiten, da gibt es weniger Hierarchien und dann im Einsatzfall muss es halt einfach schnell gehen, da muss einfach klar sein, wer macht genau was, welche Tools verwende ich, welche Abläufe habe ich. Das ist dann meistens auch hierarchischer. Da wird genau festgelegt, wer hat das Sagen, wer übernimmt eben die Kommunikation, wer übernimmt die logistische Seite mit Essen und so weiter. Das muss ich mir im Vorhinein einmal überlegt haben, weil wenn das passiert, ist es sonst zu spät. Und das kann ich halt nur in der Peacetime machen, um mich für Wartime vorzubereiten.

Andy Grunwald (00:56:22 - 00:57:01)

In der Friedenszeit ist das zum Beispiel eine Hauptaufgabe des Site Reliability Engineering Teams. zuzusehen, dass das System reliable und resilient ist, aber auch natürlich Prozesse zu schaffen, was man in Kriegszeiten während eines Inzidenz natürlich auch hochfährt. Wer ist Schreiberling, wie entscheidet man, wer Inzidenzkommander ist. funktionieren alle Handynummern, die man im Alerting System eingetragen hat. Testet die bitte jede Woche durch. Das machen wir zum Beispiel in der neuen Firma. Wir testen jede Woche unsere Escalation Phone Numbers durch First Level, Second Level, weil wir es auch schon hatten. Das zum Beispiel eine Handynummer auf einmal nicht mehr funktioniert hat.

Wolfi Gassler (00:57:01 - 00:57:11)

Wird das zum Beispiel dann über das Incident Management System automatisch gemacht, dass da jede Nummer eine SMS bekommt und du musst irgendwie bestätigen, das wäre eigentlich relativ easy zu automatisieren oder macht ihr das händisch?

Andy Grunwald (00:57:11 - 00:59:54)

Wir machen das aktuell glaube ich noch händisch, ich glaube die sind gerade dabei das durchzuautomatisieren, aber dann nicht über das Incident I.O. System, weil das machen die da nicht. Aber wir haben nebenbei auch noch Optionen, die laufen. Ist sowas wie PagerDuty. Und wenn du ein Software as a Service nutzt, der dann halt auf Alerting oder ähnliches spezialisiert ist, die haben dann solche Features. Kommen wir nochmal zum Postmortem. Dieser Postmortem ist wirklich, viele Leute sagen, Die, unsere Organisation lernt da ja gar nicht von. Und ja, oft schreibt man, oft in vielen Organisationen wird auch ein Postmortem geschrieben, um ein Postmortem geschrieben zu haben, und da wird er wieder in den Akteschrank gelegt und nie wieder reingeguckt, das ist richtig. Ein Postmortem enthält aber auch nur, auch noch ein paar mehr Sachen, wie zum Beispiel, wie haben wir diesen Ausfall gefunden, ja, Detection? Welchen Impact hatte er? Hat der einen Impact auf Kunden oder nur aufs eigene Business? Wie war die Timeline? Was war die Root Cause? was war die lösung und wie haben wir das system wieder hochgehoben also resolution and recovery was sind die korrektive actions die die wir in zukunft machen werden also was wie sieht der long term fix aus müssen wir zum beispiel die architektur ein bisschen ändern müssen wir irgendwo eine reconnect logik für die datenbank einbauen oder oder oder. Und dann aber auch noch eine ganz große section über lesson learned also was ist gut gelaufen während des inzidenz was ist nicht so gut gelaufen wurde aber sollten wir über unterhalten sollten wir prozessänderungen machen wie zum beispiel, oh es muss immer eine support kommunikationsperson da sein aber auch wo waren wir glücklich also also wo sind wir wo waren wir lucky, Ja wir hatten mal ein incident und zwar hatten wir eine automation die google cloud projekte gelöscht hat auf basis von ich glaube wenn keine user oder wenn ein google cloud projekt kein owner mehr hatte oder sowas war mal was noch für tribago. Und diese Automation hatte einen Bug. Und dann wurden ein paar mehr Google-Cloud-Projekte, Produktions-Google-Cloud-Projekte gelöscht. Aber dank eines zweiten Bugs in dieser Löschlogik wurden nicht alle Google-Cloud-Projekte gelöscht. Also da waren wir halt schon so ein bisschen lucky, dass wir einen Bug hatten, der den Inzidenz ausgelöst hat, und einen anderen Bug, der den Blast-Radius von dem Inzidenz ein bisschen kleiner gehalten hat. So was wird dann zum Beispiel da kommen, Man muss ja sagen, zum Glück kann man bei Google Cloud gelöschte Projekte wieder herstellen, weil Google Cloud löscht sie nicht direkt, sondern markiert diese nur zu löschen. Und deswegen war der Inzidenz jetzt nicht so super groß. Aber ich als alter Infrastruktur-Mensch hoffe natürlich, ihr habt alles mit CloudFormation oder Terraform oder Chef, Puppet, Solstack oder Ansible durchautomatisiert. Das ist auch ein gelöschtes Cloud-Projekt für euch kein Problem.

Wolfi Gassler (00:59:55 - 01:00:15)

Und zusätzlich, wenn man das Ganze noch öffentlich macht, kann man damit einfach Employer-Branding machen und sehr gutes Employer-Branding. Also solche Firmen, die die Postmortems einfach veröffentlichen, sind halt auch wesentlich attraktiver und sind vielleicht dann auch am Schirm von vielen Leuten, weil sie es halt einfach gut gelöst haben oder zumindest zeigen, dass sie daraus lernen.

Andy Grunwald (01:00:15 - 01:01:14)

Wenn ihr natürlich ein Postmortem veröffentlicht, achtet mal bitte darauf, dass ihr natürlich keine internen rausposaunt. Also das bedeutet, wenn ihr irgendwie einen Algorithmus habt, der euer Firmengeheimnis beinhaltet, dann kann das sein, dass dieser Algorithmus Part des Postmortems ist, zur Analyse der Root Cause. Den müsst ihr natürlich dann rausschmeißen. Aber warum ist das interessant für das Employer Branding? Das zeigt natürlich die Kultur der Firma und der Engineering Organisation. Wie offen geht ihr mit Fehlern um? Akzeptiert ihr Fehler? Werner Vogels hat mal gesagt, Jedes System wird irgendwann mal fehlschlagen. Es ist nur eine Frage der Zeit. Es gibt keine bugfreie Software. Und die Frage ist, akzeptiert ihr das oder akzeptiert ihr das nicht und blamet jeden. Postmortem sind auch blameless. Das bedeutet, es ist völlig egal, wer den Bug committet hat. Weil Verantwortung habt ihr als Team. Und deswegen bringt es auch nichts, jemanden an den pranger zu stellen deswegen keine namen in postmortems sondern akzeptiert das das system ist gefehlt und fertig.

Wolfi Gassler (01:01:14 - 01:01:31)

Vor allem wenn eine person verantwortlich war dafür da muss man sich überlegen warum war das überhaupt möglich und nicht warum die person den fehler gemacht hat weil machen alle fehler, Sondern kann er das irgendwie verhindern oder muss sie daraus Lehren ziehen, warum eine Person so einen großen Impact überhaupt haben kann auf das System zum Beispiel.

Andy Grunwald (01:01:31 - 01:02:29)

Ein anderer wichtiger Punkt, den ich sehr sehr selten in Postmortems sehe und ich lese echt viele Postmortems, weil das ist echt immer super spannend. Stellt euch mal die Frage, was ist eigentlich schief gegangen? Und dreht die Frage mal um. Alle Leute, die am Postmortem arbeiten, hat jeder das gleiche Verständnis vom Happy Pass der Applikation. Also wie sollte der Pfad der Applikation eigentlich aussehen? wenn es den Inzidenz nicht gegeben hätte. Also was ist das korrekte Verhalten? Ab und zu ist das auch gar nicht so klar. Wenn du nämlich mit fünf Leuten an dem Postmortem arbeitest, dann kann das sein, dass es zwei verschiedene Lager gibt, was das richtige Verhalten der Applikation eigentlich wäre. Und solange der Happy Pass das richtige Verhalten gar nicht definiert ist, Wie will man dann Corrective Actions definieren und zu sagen, wie behebt man das? Also werdet euch darum im Klaren, ob ihr auch dasselbe Verständnis habt von der richtigen Funktionsweise eurer Software. Sieht so eine Nachbesprechung bei der Feuerwehr ähnlich aus nach einem Großschadensereignis?

Wolfi Gassler (01:02:30 - 01:02:40)

Ich würde jetzt gerne sagen ja, aber meine Erfahrung hat gezeigt, dass da auch sehr viel Luft nach oben ist, wie man das Ganze umsetzt und wie viel man wirklich daraus lernt.

Andy Grunwald (01:02:40 - 01:02:47)

In der Nachbesprechung sind das nur die Leute, die am Einsatz beteiligt waren oder ist das dann die ganze Kompanie von dem Einsatzort?

Wolfi Gassler (01:02:47 - 01:03:34)

Ja, das kommt natürlich auf die Größe vom Einsatz drauf an. Bei einem ganz großen Einsatz machen das nur irgendwelche Chef-Ebenen natürlich unter sich, weil du kannst entweder 500 Leute einladen oder so für eine Nachbesprechung. Bei einem kleineren Einsatz ist es halt einfach das Team. Also da gibt es sicher unterschiedliche Herangehensweisen. Da gibt es auch jetzt nicht irgendwie ein vorgegebenes Muster. Ich hoffe, Berufsfeuerwehren machen das etwas besser, wobei auch da ist, glaube ich, Luft nach oben. Und da würde ich fast sagen, dass die IT vielleicht schon weiter ist, auch so gerade mit dem Öffentlichmachen. Da kann die Feuerwehr, glaube ich, noch viel davon lernen, weil sehr transparent ist die Feuerwehr meiner Meinung nach noch nicht. aber ich lasse mich gern belehren wenn es vielleicht auch gerade in deutschland da kann ich mir weniger aus wenn es da bessere beispiele gibt nur her damit.

Andy Grunwald (01:03:34 - 01:05:31)

Eine frage die ich mir lange gestellt habe ist wie lernt denn jetzt eigentlich die komplette organisation von so einem postmortem weil klar die leute die beim inzident dabei waren die lernen davon weil die halt mittendrin waren und ja man hat ein postmortem dokument da ist an zehn seiten Word-Dokument, das posieren wir uns so raus. Aber mal ganz ernsthaft, wer hat denn heutzutage Zeit, zehn Seiten zu lesen während der Arbeit? Jeder ist ja immer busy. Und ihr kennt das ja, die Leute, die eigentlich von dem Postmortem lernen sollten, tun es nicht, weil sie das Dokument nicht lesen. Und die frage habe ich mal dem ehemaligen meinem ehemaligen chef dem ehemaligen cto von trivago gestellt der kater bevor er cto bei google war war er manager und software engineer bei google und er hat nämlich ein ritual von google mit nach trivago genommen was ich was ich sehr sehr cool fand und zwar, haben wir einmal pro Quartal eine sogenannte Postmortem-Konferenz gemacht. Eine Postmortem-Konferenz ist eigentlich eine Zwei-Stunden-Session. Bei Trivago hatten wir im Büro damals auch so ein kleines Kino mit so 50 Sitzen. Und in dieser Postmortem-Konferenz haben wir drei Postmortems vorgestellt, immer von verschiedenen Teams, und haben eine Präsentation gemacht, einfach ein Talk, so eine Präsentation halt, und haben den jeweiligen Inzident beschrieben aber in einer art in einer gegebenenfalls lustigen art aber auch mit was haben wir daraus gelernt was ging schief das bedeutet wir hatten wir hatten schöne zwei stunden jedes quartal wo die ganze firma join konnte und sich vielleicht ein bisschen bisschen bisschen lachen konnte wie wir auf die nase gefallen sind und das war glaube ich ein sehr schönes ritual wie die wie ein großteil der organisation von Postmortems und von Inzidenz lernen konnte. Fand ich super. Vielleicht könnt ihr es ja auch mal ausprobieren. Muss vielleicht nicht die ganze Firma sein. Vielleicht macht ihr es einfach nur in meinem Engineering-Department. Aber einfach mal mit ein bisschen Witz über die eigenen Fehler lachen, das hilft, glaube ich, schon ganz gut.

Wolfi Gassler (01:05:32 - 01:05:57)

Und mit so einer Postmortem-Konferenz hat man dann eben auch wieder den Kreis geschlossen, nachbesprechen, lernen, zum Vorbereiten die Brücke geschlagen. Und so ist es ein riesen Kreislauf, der sich immer wiederholt. Und man merkt ja schon, dass es eben extrem viel gibt, das sich abseits von dem eigentlichen Incident beheben, abspielt, also von der Problemhebung abspielt, rund um den ganzen Kreis, den wir da jetzt besprochen haben.

Andy Grunwald (01:05:57 - 01:06:28)

Zum professionellen Incident Management gehört natürlich noch eine ganze Menge, die wir halt, so Sachen, die wir noch nicht besprochen haben. Wir sind gar nicht so richtig tief auf Runbooks eingegangen, auf das Training eurer Belegschaft, wie verhält man sich in verschiedenen Situationen, wie zum Beispiel einfach mal ruhig bleiben und vorher mal Kaffee holen oder was für Qualifikationen braucht eigentlich ein Incident Commander, weil nicht jeder sollte Incident Commander sein. Man muss ein paar Regeln befolgen, um die ganze Sache sauber über die Bühne zu kriegen.

Wolfi Gassler (01:06:28 - 01:06:38)

Wenn ihr da aber irgendwo gerne mehr hören wollt oder eine ganz spezielle Frage habt, bitte nur her damit, dann versuchen wir das natürlich in den nächsten Episoden auch dementsprechend zu behandeln.

Andy Grunwald (01:06:38 - 01:08:46)

Jetzt haben wir natürlich am Anfang gesagt, Wolfgang, wo sind denn da die Parallelen zwischen Incident Management in der IT und der Feuerwehr? Und das war auch nicht gelogen weil in der tat ich kannte die details wie jetzt eine lokale freiwillige oder berufsfeuerwehr agiert jetzt nicht dennoch wusste ich dass professionelles incident management in der it eigentlich aus methoden von der feuerwehr genommen wurden und zwar gibt es einen sehr sehr gutes buch das nennt sich incident management for operations das wurde von feuerwehrleuten geschrieben von feuerwehrleuten und it leuten und zwar erzählt das auch mal ein bisschen über die historie und zwar gab es 2012 in san francisco eine kleine konferenz eine kleine konferenz die haben da haben sich ein paar leute so zu 10 12 stück in einem loft getroffen und haben einfach mal gegrillt und einfach mal gequatscht Und zwar haben sich da ein paar Leute von Fastly, von Twitter, von Facebook, von Microsoft getroffen und haben dann drei Leute von der professionellen Feuerwehr aus Kalifornien eingeladen, die dann sehr viel mit den Waldbränden zu tun haben. Und das ganze Event hieß Web Ops Fire Ops. Und den Namen finde ich sehr, sehr schön. Und nämlich haben die Leute, die halt die großen Social Networks da betrieben haben, sich da einfach mit professionellen Feuerwehrleuten unterhalten. um genau diese Parallelen zwischen Incident Management und Feuerwehr der einen Seite zu entdecken, aber natürlich auch um primär das Incident Management von Large-Scale-IT-Systemen deutlich zu verbessern. Und diese ganze Sache wurde dann damals auf der Velocity-Konferenz auch vorgetragen und seitdem hat sich das einfach so entwickelt. Die ganzen Methoden, die moderne IT-Systeme und modernes Incident Management in der IT anwenden, kommen also eigentlich unter anderem aus dem Krisenstab und aus dem Krisenprozedere zur Waldbrandbekämpfung unter anderem in Kalifornien. Und die Abkürzung bedeutet Initial Management System, IMS, wenn man da mal ein bisschen googelt, können wir auch in den Show Notes verlinken, dann findet man da die Ursprungsdokumente aus den 70ern und Co. Also sehr, sehr spannende Geschichte.

Wolfi Gassler (01:08:47 - 01:09:32)

Jetzt muss ich ja leider, obwohl ich ja wie gesagt Pazifist bin, dazu sagen, dass auch die Feuerwehr fast alle Sachen aus dem militärischen Bereich geholt hat, weil die halt einfach dementsprechend mit extrem vielen Leuten und großen Operationen zu tun haben und dann natürlich auch schon einiges optimiert haben in den letzten Jahrhunderten höchstwahrscheinlich und dementsprechend die Feuerwehr natürlich auch viel übernommen hat. Wirkt die Feuerwehr auch teilweise sehr militärisch, obwohl da natürlich dann neue Elemente dazugekommen sind. Und ich glaube, jetzt ist halt so der nächste Schritt die Übernahme in die IT und die IT hat halt dann auch ihre neuen Elemente dazugenommen, zum Beispiel eben, dass man auch transparenter mit der ganzen Sache umgeht und Postmortems zum Beispiel auch öffentlich stellt, was jetzt bei der Feuerwehr zum Beispiel weniger der Fall ist.

Andy Grunwald (01:09:32 - 01:10:19)

Bei den ganzen Punkten, die wir besprochen haben, die haben wir natürlich nur High-Level besprochen. Im Detail liegt natürlich wie immer der Teufel. Wie zum Beispiel, wie macht man denn effiziente Kommunikation? Welche Sachen sollte man in dem Status-Update haben, welche nicht? Wie sieht sowas bei Large-Scale-Incidents aus, die über mehrere Teams, mehrere geografische Regionen, mehrere Tage oder Wochen laufen? Das sind alles Dinge, wo sich dann der eigentliche Prozess gegebenenfalls aufsplittet. Wie gesagt, wenn ihr dazu auch mal mehr hören wollt, schreibt uns doch mal bitte eure Wünsche an stetisch at engineeringkiosk.dev oder über Twitter an ENG Kiosk. Wir warten auf euer Feedback und wir hoffen auch, dass euch diese Folge wieder mal gefallen hat.

Wolfi Gassler (01:10:20 - 01:10:40)

Und wir wollen natürlich auch unbedingt diese statistisch gesehen mindestens zehn Hörerinnen herausfiltern, die bei der Feuerwehr sind oder beim technischen Hilfswerk. Also bitte lasst uns das auch wissen. Würde uns wirklich interessieren, ob die Statistik bei uns auch zutrifft, dass zwei Prozent unserer Hörerschaft bei der Feuerwehr in irgendeiner Form tätig ist oder technisches Hilfswerk.

Andy Grunwald (01:10:40 - 01:10:51)

In den Show Notes verlinken wir auch ein paar interessante Postmortems von Firmen, damit ihr mal ein Gefühl davor bekommt, wie so ein Dokument mal aussehen könnte. Ansonsten vielen Dank fürs Zuhören und noch einen schönen Tag.

Wolfi Gassler (01:10:51 - 01:11:00)

Bis nächste Woche, ciao. Was muss ich sagen, ich hab nicht zugehört.