DevOps … eine Unternehmensphilosophie, die Development, Test und Operations verbindet und die Time-to-Market verringert. Eine Philosophie, da es bei DevOps nicht nur um Methoden, Prozesse, Tools und Skills, sondern vor allem um neu gedachte Zusammenarbeit geht. Die Grenzen zwischen den Fachbereichen werden durchlässig. Damit die MitarbeiterInnen der T-Systems Multimedia Solutions (MMS) das Prinzip von DevOps kennenlernen und in ihre Bereiche tragen können, bietet das Unternehmen ein Job Rotations-Programm an – MitarbeiterInnen aus unterschiedlichen Abteilungen wechseln für einen begrenzten Zeitraum in das DevOps Team und arbeiten gemeinsam an dem Projekt DevOps@MMS. René (Softwareentwickler) und André (System Engineer) sind beim Programm dabei und berichten im Interview von seinen Vorteilen, aber auch den Herausforderungen.


Was bedeutet das Thema DevOps für euch?

René: Dass der komplette Entwicklungszyklus eines Produktes oder eines Services – von der Entwicklungs- oder Anforderungsaufnahme über den Test bis zum Betrieb – aus einem Team heraus gestemmt wird. Dieses Team hat die vollständige Verantwortung. Das erfordert ein Umdenken. Als Entwickler muss man Betrieb mit übernehmen, als Betriebler sich Entwicklungswissen aneignen.

André:  Das Problem bei klassischen Modellen ist, dass es Übergangspunkte zwischen Development, Test und Operations gibt. Wurde zum Beispiel etwas nicht sauber installiert, beginnt beim Release das große Fingerpointing zwischen diesen Bereichen:  „Wart ihr das?“ – „Nein, die anderen waren das“. Für mich ist der Inbegriff von DevOps, dass genau dies der Vergangenheit angehört. Dass gemeinsam versucht wird, das Problem zu lösen und alle gemeinsam für das Produkt einstehen. Natürlich soll im Rahmen von DevOps auch eine Toolkette entstehen, die für eine qualitative Sicherung der Arbeit sorgt, aber für mich steht DevOps vor allem für Änderungen in der kulturellen Zusammenarbeit. Es entstehen enge Netze, was letztlich auch die Qualität des Produkts hebt.

René: Wenn alle Zahnräder ineinander greifen, verkürzt DevOps die Zeit zwischen der bestehenden Anforderung bis zum Zeitpunkt, an dem die Lösung wirklich benutzt wird. Ein Plus für den Kunden.


Wie kann man sich die Arbeit im DevOps Team vorstellen?

André: Wir arbeiten daran, durchgängige Produktionsketten und automatisierte Übergänge von Development zu Test zu Operations zu schaffen. Dies umfasst u.a. das gemeinsame DevOps Framework, durchgängige Toolketten, automatisierte Prozesse sowie abgestimmte Rollenkonzepte. Das Framework umfasst die lose Kopplung von Services, die so aufeinander abgestimmt sind, dass sie eine – modulare, flexible – CD-Pipeline bewerkstelligen. Die Services können wiederum einzeln von unseren Kollegen bestellt werden und direkt in Kundenservices und Produkten eingesetzt werden.

Unser Team arbeitet innerhalb von Drei-Wochen-Sprints an der Weiterentwicklung des DevOps Frameworks. Gemeinsam entscheiden wir, welche Services wir uns als nächstes annehmen. Zum Beispiel gibt es den Service dopuppet (do für DevOps). Hier kümmern wir uns um die ganze Infrastruktur mit Puppet, einem Tool für Konfigurationsmanagement. Es gibt aber noch zahlreiche weitere Services. Ich persönlich helfe zum Beispiel konkret im dolog mit und momentan sind wir dabei, die Loggingstruktur in eine automatisierte Form zu gießen.

Wir haben damit in unseren Projekten schon viele Verbesserungen erzielt, zum Beispiel lassen sich entwicklungsbegleitende Skripte ohne viel Mehraufwand für den Betrieb wiederverwenden. Auch bekommt der Kunde zu jedem Release eine genaue Qualitätsaussage, ohne händischen Aufwand. Weiterhin ist ein Deployment nun jeden Monat auch am Werktag in maximal 2 Stunden möglich, statt wie zuvor aller 3 Monate bei 8 Stunden nur am Wochenende.


Warum wird das Thema DevOps gerade durch Job Rotation angegangen – was sind aus eurer Sicht die Vorteile?

René: Da wir aus verschiedenen Bereichen der MMS kommen, bringt jeder von uns Anforderungen aus unterschiedlichen Kundenprojekten in das DevOps@MMS-Programm ein und wir können dafür sorgen, dass das Endergebnis auch wirklich einen Mehrwert für die Kundenprojekte bietet. Darüber hinaus lernen wir uns über bestehende Bereichsgrenzen hinweg kennen, knüpfen Kontakte, um auch nach Beendigung des Programms weiterhin zusammenzuarbeiten. Gleichzeitig dienen wir auch als Wissensmultiplikator. Ich halte es für sehr wichtig, dass wir bei der Rückkehr in den eigenen Bereich unser Wissen kommunizieren und teilen. Wir können konkret in Kundenprojekten helfen, das erarbeitete und noch recht komplexe Framework einzusetzen.

André: Mit der Job Rotation kommen wir auch mal raus aus dem Tagesgeschäft, in welchem man manchmal den Blick verliert, was im Unternehmen links und rechts passiert. Mir persönlich hat es sehr geholfen, zu sehen, was in anderen Bereichen und Disziplinen passiert. Ich bekomme Einblicke in Aufgabenbereiche, die ich als System Engineer sonst nie bekommen würde und welche für das Leben der DevOps-Philosophie sehr wichtig sind. Das finde ich cool.

> Zum Whitepaper
Nutzen und Einsatz von DevOps und Cloud in deutschen Unternehmen


Für eine Weile seinen alten Job zu verlassen, birgt bestimmt auch Schwierigkeiten.

André: Ich glaube jeder hat da seine eigene Geschichte. In meinem konkreten Fall hat es einfach gepasst, da das Kundenprojekt auslief, welches ich als Systemverantwortlicher betreut habe, und somit das Arbeitsvolumen zurückging. Es wird nicht in jedem Fall so einfach sein, aber ich denke, da findet sich immer eine Lösung.

René: Bei mir hat es vom ersten Wunsch tatsächlich ein halbes Jahr gedauert, bis es endlich geklappt hat. Konkret ist jemand eingestellt worden, der dann Aufgaben von mir übernahm. Im Vorfeld haben wir uns bemüht, alles zu dokumentieren, zu automatisieren und unser Wissen zu verteilen. Das klappt relativ gut, auch wenn jetzt immer noch mal Nachfragen kommen, wo meine Hilfe benötigt wird.

André: Richtig, das Thema Wissensverteilung ist ein wichtiger Punkt. In meinem Fall wurde ein Vertrag aufgesetzt, ein Job-Rotation-Vertrag, und dort wurde verankert, dass ich für spezielle Anfragen aus dem alten Projekt zur Verfügung stehe. Ich sagte ja, man findet Lösungen. Wir haben auch einen im Team, der noch zu 20 Prozent in seinem alten Kundenprojekt unterwegs ist. Wir haben auch einige Kollegen  aus der Business Technology, welche andersherum in ihrem alten Bereich weiterarbeiten und 20 Prozent ihrer Zeit für DevOps investieren. Das geht natürlich auch.


Welche Herausforderungen brachte der Wechsel des Arbeitsalltages für euch?

René: Bei mir sind es bisher erst zweieinhalb Monate und ich muss ehrlich sagen, mir brummt der Kopf, weil so viel Neues auf mich zukommt. Ich hab zwar vorher schon ein bisschen im Betrieb zu tun gehabt, aber das jetzt nötige Betriebs-Knowhow hier im Team ist noch mal deutlich umfangreicher. Zum Beispiel wird intensiv mit der Technologie Puppet gearbeitet, mit der hatte ich vorher noch nicht gearbeitet und auch keine entsprechende Schulung, ein Sprung ins kalte Wasser für mich. Aber ich lerne gern neue Sachen dazu, deshalb wollte ich auch ins Projektteam.

André: Für mich war eine Herausforderung, in einer anderen, neuen Dimension zu denken. Im Arbeitsalltag denkt man meist in seiner Kundendimension, in der Teamdimension, aber damit endet meist der Horizont. Plötzlich gilt es, MMS-weit zu denken und einzubeziehen, wie die einzelnen Einheiten ticken und welche abteilungsinternen Herausforderungen es gibt. Aber das ist auch der Vorteil am Programm, dass aus jeder Abteilung jemand da ist, den man fragen kann.


Würdet ihr das Job Rotation Programm weiterempfehlen?

René: Das habe ich bereits und ich könnte mir vorstellen, dass sich darunter auch ein paar Kandidaten finden werden. Ich denke, das Wichtigste ist das Interesse am übergreifenden Arbeiten. Wenn du das entsprechende Wissen noch nicht mitbringst, dann ist das Programm umso wertvoller, denn genau das bekommst du darin vermittelt. Und ich finde es ideal für Entwickler als auch für Betriebler, da sie die jeweils andere Seite kennenlernen.

Zum Abschluss – euer ultimativer Rat für andere Unternehmen?

André: Also wenn die Möglichkeit besteht, DevOps umzusetzen, dann würde ich persönlich sagen, ist es immer besser, das Problem gemeinsam zu lösen und nicht von oben herab anzugehen. Natürlich braucht es dann ein bisschen mehr Zeit, wird dann am Ende aber besser in der Firma angenommen.
René: In den Anfängen der IT gehörten Entwicklung und Betrieb zusammen, aus dem Optimierungswunsch heraus wurden sie künstlich getrennt, was meiner Ansicht nach eine Fehlentwicklung war. Unternehmen, die diese Fehlentwicklung nicht korrigieren, werden es schwer haben. Insofern: Wenn ein Unternehmen überleben möchte, sollte es den DevOps-Weg gehen.

Kollegen gesucht:
Hier geht’s zu den aktuellen Stellenausschreibungen:
> Stellenbörse


Mit Freunden teilen

> Zuerst Social Funktionen aktivieren