DevOps Part I – Was ist DevOps

DevOps ist ein Begriff, der u.a. durch agile Entwicklungsmethoden in der Softwareentwicklung immer mehr an Bedeutung gewinnt. Durch die zunehmende Umstellung von linearen Vorgehensmodellen, wie das Wasserfallmodell, auf agile Entwicklungsmethoden wie Scrum, können Unternehmen schneller auf Anforderungen und Probleme reagieren. Dies stellt einerseits Softwareentwickler vor neue Herausforderungen und andererseits auch diejenigen, die für den Betrieb der Software verantwortlich sind. In klassischen Organisationen sind Entwicklung und Betrieb voneinander getrennt, welche erst auf Managementebene zusammengefasst werden. Während die einen eher darauf bedacht sind, neue Funktionen zu implementieren, steht bei den anderen der sichere und stabile Betrieb der Software im Fokus. Dabei herrschen oft Konflikte zwischen beiden Abteilungen. Oft werden nicht dieselben Werkzeuge oder Komponenten eingesetzt, was zu Problemen führen kann. Auch die Aktualisierung von operativen Umgebungen gestaltet sich nicht immer einfach, da selbst hier Abweichungen von den Testumgebungen der Entwicklung bestehen können. Bei Problemen verweisen Softwareentwickler auf die letzte funktionierende Version, um sich so aus der Misere retten zu können, so dass die Arbeit bei den Betreibern bleibt, welche als Verantwortliche für die entstandenen Ausfälle gelten. Doch betrifft dies nicht nur die Mitarbeiter beider Abteilungen, sondern auch die Abteilungsleiter, welche unterschiedliche Ziele verfolgen.

Grundlagen
Der Belgier Patrick Debois nahm im Jahr 2008 an der Konferenz „Agile 2008“ mit dem Schwerpunkt agile Softwareentwicklung in Toronto teil, wo er einen Vortrag mit dem Thema „Agile Operations and Infrastructure: How Infra-gile are You?” hielt. In diesem Vortrag vermittelte Debois seine Erfahrungen, die er in drei verschiedenen Infrastruktur-Projekten im Zusammenhang mit agiler Softwareentwicklung gesammelt hat. Parallel dazu veranstaltete der Verlag O’Reilly eine Konferenz namens Velocity zum Thema „Web Performanz und Betrieb“ in San Francisco, bei der verschiedene Firmen ihre Erfahrungen mitteilten. Eine dieser Firmen war Flickr, die im selben Jahr versuchten, die Zusammenarbeit der Abteilungen Entwicklung und Betrieb zu intensivieren. Seinen Ursprung hat der Begriff DevOps im Jahr 2009. Da Patrick Debois nicht persönlich an der Konferenz Velocity 2009 in San Jose teilnehmen konnte, beschloss er, eine eigene Konferenz in Belgien zu organisieren. Die Konferenz bekam den prägenden Namen „DevOps Days“ und findet seit diesem Zeitpunkt regelmäßig auf der ganzen Welt statt. Zudem wird der Begriff „DevOps“ von Marktforschungsunternehmen für kritische Einschätzungen verwendet sowie als Schlagwort von Unternehmen für ihre Produkte verwendet.

Definition
Einige mögen DevOps als Softwareentwicklungsmethode definieren, während andere eher an Tools und Technologien, wie Konfigurationsmanagement oder kontinuierliche Bereitstellung (englisch: Continuous Delivery, kurz CD) denken. Stattdessen ist es eher eine kulturelle Bewegung, welche versucht die Softwareentwicklung und den Alltag der betroffenen Mitarbeiter im Betrieb zu verbessern. Dieses Zusammenspiel von Softwareentwicklern und Operatoren hat den Begriff DevOps hervorgebracht, da dieser am besten die Zusammenarbeit beider Bereiche als logische Einheit beschreibt. Dabei kumuliert der Begriff DevOps tatsächlich aus den beiden Begriffen „Dev“, welcher für die Softwareentwicklung (englisch: Development) und „Ops“, welcher für den Betrieb (englisch: Operations) steht. DevOps respektiert die Tatsache, dass Unternehmen und Projekte eine eigene Kultur haben und Menschen wichtiger sind als Prozesse, die wiederum wichtiger sind als Tools. Diese Grundgedanken sind der Auslöser für die dazugehörige Bewegung, welche sich mit der Zusammenlegung zwei grundverschiedener Bereiche beschäftigt.

Abgrenzung
DevOps ist keine neue Abteilung oder Stellenbezeichnung und geht auch nicht damit einher, neue Mitarbeiter einzustellen. Ebenso geht es nicht um das Szenario, in dem Softwareentwickler für den Betrieb verantwortlich sind oder umgekehrt. Dafür unterscheiden sich Softwareentwickler und Operatoren bezüglich ihrer Schwerpunkte und Fähigkeiten. Aufgaben und Verantwortungen können sich hingegen verschieben, jedoch ändert dies nichts an der Tatsache, dass immer noch die gleichen Aufgaben, also Entwicklung und Betrieb, erledigt werden müssen. Oftmals wird der Begriff selbst auch für Tools verwendet. Doch DevOps selbst schreibt die Verwendung bestimmter Tools nicht vor. Sie ergänzen eher die Grundsätze, denn DevOps beschreibt vielmehr ein Muster für die Zusammenarbeit, Prozesse und Automatisierung. Außerdem gibt es keine Zertifizierung, wie effektiv man kommuniziert, wie gut Abteilungen in Unternehmen zusammenarbeiten oder wie gut ihre Organisation dazulernt. Das ist für eine kulturelle Bewegung nicht möglich.

Unterschiedliche Ziele
Eine Aufgabe von Softwareentwicklern besteht darin, gewünschte Funktionen schnell umzusetzen, um so einen Mehrwert für den Endanwender zu schaffen. Mit der Häufigkeit der Umsetzung neuer Funktionen steigt zudem die Wahrnehmung der Softwareentwickler, abgesehen davon, ob diese auf den Produktivsystemen verfügbar sind oder nicht. Die Aufgabe von Operatoren besteht darin, die neue Software für die Endanwender auf den Produktivsystemen zu implementieren. Zusätzlich sind sie für die Sicherstellung des laufenden Betriebs unter bestimmten Qualitätsmerkmalen verantwortlich und tragen somit die direkte Verantwortung für die Verfügbarkeit. Ihr Erfolg wird an der Erreichung der Qualitätsmerkmale gemessen. Endanwender erwarten stets eine hohe Verfügbarkeit, volle Sicherheit und eine hohe Performance. Fällt ein System aus, wirkt sich das unmittelbar auf die Wahrnehmung des Betriebs aus. Besonders bitter ist es, wenn die eigenen Überwachungssysteme den Ausfall erst später bemerken, nachdem der Kunde eine Störung gemeldet hat. Anhand dieser Aufgaben ist schon zu erkennen, dass beide Abteilungen unterschiedliche Ziele verfolgen. Während die Entwicklung versucht, die Schlagzahl an neuen Funktionen und Releases zu erhöhen, ist der Betrieb darauf bedacht, dies zu vermeiden, um so den Betrieb nicht zu gefährden.

Blame Culture
Manager neigen oft dazu, einer Abteilung oder einer einzelnen Person die Schuld an einem Problem zuzuschreiben, welche wiederum versucht, die Schuld von sich zu weisen oder auf andere zu lenken. Zudem entstehen häufig Konflikte zwischen Entwicklung und Betrieb beim Veröffentlichen neuer Releases, wenn es zu Fehlern innerhalb der Software kommt oder wenn es Probleme mit den Produktivsystemen gibt. Diese Situationen, geprägt vom Zeitdruck für die Behebung, führen häufig zur gegenseitigen Schuldzuweisung und das typische Blame Game (deutsch: gegenseitige Schuldzuweisung) beginnt, welches sich kontraproduktiv auf die Motivation auswirkt. In dieser Art von Kultur (Blame Culture) wird die Ursachenanalyse im Rahmen einer Post-mortem-Analyse oder retrospektiven Analyse mit der Suche nach etwas, das den Ausfall oder das Versagen ausgelöst hat, falsch angewendet. Kontraproduktiv wirkt sich hierbei der Zeitverlust durch Diskussionen der Schuldzuweisungen aus. Diese verlorengegangene Zeit hätte besser in eine gemeinsame Problemlösung investiert werden können, welches nicht nur das Miteinander stärkt, sondern auch motiviert Erfahrungen und Erkenntnisse miteinander zu teilen.

Betrieb als Flaschenhals
Der Konflikt zwischen Entwicklung und Betrieb hat sich mit der Einführung von agilen Methoden zunehmend zugespitzt. Methoden, wie Scrum, die eine iterative und inkrementelle Softwareentwicklung unterstützen, legen ganzheitliche Ansätze nahe, indem sie Auftraggeber und Entwicklung zusammenbringen sowie kurze Releasezyklen unterstützen. Die Vorteile solcher agilen Prozesse, einschließlich Scrum und Kanban, liegen bspw. darin, die Hindernisse für die Zusammenarbeit, die Prozesse und die Tools aufzuheben. Doch damit ist ein neues Release noch nicht auf den Produktivsystemen verfügbar, so dass der geschaffene Mehrwert genutzt werden kann. Dieses Konstrukt mit immer kürzer werdenden Releasezyklen führt letztendlich dazu, dass der Betrieb als Flaschenhals angesehen wird. Gründe dafür sind bspw. schlechte Erfahrungswerte, so dass die häufigen Releasezyklen nicht akzeptiert werden, es eigene Releasezyklen gibt oder Engpässe beim Personal dies nicht zulassen.

Kern von DevOps
Eine Kernidee der DevOps-Bewegung ist, dass sowohl bekannte als auch neue Konzepte, Prozesse und Tools zusammengefasst werden können. Obwohl diese Vielfalt zu unterschiedlichen Meinungen führt, was Bestandteile von DevOps sind und welche nicht, können viele verschiedene Aspekte unter dem Begriff DevOps zusammengefasst werden. Dieser Vorteil begünstigt den Erfahrungsaustausch erheblich, weil Experten aus unterschiedlichen Bereichen ihre Erfahrungen und Fähigkeiten einbringen. Ein Begriff wie DevOps veranlasst aber auch das Management, einen Blick darauf zu haben, das Entwicklung und Betrieb zusammenarbeiten und Synergien finden, um einen Wettbewerbsvorteil zu entwickeln. In den letzten Jahren wurden dabei folgende drei Bereiche als Ziele zusammengefasst: Zusammenarbeit, Prozesse und Tools.

Zusammenarbeit
Ein zentraler Punkt ist der zwischenmenschliche Aspekt, indem beide Teams die volle Verantwortung für Entwicklung und Betrieb übernehmen. Das verringert nicht nur die Koordination, sondern hilft effektiver zu arbeiten. Dadurch können schneller Releases ausgerollt, Entscheidungen getroffen und Probleme gelöst werden. Aber auch der gegenseitige Respekt ist von Bedeutung, der eine Voraussetzung für Vertrauen und erfolgreiche Zusammenarbeit ist. Dabei spielen Selbstverpflichtung aller Beteiligten über die Ziele, gegenseitige Weiterbildung, abbauen von Vorurteilen und die Etablierung gemeinsamer Werte eine wichtige Rolle, um so auch das Blame Game zu verhindern. Es gilt also die aus den agilen Methoden gewonnenen Best Practices abteilungsübergreifend zu etablieren.

Prozesse
Ein weiterer wichtiger Bereich in DevOps sind Prozesse. Sie spielen eine entscheidende Rolle bei dem Zusammenspiel beider Abteilungen. DevOps bedeutet jedoch nicht, beide Abteilungen zusammenzulegen, aber es ist hilfreich, interdisziplinäre Experten an den entsprechenden Schnittstellen zu haben. Jede Abteilung bekommt feste Aufgaben für den Auslieferungsprozess zugewiesen. Zudem ist es nötig, den Betrieb in die agilen Methoden der Entwicklung, wie z.B. Scrum, zu integrieren. Für die Lernkurve kann es hilfreich sein, die Rollen zu tauschen, um zu sehen, was die Aufgaben und Herausforderungen des jeweils anderen im Bereitstellungsprozess oder im Alltag sind. Bei der Festlegung von DevOps-Prozessen ist es nicht immer möglich, diese unternehmensübergreifend anzuwenden, da in kleineren Unternehmen die Grenzen zwischen beiden Abteilungen möglicherweise nicht so streng verlaufen wie in einem Konzern. Nach der Entwicklung von Prozessen, die den Anforderungen und Rahmenbedingungen entsprechen, können die Tools, welche der Unterstützung dienen, ermittelt werden. Diese Vorgehensweise ist effektiver, da sich der Umkehrprozess, d.h. die Anpassung der Prozesse an die Tools, schwieriger gestaltet.

Tools
Ein zentraler Gedanke der DevOps-Bewegung ist die Verwendung von Tools, um Vorgänge im Zusammenhang mit dem Auslieferungsprozess zu automatisieren. Das erhöht die Geschwindigkeit sowie Qualität, vermindert Fehler und schafft Transparenz. Werden die einzelnen Schritte der Auslieferung aus der Sicht der Entwicklung betrachtet, so kommen Werkzeuge für die Erstellung (englisch: Build), das Testen und Bereitstellen (englisch: Deploy) des neuen Releases zum Einsatz. Aus Sicht des Betriebes fehlt es nun an der Verteilung der neuen Releases auf die Produktivsysteme. Dafür eignen sich Systembereitstellungstools, wie bspw. Vagrant, sowie Systemkonfigurationstools, wie bspw. Chef oder Salt. Letztere besitzen in der Regel eine domänenspezifische Sprache (DSL – Domain Specific Language) als formale Sprache, über die ein Systemzustand auf abstrakter Ebene beschrieben wird. Hierbei spricht man auch von „Infrastructure as Code“. Für die einfache Verwaltung des Codes können Versionsverwaltungstools, wie Git, verwendet werden. Als Synergie können Entwicklung und Betrieb die gemeinsame Nutzung von Tools fördern, um Konfigurationen in Form von Codes wiederzuverwenden und so Inkompatibilitäten zwischen Test- und Produktivsystemen auszuschließen.

DevOps und Continuous Delivery
Kontinuierliche Lieferung (CD) dient der Beschleunigung und Automatisierung aller Prozesse in der Softwareentwicklung. Es vereint im Wesentlichen die drei Kerndisziplinen kontinuierliche Integration (englisch: Continuous Integration, kurz CI), kontinuierliches Testen (englisch: Continuous Testing) sowie kontinuierliches Bereitstellen (englisch: Continuous Deployment). CI enthält neben der Erstellung von Software-Artefakten auch die Versionskontrolle (englisch: Source Version Control, kurz SVC) und das Abhängigkeitsmanagement, während Continuous Testing die Software auf ihre Funktionsfähigkeit und Integration durch bestimmte Parameter hin überprüft. Allerdings sind erfolgreiche Tests keine Garantie für ein fehlerfreies Produkt, erhöhen jedoch die Sicherheit. Continuous Deployment umfasst die Auslieferung der erzeugten Artefakte auf Staging- und Produktivsystemen unter Berücksichtigung der Softwarepakete, Konfiguration und Datenbank-Updates. Dabei wurde gerade Continuous Deployment in Unternehmen, bei denen historisch bedingt Entwicklung und Betrieb getrennt sind, immer mehr zum Flaschenhals. Als Teil der DevOps-Bewegung war es daher entscheidend, Softwareentwicklern die Bedürfnisse und Probleme des Betriebs näherzubringen und umgekehrt. CD darf hierbei nicht mit DevOps gleichgesetzt werden, sondern es vereinfacht DevOps und ist außerdem eine wesentliche Methode im DevOps-Umfeld. Überdies gibt es neben CD noch viel mehr Bereiche, in denen DevOps als organisatorisches Modell hilfreich ist.

Hilfreich
DevOps Tools
DevOps Links

Kommentar verfassen

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.