Ist es schwierig, den Kernpunkt zu verstehen, wenn man über DevOps spricht? Wir haben für Sie anschauliche Analogien, plakative Formulierungen und Ratschläge von Experten zusammengestellt, die auch Nichtfachleuten helfen, auf den Punkt zu kommen. Der Bonus sind am Ende die eigenen DevOps der Red Hat-Mitarbeiter.
Der Begriff DevOps entstand vor 10 Jahren und hat sich von einem Twitter-Hashtag zu einer starken kulturellen Bewegung in der IT-Welt entwickelt, einer wahren Philosophie, die Entwickler dazu ermutigt, Dinge schneller zu erledigen, zu experimentieren und voranzuschreiten. DevOps ist untrennbar mit dem Konzept der digitalen Transformation verbunden. Aber wie so oft in der IT-Terminologie hat sich DevOps in den letzten zehn Jahren viele Definitionen, Interpretationen und Missverständnisse über sich selbst angeeignet.
Daher hört man oft Fragen zu DevOps wie: Ist es dasselbe wie agil? Oder ist das eine spezielle Methodik? Oder ist es nur ein weiteres Synonym für das Wort „Zusammenarbeit“?
DevOps umfasst viele verschiedene Konzepte (kontinuierliche Bereitstellung, kontinuierliche Integration, Automatisierung usw.). Daher kann es schwierig sein, das Wesentliche herauszufiltern, insbesondere wenn Sie sich für das Thema begeistern. Diese Fähigkeit ist jedoch sehr nützlich, egal ob Sie versuchen, Ihre Ideen Ihren Vorgesetzten zu vermitteln oder einfach jemandem aus Ihrer Familie oder Ihren Freunden von Ihrer Arbeit zu erzählen. Lassen wir also die terminologischen Nuancen von DevOps zunächst 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 der Wert für Leser mit jedem technischen Wissensniveau klar wird. Basierend auf den Ergebnissen dieser Gespräche haben wir die auffälligsten Analogien und eindrucksvollsten Formulierungen ausgewählt, die Ihnen beim Aufbau Ihrer Geschichte über DevOps helfen werden.
1. DevOps ist eine kulturelle Bewegung
„DevOps ist eine kulturelle Bewegung, in der beide Parteien (Softwareentwickler und IT-Systembetriebsspezialisten) erkennen, dass Software keinen wirklichen Nutzen bringt, bis jemand anfängt, sie zu nutzen: Kunden, Klienten, Mitarbeiter, nicht der Sinn“, sagt Eveline Oehrlich, Senior Research Analyst am DevOps Institute. „Damit stellen beide Parteien gemeinsam eine schnelle und qualitativ hochwertige Lieferung der Software sicher.“
2. Bei DevOps geht es darum, Entwickler zu stärken.
„DevOps ermöglicht es Entwicklern, Anwendungen zu besitzen, auszuführen und die Bereitstellung von Anfang bis Ende zu verwalten.“
„Üblicherweise wird von DevOps als eine Möglichkeit gesprochen, die Bereitstellung von Anwendungen für die Produktion durch den Aufbau und die Implementierung automatisierter Prozesse zu beschleunigen“, sagt Jai Schniepp, Direktor für DevOps-Plattformen bei der Versicherungsgesellschaft Liberty Mutual. „Aber für mich ist es eine viel grundlegendere Sache.“ DevOps ermöglicht es Entwicklern, Anwendungen oder bestimmte Softwareteile zu besitzen, sie auszuführen und ihre Bereitstellung von Anfang bis Ende zu verwalten. DevOps beseitigt Verantwortungsverwirrungen und leitet alle Beteiligten bei der Erstellung einer automatisierten, entwicklergesteuerten Infrastruktur.“
3. Bei DevOps geht es um die Zusammenarbeit bei der Erstellung und Bereitstellung von Anwendungen.
„Einfach ausgedrückt ist DevOps ein Ansatz zur Softwareproduktion und -bereitstellung, bei dem alle zusammenarbeiten“, sagt Gur Staf, Präsident und Leiter der digitalen Geschäftsautomatisierung bei BMC.
4. DevOps ist eine Pipeline
„Eine Förderbandmontage ist nur möglich, wenn alle Teile zusammenpassen.“
„Ich würde DevOps mit einem Automontageband vergleichen“, fährt Gur Staff fort. – Die Idee ist, alle Teile im Voraus zu entwerfen und herzustellen, damit sie dann ohne individuelle Anpassung zusammengebaut werden können. Der Zusammenbau des Förderers ist nur möglich, wenn alle Teile zusammenpassen. Wer einen Motor entwirft und baut, muss überlegen, wie er an der Karosserie oder am Rahmen befestigt wird. Wer die Bremsen herstellt, muss an die Räder usw. denken. Dasselbe sollte auch für Software gelten.
Ein Entwickler, der Geschäftslogik oder eine Benutzeroberfläche erstellt, muss über die Datenbank nachdenken, in der Kundeninformationen gespeichert werden, über die Sicherheitsmaßnahmen zum Schutz von Benutzerdaten und darüber, wie all dies funktionieren wird, wenn der Dienst beginnt, ein großes Benutzerpublikum, vielleicht sogar mehrere Millionen Dollar, zu bedienen ."
„Menschen dazu zu bringen, zusammenzuarbeiten und über die Teile der Arbeit nachzudenken, die andere erledigen, anstatt sich nur auf ihre eigenen Aufgaben zu konzentrieren, ist das größte Hindernis, das es zu überwinden gilt.“ Wenn Ihnen das gelingt, haben Sie hervorragende Chancen auf eine digitale Transformation“, fügt Gur Staff hinzu.
5. DevOps ist die richtige Kombination aus Menschen, Prozessen und Automatisierung
Jayne Groll, Geschäftsführerin des DevOps Institute, bot eine tolle Analogie zur Erklärung von DevOps. In ihren Worten: „DevOps ist wie ein Rezept mit drei Hauptkategorien von Zutaten: Menschen, Prozess und Automatisierung. Die meisten dieser Zutaten können aus anderen Bereichen und Quellen übernommen werden: Lean, Agile, SRE, CI/CD, ITIL, Führung, Kultur, Tools. Das Geheimnis von DevOps besteht, wie bei jedem guten Rezept, darin, die richtigen Proportionen und die richtige Mischung dieser Zutaten zu finden, um die Geschwindigkeit und Effizienz der Erstellung und Veröffentlichung von Anwendungen zu erhöhen.“
6. DevOps bedeutet, dass Programmierer wie ein Formel-1-Team arbeiten
„Das Rennen ist nicht von Anfang bis Ende durchgeplant, sondern im Gegenteil vom Ziel bis zum Start.“
„Wenn ich darüber spreche, was ich von einer DevOps-Initiative erwarten kann, denke ich als Beispiel an ein NASCAR- oder Formel-1-Rennteam“, sagt Chris Short, Senior Manager für Cloud-Plattform-Marketing bei Red Hat und Herausgeber des DevOps'ish-Newsletters. – Der Anführer eines solchen Teams hat ein Ziel: am Ende des Rennens den höchstmöglichen Platz einzunehmen, unter Berücksichtigung der dem Team zur Verfügung stehenden Ressourcen und der Herausforderungen, denen es ausgesetzt war. In diesem Fall wird das Rennen nicht vom Start bis zum Ziel geplant, sondern im Gegenteil vom Ziel bis zum Start. Zunächst wird ein ehrgeiziges Ziel festgelegt und anschließend Wege zur Erreichung festgelegt. Anschließend werden sie in Teilaufgaben zerlegt und an Teammitglieder delegiert.“
„Das Team verbringt die ganze Woche vor dem Rennen damit, den Boxenstopp zu perfektionieren. Er trainiert Kraft und Cardio, um für einen anstrengenden Renntag in Form zu bleiben. Übungen, die zusammenarbeiten, um eventuelle Probleme während des Rennens zu lösen. Ebenso sollte das Entwicklungsteam die Fähigkeit trainieren, regelmäßig neue Versionen zu veröffentlichen. Wenn Sie über solche Fähigkeiten und ein gut funktionierendes Sicherheitssystem verfügen, kommt es auch häufiger zur Einführung neuer Versionen in die Produktion. In dieser Weltanschauung bedeutet erhöhte Geschwindigkeit mehr Sicherheit“, sagt Short.
„Es geht nicht darum, das ‚Richtige‘ zu tun“, fügt Short hinzu, „es geht darum, so viele Dinge wie möglich zu beseitigen, die dem gewünschten Ergebnis im Wege stehen.“ Arbeiten Sie zusammen und passen Sie sich auf der Grundlage des Feedbacks an, das Sie in Echtzeit erhalten. Seien Sie auf Anomalien vorbereitet und arbeiten Sie an der Verbesserung der Qualität, um deren Auswirkungen auf den Fortschritt bei der Erreichung Ihres Ziels zu minimieren. Das ist es, was uns in der Welt von DevOps erwartet.“
So skalieren Sie DevOps: 10 Tipps von Experten
Es ist nur so, dass DevOps und Massen-DevOps völlig verschiedene Dinge sind. Wir verraten Ihnen, wie Sie Hürden auf dem Weg vom ersten zum zweiten überwinden.
Für viele Unternehmen beginnt der Weg zu DevOps einfach und angenehm. Es entstehen kleine leidenschaftliche Teams, alte Prozesse werden durch neue ersetzt und die ersten Erfolge lassen nicht lange auf sich warten.
Leider ist dies nur ein falscher Glanz, eine Illusion des Fortschritts, sagt Ben Grinnell, Geschäftsführer und Leiter Digital beim Beratungsunternehmen North Highland. Erste Erfolge sind sicherlich ermutigend, aber sie tragen nicht dazu bei, das ultimative Ziel einer weit verbreiteten Einführung von DevOps im gesamten Unternehmen zu erreichen.
Es ist leicht zu erkennen, dass das Ergebnis eine Kultur der Trennung zwischen „uns“ und „denen“ ist.
„Oft starten Unternehmen diese bahnbrechenden Projekte in dem Glauben, sie würden den Weg für Mainstream-DevOps ebnen, ohne darüber nachzudenken, ob andere in der Lage oder willens sind, diesen Weg zu gehen“, erklärt Ben Grinnell. – Teams zur Umsetzung solcher Projekte werden in der Regel aus selbstbewussten „Warägern“ rekrutiert, die an anderen Orten bereits etwas Ähnliches gemacht haben, aber neu in Ihrer Organisation sind. Gleichzeitig werden sie dazu ermutigt, die für alle anderen verbindlichen Regeln zu brechen und zu zerstören. Es ist leicht zu erkennen, dass das Ergebnis eine Kultur von „wir“ und „denen“ ist, die den Transfer von Wissen und Fähigkeiten behindert.“
„Und dieses kulturelle Problem ist nur einer der Gründe dafür, dass DevOps schwer zu skalieren ist. DevOps-Teams stehen vor zunehmenden technischen Herausforderungen, die typisch für schnell wachsende, IT-orientierte Unternehmen sind“, sagte Steve Newman, Gründer und Vorsitzender von Scalyr.
„In der modernen Welt ändern sich Dienstleistungen, sobald der Bedarf entsteht. „Es ist großartig, ständig neue Funktionen zu implementieren und zu implementieren, aber diesen Prozess zu koordinieren und auftretende Probleme zu beseitigen, bereitet echte Kopfschmerzen“, fügt Steve Newman hinzu. – In sehr schnell wachsenden Organisationen haben Ingenieure in funktionsübergreifenden Teams Schwierigkeiten, den Überblick über Veränderungen und die dadurch entstehenden Kaskadeneffekte auf Abhängigkeitsebene zu behalten. Darüber hinaus sind Ingenieure nicht glücklich, wenn ihnen diese Möglichkeit vorenthalten wird, und dadurch wird es für sie schwieriger, den Kern der auftretenden Probleme zu verstehen.“
Wie kann man diese oben beschriebenen Herausforderungen meistern und zur Masseneinführung von DevOps in einer großen Organisation übergehen? Experten raten zu Geduld, auch wenn Ihr oberstes Ziel darin besteht, Ihren Softwareentwicklungszyklus und Ihre Geschäftsprozesse zu beschleunigen.
1. Denken Sie daran, dass ein Kulturwandel Zeit braucht.
Jayne Groll, Geschäftsführerin, DevOps Institute: „Meiner Meinung nach sollte der Ausbau von DevOps genauso inkrementell und iterativ erfolgen wie die agile Entwicklung (und die Kultur gleichermaßen berühren). Agile und DevOps legen Wert auf kleine Teams. Doch je größer die Zahl und Integration dieser Teams wird, desto mehr Menschen übernehmen neue Arbeitsweisen, und in der Folge kommt es zu einem massiven kulturellen Wandel.“
2. Nehmen Sie sich ausreichend Zeit für die Planung und Auswahl einer Plattform
Eran Kinsbruner, Lead Technical Evangelist bei Perfecto: „Damit die Skalierung funktioniert, müssen DevOps-Teams zunächst lernen, traditionelle Prozesse, Tools und Fähigkeiten zu kombinieren und dann jede einzelne Phase von DevOps langsam zu fördern und zu stabilisieren. Alles beginnt mit der sorgfältigen Planung von User Stories und Wertströmen, gefolgt vom Schreiben von Software und der Versionskontrolle mithilfe von Trunk-basierter Entwicklung oder anderen Ansätzen, die sich am besten zum Verzweigen und Zusammenführen von Code eignen.“
„Dann kommt 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 Kenntnisstand und den Endzielen des Projekts entspricht.
Die nächste Phase ist die Bereitstellung in der Produktion. Diese sollte mithilfe von Orchestrierungstools und Containern vollständig automatisiert werden. Es ist wichtig, in allen Phasen von DevOps (Produktionssimulator, QA-Umgebung und tatsächliche Produktionsumgebung) über virtualisierte Umgebungen zu verfügen und für Tests immer nur die neuesten Daten zu verwenden, um relevante Schlussfolgerungen zu ziehen. Analytics muss intelligent und in der Lage sein, große Datenmengen mit schnellem und umsetzbarem Feedback zu verarbeiten.“
3. Nehmen Sie die Schuld aus der Verantwortung.
Gordon Haff, RedHat-Evangelist: „Die Schaffung eines Systems und einer Atmosphäre, die Experimente ermöglicht und fördert, ermöglicht sogenannte erfolgreiche Misserfolge in der agilen Softwareentwicklung. Das bedeutet nicht, dass niemand anderes für Ausfälle verantwortlich ist. Tatsächlich wird es sogar noch einfacher herauszufinden, wer dafür verantwortlich ist, da „verantwortlich sein“ nicht mehr bedeutet, „einen Unfall zu verursachen“. Das heißt, das Wesen der Verantwortung verändert sich qualitativ. Vier Faktoren werden entscheidend: das Ausmaß der Störung, Vorgehensweisen, Produktionsprozesse und Anreize.“ (Weitere Informationen zu diesen Faktoren finden Sie in Gordon Huffs Artikel „DevOps-Lektionen: 4 Aspekte gesunder Experimente“.)
4. Machen Sie den Weg frei
Ben Grinnell, Geschäftsführer und Leiter Digital beim Beratungsunternehmen North Highland: „Um eine Größenordnung zu erreichen, empfehle ich, gemeinsam mit Pionierprojekten ein „Path Clearing“-Programm zu starten. Ziel dieses Programms ist es, den Müll zu beseitigen, den DevOps-Pioniere hinterlassen, wie veraltete Regeln und ähnliches, damit der Weg nach vorne klar bleibt.“
„Geben Sie den Menschen organisatorische Unterstützung und Impulse durch eine Kommunikation, die weit über die Pioniergruppe hinausgeht, indem Sie die Erfolge neuer Arbeitsweisen weithin feiern.“ Coachen Sie Menschen, die an der nächsten Welle von DevOps-Projekten beteiligt sind und Angst davor haben, DevOps zum ersten Mal einzusetzen. Und denken Sie daran, dass diese Menschen ganz anders sind als die Pioniere.“
5. Demokratisieren Sie Tools
Steve Newman, Gründer und Vorsitzender von Scalyr: „Werkzeuge sollten den Menschen nicht verborgen bleiben und für jeden, der bereit ist, Zeit zu investieren, relativ einfach zu erlernen sein. Wenn die Fähigkeit zum Abfragen von Protokollen auf drei Personen beschränkt ist, die für die Verwendung eines Tools „zertifiziert“ sind, stehen Ihnen immer maximal drei Personen zur Verfügung, um das Problem zu lösen, selbst wenn Sie über eine sehr große Computerumgebung verfügen. Mit anderen Worten: Hier liegt ein Engpass vor, der schwerwiegende (geschäftliche) Folgen haben kann.“
6. Schaffen Sie ideale Bedingungen für Teamarbeit
Tom Clark, Leiter der Common Platform bei ITV: „Man kann alles tun, aber nicht alles auf einmal. Setzen Sie sich also große Ziele, fangen Sie klein an und gehen Sie in schnellen Iterationen voran. Mit der Zeit entwickeln Sie den Ruf, Dinge gut zu erledigen, sodass auch andere Ihre Methoden nutzen möchten. Und machen Sie sich keine Sorgen über den Aufbau eines hocheffektiven Teams. Bieten Sie den Menschen stattdessen ideale Arbeitsbedingungen, dann wird die Effizienz folgen.“
7. Vergessen Sie nicht Conways Gesetz und Kanban-Boards
Logan Daigle, Direktor für Softwarebereitstellung und DevOps-Strategie bei CollabNetVersionOne: „Es ist wichtig, die Konsequenzen von Conways Gesetz zu verstehen. In meiner lockeren Umschreibung besagt dieses Gesetz, dass die Produkte, die wir erstellen, und die Prozesse, die wir dafür verwenden, einschließlich DevOps, genauso strukturiert sind wie unsere Organisation.“
„Wenn es in einer Organisation viele Silos gibt und die Kontrolle bei der Planung, Erstellung und Veröffentlichung von Software häufig wechselt, ist der Effekt der Skalierung gleich null oder nur von kurzer Dauer. Wenn eine Organisation funktionsübergreifende Teams rund um Produkte aufbaut, die marktorientiert finanziert werden, steigen die Erfolgschancen dramatisch.“
„Ein weiterer wichtiger Aspekt der Skalierung ist die Darstellung aller laufenden Arbeiten (WIP, Workinprogress) auf Kanban-Boards. Wenn eine Organisation einen Ort hat, an dem die Leute diese Dinge sehen können, fördert das die Zusammenarbeit enorm, was sich positiv auf die Skalierung auswirkt.“
8. Suchen Sie nach alten Narben
Manuel Pais, DevOps-Berater und Co-Autor von Team Topologies: „DevOps-Praktiken über Dev und Ops selbst hinaus zu übernehmen und zu versuchen, sie auf andere Funktionen anzuwenden, ist kaum ein optimaler Ansatz. Dies wird sicherlich einige Auswirkungen haben (z. B. durch die Automatisierung der manuellen Steuerung), aber es kann noch viel mehr erreicht werden, wenn wir damit beginnen, die Liefer- und Feedbackprozesse zu verstehen.“
„Wenn es im IT-System einer Organisation alte Narben gibt – Verfahren und Managementmechanismen, die als Ergebnis vergangener Vorfälle implementiert wurden, aber ihre Relevanz verloren haben (aufgrund von Änderungen bei Produkten, Technologien oder Prozessen) – dann müssen sie unbedingt entfernt werden.“ oder geglättet, anstatt ineffiziente oder unnötige Prozesse zu automatisieren.“
9. Verbreiten Sie keine DevOps-Optionen
Anthony Edwards, Betriebsleiter bei Eggplant: „DevOps ist ein sehr vager Begriff, daher hat jedes Team am Ende seine eigene Version von DevOps. Und es gibt nichts Schlimmeres, wenn eine Organisation plötzlich über 20 verschiedene DevOps-Varianten verfügt, die nicht mehr so gut miteinander harmonieren. Es ist unmöglich, dass jedes der drei Entwicklungsteams über eine eigene, spezielle Schnittstelle zwischen Entwicklung und Produktmanagement verfügt. Auch sollten Produkte keine eigenen Erwartungen an den Umgang mit Feedback haben, wenn sie in einen Produktionssimulator übertragen werden. Andernfalls werden Sie DevOps nie skalieren können.“
10. Predigen Sie den Geschäftswert von DevOps
Steve Newman, Gründer und Vorsitzender von Scalyr: „Arbeiten Sie daran, den Wert von DevOps zu erkennen. Lernen Sie und sprechen Sie gerne über die Vorteile Ihrer Arbeit. DevOps ist eine unglaubliche Zeit- und Geldersparnis (denken Sie nur an: weniger Ausfallzeiten, kürzere mittlere Zeit bis zur Wiederherstellung), und DevOps-Teams müssen unermüdlich die Bedeutung dieser Initiativen für den Geschäftserfolg betonen (und predigen). Auf diese Weise können Sie den Kreis der Anhänger erweitern und den Einfluss von DevOps in der Organisation erhöhen.“
BONUS
Auf Unser eigenes DevOps wird am 13. September eintreffen – ja, Red Hat hat als Softwarehersteller seine eigenen DevOps-Teams und -Praktiken.
Unser Ingenieur Mark Birger, der interne Automatisierungsdienste für andere Gruppen im gesamten Unternehmen entwickelt, wird seine eigene Geschichte in reinem Russisch erzählen – wie das Red Hat DevOps-Team Anwendungen aus den von Ansible verwalteten virtuellen Hat Virtualization-Umgebungen in ein vollwertiges Containerformat migrierte die OpenShift-Plattform.
Aber das ist noch nicht alles:
Sobald Unternehmen Workloads in Container verschoben haben, funktionieren herkömmliche Methoden zur Anwendungsüberwachung möglicherweise nicht mehr. Im zweiten Vortrag erläutern wir unsere Motivation für die Änderung der Art und Weise, wie wir protokollieren, und zeigen die Fortsetzung des Weges auf, der uns zu modernen Protokollierungs- und Überwachungsmethoden geführt hat.
Source: habr.com