Was sind DevOps?

Derzeit ist dies wohl die teuerste Position auf dem Markt. Das Interesse an „DevOps“ Ingenieuren überschreitet alle denkbaren Grenzen, und das gilt umso mehr für Senior DevOps Ingenieure.
Ich arbeite als Leiter der Abteilung für Integration und Automatisierung, erraten Sie die englische Abkürzung - DevOps Manager. Reflektiert die englische Abkürzung tatsächlich unsere alltägliche Tätigkeit? Wohl kaum, das russische Pendant trifft in diesem Fall besser zu. In meiner Funktion ist es natürlich notwendig, zukünftige Teammitglieder zu interviewen und im vergangenen Jahr sind rund 50 Personen durch meine Hände gegangen, ebenso viele wurden bereits im Vorfeld von meinen Mitarbeitern gescreent.

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

Alles, was im Folgenden geschrieben wird, ist meine persönliche Meinung, Sie sind nicht verpflichtet, mir zuzustimmen, ich erlaube mir jedoch, dass es Ihren Blick auf das Thema beeinflussen könnte. Trotz des Risikos, in Ungnade zu fallen, veröffentliche ich meine Meinung, weil ich der Meinung bin, dass sie Gehör finden sollte.

Die Unternehmen verstehen unterschiedlich, wer DevOps Ingenieure sind, und um schnell Personal zu rekrutieren, hängen sie dieses Label allen an. Die Situation ist ziemlich seltsam, da die Unternehmen bereit sind, diesen Personen unrealistische Belohnungen zu zahlen, in den meisten Fällen erhalten sie jedoch nur einen Administrator-Toolset-Experten dafür.

Wer sind also die DevOps Ingenieure?

Lassen Sie uns mit der Entstehungsgeschichte beginnen – Development Operations entstand als ein weiterer Schritt zur Optimierung der Zusammenarbeit in kleinen Teams, um die Produktionsgeschwindigkeit zu erhöhen, was eine erwartete Folge war. Die Idee war, das Entwicklungsteam mit Wissen über Verfahren und Ansätze im Management von Produktumgebungen zu stärken. Mit anderen Worten, der Entwickler muss verstehen und wissen, wie sein Produkt unter bestimmten Bedingungen funktioniert, er muss verstehen, wie man sein Produkt bereitstellt, welche Umgebungsmerkmale optimiert werden sollten, um die Leistung zu steigern. So traten über einen gewissen Zeitraum hinweg Entwickler mit DevOps-Ansatz auf. DevOps-Entwickler schrieben Skripte für den Build- und Verpackungsprozess, um ihre Tätigkeit und die Funktionalität der Produktionsumgebung zu vereinfachen. Die Komplexität der Lösungsarchitektur und die gegenseitige Beeinflussung der Infrastrukturkomponenten begannen jedoch im Laufe der Zeit, die Leistungskennzahlen der Umgebungen zu verschlechtern; mit jeder Iteration waren tiefere Kenntnisse über bestimmte Komponenten erforderlich, was die Produktivität der Entwickler durch den zusätzlichen Aufwand für das Verständnis von Komponenten und die Anpassung von Systemen an spezifische Aufgaben verringerte. Die eigenen Kosten des Entwicklers stiegen, die Kosten des Produkts ebenfalls, und die Anforderungen an neue Entwickler im Team schossen in die Höhe, da sie auch die Aufgaben der „Stars“ der Entwicklung erfüllen mussten, und natürlich wurden die „Stars“ immer weniger verfügbar. Es ist auch erwähnenswert, dass, meiner Erfahrung nach, nur sehr wenige Entwickler an den Details der Paketverarbeitung im Betriebssystemkern, den Regeln der Paketweiterleitung und den Sicherheitsaspekten des Hosts interessiert sind. Der logische Schritt war es, einen Administrator zu engagieren, der mit diesen Aspekten vertraut ist, und die Verantwortung für diese Art von Aufgaben ihm zu übertragen, was dank seiner Erfahrung die Erreichung derselben Kennzahlen zu geringeren Kosten im Vergleich zu den Kosten eines „Stars“ der Entwicklung ermöglichte. Solche Administratoren wurden ins Team integriert und ihre Hauptaufgabe war das Management von Test- und Produktionsumgebungen nach den spezifischen Regeln des jeweiligen Teams, mit Ressourcen, die diesem Team zugewiesen wurden. So entstanden tatsächlich die DevOps aus der Sicht der meisten.

Teilweise oder vollständig begannen im Laufe der Zeit die Systemadministratoren, die Bedürfnisse dieses speziellen Entwicklerteams zu verstehen, wie sie das Leben der Entwickler und Tester erleichtern können, wie sie ein Update bereitstellen können, ohne an einem Freitagabend im Büro bleiben zu müssen, um Deploymentsfehler zu beheben. Die Zeit verging, und nun wurden die Systemadministratoren zu den „Stars“, die verstehen, was die Entwickler wollen. Um die Auswirkungen zu minimieren, begannen Verwaltungstools, sich zu etablieren, und alle erinnerten sich an alte und zuverlässige Methoden zur Isolierung auf Betriebssystemebene, die es ermöglichten, die Sicherheitsanforderungen, die Verwaltung des Netzwerkteils und die Gesamtkonfiguration des Hosts zu minimieren und somit die Anforderungen an die neuen „Stars“ zu reduzieren.

Es entstand eine „wunderbare“ Sache — Docker. Warum wunderbar? Nur weil die Schaffung von Isolation in chroot oder jail, ebenso wie bei OpenVZ, umfangreiche Kenntnisse des Betriebssystems erforderte, während das entsprechende Tool es ermöglichte, auf einfache Weise eine isolierte Anwendungsumgebung auf einem Host mit all dem Notwendigen darin zu schaffen und die Kontrolle wieder an die Entwicklung zu übergeben, während der Systemadministrator nur für einen Host verantwortlich ist und dessen Sicherheit und hohe Verfügbarkeit gewährleistet — eine logische Vereinfachung. Doch der Fortschritt steht nicht still und die Systeme werden erneut immer komplexer, die Komponenten nehmen zu und ein einzelner Host genügt nicht mehr den Anforderungen des Systems, weshalb Cluster gebaut werden müssen. Wir kommen wieder zu den Systemadministratoren zurück, die in der Lage sind, diese Systeme zu erstellen.

Zyklus für Zyklus tauchen verschiedene Systeme auf, die die Entwicklung und/oder Administration erleichtern, es entstehen Orchestrierungssysteme, die, bis zu dem Punkt, an dem man vom Standardprozess abweichen muss, einfach zu bedienen sind. Die Microservices-Architektur entstand ebenfalls mit dem Ziel, alles oben Genannte zu vereinfachen — weniger Abhängigkeiten, einfacher in der Verwaltung. In meiner Erfahrung habe ich die vollständige Microservices-Architektur nicht erlebt, ich würde sagen 50 zu 50 — 50 Prozent Microservices, schwarze Boxen, was hineinkommt, wird verarbeitet, und die anderen 50 — ein zerfleddertes Monolith, Dienste, die nicht unabhängig von anderen Komponenten arbeiten können. All dies hat erneut die Anforderungen an das Wissensniveau sowohl der Entwickler als auch der Administratoren erhöht.

Solche „Schaukelbewegungen“ auf Expertenniveau in Bezug auf bestimmte Ressourcen dauern bis heute an. Aber wir haben uns ein wenig abgelenkt, es gibt zahlreiche Punkte, die es wert sind, beleuchtet zu werden.

Build Engineer/Release Engineer

Sehr spezialisierte Ingenieure, die als Mittel zur Standardisierung von Softwarebuilds und -Release-Prozessen entstanden sind. Mit der Einführung von Agile schienen sie zwar an Bedeutung zu verlieren, doch das ist nicht der Fall. Diese Spezialisierung entstand als Werkzeug zur Standardisierung genau der Softwareverteilung in industriellem Maßstab, d.h. durch Anwendung standardisierter Techniken für alle Produkte des Unternehmens. Mit dem Aufkommen von DevOps haben die Entwickler teilweise Funktionen verloren, da sie nun selbst die Produkte für die Lieferung vorbereiten. Angesichts der sich verändernden Infrastruktur und dem Ansatz, möglichst schnell ohne Rücksicht auf die Qualität zu liefern, sind sie im Laufe der Zeit eher zu einem Hemmnis für Veränderungen geworden, da die Einhaltung von Qualitätsstandards die Auslieferung unvermeidlich verlangsamt. So hat nach und nach ein Teil der Aufgaben der Build-/Release-Ingenieure auf die Schultern der Systemadministratoren übergegriffen.

Ops sind so unterschiedlich

Wir bewegen uns weiter und erneut drängt uns die Vielzahl an Aufgaben und der Mangel an qualifiziertem Personal zu einer strengen Spezialisierung. Wie Pilze nach dem Regen tauchen verschiedene Operations auf:

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

DevOps — (theoretisch) eine Person, die alle Prozesse des Entwicklungszyklus versteht — die Entwicklung, das Testen, die Architektur des Produkts versteht, in der Lage ist, Sicherheitsrisiken zu bewerten und mit Automatisierungsansätzen und -mitteln, zumindest auf hohem Niveau, vertraut ist, und die auch die Vor- und Nachbereitungsunterstützung des Produkts versteht. Eine Person, die sowohl als Anwalt der Operations als auch der Development fungieren kann, was eine günstige Zusammenarbeit zwischen diesen beiden Säulen ermöglicht. Sie versteht die Arbeitsplanung der Teams und das Management der Erwartungen des Auftraggebers.

Um solche Arbeiten und Pflichten auszuführen, muss diese Person über Mittel zur Verwaltung nicht nur der Entwicklungs- und Testprozesse, sondern auch der Verwaltung der Produktinfrastruktur sowie der Ressourcenplanung verfügen. DevOps kann in diesem Verständnis nicht nur in der IT, in R&D oder sogar in PMO angesiedelt sein, sondern sollte Einfluss in all diesen Bereichen haben — als technischer Direktor des Unternehmens, Chief Technical Officer.

Ist das in Ihrem Unternehmen so? — Ich bezweifle es. In den meisten Fällen ist es entweder IT oder R&D.

Ein Mangel an Ressourcen und die Möglichkeit, zumindest auf eines dieser drei Tätigkeitsfelder Einfluss zu nehmen, wird das Gewicht der Probleme in die Richtung verschieben, wo diese Änderungen einfacher umgesetzt werden können, wie beispielsweise technische Einschränkungen für die Releases aufgrund von „schmutzigem“ Code nach Angaben der statischen Analysewerkzeuge. Das bedeutet, wenn PMO einen strengen Termin für die Funktionalitätsveröffentlichung festlegt, kann R&D nicht rechtzeitig ein qualitativ hochwertiges Ergebnis liefern und liefert es, wie auch immer möglich, ab, wobei das Refactoring auf später verschoben wird; DevOps, das zur IT gehört, blockiert mit technischen Mitteln das Release. Ein Mangel an Befugnissen zur Änderung der Situation führt im Falle verantwortlicher Mitarbeiter zu einer übertriebenen Verantwortlichkeit für Dinge, die sie nicht beeinflussen können, besonders wenn diese Mitarbeiter die Fehler verstehen und sehen können und wissen, wie sie diese beheben können — „Glück in der Unwissenheit“ — und als Folge zu Burnout und dem Verlust dieser Mitarbeiter.

Markt für DevOps-Ressourcen

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

Wir sind bereit, Sie zu treffen, wenn Sie:

1. Zabbix beherrschen und wissen, was Prometheus ist;
2. Iptables;
3. BASH-Student;
4. Professor Ansible;
5. Linux-Guru;
6. Können Sie Debugging nutzen und gemeinsam mit Entwicklern Probleme in Anwendungen (php/java/python) finden?
7. Routing verursacht bei Ihnen keine Panik;
8. Sie legen großen Wert auf die Sicherheit des Systems;
9. Sie sichern „alles und jedes“ und stellen es erfolgreich wieder her;
10. Sie wissen, das System so zu konfigurieren, dass Sie aus dem Minimum das Maximum herausholen;
11. Sie konfigurieren Replikationen vor dem Schlafengehen in Postgres und MySQL;
12. Die Konfiguration und Anpassung von CI/CD ist für Sie ebenso notwendig wie Frühstück/Mittagessen/Abendessen.
13. Sie haben Erfahrung mit AWS;
14. Sie sind bereit, sich mit dem Unternehmen weiterzuentwickeln;

Also:

• von 1 bis 6 – Systemadministrator
• 7 – ein wenig Netzadministration, was ebenfalls zu einem Systemadministrator auf Mittelstufe gehört
• 8 – ein wenig Sicherheit, was für einen Systemadministrator auf Mittelstufe erforderlich 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 so genannter CloudOps, erweitertes Wissen über spezifische Dienste Hosting der Plattform, um Gelder effizient zu nutzen und die Wartungsbelastung zu reduzieren

Zusammenfassend lässt sich zu diesem Stellenangebot sagen, dass die Bewerber hauptsächlich ein Middle/Senior System Administrator sind.

Übrigens sollte man Administratoren nicht zu stark in Linux/Windows unterteilen. Ich verstehe natürlich, dass sich die Dienste und Systeme dieser beiden Welten unterscheiden, aber die Grundlage ist bei allen gleich, und jeder respektable Administrator ist sowohl mit dem einen als auch dem anderen vertraut. Selbst wenn er es nicht ist, wird es für einen kompetenten Administrator kein Problem sein, sich damit vertraut zu machen.

Betrachten wir eine andere Stelle:

1. Erfahrung im Aufbau von hochgradig belastbaren Systemen;
2. Ausgezeichnete Kenntnisse in Betriebssystemen Linux, allgemeiner Software und Web-Stacks (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
3. Erfahrung mit Virtualisierungssystemen (KVM, VMWare, LXC/Docker);
4. Beherrschung von Skriptsprache;
5. Verständnis der Arbeitsweise von Netzwerkprotokollen und -netzwerken;
6. Verständnis der Prinzipien des Aufbaus fehlertoleranter Systeme;
7. Selbstständigkeit und Initiative;

Wir analysieren:

• 1 – Senior System Administrator
• 2 – Je nach dem Sinn, der in diesen Stack gelegt wird – Middle/Senior System Administrator
• 3 – Erfahrung kann auch bedeuten: „Ich habe keine Cluster hochgefahren, aber virtuelle Maschinen erstellt und verwaltet, hatte einen Docker-Host und Zugang zu Containern“ – Middle System Administrator
• 4 — Junior System Administrator — ja, ein Admin, der nicht in der Lage ist, elementare Automatisierungsskripte zu schreiben, egal in welcher Sprache, ist kein Admin — ein Techniker.
• 5 — Middle System Administrator
• 6 — Senior System Administrator

Zusammenfassend — Middle/Senior System Administrator

Noch eine:

1. Erfahrung in der DevOps-Arbeit;
2. Erfahrung in der Verwendung eines oder mehrerer Produkte zur Erstellung von CI/CD-Prozessen. Gitlab CI wäre von Vorteil;
3. Arbeiten mit Containern und Virtualisierung; Wenn Sie Docker verwendet haben – gut, und wenn k8s – ausgezeichnet!
4. Erfahrung in einem agilen Team;
5. Kenntnis einer beliebigen Programmiersprache;

Lassen Sie uns sehen:

• 1 — Hm… Was meinen die Leute? =) Wahrscheinlich wissen sie selbst nicht, was sich dahinter verbirgt.
• 2 — Build Engineer
• 3 — Middle System Administrator
• 4 — Soft Skills, lassen wir vorerst beiseite, obwohl Agile eine weitere Sache ist, die so interpretiert wird, wie es bequem ist.
• 5 — Zu vage — das kann eine Skriptsprache oder eine kompilierte Sprache sein. Ich frage mich, ob sie es okay finden, dass ich in der Schule Pascal und Basic geschrieben habe? =)

Ich möchte auch eine Bemerkung zu Punkt 3 machen, um das Verständnis zu festigen, warum dieser Punkt vom Systemadministrator abgedeckt wird. Kubernetes ist lediglich eine Orchestrierung, ein Werkzeug, das direkte Befehle an Netzwerktreiber und Virtualisierungs-/Isolationshosts in ein paar Befehlen bündelt und die Kommunikation mit ihnen abstrakt macht, das ist alles. Nehmen wir als Beispiel das 'Build Framework' Make, das ich, um ehrlich zu sein, nicht als Framework betrachte. Ja, ich weiß von dem Trend, Make überall einzusetzen, wo es nötig und unnötig ist — Maven in Make zu verpacken, zum Beispiel, ernsthaft?
Im Grunde ist Make einfach eine Hülle um die Shell, die die Kompilierungsbefehle, Link-Befehle und die Kompilierungsumgebung vereinfacht, genauso wie k8s.

Einmal habe ich einen Typen interviewt, der k8s in seiner Arbeit über OpenStack verwendet hat, und er erzählte, wie er Dienste darauf bereitgestellt hat, als ich jedoch speziell nach OpenStack fragte, stellte sich heraus, dass er von Systemadministratoren verwaltet wird und genauso hochgefahren wird. Glauben Sie wirklich, dass eine Person, die OpenStack hochgefahren hat, egal welche Plattform sie dahinter benutzt, nicht in der Lage ist, k8s zu verwenden? =)
Dieser Bewerber ist in Wirklichkeit kein DevOps, sondern ein gewöhnlicher Systemadministrator, um genauer zu sein, Kubernetes Administrator.

Lassen Sie uns erneut zusammenfassen — Middle/Senior System Administrator genügt ihm.

Wie viel in Gramm aufhängen

Der Gehaltsbereich für die angegebenen Stellenangebote liegt zwischen 90k und 200k.
Jetzt möchte ich eine Verbindung zwischen den finanziellen Vergütungen von Systemadministratoren und DevOps-Engineers herstellen.

Prinzipiell kann man zur Vereinfachung die Grade nach Berufserfahrung aufteilen, auch wenn dies nicht genau sein wird, ist es für die Zwecke des Artikels ausreichend.

Erfahrung:

1. bis zu 3 Jahren — Junior
2. bis zu 6 Jahren — Middle
3. über 6 Jahren — Senior

Die Jobbörse bietet an:
Systemadministratoren:

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

DevOps-Engineers:

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

Für die Erfahrung von DevOps-Engineers wurde die Erfahrung verwendet, die in irgendeiner Weise den SDLC betrifft.

Aus dem oben Gesagten folgt, dass Unternehmen in Wirklichkeit keine DevOps-Engineers benötigen und dass sie mindestens 50 Prozent der ursprünglich geplanten Kosten einsparen könnten, wenn sie einen Administrator einstellen würden; zudem könnten sie die Aufgaben des gesuchten Mitarbeiters klarer definieren und schneller den Bedarf decken. Man sollte auch nicht vergessen, dass eine klare Trennung der Verantwortlichkeiten die Anforderungen an das Personal senken und eine bessere Atmosphäre im Team schaffen kann, da es keine Überschneidungen gibt. In den meisten Stellenangeboten strotzen die Anforderungen vor Tools und DevOps-Labels, die jedoch nicht wirklich Anforderungen an einen DevOps-Engineer beinhalten, sondern lediglich die Anfragen für einen Tool-Administrator.

Der Ausbildungsprozess für DevOps-Engineers ist ebenfalls nur auf eine Reihe spezieller Aufgaben und Tools beschränkt, was kein allgemeines Verständnis der Prozesse und deren Abhängigkeiten vermittelt. Es ist sicherlich beeindruckend, wenn eine Person mit Terraform in der Lage ist, AWS EKS in Verbindung mit Fluentd Sidecar in diesem Cluster und dem AWS ELK-Stack für das Logging-System in 10 Minuten mit nur einem Befehl in der Konsole zu deployen, aber wenn sie das Grundprinzip der Logverarbeitung und deren Notwendigkeit nicht versteht und nicht weiß, wie man Metriken darüber sammelt und die Dienstqualität überwacht, bleibt sie das gleiche „Einsteigermodul“, das einige Tools bedienen kann.

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

Also, wer sind sie? DevOps-Engineers oder habgierige Systemadministratoren? =)

Wie geht es weiter?

Arbeitgeber müssen ihre Anforderungen präziser formulieren und genau die Personen suchen, die sie benötigen, anstatt mit Labels um sich zu werfen. Wenn Sie nicht wissen, was DevOps macht, sind sie in diesem Fall nicht erforderlich.

Arbeitnehmer sollten lernen. Ständig ihr Wissen verbessern, die Gesamtzusammenhänge der Prozesse betrachten und den Weg zum gesetzten Ziel verfolgen. Man kann werden, was man will, man muss sich nur anstrengen.

Quelle: habr.com