Suche
Wenn DevOps krank macht

Burnout durch DevOps: Kollaps vorprogrammiert?

Michael Thomas

© Shutterstock.com/lassedesignen

Die zunehmende Verschmelzung von Anwendungsentwicklung und IT-Betrieb gehört zu den größten Umwälzungen der IT-Welt, die die letzten Jahre hervorgebracht haben. Doch neben den unbestreitbaren Vorteilen ergeben sich im Rahmen von DevOps auch nicht zu unterschätzende Probleme: Was geschieht beispielsweise, wenn Framework und (Unternehmens-)Kultur nicht zusammenpassen? Dann ist der Burnout der Entwickler unvermeidlich – meint zumindest Tomer Levy, seines Zeichens CEO des Softwareunternehmens Logz.io.

Einer Schätzung der WHO zufolge verursachen stressfördernde Arbeitsbedingungen alleine in den USA jährliche Kosten von rund 300 Milliarden US-Dollar; eine Studie des Chartered Institute of Personnel and Development (CIPD) identifizierte Stress als die häufigste Ursache für langfristige Krankschreibungen. Bei einer Übernahme von DevOps, so Levy, stehen die Chancen ziemlich „gut“, dass die Softwareentwickler ein Teil dieser Statistik werden.

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.

Zur Erinnerung: Kurz gesagt zielt DevOps darauf ab, die traditionell zwischen Anwendungsentwicklung und IT-Betrieb bestehenden Gräben so gut wie möglich zu überbrücken, also beide Bereiche näher zusammenrücken zu lassen. Damit gehen naturgemäß breiter gefächerte Verantwortlichkeiten für die Entwickler einher. Häufig wird in diesem Zusammenhang auch von einem kulturellen Wandel gesprochen.

Lesen Sie auch: Wie DevOps Entwickler dazu zwingt, mehr Verantwortung zu übernehmen

Einst …

Und genau dieser Wandel kann laut Levy für steigende Burnout-Fälle bei Entwicklern sorgen. Denn seiner Ansicht nach haben sich zwar die für einen erfolgreichen Übergang zu DevOps notwendigen Prozesse stetig weiterentwickelt, die Kultur am Arbeitsplatz hingegen nicht. Im Rahmen des traditionellen Wasserfall-Modells verbrachten Entwickler Wochen oder Monate mit dem Schreiben von Code und übergaben das so entstandene Produkt an die QA. Im besten Fall erfolgte einige Wochen darauf die Übergabe an den IT-Betrieb und anschließend in die Produktion. Bei Fragen von Seiten der Anwender wurde auf den Support und nicht die Entwickler selbst zurückgegriffen.

… und Jetzt

Im Falle von DevOps existiert diese Kette so nicht mehr: Entwickler sind nunmehr häufig nicht nur für die Entwicklung und Tests verantwortlich, sondern begleiten den Code mitunter bis in die Produktion und den Endbenutzer-Support. Gleichzeitig hat sich die Geschwindigkeit des Prozesses an sich deutlich erhöht, manche Unternehmen geben mehrmals pro Tag oder sogar mehrmals die Stunde (oder sogar Minute) Updates in die Produktion. Dass all dies den Stresspegel nach oben schnellen lässt und an den Entwicklern nicht spurlos vorbeigeht, ist für Levy sonnenklar – vor allem eben, wenn die Unternehmenskultur im Wesentlichen die alte geblieben ist.

Mögliche Gegenmaßnahmen

Was also tun, um den Druck zu mildern? Eine konkrete Patentlösung hat Levy zwar nicht in petto, allerdings hat er einige auf seiner eigenen Erfahrung basierende Ansätze auf Lager.

Eine Möglichkeit besteht demnach darin, eine Arbeitsatmosphäre zu schaffen, die ein gründliches Nachforschen sowie einen reibungslosen Wechsel des Arbeitskontextes ermöglicht und zugleich auf einen Wechsel der bei Produktionsproblemen einbezogenen Entwickler achtet. Einen weiteren Ansatz sieht Levy in dem Einsatz von SREs (Site Reliability Engineers), einer recht neuen Berufsgruppe, die quasi als Support-Team für die Entwickler und als Mittelsmann zwischen Dev und Ops dient.

Lesen Sie auch: Empathie – die Essenz von DevOps

Da, so Levy, zu guter Letzt jedoch immer die Entwickler für das Funktionieren der Software und die Einhaltung von Deadlines verantwortlich sind, ist dies jedoch beileibe nicht ausreichend. So müssen seiner Ansicht nach auch die Teamleiter und andere Führungskräfte mit ins Boot geholten werden. Diese sollten für ein unterstützendes Arbeitsumfeld sorgen, genau darauf achten, wie viel Zeit ein Mitarbeiter mit Tests, der Bug-Jagd und der Hilfe bei Produktionsproblemen (Überstunden) verbringt und schlussendlich auch ein wachsames Auge auf typische Burnout-Symptome wie beispielsweise Erschöpfung, mangelnde Geduld, explodierende Bugzahlen und erhöhten Stress bei der Einhaltung von Deadlines achten. Denn, so Levy, kennt man all diese Faktoren genau, so fällt es deutlich leichter, die zugrundeliegenden Probleme zu lösen – zum Wohle der Mitarbeiter.

Anzumerken ist indes, dass Protagonisten der DevOps-Bewegung ein reines Zusammenlegen von Betrieb- und Entwicklungsabteilungen kaum als „DevOps“ bezeichnen würden. Ohne den angesprochenen kulturellen Wandel ist DevOps nicht zu haben – allenfalls eine Verschiebung von Aufgaben, die meist zuungunsten der Entwickler ausfällt.

Aufmacherbild: Help von Shutterstock / Urheberrecht: lassedesignen

Verwandte Themen:

Geschrieben von
Michael Thomas
Michael Thomas
Michael Thomas studierte Erziehungswissenschaft an der Johannes Gutenberg-Universität Mainz und arbeitet seit 2013 als Freelance-Autor bei JAXenter.de. Kontakt: mthomas[at]sandsmedia.com
Kommentare

Hinterlasse einen Kommentar

2 Kommentare auf "Burnout durch DevOps: Kollaps vorprogrammiert?"

avatar
400
  Subscribe  
Benachrichtige mich zu:
Sven
Gast

DevOps sehe ich genauso kritisch. Nur weil Entwickler „alles“ können, sollten sie trotzdem nicht alles machen. 😉 Entwickler bekommen immer mehr Aufgaben (auch durch Agilität und DevOps). Irgendwer muss auch nochmal Zeit haben neue Features zu entwickeln…

Daniel Fisher
Gast

Hallo,

Wenn man dem Herrn Levy so zuhört bekommt man das gefühl, dass er a) nichts von Burn-out versteht und b) das mit DevOps auch nicht verstanden hat.

„Mehrmals pro X Updates in die Produktion. Dass all dies den Stresspegel nach oben schnellen lässt“

Dabei geht es doch nur um die Routine. Wer etwas häufiger macht, verliert die Angst. Das reduziert Stress… http://martinfowler.com/bliki/FrequencyReducesDifficulty.html

„SREs“

Das ist kein DevOps. Es geht darum, dass Admin und Entwickler *direkt* miteinander reden. Sich gegenseitig verstehen (lernen) und nach der Devise *Gemeinsam sind wir stärker* eine bessere qualität abliefern. Was wieder zu weniger Stress führt.

My 2 cent