Was ist der Unterschied zwischen Sysadmin und DevOps Engineer?


40

Wenn Sie sich für eine Stelle bewerben, finden Sie normalerweise zwei Arten ähnlicher Stellen: Sysadmin Engineer und DevOps Engineer .

Beide beschäftigen sich mit der Serverkonfiguration und gewährleisten den zuverlässigen Betrieb von Computersystemen. Es kann schwierig sein, den Unterschied zwischen den beiden zu erkennen. Was sind die Hauptunterschiede zwischen ihnen?




SRE- und Sysadmin-Begriffe sind unterschiedlich.
Kenorb

2
Ich schlage vor, Sie fügen eine Definition für sysadmin hinzu und lassen Antworten zu, die dies mit der Rolle von DevOps vergleichen können. Ich persönlich denke, dass DevOps nicht einmal eine Rolle spielt ... also würde ich etwas dazu sagen.
Evgeny

1
@Evgeny Sagen Sie das den Personalagenturen.
Kenorb

Antworten:


54

Hauptsächlich ist DevOps keine Rolle (wenn es als solche verwendet wird, ist es eher ein Modewort als eine echte Rolle).

DevOps ist in etwa ein Organisationsmuster, das darauf abzielt, das Silo zwischen Entwicklern und Systemadministratoren zu durchbrechen.
Das Hauptziel besteht darin, Teams mit Entwicklern und Systemadministratoren (in der Regel zusammen mit Testern) zusammenzustellen, die für ein Produkt (eine Anwendung) von der Definition über Architekturentscheidungen bis zur laufenden Wartung dieses Produkts verantwortlich sind.
Jedes Mitglied des Teams wird Teil der Entscheidung über den gesamten Lebenszyklus des Produkts sein, ein Entwickler wird einige Sysadmin-Aufgaben in der Produktion ausführen und ein Sysadmin wird an der Entwurfsphase des Produkts teilnehmen, um Einschränkungen aus der Sicht der Infrastruktur zu vermeiden zum Beispiel.

Im Idealfall wäre ein Sysadmin auch Teil des Entwicklungsteams für das Produkt. In der Praxis bezieht sich der Sysadmin-Code eher auf die Konfiguration des Produkts und die Überwachungslösungen, aber die Möglichkeit, Bedenken gegenüber anderen Mitgliedern des Teams auszudrücken, vermeidet viele Missverständnisse auf den Bereitstellungsprozess.


9
Soviel dazu ... DevOps ist keine Rolle. Sie "erledigen" die Systemverwaltung auf andere Weise als "Teil" einer DevOps-Kultur.
Ken Mugrage

2
Einige Organisationen, in denen ich gearbeitet habe (vielleicht eher durch Zufall als durch Design), haben dies zu einem Extrem gemacht: Wir hatten keine dedizierten Sysadmins und die gesamte Sysadmin-Arbeit wurde von "normalen" Entwicklern erledigt. (In dieser speziellen Organisation waren viele der Entwickler sehr erfahrene Systemadministratoren, daher mussten wir nie jemanden einstellen, der sich darauf spezialisiert hat.)
Curt J. Sampson,

"DevOps ist ungefähr ein Organisationsmuster", der aufschlussreichere Ausschnitt, den ich bisher gelesen habe.
Webwoman

Vielleicht können Sie klarstellen, dass DevOps! = NoOps
sgargel

20

Kurze Version

DevOps ist eine Kombination aus Organisationskultur, agilen / schlanken Arbeitsweisen und Softwareautomation, die es bei Anwendung auf Systemadministration und -betrieb ermöglicht, dass diese Funktionen mit der gleichen Flexibilität wie agile oder schlanke Entwicklungsteams ausgeführt werden.

Lange Version

Die Ideen, die hinter DevOps standen, kamen von den Communities Systems Administration, Operations und Agile. Insbesondere hielt Patrick Debois auf der Agile2008 einen Vortrag mit dem Titel 'Agile Infrastructure', in dem er die Unterschiede zwischen den drei Funktionen innerhalb einer Organisation hervorhob:

  1. Agile Entwicklungsteams - Agile Teams, die Code schreiben.
  2. Systemadministrationsteams - Aufbau einer Infrastruktur zum Ausführen der Software.
  3. Operations Teams - Unterstützung von Anwendungen und Infrastruktur in Production / Live.

Debois 'Vorschlag war, die drei Arten der Zusammenarbeit zu vereinheitlichen, indem speziell Systemadministrationsteams und Betriebsteams von einem Wasserfallmodell zu einem agilen Modell verschoben wurden. Zu diesem Zweck gründete Debois DevOpsDays 2009 in Gent, Belgien, und prägte versehentlich die Phrase DevOps .

Die Idee von DevOps fand großen Anklang bei den Autoren der VisibleOps-Buchreihe: Gene Kim, George Spafford und Kevin Behr; wer fuhr fort, das Phoenix-Projekt und das DevOps-Handbuch zu schreiben . In beiden Büchern wird untersucht, wie sich Agile und Lean positiv auf die Teams für Systemadministration und -betrieb auswirken können.


1
Hervorragende Zusammenfassung! Das Beste, was ich bisher über die Geschichte hinter dieser Philosophie und diesem technischen Stil gesehen habe.
Jesse Adelman

8

Als DevOps Engineer mit Operations-Hintergrund sind Sie vom manuellen Erstellen und Bereitstellen von Servern und Software zum Skripten der Installation von Software auf Ihren Servern mit BASH, PowerShell, Python usw. übergegangen. Nach einer Weile merkten Sie, wie Coole Skripterstellung ist und beginnen, ausgefeiltere Möglichkeiten zur Automatisierung der Bereitstellung zu erkunden .

Schließlich hätten Sie sich für ein Chef-, Puppet-, Ansible- oder anderes Konfigurationsmanagement- Tool entschieden, um den Status Ihrer Systemflotte zu verwalten. Als Ihre Kenntnisse in der Automatisierung der Anwendungsbereitstellung und des Systemmanagements zusammen mit Ihren Tools reifer wurden, sind Sie in jüngerer Zeit in den Bereich „ Infrastruktur als Code“ gewechselt und haben damit nicht nur die Bereitstellung von Software, sondern auch die erforderliche Infrastruktur und die erforderlichen Umgebungen automatisiert um die Software während der Umstellung des Unternehmens auf die Cloud zu betreiben.

Jetzt kochst du mit Gas. Im Laufe der Zeit wurden Sie mit den Vorteilen der Verwendung von entwicklerorientierten Tools wie der Quellcodeverwaltung vertraut gemacht , um die Module, Rezepte und Vorlagen zu verwalten, die Ihr Arsenal an Bereitstellungs- und Verwaltungstools bilden.

Als Sie in das DevOps- Team wechselten, waren Sie dem Lebenszyklus der Softwareentwicklung und dem Konzept der kontinuierlichen Integration ausgesetzt . Junge, diese Entwickler haben Änderungen schnell veröffentlicht und um Schritt zu halten, haben Sie enger mit den Entwicklern zusammengearbeitet! Sie haben die Dringlichkeit des Entwicklungsteams erlebt, die Dinge STÄNDIG zu ändern, was dem alten betrieblichen Paradigma widerspricht: " Wenn es nicht kaputt ist, reparieren Sie es nicht ". Sie prahlen nicht mehr mit der Systemverfügbarkeit, sondern stehen auf verfügbare Infrastruktur.

Sie haben bemerkt, dass der Wechsel zu DevOps mehr war als die Arbeit mit den Entwicklern oder der Einsatz neuer Tools und Techniken , aber es gab einen deutlichen kulturellen Wandel im Team, der die gesamte Organisation durchdrang. Sie haben als engmaschiges Team mit geteilten Verantwortlichkeiten , gemeinsamen Werkzeugen und gemeinsamen Zielen gearbeitet .

Sie haben Ihre Fähigkeiten in der automatisierten Bereitstellung übernommen und sie in die " CICD " -Pipeline integriert, die von einem " Continuous Integration Server " wie Jenkins , Bamboo oder Code Pipeline koordiniert wird . Wenn die Entwickler neuen Code veröffentlichen, können Ihre Skripte, Tools und Vorlagen bei Bedarf neue Umgebungen einrichten, Test-Frameworks auslösen und die Vorproduktionsumgebungen herunterfahren, nachdem die grünen Ampeln bei der Veröffentlichung aufleuchten und sich an die Vorgaben halten Ideen der " kontinuierlichen Lieferung ".

Während sich der neue Code durch die CICD-Phasen schlängelt, können Sie, die Entwickler und das Unternehmen sicher sein, dass das Update bei der Freigabe für die Produktion nicht unterbrochen wird. Es ist noch ein langer Weg, bis das Team zu einer " kontinuierlichen Bereitstellung " kommt. Sie müssen sich jedoch noch auf die Feinheiten der Automatisierung der blau / grünen Bereitstellungsfunktion einigen, und die Entscheidung ist größtenteils eine geschäftliche Entscheidung. Vorerst sind Sie damit zufrieden, dass die Anzahl der Anrufe um 3 Uhr morgens nachgelassen hat und die Anzahl der Anrufe zwischen 1 und 2 abnimmt.

Selbst wenn Sie eine Sev-1 erhalten, ziehen Sie nicht mehr die Nacht durch, während die Manager Ihnen den Rücken runteratmen - Sie können die vorherige Version problemlos über die CICD-Pipeline freigeben und das System in kurzer Zeit wieder online stellen. Das Unternehmen hat festgestellt, dass sich die Stabilität der IT-Systeme trotz der Geschwindigkeit der Änderungen verbessert hat .

Sie staunen über die Art und Weise, wie Sie die Ressourcen verwalten, die für den Betrieb der Software in Ihrem Unternehmen erforderlich sind, insbesondere, wenn Sie an den Zustand und die Menge an Blut zurückdenken, die Sie im Rechenzentrum auf Schienen zurückgelassen haben ...


5

Sysadmin vs. DevOps (persönliche Ansicht)

Einige Unternehmen sprechen über Dev, Ops und Test. Wenn etwas getestet werden muss, sagen sie: "Test sollte das tun". Wenn etwas entwickelt werden muss, wird Dev das tun, und wenn Software bereitgestellt werden muss, wird Ops das tun.

Meiner Meinung nach und was ich in mehreren Unternehmen erlebt habe, ist, dass dies zu einer Denkweise "über die Mauer werfen" führt, die zu Reibungen zwischen Menschen und Teams führt. Persönlich habe ich manchmal das Gefühl, dass Menschen individuell arbeiten und sagen, dass ich das getan habe. Ich habe nichts zu tun, anstatt als Team zu arbeiten.

Meiner Meinung nach bedeutet DevOps, dass jeder in einem Team verantwortlich und damit beschäftigt ist, Dinge zu entwickeln, zu testen und zu betreiben. Es gibt kein Ich in einem Team und keine getrennten Abteilungen. Jeder sollte freigeben. Natürlich gibt es Spezialitäten, aber meiner Meinung nach sollte jeder in der Lage sein, in jedem Bereich mindestens 25% der Arbeit zu verrichten. Wenn zum Beispiel jemand früher ein Entwickler war, sollte man in der Lage sein, einen Konfigurationsverwaltungscode zu ändern, z. B. Chefkoch, und Software bereitzustellen.

Verweise

Sysadmin

Laut Wikipedia :

Ein Systemadministrator oder Sysadmin ist eine Person, die für die Wartung, Konfiguration und den zuverlässigen Betrieb von Computersystemen verantwortlich ist. insbesondere Mehrbenutzer-Computer wie Server.

Der Systemadministrator versucht sicherzustellen, dass die Verfügbarkeit, Leistung, Ressourcen und Sicherheit der von ihm verwalteten Computer den Anforderungen der Benutzer entsprechen, ohne das Budget zu überschreiten.

Um diese Anforderungen zu erfüllen, kann ein Systemadministrator Computerkomponenten und -software erwerben, installieren oder aktualisieren. routinemäßige Automatisierung; Sicherheitsrichtlinien einhalten; Problembehandlung; Personal schulen oder beaufsichtigen; oder technische Unterstützung für Projekte anbieten.

DevOps

Laut Wikipedia :

DevOps (eine gekürzte Mischung aus "Entwicklung" und "Betrieb") ist ein Softwareentwicklungs- und -bereitstellungsprozess, bei dem die Kommunikation und Zusammenarbeit zwischen Produktmanagement-, Softwareentwicklungs- und Betriebsexperten im Vordergrund steht. Dies wird durch die Automatisierung und Überwachung des Prozesses der Softwareintegration, Tests, Bereitstellung und Infrastrukturänderungen unterstützt, indem eine Kultur und Umgebung eingerichtet wird, in der das Erstellen, Testen und Freigeben von Software schnell, häufig und zuverlässiger erfolgen kann.

DevOps

Bildbeschreibung hier eingeben

DevOps-Toolchain

Bildbeschreibung hier eingeben


1
Nur eine winzige Bemerkung: IMHO, solange das Team als Ganzes jeden Aspekt der Entwicklungs- / Operations- / Testbereiche gut abdeckt und eine gute Kommunikation hat, ist es nicht unbedingt erforderlich, dass jeder einzelne im Team auch jeden solchen Bereich abdeckt. Sicher, es ist eine gute Sache, wenn das passiert, aber in einigen Fällen kann es unnötig teuer werden , es zu verlangen .
Dan Cornilescu

2

Ein Systemadministrator ist für die Wartung und Konfiguration von Servern verantwortlich. Er ist dafür verantwortlich, dass der Benutzer die Leistung, Verfügbarkeit und Sicherheit erhält, die er sucht. Die Definition der Rolle eines DevOps-Ingenieurs ist etwas schwieriger, da es keinen formellen Karriereweg gibt und DevOps selbst viele Formen annehmen kann.

Ein DevOps-Ingenieur kann zum Beispiel ein Entwickler sein, der an Netzwerk- und Bereitstellungsvorgängen interessiert ist, oder ein Systemadministrator, der eine Leidenschaft für Codierung und Skripterstellung hat. Der Übergang vom Systemadministrator zum DevOps-Ingenieur ist nicht sehr schwierig. In diesem Artikel wird der Prozess sehr gut beschrieben.

Viele Leute würden sogar argumentieren, dass dieser Übergang vom Systemadministrator zum DevOps-Ingenieur unabdingbar ist, da die Position des Systemadministrators in Zukunft hinfällig wird. Obwohl es viele Legacy-Server gibt, die gewartet werden müssen, und Systemadministratoren über viel Stammeswissen verfügen, wird die Sysadmin-Position in Zukunft immer knapper.


-1

Es wird Server geben, die in Rechenzentren nicht laufen. Alles wird Software sein. Speicher, Netzwerk, Systeme, Sicherheit, Rechenzentren; SDN, Firewalls, NFV, Speicher, Server usw. Sysadmins ohne Softwareentwicklungshintergrund, SDLC-Erfahrung (ich meine nicht einmal das Erstellen von Skripten für Perl, Powershell usw.) werden wahrscheinlich verschwinden. Verteilte, skalierbare und virtualisierte Umgebungen, bei denen es sich hauptsächlich um Cloud-Umgebungen handelt, wachsen horizontal und nicht vertikal.


Ich wage zu sagen, dass Sysadmins vertikal wachsen, DevOps (oder OpsDev) horizontal wachsen. Sie können das gleiche Muster sehen, wie sich aus Monolithen Microservices entwickelten. Ich würde lieber den DevOps-Ingenieur aus dem Software-Team wählen, nicht aus dem Operations / System-Team.

Weil das Operations / System-Team nur das ausführt, was das Software-Team erstellt.

  • Sysadmins erstellen / kompilieren keinen Linux- / FreeBSD- / Windows-Kernel usw. genauso wie Software-Entwickler Anwendungen erstellen / kompilieren.
  • Sysadmins durchlaufen nicht den Software Development Lifecycle (SDLC).
  • Sysadmins sind nicht Bestandteil der Produktionspipeline (CI / CD-Prozess).
  • Sysadmin wird ausgeführt, nachdem CI / Continuous Delivery / Deployment beendet wurde.

    Und wenn Sie Deployment / Delivery unterbrechen und zuweisen, kann es sein, dass die Pipeline unterbrochen ist.
    Das Software-Team ist das Erstellersystem.

Es hört sich so an, als gäbe es keinen zu verwaltenden Server / System, keinen Sysadmin-Bedarf.

Serverless Computing ist ein Cloud-Computing-Ausführungsmodell, bei dem der Cloud-Anbieter als Server fungiert und die Zuordnung von Maschinenressourcen dynamisch verwaltet. Die Preisberechnung basiert auf der tatsächlichen Menge an Ressourcen, die von einer Anwendung verbraucht werden, und nicht auf vorab gekauften Kapazitätseinheiten für Serverless Computing

Jemand aus dem Software-Team weiß bereits, wie man Code erstellt und verwaltet (SRE vs DevOps / OpsDev).


Ich frage mich, warum es DevOps heißt, aber nicht OpsDev? hängt es mit der Richtung zwischen den beiden zusammen?

* Mitten im Nirgendwo habe ich nicht angefangen, über softwaredefinierten Speicher zu schreiben. Dies ist eine Reaktion auf einen jetzt gelöschten Kommentar dazu. *

Informationen zum softwaredefinierten Speicher

  • Software-Defined Storage (SDS) ist ein Marketingbegriff für Computer-Datenspeichersoftware zur richtlinienbasierten Bereitstellung und Verwaltung von Datenspeichern unabhängig von der zugrunde liegenden Hardware. Software-definierter Speicher

  • EMC kündigte sein erstes Open Source-Produkt an: Project CoprHD. CoprHD ist ein Software Defined Storage-Controller für die Automatisierung und Verwaltung von Speichern. Die kürzlich von EMC getroffene Entscheidung, Open Source zu verwenden, steht im Mittelpunkt unserer Strategie, globalen Unternehmen einen Mehrwert zu bieten, wenn wir in einen Bereich des Wachstums und extremer Veränderungen eintreten. Als weltweit führender Anbieter von Speicher- und Informationsmanagement ist EMC führend in Bezug auf Software Defined Storage (SDS) .

  • CoprHD ist eine Open Source-Software-definierte Speichercontroller- und API-Plattform. Es ermöglicht die richtlinienbasierte Verwaltung und Cloud-Automatisierung von Speicherressourcen für den Block-, Objekt- und Dateispeicheranbieter CoprHD


1
Nicht erneut Add Name in Ihrer Antwort fordern, halten Sie es in Einklang mit der Frage, wieder empfehle ich Ihnen , lesen Sie wie man Antwort zur Orientierung.
Tensibai
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.