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
 

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

66 Episoden

Artwork
iconTeilen
 
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

66 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