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

Hinterlasse einen Kommentar
Service Management

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.

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