Suche
Erfolgreiche Unternehmen setzen auf Zusammenarbeit

Von DevOps zu DevQOps: Evolution der Qualität

Olaf Garves

©Shutterstock / Bobrova Natalia

DevOps gehört in modernen Unternehmen mittlerweile zum guten Ton. Die optimale Leistungsfähigkeit erreichen Organisationen damit jedoch nur, wenn sie die Methoden in maximaler Qualität implementieren. Was wir brauchen, ist nicht nur DevOps, sondern vielmehr „DevQOps“.

Das Agile Manifest mit seinem Mantra „Wir erschließen bessere Wege, Software zu entwickeln…“ löste vor fast genau fünfzehn Jahren eine Denkrevolution aus. Heute gehört es vielerorts zum Standard eines jeden fortschrittlichen Entwicklungshauses und jeder modernen Entwicklungseinheit. Dasselbe gilt nunmehr auch für den ehemaligen Hype rund um das Thema DevOps. Ein moderner IT-Betrieb widmet sich heutzutage intensiv den darin vermittelten Themen der Agilität.

Mehr als nur ein Schulterschluss

In der Praxis bedeutet DevOps aber mehr als nur den Schulterschluss zwischen „Dev“, also der projektgetriebenen Softwareentwicklung, und „Ops“, dem serviceorientierten Betrieb. Es geht vor allem darum, dass Dev und Ops gemeinsam Verantwortung für ein Ergebnis übernehmen – zu Recht. Darüber hinaus gibt es Veränderungen durch die damit verbundene Automatisierung: Es entstehen immer bessere innovative Tools und neue Rollen, in die sich Entwickler und Systemingenieure hineinbegeben können. IT-Service-Management kennt mit den fünf Kernbänden mit derzeit 26 Kernprozessen der IT Infrastructure Library (ITIL) bereits eine den DevOps latent ähnliche grundsätzliche Prozessbeschreibung. Aber anders als es Fachdiskussionen der vergangenen Monate oft kolportieren: Es ist weder eine Grundsatz- noch eine Glaubensfrage, sich zwischen ITIL und DevOps entscheiden zu müssen. Beide Ansätze können sogar parallel laufen – und sind gar nicht so weit weg voneinander. Noch näher kommen sie sich mit dem anstehenden ITIL-Update, das die agilen Aspekte, aber auch DevOps und Lean in diese neue ITIL-Version einbringen wird.

Der IT-Betrieb hat mittels des ITIL-Frameworks auch Change-Prozesse beschrieben und in der ITSMCommunity, insbesondere lange Zeit durch das itSMF (IT Service Management Forum), verbreitet. Somit steht die Stabilität des Betriebs – dort, wo die Software den eigentlichen Nutzen für den Endkunden oder Anwender entfaltet – nicht im Widerspruch zur Agilität der Softwareentwicklung. Das Thema Zusammenarbeit in der IT ist außerdem nicht erst mit DevOps entstanden, in erfolgreichen Organisationen war es schon immer relevant. Teamwork ist eher ein kulturelles Thema, das allerdings immer stärker durch die digitale Transformation extrem beschleunigt wird.

DevOpsCon Whitepaper 2018

Free: BRAND NEW DevOps Whitepaper 2018

Learn about Containers,Continuous Delivery, DevOps Culture, Cloud Platforms & Security with articles by experts like Michiel Rook, Christoph Engelbert, Scott Sanders and many more.

Der Stein des Anstosses

Aktuelle zwangsläufige Veränderungen in der Unternehmenskultur kündigen sich meist über Tooldiskussionen an. Anschließend an diese Diskussionen bedarf es aber auch einer Einigung in der Zusammenarbeit – das gilt insbesondere für DevOps. Verstehen sich Betrieb und Entwicklung nicht, so gerät das gesamte Unternehmen ins Wanken und verliert den Anschluss am Markt. Rein digitale Unternehmen wie das Fernbusunternehmen FlixBus oder der Hotelreservierungsservice HRS zeigen, dass ohne digitale Fähigkeiten wie beispielsweise mobile Apps, Plattformen und ein hohes Tempo im Marktangang kein neues Geschäft möglich ist.

DevOps führt auch zu strukturellen Änderungen. Es transformiert eine große IT-Einheit in kleinere Teams. Das schafft wachsenden Gestaltungsspielraum, der mit einer zunehmenden Autonomie dieser kleineren Kompetenzteams einhergeht. Damit diese Autonomie jedoch auch in Erfolg mündet, müssen Unternehmen hierfür ehemals hierarchisch angelegte Denkweisen ändern, sowohl bei Mitarbeitern als auch bei Führungskräften. Wenn DevOps also beispielsweise Zusammenarbeit voraussetzt, aber Entwicklung und Betrieb nun doch nicht im Sinne des Gesamterfolgs zusammenarbeiten, dann müssen die „Sponsoren“ des Projekts eskalieren. In diesen Fällen sollten sich alle Beteiligten persönlich treffen, um sich über die gemeinsamen Vorstellungen zur Zusammenarbeit zu verständigen. Letztendlich ist das auch nichts Neues. Die Einführung von DevOps ist ein Change-Projekt. Unterstützen können dabei neutrale Berater und ein auf das Unternehmen oder die Organisation adaptierbares DevOps-Reifegradmodell.

Vom Hype zur gelebten Realität

Aus dem Hype DevOps ist mittlerweile eine Selbstverständlichkeit geworden. Ops nimmt agiles Basiswerkzeug der Entwicklung als Erleichterung der eigenen Arbeit wie selbstverständlich an: Kanban Board, Kaizen, Jira und Backlog sind keine fremden Welten mehr. In Sprints werden übergreifende Aufgaben mit AnforAnfordernden, Fachabteilungen und der Entwicklung abgearbeitet. Eine Übersetzung in die jeweils andere Welt entfällt, und aufkommende Missverständnisse durch die zugrunde liegenden Stand-ups oder Dailys werden rasch geklärt. Neben einer erheblich verbesserten Zusammenarbeit schaffen positiv ins Unternehmen eingebundene DevOps weitere Skaleneffekte:

  • Das Unternehmen senkt Kosten, weil sich Reibungsverluste
    verringern.
  • Die Softwareentwicklungseinheiten gewinnen mindestens 20 Prozent mehr Zeit, um neue Features zu entwickeln.
  • Ops wird bei neuen Entwicklungen nicht mehr erst in letzter Instanz gefragt, sondern ist stattdessen von Anfang an mit dabei, um Betriebsthemen rechtzeitig zu adressieren, wie zum Beispiel die Notwendigkeit von Stabilisierungspatches, rechtzeitigen Firewallfreischaltungen oder die Sicherstellung der Softwareanwendungskompatibilität mit Betriebssystemversionen der Produktionssysteme.

Rückbesinnung auf die Qualität

Wesentlicher technologischer Bestandteil von erfolgreichem, qualitativ hochwertigem DevOps ist eine sauber implementierte und zunehmend standardisierte CI/CD-Lösung (Continuous Integration and Continuous Delivery Pipeline). Sie ist der Garant für die schnelle, aber auch qualitätsgesicherte Auslieferung von Code über Software hin zu einer betreibbaren Anwendung auf den Servern der Produktionsumgebung. Schnelligkeit ist Standard. Stabilität ist entscheidend für das Business. Die CI/CD-Pipeline ist außerdem eine Software, die nach Softwaremethoden entwickelt, gewartet und betrieben wird. Freestylepipelines sind somit passé.

Dass der Betrieb bisher keine Kompetenzen hatte, Entwicklungsprozesse zu beherrschen – während die Entwicklung im Gegenzug keine Garantie für einen 24/7-Betrieb und den Aufbau von Servicestrukturen geben musste –, gehört ebenfalls der Vergangenheit an. Doch wie steht es um die Gegenwart? Dev übernimmt im Sinne von „You build it, you run it“ mehr Verantwortung für die Verfügbarkeit der programmierten Anwendung im Produktionsbetrieb. Ops bildet zunehmend Fähigkeiten aus, Build- und Deployment-Prozesse als agile Services zu etablieren. Idealerweise ist ein DevOps-Team ein gemischtes Team von Betriebs- und Testmitarbeitern sowie Softwareentwicklern und -architekten. Im Idealfall ist auch der anfordernde Product Owner Teil dieses Teams. Damit entstehen die notwendige interne Kundennähe und die Innovationen zur Weiterentwicklung der Anwendungssoftware und der CI/CD-Pipeline, die ebenfalls parallel weiterentwickelt werden muss. Kundennahes Arbeiten erfordert außerdem eine ausgeprägte Kommunikationsfähigkeit. Sich hinter der Ops-Console oder dem Dev-Programmiercode zu verstecken, ist nicht mehr möglich, denn Rollen und Kompetenzen haben sich längst geändert.

Welche Kompetenzen sind aber notwendig, die CI/CD-Pipeline derart hochwertig zu erstellen oder auf Geschäftsbedürfnisse anzupassen? Als Träger einer CI/CD-Pipeline findet Jenkins oft Anwendung, insbesondere im Open-Source-Bereich. Dafür sprechen die hohe Anzahl von Plug-ins sowie der außerordentlich hohe Communitysupport und der Einsatz in vielen kommerziellen Unternehmen. Jenkins dient auch zur Ansteuerung anderer Tools, die ebenfalls beherrscht werden müssen. Zur Codeverwaltung gehören SVN und Git, zur Build-Erstellung Maven und zur Softwareauslieferung auf dem Server die Tools Puppet, Chef oder Ansible. Insgesamt tummeln sich in diesem Bereich an die 60 bis 80 Tools.

Aus DevOps wird schließlich ein hochprofessionelles DevOps, also DevQOps, wenn in die CI/CD-Pipeline entsprechende Tests integriert sind: Funktionstest, Last- und Performancetest, Code-Quality- und Securitytest. Andere Organisationen oder Unternehmen sprechen auch von BizDevOps oder SecOps. Das „Q“ – für Qualität – trifft des Pudels Kern jedoch am besten, sichert doch die Stabilität die Grundwerte der DevOps-Philosophie nach außen. Aber auch die entstehenden Inneneffekte sind wichtig. Durch die Zusammenarbeit auf Augenhöhe werden Probleme gleich angesprochen und gelöst. Die Zeit des Ticketpingpong ist damit vorüber. Der Effekt: weniger Incidents und Problems und eine höhere Motivation der Mitarbeiter. Konkret heißt das, dass der System-Engineer weniger auf Tickets und Monitoringsysteme reagiert, sondern proaktiv mit Jenkins arbeitet. Er ist damit mitten im Geschehen und auf Augenhöhe mit allen Beteiligten.

Vertrauen bleibt ein wichtiger Wert

Fazit: In einer digitalen Welt, in der sich Technologie stetig weiterentwickelt, die nächste Stufe der DevOps-Automatisierung durch Machine Learning unterstützt wird und das Internetuniversum sich durch das Internet der Dinge unendlich vergrößert, bleibt menschliches Vertrauen ein notwendiger Wert für Zusammenarbeit und damit für den Geschäftserfolg. Vertrauen entsteht durch Transparenz. Unternehmen und Organisationen werden alte Pfade des Silodenkens, der Abschottung und der Abgrenzung verlassen und die Mitarbeiter ihrer Abteilungen und Lieferanten oder Partner zusammenbringen müssen. Daraus ergeben sich hohe Anforderungen an Datenschutz, Einkauf und Unternehmenskulturen. DevQOps in der beschriebenen Art und Weise kann ein wichtiger Baustein sein, das hierfür nötige Modell vorzuleben.

Geschrieben von
Olaf Garves
Olaf Garves
leitet die Abteilung Application Management Telco und Mobility Solutions bei T-Systems Multimedia Solutions (MMS). Seit 2013 beschäftigt er sich auch mit DevOps und hat seinen Bereich entsprechend agiler Anforderungen organisatorisch und prozessual weiterentwickelt. Dabei steht die Mitarbeiterförderung ganz vorne im Fokus. Garves ist im Beirat des itSMF und beteiligt sich aktiv in der DevOps-Community der T-Systems MMS.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: