Alle Artikel mit dem Schlagwort “Maslowsche Bedürfnishierarchie

Kommentare 0

Die Verfügbarkeits Pyramide – oder wie man zu hoch verfügbaren Services kommt – Teil 2

Im vorhergehenden Post zum Thema Verfügbarkeits Pyramide beschrieb ich die ersten drei Ebenen. Nun zu den weiteren.
Ebene vier, wenn man die ersten Drei „im Griff“ hat, ist ein ordentliches Testkonzept und gesetzte Release Verfahren. Ein gutes Zitat zur Frage wie weit man Testaufwände treiben sollte, geht wie folgt:

„If you haven’t tried it, assume it’s broken.“

(Autor unbekannt)
Dem folgend gilt also alles als kaputt, solange nicht das Gegenteil nachweisbar ist. Das ist eine vielerorts untypische Vorgehensweise. Ist es doch traditionell so, dass man in ein System eindringt, oder ein Fehlverhalten auftrat. Folgt man der oben angeführten Haltung, geht man davon aus, dass bis zum Bestehen eines negativen Tests ein System als unbekannt gilt.
In der Softwareentwicklung gebt es dazu den Ansatz der Testgetriebenen Entwicklung. Dabei werden die Testfälle vor der Entwicklung der eigentlichen funktionalen Komponenten geschrieben. Nach dem Paradigma des Site Reliability Engineerings https://landing.google.com/sre/book/chapters/testing-reliability.html wird davon ausgegangen, dass man durch fundiertes und professionelles Testing die MTTR (Mean-Time-To-Repair) reduzieren und damit die MTBF (Mean-Time-Between-Failures) steigern kann:

It’s possible for a testing system to identify a bug with zero MTTR. Zero MTTR occurs when a system-level test is applied to a subsystem, and that test detects the exact same problem that monitoring would detect. Such a test enables the push to be blocked so the bug never reaches production (though it still needs to be repaired in the source code). Repairing zero MTTR bugs by blocking a push is both quick and convenient. The more bugs you can find with zero MTTR, the higher the Mean Time Between Failures (MTBF) experienced by your users.

Klassisch gibt es drei Testtypen:

  • Unit Tests, zum Testing einzelner Komponenten
  • Integrationstests, zum Testen der Komponenten im Verbund
  • Systemtests, zum Testen ganzer Umgebungen unter Simulation bestimmter Thesen (wie z.B. „Kann 10.000 User Sessions standhalten“)

Als nächster Aspekt der Pyramide wird das Capacity Planning angesehen. Also der kontrollierte Umgang mit der vorhandenen und basierend auf Trends oder Annahmen benötigten Kapazität. Bei eigenen Installationen („On-Premise“) sind hier in der Regel auch Investitionsplanungen und Entscheidungen abhängig. Aber auch beim Einsatz von Cloud Service Providern gilt es diese Disziplin sachgerecht durchzuführen. Denn man möchte/muss die etwaigen Ressourcen bei Zeiten verfügbar haben (Spin-up, Konfiguration laden, Applikation ausrollen, etc.).
Die letzten beiden Punkte der Pyramide würde ich tendenziell zusammenfassen: Development und Product.
Es ist essentiell, dass die Produktentwicklung von vornherein Skalierung vorsieht. Dazu benötigt es die richtigen Komponenten, wie Analyse Tools. Aber auch einen passenden Produktstart, wie zum Beispiel eine Einführung in Phasen („Beta“, Closed User Group, usw.). Bei Google haben sie auch dafür eine eigene Rolle, die des Launch Coordination Engineers. Diese kümmern sich um die korrekte Bearbeitung der Lauch Coordination Checklist.

Kommentare 1

Die Verfügbarkeits Pyramide – oder wie man zu hoch verfügbaren Services kommt

 
Im Jahr 2017 werden (digitale) Produkte oder Services wahrscheinlich komplett oder weitgehend auf Basis von Cloud Services konzipiert. Mindestens jedoch greifen sie in Teilen auf Cloud Services zurück. Daher ist es essentiell einen sauberen Überblick über deren Zustand zu gewährleisten.
Im Zuge des SRE (Site Reliability Engineering) Ansatzes von Google gibt es dazu ein Modell, was die notwendigsten Disziplinen strukturiert, die Site Reliability Hierachy:

sre-pyramide

Service Reliability Hierarchy by https://landing.google.com/sre/book/chapters/part3.html


An der Bedürfnispyramide von Maslow orientiert, bietet diese Pyramide eine gute Struktur zur Orientierung beim Betrieb eines Produktes/Service.
Der eigentliche „No-Brainer“ ist die erste Stufe: Monitoring. Es sollte klar sein, dass ohne ein ordentlich implementiertes Monitoring der Betrieb de-facto im Blindflug läuft.

Without monitoring, you have no way to tell whether the service is even working; absent a thoughtfully designed monitoring infrastructure, you’re flying blind. Maybe everyone who tries to use the website gets an error, maybe not—but you want to be aware of problems before your users notice them.

Die gute Nachricht, die Implementierung ist heutzutage ein Kinderspiel. Alleine in der Cloud Native Landscape tummeln sich zahlreiche neue und alte Vertreter. Es gibt keine Ausreden für ein mangelhaftes Monitoring.

CloudNativeLandscape_v0.9.4

https://github.com/cncf/landscape


Eine Ebene darüber ist die Incident Response angesiedelt, also der aktive Umgang mit Störungen („Incidents“). Nach klassischem ITIL bedeutet das umgehende Lösung, im Zweifel mittels Work-Around (Reboot tut gut). Im Rahmen eines Incidents muss nicht zwingend eine finale Lösung implementiert werden. Wichtig ist, die geordnete Wiederherstellung der eigentlichen Funktion. Meiner Meinung nach sollten Incidents auch immer sinnvoll strukturiert aufgezeichnet werden. Also sinnvolle Datenbanken führen, aus denen man Statistiken ziehen und Analysen fahren kann:

  • Welche (wiederkehrende) Muster kann man erkennen?
  • Wo treten Probleme auf?
  • Was kann ich daraus ableiten?

Nahtlos reiht sich dann die nächste Ebene ein, Post Mortem und Root Cause Analyse. In der ITIL Welt ist das oftmals auch Teil der Problem Management Disziplin. Im Kern geht es darum einerseits zu lernen was schief gelaufen ist und andererseits proaktiv in der Zukunft die Art Fehler zu vermeiden.
Ein solides Port-Mortem hört sich leichter an, als es ist. Sehr schnell entwickelt sich hier eine Blaming Kultur. Das wichtigste ist „sachlich bleiben“:

Best Practice: Avoid Blame and Keep It Constructive

Blameless postmortems can be challenging to write, because the postmortem format clearly identifies the actions that led to the incident. Removing blame from a postmortem gives people the confidence to escalate issues without fear. It is also important not to stigmatize frequent production of postmortems by a person or team. An atmosphere of blame risks creating a culture in which incidents and issues are swept under the rug, leading to greater risk for the organization

Mehr zu den anderen Ebenen in einem zukünftigen Post…