Hallo, Habr! Ich präsentiere Ihnen eine Übersetzung des Artikels. „Die Ursprünge von DevOps: Was steckt in einem Namen?“ Autor Steve Mezak.

Je nach Perspektive wird DevOps in diesem Jahr sein neuntes oder zehntes Jubiläum feiern. Im Jahr 2016 berichtete der RightScale-Cloud-Statusbericht, dass 70 Prozent der kleinen und mittelständischen Unternehmen DevOps-Methoden übernehmen. Jedes Element, das zu dieser Einschätzung beiträgt, hat sich seitdem erhöht. Während DevOps sich darauf vorbereitet, in sein zweites Jahrzehnt einzutreten, wäre es großartig, durch die Ecken der Vergangenheit zu schlendern und zu den Wurzeln von DevOps zurückzukehren – und sogar zur Herkunft des Namens selbst.

Vor 2007: Die perfekte Kette von Ereignissen

Vor 2007 führte eine Reihe von Umständen schließlich zur Entstehung dessen, was heute als DevOps bekannt ist.

Lean Production hat sich bereits als Best Practice etabliert. Auch bekannt als Toyota Produktionssystem, strebt Lean Production danach, die Prozesse in der Produktionshalle zu optimieren. (Übrigens ließ sich das Management von Toyota ursprünglich von den ursprünglichen Montagemethoden inspirieren, die von der Ford Motor Company vorgestellt wurden). Kontinuierliche Verbesserung ist das Mantra für Lean Production. In der Praxis werden ständig folgende Wege bewertet:

1. Die Unterstützung des Lagerbestands an Rohmaterial und Fertigprodukten auf einem Minimum. Lean Production bedeutet ein minimales Inventar an Rohmaterialien zur Herstellung von Produkten und eine minimale Anzahl von bereits fertigen Produkten, die auf die Aufträge oder den Versand warten.
2. Minimierung der Auftragswarteschlangen. Idealerweise gehen die eingegangenen Bestellungen sofort in den Status „abgeschlossen“ über. Eine Schlüsselkennzahl für Lean Production wird immer die Zeit vom Eingang der Bestellung bis zur Lieferung sein.
3. Maximierung der Effizienz des Produktionsprozesses. Die Reorganisation von Prozessen und verbesserte Automatisierung werden kombiniert mit dem Ziel, Produkte so schnell wie möglich herzustellen. Jeder Abschnitt der Produktion auf dem gesamten Weg (Schneiden, Schweißen, Montage, Testen usw.) wird auf Ineffizienzen überprüft.

In der IT haben traditionelle Methoden des Wasserfallmodells der Softwareentwicklung bereits schnelleren iterativen Methoden Platz gemacht, wie z.B. Agile. Geschwindigkeit war ein Schlachtruf, auch wenn die Qualität manchmal auf der Jagd nach schneller Entwicklung und Bereitstellung litt. Ähnlich haben sich Cloud-Computing, insbesondere Infrastructure-as-a-Service (IaaS) und Platform-as-a-Service (PaaS) als ausgereifte Lösungen in den Prozessen und der IT-Infrastruktur etabliert.

Schließlich begannen kürzlich Werkzeugsätze für Kontinuierliche Integration (CI) zu erscheinen. Das Konzept von CI-Tools wurde erstmals 1991 von Grady Booch in seiner Booch-Methode geboren und vorgestellt.

2007-2008: Der frustrierte Belgier

Der belgische Berater, Projektmanager und Agile-Praktiker Patrick Debois erhielt einen Auftrag von der Regierung Belgien, um bei der Migration von Rechenzentren zu helfen. Insbesondere war er für die Zertifizierung und Überprüfung der Bereitschaft zuständig. Die Aufgaben erforderten von ihm, Maßnahmen abzustimmen und Beziehungen zwischen Softwareentwicklungsteams und Betriebsteams, ServerDatenbanken und Netzwerken aufzubauen. Seine Frustration über das Fehlen von Kohärenz und die Mauern, die Entwicklung und Betrieb trennten, hinterließen einen bitteren Beigeschmack. Der Drang nach Verbesserungen führte Debois bald zu handeln.
Im Jahr 2008 auf der Agile-Konferenz in Toronto schlug Andrew Shafer vor, ein speziell organisiertes informelles Treffen zur Diskussion des Themas "Agile-Infrastruktur" zu moderieren. Und nur eine Person erschien, um das Thema zu besprechen: Patrick Debois. Ihre Diskussion und der Austausch von Ideen trugen zur Entwicklung des Konzepts des systematischen Administrierens nach Agile bei. In demselben Jahr gründeten Debois und Shafer eine mäßig erfolgreiche Gruppe von Agile Systems Administratoren bei Google.

2009: Die Zusammenarbeit von Dev und Ops

Auf der O’Reilly Velocity-Konferenz präsentierten zwei Mitarbeiter von Flickr, der Senior Vice President of Technical Operations John Allspaw und der technische Leiter Paul Hammond, die mittlerweile berühmte Präsentation "10 Deployments pro Tag: Zusammenarbeit von Dev und Ops bei Flickr".

Die Präsentation war im Stil eines Dramas, in dem Allspow und Hammond ein komplexes Zusammenspiel zwischen Vertretern von Development und Operations während des Software-Deployment-Prozesses darstellten, zusammen mit der Suche nach Schuldigen und gegenseitigen Anschuldigungen im Sinne von „Das ist nicht mein Code, das sind alles deine Computer!“ Ihre Präsentation bestätigte, dass der einzige sinnvolle Ausweg darin besteht, dass die Aktivitäten der Softwareentwicklung und -bereitstellung reibungslos, transparent und voll integriert sind. Im Laufe der Zeit wurde diese Präsentation legendär und wird nun historisch als grundlegender Meilenstein betrachtet, als die IT-Branche nach einer Methodik verlangte, die heute als DevOps bekannt ist.

2010: DevOps in den Vereinigten Staaten von Amerika

Mit der wachsenden Zahl der Unterstützer fand die DevOpsDays-Konferenz zum ersten Mal in den Vereinigten Staaten von Amerika in Mountain View, Kalifornien, kurz nach der jährlichen Velocity-Konferenz statt. Lassen Sie uns ins Jahr 2018 springen: Es sind mehr als 30 DevOpsDays-Konferenzen geplant, darunter Dutzende in den Vereinigten Staaten.

2013: Projekt „Phoenix“

Für viele von uns war ein weiteres bemerkenswertes Ereignis in der Geschichte von DevOps die Veröffentlichung des Buches „Projekt „Phoenix“ von Gene Kim, Kevin Behr und George Spafford. In diesem Roman wird die Geschichte eines IT-Managers erzählt, der sich in einer ausweglosen Situation befindet: Ihm wurde die Aufgabe übertragen, ein kritisch wichtiges E-Commerce-Projekt zu retten, das nicht gut lief. Ein geheimnisvoller Mentor des Managers — ein Mitglied des Vorstands, der von Lean-Methoden begeistert ist — gibt dem Protagonisten neue Denkanstöße zur IT und Softwareentwicklung, die der DevOps-Konzeption vorwegnehmen. Übrigens inspirierte uns „Projekt „Phoenix“ dazu, das Buch „Gehe zu Outsourcing, sonst...“ über eine ähnliche Geschichte aus der Geschäftswelt zu schreiben, in der ein Software-Vizepräsident DevOps bei der Entwicklung eines neuen großen Produkts im Outsourcing verwendet.

DevOps für die Zukunft

Es ist besser, DevOps als eine Reise oder vielleicht als ein Streben zu beschreiben, als als ein Endziel. DevOps, ähnlich wie Lean Manufacturing, strebt nach kontinuierlicher Verbesserung, Produktivitäts- und Effizienzsteigerung und sogar nach kontinuierlicher Bereitstellung. Automatisierte Tools zur Unterstützung von DevOps entwickeln sich weiterhin.

In den letzten zehn Jahren wurden viele Fortschritte mit der Einführung von DevOps erzielt, und wir erwarten, 2018 und in Zukunft noch mehr zu sehen.

Quelle: habr.com