Die agile Bewegung hat mit den Werten des Agilen Manifests dafür gesorgt, dass sich die Sichtweise auf Prozesse, Mitarbeiter und Kollegen verändert hat. Dass Personen über Prozesse gestellt werden und dem iterativen Vorgehen gegenüber langfristigen Planungen der Vorzug gegeben wird, hat mittlerweile auch den Bereich Operations erreicht.
Durch die Beschleunigung der Softwareentwicklung und die Bereitschaft, nicht Funktionierendes schnell zu verwerfen, erhöht sich der Druck auf Operations-Teams. Neue Server oder Servergruppen werden benötigt, Releases sind zu deployen und neue Buildserver hinzuzufügen – solche Standardaufgaben der Entwickler werden für den Betrieb zunehmend zum Problem. Viele Firmen bilden sie oft über Ticketprozesse ab, die jedoch nicht immer zur schnelleren Bearbeitung führen. Im schlimmsten Fall werden so mehrere Hundert Tickets pro Tag an die Teams geschickt und per “FIFO” (first in first out) abgearbeitet. Wenn aber ein Team seine Änderung schneller haben möchte, beginnt das Verhandeln um die Prioritäten.
In kleinen Firmen lässt sich so etwas noch auf kurzem Weg lösen: Der Hilfesuchende geht zum Kollegen und bittet ihn direkt um Hilfe. Er erhält so seine Änderung schneller als andere Anfragesteller. Jedoch wird der Kollege so in seinem Arbeitsfluss gestört, und die verbleibenden Tickets werden langsamer abgearbeitet. Das
Ergebnis ist, dass das Operations-Team zunehmend mit wiederkehrenden Aufgaben konfrontiert wird und weniger Zeit für die Wartung und Weiterentwicklung der Infrastruktur zur Verfügung hat.
Gestern und heute
Für gewöhnlich braucht es nicht viel Agilität, um die Arbeit im Bereich Operations durchzuführen. Die Patchdays sind oft bekannt, Schmerzen bereiteten hingegen unberechenbare Probleme wie ausfallende Coreswitches und Java-Updates. Ad-hoc-Aufgaben aus dem Rest der Abteilung kommen per Ticket oder Telefon und werden nach Wichtigkeit abgearbeitet. Die Arbeit kulminiert jedoch an Release-Tagen. Je nachdem wie die Firma ihre Deployments handhabt, muss der Betrieb sehr früh oder sehr spät dafür sorgen, dass das Release installiert wird. Darauf wird das Release vorbereitet, und zwar entweder vom Releasemanagement oder direkt vom Operations-Team.
Kollegen, die nicht an der Entwicklung der Software beteiligt waren, müssen sich um die Lauffähigkeit der Komponenten kümmern und haben zu entscheiden, welche Konfigurationsparameter zum Release gehören könnten und warum sich die Abhängigkeiten zum Release nicht auflösen lassen. Die Entwicklungsabteilung wirft das Release sprichwörtlich “über den Zaun”, und die Verantwortung lastet auf den Schultern derjenigen,
die das Update einspielen müssen. Diese Verantwortung wiegt insbesondere dann schwer, wenn die Verfügbarkeit der Plattform in den Zielvereinbarungen des Betriebs verankert ist. Jedes fehlgeschlagene Release bedeutet, dass es kein oder weniger Geld gibt – so als hinge die Verfügbarkeit der Plattform nur vom Betrieb ab.
Im Idealfall bearbeiten ein oder mehrere Kollegen in einer Zeitspanne von ein oder zwei Wochen wichtige Themen. Die Arbeit unterscheidet sich im besten Fall kaum von der Softwareentwicklung, nur verfügt diese in den meisten Fällen über einen geschützten Sprint, um ihre Arbeit zu erledigen. Diesen Schutz eines Sprints kann ein Operations-Team, insbesondere wenn es schwächer besetzt ist, nur schwer umsetzen. Auch seine Mitarbeiter hätten gern ausreichend Zeit für die Weiterentwicklung von Infrastruktur. Die verfügbare Zeit fällt aber aufgrund der Anforderungen an das Team, zunehmend schneller zu arbeiten, immer geringer aus.
Die Art und Weise, wie die Fachabteilungen und die Operationsabteilung arbeiten, muss sich strukturell angleichen. An diesem Punkt setzt DevOps an, dazu gleich mehr.
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.
Missverständnisse über DevOps
- DevOps betrifft nur Development und Operations: Der Fokus von DevOps ist bei weitem nicht so eingeschränkt, wie es der Name vermuten lässt. Vielmehr verlangt DevOps eine übergeordnete Betrachtung des Lieferweges von Software und umfasst alle Bereiche, die darauf Einfluss haben. Es setzt auf dem Wissen aus Agilität und Lean auf.
- DevOps ist nur die Automatisierung von Build und Deployment: DevOps ist nicht Continuous Delivery, das sicherlich eines der geeigneten Mittel ist, wenn DevOps in einem großen Umfeld betrieben wird. Continuous Delivery ist jedoch nur ein hilfreiches Werkzeug. Bei Continuous Delivery geht es primär um die Automatisierung von Build, Test und Deployment mithilfe einer geeigneten Werkzeugkette. DevOps hingegen ist im Kern ein Wertesystem.
- Dev übernimmt Ops, das heißt, die Entwicklung macht den Betrieb mit: Es geht nicht darum, dass die Funktionen des Bereichs Operations übernommen werden. Jeder Entwickler wird mit seiner Feature-Entwicklung genug zu tun haben. Mit wachsendem Reifegrad der entwickelten Technikenkann das Plattformteam jedoch weitere Dienste nach und nach bereitstellen, wie Database as a Service oder Message Queue as a Service. Wichtig ist hierbei, dass Fachteams alle Dienstleistungen des Plattformteams über eine Self-Service-API oder ein intuitives Interface beziehen können. Ziel ist es, mit den “Kunden” (Entwickler sind nichts anderes als Kunden einer Dienstleistung) Infrastruktur zu entwickeln, die es allen ermöglicht, schnell die Produkte zu nutzen, die anderenfalls mit manuellem Aufwand zur Verfügung zu stellen wären.
T-Profil
Für den Erfolg von DevOps ist es wichtig, dass Menschen mit dem besten Skillset für eine Aufgabe zusammenkommen und ungestört an ihr arbeiten können. Es ist allerdings wenig zielführend, wenn etwa fünf Spezialisten einzeln an jeweils einem Problem arbeiten. Vielmehr muss es Schnittpunkte in den jeweiligen Interessengebieten geben. Die Spezialisten sollten voneinander lernen können und ausreichend Spezialwissen mitbringen, um komplexe Aufgaben in einem Projekt zu lösen. In diesem Kontext ist das T-förmige Profil relevant.
Entwickler sollten beispielsweise über ausreichend Breitenwissen verfügen, um die Erfordernisse und Bedürfnisse aller anderen beteiligten Bereiche verstehen zu können. Das ist eine Grundvoraussetzung für Zusammenarbeit im Allgemeinen. Die Kerndomäne ist allerdings immer noch die Softwareentwicklung. Hier haben Entwickler ihr Tiefenwissen. Wenn sie in anderen Bereichen über zusätzliches Tiefenwissen verfügen, ist das erfreulich, aber nicht zwingend notwendig.
Chris Johnson fasst den Zusammenhang in einem mittlerweile zurückgezogenen Blog zusammen: “To be a master of anything, you must understand two layers above and two levels below the layer you’re targeting.” Und er fährt fort (der leichteren Lesbarkeit halber hier übersetzt): “Wenn jemand der beste JavaScript-Entwickler werden möchte, sollte er ein fundiertes Verständnis davon haben, wie JavaScript-Parser und Browser funktionieren. Des Weiteren sollte ein guter Entwickler verstehen, welchen Einfluss seine Applikation auf die Ebenen oberhalb seines Tätigkeitsbereichs hat.”
Die benötigten Fähigkeiten werden über die cross-funktionale Besetzung in das Team geholt. Das bedeutet für DevOps, dass dem Team auch Betriebsexperten angehören.
Nicht nur die Schnittmengen aus dem Spezialwissen und Breitenwissen der Teammitglieder sorgen dafür, dass das Team die maximale Leistungsfähigkeit hat, sondern auch deren soziale Fähigkeiten und Rollen (Katalysator, Experte). Aus der teamspezifischen Konstellation bildet sich ein “DevOps-Sweetspot”, in dem das Team bestmöglich agieren kann.
Fazit
Obwohl das Thema DevOps seit ein paar Jahren in aller Munde ist, bleiben offene Fragen: Wie skaliert DevOps in Unternehmen? Auf welche Weise lässt sich DevOps mit der Arbeit in verteilt arbeitenden Teams verbinden? Wie lassen sich IT-Service-Management und DevOps sinnvoll kombinieren? Die Umsetzung von DevOps in der Praxis zeigt, inwiefern es sich in unterschiedlichen Firmenstrukturen etablieren kann.
Wichtig ist, dass die DevOps-Bewegung – wie auch die agile Softwareentwicklung – eine Bottom-up-Entwicklung ist. Daher muss sich das Management von Operations-Abteilungen daran gewöhnen, dass klassische Teamstrukturen aufgebrochen werden. Veränderte Anforderungen an Motivation und Führung der Mitarbeiter sind die Folge.
Quelle: http://www.heise.de/developer/artikel/Operations-heute-und-morgen-Teil-2-DevOps-im-Jahre-2015-2700954.html