Was ist der Unterschied zwischen DevOps und Automation?

Ich sehe, wenn jemand DevOps macht, geht es hauptsächlich um die Automatisierung von Dingen wie Bereitstellung usw.

Aber wo hört die Automatisierung auf und wo beginnt DevOps?

Ein großer Teil von DevOps macht es möglich, sehr oft zu veröffentlichen. Dazu gehören automatisiertes Erstellen, automatisiertes Testen usw. Um seine Ziele zu erreichen, muss DevOps die Automatisierung verwenden, um effizient zu sein.

So hängen DevOps und Automatisierung zusammen. DevOps ist nicht nur Automatisierung, es steckt noch mehr dahinter. Umgekehrt wird die Automatisierung nicht ausschließlich von "DevOps people" verwendet. In der IT wurde viel automatisiert, bevor DevOps auf den Markt kam.

Bitte beachten Sie nicht das obige Diagramm, um all das darzustellen, was DevOps ist, oder all dies ist Automatisierung. Es soll dem Leser helfen, sich ein Bild davon zu machen, wie die beiden Konzepte zusammenhängen.

Automatisierung ist ein Schlüsselattribut von DevOps, aber es ist nicht die ganze Geschichte. Die Frage ist wie "Was ist der Unterschied zwischen Time-Boxing und Scrum?".

Sie werden hören, dass DevOps eine "Kultur", eine "Bewegung", eine "Methodik" und alle Arten von Dingen nennt, die es nicht gut genug einschließen, damit Sie es verstehen, obwohl diese Beschreibungen korrekt sind. Kurz gesagt, bei DevOps geht es um die Verschmelzung von agilen Methoden, Automatisierung und Virtualisierung, die eine neue Rückkopplungsschleife bei der Verwaltung / Steuerung / Steuerung eines Softwareprojekts ermöglicht.

Mit aggressiver Automatisierung geschehen Dinge, die lange dauern und menschlichem Versagen unterliegen, jetzt schnell und ohne Zwischenfälle. Infolgedessen neigen wir dazu, sie öfter zu machen. Ein Hauptbeispiel hierfür ist die Bereitstellung in der Produktion. Früher haben wir große Mengen an Arbeit gespart und außerhalb der Geschäftszeiten bereitgestellt, für den Fall, dass etwas schief gelaufen ist. Aber jetzt können wir Änderungen mehrmals am Tag implementieren, sodass die Wahrscheinlichkeit, dass etwas schief geht, dramatisch sinkt und die Auswirkungen von Fehlfunktionen viel geringer sind, wenn sie auftreten.

Sobald wir diesen wiederholbaren Prozess eingerichtet haben, sehen wir ihn als „Pipeline“. Anforderungen steigen, Code, der in der Produktion bereitgestellt wird, kommt heraus. Wir automatisieren alles entlang dieser Pipeline - Tests, Dokumentationen, Zusammenführungen, Bereitstellungen usw. Da sich die Leute auf die Automatisierung konzentrieren, erkennen sie nicht die "Pipeline-Mentalität", die sie angetrieben hat. Dies ist die Managementmethode - die Aufmerksamkeit, die der Pipeline geschenkt wird -, die DevOps zu mehr als Automatisierung macht.

Sobald wir diese Automatisierung eingerichtet haben, setzen die Feedback-Schleifen ein. Wir beginnen, Dinge wie die Zykluszeit zu messen, damit wir Dinge herausfinden können, die wir zuvor versucht hatten, mit Schätzungen zu erraten. Dinge über die Architektur, die die Automatisierung / kontinuierliche Bereitstellung erschweren, werden in der Regel durch alternative Architekturmuster ersetzt, die die Automatisierung / kontinuierliche Bereitstellung vereinfachen (einige hervorragende Beispiele hierfür sind in dem Buch 'Evolutionäre Datenbanken' dokumentiert. 'Green / Blue Deployments' sind andere ).

Hinweis Ich konnte diese Beschreibung bereitstellen, ohne über Jenkins, Check, Puppet, Ansible, Vagrant, AWS oder eines der anderen Tools zu sprechen, die sie unterstützen. Dies ist, was wir mit den übergeordneten Schlagworten wie "Methodik" meinen. Am Ende können alle Tools ersetzt werden ... Was bleibt, sind die zentralen Managementprinzipien, die durch die Automatisierung und den Fokus auf die Pipeline ermöglicht werden.

DevOps ist wirklich ein kultureller Wandel - es geht darum, die traditionellen Barrieren zwischen Betrieb und Entwicklung (und wirklich auch mit der Qualitätssicherung und dem Rest des Geschäfts!) Abzubauen. Die Idee ist, dass Sie anstelle von Abteilungssilos direkt mit anderen Teams zusammenarbeiten können, um die Dinge schneller und effizienter zu erledigen.

Es geht darum, Einschränkungen zu beseitigen und Prozesse zu rationalisieren. Die Automatisierung spielt eine wichtige Rolle, da wiederholbare Prozesse dabei helfen, Einschränkungen zu beseitigen. Beispiel: Wenn jemand von ops einen manuellen Veröffentlichungsprozess ausführen muss, um Code in eine Umgebung zu bringen, können einige Dinge im Wege stehen: Zum einen muss jemand von ops frei sein, um die Bereitstellung durchzuführen. und zweitens besteht weniger Vertrauen in den Freigabeprozess, da manuelle Arbeit fehleranfällig ist.

DevOps beinhaltet Automatisierung, aber das ist nur ein Teil davon. DevOps ist eine kulturelle Veränderung, um die Silos zwischen den verschiedenen Teilen der Organisation aufzubrechen und einen vollständigen Wertstrom bereitzustellen. Bereitstellung einer Kultur, in der Geschäft, Entwicklung, Qualitätssicherung, Infrastruktur, Sicherheit, Betrieb usw. zusammenarbeiten, um dem Endbenutzer einen Mehrwert zu bieten. DevOps ist kein Werkzeug, man kann es nicht kaufen, man muss seine Kultur ändern.

Automatisierung ist ein wesentlicher Bestandteil von DevOps, da sie die Liefergeschwindigkeit mit Qualität ermöglicht. Die Automatisierung des Bereitstellungsprozesses ist einer der Bereiche, auf die sich viele Menschen als Erstes konzentrieren, da dies eine der besten Möglichkeiten ist, schnell an Wert zu gewinnen und eine hohe Kapitalrendite zu erzielen, indem nicht nur die Zeit für die Bereitstellung verkürzt, sondern auch der Prozess standardisiert und entfernt wird fehler.

Ich möchte meine 2 Cent hinzufügen:
1) Automatisierung :
     Etwas, auf das wir heutzutage zugehen müssen. Es hat sich zu einer Notwendigkeit entwickelt, Teile zu automatisieren, wenn nicht sogar den gesamten Prozess. Dieser Ansatz gibt den Benutzern (Entwicklern) die Flexibilität, einen festen Schritt zu verwenden, und ermöglicht die Anpassung nach Bedarf.
     Der Vorteil dieses Ansatzes ist, dass wir die Teile, die wir möchten, automatisieren können, während der Entwickler den einzelnen Prozess zusammenbinden kann. Je detaillierter die Automatisierungsschritte sind, desto besser ist ihre Kontrolle.
     Es gibt auch viele Tools für die Automatisierung in Bereichen wie Roboterautomatisierung, SOP-Automatisierung (für die Wartungsindustrie), Berichtsautomatisierung (wie Splunk) usw.
2) DevOps:
     Angesichts der Lieferqualität und -pünktlichkeit, die von der heutigen Welt erwartet wird, muss die Automatisierung des Software-Lieferprozesses erweitert werden. Um dies zu ermöglichen und dem Kunden einen möglichst schnellen Mehrwert zu bieten, setzt DevOps in hohem Maße auf Automatisierungstools.
     Der Vorteil dieses Ansatzes besteht darin, dass die einzelnen Schritte automatisiert werden können, um unternehmensweit Konsistenz zu erzielen, während die gesamte Orchestrierung an den von diesem Projekt benötigten Prozess angepasst werden kann.
     Die einzelnen Automatisierungstools wie Chef für die Bereitstellung, Docker über Dockerfile, Maven für die Erstellung usw. können möglicherweise über Jenkins miteinander verknüpft werden, um die erforderliche Lösung bereitzustellen und gleichzeitig die für die Implementierung oder Verwendung erforderliche Zeit zu verkürzen .
Hoffe, dass dies dazu beiträgt, den Gedankenprozess, den Sie möglicherweise bereits haben, aufzuwerten.

Bearbeiten: Ich habe vergessen hinzuzufügen, dass ich über den Prozess und die Tools gesprochen habe - 2 der 3 Aspekte in DevOps. Wie von den anderen erwähnt, ist der dritte und ebenso wichtige Aspekt der Mensch. Einer der Hauptunterschiede, den ich zwischen dieser und der Automatisierung annehmen würde, wäre, dass die Leute häufiger dazu neigen, Automatisierung aufzunehmen, als sie DevOps widerstehen würden. Ich bin der Meinung, dass dies an der Natur von DevOps selbst liegt, da Automatisierung normalerweise damit verbunden ist, die Dinge für sie einfacher zu machen, während sie das Gefühl haben, dass DevOps die Art und Weise verändert, in der sie sich wohlfühlen.

DevOps-Bewegung besteht aus vier Hauptbereichen, die als CAMS abgekürzt werden :

1. Kultur
2. Automatisierung
3. Messung
4. Teilen

Hier ist der ursprüngliche definierende Beitrag von 2010.

In jedem Bereich gibt es einige Werkzeuge, Prozesse und Praktiken, die allgemein akzeptiert werden. Obwohl das Thema für Best Practices nicht gut definiert ist, gibt es in den meisten Fällen einige gute Praktiken, die befolgt werden müssen.

Die Automatisierung an sich ist ein etwas breiteres Thema, aber im Kontext von DevOps ist es nur eine Teilmenge dessen, was behandelt wird. Beachten Sie, dass wir kulturell führend sind, obwohl viele neue DevOps-Praktiker dies oft auf eigene Gefahr übersehen und direkt zur Automatisierung übergehen.

Automatisierung und DevOps haben nichts miteinander zu tun. DevOps ist eher ein kombiniertes Engineering, bei dem die Entwickler einer Site oder eines Dienstes alle Betreiber dieser Site oder dieses Dienstes sind. Warum ist dieser Roman? Meiner Erfahrung nach war das erste, was das Ops-Team tat, wenn etwas Aufregenderes als ein Netzwerkausfall passierte, das Dev-Team anzurufen. Warum haben sie das getan? Weil das Ops-Team nur eine Liste der anzurufenden Dev-Telefonnummern überwacht und aufbewahrt hat.

Beachten Sie, dass ich nichts über Automatisierung gesagt habe.

Bei der Automatisierung geht es darum, den Erfolg zu wiederholen. Wenn ich die Schritte a, b und c durchführe und Prozess X immer funktioniert, sind die Schritte a, b und c gute Kandidaten für die Automatisierung. Dann kann ich die Zeit für einen manuellen Vorgang nutzen, um Dinge zu tun, die mir mehr Geld einbringen. Automatisierung ist erfolgreich, wenn es einfach ist. Das Bereitstellen neuer Releases, das Ausführen von Integrationstests, das Festziehen einer Schraube, das Sichern von Daten, das Abwägen von Gutschriften gegen Lastschriften usw. eignen sich hervorragend für die Automatisierung, da die Schritte von einer Person oder einem Roboter wiederholt werden.

Hinweis : Neu ist, dass Entwickler auch die Bediener sind. Es gibt keine andere Gruppe. Kooperation war in meinem Fall selten. Wenn in der Anleitung zur Fehlerbehebung (alias TSG) nichts steht, ist Ihnen ein Anruf garantiert. Meiner Erfahrung nach war Ops der erste Anruf bei Baggerladern. Probleme zwischen den Diensten waren außerhalb ihres Ruderhauses.