Site Reliability Engineering (SRE) mit Andy Grunwald vom Engineering Kiosk #81

Moin zufolge 81 von einfach komplex heute wieder natürlich mit Burkhard und Gerrit. Moin Burkhard. Ja Moin Gerrit, Moin Moin. Ja, genau, und wir haben wieder einen wirklich tollen Gast, einen Gast, der eigentlich deutlich mehr Podcast Erfahrung hat als wir. Moin Andy vom Engineering Kiosk. Hi, ich wüsste jetzt nicht wie man Podcast Erfahrung messen kann. Ich glaub in Aufnahmen oder in Aufnahmelänge oder folgen oder also das Kriterium hier. Gesprochene Stunden.

Ja, ich hatte auch gesprochen oder aufgenommene Stunden angesetzt und ich hab gesehen, ihr seid bei Folge 188 schon vom Engineering Kiosk, von daher seid ihr jetzt bis voraus wir. Haben n bisschen Gescheatet mit ganz kurzen Folgen im Advent das Wustet, dann 21 folgen nach vorne, deswegen ist das glaub ich nicht ganz fair, aber alles gut. Super cool, dass du da bist, Andi und dir die Zeit heute nimmst. Wir wollen nicht nur über Podcast sprechen, sondern wir haben uns auch n Thema

vorgenommen. Das Side Realability Engineering. Was das genau bedeutet, was da alles dahinter steckt wirst du uns gleich mal erklären, aber. Sag uns doch noch mal ein paar Worte zu dir. Was hast du schon gemacht? Das ist eine ganze Menge, soweit ich weiß. Und was machst du aktuell?

Ja hi, ich bin Andi, ich bin hauptberuflich leider kein Podcaster. Hauptberuflich verdiene ich meine Miete als Arbeitnehmer bei Cloud Flair, da bin ich Engineering Manager im Bereich Obsibility, also obsibility, Monitoring und so weiter und sofort, also Logs, Alerting und Co. Bin gelernter Softwareentwickler, bin relativ früh ins Engineering Management gerutscht. Hab bei Trivago gearbeitet, hab mich da ziemlich viel um die Skalierung der der Webplattform

gekümmert. War dann bei einem Datenbank SS Service Provider, hab mich da um Hochverfügbarkeit von Datenbanken gekümmert und jetzt bin ich bei Cloud Flare und kümmer mich da halt um die Sichtbarkeit in Bezug auf Metriken, logs, Traces und. Co. Magst du uns einmal kurz sagen, was Cloud Flare macht? Ich glaub es ist für viele Name, aber so ganz genau weiß man es nicht, was eigentlich dahinter steckt, wenn man nicht tief in

der Technik steckt, oder? Das ist sogar als Arbeitnehmer relativ schwierig, weil das Produktportfolio relativ groß ist. Ich denke, dass viele Leute Cloud Flare a für das Produkt des Content Delivery Network

kennen. Ja, das ist n weltweites Content Delivery Network auf der anderen Seite sind die auch sehr populär in Bezug auf Thread Detection D dos Protection und Co. Also dass wenn man massenanfragen kriegt, dann schaltet man Cloud Flare davor, aber auch von Entwicklerseite gibt es da natürlich mehr und mehr Entwicklerplattformen wie Cloud Flare Pages ist ähnliches wie Gitar Pages.

Oder Cloud Flare Worker ist ähnlich sowas wie Lambda Funktion auf Ada BS und Co. Also n sehr breites Produktportfolio. Im generellen würde ich es als.it Sicherheitsfirma bezeichnen, die sich sehr viel auf internetbasisinfrastruktur würde ich so mal sagen beschäftigt. Ja, danke für deine Vorstellung. Also du hast echt schon einiges gesehen und gehört und getan

würde ich jetzt mal sagen. Was haben wir denn heute vor, magst du es uns einmal so als kleine Roadmap für die Folge abreißen, warum du dafür jetzt auch der perfekte Experte bist? Ich bin angefragt, zumindestens von euch beiden zum Thema Side Reliability Engineering mal ein bisschen was zu sprechen. Was ist das eigentlich? Ist das ein Job, wenn ja, was macht man in diesem Job, was muss man für Qualifikationen da

mitbringen, woher kommt die ganze Thematik denn was sind Core Prinzipien, wie lebt sich das eigentlich in der Praxis aus? Wir sprechen auch ein bisschen über Technologie, Tools und Co. Und warum kann ich da was zu

erzählen? Das ist eine sehr gute Frage, ich bilde mir ein Ich mache Side Reliability Engineering seit ein paar Jahren. Ob das so ist, das gilt dann anderen, ich sag mal zu bewerten, denn nur Google weiß das, denn Google hat diesen Term, ich sag mal gecountt, deswegen kann die wirklich nur sagen, du machst das, du machst das nicht und der Begriff ist auch sehr variabel in der Industrie wär natürlich auch noch zukommen, aber das ist so

ungefähr seit ha, ich sag mal 78 Jahren beweg ich mich in dem ganzen Bereich hauptberuflich. Jetzt wo du Grad schon irgendwie dabei bist. Mir läuft es auch immer wieder über den Weg, hauptsächlich durch linkedin.

Jobbezeichnungen Wir haben bei uns keine Side Relability Engineerers beziehungsweise in Personalunion vielleicht einen, der sitzt jetzt ja auch gerade da sitzt jetzt ja auch gerade im Call, aber ordnest doch mal ein, du sagst, das gibt es seit 7 Jahren was was gehört denn eigentlich dazu, was war es vielleicht auch vorher und stellt sich das googlen ein bisschen anders vor, weil die das den Begriff geprägt haben oder ist es eigentlich das gleiche wie vorher, wie schon

immer? Den Begriff gibt es länger, seit 7 Jahren. Ich übe das seit circa 78 Jahren aus, würde ich mal sagen. Der Begriff existiert seit circa 2003 ja, also 22 Jahre schon, das ist zumindestens so das was man in der Literatur so liest. Google hat den Begriff Side Reliability Engineering geprägt und zwar gab es damals eine Person, die hat 2003 bei Google angefangen, nannte sich Ben Trainer und der ist inzwischen oder immer noch Vice President

und. Überwacht da, ich sag mal die Technical Operations bei Google. Ihr könnt euch vorstellen, dass die Infrastruktur bei Google 2003 vielleicht noch nicht so groß war, inzwischen aber sehr groß und damals war ja auch das Internetwachstum sehr erheblich, wo die natürlich mehr Server, Server, Server dahingestellt haben und als Ben 2003 nach Google kam, so die Geschichte, ja ich war noch nie bei Google, ich habe noch nie bei Google gearbeitet, hat er ein

sogenanntes Side Reliability Engineering Team gegründet mit der Aufgabe oder mit der Definition. Side Reliability Engineering ist das, was passiert, wenn du Software Engineers mit der Aufgabe von Operation Betreust. Das ist so der große Claim, würde ich mal sagen und jetzt kann man die Fragen hä mach das nicht?

Ein Systemadministrator ist das nicht sogar in dem deutschen Beruf in der deutschen Berufsausbildung sogar 2 Berufe Fachinformatiker Anwendungsentwicklung, also der klassische Softwareentwickler, Fachinformatiker Systemintegration, das sind, ich würde mal sagen, die klassischen Systemadministratoren, oder? In anderen Firmen auch Betrieb

genannt. Wieso wird da jetzt was durchgemixt und die Grundidee war halt damals das Stereotypenbild von auf der einen Seite Systemadministratoren, auf der anderen Seite Softwareentwickler, wenn wir uns das Mal heranführen, Systemadministratoren werden dafür bezahlt Systeme stabil zu halten, die Uptime hochzuhalten, das darf nicht abstürzen, jeder muss eigentlich damit arbeiten können, es gibt so einen Begriff Never. Touch A running System oder

never change a running system? Ja, das fällt gerade. Dieser nicht so gut, ja. Das fällt genau in diese Kategorie, weil wenn man nämlich etwas ändert, dann hat man ein Risiko, dass sich etwas, dass etwas abstürzt, dass etwas instabil ist und co. Das bedeutet, beruflich gesehen hat ein Systemadministrator eigentlich gar kein Incentive, was so ändert, weil der wird ja am an der Uptime gemessen, wenn man so möchte. Bei Softwareentwicklern ist das

leider ganz anders. Softwareentwickler werden eingestellt, um Sachen zu programmieren, um Bugs zu fixen, um Features einzufügen, um neue Versionen auszuspielen und neue Features dem Kunden zur Verfügung zu machen. Das bedeutet, die werden dafür bezahlt, konstant was zu ändern. Jetzt ist es so, die Software, die von den Softwareentwicklern programmiert wird, muss auf die Server des Betriebes und Na ihr ihr grinst beide schon, ja das reibt. Sich schön so. Ja, genau.

Das ist so n kleiner Clash und. Das ist die eine Thematik. Jetzt könnte man sagen, Andy, beschreibst du da gerade nicht irgendwie dev ops, kommen wir gleich zu.

Die andere Thematik ist natürlich auch Systemadministratoren im klassischen Sinne loggen sich per SSH auf den Server ein, Führen Befehle aus und gehen dann irgendwie in den Feierabend, das bedeutet, viele Operationen werden manuell gemacht und das kann man machen, wenn man 5 Server hat, vielleicht auch wenn man 10 Server hat, jetzt ist man aber Google und da fängt es dann langsam an in ich sag mal. Einer Order of Magnitude immer

höher zu werden. Da geht es nicht um 10 Server, da geht es nicht um 100 Server, da geht es nicht um 1000 Server, da geht es auch nicht um einen Data Center, da geht es um etliche Data Center und wenn ich mich da jetzt überall einloggen würde auch mit CLUSTER SSH, Command und so weiter ich log mich auf 5 Server gleichzeitig ein, mach denselben Befehl auf 5 Server gleichzeitig, indem ich den nur einmal eintippe und co. Auch das dauert ja ewig, deswegen wurde gesagt OK.

Du hast Software Engineers, die schreiben Tooling um die Operations vollkommen durchzuautomatisieren und das war weit weit vor irgendwelchen Tools wie Terraform und Ensible und all das, was wir heute kennen. Ja, wir reden von 2003, wir reden von -22 Jahren, ja, wir haben 2025, also das war ne ganz andere Zeit. Du sagst und da ist ne Firma gewesen, die ist so groß gewachsen, hatte so viele Ressourcen im Einsatz um ihr eigentliches Produkt auszurollen.

Dass man festgestellt hat, ich kann, ich kann das einfach gar nicht mehr so einfach deployen und ausrollen.

Ich brauche jetzt noch n Produkt, ich muss noch mal Software entwickeln als Softwarefirma, was das Ausrollen meines Produkts beobachtet und monitort und irgendwie sicherstellt und automatisiert vor allen Dingen, dass das auch überall ankommt und so weiter das ist was du sagst, richtig, und das ist, was wir heute so n bisschen dev OPS nennen, aber je nachdem wie wie groß ich bin, ja und jetzt auch mal ne Frage, ist

dann nicht SRE. Soweit ich es jetzt verstehe und wir, wir gucken uns ja nachher noch dev ops, SRE und so weiter alles an in allen Feinheiten, aber das ist jetzt schon n Thema was in einer gewissen Grundgröße einer Firma beziehungsweise des Produktes irgendwie bedarf um sinnvoll zu sein.

Richtig also Cloud Flair hast du ja gesagt, es ist ja keine kleine bretterbude, Google ja auch nicht und so, aber ist nicht so schlimm wenn wir bei der Eisenwehr mit unseren 4 Nasen die wir haben jetzt uns jetzt nicht spezifisch um SRE kümmern, sondern wir haben ja das Problem einfach nicht, weil du was du gesagt hast wenn du irgendwie kleiner 30 Server bist, wo wir noch sind, kriegst du das auch schon noch hin, mit der Hand einigermaßen ne, obwohl wir auch schon n bisschen mehr

als mit der Hand haben, aber es ist so ne also SRE also und und das was wir heute besprechen ist schon n Thema, was typischerweise größere Firmen haben nur. Also ich würd es jetzt nicht generalisieren, aber ich würd mal sagen ja, weil der Hintergrund der ganzen Thematik ist. Wenn du ne kleine Firma bist mit relativ wenig Mitarbeitern, dann hast du und ich hasse es Menschen als Ressourcen zu bezeichnen, aber so ist es

leider nun mal. Ja wir, wir rechnen ja unter anderem auch so n bisschen Zeit und so weiter und sofort dann versucht natürlich die ganze Firma an dem Produkt zu arbeiten was die Firma verkauft. Ja und SRES und Co. Die kümmern sich eigentlich nur, ich sag mal n bisschen dreckig gesagt um sich selbst. Ja, die versuchen auf der einen Seite natürlich die operative Umgebung stabil zu halten, auf der anderen Seite versuchen die natürlich die SRES andere Teams, ich sag mal performanter zu haben.

Ja, das bedeutet Fiction abzubauen, damit zum Beispiel Softwareentwickler automatisch deployen können, ja, dass da kein Mensch mehr zwischen muss, das alles schneller geht, das bedeutet. Man könnte das auch ähnlich wie ich sag mal in einem Plattformteam übersetzen.

Ihr nutzt dann jetzt vielleicht irgendwelche no co Tools oder vielleicht irgendwelche Hyperscaler wie Amazon Webservices, Microsoft Azure, Google Cloud und Co. Dann nutzt ihr nen EKS ja so n so n Cobenetis Managed Service oder sowas und das machen dann zum Beispiel unter anderem alle alle die SRES, die kümmern sich dann um das Tooling, damit nicht jeder Softwareentwickler immer wieder erneut durch den

schmerzhaften Prozess von. Weiß ich jetzt nicht nen Reployment geben muss oder ähnliches. Ja ihr merkt schon, ich mixe gerade so ganz viele Begriffe, so n bisschen dev Ops da rein n bisschen SEE und so weiter desto größer die Firma wird, umso mehr spezialisieren sich natürlich auch die Einsatzfelder und wo der Unterschied zwischen Dev OPS und SEE und Plattform Engineering ist, da können wir gleich noch n bisschen drüber sprechen, aber.

Solche Rollen werden essentieller und wichtiger und auch Wertschaffender desto größer die Firma ist, desto mehr Produktlinien es gibt, desto mehr Synergien auch genutzt werden können, würde ich mal sagen. Würde das denn jetzt reinpassen, diese Abgrenzung zu versuchen zwischen dem Def OPS SAE und Plattform Engineering? Ja, wir, wir, wir können ja mal anfangen.

Also ich mein, ich hab gerade gesagt was SAE ist SAE ist oder SAE passiert, das heißt Reliability Engineering passiert wenn du Software Engineers mit der Aufgabe von Operations Beauftragst. Und jetzt ist vielen Leuten der Begriffe Def Ops aber auch schon mal über den Weg gelaufen, wenn man linkedin aufmacht, dann gibt es auch DEF OP Teams und dann gibt es auch DEF Ops Engineers und allem drum und dran und Def Ops selbst ist kein Job. Def op selbst ist kein Team DEF

op selbst ist eigentlich nur die Idee oder die Kultur, dass genau diese 2 Bereiche Softwareentwicklung und Betrieb miteinander zu arbeiten, weil wir haben ja gerade festgestellt, die haben diese. Diesen naturellen Streitpunkt ne der eine möchte was ändern, der andere möchte nichts ändern.

Ja und dann müssen wir aber irgendwie beide wert für die Firma schaffen, weil wir werden beide von der Firma bezahlt, also irgendwie müssen wir hier klarkommen und deffops ist halt so die Idee OK lass uns mal bitte doch alle an einem Strang arbeiten ne lass uns doch noch mal zusammensetzen und lass uns doch mal die Probleme verstehen und dann lass doch mal vielleicht den Betrieb auch rüber gucken welche Änderungen

da jetzt gerade online gehen. Oder dass die Softwareentwicklung einfach mal dem Betrieb zuhört, welche Metriken der Betrieb denn eigentlich braucht, um sicherzustellen, dass die Applikation das tut, was die Applikation tun soll. Aka Monitoring und Co. Und damals wurde festgestellt, und das war ich glaube, der erste Begriff, ich nenne es mal von DEV OPS wurde 2009 auf einer Konferenz geprägt, das mit den ganzen Jahren, das ist alles sehr wirr, warum sage ich euch gleich?

2009 kam halt dieser dev Ops Begriff auf und da wurde festgestellt, OK, wenn man die beiden Teams doch sehr nah aneinandersetzt wenn die doch sehr viel miteinander sprechen, dann kann man die Velocity erhöhen, die Velocity also in einer kurzen Zeitraum mehrmals Upgrades zu fahren. Ja Themen wie Continuous Delivery Themen wie Continuous Deployment und Themen wie Ich sag mal Big Bang Releases zu vermeiden ne ich mein der gute Software Engineer weiß.

Wenn ich ganz viele Änderungen auf einmal deployer, ist das Risiko höher, dass ich was kaputt mache, als wenn ich oft kleine Änderungen in Produktion schiebe und besonders das zweite, wenn ich oft kleine Änderungen in Produktion schiebe, dann ist es nachvollziehbar und das müsste doch eigentlich dem Betrieb auch zugute kommen, weil der Betrieb weiß ganz genau, OK, in dem nächsten Release haben wir nur die E Mail Adresse des Kontaktformulars geändert und in

dem danach haben wir nur die Farbe eines Button geänders das bedeutet das kann eigentlich nicht die Stabilität beeinflussen. Wenn da jetzt aber n Release rausgeschoben wird mit 50 Änderungen, machen wir uns mal nichts vor. Da wissen wir doch alle nichts mehr was da drin ist. Ja, es ist ja fast so an die wie wie du es also als Softwareentwickler. Ich sprech jetzt mal kurz als Softwareentwickler, ich hab ja wohl glaub ich die beiden Rollen und das Team wie Gerrit so schön

gesagt hat. Ich fühl übrigens auch beides, ich fühl in meinem Herzen 2 Schläge so ah cool, lass uns mal neue Features und Bugs machen und auf der anderen Seite wenn wir die wenn wir wenn wir laufende funktionierende Anwendung im Feld haben. Denk ich mir auch so. Oh ja, musst du jetzt das Update da reinspielen und so weiter ja, aber was ich eigentlich sagen wollte ist es ist ja sogar beim

beim Coden selbst empfohlen. Wenn du also als Softwareentwickler Änderung vornimmst in dem Code machst du das ja auch typischerweise wenn du es kannst möglichst klein ne, weil man spricht von den sogenannten Commits, also du du nimmst dir eigentlich n Thema vor oder du hast ich sag mal, normalerweise hast du entweder n Feature oder n Bug und das schneidest du so klein wie du nur kannst, damit du möglichst wenig Änderungen auf einmal machst und das.

Wird eingespielt auf den Server, das heißt noch nicht, ob das

deployed ist. Ja, aber die Änderung im Code wird ja auch nachvollziehbar getrackt über unsere Versionierungssysteme, die wir so haben und im Prinzip, wenn ich es jetzt richtig verstehe hast, was du jetzt auch noch sagst ist und genauso kleinteilig und mit der gleichen Philosophie und Strategie sollten wir vielleicht das ganze Deployment, also bis zum Schluss das Ausrollen der Software auch betrachten und und vielleicht sogar irgendwie im Extremfall

jeden einzelnen Commit irgendwie deployen oder irgendsowas damit. Damit das einfach n kontinuierlicher Prozess bleibt. Das Ausrollen und genauso überschaubar bleibt wie wie die Softwareentwicklung in Inversionierungssystem selbst. Ganz genau. Im Endeffekt ist def ops, ich sag mal die reine Harmonie zwischen Softwareentwicklung und Betrieb und das zieht sich durch durch alle Ebenen.

Fangen wir an, du hast gerade von den Commits gesprochen, ein Commit. Wird in Git oder Subversion oder Mercury oder was auch immer für ein Versionskontrollsystem genutzt wird, dann wird automatisiert die die Tests

gestartet. Continuous Integration, ja, das ist die erste Automatisierung, somit kann der Betrieb sichergehen, Ah, alle Tests sind immer grün, wurden auch ausgeführt und kein menschlicher Fehler war da der die Tests vergessen hat, dann gibt es vielleicht Continuous Deployment beziehungsweise Delivery, dann gehen die einzelnen kleinen Pakete online. Das zieht sich aber auch weiter.

Das zieht sich zum Beispiel weiter im Betrieb wie Configuration Management ja mit mit ansible Chef, Puppet CF Engine Saul Stack oder wie soll auch er heißen. Das bedeutet, dass der Betrieb beschreibt im Quellcode, wie der Server aufgesetzt wird, ah OK, wenn der Server da ist, dann soll da ein Linux System installiert werden und dann soll da ein Git demon installiert werden und dann soll da ein Docker deamon und dann soll da noch Wim installiert werden.

Und da sollen diese folgenden 5 Cronjobs installiert werden. Und gut, dass man das Deklarativ beschreibt und dass das dann auch versioniert wird und auch nachvollziehbar wird, zum Beispiel auch für die Softwareentwicklung, aber auch für das ganze Operations Team. Ihr kennt das vielleicht auch, vielleicht nicht in einer kleinen Firma mit 4 Leuten, aber wenn man 568 ist man 2 Leute im Betrieb hat, dann heißt es so, der eine geht in in den Urlaub, Freitagabend setzt man sich noch

mal eben hin. OK welche Änderung hast du denn jetzt diese Woche an welchen Servern gemacht? All diese Gespräche, diese Übergabe finden dann gar nicht mehr statt, weil es ist ja alles dann in Git, weil man sieht ja, was der Kollege dann in den Konfigurationsmanagement eingecheckt hat. Ah OK, git wurde auf diesen Servern geupdatet und jetzt haben wir nicht nur Wim als Editor, sondern auch Nano auf dem Server installiert oder

ähnliches. Und ihr wisst doch alle, wenn die Person im Urlaub ist, dann kommt Murphy um die Ecke, dann stürzt irgendwas ab und dann muss man den Kollegen anrufen, wenn da nichts dokumentiert ist beziehungsweise wenn wenn das nicht nachvollziehbar ist. Und so zieht sich diese Automatisierung einfach komplett durch. Den ganzen Stack, nennen wir es mal ich. Hab mal ne Frage n bisschen weg von der Technik.

Wieviel Spaß macht n das also ist zum Beispiel so n Konfigurationsmanagement wenn ich auf der einen Seite als Softwareentwickler sagen kann ah ich bau n cooles Feature. Auch vielleicht n kleines und das find ich total toll.

Dann kann ich mich damit super identifizieren und wenn ich auf der anderen Seite ja irgendwie nen Server in irgendeinem Dokument file nehm ich an beschreibe und sage OK da muss jetzt n dieses und jedes Betriebssystem drauf und die und die andere Software noch vielleicht ne untere Frage aber ist das so richtig was wo man so richtig so auch sich begeistern kann ist das cool? Das ist so n ja und nein.

Also ich glaub ist so ne Hassliebe und ich erzähl dir mal jetzt ne ne kleine Geschichte es es war glaub ich so 2014 2015 hab ich bei Trivago gearbeitet und da hatten wir einen sehr dicken Server da stehen. Dieser Server hatte bestimmt 300 oder 400. Conjobs laufen ja mit ganz vielen Skripten und allem drum dran, da die Skripte haben

gefühlt alles gemacht. Ja von irgendwelche Reports generiert und per e Mail Rausgesendet über nach Booking Connected irgendwelche CSV Dateien runter und hochgeladen und ja also ganz ganz viel und haben sich auch die zu diversen APIS, connected und so weiter und irgendwann hatte dieser Server n kompletten Hardwareschaden dieser Server war natürlich ich nenn das mal historisch gewachsen und manuell

aufgesetzt. Dann mussten wir einen neuen Server aufsetzen und wir mussten diese 350 3 400 Kronjobs

reproduzieren. Den Code, den hatten wir alle im Versionskontrollsystem, den da auf die Kiste zu schieben, das war jetzt nicht das Problem, das Riesenproblem war eigentlich zu wissen, welches Skript, welche Netzwerk Connection wohin macht und wer welche schreibzugriffe wohin braucht und da das alles manuell aufgesetzt wurde, kann ich dir jetzt mal sagen das manuell aufzusetzen, das macht keinen Spaß den ganzen Server initial. Wenn du schon etwas hast.

In Configuration Management zu kippen, zu Gießen, also, das bedeutet, alles zu Reverse Engineering und dann auf zum das ist jetzt auch nicht so spaßig, da bin ich, da bin ich bei dir hinten dran, einfache Änderungen zu machen und einfach sicher zu sein, okay das funktioniert und wenn der Server wieder einen Hardware Schaden hat, dann kann ich innerhalb von 15 Minuten den gleichen Server in den gleichen Zustand genauso wieder aufsetzen, unter der Voraussetzung, dass sich niemand

pss hat auf Connected hat und dann manuelle Änderungen gemacht

hat, ganz klar. Das ist n schönes Gefühl, ne und jetzt kann man natürlich sagen, OK Legacy verdient das Geld, wir haben alle Infrastruktur muss mach ich jetzt die Aufgabe und schiebe ich alles von meiner existierenden Infrastruktur in so Configuration Management automatisieren ja das muss jeder selber wissen ob das Invest. Irgendwie notwendig ist ja aber bei jedem neuen Projekt könnte man ja direkt so starten, dann fängt man an, OK, was brauche ich, ich brauch jetzt hier eine

Mail, Server, Konfiguration und so weiter und sofort ja ich mein was Configuration Management für die Pakete und für die Software auf einem Server ist. Ist ja unter anderem zum Beispiel Terror Form für die Infrastruktur selbst. Ja wir reden mal dann zum Beispiel über. Amazon Web Service über den Cloud Dienst da sagt man, da gehen die seltensten Leute ja hin in die Konsole.

Ah, ich klicke mir jetzt eine Compute Instanz, also eine EC Tool Instanz einen Server hin und dann eine lambda Funktion und so weiter sondern viele die fangen an das in Quellcode zu definieren. Ich möchte einen Server haben, dieser Server soll 5 CPUS haben und so und so viel RAM und so weiter und dann drücke ich Play und irgendwann kommt dann eine grüne Nachricht mit einem Daumen hoch. So jetzt habe ich einen Server ist ja nichts anderes

eigentlich. Das ist Infrastructure ist Code, nehme ich an. An der Stelle. Genau das, das das nennt man Infrastructure, ist Code. Wie du merkst, gibt es halt verschiedene Ebenen. Ne, du hast auf der einen Seite die Infrastructure ist Code für deine deine Server und wir haben jetzt gerade über die Cloud geredet, aber das funktioniert on premise genauso, auch wenn du wie m Ware und proxmox hast und was weiß ich nicht was du da

betreibst. Dann gibt es die Pakete auf dem Server, das nennt sich Configuration Management und was da oben drauf kommt ist in der Regel deine Custom Software die du schreibst und das kannst du dann über irgendein Deployment Tool gitab Actions Jenkins. Spinneker Circle, CI und was es da nicht so alles gibt. Man muss ja, um das zu verstehen, muss man ja auch und, und dass es so komplex ist heute und dass es die Thing devops gibt, NSRE und so weiter das hat

ja auch was mit der Zeit zu tun. Also ich fand es jetzt ganz schön, ich greif noch mal dein Beispiel aus von dem einen dicken Server mit den vielen Conjobs, so sah ja die Welt früher aus und da war die Softwareentwicklung komplex, da hatten wir typischerweise viel monolithischere Codes und so weiter das hatte auch so seine Dinge, aber es wurde quasi deployed zu 123. Maximum dicken, fetten Servern, die auch quasi in sich selbst monoliten waren, die ja da hab

ich dann halt ne IP Adresse und ne DNS und so weiter schick einfach alles klar so mit den Nachteilen die wir gerade gehört

haben. Das wie muss man dann halt irgendwie schwer konfigurieren und auch auch irgendwie n Backup irgendwie hinkriegen, dass du ne ausfällst Single Point of Failure und so weiter ja so jetzt ist aber dir die Zeit gekommen, dass wir ja das Ganze, das dieses Ganze das Wort Cloud ja was bedeutet das, es bedeutet ja, dass ich anders Software schreibe, dass ich nämlich quasi meinen.

Eine Anwendung, die logisch immer noch eine Anwendung ist, aber technisch quasi verteile, und zwar tatsächlich verteile

Netzwerktechnisch verteile. Wir haben fast alle größeren, moderneren Softwareanwendungen, sag ich mal, sind ja keine monolithischen Systeme mehr heutzutage, sondern in sich selbst verteilte Systeme, und das ist eigentlich n unglaublich kompliziertes Problem. Ja, früher hat man gesagt, verteilte Systeme, ja da gibt es ne, wenn du Computer Computer sag ich schon in Informatik studierst.

Gibt es Semester, ja verteilte Systeme, was da alles kompliziert, weil die können ausfallen und so weiter aber das

hat man halt gemacht. Ja man hat halt also die Anwendungen führen halt auf verteilten Systemen auf, also auf mehreren Servern und so weiter und auf einmal Krieg ich ja n riesen Problem ja viel größeres Problem als nur einen Server und um das quasi wieder zu managen entstehen halt wieder neue Hilfsmittel. Ja das sind halt so devop Tools von den Daniel hat auch gerade ja schon gesprochen ne, insofern geht das immer weiter und diese diese Systeme und diese Services

früher gab es ja auch noch kein AWS ja. Und dann, und das kann ich auch jetzt kurze Anekdote, ich kenne auch einen Softwareentwickler, der mit mir mal gearbeitet hat in der vorherigen Firma, der der hat ganz klassisch React Frontend programmiert und so und hatte da auch viel Spaß dran und dann ist er eingetippt, das erste Mal in das was du gesagt

hast. Infrastructure the Code, also bei AWS dann auf einmal jammel Files zu schreiben, die im Prinzip Konfigurationen sind, die krasse Sachen machen, wenn man dann einfach da rein schreibt oh ich brauch jetzt mal hier n Server und da n Server und noch einen. Und da installiere ich das, das, das und das hin und dann muss.

Ich hat das ja auch noch irgendwie Bedingungen, das muss nacheinander und so, und dann drückt man da auf den Knopf und das kommt hoch und tatsächlich, dann kann man das in der UI angucken, grün ja, alle meine Server sind da, auf einmal kann ich da was hin deployen und so, und ich glaube schon auch dem

hat das sehr viel Spaß gemacht. Ja, dass wenn man das auf dem Level macht, kriegt man auch ein Softwareentwickler hin, der Bobs zu machen, der ist bis heute dieser Softwareentwickler, weiß ich ist heute noch der Bobs engineer, glaube ich sein offizieller Titel. Noch nicht in die SRE Welt

aufgestiegen, oder? Ich weiß es nicht umgestiegen, aber das das Macht schon auch Spaß, wenn man es auf diese Weise betreibt und halt nicht irgendwie vielleicht mit der Konsole wie ISSH Summons eigentlich so früher machte und dann immer Schweißperlen auf der Stirn hat weil und ich glaube das ist auch noch mal was Andy sagen wollte, dieses SSH Krams, das ist quasi so live im Produktionssystem rumhacken ja also wenn du dann n Fehler machst und das hab ich selber

schon sehr oft gemacht. Ist halt Feierabend, dann ist sofort deine Anwendung weg. Für alle, für alle 1000 Nutzer,

die das irgendwie haben. Ja und da ist halt nichts mit Zurückrollen oder irgendsowas ja weil SSH und so, das ist halt Bär Metal sag ich mal das das machst du und hast es gemacht, das wird im Notfall noch nicht mal irgendwie getraced und aufgezeichnet ja gibt es n paar Kommandos aber schwierig ja während ja bei diesen devop Sachen wir stark daran sind, dass auch immer mal da was falsch macht, dass man das irgendwie auch reverten kann und so weiter dass du da auch

Snapshots machen kannst und so, ja. Also um die um die Thematik mit Def Ops einmal vielleicht holistisch abzuschließen. Das geht, da geht es wirklich um die Harmonie der Zusammenarbeit zwischen Softwareentwicklung und Betrieb, um den Betrieb auf der einen Seite automatisierbarer zu machen, ja, mit den Best Practices aus der Softwareentwicklung auf der anderen Seite alles was automatisiert ist. Da kann ein Mensch kein Fehler

mehr machen. Burkhard, Du hast das gerade gesagt, man gibt einen einen Befehl manuell in einen Server ein. Es reicht ja schon ein ein Leerzeichen, teilweise ja und man löscht nicht den Ordner, man löscht nämlich ganz rot oder ähnliches. Ja, also das geht ratzfatz und alles was in Software gegossen ist, da sagt man dem Computer was zu tun ist.

Natürlich unter der Voraussetzung, dass das wenig Bugs hat, hat man da keine menschlichen Fehler, aber wenn man jetzt sagt, OK, ein Softwareentwickler kümmert sich um die ganze Cloud Infrastruktur, dann ist das auch

zu kurz gedacht, denn. Def Ops ja, es sind immer noch 2 Berufe und wenn ein Mensch 2 Berufe auf einem sehr hohen Niveau machen könnte, was natürlich nicht geht, weil es sind ja 2 Berufe, dann kommt nämlich der ganze schmu, ich sag mal in die Sache, der gerade getrieben wird, weil Software Engineers sind in der Regel sehr gut Software zu schreiben und die können auch was auf dem Server deployen. Wenn es aber an zum Beispiel an Netzwerk, an Netzwerksicherheit

und so weiter geht und. Ach, da fangen die meisten Software NGS an zu struggern, wohingegen dann ein Systemadministrator sehr stark zum Beispiel im Netzwerkdesign ist. Netzwerkisolation, dass du von der einen Applikation nicht auf die andere kommst, falls sie kompromittiert ist, sicherheitstechnisch und co. Dafür ist dieser Systemadministrator in der Regel schwächer in der Softwareentwicklung.

Er kann vielleicht ein bisschen Rumskripten mit Bash oder ähnliches und da kommen diese 2 Expertisen einfach mal zusammen, setzen sich vielleicht mal in einen Meetingraum oder an einen Tisch und dann. Bauen das einfach mal zusammen. Ja, machen so n bisschen nur noch Sharing. Danke für die Einordnung. Ich würde, wenn ihr auch mögt, gerne n bisschen noch mal in die Praxis gucken vom SRE. Also wir haben natürlich schon so n paar Ziele und Themen und

und und die euch da beschäftigen rausgehört ne also ich fand das Beispiel jetzt auch ziemlich gut, auch wenn es natürlich n sehr rudimentäres ist. Also ein großer Server der dann weg ist wo man alles neu aufsetzen muss, manuell ne, aber was bedeutet das SRE? Oder SR. Engineer zu sein oder auch so n Team zu leiten heutzutage. Was sind da die Themen, die anfallen, worum kümmert man sich? Der Burkhard hat das ja gerade

schon gesagt. Die ganze Industrie bewegt sich eher zu mehr Applikationen, zu mehr Applikationen, die dann jeweils, ich sag mal, ein spezifisches Problem behandeln, wohingegen man früher eine große Applikation hatte, hat vielleicht andere Gründe oder verschiedenste Gründe, auf der einen Seite, dass die Fachdomänen immer komplexer werden. Weiß ich nicht.

Man hat eine Steuer App ja und auf einmal muss man zu Corona die Mehrwertsteuer von 16 von 19% auf 16 reduzieren und so weiter und das macht dann macht man vielleicht im im Steuerservice oder ähnliches, aber nicht im Rechnungsservice und so weiter und sofort ja, also das bedeutet, die Fachdomänen werden komplexer, dann natürlich, das alles sind mehr Leute online gekommen, jeder ist ja mit seinem Handy online und im Web online, das bedeutet es gibt viel mehr

Nutzer, das bedeutet einzelne Komponenten werden. Mehr beansprucht als andere ja, ist auch so. Zum Beispiel ein Klassiker, und das bedeutet, die muss man

anders skalieren. Punkt ist, man hat in der Regel immer ein verteiltes System, ja, auch wenn du selbst nur eine Applikation hast, deine Applikation spricht irgendwo mit einem Mail Dienstleister, deine Applikation spricht vielleicht irgendwo, dann noch mal mit Chat, GPT jetzt ja oder oder oder oder vielleicht auch schon einfach nur mit einem MQTT Server oder einer Datenbank und diese Datenbank ist wahrscheinlich auch nicht nur ein Server sondern vielleicht 2

Server. Ja, und mit einem Replica hinten dran und so weiter der Clou ist jetzt eigentlich, wer kümmert sich eigentlich darum, dass wenn wir netzwerkprobleme haben, die Applikation einfach weiterläuft? Wer kümmert sich darum, wenn die Datenbank einmal neu startet, dass die Applikation automatisch reconnected wer kümmert sich eigentlich um all diese ganzen Themen, die in einem verteilten System schief gehen können? Und ich habe gerade nur von Netzwerk gesprochen.

Ich habe noch gar nicht von Inkonsistenzen gesprochen in Verteilsystemen, wenn sich mehrere Systeme synchronisieren müssen und co. Das ist die eine Baustelle, die andere Baustelle ist natürlich das das Monitoring, also die Überwachung, also eigentlich die Frage, tut meine Applikation das, was ich eigentlich möchte, was sie tut, wer übernimmt das denn eigentlich, weil je komplexer die Applikation, desto komplexer wird natürlich auch das Monitoring.

Heutzutage reicht es nicht mehr, läuft meine Applikation, läuft der Prozess. Heute möchte man genau wissen, die durchschnittliche Anzahl in einem Warenkorb sind 5 Artikel, dann klicken 30% auf jetzt zum Zahlungsvorgang wieviel brechen beim Zahlungsvorgang ab und so weiter und sofort klassische E Commerce funnel Optimierung es geht also nicht nur von außen liefert meine Applikation einen http code 200 zurück, sondern es geht auch um das innere Leben und diese Metriken.

Man kann schon fast sagen Business Metriken. Müssen rausgezogen werden und natürlich gehen auch ins Reporting und darauf macht man natürlich auch Alerting.

Wenn jetzt Amazon eine Stunde keine Bestellung mehr durchkriegt, weil die da einen Fehler haben, dann kann der Bestellservice zwar online sein und der kann auch eine 2 hunderter zurückliefern html Zurückliefern, wenn da aber keiner bestellen kann, aus welchen Gründen auch immer und wenn die das nicht überwachen, dann wissen wir alle, dann gehen da echt ein paar Millionen irgendwie den Gullydeckel runter. Eigentlich hat SRE. Die Aufgabe, skalierbare und hochzuverlässige Systeme, ich

sag mal herzustellen. Und wenn du jetzt fragst, ja, was fällt denn da jetzt an? Das ist natürlich sehr, sehr spezifisch, auf welche Applikation man da baut, wenn man jetzt zum Beispiel in einem Datenbank s Service Provider arbeitet, dann kümmert sich natürlich sehr viel, wurde jeden Tag ein Backup gemacht, läuft die Replikation kontinuierlich, Überwachungen ob bestimmte User. Angelegt wurden oder nicht?

Wieviel super User habe ich auf der Datenbank, ich habe hoffentlich immer nur einen, wenn ein Zweiter ist Alarm vielleicht ein Security incident also es kommt dann ganz darauf an in welcher Applikation du arbeitest. Damals als ich bei Trivago gearbeitet habe, haben wir uns ziemlich viel um Lese und Schreibzugriffe von Webapplikationen, von PHP und von Java auf Datenbanken spezialisiert um das zu optimieren, denn ihr wisst, wenn eine Webseite 50 Millisekunden schneller ist, dann.

Sagt man, OK, da geht eigentlich mehr durch, ja mehr Geld durch

mehr Geld wird verdient. Als wir dann zum Beispiel die Webseite Trivago auf mehrere Data Center verteilt haben, weltweit nach Amerika, Europa und Asien, da ging es viel darum, welche Daten müssen synchron, also sofort von Amerika nach Europa geschrieben werden und welche Daten können warten, welche Daten können wir asynchron zum Beispiel mit einem Delay, mit einem Verzug von einer Minute oder so weiter versenden, nach Europa nehmen wir mal als klassisches

Beispiel. Wenn sich jemand einloggt, dann speichert man in der Regel das letzte Login Date mit.

Das ist gut, das braucht die Business Intelligence und das Data Warehouse, um zu wissen, wieviel Daily Active User habe ich denn, aber das ist jetzt keine Information die ich in realtime von Amerika nach Europa schicken muss, das ist zum Beispiel so ein Informationsdatensatz, der kann auch mit einem Verzug von 5 Minuten in Europa in der Datenbank klemmen, um solche Themen haben wir uns sehr viel gekümmert bei einer Web Applikation.

Ich will noch mal was einwerfen, ist in so einem Bild vielleicht und ich lass mir das jetzt gleich mal von Andy bestätigen,

ob das richtig ist. Also ich hab auch neulich ist es auch neulich, ist glaub ich schon wieder 2 Jahre her mit auch einem alten Kollegen gesprochen, der ist auch SRE Entwickler, Ingenieur also in die SRE Berufslaufbahn reingegangen, einer sehr großen Firma und der hat so n paar Sachen gesagt weil ich muss das auch, da hab ich überhaupt das erste Mal kam mir das so entgegen, musste erst mal verstehen was ist das überhaupt für ne Aufgabe.

Und warum ist die sinnvoll? Ja, wenn so, als wenn man als purer Softwareentwickler rumspringt, dann ist es nicht gleich klar, warum man das brauchte und der hat mir auch gesagt, Pass auf die, die diese Firma und diese Software, die ist so groß und so komplex und auch schon so lange gewachsen,

dass es auch so ist. Und das hat er noch gar nicht besprochen heute, deswegen bring ich es mal rein, dass es auch so ist, dass es eigentlich gar keinen einzigen Typen mehr gibt, kein einziges Gehirn, was alles weiß über alle Zusammenhänge und

so weiter ja weil. Das sag ich jetzt noch mal, wenn wir so große Systeme haben, die immer weiter verteilt werden, wo ja riesige Teams von softwareentwicklern, wir sprechen ja nicht von 2, sondern von 200 vielleicht da, die machen ja auch was, ja, und da entsteht noch ein Service und noch ein Service und noch eine Komponente, ja, das ist ja wie ein ganz komplexer Organismus am Ende des Tages, der da in Runtime, der da lebt, ja der, der, der am Leben erhalten wird,

der stirbt ja nicht, du machst das ja nicht aus und wieder an, das bleibt die ganze Zeit da, und ständig kommt was dazu und wird wieder was hinzu und wieder was weggenommen und so weiter also keiner weiß eigentlich so ganz genau. Wer ist hier alles da und wer spricht mit wem? Und deswegen seh ich das so n bisschen mit dem SRE wieso nen das sind so die Ärzte sag ich mal.

Ja also der der Organismus der Mensch ist dann da und der ist hoffentlich gesund aber ich überprüf sie die ganze Zeit ja ich hab mein EKG und mein Stethoskop und das leg ich überall an und was heißt das? Wenn ich also ich gucke quasi so n bisschen von außen rein, das können wir aber machen weil wir mehrere Möglichkeiten haben, da würd ich gleich noch mal n bisschen nachfragen also es werden ja. Die Softwareentwickler werden ja angehalten, auch Logs zu

schreiben. Ja, also zu einer guten Softwarearchitektur gehört ja auch dazu, dass wenn ich jetzt irgendwas in Operation ausführe und vor allen Dingen, wenn irgendwas nicht klappt wie erwartet, dass ich quasi logs reingebe ja, und das ist das unterste Level und dann auch, kann ich natürlich, wir haben gerade gesagt, das ist Netzwerk und so weiter ich sehe ja auch, wenn irgendwas nicht funktioniert vom Netzwerk her ja und wenn mal eine Komponente

nicht funktioniert, ist ja noch nicht das ganze System tot, sondern vielleicht nur ein Teil und ich merke es gar nicht erst

und so weiter. Und das ist ja vielleicht auch n Aspekt. Also weil das einfach so n komplexes Gewebe geworden ist, dass wir einfach ne Mannschaft haben müssen, die ständig hier und da gucken, ob dieses komplexe Gewebe auch tatsächlich gut zusammen spielt, denn wir wollen im besten Fall vermeiden, dass der Endanwender derjenige ist, der sagt, hier Pass mal auf, ich hab hier seit 20 Minuten versucht mich einzuloggen, geht einfach nicht,

ja und wenn dir das nicht sofort sagt, dann verlierst du in dem in dem Moment ja schon Millionen Euros, weil es dicht ist und keiner weiß, ist das ne Transparenzmachung auch, ja. Ich bezeichne Sucrilability Engineering oft als so eine Art spezialisierte Softwareentwickler. Das heißt nicht bessere Softwareentwickler kannst du gar nicht, sondern nur Softwareentwickler, die sich auf einen Teil der der Infrastruktur und so weiter beschäftigen.

Ein anderes Beispiel ist, stellt euch vor, ihr habt einen mqtt Broker oder irgendeine Datenbank und ihr habt ganz viele Autos draußen und die Senden immer io t Nachrichten an an an die Datenbank und jetzt ist die Datenbank mal offline. Und ihr startet die neu. Und jetzt möchte die Datenbank

wieder hochkommen. Die möchte gerade hochfahren, aber die kriegt so viele Anfragen von ganz vielen Autos mit den Sensordaten, dass die sofort, wenn die hochkommt, wieder abstürzt, weil die überlastet ist. Ja, das ist so ein klassisches Klassiker. Ein klassisches Beispiel gibt es auch sehr viel in moderner Softwarearchitektur bei Microservices, ja, weil da kommunizieren ja ganz viele Services mit ganz vielen anderen Services. Und so kann man sich eigentlich

immer selbst abschießen. Was SAES dann unter anderem

machen? Klar, Softwareentwickler bauen ziemlich viel, ja OK, dann reconnecte ich ich, ich probier jede Sekunde ist er wieder da, ist er wieder da und das führt ja genau zu diesem Problem was ich beschrieben hab und wenn du jetzt SAE bist kann auch jeder andere Softwareentwickler gar keine Frage ja aber SAES kümmern sich da in der Regel drum, OK die Bauen dann zum Beispiel n Exponential Back Off und ne Gitta ein, das bedeutet die sagen OK ich versuch einmal.

Server ist nicht da. Ich versuche noch einmal Server ist nicht da, ja immer nach ein 23 Sekunden und wenn du 3 Fehlschläge hast dann wird gesagt okay ich warte einfach mal 5 Sekunden dann probiere ich nach den 5 Sekunden okay vielleicht warte ich mal länger 30 Sekunden ja das bedeutet du hast so einen exponentiellen Back off wo die Autos in diesem Fall aus dem Beispiel erst später wieder versuchen zu Reconnecten das bedeutet sie geben der anderen Seite die

Möglichkeit sich zu erholen. Und mit einem. Jetzt kommt ne Key frage, musst musst du das dann mit den Softwareentwicklern besprechen, dass sie das in den Code der Autos reinmachen und muss das erst n Firmware Update in meinen BMW geben damit es klappt oder ist der SRE ingenieur jemand der dann quasi ne Komponente ins Web stellt die ganz fett ist?

Die das alles abfängt und das für die Hinterliegenden also weißt du agierst du auch quasi im Quell in dem im originalen Quelltext der Anwendung, was dann irgendwie die der MQTD Client im jeweiligen Auto wäre. Wo man ja nicht ganz einfach n schnelles Update reinspielt. Oder ist es eher schon ne hinter hintergelegte Komponente, die in der Cloud ist? Oder ist es einfach gar nicht Thema und man macht halt was gemacht werden muss? Ja um um das System stabil zu

halten? Ja, da ist die Antwort It Depens und da kommt es dann natürlich ganz drauf an, was du für Möglichkeiten hast und wie die ganze Architektur aufgebaut ist. Kann man so im Allgemeinen nicht sagen. Ich würde sagen, das Beste ist immer, wenn die Clients die die Daten senden diese Funktionalität haben, ja weil dann ist nämlich völlig egal was in der Mitte ist. Quasi wie wie in möchten leben das Problem möglichst dicht an

der Ursache bekämpfen. Und wenn ich halt nicht dicht an die Ursache rankomme, sie vielleicht kenne, dann dann geh ich n Stück weiter weg, aber also je je näher dran desto besser. O. K. Und den großen Organisationen nutzen. Die Softwareentwickler bauen dann nicht mehr diesen exponential Backout von der Gitta automatisch ein, sondern sie nutzen irgendwelche vorgefertigten Tools und Libraries, die Bauen die dann ein und sagen, OK, ich möchte Daten an.

Das Data Warehouse in ja und dann gibt es da eine Data Warehouse Komponente und dann gibt es da eine Send Methode und die macht das dann alles. Für mich war jetzt tatsächlich neu, oder? Und das hätte ich jetzt so nicht erwartet, dass also so NSAE auch wirklich in das Produkt dann eingreift und nicht nur in die Infrastruktur es.

Sind Softwareentwickler, und das ist der große Unterschied, es sind Softwareentwickler, die Softwarealgorithmen schreiben, die auch Tooling schreiben, auch weit mehr als n bisschen bash oder ähnliches. Ein Beispiel was, was wir haben ist, wir haben ganz viel Support, Tooling, wenn Leute neue Alerts hinzufügen wollen, das bedeutet sie, sie messen einen Wert und wollen dann notifiziert werden auf ihrem Handy A der geht gerade runter oder hoch. Diese Nachrichten kann man halt konfigurieren.

OK wenn dieser Wert über 5 Minuten über 500 ist, dann informier mich bitte und diese Definitionssprache da kann man auch sehr viel Fehler machen, das bedeutet wir haben auch Tools wenn irgendein anderes Team eine neue Notification reinsetzt. Wir checken die automatisiert ähnlich, so wie Unit Test. Nennen wir es mal. Wir prüfen auch okay in den letzten 30 Tagen wärst du 500 Mal informiert worden, möchtest du das?

Also das bedeutet wir berechnen dann den Wert retrospektiv um halt einfach solche ich sag mal alert Bomben zu vermeiden, weil diese Alerts, die schauen halt auch nicht auf die Uhrzeit, die feuern halt auch um 03:00 Uhr nachts, das sind zum Beispiel so. Ja so so.

Support Tools die SES unter anderem auch bauen, aber sie kümmern sich halt auch darum, dass die Infrastruktur beim Neustart stabil bleibt, dass bei verteilten Systemen serverausfälle oder ganze Ausfälle von Gebäuden ja abfangbar ist und das alles einfach weiter läuft und das ist halt nicht nur Infrastruktur, man kann nicht nur immer einen Server einstellen, da geht es viel darum, wie verhält sich die Applikation wenn die Datenbank mal nicht da ist.

Ja, und das braucht natürlich, und das macht jetzt für mich Sinn, weil ich greif jetzt noch mal kurz das MQTT Beispiel auf, weil das ist wirklich n Klassiker und bin ich jetzt nur ich mach was vorsichtig nur in Anführungszeichen ne ich will das jetzt nicht diskreditieren, die Rolle aber bin ich jetzt n klassischer Systemadministrator. Dann weiß ich vielleicht nicht genau Bescheid über das MQTT Protokoll und vielleicht die Quality of Services und so weiter und kenne zum Beispiel

der jetzt hier kritisch ist, zum Beispiel im Zusammenhang nicht. Wie ist die Anwendung konfiguriert im Auto, wenn die Datenbank nicht da ist oder der Server nicht erreichbar ist, ja dann werden vielleicht, und das kann ich alles einstellen, das muss ich aber wissen, ja dann werden zum Beispiel die Nachrichten, die eigentlich gesendet werden hätten sollen gecasht lokal ja. Und wenn, dann kommt das ja auch, dann ist das doppelt sheet sag ich mal.

Ja dann kommt das System wieder hoch und es ist nicht nur, dass 1000 Autos gleichzeitig wieder was senden wollen, sondern vielleicht auch 1000 Auto gleichzeitig das Senden wollen, was die letzte Minute nicht senden konnten und jeder jeder einzelne auch noch ne viel größere Welle abpflegt sogar, aber das kann ich ja nur verstehen, dass das überhaupt das Problem ist oder 1 werden könnte.

Wenn ich gewisse Ahnung dann tatsächlich von der Software hab, von meinem QTT Protokoll und so weiter wie das funktioniert und wann er da was schickt und wer was wo cached und so weiter und sofort, das ist ja beliebig kompliziert

heutzutage. Ja alleine wo Daten irgendwie zwischengespeichert werden, wann was neu gesendet wird und so weiter je nach Protokoll und je nach Bibliothek die ich nehme ist das ja alles sehr sehr im Detail sehr sehr versteckt und und sehr softwarelastig was ich da wissen muss, ja und um dann zu verstehen warum kracht mir mein System hier hin ja warum wenn ich den Server hochstart werde ich hier bombardiert, wer ist das da? Das sind alles Aufgaben, die

normale Softwareentwickler ebenfalls übernehmen können.

Man beschäftigt sind sich nur für eine längere Zeit mit einem anderen Detailbereich, nur der Punkt ist, dass Softwareentwickler in der Regel dafür bezahlt werden, ein Produkt nach vorne zu bringen und sich nicht, ich sag mal, um sich selbst kümmern, um Stabilität und Co. Und deswegen sollte die Firma etwas größer sein, damit die sich das auch leisten kann, solche Positionen abzustellen, solche Leute abzustellen sich genau nur um Hochverfügbarkeit zu kümmern. Thema Verfügbarkeit oder?

Uptime ist wahrscheinlich auch hier ein Inbegriff. Sind das dann Messgrößen für euch? Ich sag mal als als als Sales Mensch vertriebsmensch ganz fies. Ja man kann natürlich dann auch viel verhandeln und verkaufen und dann gibt es natürlich Firmen, denen ist Uptime ganz wichtig und dann habe ich ja erst mal eine Anforderung, die ich im besten Fall ja abgeklärt habe vorher, also 99 einhalb Prozent oder so was ist ja typischerweise etwas oder es gibt dann Applikationen, die

haben 99,9%. 100 hab ich noch nie gesehen, sollte man wahrscheinlich nicht versprechen. Sind das Anforderungen, die dann an euch herangetragen werden oder abgestimmt werden und dann hat man sag ich mal das große Paket oder das kleinere Paket, wenn es weniger uptime ist, die man braucht et cetera, also wie läuft so n so n Verhandlungsprozess und welche Ziele werden dann auch da

gesteckt? Ja, das Thema Uptime ist natürlich oder messen generell ist natürlich n Riesenthema in der in der ganzen Dev OPS und seit Reliability Engineering

Ecke nenn ich es mal. Also im Endeffekt jeder Service den ihr auch nutzt, sei es github, sei es canva, sei es Jet, GPT und wofür ihr Geld zahlt, habt ihr auch in irgendeiner Art und Weise ja einen Vertrag und wenn ihr mal in die AG BS schaut, dann steht da bestimmt irgendwie sowas wie Service Level Agreements oder so und umso größer euer Vertrag ist, desto mehr wird darauf natürlich auch geachtet. Service Level Agreements sind jetzt mal ganz Simplifiziert

gesagt. Ein Vertrag, was der Hersteller euch liefert und was zusichert. Up time. Mein Service ist verfügbar, ist jetzt mal so das offensichtlichste und da redet man oft so von wie viele Neunen hat denn mein Service 3 Neunen eine up Time von 99,9% 4999,9959 und so weiter also immer wenn ich die Zahl erhöhe geht es nur um die Nachkommastelle. Klassischerweise sagt man wenn Github jetzt. 2 Stunden offline ist, dann könnt ihr nicht arbeiten, was eigentlich nicht wahr ist, weil Git auch ein

dezentrales Protokoll ist. Aber das ist eine andere Thematik. Dann könnt ihr aber theoretisch sagen, ja so, jetzt kriege ich Geld von github, weil die haben ja ihren SLA, ihr Service Level agreement nicht erfüllt und wer das Geld dann später kriegt, sei auch mal dahingestellt, aber man muss sich nur mal ganz kurz bewusst werden, was das denn heißt, wenn wir eine Up Time von 4 neunen haben, also 99,99%. Dann darf der Service 52 Minuten pro Jahr offline sein.

Ja, über das ganze Jahr, wenn wir jetzt sagen, wir haben eine Uptime von 59, also 99,999, dann darf der Service 5 Minuten pro Jahr offline sein, wenn wir jetzt sagen, wir gehen auf 6 neunen und ich kenne keinen Service, der 6 Neunen liefert, dann darf man im Jahr 32 Sekunden offline sein. Aus meiner Erfahrung 5 neunden wer sowas schafft, da zieh ich meinen Hut vor Q dos Engineering auf höchstem Niveau die Stripe. Ap oder kann der Nutzer. Oder?

Kann der Nutzer. Ja, aber auch wenn also die Nutzer sind ja gar nicht mal so relevant, sondern wieviel Änderungen machst du an dem Service? Aber die Stripe API der Zahlungsdienstleister Stripe, der hat zum Beispiel letztes Jahr ich glaub 5. Neunen und n paar Gequetschte hinten dran geschafft. Sehr sehr hohes Engineering, Exzellenz muss man muss man sagen, so wenn man die ganze Sache mit SLA aber runterbricht, das nennt man SLA und wenn man aus Service Level agreement und

wie wird sowas berechnet? Hinten dran im Engineering ist das sind die Stichwörter SLO und SLI Service Level Objective und Service Level Indicator brechen wir das Mal runter ein Service Level indicator ist eigentlich die Metrik die man misst.

Sagen wir jetzt mal, ihr macht jede Minute eine Testabfrage an eure Webapplikation. Ist diese Webapplikation noch da. Und immer wenn die da ist, dann schreibt ihr irgendwo eine 1 rein in so eine zeitbasierte Datenbank. Das kann euer Service Level Indicator sein, euer Service Level objective sagt jetzt okay ich habe jetzt den Indicator, ich habe jetzt die Uptime, die teste ich jede Minute wie. Lange oder wie oft darf ich denn

eine 0 zurückbekommen? Wie oft darf also die Applikation offline sein, sagen wir mal in 80% der Fälle muss eine 1 zurückkommen, muss sie also online sein. Der SLO ist also ein Schwellenwert auf der Metrik, weil ihr habt ja dann ihr kriegt 100% eine 1 zurück, also ist online oder 99% der Fälle so und. Jetzt habt ihr diese, könnt ihr visualisieren, die könnt ihr sagen okay wenn euer Wert über dem Schwellenwert ist.

Also ihr seid länger offline als Eure eigener SLA ist besagt, dann könnt ihr sagen okay wir sind besser als wir versprechen. Wir sagen wir haben eine Uptime von sagen wir mal 99% ja fangen, fangen wir mal 99% an, somit könnt ihr fast dreieinhalb Tage offline sein pro Jahr, jetzt sagt ihr cool, in diesem Jahr könnt. Waren wir aber nur 2 Tage

offline. Das bedeutet wir sind besser als wir eigentlich unseren Kunden versprechen, dann würde man sagen okay den Schwellenwert, den erhöhen wir, weil ihr habt die Basis ja sehr, sehr gut geschafft, deswegen gehen wir jetzt einfach mal auf 99,9%, da darf man nur noch 8 Stunden offline sein pro Jahr, das bedeutet, ihr erhebt euren eigenen Anspruch an eure eigene Qualität, umso mehr ihr die Stabilität verbessert und jetzt ist es so, wenn man die.

Dauerhaft über seinem eigenen Schwellenwert, über seiner eigenen Service Level Objective ist. Dann kann man sagen, immer wenn wir drüber sind können wir in Innovation und Experimente investieren, weil wir wir liefern ja mehr als wir versprechen und immer wenn wir unter dem Schwellenwert sind, wenn wir ein paar Ausfälle hatten, wenn wir länger offline waren als wir eigentlich dürfen, dann legen wir alle Features beiseite und dann kümmern wir uns um Bugfixing und Stabilität wir.

Bis wir wieder über dem Schwellenwert sind. Es kann also auch ein objektiver Messwert sein, um endlich mal diese ganzen Diskussionen zu stoppen, dass die Entwickler immer sagen, wir müssen technische Schulden abbauen und wir müssen jetzt endlich mal Bugs fixen und dann der Produktmanager, Nein, wir müssen Features machen, Features, Features, Features, weil wenn nämlich die Firma sagt Okay wir bieten unseren Kunden so und so viel Prozent uptime, dann ist

das ganze Gespräch vorbei, weil. Dann dann, wenn wir unter diesem Versprechen sind, dann liefern wir das nicht, was wir unseren Kunden versprechen. Und sowas kann man halt machen, nennt sich Errorbudgets ja, dass man halt einen objektiven Messwert hat, wann man in Innovationen und Experimente AB Tests, Chaostesting und Co investiert oder wann man in Stabilität investiert, und das ist diese ganze Brücke. Und wie misst man jetzt oder wie validiert man?

Ob man den richtigen Service Level indicator, also die richtige Metrik hat, das ist ja auch eine Frage und da bin ich offen, die richtige Metrik zu finden ist unglaublich schwierig, aber ein guter lithmus Test ist, wenn ihr einen Ausfall habt, muss die Metrik nach unten gehen und wenn ihr keinen Ausfall habt, geht die Metrik nach oben, wenn ihr einen Ausfall habt und die Metrik verändert sich nicht, dann ist das nicht die richtige Metrik. Das klingt ja logisch, ja.

Ja, aber die die meisten Leute sagen, der wenn der Prozess läuft, ja oder so, die ihr müsst SL OS und SL is haben das Ziel die User Journey zu repräsentieren. Nehmen wir mal eine Datenbank, wenn der Benutzer zu der Datenbank nicht connecten kann, dann bringt die Datenbank nichts, wenn sie online ist zum Beispiel. Oder anders, wenn du, wenn du, wenn du misst, dass du, dass die Anwendung hochkommt mit dem 2. Hunderter, also dass ich

connecten. Meine HTTP service ist da, aber der ist eigentlich zerbrochen, weil die Datenbank nicht connected ist. Also ich kann eigentlich nichts machen, weil das der ganze Scheiß nicht abgespeichert wird, dann wär der der Indicator. Ja ich bin da und erreichbar auch irgendwie n bisschen bitter, weil ich bin zwar erreichbar aber nicht nutzbar ja also genau ist. Genauso komplex wie die Anwendung selbst und genauso individuell wie die Anwendung selbst.

Da muss man wahrscheinlich sehr gute Indicators finden, die die einem genau das widerspiegeln. Ja was du sagst, was User Journey Halt ist ja offen. Gesprochen.

Das ganze Thema war jetzt sehr simpel beschrieben, weil wenn man da mal reinsteigt da ist sehr viel Mathematik mit involviert über sogenannte Burn Rates und Windows und Co. Denn diese Metriken, die misst man jetzt nicht im hier und jetzt, sondern die misst man eigentlich über einen gewissen Zeitraum und der Zeitraum ist oft 30 Tage gewählt. Ja, was habe ich also für eine Uptime innerhalb von 30 Tagen und dann wird das immer so n Sliding Window genannt.

Das bedeutet die letzten 30 Tage werden einfach immer weitergeschoben und innerhalb der Windows kann man noch sogenannte Burn Rates ausrechnen und co. Es geht alles viel viel tiefer, aber fangen wir ganz einfach an, man misst eine Metrik, man setzt einen Schwellenwert fest und versucht immer über dem Schwellenwert zu sein, wenn man kontinuierlich über dem Schwellenwert ist, dann kann man den Schwellenwert n bisschen anheben, ja damit man sich sag mal sich n bisschen mehr fordert.

Ich hab jetzt noch mal eine eine letzte Frage zu dem Thema, dann können wir weitermachen. Noch mal zu dieser Metrik, also es kann ja so sein, dass ich voll ausfalle, zum Beispiel meine Software, ich sagen wir mal, ich bin 10 Minuten komplett offline ne und in diesen 10 Minuten, weil ich jetzt gerade nicht Amazon selbst bin oder Spotify da gewusst.

In diesen 10 Minuten hat halt kein einziger User irgendwas von mir gewollt von der Anwendung, ja die haben halt an der irgendwie geschlafen oder irgendwas ja oder haben wir nicht geklickt ja und dann hat das ja keiner gemerkt, ja. Jetzt, jetzt kommt die Frage, die du weißt schon worauf ich hinaus will. Ja ist denn würde ich jetzt das

verbuchen? Also ich weiß ich bin ausgefallen, das hattest du ja vorher auch schon gesagt, ich weiß aber auch, und das kann ich ja auch feststellen mit Metriken, es hat keiner gemerkt, ja ich bin so heimlich ausgefallen, ne. Wie stellst du das fest, dass kein Support Ticket reinkam, oder? Nee, weil du, du siehst ja, ob ne Anfrage zum Beispiel reinkam. Ne, also wenn ach so, nee sehe ich ja natürlich nicht, wenn der Server dann down war, hast du recht, ja.

Okay ist nicht ganz so einfach festzustellen. Ja, also. Es ist ungefähr so. Es gibt noch eine Story, das ist so ein bisschen confirmation Bias, was du da gerade machst. Also nach dem Motto, Es gibt eine Story von Kriegsflugzeugen, die sind Losgeflogen und kamen mit Schusslöchern in den Flügeln zurück und dann gab es eine Studie okay wo müssen wir diese Flugzeuge denn verstärken, und dann haben sich die Schusslöcher angeguckt, da müssen wir die

Flugzeuge verstärken. Das Riesenproblem ist, die Flugzeuge, die woanders getroffen wurden, sind abgestürzt und kamen nie zurück. Ja, kurzum, was misst du da und was verbesserst du da? Es ist unglaublich schwierig, die richtigen Metriken zu finden, das ist ein kontinuierlicher Prozess. Ja, lassen wir uns dabei stehen. Ja, gut. Und ich glaube, man sollte sich das vielleicht auch selber einfach vornehmen dann. Das ist irgendwie so ganz toll das das stimmt.

Aber ich bin ja hier auf der Fake Spur so unterwegs n bisschen, ja, das sollte man natürlich nicht machen, ja, aber. Ja, hab ich schon verstanden wie das gemeint war und jetzt jetzt ist da so n Absturz ja oder irgendwie n Service nicht verfügbar. Irgendjemand kann in ne Datenbank nicht reinschreiben

der da reinschreiben sollte was auch immer es ist aufgefallen es ist vielleicht sogar gravierend, alle sind in Panik, es ist n riesengroßes Büro alle Rennen durcheinander und. Streiten miteinander, wer ist schuld oder wie läuft das dann in so einem Team? Ja, ich denke mal hoffentlich nicht, aber cool bleiben. Arbeiten gibt es ne gewisse Eskalation müssen die Leute dann auch nachts aus ihren Betten raus und ein Computer irgendwie, wie läuft das wenn es mal nicht

so läuft? Auch n großes Thema was du ansprichst, Gerrit. Da geht es natürlich auf der einen Seite um Rufbereitschaft. Ja wer wird überhaupt informiert wenn wenn wenn was offline ist? Auf der anderen Seite geht es um Incident Management oder Incident Response fangen wir mal eben ganz kurz vorne an. Rufbereitschaft ein Ausfall kommt immer dann, wenn man ihn nicht braucht, egal ob man jetzt im Kino sitzt oder auf dem Geburtstag ist oder am Feierabend. Aber der kommt seltenst, wenn du

im Büro bist. Eine Murphys Law nennt sich sowas und im klassischen Sinne programmieren die Softwareentwickler irgendwelche Software und es wird auch Server deployed und die Administratoren werden dann nachts rausgeklingelt auf dem auf dem Handy, weil jetzt unsere uptime Metrik, die wir gerade gemessen haben, dann zum Beispiel Services wie Pager Duty oder Ops Genie oder.

Irgendwen informieren und dann klingelt dein Handy und dann musst du, sofern es denn deine Firma alles so sagt, raus und das Problem beheben, denn du hast vielleicht auch Nutzer, die Nachzuarbeiten. Im klassischen Sinne machen das die Software die die der Betrieb und da ist immer das Problem, wissen die genau was geändert wurde, haben die Kenntnisse über die Software über die über das Innenleben der Software in

modernen Setups gibt. Bei Satrilability Engineers und Dev Ops und allem drum und dran sind viele Software Engineers ebenfalls auf Rufbereitschaft. Ich hab noch nie n Software Engineer gesehen, der das wirklich toll findet.

Ja auf der anderen Seite finde ich es einfach nur fair, denn du machst ja die Änderung ja und ich hab auch schon Software Engineers gesehen, die wollen Freitagnachmittag ne neue Version in Produktion bringen, ja und dann auf die Grillparty gehen finde ich immer n bisschen schwierig, ja.

Nennt man dann over The Wall Deployment so nach dem Motto Hier ist mein Paket ja nach mir die Sintflut und das ist halt unfair dem Betrieb geben, weil vielleicht möchte der Betrieb auch auf die Grillparty gehen, deswegen würde ich sagen, in dem ganzen Def Ops Sre Part auch Software Engineers sollten Rufbereitschaft machen, denn ich denke dadurch wird man einfach nur ein besserer Softwareentwickler, weil du dich viel mehr damit auseinandersetzt.

Wie wird die ganze Software eigentlich betrieben? Was passiert, wenn Neues neu gestartet wird und so weiter und sofort. Du machst dir viel mehr Gedanken als jetzt, nur welche Farbe hat der Button?

Das ist die eine Thematik, jetzt hast du aber einen Ausfall und jetzt geht in das ganze Thema Incident Response Incident Management das erste Mal wenn man sowas erlebt dein Puls knallt in die Höhe, du hast aber deine Linie Ach kacke jetzt muss ich aber was ist wenn der Chef gleich reinkommt mich hier rumschreit meine Empfehlung und das wird man nach dem 2.3. Mal auch machen geht erstmal Kaffee holen.

Lass die, lass die Webseite offline, geht erstmal n Kaffee holen, weil das dauert jetzt erst n bisschen länger.

Kurzum ist abgestürzt, schaut euch die Fehlermeldung angeht n Kaffee holen und denkt kurz drüber nach was kann es sein und danach setzt man sich mal dahin und versucht das Problem zu analysieren, versucht im allerersten Moment die ganze Sache wieder online zu bringen, es ist völlig egal wer es war, es ist völlig egal was es war und es ist völlig egal was notwendig dafür ist um diese Applikation wieder online zu

bringen. Wir nennen das immer gaffertape ne, wir kleben einfach alles voll gaffertape zu oder Streichhölzer. Das ist gerade erst mal wieder online, das ist die eine Baustelle, was viele Leute, die sowas noch nie gemacht haben, die Tendenz ist aber zu sagen, OK wer war das und oh was kann ich helfen ja die alle Panik und jeder möchte helfen und dann kommt Sales noch um die Ecke ja und der Kunde ruft an und und ja und du bist eigentlich nur also

du willst das Problem beheben und jeder fragt kontinuierlich nach einem Status also ich hab gar keine Zeit das Problem zu beheben, weil jeder immer wissen möchte was los ist. Best Practice ist, lass die Leute arbeiten, ja und dann, wenn jetzt zum Beispiel ich als Engineering Manager, wenn ich wirklich nicht helfen kann, das Einzige was ich helfen kann in solchen Fällen ist, ich frag das Team, wollt ihr was trinken oder

wollt ihr einen? Pizza, du kannst dir einen Kaffee holen oder ein bisschen mehr Zeit. Ich frag den was braucht ihr zum Arbeiten so und meine Aufgabe ist dann die ganzen Leute wegzuhalten, ja den Vertrieb wegzuhalten, den CEO und den wer auch immer da immer kommt, das bedeutet wir bringen die Applikation wieder online

später. Später können wir uns das Problem ansehen, aber immer blameless ja, was bedeutet, es wird nicht gefragt, war das der Gerrit, war das wieder der Gerrit weil der hat das jetzt zweimal innerhalb von 2 Monaten gemacht, ich weiß nicht ob ich den weitertragen kann, ja das schürt nur Angst. Der Punkt ist wo gehobelt wird fallen auch Späne, Menschen machen Fehler, Softwareentwicklung hat Bugs, es gibt keine Bugfreie Software

Engineering Excellence im Death Ops on Side Reliability Spectrum da geht es nur darum. Wie reagiert man darauf und wie schnell ist man wieder zurück? Nennt sich MTRR Medium Time to Recover. Da geht es darum, wie schnell kannst du dich von einem Ausfall erholen, wie schnell ist das

wieder online. Bei solchen Unternehmen wie Cloud Flair jetzt, aber ich weiß nicht, ob du das Antworten darfst aus dem Nähkästchen, ja, aber was man eigentlich mal machen müsste und ich fass mir da nicht selber an die Nase und ich werd es aber demnächst mal ausprobieren.

Ja ist ja ne Übung. Katastrophenübung ja, also das Ding ist ja, wenn was ausfällt und es ist noch nie vorher ausgefallen, dann ist natürlich die Schweißperle auf der Stirn viel größer, als wenn ich das schon mal durchgemacht hab.

Man kann ja sowas üben, ja, Katastrophenschutz und so weiter das also das gibt es ja nicht nur in der Software, sondern man kann ja auch mal üben, man tut da so als wäre irgendwo Wasser übergelaufen und dann guckt man mal, haben wir überhaupt, haben wir überhaupt Sandsäcke, da haben wir, kriegen wir die Leute zusammengetrommelt, ja könnten die das alles, würde das überhaupt funktionieren, ne? Und so kann man ja auch mal, und das könnte man sogar 2 Teams machen.

Ja, irgendwer schaltet mal irgendwo was ab, ja und dann und zwar vielleicht sogar im Live System ja oder auf so einem A System Teil des Live Systems oder Irgendsowas aber so ne richtig ne richtig echte Übung ja oder man sagt das ist zum Beispiel auch Klassiker ja ich mach ja Backups von meinen Servern ja also ist egal was man da jetzt hat, AWS oder Google Cloud oder einfach nur bei hetzener irgendwas aber irgendwie gibt es ja immer irgendwie Snapshots und Backups

so ja das ist ja financy die Hub. Aber hab ich mal geübt auf einmal wieder was zurückzuspielen. Ja, das kann ich ja mal machen. Ja ich ich tu so als wär alles kaputt und spiele alles von den Snapshots, sondern in meinen Backups wieder ein ja um mal zu sehen was passiert eigentlich ja macht ihr solche Übungen? Die kurze Antwort ist ja cool und diese Übungen werden auf verschiedenen Lehren gemacht, nicht nur auf Applikationsebene, sondern auf Netzwerkebene, teilweise auf Gebäudeebene und

die ganze Sache kann man. Als Chaos Engineering bezeichnen. Aber eigentlich ist es, ich sag mal, Best practice, um sich vorzubereiten, denn du hast jetzt einen Ausfall, hast festgestellt, oh, irgendwie kann ich nicht gut mit Netzwerkabbrüchen umgehen, dann behebst du diesen Fehler wundervoll, ist wieder online, wenn du das jetzt nie wieder testest, dann kann es sein, dass ein anderer Code Change von garrit garrit, du warst es wieder. In diesem Beispiel, tut mir leid. Das kann gut sein.

So eine sogenannte Regression reinbringt. Ihr habt einen Change, aber ihr habt den Netzwerk Connectivity Test nicht erneut gemacht und deswegen seid ihr wieder dafür anfällig und dann ist nicht die Frage, ob es passiert.

Die Frage ist nur, wann es wieder passiert, das bedeutet solche Tests ausfalltests sollte man kontinuierlich machen in verschiedenen Firmen mit denen ich bisher gearbeitet habe, haben wir das zu entweder zu Events gemacht die saisonal getrieben sind, zum Beispiel in der Reisebranche, bei Trivago war das ziemlich viel. Um um Weihnachten rum im Sommer und so weiter da hat man so saisonale Trends gesehen und da haben wir zum Beispiel Loadtests vorher gemacht.

Kann unsere Plattform damit umgehen, mehrere Monate bevor viele Shops machen das um Black Friday, Cyber Monday, shoppify macht das auch, die machen kontinuierlich Tests mehrere Monate vorher um zu sehen können wir mit Ausfällen umgehen, bei Cloud fair macht das natürlich auch Cloud fair betreibt das größte Netzwerk der Welt, wenn wenn die das nicht kontinuierlich nicht machen würden. Dann hätten wir dauerhaft Ausfälle.

Musst dir immer vorstellen, desto größer deine Infrastruktur, umso mehr Ausfälle hast ja, das ist einfach physikalisch so das das da kann man einfach nichts auf den Festplatten gehen kaputt Netzteile gehen kaputt, Kabel gehen kaputt ja. Das ist, das ist nicht mehr die Ausnahme, sondern die Regel. Wenn du ne gewisse Statistische Grundmenge hast, dann ist die Regel das, was ausfällt, das ist schon klar, ja, aber man wundert sich ja halt, weil ich mich frag

so so doof vielleicht weil man wundert sich ja manchmal schon, es gibt ja auch so n Kandidaten Microsoft und so weiter und das ist noch nicht so lange her. Wo an den ganzen Flughäfen auch irgendwie da der bekannte Bluescreen wieder da war, und zwar auch für n paar Minuten mehr als nur kurz und weil irgendwo was irgendwie anscheinend eingespielt wird, da fragt man sich, was testen die da?

Ja also wenn wenn also das hat ja irgendwie ganz viele Windows Updates irgendwie, es war ja quasi deterministisch, dass das irgendwie kaputt ist. Fragt man sich, wurde das überhaupt einmal vorher überhaupt von einem Mitarbeiter intern getestet, bevor das irgendwie. Auf die Welt geleast wird so und dann und dann einmal in der Zeitzone quasi alles ausfällt beim Bluescreen ne.

Meinst du das Crossstrike? Crossstrike genau das mein ich ja, das sind ja OK, das ist nichts anderes, ich hab ne ich ich bringe ne neue Version rein oder irgendsowas ja und dann Date das ab und auf einmal stirbt halt alles hin ja aber wenn ich da das Chaosmanagement im Griff hab, dann sollte es entweder kurz sterben oder vielleicht gar nicht erst um die Welt gehen, weil das hätt ich ja also ich versteh sowas dann immer nicht ja ja. Also warum das da jetzt genau

passiert ist, kann ich dir auch nicht sagen. Ich hab nicht bei Cordsec gearbeitet, aber man muss auch sehen eine Firma einer gewissen Größe hat sehr viele Leute und ihr wisst selber wie es ist. Es gibt immer Aufgaben die man müsste mal ne automatisch. Genau. Und Co. Bei ich kann jetzt nicht für Cordsec sprechen, aber was man, was man zum Beispiel immer machen kann, ist, wenn eine Applikation mehrere Cash Server

hat. Beispiel Man nimmt n Reddits als Cash Server oder Meme Cash oder ähnliches und man hat. Die als als Ring konfiguriert. Das bedeutet, dass die Applikation nutzt nicht immer nur einen Cache Server, sondern mehrere Cache Server. Dann kann man einfach mal einen dieser Cache Server ausschalten und dann schauen, wie verhält sich die Applikation. Das ist zum Beispiel ein einfacher Chaos Test. Man kann die ganze Sache aber auch in seiner Entwicklungsumgebung deutlich

testen. Es gibt ein Tool nennt sich Toxi Proxy von Shopify, das schaltet man. Zwischen seinen Applikationen, und da kann man sagen, OK jeder, jede Anfrage, die hier durchgeht, lass doch mal 50% der TZP Pakete fallen oder legt da mal ne Latenz von 3 Sekunden drauf, so kann man zu Hause ganz einfach testen, wie verhält sich eigentlich meine Applikation, wenn die andere Applikation gar

nicht erreichbar ist. Und Achtung Man lernt sehr viel über seine Applikation und dann versucht man die ganze Sache. Halt richtig zu schreiben. Und das ist gar nicht so ich. Teste meine Applikation immer gerne, wenn ich ICE fahre. Das ist auch n ist auch n. Härtetest ja, das also der ICE ist eigentlich der Proxy Proxy in in der Realität. Ja genau können wir gerne in die Show Notes packen, dieses dieses Tool ist ist n wundervolles Tool das das hat schon sehr sehr

viele tiefe Einblicke gegeben. Beantwortet, dass die Frage Burkhardt, weil wir sind ja gekommen von der Frage gibt es sozusagen trockenübungen? Ne, ja. Den, den um den um den Notfall oder den Krisenfall einmal zu zu proben. Hinzu wird Software eigentlich ordentlich überprüft, bevor sie ausgerollt wird. Das sind ja vielleicht auch noch mal 2 Sachen, eigentlich ne das.

Ist richtig was beantwortet, ist so klar, dass und ich bin da ganz, ich bin da jetzt noch mal ganz ehrlich, wir sind ja ne sehr kleine Firma und man hat ja immer sehr viel zu tun, wir haben, wir sind noch nicht so weit, dass wir alle Trockenübungen gemacht haben, die man hätte machen können, das muss man aber mal ausprobieren, ja, und es ist auch. Es es ist nicht schnell gemacht, sag ich mal. Das muss man gut planen und gut üben.

Und du kannst natürlich immer irgendwelche minimal trockenübungen machen, dir was ins Fäustchen lügen, weil auf einem Server oder irgend so was guck ich mal. Aber tatsächlich mal so ne größeren so n größeren Rings da, das ist ja auch einfach mehr Aufwand. Ja es ist es ist einfach aufwendig, es kostet Zeit, man muss die einkalkulieren ins Budget, dass man so so was macht, ja und? Macht euch, macht euch dann

bitte nicht kaputt. Ja, denn sehr, sehr viele Firmen machen das nicht sehr, sehr viele Teams. Machen das nicht vollständig und du musst natürlich auch mal gucken, wie hoch ist denn das Risiko, wenn was ausfällt.

Ja, also alles, also alles hat ja nicht das gleiche Risiko, dass die eine Baustelle, nehmen wir mal Netflix als Beispiel, Netflix hat n Tool geschrieben sich Chaos Monkey was die haben, die haben Applikationen in ihrem Cubinetis Cluster oder Ähnliches, die aktivieren die und in diesem Chaos Monkey haben die verschiedene Szenarien implementiert und die Wissen nicht. Welches Szenario eintritt und

diese Szenarien sind? Ich fahre den ganzen Kombinierungsklasse herunter, ich fahre diese Applikation herunter, ich lege Latenz auf irgendein Netzwerk, die wissen es nicht und sowas machen die regelmäßig, wenn man den blogspot liest, könnte man annehmen, dass dieses Tool kontinuierlich aktiviert ist und 24 Stunden 7 Tage die Woche durchläuft, wenn man aber mal n bisschen mehr recherchiert, dann sind da Netflix Engineers auf Hacker News und auf Reddit unterwegs, die sagen, nee, nee, nee.

Immer wenn wir so n Test machen, dann sehen wir schon zu, dass wir alle im Büro sind. Ne also die die koordinieren das auch natürlich, die sind ja auch nicht wahnsinnig. Ja wenn die mal n Bug haben und die Schießen da mehr oder weniger kontrolliert die live Umgebung ab, dann könnt ihr alle keine keine Suites oder oder Marvel Filme mehr co ne Katastrophe ja. Das ist, wie die Freiwillige Feuerwehr, die schon im Feuerwehr Overall im Auto sitzt und drauf wartet, dass es gleich irgendwo brennt.

Deswegen also macht euch da bitte nicht kaputt, wenn man das anfängt, dann wird eure man müsste mal Liste immer nur länger, ja sie wird leider nicht kürzer und dann wollt ihr das testen und dann wollt ihr das testen und dann wollt ihr das testen und im Endeffekt müsst ihr euch leider dann noch mal

zurückführen. Wir sind hier auch da um Wert mit unserer Applikation zu schaffen und dem Kunden irgendwas zu liefern, ja. Das ist so fand dein Indikator vorhin gar nicht so schlecht. Ne, also hab ich uptime die meine ja vertraglichen Verpflichtungen vor allem auch erfüllt. Kann ich auch. Vielleicht mehr Fokus auf Produkt legen und und neue Dinge

hab ich das nicht? Ja hab ich ne Baustelle warum die ich mich vielleicht ärgern muss ne ja dann lass es so langsam aber sicher Richtung Richtung Ende kommen was was gibt es noch Andy was du uns über SEE sagen willst und musst was wir und auch die Hörer und Hörerinnen auf jeden Fall noch mitnehmen sollten. Ich glaube, es gibt noch sehr, sehr viel, was wir, was wir noch nicht erwähnt haben, und wir könnten da ewig drüber sprechen im Endeffekt.

Würde ich die Leute bitten, sich mal ein bisschen zu davon zu distanzieren, dass das immer so ein Job ist und dass das ganz spezielle Leute sind? Meines Erachtens nach sind Side Reliability Engineers einfach nur Software Engineere, die sich mit dem, Ich nenne es mal nischenthema, Hochverfügbarkeit, Resilienz und Skalierbarkeit auseinandersetzen. Und wenn man da mal ein bisschen eintaucht, dann kommt man mit sehr viel Infrastruktur in Berührung, aber dass man die aus

der Software Seite mal. Untersucht. Ja, natürlich ist das Wort cobenitis. Ich glaube in diesem Podcast noch gar nicht gefallen und viele Leute sagen, oh, ich muss mit Cobenitis arbeiten, wenn wenn ich im def ops Bereich bin, wenn ich im SAE Bereich bin, ehrlicherweise in meinen letzten 6 Jahren hab ich eigentlich fast gar nicht mit Cobenitis gearbeitet. Und das liegt nicht daran, dass Kubinitis dann nicht nicht im

Einsatz ist. Das liegt daran, dass eine Technologie nichts mit der Philosophie, wie man arbeitet und und mit dem Spezialgebiet zu tun hat. Kubinitis ist ein Platzhirsch in der Containerorchestrierung und der Container skateuling alles gut, erleichtert auch vielen Leuten, aber als Death Ops Engineer, was ein Jobtitel ist. Und Achtung, Es gibt die nichts als Jobtitel, es ist eine Kultur wie ich hoffentlich rübergebracht habe. Ist es nicht wichtig, ob du Covenites machst oder Docker

oder Jinkins oder so? In den meisten Firmen in die ich arbeite, die machen alles ganz klassisch auf bare Metal mit System d. Ja alles RAW und so weiter also du musst da nicht mit Covenites das ist die eine Baustelle, die zweite Baustelle ist wenn Du jetzt Softwareentwickler oder Softwareentwicklerin bist, ICE sind es eigentlich auch, nur die beschäftigen sich nur mit einer anderen Thematik, die beschäftigen sich nicht mit der Business Logik von deinem

Steuerprogramm, sondern mit der Hochverfügbarkeit.

Und alles, was zukommt, also ein se in Firma A ist nicht gleich ein se in Firma B und ein se in Firma C ist auch noch was anderes und es gibt oft den Mythos, dass sogenannte Betriebstems sich einfach nur in DEF op Teams oder se Teams umbenennen und dann nichts ändern, wenn man immer noch so agiert wie der ganz klassische Betrieb, dann hilft auch ein neuer Name nicht, dann ist es irgendwie alter Wein in neuen Schläuchen. Aber und auch nur, weil

Betriebsteams ein bisschen Python programmieren. Das ist jetzt auch kein SRE und das ist jetzt auch kein Dev Ops, das ist Arbeitserleichterung, die man sich mit Chat GP Thema eben kurz zusammen gescriptet hat. Es muss ein Mindset Shift stattfinden, man muss ganz anders daran denken, im Endeffekt mag ich die brutale Realität, ihr wurdet alle eingestellt um einen Traum von jemandem anders, nämlich der Geschäftsführung

mitzuentwickeln. Und das Ziel ist, solange ihr nicht in einem Profit Unternehmen arbeitet, mehr Geld, mehr Profit für die Firma zu generieren.

Das ist euer Ziel und davon hängt auch euer Gehalt ab und eure Firma ist erfolgreich, wenn ihr zusammen Betrieb und Softwareentwicklung mehr schafft und dann könnt ihr ja vielleicht auch noch eine Gehaltserhöhung fragen, aber wenn ihr euch bekriegt, oh du warst das wieder und so weiter machen wir uns mal nichts vor, dann ist ja die Geschäftsführung auch nicht happy. Ja und dann tut in der Firma eigentlich auch nichts Gutes und ihr seid eingestellt.

Um der Firma was Gutes zu tun. Ja, deswegen denke ich, da müssen wir uns mal alle mit dem Riemen reißen.

Wir sind alle Menschen, wir wollen alle einen ruhigen Feierabend haben und umso mehr wir zusammenarbeiten und das ist nämlich diese ganze Def ops ist ja e Thematik, desto ruhiger ist unser Feierabend. Wer aber mehr über diese Themen wissen möchte, dem kann ich 2 wunderschöne Bücher ans Herz legen, das ist einmal The Phoenix Project und einmal der Nachfolger The Unicorn Project, da wird es ich sag mal ein einer

Novelle sehr schön. Dargestellt, was eigentlich Def Ops ist, was eigentlich die Zusammenarbeit zwischen dem Betrieb und der Softwareentwicklung so ist.

Und wer mehr über Sa wirklich wissen möchte, der geht eigentlich auf Book dot Sa verlinken wir auch in den Show Nutzer mit, da sind die 3 Bücher von Google, die könnt ihr auch online lesen, könnt ihr euch auch irgendwo bestellen und kaufen, sind relativ dicke Schinken, kann man sehr tief einsteigen, was sa eigentlich heißt wie Google es macht oder

beziehungsweise gemacht hat. Ich hab mal den Autor davon getroffen, von einem der Bücher kurz nach der Veröffentlichung auf einer Konferenz, und da sagte er mir vom ersten Buch, das war dann einen Monat draußen, sagte er mir ja, 50% davon ist schon wieder out of Date, ne, so nach dem Motto, Das zeigt halt ungefähr die Entwicklungsgeschwindigkeit bei Google damals aber verlinken wir als in den schon nutzen, der da einsteigen möchte. Und einen hab ich noch, find ich

nämlich spannend. Empfehle ich gerade mal der Andi hat nämlich seine eigene Website, der grätscht mich weg,

wenn ich das nicht sagen soll. Aber die ist ziemlich cool, muss ich sagen, ist nämlich sehr aktiv, auch im im Lesen und Sammeln von Artikeln von anderen Leuten und die all Time Highlight Artikel. Ich hab sie ein wenig überflogen, aber das ist auf jeden Fall von mir zurechtgelegt als Literatur fürs Wochenende sind richtig coole Dinger dabei, ich glaub es gibt ja manchmal so Artikel wo man echt so genau ja, dass das mal endlich jemand Hintergrund da geschrieben hat,

genau so ist es ja, da sind echt solche Dinger kann ich euch empfehlen. Also da sind bestimmt noch mehr Seiten drin, das hab ich jetzt aber nicht geschafft in der Vorbereitung, aber die Titel von den. All time highlight Artikels, die werd ich mir jedenfalls zur Gemüte ziehen, die kann ich auch noch mal verlinken in Shownotes. Ja, das ist cool. Ich glaub die relevantesten Artikel in meinem All Time High sind Choose bohring Technology.

Ja, da geht es darum, warum es eigentlich sehr gut ist, ultra langweilige Technologie zu nutzen und nicht immer die neueste Datenbank die auf Hacker, News oder Reddit trendet. Das ist die eine Thematik. Ein anderer Artikel nennt sich clever Stop being so. Da zeigt jemand mal auf, wie komplex eigentlich vor und Nachnamen sind in Bezug auf das sind ja nur 2 Felder. Nee, dieser Mensch zeigt dir mal wie komplex es eigentlich sein kann ein Formularfeld für vor und Nachnamen zu bauen.

Wie heißt deine Website? Die ist unter verfügbar unter Andy. Grumwald.com verlinken wir auch in den Shownotes glaub ich, also überall im Netz bin ich unter Andy Grumwald zu finden und wer mehr von mir auch hören möchte und auch mehr über diese Themen, wie zum Beispiel wie wir heute gesprochen haben, ich mach auch n eigenen Podcast Engineering Kiosk Garrett hatte es schon im Intro erwähnt, verlinken wir auch, hoffentlich in den in den Shownotes, da finden wir auch

ungefähr 180 190 200 folgen. Zu Citrilability Engineering aber nicht nur DEV OPS und Co, sondern da gucken wir auch n bisschen weiter, wie zum Beispiel Spieleentwicklung und Ach, die Optimierung von Algorithmen und Komplexität, aber auch Leadership oder woher eigentlich die sogenannte SQL Query kommt. Ja und warum diese 50 Jahre alt wurde zum Beispiel. Ich mag das, wie du dich schon mit unserem Podcast einfach komplex identifizierst und sagst du, wir packen alles für dich schon aus.

Das find ich sehr gut. Ich weiß ja, wie man Podcasts hört und da, da ist man mal im Auto und da geht es immer darum, ah schon mal, welcher Podcast war das? Und da wollt ich dann noch was nachgucken, oder nee.

Das machen wir auf jeden Fall. Dann würd ich sagen, haben wir ne Runde Folge geschafft, fast n neuen Zeitrekord ja weiß ich nicht genau und Andy ich ich sag ganz herzlichen Dank, ich find das richtig cool, ich hatte einige ja Augen öffnende Momente auf jeden Fall von deinen Erläuterungen und ja, auch von den Beispielen die du gegeben hast fand ich es richtig gut. Office Book hat beigetragen hat und von daher vielen Dank. Und ja, ich hoffe wir hören und sehen uns ja und dann irgendwann

auch bald wieder. Danke dir. Vielen Dank für die Einladung. War mir ne Freude. Vielen Dank von mir auch, war richtig cool. Und ja, das obligatorische Tschüss aus Hamburg. Tschüss aus Duisburg. Einfach komplex wird präsentiert und produziert von Heiseware. Wir freuen uns auf deine Fragen und [email protected] vielen Dank fürs Hören dieser Folge bis Dienstag in 2 Wochen und Tschüss aus Hamburg.