Gute Zusammenarbeit braucht ein solides Fundament

DevOps funktioniert nicht nach einem Tag

| Autor / Redakteur: Patrick Hubbard / Stephan Augsten

Selbst in erfolgreichen DevOps-Teams gibt es immer wieder Momente, in denen es einen Schritt vor und dann wieder zwei Schritte zurück geht.
Selbst in erfolgreichen DevOps-Teams gibt es immer wieder Momente, in denen es einen Schritt vor und dann wieder zwei Schritte zurück geht. (Bild gemeinfrei: rawpixel / Pixabay)

Softwareentwicklung und IT-Betrieb im Zuge von DevOps-Strategien zu einer Einheit zu verschweißen, ist mitunter schwieriger als gedacht. Da die Teams sich aber auf die neue Arbeitskultur einstellen müssen, ist es wichtig, auch nach Fehlschlägen nicht sofort aufzugeben.

DevOps wird immer beliebter und sorgt in Vorstandsetagen zahlreicher Unternehmen zunächst für Begeisterung und dann für Bedenken: Viele sind sich des Hypes bewusst und fürchten, ins Hintertreffen zu geraten, wenn sie die neuen Arbeitsweisen nicht auch selbst bald einsetzen.

Diese Sorge verleitet manche Führungskräfte, eine sofortige Zusammenarbeit zwischen Entwicklern und Betriebsteams anzuordnen, auch wenn diese noch nie zusammengearbeitet haben oder sich bisher vielleicht gar als Konkurrenz betrachteten. Meist werden die resultierenden Probleme schon in den darauffolgenden Wochen offensichtlich.

Entwicklungs- und Betriebsteams unterscheiden sich schließlich grundlegend: Sie haben verschiedene Arbeitsweisen und Prioritäten und gehen Probleme unterschiedlich an. All das bietet Potenzial für eine sehr vielversprechende Zusammenarbeit, aber nur, wenn die Grundlagen dafür geschaffen wurden.

Legt man nicht einfach blind mit einem DevOps-Versuch los, dann eignet sich das Konzept hervorragend, um Innovation anzuregen und den Wandel im Unternehmen zu beschleunigen. Dieser Prozess wird selten ohne Meinungsverschiedenheiten, Schuldzuweisungen und Spannungen vonstattengehen.

Doch wer IT-Teams fragt, die diese Umstellung bereits gewagt haben, wird erfahren, dass viele von ihnen deutlich flexibler geworden sind, Stress reduzieren sowie die Kundenzufriedenheit steigern konnten. Nicht wenige sagen sogar, dass sie nie wieder nach dem Wasserfallmodell arbeiten wollen würden.

Die Tools für die Zusammenarbeit

Veränderungen der Teamkultur sind die wichtigste Voraussetzung, doch auch die entsprechenden Tools sind für den technologischen Wandel im Team unverzichtbar. Eine gut durchdachte DevOps-Toolchain vereinfacht die Arbeit von Software- und Infrastrukturtechnikern und lässt ihnen mehr Zeit für die Arbeit an neuen Projekten und Funktionen, um Architektur, Systeme und Qualität für die Endbenutzer zu optimieren und das Unternehmen voranzubringen.

Wie immer bei der Automatisierung werden Systeme besser, je mehr Zeit man für deren Optimierung aufwendet. Mit DevOps-Prinzipien werden diese Verbesserungen datengesteuert und wiederholbar, statt auf Vermutungen und Meinungen zu basieren. Die passenden und richtig eingesetzten Tools bewahren vor dem Teufelskreis, immer wieder hauptsächlich mit dem Lösen von Problemen beschäftigt zu sein, statt sie proaktiv zu verhindern.

Je nach Unternehmen werden unterschiedliche Tools benötigt, doch einige grundlegende Prinzipien für effektive Untersuchungen, Auswertungen und Analysen bleiben gleich. Für viele Technologieteams ist DevOps noch ziemlich neu und bietet die Gelegenheit, neue Methoden der Zusammenarbeit mit bereits im Einsatz befindlichen Tools einzuführen und diese systematischer zu nutzen.

Die Priorität sollte auf Tools liegen, die Kommunikation, Zusammenarbeit und Integration in den Vordergrund rücken. Wenn Softwareentwickler, Qualitätssicherungsingenieure und IT-Betrieb über ein zentrales Dashboard eine gemeinsame Datenbasis nutzen, sorgt dies bereits für weniger Konflikte und eine schnellere Problemlösung.

Das große Ganze betrachten

Doch wie sieht dies im großen Maßstab aus? Die richtigen Tools bieten Entwicklern schnellen Zugriff auf die Leistungsdaten, mit denen auch das Betriebsteam überwacht, welche Auswirkungen Änderungen auf die Performance haben.

Die Teams beginnen wie von selbst, Tools zur Anwendungsleistungsüberwachung (APM) einzusetzen, um die Leistung für Benutzer nicht mehr anhand von Infrastrukturmessdaten schätzen zu müssen. Außerdem integrieren sie APM-Tools in die Entwicklungszyklen, um die Leistung und Skalierbarkeit schon lange vor der Auslieferung des Codes zu überprüfen.

Noch besser: Fachkräfte wie DBAs, an denen häufig ein Mangel herrscht, werden nicht mehr für jede CPU- oder Arbeitsspeicherwarnung herangezogen. Sie können sich stattdessen auf Serviceindikatoren wie die Wartezeit konzentrieren und Abfrage- oder Tabellenoptimierungen für die Entwickler vornehmen.

Auf Produktionsseite benötigt der IT-Betrieb Tools für eine einfachere Zusammenarbeit mit der erweiterten IT-Organisation. Ein einheitlicher Überblick über die Anwendungsleistung macht es sehr viel einfacher, die die Kontrolle über Produktionsinfrastruktur, Workloads und Speicher zu behalten.

DevOps-orientierte Teams überprüfen das Anwendungsverhalten auf erwartete oder unerwartete Änderungen – und zwar von der Entwicklung über die Qualitätssicherung und Leistungstests bis zur Produktion. Wenn ungeplante Aufgaben auftauchen, liegt das meist an unbekannten Aufgaben oder Systemen, von denen noch nicht bekannt ist, wie sie sich verhalten sollen. Ungeplante Arbeit ist in Betriebsteams nicht gerade gern gesehen.

Führungskräfte müssen sicherstellen, dass die Techniker die Tools als benutzerfreundlich betrachten und einen Mehrwert in ihnen sehen, denn andernfalls werden sie sie nicht verwenden. Auch wenn jeder ein Lieblingstool hat, sorgt gutes Teamwork dafür, dass sich erfolgreich auf eine Vorgehensweise geeinigt wird.

Statt „Was funktioniert für mich am besten?“ steht die Frage „Was ist das Beste für unser Team?“ im Vordergrund. Ein weiterer Vorteil besteht darin, dass Teams häufig Sicherheitsrichtlinien als weitere Überwachungsdimension einführen und berücksichtigen, wenn unternehmenskritische Daten in verschiedenen Teams genutzt werden.

DevOps braucht Zeit

Selbst in erfolgreichen DevOps-Teams gibt es immer wieder Momente, in denen es einen Schritt vor und dann wieder zwei Schritte zurück geht. Nicht wenige erzählen, dass es gelegentlich zu erbitterten Streitigkeiten kam oder gar die Zusammenarbeit zeitweise zum Erliegen kam.

Das ist auch völlig in Ordnung: Änderungen der Unternehmenskultur und persönliche Weiterentwicklung sind selten völlig geradlinig, egal wie sehr die Bedeutung des Ziels im Bewusstsein ist. Führungskräfte und IT-Experten sollten nichtsdestotrotz Maßnahmen ergreifen, um das Risiko von Fehlschlägen zu minimieren und zuerst an die Menschen und dann an die Technik zu denken.

Nur auf diese Weise können DevOps-Methoden mit deutlich größerer Wahrscheinlichkeit optimal genutzt werden. Wenn alle Beteiligten das große Ganze überblicken, die Gründe für Veränderungen kennen und dasselbe Ergebnis anvisieren, wird das Ändern von Arbeitsweisen und Gewohnheiten zur Selbstverständlichkeit.

Eine DevOps-Kultur ermöglicht es fast allen Unternehmen, sich zu modernisieren und oft neuartige Möglichkeiten zur Nutzung von Technologien und Prozessen zu entdecken. Leistungsstarke Teams, die reibungslos zusammenarbeiten, können sich eigene Ziele setzen und zu agilen Partnern für das Unternehmenswachstum werden.

Scheitert die DevOps-Einführung dennoch, liegt das häufig daran, dass nach ersten Fehlschlägen bereits aufgegeben und zu traditionellen Methoden zurückgekehrt wurde. Dabei sind chaotische Phasen Teil des Wachstumsprozesses. Nur durch Versuch und Irrtum in der eigenen Umgebung können Teams herausfinden, wie sie die DevOps-Prinzipien ideal an das eigene Unternehmen anpassen können.

Der Gartner-Report „New Insights into Success with Agile in Digital Transformation“ beschäftigt sich mit diesem Thema und fand heraus, dass Teams mit weniger als 12 Monaten Erfahrung mit einem neuen Entwicklungsprozess nur in 34 Prozent der Fälle Erfolg hatten. Teams mit ein bis drei Jahren Erfahrung waren hingegen in 64 Prozent der Fälle erfolgreich, bei mehr als drei Jahren sogar 81 Prozent. DevOps erfordert Geduld, Engagement und Vertrauen in den Lauf der Zeit.

Patrick Hubbard, Head Geek
Patrick Hubbard, Head Geek (© SolarWinds)

Fazit

Im zweiten Jahrzehnt von DevOps können wir möglicherweise mit einer Wiedergeburt des IT-Betriebs als Wettbewerbsvorteil rechnen, ähnlich wie bei der ursprünglichen Einführung von Computern in Unternehmen. Diese waren damals nicht nur wegen all der Technik in raumhohen Schränken erfolgreich, sondern wegen ihres Bekanntheitsgrads und der entsprechenden Investitionen.

DevOps ist ein Werkzeug wie jedes andere. Doch es hat das Potenzial, selbst risikoscheue, änderungsresistente Teams in vielseitige, reaktionsschnelle Geschäftspartner zu verwandeln – eine Entwicklung, von der alle profitieren können.

Über den Autor

Patrick Hubbard ist Head Geek bei SolarWinds.

Kommentare werden geladen....

Kommentar zu diesem Artikel

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de/ (ID: 46195159 / Head Geeks Speech)