Derzeit ist dies fast die teuerste Position auf dem Markt. Die Aufregung um „DevOps“-Ingenieure geht über alle erdenklichen Grenzen hinaus und ist bei Senior DevOps-Ingenieuren noch schlimmer.
Ich arbeite als Leiter der Integrations- und Automatisierungsabteilung, vermutlich die englische Dekodierung – DevOps Manager. Es ist unwahrscheinlich, dass das englische Transkript unsere täglichen Aktivitäten widerspiegelt, aber die russische Version ist in diesem Fall genauer. Aufgrund der Art meiner Tätigkeit ist es selbstverständlich, dass ich zukünftige Mitglieder meines Teams interviewen muss, und im letzten Jahr haben mich etwa 50 Personen durchlaufen, und ebenso viele wurden bei der Vorauswahl mit meinen Mitarbeitern abgeschnitten.
Wir sind immer noch auf der Suche nach Kollegen, denn hinter dem Label DevOps verbirgt sich eine sehr große Schicht unterschiedlicher Ingenieure.
Alles, was unten geschrieben steht, ist meine persönliche Meinung, Sie müssen ihr nicht zustimmen, aber ich gebe zu, dass es Ihrer Einstellung zum Thema etwas Farbe verleihen wird. Trotz der Gefahr, in Ungnade zu fallen, veröffentliche ich meine Meinung, weil ich glaube, dass sie einen Platz hat.
Unternehmen haben unterschiedliche Vorstellungen davon, wer DevOps-Ingenieure sind, und um schnell eine Ressource einstellen zu können, hängen sie jedem dieses Etikett an. Die Situation ist ziemlich seltsam, da Unternehmen bereit sind, diesen Personen unrealistische Vergütungen zu zahlen und in den meisten Fällen einen Tool-Administrator für sie zu erhalten.
Wer sind DevOps-Ingenieure?
Beginnen wir mit der Entstehungsgeschichte: Development Operations erschien als ein weiterer Schritt zur Optimierung der Interaktion in kleinen Teams, um die Geschwindigkeit der Produktproduktion zu erhöhen, wie erwartet. Die Idee bestand darin, das Entwicklungsteam durch Kenntnisse über Verfahren und Ansätze bei der Verwaltung der Produktumgebung zu stärken. Mit anderen Worten: Der Entwickler muss verstehen und wissen, wie sein Produkt unter bestimmten Bedingungen funktioniert, er muss verstehen, wie er sein Produkt einsetzt und welche Eigenschaften der Umgebung angepasst werden können, um die Leistung zu verbessern. So tauchten seit einiger Zeit Entwickler mit einem DevOps-Ansatz auf. DevOps-Entwickler haben Build- und Paketierungsskripte geschrieben, um ihre Aktivitäten und die Leistung der Produktionsumgebung zu vereinfachen. Allerdings begann die Komplexität der Lösungsarchitektur und die gegenseitige Beeinflussung der Infrastrukturkomponenten im Laufe der Zeit die Leistung der Umgebungen zu verschlechtern; mit jeder Iteration war ein immer tieferes Verständnis bestimmter Komponenten erforderlich, was die Produktivität des Entwicklers aufgrund des Mehraufwands verringerte Kosten für das Verständnis der Komponenten und Abstimmungssysteme für eine bestimmte Aufgabe. . Die eigenen Kosten des Entwicklers stiegen, mit ihnen auch die Kosten des Produkts, die Anforderungen an neue Entwickler im Team stiegen stark an, da sie auch die Verantwortung des Entwicklungs-„Stars“ abdecken mussten, und natürlich wurden die „Stars“ weniger und weniger verfügbar. Es ist auch erwähnenswert, dass meiner Erfahrung nach nur wenige Entwickler an den Besonderheiten der Paketverarbeitung durch den Betriebssystemkernel, den Paketroutingregeln und Hostsicherheitsaspekten interessiert sind. Der logische Schritt bestand darin, einen damit vertrauten Administrator zu gewinnen und ihm ähnliche Verantwortlichkeiten zuzuweisen, was es dank seiner Erfahrung ermöglichte, die gleichen Indikatoren zu geringeren Kosten im Vergleich zu den Kosten einer „Star“-Entwicklung zu erreichen. Solche Administratoren wurden in ein Team eingeteilt und seine Hauptaufgabe bestand darin, Test- und Produktionsumgebungen gemäß den Regeln eines bestimmten Teams zu verwalten und diesem bestimmten Team Ressourcen zuzuweisen. So entstand DevOps tatsächlich in den Köpfen der Mehrheit.
Mit der Zeit begannen diese Systemadministratoren teilweise oder vollständig zu verstehen, welche Bedürfnisse dieses spezielle Team im Bereich Entwicklung hat, wie sie Entwicklern und Testern das Leben erleichtern können, wie sie ein Update einführen können, ohne am Freitag über Nacht bleiben zu müssen im Büro und korrigiert Bereitstellungsfehler. Die Zeit verging und nun waren die „Stars“ Systemadministratoren, die verstanden, was die Entwickler wollten. Um die Auswirkungen zu minimieren, wurden Verwaltungsdienstprogramme entwickelt. Jeder erinnerte sich an die alten und zuverlässigen Methoden zur Isolierung der Betriebssystemebene, die es ermöglichten, die Anforderungen an Sicherheit, Verwaltung des Netzwerkteils und die Host-Konfiguration insgesamt zu minimieren insgesamt und reduzieren dadurch den Bedarf an neuen „Stars“.
Es ist etwas „Wunderbares“ aufgetaucht – Docker. Warum wunderbar? Ja, nur weil das Erstellen einer Isolation in einem Chroot oder Jail sowie in OpenVZ nicht triviale Kenntnisse des Betriebssystems erforderte. Im Gegensatz dazu können Sie mit dem Dienstprogramm einfach eine isolierte Anwendungsumgebung auf einem bestimmten Host erstellen, in der sich alles Notwendige befindet und zur Hand ist wieder die Zügel der Entwicklung in die Hand nehmen und der Systemadministrator kann nur noch mit nur einem Host auskommen und dessen Sicherheit und Hochverfügbarkeit gewährleisten – eine logische Vereinfachung. Aber der Fortschritt steht nicht still und die Systeme werden wieder immer komplexer, es gibt immer mehr Komponenten, ein Host entspricht nicht mehr den Anforderungen des Systems und es ist notwendig, Cluster zu bilden, wir kehren wieder zu den Systemadministratoren zurück, die es sind in der Lage, diese Systeme zu bauen.
Zyklus für Zyklus erscheinen verschiedene Systeme, die die Entwicklung und/oder Verwaltung vereinfachen, es erscheinen Orchestrierungssysteme, die einfach zu verwenden sind, bis Sie vom Standardprozess abweichen müssen. Die Microservice-Architektur erschien auch mit dem Ziel, alles oben Beschriebene zu vereinfachen – weniger Beziehungen, einfacher zu verwalten. Meiner Erfahrung nach habe ich keine vollständige Microservice-Architektur gefunden, ich würde sagen, 50 bis 50 – 50 Prozent der Microservices, Black Boxes, kamen rein und kamen verarbeitet wieder heraus, die anderen 50 sind ein zerrissener Monolith, Services, die nicht getrennt von anderen arbeiten können Komponenten. All dies führte erneut zu Einschränkungen des Wissensstands sowohl der Entwickler als auch der Administratoren.
Ähnliche „Schwankungen“ im Niveau des Expertenwissens über eine bestimmte Ressource dauern bis heute an. Aber wir schweifen ein wenig ab, es gibt viele Punkte, die es wert sind, hervorgehoben zu werden.
Build-Ingenieur/Release-Ingenieur
Sehr hochspezialisierte Ingenieure, die als Mittel zur Standardisierung von Software-Build-Prozessen und -Releases entstanden sind. Im Zuge der weit verbreiteten Einführung von Agile scheinen sie nicht mehr gefragt zu sein, aber das ist bei weitem nicht der Fall. Diese Spezialisierung erschien als Mittel zur Standardisierung der Zusammenstellung und Bereitstellung von Software im industriellen Maßstab, d. h. Verwendung von Standardtechniken für alle Produkte des Unternehmens. Mit dem Aufkommen von DevOps verloren Entwickler teilweise ihre Funktionen, da es die Entwickler waren, die damit begannen, das Produkt für die Auslieferung vorzubereiten, und angesichts der sich ändernden Infrastruktur und des Ansatzes, ohne Rücksicht auf die Qualität so schnell wie möglich zu liefern, wurden sie im Laufe der Zeit zu ein Stopper für Veränderungen, da die Einhaltung von Qualitätsstandards unweigerlich die Lieferungen verlangsamt. So wurde nach und nach ein Teil der Funktionalität der Build-/Release-Ingenieure auf die Schultern der Systemadministratoren verlagert.
Operationen sind so unterschiedlich
Wir ziehen weiter und immer wieder drängen uns das Vorhandensein einer großen Bandbreite an Verantwortlichkeiten und der Mangel an qualifiziertem Personal zu einer strengen Spezialisierung, so wie Pilze nach dem Regen verschiedene Operationen auftauchen:
- TechOps – Enikey-Systemadministratoren, auch bekannt als HelpDesk Engineer
- LiveOps – Systemadministratoren, die hauptsächlich für Produktionsumgebungen verantwortlich sind
- CloudOps – Systemadministratoren, spezialisiert auf öffentliche Clouds wie Azure, AWS, GCP usw.
- PlatOps/InfraOps/SysOps – Infrastruktursystemadministratoren.
- NetOps – Netzwerkadministratoren
- SecOps – Systemadministratoren mit Spezialisierung auf Informationssicherheit – PCI-Konformität, CIS-Konformität, Patching usw.
DevOps ist (theoretisch) eine Person, die alle Prozesse des Entwicklungszyklus – Entwicklung, Test – aus erster Hand versteht, die Produktarchitektur versteht, Sicherheitsrisiken einschätzen kann, mit Ansätzen und Automatisierungstools zumindest auf hohem Niveau vertraut ist Ebene versteht sich darüber hinaus auch auf die Vor- und Nachbearbeitung. Produkt-Release-Unterstützung. Eine Person, die in der Lage ist, als Fürsprecher sowohl für den Betrieb als auch für die Entwicklung aufzutreten, was eine günstige Zusammenarbeit zwischen diesen beiden Säulen ermöglicht. Versteht die Prozesse der Arbeitsplanung durch Teams und der Verwaltung von Kundenerwartungen.
Um diese Art von Arbeit und Verantwortung wahrzunehmen, muss diese Person über die Mittel verfügen, nicht nur die Entwicklungs- und Testprozesse, sondern auch die Verwaltung der Produktinfrastruktur sowie die Ressourcenplanung zu verwalten. DevOps kann in diesem Sinne weder in der IT noch in der Forschung und Entwicklung oder sogar im PMO angesiedelt sein; es muss in all diesen Bereichen Einfluss haben – der technische Direktor des Unternehmens, der Chief Technical Officer.
Ist das in Ihrem Unternehmen so? - Ich bezweifle. In den meisten Fällen handelt es sich dabei entweder um IT oder F&E.
Mangelnde finanzielle Mittel und mangelnde Einflussmöglichkeiten auf mindestens einen dieser drei Tätigkeitsbereiche werden das Gewicht der Probleme dahingehend verlagern, dass diese Änderungen einfacher anzuwenden sind, beispielsweise die Anwendung technischer Beschränkungen für Releases im Zusammenhang mit „schmutzigem“ Code laut Statik Analysesysteme. Das heißt, wenn das PMO eine strenge Frist für die Veröffentlichung von Funktionen festlegt, kann die Forschung und Entwicklung innerhalb dieser Fristen kein qualitativ hochwertiges Ergebnis erzielen und produziert es so gut wie möglich, sodass das Refactoring für später aufgeschoben wird. DevOps im IT-Bereich blockiert die Veröffentlichung mit technischen Mitteln . Mangelnde Autorität, die Situation zu ändern, führt bei verantwortungsbewussten Mitarbeitern zur Manifestation einer Überverantwortung für das, was sie nicht beeinflussen können, insbesondere wenn diese Mitarbeiter Fehler verstehen und erkennen und wissen, wie sie sie korrigieren können – „Glück ist Unwissenheit“, und in der Folge zu Burnout und Verlust dieser Mitarbeiter.
DevOps-Ressourcenmarkt
Schauen wir uns mehrere offene Stellen für DevOps-Positionen verschiedener Unternehmen an.
Wir sind bereit, Sie zu treffen, wenn Sie:
- Sie besitzen Zabbix und wissen, was Prometheus ist;
- Iptables;
- BASH-Doktorand;
- Professor Ansible;
- Linux-Guru;
- Wissen, wie man Debugging nutzt und gemeinsam mit Entwicklern Anwendungsprobleme findet (PHP/Java/Python);
- Routing macht Sie nicht hysterisch;
- Achten Sie besonders auf die Systemsicherheit.
- Sichern Sie „alles und jedes“ und stellen Sie dieses „alles und alles“ auch erfolgreich wieder her;
- Sie wissen, wie Sie das System so konfigurieren, dass Sie das Maximum aus dem Minimum herausholen.
- Richten Sie die Replikation vor dem Schlafengehen auf Postgres und MySQL ein;
- Das Einrichten und Anpassen von CI/CD ist für Sie ebenso notwendig wie Frühstück/Mittagessen/Abendessen.
- Erfahrung mit AWS haben;
- Bereit, sich gemeinsam mit dem Unternehmen weiterzuentwickeln;
Also:
- von 1 bis 6 - Systemadministrator
- 7 - eine kleine Netzwerkadministration, die auch in den Systemadministrator der mittleren Ebene passt
- 8 – ein wenig Sicherheit, die für einen Systemadministrator mittlerer Ebene obligatorisch ist
- 9-11 – Mittlerer Systemadministrator
- 12 – Abhängig von den zugewiesenen Aufgaben entweder Middle System Administrator oder Build Engineer
- 13 – Virtualisierung – Mittlerer Systemadministrator oder sogenannter CloudOps, fortgeschrittene Kenntnisse der Dienste einer bestimmten Hosting-Site, für den effizienten Einsatz von Mitteln und die Reduzierung der Wartungslast
Zusammenfassend können wir sagen, dass die Position eines mittleren/leitenden Systemadministrators für die Jungs ausreicht.
Übrigens sollten Sie Administratoren unter Linux/Windows nicht stark spalten. Natürlich verstehe ich, dass die Dienste und Systeme dieser beiden Welten unterschiedlich sind, aber die Grundlage für alle ist dieselbe und jeder Administrator mit etwas Selbstachtung ist sowohl mit der einen als auch mit der anderen vertraut, und selbst wenn er nicht vertraut ist, wird er es tun Für einen kompetenten Administrator dürfte es nicht schwierig sein, sich damit vertraut zu machen.
Betrachten wir eine weitere freie Stelle:
- Erfahrung im Bau von Hochlastsystemen;
- Ausgezeichnete Kenntnisse des Linux-Betriebssystems, der allgemeinen Systemsoftware und des Web-Stacks (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
- Erfahrung mit Virtualisierungssystemen (KVM, VMWare, LXC/Docker);
- Kenntnisse in Skriptsprachen;
- Verständnis der Funktionsprinzipien von Netzwerkprotokollnetzwerken;
- Verständnis der Prinzipien zum Aufbau fehlertoleranter Systeme;
- Unabhängigkeit und Initiative;
Schauen wir uns Folgendes an:
- 1 – Leitender Systemadministrator
- 2 – Abhängig von der Bedeutung, die diesem Stapel zugewiesen wird – Mittlerer/Senior-Systemadministrator
- 3 - Berufserfahrung, einschließlich, kann bedeuten: „Der Cluster hat keine virtuellen Maschinen erstellt, sondern erstellt und verwaltet, es gab einen Docker-Host, der Zugriff auf Container war nicht verfügbar“ – Mittlerer Systemadministrator
- 4 – Junior-Systemadministrator – ja, ein Administrator, der nicht weiß, wie man grundlegende Automatisierungsskripte schreibt, unabhängig von der Sprache, kein Administrator – enikey.
- 5 – Mittlerer Systemadministrator
- 6 – Leitender Systemadministrator
Zusammenfassend: Mittlerer/Senior Systemadministrator
Noch eine:
- Devops-Erfahrung;
- Erfahrung in der Verwendung eines oder mehrerer Produkte zur Erstellung von CI/CD-Prozessen. Gitlab CI wäre von Vorteil;
- Arbeiten mit Containern und Virtualisierung; Wenn Sie Docker verwendet haben, ist es gut, aber wenn Sie K8s verwendet haben, ist es großartig!
- Erfahrung in der Arbeit in einem agilen Team;
- Kenntnisse einer beliebigen Programmiersprache;
Wir werden sehen:
- 1 - Hmm... Was meinen die Jungs? =) Höchstwahrscheinlich wissen sie selbst nicht, was sich dahinter verbirgt
- 2 – Bauingenieur
- 3 – Mittlerer Systemadministrator
- 4 – Soft Skills werden wir vorerst nicht berücksichtigen, obwohl Agilität eine weitere Sache ist, die auf eine praktische Weise interpretiert wird.
- 5 – Zu ausführlich – es könnte sich um eine Skriptsprache oder eine kompilierte Sprache handeln. Ich frage mich, ob das Schreiben in Pascal und Basic in der Schule für sie geeignet ist. =)
Ich möchte auch eine Anmerkung zu Punkt 3 hinterlassen, um das Verständnis dafür zu stärken, warum dieser Punkt vom Systemadministrator abgedeckt wird. Kubernetes ist lediglich eine Orchestrierung, ein Tool, das direkte Befehle an Netzwerktreiber und Virtualisierungs-/Isolationshosts in ein paar Befehle zusammenfasst und es Ihnen ermöglicht, die Kommunikation mit ihnen abstrakt zu gestalten, das ist alles. Nehmen wir zum Beispiel „Build Framework“ Make, das ich übrigens nicht als Framework betrachte. Ja, ich kenne die Mode, Make überallhin zu schieben, wo es notwendig und nicht nötig ist – Maven zum Beispiel in Make einzupacken, ernsthaft?
Im Wesentlichen ist Make nur ein Wrapper über der Shell, der die Kompilierungs-, Verknüpfungs- und Kompilierungsumgebungsbefehle vereinfacht, genau wie k8s.
Einmal interviewte ich einen Mann, der k8s bei seiner Arbeit zusätzlich zu OpenStack verwendete, und er sprach darüber, wie er Dienste darauf bereitstellte. Als ich jedoch nach OpenStack fragte, stellte sich heraus, dass es sowohl vom System verwaltet als auch erhöht wurde Administratoren. Glauben Sie wirklich, dass eine Person, die OpenStack installiert hat, unabhängig davon, welche Plattform sie dahinter verwendet, k8s nicht verwenden kann? =)
Dieser Bewerber ist eigentlich kein DevOps, sondern ein Systemadministrator und genauer gesagt ein Kubernetes-Administrator.
Fassen wir noch einmal zusammen: Ein mittlerer/oberer Systemadministrator wird für sie ausreichen.
Wie viel wiegt man in Gramm?
Die Spanne der vorgeschlagenen Gehälter für die angegebenen offenen Stellen liegt zwischen 90 und 200
Jetzt möchte ich eine Parallele zwischen den finanziellen Belohnungen von Systemadministratoren und DevOps-Ingenieuren ziehen.
Grundsätzlich können Sie der Einfachheit halber die Noten nach Berufserfahrung streuen, dies ist zwar nicht exakt, reicht aber für die Zwecke des Artikels aus.
Erfahrung:
- bis 3 Jahre – Junior
- bis 6 Jahre alt – Mittel
- mehr als 6 – Senior
Die Seite zur Mitarbeitersuche bietet:
Systemadministratoren:
- Junior – 2 Jahre – 50 Rubel.
- Mittel - 5 Jahre - 70 Rubel.
- Senior - 11 Jahre - 100 Rubel.
DevOps-Ingenieure:
- Junior – 2 Jahre – 100 Rubel.
- Mittel - 3 Jahre - 160 Rubel.
- Senior - 6 Jahre - 220 Rubel.
Nach den Erfahrungen von „DevOps“ wurden Erfahrungen genutzt, die sich zumindest irgendwie auf den SDLC ausgewirkt haben.
Daraus folgt, dass Unternehmen DevOps tatsächlich nicht benötigen und dass sie durch die Einstellung eines Administrators mindestens 50 Prozent der ursprünglich geplanten Kosten einsparen könnten; darüber hinaus könnten sie die Verantwortlichkeiten der gesuchten Person klarer definieren und den Bedarf schneller decken. Wir sollten auch nicht vergessen, dass wir durch eine klare Aufgabenteilung den Personalbedarf reduzieren und durch die Vermeidung von Überschneidungen eine angenehmere Atmosphäre im Team schaffen können. Die überwiegende Mehrheit der offenen Stellen ist voll von Dienstprogrammen und DevOps-Labels, basiert jedoch nicht auf tatsächlichen Anforderungen an einen DevOps-Ingenieur, sondern nur auf Anfragen für einen Tool-Administrator.
Der Prozess der Schulung von DevOps-Ingenieuren beschränkt sich außerdem nur auf eine Reihe spezifischer Arbeiten und Dienstprogramme und vermittelt kein allgemeines Verständnis der Prozesse und ihrer Abhängigkeiten. Es ist sicherlich gut, wenn eine Person AWS EKS mithilfe von Terraform in Verbindung mit dem Fluentd-Sidecar in diesem Cluster und dem AWS ELK-Stack für das Protokollierungssystem in 10 Minuten bereitstellen kann, indem sie nur einen Befehl in der Konsole verwendet, aber wenn sie das nicht versteht Prinzip der Verarbeitung von Protokollen selbst und wofür sie benötigt werden. Wenn Sie nicht wissen, wie Sie Metriken dazu sammeln und die Verschlechterung des Dienstes verfolgen können, ist es immer noch derselbe Enikey, der weiß, wie man einige Dienstprogramme verwendet.
Nachfrage schafft jedoch Angebot, und wir sehen einen extrem überhitzten Markt für die DevOps-Stelle, wo die Anforderungen nicht der tatsächlichen Rolle entsprechen, sondern Systemadministratoren nur mehr verdienen lassen.
Wer sind sie also? DevOps oder gierige Systemadministratoren? =)
Wie kann man weiter leben?
Arbeitgeber sollten Anforderungen präziser formulieren und genau nach denen suchen, die gebraucht werden, und nicht mit Etiketten herumwerfen. Sie wissen nicht, was DevOps tun – in diesem Fall brauchen Sie sie nicht.
Arbeiter - Lernen. Verbessern Sie Ihr Wissen ständig, betrachten Sie das Gesamtbild der Prozesse und verfolgen Sie den Weg zu Ihrem Ziel. Du kannst werden, wer immer du willst, du musst es nur versuchen.
Source: habr.com