DevOps Zustädigkeitsbereich

RobertVox

Cadet 3rd Year
Dabei seit
Nov. 2016
Beiträge
44
Hallo,

Bitte schreibt mir, wie es am häufigsten mit diesen Aufgaben von Devops ist.

Ich bin ein Java-Programmierer. Ich interessiere mich sehr für Devops und das Devops-Tool.

Ich kann mir nicht ganz vorstellen, welche Aufgaben Devops Engineer hat.

Behandelt DevOps Engineer die CI-Konfiguration in dem Sinne, dass es Jenkins (DSL) - Artefaktoren und Sonar Qube konfiguriert oder installiert er nur diese Tools und Enwickler sie konfigurieren für ihre eigenen Bedürfnisse, und dann die Rolle von DevOps ist wie ein Adminstrator

Ich frage, weil diese Konfiguration und generell die CI-Automatisierung für mich sehr interessant ist. Ich möchte kein DevOps Engineer sein, der nur für Entwickler Tools installiert und System administriert.

Ich habe auch eine Frage, wie es normalerweise aussieht, wenn ihr z. B. Mikroservices implementiert. Wer schreibt normalerweise eine DOCKERFILE in Dev-Umgebung? machen das nur Entwickler oder auch DevOps.

Ich hoffe ihr verstehst was ich meine und sorry für mein Deutsch :)

Ich weiß, dass dies individuell ist und in verschiedenen Unternehmen unterschiedlich aussehen kann, aber ich frage, wie es am häufigsten umgesetzt wird.

Vielen Dank im Voraus
 

konkretor

Commander
Dabei seit
März 2011
Beiträge
2.463
Devops ist ja eine neue Form der Organisation innerhalb des Teams Unternehmens. Viele schreiben devops weils nen tolles buzzword ist. Wenn dann die Stelle genau anschaust suchen sie einen klassischen Programmierer oder nen Admin. Die jeweils in eigenen teams sind.

Sonst hier mal etwas stöbern
https://blog.codecentric.de/
 
E

E-tech

Gast
Kommt auf die Unternehmensgröße an. Bei größerern Unternehmen gibt es eigene DevOps-Abteilungen. Die Aufgaben welche du oben beschreibst macht man auch gerne mal als Entwickler (Dev). Der eigentliche Betrieb der Systeme wird dann zumeist von anderen Leuten (Ops) durchgeführt.

Um etwas Grundverständnis über den Bereich zu schaffen empfehle ich dir den besten Freund eines IT'lers zu fragen (die Suchmaschine deiner Wahl).

Eine kleine Auswahl:
https://t3n.de/news/was-bedeutet-eigentlich-devops-723440/
https://de.atlassian.com/devops
 
Zuletzt von einem Moderator bearbeitet:

Tumbleweed

Captain
Dabei seit
März 2008
Beiträge
3.567
Disclaimer: gestartet für 5y als Entwickler, seit 3y Ops, selbst immer in kleinen Unternehmen, aber durch Kunden auch Einblicke in größere gehabt. Ich finde meine Rolle in der international gängigeren Bezeichnung SRE gut beschrieben.

Ich hab schon verschiedene Ausprägungen davon gesehen. Meines Erachtens gibt es da ein paar Missverständnisse, die sich mancherorts mittlerweile etabliert haben. Nach meinem Verständnis bezeichnet DevOps ein mindset, also eine geistige Haltung, die man versuchen sollte, in seinem Team zu etablieren. Ziel ist es, den Graben zwischen Entwicklern (Dev) und Betrieb (Ops) zu überwinden. Es war nämlich lange Zeit so (und ist leider vielerorts immer noch so), dass seitens der Entwickler eher eine "Über-Den-Zaun-Werf"-Mentalität vorherrschte.
worked-in-dev.jpg
Das hängt auch mit der hierzulande geliebten Schuldfragen-Mentalität zusammen. Wenn es kracht, geht es reflexartig darum zu klären, auf wen mit dem Finger zu zeigen ist. Wenn man die Kultur pflegt, dass die Verantwortlichkeit des Entwicklers am Rande seines IDE-Fensters endet, dann fördert man das natürlich.

Gleichzeitig hat sich auf Ops-Seite dadurch eine eher ablehnende, ausbremsende, teils schikanierende Haltung etabliert. Ist ja auch logisch - wenn ich ab Entgegennahme des Binarys für alles was ab dann passiert den Kopf hinhalten muss (d.h. z.B. auch die Nachtschicht einlegen muss, wenn der Mist im Betrieb abraucht), dann gehe ich lieber skeptischer an alles ran, was aus Richtung Entwickler kommt.

Das ist dem Gesamtunternehmen alles nicht zuträglich, weder ökonomisch, noch atmosphärisch. Ein Team, in dem alle an einem Strang ziehen, wird innovativer und produktiver vorankommen.

Eine völlig fehlgeleitete Ausprägung von DevOps, die mir schon untergekommen ist, ist die Fehlinterpretation des Slogans "you build it, you run it". In einigen Firmen führt das dazu, dass originäre Ops-Aufgaben von Entwicklern "einfach so" mitgemacht werden. Das spart die Schnittstelle und damit Reibungsverluste. Es ist aber eine Illusion, dass der gemeine (ich rede hier also von der Mehrheit, natürlich gibt es Ausnahmen) Entwickler geeignet ist, ein halbwegs sicheres und verlässliches Produktiv-System zu betreiben. Ich weiß aus der Praxis, dass das Ende vom Lied "chmod 777" (symbolisch zu betrachten) ist, weil "läuft doch".

Soviel mal vornweg und nun gehe ich auf den konkreteren Teil deiner Frage ein, ob du Docker- und CI-Pipeline-Files schreiben kannst/sollst. Du merkst an der Stelle vielleicht schon, dass du nach Details fragst.

Ich sehe die Verantwortung für Docker- und Pipeline-Files grundsätzlich bei den Entwicklern. Nun ist es aber so, dass gerade Docker bei nicht-banalen Anwendungsaufbauten sehr schnell low level wird, d.h. man wildert tief im Dschungel, in dem sich sonst nur Ops bewegt. Die Bedürfnisse (Abhänigkeiten) deiner Anwendung kennst du als Entwickler am besten. Ops hat aber gewisse Anforderungen, die das System betreffen, auf dem die Anwendung mal laufen wird:
* wohin wird wie viel in welcher Form geloggt?
* mit welchen Rechten läuft die Anwendung und entspricht das dem nötigen Minimum?
* welche Ports müssen nach außen durchgeschliffen werden und welche Container müssen untereinander kommunizieren können?
* mit welchen sonstigen Parametern (z.B. Umgebungsvariablen) muss Ops Container starten?
* etc....

Nun ist es aber so, dass nicht ständig das Rad neu erfunden werden muss. Vieles kann man einmal gemäß Richtlinien lösen und dann zur Orientierung für künftige Projekte nutzen. Ich handhabe es daher so, dass ein Entwickler mit exotischen Anforderungen bei mir (Ops) aufschlagen kann, dann diskutiere ich ein paar Sachen weg, die unnötig sind und dann löse ich das Delta als proof of concept und stelle es der Entwicklung zur Verfügung. Ich erwarte also nicht, dass sich ein Entwickler in diese Materie einliest, denn das ist nicht seine Kernkompetenz. Ich möchte dafür auch nur so abstrakt wie möglich von der Fachlogik wissen und nicht von zig Projekten tausende Seiten Spezifikation lesen müssen.
Bei Pipelines (in meinem Fall Jenkinsfiles) verhält es sich so ähnlich, wobei ich hier die Entwickler noch mehr in der Pflicht sehe. Ich hab da zwar viel Pionierarbeit bei uns im Haus geleistet, da es in meinem Sinne ist, dass der Bauprozess in Code gegossen ist, aber wenn alles irgendwo schon mal gelöst wurde, soll sich der Entwickler bitte daran orientieren und bei nötigen Erweiterungen mal selbst die Suchmaschine bemühen.

Im Kern sollen sich alle zum gleichen Ziel bekennen, nämlich die Software des Hauses effizient herzustellen und an den Mann zu bringen. Das geht am besten, wenn die Leute miteinander statt gegeneinander arbeiten. Am Ende des Tages ist es völlig egal, wer das Dockerfile geschrieben hat. Es ist Teil der Arbeit, die gemacht werden muss und jeder sollte nach seinen Stärken eingesetzt werden, ohne dadurch aber Silos entstehen zu lassen. Wenn der CI-Server rot ist, geht das alle an (denn es gibt oft technische Gründe wie CI-Server-Updates, die das verursachen und da muss dann Ops mit ran). Wenn das Produktiv-System abraucht, geht das im ersten Moment erst einmal alle an (denn es könnte die Folge defekter Anwendungslogik sein). Wenn der Code nicht kompiliert, weil die neusten Versionen der Abhängigkeiten nicht mehr kompatibel sind, dann ist das Sache der Entwickler. Gehen Pakete im Netzwerk verloren, weil ein Switch kaputt ist oder die Firewallkonfiguration daneben ist, dann ist das Sache von Ops.
 

RobertVox

Cadet 3rd Year
Ersteller dieses Themas
Dabei seit
Nov. 2016
Beiträge
44
Vielen Dank für die detaillierten Antworten!
Ich habe mir das überlegt und noch mehr darüber im Internet gelesen.

Frohe Weihnachten euch allen!
 

Airbag

Fleet Admiral
Dabei seit
Aug. 2008
Beiträge
12.116
Disclaimer: gestartet für 5y als Entwickler, seit 3y Ops, selbst immer in kleinen Unternehmen, aber durch Kunden auch Einblicke in größere gehabt. Ich finde meine Rolle in der international gängigeren Bezeichnung SRE gut beschrieben.

Ich hab schon verschiedene Ausprägungen davon gesehen. Meines Erachtens gibt es da ein paar Missverständnisse, die sich mancherorts mittlerweile etabliert haben. Nach meinem Verständnis bezeichnet DevOps ein mindset, also eine geistige Haltung, die man versuchen sollte, in seinem Team zu etablieren. Ziel ist es, den Graben zwischen Entwicklern (Dev) und Betrieb (Ops) zu überwinden. Es war nämlich lange Zeit so (und ist leider vielerorts immer noch so), dass seitens der Entwickler eher eine "Über-Den-Zaun-Werf"-Mentalität vorherrschte.
Das trifft es wohl am besten. Wir hatten vor ein paar Wochen Redhat im Haus gehabt und sie haben es ähnlich beschrieben. Eine quasi immer passende Umsetzungslösung wird es wohl kaum geben, da es sich oft vermischt, was ja zum Teil auch das Ziel ist.
 
Top