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 deinfeedbackanpodcast@heiseware.com
vielen Dank fürs Hören dieser Folge bis Dienstag in 2 Wochen
und Tschüss aus Hamburg.