Alle Artikel in der Kategorie “Service Management

Kommentare 0

Chaos Engineering – das Impfen unter den Operations Modellen

Vor ein paar Wochen stellte ich fest, dass mein Impfschutz gegen Tetanus vor 21 Jahren abgelaufen war. Das war dann in der Tat notwendig. Wikipedia definiert den Begriff einer Impfung wie folgt:

Eine Impfung, auch Schutzimpfung oder Vakzination (ursprünglich die Infektion mit Kuhpockenmaterial; von lateinisch vacca, ‚Kuh‘) genannt, ist die Gabe eines Impfstoffes mit dem Ziel, vor einer (übertragbaren) Krankheit zu schützen. Sie dient der Aktivierung des Immunsystems gegen spezifische Stoffe. Impfungen wurden als vorbeugende Maßnahme gegen Infektionskrankheiten entwickelt.

Das past zu einer Analogie, die ich im Cloudcast #299 gehört hatte. Dort ging es um die Disziplin des Chaos Engineerings, einem Betriebsmodell bei dem es darum geht, dass (verteilte) IT-Systeme niemals perfekt sind. Vielmehr ist die These sogar, dass sie verwundbar sind und eher die Frage berechtigt ist, wem diese Verwundbarkeit zuerst auffällt. Dem dafür verantwortlichen Betreiber oder jemand externem.1
Der Begriff Chaos Engineering leitet sich am ehesten von einem Modell, dass bei Netflix angewandt wird ab. Dort wurde vor Jahren ein Tool namens Chaos Monkey genutzt (und für Jedermann veröffentlicht), welches zufällig bestimmte Komponenten eines Systems bewusst im laufenden Betrieb zum Absturz bringt. Damit kann dann validiert werden, on das System als Ganzes wirklich hinreichend ausfallsicher ausgelegt ist.
Die Denke ist, Fehler werden passieren, die Frage ist nur wann. Und wie sehr kann ich den „Impact“ durch diesen Fehler im Falle minimieren.
Hier kommt die Analogie zur Impfung ins Spiel. Damit mein Immunsystem zur Abwehr gegen bestimmte Stoffe aktiviert wird, muss ich es zunächst einer kleinen Menge eben dieses Stoffes aussetzen.

Was sind die Prinzipien des Chaos Engineerings?

Hierzu bietet die eigens von Afficionados angelegte Seite PRINCIPLES OF CHAOS ENGINEERING eine gute Definition:

Chaos Engineering is the discipline of experimenting on a distributed system in order to build confidence in the system’s capability to withstand turbulent conditions in production.

Selbst wenn alle einzelnen Systeme einer verteilten Umgebung voll funktionstüchtig sind, kann es dennoch zu einer Nutzerbetreffenden Einschränkung kommen. Eben diese impliziten Abhängigkeiten sind in großen Systeme oftmals nur nach einer Störung herauszufinden (dran Denken, Lessons Learned nach einem Incident). Will man hier etwas „proaktiver“ Vorgehen, ist das Modell des Chaos Engineerings prädestiniert:

  1. Definiere den ‚steady state’, am besten in einer messbaren Form, aus dem das zu erwartende normale Verhalten Deines Systems hervorgeht. Wichtig ist hier meines Erachtens der Aspekt des messbaren. Das kann bei einer Webseite die Antwortzeit auf bestimmte Anfragen sein, am besten auf Anfragen, die eine Vielzahl von Backend-Services mit einbezieht.
  2. Stelle die Hypothese auf, dass sowohl die Kontrollgruppe, als auch die experimentelle Gruppe sich gleich verhalten werden.
  3. Definiere Variablen, die ein echtes Verhalten darstellen, wie denkbare Anzahl von abgestürzten Servern, reduzierter oder limitierter Netzwerkbandbreite, usw.
  4. Vergleiche die Experimentier und die Kontrollgruppe kontinuierlich. D.h. starte durchgängig Experimente, die durch die Veränderung der definierten Variablen geprägt sind.

Die Fortgeschrittenen führen die Experimente direkt in der Produktion aus. Naheliegend fängt man mit einem reduziertem Radius an und vergrößert diesen immer weiter. Im Idealfall ist das gesamte System eingebunden. Mir ist zudem immer wichtig, dass man die dennoch auftretenden Incidents und im wiederholten Falle Problems (nach ITIL Sprache) als Input für die Testfälle/Variablen hernimmt.

  1. Extern muss nicht limitiert sein auf einen externen „Angreifer“ im Security Sinne. Es kann sich dabei einfach um einen operationsfremden und zu spät erkannten Incident handeln.
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…