Operations heute und morgen, Teil 2: DevOps im Jahre 2015
Seite 2: Agilität
Agilität als Wegbereiter
Agile Softwareenwicklung hat nicht nur negative Folgen für die Operations-Abteilung gebracht, denn die Vorzüge, die die Softwareentwicklung aus den agilen Methoden gezogen hat, lassen sich auch auf die Arbeit im Betrieb umsetzen. In der agilen Welt sind viele Frameworks und Tools entstanden, die die tägliche Arbeit eines Operations-Teams vereinfachen, ohne dass es sofort einen agilen Arbeitsmodus einnehmen müsste. Natürlich geht es bei Agilität nicht nur um Tools, sondern auch um agile Werte. Kommunikation zu fördern und Transparenz zu schaffen, sind wichtige Aspekte der agilen Arbeitsorganisation. Ein Taskboard und ein "Daily meeting" sorgen nicht nur dafür, dass das Team seine Arbeitsschritte transparent macht, sondern fördern Verständnis für die Arbeit der anderen und sorgen dafür, dass das Team Probleme löst.
Die Art und Weise, wie Software entwickelt wird, kann auch für den Betrieb hilfreich sein. Statt "Schnipsel" von Bash-Skripten per Copy & Paste aus dem Wiki ins Terminal zu kopieren, sollte es für jede Betriebsabteilung eine Selbstverständlichkeit sein, ihre Software so einzusetzen, dass sie benutzbar und wartbar wird. So lassen sich Skripte unter Versionskontrolle bringen und über CI-Server wie Jenkins benutzen. Ein Austausch zwischen Entwicklern und Operations-Leuten zu den Themen Test Driven Development und Continuous Integration wird die kurzfristigen Probleme der Operations-Bereiche lösen und langfristig die Zusammenarbeit der Abteilungen stärken. Ein weiterer positiver Effekt ist, dass Operations-Leute die gleichen Infrastrukturkomponenten wie die Entwicklungsabteilung verwenden und diese somit geteilte Ressourcen werden und unter gemeinsamer Verantwortung stehen.
Agilität zu Ende gedacht
Der Begriff "DevOps" entstand im Rahmen der DevOpsDays, einer Konferenz, die 2009 in Belgien erstmals stattfand. Auch wenn der Begriff das Zusammenspiel von Dev (kurz für Development) und Ops (kurz für Operations) suggeriert, zeichnete sich bei den Vorträgen dieser Veranstaltung ab, dass DevOps mehr als die Summe von Entwicklung und Betrieb ist.
Eine allgemein anerkannte, abschließende Verfahrensweise von DevOps gibt es allerdings bis heute nicht. Das ist aber nicht verwunderlich, weil DevOps änlich wie Agilität eher ein Wertesystem als eine klar definierte Methode oder gar ein Produkt ist. So bilden sich immer wieder unterschiedliche Interpretationen heraus.
In der Community haben zumindest die "Drei Wege des DevOps" eine breite Anerkennung als elementare Bestandteile von DevOps gefunden. Vereinfacht ausgedrückt umfassen diese Folgendes:
- Weg 1: Die IT-Wertschöpfungskette wird vollständig betrachtet und optimiert, das heißt von den Anforderungen bis zum Betrieb.
- Weg 2: Es gibt Feedbackschleifen auf allen Ebenen – nicht nur von der Entwicklung zu den Anforderungen.
- Weg 3: Es wird eine Kultur der kontinuierlichen Verbesserung basierend auf kontrollierten Experimenten aufgebaut. Der Aspekt hat auch eine Verbindung zu "Lean Startup".
Die Kernidee von DevOps besteht darin, die Feedbackschleifen auf die gesamte Wertschöpfungskette von den Anforderungen bis zum Betrieb auszudehnen, statt sie – wie bei der agilen Softwareentwicklung häufig zu beobachten – am Ende der Produktentwicklung abzubrechen. Damit ist es möglich, die Produktionskette durchgängig sowie die Durchlaufzeiten und die Flexibilität bis in den Betrieb zu optimieren, ohne die notwendige Stabilität zu kompromittieren, da auch die Anforderungen des Betriebs hinreichend Berücksichtigung finden. So gesehen lässt sich DevOps auch als "Agilität in der IT konsequent zu Ende gedacht" betrachten. Leider gibt es einige Missverständnisse in Bezug auf DevOps, die den flächendeckenden Erfolg in Unternehmen verhindern, da die Missverständnisse bei der Implementierung in eine Sackgasse führen können.