Wie Sie das Beste aus den nine SLA-Produkten für Managed Services mit Statuscake herausholen

Eric Funk Apr 16, 2020
Wie Sie das Beste aus den nine SLA-Produkten für Managed Services mit Statuscake herausholen

Als Kunde von nine können Sie sich sicher sein, dass wir alles daran setzen, Ihren Webserver oder Ihre Datenbank am Laufen zu halten. Wir haben erst kürzlich unser Monitoring durch Prometheus /Alertmanager ersetzt, aber trotz dieser stark verbesserten Technologie haben wir immer noch einen ungedeckten Bereich, nämlich alles was vom Kunden selber auf unserer Infrastruktur betrieben wird. Das sind traditionell Webseiten oder kundenspezifische Anwendungen wie Node.js oder Java-Prozesse.

Es stellt sich die Frage, woher um alles in der Welt solle nine all diese Client-Anwendungen kennen und wie können sie diese mitten in der Nacht reparieren? Nun - wir haben eine ehrliche Antwort - wir wissen es nicht!

Weil wir starke Partnerschaften mit unseren Kunden aufgebaut haben, kennen wir zwar mit der Zeit einige Anwendungen - dennoch ist dies nicht zuverlässig, weil diese sich im Laufe der Zeit ändern und wir nicht im Zentrum der Entwicklung stehen.

Wie kann nine ein Service Level Agreement (SLA) für Ihre Anwendung anbieten?

Die Antwort ist einfach - mit Ihrer Hilfe!

Als Teil des SLA-Bestellprozesses erhalten Sie von unserem Sales ein Formular, in dem Sie um einen String Check, einen Massnahmenplan und einen Eskalationsplan gebeten werden. Wenn Sie ihre Applikation nicht selbst entwickelt haben, kann dies manchmal ein langwieriger Prozess sein. Aber vertrauen Sie uns - es lohnt sich. 

Lassen Sie uns mit dem String-Check beginnen. Selbst wenn wir unser Bestes getan haben und Ihr Webserver läuft, bedeutet das nicht unbedingt, dass Ihre Anwendung funktioniert. Sie würden sagen - meine Website funktioniert, wenn ich die URL in meinen Browser eingebe und den gewünschten Inhalt bekomme. Richtig - aber wie sagen wir das einer Maschine? 

Wir verwenden Statuscake für diese Aufgabe. Statuscake besucht Ihre Website periodisch von verschiedenen weltweiten Orten aus, genau wie Sie selbst. Um false-positiv-Warnungen zu vermeiden, konzentrieren wir uns auf die Verwendung von Kontrollstandorten in Europa.

Was ist eine guter SLA String Check?

Im einfachsten Fall verwenden wir Statuscake, um zu überprüfen, ob Ihre Website einen HTTP 200 "OK"-Statuscode zurückgibt. Wenn Ihre Website einen anderen Statuscode wie zum Beispiel 50x oder 40x liefert, ist das ein Indikator für ein Problem. 

Das Problem hier ist, dass Ihre Anwendung möglicherweise selbst bei einem technischen Probleme einen 200-Statuscode zurückgibt. Sie als Person würden sofort sehen, dass es ein Problem gibt, aber Maschinen können das nicht!

Hier kommen die sogenannten String-Checks ins Spiel. Bei diesem Setup prüft Statuscake zusätzlich zum 200er-Antwort-Code auf einen spezifischen Text in der Server-Antwort. Dies könnte zum Beispiel ein Copyrighttext in der Fusszeile Ihrer Website oder ein Element sein, welches nicht sichtbar im HTML der Seite enthalten ist.

Es ist eine Verbesserung - aber trotzdem - was passiert wenn die Fehlerseite die gleiche Fusszeile verwendet oder wenn ein Editor mitten in der Nacht eine Änderung am Text vornimmt? Dies würde einen Alarm auslösen, aber es ist überhaupt nichts kaputt! Dem Pikettdienst zuliebe, der jetzt mitten in der Nacht alarmiert wird, sollten wir dies mit allen Mitteln verhindern! 

Damit kommen wir zur bevorzugten Option - einem speziellen Status-Check auf Ihrer Website. Es dauert einige Zeit, dies zu entwickeln, aber viele Web-Frameworks wie "Spring Boot" (siehe Aktuator) bieten dies bereits out of the box an.

Was macht einen guten Status-Check aus?

  • Ein Status-Check befindet sich unter einer speziellen URL - zum Beispiel https://www.mysite.com/status
  • Er ist von einer grafischen Neugestaltung oder Inhaltsaktualisierung nicht betroffen.
  • Er sollte niemals einen Redirect vornehmen.
  • Er prüft alle Subsysteme, die für das Funktionieren Ihrer Website erforderlich sind. Wenn Sie eine Datenbank verwenden - prüfen Sie, ob Sie Daten schreiben und lesen können. Wenn Sie einen Redis-Cache verwenden - prüfen Sie, ob er funktioniert. Und bitte - sagen Sie uns, welcher der Komponenten Probleme macht.
  • Verlassen Sie sich nicht auf externe Services. Ihr Status-Check sollte Ihre Anwendung widerspiegeln, die auf der nine Infrastruktur läuft. Externe Komponenten wie ein Payment Provider kann von uns nicht beeinflusst werden.
  • Wenn Sie neue Versionen Ihrer Anwendung bereitstellen und eine Ausfallzeit zu erwarten ist, sollte die String-Prüfung nicht fehlschlagen oder unzugänglich sein. 

Beispiel:

curl -I https://www.mysite.com/status
< Date: Tue, 04 Nov 2014 19:12:59 GMT
< Content-Type: application/json; charset=utf-8
< Status: 200 OK
{“status”:”ok”}
curl -I https://www.mysite.com/status
< Date: Tue, 04 Nov 2014 19:12:59 GMT
< Content-Type: application/json; charset=utf-8
< Status: 500 Internal Server Error
{“status”:”database schema has changed”}

Jetzt wissen wir, dass Ihre Website versagt und möglicherweise auch schon warum, aber wir wissen immer noch nicht, wie wir das beheben können.

Damit kommen wir zum sogenannten Massnahmenplan und zum Eskalationsplan.

Was ist ein guter Massnahmenplan?

Der Massnahmenplan ist ein Handbuch für den Pikettdienst. Er beschreibt detailliert, was in einem Notfall zu tun ist. Ohne einen Massnahmenplan werden wir natürlich Standardmassnahmen ergreifen, um Ihre Anwendung wieder online zu bringen (z.B. Überprüfung der Log-Dateien auf Anomalien, Neustart der Dienste, falls erforderlich). Wenn Sie uns jedoch einen Massnahmenplan zur Verfügung stellen, sind wir in der Lage, spezifische, auf Ihre Anwendung zugeschnittenen Massnahmen zu ergreifen und sie so schnell wie möglich wieder verfügbar zu machen.

Ein Massnahmenplan enthält zum Beispiel folgende Anweisungen:

  • zum Bereinigen anwendungsspezifischer Caches
  • wie wir eine spezielle Wartungsseite aktivieren können
  • wie die Anwendung neu zu starten ist 

Wir werden diese Anweisungen während des Onboarding-Prozesses gemeinsam durchsehen und wertvolles Feedback dazu geben, wie diese Probleme gelöst werden können, bevor sie tatsächlich zu einer fehlgeschlagenen Statusprüfung eskalieren.

Eine gute Faustregel lautet hier: Wenn die Anwendung oder eine Komponente das Problem von sich aus erkennen kann, sollten konkrete Massnahmen automatisiert werden, ohne dass unsere Hilfe benötigt wird.

Wenn der Ingenieur die Ursache des Problems nicht beheben kann, werden wir die im Eskalationsplan vorgesehenen Kontakte nutzen, um Ihren technischen Support zu erreichen. Statuscake bietet auch eine Benachrichtigungsfunktion, die wir aber noch nicht nutzen. 

Sind Sie ein Entwickler und haben Sie Feedback zu den Kriterien für ein gute Status-Checks? Bitte teilen Sie uns dies über die unsere Social-Media Kanäle mit. Wir sind sehr an Ihren Erfahrungen interessiert und nutzen Ihren Input gerne für weitere Änderungen an unseren Onboarding-Prozessen und den Massnahmenplänen.

Wenn Sie an unserem SLA-Produkt interessiert sind oder wenn Sie die Vorteile einer besseren Statusprüfung nutzen möchten, zögern Sie bitte nicht, uns zu kontaktieren. 

Jetzt nine  kontaktieren