Autor – Henning von Kielpinski, Leiter Business Development bei Consol.
Viele Unternehmen stehen zunehmend unter Druck, in einem dynamischen Markt ihre IT-Systeme und Softwarelösungen schnell anpassen, erweitern oder erneuern zu müssen. So hat sich beispielsweise die Einführungszeit neuer Features im Vergleich zu früher um ein Vielfaches verkürzt. Gleichzeitig ist der Betrieb der IT-Systeme und Softwarelösungen immer komplexer geworden, die Anforderungen an Stabilität, Verfügbarkeit und Sicherheit sind gestiegen. Hieraus ergibt sich ein Widerspruch: Während die Entwicklung („Development“) auf Agilität und Schnelligkeit setzt, ist es die Aufgabe der Betriebsabteilung („Operations“), für Stabilität und wenig Änderung zu sorgen.
Um beide Interessen besser miteinander in Einklang zu bringen, hat sich in den vergangenen Jahren eine Methode etabliert: DevOps versucht, durch ein kommunikatives, interaktives Vorgehen und den Einsatz von Automatisierungs-Tools das Software Development und Infrastruktur-Management wieder besser miteinander zu verschmelzen.
Konflikt zwischen Entwicklung und Betrieb
Trends wie Web 4.0, die Zunahme von mobilen Devices mit unterschiedlichen Betriebssystemen, Wearables und Apps sowie immer kürzere Entwicklungszyklen haben in den letzten Jahren dazu geführt, dass sich aus der unterschiedlichen Zielsetzung beider Abteilungen ein tatsächlicher Konflikt entwickelt hat. Die Ursache dafür ist nicht primär, dass hier unterschiedliche Interessen verfolgt werden, sondern dass die Kommunikation zwischen beiden Abteilungen abgeebbt ist und teils gar nicht mehr stattfindet. Dieser Umstand ist oftmals der räumlichen Trennung geschuldet, teilweise über Kontinente hinweg.
Der Konflikt wird beispielsweise dadurch noch zusätzlich verstärkt, dass Change-Prozesse historisch so komplex geworden sind, dass sie für einzelne Mitarbeiter nicht mehr durchschaubar sind. Das lässt sich mit dem bekannten Effekt vergleichen, dass die „rechte Hand nicht mehr weiß, was die Linke tut“. Und: Bleibt für die Einhaltung der langwierigen Change-Prozesse keine Zeit, werden sie in der Praxis inoffiziell abgekürzt. Das bleibt nicht ohne Risiken für die Unternehmen, unter anderem zu Lasten der Qualitätssicherung und Informationssicherheit. Mit DevOps wird nun versucht, die Abteilungen und Prozesse wieder besser zu synchronisieren. Das Mittel dazu ist in erster Linie die Kommunikation, die in zweiter Instanz durch technische Tools unterstützt wird.
Von der Problematik, die DevOps zu lösen versucht, sind prinzipiell Unternehmen unterschiedlicher Größe und Branche betroffen. Dienstleister, die zu Firmen (B2B) und Endkunden (B2C) gleichermaßen Kontakt haben, im schnelllebigen Web 4.0 agieren und ihre Web-Oberflächen sowie Funktionen immer weiter optimieren müssen (Stichwort „Responsive Design“), sind in der Regel stärker betroffen als beispielsweise etablierte Produktionsbetriebe, bei denen sich funktional in der Software wenig ändert.
Welche Gründe haben Unternehmen, sich für DevOps zu entscheiden?
Kommunikation ist Voraussetzung, Beratung vorteilhaft
Ein DevOps-Projekt startet damit, Entscheider (C-Level) sowie die beteiligten Abteilungen zunächst für die Problematik zu sensibilisieren. Dabei gilt es, ein Bewusstsein zu schaffen für die Notwendigkeit eines permanenten kommunikativen Austauschs untereinander. Offenheit und der Wille, Wissen zu teilen gehören dabei zu den Grundvoraussetzungen. Mitarbeiter müssen bereit sein, altbekannte Wege zu verlassen, möglicherweise auch Verantwortlichkeiten abzugeben oder neue zu übernehmen.
DevOps bedeutet im Wesen, sich mit „abteilungsfremden“ Kollegen als ein Team zu verstehen, persönlich kennenzulernen und sich regelmäßig in Meetings auszutauschen. Auch wenn dies banal klingt: Der persönliche Kontakt ist essenziell für ein DevOps-Projekt. Mit ihm steht und fällt sein Erfolg. DevOps erfordert dafür einen anfänglich hohen persönlichen Zeiteinsatz von den Mitarbeitern, was den Einsatz der Methode daher nicht zwangsläufig kostengünstiger macht.
Parallel zur „menschlichen“ Erfahrung erfolgt eine kritische Analyse der bestehenden Prozesse: Wer ist wofür zuständig? Wie verlaufen Freigaben? Welche Verantwortlichen sind beteiligt? Grundsätzlich ist es ratsam, einen externen Prozessberater einzuschalten, der gleichsam auch als Coach für die Mitarbeiter agiert. Dieser ist unvoreingenommen und hat einen freien Blick auf die Notwendigkeit und Wirksamkeit existierender Prozesse. Er erkennt beispielsweise überflüssige Schritte oder Stellen, an denen etwas fehlt. Seine Aufgabe ist es auch, die Mitarbeiter für DevOps zu begeistern. Anschließend werden die Abstimmungswege und die Zusammenarbeit untereinander nach den CALMS-Grundsätzen (siehe Kasten) festgelegt.
Technische Tools minimieren Fehlerquote
Moderne technische Tools unterstützen die Arbeit nach DevOps, indem sie bestimmte repetitive Schritte – und zwar möglichst viele – automatisieren. Zum Beispiel zum Release Management, Provisioning oder Monitoring. Derzeit viel diskutiert ist der Einsatz von Docker Containern. Damit lassen sich neue Softwarepakete in einem Container zusammenfassen und gebündelt an den Betrieb übergeben – natürlich im Vorfeld automatisiert getestet, zum Beispiel über OpenStack oder OpenShift im Zusammenspiel mit dem Testframework Citrus [1]. Solche Technologien minimieren die Fehlerquote und sorgen für eine reibungslose Implementierung und einen störungsfreien Betrieb.
Nicht alle Prozesse DevOps-tauglich
Natürlich eignet sich DevOps auch für die Zusammenarbeit mit Partnern und Lieferanten innerhalb der Wertschöpfungskette. Allerdings nur bis zu einer bestimmten Komplexität und nur unter bestimmten vertraglichen Voraussetzungen. Nicht jeder Vertrag, zum Beispiel mit Outsourcing-Partnern, erlaubt DevOps. Grundsätzlich müssen Firmen von Fall zu Fall entscheiden, welche Prozesse oder Teilbereiche sie in ihr DevOps-Konzept aufnehmen wollen.
In vielen Unternehmen ist zudem die Einhaltung und Umsetzung von ITIL (IT Infrastructure Library) Pflicht. Dies steht jedoch nicht im Widerspruch zu DevOps. Im Gegenteil: DevOps und ITIL harmonieren gut zusammen. Vorausgesetzt, ITIL wird als dynamisches Regelwerk im Unternehmen praktiziert.
Fazit
DevOps ist eine Methode, die Soft Skills, Prozesse und Technologien so einsetzt, dass die Zusammenarbeit zwischen Development und Operations wieder synchron aufeinander abgestimmt ist. Ein Projekt zur initialen Einführung von DevOps dauert in der Regel zwischen drei und sechs Monate. Die Vorteile sprechen für sich: Eine Umfrage von Vanson Bourne hat ergeben, dass Befragte durch DevOps nicht nur die Zusammenarbeit untereinander sowie die Softwarequalität verbessern konnten, sondern auch ihren Umsatz steigerten [2]. Dies war beispielsweise möglich, weil sie schneller neue Features einführen oder ihre Lösungen über zusätzliche Plattformen anbieten konnten.
Quellen:
[1] www.citrusframework.org
[2] Vanson Bourne UK, 2013 im Auftrag von CA Technologies, http://www.ca.com/us/~/media/Files/whitepapers/techinsights-report-what-smart-businesses-know-about-devops.pdf
„CALMS“-Grundsätze von John Willis:
• Cultural: DevOps bedeutet immer auch ein Verstehen und Verändern der Unternehmenskultur. Das muss allen Beteiligten bewusst sein.
• Automation: DevOps versucht, möglichst viele Prozessschritte zu automatisieren und dazu entsprechende Tools einzusetzen.
• Lean: Prozesse sollten so schlank wie möglich gehalten werden. Das heißt: Nur die wirklich Verantwortlichen sollten einbezogen werden. Das kann zur Folge haben, dass Mitarbeiter Verantwortlichkeiten oder Einfluss abgeben müssen.
• Measurement: Der Erfolg sollte messbar sein, zum Beispiel anhand einer geringeren Fehlerquote oder eines schnelleren Entwicklungszyklus. Aber auch weiche Faktoren wie Zufriedenheit sollten regelmäßig kontrolliert werden.
• Sharing: DevOps basiert auf der Kommunikation, dem Teilen von Ideen, Gedanken, Ergebnissen. Dieser Punkt ist zentral für das Gelingen von DevOps.
www.consol.de
Henning von Kielpinski, Leiter Business Development bei Consol. Die Consol Consulting & Solutions Software GmbH ist ein Münchener IT-Full-Service-Anbieter für Mittelstandskunden und große Konzerne. Als neutrales IT-Beratungshaus bietet Consol optimale Lösungen. Zum Portfolio des IT-Dienstleisters mit Spezialisierung auf komplexe IT-Systeme gehören Beratung, Architektur, Entwicklung, Integration, Monitoring und Testing sowie Betrieb und Wartung.
