 Gut, dann erst mal einen schönen guten Abend, liebe GPN. Ihr kennt ihn, Felix, erlebt mit der DSGVO, fotografiert in seiner Freizeit unter Wasser und jetzt möchte er euch uns erklären, warum nur der faule Atmende ein guter Atmen ist. Bitte schön. Danke, danke. Ich gebe es gleich zu, im privaten Leben arbeite in einer IT-Unternehmensberatung. Ich habe den Vortrag normalerweise immer vor Management gehalten. Ich habe versucht, ihn jetzt etwas technischer aufzubauen, damit er mir nicht einschlaft. Aber ich denke mal, das Hauptdilemma wird ihr kennen. Wer von euch ist Entwickler? Wer von euch ist der Atmen, der es nachdem Entwickler verwalten muss? Okay, ist es entweder sehr viel DevOps oder 5050 Grad. In der Regel, man kennt es für alten Prozessen, es gibt eine Abteilung, das sind so die Entwickler und die Schwarze Magie. Bauen sie auf dem lokalen Host? Sag, bei mir hat es geklappt, du bist dran. Ja, das ist dann das, wo man dann immer sagt, irgendwie haben wir Probleme bei uns in Teams, die vermögen sich nicht, die verstehen sich nicht. Wir haben total hohe Betriebskosten, wir brauchen neue Prozesse. Ihr werdet das merken, der Vortrag, der faule Atmende ist ein Mix aus, jetzt brauche ich als Atmen um faul sein zu können und was ist eigentlich der Wandel, der sich jetzt über die Jahre ergeben hat in Richtung DevOps, was braucht man dafür, um so was machen zu können? Wenn man mit Management redet, das ist die erste Folle, die man findet, wenn man nach Hacker googelt, das ist ungefähr genau das, was ankommt bei Management. Ja, der macht ja irgendwas auf der Konsole. Wir wissen, was er tut, aber es funktioniert. Wir brauchen ihn. Kommt wir auch immer Kollegen zu uns ins Büro rein. Ja, was macht ihr euch den ganzen Tag? Ja, es ist ein bisschen Counterzeug, zocken, dann müssen wir noch YouTube schauen, was meinst du, was wir den ganzen Tag tun, arbeiten. Ja, ich sehe euch immer nur vom Laptop und da macht, ihr seid gar nicht gestresst, wo mir von mir fragt, welche Atmen ist denn besser? Was für einen Atmen brauchen wir eher? Meint ihr, wir brauchen so den Hängemattenatmen oder unseren Superhelden? Wer ist denn hier für den Hängematteatmen? Überraschung, die Mehrheit. Wer ist für den Feuerlöschen Superhelden, der kleine Kinder rettet? Ja, ist richtig geantwortlich, ich stehe nicht vor Management. Für Management ist der Atmen immer der Feuerwehrler, der den nachts einspringt, der, der alles rettet. Ja, wenn deine IT-Abteilung irgendwo nachts aufstehen muss, um Surfer zu retten, sorry, dann ist deine Technik komplett verkackt. Deshalb, die Kernaussage von meinem Vortrag, der faule Atmen ist der beste Atmen, der automatisiert seine Sachen so weit, dass er selbst, wenn er für Schläfeln den Bock hat, automatisiert noch die Krankmeldung macht. Wer von euch, wer von euch kennt dieses Getrepo, die die es noch nicht kennt, schaut es an, dass es der, der es geschafft hat, sogar beim Sternencoat zu landen, oder dass er in kompletten Arbeitsablauf automatisiert hat. Der nervige Kollege schreibt eine E-Mail, einfach E-Mail-Postvereingangscannen, automatisch eine Antwort gleich hinterher. Man sollte die Regeln, wenn es andere sehen können, vielleicht nicht Arschloch nennen, aber es ist wirklich das Wichtigste, wenn man etwas automatisieren kann und es auch noch nervig ist, man sollte automatisieren. Gut, ich sage ja vorher gesagt, wir brauchen zwei Sachen, damit wir ein faule Atmen werden können. Zum einen, die Atmens müssen ihre Sachen tun, zum anderen die Entwickler. Wem von euch ist den DevOps ein Begriff? Geil. Wer von euch will den Vortrag weiterhalten? Freiwillige? Verdammt. Jo, da muss ich gar nichts mehr erzählen, also danke für die Aufmerksamkeit, wir machen den DevOps. Ne, was muss man als erstes ändern? Es gibt große Sales Trainings, viele Bücher, das Phoenix-Projekt kann man sich durchlesen. Das Wichtigste ist, man muss die Kultur ändern. Wenn die ganzen Kollegen sagen, ja, es ist schön, dass wir DevOps machen, hat das Chef beschlossen. Was glaubt ihr, wie kann es funktionieren, wenn man zum Kunden jetzt hingeht oder wenn irgendeiner Vorstandsvorsitzender von einem Konzern sagt, wir machen DevOps, jetzt muss die IT-Betellung auch noch entwickeln? Klappt das? Ich sehe nur Kopfschutteln. Ja, also es sorgt für sehr viel Stress und dafür, dass mein Gehalt bezahlt wird, weil dann kauft man sie nämlich externe Berater an, wo ein, die können das ja dann auch. Ich habe Kunden und da sind, das sind zwei Drittel extern, also zwei Drittel externen Mitarbeiter. Ich habe von Kunden gehört, Überhörern sagen, da ist nur noch ein Fünftel intern. Also ganz ehrlich, so ein bisschen internes Skills aufbauen ist nicht schlecht. Kultur, was muss man eigentlich machen? Man muss als erstes dafür sorgen, dass auch alle mitmachen wollen. Wenn der Chef sagt, wir machen DevOps, das ist genauso wie wenn der Chef sagt, wir machen jetzt Agil, wir machen jetzt den Agil in Wasserfall. Funktioniert genauso nicht, nur weil man etwas, das jetzt Hase nennt. Ein Hund Hase nennt, macht noch keinen Hase aus dem Hund. Das machen Chefs immer ganz gerne. Man muss die Kultur anpassen. Man muss mit den Leuten reden, was eigentlich damit einhergeht. Man muss erst mal verstehen, was in den Prozessen da ist. Die IT schimpft immer die blöden Entwickler, die machen da, was das funktioniert nicht. Die Entwickler sagen immer, ja, die blöde IT, die brauchen uns Leute um Bugs zu fixen. Die Bugs haben es auch selbst eingebaut, bei uns hat alles funktioniert. Die können das nicht, die IT-Lam. Das ist so ein Standarddilemma. Man hat zwei Gegenpolis, die sich abstoßen und hat nur Stress, wenn man dann aber anfängt zu erklären, den beide Parteien reinzuholen und sagt, hey, wir haben das so eine CI-Pipeline, das ist ein Schränkens. Der ist gut, nutzt ihn mal. Ach, echt? Ja, und dann test ich lokal. Nee, du kannst eine Unit-Test einbauen, du kannst Integrations-Tests einbauen. Echt, das geht? Machst du es jetzt? Ja, das zeigt mir keiner. Das ist so das Standarddilemma. Chef sagt, mach mal. Dann sagt man, ja, das kostet uns aber Zeit, um Tests aufzubauen. Wir müssen einen Tool-Asset aufbauen. Nein. Das ist das erste, ist wirklich die Kultur in der gesamten Hierarchie durchkriegen oder seinem Chef. Ich habe eine Folie, relativ bad, die zeigt so, kosten sie, kosten sinken, alles andere wird besser. Im Sohnepfolie zeigen kann man auch machen. Was braucht man sonst noch? Ich habe es schon angefangen mit Schränkens. Alles, was irgendwo nervig Prozesse sind, automatisieren. Wer von euch richtet noch Surfer von Hand ein? Okay, es meldet sich ein paar. Warum? Okay, zum Testen und für zumindest um sein Modul des der Puppet oder der Arzt, die Arztbefehl darauf funktionieren. Das zählt noch, ja. Wer von euch verwaltet und wartet Surfer noch von Hand danach? Warum? Bitte schlaft den Prozess ab. Genau. Dann, man hätte auch sagen können, wir haben uns gut abgesprochen. Kommen wir zu Lean. Sorry, so ein Prozess gehört optimiert und am besten wegoptimiert. Einzigste Kernprozipien bei DevOps ist ja Lean culture, Lean strategy. Es sind scheiß Buzzwords, das Wichtige ist, wenn man Prozesse hat, wo alle sagen, dass es scheiße sind, könnte es einen Grund haben, dass die Prozesse scheiße sind. Dann sollte man vielleicht darüber reden und Prozesse auch ändern. Ja, Security ist wichtig. Es ist wichtig, dass man mit Security auch über seine Software redet, aber dass alles an Mehrmutter auf Security wartet, ist vielleicht ein bisschen schlecht. Gibt es immer so Abwägungen? Normalerweise bin ich auf der Security Seite, dass ich es bewerten muss. Heute kann ich gegen Security schimpfen, das ist auch ganz angenehm. Genau. Dann das Wichtige auch, man muss irgendwo Transparenz schaffen. Einzigste Kernfeatures, wo auch immer ein ganzes Sales-Training kommt ist, gibt den Manager ein Dashboard. In der Regel ist irgend so ein Manager ab Führungskraftebene 3, der will nicht von euch einzelne Tickets sehen. Die freuen sich, wenn man ihnen ein Gryphana baut, wo einfach am besten der Ampel drauf ist. Ich sehe schon, ich habe das Erfahrung mit Management. Wichtigste, wenn man im Schleff sagt, wir wollen Transparenz schaffen, wir haben dir hier die Top 10 Blocker automatisch. Du kannst ein E-Mail-Report machen und du kannst alles dort machen, noch extra Pipen und da weiter bearbeiten. Ich habe mitleid geplagt, das freut mich wirklich. So was ist das, was auch dann hilft. Es hält der IT-Abteilung, die ganz nervigen Kollegen fordert für. Man hat die Möglichkeit, dass man dann sein Arbeit wirklich machen kann. Einmal Dashboard eingerichtet, fertig, funktioniert. Das im Dashboard ist auch das, wo man dann hinkommt, dass man sagt, ja, wann ist eine Software gut, wann ist es schlecht, dass man sich mit den Abteilungen einigt, was sind eigentlich unsere gemeinsamen Ziele, was erwarte ich denn von dem Ganzen? Einfach wirklich, wenn ein Business Casper kommt, heißt, wir definieren KPIs. Ich sehe schon auch, hier haben wir Leute Erfahrung mit Businessmenschen. Man definiert einfach irgendein Ziel. Eine Software sollte, unser System sollte 99,9% Abtime haben. Das ist ein beschlossener Abtime, ich weiß, aber man hat schon mal eine definiert. Einfach Sachen beschreiben, die man messen kann, ob das man sagen kann. Du, Chef, wir haben eine Mitarbeiterauslastung von 90 Prozent. Wir haben gesagt, wir brauchen für Notfälle 12 Prozent Puffer. Wir sind über der Bemessungslinie. Wir brauchen eine Stelle mehr oder wir müssen jetzt aufstocken. Das ist einfach wirklich definierte Sachen hat. Es ist das auch in den Firmen, wo ich unterwegs bin als Berater. Das Management und die Führungskräfte, die wollen einfach nur Zahlen haben und sagen, wir sind über einem Wert und unter einem Wert. Sobald man einfach nur so was automatisch aus der Schublade rausholen kann. Ich habe keine Arbeit, diese Zahlen sind vorbereitet. Ich habe irgendein Dashboard dafür. Hält euch das Management von den Fersen. Ansonsten, das ist das letzte Ding, wo auch extrem in Beratung ist. Man hat so seinen kleinen Beraterwerkzeug koffert, ist alles geheim. Es gibt man nicht weiter. Es ist komplett gegen das Prinzip. Sharing is curving. Das heißt, man gibt Informationen weiter. Man sagt seinen Kollegen, hey, wir haben da was. Man dokumentiert seinen Wissen, was auch ganz viele Firmen immer wieder kommt, auch in den Beratungen, dass man so einen Wissens-Austausch einmal im Monat macht den ganzen Tag, dass man einfach so irgendwelche Aussage-Vents baut, dass Wissen weitergegeben werden kann. Das ist ein grundlegender Faktor von dem ganzen DevOps, dass einfach auch ein Wissens-Weitergabe gezielt gemacht wird, um den Busfaktor zu reduzieren. Wer von euch kennt den Busfaktor? Wunderbar, die Hälfte. Der Busfaktor, wie viele Leute können vom Bus überfahren werden, ohne dass es für die Firmen jetzt untergeht? Bei ganz, ganz vielen Firmen liegt der Busfaktor bei eins. Wenn der Busfaktor kleiner eins ist, haben wir ein Problem und zwar ein großes. Ich habe Kunden unterwegs bin. Da gibt es genau eine Person im gesamten Konzern mit 30.000 Leuten, die ADFS Verwaltung pflegen kann. Der Busfaktor da ist sehr, sehr, sehr schlecht. Wissenteilen, Wissendokumentieren sind die Grundprinzipien, wo man zu jedem Chef gehen kann, sagen, wir wollen was aufbauen. Es bringt die Ersparnis. Warum wir jetzt atmen das Ganze? Eigentlich baue ich dann in meinem Pipeline auf und alles funktioniert. Und wir haben, die Folie habe ich leider falsch verschoben oder falsch kopiert, das Dilemma weg. Ich habe es vorhin noch mal gesagt gehabt, die Kultur ist wichtig. Das haben wir auch alles gemacht. Wir haben bei uns in der Firma, wir haben das Austausch aufgebaut, etabliert. Gibt es einmal 100 Tage, wo man einfach so was aufbaut. Wir dwecken auch insbesondere, wie wir Sachen gemacht haben. Warum wir für einen Aufwand und einen Ticket jetzt 20 Tage gebraucht haben, wo man einfach sagen kann, da haben wir entweder nicht richtig geplant oder wir haben externen Einflussfaktoren. Das heißt, die Kultur ist an der Stelle nicht, ich bewährt jetzt ein Mitarbeiter. Wer von euch hat den Betriebsratvortrag gesehen? Dev Ops und AdWords, die ganzen Sachen dienen nicht dafür, um einen Mitarbeiter zu bewerten, sondern einfach um Erfahrungen zu sammeln. Man macht keine Storypoints, um zu sagen, wo der Entwickler scheiße, der braucht für den Tag 20 Storypoints. Es geht darum, dass man einfach bewerten kann, wie ein Team im Mittelmaß agiert, dass man sagen kann, worauf muss ich achten, das habe ich an Problemen. Ganz wesentlicher Faktor ist, wenn man damit arbeitet, die Continuous Integration, Continuous Delivery, als IT-Abteilung, wenn man Kollegen hat, die schnell selbst lernen, was teilweise sehr selten ist. Man baut einfach in einer Jenkins, GitLab, Bamboo, irgendwas hin und sagt, mach einfach eine Bildpläne, es funktioniert, am Ende fällt was raus. Dazu haben wir noch einen Knopf, und das deployt sich automatisch. Hat das von euch schon jemand so live? Es waren jetzt ungefähr 10 Prozent des Sales, die sich sanft gemeldet haben. Wie deployt der Rest? Wer von euch deployt? Bei wem von euch bauen die Entwickler noch von Hand? Ein Einzelner, das ist eine sehr gute Quote. Wir sind uns einig, welche der Faktoren da noch mal überachtacht werden sollte. Da musst du ständig so arbeiten über drei Ebenen. Genau, es gibt aufgezeichnete Sessions, aber man kann durch Auditing, wenn die Prozesse sogar aufgebaut sind, dafür sorgen, dass ich den Atmen gar nicht einloggen muss, das ist viel besser. Die Frage war, es gibt noch nebenbei, den standortmäßig so, dass Server-Wartung nur über aufgezeichnete Screen Sessions, Thermal Sessions gemacht werden kann. Wenn der Rollout automatisch passiert, das heißt, man muss nicht überwachen, dass der Atmen was macht und Jenkins, Bamboo und die Tools haben einen Audit-Lock, dann weiß ich, was passiert ist. Es ist immer eine Frage, wie man es mit Security spielt und ob Security einem vertraut. Man kann die ganze Security-Prozesse auch durch die Tools erschlagen, bringt mich auch zu dem Punkt. Ich reite extrem auf der Kultur rum, weil leider der Hauptblocker ist, auch bei den ganzen Kunden, wo ich bis jetzt gesehen habe, weshalb so was nicht funktioniert, weshalb man immer noch kämpfen muss. Ihr seht, jetzt ist die Folien habe ich von zig anderen, die Autor überredet haben schon kopiert, das braucht mich neu erfunden. Man kann sich dazu ewig lange Vorträge von Amazon holen, von Atlassien, SlideShare, das ist nicht das Rad neu erfundene. Es geht ums Prinzip, die Kultur und die Menschen kommen immer als Erstes. Danach soll man die Prozesse anschauen und irgendwann danach die Tools. Es gibt immer wieder Chefs, die sagen, ich habe dann ein geiles Tool eingekauft, wir sind jetzt besser. In der Regel funktioniert das mit, ich habe jetzt hier Fira gekauft, jetzt im Agil, funktioniert übrigens nicht. Man ist auch nicht DefOps, nur weil man beim Buur aufgebaut hat. Das ist erst Kultur und Prozesse mit den Leuten reden ganz viel, wenn man eine Prozessberatung macht oder IT-Beratung für so ein Produkt, was DefOps unterstützen kann, ist, die Leute ein Händchen halten und erklären, macht eine Kultur sauber, dann machen wir das Tool sauber, nicht andersrum. Genau. Deshalb, das Wichtigste bei so was ist, ist immer das Team, damit Arbeiten und dass es auch vom Team anerkannt wird. Ihr seht schon, ich habe ganz viele Folien zum Thema Team mitgebracht. Was entwickelt das sich immer weigern oder sehr oft weigern? Ja, ich muss jetzt ein Pool-Request machen. Entweder, ich habe ganz viele Leute, da gibt es noch SVN, kann man machen. Ich kenne und dessen Firmen, da ist der Release-Prozess, dass man seinen Entwickler für zwei Tage nach Hause schickt, die nichts mehr kommitten dürfen, dann jemand sauber von SVN Sachen zusammen kopiert und in SVN als Kopie umbenannt in neuen Ordner packt. Also die Versionshistorie, damit ist leicht kaputt übrigens. Vielleicht soll man da dann das Tooling anfassen und den Prozess und die Kultur. Also ein wesentlicher Faktor davon, wenn man sagt, man will DefOps, man will, dass Leute weniger arbeiten, müssen auch weniger Stress haben, ist, man arbeitet mit kleinen Inkrementen, man arbeitet mit diesen tollen modernen Techniken, Per-Programming, Reviews, Pool-Request, wer von euch kennt keine Pool-Request? Yes, alle kennen Pool-Request, das beruhigt mich. Ich kenne Kollegen, die kennen es nicht. Deshalb einfach wirklich nutzt solche Technik, schaut, dass man damit arbeiten kann. Nur weil ein Test viel schlägt, wurde noch niemand geköpft, maximal bin ich auf ganz beschlossen. Wer den Bild zerstört, hat immer noch nicht das Live-System zerstört. Wer ungetestet irgendwas in das Live-System rein schiebt, der wird geköpft. Und das mit Recht. Er ist mit Nerven ganz einfach mit dem Getuned mit der Stahlfeder. Meine Kollegen können nicht davon singen, ich habe die Getuned. Die schießt übrigens auch über die Straße bis zur Supermarkt gegenüber. Man muss einen Umbruch in der Kultur schaffen, in der Firma, der auch alle Abteilungen betrifft. Was ist dann in der Regel die Reaktion von Management und Co.? Oh mein Gott, jetzt habe ich gar keine Kontrolle mehr. Es ist wie bei Ad-Studio und Co., die Teams machen jetzt was, wer sagt jetzt, was in mein Produkt reinkommt, die machen irgendwie was und jetzt habe ich auch nicht mehr einen Team für Entwicklungen, eins für Betrieb. Das machen es alle, da weiß ich ja nichts mehr. Da gibt es wunderbare Techniken. Da gibt es wunderbare Techniken, wo man seinen Kollegen quasi aus einem Management hinschicken kann. Es gibt Lego Workshops, wo man mit Lego das Management in Stadt bauen lassen kann, wo sie einmal alle Schmerzen erleben können mit Ja, jetzt müsst ihr deployen. Ach, eure IT kommt mit dem Deploy nicht mehr hinterher. Ach, ihr habt es Tests vergessen. Ach, jetzt ein Erdbeben ist die Stadt kaputt. Es sind zweistöhnige Simulations-Training, wenn der Manager es nicht versteht. Die Trainings sind günstig, zwei Stunden haben die meistens Zeit, schickt man das Management einmal zu dem Training rein. Jetzt die Frage. Ist es nicht so, dass mit DevOps zusammen die Manager umgetauft werden? Das geht auch. Die Frage war, ist es mit DevOps jetzt nicht so, dass die Manager jetzt Lieder werden? Wenn es stinkt und aus einem Hund hinten rauskommt, kann ich es auch Blümchen nennen. Es ist trotzdem noch derselbe. Es gibt jetzt wieder Bewegungen. Es gab früher ein Auditor, den Lead Auditor, den Lead Pantester. Es ist egal, wie man es nennt. Also, teilweise sind ... Was meine ich? Die Manager soll sich nicht umschneugierig machen, wie ich meine, das vorbild sein. Genau, für Stream und Aufzeichnung. Man soll Manager zu bringen, dass das Team unterstützt. Was man da auch in der Unternehmensberatung hat, ist, dass man sagt, wie Sie haben den Surfend-Lieder, sprich, man dient dem Team und leitet es weniger. Das Team, selbst das Surfend, ist das Wichtigste an dem Begriff, dass man an Lieder ist immer noch ein Leitmensch. Es bringt mehr, dass es das Surfend ist, der unterstützt. Weitere Fragen ist dahin, innerhalb der letzten zehn Minuten. Gut. Das ist für die, die das Ganze nachlesen wollen. Das Wichtigste, kurz zusammengefasst, ist, wir haben Software, die wird entwickelt, werden entwickeln, wird schon getestet, man macht so was mit rein. Wenn irgendwas Scheiße ist, sagt man es auch seinen Kollegen, das ist diese Transparenz. Es gibt ganz, ganz viele IT-Abteilungen, die können Liedchen davon singen, speziell die Leute von heute unter euch, die Enterprise Software betreiben. Es gibt den guten Spruch, das Enterprise, das muss weh tun. Wenn ich Kunden gewisse Softwareprodukte das erste Mal installiere oder vorführe, die Kunden fahren dann zu. Ja, das sind gute Fehler, die müssen da passieren. Also es ist, da hat man dem Hersteller noch nicht gesagt, dass das Scheiße ist, gravierende Fehler Nachrichten in der ersten Installation zu bringen. Man hat es ihm gesagt, er hat das Ticket zugemacht. Es ist wichtig, dass man den Entwickler ins Feedback gibt und dass man auch einfach mal diesen Schulterblick bringt, dass man den Entwickler zeigt, wie er arbeitet, die IT, und der IT zeigt, wie er arbeitet, der Entwickler. Da kann man meistens auch ganz, ganz viel Bewegung reinbauen. Es recht, wenn der Entwickler auf seiner lokalen Maschine irgendeinen Schleiß baut. Welche Magie haben wir dann, was man nutzen kann? Also, das, was jeder von euch kennt, ist die ICD, habe ich erzählt, was unterdessen auch durch Presse, Facebook und Co. jeder kennen sollte. Man macht nicht einen Major Release, das einmal im Jahr deployt wird. Man schaut, dass man regelmäßig innerhalb von kleinen, am besten Service ist, dass man das AB-Tests macht. Das sind wirklich Standards, die man auch machen sollte. Und wer häufig deployt, hat entweder sehr viel Zeit oder hat es automatisiert. Wir haben es automatisiert, wir wollten irgendwie was anderes tun. Das ist auch Standard-Tool. Wer von euch nutzt Docker? Find ich gut. Man sollte, wenn man Microsoft das nutzen kann und es sinnvoll machen kann, Microsoft ist das Nutzen. Docker ist kein Security-Tool, wie ihr sagt, ich möchte das Security-Tool sichere VMs haben. Wenn ihr dann das Antwort Docker bringt, bitte einmal rausprügeln oder auf den Schulungen schicken. Docker ist nicht das Tool, das ich für sichere VMs mache. Docker ist für Reproduzierbarkeit was super, klasse ist. Ich habe es einmal installiert und habe einmal ein Image vorbereitet. Und zwar hält sich reproduzierbar. Ich habe auch Kundes jetzt sich zwei Tage beim Update von der Software daneben und sage jetzt hier ein Copy, jetzt hier ein Symlink. Ich bin auch schmerzgeplagt. Der Kund ist jetzt soweit, dass er es doch irgendwie doch Image ist und Ahnens benutzen möchte. Ist auch billiger. Genau, dann die Überwachung und Protokollierung. Das ist der, wo man immer sein Betriebsrat erklären muss. Es wird alles gut, wir machen keine Mitarbeiterüberwachung. Es ist nichts was gegen die Mitarbeiter verwendet wird. Es sollte im Mitarbeiteresleben leichter machen. Es ist wirklich einfach messen, was im System passiert. Lock-Dateien, wenn es Fehler gibt, stellen, ist nichts Böses. Zu schauen, welche Anfragen extrem lange dauern, ist nichts Böses. Man muss erstmal den Betriebsrat erklären, warum das Tool gut ist. Wie ein Konzern unterwegs ist, wird das ganz häufig haben. Wie eine Kommunikation. Jetzt habe ich es angedroht. Es gibt so magische Basis, die man in seinem Chef sagen kann, wenn man es haben will. Ein Teil, ich fange von unten an, Sicherheit. Wenn ich automatisch deploy, meine Prozesse sauber laufen und auch schnell reagieren kann, habe ich natürlich mehr Sicherheit. Ich habe Teams zusammenarbeiten können. Ich kann skalieren. Ich kann, wenn irgendwas auftritt, schneller eingreifen, schneller reagieren. Ich habe mehr Zuverlässigkeit. Ich habe die raschere Bereitstellung in die Standard-Basswürze, die man da hört. Die Folien sind dann auch alle im Wiki. Was man auch dann auf den Standard-Folien immer haben sollte, es ist 30-mal schneller, 200-mal kürzere Zeiten und Folien für Management, wenn der Chef einmal fragen hat. Genauso in dem Muster, wunderbar funktionierend, es kostet sich weniger und wir sind schneller. Brauche ich es euch nicht erklären. Was haben wir bei uns in der Firma dafür gemacht? Wir haben bei uns fast alles Service- und dessen Richtung Docker umgezogen, dass wir Docker-Dienste bereitstellen können, weil es halt einfach reproduzierbar getestet werden können. Wenn es auf dem Entwickler-Rechner in dem Docker-Container funktioniert, ist die Wahrscheinlichkeit sehr viel höher, dass es auch auf den Produktivsurfer und auf den Testsurfer einem Docker funktioniert. Und es kann nicht von Hand im Docker reingepfuscht werden. Haben wir einigen alten Entwicklern sehr viel Schmerzen bereit, wo wir gesagt haben, du darfst nicht mehr im Live-System die etwas ändern, das ist jetzt ein festes Image. Ja, ich muss ein Hotfix einspielen. Du musst ein Hotfix im Git einstecken, dann gibt es die ICD-Umgebung, da wird etwas gebaut und das kann man ausrollen. Hat man ein bisschen Schmerzen bei alten Entwicklern? Jetzt kann man einmal wieder die Werbefolien von AWS und Atlassian sehen. Bei Atlassian ist es eine continuous Integration-Acht, AWS hat es mit seinen Services geschrieben. Man will immer das Gleiche machen. Man baut seine Tools, man testet automatisiert, man überliest es, und dann schaut man, was passiert. Das heißt, man monitort die Tools und das, was man als Feedback bekommt, wird auch wieder in den Prozessen mit reingenommen, dass wir da kein Stress haben, dass wir einfach Feedback haben, was muss gemacht werden. Das zweite, was wir gemacht haben, außer, dass wir automatisch bauen, wir haben es mit Ernstbild gemacht. Man kann es ganz auch mit Chef machen, man kann es nur mit dem Arktur gelohnt haben. Wir haben es mit dem Chef gemacht, wir wollten nur keinen zentralen Master haben. Wir wollten mit reproziberer Config deployen können. Das ist das Wichtigste, was wir da haben, soll es bei KONFIG as Code. Ich habe einmal festgeschrieben eine Konfiguration und die wird ausgerollt. Mit der Kommando-Zeit lockt sich auf den Surfer ein und rollt seinen magischen Bapescript aus. Ich mach das noch jemand bei euch. Traut sich jemand, Okay, also man sollte wirklich das manuelle eingreifen wirklich wegkriegen. Wie man es auch nutzt, wir professionieren komplett auch AWS und alles darin automatisiert. Es gibt glaube ich vor mir den Vortrag mit Heimstoffe automatisieren, einfach wirklich das Tag automatisieren und Config-S Code und bitte nicht Config-S Wiki-Seite. Ich will keine Config-Fycin und herprobieren. Gut, das bringt mich in einer der Zeit auch zur letzten Folie. Habt ihr noch Fragen und übrigens versuchen Mitarbeiter. Der wichtige Teil ist, habt ihr noch Fragen? Also wenn ihr Fragen habt, zeigt auf, ich bringe das Mikro zu euch, damit auch der Stream alles gut hören kann. Ansonsten, ich bin auch offen für Feedback, wenn ihr mir gar nichts zustimmen, wenn ihr Sachen anders seht. Feedback ist ein wichtiger Teil von der Kultur. Ich habe mal was über Google SRE gelesen und wie die dann ihre KPIs oder Verfügbarkeit messen, bzw. Zielvorgaben geben und wenn da Puffer übrig ist, dann erlaubt man eben auch der IT mal höhere Frequenz Sachen zu ändern, damit es halt viel schief läuft, muss man wieder ein bisschen länger warten. Was ist das von diesem Ansatz? Oder kennst du ihn? Den Ansatz kenne ich nicht, aber es klingt extrem vernünftig, seine IT auch Luft zu geben. Wer ein IT auf 100% fährt, der hat nicht verstanden, wie es zu Themen funktioniert. Also es gibt bei dem Sales Training, wo ich mal war, die Ansage, wenn die IT nur Feuerwehr macht, dann haben wir zwar gelöschte Brände, wir können aber das Entstehenneuerbrände nicht verhindern. Selbst ein IT sollte eigentlich auf 80% laufen. Man muss neue Tools einschauen, man muss sich neue Techniken einarbeiten. Es ist absolut nichts skalieren, nichts zielführend, irgendetwas auf 100% Last zu betreiben. So, ich habe hier hinten eben noch eine Frage gesehen. Danke, dass wir das noch mal aufzeigen. Es ist einmal, dass die beiden Themen Bereiche Operations und Entwicklung, aber hast du das auch mal versucht, auf andere Gebiete zu übertragen, wie zum Beispiel QA in Entwicklung? Also da gibt es ja auch so ein paar, die voneinander nichts wissen wollen und halt ich auch immer für schädlich. Ja, dass sie nichts wissen wollen, ist der größte Fehl. Wenn eine Abteilung zu einer anderen Abteilung, ist das Schwachsinn ohne Ende. Also da kann man jetzt auf das Agile-Vorgehen verweisen. Man hat Expertner aus allen Abteilungen im Team drinnen. Der Datenbanken muss mitentwickeln, aber macht auch Datenbanken. Man hat in seinem Team auch ein Tester drinnen, der ist total auf Schwachsinn, dass man sagt, wir werfen es über den Zaun, jetzt sind die Tester dran. Man führt die Teams zusammen und das soll alles ein engeres Mitarbeiteneinander werden. Das Denken, Abteilungen und Gruppen ist absolut kontraproduktiv, macht so wie Prozesse kaputt, deshalb ist es wirklich für ein Erfolg von Gesamten wichtig, dass die Teams zusammenarbeiten. So, weitere Fragen? Dann war das sonst ziemlich die Punktlandung. Ja, es kommt noch eine kurze Frage von mir auch. Du hattest ja Enzybil angesprochen und auch, dass die Obstleute dann nicht noch irgendwelche Shell-Magie machen sollen. Was hältst du von solchen bekannten Enzybilrollen? Shell-Exec, Shell-Exec, Shell-Exec, Shell-Exec? Du hast gesehen, was passiert, wenn man das macht, da kommen eine fette rote Warnung, dass man das nicht machen soll. Es gibt Befehle, die kann man teilweise nicht anders machen, dann sollte man sich überlegen, warum man den Befehl wirklich da braucht. Also generell ist es keine empfohlenen Praxis, das zu tun. Es gibt in der Regel immer Pakete dafür, um es zu unterstützen, please don't do it. Dann vielen Dank Felix.