Technisches Monitoring und Alerting
Wir diskutieren in dieser Podcast-Folge über die 24/7-Verfügbarkeit von Diensten sowie die Bedeutung von Monitoring und Alerting. Sie erklären, dass Unternehmen wie Softwareagenturen sicherstellen müssen, dass die von ihnen entwickelten und betreuten Anwendungen immer verfügbar sind, um wirtschaftliche Verluste und Reputationsschäden zu vermeiden. Sie gehen auf die grundlegenden Prinzipien von Monitoring (Systemüberwachung) und Alerting (Benachrichtigungen bei Problemen) ein und heben hervor, dass proaktive Fehlererkennung und -behebung wichtig sind, um die Ausfallzeiten zu minimieren.
Besonderes Augenmerk legen sie auf die Notwendigkeit einer engen Verzahnung von Entwicklung und Betrieb, um Fehler frühzeitig zu erkennen und zu beheben. Sie erläutern zudem, wie moderne Open-Source-Tools wie Uptime Kuma und NetData für Infrastrukturüberwachung und Cronmonitoring eingesetzt werden, um reibungslose Abläufe zu gewährleisten. Schließlich betonen sie die Wichtigkeit einer automatisierten Überwachung und präventiven Wartung, um langfristig Stabilität und Zuverlässigkeit der Systeme sicherzustellen.
Diese Themen haben wir in der Folge angesprochen:
Wir freuen uns auf eure Erfahrungen und Gedanken zum Thema dieser Folge:
Sebastian auf LinkedIn: Sebastian Kurfürst
Tobias auf LinkedIn: Tobias Gruber
Sandstorm auf Instagram: @sandstormmedia | LinkedIn: Sandstorm
Oder auch per Mail an kontakt@sandstorm.de
Das Sandpapier ist der regelmäßig unregelmäßige Podcast der Sandstorm Media GmbH. Wir erzählen aus unserem Alltag, was wir versuchen, anders zu machen und welchen Herausforderungen und Experimenten wir uns auf unserem Weg stellen.
Transkript
Tobias
So, jetzt sehen wir Ausschläge, wenn ich bei mir reinspreche. Ich sehe auch Ausschläge bei dir. Ich kann bestätigen, dass es gibt Schläge. Ich drehe mir noch mal fast voll auf.
Sebastian
So, und jetzt sehen wir, bei mir sehe ich keine Ausschläge, wenn ich bei mir anspreche, aber siehst du welche, ist die Frage. Okay, das ist etwas verwirrend, aber ja, ist ja immer so. Sehr gut.
Tobias
Und dann sehe ich immer noch Ausschläge, ja. Das gibt sogar eine Prozentanzeige. Bei mir gibt es das nicht. 95, 95. Viel Spaß geben. Was machen wir denn eigentlich? Wir machen Sandpapier.
Sebastian
Ich habe hier so noch über dem letzten Strich sozusagen. Also 89% sagt er bei mir, wenn ich drüber habe. Ja. Da passt das schon. Ich rede ja eben lauter. Ich rede ja viel lauter als du insofern. Geh näher ans Mikro ran.
Tobias
regelmäßig, unregelmäßiger Podcast mit Themenherausforderungen. Ach so, hier Intro wollte ich mit Katharina checken, ob wir das weiter verwenden dürfen. Katharina checken. Zu Herausforderungen, Experimente aus unserem Alltag als Softwareunternehmen.
Sebastian
Reding ist ein cooles Ding.
Tobias
Heute eine Folge zum Thema, das stimmt noch nicht.
Sebastian
Wie kriege ich mit, dass es kaputt ist und was muss ich tun, damit es wieder ganz wird?
Tobias
24.7, Verfügbarkeit von Diensten, Monitoring und Alerting. Gespräch Sebastian und Tobias. Das macht das Thema gerade für dich aktuell, für dich, für mich, für alle. Ich würde ein kleines Intro mit dem Thema 24.7 machen und dann kommen wir in die Begriffe rein. Okay.
Sebastian
Herzlich willkommen!
Tobias
Herzlich willkommen zu einer neuen Folge vom Sandpapier, dem regelmäßig, unregelmäßig erscheinenden Podcast von Sandstorm, wo wir über Themen, Herausforderungen und Experimente aus unserem Alltag als Softwareunternehmen reden. Heute haben wir eine Folge für euch zum Thema 24-7-Verfügbarkeit von Diensten vorbereitet.
Tobias
und wollen heute konkret über die Themen Monitoring und Alerting sprechen. Wir, das sind heute der Sebastian. Schön, dass du wieder mit dabei bist. Und euer Host, das bin ich Tobias.
Sebastian
Ja, das Thema 24-7, Verfügbarkeit von Diensten.
Tobias
Ja, das Thema 24-7, Verfügbarkeit von Diensten. Wir sind ja als Softwareagentur, als Softwareunternehmen immer wieder in Kundenprojekten unterwegs. Und diese Kundenprojekte haben Anforderungen, was die Verfügbarkeit ihrer Dienste und Anwendungen angeht, die wir für unsere Kunden entwickeln und teilweise eben auch betreiben.
Sebastian
Es sind ja als Software-Agentur, als Software-Unternehmen immer wieder in Kundenprojekten unterwegs. Und diese Kundenprojekte haben Anforderungen, dass die Verfügbarkeit über Dienst- und Anwendungen angeht, die wir von Kunden entwickeln und teilweise auch betreiben. Und das Thema für 24 Stunden am Tag, sieben Tage pro Woche, kommt immer mal wieder auf als Beforderung.
Tobias
Und das Thema 24-7, für 24 Stunden am Tag, sieben Tage die Woche, kommt immer mal wieder auf als Anforderung. Und als Erweiterung davon am besten noch mal 365, also 365 Tage im Jahr. Ja, und heute haben wir uns die beiden Bereiche Monitoring und Alerting rausgepickt. Es gibt da in dem Bereich Verfügbarkeit von Diensten noch viele andere Sachen, machen wir bestimmt auch noch eine weitere Folge zu.
Sebastian
als Erweiterung der Flüchtlinge. Also 360 Tage im Jahr. Ja, die beiden Bereiche haben ich vorhin zu der Wörtung rausgelegt. Das gibt da eine Bereiche, wo Flüchtlinge nicht noch viel anderes ankommen, sondern auch eine weitere Flüchtlinge. So was. Am besten wir steigen da ein mit der Frage, was sind eigentlich die beiden Begriffe?
Tobias
Sebastian, am besten wir steigen mal ein mit der Frage, was sind eigentlich die beiden Begriffe? Wir lassen uns mal dort einsteigen. Wie unterscheidest du Monitoring und Alerting? Genau, also Monitoring ist erstmal die Überwachung, die englische Begriffe Überwachung. Da geht es darum, Systeme, Dinge ganz allgemein gesagt zu überwachen.
Sebastian
Genau, also Monitoring ist erstmal die Überwachung, also das englische Begriff Überwachung. Und da geht es darum, Systeme, Dienste, Dinge ganz allgemein gesagt zu überwachen.
Sebastian
So eine Überwachung kann man sich vorstellen, da kommt am Ende eine Ampel raus, rot, gelb oder grün, ganz platt gesagt. Und jetzt muss man das auch, damit man dann weiß, aha, ich habe ein Problem zum Beispiel, muss ich davon mitbekommen, wenn zum Beispiel die Ampel auf rot springt. Und genau das ist Detail Alerting, da geht es also darum, wenn ein Problem da ist, die richtigen Personen rechtzeitig zu informieren, damit die Person dann aktiv werden kann.
Tobias
So eine Überwachung kann man sich vorstellen, da kommt am Ende eine Ampel aus, rot, gelb oder grün, ganz platt gesagt. Und jetzt muss man das noch, damit man dann weiß, ich habe ein Problem zum Beispiel, muss ich davon mitbekommen, wenn zum Beispiel die Ampel auf rot springt. Und genau das ist die kleine Lerting, da geht es also darum, wenn ein Problem da ist, die richtigen Personen rechtzeitig zu informieren, damit die Personen aktiv werden.
Tobias
Also wenn wir es übersetzen, würden die englischen Begriffe Monitoring und Alerting auf Deutsch vielleicht Überwachung und Benachrichtigung? Ja. Okay. Jetzt ist es ja kein neues Thema in der Softwareentwicklung, im Betrieb von Software oder auch von Server-Systemen und auch keines, was wir uns ausgedacht haben, sondern die Thematik ist so alt wie wahrscheinlich die Informationstechnologie insgesamt. Absolut genau, so alt hält sozusagen. Man dienste Geräte, die nicht nur just for fun sind,
Sebastian
Ja. Jetzt ist es ja kein neues Thema der Softwareentwicklung im Betrieb von Software und auch von Servo-Systemen. Und wir würden es auch nicht ausgedacht haben.
Sebastian
Absolut, genau. Sobald man Dienste gebaut hat, die nicht nur just for fun sind, sondern wo sich Leute darauf verlassen wollten oder wussten, dass die da sind. Seitdem ist das ein Thema auf jeden Fall. Das heißt, wir haben hier schon mal... Wissen das Kriminalität? Wissen wir eigentlich fest, welche Verfügbarkeitsanforderungen an meine Tüfte ich so habe?
Tobias
dass sich Leute darauf verlassen würden oder wussten, dass sie da sind. Seitdem ist das ein Thema. Das heißt, wir haben hier schon mal einen Themenbereich, den wir heute ausklammern, nämlich das Thema Business-Kritikalität. Also wie lege ich denn eigentlich fest, welche Verfügbarkeitsanforderungen an meine Dienste ich so habe als Unternehmen? Wir haben aber
Sebastian
Wir haben aber trotzdem die Ansorgung von Kunden, die sagen, hey, ihr betreibt hier für uns zum Beispiel einen Onlineshop und über diesen Onlineshop läuft mein Umsatz und, nach verziehbarer Weile, dann auch das Interesse, dass der Shop online verfügbar ist. Und das am besten immer, weil wenn der Shop nicht da ist, steht immer im Raum, dass kein Umsatz über diesen Shop laufen kann. So und ich glaube,
Tobias
Trotzdem ja die Anforderungen von Kunden, die sagen, hey, ihr betreibt hier für uns zum Beispiel einen Online-Shop und über diesen Online-Shop läuft mein Umsatz und nachvollziehbare Weile hat ein Kunde dann auch das Interesse, dass der Shop online ist und verfügbar ist. Und das am besten immer, weil wenn der Shop nicht da ist, steht immer im Raum, dass kein Umsatz über diesen Shop laufen kann. So, und ich glaube in ganz
Tobias
ganz typisches Szenario, was dann existiert ist. Auf der einen Seite werden sogenannte Service Level Agreements ersprochen und vereinbart und verabredet. Also die Frage,
Sebastian
Ganz typisches Szenario, was dann existiert ist, auf der einen Seite werden sogenannte Service-Levels versprochen und vereinbart und nachgedacht. Also die Frage, Service-Level, wie verfügbar soll ein Dienst denn überhaupt sein? Das ist, denke ich, auch schon in der Branche sehr etabliert, dass es keine hundertprozentige Verfügbarkeit geben kann. Das ist etwas sehr, sehr Schwieriges, was diese Projekte 99 Grad tun wollen.
Tobias
Service Level, wie verfügbar soll ein Dienst denn überhaupt sein, weil das ist nämlich auch schon in der Branche sehr etabliert, dass es keine hundertprozentige Verfügbarkeit geben kann. Das ist was sehr, sehr Schwieriges. Es gibt diese berühmten 99,9 Prozent Verfügbarkeit, die sich manchmal gewünscht werden, was, wenn man es umrechnet, dann, ich glaube, ein paar Minuten Ausfall pro Monat oder so sind.
Tobias
schon wahnsinnig viel. Und auf der anderen Seite zu diesen Service Level Agreements gehört noch der Teil, wenn was ausgefallen ist, wie schnell man dann reagiert und auch die Störungen behoben am Ende des Tages. So, und ganz klassisches Thema, was damit einhergeht, ist das Thema Rufbereitschaft. Ich glaube, das ist auch was, was bei uns immer mal wieder vorbeikommt, weil eben die Kunden sagen, hey, unser Dienst ist auch wichtig und hat vielleicht seine Hauptlast am Wochenende, gerade bei so einem Online-Shop.
Sebastian
schon wahnsinnig viel. Und auf der anderen Seite zu den Service Level Agreements, wie gesagt, der Teil, wenn wir es auswählen, wie schnell er dann reagiert und auch die Störung überhaupt am Ende des Tages. So, und ganz klassisch zu finden, was damit einhergeht, ist die Berufbereitschaft. Ich glaube, das ist auch das, was uns nochmal wieder vorbeikommt, wenn wir eben die Kunden sagen, hey, unser Dienst ist doch richtig und hat vielleicht seinen Hauptlast,
Tobias
kann das ja durchaus sein, dass viel Online-Shopping am Wochenende passiert, wenn die Leute eben nicht selber im Büro sind oder auf Arbeit sind. Genau, und wir hatten, ich meine, so circa vor einem Jahr, die große Situation, wir haben einen großen Online-Shop bei uns relaunched und dann stand eben die Frage im Raum, okay, wir machen hier eine riesengroße Umstellung, wir wollen sicherstellen, dass alles glatt läuft.
Sebastian
Genau, und wir hatten, ich meine, so von einem Jahr an, so eine große Situation, wir haben eine große Verwaltungsgültigkeit, und wir wollten die Frage machen, wir machen eine riesengroße Umstellung, wir wollen sicherstellen, dass alles glattläuft. Und dann sind wir direkt schon im Bild hier drin. Wie sehen wir denn mit, ob alles glattläuft, was heißt denn das, und wenn es nicht glattläuft, ja, wie kommen wir zu dem Punkt, dass wir was tun können.
Tobias
Und dann sind wir direkt schon in den Themen drin. Monitoring und Alert. Wie kriegen wir denn mit, ob alles glatt läuft? Was heißt denn das? Und wenn es nicht glatt läuft, ja, wie kommen wir zu dem Punkt, dass wir was tun können? Genau. Und dann sind wir schon mitten im Thema. Wir sind bei der zeitlichen Komponente. Wann tritt denn Störungen auf? Was ist denn da so typisch bei uns? Genau.
Sebastian
Genau, dann sind wir schon mit dem Thema. Ist das jetzt mehr als ein Kompliment, oder wann tritt denn die Störungen auf? Was ist denn da so typisch für uns? Genau, also da kann man eigentlich, also die passieren immer plötzlich, so wirken sie zumindest. Also ich sag mal, von jetzt auf gleich ist das System offline beispielsweise, also nicht mehr verfügbar. Es ist aber so, dass wenn man sich diese Fehler dann anguckt im Detail, gibt es quasi zwei Arten von Fehlern in dem einen Szenario.
Tobias
Es ist aber so, dass, wenn man sich diese Fehler dann anguckt, gibt es quasi zwei Arten von Fehlern der Art. In dem einen Szenario passiert, gibt es eine Vorwarnzeit, also da gibt es quasi Indikatoren, woran man vorher hätte merken können, dass das bald passiert, also der beste Beispiel zum Beispiel die Festplatte befolgt.
Sebastian
passiert, gibt es eine Vorwarnzeit, also da gibt es quasi Indikatoren, woran man vorher hätte merken können, dass das bald passiert. Also das beste Beispiel, zum Beispiel die Festplatte wird voll. Ja, in irgendeinem Zeitpunkt ist die Platte 100% voll, dann kann nichts mehr geschrieben werden und dann ist typischerweise auch der Dienst offline. Allerdings kann ich natürlich über einen längeren Zeitpunkt schon feststellen, dass der Füllstand sich sozusagen langsam erhöht und damit kann ich sogar eigentlich im Vorhinein auch ziemlich genau sagen, okay, naja, wenn ich jetzt so weitermache, dann ist in drei Tagen halb zig, dann ist die Platte voll.
Tobias
In irgendeinem Zeitpunkt ist die Platte 100% voll, da kann nichts Schlimmes entnehren oder ist typischerweise auf der Dienst-Offline. Allerdings kann ich natürlich über ein längerer Zeitpunkt schon feststellen, dass der Frühstand sich sozusagen langsam erhöht und damit kann ich eigentlich im Vorjahr noch ziemlich genau sagen, okay, naja, eigentlich jetzt so weitermachen, dann ist in drei Tagen ein Halbzirk, dann ist die Platte voll, dann werde ich das Problem haben.
Sebastian
Dann werde ich das Problem haben. Und andere Probleme, andere Szenarien, da kann ich das halt nicht feststellen. Da ändere ich, also da passiert das auch plötzlich, aber da ändere ich typischerweise auch irgendwas im System zu diesem Zeitpunkt oder ungefähr um diesen Zeitpunkt. Also das heißt, das Typischste, was wir machen ist, wir installieren neue Softwareversionen, weil wir quasi die Kunden irgendwelche Änderungen machen wollen.
Tobias
Und andere Probleme, andere Szenarien, da kann ich das nicht stellen. Da ändere ich, das passiert auch plötzlich, aber da ändere ich auch irgendwas im System zu diesem Zeitpunkt. Das heißt, das Typischste, was wir machen, ist, wir installieren neue Softwareversionen, weil wir die Kunden irgendwelche Änderungen machen wollen. Und das heißt, immer, wenn wir ein neues Deployment, als es bei uns ist,
Sebastian
Und das heißt, immer, wenn wir ein neues Deployment, heißt das bei uns, also eine neue Software ausspielen, eine neue Version der Webseite online schalten, das ist zwar komplett automatisiert, aber natürlich gibt es durch jede Veränderung auch ein gewisses Risiko, dass was schief geht. Und das merkt man dann natürlich auch im Fall im Monitoring und dass man da aktiv werden muss. Jetzt hast du gerade schon angefragt, was ist das für ein Risiko? Wir reden ja hier von einem Betriebsrisiko
Tobias
in der Organisation der Webseite online schreiben. Das ist zwar komplett automatisiert, aber natürlich gibt es durch jede Veränderung ein gewisses Risiko, dass etwas schiefgeht. Und das merkt man dann natürlich auch im Falle.
Tobias
Jetzt hast du gerade ein schönes Wort angesprochen, das will ich mal aufgreifen. Risiko. Wir reden ja hier von einem Betriebsrisiko und einem Unternehmensrisiko. Wenn, ein Beispiel von vorhin, wenn der Online-Shop über den mein Umsatz läuft, wenn der ausfällt, dann habe ich ein Risiko für mein Unternehmen.
Sebastian
Wir haben es hier mit Systemen zu tun, wo ich ein Risiko-Manage-Standard
Tobias
Wir haben es vorhin schon gesagt, es gibt keine hundertprozentige Sicherheit. Das heißt, wir haben es hier mit einem System zu tun, wo ich ein Risikomanagement machen muss. Das heißt, ich muss mir angucken, welche Risiken können denn eintreten und wie möchte ich mit denen umgehen. Manche Risiken muss ich akzeptieren, andere möchte ich mitigieren, also möchte ich Maßnahmen ergreifen, um die zu verhindern. Und auf andere wiederum möchte ich schnell reagieren können, weil ich sage, die treten so selten ein, aber wenn sie eintreten, kann ich reagieren.
Sebastian
um die zu verhindern und andere wiederum richtig schnell reagieren können.
Tobias
Ich finde das ein wichtiger Punkt, es geht um die Kommunikierung, weil das ist eigentlich häufig das erste, was wir überlegen müssen, ist, wenn man natürlich überfragen soll, dann soll es am liebsten immer um einen zu lernen, das ist völlig nachvollziehbar, den Wunsch haben wir natürlich genauso als der Dienstleister, aber es ist
Sebastian
Ich finde das ein wichtiger Punkt. Es geht um Risikomanagement, nicht zwangsläufig um Risikominimierung. Weil das ist eigentlich häufig das erste, worüber wir reden müssen, ist, wenn man natürlich die Kunden fragt, dann sagen die natürlich, naja, es sollte am liebsten immer online sein. Und das ist völlig nachvollziehbar. Diesen Wunsch haben wir natürlich genauso als der Dienstleister. Aber es ist halt so, dass dieses Szenario halt einfach mit extremsten Kosten verbunden ist. Wenn ich halt wirklich die aller, allerletzten Risiken
Sebastian
rausnehme und Kosten im Betrieb der Infrastruktur, aber auch Kosten, also Aufwände, die entstehen, wenn man Änderungen nimmt, also was ja dann auch Kosten sozusagen umgelegt sind.
Tobias
Ich glaube, auch das im Detail machen wir in einer separaten Folge, wie man sozusagen die Systemarchitektur aufbaut, um sowas zu unterstützen und was dann eben auch die Vor- und Nachteile davon sind.
Tobias
Und jetzt waren wir ja bei den Risiken. Jetzt sind wir gerade eingestiegen. Okay, wir müssen uns verschiedene Risiken anschauen. Und du hattest vor uns gesagt, auch wenn eine Änderung des Status, also wenn die Ampel beispielsweise umspringt, weil mein Dienst plötzlich nicht mehr verfügbar ist, wenn die plötzlich ist, möchte ich das mitbekommen. Ja, absolut. Also der Bürgermeister ist eigentlich nicht mitbekommen, sondern der Kunde ist mitbekommen. Oder sein Kunde.
Sebastian
Auch wenn eine Änderung des Status, weil man Dienstplätze nicht mehr verfügbar ist, möchte ich das mitbekommen. Ja, absolut. Also der Worst Case ist eigentlich nicht wir bekommen das mit, sondern der Kunde bekommt das an unserer Stelle mit oder sein Kunde bekommt es mit. Also jetzt in unserem Fall, wir haben einen Kunden, das ist der betragene Online-Shop, verkauft ihre oder seine Produkte darüber und deren Endverbraucher
Tobias
und verkauft es immer unter seiner Runde darüber. Wer dann anruft und sagt, hey, ich kann was bestellen, aber die Seite ist krank und klein. Das ist natürlich für die Firma. Und für uns natürlich genauso. Wenn jetzt sozusagen dann unsere Kunden anruft und sagt,
Sebastian
würde dann anrufen und sagen, hey, ich würde gern was bestellen wollen, aber die Seite ist gerade offline. Das ist natürlich für die Firma, für das Unternehmen ein riesen Reputationsverlust, wenn das häufiger vorkommt. Und für uns natürlich genauso im übertragenden Sinn, wenn jetzt sozusagen dann unser Kunde, unsere Kundin anruft und sagt, hey, der Server ist gerade offline, der Shop ist offline, was habt ihr gerade gemacht? Und wir so, oh, keine Ahnung. Das wollen wir natürlich absolut vermeiden. Deshalb ist für uns die
Tobias
Das ist für uns die Basislevel des permanentes Monitoring. Das heißt, wir kontrollieren einfach regelmäßig automatisiert, ist das System aus Weltgründensicht verfügbar. Und das Ziel dafür ist vor allem, dass wir vor dem Kunden merken,
Sebastian
Basislevel ist permanentes Monitoring. Das heißt, wir kontrollieren einfach regelmäßig automatisiert, ist das System aus Endkundensicht verfügbar. Wir nennen das Availability oder Uptime Monitoring. Und das Ziel dafür ist vor allem, dass wir vor dem Kunden merken, dass was einem System falsch ist, dass ein Problem da ist. Und damit können wir natürlich auch idealerweise Probleme schon beheben, bevor der Kunde überhaupt es merkt, zum Beispiel.
Tobias
Das möchte ich nochmal betonen, was du gerade gesagt hast. Den Fall, den wir vermeiden wollen, ist, dass die Endnutzerinnen eines Dienstes bemerken als Erste, dass der nicht verfügbar ist und dann so eine Kette losgeht, bis überhaupt bei uns als Betreiber beispielsweise die Information ankommt und wir reagieren können, weil dann vergeht schon mal sehr viel Zeit und diese Reportationsverlustkette sozusagen ist aufgemacht,
Sebastian
Ich möchte nochmal betonen, was du gerade gesagt hast, dass dieses... Den Fall, den wir vermeiden wollen, ist, dass der Endnutzer, die Endnutzerinnen eines Dienstes bemerkt, als erstes, dass er nicht verfügbar ist und dann so eine Kette losgeht, ist überhaupt für uns als Betreiber, beispielsweise, die Endnutzerin an, kommt und wir reagieren können, weil dann geht schon mal sehr viel Zeit um diese Reproduktions- benutzte Kette, sozusagen, ist aufgemacht, sondern, dass er
Tobias
Das Availability Monitoring, also das Verfügbarkeits Monitoring, was wir einsetzen, soll genau diese Kette umdrehen, dass wir die Ersten sind, die bemerken, wenn ein Dienst nicht zur Verfügung steht. Und darin sehen wir dann direkt schon wieder beide Komponenten. Monitoring, also die Überwachung, ich muss es mitbekommen, und das Alerting, die Benachrichtigung. Haben wir das durchgehend im Einsatz?
Sebastian
Soll genau diese Kette umdrehen, dass wir die Ersten sind, die bemerkt, wenn der Dienst nicht zur Verfügung steht. Und dadurch sehen wir dann direkt, dass wir beide Komponenten, also die Überwachung mitbekommen und das Alerting, die Nachrichtigung.
Sebastian
Ja, genau. Das nutzen wir tatsächlich in allen Projekten. Egal, ob wir jetzt einen Service-Vertrag haben oder nicht mit unseren Kunden. Sondern das machen wir einfach ganz normal. Das ist Teil unserer Project-Checkliste, unserer Goal-Life-Checkliste. Das heißt, alle Projekte werden einfach von uns gemonitert. Auch völlig egal, ob wir den Server zum Beispiel bereitstellen oder nicht. Weil wir wollen trotzdem gerne wissen, selbst wenn unsere Software auf einem Kundensystem läuft, das haben wir manchmal in ganz großen Instanzen,
Tobias
Das heißt, alle Projekte werden von uns gemolitert. Auch völlig egal, ob wir dafür den Server zum Beispiel freistellen oder nicht. Wir wollen trotzdem gerne wissen, selbst wenn unsere Software auf einem Kundensystem läuft.
Sebastian
bei großen Kunden, dass wir sozusagen die Software in den Paket packen zum Kunden geben und der installiert die für uns komplett und betreibt die auch komplett für uns. Aber trotzdem möchten wir natürlich wissen, wie gut oder schlecht verhält sich unsere Software, damit wir halt auch mit den Kunden proaktiv in den Dialog kommen können, zum Beispiel, wenn es ein Problem gab, ob wir da was verbessern sollten oder auch nicht. Und was auch interessant ist daran ist,
Sebastian
Wenn man sich anguckt, die Last auf einem System ist ja nicht gleich verteilt. Also wenn wir in Europa zum Beispiel sind, dann gehen wir alle ungefähr zu einer ähnlichen Zeit plus minus ins Bett und stehen zu einer ähnlichen Zeit auf. Also das heißt, nachts um drei wird fast niemand unser System verwenden. Es ist aber durchaus hilfreich.
Tobias
Also wenn wir in Europa zum Beispiel sind, dann hat man natürlich generell ungefähr so eine händlichen Zeit plus minus ins Bett und stellt so eine händlichen Zeit vor. Also das heißt, nachts um drei wird fast niemand unser System verwenden. Es ist aber durchaus hilfreich, regelmäßig auch dort automatisiert zu gucken, ist das System noch online, weil man immer halt so ein Gefühl für kriegt, wie stabil ist denn eigentlich das System oder gibt es halt immer mal so kurze Aussetzer, die man vielleicht gar nicht so richtig merken würde, wo auch die Kunden zum Beispiel,
Sebastian
regelmäßig auch dort automatisiert zu gucken, ist das System noch online, weil man damit halt so ein Gefühl für kriegt, wie stabil ist denn eigentlich das System oder gibt es halt immer mal so kurze Aussetzer, die man vielleicht gar nicht so richtig merken würde, wo auch die Kunden zum Beispiel würden einen kurzen Aussetzer sehen, machen einen Neuladen, dann ist wieder alles da und sagt der Kunde, okay, naja, gut.
Tobias
Dann kommt ein Ausserzer, macht einen Neuladen und dann ist wieder alles klar. Dann fragt der Kunde, okay, naja, gut. Aber ich will trotzdem wirklich, wenn das immer wieder passiert, weil dann will ich natürlich was dagegen tun. Da ist vielleicht ein kleiner Tipp sozusagen in der Verfügbarkeit nicht so dramatisch. Aber wenn das permanent passiert, dann fragt sich der Kunde natürlich, was ist denn hier das für ein System, wenn ich jetzt bei jedem zehnten Seiten aufladen weiß, das ist eigentlich ein problematisches Problem.
Sebastian
Aber ich will trotzdem mitkriegen, wenn das immer wieder passiert, weil dann will ich natürlich was dagegen tun. Weil da ist vielleicht ein kleiner Dip sozusagen in der Verfügbarkeit nicht so dramatisch. Aber wenn das permanent passiert, dann fragt sich der Kunde natürlich trotzdem, was ist denn hier das für ein System, wenn ich jetzt bei jedem zehnten Seiten aufladen eine weiße Seite bekomme beispielsweise.
Tobias
das oder es ist ein Hinweis, dass irgendwo eine tiefer gehende Ursache irgendwo drin steckt, die sich
Tobias
noch nicht stark auswirkt, aber was natürlich ein Risiko wirkt, dass das stärker passiert. Du hast, glaube ich, ich weiß gar nicht, ob du jetzt das Wort schon gesagt hast, wir haben auf jeden Fall im Vorgespräch darüber gesprochen, das Thema Predictive Maintenance, also das, was du gerade angesprochen hast. Ich sammle Daten über das System, in dem Fall zum Beispiel die Online-Überwachung. Und was ist jetzt der, beschreib mal, was bedeutet Predictive Maintenance und was ist der Ansatz?
Sebastian
Genau, also bei jetzt, wenn man einfach nur guckt, ist der Dienst online oder nicht, dann ist es natürlich nicht predictive, weil da kriege ich erst im Nachgang mit, okay, jetzt ist er gerade offline sozusagen, jetzt ist er nicht verfügbar. Interessant ist, dass ich, wenn ich, wenn ich Verfügbarkeiten messe, dann kriege ich ja nicht nur mit, ist da oder ist nicht da, ich kriege auch mit, wie lange brauche ich zum Beispiel zu antworten, also das ist, wir nennen das die Latenz. Und das ist zum Beispiel schon ein ganz interessanter Indikator, wo ich
Tobias
Das ist zum Beispiel schon ein ganz interessanter Edikator.
Sebastian
so ein bisschen ablesen kann, ist es geht es dem System gut oder ist es gerade irgendeine Lastsituation, also ist es absehbar, dass mein System sich schlecht verhalten oder ausfallen wird. Und das ist eigentlich unser Ziel. Unser Ziel ist ja nicht so lange hier schön dazusitzen, bis irgendwann eine rote Lampe angeht und wir auf unserem Handy eine SMS kriegen, hey, da ist ein System ausgefallen, sondern wir wollen ja das proaktiv managen und proaktiv fixen.
Tobias
Und das ist eigentlich unser Ziel. Unser Ziel ist ja nicht, so lange hier nur da zu sitzen, bis irgendwann die rote Lampe angeht und wir auf unseren Handy den ersten Rest kriegen, hey, da ist ein System ausgefallen. Sondern wir wollen ja das proaktiv managen und proaktiv fixen. Und deshalb ist das für uns so ein riesig großes Thema, dass wir bei jedem Incident passieren, also bei jedem Problem in Produktion dann im Nachgang mal gucken, okay, was können wir tun, damit wir das halt im Vorhinein
Sebastian
Und deshalb ist das für uns so ein riesig großes Thema, dass wir bei jedem Inzident, was wir haben, also bei jedem Problem, in der Produktion dann im Nachgang immer gucken, okay, was können wir tun, damit wir das halt im Vorhinein mitbekommen. Und es stellt sich halt raus, dass man da echt sehr, sehr viele Probleme schon im Vorhinein mitbekommen kann. Und das ist halt extrem lernvoll, das auch zu tun. Weil das auch den Stress massiv reduziert für die Beteiligten am Ende des Tages. Genau. Auch in dem Punkt hier noch mal betreiben.
Tobias
Genau, auch in den Punkt gehen wir noch mal kurz rein.
Tobias
Die Situation, wir haben es von uns schon mal angesprochen, mit dem Thema Rufbereitschaft, die wir häufig sehen, was gemacht wird in anderen Unternehmen, ist sozusagen, wir akzeptieren, dass es Ausfälle gibt und wenn die Kritikalität des Systems so hoch ist, dann muss halt nachts, wenn das System ausfällt, jemand aus dem Schlaf geklingelt werden.
Sebastian
Die Situation, wir haben es schon mal angesprochen, mit dem Thema Berufbereitschaft, die wir häufig sehen, was gemacht wird in anderen Konternecken, ist sozusagen, dass wir akzeptieren, dass es ausgeregiert wird, und wenn die Kritikalität des Systems so hoch ist, dann muss dann das, dass es im Ausfeld jemanden gibt, die nicht klagen oder sich dann darum kümmern. Und wir versuchen, sozusagen diese Situation zu vermeiden,
Tobias
nicht schlafen oder sich dann darum kümmern. Und wir versuchen sozusagen diese Situation zu vermeiden als Ansatz sozusagen und überlegen uns, okay, wie muss unser System eben aussehen? Was können wir an vorlaufenden Indikatoren, das was du gerade beschrieben hast mit der Latenz, was können wir uns da an vorlaufenden Indikatoren angucken?
Tobias
um im normalen Geschäftsbetrieb, Montag bis Freitag, den wir haben, das System und so weit, um das System zu kümmern, dass es eben nicht ausfällt, dass diese Risiko eben nicht eintritt. Wir haben natürlich trotzdem die Situation, gerade nachdem wir zum Beispiel große Livegagge gemacht haben, zum Beispiel Online-Shops, wo wir natürlich schon auch außerhalb der Geschäftszeiten intensiv auf das System gucken und dann auch proaktiv, wenn ihr merkt, wo das geht,
Sebastian
um das System zu kümmern, dass es eben nicht auswärts, dass die so nicht freundlich eintritt. Genau, und wir haben natürlich trotzdem die Situation, gerade nachdem wir zum Beispiel große Live-Gänge gemacht haben, zum Beispiel bei Online-Jobs, wo wir natürlich schon auch außerhalb der Geschäftszeiten intensiv auf das System gucken und dann auch proaktiv, wenn wir merken, oh, das geht hier gerade einen Bach runter, sozusagen, jetzt bei dem Latenzbeispiel, dann proaktiv Einfluss nehmen,
Tobias
um die Situation zu verbessern. Das ist schon klar. Das sind die berühmten 10 bis 20 Prozent. Aber der Witz ist halt, das macht man vielleicht mal vier Wochen maximal. Also relativ kurzer Zeitraum. Und danach schwingt sich das wieder ein. Dann haben wir die Kinderkrankheiten raus aus dem System. Und dann können wir jetzt vom Normalbetrieb übergehen. Das ist das Schöne daran, dass sich die Menge an Projekten, die wir haben über die Zeit,
Sebastian
um die Situation zu verbessern, das ist schon klar. Das sind halt die berühmten 10 bis 20 Prozent. Aber der Witz ist halt, das hat man dann vielleicht mal vier Wochen lang maximal, also in relativ kurzer Zeitraum. Und danach schwingt sich das wieder ein. Also dann hat man so die Kinderkrankheiten raus aus dem System.
Sebastian
Und dann können wir wieder zu dem Normalbetrieb übergehen. Und das ist eigentlich das Schöne daran, dass sich die Menge an Projekten, die wir haben über die Zeit natürlich immer weiter gesteigert hat, mit zunehmender Teamgröße, aber wir trotzdem nicht mehr, also ich persönlich zum Beispiel, nicht mehr Zeit in irgendwelchen Notrufsituationen bin. Im Gegenteil, ich habe erst gefühlt, es ist ein bisschen weniger gehoben, weil sich es auf mehr Schultern verteilt natürlich.
Tobias
beschreibet haben. Aber wir trotzdem nicht mehr, also ich persönlich zum Beispiel, nicht mehr Zeit in irgendwelchen Notrufsituationen binden. Im Gegenteil, ich habe das Gefühl, es ist ein bisschen weniger geworden, weil es sich auf mehr Schultern verteilt natürlich. Aber auch, wenn ich das ausblende und einfach mal auf die absoluten Zahlen gucke, würde ich sagen, dass es mindestens gleich mit dem, dass natürlich super eine Menge an Projekten, die wir einfach haben, miteinander verglichen mit der geringen Menge an Projekten, die wir am Anfang hatten.
Sebastian
Aber auch, selbst wenn ich das ausblende und einfach nur auf die absoluten Zahlen gucke, würde ich sagen, ist es mindestens gleich geblieben. Und das ist natürlich super bei der Menge an Projekten, die wir einfach haben mittlerweile und verglichen mit der geringen Menge an Projekten, die wir am Anfang hatten.
Tobias
Jetzt sind wir eingestiegen. Du hattest beschrieben unser Verfügbarkeitsmonitoring, also das Availability- und Uptime-Monitoring. Das ist sozusagen die Ebene, die am weitesten oben auf das System guckt und aus Endnutzerinnen-Sicht schaut, ist das System für seine eigentliche Aufgabe verfügbar.
Sebastian
hat es ja in mehrere Schichten sozusagen zu Ausfällen gekommen, dass die Service Beeinträchtigungen und lasst uns dort nochmal reingehen. Wir unterscheiden uns ganz stark mit unserer Seite zwischen der Infrastruktur und der Anwendung der Applikations-Service. Was machen wir denn auf der Infrastruktur-Seite?
Tobias
in mehreren Schichten sozusagen zu Ausfällen kommen oder zu Service-Beeinträchtigungen. Und lassen uns doch da nochmal reingehen. Wir unterscheiden ganz stark auf unserer Seite erstmal zwischen Infrastruktur und der Anwendung der Applikation selbst. Was machen wir denn auf der Infrastruktur-Seite? Genau, Infrastruktur ist quasi alle zugrundelegende Dienst, die wir brauchen, wenn wir alle trainieren. Das heißt,
Sebastian
Genau Infrastruktur ist quasi alle zugrunde liegende Dienste, die ich brauche, damit meine Anwendung funktioniert. Das heißt, unsere Anwendung läuft auf Servern in irgendeinem Rechenzentrum und die ganz grundlegenden Dienste sind natürlich Strom, Internet und so weiter. Da haben wir natürlich wenig Einfluss drauf, sondern müssen uns darauf verlassen, dass unser Rechenzentrumsbetreiber einen guten Job macht und das tun wir auch. Das heißt, diese Art von Problemen haben die im Griff. Das heißt, wir starten de facto bei der
Tobias
Wenn man das mal in ein Rechenzentrum und die ganz Grundlegende gibt, die sind natürlich Strom, Internet und so weiter, da haben wir natürlich wenig Einfluss drauf, da müssen wir uns darauf verlassen, dass unser Rechenzentrumsbetreiber einen guten Job macht und das tun die auch. Das heißt, diese Art von Problemen haben die getroffen. Das heißt, wir starten de facto bei der physischen oder virtuellen Server, also vielleicht bei Hardware und sind für alles drin verantwortlich.
Sebastian
physischen oder virtuellen Servern, also sprich bei Hardware. Und sind für alles dort drin verantwortlich, beginnend mit dem Betriebssystem. Und das heißt, man monitort CPU, also Prozessorauslastung, RAM, also Arbeitsspeicherauslastung und auch wie entwickeln die sich. Man guckt die Festplatte an, weil das zum Beispiel so ein Ding ist, Festplatten werden natürlich immer größer.
Tobias
Das heißt, man monitort CPU, also Prozessorauslastung, Arbeitsspeicherauslastung und auch wie entwickelt sie sich. Man guckt die Festplatte an, weil das ist zum Beispiel, so ein Ding ist Festplatte natürlich immer größer, das ist auch super, aber man kann auch Festplatte trotzdem sehr schnell, sehr selten vollschreiten, wenn das System etwas abläuft.
Sebastian
Logischerweise, das ist auch super, aber man kann auch Festplatten trotzdem sehr schnell, sehr, sehr voll schreiben, wenn man ein System hat, das einmal läuft. Und das heißt, und jetzt habe ich das Problem,
Tobias
Das heißt, und jetzt habe ich das Problem, im Server, wenn die Festplatte mal hundertprozentig voll ist, ist es extrem schwer, damit zu interagieren. Da kann ich teilweise nicht mehr auf das System eindringen, um irgendwas zu tun. Und genauso, wenn 100% der CPU-Aarm ansteckt oder den ganzen Rahmen verbraucht. Das ist eigentlich das Symptom, das ich überhabe. Sobald irgendeine dieser Ressourcen vollständig ausgelastet sind, wird es extrem schwer, mit dem System zu interagieren. Das heißt, wir müssen versuchen,
Sebastian
den Server, wenn die Festplatte mal 100%ig voll ist, ist extrem schwer damit zu interagieren. Da kann ich mich teilweise nicht mal mehr auf das System vernünftig einloggen, um irgendwas zu tun. Und genauso, wenn 100% der CPU am Anschlag sind oder der gesamte RAM verbraucht ist, das ist eigentlich das Symptom, das ich immer habe. Sobald irgendeine dieser Ressourcen vollständig ausgelastet sind, wird es extrem schwer mit dem System zu interagieren. Das heißt, wir müssen versuchen, das vorherzumachen. Und
Tobias
und haben dann mehr Berührungsspielraum am Ende des Tages. Das heißt, die Basis-Illikatur, die ich schon genannt hatte, also CPU, Rahmen- und Festplatte, ist das, was wir ständig monitorn. Wir nutzen aber Systeme, sich Netdata, das monitort noch hunderte mehr Parameter von Servern und zum Beispiel auch IO-Wave, das ist so ein
Sebastian
haben dann mehr Bewegungsspielraum am Ende des Tages. Das heißt, die Basisindikatoren, die ich schon genannt hatte, also CPU, Rahmen- und Festplatte, ist das, was wir ständig monitorn. Wir nutzen aber ein System, das nennt sich NetData, das monitort noch hunderte mehr Parameter von Servern und zum Beispiel auch
Sebastian
Das ist so eine Indikation, wie lange muss ein kleiner Job auf den Prozessor warten, um etwas zu tun beispielsweise, oder wie lange muss der warten, bis der dann übers Netzwerk verschickt wird. Das können alles Indikatoren sein, für gewisse Hardware-Fehler beispielsweise, die natürlich selten eintreten, aber die trotzdem hilfreich sind zu überwachen.
Tobias
Das ist ein OPSOS-System, das hat schon extrem viele diese Art von Checks eingebaut, out of the box.
Sebastian
Genau, der Witz von diesem System ist halt, es ist ein Open-Source-System, das hat schon extrem viele diese Art von Checks eingebaut, out of the box, und das war für uns ein riesen Quantensprung, als wir das eingeführt haben, weil davor haben wir halt die Standardmetriken erfasst, aber es war halt immer so ein bisschen so eine handgestrickte Lösung, wo man nie so hundertprozentig sicher war, dass es wirklich die richtigen Metriken in letzter Konsequenz waren, und dass alles korrekt berechnet wurde und so weiter. Genau, das ist auf jeden Fall ein System, was da sehr gut funktioniert.
Tobias
Genau, das ist auf jeden Fall ein System, was da sehr gut funktioniert. Und jetzt hast du gerade schon beschrieben, das NetData kümmert sich an der Stelle nicht nur um das Monitoring, sondern auch das Alerting. Genau. Was passiert da? Was heißt Alerting bei uns in dem Fall? Genau, also Alerting bei uns ist ein Swag. Neben der Komplikation, alle Systeme, über die wir gerade reden, die Monitor, also die schicken Alerts in einen speziellen Swag-Kanal ein. Und da kommen die relevanten Mengen an Leute. Erstmal, ich sage jetzt mal, eine Push-Notification. Aufs Handy gibt es auch.
Sebastian
Genau. Genau, also Alerting bei uns, also wir nutzen Slack für die interne Kommunikation und alle Systeme, über die wir gerade reden, schicken Alerts in einen speziellen Slack-Kanal rein. Und damit bekommen die relevante Menge an Leuten erstmal, ich sag jetzt mal, eine Push-Notification aufs Handy, im Zweifelsfall auch.
Sebastian
Wir haben auch noch bestimmte andere, also für bestimmte Systeme in dieser kritischen Phase, also gerade nach dem Launch beispielsweise, gibt es auch einen Direktkanal, direkt per Push-Notification aufs Handy, was dann auch ein Pling macht beispielsweise, sodass wir das halt nicht für jede Notification bekommen müssen, aber halt für die ganz dringenden in diesen Hochlastsituationen.
Tobias
Wir haben auch noch für bestimmte Systeme in dieser kritischen Phase, also gerade nach Launch beispielsweise, gibt es auch einen direkten Kanal, direkt per Push-Notification aufs Handy, was dann auch ein Kling macht beispielsweise, also dass wir das halt nicht für jeden Notified, nicht für jeden Notification kommen müssen, aber halt für die ganz dringend in diesen Hochlastsituationen.
Tobias
Genau, ganz konkret mal das Beispiel gemacht. Du hattest es ja vor uns beschrieben. Wir sind mit dem neuen Onlineshop live gegangen. Das ist das erste Wochenende nach dem Launch. Und wir gucken uns durch das Monitoring quasi in Echtzeit, können wir uns den Server angucken, wie geht es dem Server, was CPU-RAM und so weiter angeht, was du gerade beschrieben hast. Und dadurch, dass wir sehen und auch im Service-Fall diese Push-Notification bekommen, wenn ein gewisser Schwellwert überschritten ist an Auslastung, haben wir noch die Möglichkeit mit dem
Sebastian
Wir gucken uns durch das Monitoring quasi in Echtzeit, können wir uns den Server anschauen, wie geht es zum Server, was z.B. U-Bahn und so weiter, wie ihr das beschrieben habt. Und dadurch, dass wir das sehen und auch unser Service bei dieser Push-Nodification bekommen, dass das Schwellenwerk verschritten ist an den Auslastungen, haben wir noch die Möglichkeit, das System zu interagieren, dass es draußen nicht mehr benutzbar wird, wenn es ausfällt.
Tobias
System zu interagieren, bevor es eben nicht mehr benutzbar wird und wirklich komplett ausfällt für die Kunden. Genau, was in der Infrastruktur überhaupt noch wichtig ist, ist ein Thema, was viele Leute gerade nicht richtig konzeptabel haben. Und zwar geht es um HTTPS und L-Zertifikate. Also wir nutzen mittlerweile das Internet eigentlich alle in der Art und Weise, die verschlüsselt ist. Das sind wir an dem HTTPS, also S für Secure vorne.
Sebastian
Genau, was an der Infrastruktur, glaube ich, noch wichtig ist, ist ein Thema, was viele Leute gar nicht so richtig auf dem Zettel haben. Und zwar geht es um HTTPS und SSL-Zertifikate. Also wir nutzen mittlerweile das Internet eigentlich alle in einer Art und Weise, die verschlüsselt ist. Das sieht man an dem HTTPS, also S für Secure vorne. Und das hat den Vorteil, dass quasi meine Kommunikation zwischen meinem Browser und meinem Zielsystem, meinem Server nicht von irgendwelchen dritten
Tobias
Das hat den Vorteil, dass meine Kommunikation zwischen meinem Brause- und meinem Zielsystem und meinem Server nicht von irgendwelchen Tritten mitgelesen werden kann. Früher war es so, dass die Brause und Banken solche Sachen hatten, weil das relativ teuer war und man auch manuell arbeiten brauchte und man brauchte relativ viele Prozesse. Man musste auch jährlich Geld bezahlen für diese Zertifikate.
Sebastian
mitgelesen werden kann, genau. Und früher war das so, dass das nur so Banken und solche Sachen hatten, weil das relativ teuer war und manuell Arbeit gebraucht hatte und brauchte dann relativ viele Prozesse. Wie gesagt, musste auch Geld bezahlen jährlich für diese Zertifikate. Und da wurde vor einigen Jahren ein System erschaffen, das nennt sich Let's Encrypt von Mozilla unter anderem.
Sebastian
Und das geht, das hatte das Ziel, einen großen Teil des Internets mit SSL, also abzusichern mit sicherem Internet-Traffic, damit man halt nicht im Internet-Café zum Beispiel mitgelesen werden kann, was ich da so tue, wenn halt noch andere oder im Café beispielsweise, wenn ich einfach mit meinem Handy ins WLAN gehe von dem Café, damit ich halt nicht mitlesen kann, das macht mein Nachbar. So und... Ja, das noch mal. Das war für mich eigentlich sofort...
Tobias
Und das haben das Ziel, einen großen Teil des Internets mit SSL, also abzusichern mit sicherem Internet-Traffic, damit man halt nicht im Internet-Café zum Beispiel mitgelesen kann, was ich da so tue. Bei einer Handlerseite oder einem Café beispielsweise, wenn ich halt mit meinem Handy ins WLAN gehe, von einem Café, und ich halt nicht mitlesen kann, das macht mein Nachbar.
Tobias
Ich will das nochmal betonen, weil das war für mich, als ich das so verstanden habe, so ein spannender Aspekt. Das Internet ist quasi wie Postkarten verschicken. Wenn ich nicht diese Verschlüsselung verwende,
Sebastian
Das Internet ist quasi wie Postkarten, das versteht man nicht. Wenn ich nicht diese Verschlüsse verwende, sind alle Nachrichten, die ich vergesse, sind alle Nachrichten, die ich vergesse, sind alle Nachrichten, die ich vergesse, sind alle Nachrichten, die ich vergesse, sind alle Nachrichten, die ich vergesse, sind alle Nachrichten, die ich vergesse, sind alle Nachrichten, die ich vergesse, sind alle Nachrichten, die ich vergesse, sind alle Nachrichten, die ich vergesse, sind alle Nachrichten, die ich vergesse, sind alle Nachrichten, die ich vergesse, sind alle Nachrichten, die ich vergesse, sind alle Nachrichten, die ich vergesse, sind alle Nachrichten, die ich vergesse, sind alle Nachrichten, die ich vergesse, sind alle Nachrichten, die ich vergesse, sind alle Nachrichten, die ich vergesse, sind alle Nachrichten, die ich vergesse,
Tobias
Es sind alle Nachrichten, die ich quasi über das Internet sende, also wenn ich in meinem Browser irgendwas tue, Musik streame oder mein Onlinebanking benutze, das sind Postkarten, die ich verschicke. Und nur wenn ich diese Verschlüsselung mit dem HTTPS zum Beispiel aktiviert ist,
Tobias
Dann sind es eben Briefe und keine Postkarten, die ich benutze. Und dieser Switch, der da passiert ist im Internet, der ist ja mal für meine eigenen Daten, dass die geschützt sind und nicht jeder da irgendwas mitlesen kann, super wichtig.
Sebastian
Genau, das braucht quasi so Zertifikate. Das sind spezielle Dateien, die das absichern. So was wie Schlüssel, könnte man sich das vorstellen. Und die haben ein Götigkeitsdatum. Also die laufen ab nach einer gewissen Zeit. Was Let's Encrypt gemacht hat, ist, die haben sich was überlegt, wie man automatisiert sozusagen sich neue Schlüssel holen kann für Domains, die einem selber gehören.
Tobias
sich neue Schlüsse holen. Und haben gesagt, das musst du aber auch ständig machen. Das Zertifikat ist nicht mehr ein Jahr gültig, sondern nur noch 90 Tage. Das bedeutet, man muss alle drei Monate maximal sich ein neues Zertifikat holen. Und damit, wenn ich das halt vergesse, wenn ich das nicht mache sozusagen, dann ist halt meine Seite offline.
Sebastian
Und haben gesagt, das musst du aber auch damit ständig machen. Also die haben gesagt, ein Zertifikat ist nicht mehr ein Jahr gültig, sondern nur noch 90 Tage. Das bedeutet also, man muss alle drei Monate maximal sich so ein neues Zertifikat holen. Und damit, wenn ich das halt vergesse, wenn ich das nicht mache sozusagen,
Sebastian
Dann ist halt meine Seite offline. Und das hat bestimmt viele schon mal gesehen. Im Pause kriegt man diese schöne Nachricht, wo dann sagt, hier, absolut unsichere Seite, willst du wirklich, wirklich weitermachen? Und eigentlich solltest du nicht weitermachen. Hier ist definitiv was komisch. Tu's nicht, so sinngemäß.
Tobias
Das ist ein schönes Beispiel für Predictive Management. Man weiß natürlich genau, wann es abläuft. Man hat viel Zeit dazu zu reagieren. Bei uns ist es so, dass das System
Sebastian
Und das läuft auch darauf hinaus, wenn das ein Problem ist, dann ist die Seite auch de facto offline. Das ist ein schönes Beispiel für Predictive Maintenance, weil man weiß natürlich genau, wann läuft das ab. Man hat viel Zeit, da zu reagieren. Und bei uns ist es, glaube ich, so, dass das System typischerweise noch 30 Tage vor Ablauf beginnt, neue Zertifikate zu holen. Und unser Monitoring fängt an bei 14 Tagen, glaube ich. Das heißt, wir haben immer noch zwei Wochen, entspannt Zeit zu reagieren, wenn da irgendwas klemmt. Und können das halt entspannt lösen. Und der Kunde kriegt nichts davon mit.
Tobias
Das heißt, wir haben immer noch zwei Wochen in Spannzeit zu reagieren, wenn da irgendetwas klemmt und wir können das halt entspannen. Hier ist noch der Kunde, der kriegt nichts davon hin. Und vielleicht am Rande, wir haben auch schon mit dem System, das hätte ich schon gesagt, dass wir auch sonst sozusagen fremde Server mitmonitoren, von Kunden von uns, also von Großkunden von uns. Wir hatten schon wieder die Situation, dass unser System reingeschleicht wird,
Sebastian
Und Funflect am Rande, wir haben auch schon mit dem System, ich hatte ja schon gesagt, dass wir auch sozusagen fremde Server mit Monitoren von Kunden von uns, also von Großkunden von uns, wir hatten schon hin und wieder die Situation, dass unser System angeschlagen hat und gesagt hat, hier das SSL-Zertifikat läuft aus und wir haben dann mal angerufen und gesagt, hier habt ihr das eigentlich auch im Zettel, euer SSL-Zertifikat läuft aus. Also es ist halt schon so,
Tobias
Also es ist halt schon so ein Punkt, den man auch hat.
Sebastian
Es ist halt schon ein Punkt, den man auch hin und wieder ganz gern vergisst. Und ich finde es aber eine wichtige Geschichte, dass man sich das halt vom Ende her anguckt, was kann alles so schiefgehen.
Tobias
Es ist ein kleines Detail, die nichts mit dem Server und nichts mit der Anwendung zu tun hat, sondern es steht halt irgendwie dazwischen und kann aber dafür sorgen, dass die Anwendung für die Endnutzer nicht verfügbar ist. Jetzt haben wir über Infrastruktur gesprochen, über den Server und wo die Anwendung läuft, die wir betreiben. Und jetzt kann die Anwendung selbst, dem Server geht es gut, aber die Anwendung tut irgendetwas. Was machen wir denn da?
Sebastian
Genau, also wir haben in den Anwendungen oder in den großen Anwendungen gibt es ganz, also machen die Logging, das bedeutet, die schreiben alle möglichen Statusinformationen mit und diese Logs kann man analysieren und da kriegt man sozusagen
Tobias
und diese Logs kann man analysieren und dann kriegt man sozusagen tief einregeln, wie geht es einer bestimmten Anwendung, was tut die eigentlich unter der Haube? Gibt es Fehler, die passieren oder gibt es Probleme, die nicht passieren sollen? Das kommt sich dann quasi an. Wie häufig kommen bestimmte Meldungen? Die Meldungen sind typischerweise zugeordnete, haben eine Kritikalität,
Sebastian
einen tiefen Einblick in, wie geht es einer bestimmten Anwendung, was tut die eigentlich unter der Haube? Gibt es Fehler, die passieren oder gibt es Probleme, die eigentlich nicht passieren sollten? Also man guckt sich dann quasi an, wie häufig kommen bestimmte Meldungen um, also die Meldungen sind auch typischerweise so zugeordnet nach einer Kritikalität, also zwischen, das ist eine Info, das ist ein Warning, das ist ein Error, um mal drei zu nennen.
29:40.69
Tobias Das ist eine Info, das ist ein Warning, das ist ein Error, um das mal zu nennen. Man will halt wirklich wenig Errors haben, zum Beispiel. Warnings können schon mal ein bisschen vorkommen, aber auch da möchte ich verstellen, wenn es auf einen Schlag viel mehr sind als gestern, zum Beispiel, in der gleichen Zeit. Diese Art von Trends möchte ich quasi erkennen. Dann ist es so, dass andere typischerweise etwas
Sebastian
Man will möglichst wenig Eros haben, z.B. Warnings können schon mal ein bisschen vorkommen, aber auch da möchte ich verstehen, wenn es auf einen Schlag viel mehr sind als gestern z.B. um die gleiche Zeit. Diese Art von Trends möchte ich quasi erkennen.
Sebastian
So, und dann ist es so, dass Anwendungen typischerweise, wenn irgendwie was wirklich ein Fehler passiert, also man sieht das als Kunde dann typischerweise, dass man irgendeine Seite bekommt, hier, es ist was schief gelaufen, ups, tut uns leid, dann, da passiert in der Anwendung, das nennt sich eine Exception, das ist quasi eine Fehler mit sehr viel Information, wo man genau weiß, okay, wo war die Anwendung exakt, welchen Codefad hat sie genommen, und die sind auch sehr hilfreich auszulesen, also das ist Exception Monitoring, was da auch noch mit ein großes Thema ist.
Tobias
Und die sind auch sehr hilfreich auszulesen. Also das ist Exception Monitoring, was da auch noch mit ein großes Thema ist. Und das Interessante ist, häufig wird Exception Monitoring gemacht. Da gibt es viele Dienste, wie z.B. für Sentry als kommunizierter Dienst. Und bei Logs gucken sich weniger Leute an, interessanterweise teilweise. Obwohl die auch ganz ganz viele Informationen unterhalten. Und was ich immer wichtig finde, ist, dass wir halt immer wieder zur Ursache gehen,
Sebastian
Und das Interessante ist, häufig wird Exception Monitoring gemacht, da gibt es viele Dienste für, wie z.B. Sentry als kommerzieller Dienst. Aber Logs gucken sich weniger Leute an interessanterweise teilweise, obwohl die auch ganz ganz viele Informationen enthalten.
Sebastian
Und was ich immer wichtig finde, ist, dass wir halt immer wieder zur Ursache gehen. Das heißt, dass wir gucken, dass unsere Logs möglichst aussagekräftig sind. Das heißt, dass ich nicht hier 10.000 Euros am Tag habe, die eigentlich keine Bedeutung haben. Das heißt, die müssen wir wegkriegen in unserem Quersystem. Und genauso auch mit den Exceptions, die bieten mir halt nur dann einen Mehrwert, wenn sie halt nur dann geworfen werden, wenn es echte Probleme gibt und nicht einfach
Tobias
wenn sie nur angeworfen werden, wenn es echte Probleme gibt und nicht einfach unter der Haube ständig. Und da muss man auch die Anwendung entsprechend noch ein bisschen modifizieren, dass sie sich gut betreiben lassen. Das ist für uns, weil wir sowohl die Anwendung schreiben als in dem Fall, wo wir sie selber betreiben, sozusagen die Möglichkeit,
Sebastian
unter der Haube ständig sozusagen. Und da muss man auch die Anwendungen entsprechend dann noch mal ein bisschen modifizieren, dass das halt, dass sie sich gut betreiben lassen auf die Art und Weise. Das ist für uns, weil wir wohl die Anwendungszeit meistens in dem Fall, wenn wir es selber betreiben, sozusagen die Möglichkeit, unsere eigene Arbeit im Betrieb leichter zu machen. Wenn wir an die Ursache angehen, die Anwendung und sagen,
Tobias
unsere eigene Arbeit im Betrieb leichter zu machen. Wenn wir an die Ursache rangehen, nämlich die Anwendung und sagen, wir heben dort einen Fehler, der vielleicht zu Fehlermeldungen sonst führt und kommen nicht in die Situation, wo wir sagen, den Fehler kennen wir, der fliegt immer Montag Mittag, den können wir ignorieren. Da sind wir auch an einem Aspekt,
Sebastian
Da kommt man nicht in eine Situation, wo man sagt, den kennen wir, den können wir ignorieren. Da sind wir auch noch etwas weg. Das ist ja diese Benachrichtigung, man ist wieder aufgetreten, in der Anwendung ist etwas schiefgegangen. Das ist ja nicht normal, so zu sagen. Wie häufig kommt es denn vor mit, auch ob das wirklich so ein Grund draußen war, wo ich irgendwann noch sage, da ist mal viel los und das wird nicht schlecht. Wurde ich direkt nach sich hineingetodelt.
Tobias
Das ist ja diese Benachrichtigung. Hier ist ein Fehler aufgetreten. In deiner Anwendung ist was schiefgegangen. Das ist ja ein Nicht-Normalfall sozusagen. Wie häufig kommt das denn vor und erzeugt das so einen Grundrauschen, wo ich dann irgendwann mal sage, da ist halt viel los in dem Slack-Kanal, wo die Monitoring-Nachrichten eintudeln. Och, ich mach den mal lieber stumm, weil der nervt. Ja, genau. Das ist auch ein Begriff.
Sebastian
Genau, das ist genau das Problem. Das hat auch einen Begriff. Das ist sozusagen hier Exception oder Alert-Fatigue. Keine Ahnung, wie man das ausspricht. Also Müdigkeit sozusagen. Also Fatigue auf Englisch, glaube ich. Und das ist genau dieses Rauschen durch. Man kriegt es gar nicht mehr mit, wenn man denkt, es wird schon nichts sein. Sonst war ja auch immer nichts. Und das ist natürlich total gefährlich, wenn das eintritt.
Tobias
Das ist genau dieses Rauschen.
Sebastian
Deshalb versuchen wir, das Problem vom Ende her zu betrachten und dafür zu sorgen, dass Fehler, wenn sie ausgelöst werden, auch tatsächlich einen Impact haben. Das heißt, dass wir merken, das ist wirklich ein Problem.
Sebastian
Und dann haben wir auch ein Incentive, das zu lösen. Und wenn man halt weiß, okay, da ist ein Problem für den Kunden aufgetreten. Und wir kriegen auch eine Vorstellung, wie viele sind es eigentlich davon. Und viele Tools funktionieren da ein bisschen anders. Also, die haben eher so die Philosophie, na ja, du kriegst halt 10.000 der Exceptions, da musst du mit klarkommen. Weil, wenn ich sozusagen, das geht auch nicht anders, wenn ich sozusagen die ursprüngliche Software nicht verändern kann oder beeinflussen kann, dann muss ich natürlich mit der großen Menge an
Tobias
Viele Tools funktionieren ein bisschen anders. Die haben eher so die Philosophie, naja, du kriegst halt 10.000 Exceptions, da musst du nicht klarkommen. Das geht auch nicht anders. Wenn ich die Software nicht verändern kann oder beeinflussen kann, dann muss ich natürlich mit der großen Menge an Predaten, die so aufschlagen, irgendwie klarkommen und muss die von mir sortieren und Klebezeiten dran schreiben und sagen, die sind ganz wichtig, die sind unwichtig und alles dazwischen.
Sebastian
Ich habe viele Fehler, die so aufschlagen, irgendwie klarkommen und muss die für mich sortieren und noch Klebezelle dran schreiben und sagen, die sind ganz wichtig, die sind unwichtig und alles dazwischen.
Sebastian
Das ist aber einer der Vorteile, wenn man Operations, also Betrieb und Entwicklung so eng verzahnt, wie wir das machen, dass wir damit diese gesamte Kette betrachten können und natürlich die Fehler auch an der Ursache lösen können. Und damit brauchen wir halt kein Tooling, was halt 10 Millionen Exceptions sortiert und in drei Kisten einsortiert, weil das Ziel ist einfach, dass es nicht 10 Millionen Exceptions gibt.
Tobias
Das ist aber einer der Vorteile, wenn man Operations, also Betrieb und Entwicklung so eng verzahlt, wie wir das machen, dass wir damit diese gesamte Kette betrachten können und natürlich die Fehler auch an der Ursache lösen können. Dann brauchen wir halt kein Problem, was halt 10 Millionen Exceptions sortiert und in drei Kisten einsortiert, weil das Ziel ist einfach, dass es nicht 10 Millionen Exceptions gibt.
Tobias
Ja, ich glaube, das ist auch so ein Punkt für uns als vergleichsweise kleine Agentur mit der engen Verzahnung, was du gerade sagtest. Entwicklung und Betrieb machen ähnliche Leute, machen die gleichen Leute, machen wir in einem Projektteam. Damit habe ich diese Incentivierung, ich möchte möglichst wenig Betriebsthemen auf dem Tisch haben, sondern ich möchte möglichst viele Features für den Kunden entwickeln.
Sebastian
vergleicht mit der kleinen Kultur, mit der Infrastruktur. Sogar sagt es mal, Entwicklung und Betrieb machen ähnliche Leute. Die gleichen Leute machen wir in einem Projektteam. Damit habe ich diese Instativierung. Ich möchte möglichst wenig Betriebssysteme auf dem Tisch haben, sondern ich möchte möglichst viele Features für die Kunden entwickeln. Also behebe ich ein Problem ursächlich,
Tobias
Also behebe ich ein Problem ursächlich und löse damit ganz viele nachfolgende Probleme, nämlich dass überhaupt die Fehler auftreten, dass ich darüber benachrichtigt werde, dass sie dieses Grundrauschen erzeugen und habe damit viele Benefits oder viele Vorteile. Und ich glaube gerade in größeren Unternehmen, wo diese Abteilungen stärker getrennt sind, da
Sebastian
lösen damit ganz viele nachfolgende Probleme, nämlich dass überhaupt die Fehler auftreten, dass ich nur benachrichtigt werde. Das ist ein großes Grundrauschen erzeugt und hat aber viele Benefiz, viele Vorteile. Und ich glaube, gerade die größten Unternehmen, wo diese Abteilungswerke getrennt sind, da habe ich schon viel größere Herausforderungen, was das angeht, als du den Fall eben gerade beschrieben hast. Eigentlich ist das für die Unternehmen verantwortlich, bekommt diese ganze Verhandichtigung, hat aber keinen direkten Zugriff
Tobias
habe ich eine viel größere Herausforderung, was das angeht. Das ist den Fall, den du gerade beschrieben hast. Ein Team ist für den Betrieb verantwortlich, bekommt diese ganzen Benachrichtigungen, hat aber keinen direkten Zugriff oder kann nicht beeinflussen, ob jetzt einer dieser Fehler auch mal behoben wird, sondern die können das im besten Fall noch in den Prozess einkippen, wo dann priorisiert wird, dass vielleicht mal ein Fehler in der Anwendung ursächlich behoben wird, was aber wieder von einem ganz anderen Produktmanagement-Team entschieden wird.
Sebastian
Wo das vielleicht mal ein Fehler in der Anwendung grundsätzlich behoben wird. Da hat unsere Größtenphänetik seine Fortschneidern und unsere Philosophie entgegen.
Tobias
Da hat unsere Größe definitiv seine Vorteile und auch unsere Philosophie, denke ich. Ja, absolut. Ich glaube, das macht schon... Also, es erfordert natürlich auch von unserem Team sehr viel Wissen. Also, was nicht nur im Programmierung bespricht, sondern natürlich auch irgendwie betreibe ich das denn.
Sebastian
Ja, absolut. Ich glaube, das macht schon... Also, es erfordert natürlich auch von unserem Team sehr viel Wissen. Also, was nicht nur im Programmiererischen ist, sondern natürlich auch irgendwie, wie betreibe ich das denn? Das muss halt zusammengedacht werden. Und das ist uns halt wirklich wichtig, dass sozusagen die Aufgabe nicht aufhört, wenn es fertig programmiert ist, sondern die Aufgabe hört dann auf, wenn es produktiv installiert ist und keine Fehler auf Ursache hat. Weil natürlich auch
Sebastian
damit man auch einfach diese Feedbackkette schließt, weil das ist ja auch was wichtiges. Wir machen alle Fehler und wenn wir Programmierfehler machen, wirken die sich auch hin und wieder logischerweise für unsere Kunden negativ aus und es ist total wichtig, als derjenige, der es gebaut hat, daraus auch lernen zu können und dafür brauche ich natürlich auch eine schnelle Feedback-Scheife und deshalb zum Beispiel ist es auch sehr wichtig, dass wenn ich eine neue Softwareversion reviest habe, dann sehe ich
Tobias
Und es ist total wichtig, als Gaming das gebaut hat, daraus lernen zu können. Dafür brauche ich natürlich auch eine schnelle Feedback-Schleife. Deshalb zum Beispiel ist es auch sehr wichtig, dass wenn ich eine neue Software-Version gelöst habe, dann sehe ich eine Stunde später, oh hier kommen fünf Meldungen rein, die mit meinen Problemen zu tun haben, da ist wohl was schief gegangen, und dann kann ich überlegen, gehe ich zurück oder gehe ich nach vorne zum Beispiel, kann ich das noch fixen, um einfach diese Feedback-Schleife zu schließen.
Sebastian
Eine Stunde später, oh, hier kommen fünf Meldungen rein, die mit meinem Problem zu tun haben, ups, da ist wohl was schief gegangen und dann kann ich überlegen, gehe ich zurück oder gehe ich nach vorne zum Beispiel, kann ich das noch fixen, um einfach diese Feedback-Schleife zu schließen, weil sonst habe ich halt das Problem, dass sozusagen das Feedback nie bei den Entwicklerinnen und Entwicklern ankommt im Worst Case.
Tobias
sozusagen das Feedback nie bei den Gegenden 2.0 ankommen. An der Stelle verweise ich mal, ich bin mir ziemlich sicher, wir haben schon eine Frage zum Thema Qualitätsmanagement insofern gemacht, die verlinken wir euch natürlich auch in den Show Notes. So, und jetzt hatten wir die zwei Bereiche, die Infrastruktur, Server und alles unterhalb der Anwendung sozusagen, wenn man in diesen Schichten denken und die Anwendung selbst. Und jetzt hatten wir im Vorgespräch noch was rauskristallisiert, wurde gesagt, es gibt noch einen Bereich,
Sebastian
So, und jetzt haben wir die zwei Bereiche, die Infrastruktur, Serverangriff, unterhalb der Anderen, sozusagen, wenn man in Schichten denkt, und die Anderen selbst. Und jetzt hatten wir ein Vorgespräch nach der Frostpistole, da haben wir gesagt, nee, der gibt's nicht. Es gibt noch einen Bereich, der immer mal wieder rauskommt, der sich so ganz klassisch ein oder so mit beiden Seiten zuordnen lässt.
Tobias
der immer mal wieder auftritt, der sich nicht so ganz klassisch einer von den beiden Seiten zuordnen lässt. Genau, das ist so eine typische Anwendung. Gerade in der größten Anwendung, die hat immer irgendwelche Hinterkunftjobs, Hinterkunfttasks, die wiederkehrend sind. Die wiederkehrend sind, die wieder und immer mal passieren, durch, ich sag mal, Reinigungsarbeit oder sowas, könnte man sich so hoch vorstellen. Und das läuft ohne Frage.
Sebastian
Genau, und es ist so, typische Anwendungen, gerade größere Anwendungen, die haben immer irgendwelche Hintergrundjobs, Hintergrundtasks sozusagen, also irgendwelche wiederkehrende Dinge, die im Hintergrund immer mal passieren müssen, ich sag mal Reinigungsarbeiten oder sowas, könnte man sich so grob vorstellen.
Sebastian
Und das läuft unter dem Schwachwort CRON, also das ist das System, was das sozusagen alle Stunde oder einmal am Tag startet, typischerweise, auf Lienungssystemen. Und jetzt will man eigentlich gerne wissen, wenn es sozusagen nicht aufgeräumt wurde, sage ich jetzt mal, das will man gerne mitbekommen. Und es stellt sich halt raus, es ist leider gar nicht so einfach mitzubekommen, weil ich
Tobias
oder einmal am Tag startet, typischerweise, auf Linux-Systemen. Und jetzt will man eigentlich gerne wissen, wenn sozusagen nicht aufgeräumt wurde, sage ich jetzt mal. Das will man gar nicht mitbekommen, weil es stellt sich halt raus, es ist leider gar nicht so einfach mitzubekommen, weil ich sonst ja immer auch was offene Fehler im Alert mache, also sprich ich
Sebastian
Sonst ja immer auf einen Fehler einen Alert mache. Also sprich, ich sage halt, wenn ein Fehler kommt, dann will ich das gerne wissen. Wenn meine Seite nicht verfügbar ist, dann will ich das gerne wissen. Und jetzt habe ich auf einmal das Szenario, wenn was nicht passiert ist, wenn mein Backup nicht gelaufen ist innerhalb von 24 Stunden, dann will ich das wissen. Und...
Tobias
Und jetzt haben wir das Szenario, wenn was nicht passiert ist, wenn ein Backup nicht gelaufen ist von 24 Stunden, dann will ich das wissen. Und das ist auf jeden Fall so ein Punkt. Da haben wir eine eigene Lösung gebaut, die ist ziemlich simple. Funktioniert quasi so, dass nach einem Backup oder nach einem Import oder nach einer Datenanalyse
Sebastian
Das ist auf jeden Fall so ein Punkt. Da haben wir eine kleine eigene Lösung gebaut. Die ist eigentlich ziemlich simpel. Funktioniert quasi so, dass nach einem Backup oder nach einem Import oder nach einer Datenanalyse, egal welchen Job man macht, muss man am Ende noch mal einen HTTP-Request, also einen Webrequest, an so einen Analysedienst schicken. Und was der macht, ist, wenn er nicht
Tobias
Und was ja macht, ist, wenn ein nicht
Sebastian
Und das ist eigentlich auch so ein Dienst, der uns schon sehr, sehr viel
Sebastian
In dem Import- oder Backup-Beispiel merke ich nicht erst, wenn ich das Backup bräuchte, dass ich die Chance in Ruhe habe, wenn alles entspannt ist.
Tobias
Beispiel habe ich merkte nicht, erst wenn ich es mir gerade leuchte, oh Mist, der Lieferstein für einen halben Jahr nicht mehr, sondern unfällig. Ich habe die Chance auch in Ruhe, wenn noch alles entspannt ist, halb nicht so zu kümmern, dass der halt auch wirklich noch
Sebastian
mich darum zu kümmern, dass es auch wirklich läuft. Genauso auch bei Importen oder bei irgendwelchen Aufräumarbeiten im Hintergrund, die zum Beispiel dann schließlich der Kreis zu einer vollen Platte führen können beispielsweise. Das sind alles solche Dinge, da ist es total hilfreich auch mitzubekommen, wenn bestimmte System-Dinge im Hintergrund halt nicht passieren, damit halt meine Anwendung nicht verdreckt, in Anführungszeichen.
Sebastian
einfach weiß, hier wurde regelmäßig durchgeputzt, ohne dass ich jeden Tag manuell hinterher gucken muss. Das versuchen wir zu vermeiden, wir versuchen alles so viel wie möglich im Betrieb zu automatisieren, damit wir halt einfach Zeit haben, uns langfristig um Themen zu kümmern und auch um neue Projekte natürlich.
Tobias
Zum Schluss die nicht abgesprochene Gretchenfrage. Wer überwacht denn die Überwachung?
Sebastian
Das Problem hatten wir natürlich auch schon in der Vergangenheit. Mittlerweile ist es so, dass wir da bestimmte Sachen auch überwachen. Also zum Beispiel, wir wissen halt, wenn keine Logs mehr ankommen, gibt es eine Alert beispielsweise. Einfach weil wir wissen, es muss einfach eine gewisse Grundmenge an Alerts durchkommen.
Tobias
Mittlerweile ist es so, dass wir da bestimmte Sachen auch überwachen. Also zum Beispiel, wir wissen halt, wenn keine Logs in der Hand kommen, dann erlönt es beispielsweise. Einfach weil wir wissen, es muss einfach eine gewisse Grundmenge an Erläutern durchkommen. Es wird aber trotzdem immer aus meinen Ebenen, weil es da nicht mehr kommt, es lässt sich gar nicht hundertprozentig vermeiden. Das ist immer wieder bei unseren hundert Prozent. Genau, aber statistisch ist da schon relativ viel Wahn.
Sebastian
Es wird aber trotzdem immer Szenarien geben, wo man das halt nicht mitbekommt. Das lässt sich gar nicht hundertprozentig vermeiden. Man kann aber statistisch da schon relativ viel machen, wenn man einfach Erfahrungswerte hat, wie viel müsste man eigentlich von einem gewissen Problem regelmäßig bekommen. Und man bekommt natürlich auch eine Vorstellung, wie zuverlässig funktioniert eigentlich mein Monitoring-System. Also wir hatten zum Beispiel vor dem
Tobias
Das ist natürlich auch eine Vorstellung, weil es funktioniert eigentlich bei Monitoring-Systemen. Also wir hatten zum Beispiel vor dem Lab-Data, was ich erzählt hatte, mit der Infrastruktur-Monitoring, hatten wir dieses alles selber gestricktes System. Das war leider nicht besonders zuverlässig für diese Server-Statistiken. Das heißt, es fiel halt normalerweise beispielsweise, und jetzt haben wir auch das total hilfreich. Also das braucht man im Grunde genommen, wie gesagt, wir wechseln das nochmal, obwohl so ein
Sebastian
Netdata, was ich erzählt hatte, mit dem Infrastrukturmonitoring hatten wir dieses alles selber gestrickte System. Das war leider nicht so sonderlich zuverlässig für diese Server-Statistiken. Das heißt, das fiel halt immer mal aus beispielsweise. Deshalb war das total hilfreich. Also das war auch ein Grund, weshalb wir gesagt haben, wir wechseln das nochmal, obwohl so ein Wechsel in so einem zentralen System schon immer auch durchaus ein Effort ist. Also das ist nicht so eben mal getan, sondern da muss man schon ein bisschen Energie reinstecken, um das wirklich durchzuziehen. Ja.
Tobias
Ja sehr schön.
Tobias
Nach meinem Zettel sind wir alle Themen durchgegangen, die wir vorher besprochen haben. Ist dir während unseres Gesprächs noch etwas aufgefallen, was du zum Thema Monitoring und Alerting sagen möchtest, Sebastian? Ich möchte vielleicht mal einen Mini-Export zu den technischen Sachen, also was wir da so nutzen, geben. Einfach nur einen ganz konkreten Überblick zu geben. Also, bei den Leveled, Capital und SSL Monitoring,
Sebastian
das.
Sebastian
Ich würde vielleicht noch mal einen ganz kurzen Mini-Exkurs zu den technischen Sachen, also was wir da so nutzen, geben. Einfach um einen ganz konkreten Überblick zu geben. Also bei diesem Availability, Uptime und SSL Monitoring nutzen wir ein Open Source Tool namens Uptime Kuma. Da gibt es auch diverse Software-Service-Produkte, die man da verwenden kann. Aber für uns ist das Uptime Kuma da ziemlich gut.
Sebastian
Dann Infrastruktur-Monitoring, dann NET-Data, das hatte ich ja schon gesagt, das ist auch Open Source und hat auch eine Cloud-Variante, wie man möchte. Genau, anwendungsspezifisches Monitoring, da haben wir am meisten rein investiert. In der Vergangenheit haben wir sehr viel Verschiedenes ausprobiert, unter anderem diesen gesamten hier lsx-search-logs-kibana-Stack ganz, ganz früher. Mittlerweile sind wir bei ClickHouse als Datenbank, Vector als Log-Aggregator in Kombination mit NATS.io.
Tobias
Das ist auch Open Source und hat auch eine Cloud Variante, die man möchte. Genau andere Spezifische Monitoring haben wir am meisten rein investiert.
Sebastian
und Grafana für Dashboards und Alerting in der Ecke. Genau, und Cronmonitoring hatte ich ja schon gesagt, das ist eine kleine, selbstgebaute Lösung, die dieses Handling macht und die dann wiederum die Alerts auf den anderen Wegen halt triggert.
Tobias
Und LERTS, also Benachrichtigungen, kommen bei uns woran? Du hattest Slack schon gesagt. Genau, Slack. Und der zweite Dienst ist Notify.io. Da schreibt sich ja nichts. Das ist also N-T-F-Y.io. Also Notify, nur ohne Vogale. Ja, das ist auch ein schönes, kleines, cooles Open-Source-Projekt. Und das kann man sehr gut dafür verwenden, z.B. Code Qualifications aufs Handy zu bekommen. Und damit auch einzustellen, wie dringend sie wieder schlussweise.
Sebastian
Genau, im Slack. Und der zweite Dienst, den wir nutzen, ist Notify.io. Der schreibt sich allerdings ein bisschen. Also n-t-f-y.io. Also Notify, nur ohne hier Vokale. Genau, das ist auch ein schönes, kleines, cooles Open-Source-Projekt. Und das kann man sehr gut dafür verwenden, zum Beispiel Push-Notifications aufs Handy zu bekommen. Und damit halt auch einzustellen, wie dringend sind die beispielsweise.
Tobias
Ja, vielen Dank. Dann war das jetzt nochmal zum Abschluss der Überblick über die Systeme und Tools, die wir da im Einsatz haben, mit Schwerpunkt auf Open Source und Dinge, die wir auch selber hosten können und betreiben können, die wir dann auch wieder monitorn. Da schließt sich der Kreis oder ist es sozusagen wirklich ein Kreislauf.
Sebastian
Einfaches Hobby mit Schwerpunkt und Dinge, die wir auch selber posten können. Vielen Dank, Sebastian, für das Gespräch heute über das Thema 24x7np.
Tobias
Ja, vielen lieben Dank Sebastian für das Gespräch heute über das Thema 24 x 7. Wie verfügbar sind denn unsere Dienste und wie kriegen wir das mit und wie stellen wir sicher, dass unsere Dienste, die wir betreiben, verfügbar sind? Danke an alle Hörerinnen und Hörer fürs Zuhören. Wenn ihr Feedback oder Fragen habt, schreibt uns gerne entweder per E-Mail oder auf unseren Social Media Kanälen.
Tobias
Und alle Themen und Folgen, die wir in dieser Podcast-Folge angesprochen haben, findet ihr wie immer in den Shownots. Dann bleibt mir an dieser Stelle nur noch zu sagen, vielen Dank fürs Zuhören und bis zum nächsten Mal. Macht's gut. Tschüss.
Sebastian
Vielen Dank fürs Zuhören und bis zum nächsten Mal.