Artwork

Inhalt bereitgestellt von Stefan Majewsky and Xyrillian Noises. Alle Podcast-Inhalte, einschließlich Episoden, Grafiken und Podcast-Beschreibungen, werden direkt von Stefan Majewsky and Xyrillian Noises oder seinem Podcast-Plattformpartner hochgeladen und bereitgestellt. Wenn Sie glauben, dass jemand Ihr urheberrechtlich geschütztes Werk ohne Ihre Erlaubnis nutzt, können Sie dem hier beschriebenen Verfahren folgen https://de.player.fm/legal.
Player FM - Podcast-App
Gehen Sie mit der App Player FM offline!

STP032: Hochverfügbarer Softwarebetrieb

1:15:59
 
Teilen
 

Fetch error

Hmmm there seems to be a problem fetching this series right now. Last successful fetch was on January 02, 2025 14:02 (18d ago)

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
Inhalt bereitgestellt von Stefan Majewsky and Xyrillian Noises. Alle Podcast-Inhalte, einschließlich Episoden, Grafiken und Podcast-Beschreibungen, werden direkt von Stefan Majewsky and Xyrillian Noises oder seinem Podcast-Plattformpartner hochgeladen und bereitgestellt. Wenn Sie glauben, dass jemand Ihr urheberrechtlich geschütztes Werk ohne Ihre Erlaubnis nutzt, können Sie dem hier beschriebenen Verfahren folgen https://de.player.fm/legal.

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

  • 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):

  continue reading

67 Episoden

Artwork
iconTeilen
 

Fetch error

Hmmm there seems to be a problem fetching this series right now. Last successful fetch was on January 02, 2025 14:02 (18d ago)

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
Inhalt bereitgestellt von Stefan Majewsky and Xyrillian Noises. Alle Podcast-Inhalte, einschließlich Episoden, Grafiken und Podcast-Beschreibungen, werden direkt von Stefan Majewsky and Xyrillian Noises oder seinem Podcast-Plattformpartner hochgeladen und bereitgestellt. Wenn Sie glauben, dass jemand Ihr urheberrechtlich geschütztes Werk ohne Ihre Erlaubnis nutzt, können Sie dem hier beschriebenen Verfahren folgen https://de.player.fm/legal.

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

  • 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):

  continue reading

67 Episoden

Alle Folgen

×
 
Loading …

Willkommen auf Player FM!

Player FM scannt gerade das Web nach Podcasts mit hoher Qualität, die du genießen kannst. Es ist die beste Podcast-App und funktioniert auf Android, iPhone und im Web. Melde dich an, um Abos geräteübergreifend zu synchronisieren.

 

Kurzanleitung

Hören Sie sich diese Show an, während Sie die Gegend erkunden
Abspielen