Ich habe gerade mit einem DevOps-Mann gesprochen, der einige wirklich gute Punkte über die Schwierigkeiten angesprochen hat, ein DevOps-Ingenieur zu sein und sich manchmal wie eine Ein-Mann-Armee zu fühlen, obwohl er in einem Team von 16 Ingenieuren ist.

Er trägt viele verschiedene Hüte, sitzt aber im Entwicklungsteam und erledigt Infrastrukturarbeiten. Er liebt die coole Technologie, mit der er arbeiten kann - mit einer Menge Automatisierung, Cloud, Containerisierung usw. Aber er kämpft darum, dass er die einzige Person opsin einem devTeam ist, die dies tut . Er berichtet an den Development Manager, arbeitet jedoch enger mit dem Infrastructure Manager zusammen.

Dies scheint bei vielen DevOps-Fachleuten der Fall zu sein, mit denen ich spreche. Was könnte getan werden, damit sich DevOps-Ingenieure weniger als Einzelgänger fühlen?

Mein erster Gedanke ist: "Warum ist er der einzige, der Operationen in einem Entwicklerteam ausführt, insbesondere, wenn er mit viel Automatisierung arbeitet?" Ich denke, es gibt eine Gelegenheit, das Lone-Wolf-Syndrom anzusprechen. Insbesondere in einer Entwicklungsumgebung bietet Infrastructure-as-Code einen hervorragenden Rahmen für die Lastverteilung. Die Mitarbeiter der Einsatzabteilung sollten Experten für die Ermittlung und Definition der Infrastrukturanforderungen für die Anwendung sein, sie sollten jedoch auch in der Lage sein, eine Plattform zu erstellen, auf der Entwicklerrollen so viel wie möglich unabhängig voneinander ausführen können.

Es klingt wie ein Silo in einem Team. alte Gewohnheiten sind schwer abzulegen. Ein Programmierer mag sich nicht wohl fühlen, wenn er einen Server hochfährt und härtet, aber in einem reinen Devop-Modell sollte er die Werkzeuge dazu haben. Eine Mitarbeiterin in einem Entwicklerteam sollte nicht für die Bereitstellung der Infrastruktur für die App selbst verantwortlich sein, sie sollte jedoch einen Einblick in die erforderlichen Aufgaben gewähren und eine Anleitung geben, wie die App-Entwickler dies selbst tun können. Es ist fast ein Meta-Infrastruktur-Modell. ops-ingenieure bauen eine infrastruktur auf, die auf anfrage des entwicklungsteams bei bedarf aufgebaut werden kann.

Beratung, Kommunikation und Verantwortungsübernahme sind entscheidend für den Erfolg eines Entwicklerteams.

Ich denke, der erste Fehler ist in diesem Satz:

Er berichtet an den Development Manager, arbeitet jedoch enger mit dem Infrastructure Manager zusammen.

DevOps ist eine kulturelle Veränderung, die darauf abzielt, Silos zu entfernen. Wenn noch Silos vorhanden sind, können Sie diesen Ingenieur nennen. Ein Ingenieur, der die operative Entwicklung betreibt, ein Automatisierungsexperte, ein Entwickler, der die Infrastruktur automatisiert - aber dieser Ingenieur ist kein DevOps-Ingenieur.
Tatsächlich ist "DevOps Engineer" keine echte Rolle , sondern eher ein "Chapeau", da es Entwickler, Systemadministratoren, QS-Tester und Architekten umfassen kann, die in einem gemeinsamen Team arbeiten.

Ein Problem, das ich oft sehe, ist, dass die Leute in den Modewortgebrauch von DevOps geraten und ihn als Jobtitel ansehen, aber sie verstehen nicht wirklich, was DevOps ist. Wenn sie DevOps auf diese Weise betrachten, sind sie oft isoliert und fühlen sich allein. Sie machen Fehler und Unzulänglichkeiten dafür verantwortlich, dass sie ein "einsamer Wolf" sind, ohne dass ein Buy-in für das Management und die Organisation erforderlich ist.

Wie Sie es beschreiben, ist dieser Ingenieur der einzige, der Operationen in einem Entwicklerteam ausführt. Das macht ihn nicht zum "DevOps-Ingenieur". (Was auch immer das in seiner Organisation bedeutet) Er arbeitet isoliert, weil der Job als "DevOps Engineer" präsentiert wird, aber es scheint, dass andere Leute in seinem Team nicht an Operationen arbeiten möchten.

Seien wir ehrlich, es wird immer ops und dev geben. Die Hauptidee hinter devops ist es, die Verantwortlichkeiten so zu teilen, dass es keine Übergabe eines Produkts von dev an ops oder nur die Bereitstellung einer Plattform durch ops für dev gibt. Das Hauptziel ist es, mehr Zusammenarbeit in ein Team zu bringen. Wenn Sie diese Rolle als "DevOps Engineer" bezeichnen, wird diese Idee durch den Vorschlag gebrochen, dass Sie beide Aufgaben mit demselben Fachwissen ausführen können - was selten der Fall ist.

Das erste, was meiner Meinung nach getan werden muss, ist, dem Team die operativen Tools vorzustellen, jedem ein Grundwissen über die Tools zu vermitteln und dann die Verantwortung für das Konfigurieren / Codieren der operativen Tools auf das gesamte Team zu übertragen. Die Hauptidee dahinter ist, sich von "demjenigen, der alle Aufgaben erledigt" zu "demjenigen, der das Team unterstützt und dem Team Verweise auf Implementierungen gibt" zu bewegen.

Dies ergänzt die anderen Antworten, indem in einem ersten Schritt auf einfachere Weise Maßnahmen ergriffen werden als bei einer Umstrukturierung des Managements.

Das Wichtigste für DevOps-Ingenieure in solchen Situationen ist, (a) Management-Engagement und (b) erforderliche Budgets zu erhalten . Lesen Sie weiter für mehr Details zu beiden ...

Holen Sie sich Management-Engagement

Sobald dies geschehen ist, wird es für solche DevOps-Ingenieure einfach. Besonders wenn Widerstand (von allen möglichen Parteien) ins Spiel kommt. Vertrauen Sie mir, es wird solchen Widerstand geben, der Herausforderungen wie:

• Warum müssen wir uns ändern? Ich möchte weitermachen, was ich schon seit X Jahren getan habe!
• Ich möchte nicht die (technische) Kraft verlieren, die ich habe, und alle Arten von Workflow-Vorgängen abschließen, um eine dumme Lösung in der Produktion zu finden, die 5 Minuten anstatt 5 Stunden (oder Tage ...) in Anspruch nehmen sollte.
• ... (Ich könnte hier noch ein Dutzend Kugeln hinzufügen ...).

Wann immer diese Herausforderungen auftauchen, sollte ein DevOps-Ingenieur nur sagen:

Es tut mir leid, ich mache nur meine Arbeit ... basierend auf Anweisungen des oberen Managements.

Erhalten Sie die erforderlichen Budgets

Ein effektiver Weg, um die erforderlichen Budgets zu erhalten, besteht darin, einen geeigneten Business Case zu erstellen / einzureichen, der die greifbaren und immateriellen Vorteile verschiedener DevOps-Praktiken erklärt, indem sie auf einige reale Fälle angewendet werden, die auf das Unternehmen selbst zutreffen.

Im Folgenden sind einige Beispiele aus der Praxis aufgeführt, die ich selbst als SCM-Berater bei einigen Unternehmen erlebt habe, bei denen diese Vorgänge stattgefunden haben. Ich weiß, ist SCM nur ein Teil des DevOps, aber es ist der Bereich , wo ich etwas Know - how ...

1. Vorteile der Automatisierung

Aufgrund einiger Streiks von nur 2 (!!!) Computer-Bedienern (die die Konsolenbefehle nicht mehr tippten, als sie erwartet wurden) mussten die Züge auf halbem Weg zwischen 2 Fabriken angehalten werden (da das System im Werk war) Wo der Zug ausfuhr, waren wichtige Daten zur Abfertigung des Zuges nicht verfügbar.

Durch die Implementierung eines SCM-Systems wurden viele Bedienerbefehle automatisiert.

2. Reduzieren Sie die Softwarelizenzkosten

Einige Softwareanbieter hatten beschlossen, die jährlichen Gebühren für die (veraltete) SCM-Software zu erhöhen, denen das Management nicht zugestimmt hatte. Dafür haben sie ein spezielles Projekt erstellt, um es durch eine alternative SCM-Software zu ersetzen.

Das Budget des Projekts entsprach der jährlichen Gebühr, die sie nicht weiter zahlen wollten. Dazu gehörte das Einfliegen von Ingenieuren aus anderen Kontinenten (wie mir), um das Projekt zum Erfolg zu führen.

3. Reduzieren Sie die Betriebskosten

Einige große Versicherungsunternehmen verwendeten FTP-Software, um Software-Fixes auf etwa 13.000 Midrange-Computer (AS / 400) im ganzen Land zu übertragen, und dies, sobald ein Fix verfügbar wurde. Die Kosten für eine solche Überweisung betrugen ungefähr 4 USD (13.000 x 4 = 52.000 USD für eine einzelne Überweisung ...). Die Software bestand aus 120.000 Komponenten, die von rund 150 Entwicklern entwickelt und gewartet wurden. Überlegen Sie, mit welcher Wahrscheinlichkeit 1 Entwickler 1 (winzigen) Fehler in einer dieser 120.000 Komponenten begangen hat, die es in die Produktion geschafft haben, und erforderten eine dringende Reparatur, die weitere 52.000 USD kosten würde (nur für den Transfer!).

Durch die Implementierung eines geeigneten SCM-Systems (mit verwalteten Testumgebungen, Genehmigungen usw.) konnte dieses Unternehmen eine erhebliche Kostenreduzierung erzielen. Überlegen Sie, wenn das SCM-System die Notwendigkeit von nur 20 Übertragungen von dringenden Korrekturen verhindern konnte, führte dies zu einer Kostenreduzierung von 52.000 x 20 = 1.040.000 USD (ein ziemliches Budget für die Implementierung eines SCM-Systems, das nur einen Bruchteil benötigte) von diesem Betrag, um die Arbeit zu erledigen).

4. Reduzieren Sie die Kosten für Nichtverfügbarkeit

Wenn die oben genannten Fälle nicht überzeugend genug sind, denken Sie daran, dass die Systeme eines großen Kreditkartenunternehmens auf der ganzen Welt nicht verfügbar sind. Mir wurde gesagt, dass 1 Sekunde Nichtverfügbarkeit sie 1.000.000 USD kostet.

Dies ist wahrscheinlich auch der Grund, warum solche Unternehmen schon seit vielen Jahrzehnten über ausgefeilte DevOps-Tools verfügen. Denn jede Sekunde, die sie nicht im Geschäft sind, kostet sie ein Vermögen.

TL; DR: Da das obere Management normalerweise launisch und anfällig für Wut ist, würde ich vorschlagen, seinen Geist ein wenig zu beugen, um eine andere Perspektive zu erhalten, während die Dinge allmählich zum Besseren verändert werden.

(Ich gehe davon aus, dass sein Problem ist in erster Linie mit dem widerstreb Devs , nicht seinen anderen ops Kollegen , die scheinen in erster Linie klassische Operationen zu tun.)

IMO, auch wenn Sie DevOps einsetzen, bedeutet dies nicht unbedingt, dass jeder Entwickler ein vollwertiger DevOps-Guru sein muss. Ich finde es ziemlich normal, dass es einen oder zwei echte Experten in einer bestimmten Gruppe von Menschen gibt und der Rest mehr oder weniger mitmacht. Solange die Arbeitsbelastung für diesen Kerl nicht zu groß ist und es ihm gelingt, sein Wissen in Skripten usw. zusammenzufassen, anstatt ein eigenes Silo zu bauen, ist das in Ordnung für mich.

Das eine, was nicht passieren sollte, ist, dass der DevOps-Typ seine Automatisierung ausführt, und alle anderen bemühen sich, diese Automatisierung zu vermeiden (dh über die CI / CD-Pipeline hinauszugehen und in einer der Umgebungen manuell zu arbeiten). Dies ist IMO die Hauptsache, die aufhören muss. Eine Lösung dafür wäre, sehr stark auf das Vieh-nicht-Haustier-Konzept zu drängen, dh VMs oder Container so schnell wie möglich nach links und rechts unerbittlich abzureißen und kontinuierlich neue hochzufahren.

Zweitens muss natürlich jeder wissen, was die Automatisierung tut, und zumindest theoretisch, mit einigem Herumgraben, in der Lage sein, die Automatisierungsmaschinerie zu starten (dh, wenn alles von einem Commit / Push ausgeht, dann die Entwickler) müssen sich der Tatsache bewusst und auf dem neuesten Stand sein, dass im Hintergrund Dinge passieren werden, wenn sie sich verpflichten). Die CI (/ CD) -Pipeline muss gut sichtbar sein und sollte allen bekannt sein (dh wenn ein Entwickler sie bricht).

Drittens muss der "Ein-Mann" natürlich darauf achten, dass er keine einfachen, alltäglichen Aufgaben für seine Kollegen erledigt (z. B. Dockerfile nach Dockerfile für ihre Artefakte erstellen ...).

Viertens müssen die Lösungen, die der Entwickler von DevOps erstellt, tatsächlich den manuellen Ansätzen der Vergangenheit in messbarer Weise überlegen sein . In diesem Fall sollte es ihm möglich sein, seine Verbesserungen zu demonstrieren . dh zeigen Sie, wie die Dinge für alle einfacher werden oder wie es unmöglich zu sein scheint, Fehler in späteren Phasen der Pipe usw. einzuführen. Wenn dies nicht möglich erscheint, muss der DevOps-Typ sich genau ansehen, was passiert er macht. Wenn es möglich ist, erfordert das Brownbag-Sitzungen und viel Evangelisierung in seinem Team.

Offensichtlich werden Sie in einer solch widerstrebenden Umgebung wahrscheinlich nicht in naher Zukunft zu einer vollständig automatisierten CD-Lösung oder einer stammbasierten Entwicklung kommen. Aber ich würde mir nicht allzu viele Sorgen darüber machen, herausgegriffen zu werden. Er ist der Experte, und wenn er seine Arbeit gut macht, wird sich das gesamte Team nach und nach verbessern.

Und schließlich, wenn es nach Jahren und Jahren der Mühe keine sichtbare Besserung bei seinen Kollegen gibt, ist es immer möglich, nach anderen Wegen zu suchen (sei es innerhalb oder außerhalb des Unternehmens). Die Erfahrung von DevOps ist heutzutage eine hervorragende Basis für die Jobsuche ...

Ich sehe hier viele großartige Antworten, wenn ich über DevOps als Kultur spreche, Vorschläge zur Zusammenarbeit mit dem Management und Hilfestellung bei der Definition der Vor- und Nachteile eines DevOps-Teams oder Ingenieurs. Ich denke, jeder von ihnen ist großartig, und wirklich anschaulich, dass viele Antworten zu 100% richtig und dennoch sehr unterschiedlich oder sogar völlig uneindeutig sind ... Das ist DevOps!

Diese Antwort ist nur meine einzigartige Perspektive aus Erfahrung und zeigt möglicherweise keine Normen oder Best Practices an ...

Was Ihr DevOps-Kollege jedoch bemängelt hat, ist die Art und Weise, in der DevOps herausfordernd und schwierig wird , insbesondere, wenn er zum DevOps-Ingenieur ernannt wird, und nicht nur eine kulturelle Denkweise.

Persönlich bin ich gerne ein Einzelgänger, weil ich immer noch wertvolle Beiträge leiste, aber auch meine eigenen Grenzen setze, während ich andere dazu überrede, sich selbst zu helfen, und mir dabei helfe, IT-Silos aufzubrechen.

Einige Silos bleiben intakt , und das ist in Ordnung. Es ist DevOps Mission, das zu umgehen und zu versuchen, diese Silos so unbedeutend oder unsichtbar wie möglich zu machen.

Es ist möglich, dass Ihr Mitarbeiter bemerkt oder noch nicht bemerkt hat, dass er oder sie es nicht mag, ein DevOps-Ingenieur zu sein .

Relativ gesehen ist das Konzept der Devops neu und definiert sich meiner Meinung nach immer noch. Momentan bin ich als Entwicklungsingenieur tätig. Für mich bedeutet dies, dass ich die Tools und Prozesse, die sowohl von unseren Entwicklerteams als auch von unseren Betriebsteams verwendet werden, vereinfache und weiterentwickle, damit sie sich auf das Produkt konzentrieren können, das für das Unternehmen Umsatz generiert. Die Ops und Dev Teams drehen ihre eigenen Server und wie benötigt. Ich schließe einfach das CI für unsere Produkte an, stelle sicher, dass unsere Prozesse sinnvoll sind, und suche, welche Prozesse verbessert / automatisiert werden können. Ich treffe mich mit all unseren Abteilungen, vom Vertrieb über das Lager bis hin zu Entwicklern und Betrieben (QS- und Release-Manager), um zu sehen, was sie tun und wie ich ihre Prozesse verbessern kann.

DevOps bedeutet für mich, dass die Entwicklung und der Betrieb eines Softwaresystems in die Verantwortung eines Teams fällt und nicht in getrennte Entwickler- und Betriebsteams. Dies ist eine Einbahnstraße. Die besten Teams bestehen aus " T-förmigen " Leuten, die Experten auf einem Gebiet sind und mit mehreren verwandten Gebieten vertraut sind.

• Von Teammitgliedern mit Ops-Erfahrung wird erwartet, dass sie das tun, was sie am besten können (z. B. Ops), die Grundlagen für das lehren, was sie am besten können (z. B. Ops) und in verwandten Bereichen (z. B. Entwicklungsaufgaben) lernen und arbeiten.
• Von Teammitgliedern mit Dev-Erfahrung wird erwartet, dass sie das tun, was sie am besten können (dh Dev), die Grundlagen für das vermitteln, was sie am besten können (dh Dev), und dass sie in verwandten Bereichen lernen und arbeiten (dh Ops-Aufgaben).

Damit sich der DevOps-Ingenieur weniger wie ein Einzelgänger fühlt, bitten Sie ihn, den Entwicklern das Betreiben der Systeme beizubringen , wobei er anerkennt, dass er der Experte für das Entwerfen der Infrastruktur ist.

Lassen Sie ihn von Anfang an in die Architektur auf hohem Niveau ein, damit er die Belange seiner Spezialität einbringen kann. (Bevor wir DevOps hatten, beschönigten unsere Architekturzeichnungen immer "Kleinigkeiten" wie Load Balancer und redundante Server. Jetzt sind solche Dinge Teil der allerersten Skizzen.)

Erwarten Sie von den Entwicklern, dass sie einige der alltäglichen Routineaufgaben übernehmen, um sowohl Redundanz im Team zu schaffen als auch die "Plackerei" -Jobs fair zu verteilen.

Erwarten Sie, dass er zur Entwicklung beiträgt, wenn keine ops-ähnlichen Aufgaben zu erledigen sind. Einige DevOps, von denen ich weiß, dass sie Datenbankarbeit als natürliche Erweiterung ihres Fachgebiets betrachten, sind sich nicht sicher, ob dies verallgemeinert werden kann.

Was könnte getan werden, damit sich DevOps-Ingenieure weniger als Einzelgänger fühlen?

In Anlehnung an - was kann ein DevOps Ingenieur tun sich / sich zu fühlen sich weniger wie ein einsamer Wolf?

Der Mangel an Kultur und Managementunterstützung ist nur ein Teil der Gleichung. Der andere Teil ist meiner Meinung nach, dass sich das Detailwissen von DevOps oft auf komplexe Zusammenhänge bezieht und es wichtig ist, Ratschläge zu haben und auf Arbeitsbeispiele zu verweisen.

Deshalb - fühle dich nicht wie ein einsamer Wolf; Beteilige dich an DevOps-Communities wie dieser hier oder an toolspezifischen Gruppen und GitHub - das Gefühl ist zumindest, dass du nicht der einzige einsame Wolf bist ;-)