Get best of the week

Beruf DevOps-Ingenieur: Eine Ansicht des Systemadministrators



Ich arbeite als DevOps-Ingenieur bei Parallels. Ich unterstütze die Entwicklung verschiedener Dienste, schreibe Skripte für deren automatische Bereitstellung und kommuniziere eng mit dem Entwicklungsteam. Ich werde Ihnen sagen, wie die Arbeit organisiert ist, wie viel sie bezahlen und wozu der DevOps-Ansatz für die Softwareentwicklung gut ist.

Alles begann damit, dass es für mich langweilig wurde, als Systemadministrator zu arbeiten. Ich wollte etwas Neues. Ich habe versucht, 1C zu entwickeln, aber ziemlich schnell wurde mir klar, dass dies nicht meins war. Er lernte Python, verbesserte seine Kenntnisse in Unix-Systemen und führte ein Interview bei Parallels. Dann wusste ich fast nichts über DevOps, ich kam nur und sagte: Ich möchte für dich arbeiten. Zwei Monate später nahmen sie mich mit.

Was ist DevOps?


Wenn Sie 5 Personen fragen, was DevOps ist, erhalten Sie 5 verschiedene Antworten. Für Evangelisten ist dies eine Kultur oder vielmehr eine Transformation des Denkens. Für Ingenieure eine Reihe von Lösungen und Werkzeugen. Für Manager eine Methodik. Für Personalvermittler - ein Beruf. Und für alle anderen ist es wahrscheinlich nur ein Schlagwort.

Die Wahrheit liegt wie immer irgendwo dazwischen. DevOps ist alles zusammengenommen. Ihre Hauptaufgabe besteht darin, die Lieferung des Produkts vom Geschäft zum Verbraucher zu beschleunigen. Der Begriff selbst wurde vor etwa zwölf Jahren von dem unabhängigen IT-Berater Patrick Debois geprägt. Er wollte die metaphorische Mauer zwischen Entwicklern (dev) und Systemadministratoren (ops) aufbrechen und sie zu einer effektiven Einheit kombinieren, die Software schneller erstellen, Releases häufiger und mit weniger Fehlern einführen kann.

Im Zentrum von DevOps steht daher die Idee der geteilten Verantwortung, es gibt keine Gewaltenteilung. Der Programmierer kann an der Konfiguration teilnehmen, wenn er besser weiß, wie die Konfiguration seines Dienstes geschrieben wird, und der Systemadministrator in der Entwicklung. Wenn ein Problem auftritt, wird es nicht wie ein Ball in einem Tischtennis von einem Mitarbeiter auf einen anderen übertragen, sondern wird häufig. Jeder ist an seiner Beseitigung beteiligt.



Eine Minute langweiliger Statistiken. Laut der DORA-Studie (DevOps Research and Assessment) verwenden funktionsübergreifende Teams den DevOps-Ansatz:

  • 208-mal häufiger Code bereitstellen;
  • 106-mal verkürzen Sie die Zeit vom Festschreiben bis zur Bereitstellung.
  • 2,604-mal schnellere Wiederherstellungssysteme nach Ausfällen;
  • 7-mal weniger Ausfallwahrscheinlichkeit aufgrund von Änderungen.

Die Kombination von Dev und Ops allein führt natürlich nicht zu einer solchen Effizienz. Der DevOps-Ansatz umfasst die Verwendung vieler neuer Entwicklungs-, Test- und Bereitstellungstools für die Organisation von CI \ CD (das Konzept der kontinuierlichen Integration und Bereitstellung). Zu den bekanntesten:

  • Git und GitHub - Quellcodeverwaltungssysteme;
  • Jenkins - ein Automatisierungsserver zum Erstellen von CI / CD-Pipelines;
  • Docker - Software zur Automatisierung der Bereitstellung und des Anwendungsmanagements in Umgebungen mit Unterstützung für die Containerisierung;
  • Kubernetes - ein offenes Container-Orchestrierungssystem;
  • Chef, Puppet und Ansible - Tools für die automatische Konfiguration und Bereitstellung;
  • Selen - Testautomatisierungslösung;
  • Prometheus und Nagios - Serverüberwachungssoftware;
  • Grafana ist eine Lösung zum Sammeln und Analysieren von Metriken.

Gleichzeitig gibt es weder einen universellen Satz von Tools, die für jedes Unternehmen geeignet sind, noch gibt es einen einzigen Pfad zu DevOps. Es gibt nur das, was in Ihrer Infrastruktur funktioniert oder umgekehrt nicht funktioniert. Ich nehme regelmäßig an Konferenzen und verschiedenen Veranstaltungen teil, kommuniziere mit Kollegen anderer Unternehmen und kann sagen, dass 80% der Dinge, die sie in Parallels verwenden, nicht besonders zutreffend sind.

Jedes Unternehmen hat sein eigenes Produkt, seinen eigenen Technologie-Stack und seine Engpässe. Daher ist der Optimierungsansatz sehr unterschiedlich. Manchmal müssen Sie die Architektur der Dienste selbst ändern, einige sind so komplex oder unflexibel, dass es schwierig ist, den DevOps-Ansatz auf sie zu übertragen.

Die Essenz des DevOps-Ingenieurs


Grundsätzlich ist ein DevOps-Ingenieur ein technischer Spezialist, der alle Hauptphasen des Softwareentwicklungszyklus versteht, Engpässe in Prozessen korrigiert und die Umgebung anpasst:

  • Schreibt Code für die automatisierte Anwendungsbereitstellung
  • teilweise verantwortlich für ihre Verfügbarkeit, nicht persönlich als Systemadministrator, sondern mit seinem Team;
  • trägt eine Pflicht auf seiner Infrastruktur (versteht Fehler, manchmal zusammen mit einem Programmierer).

Automatisierung ist das, was einem DevOps-Ingenieur in erster Linie auf die Schultern fällt. Die Erstellung eines IT-Produkts mit dem traditionellen Ansatz erfolgt wie folgt: Der Programmierer schreibt seinen Code, kompiliert ihn in einem bestimmten Format und gibt ihn an den Systemadministrator weiter. Er geht zum Server, installiert und konfiguriert alles mit seinen Händen. Gleichzeitig kämpfen sie für verschiedene Dinge: den Systemadministrator - für Stabilität, den Programmierer - für ihre Änderungen, was natürlich die Arbeit jedes einzelnen von ihnen erschwert.

In DevOps funktioniert dies etwas anders. Die Anwendung wird mithilfe von Skripten bereitgestellt. Der DevOps-Techniker legt eine bestimmte Abfolge von Aktionen fest, die den vom Programmierer geschriebenen Code zuerst zum Testserver und dann zum Kampfserver bringt (wenn entschieden wird, dass die Änderungen freigegeben werden können). Somit hat der Entwickler die Möglichkeit, seinen Code mindestens alle 15 Minuten zu überprüfen und dies sogar um drei Uhr morgens mit einem einfachen Klick auf eine Schaltfläche zu tun.

Spezifische Verantwortlichkeiten sowie die erforderlichen Fähigkeiten hängen stark vom Arbeitsplatz ab. Wir in Parallels verfügen über einen Großteil unserer Infrastruktur. Die wichtigsten Teile befinden sich nicht in den öffentlichen Clouds, sondern auf unseren eigenen physischen Servern in mehreren Rechenzentren. Und manchmal gibt es wichtige Updates in Bezug auf Hardware und Software auf diesen Servern, und eine regelmäßige Migration ist erforderlich.

Das ist auch mein Job.


Ich versuche, alles maximal zu automatisieren, damit der Prozess weniger schmerzhaft ist. Das letzte Mal war es im Rahmen des Testens von Cross-Backups und der Toleranz gegenüber Infrastrukturfehlern möglich, Dienste aus den USA in 10 Minuten in die Schweiz zu übertragen und alles zu aktualisieren, was auf dem Weg erforderlich war. Für die moderne Technologie ist dies natürlich keine große Leistung. Aber für uns - ein großer Schritt nach vorne.

Legacy ist auch eine echte Herausforderung für DevOps-Ingenieure. Selbst in Unternehmen mit gut ausgebauten Workflows gibt es Services, die schon sehr lange geschrieben wurden, und niemand erinnert sich vollständig daran, wie sie eingerichtet wurden, da sie häufig manuell durchgeführt wurden und die Personen, die an ihnen gearbeitet haben, nicht mehr in der Organisation arbeiten. Wenn dies ein wichtiger Dienst ist, wird viel recherchiert - Sie müssen ihn bis ins kleinste Detail herausfinden, wie er funktioniert, Code für die Bereitstellung schreiben, ihn mit Überwachung und Metriken abdecken.

Dies lohnt sich auch dann, wenn sich der Anwendungscode nicht sehr aktiv ändert. Warum, wenn alles so funktioniert? Installieren Sie Sicherheitsupdates, suchen und beheben Sie Probleme, von denen möglicherweise niemand etwas weiß, um sie im Falle eines Fehlers reproduzieren zu können. Kürzlich habe ich gerade Skripte für einen solchen Dienst mit einer langen Geschichte geschrieben. Änderungen im Code waren erforderlich, die Arbeit ist noch nicht abgeschlossen, aber der Fortschritt ist groß. Es ist sehr interessant, ein vollständiges Bild der Anwendung aus unterschiedlichen Teilen zu sammeln. Es ist schön, das Ergebnis später zu betrachten.

Und natürlich hängt die Implementierung des DevOps-Ansatzes eng mit der Messung zusammen. Wie stark hat sich die Reaktionszeit verändert? Wie oft treten die beabsichtigten Fehler auf? Früher hatte ein Systemadministrator oft keine Ahnung, wie er diese Dinge messen sollte. Anwendungen waren Black Boxes, nur die grundlegendsten Merkmale blieben übrig: Prozessorlast, Speicherverbrauch, Datenverkehr. Und als die neue Version bereitgestellt wurde, konnten weder der Systemadministrator noch der Programmierer schnell feststellen, dass nicht alles genau wie geplant lief. Es blieb zu warten auf verärgerte Anrufe beim technischen Support.

Mit dem DevOps-Ansatz gehört dies der Vergangenheit an. Sie können die Erfassung realer Anwendungsmetriken konfigurieren, sie mit dem Ressourcenverbrauch vergleichen. Dadurch ist es besser und schneller, Probleme zu finden, zu optimieren, die Qualität der Produkte zu verbessern und nicht nur die Serververfügbarkeit.

Wie viel verdienen DevOps-Ingenieure?


Das Gehalt eines DevOps-Ingenieurs hängt von Fähigkeiten, Arbeitsort und Wohnort ab. Das Gehalt eines in Moskau tätigen Spezialisten ist mit 130 bis 350.000 Rubel pro Monat das höchste in Russland. Unternehmen in St. Petersburg bieten in dieser Position 100 bis 300.000 Rubel an. In anderen Regionen unseres Landes sind sie bereit, 70-120 Tausend Rubel zu zahlen.

Das durchschnittliche Jahreseinkommen in den USA liegt nach Angaben von Puppet, wie einige HRs sagen, zwischen 100 und 125.000 US-Dollar. In Australien und Neuseeland - 75-100 Tausend US-Dollar. In Europa - 50-75 Tausend US-Dollar. In Asien erhalten DevOps-Ingenieure nicht mehr als 25.000 US-Dollar pro Jahr.

More articles:


All Articles