Wie KI DevOps- und SRE-Praktiken transformieren wird | Better Stack Podcast Ep. 12
BBetter Stack
Computing/SoftwareAuto EnthusiastManagementTelecommutingMental HealthInternet Technology
Transcript
00:00:00Ich drücke es mal so aus: Öffne ein Claude-Code-Projekt und bitte es, dir eine Brücke zu entwerfen
00:00:05oder einen Wolkenkratzer.
00:00:08Und dann möchte ich, dass du diesen Entwurf nimmst und ihn tatsächlich baust.
00:00:12Und dann möchte ich, dass du dich hineinsetzt. Wäre dir dabei wohl?
00:00:16Wäre es für dich in Ordnung, über diese von ihm entworfene Brücke zu fahren?
00:00:19Genau, bis du aufhörst, den Kopf zu schütteln. Wir brauchen diese Ingenieure vor Ort.
00:00:25Willkommen beim Better Stack Podcast, in dem wir Gespräche über Softwareentwicklung, KI und alle Arten neuer Technologien führen.
00:00:32Ich bin einer deiner Gastgeber, Andris, und heute werde ich begleitet von Wishes, hallo
00:00:38und Amin Astani. Hi Amin, wie läuft's? Freut mich, dich hier zu haben!
00:00:44Ja, äh, danke, dass du mich eingeladen hast. Es ist mir eine große Freude. Also, nach dem, was ich über dich weiß,
00:00:51habe ich den Eindruck, dass du
00:00:53schon fast wie ein SRE-Wizard. Du bist da sehr tief drin, moderierst deinen eigenen Podcast zu dem Thema
00:01:01Da sind wir natürlich neugierig: Wie hast du in diesem Bereich angefangen? Und wie sah dein bisheriger Weg
00:01:08in der Softwareentwicklung aus?
00:01:11Ja, gute Frage, Andris und Richard. Danke, dass ich da bin. Ja, wie habe ich angefangen?
00:01:17Nun, als ich in der Highschool war, hat mir die Mutter meiner Freundin Red Hat Linux gezeigt.
00:01:23Sie belegte einen Informatikkurs an einem Community College und hat mir
00:01:29einfach ihren Desktop gezeigt, der weder Windows noch Mac war. Ich war völlig verwirrt. Es war ein KDE-Desktop auf Basis von
00:01:37Red Hat Linux, und ich war fasziniert. Ich fing an, mich damit zu beschäftigen, damals in der elften Klasse der Highschool.
00:01:44Und dann habe ich mein ähm...
00:01:47Informatikstudium gemacht und mich sehr für Infrastruktur interessiert, sehr für Betriebssysteme und dafür, Computern Dinge beizubringen,
00:01:55die wir vorher nicht kontrollieren konnten. Das war also der Anfang.
00:02:00Du warst also schon immer ein Befürworter von Open-Source-Software, nehme ich an, wenn du Linux benutzt?
00:02:06Oh, zu 100 %.
00:02:08Linux ist mein Hauptbetriebssystem
00:02:10seit über zwei Jahrzehnten jetzt, also seit
00:02:122005.
00:02:15Okay. Ja, und wann kam der Punkt, an dem du dich ernsthaft mit SRE beschäftigt hast?
00:02:20Ja, das war vor etwa 10 Jahren. Zuvor war ich ein klassischer Operations-Mitarbeiter bei einem rasant wachsenden
00:02:29PaaS-SaaS-Unternehmen namens Acquia. Falls du jemals von Drupal gehört hast – der Gründer des Open-Source-Projekts Drupal
00:02:34hat dieses Unternehmen gegründet, und sie machten die professionellen Dienstleistungen, das Hosting und den Support für Drupal-Websites.
00:02:38Ich war also in deren Operations-Team, aber während das Unternehmen wuchs – und es war ein raketenartiges Wachstum –
00:02:45gab es viele, viele große Kunden, deren Namen man kennt. Mit diesem Maßstab kam viel manuelle Plackerei. Da haben wirs.
00:02:51Jetzt sprechen wir über SRE. Es gab viel manuelle Plackerei, es gab viele Vorfälle.
00:02:55Wir stießen langsam an die Realität des Betriebs im großen Maßstab im Vergleich zu der Architektur,
00:03:01mit der wir ursprünglich begonnen hatten, und den Prozessen, mit denen wir gestartet waren. Also fing ich an, The Phoenix Project zu lesen. Ich fing an,
00:03:09mich mit Cloud System Administration zu beschäftigen, dem ersten Buch über SRE.
00:03:12Es war nicht das Google-SRE-Buch, das Thema SRE nahm darin nur ein paar Seiten ein, und es enthielt 12 Praktiken.
00:03:17Und auch da war ich sehr, sehr fasziniert und fing an, es anzuwenden.
00:03:21Und ich weiß eigentlich gar nicht, was The Phoenix Project ist. Oh je!
00:03:26Ja, ja. Also, The Phoenix Project war sozusagen das ursprüngliche DevOps-Buch.
00:03:31Ähm, und es ist ein wirklich gutes Buch.
00:03:34Ja, es ist eine Geschichte und es handelt von
00:03:39dem VP of IT Operations, der sich mit einigen schwerwiegenden organisatorischen Problemen herumschlagen muss,
00:03:45und wie er durch die Anleitung eines geheimnisvollen Mentors, von dem man später erfährt, dass er ein Vorstandsmitglied des Unternehmens ist,
00:03:53etwas beigebracht bekommt über
00:03:55etwa
00:03:56alte Fabrikfertigungskonzepte und wie sich diese direkt auf Softwaretechnik und IT-Ops anwenden lassen. Und
00:04:05es stellte viele Konzepte vor, die ich auch heute noch verwende und mit Kunden bespreche, weil sie extrem relevant sind.
00:04:11Das war also das ursprüngliche Buch, aber darüber hinaus
00:04:13habe ich eine ganze Menge Zeug gelesen, vieles davon aus der Welt des Managements.
00:04:18Zusätzlich zu all den technischen Dingen, die ich las, um mich als SRE und Softwareentwickler weiterzubilden,
00:04:24gibt es eben auch die Managementseite, denn DevOps und SRE sind eine soziotechnische Praxis.
00:04:29Du schlägst eine Brücke zwischen dem, was Technologie leisten kann, und wie Menschen sie nutzen, um gute geschäftliche Ergebnisse zu erzielen.
00:04:36Und ich schätze, da ist eine Menge menschliches Versagen im Spiel und im Umgang damit, oder?
00:04:42Ich meine, ja. Absolut. Verdammt, es gibt ein Buch über menschliches Versagen, das du wahrscheinlich auch lesen solltest.
00:04:50Ja, äh, es gibt einen Gentleman – sein Name entfällt mir im Moment leider –, aber er ist
00:04:57so eine Art Professor in Sydney, Australien, und alles, worüber er spricht, sind Flugunfälle und wie menschliches Versagen...
00:05:05Das ist riesig, das ist sehr nützlich in der Post-Mortem-Kultur. Menschliches Versagen ist nicht das Ende.
00:05:10Wenn man sagt: „Oh ja, der Grund für diesen Vorfall, diesen Produktionsvorfall, war menschliches Versagen“ –
00:05:16nein, das ist der Anfang der Diskussion, das ist nicht das Ende. Welche Faktoren haben dazu beigetragen,
00:05:21dass diese Person an diesem Ort den Befehl vertippt und die Produktionsdatenbank in die Luft gejagt hat?
00:05:27Hätte sie überhaupt Zugriff auf die Produktionsdatenbank haben sollen? Waren die Tools ergonomisch? Hatte er letzte Nacht geschlafen?
00:05:34Wie oft wurde er angepigt? Weißt du, da spielen alle möglichen Dinge eine Rolle.
00:05:38Aber ja, wenn Leute „menschliches Versagen“ sagen, muss ich sofort an dieses Buch denken. Ich muss dir dafür mal einen Link für die Shownotes geben.
00:05:45Ja, ich erinnere mich glaube ich an meine erste
00:05:49Einführung in End-to-End-Tests: Ich hörte einen Kurs, in dem jemand von einem Vorfall erzählte,
00:05:54bei dem eine Software für Chirurgen entwickelt worden war
00:05:58und man bestimmte Schaltflächen in einer bestimmten Reihenfolge anklicken musste.
00:06:03Aber die Chirurgen hatten sich so sehr daran gewöhnt, dass sie sie so schnell anklickten,
00:06:07dass die Software anfing zu spinnen, und niemand hatte erwartet, dass das passieren könnte.
00:06:13Das ist also ziemlich interessant.
00:06:15Ja, absolut, die Schnittstelle zwischen Mensch und Automatisierung ist etwas, dem wir bei den Produkten, die wir betreiben, immer Aufmerksamkeit schenken müssen.
00:06:25Ja.
00:06:26Und dann habe ich auch gehört, dass du
00:06:28während der Pager-Ära mit DevOps und SRE begonnen hast, wo man Piepser benutzen musste. Stimmt das?
00:06:35Ja, tatsächlich, ja. Als ich das erste Mal On-Call war, wurde mir ein physischer
00:06:42Pager ausgehändigt. Und man muss sagen – oh wow, welches Jahr war das?
00:06:46Das war 2005.
00:06:48Oh wow, okay. Also mein allererster Tech-Job – oh, das ist großartig.
00:06:55Ich arbeitete in einer Garage, wie jedes erfolgreiche Startup es tut, in Plant City, Florida.
00:07:02Der Vater einer guten Freundin
00:07:04hatte ein Nebenprojekt, bei dem er Webhosting, E-Mail-Hosting und einen Dial-up-ISP von seiner Garage aus betrieb.
00:07:12Er heißt Curtis Fellaini. Ich habe großen Respekt vor ihm, und er ähm
00:07:18brachte mir alles bei, was ich wusste. Aber ja, wir haben dieses On-Call-Tool namens What's Up Gold laufen lassen.
00:07:24Und alles, was es tat – der Name kommt mir bekannt vor –, es machte keine HTTP-Prüfungen,
00:07:33sondern es führte ICMP-Pings zu den Servern durch, also ganz klassisches Pingen. Und wenn es kein Ergebnis zurückbekam,
00:07:40schickte es
00:07:42einen Pager-Ruf. Ich habe eine Weile einen Pager mit mir herumgetragen, als ich dort arbeitete.
00:07:48Unmittelbar danach, als ich an meiner Alma Mater im Bereich Supercomputing/HPC arbeitete, war es Nagios
00:07:54und Textnachrichten auf das Mobiltelefon.
00:07:57War das eine bewusste Entscheidung oder gab es zu diesem Zeitpunkt bereits neuere Technologien wie eben SMS und so weiter?
00:08:07Ich meine, ja, damals gab es einfach mehr Tools,
00:08:11zwar begrenzt, aber es gab mehr verfügbare Werkzeuge zur Überwachung
00:08:15der Infrastruktur. Und als ich in der HPC-Abteilung der University of South Florida war,
00:08:22hatten wir es bereits mit Hunderten von Servern zu tun, weil es eben HPC ist.
00:08:27Man hat Racks voller Server, die Rechenjobs ausführen. Wir brauchten also
00:08:31etwas mehr als
00:08:34nur einen Pager. Und auch der Inhalt der Pager-Nachricht war wichtig, denn wenn man einfach nur
00:08:40eine Nachricht bekam: „Oh, okay, ich muss nachschauen, was das Ding vom Piepser will“, war das mühsam,
00:08:45aber mit Nagios bekam man zumindest etwas Kontext, etwa dass dieser Server
00:08:50ausgefallen ist oder dieser mit dem Server verbundene Dienst down ist. Selbst damals
00:08:56hatte man also schon eine gewisse Raffinesse, was die Konfiguration
00:09:01anging,
00:09:03was man pro Host oder pro Dienst überwachen wollte.
00:09:06Das war definitiv lange vor SLOs, daran dachte damals noch niemand.
00:09:13Wir dachten nur darüber nach: Ist dieser Port offen und liefert er die erwartete Antwort?
00:09:17Ja, wow, 2005, da war ich glaube ich in der Mittelstufe. Da habe ich noch gar nicht an
00:09:26Informatik
00:09:28gedacht.
00:09:30Ja, man sieht es mir nicht an, aber ich bin älter, als ich aussehe. Ja, ich merke schon. Nun, du siehst sehr gut aus. Vielen Dank!
00:09:37Also, ich habe ein bisschen recherchiert, du hast wohl bei Meta gearbeitet. Was hast du dort gemacht?
00:09:43Und wie war es, bei Meta zu arbeiten?
00:09:45Oh je. Ähm, ich war Production Engineer
00:09:48und Production Engineering Manager.
00:09:52Das bedeutet im Grunde deren Version von SRE. Und ich habe an zwei Projekten gearbeitet: Das erste Projekt, nur für ein paar Monate,
00:10:00war ein Team namens Conveyor. Es gibt dazu tatsächlich öffentlich zugängliche IEEE-Parks über
00:10:06Conveyor. Conveyor ist wahrscheinlich eines der größten CD-Systeme der Welt.
00:10:11Alle Build-Artefakte, die für die Backend-Dienste bei Meta erstellt werden,
00:10:18laufen durch Conveyor, und es gibt ein schrittweises Rollout aller Änderungen für Tausende über Tausende über Tausende von Backend-Diensten.
00:10:25Sind die streng intern bei Meta?
00:10:29Nur intern, ja.
00:10:31Aber ja, es gibt einen Artikel von Boris Gubrick, den du dir mal durchlesen solltest,
00:10:37über das, was sie aufgebaut haben, und das ist sehr, sehr interessant.
00:10:39Ich war also ein paar Monate dort, als sie das System skalierten,
00:10:43und half ihnen bei der Alarmierung, denn anfangs,
00:10:46wie das eben so ist, bekam man Hunderte von Alarmen pro Woche, und ich dachte mir: Moment,
00:10:49lass uns das mal aufräumen und
00:10:51weißt du, die Observability so weit bringen, dass sie zumindest wussten, wann Ausfälle stattfanden. Und dann habe ich auch
00:10:58einige
00:11:00wie soll man sagen, Notfallprozeduren ausgearbeitet, um wichtige Funktionen über ihr Feature-Flagging-Tool abzuschalten,
00:11:06einfach um sicherzustellen, dass wir uns schnell von Vorfällen erholen konnten.
00:11:10Das habe ich also ein paar Monate gemacht, aber den Großteil meiner Zeit verbrachte ich
00:11:13in einem anderen Team, das
00:11:16so eine Art internes Heroku war. Man hat dort sehr einfache zustandslose Dienste,
00:11:23und Teams stampfen diese Dinger ständig aus dem Boden, und man muss sie irgendwo betreiben, und dieses
00:11:29Team und dieser Dienst existierten, um diesen Prozess zu vereinfachen, denn früher war das Einrichten eines Dienstes sehr schwierig. Ich war also der erste
00:11:37Production Engineer
00:11:40in diesem Team, und das war ziemlich abgefahren. Aber das habe ich dort gemacht.
00:11:44Es hat auf jeden Fall viel Spaß gemacht. Es gab Leute, mit denen ich zusammengearbeitet habe,
00:11:48deren Gehirne einfach fünfmal so groß
00:11:51waren wie meine, weißt du? Die Leute, mit denen man bei solchen Unternehmen arbeitet, sind einfach
00:11:55super brillant, und ich habe dort eine Menge gelernt. Ich wollte gerade sagen, ich glaube, es gibt ein Unternehmen namens Honeycomb, und
00:12:02die Person, die es gegründet hat, Charity Majors, war die bei Meta?
00:12:06Kennst du sie? Hast du sie getroffen?
00:12:09Ähm, das ist sehr, sehr interessant,
00:12:12dass du fragst. Ich habe sie vor anderthalb Jahren auf einer Observability-Days-Veranstaltung in Boston persönlich kennengelernt.
00:12:20Ja, sie hat bei Meta gearbeitet, äh,
00:12:22und die Inspiration für Honeycomb stammte von einem
00:12:26Observability-Tool im planetarischen Maßstab namens Scuba,
00:12:30genau. Ich habe Scuba also genutzt und es geliebt, und ich freue mich sehr, dass sie äh
00:12:37ein Unternehmen gegründet hat, um das zu tun. Sie und ich haben uns in letzter Zeit auf LinkedIn ab und zu ein wenig unterhalten,
00:12:44wegen unseres gemeinsamen Interesses an
00:12:47der Frage, wie agentisches Programmieren die Zuverlässigkeit beeinflussen wird.
00:12:51Wir haben uns also immer mal wieder über dieses Thema ausgetauscht.
00:12:54Aber ja, sie ist eine echt coole Person und es ist ein Privileg, sich hin und wieder mit ihr zu unterhalten.
00:12:59Ja, ja, das ist eigentlich eine schöne Überleitung zu dem, was wir dich auch fragen wollten: Wo siehst du die Zukunft von KI
00:13:06für SRE, DevOps und all diese Praktiken?
00:13:13Oh je, okay. Also, fantastischer Werbeblock, vielen Dank. Ich steige direkt in die These ein.
00:13:19Wir haben Softwareentwickler, denen ein
00:13:24fantastisches Werkzeug an die Hand gegeben wurde, nämlich die agentische Entwicklung. Jeder kriegt wie von Zauberhand Code generiert, auf Wunsch von Tools wie Claude und so weiter.
00:13:35Das bedeutet also, dass eine um eine Größenordnung größere Menge an Code
00:13:39durch unseren
00:13:42Value Stream fließen wird: unsere CI/CD-Pipelines, unsere Tests, unsere Reviews, unsere Code-Deployments, unsere Incident Response, unsere Change-Management-Prozesse –
00:13:50all dieser Code wird durch dieses System fließen, das jeder von uns für seine Firma aufgebaut hat.
00:13:56Und das bedeutet, dass wir all diese Fähigkeiten
00:13:58einem Stresstest unterziehen werden. Zum Beispiel
00:14:01gibt es eine lineare
00:14:04Beziehung
00:14:06zwischen der Anzahl der Änderungen, die man an einer Software vornehmen kann, und der Anzahl der Pager-Alarme oder Incidents,
00:14:12die man erhält.
00:14:14Das ist
00:14:15eine erwiesene Tatsache. Es ist also nur vernünftig anzunehmen, dass wenn man den Code-Durchsatz
00:14:20durch seine Pipeline verzehnfacht,
00:14:23man auch zehnmal so viele Alarme hat.
00:14:26Die Frage ist also wirklich, wie eure Organisation darauf reagieren würde. Aus SRE-Sicht erwarte ich also,
00:14:32dass wir Operations-Leute in Zukunft sehr äh
00:14:39sehr gefragt sein werden, weil wir den Flaschenhals darstellen.
00:14:42Es geht nicht mehr darum, Code zu schreiben und auszuliefern, sondern darum, wie wir ihn betreiben.
00:14:49Funktioniert er? Erfüllt er die Erwartungen der Kunden?
00:14:51Ähm
00:14:53und
00:14:55deshalb gehe ich davon aus, dass dies der große Wandel sein wird.
00:14:58Das ist eine riesige Herausforderung, denn während dieses Übergangs kann eine Menge schiefgehen.
00:15:04Man kann, wie ich bereits erwähnte, viel mehr Incidents haben. Lernt ihr aus Fehlern
00:15:09und führt ihr weiterhin Postmortems durch? Baut ihr eine CI/CD-Pipeline auf, die tatsächlich funktioniert
00:15:15und im Grunde dafür sorgt, dass menschlicher Aufwand immer einen großen Hebel hat?
00:15:20Das Witzige ist also, dass wir uns seit Jahrzehnten auf dieses Ereignis vorbereiten. Nur eben,
00:15:27es gewohnt sind, in Maßstäben von Big Tech zu denken, wo man 20.000 Ingenieure hat,
00:15:31aber
00:15:33jetzt haben wir kleinere Organisationen, die das Zehnfache an Code produzieren und somit denselben Durchsatz haben.
00:15:38All diese Grundlagen also,
00:15:40über die größere Unternehmen im vergangenen Jahrzehnt geschrieben und gesprochen haben, die
00:15:47müssen jetzt plötzlich wir alle anwenden.
00:15:49Man muss die Grundlagen tatsächlich umsetzen. Und dann gibt es noch
00:15:53die Tatsache, dass
00:15:56Softwareentwicklungsorganisationen sich um die Idee herum organisiert haben: Oh, das Coden dauert am längsten,
00:16:03das ist der größte Zeitfresser,
00:16:05also müssen wir sicherstellen, dass Ingenieure so viel Zeit wie möglich mit Coden verbringen. Wenn das nicht mehr stimmt,
00:16:09müssen wir uns um die Aktivitäten herum neu organisieren, die jetzt am meisten Zeit in Anspruch nehmen.
00:16:15Es wird also einen gewissen Wandel geben bezüglich der Art und Weise, wie wir diese Organisationen führen. Und schließlich,
00:16:20und ich denke, das hast du im Trend der KI-gestützten SRE gesehen,
00:16:23worüber ich oft und in meinem Podcast gesprochen habe, werden wir diese Technologie geschickt
00:16:31dort einführen müssen, wo es angebracht ist, wo wir einen großen Hebel daraus ziehen können, um diesen Betrieb zu bewältigen, richtig?
00:16:37Denn es gibt zum Beispiel Unternehmen da draußen – ich glaube, ein gutes Beispiel ist incident.io –, da wirst du angepaged,
00:16:44und noch bevor du aus dem Bett aufstehst,
00:16:47gibt es bereits einen agentischen Workflow, der sagt: Okay, welche Änderungen wurden kürzlich an der Codebasis vorgenommen?
00:16:53Was sagen die Alarme wirklich? Was sagen die Metriken wirklich? Und versucht,
00:16:59eine erste Diagnose zu stellen, noch bevor du überhaupt aus dem Bett bist und den Schlaf aus den Augen gerieben hast.
00:17:04Es gibt also einige Bereiche in unseren operativen Verantwortlichkeiten, die
00:17:09großen Nutzen aus KI ziehen können, aber man übernimmt nicht einfach alles.
00:17:12Man muss darüber nachdenken, was die tatsächlichen Probleme sind und wie der ROI aussieht.
00:17:16Aber wie dem auch sei, das ist meine These. Ich halte dazu in ein paar Wochen sogar ein Webinar zu genau diesem Thema.
00:17:23Das ist so interessant, denn der Anwendungsfall, den du vorhin erwähnt hast:
00:17:29Man wacht auf und wird wegen irgendetwas angepaged –
00:17:32wurde das in der Praxis schon umgesetzt? Denn
00:17:36eine Sache, bei der ich sehe, dass sie schiefgehen kann, ist: Nehmen wir an, es gibt Triage-Stufen, bei denen die KI bei der ersten Triage
00:17:43das Problem vielleicht alleine lösen kann. Aber im nächsten Schritt brauchen wir einen Menschen im Prozess.
00:17:51Und manchmal, um einen Vergleich zum Coden zu ziehen, sehe ich bei Claude Code während des Reasoning: „Ich sollte das tun“ – und dann denkt es sich:
00:17:56„Moment mal, nein,
00:17:59ich sollte
00:17:59das wahrscheinlich alles löschen und von vorne anfangen und das machen.“
00:18:02Und ich habe das Gefühl, dass dasselbe bei diesen Incident-Management-Bots passieren könnte. Sie denken sich: „Oh, das ist ein leichter Fix.
00:18:10Moment. Vielleicht kann ich es alleine lösen“, in solchen Situationen.
00:18:13Nein, da hast du zu 100 % recht.
00:18:15Ich glaube, dieses Zitat von IBM aus den 1970er Jahren hat in letzter Zeit die Runde gemacht: Überlasse niemals einem Computer eine Managemententscheidung.
00:18:22Was ich damit meine: Es gibt zwei Arten, wie man diese
00:18:27KI-Werkzeuge
00:18:29oder Automatisierung im Allgemeinen nutzen kann. Es gibt zwei Philosophien zur Automatisierung,
00:18:32über die geschrieben wurde. Die erste nennt sich das „Leftover-Prinzip“, bei dem man im Grunde sagt: Oh, okay. Wir lassen Software
00:18:38– das muss nicht mal KI sein, das können einfach Tools sein – all diese Dinge für uns erledigen,
00:18:43autonom in unserem Namen. Wir müssen nicht darüber nachdenken.
00:18:46Und wir Menschen bekommen dann das übrig Bleibende, was typischerweise der Kram ist, zu dessen Lösung man einen Doktortitel braucht.
00:18:51Ähm,
00:18:53das ist
00:18:54nicht sehr praktikabel, weil man dann sein gesamtes Budget für Doktortitel ausgibt
00:18:57und außerdem zu viel Vertrauen in ein autonom laufendes System setzt; und wenn das die falsche Entscheidung trifft, steckt man in Schwierigkeiten.
00:19:04Die
00:19:07praktikablere Philosophie ist das sogenannte „Kompensationsprinzip“, bei dem man die menschliche Arbeitskraft verstärkt.
00:19:15Man lässt Computer und Automatisierung die Dinge tun, die sie gut können, und man lässt die Menschen die Dinge tun,
00:19:22die Menschen gut können,
00:19:25nämlich:
00:19:26Wir verstehen den Kontext unserer Systeme. Wir verstehen das Problem, das wir lösen wollen, und wir verstehen das Kundenerlebnis.
00:19:33Unser Gehirn enthält so viel Kontext, dass es viel...
00:19:38vorteilhafter für uns ist, diesen zu nutzen, anstatt die KI alles machen zu lassen. Um deine Frage direkter zu beantworten:
00:19:44Ich denke, diese KI-Umstellung sollte wirklich nicht dazu führen,
00:19:50Änderungen an der Produktion vorzunehmen, es sei denn, es geschieht auf einem gut eingegrenzten, klar definierten Pfad.
00:19:58Ich nenne dir ein Beispiel: automatisches Rollback von Code. Das machen wir bereits vollautomatisch ohne KI, wenn man an Kubernetes denkt,
00:20:06oder? Wenn man ein Deployment hat und die Version des neuen Container-Image ändert und die...
00:20:13Readiness-Prüfungen fehlschlagen, rat mal was passiert?
00:20:16Die Änderung wird nicht ausgerollt.
00:20:19Genau. Solche Mechanismen sind sehr einfach, leicht zu durchdenken und sie ermöglichen es uns, Änderungen sicher durchzuführen.
00:20:26Weißt du, solche klar definierten Probleme kann man der Automatisierung überlassen, und das tut sie bereits.
00:20:32Aber wenn man jetzt...
00:20:35der KI einfach erlaubt zu sagen: Ja, wir sollten diese Änderung an unserer Infrastruktur ohne menschliches Zutun vornehmen,
00:20:41halte ich das für unverantwortlich. Ich denke, wir Menschen – um auf den Punkt mit den Einschränkungen zurückzukommen –
00:20:46werden unsere Zeit darauf verlegen müssen zu fragen:
00:20:49Ist das wirklich die richtige Entscheidung?
00:20:52Weißt du, diese Genehmigungen, Code-Reviews und die Prüfung jeglicher Infrastrukturänderungen
00:20:59werden schätzungsweise der Bereich sein,
00:21:00in den wir viel Mühe stecken werden.
00:21:03Und ja, wir werden das automatisieren wollen, wo es möglich ist, aber das erfordert Disziplin und eine Sicherheitsbilanz.
00:21:09Ja, und eine weitere Frage zu dem, was du vorhin gesagt hast, betrifft diesen linearen Vergleich: Je mehr Code man hat,
00:21:19desto mehr Vorfälle wird es geben. Du arbeitest ja als Berater
00:21:22in diesem Bereich. Hast du mitbekommen, dass Unternehmen das gerade erleben, wie
00:21:28seit sie
00:21:30mehr Code
00:21:31ausgeben oder an die KI auslagern, infolgedessen mehr Vorfälle auftreten?
00:21:36Durchaus, auf jeden Fall.
00:21:39Auf jeden Fall, und ich würde noch hinzufügen, dass es auch andere Fehlerarten gibt, die aufgrund
00:21:47dieser
00:21:49Änderung aufzutauchen beginnen. Ein wirklich simples Beispiel, über das man nachdenken kann,
00:21:53ist,
00:21:54dass sich deine CI/CD-Pipelines stauen. Die Latenz zwischen dem Erstellen eines Build-Artikakts und dem Gang in die Produktion dauert immer länger,
00:22:00weil einfach mehr Änderungen durchlaufen. Organisationen spüren also
00:22:05diese Schmerzpunkte bereits. Ich meine, um ein kurzes Fallbeispiel zu nennen: Ich habe einen
00:22:12Kunden, für den ich kürzlich eine Bewertung durchgeführt habe, da ich unter anderem untersuche,
00:22:17wie die operative Ausrichtung des gesamten Unternehmens aussieht, wie sie Code ausliefern und betreiben, und ihnen Ratschläge für die nächsten Schritte gebe.
00:22:24Eines der Teams meinte also: Ja, dieses KI-Zeug ist wirklich gut, lasst uns anfangen, Features herauszupumpen.
00:22:31Und das haben sie getan, aber
00:22:33sie haben ihre Releases nicht angepasst und hatten keinen guten, soliden Code-Review-Prozess.
00:22:38Deshalb schoss die Zahl der Vorfälle sofort in die Höhe, sodass sie – anstatt
00:22:43sich auf den Code zu konzentrieren und all die Dinge auszuliefern, die sie sich vorgenommen hatten – von Kundeneskalationen
00:22:49und Vorfällen begraben wurden.
00:22:51Man merkt also: Das ist keine Theorie, das passiert genau jetzt.
00:22:55Diese um Größenordnungen gesteigerte Anzahl von Änderungen in der Produktion
00:23:01wird
00:23:03alle schwachen Glieder in deiner operativen Haltung aufdecken.
00:23:06Und wenn du so etwas wie ein
00:23:09SRE-Arzt bist, der diesen Kunden mit diesem Problem hat – was ist dein Vorschlag, was man in diesem Fall tun sollte?
00:23:16Wie du gerade erwähnt hast:
00:23:18Genau. Ich habe es vorhin schon angedeutet: all diese Grundlagen, über die wir gesprochen haben,
00:23:24müssen wir in den letzten ein bis zwei Jahrzehnten in den Fokus rücken.
00:23:27Teams
00:23:29müssen zum Beispiel eine gültige Teststrategie haben.
00:23:35Sie müssen wissen, dass der Code, den sie in die Produktion bringen wollen, von hoher Qualität ist.
00:23:39All die Dinge, über die sie gelernt haben – ich bin ein großer Befürworter von Service-Level-Zielen,
00:23:43ich bin ein großer Befürworter von SLOs.
00:23:47Denn das versetzt uns in die Lage, den Zustand unseres Produktionssystems aus Kundensicht zu verstehen.
00:23:52Das
00:23:54ist ein wesentliches Puzzleteil, weil es dir ermöglicht, auf datengestützte Weise die Anzahl der Änderungen
00:23:59in der Produktion im Hinblick auf Feature-Anfragen und dergleichen zu regulieren, sodass du
00:24:03deine bestehende Einnahmequelle nicht riskierst,
00:24:07während du neuen Einnahmequellen nachjagst.
00:24:10Das ist der geschäftliche Grund für SLOs. Eines ist mir beim letzten Unternehmen aufgefallen, für das ich gearbeitet habe:
00:24:16Sie meinten:
00:24:19Jedes Team sollte seine SLO-Ziele einhalten. Da wir uns so schnell bewegten, haben einige Teams
00:24:25diese Ziele jedoch nicht erreicht.
00:24:28Viele Teams waren im Rückstand,
00:24:30und die Managemententscheidung lautet: Egal, es ist wichtiger, Features auszuliefern, als SLO-Ziele einzuhalten.
00:24:36Jep.
00:24:37Und das ist vermutlich der Hauptgrund, warum SLOs nicht so effektiv waren, wie Google es vor einem Jahrzehnt versprochen hat.
00:24:44Denn es verhält sich so – und ich habe in früheren Beiträgen darüber gesprochen: Man kann ein SLO-Programm haben,
00:24:49man kann den Prozess durchlaufen, bei dem sich Ingenieure in eine Ecke setzen und überlegen: Was ist die User Journey?
00:24:55Lasst uns das quantifizieren, etwas Observability einrichten,
00:24:57Prometheus oder OpenTelemetry aufbauen und wirklich schicke Dashboards erstellen.
00:25:01Aber wenn der Product Manager,
00:25:05wenn die Produktorganisation nicht mitzieht,
00:25:07wenn das Führungsteam nicht mitzieht,
00:25:09dann
00:25:12ist das Zeitverschwendung.
00:25:14Dann hast du nur SREs und vielleicht Ingenieure, die in einer Ecke arbeiten und sagen: Hey, die Dinge laufen nicht gesund,
00:25:19und weißt du,
00:25:21die Führung will trotzdem weiter ausliefern. Damit ein SLO erfolgreich ist,
00:25:26muss es ein Spiel sein, das alle spielen. Und wenn ich
00:25:32die SLO-Kultur von Organisationen bewerte – was ich viel mache –, neige ich dazu, diese Frage zu stellen: Wenn ein Fehlerbudget aufgebraucht ist,
00:25:38was macht der Product Manager?
00:25:41Wenn der Product Manager sagt: Okay, nächsten Sprint ändern wir den Umfang des nächsten Sprints,
00:25:46gut,
00:25:48befindest du dich auf einem mittleren Reifegrad. Wenn sie das nicht tun,
00:25:50bist du auf einem niedrigen Reifegrad. Ich habe tatsächlich ein SLO-Reifegradmodell von eins bis fünf entwickelt – eins ist unreif, fünf ist optimierend –, um Unternehmen
00:25:58dabei zu helfen zu verstehen, wo sie auf ihrer Reise stehen. Aber du hast recht, viele Organisationen tun das nicht.
00:26:03Sie haben ein Dashboard, sie haben Metriken darauf, Ingenieure werden dafür bezahlt,
00:26:08aber
00:26:10geschäftliche Entscheidungen werden nicht anhand von SLOs getroffen.
00:26:12Es dient nur der Alarmierung.
00:26:16Und in welcher Situation befinden sich die Kunden, die zu dir kommen,
00:26:21sodass sie
00:26:24deine Hilfe benötigen? Sind sie in einer guten, schlechten oder dazwischenliegenden Situation?
00:26:28Das kommt darauf an. Es gibt zwei Wendepunkte, an denen ich tendenziell mit Kunden arbeite. Der erste Wendepunkt ist so etwas wie
00:26:37Ein junges Unternehmen, das gerade eine Finanzierungsrunde erhalten hat, die Vertriebsorganisation boomt, man hat Product-Market-Fit
00:26:44Aber sie sind unerfahren und hatten zuvor noch nie Infrastruktur auf Unternehmensebene.
00:26:49Sie haben noch nie an Unternehmenskunden verkauft und fangen an zu schwächeln
00:26:53unter dem Druck dieser gestiegenen Skalierung – sehr ähnlich wie die Erfahrung, die ich früher in meiner Karriere gemacht habe.
00:26:59Das ist etwas, worüber ich sehr, sehr gut Bescheid weiß, weil ich es selbst erlebt habe. Das ist der erste Wendepunkt.
00:27:04Und das ist ein spannender Wendepunkt. Das ist quasi ein gutes Problem, das man haben kann. Es kann für die dort Arbeitenden stressig sein
00:27:09Der zweite Wendepunkt
00:27:12ist meistens, wenn man eine größere Organisation ist und nun beginnen muss zu standardisieren,
00:27:17wie man über mehrere Teams hinweg operiert.
00:27:21Vielleicht hat man ein SRE-Programm und muss bewerten, wie effektiv dieses ist, ob die Prozesse funktionieren,
00:27:28ob das Beteiligungsmodell funktioniert, ob die Engineering-Teams und Produkt tatsächlich am Prozess teilnehmen.
00:27:34Unternehmen also, die viele Akquisitionen tätigen,
00:27:37kommen typischerweise zu mir, weil sie versuchen, diesen wilden Haufen zu bändigen, denn bei jeder Akquisition
00:27:44gibt es einen völlig neuen Tech-Stack, den sie einbinden müssen. Man muss also über viel übergeordnete Governance nachdenken,
00:27:50um sicherzustellen, dass sich alle an dieselben Regeln halten.
00:27:55Sicher.
00:27:57Und ich denke, bei den kleineren Unternehmen, die du erwähnt hast, denen, die Geld aufgenommen haben –
00:28:02nun, da es KI gibt und die Leute KI nutzen, um Features zu bauen,
00:28:06wird dieser Mangel an Struktur noch zunehmen, weil die Leute einfach Features bauen und sie mit KI ausliefern,
00:28:13ohne an Logs, Metriken, Traces oder ähnliches zu denken.
00:28:16Was sind die größten Dinge, bei denen Leute in dieser kleineren Phase ihres Unternehmens zu dir kommen mit Problemen,
00:28:23die für dich offensichtlich sind, die sie aber nicht als Problem sahen?
00:28:27Ja, ich schätze, ich habe es in einer früheren Antwort schon angedeutet, aber ich werde es von oben nach unten einrahmen.
00:28:34also
00:28:36Das offensichtliche Problem, das ich sehe, ist ein unterbrochener Feedback-Kreislauf zwischen dem, was in der Produktion passiert,
00:28:41und dem, was in der Kundenerfahrung passiert, sowie bei der Produktpriorisierung.
00:28:46Das sehe ich schon lange und bei vielen Teams, bei vielen Teams. Es ist wahrscheinlich das häufigste Problem
00:28:55Wenn ich also als Berater arbeite,
00:28:58überlege ich mir hinter den Kulissen als Erstes, wie ich sicherstelle, dass dieser Feedback-Kreislauf etabliert wird.
00:29:03Es ist also erstaunlich,
00:29:05wie viele Unternehmen einen Vorfall erleben,
00:29:08Kunden verärgert werden
00:29:10und Tickets beim Support einreichen, sodass der Support überflutet wird.
00:29:13Der Support hat dieses wunderbare Geschenk für die Produkt- und Ingenieursorganisation, das sich Feedback nennt. Sie wissen,
00:29:23was die Kunden wütend macht, was sie daran hindert, den Dienst zu nutzen, und was sie möglicherweise zum Gehen motiviert?
00:29:30Und ich habe immer wieder erlebt,
00:29:33dass dieses Feedback völlig ignoriert oder gegenüber der Feature-Arbeit in der Priorität nach hinten gestellt wird
00:29:41und das Endresultat ist dann
00:29:44volle Fahrt voraus bei Features, obwohl das Produkt brennt, und das ist für mich
00:29:51etwas, das mir sofort auffällt, wenn ich Teams interviewe und bewerte.
00:29:55Aber normalerweise, wenn man im Unternehmen arbeitet, sieht man das nicht, weil man denkt: Ich bin Softwareentwickler,
00:29:59ich werde dafür belohnt, Features auszuliefern. Ich habe im letzten Quartal 50 Widgets geliefert, super, ich kriege meinen Bonus.
00:30:05Produktmanager denken genauso:
00:30:07Ja, wir haben diese Projekte herausgebracht. Dieser Kunde unterschreibt bei uns, weil wir das getan haben.
00:30:11Unterdessen sind die bestehenden Kunden völlig außer sich vor Wut. Sie sind unzufrieden mit dem, was passiert,
00:30:16also ein unterbrochener Feedback-Kreislauf.
00:30:19Und liegt das an der Kultur in San Francisco oder einfach daran,
00:30:22dass die Leute einfach besser als ihre Konkurrenten dastehen wollen? Ich weiß nicht. Warum ist das deiner Meinung nach so?
00:30:28Ich glaube nicht, dass das typisch für San Francisco ist. Ich denke, das ist einfach typisch für Unternehmen im Allgemeinen, für Anreizstrukturen,
00:30:36für Unternehmenskulturen, denn
00:30:39wenn
00:30:41man
00:30:42verschiedene Abteilungen hat,
00:30:44was passiert, wenn ein Unternehmen wächst, und das geschieht natürlich, weil man den Aufwand organisieren muss,
00:30:49fängt man an, in Silos zu arbeiten.
00:30:51Ich habe Softwareentwickler hier drüben. Ich habe Produktmanager hier drüben. Vielleicht sind sie zwar integriert
00:30:55in die Engineering-Teams, aber sie haben ihre eigenen Anreize. Und die Support-, DevOps- und SRE-Leute
00:31:01haben ebenfalls ihre eigenen Anreize, aber sie sind alle getrennt und stehen im Widerspruch zueinander.
00:31:06Genau, und
00:31:09normalerweise
00:31:11hat sich zu diesem Zeitpunkt noch niemand mit ihnen zusammengesetzt und gesagt:
00:31:13Wie können wir unsere Anreizstruktur so ändern,
00:31:18dass wir alle in dieselbe Richtung steuern? Eines der Dinge, die Meta getan hat,
00:31:21was mir wirklich gut gefiel und von dem ich glaube, dass es sehr gut funktioniert,
00:31:25war, dass bei der Leistungsbeurteilung eines Entwicklers – zumindest in den Teams, in denen ich gearbeitet habe –
00:31:31nicht nur auf Features geschaut wurde.
00:31:34Sie achteten auf operative Exzellenz und Produktionsexzellenz, und sie schauten sich an: An welchen Vorfällen waren sie beteiligt?
00:31:41An welchen Zuverlässigkeitsarbeiten haben sie mitgearbeitet? An welchen Skalierungsarbeiten haben sie gearbeitet?
00:31:45Wie haben sie das System zuverlässiger und bedienbarer gemacht? Und das wirkte sich darauf aus, ob sie den Bonus bekamen
00:31:51oder ob sie befördert wurden. Es war ein wichtiger Teil
00:31:54der Kriterien.
00:31:57Als sie also
00:31:58dazu übergingen, bedeutete das, dass sich die Anreize für die Softwareentwickler änderten, und in dem Team, in dem ich war,
00:32:05in dem wir das zusammen mit den
00:32:07Entwicklungsleitern, mit denen ich arbeitete, wirklich vorangetrieben haben,
00:32:12kamen diese Entwickler wie von Zauberhand auf mich zu und sagten: Du, ich würde gerne an einigen Zuverlässigkeitsarbeiten mit dir teilnehmen.
00:32:18Kann ich diesen Lasttestprozess übernehmen?
00:32:20Klar, absolut. Hier sind die Runbooks, hier sind ein paar Skripte, leg einfach los.
00:32:25Und es ist erstaunlich, was passiert, wenn sich Anreize verschieben.
00:32:29Das ist also
00:32:31meiner Meinung nach eine natürliche Entwicklung für jede Organisation: Wenn man ein winziges Startup ist, bei dem jeder für alles verantwortlich ist,
00:32:38Finanzierung sucht und versucht, diese ersten Kunden zu gewinnen und bei Laune zu halten,
00:32:43sind die Anreize ohnehin aufeinander abgestimmt.
00:32:45sonst würde das Unternehmen nicht überleben, aber wenn man größer wird und diese Aufgabentrennung hat,
00:32:51wird es immer schwieriger, eine Anreizstruktur zu haben, die über die gesamte Organisation hinweg aufeinander abgestimmt ist.
00:32:55Genau hier kommen also die soziotechnischen Aspekte ins Spiel, wenn wir über SRE und DevOps sprechen.
00:33:00Schön und du hast auch erwähnt, dass bei diesem rasanten Vorstoß mit KI
00:33:06die Leute mehr Menschen wie dich brauchen, die in diesem Bereich arbeiten, und andererseits
00:33:12hören wir, dass die Softwareentwicklung stirbt, dass es keine Jobs mehr gibt, richtig?
00:33:17Glaubst du also, dass für Junior-Entwickler, die diesen Podcast hören,
00:33:23SRE und DevOps zu diesem speziellen Zeitpunkt ein guter Bereich sind, in den man einsteigen sollte? Ja und ja, also
00:33:30ich werde mich dagegen stemmen und ich werde nicht die Person sein, die sagt, dass die Softwareentwicklung tot ist.
00:33:36Ich denke tatsächlich, dass die Grundlagen
00:33:38sogar noch
00:33:41wichtiger sind.
00:33:43Das Verständnis von Programmiersprachen und ihrer Funktionsweise sowie von Algorithmen und ihrer Funktionsweise ist noch wichtiger,
00:33:50weil
00:33:53wie sollen wir den Code überprüfen, den eine KI generiert?
00:33:56Und wie sollen wir Systeme entwerfen, die funktionieren? Denn wenn man einem LLM-Modell einfach sagt: Hey, entwerfe dieses Ding,
00:34:04bist du dir sicher, dass das funktioniert? Ich drücke es mal so aus: Öffne ein Claude-Code-Projekt
00:34:08und bitte es, dir eine Brücke zu entwerfen
00:34:11oder einen Wolkenkratzer
00:34:15und dann möchte ich, dass du diesen Entwurf nimmst und ihn baust
00:34:18und dich dann hineinsetzt. Wirst du dich dabei wohlfühlen?
00:34:22Wirst du dich wohlfühlen, über diese Brücke zu fahren, die es entworfen hat?
00:34:25Genau, bis du aufhörst, den Kopf zu schütteln, brauchen wir diese Ingenieure an Ort und Stelle.
00:34:31Genau, und was SRE- und DevOps-Leute angeht: Ja, natürlich.
00:34:34Es muss mehr von uns geben, denn dort liegt der Engpass. Wenn wir so viele Änderungen am System vornehmen,
00:34:39müssen wir unbedingt sicherstellen, dass es gesund ist, dass wir die Auswirkungen der Änderungen auf die Produktion verstehen,
00:34:43dass wir eine CI/CD-Pipeline, einen Wertstrom haben – wenn ich das auf die höchste Ebene extrapoliere –, der
00:34:51intakt und überwacht ist und wie ein Produktionsdienst behandelt wird. Meiner Ansicht nach werden all diese Fähigkeiten noch wichtiger werden.
00:34:58So wie ich das zu betrachten pflege: Es ist ein bisschen wie in der Formel 1, man hat eine Boxenlanny
00:35:04und diese Boxencrew weiß alles über dieses Fahrzeug, kann jedes Teil austauschen und gibt diesem Fahrer die Möglichkeit, die Rennstrecke zu dominieren.
00:35:12Man braucht diese Leute,
00:35:15weil das den Produktmanagern und Architekten die Umgebung gibt,
00:35:22schnell zu iterieren und diese Änderungen herauszubringen, ohne dass diese Engpässe auftreten.
00:35:27Meiner Ansicht nach
00:35:29also,
00:35:30es ist eine großartige Zeit, ein SRE zu sein. Vor ein paar Jahren war das wohl anders, weil alle entlassen wurden,
00:35:35aber ich denke, dass
00:35:37wenn man sich wirklich auf die Grundlagen konzentriert, wenn man
00:35:39Linux und Systeme sowie die soziotechnischen Aspekte versteht, also im Grunde, was es bedeutet, tatsächlich ein SRE zu sein,
00:35:46dann kann man es meiner Meinung nach
00:35:49sehr weit bringen
00:35:51in dieser Karriere. Aber wir müssen natürlich das Aufkommen der agentischen Entwicklung berücksichtigen.
00:35:57Wir können davor nicht den Kopf in den Sand stecken.
00:35:59Du hast also erwähnt:
00:36:02War das The Phoenix Project? Ja, das Buch.
00:36:05Ja, welche anderen Ressourcen hältst du für wertvoll für jemanden, der sehr tief in dieses Thema eintauchen möchte?
00:36:12Oh Mann, da gibt es jede Menge. Lass mich dir die Standardwerke nennen.
00:36:18Ich meine, das DevOps Handbook ist gut. Als dieses Buch herauskam, fand ich,
00:36:21war es eine großartige Zusammenfassung von allem, was ich vor dem Erscheinen des Buches gelernt hatte. Es ist eine großartige,
00:36:27eine großartige All-in-One-Anlaufstelle. Leading Change von John Kotter
00:36:30handelt von transformatorischer Führung und Change Management in Organisationen.
00:36:34Es gibt dir einen Rahmen, und wenn du SRE in einem Team bist oder eine Zuverlässigkeitstransformation vorantreiben willst,
00:36:41ist es gut, das zu kennen. Das Buch Toyota Kata,
00:36:45das davon handelt, wie Toyota kontinuierliche Verbesserung in der Automobilherstellung betreibt,
00:36:52ist sehr nützlich, sehr nützlich. Einer der Ersten, die sich das System ausgedacht haben. Ja, ich glaube, ich habe davon gehört. Ja,
00:36:59Kaizen
00:37:02war das Konzept von Toyota.
00:37:04Das japanische Wirtschaftswunder ist das, was Agile
00:37:07und DevOps hervorgebracht hat, es war der Vorläufer davon. Ein weiteres Buch: The Practice of System and Network Administration,
00:37:13ich erwähnte es, ich glaube, die haben mittlerweile eine neue Auflage, sehr, sehr nützlich.
00:37:17Ja, und die SRE-Bücher, die Google herausgibt, sind gut, aber ich möchte Einschränkungen machen:
00:37:22Das sind Bücher, die von Leuten geschrieben wurden, die für absolut gigantische Unternehmen arbeiten
00:37:27und ein unbegrenztes Budget haben.
00:37:30Die Praktiken und Vorgehensweisen dort unterscheiden sich also von dem, wie man bei einer
00:37:35Vier-Personen-Startup vorgeht, aber ich denke,
00:37:37wenn man all diese Teile zusammenfügt, erhält man ein Verständnis aus Sicht eines Ingenieurs,
00:37:44aus
00:37:44Sicht einer Führungskraft
00:37:46und aus Sicht eines Strategen dafür, wie man DevOps- und SRE-Initiativen vorantreibt.
00:37:49Daher habe ich glaube ich eine einzigartige Perspektive, weil ich das Ganze ganzheitlich betrachte. Ich gehe nicht nur tief in
00:37:55das Thema ein, dass ich nur Kubernetes mache und Kubernetes zum Laufen bringe. Ich versuche, Teams zum Laufen zu bringen
00:37:59und danach kümmern wir uns um die technischen Probleme und lösen diese.
00:38:03Und für alle Zuhörer: Wir verlinken die erwähnten Bücher in den Shownotes.
00:38:09Ähm, ich wollte fragen, um noch mal auf KI zurückzukommen: Ich stimme dir zu, dass die Leute die Grundlagen lernen sollten und dass
00:38:16Softwareentwicklung oder Programmierung nicht verschwinden wird. Aber es gibt einen gewissen Trend,
00:38:21bei dem ich immer mehr sehe, dass Leute Code in die Produktion bringen, ohne ihn zu überprüfen.
00:38:26Und ich bin sicher, dass das irgendwelche Leute auf Twitter oder X sind oder einfach
00:38:30Leute, die angeben und das gar nicht stimmt.
00:38:32Aber es gibt so gewisse Vordenker wie die Leiter von KI-Unternehmen, wie Dario, äh Musk, die sagen:
00:38:39Hey, nächstes Jahr 2027 oder so
00:38:41kann man Code schreiben und ihn veröffentlichen, ohne ihn anzusehen, oder man kann Code schreiben,
00:38:47wie kompilierten Code, ohne die Programmiersprache zu schreiben – also diesen Code zu kompilieren, sodass Sprachen tot sein werden. Was denkst du darüber?
00:38:54Ich bezweifle stark, dass diese Vordenker Rufbereitschaft haben,
00:38:58denn wenn sie das hätten, würden sie etwas völlig anderes sagen.
00:39:02Keineswegs.
00:39:04Sie sind nicht in der Infrastruktur. Sie sind nicht die Informationssicherheitsgruppe,
00:39:08die sich darüber beschwert,
00:39:09dass Schwachstellen eingeschleust werden, und sie müssen sich nicht damit herumschlagen, was passiert, wenn Kunden verärgert sind. Klar,
00:39:13LLMs können Code produzieren,
00:39:16der syntaktisch korrekt und einigermaßen logisch ist.
00:39:21Schreiben sie etwa 20, 30 Prozent?
00:39:23Vielleicht.
00:39:25Aber selbst dann
00:39:29wirst du nach wie vor
00:39:31ein ordentliches Monitoring und Observability benötigen,
00:39:37weißt du, Tests in der Produktion. Okay, wenn du Tests in der Produktion willst, wie Charity es vertritt,
00:39:42gibt es einige
00:39:45Voraussetzungen und Investitionen, die man tätigen muss. Ihrer Ansicht nach
00:39:48wird das Observability sein – das Verständnis für das Verhalten deiner Software. Aber selbst dann, wenn ich,
00:39:54weißt du,
00:39:56eine Regierung wäre und Software kaufen müsste,
00:39:59muss sie meine Sicherheitsvorgaben erfüllen
00:40:03Wenn ich ein medizinisches Unternehmen wäre und du Software schreibst, die buchstäblich dafür verantwortlich ist, Patienten am Leben zu erhalten,
00:40:09glaubst du wirklich, du möchtest, dass ein LLM das ohne Überprüfung generiert? Das wäre unvereinbar mit jeglicher Verantwortung.
00:40:15Das führt zurück zu dem Beispiel mit der Brücke oder dem Wolkenkratzer. Willst du wirklich, dass ein LLM eine Brücke oder einen Wolkenkratzer entwirft
00:40:21und man das einfach baut, Mörtel und Bewehrung rein und los geht's? Nein,
00:40:27nein, absolut nicht.
00:40:31Ja, diese Brücken- und Wolkenkratzer-Analogie ist eine sehr gute Sichtweise, an die ich nie gedacht hatte.
00:40:37Weißt du, wenn du ein Ingenieur wärst,
00:40:39vom Anfänger zum Profi: Würdest du über deine eigene Brücke gehen wollen, die du gerade gebaut hast?
00:40:43Ja, und das ist der Punkt, über den wir nachdenken müssen – ich erwähnte ja Curtis,
00:40:49ich liebe diesen Typen, am Anfang dieser Episode.
00:40:52Er war ein PE
00:40:56Ein professioneller Elektroingenieur zu sein bedeutete, dass er zur Schule ging
00:41:02die PE-Prüfung ablegte, mehrere Jahre lang als Praktikant in einem Unternehmen arbeitete und schließlich nach einer großen Prüfung
00:41:09dann und erst dann in der Lage war, Ingenieurprojekte durchzuführen. Es gibt ein hohes Maß an Disziplin
00:41:18darin, wie
00:41:21man Dinge tut. Ich meine, es ist dasselbe bei Ärzten.
00:41:23Man lernt die Theorie, aber dann ist man jahrelang unter Aufsicht in der Praxis, bevor man tatsächlich Medizin ausüben darf.
00:41:30Und das hat einen Grund. Der Grund ist,
00:41:33dass die Entscheidungen, die wir treffen, massive Auswirkungen auf das Leben von Menschen und auf die Umwelt haben,
00:41:40und die Softwarebranche hat das noch nicht ganz
00:41:44aufgeholt.
00:41:47Ich sage nicht unbedingt, dass wir diese Modelle nachahmen müssen, aber
00:41:52wir müssen zumindest
00:41:54die Risiken anerkennen, die wir einführen, und wir müssen die Disziplin haben, wenn wir Dinge bauen, die das Leben von Menschen beeinflussen,
00:42:01diese Disziplin an den Tag zu legen. Wir müssen über Risiken nachdenken, wir müssen über negative Ergebnisse nachdenken,
00:42:05wir müssen Verantwortung übernehmen, und ich denke,
00:42:08es gibt viele Organisationen, die das nicht hören wollen, weil es ihre Fähigkeit, Fortschritte zu machen, einschränkt.
00:42:14Aber
00:42:16warum schreiben wir Software? Wir lösen Probleme für Menschen, wir sollten keine neuen schaffen.
00:42:23Ja, und das ist ein sehr interessanter Punkt, den du über deinen Freund gesagt hast – sorry, ich habe seinen Namen vergessen, den PE (Professional Engineer) Curtis, denn Curtis...
00:42:31Ja, denn hier in Kanada
00:42:33gab es eine Diskussion darüber, dass man hier eine Berufszertifizierung benötigt, um sich Ingenieur nennen zu dürfen.
00:42:40Und dann gab es die Debatte, dass Software-Ingenieure den Titel Ingenieur nicht tragen sollten, weil sie diese Zertifizierung nicht erworben haben.
00:42:48Ja.
00:42:51Ja, das leuchtet ein, das leuchtet ein.
00:42:53Ja, das Maß an Disziplin ist in unserer Branche und deren Branche einfach völlig unterschiedlich.
00:42:57Ja, genau. Ähm, ich wollte auf etwas eingehen, das du in deinem
00:43:03LinkedIn-Profil geschrieben hast. Du erwähntest: Von Burnout und Engpässen zu zuverlässigen, schnell agierenden Teams und Systemen.
00:43:12Was ist also deine Erfahrung mit Burnout?
00:43:16Oh je, ich habe eine Menge Erfahrung mit Burnout.
00:43:21Weißt du, als Operations-Mensch in schnell wachsenden Organisationen
00:43:26gibt es
00:43:28definitiv Leute mit so etwas wie Helferkomplexen, Leute, die sich beweisen wollen, Leute, die
00:43:35diese kleinen Dinge in der Psychologie, wo sie das Gefühl haben, dass sie
00:43:39einfach einspringen und Verantwortung übernehmen. Das ist eine Schwachstelle, richtig? Hochstapler-Syndrom,
00:43:45all diese Tendenzen, die wir alle als Menschen haben, Gefallsucht, all diese Dinge können zu einem Burnout beitragen, bei dem man
00:43:52so motiviert ist, anderen zu beweisen, dass man gute Arbeit leistet, dass man nicht auf seinen Körper hört,
00:43:59dass man nicht auf
00:44:02seine Gefühle, seinen emotionalen Zustand hört. Man ist nicht introspektiv. Man gibt sich selbst keine Zeit und keinen Raum zur Erholung.
00:44:08Deine Beziehung zur Erholung ist gestört – es gab eine Zeit, in der ich dachte, Erholung sei schlecht,
00:44:14dass Müßiggang
00:44:16verschwenderisch war, während in
00:44:20dieser Phase meines Lebens, in der ich viel über diesen Kram nachdenke, nein, Erholung
00:44:25dir die Fähigkeit gibt, später die großen Lasten zu stemmen.
00:44:29Leute, die Bodybuilding betreiben, sind schließlich auch nicht jeden
00:44:35Tag im Fitnessstudio und trainieren jeden Muskelstrang. Sie geben sich selbst Zeit,
00:44:40um die Muskelfasern wieder aufzubauen.
00:44:45Warum sagen wir dann,
00:44:47dass wir
00:44:49das in Bezug auf unseren Geist nicht tun können? Das ist das Thema.
00:44:51Aber ich erinnere mich, dass ich nach dem Verlassen von Meta
00:44:55sozusagen Patient Null in der gigantischen Entlassungswelle war.
00:45:01Ich war also von den Entlassungen betroffen. Tut mir leid deswegen.
00:45:04Oh nein, ich meine, Shinto Moto würde nicht existieren, wenn es das nicht gegeben hätte. Alles klar, cool,
00:45:08wie der Phönix aus der Asche, genau so war meine Reaktion darauf.
00:45:13Aber diese Phase, in der ich mein eigenes Unternehmen gründe
00:45:18und mich einen Schritt aus der Branche zurückziehe und darüber nachdenke, wie ich arbeiten möchte, hat mich wirklich
00:45:23sehr bewusst gemacht für das Burnout, das ich mit mir herumschleppte, ohne es mir einzugestehen.
00:45:32Und weißt du, ich erinnere mich daran, dass ich früher in meiner Karriere der grummelige Sysadmin war – falls irgendwelche Leute
00:45:38von Acquia oder ehemalige Acquia-Mitarbeiter das hier hören, wissen sie, wovon ich spreche.
00:45:42Ich war früher echt verdammt grummelig
00:45:44und heute bin ich sehr jovial, weil ich etwas an mir gearbeitet habe.
00:45:49Aber das war Burnout, und ich habe es nicht erkannt.
00:45:51Ich dachte einfach, dass zu viele Leute zu mir kamen und mich um Dinge baten,
00:45:56die sie eigentlich selbst tun sollten – nach dem Motto: Lies die man-Page, weißt du, was ich meine?
00:45:59Ich hatte mit viel Burnout zu kämpfen, und ich denke, mein Unternehmen und die Art, wie ich es führe, geben mir den Raum,
00:46:04um diese Herausforderungen
00:46:07direkt anzugehen
00:46:08und auf eine gesündere Weise mit der Arbeit zu interagieren,
00:46:13die besser dazu passt, wie mein Gehirn funktioniert, was ich in meinem Leben möchte und sicherzustellen,
00:46:20Weißt du, dass ich nicht
00:46:23um zu arbeiten lebe. Ich arbeite
00:46:25schlicht, um Erfahrungen zu machen, die mich erfüllen. Weißt du, was ich meine?
00:46:28Was denkst du darüber? Ich weiß, ich bin etwas abgesprungen.
00:46:31Ich wollte nur sagen, dass den griesgrämigen
00:46:34Sysadmin, damit kann ich mich identifizieren. Nicht etwa ich persönlich, aber in Firmen, in denen ich gearbeitet habe, gab es immer diesen Typen,
00:46:40der Kubernetes aufsetzen kann oder alles über AWS weiß und wenn man etwas von ihm will,
00:46:44reagiert er genervt. Okay, und dann macht er es zwar, will es aber eigentlich nicht tun, daher kann ich das nachvollziehen.
00:46:49Aber ja, ich verstehe, warum das passiert und woher das kommt, rein durch die Tatsache, dass es so oft vorkommt und
00:46:56deshalb verstehe ich die Frustration.
00:46:59Und ja, ich denke, es ist gut, davon Abstand zu gewinnen und äh, man muss an sich arbeiten und andere Dinge ausprobieren,
00:47:05auf jeden Fall. Da ist persönliche Verantwortung im Spiel, aber eben auch ein starkes Bewusstsein für die Kultur
00:47:11der Umgebung, in der man arbeitet, die Teams, mit denen man arbeitet, und die Leute, mit denen man zu tun hat,
00:47:15und sicherzustellen, dass man Orte auswählt, die am besten zu einem passen. Ich weiß, der Arbeitsmarkt ist noch etwas seltsam,
00:47:21da fällt es vielleicht schwer,
00:47:22solche Entscheidungen zu treffen und zu sagen: Ich gehe jetzt einfach woanders hin.
00:47:26Das mag wirklich schwierig sein, das ist mir klar, aber zumindest achtsam zu sein
00:47:30bezüglich des Ortes, an dem man ist, auf die eigenen Emotionen und den Körper zu hören und entsprechende Schritte einzuleiten,
00:47:36das ist meiner Meinung nach ein wesentlicher Teil des Ganzen. Es gibt da
00:47:39eine Ärztin, Dr. Maslach, die hat etwas namens Burnout-Inventar entwickelt.
00:47:44Sie hat es ursprünglich für medizinisches Personal entworfen, weil sie aus dem medizinischen Bereich stammte,
00:47:49aber das Burnout-Inventar und ihre Forschung lassen sich extrem gut auf die Tech-Branche anwenden.
00:47:56Und man kann sich sogar
00:47:58einige ihrer Vorträge ansehen. Ich glaube, sie hat
00:48:01Vorträge für das jährliche DevOps-Event gehalten, das der Autor von Das Projekt veranstaltet hat.
00:48:06Ja.
00:48:08Also,
00:48:09ja, ich habe mich ein wenig mit den klinischen Aspekten des Burnouts befasst und es auch selbst erlebt.
00:48:15Ja, und ich freue mich riesig, dass diese Entlassung für dich etwas Gutes bewirkt hat und den Weg dafür geebnet hat,
00:48:24dass du deine eigene Firma gegründet hast. Und ich finde es so interessant, was ich deinen Beiträgen entnehmen kann,
00:48:31dass du dieses Unternehmen
00:48:33quasi von unterwegs aus führst, stimmt's? Du bist
00:48:35ständig am Umziehen. Du führst im Grunde eine Art nomadenhaften Lebensstil, ist das richtig? Genau so ist es.
00:48:42Ich lebe tatsächlich als Nomade. Ich führe dieses Gespräch gerade buchstäblich über Starlink mitten in der hohen Wüste in Nevada,
00:48:50äh, ich habe meinen Toyota Tacoma Pickup-Truck umgebaut.
00:48:54Ich nenne sie Molly. Ich habe meinen Pickup-Truck in eine
00:48:59mobile Kommandozentrale verwandelt. Ich stehe
00:49:02gerade auf der Ladefläche,
00:49:04äh
00:49:05und habe komfortable Schlafplätze, 300 Watt Solarstrom,
00:49:09einen Kühlschrank, eben ein selbstgebautes Energiesystem. Ich habe mir also ein Mikro-Zuhause
00:49:16aus diesem Truck gebaut und arbeite von überall aus – von meinem Grundstück hier in Nevada bis hin zum
00:49:23Parkplatz eines AMC-Kinos irgendwo in Boston. Ich arbeite von überall aus, was unglaublich viel Spaß macht.
00:49:29Ich mache das jetzt schon seit
00:49:31zweieinhalb Jahren. Ich habe Shirtomoto vor drei Jahren gegründet
00:49:34und lebe seit zweieinhalb Jahren als Nomade, und es war das schönste Abenteuer meines Lebens.
00:49:41Weißt du,
00:49:43während ich in den Bergen gearbeitet habe, ist einmal ein Bär in meinen Truck geklettert.
00:49:46Oh, wow!
00:49:48Ja, wie war das so?
00:49:51Das war schon ein wenig gruselig. Damals war ich noch in einem Dachzelt unterwegs,
00:49:54nicht in meinem coolen Camper von heute. War es ein Schwarzbär oder ein Braunbär?
00:49:58Nun, ich lebe noch. Folglich war es ein Schwarzbär. Alles klar.
00:50:02Es war der größte Schwarzbär, den ich je gesehen habe, er war absolut gigantisch.
00:50:06Er hat wohl nach Picknickkörben oder so gesucht,
00:50:08aber
00:50:09er ist auf die Ladefläche geklettert, auf der ich oben auf dem Gestell im Dachzelt geschlafen habe, und das Gewicht hat sich dadurch verlagert.
00:50:17Ich musste dann die Schlüssel aus der Tasche kramen und den Alarmanfall auslösen
00:50:21und als der Alarm anging, ist der Bär weggelaufen.
00:50:24Ja, danach habe ich verstanden, wie wichtig es ist, etwas zu bauen, das geschlossen ist. Zumindest kann der Bär mich nicht sehen
00:50:30oder hineinkommen.
00:50:33Du hast also Nevada und Boston erwähnt, machst also jedes Jahr einen Cross-Country-Trip mit deinem Truck? Ja, jedes Jahr.
00:50:42Ich plane tatsächlich, in einem Monat in den Nordosten zurückzukehren. Momentan habe ich einen 6x10-Frachtanhänger, den ich umbaue.
00:50:48Nach diesem Gespräch bohre ich Löcher, baue Fenster und Lüftungsventilatoren ein
00:50:52und installiere 1000 Watt Solarstrom. Wir machen das volle Programm, und es wird mein mobiles
00:50:58Hauptquartier und Büro, in dem ich bei schlechtem Wetter arbeiten kann.
00:51:02Das ist ja cool. Und für Ingenieure oder andere Leute, die daran interessiert sind:
00:51:08Wie hoch ist ungefähr der Preis für den Bau eines solchen mobilen Zuhauses, wie du es gemacht hast?
00:51:13Nun, der Frachtanhänger ist eigentlich recht günstig, den bekommt man für so vier bis fünftausend und dann,
00:51:20je nachdem, was man noch machen muss, steigen die Kosten. Man muss ihn natürlich isolieren,
00:51:24etwas Belüftung und Elektrik einbauen.
00:51:27Es gibt eine ganze Welt von Leuten da draußen, die so etwas tun.
00:51:31Ich bin nur einer der wenigen, die nomadenhaftes Leben und Technik miteinander verbunden und es zum Laufen gebracht haben.
00:51:36Aber der Truck ist ein Tacoma mit einem maßgeschneiderten Camper drauf von einer Firma namens Go Fast.
00:51:41Ich habe diesen hier gebraucht gekauft, aber äh
00:51:44ja, es kommt wirklich darauf an, was man braucht. Ich sehe Leute, die sich in einem Prius einrichten,
00:51:51und ich sehe auch Leute in ausgefeilteren Gefährten, aber
00:51:55die Einstiegskosten können gering sein, wenn man ein bisschen Ahnung von Autos hat und bereit ist,
00:52:01sich die Hände schmutzig zu machen und anzupacken.
00:52:04Was hat dich also zu diesem Unterfangen inspiriert,
00:52:07zu campen, zu reisen und
00:52:10dein Auto aufzumotzen?
00:52:11Ja, also ich habe vor dieser Reise nur an zwei Orten gelebt
00:52:14und mein ganzes Leben damit verbracht zu arbeiten und im Grunde das zu tun, was die Leute mir gesagt haben,
00:52:21was man von einem jungen Mann erwartet: Man geht aufs College, macht seinen Abschluss, bekommt einen guten Job
00:52:26und arbeitet sich hoch. Das habe ich getan
00:52:28und
00:52:29am Ende dieses Corporate-Weges wurde mir klar: Mann, ich bin gar nicht so glücklich,
00:52:34wie ich es eigentlich sein sollte. Ich habe enorme Erfolge erzielt, aber es fühlt sich nicht richtig an. Und als ich mein eigenes Unternehmen gründete und merkte:
00:52:41Will ich wirklich so viel Miete im Raum Boston zahlen?
00:52:44Wenn ich nicht in Boston bleibe, was würde ich dann tun? Da stieß ich auf ein YouTube-Video von einem Typen, der einen U-Haul-Truck,
00:52:51also einen Umzugswagen,
00:52:53in eine Wohnung auf Rädern verwandelt hatte, und ich dachte mir:
00:52:55Huh,
00:52:58das ist irgendwie cool.
00:53:00Und ich fing an, mich in diesen YouTube-Kaninchenbau zu begeben und herauszufinden, dass es eine ganze
00:53:05Community von Leuten gibt, die so leben, und ich habe einfach
00:53:08recherchiert, jede Menge YouTube geschaut und schließlich beschlossen: Ich habe alles verkauft,
00:53:13den Mietvertrag für die Wohnung nicht verlängert
00:53:16und bin in meinem Civic nach Westen gefahren. Ein paar Monate später habe ich Molly bekommen, sie eingerichtet
00:53:22und losgelegt. Ja, es war die Einsicht, dass ich eine Menge
00:53:28Lebenserfahrung nachzuholen hatte.
00:53:31Ich hatte ironischerweise zu viel Zeit mit einem Tech-Podcast verbracht – ich habe zu viel Zeit
00:53:37am Computer verbracht und zu wenig draußen in der Welt, und mir wurde klar, dass ich diese Erfahrung brauchte, um einen Ausgleich zu finden, denn
00:53:44ich bin mehr als nur ein ver Nerdeter Typ, ich bin ein Mensch mit meiner eigenen
00:53:49eigenen Note.
00:53:52Ich muss rausgehen und Gras anfassen.
00:53:55Ich muss Gras anfassen, und ich habe hier draußen in der Welt mehr als nur Gras angefasst: Felsen,
00:53:59Weißt du, Berge, Wasser, all so Zeug. Es gibt hier draußen so viel zu berühren. Ja, absolut.
00:54:04Du hast also deine Bären-Geschichte erwähnt – gab es noch andere
00:54:08interessante Abenteuer, während du unterwegs warst?
00:54:12Oh, so viele! Ich bin mit Freunden den Cinnamon Pass in Colorado gefahren, das ist eine Offroad-Strecke,
00:54:18etwas technischer und anspruchsvoller. Ich war in Wyoming, ich war in Yellowstone, Grand Teton.
00:54:24Ich habe auf öffentlichem Land in der Nähe gecampt, wo man Bären sehen kann. Manchmal höre ich
00:54:30dort, wo ich bin, wilde Esel, und vor ein paar Tagen habe ich Wildpferde gesehen.
00:54:34Man hört sie laufen, schaut aus dem Zeltfenster und da sind sie, ein paar Pferde.
00:54:39Äh
00:54:41Aber ja, ich habe das Land einige Male kreuz und quer bereist
00:54:45und
00:54:47ja, es war schön. Ich habe eine Partnerin, die bereit ist,
00:54:51meine Verrücktheiten mitzumachen, und wir erleben gemeinsam Abenteuer.
00:54:54ähm, und ja, es es es hat Spaß gemacht. Ich meine, das könnte eine ganze Episode über all die verrückten Orte sein, an denen ich war
00:55:01Oh, ja
00:55:03Das klingt großartig. Wahrscheinlich gibt es dazu eine Episode in deinem eigenen Podcast, oder?
00:55:08Darüber, weißt du, sollte es eigentlich geben, weil normalerweise – also, weil ich mir einen Gast einlade und wir dann über
00:55:15das Thema, aber vielleicht sollte ich einfach mal eine machen, in der es darum geht
00:55:20ja, selbst die äh die Ansichten und deine Lektionen zum Thema Burnout, ich denke, das wäre eine sehr
00:55:25nützliche Episode für viele Ingenieure, besonders heutzutage, weil ich das Gefühl habe
00:55:29man hat uns versprochen, dass KI
00:55:33uns produktiver macht und wir weniger Stunden arbeiten müssen, während es in Wirklichkeit meiner Meinung nach genau umgekehrt ist
00:55:41Manchmal brennt man einfach durch die Menge an Arbeit aus, die man mit diesen nun verfügbaren Werkzeugen leisten soll
00:55:50Ja, meine Ansichten dazu würden wahrscheinlich als sehr subversiv angesehen werden
00:55:53Und ich belasse es einfach dabei, dass wir wir brauchen wir brauchen mehr Arbeiter. Seien wir ehrlich
00:55:58Das sind wir nun mal. Wir sind Arbeiter. Wir wir brauchen Bedingungen, die menschlicher sind
00:56:03Absolut
00:56:06Ja, stimmt
00:56:08Wir fragen unsere Gäste immer gerne: Hast du irgendwelche kontroversen Thesen über SRE, DevOps?
00:56:14KI, irgendwas mit Tech. Ja. Gut, eine steile These, und ich sage das mit dem allergrößten
00:56:22Respekt, ich möchte die SRE-Praxis nicht abschirmen oder gatekeepen
00:56:26aber ich sage folgendes: Wenn du eine SRE-Rolle hast, wenn du eine Berufsbezeichnung hast
00:56:29die SRE heißt
00:56:32und du im Moment in der Ecke sitzt und YAML schreibst
00:56:34und Alarme bekommst
00:56:37möchte ich, dass du wirklich hinterfragst, ob das tatsächlich eine SRE-Rolle ist
00:56:40SRE ist eine Praxis, bei der man ein nicht ganz so zuverlässiges System nimmt
00:56:45und es in ein zuverlässiges System verwandelt
00:56:47und Kunden durch SLOs glücklich macht
00:56:50Toil-Management, Kapazitätsplanung, richtig, all diese übergeordneten operativen Verantwortlichkeiten und die Nutzung von Softwareentwicklung
00:56:59Das ist sehr, sehr wichtig. Das ist SRE-Praxis
00:57:01YAML ist also keine Programmiersprache, wenn du das die meiste Zeit über machst
00:57:06ermutige ich dich, dich in tiefere Gewässer zu begeben. Es ist großartig hier draußen
00:57:11es gibt eine tolle Community, viele Leute, die dir mehr als gerne etwas beibringen, aber
00:57:15stelle sicher, dass du Rollen findest, die dich herausfordern und dir beim Wachsen helfen
00:57:18Das Buch Das Projekt machte das Wort DevOps populär, und seitdem gibt es Leute, die DevOps-Ingenieure sind und was tun?
00:57:26Du sagtest wie YAML schreiben und äh
00:57:29Kubernetes buchstabieren und all das Zeug, und es ist ein bisschen so, als wäre das DevOps
00:57:33von dem das Buch sprach, nicht jemand, der das tut. Es ist eher so, wie du es erklärt hast, das Brückenbauen zwischen zwei verschiedenen
00:57:39War es, wie ist das Wort, nicht Systemen, sondern Disziplinen?
00:57:43Und ich denke, es ist ziemlich üblich, wie ich sagte, auf der Welt zu sehen: Ich bin ein DevOps-Ingenieur
00:57:48Ich lerne DevOps und es ist so, es ist nicht das, es ist
00:57:51was du erklärt hast. Es ist jetzt schwierig, diese Brücke zu schlagen, weil es mittlerweile so verbreitet ist, dass Leute DevOps-Ingenieure sind
00:57:56Es wird nicht so gesehen, wie du es erklärt hast. Aber ja, es ist schwer, jetzt noch zurückzugehen, nicht wahr?
00:58:02Ja, ich meine, wir sprechen über Semantik und Namen, also werde ich versuchen zu präzisieren, was ich meine, wenn ich von DevOps spreche
00:58:09Ja, in der Tat
00:58:10Wir sprechen nicht über eine Reihe von Tools. Wir sprechen nicht über ein bestimmtes Team, Titel, Tool oder Team, die Leute reden darüber
00:58:15die ganze Zeit. Nein, das ist es nicht, es ist die Praxis, zusammenzuführen
00:58:19Technologie, Menschen, Führung, Prozesse, damit wir Software so schnell wie möglich an den Kunden liefern können
00:58:27kooperativ und so gut wie möglich für das Unternehmen – das ist für mich DevOps, und das Mittel, um
00:58:34dorthin zu gelangen, sind die Werkzeuge
00:58:35Es ist nicht nur Kubernetes. Kubernetes ist ein Teil des Puzzles. Es ist nicht nur CI/CD
00:58:40Es ist ein Teil des Puzzles. Manchmal bedeutet es auch, sich hinzusetzen und den Leuten zuzuhören. Manchmal geht es darum, Visionen und Strategien aufzubauen, manchmal
00:58:47Weißt du, es geht darum, deinem Team einen freien Tag zu geben, nachdem es zu oft um 3 Uhr nachts angepopt wurde.
00:58:52DevOps dreht sich um diese gesamte
00:58:55ganzheitliche Sichtweise und nicht nur um die Werkzeuge. Die Werkzeuge sind sexy, ich verstehe es, die Leute wollen die Werkzeuge verkaufen
00:59:01aber das ist nur ein Aspekt des gesamten Erlebnisses. Ja, apropos Werkzeuge: Hast du irgendwelche Lieblingstools, die du nutzt?
00:59:08Oh je, okay. Äh, lass mich mal darüber nachdenken. Ja, ich steuere mal eins bei. Also
00:59:14es
00:59:15gab in letzter Zeit viele Vorfälle bei GitHub
00:59:20und wir haben uns ein bisschen an die Gewohnheit gewöhnt: Hey, ich möchte, dass meine Build-Prozesse und Test-Pipelines
00:59:26bei einem Anbieter laufen. Es gibt stattdessen ein Tool, das du nutzen kannst, wenn du dein Zeug selbst hosten möchtest
00:59:32das sich Concourse nennt
00:59:35Und ich mag Concourse. Es ermöglicht dir, sehr ausgefeilte
00:59:38Pipelines für Tests, Builds, Bereitstellungen oder was auch immer zu erstellen, unter Verwendung von YAML, wobei jeder kleine Abschnitt in einem Container läuft
00:59:47Aber du hostest es selbst, und der Grund, warum ich es wirklich mag
00:59:50ist, dass die Open-Source-Community
00:59:53wie die Governance ein eigenes Governance-Modell ist
00:59:56Es gehört keinem Unternehmen, das einfach so die Lizenz austauschen und es in ein SaaS verwandeln kann
01:00:01was wir bei anderen Projekten schon oft gesehen haben. Wenn du also frustriert bist von
01:00:06weißt du
01:00:09der Nutzung des Cloud-Dienstes des Tages für dein CI/CD, schau dir Concourse an, nutze es, lass es On-Premises laufen
01:00:16Weißt du, vielleicht gehst du in der Philosophie fünf oder zehn Jahre zurück, aber es ist vielleicht stabiler. Wer weiß?
01:00:20Cool. Ich habe noch nie davon gehört. Ich muss es mir mal ansehen
01:00:23Ja, ich auch
01:00:26Ja, das ist gutes Zeug. Oh, es gibt da draußen einige Unternehmen, die es definitiv nutzen
01:00:29Und ja, Freunde lassen Freunde kein Jenkins nutzen, das ist vorbei. Tu das nicht. Tu das nicht
01:00:35Du sagst also, Jenkins ist tot
01:00:38Habe ich das gesagt?
01:00:41Nein, nein, nein, das war keine Fangfrage
01:00:44Aber was ich sage, ist, dass es einige mehr Optionen gibt
01:00:47und ich glaube nicht, dass die Leute noch Groovy-Skripte schreiben wollen. Also ja
01:00:51andere Dinge da draußen waren für mich ebenfalls eine Qual
01:00:54Ja, als ich sie benutzt habe
01:00:57Ja
01:00:59Sehr gut
01:01:01Gibt es etwas, das du promoten möchtest, wie zum Beispiel deinen Podcast? Gibt es noch etwas, worüber du sprechen willst, bevor wir zum Ende kommen?
01:01:06Klar, machen wir das. Dafür bin ich immer dankbar. Ja
01:01:09Ich bin Berater bei meiner Firma cherto moto. Das schreibt sich c-e-r-t-o-m-o-d-o.io. Ich bin spezialisiert darauf, die
01:01:18Zuverlässigkeits-, DevOps- und SRE-Haltung von Unternehmen zu bewerten. Wenn du oft angepimt wirst
01:01:22wenn du nicht oft lieferst, wenn Kunden wütend sind
01:01:26solltest du unbedingt etwas Zeit in meinem Kalender reservieren. Ich leite auch einen Podcast namens Reliability Rebels
01:01:31in dem ich Leute interviewe und darüber spreche
01:01:33wie SRE nicht nur aus Tools besteht, sondern auch darin, den Status quo herauszufordern
01:01:38über das Soziotechnische zu sprechen, und am 24.
01:01:41Februar halte ich ein Webinar über
01:01:45die
01:01:47KI-Code-Flut
01:01:48Ich nenne es glaube ich den KI-Code-Tsunami. Ähm, und ich mache monatlich Webinare über allerlei interessante Themen
01:01:54Wenn du also interessiert bist, schau auf meiner Website vorbei und du kannst all das Zeug lernen. Vielen Dank für die Gelegenheit, das zu erwähnen
01:01:59Keine Ursache. Danke dir. Ich für meinen Teil
01:02:03dafür, dass du all diese Abenteuer und gewonnenen Erkenntnisse geteilt hast. Es hat großen Spaß gemacht, dich dabei zu haben
01:02:09Also vielen Dank an alle fürs Zuhören bei dieser Episode des Better Stack Podcasts
01:02:13Abonniert unsere Show, wo immer ihr eure Podcasts bekommt – Apple, Spotify, YouTube, sucht es euch aus, aber für den Moment
01:02:20ist das ein Tschüss von mir
01:02:22und ein Tschüss von mir
01:02:25und ein Tschüss von mir
01:02:33(forsche Musik)