Aufbau einer DevOps-Kultur – Geschwindigkeit, Risiko, Geduld und Vertrauen

DevOps ist eine Reihe von Verfahren, die die Prozesse zwischen Softwareentwicklungs- und IT-Teams automatisieren, damit sie Software schneller und zuverlässiger erstellen, testen und freigeben können. Das Konzept von DevOps basiert auf dem Aufbau einer Kultur der Zusammenarbeit zwischen Teams, die historisch in relativen Silos funktionierten. Die versprochenen Vorteile umfassen mehr Vertrauen, schnellere Software-Releases, die Fähigkeit, kritische Probleme schnell zu lösen und ungeplante Arbeit besser zu verwalten. 1

DevOps entwickelt sich weiter … zu einer Kultur für die kontinuierliche Bereitstellung von IT-Services. Je mehr Teile des Puzzles sich einfügen, desto besser verstehen wir, dass DevOps in erster Linie eine Frage der menschlichen Zusammenarbeit ist – unterstützt von Tools und Technologien. [2]

Erweitern Sie die Sicht mit DevOps

Das Wort “DevOps” ist eine Verschmelzung von “Entwicklung” und “Betrieb”. Es bezog sich ursprünglich auf Bemühungen, diese beiden Aspekte der Softwareaktivitäten zusammenzuführen, wobei “Fabrikprodukt” durch ein Lieferverfahren (Ops) in “Verbrauchsmaterial” umgewandelt wird (Dev). [3]

“DevOps culture” erweitert sozusagen das Gelände, auf dem DevOps gebaut wurde. Es ist auch die geheime Zutat, die für jede Organisation erforderlich ist, die DevOps-Praktiken in ihre eigenen Geschäftsprozesse einbetten möchte. Nur wenn die DevOps-Kultur eingeführt wurde, kann die Organisation die Vorteile von DevOps nutzen. So wie das Lied sagt: “Ohne das andere kannst du keins haben.”

Stufen der DevOps-Bereitschaft

Viele jüngere Unternehmen waren in der Lage, von Anfang an fortschrittliche Software und / oder Services und agile Methoden in ihre Geschäftsabläufe zu integrieren. Wenn sie dies noch nicht getan haben, werden sie wahrscheinlich in der Lage sein, die DevOps-Kultur und die ihr zugrundeliegenden Techniken und Gewohnheiten in ihr tägliches Betriebsgefüge zu integrieren.

Aber für viele andere Organisationen ist und wird die Integration fortgeschrittener Technologien ein Kampf sein. Diese Unternehmen müssen sich mit Legacy-Systemen auseinandersetzen – um nur ein Beispiel zu nennen – aber auch mit einer kulturell tief verwurzelten Abhängigkeit von diesen Systemen und anderen Gepäckstücken. Es gibt also zwei Arten von Kämpfen: technische – nennen wir das “Ziel” für gegenwärtige Zwecke – und kulturelle: “dispositionale” oder “subjektive”.

Im Grunde genommen geht es bei der “Kultur” nur um Gewohnheiten – darum, sie zu behalten, sie zu verändern, zu aktualisieren und – ja – sie zu brechen. Und wenn wir über Gewohnheiten sprechen , sprechen wir oft auch über Interessen . Auch “Interessen” können entlang derselben Bruchlinie klassifiziert werden:

  • Business-Interessen
  • Qualitäts-Interessen
  • Mitarbeiter-Interessen

DevOps Change – technisch und kulturell

Die für einen grundlegenden Kulturwandel erforderlichen Investitionen können auf ihre Art ebenso bedeutsam sein wie technische Veränderungen. Wenn das nach Übertreibungen klingt, sollten Sie folgendes beachten: Laut Gartner werden in diesem Jahr 90% der Infrastruktur- und Operations-Organisationen, die versuchen, DevOps zu verwenden, “ohne ihre kulturellen Grundlagen zu berücksichtigen”, versagen. [4]

Diese Art von Statistik sollte als Weckruf für Organisationen dienen, die erwogen haben, nicht nur DevOps, sondern auch DevOps-Kultur in ihr Gefüge zu integrieren. Dies gilt insbesondere, wenn es darum geht, den Wandel maßgeblich zu gestalten: das Tempo dieser Veränderung.

DevOps Spannungen – konzeptionell und praktisch

Es gibt zwei Hauptspannungen, die wir um diesen Änderungsfaktor herum identifizieren können. Und diese zu verstehen und ihnen zu begegnen, kann Unternehmen bereits dabei helfen sicherzustellen, dass sie eine robuste DevOps-Kultur aufbauen können.

Die erste Spannung ist konzeptuell: zwischen der Geschwindigkeit einerseits und der Deliberation oder der Geduld andererseits, mit der (gesamten kulturellen) Einstellung der Organisation zum Risiko [5], die als eine Art vermittelndes Element dient.

Die zweite Spannung ist praktisch: Es handelt sich um einen grundlegenden Interessenkonflikt zwischen den beiden Akteursgruppen, deren Arbeit hier involviert ist: (Web-) Entwickler und Infrastruktur, oder Operationen, Ingenieure.

Schauen wir uns diese Spannungen nacheinander an.

Um schneller zu gehen, sei zuerst geduldig

In einem (vereinfachenden) Sinne, wie Fordismus, Taylorismus und sogar Muzak davor, kann DevOps als alles über Geschwindigkeit angesehen werden – über das Produzieren von mehr in weniger Zeit. Definitionen von DevOps unterscheiden sich beträchtlich – als ein Konzept, es ist immer noch eine Arbeit in Arbeit – aber eine Sache, die sie alle gemeinsam haben, ist ein Verweis auf Aktualität: “DevOps zielt auf kürzere Entwicklungszyklen, erhöhte Einsatzfrequenz und zuverlässigere Releases …. ” [6] Ähnlich begann ein McKinsey-Blog, der letztes Jahr veröffentlicht wurde:

Schnelle Innovation, Time-to-Market, Kundenorientierung, verhalten wie ein Start-up-Sound vertraut? Es sind alles Phrasen, die den CEO begeistern und denen Angst einflößen, die damit beschäftigt sind, ihre Organisationen zu leiten, zu transformieren und zu schützen … Agile Methoden können die Produktentwicklung beschleunigen, neue Werte schaffen und organisatorische Veränderungen anstoßen.

Aber Schwierigkeiten entstehen, wenn das Bedürfnis nach Geschwindigkeit isoliert von den anderen Schlüsselelementen von DevOps betont wird – und hier kann es schwierig werden. Der gleiche McKinsey Blog gibt ein Beispiel:

Wir haben viele Organisationen wie Banken und Telcos gesehen, die Millionen in die agile Entwicklung pumpen und nach jedem Sprint ein fertiges Produkt liefern – und dann warten (und warten … und warten). Wenn das Produkt schließlich live geschaltet wird, geschieht dies über eine große, altmodische Version.

Ein Grund dafür ist eine “tief verwurzelte kulturelle Risikoaversion”, die wiederum auf die Erfüllung von “Compliance-Forderungen” zurückzuführen ist. Und es wird argumentiert, dass es “eine massive Verschiebung – eine kulturelle Verschiebung – zur Überwindung” der Vorsicht, die am Ende als Bremse für das Tempo des Wandels dient, unternimmt.

Interessenkonflikte: Entwicklungswechsel versus operativer Widerstand

Und das bringt uns zu der zweiten Spannung, die wir oben angemerkt haben: zwischen beruflichen Interessensgruppen innerhalb einer Organisation. Auf einer Ebene kann diese Spannung als in einem “Konflikt zwischen Jahren und Jahrzehnten entstandener Konflikte gesehen werden, in dem Entwicklungs- und Operationsteams voneinander getrennt sind und nicht in der Lage sind zu kommunizieren, geschweige denn effektiv zusammenzuarbeiten.” Aber es wird schlimmer: Mark Burgess stellt das Problem wie folgt dar:

Es gibt einen grundlegenden Interessenkonflikt zwischen den Rollen des Entwicklers und des Operations Engineers …. Web-Entwickler sind motiviert, neue Güte so schnell wie möglich zu erreichen. Infrastrukturingenieure haben oft wenig Anreiz, etwas zu ändern. Sie sind daran gewöhnt, ignoriert zu werden, bis etwas schief geht, woraufhin sie die Schuld für die Schuld haben. Etwas ohne die gebotene Sorgfalt zu implementieren, würde sie nur in Schwierigkeiten bringen. Für Entwickler während des Web-Booms war der operative Widerstand das Problem. Bei den Operationen war der Entwicklungswandel das Problem.

Um dieses grundlegende Problem anzugehen, ist ein grundlegender Wandel erforderlich. Und es muss den oben erwähnten “massiven … kulturellen Wandel” beinhalten. Das erste Adjektiv bedeutet hier, dass die Verschiebung innerhalb der Organisation stattfinden muss. Und das braucht Zeit – genau die Ware, die so knapp erscheint, wenn wir DevOps nur als eine Frage der Effizienz betrachten.

Das zweite Adjektiv “kulturell” bezieht sich hier auf die Einstellungen, die alle Schlüsselakteure in einem Veränderungsprogramm gegenüber dieser Veränderung haben. Und die zentrale Komponente jeder veränderten Einstellung ist Vertrauen. Und damit wir hier nicht zu heikel werden, wollen wir präzisieren, dass wir “funktionales Vertrauen” meinen. Ein solches Vertrauen zwischen den Akteuren in einer Organisation aufzubauen, ist der Schlüssel zum Aufbau der DevOps-Kultur in der Struktur einer Organisation.

DevOps – Kleines Wort, große Anforderungen

Am Ende ist DevOps ein kurzes Wort, das eine Reihe von Anforderungen enthält, die nichts zu verachten sind:

  • Auf der technischen Seite: Holen Sie sich das Kit Ihrer Organisation und bereinigen Sie das alte Durcheinander
  • Sich mit allen Akteuren auseinandersetzen, die die Veränderungen, die eine neue DevOps-Kultur ermöglicht, implementieren werden, sowie alle Mitarbeiter, die von ihnen betroffen sein werden (wahrscheinlich alle)
  • Arbeiten Sie insbesondere daran, eine Kultur des Vertrauens im Hinblick auf die Einhaltung von Vorschriften und Anforderungen aufzubauen (im Gegensatz zum Aufbau einer Kultur der gerechten Einhaltung ).
  • Seien Sie darauf vorbereitet, langsamer zu werden, in Anerkennung der massiven Veränderungen, um sowohl auf der ganzen Linie als auch nachhaltig schneller zu werden

Es ist wie alles andere, um diese Forderungen zu erfüllen, und der Gewinn in Form einer “Kultur effektiver und nahtloser Zusammenarbeit” ist es mehr als wert. [7]

Der Beitrag erschien zuerst bei Exin.

1.Quelle: https://www.atlassian.com/devops ↩ 
[2] Quelle: http://markburgess.org/blog_devops.html . 
[3] Quelle: http://markburgess.org/blog_devops.html 
[4] Quelle: https://cio.economectimes.indiatimes.com/news/corporate-news/gartner-highlights-5-key-step-to- -liefern-an-agile-io-culture / 47014075? redirect = 1 . 
[5] Siehe https://www.mckinsey.com/business-functions/digital-mckinsey/our-insights/digital-blog/five-cultural-changes-you-need-for-devops-to-work 
[6] Quelle: https://en.wikipedia.org/wiki/DevOps . 
[7] Quelle:https://devops.com/10-top-tips-devops-cultural-change .



Leave Comment

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.