Wir sprechen über DevOps in verständlicher Sprache

Es ist schwierig, das Wesentliche zu erfassen, wenn man über DevOps spricht? Wir haben für Sie prägnante Analogien, prägnante Formulierungen und Ratschläge von Experten zusammengestellt, die selbst Nicht-Spezialisten helfen, zum Kern der Sache zu gelangen. Am Ende gibt es einen Bonus – das eigene DevOps-Team von Red Hat.

Der Begriff DevOps entstand vor 10 Jahren und hat sich von einem Hashtag auf Twitter zu einer kraftvollen kulturellen Bewegung in der IT-Welt entwickelt, einer echten Philosophie, die Entwickler ermutigt, schneller Ergebnisse zu erzielen, zu experimentieren und durch Iteration voranzukommen. DevOps ist untrennbar mit dem Konzept der digitalen Transformation verbunden. Doch, wie es oft bei IT-Begriffen der Fall ist, hat DevOps in diesen zehn Jahren viele Definitionen, Interpretationen und Missverständnisse angesammelt.

Deshalb hört man häufig Fragen wie: Ist das dasselbe wie Agile? Oder ist es eine spezielle Methodologie? Oder ist es einfach ein weiteres Synonym für das Wort „Zusammenarbeit“?

DevOps umfasst viele verschiedene Konzepte (kontinuierliche Lieferung, kontinuierliche Integration, Automatisierung usw.), daher kann es schwierig sein, das Wesentliche herauszufiltern, insbesondere wenn man für das Thema sensibilisiert ist. Diese Fähigkeit ist jedoch sehr nützlich, unabhängig davon, ob Sie Ihre Ideen an die Führungsebene weitergeben oder einfach nur jemandem aus der Familie oder Bekannten von Ihrer Arbeit erzählen. Deshalb lassen wir vorerst die terminologischen Feinheiten von DevOps beiseite und konzentrieren uns auf das Gesamtbild.

Was ist DevOps: 6 Definitionen und Analogien

Wir haben Experten gebeten, die Essenz von DevOps so einfach und kurz wie möglich zu erklären, damit ihr Wert für Leser mit jedem technischen Niveau verständlich wird. Aus diesen Gesprächen haben wir die eindrucksvollsten Analogien und prägnantesten Formulierungen ausgewählt, die Ihnen helfen werden, Ihre Erzählung über DevOps aufzubauen.

1. DevOps ist eine kulturelle Bewegung

„DevOps ist eine kulturelle Bewegung, innerhalb derer beide Seiten (Softwareentwickler und IT-Systemadministratoren) anerkennen, dass Software keinen realen Nutzen bringt, solange sie nicht von jemandem genutzt wird: Kunden, Klienten, Mitarbeitern, das spielt keine Rolle“, sagt Eveline Oehrlich, Senior Analystin am DevOps Institute. „Deshalb sorgen beide Seiten gemeinsam für eine schnelle und qualitativ hochwertige Lieferung von Software.“

2. DevOps befähigt Entwickler

„DevOps gibt Entwicklern die Befugnis, Anwendungen zu besitzen, sie zu starten und die Lieferung von Anfang bis Ende zu verwalten.“

„Normalerweise wird DevOps als eine Methode beschrieben, um die Lieferung von Anwendungen in die Produktion durch den Aufbau und die Anwendung automatisierter Prozesse zu beschleunigen“, sagt Jai Schniepp, Direktor für DevOps-Plattformen bei der Versicherungsfirma Liberty Mutual. „Aber für mich ist es eine viel grundlegendere Sache. DevOps gibt Entwicklern die Befugnis, Anwendungen oder bestimmte Teile der Software zu besitzen, sie zu starten und die Lieferung von Anfang bis Ende zu verwalten. DevOps beseitigt die Verwirrung über Verantwortlichkeiten und führt alle Beteiligten dazu, eine automatisierte und von Entwicklern verwaltete Infrastruktur zu schaffen.“

3. DevOps ist Zusammenarbeit bei der Erstellung und Lieferung von Anwendungen.

„Einfach ausgedrückt, ist DevOps ein Ansatz zur Produktion und Lieferung von Software, bei dem alle zusammenarbeiten“, bemerkt Gur Staf, Präsident und Leiter der Digital Business Automation bei BMC.

4. DevOps ist eine Produktionslinie.

„Eine fließende Montage ist nur möglich, wenn alle Teile zueinander passen.“

„Ich würde DevOps mit einer Automobilmontagelinie vergleichen“, fährt Gur Staf fort. „Die Idee ist, alle Teile im Voraus so zu entwerfen und herzustellen, dass sie später ohne individuelle Anpassung zusammengebaut werden können. Eine fließende Montage ist nur möglich, wenn alle Teile zueinander passen. Diejenigen, die den Motor entwerfen und herstellen, müssen darüber nachdenken, wie er am Chassis oder Rahmen befestigt wird. Diejenigen, die die Bremsen herstellen, müssen an die Räder denken, und so weiter. Genauso sollte es auch mit Software sein.“

„Ein Entwickler, der die Geschäftslogik oder die Benutzeroberfläche erstellt, muss an die Datenbank denken, die die Informationen über die Kunden speichert, an Sicherheitsmaßnahmen zum Schutz der Benutzerdaten sowie daran, wie alles funktionieren wird, wenn der Dienst ein großes, möglicherweise sogar Millionen von Benutzern umfassendes Publikum bedient.“

„Es ist eine der größten Herausforderungen, die Zusammenarbeit der Menschen zu fördern und sie dazu zu bringen, über die Aspekte ihrer Arbeit nachzudenken, die von anderen erledigt werden, anstatt sich ausschließlich auf ihre eigenen Aufgaben zu konzentrieren. Wenn dies gelingt, eröffnen sich großartige Chancen für die digitale Transformation“, fügt Gur Staf hinzu.

5. DevOps ist die richtige Kombination aus Menschen, Prozessen und Automatisierung

Jayne Groll, Geschäftsführerin des DevOps Institute, brachte eine hervorragende Analogie zur Erklärung von DevOps: „DevOps ist wie ein Rezept, das drei Hauptkategorien von Zutaten umfasst: Menschen, Prozesse und Automatisierung. Viele dieser Zutaten können aus anderen Bereichen und Quellen stammen: Lean, Agile, SRE, CI/CD, ITIL, Führung, Kultur, Werkzeuge. Das Geheimnis von DevOps, wie bei jedem guten Rezept, liegt darin, wie man die richtigen Proportionen auswählt und diese Zutaten mischt, um die Geschwindigkeit und Effizienz bei der Erstellung und Bereitstellung von Anwendungen zu steigern.“

6. DevOps ist, wenn Programmierer wie ein Formel-1-Team arbeiten

„Das Rennen wird nicht vom Start zum Ziel geplant, sondern umgekehrt, vom Ziel zum Start.“

„Wenn ich darüber spreche, was von der DevOps-Initiative zu erwarten ist, ziehe ich ein Beispiel an einem NASCAR- oder Formel-1-Rennteam“, sagt Chris Short, Senior Marketing Manager für Cloud-Plattformen bei Red Hat und Herausgeber des Newsletters DevOps’ish. „Der Teamleiter hat ein Ziel: den bestmöglichen Platz im Rennen zu erreichen, basierend auf den verfügbaren Ressourcen und den Herausforderungen, die das Team bewältigen muss. Dabei wird das Rennen nicht vom Start zum Ziel, sondern umgekehrt, vom Ziel zum Start geplant. Zuerst wird ein ambitioniertes Ziel gesetzt, dann werden die Wege zu dessen Erreichung festgelegt, die dann in Teilaufgaben unterteilt und den Teammitgliedern delegiert werden.“

„Die gesamte Woche vor dem Rennen arbeitet das Team an den Boxenstopps. Sie machen Kraft- und Ausdauertraining, um am anstrengenden Renntag in Form zu sein. Sie üben das gemeinsame Handeln zur Lösung von Problemen, die während des Rennens auftreten können. In ähnlicher Weise muss das Entwicklerteam die Fähigkeiten zur häufigen Veröffentlichung neuer Versionen trainieren. Mit diesen Fähigkeiten und einem gut funktionierenden Sicherheitssystem erfolgt die Veröffentlichung neuer Versionen in der Produktion ebenfalls häufiger. In diesem Weltbild bedeutet ein Anstieg der Geschwindigkeit auch einen Anstieg der Sicherheit“, sagt Short.

„Es geht nicht darum, die ‚richtigen Dinge‘ zu tun“, fügt Short hinzu, „sondern darum, so viele Hindernisse wie möglich zu beseitigen, die dem gewünschten Ergebnis im Weg stehen. Arbeiten Sie zusammen und passen Sie sich aufgrund des Feedbacks an, das Sie in Echtzeit erhalten. Seien Sie auf Anomalien vorbereitet und arbeiten Sie daran, die Qualität zu steigern, um ihren Einfluss auf das Erreichen des Ziels zu minimieren. Genau das erwartet uns in der Welt von DevOps.“

Wie man DevOps skalieren kann: 10 Tipps von Experten

Einfaches DevOps und massives DevOps sind völlig verschiedene Dinge. Wir zeigen Ihnen, wie Sie die Hindernisse überwinden können, um vom ersten zum zweiten zu gelangen.

Für viele Organisationen beginnt der Weg zu DevOps einfach und angenehm. Es werden kleine, engagierte Teams gebildet, alte Prozesse durch neue ersetzt und die ersten Erfolge lassen nicht lange auf sich warten.

Leider ist dies nur ein trügerischer Glanz, eine Illusion des Fortschritts, wie Ben Grinnell, Geschäftsführer und Leiter der digitalen Technologien bei der Beratungsgesellschaft North Highland, sagt. Frühe Erfolge sind zwar ermutigend, helfen jedoch nicht, das endgültige Ziel zu erreichen, nämlich die umfassende Nutzung von DevOps in der Organisation.

Es ist leicht zu erkennen, dass dadurch eine Kultur des Teilens in ‚wir‘ und ‚sie‘ entsteht.

„Oft starten Organisationen solche Pilotprojekte in der Annahme, dass sie den Weg zu einem breiten DevOps-Ansatz ebnen, ohne darüber nachzudenken, ob auch andere bereit und in der Lage sind, diesen Weg zu gehen“, erklärt Ben Grinnell. „Die Teams, die für die Umsetzung solcher Projekte zusammengestellt werden, bestehen meist aus selbstbewussten „Wikingern“, die an anderen Orten Ähnliches getan haben, jedoch neu in Ihrer Organisation sind. Sie werden zudem ermutigt, Regeln zu brechen und zu verletzen, die für alle anderen weiterhin verbindlich bleiben. Es ist leicht zu erkennen, dass dadurch eine Kultur des 'Wir' und 'Die' entsteht, die den Wissensaustausch und die Weitergabe von Fähigkeiten behindert.“

„Und dieses kulturelle Problem ist nur einer der Gründe, warum es schwierig ist, DevOps zu skalieren. DevOps-Teams sehen sich einer zunehmend komplexen technischen Herausforderung gegenüber, die typisch für schnell wachsende Unternehmen ist, die stark auf IT-Technologien setzen“, sagt Steve Newman, Gründer und Vorsitzender von Scalyr.

„In der modernen Welt ändern sich Dienstleistungen sofort, sobald ein Bedarf entsteht. Ständig neue Funktionen zu implementieren und bereitzustellen, ist natürlich großartig, aber die Koordination dieses Prozesses und die Lösung auftretender Probleme sind eine echte Herausforderung“, fügt Steve Newman hinzu. „In sehr schnell wachsenden Organisationen kämpfen Ingenieure in cross-funktionalen Teams darum, die Möglichkeit zu bewahren, Änderungen zu verfolgen und die dadurch entstehenden Kaskadeneffekte auf Dependency-Ebene zu erkennen. Darüber hinaus sind Ingenieure alles andere als glücklich, wenn ihnen diese Möglichkeit genommen wird und es ihnen dadurch schwerer fällt, die Natur der auftretenden Probleme zu verstehen.“

Wie kann man also die oben beschriebenen Schwierigkeiten überwinden und zu einem breiten Einsatz von DevOps in großen Organisationen übergehen? Experten raten, Geduld zu haben, selbst wenn Ihr Endziel darin besteht, den Softwareentwicklungszyklus und die Geschäftsprozesse zu beschleunigen.

1. Denken Sie daran, dass kulturelle Veränderungen Zeit erfordern

Jayne Groll, Geschäftsführerin des DevOps Institute: Meiner Meinung nach sollte die Erweiterung von DevOps ebenso schrittweise und iterativ erfolgen wie die agile Entwicklung (und gleichermaßen die Kultur betreffen). In Agile und DevOps liegt der Fokus auf kleinen Teams. Mit der wachsenden Zahl und Integration solcher Teams stellen wir jedoch fest, dass immer mehr Menschen neue Arbeitsmethoden anwenden, was zu einem umfassenden kulturellen Wandel führt.

2. Nehmen Sie sich ausreichend Zeit für Planung und Auswahl der Plattform

Eran Kinsbruner, Chief Evangelist bei Perfecto: Um das Skalieren erfolgreich zu gestalten, müssen DevOps-Teams zunächst lernen, traditionelle Prozesse, Werkzeuge und Fähigkeiten zu kombinieren, und dann langsam jede Phase von DevOps entwickeln und stabilisieren. Alles beginnt mit einer sorgfältigen Planung der Benutzergeschichten und der Wertstromflüsse, gefolgt von der Softwareentwicklung und der Versionskontrolle unter Verwendung von trunk-based development oder anderen Ansätzen, die sich am besten für das Branching und Merging von Code eignen.

Als nächstes folgt die Integrations- und Testphase, in der bereits eine skalierbare Plattform für die Automatisierung erforderlich ist. Hier ist es für DevOps-Teams wichtig, die richtige Plattform auszuwählen, die ihrem Fähigkeitsniveau und den endgültigen Zielen des Projekts entspricht.

Die nächste Phase ist die Bereitstellung in der Produktionsumgebung, die vollständig automatisiert unter Verwendung von Orchestrierungs- und Container-Tools erfolgen sollte. Es ist wichtig, virtualisierte Umgebungen in allen Phasen von DevOps zu haben (Simulator für die Produktionsumgebung, Testumgebung und tatsächlich die Produktionsumgebung) und stets die aktuellsten Daten für Tests zu verwenden, um relevante Erkenntnisse zu gewinnen. Die Analytik sollte intelligent sein und in der Lage, große Datenmengen mit schnell und effizientem Feedback zu verarbeiten.

3. Nehmen Sie die Verantwortung ohne Schuldzuweisungen an

Gordon Haff, Evangelist bei RedHat: „Die Schaffung eines Systems und einer Atmosphäre, die Experimente ermöglichen und fördern, erlaubt es, sogenannte erfolgreiche Fehler in der agilen Softwareentwicklung umzusetzen. Das bedeutet nicht, dass niemand mehr für Fehler verantwortlich ist. Tatsächlich wird es einfacher, einen Verantwortlichen zu benennen, da „verantwortlich sein“ nicht mehr „der Schuldige eines Fehlers sein“ bedeutet. Das heißt, die Essenz von Verantwortung verändert sich qualitativ. Dabei werden vier Faktoren extrem wichtig: das Ausmaß des Fehlers, die Ansätze, die Produktionsprozesse und die Anreize.“ (Mehr zu diesen Faktoren kann in dem Artikel von Gordon Huff „DevOps lessons: 4 aspects of healthy experiments“ nachgelesen werden.)

4. Räumen Sie den Weg frei

Ben Grinnell, Managing Director und Leiter des Bereichs digitale Technologien der Unternehmensberatung North Highland: „Um Skalierung zu erreichen, empfehle ich, gemeinsam mit den Vorzeigeprojekten ein Programm zur ‚Wegfreimachung‘ zu starten. Ziel dieses Programms ist es, den Schmutz zu beseitigen, der von den Vorreitern im DevOps zurückgelassen wird, wie veraltete Regeln und ähnliches, damit der Weg nach vorne frei bleibt.“

„Geben Sie den Menschen organisatorische Unterstützung und setzen Sie Impulse durch Kommunikation, die weit über die Gruppe der Vorreiter hinausgeht, indem die Erfolge neuer Arbeitsmethoden umfassend gefeiert werden. Schulen Sie die Menschen, die in der nächsten Welle von DevOps-Projekten involviert sind und nervös sind, weil sie DevOps zum ersten Mal benutzen. Und denken Sie daran, dass diese Menschen sich stark von den Vorreitern unterscheiden.“

5. Machen Sie die Werkzeuge demokratischer

Steve Newman, Gründer und Vorsitzender von Scalyr: „Werkzeuge sollten den Menschen nicht vorenthalten werden und sie sollten relativ einfach zu erlernen sein für jeden, der bereit ist, Zeit dafür aufzuwenden. Wenn nur drei Personen, die als ‚zertifiziert‘ für den Umgang mit einem bestimmten Werkzeug eingestuft sind, die Möglichkeit haben, Logs anzufordern, werden Sie immer maximal drei Personen haben, die das entsprechende Problem lösen können, selbst wenn Sie eine sehr große Rechenumgebung haben. Mit anderen Worten, hier entsteht ein Engpass, der ernsthafte (geschäftliche) Folgen haben kann.“

6. Schaffen Sie optimale Bedingungen für die Teamarbeit

Tom Clark, Leiter des Bereichs Common Platform bei ITV: „Sie können alles tun, aber nicht alles auf einmal. Setzen Sie sich große Ziele, beginnen Sie klein und bewegen Sie sich durch schnelle Iterationen nach vorne. Mit der Zeit erarbeiten Sie sich den Ruf eines Teams, das erfolgreich ist, wodurch auch andere Ihre Methoden anwenden möchten. Streben Sie nicht danach, ein hochgradig effizientes Team aufzubauen. Stattdessen schaffen Sie den Menschen perfekte Arbeitsbedingungen, und die Effizienz wird von selbst kommen.“

7. Vergessen Sie das Conway-Gesetz und die Kanban-Boards nicht

Logan Daigle, Director of Software Delivery und DevOps-Strategie bei CollabNetVersionOne: „Es ist wichtig, die Konsequenzen des Conway-Gesetzes zu erkennen. In meiner freien Interpretation besagt dieses Gesetz, dass die Produkte, die wir schaffen, und die Prozesse, die wir dabei verwenden, einschließlich DevOps, genauso strukturiert sind wie unsere Organisation.“

„Wenn in einer Organisation die Fragmentierung hoch ist und beim Planen, Erstellen und Veröffentlichen von Software die Verantwortung oft wechselt, wird der Effekt der Skalierung null oder von kurzer Dauer sein. Wenn die Organisation jedoch funktionsübergreifende Teams um Produkte bildet, die marktorientiert finanziert werden, steigen die Chancen auf Erfolg erheblich.“

„Ein weiterer wichtiger Aspekt der Skalierung besteht darin, alle Arbeiten, die im Gange sind (WIP, work in progress), auf Kanban-Boards darzustellen. Wenn es in der Organisation einen Ort gibt, an dem die Menschen solche Dinge sehen können, fördert dies die Zusammenarbeit erheblich, was sich positiv auf die Skalierung auswirkt.“

8. Suchen Sie nach alten Narben

Manuel Pais, DevOps-Berater und Mitautor des Buches „Team Topologies“: „Es ist nicht optimal, DevOps-Praktiken über die eigentlichen Dev- und Ops-Teams hinauszuführen und zu versuchen, sie auf andere Funktionen anzuwenden. Das wird sicherlich einen gewissen Effekt haben (zum Beispiel durch die Automatisierung manueller Aufgaben), aber man kann viel mehr erreichen, wenn man mit dem Verständnis der Liefer- und Feedbackprozesse beginnt.“

„Wenn in der IT-Systemlandschaft eines Unternehmens alte Wunden vorhanden sind – Verfahren und Managementmechanismen, die aufgrund früherer Vorfälle implementiert wurden, aber an Relevanz verloren haben (wegen des Wechsels von Produkten, Technologien oder Prozessen) – dann sollten diese ohne Zweifel entfernt oder geglättet und nicht ineffiziente oder unnötige Prozesse automatisiert werden.“

9. Vermeiden Sie die Schaffung von DevOps-Varianten

Anthony Edwards, Produktionsleiter bei Eggplant: „DevOps ist ein sehr vager Begriff, weshalb jedes Team seine eigene Variante von DevOps entwickelt. Nichts ist schlimmer, als wenn innerhalb eines Unternehmens gleich 20 Varianten von DevOps entstehen, die nicht gut miteinander harmonieren. Es kann nicht sein, dass jedes der drei Entwicklerteams seine eigene, spezielle Schnittstelle zwischen Entwicklung und Produktmanagement hat. Auch dürfen die Produkte nicht ihre eigenen, einzigartigen Erwartungen in Bezug auf die Verarbeitung von Feedback beim Transfer in die Produktionsumgebungssimulation haben. Andernfalls wird es Ihnen nie gelingen, DevOps zu skalieren.“

10. Verkünden Sie den Wert von DevOps für das Geschäft

Steve Newman, Gründer und Vorsitzender von Scalyr: „Arbeiten Sie daran, den Wert von DevOps anzuerkennen. Lernen Sie, und scheuen Sie sich nicht, über den Nutzen dessen zu sprechen, was Sie tun. DevOps spart unglaublich viel Zeit und Geld (denken Sie nur daran: weniger Ausfallzeiten, kürzere Wiederherstellungszeiten), und die DevOps-Teams sollten unermüdlich die Bedeutung dieser Initiativen für den Geschäftserfolg hervorheben (und predigen). So können Sie den Kreis der Befürworter erweitern und den Einfluss von DevOps im Unternehmen stärken.“

BONUS

Auf Red Hat Forum Russland Am 13. September kommt unser eigener DevOps – ja, Red Hat, als Softwarehersteller, hat eigene DevOps-Teams und -Praktiken.

Unser Ingenieur Mark Birger, der an der Entwicklung von internen Automatisierungsdiensten für andere Gruppen in der gesamten Organisation arbeitet, wird in reinem Russisch seine eigene Geschichte erzählen – wie das DevOps-Team von Red Hat Anwendungen von virtualisierten Hat Virtualization-Umgebungen, die von Ansible verwaltet werden, in ein vollwertiges Containerformat auf der OpenShift-Plattform migriert hat.

Aber das ist noch nicht alles:

Nachdem Organisationen ihre Arbeitslasten in Container verlagert haben, könnten traditionelle Methoden zur Überwachung von Anwendungen nicht mehr funktionieren. In dem zweiten Bericht erläutern wir unsere Motivation für die Änderung der Protokollierungsmethoden und zeigen den weiteren Weg, der uns zu modernen Methoden der Protokollierung und Überwachung geführt hat.

Quelle: habr.com