Im Moment ist dies fast die teuerste Position auf dem Markt. Die Hektik der DevOps-Ingenieure überschreitet alle denkbaren Grenzen, geschweige denn die der Senior DevOps-Ingenieure.
Ich arbeite als Leiter der Integrations- und Automatisierungsabteilung, schätze die englische Entschlüsselung - DevOps Manager. Ob die englische Dekodierung genau unsere täglichen Aktivitäten widerspiegelt, ist unwahrscheinlich, aber die russische Version ist in diesem Fall genauer. Aufgrund meiner Tätigkeit ist es selbstverständlich, dass ich zukünftige Mitglieder meines Teams interviewen muss. Im vergangenen Jahr sind ungefähr 50 Personen durch mich gegangen, und der gleiche Betrag wurde mit meinen Mitarbeitern auf dem Bildschirm abgeschnitten.
Wir suchen immer noch Kollegen, denn hinter dem DevOps-Label verbirgt sich eine sehr große Schicht verschiedener Arten von Ingenieuren.
Alles, was unten geschrieben steht, ist meine persönliche Meinung. Sie sind nicht verpflichtet, dem zuzustimmen, aber ich gebe zu, dass es Ihre Einstellung zum Thema berühren wird. Trotz des Risikos, in Ungnade zu fallen, veröffentliche ich meine Meinung, weil ich glaube, dass er einen Platz hat, an dem er sein kann.
Unternehmen verstehen anders, wer DevOps-Ingenieure sind, und um schnell eine Ressource einzustellen, hängen sie dieses Etikett für alle auf. Die Situation ist ziemlich seltsam, da Unternehmen bereit sind, diesen Personen unrealistische Belohnungen zu zahlen, und in den meisten Fällen ein Verwaltungstool für sie erhalten.
Wer sind die DevOps-Ingenieure?
Beginnen wir mit der Geschichte - Development Operations erschien als ein weiterer Schritt zur Optimierung der Interaktion in kleinen Teams, um die Produktionsgeschwindigkeit des Produkts als erwartete Folge zu erhöhen. Die Idee war, das Entwicklungsteam mit Kenntnissen ü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, muss verstehen, wie er sein Produkt einsetzt und welche Umwelteigenschaften zu verschärfen sind, um die Produktivität zu steigern. Daher tauchten Entwickler einige Zeit mit dem DevOps-Ansatz auf. DevOps-Entwickler haben Build- und Packaging-Skripte geschrieben, um ihre Aktivitäten und die Leistung einer produktiven Umgebung zu vereinfachen. Die Komplexität der Entscheidungsarchitektur und die gegenseitige Beeinflussung von Infrastrukturkomponenten im Laufe der Zeit verschlechterten jedoch allmählich die Leistung von Umgebungen. Mit jeder Iteration war ein immer tieferes Verständnis bestimmter Komponenten erforderlich, was die Produktivität des Entwicklers selbst aufgrund der zusätzlichen Kosten für das Verständnis der Komponenten und Optimierungssysteme für eine bestimmte Aufgabe verringerte . Die eigenen Kosten des Entwicklers stiegen, die Kosten für das Produkt und die Anforderungen an neue Entwickler im Team stiegen stark an, da sie auch die Verantwortung des „Sterns“ der Entwicklung übernehmen mussten und der „Stern“ natürlich weniger zugänglich wurde. Es ist auch erwähnenswert, dass meiner Erfahrung nach nur wenige Entwickler an den Besonderheiten der Paketverarbeitung durch den Kernel des Betriebssystems, den Paketroutingregeln und den Sicherheitsaspekten des Hosts interessiert sind. Der logische Schritt bestand darin, einen Administrator zu gewinnen, der mit dieser besonderen Verantwortung vertraut ist, und ihm die Verantwortung eines ähnlichen Formats zuzuweisen, was es dank seiner Erfahrung ermöglichte, dieselben Indikatoren zu geringeren Kosten im Vergleich zu den Kosten des Entwicklungsstars zu erzielen. Solche Administratoren wurden in ein Team eingeteilt, und ihre Hauptaufgabe bestand darin, Test- und Produktivumgebungen basierend auf den Regeln eines bestimmten Teams mit Ressourcen zu verwalten, die diesem bestimmten Team zugewiesen wurden. Tatsächlich erschien DevOps in der Mehrheitssicht.
Teilweise oder vollständig im Laufe der Zeit begannen diese Systemadministratoren, die Anforderungen dieses speziellen Teams im Entwicklungsbereich zu verstehen, das Leben von Entwicklern und Testern zu vereinfachen, das Update einzuführen und nicht am Freitag über Nacht im Büro zu bleiben, um Bereitstellungsfehler zu beheben. Im Laufe der Zeit werden Systemadministratoren, die verstehen, was die Entwickler wollen, zu den "Stars". Um die Auswirkungen zu minimieren, holten die Verwaltungsdienstprogramme auf, alle erinnerten sich an die alten und zuverlässigen Methoden zur Isolierung der Betriebssystemebene, die es ermöglichten, die Sicherheitsanforderungen zu minimieren, den Netzwerkteil und die Hostkonfiguration als Ganzes zu verwalten und infolgedessen die Anforderungen für neue "Sterne" zu reduzieren.
Eine "wunderbare" Sache ist aufgetaucht - Docker. Warum wunderbar? Ja, nur weil das Erstellen einer Isolation in Chroot oder Jail sowie in OpenVZ nicht triviale Kenntnisse des Betriebssystems in einem Zählerdienstprogramm erforderte, mit dem Sie einfach eine isolierte Anwendungsumgebung auf einem bestimmten Host mit allem, was Sie benötigen, erstellen und die Zügel wieder an die Entwicklung übertragen und nur den Systemadministrator verwalten können Nur ein Host sorgt für Sicherheit und hohe Verfügbarkeit - eine logische Vereinfachung. Der Fortschritt steht jedoch nicht still und die Systeme werden immer komplizierter, immer mehr Komponenten, ein Host erfüllt nicht mehr die Anforderungen des Systems und es ist notwendig, Cluster zu erstellen. Wir kehren wieder zu den Systemadministratoren zurück, die diese Systeme erstellen können.
Zyklus für Zyklus erscheinen verschiedene Systeme, die die Entwicklung und / oder Verwaltung vereinfachen. Orchestrierungssysteme sind einfach zu verwenden, genau bis Sie sich vom Standardprozess entfernen müssen. Die Microservice-Architektur schien auch alles zu vereinfachen, was oben beschrieben wurde - weniger Beziehungen, einfacher zu verwalten. Nach meiner Erfahrung fand ich keine vollständige Microservice-Architektur, ich würde sagen, 50 bis 50 - 50 Prozent der Microservices, Black Boxes, kamen herein, wurden verarbeitet, die anderen 50 - ein zerrissener Monolith, Services, die nicht in der Lage waren, getrennt von anderen Komponenten zu arbeiten. All dies führte wiederum zu Einschränkungen des Wissensstands von Entwicklern und Administratoren.
Ähnliche "Schwankungen" des Expertenwissens einer bestimmten Ressource bestehen bis heute fort. Aber wir waren etwas abgelenkt, es gibt viele Punkte, die es wert sind, hervorgehoben zu werden.
Build Engineer / Release Engineer
Sehr hochspezialisierte Ingenieure, die als Mittel zur Standardisierung von Software-Montageprozessen und deren Releases erschienen sind. Bei der Einführung der Massenagilität Agile scheinen sie nicht mehr gefragt zu sein, aber dies ist bei weitem nicht der Fall. Diese Spezialisierung hat sich als Mittel zur Standardisierung der Montage und Lieferung von Software im industriellen Maßstab erwiesen, d.h. Verwendung von Standardtechniken für alle Produkte des Unternehmens. Mit dem Aufkommen von DevOps haben Entwickler ihre Funktionen teilweise verloren, da die Entwickler damit begonnen haben, das Produkt für die Lieferung vorzubereiten. Angesichts der sich ändernden Infrastruktur und des Ansatzes für die schnellste Lieferung ohne Rücksicht auf die Qualität wurden sie im Laufe der Zeit zu einem Stopper der Änderungen, da die Einhaltung von Qualitätsstandards die Lieferungen zwangsläufig verlangsamt. So wurde nach und nach ein Teil der Build / Release-Funktionalität von Ingenieuren auf die Schultern von Systemadministratoren migriert.
Ops ist so anders
Wir gehen weiter und wieder drängt uns das Vorhandensein einer Vielzahl von Verantwortlichkeiten und der Mangel an qualifiziertem Personal zu einer harten Spezialisierung, wie Pilze nach Regen, verschiedene Operationen erscheinen:
- TechOps - Enike-Systemadministratoren, auch bekannt als HelpDesk Engineer
- LiveOps - Systemadministratoren, die hauptsächlich für produktive Umgebungen verantwortlich sind
- CloudOps - Systemadministratoren, die sich auf öffentliche "Clouds" von Azure, AWS, GCP usw. spezialisiert haben.
- PlatOps / InfraOps / SysOps - Administratoren von Infrastruktursystemen.
- NetOps - Netzwerkadministratoren
- SecOps - Systemadministratoren, die auf Informationssicherheit spezialisiert sind - PCI-Konformität, CIS-Konformität, Patches usw.
DevOps - (theoretisch) eine Person, die alle Prozesse des Entwicklungszyklus aus erster Hand kennt - Entwicklung, Test, Verständnis der Produktarchitektur, Bewertung von Sicherheitsrisiken, Kenntnis von Automatisierungsansätzen und -mitteln, zumindest auf hohem Niveau, sowie Verständnis für Vor- und Nachbereitungen Produktfreigabeunterstützung. Eine Person kann sowohl für Betrieb als auch für Entwicklung eintreten, was eine günstige Zusammenarbeit zwischen den beiden Säulen ermöglicht. Teamplanungsprozesse verstehen und Kundenerwartungen verwalten.
Um diese Art von Arbeit und Verantwortlichkeiten ausführen zu können, muss diese Person über die Mittel verfügen, um nicht nur die Entwicklung, das Testen, sondern auch das Management der Produktinfrastruktur sowie die Ressourcenplanung zu steuern. DevOps in diesem Sinne können weder in der IT noch in der Forschung und Entwicklung oder sogar im PMO angesiedelt sein. Es sollte in all diesen Bereichen Einfluss haben - dem technischen Direktor des Unternehmens, dem Chief Technical Officier.
Ist das in Ihrer Firma so? - Ich bezweifle es. In den meisten Fällen handelt es sich entweder um IT oder um Forschung und Entwicklung.
Der Mangel an Mitteln und die Möglichkeit, mindestens einen dieser drei Geschäftsbereiche zu beeinflussen, werden das Gewicht der Probleme auf die Seite verlagern, auf der diese Änderungen leichter anzuwenden sind, beispielsweise die Anwendung technischer Beschränkungen für Freisetzungen im Zusammenhang mit dem "schmutzigen" Code gemäß den Daten der statischen Analysesysteme. Das heißt, wenn das PMO eine enge Frist für die Freigabe von Funktionen festlegt, kann F & E innerhalb dieser Fristen kein qualitativ hochwertiges Ergebnis liefern und gibt es so weiter, wie es möglich ist. DevOps in Bezug auf IT wird durch technische Mittel blockiert, um die Freigabe zu blockieren. Die mangelnde Befugnis, die Situation bei verantwortungsbewussten Mitarbeitern zu ändern, führt zu einer Manifestation der Überverantwortung für das, was sie nicht beeinflussen können. Darüber hinaus ist es „Glück in Unwissenheit“, wenn diese Mitarbeiter die Fehler verstehen und sehen und wie sie behoben werden können Burnout und Verlust dieser Mitarbeiter.
DevOps-Ressourcen vermarkten
Schauen wir uns einige DevOps-Stellenangebote verschiedener Unternehmen an.
Wir sind bereit, uns mit Ihnen zu treffen, wenn Sie:
- Besitze Zabbix und weiß, was Prometheus ist;
- Iptables;
- Doktorand BASH;
- Professor Ansible;
- Linux-Guru
- Wissen, wie man Debug verwendet und Anwendungsprobleme zusammen mit Entwicklern findet (php / java / python);
- Routing verursacht keine Wutanfälle;
- Achten Sie besonders auf die Systemsicherheit.
- Sichern Sie „alles und alles“ und stellen Sie dieses „alles und alles“ erfolgreich wieder her.
- Sie wissen, wie Sie das System so konfigurieren, dass es aus einem Minimum - Maximum herauskommt.
- Konfigurieren Sie die Replikation vor dem Schlafengehen auf Postgres und MySQL.
- Das Einrichten und Anpassen von CI / CD für Sie ist eine Notwendigkeit wie Frühstück / Mittag- / Abendessen.
- Erfahrung mit AWS haben;
- Bereit, sich mit dem Unternehmen zu entwickeln;
Also:
- 1 bis 6 - Systemadministrator
- 7 - ein bisschen Netzwerkadministration, die auch in den Systemadministrator der mittleren Ebene passt
- 8 - ein bisschen Sicherheit, die für einen Systemadministrator mittlerer Ebene obligatorisch ist
- 9-11 - Mittlerer Systemadministrator
- 12 - Abhängig von den festgelegten Aufgaben entweder Middle System Administrator oder Build Engineer
- 13 - Virtualisierung - Middle System Administrator oder das sogenannte CloudOps, fortgeschrittenes Wissen über die Dienste einer bestimmten Hosting-Plattform, um die Mittel effizient einzusetzen und die Belastung des Dienstes zu verringern
Zusammenfassend können wir sagen, dass der mittlere / höhere Systemadministrator für die Jungs ausreicht.
Übrigens, trennen Sie die Administratoren unter Linux / Windows nicht stark voneinander. Natürlich verstehe ich, dass die Dienste und Systeme dieser beiden Welten unterschiedlich sind, aber jeder hat eine Basis und jeder Administrator, der sich selbst respektiert, ist mit dem einen oder anderen vertraut, und selbst wenn er nicht vertraut ist, wird es für einen kompetenten Administrator nicht schwierig sein, sich damit vertraut zu machen.
Betrachten Sie eine andere Stelle:
- Erfahrung im Aufbau hoch belasteter Systeme;
- Hervorragende Kenntnisse des Linux-Betriebssystems, der systemweiten Software 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 Netzwerken von Netzwerkprotokollen;
- Verständnis der Prinzipien zum Aufbau fehlertoleranter Systeme;
- Unabhängigkeit und Initiative;
Analysieren:
- 1 - Leitender Systemadministrator
- 2 - Abhängig von der in diesen Stapel investierten Bedeutung - Middle / Senior System Administrator
- 3 - Erfahrung, einschließlich, kann bedeuten: "Der Cluster hat keine virtuellen Maschinen ausgelöst, sondern erstellt und verwaltet. Es gab einen Docker-Host. Der Zugriff auf Container war eingeschränkt." - Middle System Administrator
- 4 - Junior System Administrator - Ja, der Administrator kann keine elementaren Automatisierungsskripte schreiben, unabhängig von der Sprache und nicht vom Administrator.
- 5 - Mittlerer Systemadministrator
- 6 - Leitender Systemadministrator
Zusammenfassen - Mittlerer / Senior System Administrator
Noch eine:
- Erleben Sie Devops;
- Erfahrung in der Verwendung eines oder mehrerer Produkte zur Bildung von CI / CD-Prozessen. Gitlab CI wird ein Vorteil sein;
- Arbeiten Sie mit Containern und Virtualisierung. Wenn Sie Docker verwendet haben - gut, aber wenn k8s - großartig!
- Erfahrung in einem agilen Team;
- Kenntnisse in jeder Programmiersprache;
Mal sehen:
- 1 - Hmm ... was meinen die Jungs? =) Höchstwahrscheinlich wissen sie selbst nicht, was dahinter steckt
- 2 - Ingenieur bauen
- 3 - Mittlerer Systemadministrator
- 4 - Soft-Skill, wir werden es noch nicht berücksichtigen, obwohl Agile eine weitere Sache ist, die als bequem interpretiert wird.
- 5 - Zu umfangreich - Es kann eine Skriptsprache sein oder kompiliert werden. Interessanterweise hat er in der Schule über Pascal und Basic geschrieben? =)
Ich möchte auch eine Bemerkung zu 3 Punkten hinterlassen, um das Verständnis dafür zu stärken, warum dieser Punkt vom Systemadministrator behandelt wird. Kubernetes ist nur eine Orchestrierung, ein Tool, das direkte Befehle an Netzwerktreiber und Virtualisierungs- / Isolationshosts in ein paar Befehlen zusammenfasst und es Ihnen ermöglicht, die Kommunikation mit ihnen abstrakt zu gestalten, das ist alles. Nehmen Sie zum Beispiel das 'Build Framework' Make, das ich übrigens nicht als Framework betrachte. Ja, ich kenne die Mode, Make überall hin zu schieben, wo es notwendig und nicht notwendig ist - Maven zum Beispiel ernsthaft in Make einzuwickeln?
Im Wesentlichen ist Make nur ein Wrapper über der Shell, der die Kompilierung, Verknüpfung, Kompilierungsumgebung sowie k8s vereinfacht.
Einmal habe ich einen Mann interviewt, der k8s in seiner Arbeit über OpenStack verwendet hat, und er hat darüber gesprochen, wie Dienste darauf bereitgestellt werden können. Als ich jedoch nach OpenStack fragte, stellte sich heraus, dass es verwaltet und von Systemadministratoren angesprochen wird. Glauben Sie wirklich, dass die Person, die OpenStack ausgelöst hat, unabhängig davon, welche Plattform er hinter sich verwendet, k8s nicht verwenden kann? =)
Dieser Antragsteller ist eigentlich kein DevOps, sondern derselbe Systemadministrator und genauer gesagt der Kubernetes-Administrator.
Wir fassen noch einmal zusammen - Middle / Senior System Administrator wird für sie ausreichen.
Wie viel in Gramm zu hängen
Die Streuung der angebotenen Gehälter für die angegebenen offenen Stellen beträgt 90.000 bis 200.000
Jetzt möchte ich eine Parallele zwischen den finanziellen Belohnungen von Systemadministratoren und DevOps-Ingenieuren ziehen.
Im Prinzip können Sie zur Vereinfachung Erfahrungsgrade streuen, obwohl dies nicht korrekt ist, da die Zwecke des Artikels ausreichen.
Erfahrung:
- unter 3 Jahren - Junior
- unter 6 Jahren - Mitte
- mehr als 6 - Senior
Die Mitarbeitersuchseite bietet:
Systemadministratoren:
- Junior - 2 Jahre - 50k reiben.
- Mitte - 5 Jahre - 70k Rubel.
- Senior - 11 Jahre alt - 100.000 Rubel.
DevOps-Ingenieure:
- Junior - 2 Jahre - 100k reiben.
- Mitte - 3 Jahre - 160k reiben.
- Senior - 6 Jahre alt - 220k reiben.
Nach den Erfahrungen von „DevOps“ haben wir diese Erfahrungen genutzt und zumindest irgendwie die SDLC beeinflusst.
Aus dem oben Gesagten folgt, dass Unternehmen tatsächlich keine DevOps benötigen und dass sie durch die Einstellung des Administrators mindestens 50 Prozent der ursprünglich geplanten Kosten einsparen könnten. Außerdem könnten sie die Verantwortlichkeiten der Person klarer bestimmen und den Bedarf schnell schließen. Vergessen Sie nicht, dass Sie durch eine klare Aufgabenteilung den Personalbedarf reduzieren und aufgrund fehlender Kreuzungen eine günstigere Atmosphäre im Team schaffen können. Die überwiegende Mehrheit der offenen Stellen ist voll von Dienstprogrammen und DevOps-Labels. Sie erfüllen jedoch nicht wirklich die Anforderungen für DevOps Engineer, sondern sind lediglich Anfragen an den Administrator.
Der Prozess der Schulung von DevOps-Ingenieuren ist auch nur durch eine Reihe spezifischer Arbeiten und Dienstprogramme begrenzt und bietet kein allgemeines Verständnis der Prozesse und ihrer Abhängigkeiten. Es ist sicherlich gut, wenn eine Person Terraform verwenden kann, um AWS EKS in Verbindung mit dem Fluentd-Beiwagen in diesem Cluster und dem AWS ELK-Stack für das Protokollierungssystem in 10 Minuten mit nur einem Befehl in der Konsole bereitzustellen, aber das Prinzip der Verarbeitung nicht versteht Protokolle und warum sie benötigt werden, um nicht zu wissen, wie man Metriken auf ihnen sammelt und die Verschlechterung des Dienstes verfolgt, dann wird es das gleiche Enikey sein, das in der Lage ist, einige Dienstprogramme zu verwenden.
Die Nachfrage schafft jedoch Angebot, und wir sehen einen extrem überhitzten Markt für die DevOps-Position, in dem die Anforderungen nicht der tatsächlichen Rolle entsprechen, sondern nur den Systemadministratoren ermöglichen, mehr zu verdienen.
Also wer sind sie? DevOps oder gierige Systemadministratoren? =)
Wie kann man weiter leben?
Für Arbeitgeber - es ist genauer, Anforderungen zu formulieren und genau diejenigen zu suchen, die benötigt werden, und keine Etiketten zu streuen. Sie wissen nicht, was DevOps tun - Sie brauchen sie in diesem Fall nicht.
Arbeiter - lernen. Verbessern Sie Ihr Wissen ständig, sehen Sie sich das Gesamtbild der Prozesse an und verfolgen Sie den Weg zum Ziel. Sie können werden, was Sie wollen, Sie müssen es nur versuchen.