Es ist schwierig, das Wesentliche zu erfassen, wenn es um DevOps geht? Wir haben für Sie anschauliche Analogien, prägnante Formulierungen und Expertenrat zusammengestellt, die selbst Nicht-Spezialisten helfen, zum Kern der Sache zu gelangen. Am Ende gibt es ein Bonus – die DevOps-Mitarbeiter von Red Hat.
Der Begriff DevOps entstand vor 10 Jahren und entwickelte sich vom Hashtag auf Twitter zu einer kraftvollen kulturellen Bewegung in der IT-Welt, einer echten Philosophie, die Entwickler ermutigt, schneller Ergebnisse zu erzielen, zu experimentieren und durch iteratives Arbeiten voranzukommen. DevOps ist untrennbar mit dem Konzept der digitalen Transformation verbunden. Doch wie es oft bei IT-Begriffen der Fall ist, hat DevOps in den letzten zehn Jahren viele Definitionen, Interpretationen und Missverständnisse angesammelt.
Deshalb hört man oft Fragen zu DevOps wie: Ist das dasselbe wie Agile? Oder ist es eine spezielle Methodik? Oder ist es einfach ein weiteres Synonym für "Zusammenarbeit"?
DevOps umfasst viele verschiedene Konzepte (wie kontinuierliche Lieferung, kontinuierliche Integration, Automatisierung usw.), daher kann es schwierig sein, das Wesentliche herauszufiltern, insbesondere wenn man für das Thema interessiert ist. Diese Fähigkeit ist jedoch äußerst nützlich, ganz gleich, ob Sie Ihre Ideen Ihrem Vorgesetzten vermitteln oder einfach jemandem aus Ihrer Familie oder Ihrem Bekanntenkreis von Ihrer Arbeit erzählen möchten. Lassen Sie uns also die terminologischen Feinheiten von DevOps beiseitelegen und uns auf das Gesamtbild konzentrieren.
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 Hintergrund verständlich wird. Aus diesen Gesprächen haben wir die prägnantesten Analogien und markanten Formulierungen ausgewählt, die Ihnen helfen werden, Ihre Erzählung über DevOps zu gestalten.
1. DevOps ist eine kulturelle Bewegung
„DevOps ist eine kulturelle Bewegung, in der beide Seiten (Softwareentwickler und IT-Systembetreiber) anerkennen, dass Software keinen echten Wert hat, solange sie nicht von jemandem genutzt wird: sei es von Kunden, Klienten oder Mitarbeitern“, sagt Eveline Oehrlich, Senior Research Analyst am DevOps Institute. „Deshalb gewährleisten beide Seiten gemeinsam eine schnelle und qualitativ hochwertige Softwarebereitstellung.“
2. DevOps ist das, was Entwicklern Macht verleiht
„DevOps gibt Entwicklern die Befugnis, Anwendungen zu besitzen, sie zu starten und die Lieferung von Anfang bis Ende zu verwalten.“
«Обычно о DevOps говорят, как о способе ускорить доставку приложений в продакшн за счет выстраивания и применения автоматизированных процессов, – говорит Джей Шнайп (Jai Schniepp), директор по платформам DevOps страховой компании Liberty Mutual. – Но для меня это гораздо более фундаментальная вещь. DevOps наделяет разработчиков полномочиями на владение приложениями или определенными частями ПО, на их запуск и управление доставкой от начала и до конца. DevOps устраняет неразбериху с ответственностью и ведет всех участников процесса к созданию автоматизированной и управляемой разработчиком инфраструктуры».
3. DevOps – это сотрудничество при создании и доставке приложений
«Проще говоря, DevOps – это такой подход к производству и доставке ПО, когда все работают вместе», – отмечает Гур Стаф, президент и руководитель направления автоматизации цифрового бизнеса компании BMC.
4. DevOps – это конвейер
«Конвейерная сборка возможна, только если все детали подходят друг к другу».
„Ich würde DevOps mit einem Fließband für die Automobilproduktion vergleichen“, fährt Gur Staff fort. „Die Idee ist, alles im Voraus zu planen und die einzelnen Teile so herzustellen, dass sie später ohne individuelle Anpassungen zusammengesetzt werden können. Fließbandproduktion ist nur möglich, wenn alle Teile zueinander passen. Diejenigen, die den Motor entwerfen und herstellen, müssen sich überlegen, wie er an die Karosserie oder den Rahmen befestigt wird. Die Hersteller der Bremsen müssen an die Räder denken, und so weiter. Genau so sollte es auch mit Software sein.
Ein Entwickler, der die Geschäftslogik oder die Benutzeroberfläche erstellt, muss an die Datenbank denken, die Informationen über die Kunden speichert, an die Sicherheitsmaßnahmen zum Schutz der Benutzerdaten und daran, wie all das funktionieren wird, wenn der Service eine große, möglicherweise sogar multimillionenfache Nutzerbasis bedient.
„Die größte Hürde, die es zu überwinden gilt, besteht darin, dass Menschen zusammenarbeiten und über die Teile ihrer Arbeit nachdenken, die von anderen erledigt werden, anstatt sich ausschließlich auf ihre eigenen Aufgaben zu konzentrieren. Wenn dies gelingt, haben Sie hervorragende Chancen auf digitale Transformation“, fügt Gur Staf hinzu.
5. DevOps ist die richtige Kombination aus Menschen, Prozessen und Automatisierung.
Jayne Groll, die Geschäftsführerin des DevOps Instituts, hat eine hervorragende Analogie zur Erklärung von DevOps vorgeschlagen. Ihrer Meinung nach ist „DevOps wie ein Kochrezept, bei dem es drei Hauptkategorien von Zutaten gibt: Menschen, Prozesse und Automatisierung. Die meisten dieser Zutaten können aus anderen Bereichen und Quellen kommen: Lean, Agile, SRE, CI/CD, ITIL, Führung, Kultur, Werkzeuge. Das Geheimnis von DevOps, genau wie bei jedem guten Rezept, besteht darin, die Zutaten in der richtigen Proportion zu kombinieren und zu mischen, 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 bis zur Ziellinie geplant, sondern umgekehrt, von der Ziellinie bis zum Start.“
„Wenn wir über das sprechen, was wir von der DevOps-Initiative erwarten können, vergleiche ich das mit einem NASCAR- oder Formel-1-Rennteam“, sagt Chris Short, Marketing Manager für Cloud-Plattformen bei Red Hat und Herausgeber des Newsletters DevOps’ish. „Ein Teamleiter hat ein einziges Ziel: So viele Punkte wie möglich zu sammeln, basierend auf den verfügbaren Ressourcen und den Herausforderungen, denen das Team gegenübersteht. Dabei wird das Rennen nicht vom Start zum Ziel, sondern umgekehrt geplant – vom Ziel zurück zum Start. Zuerst wird ein ehrgeiziges Ziel gesetzt, danach werden die Wege zu dessen Erreichung festgelegt. Diese werden dann in Aufgaben aufgeteilt und an die Teammitglieder delegiert.“
„Die ganze Woche vor dem Rennen verfeinert das Team den Boxenstopp. Es konzentriert sich auf Kraft- und Cardiotraining, um an einem anstrengenden Renntag in Form zu sein. Das Team übt die gemeinsame Reaktion auf Probleme, die während des Rennens auftreten können. Genauso sollte das Entwicklungsteam die Fähigkeiten für häufige Releases neuer Versionen trainieren. Mit solchen Fähigkeiten und einem stabilen Sicherheitssystem können neue Versionen auch häufiger in die Produktion gebracht werden. In diesem Sinne bedeutet steigende Geschwindigkeit auch steigende 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 in Echtzeit an das Feedback an, das Sie erhalten. Seien Sie bereit für Anomalien und arbeiten Sie an der Qualität, um deren Einfluss auf den Fortschritt in Richtung Ziel zu minimieren. Genau das erwartet uns in der Welt von DevOps.“
DevOps skalieren: 10 Tipps von Experten
Einfaches DevOps und massives DevOps sind zwei vollkommen unterschiedliche Ansätze. Wir erklären Ihnen, wie Sie die Hindernisse auf dem Weg vom ersten zum zweiten überwinden können.
Für viele Organisationen beginnt der Weg zu DevOps einfach und erfreulich. Es werden kleine, leidenschaftliche Teams gebildet, 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, wie Ben Grinnell, Geschäftsführer und Leiter für digitale Technologien der Unternehmensberatung North Highland, sagt. Frühzeitige Erfolge sind natürlich ermutigend, helfen jedoch nicht, das endgültige Ziel zu erreichen: die umfassende Einführung von DevOps in der Organisation.
Es ist leicht zu erkennen, dass sich dadurch eine Kultur der Trennung in 'wir' und 'sie' formiert.
„Häufig starten Organisationen solche Pionierprojekte in der Annahme, dass sie den Weg für eine breitere Anwendung von DevOps ebnen werden, ohne zu überlegen, ob andere bereit sind, diesen Weg zu gehen“, erklärt Ben Greenhalgh. „Die Teams, die für die Durchführung solcher Projekte zusammengestellt werden, bestehen oft aus selbstbewussten „Wikinger“, die Ähnliches an anderen Orten getan haben, aber neu in Ihrer Organisation sind. Ihnen wird geraten, Regeln zu brechen und zu ignorieren, die für alle anderen gelten. Es ist leicht zu erkennen, dass dadurch eine Kultur des 'Wir' gegen 'Sie' entsteht, die den Wissensaustausch und das Erlernen von Fähigkeiten behindert.“
„Dieses kulturelle Problem ist nur einer der Gründe, warum DevOps schwer skalierbar ist. DevOps-Teams sehen sich mit einer Zunahme rein technischer Komplexitäten konfrontiert, die für schnell wachsende Unternehmen typisch sind, die auf IT-Technologien setzen“, sagt Steve Newman, Gründer und Vorsitzender von Scalyr.
„In der heutigen Welt verändern sich Dienstleistungen sofort, sobald der Bedarf entsteht. Es ist natürlich großartig, ständig neue Funktionen zu realisieren und einzuführen, aber den Prozess zu koordinieren und auftretende Probleme zu lösen, ist eine echte Herausforderung“, fügt Steve Newman hinzu. „In sehr schnell wachsenden Organisationen kämpfen Ingenieure in funktionsübergreifenden Teams darum, die Möglichkeit zu behalten, Änderungen und die daraus resultierenden Kaskadeneffekte auf Abhängigkeitsebenen nachzuvollziehen. Darüber hinaus sind Ingenieure alles andere als erfreut, wenn sie von dieser Möglichkeit ausgeschlossen werden, was es ihnen erschwert, die Natur der auftretenden Probleme zu verstehen.“
Wie können diese beschriebenen Herausforderungen überwunden werden, um eine umfassende Nutzung von DevOps in großen Unternehmen zu realisieren? Experten raten dazu, Geduld zu haben, selbst wenn Ihr endgültiges Ziel darin besteht, den Softwareentwicklungszyklus und die Geschäftsprozesse zu beschleunigen.
1. Denken Sie daran, dass kulturelle Veränderungen Zeit brauchen
Jayne Groll, Geschäftsführerin des DevOps Institute: „Meiner Meinung nach sollte die Erweiterung von DevOps ebenso schrittweise und iterativ erfolgen wie agile Entwicklung (und in gleichem Maße die Kultur betreffen). In Agile und DevOps liegt der Fokus auf kleinen Teams. Doch mit dem Wachstum und der Integration solcher Teams kommen immer mehr Menschen hinzu, die neue Arbeitsmethoden anwenden, was zu einer großflächigen kulturellen Transformation führt.“
2. Planen Sie ausreichend Zeit für die Auswahl der Plattform ein
Eran Kinsbruner, Chief Evangelist bei Perfecto: „Damit die Skalierung funktioniert, müssen DevOps-Teams zunächst lernen, traditionelle Prozesse, Werkzeuge und Fähigkeiten zu kombinieren, und dann jede Phase von DevOps schrittweise entwickeln und stabilisieren. Alles beginnt mit einer sorgfältigen Planung der User Stories und der Wertstromereignisse, gefolgt von der Softwareentwicklung und Versionskontrolle unter Verwendung von trunk-basiertem Development oder anderen Ansätzen, die am besten für das Branching und Merge von Code geeignet sind.“
Anschließend folgt die Phase der Integration und des Testens, 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 ihren Fähigkeiten und den endgültigen Zielen des Projekts entspricht.
Die nächste Phase ist das Deployment in der Produktionsumgebung, das vollständig automatisiert mit Orchestrierungs- und Container-Tools erfolgen muss. Dabei ist es wichtig, virtualisierte Umgebungen in allen DevOps-Phasen zu haben (Simulationsumgebung, Qualitätssicherung und die eigentliche Produktionsumgebung) und immer nur die aktuellsten Daten für Tests zu verwenden, um relevante Erkenntnisse zu gewinnen. Analytik sollte intelligent sein und in der Lage, große Datenmengen schnell und effektiv zu verarbeiten.
3. Nehmen Sie die Verantwortung aus der Schuldfrage.
Gordon Haff, Evangelist bei RedHat: „Die Schaffung eines Systems und einer Atmosphäre, die Experimente zulassen und fördern, ermöglicht die Umsetzung sogenannter erfolgreicher Fehlschläge in der agilen Softwareentwicklung. Das bedeutet nicht, dass niemand mehr für Fehlschläge verantwortlich ist. Tatsächlich wird es sogar einfacher, Verantwortliche zu benennen, da „Verantwortung übernehmen“ nicht mehr bedeutet, „den Schuldigen zu finden“. Das Wesen der Verantwortung ändert sich also qualitativ. Dabei werden vier Faktoren extrem wichtig: der Umfang des Fehlschlags, die Ansätze, die Produktionsprozesse und die Anreize.“ (Mehr zu diesen Faktoren finden Sie im Artikel von Gordon Huff „DevOps lessons: 4 aspects of healthy experiments“.)
4. Räumen Sie den Weg frei
Ben Grinnell, Managing Director und Leiter des Bereichs digitale Technologien der Consultingfirma North Highland: „Um Skalierung zu erreichen, empfehle ich, zusammen mit den Pionierprojekten ein Programm zur „Wegfreimachung“ zu starten. Ziel dieses Programms ist es, den Schutt zu beseitigen, der von den DevOps-Pionieren zurückgelassen wird, wie zum Beispiel überholte Regeln und ähnliches, damit der Weg nach vorne frei bleibt.“
Bieten Sie den Menschen organisatorische Unterstützung und fördern Sie die Kommunikation, die über die Gruppe der Pioniere hinausgeht, und feiern Sie die Erfolge neuer Arbeitsmethoden. Schulen Sie die Personen, die an der nächsten Welle von DevOps-Projekten beteiligt sind und nervös sind, weil sie DevOps zum ersten Mal verwenden. Und denken Sie daran, dass sich diese Personen stark von den Pionieren unterscheiden.
5. Machen Sie Werkzeuge zugänglicher
Steve Newman, Gründer und Vorstandsvorsitzender von Scalyr: Werkzeuge sollten nicht vor den Menschen verborgen werden und sie sollten relativ einfach zu erlernen sein für jeden, der bereit ist, Zeit dafür zu investieren. Wenn die Möglichkeit, Protokolle anzufordern, nur drei Personen, die für den Umgang mit einem bestimmten Werkzeug 'zertifiziert' sind, zur Verfügung steht, haben Sie immer nur maximal drei Personen, die in der Lage sind, das entsprechende Problem zu lösen, selbst wenn Sie über eine sehr große IT-Umgebung verfügen. Mit anderen Worten, hier entsteht ein Engpass, der ernsthafte, geschäftliche Konsequenzen haben kann.
6. Schaffen Sie optimale Bedingungen für die Teamarbeit
Tom Clark, Leiter der Abteilung Common Platform bei ITV: „Sie können alles tun, aber nicht alles auf einmal. Setzen Sie sich ehrgeizige Ziele, beginnen Sie klein und arbeiten Sie sich durch schnelle Iterationen nach vorne. Im Laufe der Zeit werden Sie sich einen Ruf als Team erarbeiten, das erfolgreich ist, und andere werden Ihre Methoden ebenfalls anwenden wollen. Streben Sie dabei nicht direkt nach einem Hochleistungsteam. Sorgen Sie stattdessen dafür, dass die Menschen optimale Arbeitsbedingungen haben, und die Effizienz wird von selbst kommen.“
7. Vergessen Sie das Conway-Gesetz und Kanban-Boards nicht
Logan Daigle, Director of Software Delivery and DevOps Strategy bei CollabNetVersionOne: „Es ist wichtig, sich der Konsequenzen des Conway-Gesetzes bewusst zu sein. In meiner freien Übersetzung besagt dieses Gesetz, dass die Produkte, die wir erstellen, und die Prozesse, die wir dabei verwenden, einschließlich DevOps, genauso strukturiert sind wie unsere Organisation.“
Wenn in einer Organisation die Trennung groß ist und das Management während der Planung, Erstellung und Veröffentlichung von Software häufig wechselt, wird der Skalierungseffekt null oder nur von kurzer Dauer sein. Bildet die Organisation jedoch cross-funktionale Teams um Produkte, die marktgerecht finanziert werden, steigen die Erfolgschancen erheblich.
Ein weiterer wichtiger Aspekt der Skalierung besteht darin, alle Arbeiten in Bearbeitung (WIP, work in progress) auf Kanban-Boards darzustellen. Wenn es in der Organisation einen Raum gibt, in 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“: Die Ausweitung der DevOps-Praktiken über Dev und Ops hinaus und der Versuch, sie auf andere Funktionen anzuwenden, kann kaum als optimal betrachtet werden. Dies wird zweifellos einen gewissen Nutzen haben (zum Beispiel durch die Automatisierung manueller Aufgaben), jedoch können viel größere Fortschritte erzielt werden, wenn man mit dem Verständnis der Liefer- und Feedbackprozesse beginnt.
«Wenn in den IT-Systemen einer Organisation alte Narben vorhanden sind – Verfahren und Managementmechanismen, die nach früheren Vorfällen implementiert wurden, aber aufgrund von Änderungen in Produkten, Technologien oder Prozessen nicht mehr relevant sind –, dann sollten diese unbedingt entfernt oder geglättet werden, anstatt ineffektive oder unnötige Prozesse zu automatisieren.»
9. Schaffen Sie keine Varianten von DevOps
Antony Edwards, Produktionsleiter bei Eggplant: «DevOps ist ein sehr vager Begriff, weshalb jede Team seine eigene Interpretation davon hat. Es gibt nichts Schlimmeres, als wenn innerhalb einer Organisation gleich 20 Varianten von DevOps existieren, die nicht gut miteinander harmonieren. Es sollte nicht sein, dass jedes der drei Entwicklungsteams eine eigene, besondere Schnittstelle zwischen Entwicklung und Produktmanagement hat. Ebenso dürfen die Produkte keine einzigartigen Erwartungen an das Feedback-Handling beim Übergang in die Produktionsumgebung haben. Andernfalls wird es Ihnen nie gelingen, DevOps zu skalieren.»
10. Predigen Sie den Geschäftswert von DevOps
Steve Newman, Gründer und Vorstandsvorsitzender von Scalyr: „Arbeiten Sie daran, den Wert von DevOps anzuerkennen. Lernen Sie und zögern Sie nicht, die Vorteile dessen zu kommunizieren, was Sie tun. DevOps spart unglaublich viel Zeit und Geld (denken Sie nur: weniger Ausfallzeiten, kürzere Wiederherstellungszeiten). DevOps-Teams sollten unermüdlich die Bedeutung dieser Initiativen für den Geschäftserfolg betonen und propagieren. So können Sie die Anzahl der Befürworter erweitern und den Einfluss von DevOps in Ihrer Organisation verstärken.“
BONUS
Auf Am 13. September kommt unser eigener DevOps – ja, Red Hat hat als Softwarehersteller eigene DevOps-Teams und Praktiken.
Unser Ingenieur Mark Birger, der sich mit der Entwicklung interner Automatisierungsdienste für andere Gruppen in der gesamten Organisation beschäftigt, wird in einwandfreiem Russisch seine eigene Geschichte erzählen – wie das DevOps-Team von Red Hat Anwendungen von virtuellen Umgebungen von Hat Virtualization, die von Ansible verwaltet werden, in ein vollwertiges Container-Format auf der OpenShift-Plattform migriert hat.
Aber das ist noch nicht alles:
Nachdem Organisationen ihre Arbeitslasten in Container migriert haben, funktionieren traditionelle Ansätze für das Monitoring von Anwendungen möglicherweise nicht mehr. In unserem zweiten Bericht erläutern wir unsere Motivation zur Veränderung der Protokollierungsmethoden und zeigen den fortlaufenden Weg, der uns zu modernen Methoden der Protokollierung und Überwachung geführt hat.
Quelle: habr.com
