Ja, hi, ich bin Chris und ich mache dieses Computer-Ding jetzt seit 0x20 Jahren, das heißt, ich bin offiziell alter Sack.

Ich soll was über DevOps erzählen, hat man mich von einem halben Jahr gebeten, zu einem anderen Anlass und den Talk dann hier auch nochmal platziert. Es geht darum, dass das eine Kultur ist, die sich in Unternehmen oder überhaupt beim Umgang mit Rechnern entwickelt hat. Und zwar unter dem Einfluss von einer ganzen Menge Sachen, die das geformt oder gemacht haben.

Wir müssen einmal über Märkte reden, also speziell über den IT-Markt, wie er sich so langsam entwickelt hat. Das links, das ist ein sogenanntes Carnivian-Diagramm und wenn wir uns IT angucken, so vor dem Dotcom-Boom, 98 oder sowas, dann sind wir ganz klar hier im Bereich Chaotik,

wo alles relativ unstrukturiert ist und wo es nicht mal ein Business-Modell gab, wo die Leute also alle möglichen Sachen irgendwie ins Netz geworfen haben, dass es ganz neu gab und dann geguckt haben, was dann irgendwie funktioniert. Die Sachen, die funktioniert haben, wir sind jetzt ungefähr bei 2000 oder so,

da hat man dann sich überhaupt überlegt, wie betreiben wir denn jetzt mit mal IT, die größer ist als eine Firma, wo man also nicht 1000 User hat, sondern 10, 100, 1000 Millionen oder gar mehrere Millionen User. Was sind funktionierende Architekturen, was sind funktionierende Best Practices und all solche Sachen. Aus dieser Zeit hat sich dann so verschiedenes Zeug entwickelt, es haben sich dann Best Practices entwickelt,

aber es gab noch keine Metriken zum Beispiel und inzwischen sind wir auch soweit, dass wir ein voll entwickeltes Modell haben und wir haben auch volle Prozessreife erreicht. Das heißt, es gibt auch Metriken, Verwässerungsprozesse und alles Mögliche andere, was dazugehört.

Es gibt da, wenn man sich das anguckt, bei der Prozessreife das sogenannte CMMI, das Capability Maturity Model und an dieser Stelle gibt es einen großen Übergang, nämlich der zwischen qualitativen Metriken oder überhaupt keine zu haben und hier, wo man Zahlen hat. Wenn man was outsourced, dann geht es nur, wenn man über Prozessreife Level 4 ist,

also wenn es Metriken gibt, weil vorher weiß man gar nicht, was der Dienstleister, an dem man outsourced, verkauft und wie man messen kann, ob er die gekaufte Leistung auch überhaupt erbringt. Das heißt, wenn man, was weiß ich, 95 oder so auf der Ecke mit der Landesbank zu tun hat,

die ihre IT outsourced hat, an irgendein Unternehmen, dann sitzt man laufend in irgendwelchen Krisenmeetings, wo die Leute sich gegenseitig beschuldigen, nee, du tust nicht, was ich gekauft habe, doch, wir haben doch das und das gemacht und das kann halt nicht funktionieren, wenn es keine definierten Prozesse gibt, keine definierten Erfolgsmetriken und Zahlen, die man dann einfach nebeneinander hält und dann ist alles klar,

sondern gibt es halt eine Reihe von Fingerpointing und Streit. Zahlen kann man überhaupt nur kriegen, wenn man einen Prozess mehrfach ausführt. Also das heißt, im ersten Jahr kann man vielleicht Basiszahlen ermitteln oder bei den ersten paar Iterationen, aber Zahlen und Verbesserungen oder Veränderungen kann man überhaupt nur messen,

wenn Dinge mehrfach ausgeführt werden und wenn die Bedingungen dabei vergleichbar sind. Wenn man also in einem Unternehmen arbeitet, das in sechs Jahren um den Faktor 100 wächst, dann sind die Deliverables zwar immer dieselben jedes Jahr, Hotelräume an die Leute bringen, dafür sorgen, dass die Hotels die Leute tatsächlich da benachten lassen und hinterher Kundenreviews und Fotos und so ein Kram einsammeln,

aber die Scale, auf der das läuft, ist halt alle drei Jahre um den Faktor 10 verschieden und das heißt, obwohl die Deliverables überall dieselben sind, sind die Dinge oder die Prozesse oder die Maschinerie, mit der das erreicht wird, jedes Jahr oder spätestens jedes zweite Jahr vollkommen anders. Das heißt, man kommt, egal wie gut man bei Prozess oder Betriebsorganisation ist,

niemals hier rüber in diese Richtung kann, also nicht viel outsourcing, sondern muss alles selber und custom machen, weil bis man überhaupt einen Dienstleister verklickert hat, worum das geht, hat sich das Problem selber schon so verändert und mutiert, dass man wieder von vorne anfangen kann. Wir haben etwas ähnliches erlebt in der Zeit um 2002, 2003 herum.

Da vorher hat man in Enterprise IT und dann auch in Web IT versucht, hoch zu skalieren, indem man größere Maschinen gekauft hat. Das da ist, ich glaube, das ist ein 15K im Sun Performance Benchmark Center in Langen. Ich habe die zwölfte Enterprise 10.000 von Hamburg nach Büdelsdorf

zum Mobilcom gefahren, um die Zeit rum und drei Jahre später lief von den zwölf Enterprise 10.000en keine mehr. Stattdessen standen da Shaves voll, ein HE und zwei HE-Kisten. Das heißt, statt scale up, also kauf mir eine größere Schachtel,

hat sich alles verändert hin zu scale out. Also stellen wir einfach viel mehr Schachteln hin. 1.000, 10.000, 100.000 oder gar Millionen von Computern in einem oder mehreren Data Centers sind etwas, das inzwischen ein gut verstandenes Geschäft ist.

Wenn man viele Rechner hat, dann müssen sich die Werkzeuge verändern. Insbesondere kann man nicht mehr, wie das so üblich ist, mit SSH auf einen Rechner klettern. Wenn man das doch machen muss, warum auch immer,

dann kann man gleich ein Ticket aufmachen. Wenn man auf einen Rechner klettern muss, um was nachzugucken, ist offensichtlich das Monitoring kaputt. Wenn man auf einen Rechner klettern muss, um gar was zu verändern, dann ist offensichtlich die Automatisierung kaputt. Und vermutlich, hoffentlich, nicht nur diese eine Kiste kaputt, sondern alle anderen auch, und zwar hoffentlich gleich. Das heißt, man muss Mechanismen und Prozesse entwickeln,

mit denen man solche Sachen automatisieren kann, mit denen man Systemadministrationen automatisieren kann. Dann bekommt man irgendetwas, Puppet Chef, Ansible Salt oder was auch immer, das eine Systemkonfiguration beschreibt. Und dann fährt man sich ein paar Kisten hoch, echte oder virtuelle,

mit einem abgebranchten Teil von dem, was kaputt ist, verifiziert, dass es wirklich kaputt ist. Dann fixt man das Ganze irgendwie, fährt den ganzen Mist wieder hoch, guckt, dass es heil ist, und dann mötscht man den Kram rein und rollt es dann erst auf eine kleine Menge von Maschinen und dann auf alle anderen aus. Und dann repariert sich das hoffentlich flott und weit.

Hoffentlich heißt, Hoffnung ist keine Strategie, dass man sich überlegen muss, dass es wahrscheinlich irgendwo ein paar Stragglers oder Fails geben wird und dass man die finden und erkennen muss und dass man die aus der Flotte schießen muss. Und sich dann anguckt, warum es da gefailt hat.

Ist das ein systematischer Fehler? Also war mein Fix nicht richtig? Ist das ein systematischer Fehler? Also sind einige dieser Maschinen etwa besonders, und ich habe gedacht, die sind wie alle anderen, ist das ein systematischer Fehler? Sind diese Maschinen etwa anders, weil mit denen früher mal was anders gemacht worden ist? Oder es ist einfach nur kosmische Strahlung gewesen? Man wird dann feststellen, dass, wenn man das tatsächlich nachguckt,

kosmische Strahlung in der Tat extrem selten ist, aber vorkommt. Wenn man Suns bei Dräger hinstellt und da dann Alpha-Strahler in der Produktion eingesetzt werden, weil Gasmasken oder ähnliche Sachen getestet werden müssen, dann kommt das zu erstaunlich vielen Rahmenfehlern.

Der Punkt ist jedenfalls, dass man da hin muss. Das heißt, man fängt an, Sachen reproduzierbar zu machen, indem man sie automatisiert. Wenn man sie reproduzierbar hat zu einem Grad, dass präzise null manuelle Eingriffe notwendig sind, das heißt, wenn es nicht mehr durch eine Person gefiltert werden muss, die ja alle Ereignisse böse realisiert, dann werden Sachen auch parallelisierbar.

Und dann kommt man irgendwann zu dem Punkt, wo man Sachen orchestrieren muss, das heißt, wo man mit Puppet z.B. hart gegen die Wand läuft, weil Puppet etwas ist, dass eine Maschine administriert, aber man plötzlich Abhängigkeiten hat. Der Cluster ist erst oben, wenn drei von meinen fünf sich da irgendwie quorumifiziert haben. Und wenn man versucht, so was mit Puppet zu beschreiben, dann merkt man erst einmal, wie zwangsjackig das ist

und dass man dringend was anderes braucht. Und dann stellt man fest, es gibt gar nichts. Aber das ist ein anderer Talk für eine andere Konferenz. Neben diesen ganzen technischen Veränderungen und technischen Breppern braucht man auch irgendwie eine passende Kultur dazu.

Danke übrigens, Anche. Das ist sehr nützlich mitunter. Das ist hier ein Sinnbild für das, was in einer News Group, die es früher gab, die als SysAdmin Recovery so gängige Jokes waren, das ist ein Lard,

also was zum User ziehen. Und ein paar leckere Kekse. Die Kekse für den SysAdmin, der Lard für die Loser. Und das ist zwar mitunter recht angenehm zu lesen, aber als mentales Modell ist das sehr giftig. Das ist einer der Gründe, warum ich zum Beispiel nie auf Kanossa oder Kanossa Parties war.

Daran ist diese Person schuld. Das ist Tom Lim und Shelley. Der hat da ein Buch geschrieben, das hieß The Practice of System Administration, später dann of System Network Administration, weil es einzelnstehende Rechner gar nicht mehr gibt. Und dieses Buch hatte im vorderen Teil einen Haufen Technik. Und das war das erste Buch, das ich gelesen habe

über System Administration, das im hinteren Teil, so Kapitel 5 und 6, was über den Beruf des System Administrators erzählt hat. Also weswegen bist du überhaupt in dieser Firma? Was ist deine Aufgabe in der Firma? Nein, was ist erstmal die Aufgabe von der Firma? Und wie stellt sich die Aufgabe der Firma in deinem Leben dar? Also wie musst du mit den Leuten, also deinen Kunden

und deinen Chefs reden, damit du von deinen Chefs Geld bekommst, um Spielzeug zu kaufen? Und was musst du machen mit deinen Kunden, und das ist nicht Larten, damit sie dir nicht mehr auf den Sack gehen. Damit war der Limoncelli seinerzeit um bestimmt sieben oder acht Jahre voraus. Das ist Booking 2008.

Der Begriff DevOps kommt aus Belgien von Patrick Dubois. Und 2008 bei Booking, das ist Dennis, mit dem Bookinglad zu dieser Zeit. Dennis hat sich das ganze DevOps Zeug sehr zu Herzen genommen, dieses Ding dann auch an den Nagel gehängt. Das hat also keine weiteren Einsätze mehr gesehen.

Mario ist bei seinen Komits auch vorsichtiger geworden. Nein, nein, das hat nicht gewirkt. Und seit 2008 gibt es das Wort DevOps, aber das Konzept ist wie gesagt viel älter. Die grundsätzlichen Ideen, die kommen eigentlich schon früher zum Beispiel in den Büchern

von Tim Limoncelli vor. DevOps ist auch irgendwie so agil, und damit irgendwie wahrscheinlich das Gegenteil von ITIL. Das ist so ein bisschen wie scale up zu scale out oder sowas in der Art. Jedenfalls ist DevOps, wenn man es sich anguckt, eher eine Bewegung, die von unten herkommt,

also die mit den Leuten arbeitet, während ITIL, wenn man es sich anguckt, meistens ein Prozess ist, der irgendwie von oben, also von der Management-Seite her initiiert wird. Wir werden sehen, dass das auch nicht ganz richtig ist. Vernünftige DevOps-Geschichten kriegt man ohne C-Level Management-Unterstützung auch nicht sinnvoll hin. Die Grundidee ist, die Mauer einzureißen.

Das Foto ist von Thomas Rössler von 1989. Das heißt, das muss also ein paar Monate vor dem versäglichen Mauerfall gemacht worden sein. Da bin ich gerade von C64 auf Amiga umgeschrieben. Wenn man die Mauer niederreißt, dann heißt das auch, dass man die Devs,

also die Entwickler und die Ops, also die Betriebsleute, zusammensetzt und zusammenarbeiten lässt und hoffentlich auch selbe oder ähnliche Methodiken oder Werkzeuge verwenden lässt. Daher kommt dieser Spruch, der Untertitel dieses Talks ist. There is no such thing as a DevOps-Team. Wenn man ein DevOps-Team macht,

dann hat man wieder einen weiteren dritten Bunker neben DevOps geschaffen, der mit den anderen nicht redet. Das heißt, wenn wir eine moderne Produktionsumgebung haben, womöglich virtualisiert, dann haben wir automatisierte Infrastruktur, also Heat-Skripte oder Dockerfiles oder ähnliches Zeug, Infrastruktur als Code,

mit dem wir Zeugs deployen können. Wenn das Ganze jetzt noch 16 zu 9 geblieben wäre, dann würde man das sogar lesen können. Das heißt, wir erzeugen Systeme aus Skripten auf irgendeine Art und Weise. Wir haben dann ein gemeinsames Code-Repository, in dem alles drin ist. Oder, wenn wir sehr arm dran sind, dann gibt es viele Repositories,

in denen dann in unterschiedlichen Versionen aus unterschiedlichen Repositories Sachen zu importieren sind. Wir haben dann irgendwie eine automatisierte Deployphase, die den ganzen Kram in die Produktion reindrückt. Das ist ganz wichtig. Wir haben Deployment von Code und Activation von Code getrennt.

Das heißt, ich kann Code ausrollen, ohne dass er ausgeführt wird. Und dann probiere ich ihn in der Produktion einmal aus mit einem Feature-Flag, so für mich. Oh ja, es ist nichts hintergebrannt. Dann probiere ich ihn für 5% aller User mit einem User-Agent Strik McIntosh und einem Herkunftsland GOIP Japan aus. Und stelle fest, es ist immer noch keine Bewegung

auf dem Error-Log. Und dann gehe ich langsam hoch und gucke, was zum Beispiel mit der Conversion ist. Also kaufen die Leute meine Hotelräume noch. Oder ähnliches Zeug. Und dadurch kann ich, wenn ich Deploy und Activation getrennt habe, Code, der nicht so günstige Ergebnisse hat, auch relativ schnell und ohne großen Aufwand still liegen.

Und mir dann überlegen, ob und wie ich ihn wieder aus der Produktion rausgeprökelt oder durch was weniger kaputtes Ersatz bekomme. Das heißt, diese ganze Feature-Flag, Graceful Dragonation-Sache, ist wichtig. Ich muss außerdem testen und messen. Das heißt, ich muss erkennen können, ob ich irgendwie eine Krise habe.

Ich kann keinen Rollout machen, wenn mein Monitoring mehr als 15 Sekunden laggt. Ich kann kein Testing in Production machen, wenn mein Monitoring-System zu viel laggt hinterher. Weil ich, bis ich mitkriege, dass die Bude brennt, ich wahrscheinlich schon niedergebrannt bin. Und deswegen brauche ich ein schnelles und zuverlässiges Monitoring.

Und dann, das kann man hier nicht sehen, ich brauche dann ein, das ist gerade beim Folien auf 4 zu 3 umstellen kaputt gegangen, ich brauche dann irgendein internes Kommunikationssystem, mit dem ich Hilfe zusammenrufen kann, wenn die Bude dann doch mal brennt. Das heißt, ich brauche irgendeinen Jabber-Server-Channel oder irgendwas anderes.

Und vor allen Dingen muss ich die Leute kennen vorher, denen ich dann traue, in so einer Krise meinen Arsch zu retten. Darum ist es halt sehr wichtig, dass man nicht Abteilungen kennt. Ich brauche einen DBA, sondern der AV-Master ist da und ich brauche Simon. Oder sowas in der Art.

Jetzt brauche ich jemanden, aber weiß keine Namen. Das passt ja wie die Faustoforge. Vielen Dank. Wir haben auf diese Art und Weise tatsächlich Konvergenz zwischen Technologie und Kultur,

weil die Leute in Betrieb und die Leute in der Entwicklung dieselben Tools verwenden. Wir skripten alles, wir zentralisieren das Monitoring und alle arbeiten mit demselben View auf die Systeme. Wir haben die Systemadministrationswerkzeuge, die wir brauchen, schon an der Entwicklungsphase eingebaut in das Ganze.

Wir haben, wie gesagt, Entwickler und Admins, die dieselben Tools benutzen. Und ja, alles wird gut. Und dann, wenn wir die Leute auch noch zusammensetzen, dann können wir das Ganze auch mit einem gemeinsamen Namen benennen. Dann ist es halt der Forbes. Die Frage ist,

warum, wenn wir das alles gemacht haben, warum kriegen die sich alle trotzdem noch in die Haare? Also was ist der Unterschied, mit dem es dann trotzdem noch zu Konflikten kommt, wenn sie denn alle das selbe machen? Der Grund für die Konflikte, die dann noch entstehen, ist, dass die Leute verschiedene Erfolgsmetriken haben. Also Entwickler sind

Leute, bei denen ... Ihr lacht, das ist wirklich so, Die machen ihren Scrum, das ist so drei Wochen und dann eine Woche Aufräumen oder so was. Timebox, was in der Zeit fertig ist,

das sind user-sichtbare Features. Was nicht fertig geworden ist, kommt aus Backlog, wird neu kriorisiert und beim nächsten Scrum läuft es dann durch oder was anderes. Und am Ende vom Scrum ist die große Abnahmefeier, da laufen alle auf den Rasen, das ist hier in Karlsruhe. Also in Durlach, bei web.de, der Park hinten, der sieht genau so aus.

Da kugeln sie dann alle rum und oh, schön bunt, neue Features. Ja klar, aber bei Infrastruktur, also bei also kein Mensch auf der Welt hat jemand gesagt hey toll, das Licht ist angegangen, weil ich den Schalter betätigt habe. Aber

das Licht geht mal nicht an, wenn man den Schalter betätigt. Dann ist Krise. Also Infrastruktur, Betrieb, Operations hat eine andere Erfolgsmetrik. Die werden nicht an tollen neuen Features gemessen, sondern die werden an Fehlschlägen gemessen. Das ist das, was zählt. Das heißt, der Mindset bei Operations ist, wir gehen rein,

die Mission wird ausgeführt, es wird niemand zurückgelassen. Ihr seht, dass die alle Webcams oben am Helm haben. Und dann wird exfiltriert und nur wenn die Mission ausgeführt ist, dann wird die nächste Mission angemessen. Das heißt, die machen eher Anbahn als Scrum. Die werden ganz anders bewertet an ihren Fehlschlägen und nicht an

ihren Erfolgen als Entwickler. Und haben entsprechend auch eine ganz andere Optik, einen ganz anderen Mindset, eine ganz andere Denkweise. Bei Booking ist noch ganz was komisches passiert. Booking hat bestimmte Regeln in

jeden Entwicklerkopf reingeprügelt. Das sind die zwei Regeln. Wenn du es kaputt machst, kriegst du es überhaupt mit. Wenn nicht, hast du in der Produktion nichts verloren. Also wenn du nicht die Metriken kennst, an denen du gucken kannst, ob dein Code erfolgreich ist, funktioniert, dann musst du dich mal damit auseinandersetzen, was du an System

da unter dem Messer hast und darüber lernen. Das ist okay. Booking bringt den Leuten das da. Booking bei. Booking unterscheidet sehr hart zwischen Sachwissen. Du kommst von der Uni und weißt alles über Algorithmen. Also Fachwissen. Und Sachwissen halt. Du bist bei Booking. Und da machen wir so, weil die anderen drei Möglichkeiten, die es gibt,

funktionieren für uns nicht. Das heißt, neben der Ausbildung, die man mitbringt und die man haben muss, gibt es noch die Ausbildung, die man da vor Ort bekommt und die die spezifischen Entscheidungen, die sich aus der Geschichte ergeben haben und Erfahrungen, die die Firma gemacht hat, den Leuten beibringt, damit sie da reinpassen. Und das Zweite ist dann if you break it, can you fix it? Und wenn nicht,

also wenn du es nicht heil machen kannst, nachdem es kaputt gespielt hat, wer kann deinen Arsch retten? Welche Person kann deinen Arsch retten? Das ist wichtig, weil irgendein DBA wird dir nicht helfen können, aber Simon wird es vielleicht können oder was weiß ich, irgendjemand anders. Oder beim Netzwerk genauso. Du musst die Namen kennen und zu den Leuten entkriegen.

Das ist ein ziemlicher Hack, weil das sind Regeln, die mit Fehlschlägen, das zum Beispiel ist ein Fehlschlag hier, die mit Fehlschlägen umgehen. das ist aber in Entwicklergirirne reingeprügelt worden, die ja eigentlich Feature-Entwicklung machen sollen und nicht Infrastruktur.

Das heißt, man muss die Leute dazu bringen, sich zu überlegen, was der worst case ist. Und das andere sind nur nette Nebeneffekte bei der ganzen Geschichte. Das ist eine Diskussionskultur zum Beispiel, die man an bestimmten Orten viel mehr findet als ein andere. Die Linus Kernemailing Liste zum

Beispiel ist etwas, das eine sehr herzliche Umgangskultur hat. Wenn ich einen Patch an die Linus Kernemailing Liste schicke, dann fragen die Leute nicht, was wird jetzt besser mit deinem Patch? Die fragen erstmal ja, was macht denn das im schlimmsten Fall? Also was passiert, wenn alles explodiert? Welche Farbe hat der Rauch dann jetzt mit deinem Patch?

Und ist das besser als vorher? Das ist nicht leicht zu verstehen für einen Feature-Entwickler. Man hat also laufend Leute, die irgendwie Zeugs an die Linus Kernemailing Liste schicken und sich dann wundern, warum sie da so negativ empfangen werden. Das ist nicht negativ, sondern das ist der Code of Conflict, den es jetzt beim

Kernedokumentationsdirektor gibt. Und der erklärt ziemlich gut, was da passiert. Im ersten Absatz oben steht, wir sind Infrastruktur-Leute und wir interessieren uns dafür, was du alles schlimmer machst oder wie sich die Schlimmheit verändert durch deine ganze Patcherei. Und das musst du aushalten. Der zweite Absatz, der erklärt dann, was du nicht aushalten

musst, ist, wenn jemand dich als Person antöbelt, aus welchem Grund auch immer. Da ist die Grenze. Ich finde, das erklärt es ziemlich schlecht, weil genau das nicht gesagt wird, sondern da ziemlich drumrum getanzt wird. Aber mit dem vorher Gesagten wird das eigentlich ziemlich klar, was die versuchen da zu machen und warum sie das machen. Das ist relativ leicht. Wer von euch zum Beispiel

erinnert sich daran? Oder war gar dabei? Das ist jetzt 14 Jahre her und da erinnern sich noch Leute dran. Oder das hier. Das ist jetzt 10 Jahre her. Da habe ich drei Klimaanlagen verloren und dann ganz Web.de abgeschaltet.

An einem Freitag um 8 mit drei besoffenen Süßadminen, von denen einer bereits gekündigt hatte und seinen Abschied gefeiert hat. Und Samstag Mittag, also um 8 war aus, um 10 haben Kunden nichts mehr gemerkt davon. Da waren wir notdürftig wieder online.

Und Samstagmittag war volle Redondanz wieder hergestellt und die Klimaanlage lief manuell. Mach aus, mach aus. Wir haben null Kühlleistung. Alles ausgemacht. Der Plan war, alles, was eine HE hat abzuschalten. Weil alles, was zwei HE oder mehr hat, hat Platten. Das sollte sauber runtergefahren

werden. Alles, was eine HE hat, da kann man einfach die Stecker ziehen. Dummerweise sind Switches auch eine HE und dann war nichts mehr mit dem sauber runtergefahren. Aber in so einer Situation einem dazugezogenen Heptisk-Mitarbeiter den Unterschied

zwischen dem Switch und dem Server zu erklären, war nicht mehr drin. Da musste man dann ein bisschen improvisieren. Naja. Und dann als alles aus war, kamen die Leute, die die Klimaanlage inzwischen versucht haben zu retten, sagten, wir haben hier eine manuelle Steuerung und wir kommen nicht unter 200.000 Watt Kühlleistung. Das heißt, ich brauche jetzt 200.000

Watt Abwärme oder mir friert alles ein. Da haben wir den ganzen Scheiß wieder angeschaltet. Ziemlich schnell. Und erstmal nicht rinundant. Hauptsache, der Mist läuft. Viele Süßatmend sind sehr, sehr konservative Personen. Die stehen Veränderungen erstmal

abwährend gegenüber. Wieso läuft doch? Und Entwickler sind halt eher progressive Personen. Ja, der neue geile Code hat viel Feature. Wo wir jetzt mal raus. Tatsächlich hat Booking die Erfahrung gemacht, dass schnelle und häufige Rollouts besser sind als seltene. Booking hat ein

einziges großes Repository. Da haben wir gerade oben vor einer Stunde beim PHP- Raum einen sehr schönen Talk zugehört von Benjamin Eberleih. Und Booking rollt tatsächlich so acht bis zehnmal am Tag oder noch öfter dieses Repo aus. Was läuft in der Produktion? Das meistens irgendwie Head. Also direkt der Master-Branche. Aber

Rollout und Activation sind halt getrennt. Das heißt der Code, der draußen liegt auf den Produktion-Servern, ist nicht unbedingt der, der ausgeführt wird, wenn du da irgendwo draufklickst. Und dann gibt es ein paar Subsysteme bei Booking. Zum Beispiel das Buchungssystem im Vergleich zum Browsing-System. Das Browsing-System

da kann man sich an Hotel-Räumen aussuchen. Beim Buchungssystem macht man tatsächlich eine Buchung. Und der ganze Bookcode, weil der unter PCI-Compliance und sonst wie steht, der wird wesentlich seltener ausgerollt. Und das führt zu allerlei Problemen, weil sich halt solche Changes akkumulieren und das am Ende sehr, sehr schwierig ist, rauszufinden, welcher von den 1200 Patches, der da drin ist, denn jetzt schimmelig ist.

Sodass es inzwischen so ist, dass auch der Bookcode häufiger ausgerollt wird. Einfach, damit der Changeset kleiner ist, damit man die Fehler schneller findet, die man untenrum irgendwie mit einschleppt. Ich habe für Booking irgendwann mal eine für eine interne Entwicklerkonferenz ein paar Slides vorbereitet. Und

da habe ich unter anderem erzählt, dass es Firmen gibt, die irgendwie komplizierte Change Management Prozesse haben, mit denen man Changes besser verwalten kann. Das tut Booking eher nicht, weil es nichts hilft. Das sind die Original Slides, die ich damals hatte. Booking hat tatsächlich ein Budget für Downtime. Das heißt,

wenn man bei Booking irgendwie in der IT sitzt, dann kann man nicht vermeiden, auf mindestens einen Monitor zu gucken, bei dem man so eine Kurve sieht über die Zeit. Also das ist die Zeitachse. Und das ist eine Euro-Achse. Und immer wenn da so ein orangener senkrechter Blip ist, dann ist also irgendwie ein Configuration Change gemacht worden. Immer wenn da ein senkrechter

lilaner Blip ist, dann ist ein Rollout gemacht worden. Und wenn nach so einem orange Blip die aktuelle Euro-Linie irgendwie so abstürzt, dann sollte man sich vielleicht mal mit dem Gedanken beschäftigen, dass der letzte Change nicht so gut war, und sich überlegen, wie man da wieder rauskommt. Das ist weniger schlimm, als man denkt, weil

Booking halt Zahlen hat für den erwarteten Umsatz, basierend auf gestern und der letzten Woche und dem letzten Jahr, skaliert mit dem year on year growth und solchen Sachen. Und eine Mimik hat, mit der Sie feststellen können, wie viel Euro Sie denn gerade verlieren, indem Sie die Prognose und die tatsächlichen Einnahmen, also das Integral berechnen

zwischen diesen beiden Kurven. Und dafür haben Sie ein Budget. Das heißt, Management hat Controls, die sagen, der Prozess Testing in Production funktioniert, wenn wir weniger als so und so viel 100.000 Euro im Monat an entgangenen Einnahmen haben. Was die Firma dann haben möchte, ist

ein Text, der hat die Überschrift RFO, Reasons for Outage, und dann steht da drin, was die Firma für dieses Geld bekommen hat, an neuem Wissen. Das heißt, ein guter Fail ist einer, bei dem die Firma was gelernt hat und dann die Prozesse verbessert hat. Ja, das Ganze macht man, indem man sich hinsetzt und sich dann analysiert, was da passiert ist, mit so einer Timeline.

Wann haben wir was gemerkt? Wann ist es tatsächlich passiert, aufgrund der Messdaten, die wir haben? An welcher Stelle sind unsere Prozesse verbesserungswürdig, dass das nicht wieder passiert? Oder unsere Technik verbesserungswürdig? Das Ganze gibt es zum Nachlesen unter der Überschrift Blameless Postmortem an vielen Stellen im Web. Und es gibt neben Booking noch einen Haufen weiterer Firmen, die das machen.

Die Idee, die dahinter steht, ist Case Colen, der alte CEO von Booking, ist so ein Motorradrennfahrer, der fährt die Rallye Dakar und ähnliche Geschichten. Aber das Konzept, dass er da predigt, kommt eigentlich aus dem Fallschirmspringen, das heißt Carefull Carelessness.

Die meisten Leute sehen den Careless Part, also wir springen aus der offenen Tür von einem Flugzeug, unter uns 4000 Meter nichts. Man muss da schon ein bisschen Carefull machen, damit man das mehr als einmal tun kann. Das heißt, ich will aus der Tür von einem Flugzeug springen, aber ich muss ein paar Dinge haben und

können, damit das wiederholbar ist. Ich muss die Ausbildung haben, ich muss Leute haben, Personen, Individuen kennen, denen ich trauen kann. Ich hab meinen Fallschirm, der von mir gepackt wird und von jemand anders kontrolliert wird. Ich hab die Reserve, die von jemand anders gepackt wird und von mir kontrolliert wird.

Und wenn ich irgendwie was fischig finde oder mir nicht wohl ist oder mir die Nase vom Piloten nicht gefällt oder was auch immer, dann spring ich halt nicht oder roll halt nicht aus. Und das ist das, was Booking macht im Prinzip. Das heißt, wir wollen einen Rollout überleben. Das Konzept heißt Survivability.

Und wir wollen das mehr als einmal tun. Wir wollen das eigentlich oft pro Tag sogar können. Und damit das funktioniert, müssen wir es überlebbar machen. Wir müssen unsere Systeme so bauen, dass Fehler überlebbar werden. Wir müssen unsere Prozesse so bauen, dass Fehler überlebbar werden. Und wir müssen

hinterher davon gehen können und die Geschichten erzählen können, damit die anderen das nicht nochmal ausprobieren müssen, sondern sich neu aufregende Dinge überlegen können, wie man stattdessen auf die Nase fallen kann. Ja. Und das geht halt nur, wenn man die ganze Geschichte überlebt und hinterher eine tolle Story hat. Das heißt,

wir machen das so. Das heißt, wir müssen uns auf Tests konzentrieren. Die besten Tests sind so realistisch als möglich. Das heißt, wenn wir unsere Systeme so bauen können, dass Fehler in der Produktion überlebbar werden, dann können wir auch in der Produktion testen. Und dann kriegen wir richtige echte Daten. Jeden Mittwoch

ab neun oder so testet Booking in Produktion die Kapazität der Systeme. Das geht bis Mittags ungefähr. Das heißt, die eingehende Load wird durch die Load Balancer auf immer weniger und weniger Frontend-Systeme konzentriert. Oder die Database Load Balancer konzentrieren die eingehenden SQL-Querys auf immer weniger und weniger Datenbanken. Und dann gucken wir mal an, wie sich die Last auf

diesen Systemen verändert. Und ab welcher Stelle irgendwie Rauch aus den Servern kommt. Und wenn dann so die Latenzen in dieser Hockey-Kurve nach oben gehen, weil wir Sättigung erreichen und die ersten Arrows kommen, dann wissen wir auch zum Beispiel, ist das Problem Memory oder CPU? Sind es die Datenbanken oder die Frontends?

Oder andere Komponenten, die überlastet werden? Das heißt, wir haben nicht irgendwelche hypothetischen Zahlen, mit denen wir skalieren können. Wir haben nicht irgendwelche hypothetischen Zahlen für unsere Kapazität. Sondern das Ganze ist ein richtiger, einfacher 3-Satz mit richtiger echter User-Last und richtigen ersten Kapazitäten. Wenn man das Ganze richtig macht, dann gibt es, was weiß ich, 3

oder 4 Arrows 500 in dem ganzen Prozess. Und wenn man dann die Kosten für eine Buchung kennt, kann man sich ausrechnen, was dieser ganze Last-Test also kostet. Aber der Erkenntnisgewinn ist klar viel, viel größer als die Kosten, die dadurch entstehen. Das heißt, I don't always test my code,

but when I do, I test it in production. Das ist genau das, was ich mache, wenn ich das mache. Also das ist kein Witz-Shirt oder Witz-Shield oder so, sondern das ist genau das, was man machen sollte, wenn man es irgendwie überlebbar machen kann. Daraus kann man die Gedanken weiterentwickeln und sich überlegen, man kann Systemadministration

auch gleich auf Gewalt umstellen. Also wenn ich eh Systeme haben muss, die ausfallsicher sind, dann müssen die das auch abkönnen, wenn ich ins Data Center runter gehe und irgendein beliebiges System, wahllos eines, ausschalte oder ein beliebiges Kabel ziehe oder sonst eine beliebige Veränderung vornehme. Und ich kenne jemanden bei Web.de, der das tatsächlich gemacht

hat. Die Person ist also dann morgens gekommen, technical director, runter ins Data Center und dann das. Das muss gehen. Ja, sonst hat man gerade einen Spoff gefunden, ist doch gut. Und genauso fahre ich Server nicht runter, sondern ich schieße sie immer

weg. Ich schalte sie nicht aus, ich ziehe immer das Kabel. Am besten noch, dass es ein schön braun out geht. Weil meine Installation das aushalten muss. Das muss vollkommen risikolos sein, sonst ist sie defekt. Und das heißt, ich teste immer in Produktion, wenn ich irgendwie kann.

Und ich habe meine Systeme so gebaut, dass sie reproduzierbar sind, dass ich also keine Kätzchen habe, mit Namen, die ich zum Tierarzt tragen muss, liebevoll pflegen, wenn sie mal krank sind. Sondern was ich brauche sind Kühe. Wenn die krank sind, werden sie in den Kopf geschossen, kommt eine neue Kuh.

Bitte? Ja. Ein Freund von mir hat halt diesen Spruch, auch als T-Shirt. Ich habe auch das T-Shirt. Nobody wants backup, everybody needs restore. Aber das stimmt gar nicht. Weil Rebuild ist voll in Ordnung. Jede Komponente, die ausfällt, jede einzelne Komponente wenigstens,

man kann das dann noch steigern, also Mehrfachfehler erlauben, die muss einfach nachschiebbar sein und dann im Rahmen von irgendeiner bekannten und getesteten MTTR als neues Ersatzsystem aufzeigen. Also eigentlich will ich gar keinen Backup. Ich brauche natürlich Backups, wenn ich State habe. State ist schwer ersetzbar. Aber alles andere, Hardware,

Maschinerie, das müssen Services sein, wo ich dann einfach nachschiebe. Also warum hauen sich trotzdem Dev und Ops noch? Wenn da auch Einigkeit besteht. Weil auch das kriegt man noch verklickert. Ops-Leute, okay,

eine Mission, voll durch automatisieren. Ja, haben wir verstanden als Dev-Leute, können wir alles mit einbeziehen. Trotzdem gibt es immer noch Krieg. Das hier ist Monaska. Das ist ein Open-Stack-Dienst, Monitoring as a Service. Das ist ein Schema, wie es aufgebaut ist. Das ist von der Website die Beschreibung. Ja, it's an Open Source, Multitenant, highly scalable,

performant, fault tolerant, Monitoring as a Service, solution that integrates and uses a REST API for high speed metrics. If you break it, can you fix it? Das heißt, kennst du dich aus? Mit Kafka, mit Storm, mit Zookeeper, mit

MySQL, mit Vagrant, mit Influx, mit Drop Wizard und mit Vertica. Das ist dein Team. Benenne die Namen, stelle jemanden einen dafür oder zwei oder drei. Ja, das heißt, dass der aktuelle Developer-Zirkus stapelt Container aufeinander, von denen sie auch nicht mehr wissen, was da drin ist.

MySQL, keine Ahnung, wie das aufgesetzt ist oder was das Konfig herkriegt. Und hier sind noch drei Cassandra-Container und drei Zookeeper-Container. Und wenn mal was ist, ja dann... Ja, das ist Open-Stack- Schemadiagramm. Die Komponenten und wie sie miteinander verkabelt sind, das ist erstens vereinfacht und zweitens veraltet.

Und nicht lustig. Kein Stück. Erzähle ich morgen was zu. Und wenn die Success-Metrik ist, wie sich das System im Fehlerfall verhält, dann hat man einen Scheißjob an dieser Stelle. Weil man all diese Komplexität und all diese Technologien, die die Devs da mit ihrem Technogietetris aufeinander

gestapelt haben, da muss man jetzt anfangen, Klötzchen rauszuziehen, ohne dass es so umfällt. Und wenn es umfällt, ist nicht der Dev-Schuld, der das aufgestapelt hat, sondern nicht, weil ich das Klötzchen gezogen habe. Das gibt Streit, zwangsläufig. Containerismus ist eine Krankheit. Ich weiß noch nicht, ob sie heilbar ist.

Also Ruby-E, Köl, sonst was, Pipe, Shell, ist so eine Homebrew- Installations-Sache. Hier ist ein Docker-Demo-Aufruf, der lädt einen Blob runter, hier so ein Tutorial-Blob, besteht aus einem Ubuntu-Blob, einem 1210-Blob, von dem keiner weiß, dass da drin ist,

und einem Tutorial-Blob. Das sieht reproduzierbar aus. Es gibt ja einen Docker-Fall, das das zusammenbaut. Aber was da reproduziert wird, ist einfach, da wird ein Binär-Patch für einen anderen Binär-Patch runtergeladen und draufgepleiht. Und dann hat man halt ein anderes Datalsystem inne. Aber was da drin ist, oder was das macht, kein Mensch weiß es. Und wenn man reinguckt, ist da tatsächlich eine Bash-Historie drin.

Warum, wenn es durch einen reproduzierbaren Bildprozess zusammengezogen wurde? Wie kann da eine Bash-Historie oder eine MySQL-Historie da drin sein? Das da, das ist ein Puppet-Rezept. Puppet ist ja eigentlich sehr reproduzierbar. Und alles, dieses Puppet-Rezept, das lädt mit Weget hier in Scala runter und macht dann ein dpkg-x

das Paket aus und macht dann ein CP, um die ausgepackten Dateien an Ort und Stelle zu kopieren. What? Das ist ein Puppet-Rezept! Das ist verstrahlt. das ist kein isoliertes Problem. Es gibt Leute, die Keystone-Migration von Icehouse

nach Juno geschrieben haben, die funktionieren. Für einen User eine Roll und einen Tenant. Was gemacht wird, ist aber das Ganze in einer dreifach geschachten Schleife, also mit N-O-3 auszuführen, ungecached. Das heißt, schon wenn man das Ganze mit fünf Tenants, fünf Usern und fünf Rolls macht, terminiert es nie. Das heißt, das ist offensichtlich auf einem MacBook eher mit einem Dev-Stack im St. Oberholz getestet worden, aber niemals

in Produktion. Das ist nicht der Job, den ich machen möchte. Und deswegen gibt es Streit.

Informatik ist die Wissenschaft von den Einsen und den Nullen. Komplizierter wird es nicht mehr. Alles, was wir in Informatik machen, ist total trivial einfach. Aber wir stapeln halt 30 oder 40 Schichten aufeinander und dann nochmal über das Netz einen weiteren Turm dieser

Höhe. Und das interagiert alles miteinander. Ein guter Informatiker ist einer, der diese 30 oder 40 Schichten im Kopf alle aufklappen kann. Und wenn ich dann oben ein bisschen Epsilon Delta mache, dann weiß ich, weil ich mich auskenne, was unten das für Auswirkungen hat. Darum bin ich auch so genervt, wenn mich jemand stört, weil ich eine halbe Stunde brauche,

um diesen ganzen Turm in meinem Kopf auszuklappen und zu visualisieren, damit ich gut bin. Und dann labert mich einer an, hast du dir schon mal HMM angesehen? Ja, habe ich, aber nicht jetzt. Ja, weil das ganze Systemverhalten auch total nicht linear ist und man echt wissen muss, wo die Grenzen sind dann irgendwie,

damit man damit klarkommt. Das ist schwierig, diese ganze Geschichte. Das ist auch keine neue Erkenntnis. Das hier ist von 1982. A list programmer knows the value of everything and the cost of nothing. Das ist der typische Container-Rubi-Schubser irgendwie.

Das ist der List-Programmierer mit einer List-Beschehen von 1982 oder sowas. Oder wo ist Ralf? Da ist Ralf. Ralf meinte, ja, virtualisiert euer Mal, euer Kram und baut mal eure SDNs, aber irgendjemand wird euer Matreschka-Netzwerke dann auch mal die baggen müssen. Das heißt, irgendjemand

wird dann tatsächlich einmal durch diese ganzen Layer runtersteigen müssen und auseinander bauen müssen, wie das ganze ineinander greift oder nicht mehr ineinander greift, wenn es hakt. Das ist dann auch die Jobsicherheit für Systemadministrationen. Nur Systemadministrationen sind es dann nicht mehr. Ich habe Architekten, die sich das ganze mal ein bisschen sinnvoll überlegen, die dann vielleicht auch sich einen

eingeschränkten Technologie-Stack überlegen, der das Problem abdeckt und dann dafür sorgt, dass das ganze Projekt irgendwie einen manageable operativen Footprint hat. Vielleicht kein Kafka und Kassandra da rein, sondern irgendwas, das wir schon können oder so. Wir haben Infrastrukturentwickler

oder bei Google heißen sie SREs, System Reliability Engineers, Leute, die sich dafür interessieren, was man an Code schreiben muss, damit die Karren auch laufen und Fehler erkannt werden. Wir haben Systemadministratoren immer weniger und wir haben dann Operators, das sind dann am Ende Leute, die man halt nicht in Euros bezahlt, sondern

in Bananen, weil sie den Job haben durch das Data Center zu laufen und überall da, wo die rote Lampe leuchtet, die Platte raus und eine andere rein oder sowas auf dem Level. Also Tätigkeiten, die man durchaus mit angelerntem Personal nach Sicherheitsüberprüfung abwickeln kann. Das heißt, dass da der Systemadministrator,

den gibt es halt immer weniger in Zukunft mit mehr Automatisierung, aber Infrastrukturentwicklung ist tatsächlich ein Job, der von einem Feature-Entwickler sehr entschieden ist, weil er eine andere Erfolgsmetrik hat und weil er sich mit Automatisierung von Sachen beschäftigt und mit der Zuverlässigkeit von solchen Systemen, die wirklich viele

Techniken aufeinander stapeln, auseinandersetzt. Und DevOps ist da eine große Verbesserung, weil es dafür sorgt, dass diese Leute mehr miteinander reden, aber den eigentlichen Zielkonflikt, die unterschiedliche Erfolgsmetrik, die unterschiedlichen Interessen, der wird dadurch nicht aus dem Weg geräumt und das muss man dann auch sehen

und wahrnehmen und da gemeinsam drüber reden und gucken, wie man das dann in den Betrieben legt. Vielleicht so, wie Booking es gemacht hat mit diesen beiden Regeln. If you break it, will you even notice? And if you break it, can you fix it? Das ist recht simpel, aber das ruft dann den Entwicklern die notwendigen Merksätze sehr einfach in den Kopf

und vereinfacht dann viele Dinge. Fragen. An alle eigentlich, aber speziell auch an Devs, weil die die Symmetrik nimmt. Für die Ops

ist die Auflage, dass sie dem Change nicht im Weg stehen dürfen. Bei Booking zum Beispiel ist es so, dass ein DBA einen Rollout oder ein Database Change nicht aufhalten kann. Das kann er nicht. Das heißt, die Aufgabe von einem DBA ist es nicht, die Datenbank zu beschützen und der heilige Hohe Priester der Database

zu sein, sondern der DBA ist jemand, der sich darum kümmert, die Entwickler vor, während und nach dem Crash zu betreuen. Die Entwickler zu betreuen, vor, während, nachdem sie die Datenbank kaputt machen.

Also vorher ... Was ich mache vorher ist Consulting. Ich habe mir da dein Schema mal angeguckt und deine Queries und vermutlich wird das Folgende passieren. Ich habe das mal ausprobiert. Der Plan sieht so aus und

ich schlage dir vor, du könntest die Queries so schreiben, dann tut es weniger weh. Wenn der Entwickler sagt, nee, hau ab, dann wird das halt so kaputt ausgerollt. Dann geht das System kaputt, dann bemerkt der DBA das, rennt zu dem Entwickler hin und hier dein Change ist es gerade, der dafür sorgt, dass wir mit der Umsatzkurve bei Null sind. Und hinterher

ja, nun ist es so kaputt gegangen, wie ich es dir vorher gesagt habe. Hier ist der Change, der ist aber inkompatibel beim Einspielen, das heißt wir brauchen die folgende Migrationsprozedur und dann sind wir in der Viertelstunde wieder online. Das heißt aber, dass ich dann als Ops-Person mit den Devs tatsächlich reden muss und auch in deren Sprache und deren Interessen

Weltmodell-kompatibel erklären muss, was da gerade passiert und dass es gut für die ist, wenn sie auf mich hören. Und dann crashen sie das System vielleicht beim ersten Mal und beim zweiten Mal haben sie dann schon gemerkt, der Christ, wenn dir das sagt, dann will der mir gar nicht im Weg stehen. Wenn ich auf den höre, tut es allen weniger weh. Und beim dritten Mal kommen sie dann vorher schon an

und sagen, sag mal hier, das kommt mir fischig vor. Erstens, wie würdest du das machen und zweitens, hast du mal einen Kurs oder so? Damit ich mehr über die Datenbank weiß. Das funktioniert ausgezeichnet. Das ist die Aufgabe von Ops-Leuten. Das ist aber kein Hexenwerk, weil das steht so schon 2001 bei Limoncelli im Buch. Also man muss sich halt mal damit beschäftigen,

was die Aufgabe der Firma ist und sich dann überlegen, wie man da mitrudern kann, anstatt gegen anzustehen. Weitere Fragen. Kapazität

ist ein wichtiger Punkt. Die Frage ist, was ich da machen kann. Das ist zum Beispiel der Grund, warum Booking jeden Mittwoch diese Kapazitätstests macht. Damit sie wissen, was die reale Kapazität ist. Was die haben, ist halt diese Lastprognose über das Jahr, weil jedes Jahr von der Form her in etwa gleich aussieht.

Das heißt, wenn man so ein Year-on-Year-Growth-Scale ermittelt hat vor Ostern, dann weiß man für den Rest des Jahres schon, wie schlimm es wird. Also der Rest des Ladens der findet das natürlich schön, weil alle werden reicher und die Ops-Leute sehen nur, wie schlimm es wird, weil sie müssen Zeugs nachschieben und Dinge brechen auseinander und

ähnliche Sachen. Und das heißt, das ist dann aber auch sehr leicht, wenn man dann die gemessene Kapazität hat und die prognostizierte Kapazität hat und damit dann zu seinem Technical Director geht und sagt, HP hat eine Latenz von sechs Wochen, Minimum, und in acht Wochen berühren sich die beiden Kurven, dann ist das eine 15-Minuten-Sache,

da ein Budget von eineinhalb Millionen zu kriegen. Überhaupt gar kein Problem. Das ist eine sehr einfache Diskussion. Hier waren noch Fragen.

Die Frage war, was gibt es an Migrationsstrategien, mit denen man ein althergebrachten

Systembetrieb auf Automatisierung und auf solche Denkweisen kriegt? Entwickler, die Ops-Interessen mitvertreten und Ops die Veränderung nicht mehr im Weg stehen. Das ist der Punkt, was ich sage. Das sieht zwar aus wie ein Grassroots-Prozess, der von unten

herkommt, aber der braucht natürlich Unterstützung vom C-Level her, wo eine ganz klare Ansage kommt, wir machen das zusammen und das bedeutet, wir erwarten von euch in Ops das Change mitgetragen wird und tatsächlich ist hier jetzt ein Budget dafür. Und wir machen das jetzt so und dann muss man sich mal ein paar Mal in so blameless Postmortem mit

reinsetzen, damit das auch die richtige Richtung nimmt, die ganze Geschichte. Und vor allen Dingen muss man auch von vornherein kommunizieren, dass Fehlschläge nicht nur drin sind, sondern erwartet werden. Ich habe, und das ist wörtlich zitiert jetzt, ich habe in der Kantine bei Booking gesessen, Kees Kohlen hat da oben mit allen anderen immer Mittag gegessen.

Das war noch in etwas kleinerer Laden da und er ist dann so am Kauen gewesen und meinte dann den Menschen bei ihm gegenüber, dich habe ich noch nie gesehen, bist du neu? Und der ja, ich bin hier drei Wochen. Ah, did you crash the production already? Und der Typ so nein, wieso? Natürlich nicht, ja wofür bezahle ich dich eigentlich?

Das ist wörtlich, das ist wörtlich so passiert und das ist genau das C-Level Endorsement, das ist Brauch, um diese Veränderung in den Köpfen zu erzeugen. Change ist gut,

aber man muss es halt mit Carefull Carelessness machen, das heißt wir müssen erstmal dafür sorgen, dass die Leute die Systeme wirklich kennen, dass sie die Metriken kennen, damit sie mitkriegen, was kaputt geht, wenn es kaputt geht und dass sie wissen müssen, wer kennt sich wirklich damit aus, wenn ich es kaputt gespielt habe und wenn du das erzeugt hast, dann kannst du tatsächlich auch erfolgreich so was machen. Du musst den Leuten Mut machen,

es ist okay, wenn du was kaputt machst, aber wir wollen was dabei lernen. Wir haben gerade eine halbe Million in der Ausbildung investiert, natürlich werden wir dich nicht feuern, weil die Outage hat halt eine halbe Million gekostet. Und du musst auch dafür sorgen, dass die Ausbildung vor dem Crash da ist, das heißt, dass die Leute die Möglichkeit

haben, das ganze zu lernen und solche Changes durchzuführen, ohne das System zu killen. Die wollen ja gut sein und wenn dann doch mal was passiert, dann muss der Raum da sein, damit sie den Crash überlebbar haben können. Waren hier noch Fragen? Ich wollte alle Seiten mal abdecken. Also meine Frage wäre endlich gewesen,

aber was zu ergänzender Frage, habe ich überhaupt eine Chance, als jemand, der jetzt sagt, ich habe irgendwie so einen zweiten Team, mit dem ich die Seite dann in Code und Intersprung haben wollte, wenn da nichts von oben her heran kommt, so hey, ihr müsst ja jetzt noch alle mal mitmachen.

Das muss ganz klar von oben und von unten kommen. Ich brauche es vom Management her, nicht nur der Absicht, sondern mit harten Quarantinen. Bei Booking ist es halt ein Budget. Und es muss von unten kommen.

Wir wollen gut sein. Ich will wissen, wie es funktioniert, auch im Betrieb, obwohl ich Entwickler bin. Ich will, dass es moderner wird, auch wenn ich Admin bin. Und mir ist klar, dass es dann Veränderungen gibt, die das ganze System und seine Stabilität gefährden werden. Aber wir wollen in diesen neuen Zustand kommen und das heißt, das packen wir alle mit an. Und nur wenn du alle diese Parteien zusammenkriegst

und sie das alle wollen, kann es gelingen. Das ist echt anstrengend und schwierig. So, hier waren noch Fragen.

Ja. Die Frage ist, was passiert, wenn man keine direkte Erfolgsmetrik hat? Bei Booking ist das ja relativ einfach. Die verkaufen Hotelräume und man kann jede Minute sehen, wie viele davon verkauft worden sind. Wenn ich AB-Tests mache, bei was weiß ich, web.de und ich mache eine

Änderung am Folder-Management, dann kann ich nicht sehr gut sehen, welche davon erfolgreich sind oder nicht. Das ist ein schwieriges Problem. Und die erste Diskussion muss immer über Metriken sein. Wie kann ich überhaupt Erfolg messen? Damit man in quantifizierbare Bereiche kommt. Das ist immer Domainspecifik. Also

wenn ich ein Freemailer bin, geht es anders als wenn ich ein Hotelverkäufer bin oder ein Hoster oder was auch immer. Nein, ich fange im Business an. Das muss immer im Business anfangen und es muss auch deswegen im Management verankert werden. Als Prozess und als Änderungswunsch. Sonst geht es nicht.

Ja? Ja?

Die Frage war, wie ist das mit Testen in Produktion, wenn ich wirklich eine Produktion habe oder eine Produktionssteuerung? Und das führt uns auf die Frage der

Überlebbarkeit zurück am Ende. Mit keinen Kraftwerken geht das nicht so wie mit Pucking. Das ist klar.

Ich habe da eine größere Zieldivergenz als sonstwo. Ja, das ist wahr. Das ist relativ inkompatibel. Ich habe keine Ahnung, was oder wie man das da anpassen kann. Wenn ich einen Test nicht klar machen kann in der Produktion, kann ich

da nicht testen. Das muss ich simulieren. Das ist klar. diese Kläranlage für Hamburger Hafen schlägt Schwermetalle raus. Da haben wir dann auch mit Wasser getestet und mit Kies. Und nicht mit echtem Hafen-Schlangen mit Schwermetallen und mit echten Klär-Chemikalien drin. Aber wir haben auch

einen Golf dastehen gehabt in Fluchtrichtung mit laufendem Motor und wir haben das mit 20 Containern voller Zeugs laufen lassen. An einem Punkt. Aber erst, nachdem es vorher in der Simulation mit Pixelwasser funktioniert hat.

ITIL ist als Methode und als Art und Weise, wie es eingeführt wird, oft sehr top down. ITIL ist außerdem extrem fehleranfällig spezifiziert. Wenn man sich die ITIL Sachen anguckt, wie sie spezifiziert sind,

dann sind sie dafür eine unendlich große Form mit einer unendlich groß ausdifferenzierten Anzahl von Rollen und Funktionen. Und das heißt, wenn man ITIL irgendwo einführt, muss man das immer runterscalen auf die eigene Organisationsgröße und das wird in vielen Stellen, die ich gesehen habe, nicht gemacht. Das heißt, was ich da

oft sehe, sind irgendwelche Bürokratie-Monster, die einem sinnvollen Arbeiten im Wege stehen. Und DevOps kommt eigentlich zumindest auf der Verpackung, als von unten Grasruts Sache her, ist es nicht, weil ich brauche das C-Level Endorsement, um es einzuführen. Aber das führt dadurch meiner Erfahrung

noch öfter zu einer Prozessgröße und Detailtheit, die der Firmengröße und Problemengröße angepasst ist. ich glaube, dass es eher ein Verpackungsproblem ist. Wenn man ITIL so denken und einführen würde, wie man an DevOps reingeht, wäre es vielleicht öfter erfolgreich. Viele

Firmen machen ja schon ITIL, bevor sie ITIL einführen, verwenden nur nicht die Normenworte dafür. Das heißt, die ITIL-Einführung könnte sich eigentlich darauf beschränken, ein paar Dinge zu benennen, damit es hier genauso heißt wie bei den anderen Dienstleistern. Stattdessen wird dann ein riesiges Bohai vom Zaun gebrochen. Und

Verwaltungsoverhead draufgeknallt, der mit der Arbeit, die eigentlich zu machen ist und den Problemen, die eigentlich zu lösen sind, nichts zu tun hat.

Ja, das meinte ich mit, man hat halt eine unendlich ausdifferenzierte Prozessstruktur in der Spezifikation, die dann zu groß installiert wird, und dann geht man da her und verarscht den Prozess in der Praxis, wie du es nennst, und führt Shortcuts ein. Das ist das nicht, das ist DevOps. Du führst Prozesse ein, die der Problemstellung und

der Firmengröße angemessen sind. Das heißt, die Leute, für die die Prozesse wichtig sind, weil sie sie ausführen, und die Leute, für die die Prozesse wichtig sind, weil sie die Zahlen brauchen, die setzen sich zusammen und einigen sich darauf, was wirklich gemacht werden muss. Wenn man das dann auch noch so nennt, wie im ITIL-Dokument, dann ist man fertig mit der ITIL-Einführung und hätte überhaupt kein Problem. Aber so wird es halt in der Regel nicht gemacht.

So, ich schlage vor. Christian ist noch eine Zeit lang hier. Wer noch Fragen hat, kann sich vielleicht gleich noch an ihn wenden. Ansonsten vielen Dank für diesen hervorragenden Vortrag.