Was sind DevOps?

Aktuell ist dies nahezu die teuerste Position auf dem Markt. Der Hype um "DevOps"-Ingenieure übersteigt alle vorstellbaren Grenzen, und das gilt umso mehr für Senior DevOps-Ingenieure.
Ich arbeite als Leiter der Abteilung für Integration und Automatisierung, die englische Bezeichnung ist DevOps Manager. Spiegelt diese englische Bezeichnung unsere tägliche Arbeit wider? Wahrscheinlich nicht, aber die russische Variante ist in diesem Fall treffender. In meinem Beruf ist es natürlich erforderlich, zukünftige Mitglieder meines Teams zu interviewen, und im vergangenen Jahr habe ich etwa 50 Personen durch diese Gespräche geführt, während noch einmal so viele in den Vorkandidaten für meine Mitarbeiter herausgefiltert wurden.

Wir sind immer noch auf der Suche nach Kollegen, denn hinter dem Titel DevOps verbirgt sich eine sehr große Schicht verschiedener Ingenieure.

Alles, was unten steht, ist meine persönliche Meinung; Sie sind nicht verpflichtet, damit übereinzustimmen, aber ich gebe zu, dass es Ihren Blick auf das Thema beeinflussen könnte. Trotz des Risikos, in Ungnade zu fallen, veröffentliche ich meine Meinung, da ich denke, dass sie einen Platz hat.

Unternehmen haben unterschiedliche Vorstellungen davon, wer DevOps-Ingenieure sind, und kleben diesem Label häufig jedem an, um schnell Ressourcen zu finden. Die Situation ist ziemlich merkwürdig, da Firmen bereit sind, diesen Personen unrealistische Vergütungen zu zahlen, während sie in den meisten Fällen nur einen Tools-Administrator erhalten.

Wer sind also DevOps-Ingenieure?

Lassen Sie uns mit der Geschichte beginnen – Development Operations entstand als weiterer Schritt zur Optimierung der Zusammenarbeit in kleinen Teams, um die Produktgeschwindigkeit zu erhöhen. Die Grundidee war, das Entwicklungsteam mit Wissen über Prozesse und Ansätze im Management der Produktumgebung zu bereichern. Mit anderen Worten, ein Entwickler sollte verstehen, wie sein Produkt unter verschiedenen Bedingungen funktioniert, er sollte wissen, wie man sein Produkt bereitstellt und welche Umgebungsparameter angepasst werden müssen, um die Leistung zu steigern. So entstanden im Laufe der Zeit Entwickler mit einem DevOps Ansatz. DevOps-Entwickler schrieben Skripte für den Build- und Verpackungsprozess, um ihre Arbeit und die Funktionalität der Produktionsumgebung zu erleichtern. Die Komplexität der Lösungsarchitektur und das gegenseitige Zusammenspiel der Infrastrukturkomponenten begannen jedoch mit der Zeit, die Leistungskennzahlen der Umgebungen zu verschlechtern. Mit jeder Iteration wurde ein tieferes Verständnis für bestimmte Komponenten erforderlich, was die Produktivität des Entwicklers aufgrund zusätzlicher Anstrengungen zur Verständnisschaffung und Systemoptimierung für spezifische Aufgaben reduzierte. Die Kosten für den Entwickler stiegen, ebenso die Produktkosten, während die Anforderungen an neue Entwickler im Team sprunghaft anstiegen, da diese auch die Pflichten eines „Stars“ der Entwicklung übernehmen mussten; verständlicherweise wurden solche „Stars“ immer weniger verfügbar. Zudem möchte ich anmerken, dass aus meiner Erfahrung nur wenige Entwickler interessiert an den spezifischen Aspekten der Paketverarbeitung durch den Kernel des Betriebssystems, den Regeln der Paketweiterleitung und den Sicherheitsaspekten des Hosts sind. Ein logischer Schritt war daher, einen Administrator hinzuzuziehen, der damit vertraut ist, und ihm diese Aufgaben zu übertragen. Dank seiner Erfahrung konnten die gleichen Leistungskennzahlen zu geringeren Kosten im Vergleich zu den Kosten eines „Stars“ in der Entwicklung erreicht werden. Diese Administratoren wurden in das Team integriert, und seine Hauptaufgabe war das Management der Test- und Produktionsumgebungen gemäß den spezifischen Regeln des jeweiligen Teams sowie mit den für dieses Team bereitgestellten Ressourcen. So entstanden letztlich die DevOps im Verständnis der meisten.

Im Laufe der Zeit begannen diese Systemadministratoren zunehmend, die spezifischen Anforderungen ihres Entwicklungsteams zu verstehen. Sie lernten, wie sie das Leben für Entwickler und Tester erleichtern konnten, wie sie Updates erfolgreich einspielen und vermeiden konnten, am Freitagabend im Büro zu bleiben, um Deployments zu reparieren. Mit der Zeit wurden Systemadministratoren zu den wahren Experten, die die Wünsche der Entwickler erfassten. Um die Auswirkungen zu minimieren, wurden Verwaltungstools integriert, und alle erinnerten sich an bewährte Isolationstechniken auf Betriebssystemebene, die die Sicherheitsanforderungen, die Netzwerkverwaltung und die gesamte Hostkonfiguration optimierten, wodurch die Anforderungen an die neuen „Experten“ gesenkt wurden.

Eine "bemerkenswerte" Erfindung ist aufgekommen – Docker. Warum bemerkenswert? Weil die Erstellung von Isolierungen in chroot oder jail, sowie mit OpenVZ, ein umfangreiches Wissen über das Betriebssystem erforderte. Mit dieser praktischen Lösung können Sie jedoch ganz einfach eine isolierte Anwendungsumgebung auf einem Host mit allem Notwendigen schaffen und die Kontrolle wieder an die Entwickler übergeben, während der Systemadministrator sich ausschließlich um einen einzigen Host kümmert, um dessen Sicherheit und hohe Verfügbarkeit zu gewährleisten – eine logischere Vereinfachung. Aber der Fortschritt bleibt nicht stehen, und die Systeme werden zunehmend komplexer, mit immer mehr Komponenten. Ein einzelner Host genügt nicht mehr den Anforderungen des Systems, weshalb Cluster aufgebaut werden müssen. Hierbei kehren wir wieder zu den Systemadministratoren zurück, die in der Lage sind, solche Systeme zu konstruieren.

Mit jeder Iteration entstehen verschiedene Systeme, die die Entwicklung und/oder Administration vereinfachen. Es entstehen Orchestrierungssysteme, die bis zu dem Punkt einfach zu bedienen sind, an dem man von den Standardprozessen abweichen muss. Auch die mikroservices Architektur wurde eingeführt, um all das oben Beschriebene zu vereinfachen – weniger Wechselwirkungen, einfacher zu verwalten. In meiner Erfahrung habe ich nie eine vollständig mikroservices Architektur gesehen; ich würde sagen, es ist 50 zu 50 – 50 Prozent Mikroservices, schwarze Boxen, die Informationen verarbeiten, und die anderen 50 Prozent sind monolithisch fragmentierte Systeme, deren Dienste ohne die anderen Komponenten nicht unabhängig funktionieren können. All dies schränkt wiederum das Wissen sowohl von Entwicklern als auch von Administratoren ein.

Solche 'Schaukelbewegungen' im Expertenwissen über bestimmte Ressourcen halten bis heute an. Aber das führt uns etwas ab vom Thema; es gibt viele Aspekte, die es zu beleuchten gilt.

Build Engineer/Release Engineer

Hochspezialisierte Ingenieure, die als Mittel zur Standardisierung der Software-Bauprozesse und deren Bereitstellung entstanden sind. Im Zuge der Einführung von Agile schien es, als würden sie an Bedeutung verlieren, jedoch ist das keineswegs der Fall. Diese Spezialisierung entstand, um genau die Standardisierung der Softwareentwicklung und -liefermengen in einem industriellen Maßstab zu ermöglichen, d.h. durch die Anwendung gängiger Techniken für alle Produkte des Unternehmens. Mit dem Aufkommen von DevOps haben Entwickler teilweise Funktionen verloren, da sie nun selbst für die Vorbereitung des Produkts zur Auslieferung verantwortlich sind. Angesichts der sich verändernden Infrastruktur und der Ausrichtung auf eine maximal schnelle Lieferung ohne Rücksicht auf die Qualität hat sich dies im Laufe der Zeit in ein Hindernis für Veränderungen verwandelt, denn das Festhalten an Qualitätsstandards verlangsamt zwangsläufig die Bereitstellung. So wurde schrittweise ein Teil der Aufgaben der Build-/Release-Ingenieure auf die Schultern der Systemadministratoren übertragen.

Ops sind so vielfältig

Wir machen weiter und erneut zwingt uns ein breites Spektrum an Aufgaben und der Mangel an qualifiziertem Personal zur strikten Spezialisierung. Wie Pilze nach dem Regen entstehen verschiedene Operations:

• TechOps – Systemadministratoren, auch bekannt als HelpDesk Engineer
• LiveOps – Systemadministratoren, die hauptsächlich für produktive Umgebungen zuständig sind
• CloudOps – Systemadministratoren, die sich auf öffentliche Clouds wie Azure, AWS, GCP usw. spezialisiert haben
• PlatOps/InfraOps/SysOps – Systemadministratoren für Infrastruktur.
• NetOps – Netzwerkadministratoren
• SecOps – Systemadministratoren, die sich auf Informationssicherheit spezialisiert haben – PCI-Compliance, CIS-Compliance, Patching usw.

DevOps – eine Person, die alle Phasen des Entwicklungszyklus versteht – Entwicklung, Test, Produktarchitektur, in der Lage Risiken im Bereich Sicherheit zu bewerten, vertraut mit Ansätzen und Automatisierungstools auf zumindest hohem Niveau und darüber hinaus auch vor- und nachgelagerte Produktunterstützung versteht. Eine Person, die sowohl als Anwalt für die Betriebs- als auch für die Entwicklungsseite fungiert und so eine gute Zusammenarbeit zwischen diesen beiden Säulen ermöglicht. Verstehend die Arbeitsplanung durch Teams und das Management der Kunden Erwartungen.

Um solche Aufgaben und Verantwortlichkeiten zu erfüllen, muss die betreffende Person über Mittel verfügen, um nicht nur die Entwicklungs- und Testprozesse, sondern auch das Infrastrukturmanagement des Produkts sowie die Ressourcenplanung zu steuern. DevOps kann in diesem Verständnis weder im IT- noch im R&D-Bereich oder sogar im PMO angesiedelt sein; er sollte in allen diesen Bereichen Einfluss haben — als technischer Direktor des Unternehmens, Chief Technical Officer.

Gilt das auch für Ihr Unternehmen? — Ich bezweifle es. In den meisten Fällen gehört es entweder zur IT oder zum R&D.

Ein Mangel an Ressourcen und die Unfähigkeit, auch nur einen dieser drei Arbeitsbereiche zu beeinflussen, wird dazu führen, dass die Problematik dorthin verschoben wird, wo diese Änderungen einfacher umgesetzt werden können, zum Beispiel die Anwendung technischer Einschränkungen bei Releases aufgrund von "schmutzigem" Code laut den Berichten statischer Analysesysteme. Das bedeutet, wenn das PMO eine strenge Frist für die Veröffentlichung von Funktionen festlegt, kann die Forschung und Entwicklung (R&D) kein qualitativ hochwertiges Ergebnis innerhalb dieser Frist liefern und gibt ab, was sie kann, wobei das Refactoring auf später verschoben wird. DevOps, das sich auf IT bezieht, blockiert dann durch technische Mittel das Release. Ein Mangel an Befugnissen zur Veränderung der Situation führt im Fall verantwortlicher Mitarbeiter zu einer Überverantwortung für Dinge, die sie nicht beeinflussen können, besonders wenn diese Mitarbeiter die Fehler erkennen und wissen, wie man sie behebt – „Glück liegt im Unwissen“, was wiederum zu einem Burnout und dem Verlust dieser Mitarbeiter führt.

Der Markt für DevOps-Ressourcen

Lassen Sie uns einige Stellenangebote für die Position DevOps von verschiedenen Unternehmen betrachten.

Wir sind bereit, Sie zu treffen, wenn Sie:

1. Zabbix beherrschen und wissen, was Prometheus ist;
2. Iptables;
3. Ein BASH-Aspirant;
4. Ein Ansible-Professor;
5. Ein Linux-Guru;
6. Sie sind in der Lage, Debugging zu nutzen und zusammen mit Entwicklern Probleme in Anwendungen (PHP/Java/Python) zu identifizieren;
7. Routing macht Ihnen keine Angst;
8. Sie legen großen Wert auf die Sicherheit des Systems;
9. Sie sichern alles und erfolgreich wiederherstellen;
10. Sie wissen, wie man das System so konfiguriert, dass man das Maximum aus dem Minimum herausholt;
11. Sie richten Replikationen vor dem Schlafengehen in Postgres und MySQL ein;
12. CI/CD-Konfiguration und -Anpassung sind für Sie eine Notwendigkeit wie Frühstück/Mittagessen/Abendessen.
13. Sie haben Erfahrung mit AWS;
14. Sie sind bereit, mit dem Unternehmen zu wachsen;

Also:

• von 1 bis 6 - Systemadministrator
• 7 - ein wenig Netzwerkadministration, was auch im Bereich Systemadministration auf Middle-Niveau fällt
• 8 - ein wenig Sicherheit, was für einen Systemadministrator auf Middle-Niveau unerlässlich ist
• 9-11 - Middle System Administrator
• 12 - Je nach den gestellten Aufgaben entweder Middle System Administrator oder Build Engineer
• 13 - Virtualisierung - Middle System Administrator oder CloudOps, mit erweiterten Kenntnissen speziell über die Dienste einer bestimmten Plattform, um Ressourcennutzung zu optimieren und die Wartungsbelastung zu reduzieren und sogar Plattformen, um finanzielle Mittel effizient zu nutzen und die Wartungsbelastung zu reduzieren

Zusammenfassend lässt sich sagen, dass die Kandidaten für diese Stelle mindestens auf Middle/Senior System Administrator-Niveau sein sollten.

Übrigens sollte man die Admins nicht zu stark in Linux/Windows unterteilen. Ich verstehe, dass sich die Services und Systeme dieser beiden Welten unterscheiden, aber die Grundlagen sind bei allen gleich. Jeder respektable Administrator sollte mit beiden vertraut sein, und selbst wenn er es nicht ist, sollte es einem kompetenten Admin leicht fallen, sich einzuarbeiten.

Betrachten wir eine andere Stelle:

1. Erfahrung im Aufbau von hochbelastbaren Systemen;
2. Ausgezeichnete Kenntnisse in Linux-Betriebssystemen, allgemeiner Systemsoftware und Web-Stacks (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
3. Erfahrung mit Virtualisierungssystemen (KVMVMWare, LXC/Docker);
4. Beherrschung von Skriptsprachen;
5. Verständnis der Funktionsweise von Netzwerken und Netzwerkprotokollen;
6. Verständnis der Prinzipien für den Aufbau von ausfallsicheren Systemen;
7. Selbstständigkeit und Initiative;

Wir analysieren:

• 1 — Senior System Administrator
• 2 — Je nach Bedeutung, die diesem Stack beigemessen wird — Middle/Senior System Administrator
• 3 — Berufserfahrung kann auch bedeuten — „Ich habe Cluster nicht erstellt, aber virtuelle Maschinen angelegt und verwaltet, hatte einen Docker-Host, Zugang zu Containern“ — Middle System Administrator
• 4 — Junior Systemadministrator — ja, ein Administrator, der nicht in der Lage ist, grundlegende Automatisierungsskripte zu schreiben, unabhängig von der Sprache, ist kein Administrator — ein Einsteiger.
• 5 — Middle Systemadministrator
• 6 — Senior Systemadministrator

Zusammenfassend — Middle/Senior Systemadministrator

Noch eine:

1. Erfahrung in DevOps;
2. Erfahrung mit der Nutzung eines oder mehrerer Produkte zur Gestaltung von CI/CD-Prozessen. GitLab CI wäre von Vorteil;
3. Arbeit mit Containern und Virtualisierung; Wenn Sie Docker verwendet haben – gut, aber wenn Sie k8s genutzt haben – hervorragend!
4. Erfahrung in einem Agile-Team;
5. Kenntnis einer Programmiersprache;

Lass uns sehen:

• 1 — Hmm… Was meinen die Leute damit? =) Wahrscheinlich wissen sie selbst nicht, was dahintersteckt.
• 2 — Build Engineer
• 3 — Middle Systemadministrator
• 4 — Soft Skills, werden wir vorerst nicht betrachten, obwohl Agile eine weitere Sache ist, die je nach Bequemlichkeit interpretiert wird.
• 5 — Zu vage — das kann eine Skriptsprache oder eine kompilierte Sprache sein. Interessant, würde es zählen, wenn ich in der Schule auf Pascal und Basic programmiert habe? =)

Ich möchte auch einen Kommentar zu Punkt 3 abgeben, um das Verständnis dafür zu stärken, warum dieser Punkt von einem Systemadministrator abgedeckt wird. Kubernetes ist lediglich eine Orchestrierung, ein Werkzeug, das direkte Befehle an die Netzwerktreiber und Virtualisierungs-/Isolationshosts mit einigen Befehlen verpackt und eine abstrakte Kommunikation mit ihnen ermöglicht, das ist alles. Nehmen wir zum Beispiel das 'Build-Framework' Make, das ich, um es klarzustellen, nicht als Framework betrachte. Ja, ich kenne den Trend, Make überall dort einzusetzen, wo es nötig und unnötig ist – beispielsweise Maven in Make zu verpacken, ernsthaft?
Im Grunde genommen ist Make einfach eine Hülle um die Shell, die insbesondere die Kompilierungs-, Link- und Kompilierungsumgebungsbefehle vereinfacht, genauso wie k8s.

Einmal habe ich einen jungen Mann interviewt, der k8s in seiner Arbeit über OpenStack genutzt hat, und er erzählte mir, wie er Dienste darauf bereitgestellt hat. Als ich jedoch konkret nach OpenStack fragte, stellte sich heraus, dass es ebenso von Systemadministratoren verwaltet wird. Glauben Sie wirklich, dass jemand, der OpenStack unabhängig von der Plattform, die er dafür nutzt, eingerichtet hat, nicht in der Lage ist, k8s zu verwenden? =)
Dieser Bewerber ist tatsächlich kein DevOps, sondern ein Systemadministrator, genauer gesagt ein Kubernetes-Administrator.

Zusammenfassend wird ein Middle/Senior Systemadministrator ausreichend sein.

Wie viel in Gramm wiegen

Die Gehaltsbandbreite für die angegebenen Stellen variiert zwischen 90k und 200k.
Jetzt möchte ich eine Verbindung zwischen den finanziellen Belohnungen von Systemadministratoren und DevOps-Engineers herstellen.

Im Prinzip kann man die Erfahrungsgrade grob einteilen, auch wenn das nicht ganz genau ist; für die Zwecke des Artikels sollte das ausreichen.

Erfahrung:

1. bis zu 3 Jahren — Junior
2. bis zu 6 Jahren — Middle
3. mehr als 6 Jahren — Senior

Die Job-Website bietet an:
Systemadministratoren:

1. Junior — 2 Jahre — 50k Rub.
2. Middle — 5 Jahre — 70k Rub.
3. Senior — 11 Jahre — 100k Rub.

DevOps-Engineers:

1. Junior — 2 Jahre — 100k Rub.
2. Middle — 3 Jahre — 160k Rub.
3. Senior — 6 Jahre — 220k Rub.

Für die Erfahrung der "DevOps"-Kandidaten wurde jegliche Erfahrung verwendet, die in irgendeiner Weise den SDLC berührt.

Daraus folgt, dass Unternehmen in der Tat keine DevOps-Profile benötigen und dass sie mindestens 50 Prozent ihrer ursprünglich geplanten Ausgaben sparen könnten, wenn sie stattdessen einen Administrator einstellen würden. Darüber hinaus könnten sie die Aufgaben des gesuchten Mitarbeiters klarer definieren und schneller auf ihren Bedarf reagieren. Es sollte auch nicht vergessen werden, dass eine klare Trennung der Verantwortlichkeiten die Anforderungen an das Personal senkt und eine angenehmere Atmosphäre im Team schafft, da Überschneidungen vermieden werden. In den meisten Stellenanzeigen sind zahlreiche Werkzeuge und DevOps-Kennzeichnungen zu finden, die jedoch nicht auf echten Anforderungen an einen DevOps Engineer basieren, sondern lediglich nach einem Tool-Administrator suchen.

Der Schulungsprozess für DevOps-Ingenieure ist ebenfalls nur auf eine Reihe spezifischer Aufgaben und Tools beschränkt und vermittelt kein umfassendes Verständnis für die Prozesse und deren Abhängigkeiten. Es ist zwar beeindruckend, wenn jemand mit Terraform innerhalb von 10 Minuten ein AWS EKS mit einem Fluentd Sidecar in diesem Cluster und einem AWS ELK-Stack für das Logging in einer einzigen Konsolenzeile bereitstellen kann, jedoch wird diese Person, die das Prinzip der Logverarbeitung und deren Notwendigkeit nicht versteht und nicht weiß, wie man Metriken sammelt und die Serviceverschlechterung überwacht, letztendlich nur ein kniffliger Techniker sein, der einige Werkzeuge benutzen kann.

Die Nachfrage erzeugt jedoch das Angebot, und wir sehen einen extrem überhitzten Markt für die DevOps-Position, wo die Anforderungen nicht der tatsächlichen Rolle entsprechen, sondern lediglich Systemadministratoren ermöglichen, mehr Geld zu verdienen.

Wer sind sie also? DevOps oder gierige Systemadministratoren? =)

Wie geht es weiter?

Arbeitgeber sollten die Anforderungen präziser formulieren und genau die Personen suchen, die sie benötigen, anstatt mit Etiketten um sich zu werfen. Wenn Sie nicht wissen, was DevOps machen, dann werden Sie sie in diesem Fall auch nicht brauchen.

Mitarbeiter — Lernen. Ständig das Wissen erweitern, den Gesamtprozess im Blick behalten und den Weg zum festgelegten Ziel verfolgen. Man kann werden, was man will, man muss nur bereit sein, sich anzustrengen.

Quelle: habr.com