Lépjen offline állapotba az Player FM alkalmazással!
STP032: Hochverfügbarer Softwarebetrieb
Fetch error
Hmmm there seems to be a problem fetching this series right now. Last successful fetch was on January 02, 2025 14:02 ()
What now? This series will be checked again in the next day. If you believe it should be working, please verify the publisher's feed link below is valid and includes actual episode links. You can contact support to request the feed be immediately fetched.
Manage episode 354913206 series 2920733
Die heutige Episode beschäftigt sich neben dem offensichtlichen Hauptthema auch mit Prozenten, deren Bedeutung bedacht sein sollte, und dem Verhalten guter Manager. Deshalb sei hiermit eine Politik-Triggerwarnung ausgesprochen... aber nur eine kleine.
Shownotes
Schlagwort: Site Reliability Engineering (SRE)
- Hauptziel: "Schaffung skalierbarer und hochzuverlässiger Softwaresysteme"
Grundkonzept: Service Level
- SLO (Service Level Objective): selbstgewählter Indikator soll bis zu einem bestimmten Grad an 100% herangeführt werden (z.B. Zeiten, zu denen der Dienst erreichbar ist; Anteil der Anfragen, die in weniger als 1 Sekunde beantwortet werden; Anteil der Anfragen, die erfolgreich beantwortet werden)
- SLA (Service Level Agreement): SLO, der mit dem Kunden vertraglich vereinbart ist
- Beispiel: 99% Verfügbarkeit = bis zu 3,65 Tage Ausfall; 99,9% = bis zu 8,77 Stunden; 99,99% = bis zu 52 Minuten; 99,999% = bis zu 5,2 Minuten
Problem: die Unbekannten in der Gleichung
- Known Unknowns (bekanntes Unwissen): ich weiß, dass ich etwas nicht weiß (z.B. wann meine Festplatte ausfallen wird)
- Unknown Unknowns (unbekanntes Unwissen): ich weiß nicht mal, dass da etwas ist, was ich nicht weiß (z.B. dass meine angebliche 30-TB-Festplatte in Wahrheit nur eine 32-GB-Speicherkarte in einem großen Gehäuse ist)
- siehe auch: zur Wortherkunft der Begriffsgruppe "(un)known (un)knowns"
strukturierter Einblick in Applikationen mittels Instrumentierung
- Logging: Ereignisse innerhalb der Applikation werden als textförmiger Bericht (Log) aus der Applikation ausgeleitet und in einem Log-System durchsuchbar gemacht
- Monitoring: Zustand der Applikation wird in Form von Messdaten quantifiziert, in einer Zeitseriendatenbank abgelegt und in Dashboards aufbereitet (Beispielbild); Messdaten entweder direkt aus der Applikation selbst oder durch ein Extraprogramm von außen erhoben
- Alarmierung: Menschen werden benachrichtigt, wenn ein bestimmter Messwert eine bestimmte Schwelle überschreitet (oder eine Überschreitung projiziert ist, z.B. "die Festplatte läuft gerade voll und in einer Stunde ist sie komplett voll")
strukturierte Herangehensweisen beim Durchführen von Änderungen
- Configuration as Code: Änderungen werden möglichst nie manuell vorgenommen, sondern es wird ein Programm geschrieben (bzw. die Konfiguration für jenes Program angepasst), das die Änderungen vornimmt; bei Problemen ist ein Zurückrollen auf den letzten funktionierenden Zustand möglich
- Continuous Integration (CI): Änderungen an Code und Konfiguration fließen in ein System, das automatisch standardisierte Tests ausführt, um die Änderung auf Fehler zu prüfen; bei Erfolg automatische Übernahme der vorgeschlagenen Änderung in den veröffentlichten Code-Stand
- Continuous Delivery (CD): automatisches oder stark automatisiertes Ausrollen von Änderungen an Code und Konfiguration von Testsystemen in Verifikationssysteme in Produktivsysteme
- Rolling Upgrade: bei Systemen mit mehreren gleichartigen Komponenten werden die Komponenten nacheinander durch die neue Version ersetzt, damit das Ausrollen für den Kunden unsichtbar ist und bei Fehlern frühzeitig gestopppt werden kann
- Canary Deployment: Ausrollen einer Änderung zunächst nur in einem kleinen Teil des Systems; bei Problemen ist nur der kleine Teil betroffen (siehe auch Ankündigungen der Form "diese Funktion ist zurzeit nur für ausgewählte Kunden verfügbar")
strukturierter Umgang mit Alarmen/Fehlern
- standardisierte Abläufe ("Playbooks") für Alarme
- Postmortem-Analyse mindestens nach signifikanten Fehlern (Was ist passiert? Was war der tatsächliche Grund? Was ist bei der Bekämpfung des Problems gut/schlecht gelaufen? Was können wir besser machen?)
- Fehlerkultur: Das Hauptziel soll nicht sein, einen Schuldigen zu finden, sondern das Problem möglichst schnell zu beheben und dann dafür zu sorgen, dass das Problem nie wieder auftritt.
- Parallelen zum Toyota-Produktionssystem
im Gespräch erwähnt (im Kontext des Gesetzesvorhabens zur Chatkontrolle):
67 epizódok
Fetch error
Hmmm there seems to be a problem fetching this series right now. Last successful fetch was on January 02, 2025 14:02 ()
What now? This series will be checked again in the next day. If you believe it should be working, please verify the publisher's feed link below is valid and includes actual episode links. You can contact support to request the feed be immediately fetched.
Manage episode 354913206 series 2920733
Die heutige Episode beschäftigt sich neben dem offensichtlichen Hauptthema auch mit Prozenten, deren Bedeutung bedacht sein sollte, und dem Verhalten guter Manager. Deshalb sei hiermit eine Politik-Triggerwarnung ausgesprochen... aber nur eine kleine.
Shownotes
Schlagwort: Site Reliability Engineering (SRE)
- Hauptziel: "Schaffung skalierbarer und hochzuverlässiger Softwaresysteme"
Grundkonzept: Service Level
- SLO (Service Level Objective): selbstgewählter Indikator soll bis zu einem bestimmten Grad an 100% herangeführt werden (z.B. Zeiten, zu denen der Dienst erreichbar ist; Anteil der Anfragen, die in weniger als 1 Sekunde beantwortet werden; Anteil der Anfragen, die erfolgreich beantwortet werden)
- SLA (Service Level Agreement): SLO, der mit dem Kunden vertraglich vereinbart ist
- Beispiel: 99% Verfügbarkeit = bis zu 3,65 Tage Ausfall; 99,9% = bis zu 8,77 Stunden; 99,99% = bis zu 52 Minuten; 99,999% = bis zu 5,2 Minuten
Problem: die Unbekannten in der Gleichung
- Known Unknowns (bekanntes Unwissen): ich weiß, dass ich etwas nicht weiß (z.B. wann meine Festplatte ausfallen wird)
- Unknown Unknowns (unbekanntes Unwissen): ich weiß nicht mal, dass da etwas ist, was ich nicht weiß (z.B. dass meine angebliche 30-TB-Festplatte in Wahrheit nur eine 32-GB-Speicherkarte in einem großen Gehäuse ist)
- siehe auch: zur Wortherkunft der Begriffsgruppe "(un)known (un)knowns"
strukturierter Einblick in Applikationen mittels Instrumentierung
- Logging: Ereignisse innerhalb der Applikation werden als textförmiger Bericht (Log) aus der Applikation ausgeleitet und in einem Log-System durchsuchbar gemacht
- Monitoring: Zustand der Applikation wird in Form von Messdaten quantifiziert, in einer Zeitseriendatenbank abgelegt und in Dashboards aufbereitet (Beispielbild); Messdaten entweder direkt aus der Applikation selbst oder durch ein Extraprogramm von außen erhoben
- Alarmierung: Menschen werden benachrichtigt, wenn ein bestimmter Messwert eine bestimmte Schwelle überschreitet (oder eine Überschreitung projiziert ist, z.B. "die Festplatte läuft gerade voll und in einer Stunde ist sie komplett voll")
strukturierte Herangehensweisen beim Durchführen von Änderungen
- Configuration as Code: Änderungen werden möglichst nie manuell vorgenommen, sondern es wird ein Programm geschrieben (bzw. die Konfiguration für jenes Program angepasst), das die Änderungen vornimmt; bei Problemen ist ein Zurückrollen auf den letzten funktionierenden Zustand möglich
- Continuous Integration (CI): Änderungen an Code und Konfiguration fließen in ein System, das automatisch standardisierte Tests ausführt, um die Änderung auf Fehler zu prüfen; bei Erfolg automatische Übernahme der vorgeschlagenen Änderung in den veröffentlichten Code-Stand
- Continuous Delivery (CD): automatisches oder stark automatisiertes Ausrollen von Änderungen an Code und Konfiguration von Testsystemen in Verifikationssysteme in Produktivsysteme
- Rolling Upgrade: bei Systemen mit mehreren gleichartigen Komponenten werden die Komponenten nacheinander durch die neue Version ersetzt, damit das Ausrollen für den Kunden unsichtbar ist und bei Fehlern frühzeitig gestopppt werden kann
- Canary Deployment: Ausrollen einer Änderung zunächst nur in einem kleinen Teil des Systems; bei Problemen ist nur der kleine Teil betroffen (siehe auch Ankündigungen der Form "diese Funktion ist zurzeit nur für ausgewählte Kunden verfügbar")
strukturierter Umgang mit Alarmen/Fehlern
- standardisierte Abläufe ("Playbooks") für Alarme
- Postmortem-Analyse mindestens nach signifikanten Fehlern (Was ist passiert? Was war der tatsächliche Grund? Was ist bei der Bekämpfung des Problems gut/schlecht gelaufen? Was können wir besser machen?)
- Fehlerkultur: Das Hauptziel soll nicht sein, einen Schuldigen zu finden, sondern das Problem möglichst schnell zu beheben und dann dafür zu sorgen, dass das Problem nie wieder auftritt.
- Parallelen zum Toyota-Produktionssystem
im Gespräch erwähnt (im Kontext des Gesetzesvorhabens zur Chatkontrolle):
67 epizódok
Minden epizód
×Üdvözlünk a Player FM-nél!
A Player FM lejátszó az internetet böngészi a kiváló minőségű podcastok után, hogy ön élvezhesse azokat. Ez a legjobb podcast-alkalmazás, Androidon, iPhone-on és a weben is működik. Jelentkezzen be az feliratkozások szinkronizálásához az eszközök között.