1
00:00:00,480 --> 00:00:03,640
Moin, hier ist einfach komplex 
mit euren Hosts Burkhard und 

2
00:00:03,640 --> 00:00:07,360
Gerrit und heute wieder mit 
einem Gast zum Thema 

3
00:00:07,360 --> 00:00:10,000
Observability der Heinrich 
Hartmann von Zalando. 

4
00:00:10,000 --> 00:00:12,360
Hallo Heinrich. 
Hallo Gerrit, vielen Dank für 

5
00:00:12,360 --> 00:00:13,960
die Einladung. 
Ich freue mich, hier bei euch zu

6
00:00:13,960 --> 00:00:16,280
sein heute. 
Ja, schön, dass du da bist und 

7
00:00:16,280 --> 00:00:19,400
man darf es vielleicht sagen. 
Die Einladung ist entstanden 

8
00:00:19,400 --> 00:00:23,160
durch einen gemeinsamen Kollegen
und Freund, den Cornelio, also 

9
00:00:23,160 --> 00:00:24,400
an dieser Stelle Grüße an 
Cornelio. 

10
00:00:24,880 --> 00:00:28,760
Grüß dich, cor von mir. 
Dann lass uns starten. 

11
00:00:28,760 --> 00:00:30,920
Also Observability soll das 
Thema sein, aber Heinrich, 

12
00:00:30,920 --> 00:00:33,480
erstmal magst Du dich kurz 
vorstellen, damit die Leute 

13
00:00:33,480 --> 00:00:35,600
wissen, mit wem sie es hier 
eigentlich zu tun haben heute. 

14
00:00:36,000 --> 00:00:37,120
Ja, sehr gerne. 
Ja. 

15
00:00:37,120 --> 00:00:40,040
Mein Name ist Heinrich, Ich bin 
Senior Principal Engineer bei 

16
00:00:40,040 --> 00:00:43,240
Zalando in der Infrastruktur, 
also, betreue quasi die die 

17
00:00:43,240 --> 00:00:46,640
gesamte Plattform für uns n 
bisschen mit und ja, ich bin 

18
00:00:46,640 --> 00:00:49,480
seit ungefähr 10 Jahren im 
Reliability Engineering und auf 

19
00:00:49,480 --> 00:00:52,080
diesem observability Thema 
unterwegs, also meine 

20
00:00:52,560 --> 00:00:55,200
weitreichende Vergangenheit ist 
aus der Mathematik, ich bin 

21
00:00:55,200 --> 00:00:57,680
gebürtiger Mainzer, hab dann 
auch in in Bonn studiert. 

22
00:00:57,920 --> 00:01:01,240
Und ne Promotion abgeschlossen 
und dann ja wie es vielen Leuten

23
00:01:01,240 --> 00:01:03,440
dann auch in der Akademie ja so 
geht, irgendwann in die Software

24
00:01:03,440 --> 00:01:06,200
abgebogen und ich bin bisschen 
bei diesen Grundlagenproblemen 

25
00:01:06,200 --> 00:01:08,640
hängen geblieben. 
Also ich hatte dann auch meinen 

26
00:01:08,640 --> 00:01:12,080
wordpress Blog und so meine 
ersten Python Web Apps, die ich 

27
00:01:12,080 --> 00:01:15,640
dann selber gestartet hab und 
dann so meine Güte das am Laufen

28
00:01:15,640 --> 00:01:18,400
zu halten, dass My Sequel nicht 
immer abstürzt und sich dann von

29
00:01:18,400 --> 00:01:19,840
meinen Usern irgendwie erzählt 
bekomme. 

30
00:01:19,840 --> 00:01:22,360
Ich kann mich hier für n Event 
nicht registrieren, das hatte 

31
00:01:22,360 --> 00:01:26,000
mich so n bisschen zu oft dann 
irgendwie geärgert. 

32
00:01:26,320 --> 00:01:28,480
Dass ich gedacht hab, so, das 
muss man mal richtig verstehen. 

33
00:01:28,800 --> 00:01:31,760
Und Na ja, sind wir 10 Jahre 
später, ich weiß nicht, ob ich 

34
00:01:31,760 --> 00:01:36,080
es richtig verstanden hab, aber 
auf jeden Fall hab ich das Thema

35
00:01:36,080 --> 00:01:39,800
jetzt aus aus verschiedensten 
Ecken gesehen und auch relativ 

36
00:01:39,800 --> 00:01:42,840
viel da drüber erzählt oder mich
damit beschäftigt. 

37
00:01:42,840 --> 00:01:46,760
Also ich war 5 Jahre dann Chief 
Data Scientist bei einer 

38
00:01:46,760 --> 00:01:49,200
Monitoring bendor hab da so n 
bisschen Anomalie Detection auf 

39
00:01:49,200 --> 00:01:52,080
Zeitserien gemacht. 
Und dann bei Zalando hab ich 

40
00:01:52,080 --> 00:01:55,800
zwischenzeitlich das Reliability
Engineering geleitet als Head of

41
00:01:55,800 --> 00:01:59,120
Engineering und genau guck halt 
jetzt wieder in einer 

42
00:01:59,600 --> 00:02:03,200
Engineeringrolle als ja so 
Architekt Slash, Principal 

43
00:02:03,200 --> 00:02:05,920
Engineer bei Zalando, über diese
Reliability Fragen. 

44
00:02:06,720 --> 00:02:09,360
Super. 
Vielen dank Heinrich klingt 

45
00:02:09,360 --> 00:02:12,000
super spannend und ich bin echt 
gespannt gleich zu hören wie es 

46
00:02:12,000 --> 00:02:15,120
so läuft bei euch bei Zalando. 
Jetzt hast du gerade schon 

47
00:02:15,360 --> 00:02:18,080
gesagt, du warst mal tätig in 
einer Firma die Monitoring 

48
00:02:18,080 --> 00:02:20,720
gemacht hat und. 
N bisschen in meiner 

49
00:02:20,720 --> 00:02:24,000
Vorbereitung hab ich gesehen 
Monitoring oder oder anders 

50
00:02:24,000 --> 00:02:27,600
gesagt Observability ist 
irgendwo Monitoring, aber mehr 

51
00:02:28,000 --> 00:02:31,040
magst du vielleicht in dem in 
dem Kontext auch mal uns 

52
00:02:31,200 --> 00:02:35,120
observability erstmal zum Start 
erklären und definieren. 

53
00:02:35,360 --> 00:02:38,840
Ja, ist n sehr guter Einstieg, 
weil bei Observability wieso bei

54
00:02:38,840 --> 00:02:43,360
so vielen Sachen in der IT gibt 
es total viele überschneidende 

55
00:02:43,440 --> 00:02:45,840
Definitionen, je nachdem mit wem
du sprichst. 

56
00:02:46,240 --> 00:02:48,240
Und ich würde die Begriffe 
eigentlich sehr gerne sehr weit 

57
00:02:48,240 --> 00:02:50,480
fassen. 
Also so wie programmieren. 

58
00:02:50,480 --> 00:02:53,840
Im Prinzip ist Tell the Computer
what to do sagt dem Computer was

59
00:02:53,840 --> 00:02:57,200
ich, was er tun soll ist für 
mich obsibility genau das 

60
00:02:57,200 --> 00:02:59,760
Gegenteil davon. 
Also ich möchte verstehen, was 

61
00:02:59,760 --> 00:03:03,200
der Computer gerade tut und das 
ist tatsächlich ein erstaunlich 

62
00:03:03,200 --> 00:03:05,680
schweres Problem. 
Beim Auto kannst du einfach die 

63
00:03:05,680 --> 00:03:08,920
Motorhalber öffnen und siehst 
okay hier kriegst Geräusche die 

64
00:03:08,920 --> 00:03:11,240
dir entgegenkommen, du siehst 
irgendwie, da funktioniert 

65
00:03:11,240 --> 00:03:13,120
irgendwas nicht, da sollte was 
vibrieren oder so. 

66
00:03:13,760 --> 00:03:15,680
Unsere Rechner sind jetzt 
meistens in der Cloud, das 

67
00:03:15,680 --> 00:03:17,640
heißt, ich hör noch nicht mal 
die Festplatte irgendwie 

68
00:03:17,640 --> 00:03:20,320
rauschen, wenn Sie irgendwie 
Daten liest. 

69
00:03:20,320 --> 00:03:23,040
Also die Informationen, die man 
von von den Rechnern gesendet 

70
00:03:23,040 --> 00:03:27,360
bekommt, sind eigentlich per se 
erstmal sag mal sehr sehr wenige

71
00:03:27,600 --> 00:03:29,760
und auch wenn man so aus einer 
Anwendersicht kommt, ich hab ja 

72
00:03:29,760 --> 00:03:32,640
früher auch auf Windows System 
viel Zeit verbracht, da war 

73
00:03:32,640 --> 00:03:36,640
immer so ne sehr große Barriere 
von OK ich hab das UI aber guck 

74
00:03:36,640 --> 00:03:40,120
da mal hinter was wie was macht 
der eigentlich, warum hängt das 

75
00:03:40,120 --> 00:03:42,920
Programm? 
Oder wie ist jetzt n Fehler ja 

76
00:03:42,920 --> 00:03:45,360
entstanden oder wo kommt der her
oder was muss ich jetzt tun, 

77
00:03:45,360 --> 00:03:47,600
damit das aufhört? 
Und für mich ist so 

78
00:03:48,000 --> 00:03:50,880
Observability im Prinzip genau 
dieser Quest. 

79
00:03:50,880 --> 00:03:54,120
Du hast n Programm oder n 
System, das tut irgendwas jetzt 

80
00:03:54,120 --> 00:03:58,160
das mal n Nutzer oder wenn jetzt
hier so n so n Operator oder 

81
00:03:58,640 --> 00:04:01,080
Incident Responder im Zweifel 
interessiert einen das am 

82
00:04:01,080 --> 00:04:03,360
meisten wenn irgendwas nicht 
klappt verstehen. 

83
00:04:03,520 --> 00:04:06,640
Was was macht das? 
Und das fängt bei ganz einfachen

84
00:04:06,640 --> 00:04:10,120
Sachen an, die Debugging, also 
Logging wo ich so debuglogs in 

85
00:04:10,120 --> 00:04:13,120
meinem Code injiziere um zu 
verstehen, hey wann wird eine 

86
00:04:13,120 --> 00:04:14,640
gewisse Zeile irgendwie 
ausgeführt. 

87
00:04:14,960 --> 00:04:17,959
Das geht in in Debugging rein, 
wo man an den Postes quasi 

88
00:04:17,959 --> 00:04:20,839
attached und guckt hier 
speicherstellen Ausliest und 

89
00:04:20,839 --> 00:04:24,120
variablen Ausliest und probiert 
das rauszufinden und das geht 

90
00:04:24,120 --> 00:04:27,600
halt in diese so mal klassische 
so mal Enterprise Obsibility 

91
00:04:27,600 --> 00:04:30,320
rein, wo wir dann auch große 
Logging Systeme haben. 

92
00:04:30,320 --> 00:04:32,200
Das ist im Prinzip ja genau 
wieder dasselbe, die 

93
00:04:32,200 --> 00:04:35,760
Applikationen die die Spucken 
auch Log Dateien oder Loglines 

94
00:04:35,760 --> 00:04:40,720
aus, die werden zusammengefasst,
aber eben auch andere Telemetrie

95
00:04:40,720 --> 00:04:42,560
Typen und da ist vor allen 
Dingen. 

96
00:04:43,120 --> 00:04:45,600
Die Metriken relevant das sind 
Zeitserien, die aufgenommen 

97
00:04:45,600 --> 00:04:48,480
werden und eventdaten oder 
Tracingdaten. 

98
00:04:48,720 --> 00:04:53,040
Und da geht es einfach um um 
Events oder Interaktionen 

99
00:04:53,040 --> 00:04:57,200
zwischen verteilten Systemen, 
die zu speichern und so 

100
00:04:57,200 --> 00:04:59,680
zugänglich zu machen, dass man 
auch verteilte Systeme 

101
00:04:59,680 --> 00:05:02,280
analysieren kann. 
Und ja, je nachdem, welches 

102
00:05:02,280 --> 00:05:04,880
konkrete Problem man hat, da 
sind die Tools für Observability

103
00:05:04,880 --> 00:05:08,000
natürlich sehr unterschiedlich. 
Also bei einem Hobbyprojekt, was

104
00:05:08,000 --> 00:05:10,720
ich an der Seite mache in meinem
Blog nutze ich auch einfach 

105
00:05:10,720 --> 00:05:13,760
Standard Outlogging der Prozess 
spuckt einfach Sachen aus, das 

106
00:05:13,760 --> 00:05:17,000
klappt. 
Aber aber was ganz kurz, was ich

107
00:05:17,000 --> 00:05:20,360
aber trotzdem manuell dafür also
im Code dafür sorgen muss oder 

108
00:05:20,360 --> 00:05:22,320
irgendwo in meiner Anwendung, 
dass das passiert, dass diese 

109
00:05:22,320 --> 00:05:23,920
Logs ausgespuckt werden, das ist
ja kein, ist ja nicht 

110
00:05:23,920 --> 00:05:26,480
gottgegeben, oder dass dass Code
solche Logs ausspuckt. 

111
00:05:26,960 --> 00:05:29,080
Ja, das stimmt. 
Also in aller Regel ist das OK 

112
00:05:29,080 --> 00:05:31,280
Print. 
Statement da gibt es noch n paar

113
00:05:31,280 --> 00:05:34,040
Tricks, die man anwenden kann um
das zu externalisieren wenn man 

114
00:05:34,040 --> 00:05:37,840
möchte, aber im wesentlichen ist
es das und ja, an anderer Stelle

115
00:05:37,840 --> 00:05:39,880
hat man vielleicht 
ressourcenproblem, wo man oft 

116
00:05:39,880 --> 00:05:42,680
irgendwie in Sachen reinläuft. 
Hey Speicherplatz läuft läuft 

117
00:05:42,680 --> 00:05:46,000
zu, ich hab irgendwie memory 
Probleme, da sind Metriken 

118
00:05:46,000 --> 00:05:48,560
klassischerweise einfach sehr 
gut um zu verstehen wie sind 

119
00:05:48,560 --> 00:05:53,360
Ressourcenauslastungen da und 
dann letztlich diese diese Event

120
00:05:53,360 --> 00:05:56,480
und Tracing Daten, die sind dann
wichtig wenn man verteilte 

121
00:05:56,480 --> 00:05:58,840
Systeme hat, also nicht 34 
Anwendungen hat die mit 

122
00:05:58,840 --> 00:06:03,200
Miteinander sprechen und. 
Dann ist die Frage, wo genau 

123
00:06:03,200 --> 00:06:05,680
liegt denn der Fehler? 
Sehr schwer zu diagnostizieren, 

124
00:06:05,920 --> 00:06:09,040
wenn man einzeln auf die 
Anwendungen guckt und da helfen 

125
00:06:09,040 --> 00:06:12,880
diese Destibierte Tracing Tools.
OK, ich hak noch mal nach 

126
00:06:13,120 --> 00:06:14,920
Metriken, das kann ich mir so 
vorstellen. 

127
00:06:14,920 --> 00:06:17,200
Da meinst du wahrscheinlich so 
Operating System Monitoring, 

128
00:06:17,200 --> 00:06:20,560
also so wieviel CPU Last hab ich
gerade im Moment, wieviel 

129
00:06:20,640 --> 00:06:23,120
Displays hab ich noch frei? 
Und so weiter. 

130
00:06:23,120 --> 00:06:25,520
Also die ne die Last vom Rechner
zum Beispiel sowas. 

131
00:06:25,520 --> 00:06:27,280
Also es hat ja jetzt nicht 
direkt was mit der Anwendung zu 

132
00:06:27,280 --> 00:06:29,280
tun, sondern mit dem 
Environment, in der die 

133
00:06:29,280 --> 00:06:30,680
Anwendung gerade eingebettet 
ist. 

134
00:06:30,680 --> 00:06:33,440
Wie geht es dem ne und das hat 
ja auch was damit zu tun, wie 

135
00:06:33,440 --> 00:06:36,000
hält sie meine, wie weit hält 
sie meine Anwendung ist Kurs, 

136
00:06:36,000 --> 00:06:38,280
was meinst du oder? 
Genau richtig also, wenn du 

137
00:06:38,280 --> 00:06:41,360
Hardtop aufmachst oder nen 
Systemtool, dann siehst du 

138
00:06:41,360 --> 00:06:43,120
einfach Metriken, die 
aufgezeichnet werden. 

139
00:06:43,600 --> 00:06:46,480
In der Kommandozeile sind die 
oft sehr recent mit einer hohen 

140
00:06:46,480 --> 00:06:48,720
Sampling Frequenz. 
Jede Sekunde wird n neuer 

141
00:06:48,720 --> 00:06:51,280
Datenpunkt aufgezeichnet, ne 
Metrik in einem Enterprise 

142
00:06:51,280 --> 00:06:54,160
Kontext wird halt über längere 
Zeithorizonte aufgezeichnet, 

143
00:06:54,160 --> 00:06:57,240
dann in der Regel NN kleineres 
Sampling Intervall hoff ich jede

144
00:06:57,240 --> 00:07:00,800
Minute und Infrastrukturmetriken
die wir gerade besprochen haben,

145
00:07:00,800 --> 00:07:04,200
also einfach wie sind die CPUS 
ausgelastet, wieviel Speicher 

146
00:07:04,200 --> 00:07:08,480
hab ich frei sind so der. 
Red and Butter, so dieser Chor, 

147
00:07:08,480 --> 00:07:10,600
wo Metriken wirklich richtig gut
sind und wo die auch 

148
00:07:10,600 --> 00:07:12,800
normalerweise anfangen. 
Es gibt natürlich auch 

149
00:07:12,800 --> 00:07:16,240
Application Matrix und da 
Klassiker ist zum Beispiel Cash 

150
00:07:16,240 --> 00:07:18,480
Sites oder irgendwelche Q 
Längen. 

151
00:07:19,120 --> 00:07:22,400
Es gibt viele Entwickler die 
dann auch sehr viel 

152
00:07:22,400 --> 00:07:25,480
feingranularere Metriken, 
rausschreiben teilweise 

153
00:07:25,480 --> 00:07:28,960
irgendwelche Counts von Events 
oder teilweise dann auch für 

154
00:07:28,960 --> 00:07:31,200
jeden Nutzer noch mal. 
Wie oft hat er denn diesen 

155
00:07:31,200 --> 00:07:33,160
Button geklickt? 
Das kann man natürlich als 

156
00:07:33,160 --> 00:07:35,760
Zeitserie modellieren, wo man 
dann quasi für jeden Nutzer 

157
00:07:35,760 --> 00:07:38,160
zählt. 
Na ja, wie oft wurde dann ne 

158
00:07:38,720 --> 00:07:42,640
gewisse Anfrage gemacht, aber 
dann kommt man genau in so nen 

159
00:07:42,640 --> 00:07:46,240
an so nen Punkt wo das kein kein
gutes Datenformat mehr ist um 

160
00:07:46,240 --> 00:07:48,640
diese um diese Daten 
aufzunehmen. 

161
00:07:48,640 --> 00:07:52,160
Also Genetiken sollte man 
klassischerweise eher an Sachen 

162
00:07:52,160 --> 00:07:54,880
knüpfen die so statischen 
Ressourcencharakter haben. 

163
00:07:55,200 --> 00:07:57,320
Also lass uns das noch mal 
aufdröseln und und normal in ne 

164
00:07:57,320 --> 00:07:59,480
Box packen. 
Wir haben Observability 

165
00:07:59,480 --> 00:08:03,920
besprochen und du sagst besteht 
aus ist sehr weiter Begriff hab 

166
00:08:03,920 --> 00:08:05,640
ich verstanden. 
Besteht aus mehreren 

167
00:08:05,640 --> 00:08:07,760
Komponenten. 
Ich würd es mal von abstrakt 

168
00:08:07,760 --> 00:08:10,080
nach feiner versuchen durch zu 
deklinieren. 

169
00:08:10,080 --> 00:08:12,760
Du Schüttelst sofort den Kopf, 
wenn ich Quatsch erzähle, ich 

170
00:08:12,760 --> 00:08:15,560
hab verstanden, es gibt quasi 
die niedrigen, also es geht 

171
00:08:15,560 --> 00:08:19,720
erstmal um Software Punkt 
Software läuft auf Hardware, die

172
00:08:19,720 --> 00:08:24,120
Hardware selber kann man 
observen Monitoren ob ihres 

173
00:08:24,120 --> 00:08:27,920
Gesundheitszustandes also zum 
Beispiel CPU Last Auslastung, 

174
00:08:27,920 --> 00:08:31,280
RAM Netzwerk Traffic der gerade 
ein und abgeht. 

175
00:08:31,640 --> 00:08:34,159
Das sind die, würde ich sagen, 
die außen die Hardware Metriken.

176
00:08:34,159 --> 00:08:37,640
Dann hast du gesagt in der 
Applikation selber kann ich noch

177
00:08:37,640 --> 00:08:40,559
mal spezielle Metriken haben, 
also ich während ich den 

178
00:08:40,559 --> 00:08:43,760
gesamten Rahmen eines Systems 
mir angucken kann, habe ich in 

179
00:08:43,760 --> 00:08:46,800
der Anwendung läuft ne Software 
Anwendung auch n bestimmten 

180
00:08:46,800 --> 00:08:50,200
Arbeitsspeicher den die für sich
allokiert, so ist es 

181
00:08:50,200 --> 00:08:51,760
typischerweise. 
Wer das jetzt noch nicht gehört 

182
00:08:52,000 --> 00:08:54,600
hat und auch und das ist quasi 
auch erstmal unabhängig von dem 

183
00:08:54,600 --> 00:08:56,960
was ich da programmiert hab und 
ob ich Python genommen hab oder 

184
00:08:56,960 --> 00:09:00,240
Java Script oder Java und ob ich
da irgendwelche logs rausfeuer 

185
00:09:00,240 --> 00:09:03,360
das ist was was ich. 
Grundsätzlich bei jeder Software

186
00:09:03,360 --> 00:09:05,320
ist unterschiedlich in der 
Technologie, aber das kann ich 

187
00:09:05,320 --> 00:09:08,880
im Prinzip rausbekommen. 
Wie ist meine, oft ist das 

188
00:09:08,880 --> 00:09:12,040
Stichwort Heepsize so, ja wie 
ist die Größe, wie ist die 

189
00:09:12,040 --> 00:09:15,040
Allokation von meiner von meiner
Anwendung, ja es kann wichtig 

190
00:09:15,040 --> 00:09:16,880
sein, denn es kann zum Beispiel 
sein, ich habe ein 

191
00:09:16,880 --> 00:09:20,960
Datenbankprozess in in meiner 
Programmiersprache und jetzt 

192
00:09:21,200 --> 00:09:23,520
Hallo, jetzt habe ich eine 
schlechte Anfrage und die 

193
00:09:23,520 --> 00:09:26,600
braucht zum Beispiel mehr als 4 
Gigabyte in ihrem eigenen 

194
00:09:26,600 --> 00:09:29,400
Speicher, dann kann es sein, 
obwohl ich irgendwie 128 

195
00:09:29,400 --> 00:09:32,240
Gigabyte auf meinem Server hab. 
Puren RAM zur Verfügung. 

196
00:09:32,480 --> 00:09:35,120
Dass das Ding abstürzt. 
Dann steht da so was drin wie 

197
00:09:35,120 --> 00:09:38,960
Heep Allocation failed, weil 
nämlich zum Beispiel Programme 

198
00:09:39,280 --> 00:09:42,080
in der Standarddefinition 
irgendwie nur 4 Gigabyte greifen

199
00:09:42,080 --> 00:09:43,560
dürfen ja, aus 
Sicherheitsgründen oder 

200
00:09:43,560 --> 00:09:46,080
Irgendsowas also das wäre das 
zweite Level um es klar zu 

201
00:09:46,080 --> 00:09:47,680
machen, also haben wir Hardware,
dann haben wir quasi 

202
00:09:47,680 --> 00:09:51,240
anwendungslevel als Metriken und
dann dazu gesagt erklärt, dass 

203
00:09:51,240 --> 00:09:54,760
wir auch aufspeichern können, 
die Custom Logs, wofür jeder 

204
00:09:54,760 --> 00:09:58,000
Entwickler dann selbstständig ja
in die Tasten greifen muss. 

205
00:09:58,480 --> 00:10:00,480
Damit da irgendwelche 
Nachrichten rauskommen, was 

206
00:10:00,480 --> 00:10:03,680
gerade im Programm passiert und 
all das, da muss man bei Zalando

207
00:10:03,680 --> 00:10:06,400
dann sehen, haben wir nicht nur 
eine Kiste und eine Anwendung 

208
00:10:06,400 --> 00:10:10,960
und ein Programm, sondern ganz 
viele Server mit ganz vielen 

209
00:10:11,040 --> 00:10:12,880
Microservices, die da drauf 
laufen, die quasi wieder 

210
00:10:12,880 --> 00:10:14,840
Prozesse sind in eigener 
Anwendung, mit ganz vielen 

211
00:10:14,840 --> 00:10:18,480
verschiedenen Codes der Laufen 
und dann bekomme ich jede Menge 

212
00:10:18,480 --> 00:10:21,440
Daten und ich glaube, jetzt 
kommt es glaube ich, wo du dann 

213
00:10:21,440 --> 00:10:23,840
auch oder vielleicht auch ein 
Mathematiker gefragt ist. 

214
00:10:24,320 --> 00:10:27,280
Ja, wie kriege ich denn aus 
dieser Datenwolke? 

215
00:10:27,840 --> 00:10:32,320
Informationen geschöpft und 
Inhalte raus, die mir die mir 

216
00:10:32,320 --> 00:10:34,560
erklären warum System gut 
funktioniert oder auch nicht 

217
00:10:34,560 --> 00:10:37,320
oder an der einen Stelle n Hick 
up hat und so weiter hab ich es 

218
00:10:37,320 --> 00:10:39,640
richtig verstanden? 
Ja genau OK. 

219
00:10:40,560 --> 00:10:43,520
Also zum zum Zalando Scale kann 
ich ein bisschen was erzählen. 

220
00:10:43,520 --> 00:10:47,160
Also wir haben ungefähr 10000 
Nodes, auf denen Applikationen 

221
00:10:47,160 --> 00:10:51,760
laufen, laufen, wir haben 2000 
plus Softwareentwickler, über 3 

222
00:10:51,760 --> 00:10:53,760
dreieinhalbtausend 
Microservices. 

223
00:10:54,400 --> 00:10:55,800
Die miteinander reden. 
Also wir haben so n 

224
00:10:55,800 --> 00:10:58,320
Architekturdiagramm, es ist 
schon schon relativ alt, wir 

225
00:10:58,400 --> 00:11:01,720
haben das mal so geplottet und 
man kann einfach sehr wenig 

226
00:11:01,720 --> 00:11:04,200
Struktur so erkennen von der 
gesamten Ding, es sieht einfach 

227
00:11:04,200 --> 00:11:08,120
aus wieso n riesiger Todesstern 
von Verknüpfungen, da gibt es so

228
00:11:08,120 --> 00:11:11,200
n paar architektonische 
Bestrebungen auch so n nennen 

229
00:11:11,200 --> 00:11:14,080
wir domaingateways diese 
dependent Citroen n bisschen 

230
00:11:14,080 --> 00:11:18,840
stärker zu strukturieren, aber. 
Man kann sich vorstellen, also n

231
00:11:18,840 --> 00:11:21,120
Problem, was Zalando auch in der
Vergangenheit wirklich gehabt 

232
00:11:21,120 --> 00:11:24,080
hat ist, wenn jeder einzelne 
Entwickler jetzt nur auf seinen 

233
00:11:24,080 --> 00:11:26,560
Applikationen guckt und wir 
haben auch wirklich dieses You 

234
00:11:26,560 --> 00:11:28,840
Build it your Unit, das heißt 
die Entwickler die ne ne 

235
00:11:28,840 --> 00:11:31,760
Applikation bauen, die sind 
nachher auch in incident 

236
00:11:31,760 --> 00:11:34,320
Situationen diejenigen die das 
die backen, aber wenn die alle 

237
00:11:34,320 --> 00:11:36,480
nur auf ihre Applikation gucken 
ist für die einfach sehr schwer 

238
00:11:36,480 --> 00:11:40,400
zu sagen, sind wir denn jetzt 
gerade schuld an einer User 

239
00:11:40,400 --> 00:11:43,040
seitigen Funktion die nicht 
funktioniert weil wir haben? 

240
00:11:43,280 --> 00:11:46,000
Im Zweifel in der Call Chain 
irgendwie 10 Services, die 

241
00:11:46,000 --> 00:11:49,280
diesen Request alle sehen, also 
vom Nutzer auf der Webseite. 

242
00:11:49,600 --> 00:11:52,560
Da sind 10 verschiedene Rechner 
im Zweifel mit verschiedenen 

243
00:11:52,560 --> 00:11:54,760
Applikationen. 
Also wenn ich irgendwas in 

244
00:11:54,760 --> 00:11:57,200
meinen Warenkorb legen würde, 
dann passieren im Hintergrund 10

245
00:11:57,200 --> 00:11:59,600
Aktionen an an 10 Microservices 
zum Beispiel. 

246
00:11:59,600 --> 00:12:03,440
Das können auch Hunderte sein, 
aber das sind mal mindestens 10 

247
00:12:03,440 --> 00:12:06,800
oder an vielen Stellen. 
Also genau. 

248
00:12:07,200 --> 00:12:09,360
Und wenn du dann dieses Spiel 
spielst, du hast erst mal alle 

249
00:12:09,360 --> 00:12:11,920
in dem Call irgendwie das der 
Checkout funktioniert gerade 

250
00:12:11,920 --> 00:12:12,960
nicht. 
Wir verdienen kein Geld. 

251
00:12:12,960 --> 00:12:16,280
Ja und du hast dann vielleicht 
30 Applikationen die dann an 

252
00:12:16,280 --> 00:12:19,200
dieser Checkout Journey hängen 
und dann versucht jeder einzelne

253
00:12:19,200 --> 00:12:22,440
Entwickler zu sagen Hey wo liegt
denn das Problem und die gucken 

254
00:12:22,440 --> 00:12:24,640
alle auf ihre Dashboards mit den
Metriken und sagen hier ist 

255
00:12:24,640 --> 00:12:27,280
grün, hier ist grün, hier ist 
grün, wir sehen in unseren Logs 

256
00:12:27,280 --> 00:12:31,200
nicht und dann sagen wir OK aber
der Nutzer das klappt nicht und 

257
00:12:31,520 --> 00:12:35,520
dann hat man sehr. 
Langwierige Fehlersuchprozesse, 

258
00:12:35,520 --> 00:12:37,800
weil einfach der das Surface so 
lang ist. 

259
00:12:37,800 --> 00:12:41,240
Du kannst jetzt nicht sagen, OK,
nehme diesen einen Java Prozess,

260
00:12:41,240 --> 00:12:43,200
das muss irgendwo da sein und 
dann guck ich halt so lange bis 

261
00:12:43,200 --> 00:12:45,800
ich es da finde, sondern du hast
so viel Kommunikationsoverhead 

262
00:12:45,800 --> 00:12:49,640
zwischen den Teams und das ist 
tatsächlich so n Punkt wo einem 

263
00:12:49,640 --> 00:12:52,160
dieses sag mal auch relativ 
klassische Metrik und 

264
00:12:52,160 --> 00:12:55,960
Loggetriebene Debugging nicht 
mehr weiterhilft, wo es einfach 

265
00:12:55,960 --> 00:12:58,600
sehr sehr schwierig wird und 
selbst wenn du nur ne Datenbank 

266
00:12:58,600 --> 00:13:01,400
und nen Webserver hast. 
Teilweise bei den Logs zu 

267
00:13:01,400 --> 00:13:04,200
verstehen, welcher Request von 
dem Webserver passt jetzt zu 

268
00:13:04,200 --> 00:13:07,040
welchem Sequiry die in der 
Datenbank waren? 

269
00:13:07,200 --> 00:13:11,360
Das ist oft ziemlich haarig und 
das ist so ein Problem, das 

270
00:13:11,360 --> 00:13:13,640
wurde innerhalb der Applikation 
schon lange gelöst. 

271
00:13:13,640 --> 00:13:16,400
Mit den Stack Traces, weil Stack
Traces sind letztlich auch du 

272
00:13:16,400 --> 00:13:19,800
hast irgendwo einen Fehler und 
du kriegst ganz genau eine so 

273
00:13:19,800 --> 00:13:22,880
eine Call Chain die dir 
angezeigt wird warum wurde? 

274
00:13:23,280 --> 00:13:25,360
Dieser Fehler geworfen? 
Na ja, weil diese Funktion 

275
00:13:25,360 --> 00:13:27,600
aufgerufen wurde, teilweise mit 
diesen Parametern. 

276
00:13:27,760 --> 00:13:29,160
Warum wurde die Funktion 
aufgerufen? 

277
00:13:29,160 --> 00:13:32,320
Na ja, weil eine andere Funktion
diese Funktion aufgerufen hat 

278
00:13:32,320 --> 00:13:34,680
und so gehst du halt bis ganz 
nach oben und dann fängt es 

279
00:13:34,680 --> 00:13:36,280
irgendwie an. 
Warum wurde ne Funktion 

280
00:13:36,280 --> 00:13:37,920
aufgerufen? 
Na ja ich hab n netzwerkpaket 

281
00:13:37,920 --> 00:13:41,040
irgendwo gekriegt oder ne 
webanfrage und dann hast du so 

282
00:13:41,040 --> 00:13:44,320
ne kausality Chain und im 
Prinzip ist die Grundidee von 

283
00:13:44,320 --> 00:13:46,400
diesem. 
Distributed Tracing oder 

284
00:13:46,400 --> 00:13:49,600
verteilten Tracing diese Stact 
Traces fortzusetzen. 

285
00:13:49,680 --> 00:13:51,360
Cross Application. 
Ah cool. 

286
00:13:51,560 --> 00:13:53,920
Ich verstehe es. 
Genau, du gehst dann quasi hin. 

287
00:13:54,320 --> 00:13:57,600
Auch nimm TCP Layer und sagst 
OK, wo kommst du denn eigentlich

288
00:13:57,600 --> 00:13:58,720
her? 
Und dann gehst du quasi in den 

289
00:13:58,720 --> 00:14:02,840
Stact Trace von der Anwendung, 
die dich gecallt hat und solange

290
00:14:02,840 --> 00:14:07,200
du wirklich mal keine, also 
asynchrone Komplikation der 

291
00:14:07,200 --> 00:14:09,680
Mitte hast in der Mitte hast, 
sondern wirklich einfach eine 

292
00:14:09,680 --> 00:14:12,680
Applikation microservice Macht, 
hat http call an den nächsten 

293
00:14:12,680 --> 00:14:16,480
Microservice was. 
So mal zumindest. 85% aller Use 

294
00:14:16,480 --> 00:14:18,000
Cases abdeckt. 
Das ist also wirklich ne sehr 

295
00:14:18,000 --> 00:14:21,400
sehr standardisierte 
Systemarchitektur, dann kann man

296
00:14:21,400 --> 00:14:24,400
mit diesem Konzept konzeptionell
sehr sehr klar nachverfolgen. 

297
00:14:24,480 --> 00:14:29,440
Der Nutzer trifft unsere Edge 
trifft den ersten Load Balancer 

298
00:14:29,440 --> 00:14:33,240
von uns, dann machen wir quasi 
den ersten sogenannten Span auf 

299
00:14:33,240 --> 00:14:36,720
und dann gucken wir OK, welche 
Funktionen werden ausgeführt und

300
00:14:36,800 --> 00:14:40,560
welche Applikation wird danach 
gecallt und jetzt kann man sich 

301
00:14:40,560 --> 00:14:42,800
leicht vorstellen, wenn wir das 
für jeden Request machen, wir 

302
00:14:42,800 --> 00:14:46,160
kriegen irgendwie keine Ahnung. 
3000000 Requests pro Sekunde 

303
00:14:46,480 --> 00:14:51,560
wird das ne sehr sehr, sehr 
große Datenmenge, die da die da 

304
00:14:51,560 --> 00:14:54,920
entsteht und und selbst die zu 
speichern das System kommt da 

305
00:14:54,920 --> 00:14:57,680
alles von Google, das ist 
einfach völlig outside jenseits 

306
00:14:57,680 --> 00:15:00,080
von gut und böse das das das 
kriegt man nicht hin wenn man 

307
00:15:00,080 --> 00:15:03,120
das für jeden Function Call 
macht, das heißt das erste was 

308
00:15:03,120 --> 00:15:05,840
man macht. 
Um es explizit zu sagen, ich 

309
00:15:05,840 --> 00:15:09,520
möchte nicht jede jede function 
Call mir angucken, sondern nur 

310
00:15:09,520 --> 00:15:12,720
spezifische und in Python ist es
auch in einem SDK sehr schön 

311
00:15:12,720 --> 00:15:15,200
gelöst, dass ich einfach eine 
Annotation an meine Funktion 

312
00:15:15,200 --> 00:15:17,480
mache und sage, Hey die 
interessiert mich aber jedes Mal

313
00:15:17,480 --> 00:15:20,760
wenn die ausgeführt wird bit 
capture, das quasi in diesem 

314
00:15:20,760 --> 00:15:22,480
Distributed Tracing. 
Wie wähle ich die aus? 

315
00:15:22,480 --> 00:15:25,480
Dann vorher diese Funktion, also
sind das die ist es, basiert das

316
00:15:25,480 --> 00:15:27,440
auf Verfahrung das eine 
Funktion? 

317
00:15:27,920 --> 00:15:31,600
Also die Idee ist das ja es es 
geht nicht unbedingt um Fehler, 

318
00:15:31,600 --> 00:15:33,760
es geht um die Business 
Processes zu verstehen. 

319
00:15:33,920 --> 00:15:39,520
Also du möchtest quasi von dem 
von dem Produktlevel die der der

320
00:15:39,520 --> 00:15:43,840
Button funktioniert nicht 
untergehend auf auf Architektur 

321
00:15:43,840 --> 00:15:46,760
Level zu verstehen, Na welche 
Systeme sind da drin und was ist

322
00:15:46,760 --> 00:15:49,440
so die Business Logic die da die
da kaputt geht? 

323
00:15:49,920 --> 00:15:52,800
Und wie gesagt, es muss 
irgendwie human parsible 

324
00:15:52,800 --> 00:15:55,120
bleiben. 
Das heißt, idealerweise möchte 

325
00:15:55,120 --> 00:15:58,240
ich so n so n so n Trace haben, 
der sehr konzeptionell ist. 

326
00:15:58,400 --> 00:16:01,440
Also wir haben irgendwie nen 
Order Reservation Service, der 

327
00:16:01,440 --> 00:16:05,000
Gecallt wurde und der hat dann 
ne Datenbank query gemacht mit 

328
00:16:05,000 --> 00:16:07,360
den und den was weiß ich high 
Level, die heißt irgendwie 

329
00:16:07,360 --> 00:16:11,360
Reserve Stock oder sowas und die
hat n Timeout gehabt und dann 

330
00:16:11,440 --> 00:16:13,840
dann kann ich danach immer noch 
in den Code springen oder nen 

331
00:16:13,840 --> 00:16:17,120
Debugger anmachen um dann n 
feineres debugging zu machen 

332
00:16:17,360 --> 00:16:19,440
weil man möchte in diesem 
verteilten Trace. 

333
00:16:19,800 --> 00:16:23,400
Quasi high Level, die die 
Business Logik nachvollziehen. 

334
00:16:23,400 --> 00:16:24,640
Ich. 
Verstehe, denn du musst denn, 

335
00:16:24,640 --> 00:16:26,880
denn wenn du dann einmal siehst,
überhaupt in diesem High Level 

336
00:16:26,880 --> 00:16:29,280
Stack Trace, dann weißt du 
überhaupt erst mal, welche 

337
00:16:29,280 --> 00:16:33,640
Datenbank auf welchem Server nen
Timeout hatte und damit damit 

338
00:16:33,640 --> 00:16:35,840
bist du erst mal eingenordet. 
Wo kann ich mich erst mal 

339
00:16:35,840 --> 00:16:37,680
einloggen und wo hol ich mir 
denn jetzt die Detail 

340
00:16:37,760 --> 00:16:40,400
Detailinformationen aus den Logs
zum Beispiel raus von dieser 

341
00:16:40,400 --> 00:16:42,240
Datenbank, vorher weißt du es ja
noch gar nicht, ja. 

342
00:16:42,640 --> 00:16:44,840
Genau. 
Und dann stell dir vor, für 

343
00:16:44,840 --> 00:16:47,680
jeden. 
Request, den du bei der Zalando 

344
00:16:47,680 --> 00:16:53,040
Webseite machst über Suche oder 
View Pages haben wir einen 

345
00:16:53,040 --> 00:16:55,920
Stacktrace der ungefähr 1000 
Einträge hat, nachher im 

346
00:16:55,920 --> 00:16:59,040
Telemetrie System. 
Krass, also ist ne extreme Load 

347
00:16:59,040 --> 00:17:01,040
implification. 
Da habt ihr ja ne retention 

348
00:17:01,040 --> 00:17:02,160
policy hoffentlich drauf. 
Ne. 

349
00:17:02,160 --> 00:17:05,119
Also wie das ist ja das nächste.
Also ja jetzt jetzt sagst du das

350
00:17:05,280 --> 00:17:08,160
ich verstehe das also man ich 
spreche das noch mal so n 

351
00:17:08,160 --> 00:17:11,280
bisschen in in in anderen Worten
auf die Spur also man was ihr 

352
00:17:11,280 --> 00:17:14,720
wissen wollt ist wenn ein Fehler
entsteht. 

353
00:17:15,359 --> 00:17:17,119
Wo ist der überhaupt in so einem
riesigen System? 

354
00:17:17,119 --> 00:17:19,599
Ja, ja, das heißt eure und was 
ich verstanden hab, eure 

355
00:17:19,599 --> 00:17:22,359
Strategie ist, dass wenn jeder 
User klickt oder in irgendeinen 

356
00:17:22,359 --> 00:17:25,119
User klickt einmal dann 
passieren jetzt zig Sachen, ja 

357
00:17:25,119 --> 00:17:27,240
das muss man jetzt der Zuhörer, 
der jetzt nicht so tief in Cloud

358
00:17:27,240 --> 00:17:29,960
und so weiter drin ist, aber es 
werden Netzwerk Calls gemacht 

359
00:17:29,960 --> 00:17:32,080
von einem Server zum nächsten 
und so weiter das das können 

360
00:17:32,080 --> 00:17:34,640
irgendwie genau also mit 
Microservices zusammen und so, 

361
00:17:34,640 --> 00:17:36,640
das können ganz viele Server 
sein die irgendwas gemacht haben

362
00:17:36,640 --> 00:17:38,880
und ganz viele Komponenten in 
der Datenbank wird das 

363
00:17:38,880 --> 00:17:41,200
eingetragen irgendwo wird das 
ausgetragen und sofort ja. 

364
00:17:41,680 --> 00:17:45,520
Was du jetzt sagst, ihr 
schneidet quasi so ne Art Fluss 

365
00:17:45,920 --> 00:17:50,120
durch die Architektur, durch die
Komponenten mit gut ausgewählt, 

366
00:17:50,120 --> 00:17:52,240
das ist wahrscheinlich schon 
einer der Künste, dass man das 

367
00:17:52,720 --> 00:17:55,120
nicht zu dicht macht und auch 
nicht zu dünn, sodass man genau 

368
00:17:55,200 --> 00:17:58,080
später sich quasi lang hangeln 
kann und weiß, wo muss ich genau

369
00:17:58,080 --> 00:18:01,080
gucken und der tut das quasi für
jeden Klick und jetzt wär mal ne

370
00:18:01,080 --> 00:18:04,680
Frage, das kannst du ja machen. 
Aber wahrscheinlich nicht ewig 

371
00:18:04,680 --> 00:18:06,280
lange. 
Also du wirst doch nicht sagen 

372
00:18:06,280 --> 00:18:09,280
können, was war vor einem halben
Jahr, als der als der gesagt, 

373
00:18:09,440 --> 00:18:11,360
weil du hast ja gesagt, sind 
sowieso viele Daten, ja, das 

374
00:18:11,360 --> 00:18:14,240
heißt, die Macht das 
wahrscheinlich so Last Day oder 

375
00:18:14,240 --> 00:18:16,560
Last Two Days oder darfst du 
das, darfst du das sprechen, was

376
00:18:16,560 --> 00:18:18,720
habt ihr da so? 
Ja, das das hat sich verändert. 

377
00:18:18,720 --> 00:18:21,040
Das waren früher eher hours, 
jetzt haben wir irgendwie n paar

378
00:18:21,040 --> 00:18:25,040
Days, da das das, da ändert sich
auch so die Capabilities von den

379
00:18:25,040 --> 00:18:27,600
verschiedenen Zulieferern die 
diese Systeme betreiben, das 

380
00:18:27,600 --> 00:18:30,360
machen wir auch nicht selber. 
Ja und die andere Sache die man 

381
00:18:30,360 --> 00:18:34,400
auch dazu sagen muss. 
Wir speichern nicht alle dieser 

382
00:18:34,400 --> 00:18:36,640
Traces ab. 
Wir haben da ne Sampling Rate 

383
00:18:36,640 --> 00:18:38,280
drauf. 
Aktuell ist das glaub ich so bei

384
00:18:38,280 --> 00:18:40,640
rund 30%, was immer noch sehr 
viel ist. 

385
00:18:40,640 --> 00:18:44,000
Andere Firmen sind eher so bei 
ein oder 0 Komma ein Prozent und

386
00:18:44,480 --> 00:18:49,000
da ist tatsächlich in meinen 
Augen ist es die richtige Art 

387
00:18:49,000 --> 00:18:51,680
und Weise damit umzugehen. 
Wir haben in diesem ganzen 

388
00:18:51,680 --> 00:18:55,200
obsibility Prozess so ne nen 
fundamentalen Trader auf den wir

389
00:18:55,200 --> 00:18:57,480
immer machen müssen, das ist 
einfach Datenvolumen und damit 

390
00:18:57,480 --> 00:19:01,440
auch Kosten mit Resolution. 
Und da muss man ein bisschen 

391
00:19:01,440 --> 00:19:04,960
smart sein, wenn man einfach 
jeden function Call und jeden 

392
00:19:04,960 --> 00:19:06,880
was heißt. 
Register Assignment Rauslockt 

393
00:19:06,880 --> 00:19:09,200
aus dem Prozess, da macht die 
CPU nachher überhaupt nichts 

394
00:19:09,200 --> 00:19:10,680
anderes mehr als nur ständig zu 
berichten. 

395
00:19:10,680 --> 00:19:13,200
Was hast du gerade gemacht und 
das ist letztlich auch nicht 

396
00:19:13,200 --> 00:19:16,400
wirklich zielführend, sondern 
man muss bei den Daten, die man 

397
00:19:16,400 --> 00:19:19,040
wirklich rausschreibt und sagt 
die Zentralisiere ich und die 

398
00:19:19,040 --> 00:19:22,080
speichere ich und die indiziere 
ich nachher auch, da muss man 

399
00:19:22,080 --> 00:19:25,840
schon so mal ökonomisch mit 
umgehen und wir haben Phänomene,

400
00:19:26,000 --> 00:19:30,160
es gibt einige. 
Operationen nennen wir die zum 

401
00:19:30,160 --> 00:19:34,640
Beispiel Reset Passwort oder 
Change Adress oder 

402
00:19:34,800 --> 00:19:37,840
Profilseitenänderungen. 
Die sind teilweise auch wichtig 

403
00:19:37,840 --> 00:19:41,760
für die User Experience, aber 
die sind sehr selten und da 

404
00:19:41,760 --> 00:19:44,800
wollen wir jetzt schon jeden 
einzelnen Reset Passwort request

405
00:19:44,800 --> 00:19:48,680
gerne haben, weil das sind 10 
pro Minute vielleicht ja, da 

406
00:19:48,680 --> 00:19:51,440
kommen wir, da kommen wir alle 
Mitsteinen in voller Detailgröße

407
00:19:51,760 --> 00:19:56,680
aber View Gender Home ja wenn du
einfach einfach auf die Webseite

408
00:19:56,680 --> 00:20:00,320
kommst. 
Da reicht n Promille locker 

409
00:20:00,880 --> 00:20:04,880
locker und das heißt, da möchte 
man so dynamisch n bisschen die 

410
00:20:04,880 --> 00:20:07,960
Granularität Unterfahren und die
zweite Sache, die ich da gerade 

411
00:20:07,960 --> 00:20:10,080
noch anfügen möchte, ist, ich 
glaube, auch wenn man dieses 

412
00:20:10,080 --> 00:20:12,960
Obsibility Endgame anguckt, ich 
mein, Wir sind jetzt irgendwie 

413
00:20:13,040 --> 00:20:16,960
keine Ahnung 15 Jahre drin in 
diesem Obsibility Game, 

414
00:20:17,200 --> 00:20:19,280
vielleicht noch n bisschen 
länger seit.com vielleicht auch 

415
00:20:19,360 --> 00:20:22,400
ja OK, dot com hatte auch schon 
obsibility, insofern jetzt gut, 

416
00:20:22,400 --> 00:20:26,720
vielleicht 25 Jahre, aber wir 
sind noch nicht am Zielen. 

417
00:20:26,880 --> 00:20:31,240
Ich glaube, dass man immer noch 
diese diese Fragen, die man an 

418
00:20:31,240 --> 00:20:34,160
den Prozess stellen kann, dass 
die immer noch sehr limitiert 

419
00:20:34,160 --> 00:20:37,440
sind und ich hoffe, dass wir in 
der Zukunft immer mehr in der 

420
00:20:37,440 --> 00:20:43,040
Lage sind, immer präzisere 
Fragen an an an Systeme zu 

421
00:20:43,040 --> 00:20:46,400
stellen und die Antworten nicht 
zu bekommen, weil wir alles 

422
00:20:46,400 --> 00:20:48,960
weggelockt haben und so ne 
riesige Datenbank haben, wo 

423
00:20:48,960 --> 00:20:52,560
alles was das System die gemacht
hat drin ist, sondern weil wir 

424
00:20:52,560 --> 00:20:56,000
an das System selber rantreten 
und quasi dynamisch fragen. 

425
00:20:56,480 --> 00:20:58,160
Sag mal, was ist denn in dieser 
Variable drin? 

426
00:20:58,160 --> 00:21:00,640
Sag mal, wie oft hast du das 
denn ausgeführt und dass wir 

427
00:21:00,640 --> 00:21:04,440
sehr viel quasi näher an die an 
die Anwendung kommen und dann 

428
00:21:04,440 --> 00:21:08,080
näher an den Prozess kommen und 
den direkter auf diese Daten 

429
00:21:08,080 --> 00:21:11,680
zugreifen, das ist zumindest 
langfristig denke ich wo wo wir 

430
00:21:11,680 --> 00:21:13,640
auch wieder was sehen werden, 
dass wir näher in die Richtung 

431
00:21:13,640 --> 00:21:17,800
kommen, ja. 
Ein kurzer Hinweis in eigener 

432
00:21:17,800 --> 00:21:19,880
Sache. 
Kennst du das auch, dass von 

433
00:21:19,880 --> 00:21:22,120
neuer Software zur 
Digitalisierung der Produktion 

434
00:21:22,120 --> 00:21:24,320
zurückgeschreckt wird? 
Ihr seid gefangen zwischen 

435
00:21:24,320 --> 00:21:27,280
starrer, veralteter 
Standardsoftware und endlosen 

436
00:21:27,280 --> 00:21:28,800
Individual 
Entwicklungsprojekten. 

437
00:21:29,200 --> 00:21:32,880
Unsere Mission bei Heisenware 
ist es, das zu beenden mit 

438
00:21:32,880 --> 00:21:35,360
unserem App Baukasten geben wir 
dir die Möglichkeit, 

439
00:21:35,520 --> 00:21:39,040
maßgeschneiderte Software für 
den Shopfloor schnell und ohne 

440
00:21:39,040 --> 00:21:41,920
Code zu erstellen. 
Denk an Maschinendatenerfassung 

441
00:21:41,920 --> 00:21:44,720
moderne Visualisierung für die 
Produktionsleiter oder eine 

442
00:21:44,720 --> 00:21:47,520
mobile App zur Buchung von 
Zeiten direkt am Arbeitsplatz 

443
00:21:48,080 --> 00:21:51,520
und das beste du kannst deine 
Lösungen ganz einfach ohne it 

444
00:21:51,600 --> 00:21:54,560
Aufwand selbst betreiben. 
Sagt günstiger als eine externe 

445
00:21:54,560 --> 00:21:57,920
Entwicklung unendlich passender 
als Software von der Stange. 

446
00:21:58,000 --> 00:22:01,280
Weitere Infos und eine 
kostenlose 30 Tage Testphase 

447
00:22:01,280 --> 00:22:04,800
findest du auf heisenware.com. 
Slash einfach minus komplex als 

448
00:22:04,800 --> 00:22:08,400
Träumhörer bieten wir dir im 
Anschluss 20% Rabatt auf alle 

449
00:22:08,400 --> 00:22:11,720
Pakete im ersten Jahr und jetzt 
viel Spaß mit der weiteren Folge

450
00:22:11,720 --> 00:22:15,840
ich hab darf ich noch eine Frage
stellen zu den zu den Traces 

451
00:22:15,840 --> 00:22:18,960
oder den den Spuren vielleicht 
ein bisschen naiv, aber dafür 

452
00:22:18,960 --> 00:22:22,280
bin ich ja da. 
Für irgendeinen Request jetzt 

453
00:22:22,280 --> 00:22:24,000
auf der Website sagen wir mal 
den den Passwort. 

454
00:22:24,000 --> 00:22:27,400
Du hast gerade den den Passwort 
Change und den einfach den 

455
00:22:27,400 --> 00:22:30,400
Website Aufruf quasi als als 2 
Beispiele gebracht, ist diese 

456
00:22:30,720 --> 00:22:32,960
Trace diese Spur vorher schon 
definiert? 

457
00:22:32,960 --> 00:22:36,720
Wisst ihr wo dann die wie der 
Flow quasi ist? 

458
00:22:36,720 --> 00:22:40,080
Durch all eure Microservices und
Funktionen oder werden die dann 

459
00:22:40,240 --> 00:22:43,840
dynamisch auch wieder 
mitgeschnitten und man weiß es 

460
00:22:43,840 --> 00:22:46,160
danach eigentlich erst? 
Wie ist es gelaufen? 

461
00:22:46,400 --> 00:22:49,040
Also ja, das ist das ne Gute. 
Frage also das System 

462
00:22:49,040 --> 00:22:51,200
funktioniert. 
Das hat 2 Komponenten die das 

463
00:22:51,200 --> 00:22:54,080
zum Funktionieren bringen. 
Das eine ist quasi ID 

464
00:22:54,080 --> 00:22:58,640
propagation in dem Moment wo wo 
der Request zum ersten Mal die 

465
00:22:58,640 --> 00:23:02,080
Infrastruktur trifft wird ne 
UUID generiert und diese UID 

466
00:23:02,080 --> 00:23:04,880
wird propagiert, das heißt ich 
muss vorher keinen Flow 

467
00:23:04,880 --> 00:23:07,360
definieren oder irgendwas, 
sondern ich muss nur wissen 

468
00:23:07,520 --> 00:23:09,360
jeder ITTP request hat so n 
Header. 

469
00:23:09,920 --> 00:23:12,720
Und da steht ne Flow ID drin und
die muss ich dann wieder 

470
00:23:12,720 --> 00:23:14,960
aufgreifen. 
Das muss quasi dieses API 

471
00:23:14,960 --> 00:23:17,360
Framework machen und das muss 
auch die Applikation können, 

472
00:23:17,360 --> 00:23:20,640
dass sie diesen diesen Header 
weitergibt und jetzt die zweite 

473
00:23:20,640 --> 00:23:23,000
Sache ist. 
Centralized Storage, also jede 

474
00:23:23,000 --> 00:23:26,080
Applikation die managt so ne Q 
von diesen ganzen Events die sie

475
00:23:26,080 --> 00:23:29,280
gespeichert hat und die schreibt
die dann asynchron an ein 

476
00:23:29,280 --> 00:23:32,320
zentrales Backend und was das 
Backend jetzt macht, das guckt 

477
00:23:32,320 --> 00:23:34,360
einfach und kriegt kriegt den 
von den ganzen Applikationen. 

478
00:23:34,360 --> 00:23:37,680
Kriegt das jetzt diese diese 
diese Spuren oder Traces 

479
00:23:37,680 --> 00:23:40,800
zugesandt? 
Und das macht jetzt so nen Join.

480
00:23:41,040 --> 00:23:43,720
Das guckt sich quasi, wenn der 
Nutzer da ne Anfrage macht guckt

481
00:23:43,720 --> 00:23:45,120
sich das an. 
Na ja, was waren denn die ganzen

482
00:23:45,120 --> 00:23:48,720
Events die ich mit dieser Trace 
ID gesehen hab und dann baut die

483
00:23:48,720 --> 00:23:50,920
das zu einem Stack Trace View 
zusammen, das heißt nachher der 

484
00:23:50,920 --> 00:23:54,800
Entwickler der der der klickt 
dann auf so n so n so ne Trace 

485
00:23:54,800 --> 00:23:57,840
ID und dann sieht er diesen Baum
wie du das aus einem Debugger 

486
00:23:57,840 --> 00:23:59,680
auch kennst. 
Wo du diese Frames untereinander

487
00:23:59,680 --> 00:24:02,520
hast und dann sieht er halt. 
Oft halt auch mit Timing. 

488
00:24:02,520 --> 00:24:04,480
Informationen wie lang so n Spam
ist. 

489
00:24:04,480 --> 00:24:07,000
Das zeigt immer wie lange ne 
Operation gedauert hat, aber es 

490
00:24:07,000 --> 00:24:09,640
ist letztlich so ne Stack Trace 
artige Datenstruktur die dann 

491
00:24:09,640 --> 00:24:11,040
visualisiert wird, das heißt 
der. 

492
00:24:11,040 --> 00:24:14,360
Request identifiziert sich in 
jedem Schritt als der Request 

493
00:24:14,360 --> 00:24:17,280
über die UID und dadurch habt 
ihr nachher den Flow, aber 

494
00:24:17,280 --> 00:24:19,000
keiner muss den vorher 
definieren. 

495
00:24:19,000 --> 00:24:21,400
Das ist gegeben durch den durch 
den Code selbst. 

496
00:24:21,600 --> 00:24:24,880
Der Flow wird quasi. 
Discovered, aber du hast pro 

497
00:24:24,880 --> 00:24:27,360
Applikation 
instrumentierungsaufwand und das

498
00:24:27,360 --> 00:24:30,720
ist tatsächlich die praktische 
Hürde, wo ganz viele Firmen dran

499
00:24:30,720 --> 00:24:32,960
scheitern. 
Nachher, wenn man das alles in 

500
00:24:32,960 --> 00:24:35,840
allen Systemen drin hat, ist das
mega cool. 

501
00:24:36,160 --> 00:24:39,560
Also ganz, ganz viele Probleme 
sind halt einfach OK. 

502
00:24:39,560 --> 00:24:42,320
Du machst das auf, ist völlig 
offensichtlich, es ist OK, ich 

503
00:24:42,320 --> 00:24:45,880
weiß irgendwie 10 Service ist 
tief, es ist der Datenbank 

504
00:24:45,880 --> 00:24:48,320
kriegt weiß nicht ich kann den 
Error direkt sehen OK ich weiß 

505
00:24:48,320 --> 00:24:52,440
es war irgendwie n overload oder
irgendwie n parameterproblem und

506
00:24:52,440 --> 00:24:54,480
dann ist die D Bogging Journey 
einfach sehr schnell. 

507
00:24:54,800 --> 00:24:57,680
Aber wenn du erstmal da bist, du
hast noch keine Applikation 

508
00:24:57,680 --> 00:25:01,400
instrumentiert, du bist einfach 
noch auf auf auf Schritt 0, dann

509
00:25:01,400 --> 00:25:04,960
fängst du an, eine Applikation 
zu instrumentieren und dann 

510
00:25:04,960 --> 00:25:07,840
Mehrwert ist einfach nahe 0. 
Weil du kriegst noch keine Trace

511
00:25:07,840 --> 00:25:09,680
ID übergeben. 
Du schreibst vielleicht deine 

512
00:25:09,680 --> 00:25:11,600
Trace id weiter, aber die wird 
im nächsten Schritt wieder 

513
00:25:11,600 --> 00:25:15,840
ignoriert und das heißt, selbst 
wenn du 34 hast, siehst du 

514
00:25:15,840 --> 00:25:18,480
einfach noch keine Traces die 
wirklich zusammenhängen, sondern

515
00:25:18,640 --> 00:25:22,320
sobald du immer einen dazwischen
hat, der dieses System nicht 

516
00:25:22,320 --> 00:25:25,000
respektiert. 
Fallen deine Traces auseinander,

517
00:25:25,000 --> 00:25:27,840
was die Usability davon geringer
macht. 

518
00:25:27,840 --> 00:25:30,800
Was du bekommst ist n Access 
log, das hab ich tatsächlich bei

519
00:25:30,800 --> 00:25:33,280
mir in meinem Homelab hab ich 
auch ziemlich viel Monitoring 

520
00:25:33,280 --> 00:25:36,360
laufen, aber ich hab kein 
Tracing oder kein gutes Tracing,

521
00:25:36,360 --> 00:25:39,720
ich hab nur Tracing auf dem Load
Balancer und dann hab ich n 

522
00:25:39,720 --> 00:25:43,640
nettes Access log, man hat halt 
keinen keine weiteren 

523
00:25:43,640 --> 00:25:46,200
Informationen, damit fängt es 
halt an und dann hat man so ne 

524
00:25:46,200 --> 00:25:48,600
Journey wo man dann anfängt OK 
jetzt hab ich vielleicht die 

525
00:25:48,600 --> 00:25:51,520
ersten Layer oder die ersten 2 
Layer instrumentiert und 

526
00:25:51,520 --> 00:25:53,040
irgendwann wird es dann mega 
cool. 

527
00:25:53,280 --> 00:25:56,240
Weil, Hey, du hast auf einmal 
Discovery von Clients. 

528
00:25:56,480 --> 00:25:59,360
Also wer sind eigentlich der 
callt dich eigentlich von mal? 

529
00:25:59,360 --> 00:26:01,920
Verstehst du das total gut, weil
die alle ihre Trace IDS 

530
00:26:01,920 --> 00:26:04,520
mitschicken und dann kannst du 
sagen Hey OK ich weiß nicht nur 

531
00:26:04,520 --> 00:26:06,960
wer mich gecallt hat, ich weiß 
auch warum der mich gecallt hat 

532
00:26:07,040 --> 00:26:09,520
und welche User Journey quasi 
dahinter steckt auf unserer 

533
00:26:09,520 --> 00:26:13,200
Webseite solche Sachen kann man 
dann machen aber das sind so 

534
00:26:13,200 --> 00:26:15,400
Netzwerkeffekte die dann zum 
Tragen kommen wenn du halt 

535
00:26:15,400 --> 00:26:17,520
relativ weit schon bist. 
Ist es dann nicht. 

536
00:26:17,520 --> 00:26:20,160
So dass also ich kann davon auch
n Lied singen, immer im kleinen 

537
00:26:20,160 --> 00:26:22,440
ne, also ich hab nie mit Zalando
gearbeitet, dann noch nicht mal 

538
00:26:22,440 --> 00:26:25,240
halb so groß, aber die Probleme 
sind die gleichen, auch wenn du 

539
00:26:25,240 --> 00:26:27,120
n kleineres System hast. 
Du willst es trotzdem alles 

540
00:26:27,120 --> 00:26:29,760
wissen und wenn du so n bisschen
anfängst dich zu verteilen, dann

541
00:26:29,760 --> 00:26:32,960
dann dann hast du technisch 
mathematisch die gleichen 

542
00:26:32,960 --> 00:26:35,880
Probleme nur auf n kleineren 
Scale sag ich mal aber ist nicht

543
00:26:35,880 --> 00:26:38,080
das eine schwierige, dass du n 
sehr guten Systemarchitekten 

544
00:26:38,080 --> 00:26:39,800
brauchst? 
Der sagt wenn man einmal dann 

545
00:26:39,800 --> 00:26:42,080
das ist glaub ich ne 
Architekturentscheidung die alle

546
00:26:42,160 --> 00:26:44,800
deine wie viele waren es 
Developer respektieren müssen. 

547
00:26:45,080 --> 00:26:47,520
Dass man sagt, Pass auf wir, wir
machen das so mit dieser ID, so 

548
00:26:47,520 --> 00:26:50,560
wie du es gesagt hast. 
Deshalb von der UNIQUE ID und es

549
00:26:50,560 --> 00:26:52,480
funktioniert. 
System funktioniert ja nur dann 

550
00:26:52,560 --> 00:26:55,880
perfekt, wenn jeder einzelne 
Entwickler der n Code schreibt 

551
00:26:55,880 --> 00:26:58,600
jetzt kommen wir nämlich noch 
mal zurück und ich glaube du 

552
00:26:58,600 --> 00:27:00,480
sagst wieder dann falsch wenn 
ich falsch liege, aber ich 

553
00:27:00,480 --> 00:27:03,120
glaube es ist so, dass jeder 
einzelne Entwickler muss das 

554
00:27:03,120 --> 00:27:06,880
quasi kennen und akzeptieren und
in seine Logs dir ne Applikation

555
00:27:06,880 --> 00:27:09,760
rausschreibt, das ist nämlich 
jetzt wichtig, die Applikation 

556
00:27:09,760 --> 00:27:12,440
macht jetzt zum Beispiel NSQL 
Query irgendwo drauf auf ne 

557
00:27:12,440 --> 00:27:15,760
irgendeine Datenbank, ja. 
Da muss dann in in dem Log der 

558
00:27:15,760 --> 00:27:18,800
dazugehört, den ich als 
applikationsentwickler schreibe,

559
00:27:18,960 --> 00:27:22,000
diese ID mit abgeloggt werden, 
dass die irgendwo steht, ja oder

560
00:27:22,000 --> 00:27:24,720
abgeschickt werden oder wie auch
immer, ja dekollation muss 

561
00:27:24,720 --> 00:27:27,760
entstehen und das was du sagtest
glaub ich um das auch noch mal 

562
00:27:27,760 --> 00:27:30,160
zu sagen ist dabei, dass er 
quasi wieso n Baum ist. 

563
00:27:30,160 --> 00:27:33,120
Du fängst oben an und dann geht 
es wieso n wieso ne wieso n 

564
00:27:33,120 --> 00:27:35,680
Gewitter quasi wieso Blitze die 
sich verteilen geht es runter 

565
00:27:35,680 --> 00:27:38,640
ins System. 
Und wenn nur ein, wenn nur ein 

566
00:27:38,640 --> 00:27:41,400
System quasi die ID nicht weiter
nach unten leitet, dann hast du 

567
00:27:41,400 --> 00:27:44,280
quasi so n Bruch drin und kannst
schlechter verstehen. 

568
00:27:44,280 --> 00:27:46,480
Was war da los? 
Ja und kurz noch mal um Gerrit 

569
00:27:46,480 --> 00:27:49,680
zu sagen warum, warum kann man 
das im Prinzip eigentlich nur 

570
00:27:50,000 --> 00:27:53,280
post mortem irgendwie 
analysieren was da los ist, weil

571
00:27:53,280 --> 00:27:55,920
tatsächlich solche 
hochverteilten Systeme und jetzt

572
00:27:55,920 --> 00:27:58,480
quetscht er mich wieder weg wenn
es nicht so ist bei Zalando im 

573
00:27:58,480 --> 00:28:01,600
Prinzip nicht vorhersagbar sind,
weil nämlich diese Load 

574
00:28:01,600 --> 00:28:04,880
Balancer, von denen der Heinrich
spricht, das sind quasi Server 

575
00:28:04,880 --> 00:28:07,680
die entscheiden jeder. 
Für jede Anfrage neu. 

576
00:28:08,320 --> 00:28:11,120
Wo geht die gerade hin? 
Die Entscheidung, das können 

577
00:28:11,680 --> 00:28:13,960
statische Algorithmen sein, wo 
man sagt, Ich mach einfach Round

578
00:28:13,960 --> 00:28:16,720
Robin immer der nächste und so 
weiter dann kann man sich das 

579
00:28:16,720 --> 00:28:18,480
vielleicht zusammenreihen was so
ist, aber da gibt es viel 

580
00:28:18,480 --> 00:28:21,120
kompliziertere Algorithmen die 
wisst die die die überlegen 

581
00:28:21,120 --> 00:28:24,200
quasi woah der hat jetzt hier 
ganz wenig gekriegt und so 

582
00:28:24,200 --> 00:28:26,080
weiter und sofort, ja 
unglaublich schwer 

583
00:28:26,080 --> 00:28:29,360
vorherzusagen, wer am Ende der 
deine Anfrage abkriegt, selbst 

584
00:28:29,360 --> 00:28:31,440
für denjenigen der den Code da 
geschrieben hat, ja weil. 

585
00:28:32,000 --> 00:28:34,560
Genau, dass die Idee ist, dass 
das System quasi mit diesen Load

586
00:28:34,560 --> 00:28:36,400
balancern irgendwie so belegt 
wird, dass irgendwie alle 

587
00:28:36,400 --> 00:28:38,560
gleichmäßig busy sind und nicht 
der eine schwitzt und die 

588
00:28:38,560 --> 00:28:41,520
anderen feiern so. 
Ja, also die 2 Sachen noch mal 

589
00:28:41,520 --> 00:28:43,320
gerade nachgesprochen. 
So das glaub ich, gibt noch mal 

590
00:28:43,320 --> 00:28:46,440
so n vielleicht so n Verständnis
warum man diese warum man warum 

591
00:28:46,440 --> 00:28:49,120
das wichtig ist, diese ID immer 
weiterzureichen, warum man 

592
00:28:49,120 --> 00:28:52,160
vorher nicht weiß wer eigentlich
das Abkriegt, den ganzen Kram. 

593
00:28:53,000 --> 00:28:54,600
Ja, das ist konzeptionell genau 
richtig. 

594
00:28:54,600 --> 00:28:57,800
Und auch gerade dieses Problem 
bei dem Monitoring Bindor hatten

595
00:28:57,800 --> 00:29:00,240
wir noch kein so verteiltes 
System, das war noch irgendwie 

596
00:29:00,240 --> 00:29:04,600
2000 Zehner Jahre, da war das ja
schon vielleicht n bisschen 

597
00:29:04,600 --> 00:29:08,360
später 15, aber da, da haben wir
noch irgendwie auf einzelne 

598
00:29:08,360 --> 00:29:11,440
Server deployed und auch uns da 
eingeloggt mit SSH und ich hab 

599
00:29:11,440 --> 00:29:14,360
da auch ständig die Logs getailt
und ich wusste auch OK, in 

600
00:29:14,360 --> 00:29:17,280
unserem Webstore waren wir 
vielleicht 3 Nodes bei unserer 

601
00:29:17,280 --> 00:29:20,000
Datenbank 10. 
Aber ich seh einfach jeden 10. 

602
00:29:20,000 --> 00:29:22,400
Rick fest und ich konnte auch 10
SSH Fenster aufmachen. 

603
00:29:22,400 --> 00:29:24,880
Wenn ich jetzt ganz genau wissen
wollte, wo wo es wo der 

604
00:29:24,880 --> 00:29:27,040
hinkommt. 
Die hab ich dann teilweise dann 

605
00:29:27,040 --> 00:29:29,600
manuell in ne Datenbank 
reingeschoben und dann irgendwie

606
00:29:29,600 --> 00:29:33,040
meine Creps da drüber gemacht. 
Ja das funktioniert bei Zalando 

607
00:29:33,040 --> 00:29:36,040
einfach nicht mehr, weil 
teilweise sind die einfach auf 

608
00:29:36,040 --> 00:29:39,360
5000 Nodes hochgescaled also da 
wird es mit SSH Fenster 

609
00:29:39,360 --> 00:29:42,840
aufmachen n bisschen schwierig 
und so n großen Bildschirm. 

610
00:29:43,280 --> 00:29:44,920
Genau. 
So große Bildschirme haben wir 

611
00:29:44,920 --> 00:29:47,120
nicht, ja. 
Und du hast auch noch diese 

612
00:29:47,120 --> 00:29:50,160
dynamischen Sachen, dass du du 
kommst mit Kybernet, das sowieso

613
00:29:50,160 --> 00:29:52,040
nicht gut ran. 
Und selbst wenn du rankommst, 

614
00:29:52,040 --> 00:29:54,360
dann ist der Pott vielleicht weg
oder es kam irgendwie n Neuer 

615
00:29:54,360 --> 00:29:56,080
dazu. 
Das ist alles n bisschen 

616
00:29:56,080 --> 00:29:59,680
dynamischer, das heißt also 
diese diese Idee ich, ich 

617
00:29:59,680 --> 00:30:02,080
arbeite mit der Applikation 
selber oder mit diesem 

618
00:30:02,080 --> 00:30:05,440
Deployment selber, das ist es 
ist sehr sehr schwierig, obwohl 

619
00:30:05,440 --> 00:30:07,560
ich ich denke, dass das 
Unterdeveloped ist. 

620
00:30:07,560 --> 00:30:09,840
Ich glaube, an vielen Stellen 
sollten wir das tatsächlich tun,

621
00:30:09,840 --> 00:30:14,160
und das ist auch so dieser 
Gedanke, ganz viel von also. 

622
00:30:15,360 --> 00:30:18,120
Die Sachen, die wir bei Zalando 
machen, sind nicht konzeptionell

623
00:30:18,120 --> 00:30:20,720
anders als auf jeder Scale. 
Auch ich mach ne ganze Menge 

624
00:30:20,720 --> 00:30:23,720
Prototyping in meinem Home Lab, 
wo ich einfach 20 Container hab 

625
00:30:23,720 --> 00:30:27,040
auf einer Note und konzeptionell
sind die Sachen mehr oder 

626
00:30:27,040 --> 00:30:29,440
weniger dieselben, auch was der 
Entwickler sieht ist dieselbe, 

627
00:30:29,600 --> 00:30:32,560
die Plattform ist natürlich n 
bisschen anders und was du schon

628
00:30:32,560 --> 00:30:34,800
angesprochen hast dieses 
Governance Thema, wie stelle ich

629
00:30:34,800 --> 00:30:37,680
denn sicher, dass wir hier alle 
zusammenarbeiten ist natürlich 

630
00:30:37,680 --> 00:30:41,280
wichtig, weil sonst kriegst du 
diese Broken traces und das ist 

631
00:30:41,360 --> 00:30:43,200
tatsächlich genau die Krux an 
der Sache. 

632
00:30:43,840 --> 00:30:46,520
Wie du es dargestellt hast mit 
diesem OK, die Entwickler müssen

633
00:30:46,520 --> 00:30:49,280
genau diese ID in die Loginline 
reinmachen, da sind wir n 

634
00:30:49,280 --> 00:30:52,320
bisschen weiter, da gibt es 
mittlerweile open Standards, das

635
00:30:52,320 --> 00:30:56,160
ist vor allen Dingen das Open 
telemetry Projekt, was einen 

636
00:30:56,160 --> 00:31:00,480
Satz von Libraries anbietet, wo 
alle sagen wir mal a Mainstream 

637
00:31:00,480 --> 00:31:03,920
Frameworks mit supported sind 
und sobald du dann Open 

638
00:31:03,920 --> 00:31:06,400
telemetry importierst macht er 
dieses. 

639
00:31:07,360 --> 00:31:10,720
ID Forwarding Layer macht der im
Wesentlichen automatisch und für

640
00:31:10,720 --> 00:31:12,240
ne ganze Menge Standard Library 
ist. 

641
00:31:12,240 --> 00:31:15,200
Gerade Datenbankadapter gibt es 
dann auch Autoinstrumentations 

642
00:31:15,360 --> 00:31:18,320
wo der dann einfach sagt, OK 
jede Datenbank kriegt fest, 

643
00:31:18,480 --> 00:31:21,640
kriegt ne standardisierte Spam 
zugeordnet, da gibt es auch ne 

644
00:31:21,640 --> 00:31:24,320
ganze Menge Felder die 
automatisch gefüllt sind, also 

645
00:31:24,320 --> 00:31:28,640
da da wurde wurde schon ne Menge
abstrahiert und der der Datapart

646
00:31:28,640 --> 00:31:31,040
ist auch ein bisschen ein 
anderer also wir schreiben das 

647
00:31:31,040 --> 00:31:33,880
nicht in den Log Stream rein der
in das Login System geht sondern

648
00:31:33,880 --> 00:31:35,840
es gibt einfach einen parallelen
Datenstream. 

649
00:31:36,080 --> 00:31:38,880
Der dann direkt in dieses 
Tracing System geht. 

650
00:31:39,280 --> 00:31:41,040
Da kommst du jetzt nämlich. 
Auf den Punkt, da würde ich 

651
00:31:41,040 --> 00:31:42,840
gerne noch mal aus 
Eigeninteresse noch mal n 

652
00:31:42,840 --> 00:31:45,640
bisschen tiefer reinhaken, weil 
ja erstmal für den Zuhörer noch 

653
00:31:45,640 --> 00:31:49,040
mal also das die Anwendung 
selber würde natürlich am 

654
00:31:49,040 --> 00:31:51,600
schönsten am schnellsten laufen,
wenn sie gar nichts preisgeben 

655
00:31:51,600 --> 00:31:53,680
würde von ihr. 
Also man muss einfach dazu 

656
00:31:53,680 --> 00:31:56,080
sagen, das ist so wenn ich was 
ablogge wenn ich was 

657
00:31:56,080 --> 00:31:59,200
hinspeichere Informationen 
wegspeicher über das was ich 

658
00:31:59,200 --> 00:32:01,760
gerade gemacht hab, dann ist es 
einfach zusätzlicher Aufwand 

659
00:32:01,760 --> 00:32:03,360
erstmal weil ich es einfach 
speichern muss. 

660
00:32:03,840 --> 00:32:06,120
Und zweitens, weil, weil ich es 
irgendwo, also weil ich, weil 

661
00:32:06,120 --> 00:32:10,080
ich es im Prozess machen muss, 
das heißt, mein mein Code kommt 

662
00:32:10,080 --> 00:32:12,720
irgendwie, request kommt an, 
jetzt mach ich irgendwie SQL 

663
00:32:12,720 --> 00:32:13,760
Call, jetzt will ich ihn 
eigentlich wieder 

664
00:32:13,760 --> 00:32:16,320
zurückschicken, kann ich nicht, 
weil ich muss hinschreiben, mein

665
00:32:16,320 --> 00:32:19,280
Code, mein mein Call kommt an, 
jetzt mach ich den SQL Call und 

666
00:32:19,280 --> 00:32:22,960
jetzt log ich erstmal das was 
ich da gecallt hab und das frag 

667
00:32:22,960 --> 00:32:25,720
ich dich gleich wohin auch immer
ja auf die Festplatte oder 

668
00:32:25,720 --> 00:32:28,240
vielleicht schick ich ihn ab 
oder so aber immerhin in diesem 

669
00:32:28,240 --> 00:32:31,120
Programm gibt es halt eine Zeile
Code die dafür. 

670
00:32:31,520 --> 00:32:35,680
Zuständig ist nur mal darüber zu
zu benachrichtigen, dass das 

671
00:32:35,680 --> 00:32:37,520
passiert ist. 
Das macht das Programm 

672
00:32:37,520 --> 00:32:40,800
langsamer. 
Punkt ja, und das heißt, man 

673
00:32:40,800 --> 00:32:44,480
will eigentlich im Idealen, in 
der idealen theoretischen Welt 

674
00:32:44,480 --> 00:32:47,280
will man zwar alle Informationen
haben, aber möglichst non 

675
00:32:47,280 --> 00:32:51,040
intrusive ja, ich mach mal n 
Bild ja wenn wir sagen, der 

676
00:32:51,040 --> 00:32:53,840
Zalando Architektur Stack mit 
den ganzen Servern im ganzen 

677
00:32:53,840 --> 00:32:56,120
Kram ist sowas wie n 
komplizierter Organismus, wieso 

678
00:32:56,120 --> 00:32:59,280
n Mensch ja und jetzt füttern 
wir irgendwas rein um den 

679
00:32:59,280 --> 00:33:00,800
Menschen irgendwas funktioniert 
nicht mehr. 

680
00:33:01,240 --> 00:33:02,880
Dann ist ja halt schon so 
komplex geworden, dass wir gar 

681
00:33:02,880 --> 00:33:06,000
nicht mehr genau wissen, wieso 
welche, welche Magenkehre hat. 

682
00:33:06,000 --> 00:33:08,520
Jetzt, da hier irgendwas 
abgekriegt, ne und jetzt 

683
00:33:08,520 --> 00:33:12,360
könntest du mittelaltermäßig 
intrusiv ja steckst du halt in 

684
00:33:12,360 --> 00:33:14,960
den Menschen irgendwelche 
Elektroden rein, so die zeichnen

685
00:33:14,960 --> 00:33:16,720
dir das irgendwie mit ja und du 
weißt was los ist. 

686
00:33:16,880 --> 00:33:19,000
Das tut den Menschen aber nicht 
so gut und das tut halt auch der

687
00:33:19,000 --> 00:33:21,280
Zalando Anwendung nicht so gut, 
das heißt du willst eigentlich 

688
00:33:21,280 --> 00:33:23,520
dich hin entwickeln zu so einem 
Bild wo du Raumschiff Enterprise

689
00:33:23,520 --> 00:33:27,320
mäßig steht halt Pille da und 
macht halt mit diesem mit diesem

690
00:33:27,320 --> 00:33:30,080
Scanner da ja einmal der 
Organismus hoch und runter. 

691
00:33:30,640 --> 00:33:32,360
Das hat den nicht dabei gestört 
zu verdauen. 

692
00:33:32,360 --> 00:33:35,640
Ne der verdaut ist super, läuft 
alleine rum, ist alles andere 

693
00:33:35,640 --> 00:33:38,000
Systeme werden nicht gestört, 
weiß aber trotzdem wie es ihm 

694
00:33:38,000 --> 00:33:42,320
geht und jetzt komme ich zu 
meiner Frage wenn man als normal

695
00:33:42,320 --> 00:33:44,560
Entwickler irgendwie gibt es ja 
auch so loglybe Reason so weiter

696
00:33:44,560 --> 00:33:46,560
wenn ich jetzt no GS 
programmiere oder Python oder 

697
00:33:46,560 --> 00:33:49,520
wie auch immer im Backend dann 
schreibe ich halt irgendwie im 

698
00:33:49,520 --> 00:33:51,240
besten Fall schon mit dem 
Timestamp und so n bisschen 

699
00:33:51,240 --> 00:33:54,640
schön aufbereitet den Kram hin 
log line dann legt er sich aber 

700
00:33:54,640 --> 00:33:56,720
wohin denn? 
Ja in meinem Docker Volume. 

701
00:33:56,960 --> 00:33:59,280
Und in dein Docker Volume ist 
halt wieder auf der Festplatte 

702
00:33:59,280 --> 00:34:00,960
von dem Server, wo ich halt 
gerade lebe. 

703
00:34:00,960 --> 00:34:03,480
So, ja das kann ich machen, ist 
auch relativ schnell, weil 

704
00:34:03,480 --> 00:34:05,960
Festplattenschreiben ist ja auch
schon relativ schnell, macht ihr

705
00:34:06,080 --> 00:34:09,920
das noch so und und greift ihr 
dann quasi mit? 

706
00:34:09,920 --> 00:34:12,880
Weil meine Frage ist jetzt wie 
kommen diese ganzen Daten, die 

707
00:34:12,880 --> 00:34:15,000
müssen ja irgendwie mit zentral 
irgendwo aggregiert ankommen, 

708
00:34:15,000 --> 00:34:16,800
davon hast du auch schon 
geredet, dafür gibt es Software 

709
00:34:17,280 --> 00:34:20,000
aber wird das live abgeschickt 
während dieses Log Event 

710
00:34:20,000 --> 00:34:21,920
entsteht oder wird das erstmal 
auf die Festplatte gehauen? 

711
00:34:21,920 --> 00:34:24,120
Dann gibt es den zweiten Prozess
der scannt das und schickt das 

712
00:34:24,120 --> 00:34:26,320
in Dingern weg weil ich will ja 
irgendwie schaffen. 

713
00:34:26,800 --> 00:34:29,600
Dass mein mein ganzes Logging 
und Monitoring System nicht 

714
00:34:29,600 --> 00:34:32,080
meine Anwendung langsam macht 
und kannst du da uns noch n paar

715
00:34:32,080 --> 00:34:35,600
Insights geben oder mir vor ich 
bin da auch noch auf der Suche 

716
00:34:35,600 --> 00:34:38,639
nach der idealen Lösung für n 
für ne Mittel für mittelgroße 

717
00:34:38,679 --> 00:34:40,920
Architektur sag ich mal ja 
übrigens. 

718
00:34:40,920 --> 00:34:43,040
Ist echt wirklich sehr sehr 
schön auf den Punkt, weil genau 

719
00:34:43,040 --> 00:34:44,719
um die Sachen geht es und es ist
im Prinzip auch nicht 

720
00:34:44,719 --> 00:34:47,360
schwieriger als das die die 
meisten die meisten Sachen. 

721
00:34:48,159 --> 00:34:50,920
Bei bei Telemetrie du machst 
eigentlich immer was ähnliches 

722
00:34:50,920 --> 00:34:53,840
als so n Print F Statement und 
das sind 2 Sachen die da ne 

723
00:34:53,840 --> 00:34:55,960
Rolle spielen. 
Das eine ist die Serialisierung,

724
00:34:55,960 --> 00:34:58,960
die Serialisierung, also das 
Stringformetting und das ist 

725
00:34:58,960 --> 00:35:01,720
schon relativ teuer weil du 
alliziierst n relativ großen 

726
00:35:01,720 --> 00:35:05,120
Speicherbereich und dann machst 
du so CPU intensive Sachen, also

727
00:35:05,120 --> 00:35:09,600
jeder der auch json parsing oder
json seriilization gemacht hat, 

728
00:35:09,600 --> 00:35:12,320
das ist oft das langsamste was 
dein Microservice macht und 

729
00:35:12,320 --> 00:35:14,800
jetzt machst du noch mal was was
potenziell sehr langsam ist 

730
00:35:14,800 --> 00:35:17,600
nämlich. 
Dein schönes Event, quasi als 

731
00:35:17,600 --> 00:35:20,480
schönes Human Readibles String 
aufzubereiten, in irre großes 

732
00:35:20,480 --> 00:35:21,960
Ding. 
Und dann machst du was zweites, 

733
00:35:21,960 --> 00:35:24,560
was auch sehr langsam ist, 
nämlich normalerweise IO du 

734
00:35:24,720 --> 00:35:27,120
schreibst es auf die Festplatte 
oder du schreibst es über das 

735
00:35:27,120 --> 00:35:29,840
Netzwerk, das heißt es geht aus 
deinem Arbeitsspeicher rum, geht

736
00:35:29,840 --> 00:35:32,400
einmal um ein System wo es geht 
in die in die Netzwerkkarte 

737
00:35:32,400 --> 00:35:36,320
rein, das ist alles teuer, das 
ist ziemlich teuer und gerade 

738
00:35:36,320 --> 00:35:39,600
diese ganzen Sachen no JIS 
Dummel mit asing quinness IO und

739
00:35:39,600 --> 00:35:41,360
was weiß ich, da haben wir ja 
auch als Entwickler sehr viel 

740
00:35:41,360 --> 00:35:43,160
gehört. 
Wie man das jetzt besser macht, 

741
00:35:43,160 --> 00:35:45,200
das ist alles total relevant in 
dem Kontext. 

742
00:35:45,280 --> 00:35:47,920
Manches kann man einfach 
offloaden, wo man sagt, OK 

743
00:35:47,920 --> 00:35:51,120
asynchron, wenn die CPU mal 
nichts zu tun hat, dann dann 

744
00:35:51,120 --> 00:35:54,480
schieben wir das dann irgendwie 
weg oder haben irgendwie NDMA 

745
00:35:54,480 --> 00:35:58,600
Lösungen, dass das nicht mehr 
über die CPU muss, aber das ist 

746
00:35:58,600 --> 00:36:01,360
im wesentlichen ist es dieses 
Spiel und das ist auch genauso 

747
00:36:01,360 --> 00:36:05,360
komplex, also Invariance of 
Problem und dann ist n 

748
00:36:05,360 --> 00:36:09,360
kostendifferencial da wieviel 
kostet mich ein Prozent 

749
00:36:09,360 --> 00:36:11,600
Performance overhead, wieviel 
kostet mich? 

750
00:36:11,840 --> 00:36:15,120
5% Performance Overhead wieviel 
kostet mich 50% Performance 

751
00:36:15,120 --> 00:36:18,520
Overhead und je nachdem wie fein
ich logge sind wir auf diesen 

752
00:36:18,520 --> 00:36:21,520
Skalen unterwegs. 
Was mich n bisschen schockiert 

753
00:36:21,520 --> 00:36:26,480
hat oder enttäuscht hat ist, 
dass die Commercial Incentives 

754
00:36:26,480 --> 00:36:28,920
nicht unbedingt da sind zu 
sagen, wir machen Performance 

755
00:36:28,920 --> 00:36:33,080
Oriented Programming bei 
Zalando, also ist es oft nicht 

756
00:36:33,080 --> 00:36:35,920
so entscheidend wichtig, ob wir 
ein Prozent schneller oder 

757
00:36:35,920 --> 00:36:38,240
langsamer sind. 
Weil die Profit margins, die 

758
00:36:38,240 --> 00:36:41,040
hängt tatsächlich nicht da dran.
Machen wir 100 Milliarden 

759
00:36:41,040 --> 00:36:44,120
Requests die Sekunde, sondern 
wir haben irgendwie n paar 

760
00:36:44,120 --> 00:36:47,360
Requests von jedem Nutzer, die 
dann hoffentlich hoffentlich mit

761
00:36:47,360 --> 00:36:51,440
relativ high Commercial Revenue 
konvertieren. 

762
00:36:51,680 --> 00:36:54,560
Also wir haben ne so ne Menge 
Spielraum, also die 

763
00:36:54,560 --> 00:36:58,080
Infrastrukturkosten sind kein so
immens, der Kostenfaktor in 

764
00:36:58,080 --> 00:37:00,640
einem großen Zalandokosten wenn 
du es jetzt mit Returns 

765
00:37:00,640 --> 00:37:03,680
Management oder so vergleichst. 
Ja das heißt. 

766
00:37:04,240 --> 00:37:06,880
Die Incentives sind nicht jetzt 
zu sagen, da polieren wir eher. 

767
00:37:07,120 --> 00:37:11,280
Die Incentive ist eher zu sagen,
Hey, wenn unser Shopdown ist, 

768
00:37:11,360 --> 00:37:13,720
dann können wir gar nichts 
verkaufen und wir müssen das um 

769
00:37:13,720 --> 00:37:15,680
jeden Preis verhindern, weil das
ist einfach absolut 

770
00:37:15,680 --> 00:37:18,520
schweineteuer Verfügbarkeit. 
Müsst ihr optimieren als erste 

771
00:37:18,520 --> 00:37:19,960
im Parameter genau 
Verfügbarkeit. 

772
00:37:19,960 --> 00:37:23,040
Ist extrem wichtig im E 
Commerce, wo du wirklich auch so

773
00:37:23,040 --> 00:37:26,000
ne direkte Korrelation hast. 
Wenn der Shopdown ist, verdienst

774
00:37:26,000 --> 00:37:28,560
du kein Geld, das hast du bei 
einer Bank zum Beispiel nicht 

775
00:37:28,560 --> 00:37:31,600
so, das ist auch ne Logistik 
nicht so und das verschiebt 

776
00:37:31,600 --> 00:37:34,800
quasi wie diese wie diese. 
Trade Offs gemacht werden. 

777
00:37:34,960 --> 00:37:37,760
Selbst würde ich generell sagen,
Zalando ist eher auf der Seite 

778
00:37:37,760 --> 00:37:41,680
mehr loggen und mehr Daten 
rausschreiben als jetzt 

779
00:37:41,680 --> 00:37:43,600
Performance orientiert zu 
programmieren, das muss 

780
00:37:43,600 --> 00:37:46,640
natürlich trotzdem nicht 
stupidly wasteful sein, aber da 

781
00:37:46,640 --> 00:37:49,040
sind wir schon so mal eher 
bereit Trade offs zu machen, zu 

782
00:37:49,040 --> 00:37:54,160
sagen wir sind da eher verbos 
orientiert ja cool, danke für 

783
00:37:54,160 --> 00:37:55,760
die. 
Inzeit und ist dann jetzt jetzt 

784
00:37:55,760 --> 00:37:58,640
mal ne soziale Frage in so n 
Team. 

785
00:37:58,720 --> 00:38:00,960
Also. 
So n Job kann ja ganz schön hart

786
00:38:00,960 --> 00:38:03,840
sein, weil ich ich meine jetzt, 
du bist ja genau die Person, die

787
00:38:03,840 --> 00:38:06,240
im Wind steht, wenn was nicht 
funktioniert. 

788
00:38:06,240 --> 00:38:09,520
Ja so, du sagst ja verfügt, also
warum macht ihr das alles um um 

789
00:38:09,520 --> 00:38:12,960
wenn was nicht funktioniert 
möglichst schnell weil 

790
00:38:12,960 --> 00:38:16,560
Schnelligkeit hast du gesagt Key
ja rauszufinden was los ist 

791
00:38:17,120 --> 00:38:19,440
müsst ihr das trainieren also 
ich ich kenn mich selber ich 

792
00:38:19,440 --> 00:38:21,360
weiß nicht ob es anderen 
Entwicklern geht wenn bei uns 

793
00:38:21,360 --> 00:38:23,040
was kaputt ist. 
Ja manchmal krieg ich so ne 

794
00:38:23,040 --> 00:38:25,600
Nachricht von Gerrit Ich hab das
und das gemacht das geht 

795
00:38:25,600 --> 00:38:27,600
überhaupt nicht es ist für mich 
das Schlimmste. 

796
00:38:28,080 --> 00:38:30,520
Also wenn ich hab ich ich hab 
den schönsten Tag ja und wenn 

797
00:38:30,520 --> 00:38:33,120
dann sowas kommt, so weißt du so
ne standardsache wo du sagst 

798
00:38:33,440 --> 00:38:36,960
Alter das ne ich ich geb mal n 
Beispiel Time Series Database 

799
00:38:36,960 --> 00:38:39,560
hatten wir heute morgen ja Time 
Series Database ich drück da auf

800
00:38:39,560 --> 00:38:43,280
den Knopf da kommt nichts und 
als Entwickler geht in deinem 

801
00:38:43,280 --> 00:38:47,480
Schädel ab wenn da nichts kommt 
dann dann ist die das ist 

802
00:38:47,480 --> 00:38:49,760
richtig scheiße und du weißt 
gerade was alles noch alles 

803
00:38:49,760 --> 00:38:52,080
sterben wird weil weil das 
gerade nicht geht ja. 

804
00:38:52,640 --> 00:38:54,360
Und ich krieg dann das große P 
in die Augen. 

805
00:38:54,360 --> 00:38:56,560
Ich bin echt wirklich, also ich 
muss richtig dran üben, ich bin 

806
00:38:56,560 --> 00:38:59,280
wirklich richtig unentspannt und
kann dann gar nicht mehr meiner 

807
00:38:59,280 --> 00:39:01,960
normalen Arbeit nachgehen, weil 
das eigentlich so brennend ist, 

808
00:39:03,000 --> 00:39:05,880
dass ich eigentlich noch nicht 
mal Lust oder den Mut habe, 

809
00:39:05,880 --> 00:39:07,840
irgendwie das fertigzumachen, 
was ich gerade hab, was sinnvoll

810
00:39:07,840 --> 00:39:10,680
wäre und und mich das völlig aus
dem Takt bringt. 

811
00:39:10,680 --> 00:39:12,800
Ja, ist das denn nicht auch so 
bei euch? 

812
00:39:12,800 --> 00:39:14,560
Also vor allen Dingen auch wenn 
ich, wenn du sagst, also die 

813
00:39:14,560 --> 00:39:16,880
Entwickler werden da mit 
Rangezogen so und irgendwie der 

814
00:39:16,880 --> 00:39:19,680
Shop ist tot, jemand drückt da, 
also es gab oder hier 

815
00:39:19,680 --> 00:39:21,360
krasserweise es gab neues 
Release ja. 

816
00:39:21,600 --> 00:39:23,480
Irgendwas, was immer, immer 
ging, ja irgendwo ist. 

817
00:39:23,480 --> 00:39:26,160
Da gab es doch keinen Test oder 
irgendwas ist jetzt kaputt. 

818
00:39:26,160 --> 00:39:29,840
Ja, dann ist ja, das ist ja wie 
wenn die, wenn es brennt so oder

819
00:39:30,240 --> 00:39:32,320
kannst du da mal so n so n 
Inside geben, so wie wie macht 

820
00:39:32,320 --> 00:39:34,720
ihr das? 
Da diese Analogie zu 

821
00:39:34,720 --> 00:39:37,640
firefighting ist tatsächlich 
auch sehr, sehr adäquat. 

822
00:39:37,640 --> 00:39:42,000
Aber Hektik und Aufregung bringt
nichts, selbst wenn du viel Geld

823
00:39:42,000 --> 00:39:45,080
verlierst. 
Jede Minute ist es, die die 

824
00:39:45,080 --> 00:39:48,000
Attitüde muss Professional sein,
in dem in dem Moment. 

825
00:39:48,320 --> 00:39:50,800
Und deswegen übt man das auch. 
Deswegen gibt es eine ganze 

826
00:39:50,800 --> 00:39:52,240
Menge Material. 
Auch die, die Teams 

827
00:39:52,240 --> 00:39:55,280
bereitstellen für ihre Incident 
Responder, diese sogenannten 

828
00:39:55,280 --> 00:39:56,920
Playbooks, so 
Standardprozeduren, die 

829
00:39:56,920 --> 00:39:59,400
durchführbar sind. 
Oft sind auch Gamedays, wo das 

830
00:39:59,400 --> 00:40:03,640
trainiert wird, es ist ein 
relativ standardprozess, es ist 

831
00:40:03,640 --> 00:40:07,880
OK, der Order Drop Alert kommt 
OK check die commercials Check 

832
00:40:07,880 --> 00:40:12,480
die SLOS welche Systeme sind es?
Wir haben oft sind die Leute, 

833
00:40:12,480 --> 00:40:15,440
die es betrifft, schon direkt 
selber alerted, weil die Teams, 

834
00:40:15,440 --> 00:40:17,440
die die Applikation 
bereitstellen, in der Regel sehr

835
00:40:17,440 --> 00:40:20,600
gutes Alerting Coverage haben. 
Dann wird n Incident aufgemacht 

836
00:40:20,600 --> 00:40:23,800
im Chat, wenn es wirklich n 
großer Major Incident ist, wird 

837
00:40:23,800 --> 00:40:25,680
sofort n Video Meeting dazu 
gemacht. 

838
00:40:26,080 --> 00:40:29,040
Wir gucken durch, wir in den 
Traces, was sehen wir, können 

839
00:40:29,040 --> 00:40:31,440
wir die Fehlerdiagnose machen, 
welche Teams brauchen wir, um es

840
00:40:31,440 --> 00:40:33,200
zu beheben? 
Ihr macht n Video. 

841
00:40:33,200 --> 00:40:35,360
Meeting aber nicht um zu 
quatschen, sondern ihr macht 

842
00:40:35,360 --> 00:40:37,880
einfach das auf und dabei sitzt 
ihr und jeder guckt in die Dings

843
00:40:37,880 --> 00:40:40,160
und ihr sprecht einfach wieso n 
in unserem Online Game hier. 

844
00:40:40,160 --> 00:40:41,760
Ich seh das und das und so 
weiter kann man sich so 

845
00:40:41,760 --> 00:40:44,400
vorstellen, einfach die schnell 
mal alle zusammen, also die die 

846
00:40:44,400 --> 00:40:45,960
großen. 
Incidents die laufen so ab, wenn

847
00:40:45,960 --> 00:40:48,320
man wirklich weiß, die Scheiße 
ist am dampfen, dann haben wir 

848
00:40:48,320 --> 00:40:52,240
einen Incident Commander, der so
Koordinator des Incidents ist. 

849
00:40:52,480 --> 00:40:55,440
Der hat formal keine Aufgaben im
Debugging, der Macht nicht groß 

850
00:40:55,440 --> 00:40:57,920
seine Konsole auf und versucht 
es zu verstehen, sondern der ist

851
00:40:57,920 --> 00:41:02,080
Koordinator und der stellt 
sicher, dass alle Leute, die das

852
00:41:02,080 --> 00:41:06,080
betrifft, die die Meaningvoll an
der Incident Resolution 

853
00:41:06,080 --> 00:41:09,840
beteiligt sein sollen, in dem 
Raum sind und arbeitsbereit sind

854
00:41:10,160 --> 00:41:11,840
und dass auch Leute, die 
ablenken, einfach 

855
00:41:11,840 --> 00:41:13,680
rausgeschmissen werden. 
Gibt es auch teilweise, dass 

856
00:41:13,680 --> 00:41:15,840
dann auch teilweise Senior 
Management Stakeholder mal da 

857
00:41:15,840 --> 00:41:18,960
gewesen sind und irgendwie so. 
Status haben wollten. 

858
00:41:18,960 --> 00:41:21,120
Und er hat dann auch gesagt, 
Bitte nicht jetzt, ihr werdet 

859
00:41:21,120 --> 00:41:25,400
informiert über ein so ne 
regelmäßige so n Form was du 

860
00:41:25,400 --> 00:41:27,760
dann ausfüllst als Incident 
Commander wo dann quasi 

861
00:41:27,760 --> 00:41:31,440
Management Board und Management 
Chain informiert werden. 

862
00:41:31,640 --> 00:41:33,880
Man kann im Chat irgendwie 
folgen wenn man das als 

863
00:41:33,880 --> 00:41:36,160
Entwickler auch gerne wissen 
will, wo stehen wir gerade oder 

864
00:41:36,160 --> 00:41:39,480
wenn man vielleicht auch helfen 
kann aber das wichtige ist es 

865
00:41:39,480 --> 00:41:42,800
ist n standardprozess. 
Es ist Full Attention, alles 

866
00:41:42,800 --> 00:41:45,920
stehen und liegen lassen. 
Wir fixen das jetzt also alle 

867
00:41:45,920 --> 00:41:49,120
anderen Sachen haben Pause nicht
noch irgendwie n wichtiges OK, 

868
00:41:49,120 --> 00:41:50,760
dann ist ja mein. 
Gefühl immer richtig, dass ich 

869
00:41:50,760 --> 00:41:52,680
alles andere erstmal stehen und 
liegen lasse. 

870
00:41:52,720 --> 00:41:55,760
Alles stehen und liegen lassen. 
Wenn Commercial Impact da ist, 

871
00:41:55,760 --> 00:41:58,640
auf jeden Fall. 
Es gibt natürlich Abstufungen, 

872
00:41:58,880 --> 00:42:01,160
wir haben da so n so n 
Threshold, was ist n Incident, 

873
00:42:01,160 --> 00:42:05,440
aber generell sobald für User 
Experience im großen Stil, also 

874
00:42:05,440 --> 00:42:07,920
mal mehr als 100 User oder mehr 
als 1000 user. 

875
00:42:08,320 --> 00:42:11,040
Beeinflusst ist ist es n 
Incident und das wird mit Höchst

876
00:42:11,040 --> 00:42:14,400
der Priorität gemacht bis er 
mittigiert ist. 

877
00:42:14,400 --> 00:42:18,040
Also das heißt bis das Bleeding 
gestoppt ist und danach ist so 

878
00:42:18,040 --> 00:42:19,680
OK. 
Geht mal nach Hause. 

879
00:42:19,680 --> 00:42:22,320
Wir fangen jetzt nicht noch an 
irgendwie den Code zu fixen 

880
00:42:22,560 --> 00:42:26,400
nachts um 9, sondern das machen 
wir am nächsten Morgen aber als 

881
00:42:26,400 --> 00:42:29,000
erstes und dann schreiben wir 
auch n Dokument direkt das 

882
00:42:29,000 --> 00:42:31,520
postmorton Dokument Dokument und
das ist auch relativ 

883
00:42:31,520 --> 00:42:34,120
standardisiert, ist nicht so arg
lang aber es wird halt 

884
00:42:34,120 --> 00:42:36,480
aufgeschrieben na ja was ist 
schiefgelaufen? 

885
00:42:36,640 --> 00:42:39,720
Was sind die, was war die, was 
war die Ursache und was wollen 

886
00:42:39,720 --> 00:42:41,960
wir besser machen? 
Dass das in nächster Zeit nicht 

887
00:42:41,960 --> 00:42:45,120
mehr passiert und das durchläuft
dann auch n Standardprozess, da 

888
00:42:45,120 --> 00:42:48,400
gibt es dann auch auf Zalando 
Ebene noch mal so nen gesamten 

889
00:42:48,400 --> 00:42:51,200
Operational Review, wo wir aber 
die letzte Woche zurückgucken 

890
00:42:51,200 --> 00:42:53,600
und sagen Hey wieviel Sachen 
sind denn schiefgelaufen, gibt 

891
00:42:53,600 --> 00:42:55,440
es irgendwie auf globaler Ebene 
noch Sachen die wir besser 

892
00:42:55,440 --> 00:42:57,840
machen müssen? 
Ja, du habe. 

893
00:42:57,840 --> 00:42:59,520
Ich bei bei euch. 
Jetzt habe ich verstanden 

894
00:42:59,520 --> 00:43:03,080
Incidents oder Major Incidents 
Messe ihr an der Anzahl der 

895
00:43:03,080 --> 00:43:06,840
betroffenen Nutzer. 
Also es kann n ganz kleines 

896
00:43:06,840 --> 00:43:10,680
Problem eigentlich im in der 
Software sein, aber Incidents 

897
00:43:10,680 --> 00:43:13,040
bemisst sich, also die Schwere 
des des Incidents bemisst sich 

898
00:43:13,040 --> 00:43:17,200
nachdem wie viele User betroffen
sind quasi so das erste Teil der

899
00:43:17,200 --> 00:43:20,000
Frage zweite ist wenn jetzt 
jemand was noch nicht macht wie 

900
00:43:20,000 --> 00:43:23,440
definier ich denn gute Major 
Minor oder überhaupt Incidents 

901
00:43:23,600 --> 00:43:25,280
Kennzahlen für mich ja sehr 
gute. 

902
00:43:25,280 --> 00:43:28,000
Frage. 
Also das ist allgemein 

903
00:43:28,000 --> 00:43:31,360
Hochdimensional das Problem und 
das ist auch nach nach Business 

904
00:43:31,440 --> 00:43:33,240
unterschiedlich. 
Also das ist für ne Logistik 

905
00:43:33,240 --> 00:43:36,960
oder ne Bank unterschiedlich 
viel von E Commerce Company und 

906
00:43:37,440 --> 00:43:40,720
es es gibt da Standardliteratur 
zu und es gibt auch glaub ich 

907
00:43:40,720 --> 00:43:43,680
dokumentiert was Google oder 
andere Companies macht machen. 

908
00:43:44,320 --> 00:43:46,720
Ich glaube was am meisten Sinn 
macht sich ist erstmal über 

909
00:43:46,720 --> 00:43:50,040
Impact die menschens Gedanken zu
machen was sind Art und weisen 

910
00:43:50,040 --> 00:43:53,920
wie ich Messe Impact Messe und. 
Bei jedem, also E Commerce 

911
00:43:53,920 --> 00:43:55,760
Company hast du immer commercial
impact. 

912
00:43:55,840 --> 00:43:58,720
Das ist quasi den Revenue, den 
du einfach nicht machst. 

913
00:43:58,880 --> 00:44:02,560
Den kannst du oft relativ genau 
messen, weil du weißt wieviel du

914
00:44:02,960 --> 00:44:05,000
wieviel Orders du pro Minute 
rein kriegst. 

915
00:44:05,000 --> 00:44:07,400
Und wenn du weniger Orders rein 
kriegst, das kannst du dann so 

916
00:44:07,400 --> 00:44:10,320
einen Pi mal daumenfaktor 
anlegen um zu verstehen wie groß

917
00:44:10,320 --> 00:44:13,600
ist der Impact, aber ganz viele 
Incidence, zum Beispiel wenn 

918
00:44:13,600 --> 00:44:15,720
Reset Passwort nicht 
funktioniert haben keinen 

919
00:44:15,720 --> 00:44:17,800
Commercial Impact. 
Weißt du, dass die trotzdem 

920
00:44:17,800 --> 00:44:20,160
irgendwie nicht wichtig waren? 
Natürlich waren die wichtig. 

921
00:44:20,640 --> 00:44:23,640
Und du brauchst dann 
pragmatische KPIS, die dir so 

922
00:44:23,640 --> 00:44:25,440
erlauben, so n Daumen dran zu 
machen. 

923
00:44:25,760 --> 00:44:28,680
Du kannst da beliebig das 
Weitertreiben und irgendwie 

924
00:44:28,680 --> 00:44:31,520
gucken, was war denn jetzt der 
Impact zu so zu so NKPI im 

925
00:44:31,520 --> 00:44:34,640
Produktbereich, der ist Customer
Lifetime Value, aber wie willst 

926
00:44:34,640 --> 00:44:37,160
du den jemals berechnen? 
Also diese Sachen bringen 

927
00:44:37,160 --> 00:44:38,720
nichts, sondern ganz 
pragmatisch. 

928
00:44:38,880 --> 00:44:42,640
Wir haben noch Dimensionen 
kosten, wenn manchmal waren 

929
00:44:42,640 --> 00:44:45,040
keine User Experience da, aber 
wir haben dummerweise n 

930
00:44:45,040 --> 00:44:47,920
grafikkartencluster was 
Wochenende laufen lassen ja ist 

931
00:44:47,920 --> 00:44:50,400
auch n incident. 
Der dann irgendwie bepreist 

932
00:44:50,400 --> 00:44:53,280
wird. 
Oder wir haben diese 

933
00:44:53,480 --> 00:44:56,400
Userdimension wieviel Nutzer 
waren beeinflusst oder wieviel 

934
00:44:56,400 --> 00:44:59,560
Employees waren beeinflusst. 
Davon ist auch wichtig und das 

935
00:44:59,560 --> 00:45:03,000
sind so mal 445 KPIS und dann 
kann ich umgekehrt sagen, Na ja,

936
00:45:03,000 --> 00:45:07,280
wenn weniger als 100 User 
beeinflusst sind, dann fangen 

937
00:45:07,280 --> 00:45:09,760
wir jetzt nicht an nachts um 3 
dieses Problem zu fixen. 

938
00:45:09,840 --> 00:45:13,760
Es ist dann auch wichtig für die
Teams dann zu sagen, OK, nur 

939
00:45:13,760 --> 00:45:16,640
weil wir jetzt n Problem sehen. 
Wenn das unter so einem gewissen

940
00:45:16,640 --> 00:45:18,560
Threshold ist. 
Wenn wir wissen, No Financial 

941
00:45:18,560 --> 00:45:23,080
impact oder no Major Financial 
Impact oder nur so wenig Nutzer 

942
00:45:23,080 --> 00:45:24,080
beteiligt. 
Es gibt dann so 

943
00:45:24,080 --> 00:45:27,120
Ausschusskriterien, wo man mit 
gutem Gewissen sagen kann, wir, 

944
00:45:27,120 --> 00:45:30,840
wir machen dieses Thema jetzt 
erstmal wieder zu und genau und 

945
00:45:30,880 --> 00:45:33,880
jetzt die letzte Frage, wie 
definiere ich severity da gibt 

946
00:45:33,880 --> 00:45:37,440
es auch in der in der Community 
verschiedene Meinungen zu was 

947
00:45:37,440 --> 00:45:40,720
wir machen ist wir haben einfach
Beispiele genommen, wir haben 

948
00:45:40,720 --> 00:45:42,920
gesagt hier haben wir ne 
Handvoll Incidents, das waren 

949
00:45:42,920 --> 00:45:45,280
für uns die SEV Einser. 
Das sind so, wenn du auf n 

950
00:45:45,280 --> 00:45:47,360
halbes Jahr zurückguckst. 
Das sind die, die die in 

951
00:45:47,360 --> 00:45:50,000
Erinnerung bleiben. 
Wir haben zum Beispiel in der 

952
00:45:50,000 --> 00:45:54,480
Cyberweek einmal unsere gesamte 
DNS Config genjuckt in AWS, das 

953
00:45:54,480 --> 00:45:59,320
ist so ein memorable SEV One, wo
einfach alle internen Tools 

954
00:45:59,440 --> 00:46:03,360
nicht mehr funktioniert haben, 
ja und externen Tools ja 

955
00:46:03,440 --> 00:46:05,520
telefonbuchseite. 
Zerrissen quasi für die Leute, 

956
00:46:05,520 --> 00:46:06,920
die jetzt das nicht ganz 
verstanden haben. 

957
00:46:06,920 --> 00:46:09,040
Also DNS irgendwie DNS verjuckt 
heißt die die. 

958
00:46:09,760 --> 00:46:12,320
Du erreichst nichts mehr, wo es 
mal irgendwie sein sollte. 

959
00:46:12,320 --> 00:46:14,480
Die Telefonbücher und die 
Nummern haben sich irgendwie, 

960
00:46:14,480 --> 00:46:16,440
die Zuordnung hat sich irgendwie
verändert, aber kurz 

961
00:46:16,440 --> 00:46:19,680
zwischendurch ja. 
Genau und zum schlechtest 

962
00:46:19,680 --> 00:46:23,000
möglichen Zeitpunkt. 
Und wir haben dreieinhalb 

963
00:46:23,000 --> 00:46:25,920
Stunden gebraucht, bis wir den 
Shop wieder im Laufen hatten und

964
00:46:25,920 --> 00:46:29,600
11 Stunden bis wir internen 
Tools wieder am Laufen hatten. 

965
00:46:31,040 --> 00:46:34,000
Ja also ja es ist ne sehr sehr 
nette Geschichte, ich hätte dir 

966
00:46:34,160 --> 00:46:36,520
dieses Jahr schon mal auf einer 
Konferenz erzählt, deswegen fühl

967
00:46:36,520 --> 00:46:38,480
ich mich jetzt hier auch 
komfortabel das zu scheren. 

968
00:46:38,720 --> 00:46:41,600
Da gibt es auch n blogspot zu. 
War sehr memorable ist da 

969
00:46:41,600 --> 00:46:45,600
metapata Incident oder 
tatsächlich von einem Typo wo 

970
00:46:45,600 --> 00:46:48,480
immer Meta Data stehen sollte, 
da hat sein Infrastruktur 

971
00:46:48,480 --> 00:46:52,120
Engineer NP zu viel eingefügt 
und dann ist Automation 

972
00:46:52,120 --> 00:46:55,320
Losgetriggert und hat einfach 
alle die NS entrys Ausgejuckt 

973
00:46:55,320 --> 00:46:58,560
von allen Clustern. 
Also ich glaube ja, dass diese. 

974
00:46:58,560 --> 00:47:01,000
Story von dem die, die kennt ihr
alle mit dem Schmetterling oder 

975
00:47:01,000 --> 00:47:03,760
dem Falter, der dann den den 
den, den den Falterschlag macht 

976
00:47:03,760 --> 00:47:05,840
und dann steht steht irgendwo 
auf der anderen, auf dem anderen

977
00:47:05,840 --> 00:47:07,920
Kontinent n Orkan. 
Das gibt es ja hier. 

978
00:47:07,920 --> 00:47:10,440
Ne die wie heißt das gleich? 
Ich hab es vergessen, Butterfly 

979
00:47:10,440 --> 00:47:12,960
Effect der Butterfly Effekt 
danke den gibt es eigentlich in 

980
00:47:12,960 --> 00:47:15,080
der Software viel stärker als 
jetzt hier über irgendein 

981
00:47:15,080 --> 00:47:16,640
Butterfly. 
Ja das ist nämlich tatsächlich 

982
00:47:16,640 --> 00:47:19,080
so, manchmal reicht n Komma oder
n doppelter Buchstabe oder 

983
00:47:19,080 --> 00:47:22,640
irgend so was an der falschen 
Stelle zur falschen Zeit falsch 

984
00:47:22,640 --> 00:47:25,040
deployed und man kann sich das 
nicht vorstellen als 

985
00:47:25,040 --> 00:47:28,480
normalsterblicher und dann gehen
halt weiß weiß ich zehneinhalb 

986
00:47:28,480 --> 00:47:31,400
Millionen teilen Code und die 
entsprechende Infrastruktur 

987
00:47:31,400 --> 00:47:34,320
einfach bar. 
Das sind aber dann auch die 

988
00:47:34,320 --> 00:47:36,640
schönen Dinger, muss man sagen. 
Die sind dann die Dinger hat, 

989
00:47:36,640 --> 00:47:39,320
wenn man sie dann findet, sind 
sie auch schnell gefixt, ja, 

990
00:47:39,320 --> 00:47:41,440
also weil dann stellen pack ich 
das kommen wir halt wieder hin 

991
00:47:41,440 --> 00:47:44,160
und und dann geht es auch schon 
wieder einigermaßen, stimmt 

992
00:47:44,160 --> 00:47:45,960
nicht ganz, weil in der 
Zwischenzeit ist halt alles 

993
00:47:45,960 --> 00:47:48,920
mögliche, weil die Leute Leute 
empfangen ja also ihr habt ja 

994
00:47:48,920 --> 00:47:50,840
einfach viele requests ne und 
ich dann krieg ich in 

995
00:47:50,840 --> 00:47:52,880
konsistente Daten oder 
Irgendsowas und sofort da hab 

996
00:47:52,880 --> 00:47:55,120
ich Notfall dann muss ich was 
abräumen danach noch hab viel 

997
00:47:55,680 --> 00:47:57,760
ich hab glaub ich viel 
bereinigungsarbeit und so weiter

998
00:47:57,760 --> 00:47:59,840
da hat mir da Konsistenz 
hinzuschieben und sofort ja. 

999
00:48:00,640 --> 00:48:02,080
Ja, kommt. 
Immer drauf ankommt, drauf an. 

1000
00:48:02,360 --> 00:48:04,800
Denn wenn keine Daten 
reinkommen, dann ist oft nicht 

1001
00:48:04,800 --> 00:48:07,440
so schwer, wenn falsche Daten 
reinkommen ist horrible. 

1002
00:48:07,680 --> 00:48:09,720
Ich mag noch mal. 
Also wie ich würd gerne noch mal

1003
00:48:09,720 --> 00:48:11,880
kurz auf dem Incident bleiben, 
aber ich mag noch mal n bisschen

1004
00:48:11,880 --> 00:48:13,920
anderes Thema anschneiden und 
wir gehen auch so n so n 

1005
00:48:13,920 --> 00:48:15,640
bisschen in die Verlängerung sag
ich mal. 

1006
00:48:15,640 --> 00:48:17,880
Aber das das würd ich gerne 
schon noch mal irgendwie auf die

1007
00:48:17,880 --> 00:48:20,800
Tonspur bringen und zwar 
incident detection fänd ich 

1008
00:48:20,800 --> 00:48:22,400
jetzt mal ganz spannend. 
Du hast jetzt ganz am Anfang 

1009
00:48:22,400 --> 00:48:24,040
gesagt ich hab dir direkt gleich
das auf meinen Zettel 

1010
00:48:24,040 --> 00:48:26,560
geschrieben, find ich total 
spannend weil. 

1011
00:48:27,080 --> 00:48:28,520
Klar, jetzt haben wir da 
gesprochen, wir wissen nen 

1012
00:48:28,520 --> 00:48:31,200
Incident und wir gehen dann 
durch die Stack traces, aber 

1013
00:48:31,360 --> 00:48:33,840
woher wissen wir denn überhaupt,
dass es n Incident gibt? 

1014
00:48:33,840 --> 00:48:37,680
Das ist ja auch n Riesenthema 
das du sitzt halt im Sessel und 

1015
00:48:37,840 --> 00:48:40,280
guckst im Notfall irgendwie auf 
irgendeine Konsole von irgendwo 

1016
00:48:40,280 --> 00:48:42,360
hin, da weißt du ja auch nicht, 
dass Zalando kaputt ist. 

1017
00:48:42,360 --> 00:48:46,160
So ja und also meine Frage zielt
darauf hin, ich verstehe Ihr 

1018
00:48:46,160 --> 00:48:48,280
habt eine riesen Datenbank mit 
Riesen vielen Daten die da 

1019
00:48:48,280 --> 00:48:50,560
einfließen von allen Systemen 
auf allen möglichen 

1020
00:48:50,560 --> 00:48:54,400
Abstraktionsebenen und jetzt wär
es ja schick vielleicht sogar 

1021
00:48:54,400 --> 00:48:57,400
mit KI. 
Zu sagen, OK, das hier ist der 

1022
00:48:57,400 --> 00:49:01,440
Normalzustand und jetzt will ich
quasi alarms kriegen, wenn sich 

1023
00:49:01,440 --> 00:49:04,640
diese Wolke von datenpunkten und
von Parametern und Prozessen, 

1024
00:49:04,640 --> 00:49:07,400
die sich normalerweise so die 
normalerweise so wabert, ich sag

1025
00:49:07,400 --> 00:49:10,080
es mal ganz grob ja, wenn die 
jetzt irgendwie anders wabert, 

1026
00:49:10,080 --> 00:49:13,240
ja, wenn ich irgendwie n Zacken 
klickt oder irgendwie so, das 

1027
00:49:13,240 --> 00:49:14,840
muss ich ja irgendwie erkennen 
können und dann müsste ich 

1028
00:49:14,840 --> 00:49:16,920
eigentlich so n Incident Report 
bekommen und schon mal. 

1029
00:49:16,920 --> 00:49:19,040
Also du müsstest wahrscheinlich 
irgendwie ne e Mail bekommen und

1030
00:49:19,040 --> 00:49:23,040
sagen, so, hier ist irgendwas 
anders als sonst, ja oder ergibt

1031
00:49:23,040 --> 00:49:24,880
sowas, habt ihr sowas? 
Wie kriegt ihr sowas mit? 

1032
00:49:25,680 --> 00:49:28,440
Es ist echt ne tolle. 
Frage und auch diese diese 

1033
00:49:28,440 --> 00:49:30,960
Beschreibung, wie man sich das 
naiv vorstellt, es ist ist sehr 

1034
00:49:30,960 --> 00:49:36,040
sehr gut und das ist n Pfad wo 
sehr viele Leute diesen Pfad 

1035
00:49:36,040 --> 00:49:39,120
runtergehen und extrem verbrannt
werden, weil es stellt sich 

1036
00:49:39,120 --> 00:49:42,840
raus, dass dieses System jedes 
IT System was hinreichend 

1037
00:49:42,840 --> 00:49:45,920
komplex ist, sehr instabil ist. 
Du hast am Tag irgendwie 100 

1038
00:49:45,920 --> 00:49:49,400
Deployments oder 1000 
deployments ja, aber auch schon 

1039
00:49:49,400 --> 00:49:51,360
bei einer kleineren Architektur,
da du hast ja irgendwie 

1040
00:49:51,360 --> 00:49:53,600
wenigstens ein Team, das 
verändert dieses System 

1041
00:49:53,600 --> 00:49:55,880
andauernd. 
Und dann hast du load pattern 

1042
00:49:55,880 --> 00:50:00,000
changes, dass du teilweise OK, 
du siehst einfach keine 

1043
00:50:00,000 --> 00:50:02,080
Requests, weil die Leute alle 
aufs Klo gegangen sind. 

1044
00:50:02,080 --> 00:50:05,400
Oder du siehst zehnmal so viele 
Requests, weil irgendwie gerade 

1045
00:50:05,400 --> 00:50:08,440
n Product Release war oder n 
Marketing push, wo irgendwie 

1046
00:50:08,440 --> 00:50:11,280
Leute viel gekommen sind. 
Das heißt du hast ne enorme 

1047
00:50:11,280 --> 00:50:15,760
Varianz in diesen Daten drin und
das ist für ne KI oder für n 

1048
00:50:15,760 --> 00:50:19,440
automatisiertes System ganz ganz
ganz schwer zu sagen ist das 

1049
00:50:19,840 --> 00:50:23,840
expected variance ist es auch 
wenn du errors hast. 

1050
00:50:24,160 --> 00:50:27,760
Das ist interessiert das 
überhaupt jemanden oder ist das 

1051
00:50:27,760 --> 00:50:31,640
brennst gerade und das diese 
Korrelation von OK du kriegst 

1052
00:50:31,640 --> 00:50:35,880
diese diesen Schwall an Daten 
und das The Business Care ist 

1053
00:50:35,880 --> 00:50:39,240
extrem schwer und was in aller 
Regel passiert, es funktioniert 

1054
00:50:39,240 --> 00:50:42,400
ganz OK, aber du hast dann ne 
false positive Rate von 

1055
00:50:42,400 --> 00:50:47,440
vielleicht auch nur 2% aber. 
Diese 2% auf ne sehr hohe Basis 

1056
00:50:47,440 --> 00:50:50,000
an quasi Requests oder Events 
die reinkommen. 

1057
00:50:50,240 --> 00:50:53,800
Die verhageln dir komplett die 
deine on Call rotations, weil du

1058
00:50:53,800 --> 00:50:56,800
ständig gefragt wirst. 
Jetzt ist nicht nur oh Scheiße, 

1059
00:50:56,800 --> 00:50:59,600
die teilzehn Datenbank macht gar
nichts, sondern es ist Hey guck 

1060
00:50:59,600 --> 00:51:01,960
mal, ich hab diese Anomalie 
gefunden, diese Daten sehen 

1061
00:51:01,960 --> 00:51:04,080
nicht so aus wie meine Baseline,
willst du nicht vielleicht mal 

1062
00:51:04,080 --> 00:51:06,960
gucken und du bist ich hab grad 
das Meeting und ich soll 

1063
00:51:06,960 --> 00:51:09,520
eigentlich hier was entwickeln 
und ja. 

1064
00:51:10,240 --> 00:51:12,800
Vielleicht machst du es dreimal 
und kannst aber nichts finden. 

1065
00:51:12,880 --> 00:51:15,080
Oder du machst es dann 
irgendwann gar nicht mehr, weil 

1066
00:51:15,080 --> 00:51:17,920
es dich einfach nur noch nervt. 
Und da sind eigentlich seit 10 

1067
00:51:17,920 --> 00:51:20,600
Jahren laufen in dieses Problem 
alle rein, wieviel Unternehmen 

1068
00:51:20,600 --> 00:51:22,720
die das alle probiert haben, es 
hat einfach nie funktioniert, 

1069
00:51:23,040 --> 00:51:26,200
vielleicht jetzt mit Large 
language models wir bessere 

1070
00:51:26,200 --> 00:51:29,040
Shots I don't know wir machen es
ganz anders. 

1071
00:51:30,160 --> 00:51:31,520
Jetzt kommt es. 
Jetzt bin ich gespannt. 

1072
00:51:32,400 --> 00:51:34,640
Genau. 
Also meine meine Philosophie 

1073
00:51:34,640 --> 00:51:36,920
oder eine andere Dynamik, die du
auch oft hast, ist OK. 

1074
00:51:36,920 --> 00:51:39,200
Du hattest n Incident und dann 
fragst du dich, na ja, welchen 

1075
00:51:39,200 --> 00:51:40,720
Alert musst du jetzt 
konfigurieren, dass du mit 

1076
00:51:40,720 --> 00:51:43,680
dieses Problem das nächste Mal 
detektierst läuft in dasselbe 

1077
00:51:43,680 --> 00:51:45,240
Phänomen rein. 
Auf einmal hast du ganz viele 

1078
00:51:45,240 --> 00:51:48,200
Sachen, das heißt, was wir 
eigentlich sagen, lass mal die 

1079
00:51:48,200 --> 00:51:52,080
Rechner Rechner sein, lass mal 
die errors Error sein wir wir 

1080
00:51:52,080 --> 00:51:56,440
kümmern uns gar nicht so drum ob
die ob die Datenbank sich gerade

1081
00:51:56,440 --> 00:51:59,120
in die Hosen scheißt oder ob die
Applikation gerade. 

1082
00:51:59,600 --> 00:52:02,560
Jede Menge Logs ausspuckt We 
Care. 

1083
00:52:03,040 --> 00:52:07,400
Ob die Nutzer happy sind, wir 
wir, wir kümmern uns drum können

1084
00:52:07,400 --> 00:52:10,720
die Nutzer die Homepage surfen, 
können die Nutzer einen Checkout

1085
00:52:10,720 --> 00:52:13,160
machen, können die Nutzer ihren 
Warenkorb benutzen, können die 

1086
00:52:13,160 --> 00:52:16,160
Nutzer ihre Adresse ändern das 
sind die Sachen, die wir gerne 

1087
00:52:16,160 --> 00:52:21,040
hätten, solange die Nutzer alles
machen können keine Alerts, kein

1088
00:52:21,200 --> 00:52:24,840
kein Grund sofort alles stehen 
und liegen zu lassen und zu 

1089
00:52:24,840 --> 00:52:26,800
sagen sagen zu OK müssen jetzt 
sein. 

1090
00:52:27,240 --> 00:52:29,880
Man kann vielleicht n Ticket 
aufgemacht werden oder da kann 

1091
00:52:29,880 --> 00:52:33,880
ne e Mail geschrieben werden an 
das Team die sagt Hey das sollte

1092
00:52:33,880 --> 00:52:36,640
man sich mal angucken, aber es 
sollte nicht sein. 

1093
00:52:36,640 --> 00:52:40,160
Alle stehen und liegen lassen 
sofort hier ran an den Speck und

1094
00:52:40,160 --> 00:52:43,680
die Technik die wir da verwenden
um dieses High Level alerting 

1095
00:52:43,680 --> 00:52:46,480
hinzukriegen, das sind SLOS da 
hattet ihr glaub ich auch vor 

1096
00:52:46,480 --> 00:52:49,560
vor kurzem mal ne Folge zu 
Service Level Objectives die 

1097
00:52:49,560 --> 00:52:53,760
sind bei uns sehr sehr stark von
der produktjourney geankert also

1098
00:52:53,760 --> 00:52:55,720
wir haben quasi die Frukmanager 
gefragt was sind denn die 

1099
00:52:55,720 --> 00:52:58,000
Funktionen die Zalando so hat? 
Und dann? 

1100
00:52:58,160 --> 00:53:00,560
Dann haben wir versucht, jedes 
einzelne Ding zu messen und 

1101
00:53:00,560 --> 00:53:03,560
meistens ist es einfach eine 
spezielle Query gegen diesen 

1102
00:53:03,560 --> 00:53:05,600
Datenstream von Traces, den wir 
gesehen haben. 

1103
00:53:05,600 --> 00:53:08,280
Es ist einfach OK, es ist dieser
Button oder in dieser 

1104
00:53:08,280 --> 00:53:10,840
Applikation muss genau diese 
Funktion aufgerufen werden und 

1105
00:53:10,880 --> 00:53:15,040
dann man will wissen was ist die
Errorrate von dieser Operation 

1106
00:53:15,520 --> 00:53:18,560
und so das High Level Alerting 
for Zalando funktioniert im 

1107
00:53:18,560 --> 00:53:22,360
Prinzip so, du hast so n Satz 
von vielleicht 102 100 SLOS die 

1108
00:53:22,360 --> 00:53:25,160
quasi diese User Journeys 
abcovern und wenn die alle grün 

1109
00:53:25,160 --> 00:53:26,640
sind. 
Da gibt es schon mal keinen 

1110
00:53:26,640 --> 00:53:28,640
Grund, Panik zu so, und das ist 
jetzt. 

1111
00:53:28,640 --> 00:53:31,320
Irgendwie quasi nen Bot, der ist
programmiert und zieht diese 

1112
00:53:31,320 --> 00:53:33,760
Requests durch und kriegt hier 
entsprechenden erwarteten 

1113
00:53:33,760 --> 00:53:35,920
Antworten n bestimmten 
Zeitfräser oder wie und das 

1114
00:53:36,080 --> 00:53:37,920
läuft die ganze Zeit oder wie 
stell ich mir das vor? 

1115
00:53:38,480 --> 00:53:40,080
Nee, es ist. 
Kein Bot, das ist der echte User

1116
00:53:40,080 --> 00:53:42,240
Traffic, das ist der echte 
Nutzertraffic, den Wir nehmen. 

1117
00:53:42,880 --> 00:53:45,800
Ah. 
OKOKOK jetzt hab ich OK das OK 

1118
00:53:45,800 --> 00:53:47,320
verstanden. 
Magst du quasi ob ich hab? 

1119
00:53:47,440 --> 00:53:48,560
Noch was anderes. 
Im Kopf. 

1120
00:53:48,560 --> 00:53:52,560
Man könnte ja auch sagen, ich, 
ich, ich, ich, ich programmiere 

1121
00:53:52,560 --> 00:53:55,280
einen Roboter user. 
Und dann kenn ich meine User 

1122
00:53:55,280 --> 00:53:58,480
Journeys und der klickt halt 
diese ganzen User Journeys 

1123
00:53:58,480 --> 00:54:01,360
durch, automatisiert, und zwar 
immer wieder ja und weil das der

1124
00:54:01,360 --> 00:54:04,080
Roboter User ist, hat er ne 
spezielle ID und der zahlt halt 

1125
00:54:04,080 --> 00:54:06,120
nix oder irgendsowas der darf 
das halt alles machen, aber der 

1126
00:54:06,120 --> 00:54:08,000
kriegt diese User Journey 
trotzdem jetzt stell. 

1127
00:54:08,000 --> 00:54:12,880
Dir vor paypal ist Broken für 
Nutzer in Spanien hast du nen 

1128
00:54:13,040 --> 00:54:16,400
Nutzer, der immer aus Spanien 
kommt und immer paypal 

1129
00:54:16,400 --> 00:54:18,560
auscheckt. 
Und du hast so kombinatorische 

1130
00:54:18,560 --> 00:54:20,320
Probleme. 
Du hast dann irgendwie 5 Feature

1131
00:54:20,320 --> 00:54:22,320
flags und verschiedene 
Nutzergruppen. 

1132
00:54:22,360 --> 00:54:25,200
Android war irgendwie Broken, in
gewisser Hinsicht musst du 

1133
00:54:25,200 --> 00:54:27,280
wieder NP komplett. 
Das Problem irgendwie gefühlt 

1134
00:54:27,280 --> 00:54:29,440
haben die die Kombinatory. 
Explodiert komplett. 

1135
00:54:29,600 --> 00:54:31,280
Du hast bei jedem Service 
irgendwie 3 verschiedene 

1136
00:54:31,280 --> 00:54:35,680
Varianten und im Vorhinein quasi
Roboter finden zu wollen die die

1137
00:54:35,760 --> 00:54:39,400
dynamisch genug sind es es 
funktioniert nicht. 

1138
00:54:39,560 --> 00:54:41,960
Du hast quasi Unit Testing was 
wenn du einen kleineren 

1139
00:54:41,960 --> 00:54:44,080
kombinatorischen Raum hast 
funktioniert. 

1140
00:54:44,720 --> 00:54:47,080
Und du hast natürlich an 
einzelnen Stellen noch n paar 

1141
00:54:47,080 --> 00:54:49,080
Probs. 
Also jetzt so was wie Red Reset 

1142
00:54:49,080 --> 00:54:50,720
Passwort wo du wenig Varianz 
hast. 

1143
00:54:50,880 --> 00:54:53,840
Das kannst du so proben, aber 
die Idee, dass du den gesamten 

1144
00:54:53,840 --> 00:54:57,520
Shop mit der ganzen Komplexität 
mit Robot Usern abcovert das das

1145
00:54:57,520 --> 00:54:59,960
funktioniert nicht und es wäre 
auch sehr sehr teuer wenn du es 

1146
00:54:59,960 --> 00:55:02,040
probieren würdest, weil du musst
diese ganzen Journeys ja alle 

1147
00:55:02,040 --> 00:55:05,520
konfigurieren, das heißt No 
hanging Fruit und auch sehr sehr

1148
00:55:05,520 --> 00:55:09,480
nah an der Business Relevanz ist
einfach observed the behavior of

1149
00:55:09,480 --> 00:55:11,920
the actual users ja du hast 
also. 

1150
00:55:11,920 --> 00:55:14,960
In jeder. 
User Story, die du so hast auf 

1151
00:55:14,960 --> 00:55:19,520
deiner Website oder in eurem 
Shop ein bestimmtes Key Element 

1152
00:55:19,520 --> 00:55:22,960
oder eine Key Event oder 
mehrere, vielleicht sogar die, 

1153
00:55:23,280 --> 00:55:27,280
wenn sie funktionieren, auf Grün
stehen und in dem Moment wohl 

1154
00:55:27,280 --> 00:55:30,160
ein User nicht in der Lage ist 
dazu das durchzuführen, sagst du

1155
00:55:30,400 --> 00:55:32,360
der kann. 
Nicht machen, was er eigentlich 

1156
00:55:32,360 --> 00:55:34,080
gerne möchte und dann wird es 
rot. 

1157
00:55:34,080 --> 00:55:37,120
Ja und dann kriegt er da Leute 
oder so und beim ersten aber 

1158
00:55:37,120 --> 00:55:38,680
auch nicht, vielleicht nicht die
Grundidee, die Grundidee. 

1159
00:55:38,680 --> 00:55:40,560
Ist wichtig, aber du aggregierst
natürlich. 

1160
00:55:40,560 --> 00:55:43,920
Du sagst irgendwie in der 
letzten Stunde haben mehr als 2%

1161
00:55:43,920 --> 00:55:47,160
der Nutzer n Problem gehabt, da 
müssen wir mal reingucken. 

1162
00:55:47,360 --> 00:55:49,720
Ja OK ist. 
Immer für uns n bisschen anderer

1163
00:55:49,720 --> 00:55:51,560
Scale. 
Ja ist immer spannend für euch 

1164
00:55:51,560 --> 00:55:54,280
ist das ja richtig Statistik sag
ich mal an der Stelle dann ja, 

1165
00:55:54,280 --> 00:55:56,080
das ist dann. 
Das Gesetz der großen Zahlen der

1166
00:55:56,080 --> 00:55:57,600
großen User, das ist auch total 
krass. 

1167
00:55:57,600 --> 00:56:00,080
Man kann sich irgendwie. 
Also selbst wenn du nen Cloud 

1168
00:56:00,160 --> 00:56:02,360
Anbieter bist und aber wenn 
seine Kunden alle aus 

1169
00:56:02,360 --> 00:56:04,240
Deutschland kommen, dann hast du
schon mal n ganz anderes 

1170
00:56:04,320 --> 00:56:06,480
reduziertes Problem als wenn die
halt dich auf dem Globus 

1171
00:56:06,480 --> 00:56:08,640
verteilen, weil das hatte ich 
auch gerade nicht im Kopf, das 

1172
00:56:08,640 --> 00:56:11,080
ist ja so, die Uhren ticken alle
anders, da stehen noch mal 

1173
00:56:11,080 --> 00:56:14,120
andere Datencenter, dann gibt es
Kabel die im Wasser liegen und 

1174
00:56:14,120 --> 00:56:17,920
so 1000 Sachen die der ganzen 
Komplexität eigentlich noch noch

1175
00:56:17,920 --> 00:56:20,360
den den Rest geben so ja da muss
man sich echt mal überlegen wie 

1176
00:56:20,360 --> 00:56:22,080
man es macht. 
Ja also ich ich. 

1177
00:56:22,080 --> 00:56:24,000
Glaube ganz ehrlich gesagt, 
dass. 

1178
00:56:24,480 --> 00:56:27,040
Diese Sicht, was macht denn, was
interessiert den Nutzer, dass 

1179
00:56:27,040 --> 00:56:29,680
das extrem vereinfacht, weil 
wenn du auf dieses auf wenn du 

1180
00:56:29,680 --> 00:56:32,400
auf dieses Problem Zalando soll 
reliable sein drauf guckst mit 

1181
00:56:32,400 --> 00:56:35,840
ich hab 10000 Rechner und hab 
1000 Applikationen die sich da 

1182
00:56:35,840 --> 00:56:39,360
ständig verändern du hast keine 
Chance da wird immer eine ganze 

1183
00:56:39,360 --> 00:56:42,240
Menge Broken sein und du bist 
quasi bei diesem Haufen hast 

1184
00:56:42,240 --> 00:56:44,960
ganz schwer haben rauszufinden 
was interessiert eigentlich 

1185
00:56:44,960 --> 00:56:47,040
gerade jemanden bei wo lohnt es 
sich zu investieren? 

1186
00:56:47,520 --> 00:56:50,080
Wenn du umgekehrt guckst, was 
ist die User Experience ist 

1187
00:56:50,080 --> 00:56:53,280
wirklich sehr UI driven was sind
die Funktionen, die High Level 

1188
00:56:53,280 --> 00:56:56,280
bereitgestellt werden müssen und
versuchst genau da anzusetzen 

1189
00:56:56,280 --> 00:56:58,880
mit deinen Messungen, 
idealerweise sogar im Browser 

1190
00:56:58,880 --> 00:57:03,120
oder nah an so nah am Nutzer wie
möglich und dann sicherstellst 

1191
00:57:03,120 --> 00:57:06,480
Hey, denn die Nutzer die haben 
keine großflächigen Probleme und

1192
00:57:06,480 --> 00:57:09,040
das ist die ist das der Gold 
Standard für Alerting. 

1193
00:57:09,040 --> 00:57:11,360
Ja wir haben natürlich unser 
Datenbank Team hat auch 

1194
00:57:11,360 --> 00:57:13,680
Datenbank Alerts ja wir wollen 
einfach nicht, dass die Customer

1195
00:57:13,680 --> 00:57:16,880
Datenbank Out of Memory läuft ja
das das sollen wir verhindern. 

1196
00:57:17,200 --> 00:57:21,360
Aber wenn wir mit Alerts einfach
anfangen, immer was ist wer sind

1197
00:57:21,360 --> 00:57:24,080
unsere Customer? 
Was sollen unsere Customer tun? 

1198
00:57:24,160 --> 00:57:25,920
Auch auf den verschiedenen 
Plattformenlayern? 

1199
00:57:25,920 --> 00:57:28,640
Ja, was ist von einem CDP System
was wenn du internes System 

1200
00:57:28,640 --> 00:57:29,840
hast? 
Was sind die Customer, was 

1201
00:57:29,840 --> 00:57:32,560
sollen die Customer tun und da 
sollten deine Alerts geankert 

1202
00:57:32,560 --> 00:57:36,480
sein, die sollten nie geankert 
sein oh OK ich weiß wenn Reddits

1203
00:57:36,480 --> 00:57:39,520
mehr als 50% Memory hat, dann 
krieg ich potenziellen Problem, 

1204
00:57:39,520 --> 00:57:42,560
dann mach ich mir n paging Alert
der mich sofort notified wenn 

1205
00:57:42,560 --> 00:57:46,720
Reddits über 50% Memory hat. 
Kein Business Impact ja bringt 

1206
00:57:46,720 --> 00:57:48,720
nichts, ich verstehe. 
Ihr dreht das, ihr dreht das 

1207
00:57:48,720 --> 00:57:51,280
die, die dreht die Kausalität da
quasi rum, das macht Sinn, ja. 

1208
00:57:52,320 --> 00:57:54,160
Passt es noch rein, wenn. 
Wir noch mal über dieses Open 

1209
00:57:54,160 --> 00:57:57,840
Telemetry sprechen oder diesen 
Open telemetry Standard. 

1210
00:57:57,920 --> 00:58:00,560
Du hattest das so mal vorhin so 
erwähnt, ja, den gibt es da 

1211
00:58:00,960 --> 00:58:02,440
genau das. 
Ist vielleicht auch was für die 

1212
00:58:02,440 --> 00:58:05,680
Nutzer oder die Zuhörer oder 
dich, lieber Zuhörer, den du das

1213
00:58:05,680 --> 00:58:08,480
gerade hörst, was du vielleicht 
auch selber mal ausprobieren 

1214
00:58:08,480 --> 00:58:11,720
möchtest. 
Open Telemetry ist tatsächlich 

1215
00:58:11,720 --> 00:58:14,640
NN Offener Standard, den man im 
Internet findet. 

1216
00:58:14,640 --> 00:58:18,080
Da gibt es Libraries für alle 
möglichen, alle möglichen 

1217
00:58:18,400 --> 00:58:22,240
Sprachen, es ist n Vendor 
Neutraler Standard, der uns auch

1218
00:58:22,240 --> 00:58:25,120
einfach als als Plattform dient,
als als Zalando, um auch 

1219
00:58:25,120 --> 00:58:27,920
Independence von speziellen 
Vendoren herzustellen, also 

1220
00:58:27,920 --> 00:58:30,640
eigentlich auch immer aus 
kommerzieller Sicht interessant 

1221
00:58:31,040 --> 00:58:33,480
und es gibt ne Menge Sachen zu 
entdecken, diese 

1222
00:58:33,480 --> 00:58:36,600
autoinstrumentation Libraries 
für alle möglichen, alle 

1223
00:58:36,600 --> 00:58:40,160
möglichen Telemetrie Typen und. 
Im homelap Kontext. 

1224
00:58:40,160 --> 00:58:43,080
Ich hab es ist on Ramp ist 
natürlich n bisschen, man muss 

1225
00:58:43,080 --> 00:58:44,960
sich da erst mal n bisschen 
reinfuchsen bis man das alles am

1226
00:58:44,960 --> 00:58:46,080
laufen hat. 
Man gibt da so ne 

1227
00:58:46,080 --> 00:58:49,520
Kollektorkomponente die man auch
lokal verwenden kann um zu 

1228
00:58:49,520 --> 00:58:51,840
verstehen wie sehen die Daten 
aus die da rausgeschrieben 

1229
00:58:51,840 --> 00:58:54,800
werden und so weiter aber wenn 
man das alles mal aufgesetzt 

1230
00:58:54,800 --> 00:58:57,800
hat, was tatsächlich richtig 
cool ist, ist so die 

1231
00:58:57,800 --> 00:59:01,760
Flexibilität die das bietet die 
Backends zu ändern. 

1232
00:59:01,920 --> 00:59:05,640
Also du kannst ja bei Graphana 
einen Demo Account machen. 

1233
00:59:05,640 --> 00:59:07,840
Du kannst bei Datadock einen 
Demo Account machen, du kannst 

1234
00:59:07,840 --> 00:59:10,360
bei Chronos 4 einen Demo Account
machen, du kannst bei der Zero 

1235
00:59:10,360 --> 00:59:13,520
und Demo Account machen und dann
kannst du die Daten einfach an 

1236
00:59:13,520 --> 00:59:16,400
alle schicken oder an 1 schicken
und dann woanders hinschicken, 

1237
00:59:16,720 --> 00:59:22,160
aber das ist irgendwie wirklich 
nur 22 Klicks fast ja also 2 

1238
00:59:22,160 --> 00:59:25,680
konfigurationslines die du in so
ein konfigurationsding droppst 

1239
00:59:25,680 --> 00:59:28,720
und dann bist du hast du deine 
ganzen Daten in ein anderes 

1240
00:59:28,720 --> 00:59:32,400
Backend umgezogen und. 
Das ist tatsächlich ziemlich 

1241
00:59:32,400 --> 00:59:34,400
sexy. 
Mit diesen Demo Accounts bin ich

1242
00:59:34,400 --> 00:59:38,280
auch im private Bereich gerade 
eher unterwegs als Self hosted 

1243
00:59:38,280 --> 00:59:42,440
Telemetry, irgendwie Prometheus 
und Loki und was weiß ich alles 

1244
00:59:42,440 --> 00:59:44,680
am Laufen zu halten und diese 
Tracing Datenbanken, das ist 

1245
00:59:44,680 --> 00:59:47,040
nicht so Joy Ful Time die man da
hat. 

1246
00:59:48,080 --> 00:59:50,720
Also insofern denke ich im 
kommerziellen Kontext ist man 

1247
00:59:50,720 --> 00:59:53,360
sowieso meistens auf diesen 
Vendor basierten Lösungen. 

1248
00:59:53,360 --> 00:59:55,880
Home Context kann es Sinn machen
mit diesen Demo Accounts zu 

1249
00:59:55,880 --> 00:59:59,760
arbeiten oder Small Pate 
Accounts und dann bietet. 

1250
00:59:59,840 --> 01:00:03,120
Open Tenemetry einfach ne sehr 
flexible Basis, wo man einfach 

1251
01:00:03,120 --> 01:00:06,280
die Collection komplett Open 
Source Vendor nutral hat und 

1252
01:00:06,280 --> 01:00:09,040
dann so n Central Data Hub hat, 
wo man auch Open Source 

1253
01:00:09,040 --> 01:00:12,040
Komponenten oder Vendor Back 
Komponenten einfach anschließen 

1254
01:00:12,040 --> 01:00:15,360
kann. 
Und ja Standard ist ne Community

1255
01:00:15,360 --> 01:00:19,600
die das macht seit ja 78 Jahren 
mittlerweile ursprünglich auch 

1256
01:00:19,600 --> 01:00:23,040
von von Google mitgegründet und 
wir hatten ja über viel über 

1257
01:00:23,040 --> 01:00:27,040
Distibuted Tracing gesprochen. 
Der Innovator von Distubuted 

1258
01:00:27,040 --> 01:00:29,720
Tracing ist der Ben Siegelmann. 
Der war damals bei Google, der 

1259
01:00:29,880 --> 01:00:32,720
hat dann diese Firma Light Step 
gegründet und der hat auch Open 

1260
01:00:32,720 --> 01:00:37,920
Telemetry mit quasi gefounded 
und hat dann quasi das ist quasi

1261
01:00:37,920 --> 01:00:42,160
das Go to Technologie, gerade um
auch dieses Distubuted Tracing 

1262
01:00:42,160 --> 01:00:46,160
zu machen, aber alle Telemetrie 
Typen sind sind supported, also 

1263
01:00:46,160 --> 01:00:49,920
heute moderne Telemetrie Stack 
ist eigentlich über um Open 

1264
01:00:49,920 --> 01:00:53,280
Telemetrie rum gebaut ja voll 
gut voll. 

1265
01:00:53,280 --> 01:00:54,880
Aktuell voll relevant auch für 
uns. 

1266
01:00:55,120 --> 01:00:57,040
Hatte ich so auch noch nicht auf
dem Zettel, guck ich mir an, 

1267
01:00:57,040 --> 01:00:59,280
muss man glaub ich mal schauen, 
packen wir in die Shownotes 

1268
01:00:59,280 --> 01:01:01,760
skirit. 
Was gibt es jetzt noch? 

1269
01:01:01,760 --> 01:01:06,000
Was wir noch zu observability 
Distributed Tracing Metriken 

1270
01:01:06,000 --> 01:01:09,440
logs sagen müssen, was 
vielleicht noch gesagt werden 

1271
01:01:09,440 --> 01:01:11,560
muss, es gibt schon mal ganz 
viel, aber vielleicht haben wir 

1272
01:01:11,560 --> 01:01:14,240
noch irgendwas nicht gecovert, 
was du gerne covern wolltest. 

1273
01:01:14,720 --> 01:01:16,480
Ja, ich würd vielleicht zum. 
Abschluss einfach sagen. 

1274
01:01:16,480 --> 01:01:20,000
Es ist so dieses Curiosity Thema
was mich bei Observability auch 

1275
01:01:20,000 --> 01:01:22,480
hält ist wirklich diese 
Kernfrage, was macht mein 

1276
01:01:22,480 --> 01:01:25,280
Rechner eigentlich? 
Was wie kann ich das rausfinden?

1277
01:01:25,600 --> 01:01:27,920
Und da haben wir natürlich in 
verschiedenen Kontexten 

1278
01:01:27,920 --> 01:01:31,000
verschiedensten Tools, die uns 
das quasi näherbringen oder die 

1279
01:01:31,000 --> 01:01:33,680
uns das erlauben, aber es ist 
einfach n relevantes und 

1280
01:01:33,680 --> 01:01:37,280
spannendes Problem und da gibt 
es total für die Historie auch 

1281
01:01:37,280 --> 01:01:41,680
noch damals hörtest du diesen 
Raumschiff Enterprise Rekorder 

1282
01:01:41,760 --> 01:01:45,200
Analogie Solaris damals hatte so
Technologien mit denen man da 

1283
01:01:45,200 --> 01:01:47,360
noch viel besser reingucken 
konnte in die Prozesse die wir 

1284
01:01:47,360 --> 01:01:50,080
auf Linux vielleicht jetzt so 
langsam auch bekommen. 

1285
01:01:50,400 --> 01:01:52,880
Aber ich rechne damit, dass wir 
so in Richtung Continuous 

1286
01:01:52,880 --> 01:01:55,360
Profiling, Dynamic 
Instrumentation noch ne Menge 

1287
01:01:55,360 --> 01:01:59,440
sehen und das hat man ja in 
allen Kontexten, ja, sei es 

1288
01:01:59,440 --> 01:02:02,720
irgendwie Web, sei es embedded, 
sei es Enterprise, sei es 

1289
01:02:02,720 --> 01:02:05,200
privat, sei es homelab, man 
läuft immer in diese Probleme 

1290
01:02:05,200 --> 01:02:11,120
rein und ich freue mich auf so n
Linux MCP, wo ich nachher JTBT 

1291
01:02:11,120 --> 01:02:13,520
einfach fragen kann, hey, was 
macht mein Rechner einfach, ja. 

1292
01:02:15,040 --> 01:02:17,920
Und das für mich ist da noch ne 
Menge drin was Observability 

1293
01:02:17,920 --> 01:02:20,720
angeht, dass wir einfach nicht 
nur gut werden in unseren 

1294
01:02:20,720 --> 01:02:23,600
Rechnern, sagen was sie tun 
sollen, sondern auch gut werden 

1295
01:02:23,600 --> 01:02:27,040
in verstehen was macht das Ding 
eigentlich und was was sieht das

1296
01:02:27,120 --> 01:02:29,840
ja cool. 
OK dann sag ich. 

1297
01:02:30,480 --> 01:02:32,640
Mal vielen dank, du hast den 
Bogen jetzt noch mal geschlossen

1298
01:02:32,640 --> 01:02:34,920
zum zum Eingang. 
Ja, hast du auch gesagt, es geht

1299
01:02:34,920 --> 01:02:38,880
drum zu verstehen was macht der 
Rechner ja nicht, wir sagen dem 

1300
01:02:38,880 --> 01:02:40,480
Rechner was zu tun ist, sondern 
wir wollen wissen was er 

1301
01:02:40,480 --> 01:02:43,520
eigentlich tut und warum. 
Und ja, von meiner Seite vielen 

1302
01:02:43,520 --> 01:02:45,360
herzlichen Dank. 
War richtig cool, Spaß gemacht, 

1303
01:02:45,360 --> 01:02:48,080
viel gelernt und hoffentlich bis
bald noch mal. 

1304
01:02:48,320 --> 01:02:49,680
Danke dir. 
Ja vielen Dank. 

1305
01:02:49,680 --> 01:02:52,160
Für die Einladung sehr gerne ja,
von meiner. 

1306
01:02:52,160 --> 01:02:53,680
Seite vielen dank Herrn, ich hab
viel gelernt. 

1307
01:02:53,680 --> 01:02:56,760
Die Folge war super spannend, 
Deep Teig diesmal n bisschen 

1308
01:02:56,760 --> 01:03:00,240
schnack gut alles klar Tschüss 
aus Hamburg ciao ciao. 

1309
01:03:01,040 --> 01:03:03,440
Einfach komplex. 
Wird produziert und präsentiert 

1310
01:03:03,440 --> 01:03:06,000
von Heisenware. 
Heisenware ist deine Low Code 

1311
01:03:06,000 --> 01:03:09,520
Plattform zur Erstellung und zum
Betrieb interaktiver Apps rund 

1312
01:03:09,520 --> 01:03:11,520
um den Shopfloor. 
Starte noch heute deinen Free 

1313
01:03:11,520 --> 01:03:15,280
Trial unterheisenware.com 
einfach minus komplex.