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

comment 1
Service Management

 

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:

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.

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…

1 Kommentar

  1. Pingback: Die Verfügbarkeits Pyramide – oder wie man zu hoch verfügbaren Services kommt – Teil 2 – Villar.cloud

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

w

Verbinde mit %s