Im Zweifel läuft in den meisten (ordentlich geführten) Unternehmen ein Monitoring-Tool wie Nagios oder Hyperic. Diese Tools messen mehr oder weniger regelmäßig bestimmte Betriebswerte auf dem Server und geben Alarm (per e-Mail und/oder SMS), wenn bestimmte Grenzwerte unter- oder überschreiten werden.
Die Überprüfung der technischen Faktoren ist schön und gut, reicht aber nicht aus. Wenn ein Programmierer aber beim letzten Update die “Bestellung abschicken” Seite im e-Commerce Shop zerschossen hat bringt es nicht viel zu messen, ob die Festplatte voll ist. Und zu warten bis die Horror-Meldungen im Support eintrudeln kostet Geld.
Die Lösung? Monitoring der Key Performance Indicators! (die deutsche Sprach stirbt, sorry). Wie funktioniert das ganze?
Die Marketing und Operations Leute im Unternehmen überlegen zusammen(!) mit den Techies, welche Kennzahlen eine potenzielle Bedrohung des Umsatzes oder der Kundenzufriedenheit messbar machen können. Diese Werte lässt man dann regelmäßig überprüfen und ggf. Alarm schlagen.
Einige Beispiele:
- Keine Anmeldung seit X Minuten? Warning. Immernoch keine Anmeldung seit Y Minuten? Panic
- Keine Bestellung seit X Minuten, obwohl es mitten am Tag ist? Panic
- Konversionsrate einer Landing Page sinkt massiv? Warning
- Keine Artikel werden in die Warenkörbe gelegt? Panic
Es geht also darum eine Liste von 5-10 Fehlern zu finden und messbar zu machen, die direkt auf den Umsatz durchschlagen und wo alle panisch losrennen müssen, wenn da was schief geht. Für diese Werte sollten typische Durchschnittswerte gefunden werden (e.g. normalerweise bestellt alle 3 Minuten jemand das Produkt X) und eine akzeptable Abweichung definiert werden (z.B. eine Standardabweichung). Meistens pendeln sich diese Werte auch langsam ein, während alle Erfahrungen sammeln (und die Techniker von den Fehlalarmen genervt werden).
Dabei müssen es immer Indikatoren sein, die man relativ fix aus der Datenbank ziehen kann, ohne das Data Warehouse anzuschmeissen. Schliesslich werden die meistens alle 5 Minuten oder so abgerufen.
Ein ausgeklügeltes, regelmäßiges KPI Monitoring lässt die Techniker ruhiger schlafen und hilft den GAU zu vermeiden: wenn der Kundendienstmitarbeiter mit einem hochroten Kopf angestürmt kommt und meint die Anmeldung wäre kaputt. Mit KPI Monitoring kann man zumindest sagen: das weiss ich schon, danke, wir arbeiten dran.
Zusätzlich kann man mit Nagios komplette funktionale Tests automatisiert abwickeln (wie hier beschrieben). Aber das ist ein anderes Thema. Ausserdem muss ich mich jetzt mal mit dem Thema “Suchen optimieren” beschäftigen. Ole ole!
Hm, zu JMeter… ist Nagios dafür nicht etwas “fehl” am Platz? Macht ein JMeter im CruiseControl nicht viel mehr Sinn? Siehe dazu auch http://nohn.org/blog/archives/8-Continuous-Builds-with-CruiseControl,-Ant-and-PHPUnit.html
Wir nutzen CruiseControl u.a. zur automatisierten Copy&Paste Detection, Einhaltung von Coding Style Guidelines, Zend Code Analyzing, PHPUnit und Selenium Tests sowie zur Erstellung von Code Metriken als vollständig integriertes CI Tool.
Björn Schotte
August 22nd, 2007
Hi Björn. Danke für deinen Kommentar!
Ich glaube die beiden Sachen schliessen sich nicht aus, sondern sollten sich ergänzen.
Phing, Simpletest & Co. sind super um einen stabilen Build zu erreichen. Die messen aber auch nur, was sie messen können.
Ich bin ein grosser Freund davon auch im Produktivsystem KPIs zu messen. Ein einfaches Beispiel: Das SSL Zertifikat ist abgelaufen. Aufgrund der Fehlermeldung geht die Anmeldequote in den Keller. Eine Probe auf die Registrierungen würde zumindest schnell Alarm schlagen. Weitere Beispiele wäre fehlkonfigurierte Firewalls, Applikationsfehler die nicht getestet wurden usw.
Aber klar, einen stabilen Build sollte man trotzdem vorher erreichen. Nagios ist eine weitere kontrollierende Instanz.
Jan
August 22nd, 2007