Jeder Systemadministrator kennt das: Die Systeme werden ausgiebig überwacht, alle Dienste scheinen zu funktionieren und trotzdem weist der Graph für Payment-Transaktionen Anomalien auf. Die Zugriffszeiten auf die Bezahlsysteme sind um den Faktor 10 in die Höhe geschnellt. Manuelle Tests der entsprechenden Komponenten zeigen keine Probleme und auch der Dienst, der die Metrik der Payment-Schnittstelle des externen Dienstleisters prüft, meldet keine Fehler.
Nach intensiver Recherche ist dann endlich der Übeltäter entdeckt: Ein Bug in der nächtlich aktualisierten Middleware verzögert den reibungslosen Zahlungsablauf. Die Administratoren rollen die Release zurück – und die Performanceprobleme beim Zahlungsverkehr gehören der Vergangenheit an.
Damit solche Abläufe nicht zur Gewohnheit werden, arbeiten Software-Entwickler oft mit agilen Methoden, die den Entwicklungsprozess maßgeblich beeinflussen. So stehen nicht mehr ausschließlich Programmiertätigkeiten im Vordergrund, sondern auch umfangreiches Testen der Software sowie die enge Zusammenarbeit mit allen Projektbeteiligten. Diese Prinzipien bilden die Basis des "Test Driven Development" und des "Behavioral Driven Development".
Der wesentliche Gedanke beim Test Driven Developments ist es sicherzustellen, dass Software nicht nur einfach funktioniert, sondern sich auch exakt so verhält, wie der Benutzer es erwartet. Um dies zu erreichen, werden automatisierte Testsysteme, zum Beispiel Hudson [1] oder Cruisecontrol [2] eingesetzt, die bestimmte Funktionen der Applikation regelmäßig testen.
Behavioral Driven Development erweitert die Prinzipien des Test Driven Developments dahingehend, dass auch Nicht-Entwickler an dem Prozess der Software-Entwicklung teilhaben sollen. Hier steht das Einbeziehen aller an einem Projekt beteiligten Personen im Vordergrund. Um den Projektbeteiligten größtmögliche Einsicht in die Funktionsweise der Applikation zu ermöglichen, sollen diese unter anderem in die Lage versetzt werden, eigene Szenarien für das automatisierte Testen beizusteuern. Dies erleichtert oder ermöglicht überhaupt erst der Einsatz einer Domänen-spezifischen Sprache (Domain-specific Language, DSL), die sich am herkömmlichen Sprachgebrauch orientiert und nicht als Programmiersprache anzusehen ist.
Solche Überlegungen beherzigt Cucumber-Nagios [3] und ermöglicht so die Anwendung der beiden oben genannten Prinzipien auf den Infrastrukturbereich. Nicht mehr nur die bloße Funktion (die Applikation läuft) wird überwacht, sondern der Prozess, der zum gewünschten Ergebnis führen soll (die Applikation verhält sich wie beabsichtigt). Zudem haben alle Mitarbeiter die Möglichkeit, eigene Checks für das Monitoringsystem beizusteuern, ohne dass der Administrator Zeit für das Schreiben spezieller Funktionen aufwenden muss. Auch dafür gibt es bereits ein Buzzword: Behavioral Driven Infrastructure.
Cucumber-Nagios wird ganz klassisch als Plugin in ein beliebiges Open-Source-Monitoringssystem eingebunden, das die Rückgabewerte von Nagios-Plugins interpretieren kann. Cucumber-Nagios basiert auf Cucumber [4] , einer weitverbreiteten Software zum automatisierten Testen von Ruby, Java, Dotnet, Flex sowie jeglicher Webanwendungen und nutzt dessen DSL Gherkin [5] .
Im Maschinenraum arbeitet außerdem Webrat, ein Ressourcen-schonender Browser-Simulator, der für Testszenarien via HTTP zum Einsatz kommt. Zusätzlich ist die Mechanize-Bibliothek [6] eingebunden, die Funktionen für automatisierte Interaktionen auf einer Website beisteuert. Dank der Ruby-Implementation Net::SSH [7] des SSH2-Client-Protokolls ist außerdem SSH-Unterstützung mit an Bord.