DevOps-Jobbezeichnungen, Rollen und Verantwortlichkeiten

Was steckt in einem Namen? Das ist eine Frage, die sich führende Tech-Forscher immer häufiger stellen, wenn sie das Phänomen DevOps betrachten. DevOps, ein Titel, der buchstäblich eine Bewegung repräsentiert, bei der Entwicklungs- und Betriebsteams zusammenarbeiten, anstatt miteinander zu streiten, hat in den letzten Jahren das Unternehmensökosystem als dominierende philosophische Strategie schnell gestört. Dennoch fühlen sich viele Geschäftsleiter verloren, wenn es darum geht, DevOps richtig umzusetzen, da es an klarer Richtung fehlt, wie man eine DevOps-Kultur schafft. Angesichts der manchmal verwirrenden Verwirrung, die DevOps umgibt, ist es keine Überraschung, dass es schwierig ist, einen Konsens über Titel und Rollen in DevOps zu finden, und oft hängt davon ab, wen man fragt. Heute werden wir Titel und Rollen im DevOps untersuchen, damit Sie besser verstehen können, wie es in Ihrer Organisation funktionieren könnte.

Über Titel und Rollen in DevOps

In den letzten zehn Jahren oder länger haben Unternehmensorganisationen zunehmend begonnen, eine breite Palette von Cloud-Komponenten zu integrieren, die die einstige Infrastruktur in Managed Services verwandelt haben. Dies führte zu einem Bedarf an einem besseren Verständnis zwischen Entwicklungsteams und Betriebsteams, das nur aus einer kohärenteren Kooperationskultur entstehen kann, und so entstand DevOps. Zu den Themen, die die DevOps-Community spalten, gehört, ob Titel einen DevOps-Schwerpunkt widerspiegeln sollten. Das Argument ist, dass DevOps ein Kulturwandel ist und die Zentralisierung auf wenige Personen der Vorstellung widerspricht, dass DevOps jedem gehört. Während ein DevOps-Titel auf jemanden hinweist, der die Notwendigkeit kooperativen Informationsaustauschs versteht – was immer gut ist, kann es auch potenziell schädlich sein. Kritiker der Verwendung des Begriffs "DevOps" in einem Titel sind der Meinung, dass dies dem kollaborativen, verantwortungsorientierten Geist der Philosophie widerspricht und vor Veraltung warnt, falls die Bewegung wie andere Technologietrends verläuft. Menschen dieser Denkrichtung glauben, dass DevOps keine Fähigkeit, sondern eine Denkweise ist. Im weiteren Kontext betrachten manche Organisationen DevOps lieber als Rollen. Andere Organisationen sehen den Bedarf an Rollen und Titeln, die diese Rollen erfüllen. Wie Titel und Rollen in einem DevOps-Unternehmen angewendet werden, hängt davon ab, was für die Organisation am sinnvollsten ist.

Titel, Rollen und Karriereweg

Nachdem wir nun besprochen haben, ob Organisationen das Wort DevOps in den Namenskonventionen für Titel, die mit diesem Karriereweg verbunden sind, verwenden sollten, werfen wir einen tiefen Blick darauf, wie dieser Weg aussieht. Hier sind einige Titel, die Sie in DevOps-Organisationen, großen wie kleinen, erwarten können:

• DevOps oder Platform Engineer
• Bauingenieur
• Zuverlässigkeitsingenieur
• Release Manager
• Datenanalyst
• Produktmanager

DevOps oder Platform Engineer

Je nachdem, auf welcher Seite der oben genannten Debatte eine Organisation steht, kann es sein, dass sie jemanden namens DevOps Engineer beschäftigt – oder auch nicht. Wenn nicht, hat die Organisation bei einem DevOps-Ansatz wahrscheinlich einen Platform Engineer, der die Infrastruktur der Plattform unterstützt, die aus interner Entwicklung und verschiedenen Managed Services besteht. Titel: DevOps Engineer oder Platform Engineer Rolle: DevOps Evangelist

Bauingenieur

Ein Build Engineer wird üblicherweise als Build and Release Engineer bezeichnet. Daher arbeitet der Build Engineer eng mit dem unten beschriebenen Titel Release Manager zusammen. Der Build Engineer ist dafür verantwortlich, sicherzustellen, dass Build- und Deployment-Anforderungen in einer schnelllebigen CI/CD-Umgebung erfüllt werden. Im Alltag übernimmt der Build Engineer Aufgaben wie das Management und die Wartung von Code, das Erstellen neuer Builds, die Standardisierung automatisierter Deployment, die Erfüllung der Konfigurationsanforderungen, Unterstützung bei Release Notes und mehr. Der Build Engineer kann in einer traditionellen DevOps-Organisation die Rolle des Automatisierungsorchestrators übernehmen. Diese Person ist auch dafür verantwortlich, die Bedeutung der Erwartungen der Nutzer zu verstehen und übernimmt möglicherweise einige der hybriden Aufgaben einer UX-Designer-Rolle. Diese Rolle übernimmt manchmal auch die Aufgaben eines Configuration Managers, wobei es je nach Organisation eine ganz andere Person sein kann. Titel: Build Engineer, UX Designer, Configuration Manager Rolle: Automatisierungsorchestrator, Softwaretester, Deployer von Releases

Release Manager

Ein Release Manager wird manchmal auch Release Engineer genannt. In diesem Fall lassen wir den Engineer-Teil absichtlich außen vor. Denken wir mal darüber nach. Das Wort Engineer impliziert, etwas Detailgenauigkeit, Wissen und Finesse zu orchestrieren. Es stimmt, dass die Organisation ständiger Releases für ein DevOps-Unternehmen eine ausgefeilte Orchestrierung erfordert, aber der Release Manager ist mehr als das. Der Release Manager sollte in erster Linie eine Management- und Aufsichtsposition sein, die ein tiefes Maß an praktischem Entwicklungswissen erfordert, um erfolgreich zu sein. Führung ist in dieser Rolle entscheidend. Zu den durchschnittlichen Aufgaben gehören nicht nur die Koordination mehrerer Releases und das Verständnis von CI/CD, sondern auch manchmal das Ausarbeiten von Entwicklungspipeline-Strategien und deren Koordinierung zwischen den Teams. Titel: Release Manager oder Release Engineer Rolle: Release Leader und Aufsicht

Standortzuverlässigkeitsingenieur

Der Site Reliability Engineer, auch bekannt als Reliability Engineer, ist die Person, die für die Qualität der Orchestrierung und Integration der Werkzeuge verantwortlich ist, die für den täglichen Betrieb benötigt werden. Dies ist die Quintessenz der Rolle, die einem einfällt, wenn Menschen zum ersten Mal an DevOps denken: der "Magier", der bestehende Infrastruktur meisterhaft mit Cloud- und Datenspeicherinfrastrukturen zusammenführt. Diese Rolle ist in jeder DevOps-Organisation wichtig, da ein Versäumnis, eine solide Integration sicherzustellen, zu kostspieligen Ausfällen führen kann. Titel: Site Reliability Engineer, Reliability Engineer Rolle: Sicherheitsingenieur, Multiple Systems Utilitarist

Datenanalyst

Ihr DevOps Data Analyst filtert und filtert Daten ab, um die Entwicklungsziele zu unterstützen. Als wesentliches Mitglied des Entwicklungsteams nutzt der Data Analyst bestehende Daten und Nutzerdaten, um kritisch über Muster nachzudenken, die die Benutzererfahrung und andere Designaspekte beeinflussen. Diese Person kann einige Überschneidungen mit den Aufgaben eines UX-Designers und QA-Analysten haben. Data Analyst wird oft als Einstiegsposition betrachtet, die Karrierewege in den Bereich Data Scientist einschließt. Titel: Data Analyst, QA Analyst Rolle: Der Data Whist

Produktmanager

Der Product Manager ist der einzige Titel auf dieser Liste, der in erster Linie operativ ist. Obwohl der oben erwähnte Release Manager einige Überschneidungen mit Entwicklung und Betrieb aufweist, handelt es sich dennoch größtenteils um eine Entwicklungsteam-Position. Als Mitglied des Betriebsteams ist der Product Manager dafür verantwortlich, mit dem Entwicklungsteam zusammenzuarbeiten, um sicherzustellen, dass die Anforderungen des Produkts bei jedem Sprint auf hohem Qualitätsstandard erfüllt werden. Titel: Product Manager Rolle: Product Perfection Assurance Es gibt einige Positionen in einer DevOps-Organisation, die in diesem Artikel aufgrund ihrer Überschneidungen mit den Aufgaben anderer oben genannten Titel nicht mit einem eigenen Inhaltsbereich hervorgehoben wurden. Diese sind:

• Konfigurationsmanager
• UX-Designer
• Data Scientist
• QA-Analyst

Einer der oben genannten Titel könnte ein Hinweis darauf sein, dass eine Organisation mit einer DevOps-Denkweise arbeitet. Wenn Sie einen Karriereweg im DevOps-Bereich anstreben und nach Organisationen suchen, für die Sie arbeiten können, schadet es nicht, zu fragen, ob sie DevOps-Praktiken anhängen.

Karrierewege in DevOps

Die meisten Technologiebereiche bieten einen klaren Karrierepfad, der wie ein Baum mit mehreren Zweigen aussieht, in dem jede Karriereentscheidung einen auf einen anderen Weg bringen oder einen neuen Weg eröffnen kann. Bei DevOps ist das nicht so klar. Vielleicht liegt es daran, dass DevOps eine Philosophie war, die natürlich entstand, als ehrgeizige Wissenssuchende nach der Einführung von Cloud-Technologie eine Lücke in ihren Organisationen füllten? Vielleicht liegt es daran, dass jeder so unterschiedlich an DevOps herangeht, dass wir uns nicht einmal darauf einigen können, wie man Titel strukturiert? Was auch immer der Grund ist, Informationen über einen Karriereweg innerhalb von DevOps sind relativ begrenzt. Bis heute gibt es keinen höheren Abschluss in DevOps, obwohl es viele Organisationen gibt, die bereit sind, Zertifizierungen für Best Practices anzubieten. Ein typischer DevOps-Weg beginnt wahrscheinlich am Arbeitsplatz, wenn Ihre Organisation beginnt, sich zu DevOps zu entwickeln, vielleicht sogar noch vorher, wenn Sie in eine DevOps-Rolle einsteigen, um voranzukommen. Wenn Sie DevOps nicht innerhalb einer Organisation praktizieren, können Sie Zertifikate an Hochschulen erwerben, um in diesem Bereich einzusteigen. Der durchschnittliche DevOps Engineer, der an der Spitze der DevOps-Pyramide steht, verdient im Durchschnitt knapp unter 92.000 Dollar pro Jahr. DevOps ist eine Bewegung mit viel Schwung. Wenn Ihre Organisation einen Wandel in der DevOps-Kultur in Erwägung zieht, kontaktieren Sie BMC. Als Top-Berater im DevOps-Bereich haben wir die richtigen Menschen und Werkzeuge, um Ihren Übergang schnell und mühelos zu gestalten. Nehmen Sie noch heute Kontakt mit uns auf .

DevOps-Leitfaden

1. Was ist DevOps? Eine umfassende Einführung
2. Eine kurze Geschichte von DevOps
3. Einführung in die DevOps-Architektur
4. Automatisierung in DevOps: Warum und wie man DevOps-Praktiken automatisiert
5. Was ist CI/CD? Kontinuierliche Integration und kontinuierliche Lieferung erklärt
6. Wie man eine CI/CD-Pipeline mit Jenkins aufbaut
7. DevOps-Metriken zur Optimierung von CI/CD-Pipelines
8. Kontinuierliche Liefermetriken
9. Ist Continuous Integration in Continuous Deployment ein Fortschritt – oder nicht?
10. Unterschiede zwischen Continuous Integration (CI), Delivery (CD) und Deployment
11. Quellcode und Versionskontrolle in DevOps
12. Was ist kontinuierliche Testung?
13. Testautomatisierungs-Frameworks: Der ultimative Leitfaden
14. Release Management in DevOps
15. Erklärt: Monitoring & Telemetrie in DevOps
16. Anwendungs-Leistungsmanagement in DevOps
17. DevOps-Orchestrierung im SDLC
18. Einführung in Datenbank-DevOps
19. Die Rolle der Microservices in DevOps
20. Die Rolle der Virtualisierung in DevOps
21. Container & DevOps: Wie Container in DevOps-Lieferpipelines passen
22. Was ist eine Containerpipeline?
23. Was ist eine DevOps-Toolchain?
24. Verwaltung von Containern und Code für DevOps
25. Die Rolle von Agile in DevOps
26. Die Rolle der Cloud in DevOps
27. Was ist FinDevOps?
28. Top-DevOps-Trends im Jahr 2022
29. DevOps-Werte & Prinzipien
30. DevOps-Kennzahlen und KPIs
31. DevOps-Ratschläge für kleine, mittlere und große Organisationen
32. DevOps-Teamstruktur
33. Top-DevOps-Bücher, die man heute lesen sollte
34. Buchrezension von The Phoenix Project: DevOps For Everyone
35. DevOps-Influencer: 11 DevOps-Experten, denen Sie auf Twitter folgen können
36. GitHub, GitLab, Bitbucket & Azure DevOps: Was ist der Unterschied?
37. Best Practices: Wie man Anwendungen für Kubernetes architekt
38. Konfigurationsmanagement in DevOps
39. DevOps-Verzweigungsstrategien erklärt
40. DevOps-Jobbezeichnungen, Rollen und Verantwortlichkeiten
41. Testen in DevOps: Konzepte, Best Practices und mehr
42. Der vollständige DevOps-Zertifizierungsleitfaden für 2022
43. Was ist das Kubernetes-Operator-Muster?

Diese Beiträge sind meine eigenen und spiegeln nicht unbedingt die Position, Strategien oder Meinung von BMC wider.