Wenn man die Blogs der Technikteams großer Websites wie Wordpress.com, Flickr, Etsy und anderer verfolgt, möchte man seinen Augen kaum trauen: Von bis zu fünfzig Deployments in die Livesysteme pro Tag ist da die Rede, von fünfundzwanzigtausend Releases in etwas über vier Jahren und so weiter und so fort [1], [2]. Ich weiß nicht, wie es Ihnen geht, aber ich fühle mich dabei schlecht. Ich erinnere mich schmerzlich zurück an betriebliche Abnahmen, die nach Monaten daran gescheitert sind, dass noch irgendeine Betriebsdokumentation gefehlt hat. Sie scheiterten auch an Staging-Phasen, die oft länger gedauert haben als die eigentliche Entwicklung. Und ich frage mich: Was um alles in der Welt machen die eigentlich anders und vielleicht auch besser?
Zeitreise
Um das zu verstehen, reisen wir ein wenig in der Zeit zurück, ungefähr in das Jahr 2004/2005. Der IT-Markt hatte nach dem Zusammenbruch der DotCom-Blase im Frühjahr 2000 die Talsohle durchschritten und eine neue Gründergeneration begann vor allem in den Vereinigten Staaten den Grundstein für das zu legen, was man „Web 2.0“ nennt. Die Aufbruchsstimmung war ähnlich wie Ende der 1990er Jahre, aber eines war grundlegend anders: Investorengelder gab es diesmal nicht mehr für Visionen, sondern nur noch für laufende Software. Für Start-up-Unternehmer zu dieser Zeit bedeutete das, möglichst schnell zu geringstmöglichen Kosten ein erstes vorzeigbares Produkt auf den Markt zu bringen und es dann kontinuierlich zu erweitern und zu verbessern, sobald (und falls) das Geld anfing zu fließen. Die Revolution brachten dynamische Programmiersprachen wie Ruby und Webframeworks wie Rails, mit denen Applikationsentwicklung plötzlich so effizient möglich wurde wie nie zuvor (und deren Konzepte nebenbei bemerkt mittlerweile auch die Java-Welt maßgeblich beeinflusst haben). Und auch die Betriebsinfrastruktur wurde einfacher: Keine schwerfälligen Applikationsserver mehr, für deren Konfiguration und Betrieb Spezialisten und leistungsfähige Hardware gebraucht wurden, sondern leichtgewichtige Laufzeitumgebungen, die sich mit virtuellen Maschinen beim Hoster des Vertrauens begnügten. Fand ein Kunde ein Problem, wurde der Fehler behoben und eine neue Version in Produktion gebracht – das Ganze oft innerhalb von wenigen Stunden oder gar Minuten. Die Teams waren klein und motiviert, und für Entwicklung und Betrieb war meist ein und dieselbe Person zuständig. „Lean-Start-up“ nennt sich das mittlerweile, und es steht für nicht weniger als einen massiven Paradigmenwechsel.
„Die Realität ist in Wirklichkeit ganz anders!“ (Helmut Kohl)
Zurück in der klassischen Corporate-IT-Welt des Jahres 2011 ist davon noch nicht viel zu spüren. Agile Methoden haben sich zwar in der Softwareentwicklung inzwischen auf breiter Front durchgesetzt, und selbst in Traditionshäusern gehört es neuerdings zum guten Ton, dass man selbstverständlich „Scrum macht“, man ist ja schließlich nicht von gestern. Spätestens dort aber, wo Unternehmenssoftware dummerweise erst wirklich anfängt, einen Beitrag zur Wertschöpfung zu leisten, ist meist das Ende der agilen Fahnenstange erreicht. Unzählige Entwickler, Architekten und Projektleiter sind schon schier daran verzweifelt, das Ergebnis wochen- und monatelanger Mühe endlich über die Schwelle der heiligen Hallen des Rechenzentrums zu tragen. „Njet“, bekommen sie zu hören, „so geht das nicht“, und im Augenwinkel knallt noch der Schuh auf den Schreibtisch. Alles Schikane? Ziemlich sicher nicht, wenn wir einmal die Perspektive wechseln und die ganze Sache aus der Sicht eines Systemadministrators sehen. Stellen Sie sich vor, wie es ist, wenn Sie um drei Uhr morgens aus dem Bett geklingelt werden und versuchen müssen, ein geschäftskritisches System wieder ans Laufen zu bekommen, über das Sie kaum etwas wissen. Sie haben einen Waschzettel mit ein paar Hinweisen zum Starten und Stoppen und wissen bestenfalls ungefähr, wo die Log-Dateien liegen. Zu dumm, dass sich darin außer ein paar Java Exceptions kein Hinweis auf den Fehler findet – und von Java haben Sie als Unix-Experte ungefähr so viel Ahnung wie ein Schwein vom Klettern. Und um diese Zeit einen Entwickler ans Telefon zu bekommen, ist illusorisch, und das System ist nur eines von ungefähr fünfzig, die Sie und Ihre Kollegen betreuen müssen. Viel Spaß!
Sie sehen, worauf ich hinaus will; das Dilemma ist offensichtlich: Die Innovationszyklen in unserer Branche werden immer kürzer, der Markt ruft nach neuen Produkten, der Wettbewerb schläft nicht, wer rastet, der rostet. Die Fähigkeit zur ständigen Veränderung ist heute mehr denn je ein kritischer Erfolgsfaktor. Auf der anderen Seite: Ausfälle und Pannen haben in den allermeisten Fällen ihre Ursache in irgendeiner Veränderung an Bestehendem. Da ist es nur verständlich, dass im klassischen Systembetrieb Veränderung eher als Ausnahme gesehen wird und Prozessframeworks wie ITIL die Komplexität von Änderungsprozessen auch nicht gerade reduzieren. „If it ain’t broke, don’t fix it.“ – ich glaube, es gibt Administratoren, die das sogar als Aufdruck auf ihrem T-Shirt tragen.
Wenn Veränderung nun also für Unternehmen notwendig ist, um wettbewerbsfähig zu bleiben, gleichzeitig aber damit die Gefahr einhergeht, dass etwas schief läuft, gibt es eigentlich nur eine Lösung: notwendige und sinnvolle Veränderungen zulassen und gleichzeitig Mittel und Wege finden, das Risiko von Fehlern zu reduzieren. Und damit sind wir genau bei der Essenz dessen angekommen, was Unternehmen mit traditioneller Aufgabenteilung in der IT von Lean-Start-ups lernen können.
Kultur …
Zwei Dinge braucht es nämlich dazu: eine passende Unternehmenskultur und die geeigneten Praktiken und Werkzeuge. Der erste Teil, die Unternehmenskultur, ist der einfachste und der schwierigste zugleich. Der einfachste ist er, weil es im Kern nur darum geht, gemeinsam an einem Strang zu ziehen und zu verstehen und zu akzeptieren, dass beide Rollen – Entwicklung und Betrieb – ihren Beitrag zur Wertschöpfung eines Unternehmens zu leisten haben. Ein Rechner, auf dem nichts läuft, ist nun einmal nicht viel mehr als wertloses Blech. Und eine Software, die nicht betrieben wird, ist nur eine akademische Fingerübung. Der schwierigste ist er, weil die Realität leider meistens anders aussieht. Betriebsorganisationen werden eher an Uptime und Fehlerrate gemessen als zum Beispiel an der Flexibilität der Deployment-Prozesse – und für Entwickler und Projektleiter zählt die Anzahl der termin- und budgetgerecht umgesetzten Features nicht primär die Betriebsfreundlichkeit der Software. Dabei hilft es oft, rechtzeitig miteinander zu reden: Die Fehlermeldung „Configuration file foo.cfg not found at file system location /etc/foo“ etwa hilft einem Administrator einfach deutlich weiter als „Component foo.bar.Foo not configured“. Dennoch: kulturelle Änderungen brauchen Zeit, Energie und letztendlich auch die Unterstüzung „von oben“, wenn sie Früchte tragen sollen – nichts also, was man schnell erreichen kann. Bleiben noch die Werkzeuge.
… und Werkzeuge
Ein wichtiges Werkzeug für die Softwareentwicklung ist heute „Continuous Integration“, kurz CI. Nach dem Motto „Fail early, fail fast, fail often“ geht es hier darum, dem Entwickler eine sehr zeitnahe und unmittelbare Rückmeldung über die Auswirkungen einer von ihm durchgeführten Änderung zu geben. Voraussetzung dafür sind umfangreiche Tests, die automatisiert und schnell ablaufen können und eine zuverlässige Aussage über den Zustand des Systems geben müssen. Führt man den Gedanken ein wenig weiter und schließt auch das automatische Deployment in eine Laufzeitumgebung mit ein, landet man bei „Continuous Deployment/Delivery“ (CD), einer der Schlüsselpraktiken, die Lean-Start-ups so schnell machen. Viele Minireleases mit kleinen Änderungen sind meist weniger risikoreich als große Releases mit vielen Änderungen, so die Überlegung, und zudem wesentlich leichter rückgängig zu machen. Auch wenn die Laufzeitumgebung letztendlich noch nicht die „echte“ Produktion ist, sondern nur ein QA- oder Pre-Production-System, gewinnt man durch Continuous Deployment viel Flexibilität und Sicherheit und kann auf lange Sicht mit der Qualität der häufig gelieferten Releases vielleicht auch langsam den Betrieb überzeugen, dass dahinter mehr steckt als eine kurzlebige Modeerscheinung.
Continuous Deployment ist nur eines von vielen Beispielen für Praktiken und Werkzeuge. Allen gemeinsam ist aber eines: der starke Fokus auf der Automatisierung von ansonsten komplexen, fehleranfälligen Prozessen, die durch eine neue Klasse von leistungsfähigen und flexiblen Frameworks unterstützt wird. Ein mittlerweile recht bekannter Vertreter aus dieser Kategorie ist „Chef“.
Fazit
Warum erzähle ich Ihnen das alles? Ganz einfach: Weil ich glaube, dass auch klassisch aufgestellte Unternehmen von einer stärkeren Verbindung zwischen Entwicklung und Betrieb profitieren können. Wahrscheinlich ist Ihr Ziel nicht, fünfzig produktive Deployments am Tag zu erreichen. Vielleicht möchten Sie nur die Zeit bis zur Produktivschaltung eines neuen Releases von drei Monaten auf einen Monat reduzieren. Aber auch dann lohnt es sich, einen Blick in den Werkzeugkasten der DevOps zu werfen. Und wer weiß, vielleicht hat das ja am Ende sogar noch positive Auswirkungen auf die Kultur?