Ist es schwierig, über DevOps zu sprechen? Wir haben für Sie lebendige Analogien, Percussion-Formulierungen und kompetente Ratschläge zusammengestellt, die auch Nicht-Spezialisten helfen, auf den Punkt zu kommen. Am Ende ist der Bonus Red Hats eigene DevOps.
Der Begriff DevOps entstand vor 10 Jahren und entwickelte sich von einem Hashtag auf Twitter zu einer mächtigen kulturellen Bewegung in der IT-Welt. Diese wahre Philosophie ermutigt Entwickler, mit der Iterationsmethode schneller Ergebnisse zu erzielen, zu experimentieren und voranzukommen. DevOps ist untrennbar mit dem Konzept der digitalen Transformation verbunden. Aber wie so oft bei der IT-Terminologie ist es DevOps über ein Jahrzehnt gelungen, viele Definitionen, Interpretationen und Missverständnisse zu gewinnen.
Daher kann man über DevOps oft Fragen hören wie: Ist es dasselbe wie agil? Oder ist es eine spezielle Methodik? Oder ist es nur ein weiteres Synonym für das Wort „Zusammenarbeit“?
DevOps enthält viele verschiedene Konzepte (kontinuierliche Bereitstellung, kontinuierliche Integration, Automatisierung usw.), sodass es schwierig sein kann, die Hauptsache zu isolieren, insbesondere wenn Sie sich für das Thema interessieren. Diese Fähigkeit ist jedoch sehr nützlich. Es spielt keine Rolle, ob Sie versuchen, Ihre Ideen Ihren Vorgesetzten zu vermitteln oder nur Ihren Verwandten oder Freunden von Ihrer Arbeit zu erzählen. Legen Sie daher vorerst die terminologischen Nuancen von DevOps beiseite und konzentrieren Sie sich 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 erläutern, damit der Leser bei jeder technischen Ausbildung seinen Wert erkennen kann. Basierend auf den Ergebnissen dieser Gespräche haben wir die auffälligsten Analogien und Percussion-Formulierungen ausgewählt, mit denen Sie Ihre Geschichte über DevOps erstellen können.
1. DevOps ist eine kulturelle Bewegung
„DevOps ist eine kulturelle Bewegung, in der beide Parteien (Softwareentwickler und Spezialisten für den Betrieb von IT-Systemen) erkennen, dass Software erst dann echte Vorteile bringt, wenn jemand sie nutzt: Kunden, Kunden, Mitarbeiter, Nicht der Punkt, sagt Eveline Oehrlich, Senior Analyst am DevOps Institute. "Daher bieten beide Parteien zusammen eine schnelle und qualitativ hochwertige Softwarebereitstellung."
2. DevOps befähigt Entwickler
"DevOps ermöglicht Entwicklern das Eigentum an Anwendungen, deren Start- und Bereitstellungsmanagement von Anfang bis Ende.""Normalerweise wird über DevOps gesprochen, um die Bereitstellung von Anwendungen für die Produktion zu beschleunigen, indem automatisierte Prozesse erstellt und angewendet werden", sagte Jai Schniepp, Direktor von DevOps Platforms, Liberty Mutual Insurance Company. "Aber für mich ist es eine viel grundlegendere Sache." DevOps gibt Entwicklern die Berechtigung, Anwendungen oder bestimmte Teile der Software zu besitzen, zu starten und die Bereitstellung von Anfang bis Ende zu verwalten. DevOps beseitigt die Verwirrung der Verantwortung und führt alle Teilnehmer des Prozesses dazu, eine automatisierte und von Entwicklern gesteuerte Infrastruktur zu schaffen. “
3. DevOps ist eine Zusammenarbeit bei der Erstellung und Bereitstellung von Anwendungen
"Einfach ausgedrückt ist DevOps ein solcher Ansatz für die Produktion und Bereitstellung von Software, wenn alle zusammenarbeiten", sagte Gur Staf, Präsident und Leiter der digitalen Geschäftsautomatisierung bei BMC.
4. DevOps ist eine Pipeline
„Die Förderermontage ist nur möglich, wenn alle Teile zusammenpassen.“„Ich würde DevOps mit einer Auto-Montagelinie vergleichen“, fährt Gur Staf fort. - Die Idee ist, alle Details vorab zu entwerfen und herzustellen, damit sie später ohne individuelle Passform zusammengebaut werden können. Die Montage des Förderers ist nur möglich, wenn alle Teile zusammenpassen. Diejenigen, die den Motor konstruieren und herstellen, sollten überlegen, wie er an der Karosserie oder am Rahmen montiert werden soll. Wer bremst, sollte an Räder denken und so weiter. Bei Software sollte es genauso sein.
Ein Entwickler, der eine Geschäftslogik oder Benutzeroberfläche erstellt, sollte über eine Datenbank nachdenken, in der Informationen über Kunden gespeichert sind, über Sicherheitsmaßnahmen zum Schutz von Benutzerdaten und darüber, wie diese funktionieren, wenn der Dienst eine große, möglicherweise sogar mehrere Millionen Menschen bedient Benutzerpublikum. "
„Menschen dazu zu bringen, zusammenzuarbeiten und über die Teile der Arbeit nachzudenken, die von anderen ausgeführt werden, und sich nicht nur auf ihre eigenen Aufgaben zu konzentrieren - dies ist das größte Hindernis, das überwunden werden muss. Wenn es gelingt, haben Sie hervorragende Chancen für die digitale Transformation “, fügt Gur Staf hinzu.
5. DevOps ist die richtige Kombination aus Menschen, Prozessen und Automatisierung
Jayne Groll, Executive Director des DevOps Institute, bot eine großartige Analogie zur Erklärung von DevOps. Ihr zufolge ist „DevOps wie ein kulinarisches Rezept, bei dem es drei Hauptkategorien von Zutaten gibt: Menschen, Prozesse und Automatisierung. Die meisten dieser Zutaten können aus anderen Bereichen und Quellen stammen: Lean, Agile, SRE, CI / CD, ITIL, Führung, Kultur, Tools. Das Geheimnis von DevOps sowie jedes gute Rezept besteht darin, die richtigen Proportionen auszuwählen und diese Zutaten zu mischen, um die Geschwindigkeit und Effektivität der Arbeit beim Erstellen und Freigeben von Anwendungen zu erhöhen. “
6. DevOps - Hier arbeiten Programmierer als Formel-1-Team
"Das Rennen ist nicht von Anfang bis Ende geplant, sondern von Ende bis Start.""Wenn ich darüber spreche, was Sie von der DevOps-Initiative erwarten können, werde ich als Beispiel das NASCAR- oder Formel-1-Rennteam anführen", sagt Chris Short, General Manager des Cloud-Plattform-Marketings von Red Hat und Herausgeber der DevOps-Mailingliste. - Der Leiter eines solchen Teams hat ein Ziel: den maximal möglichen Platz gemäß den Ergebnissen des Rennens einzunehmen, unter Berücksichtigung der dem Team zur Verfügung stehenden Ressourcen und der Prüfungen, die auf seinen Anteil fielen. Darüber hinaus ist das Rennen nicht von Anfang bis Ende geplant, sondern von Ende bis Start. Zuerst wird ein ehrgeiziges Ziel festgelegt, und dann werden Wege festgelegt, um es zu erreichen. Dann werden sie in Unteraufgaben unterteilt und an Teammitglieder delegiert. “
„Die ganze Woche vor dem Rennen hat das Team den Boxenstopp verbessert. Er trainiert Kraft und Cardio, um an einem anstrengenden Renntag in Form zu sein. Er erarbeitet gemeinsame Maßnahmen, um eventuelle Probleme im Rennen zu lösen. Ebenso muss das Entwicklungsteam die Fähigkeiten trainieren, häufig neue Versionen zu veröffentlichen. Mit solchen Fähigkeiten und einem gut funktionierenden Sicherheitssystem kommt es auch häufiger vor, dass neue Versionen in der Produktion eingeführt werden. In dieser Weltanschauung bedeutet eine Erhöhung der Geschwindigkeit eine Erhöhung der Sicherheit “, sagt Short.
„Es geht nicht darum, das„ Richtige “zu tun“, fügt Short hinzu, „sondern möglichst viele Dinge zu eliminieren, die dem gewünschten Ergebnis im Wege stehen. Arbeiten Sie zusammen und passen Sie sich an das Feedback an, das Sie in Echtzeit erhalten. Seien Sie auf Anomalien vorbereitet und arbeiten Sie an der Verbesserung der Qualität, um deren Auswirkungen auf die Bewegung in Richtung Ziel zu minimieren. Das erwartet uns in der Welt von DevOps. “
So skalieren Sie DevOps: 10 Expertentipps
Nur DevOps und massive DevOps sind zwei völlig verschiedene Dinge. Wir zeigen Ihnen, wie Sie die Barrieren von der ersten zur zweiten überwinden können.Für viele Unternehmen beginnt der Weg zu DevOps einfach und gut. 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 von Fortschritt, so Ben Grinnell, Geschäftsführer und Leiter der digitalen Technologie bei der Beratungsfirma North Highland. Frühe Siege sind sicherlich ermutigend, tragen aber nicht dazu bei, das endgültige Ziel zu erreichen, nämlich den massiven Einsatz von DevOps in der Organisation.
Es ist leicht zu erkennen, dass sich dadurch eine Kultur der Trennung in „wir“ und „sie“ bildet.„Oft starten Unternehmen solche wegweisenden Projekte und glauben, dass sie den Weg für Massen-DevOps ebnen werden, ohne zu zögern können und werden andere diesen Weg gehen wollen“, erklärt Ben Grinnel. - Teams für die Umsetzung solcher Projekte werden normalerweise von selbstbewussten „Wikingern“ rekrutiert, die bereits an anderen Orten etwas Ähnliches getan haben, aber für Ihre Organisation neu sind. Gleichzeitig werden sie ermutigt, die Regeln zu brechen und zu zerstören, die für alle anderen verbindlich bleiben. Es ist leicht zu erkennen, dass dadurch eine Kultur der Trennung in „wir“ und „sie“ entsteht, die den Transfer von Wissen und Fähigkeiten behindert. “
„Und dieses kulturelle Problem ist nur einer der Gründe, warum DevOps schwer zu skalieren ist. Die DevOps-Teams sehen sich mit dem Wachstum rein technischer Schwierigkeiten konfrontiert, die für schnell wachsende Unternehmen charakteristisch sind, die sich auf IT-Technologie verlassen haben “, sagte Steve Newman, Gründer und Vorstandsvorsitzender von Scalyr.
„In der modernen Welt ändern sich die Dienstleistungen, sobald ein solcher Bedarf entsteht. Die weitere Implementierung und Implementierung neuer Funktionen ist natürlich großartig, aber die Koordination dieses Prozesses und die Behebung von Problemen ist ein echtes Problem “, fügt Steve Newman hinzu. - In sehr schnell wachsenden Organisationen haben Ingenieure als Teil funktionsübergreifender Teams Schwierigkeiten, Änderungen und die von ihnen auf Abhängigkeitsebene erzeugten Kaskadeneffekte zu verfolgen. Darüber hinaus sind Ingenieure überhaupt nicht glücklich, wenn ihnen eine solche Gelegenheit genommen wird, und infolgedessen wird es für sie schwieriger, das Wesentliche der auftretenden Probleme zu verstehen. “
Wie können diese oben beschriebenen Schwierigkeiten überwunden und der massive Einsatz von DevOps in einer großen Organisation fortgesetzt werden? Experten fordern Sie auf, geduldig zu sein, auch wenn Ihr oberstes Ziel darin besteht, den Softwareentwicklungszyklus und die Geschäftsprozesse zu beschleunigen.1. Denken Sie daran, dass der kulturelle Wandel Zeit braucht
Jayne Groll, Executive Director des DevOps Institute: „Meiner Meinung nach sollte die DevOps-Erweiterung so schrittweise und iterativ sein wie die agile Entwicklung (und die Kultur gleichermaßen beeinflussen). Agile und DevOps konzentrieren sich auf kleine Teams. Mit zunehmender Anzahl und Integration solcher Teams wenden jedoch immer mehr Menschen neue Arbeitsmethoden an, und infolgedessen entsteht ein umfassender kultureller Wandel. “
2. Verbringen Sie genügend Zeit mit der Planung und Auswahl einer Plattform
Eran Kinsbruner, leitender technischer Evangelist bei Perfecto: „Damit die Skalierung funktioniert, müssen die DevOps-Teams zunächst lernen, wie traditionelle Prozesse, Tools und Fähigkeiten kombiniert werden, und dann jede einzelne DevOps-Phase langsam erweitern und stabilisieren. Alles beginnt mit einer sorgfältigen Planung von User Stories und Wertströmen (Wertestream), gefolgt von der Phase des Schreibens von Software und der Versionskontrolle mithilfe der Trunk-basierten Entwicklung oder anderer Ansätze, die sich am besten zum Verzweigen und Zusammenführen von Code eignen. “
„Dann folgt die Integrations- und Testphase, in der bereits eine skalierbare Automatisierungsplattform erforderlich ist. Und hier ist es wichtig, dass DevOps-Teams die richtige Plattform auswählen, die ihren Fähigkeiten und den endgültigen Zielen des Projekts entspricht.
Die nächste Phase ist die Bereitstellung in einer Produktionsumgebung und sollte mithilfe von Orchestrierungswerkzeugen und -containern vollständig automatisiert werden. Gleichzeitig ist es wichtig, in allen Phasen von DevOps (einem Produktionsumgebungssimulator, einer Qualitätskontrollumgebung und tatsächlich einer Produktionsumgebung) virtualisierte Umgebungen zu haben und immer nur die neuesten Daten für Tests zu verwenden, um relevante Schlussfolgerungen zu erhalten. Analytics muss intelligent sein und Big Data mit schnellem und effizientem Feedback verarbeiten können. “
3. Befreien Sie sich von dem schuldigen Geschmack
Gordon Haff, RedHat-Evangelist: „Die Schaffung eines Systems und einer Atmosphäre, die Experimente ermöglichen und fördern, ermöglicht die Implementierung sogenannter erfolgreicher Fehler in der agilen Softwareentwicklung. Dies bedeutet nicht, dass niemand anderes für die Fehler verantwortlich ist. In der Tat wird es noch einfacher, eine verantwortliche Person zu etablieren, da „verantwortlich sein“ nicht mehr bedeutet, „der Schuldige des Unfalls zu werden“. Das heißt, das Wesen der Verantwortung ändert sich qualitativ. In diesem Fall werden vier Faktoren äußerst wichtig: das Ausmaß des Ausfalls, Ansätze, Produktionsprozesse und Anreize. “ (Weitere Informationen zu diesen Faktoren finden Sie in den DevOps-Lektionen von Gordon Huff: 4 Aspekte gesunder Experimente.)
4. Machen Sie den Weg frei
Ben Grinnell, Geschäftsführer und Leiter Digital Technology bei North Highland Consulting: „Zur Skalierung empfehle ich, das Pathfinder-Programm zusammen mit wegweisenden Projekten zu starten. Das Ziel dieses Programms ist es, den Müll zu beseitigen, der bei den Pionieren von DevOps verbleibt, z. B. Regeln, die an Relevanz verloren haben, und ähnliche Dinge, damit der Weg nach vorne frei bleibt. “
„Geben Sie den Menschen organisatorische Unterstützung und geben Sie Impulse durch Kommunikation, die weit über die Pioniergruppe hinausgeht und den Erfolg neuer Arbeitsmethoden weithin feiert. Trainieren Sie Personen, die an der nächsten Welle von DevOps-Projekten beteiligt sind und nervös sind, DevOps zum ersten Mal zu verwenden. Und denken Sie daran, dass diese Leute sich sehr von den Pionieren unterscheiden. “
5. Werkzeuge demokratischer machen
Steve Newman, Gründer und Vorsitzender von Scalyr: „Werkzeuge sollten nicht vor Menschen verborgen sein und für jeden, der bereit ist, Zeit damit zu verbringen, relativ einfach zu erlernen sein. Wenn die Möglichkeit, Protokolle anzufordern, nur drei Personen zur Verfügung steht, die für die Arbeit mit einem Tool „zertifiziert“ sind, haben Sie immer maximal drei Personen, die sich mit dem entsprechenden Problem befassen können, selbst wenn Sie über eine sehr große Computerumgebung verfügen. Mit anderen Worten, hier entsteht ein Engpass, der schwerwiegende (geschäftliche) Konsequenzen haben kann. “
6. Schaffen Sie ideale Bedingungen für die Teamarbeit
Tom Clark, Leiter der Common Platform bei ITV: „Sie können alles tun, aber nicht alles auf einmal. Setzen Sie sich daher große Ziele, fangen Sie klein an und fahren Sie mit schnellen Iterationen fort. Mit der Zeit werden Sie einen Ruf als erfolgreiches Team erlangen, sodass auch andere Ihre Methoden anwenden möchten. Und jagen Sie nicht dem Aufbau eines hochwirksamen Teams nach. Bieten Sie den Menschen stattdessen ideale Arbeitsbedingungen, und Effizienz wird von selbst kommen. “
7. Vergessen Sie nicht Conway Law und Kanban Boards
Logan Daigle, CollabNetVersionOne DevOps-Direktor für Softwarebereitstellung und Strategie: „Es ist wichtig, die Konsequenzen des Conway-Gesetzes zu verstehen. In meiner kostenlosen Paraphrase besagt dieses Gesetz, dass die von uns erstellten Produkte und die von uns verwendeten Prozesse, einschließlich DevOps, sich als dieselben wie unsere Organisation herausstellen. “
„Wenn die Organisation stark fragmentiert ist und das Management beim Planen, Erstellen und Freigeben von Software viele Male von Hand zu Hand geht, ist der Effekt der Skalierung gleich Null oder von kurzer Dauer. Wenn die Organisation funktionsübergreifende Teams um Produkte bildet, die marktorientiert finanziert werden, steigen die Erfolgschancen dramatisch. “
„Ein weiterer wichtiger Aspekt der Skalierung besteht darin, alle laufenden Arbeiten (WIP, Workinprogress) auf den Kanban-Tafeln anzuzeigen. Wenn eine Organisation an einem Ort erscheint, an dem Menschen solche Dinge sehen können, stimuliert dies die Zusammenarbeit erheblich, was sich positiv auf die Skalierung auswirkt. “
8. Suchen Sie nach alten Narben
Manuel Pais, DevOps-Berater und Co-Autor von Team Topologies: „Die Übernahme von DevOps-Praktiken über Devi Ops hinaus und der Versuch, sie auf andere Funktionen anzuwenden, kann kaum als optimaler Ansatz bezeichnet werden. Dies wird zweifellos einen gewissen Effekt haben (zum Beispiel aufgrund der Automatisierung der manuellen Steuerung), aber viel mehr kann erreicht werden, wenn wir mit einem Verständnis der Lieferprozesse und des Feedbacks beginnen. “
„Wenn das IT-System des Unternehmens alte Narben aufweist - Verfahren und Verwaltungsmechanismen, die aufgrund früherer Vorfälle implementiert wurden, aber ihre Relevanz verloren haben (aufgrund einer Änderung von Produkten, Technologien oder Prozessen), müssen sie auf jeden Fall entfernt oder geglättet werden. und nicht ineffiziente oder unnötige Prozesse automatisieren. “
9. Spawnen Sie keine DevOps-Optionen
Anthony Edwards, Produktionsleiter für Auberginen: „DevOps ist ein sehr vager Begriff, daher hat jedes Team seine eigene Version von DevOps. Und es gibt nichts Schlimmeres, wenn sofort 20 DevOps-Sorten in der Organisation erscheinen, die nicht sehr gut miteinander auskommen. Jedes der drei Entwicklungsteams kann keine eigene, spezielle Schnittstelle zwischen Entwicklung und Produktmanagement haben. Da es für die Produkte unmöglich ist, ihre eigenen, einzigartigen Erwartungen hinsichtlich der Verarbeitung von Feedback zu haben, wenn die Produktionsumgebung auf den Simulator übertragen wird. Andernfalls können Sie DevOps niemals skalieren. "
10. Predigen Sie den Wert von DevOps für Unternehmen
Steve Newman, Gründer und Vorsitzender von Scalyr: „Arbeiten Sie daran, den Wert von DevOps zu erkennen. Lernen Sie und sprechen Sie über die Vorteile Ihrer Arbeit. DevOps spart unglaublich Zeit und Geld (denken Sie nur an weniger Ausfallzeiten, kürzere durchschnittliche Wiederherstellungszeit), und DevOps-Teams müssen die Bedeutung dieser Initiativen für den Geschäftserfolg unermüdlich betonen (und predigen). So können Sie den Kreis der Anhänger erweitern und den Einfluss von DevOps in der Organisation stärken. "
BONUS
Am 13. September werden unsere eigenen DevOps beim Red Hat Forum Russia eintreffen - ja, Red Hat als Softwarehersteller hat seine eigenen DevOps-Teams und -Praktiken.Unser Ingenieur Mark Birger, der interne Automatisierungsdienste für andere Gruppen im gesamten Unternehmen entwickelt, erzählt seine eigene Geschichte in rein russischer Sprache - wie das Red Hat DevOps-Team Anwendungen aus von Hat Virtualization verwalteten Umgebungen von Ansible in ein vollständiges Containerformat auf der OpenShift-Plattform migrierte.
Aber das ist noch nicht alles:Nachdem Organisationen Workloads in Container übertragen haben, funktionieren herkömmliche Methoden zur Anwendungsüberwachung möglicherweise nicht mehr. Im zweiten Bericht werden wir unsere Motivation zur Änderung der Registrierungsmethode erläutern und die Fortsetzung des Weges zeigen, der uns zu modernen Methoden der Aufzeichnung und Überwachung führte.