STP032: Hochverfügbarer Softwarebetrieb

<p>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.</p><h2>Shownotes</h2><ul>
<li>
<p>Schlagwort: <a href="de.wikipedia.org/w/index.php?title=Site_Reliab… Reliability Engineering (SRE)</a></p>
<ul>
<li>Hauptziel: "Schaffung skalierbarer und hochzuverlässiger Softwaresysteme"</li>
</ul>
</li>
<li>
<p>Grundkonzept: Service Level</p>
<ul>
<li><a href="en.wikipedia.org/w/index.php?title=Service-lev… (Service Level Objective)</a>: 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)</li>
<li>SLA (Service Level Agreement): SLO, der mit dem Kunden vertraglich vereinbart ist</li>
<li>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</li>
</ul>
</li>
<li>
<p>Problem: die Unbekannten in der Gleichung</p>
<ul>
<li><strong>Known Unknowns</strong> (bekanntes Unwissen): ich weiß, dass ich etwas nicht weiß (z.B. wann meine Festplatte ausfallen wird)</li>
<li><strong>Unknown Unknowns</strong> (unbekanntes Unwissen): ich weiß nicht mal, dass da etwas ist, was ich nicht weiß (z.B. <a href="vice.com/en/article/akek8e/walmart-30tb-ssd-ha… meine angebliche 30-TB-Festplatte in Wahrheit nur eine 32-GB-Speicherkarte in einem großen Gehäuse ist</a>)</li>
<li>siehe auch: <a href="de.wikipedia.org/w/index.php?title=There_are_k… Wortherkunft der Begriffsgruppe "(un)known (un)knowns"</a></li>
</ul>
</li>
<li>
<p>strukturierter Einblick in Applikationen mittels Instrumentierung</p>
<ul>
<li><strong>Logging:</strong> Ereignisse innerhalb der Applikation werden als textförmiger Bericht (Log) aus der Applikation ausgeleitet und in einem Log-System durchsuchbar gemacht</li>
<li><strong>Monitoring:</strong> Zustand der Applikation wird in Form von Messdaten quantifiziert, in einer <a href="de.wikipedia.org/w/index.php?title=Zeitreihend…; abgelegt und in Dashboards aufbereitet (<a href="en.wikipedia.org/w/index.php?title=Grafana&…;); Messdaten entweder direkt aus der Applikation selbst oder durch ein Extraprogramm von außen erhoben</li>
<li><strong>Alarmierung:</strong> 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")</li>
</ul>
</li>
<li>
<p>strukturierte Herangehensweisen beim Durchführen von Änderungen</p>
<ul>
<li>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</li>
<li><a href="de.wikipedia.org/w/index.php?title=Kontinuierl… Integration (CI)</a>: Ä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</li>
<li><a href="de.wikipedia.org/w/index.php?title=Continuous_… Delivery (CD)</a>: automatisches oder stark automatisiertes Ausrollen von Änderungen an Code und Konfiguration von Testsystemen in Verifikationssysteme in Produktivsysteme</li>
<li>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</li>
<li>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")</li>
</ul>
</li>
<li>
<p>strukturierter Umgang mit Alarmen/Fehlern</p>
<ul>
<li>standardisierte Abläufe ("Playbooks") für Alarme</li>
<li>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?)</li>
<li>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.</li>
<li>Parallelen zum <a href="de.wikipedia.org/w/index.php?title=Toyota-Prod…;
</ul>
</li>
<li>
<p>im Gespräch erwähnt (im Kontext des Gesetzesvorhabens zur Chatkontrolle):</p>
<ul>
<li><a href="c3d2.de/news/pentaradio24-20220524.html"&… vom Mai 2022</a> und ganz aktuell <a href="c3d2.de/news/pentaradio24-20230124.html"&… Januar 2023</a></li>
<li><a href="logbuch-netzpolitik.de/lnp429-endlich-sind-wir…: Endlich sind wir am Anfang angekommen</a></li>
<li><a href="logbuch-netzpolitik.de/lnp430-die-groesste-koa…: Die größte Koalition aller Zeiten</a></li>
</ul>
</li>
</ul>