DevOps und die kritischen Fragen
(Originalartikel von Mark Smalley, übersetzt von Alexandra Ordeanu (Juli 2021)):
Sagen Sie es weiter:
Mein Vortrag auf der kommenden itSMF UK-Konferenz (der Originalartikel wurde 2016 veröffentlicht) ist die neueste Wiederholung meines Vortrags „Kill DevOps“-. Die erste Version habe ich 2014 in Peking präsentiert und seitdem wahrscheinlich 20 Änderungen daran vorgenommen. Dieser Prozess der kontinuierlichen Verfeinerung ist ganz im Einklang mit der Botschaft hinter dem kryptischen Titel. „Kill DevOps“ bezieht sich auf ein altes Zen-Sprichwort über die Reise eines Mönchs zur Erleuchtung und zum Erwachen. Wenn du glaubst, dass du die Erleuchtung gefunden hast, denk noch einmal nach, denn das wirst du nie. So ist es auch bei DevOps: Es geht um kontinuierliches Experimentieren und Lernen.
Was die praktische Anleitung angeht, möchte ich Ihnen einige wichtige Aspekte in Form von kritischen Fragen, die Sie sich stellen sollten, mit auf den Weg geben.
Welches Problem versuchen Sie zu lösen?
Die meisten Menschen investieren in DevOps, um ihre Development- und Deployment-Prozesse zu beschleunigen und dabei das Betriebsverhalten ihrer Informationssysteme und Services nicht zu beeinträchtigen – und oft sogar zu verbessern: Zuverlässigkeit, Verfügbarkeit, Sicherheit. Ob DevOps Kosten spart, ist umstritten. Ja, es macht einige Aktivitäten effizienter, aber auf der anderen Seite ist es eine ziemliche Investition, die DevOps-Kultur und -Praktiken zu übernehmen. Es wird Ihnen nicht wirklich dabei helfen, Ideen für neue Funktionen zu entwickeln – das liegt eher im Bereich von “Agile”. Es hat jedoch das Potenzial, die IT zu einem besseren Arbeitsplatz zu machen. Menschen wie menschliche Wesen zu behandeln, ist einer der Grundsätze von DevOps. Wenn Sie also auf der Suche nach einer höheren Veränderungsrate, einem besseren Betriebsverhalten und Spaß an der Arbeit sind, lesen Sie weiter.
Können Sie sich die Vorteile leisten?
Menschen nutzen die kulturellen Normen und technischen Praktiken von DevOps auf unterschiedliche Weise und in verschiedenen Arten von Organisationen, aber der gemeinsame Erfolgsfaktor scheint ein innerer Antrieb und die Überzeugung zu sein, dass sich die Dinge radikal ändern müssen. Obwohl viele Menschen DevOps-Prinzipien und -Praktiken erfolgreich in ihren eigenen Organisationen angewendet haben, ist es immer zweifelhaft, ob das, was funktioniert hat, auch für eine andere Organisation mit ihren eigenen spezifischen Umständen funktionieren wird. Ich mache oft den Vergleich mit dem Übergang vom dunklen Zeitalter zum Zeitalter der Aufklärung.
Das dunkle Zeitalter der IT war geprägt von starren Projektplänen und Prozessen, unterstützt von Service Level Agreements, die das Verhältnis zwischen Business und IT polarisierten. Das Zeitalter der IT-Aufklärung ist reaktionsfähiger, emergent und integrativ. Multidisziplinäre Zusammenarbeit ist das Gebot der Stunde, mit einem hohen Maß an Vertrauen zwischen allen Beteiligten. Dazu gehören auch die Manager, die nun gefordert sind, mit den Händen im Rücken zu managen – nicht alle sind dieser Aufgabe gewachsen. Die Frage, die Sie sich also stellen müssen, ist, ob Sie bereit sind, einen ziemlich rigorosen organisatorischen und kulturellen Wandel zu vollziehen, um aus DevOps einen Nutzen zu ziehen.
Ist das DevOps-Pferd für Ihren Kurs geeignet?
DevOps gedeiht unter den Bedingungen organisatorischer Komplexität. Ich verwende den Begriff Komplexität, um eine lose Kopplung zwischen Ursache und Wirkung zu bezeichnen. Einer der Experten auf diesem Gebiet ist Dave Snowden. Unter Bezugnahme auf sein Cynefin-Framework unterscheidet Snowden zwischen fünf Bereichen:
1 Offensichtlich, in dem die Beziehung zwischen Ursache und Wirkung für alle offensichtlich ist
2 Kompliziert, bei dem die Beziehung zwischen Ursache und Wirkung eine Analyse oder eine andere Form der Untersuchung und/oder die Anwendung von Expertenwissen erfordert
3 Komplex, bei dem der Zusammenhang zwischen Ursache und Wirkung nur im Nachhinein, nicht aber im Voraus erkannt werden kann
4 Chaotisch, bei dem es keine Beziehung zwischen Ursache und Wirkung auf Systemebene gibt
5 Unordnung, bei der nicht bekannt ist, welche Art von Kausalität vorliegt.
Die deterministischen Bereiche „offensichtlich“ und „kompliziert“ sind ein ziemlich gutes Terrain für strukturierte Projektpläne und -prozesse, weil man mehr oder weniger weiß, wie die Dinge reagieren. Wenn die Bedingungen jedoch weniger vorhersehbar sind, funktioniert ein eher emergenter Ansatz besser. Snowden nennt dies Probe – Sense – Respond. Da die nicht-deterministische Natur des „Systems“ bedeutet, dass eine ausfallsichere Lösung unrealistisch ist, geht es darum, kleine Safe-to-Fail-Experimente zu treffen. Dies entspricht der DevOps-Kultur, die das ständige Experimentieren, das Eingehen von Risiken und das Lernen begünstigt. Unter den Bedingungen der Komplexität werden Sie den größten Nutzen aus dem Reiten des DevOps-Pferdes ziehen. Oder auf dem Einhorn, wenn Sie in einem ausgefallenen Unternehmen wie Amazon, Netflix, Google, Spotify oder Etsy arbeiten.
This article was originally published in English on ITSM.tools.
