Warum sollte ich nicht versuchen, einen 'DevOps Engineer' einzustellen?

Die Idee, einen DevOps-Ingenieur zu haben, ist in letzter Zeit recht populär geworden , und es scheint ansprechend, nur eine Person zu haben, die in der Lage ist, viele der Vorteile von DevOps zu nutzen, wie im Puppet-Blog beschrieben :

Unternehmen, die DevOps-Praktiken anwenden, sind überaus leistungsfähig: Sie stellen Code bis zu 30-mal häufiger bereit als ihre Konkurrenten, und laut unserem Bericht zum DevOps-Status von 2015 schlagen 50 Prozent ihrer Bereitstellungen fehl.

Ich habe jedoch viel Widerspruch gegen die Idee eines DevOps-Ingenieurs bemerkt, der versucht, diese Verbesserungen vorzunehmen:

Trotz der weitgehenden Übereinstimmung mit den DevOps-Kernattributen wird der Begriff „DevOps-Ingenieur“ kontrovers diskutiert. Einige sagen, der Begriff selbst widerspreche den DevOps-Werten. Jez Humble, Mitautor von Continuous Delivery, weist darauf hin, dass die bloße Anrufung eines DevOps-Ingenieurs zusätzlich zu dev und ops ein drittes Silo schaffen kann - "... eindeutig eine schlechte (und ironische) Möglichkeit, diese Probleme zu lösen . "

Warum ist es für ein Unternehmen möglicherweise keine so gute Idee, einen DevOps-Ingenieur einzustellen, um zu versuchen, DevOps zu implementieren, im Gegensatz zu den organisatorischen Veränderungen, die von Blogs wie diesem befürwortet werden ? Werden die Vorteile durch eine isolierte DevOps-Rolle zunichte gemacht?

TL; DR : Sie sollten niemals versuchen, ein DevOps-Team einzustellen

Grundsätzlich gibt es drei am häufigsten zu besetzende Rollen:

1. DevOps Architekt / Evangelist
2. DevOps-Ingenieur
3. CI / CD-Ingenieur

Diese Rollen unterscheiden sich von Ihren 6 wesentlichen Softwareentwicklungsrollen, aus denen sich die Softwareentwicklungsorganisation traditionell zusammensetzt:

1. Produkt Management
2. Software-Entwicklung
3. Tools-Entwicklung
4. Sicherheit und Compliance
5. Qualität und Prüfung
6. Systembetrieb (SRE)

Gehen wir die drei Rollen einzeln durch und sehen, wie sie passen

DevOps Architekt oder Evangelist

• Warum : Wenn Sie verloren sind, langsam, kaputt und nicht wissen, was Sie tun sollen.
• Wann : Zu Beginn des Prozesses in der Planung.
• Was : Rolle auf Managementebene, um alle Manager und Leads in der gesamten Software-Engineering-Organisation zu leiten. Diese Person plant die gesamte Umwandlung Ihrer Engineering-Organisation in einen hoch funktionierenden Zustand.
• Wer : Beratendes Mitglied, das sich mit Theorie, Managementpraktiken, Kulturthemen und Abläufen auskennt und direkt an VP of Software Engineering berichtet.

In einigen Fällen und für kleinere und mittlere Unternehmen beginnen Sie den Prozess möglicherweise mit der Einstellung einer Beratungsorganisation wie DORA.

DevOps-Ingenieur

• Warum :
  1. Überbrückung der Lücken zwischen Teams, wenn diese nach den oben genannten funktionalen Rollen organisiert sind, um eine funktionsübergreifende Zusammenarbeit zu gewährleisten.
  2. Einbindung in produktorientierte Teams, zu denen jeweils 6 traditionelle Rollen gehören, um die Wissenslücken zu schließen und die Implementierung und Übernahme der neuartigen Praktiken und Tools zu unterstützen.
• Wann : Sobald Sie Ihre Pläne festgelegt haben und die organisatorische Umgestaltung beginnt und das gesamte Managementteam an Bord ist.
• Was : Ermöglichen Sie funktionsübergreifende Zusammenarbeit, stellen Sie sicher, dass Teamgrenzen aufgelöst werden, dass lokale Optimierungen innerhalb von Teams keine Barriere für einen hohen Arbeitsdurchsatz in der gesamten Wertschöpfungskette von Kundenwünschen bis hin zu Kundenlieferungen darstellen.
• Wer : Erfahrener Ingenieur mit Fähigkeiten sowohl in der Softwareentwicklung als auch im Systembetrieb. Er sollte sich mit den Best Practices, Prozessen und Kulturänderungen im Zusammenhang mit der DevOps-Transformation auskennen.

CI / CD-Ingenieur

• Warum : Um die Implementierung von CI / CD-Pipelines zu unterstützen, integrieren Sie Ihre Toolkette und bringen Sie die Tools ein, die eine bessere Arbeit des Unternehmens ermöglichen.
• Wann : Während des Übergangs in eine größere Organisation, während die oben genannten Rollen bereits besetzt wurden.
• Was : Ingenieur, der im Wesentlichen Teil des Tools-Teams ist, das in der Lage sein wird, CI / CD-Pipelines einzurichten und interne Systeme so zu integrieren, dass Reibungsverluste beim Arbeitsdurchsatz vermieden werden.
• Wer : Ingenieur mit Erfahrung in den Bereichen Tools, Integrationsprozess, Release Management und DevOps. Jemand, der versteht, dass er das menschliche Gating im Release-Prozess durch Automation ersetzt.

Ich würde DevOps Ingenieur argumentieren wie in Ihrem beschriebene Frage Link ist in erster Linie eine Rolle Sysadmin. Zitiere die Fähigkeiten hier als Hintergrund für diese Antwort:

Deine Kletterausrüstung.

• Starker Hintergrund in der Linux / Unix-Administration Erfahrung mit Automatisierung / Konfigurationsmanagement mit Puppet, Chef oder einem gleichwertigen Produkt
• Möglichkeit zur Verwendung einer Vielzahl von Open Source-Technologien und Cloud-Diensten (Erfahrung mit AWS erforderlich)
• Starke Erfahrung mit SQL und MySQL (auch NoSQL-Erfahrung ist von Vorteil, da wir auch Redis verwenden)
• Ein funktionierendes Verständnis von Code und Skript (PHP, Python, Perl und / oder Ruby)
• Kenntnisse über Best Practices und IT-Abläufe in einem stets verfügbaren Service

In dieser Beispieljobbeschreibung ist DevOps Engineer nur ein Modewort für einen Systemadministrator, der sich mit Cloud-basierter Infrastruktur und Automatisierung auskennt, in der Lage ist, Code zu lesen, um bei der Diagnose zu helfen, und sich der Hochverfügbarkeitspraktiken und -lösungen bewusst ist.

Dies hängt eng mit den DevOps-Praktiken und der Silo-Breaking-Kultur zwischen dev und op zusammen, wie in dieser Frage dargestellt. Worin besteht der Unterschied zwischen Sysadmin und DevOps Engineer?

Es wird keine gute Idee sein, weil ein Sysadmin, wie gut er / sie mit der Praxis und Kultur der Entwickler umgehen kann, nicht die richtige Person ist, um eine Unternehmenstransformation voranzutreiben. Sie werden diese Person nicht mit Blick auf einen Kulturwandel einstellen, sondern mit Blick auf eine Werkzeugkonfigurationsansicht, die nicht wirklich hilft, die Prozesse zu unterbrechen. Dies wird möglicherweise auch von seinen Kollegen schlecht aufgenommen, und Sie werden nur Widerstand gegen die Änderung leisten, wenn vorher keine Kulturänderung geplant ist

Die Antwort von @ Jiri Klouda gibt einen guten Überblick über eine akzeptable Rolle als DevOps-Ingenieur sowie über den Schritt in der Veränderung, der Wert bringt und zum Erfolg beiträgt.

Mir ist klar, dass diese Antwort möglicherweise nicht perfekt zu Ihnen passt, aber ich habe Folgendes getan

Ich war der erste Entwickler, der bei einem sehr geschäftigen E-Commerce-Startup mit unglaublich viel Verkehr arbeitete. Mir ist klar, dass das Unternehmen noch jung war und dass ich für eine Weile die einzige technische Inhouse-Ressource sein würde.

Da ich das wusste, beschloss ich, meine Infrastruktur so zu strukturieren, dass ich ZERO-Systemadministration durchführen musste.

Ich habe mich für ein Hosting in der Cloud entschieden, weil ich dadurch weniger Systemwartung hatte. Ich suchte einen AWS-Ingenieur mit Puppenerfahrung. Gemeinsam haben wir eine autoskalierbare Infrastruktur entwickelt, die als Code in Cloudformation geschrieben wurde. Alle Konfigurationsdateien wurden in Puppet versioniert.

Dies ermöglichte es mir als Entwickler, diese Rolle als Entwickler zu übernehmen. Ich habe Code-Release-Tools in Python und Fabric erstellt. Ich habe dasselbe Skript verwendet, um meine Anwendung auf neue Server zu booten, die automatisch skaliert werden.

Das hat sehr gut funktioniert und auch heute, drei Jahre später, mache ich noch keine Systemwartung. Wir haben einen Systemadministrator (denselben AWS-Ingenieur) für 10 Stunden im Monat, und ich versuche, seine Sprints so zu strukturieren, dass ich ihn nicht ärgere. Auf diese Weise respektiere ich seine Zeit und verwalte seine Sprints so gut ich kann.

Wenn ein System eine verminderte Leistung aufweist, beende ich es einfach und ein anderes dreht sich an seiner Stelle.

Ich hoffe, diese Antwort könnte Ihnen irgendwie nützen

Sie sollten keinen DevOps-Ingenieur einstellen, da DevOps so viele verschiedene Disziplinen umfasst, dass eine Person möglicherweise nicht in allen Aspekten dieser Disziplinen Experte sein kann. Wenn Sie einen Alleskönner einstellen, stellen Sie einen Meister von keinem ein.

DevOps ist unbedingt ein Team basierte Unterfangen , und Sie können möglicherweise nicht eine Person erwarten , die Erwartungen eines ganzen Teams zu unterstützen. Betrachten Sie den Umfang von DevOps. Eine Person kann unmöglich:

• Sei ein Rockstar Entwickler in [Sprache]
• Seien Sie ein Networking-Guru und kennen Sie alle erforderlichen RFCs
• Seien Sie ein erfahrener Systemadministrator
• Seien Sie ein erfahrener QS-Tester
• Seien Sie ein Datenbankadministrator
• Spezialisiert auf Speicherung und Sicherung
• Know Site Reliability Engineering
• Möglicherweise auch andere Disziplinen

In einigen der oben genannten Bereiche gibt es sogar Unterdisziplinen , z. B. Windows-Systemadministrator oder Linux / Unix-Systemadministrator, oder Sie verwenden in Ihrem System mehr als eine Codierungssprache.

Kein Mensch kann möglicherweise ein Experte in all dies, was bedeutet , dass , wenn Sie Adverting für einen DevOps Ingenieur, als der schwächste Bereich auf Ihrem DevOps Team Networking ist, führen Sie eine sehr gute Arbeit bei der Werbung für Ihre Notwendigkeit für eine Vernetzung nicht tun Spezialisten für Ihr DevOps- Team . Während keine Person einer bestimmten Rolle im DevOps-Team zugeordnet werden sollte, würden Sie Ihrem Team einen schlechten Dienst erweisen, indem Sie so tun, als gäbe es keine Spezialisten oder Fachexperten (KMU) im Bereich von DevOps. Das Pendel von einem Extrem zum anderen zu schwingen - vom Silo bis zum Vortäuschen, wie jede Rolle in Ihrem DevOps-Team das gleiche ist - kann ebenso viele Probleme verursachen.

Obwohl es gut ist, Teammitglieder in mehr als einer Disziplin zu trainieren - insbesondere in den überlappenden Bereichen -, ist es einfach keine Übung, von ihnen zu erwarten, dass sie in der Lage sind, ein so großes Wissensvolumen zu beherrschen.

Das bedeutet, dass jeder, der Ihnen sagt, dass er alle Aspekte von DevOps kennt, Sie wahrscheinlich anlügt. Stellen Sie einen Spezialisten in dem Bereich ein, in dem Sie am schwächsten sind und der in einem DevOps-Team gearbeitet hat - und keinen "DevOps-Ingenieur".

Genau diese Herausforderung hatte ich bei der Implementierung bei ASOS. Das Ziel für uns ist es, Teams zu haben, die sich selbst versorgen und daher eine bestimmte Rolle spielen können. Wir leben jedoch in der realen Welt und für viele Entwickler ist es nicht das Wichtigste, über gute DevOps-Praktiken nachzudenken. Deshalb brauchen sie Hilfe dahin kommen.

Was wir gemacht haben war:

• Die Amtszeit der DevOps-Ingenieure verlieren, DevOps ist etwas, das wir alle tun sollten, nicht unsere Berufsbezeichnung, deshalb haben wir sie etwas anderes genannt.

• Sie wurden auf Teams verteilt, aber nur auf 1 von 3. Dies bedeutete, dass sie kein Macher sein konnten, sondern als Kompetenz angesehen werden mussten, um Teams dabei zu helfen, sich selbst zu verbessern und ihre eigenen Probleme zu lösen (unter Anleitung).

• unterhielt auch eine zentrale Funktion als Kompetenzzentrum und kümmerte sich um die Überlegungen des Unternehmens, alles, was alle Teams betrifft

Während wir uns weiterentwickeln, überprüfen wir dieses Modell, aber für uns funktioniert es bislang effektiv

Ich denke nicht, dass Sie in der Lage sein werden, eine endgültige Antwort darauf zu bekommen, weil es so aussieht, als würden viele Dinge eine Rolle spielen.

• Wie an Bord ist das Unternehmen mit der DevOps-Praxis
• Welche Art von Anwendung oder Dienstleistung bietet das Unternehmen an?
• Die Struktur Ihres Unternehmens

Ich habe gerade ein Vorstellungsgespräch für eine Stelle abgeschlossen und einen Titel als DevOps-Ingenieur erhalten, aber ich arbeite unter anderem als Sys Admin. Dies ist aufgrund der Größe des Unternehmens und der Art der anwendungsbezogenen Verwaltung nur aus Gründen der Notwendigkeit erforderlich. Einige Positionen, für die ich ein Interview geführt habe, hatten einen ähnlichen Titel und sie suchten mehr jemanden von der Seite der Entwicklung, was Erfahrung angeht. Sie erwarteten mehr Schreiben von Code und keinen Systemadministrator, der Automatisierung betreibt. SRE scheint ein Titel zu sein, der an Popularität gewinnt, also könnte dies der richtige Weg sein. Ich hatte mich selbst als Systemadministrator und Automatisierungstechniker als letzten Job, da ich in der Regel mit dem Schreiben von Texten beschäftigt war und der Koch die meiste Zeit stapelt. Das Unternehmen verfolgte ein ziemlich gutes Devop-Modell, bei dem alle an Bord waren und die Entwickler neben den Einsatzkräften arbeiteten, aber ich denke, ihre Zukunft hat nicht geklappt.

Jetzt, da ich in dieser Position bin, versuche ich, Horn in irgendeiner Automatisierung zu beschlagen und wir haben einige Leuteprobleme, die wir aussortieren müssen. Menschen kommen und gehen und einige der Workflows wurden entworfen, weil es jemand anders so entworfen hat und nicht, weil es dazu passt, wie Menschen arbeiten.

Grundsätzlich denke ich, Sie sollten die Stellenbeschreibung herausfinden und sich nicht so viele Gedanken über den Titel machen, es sei denn, es ist gebunden, irgendwie zu zahlen, oder Sie denken, der eine oder andere würde die richtige Art von Leuten anziehen.

Wenn Sie sich mit der Bedeutung von DevOps befassen und einem "einen wahren Weg" folgen. Sie sollten keinen DevOps-Ingenieur einstellen. Sie sollten einen Automation Engineer, einen Deployment Engineer, einen Platform Architect oder eine Reihe anderer Rollen beauftragen, die genau das tun, was Sie benötigen.

Wenn es Ihnen nicht wichtig ist, ein echter DevOps-Praktiker zu sein, können Sie es so nennen, wie Sie möchten.