Es gibt keine DevOps-Ingenieure. Wer existiert dann und was sollten wir damit tun?

In letzter Zeit haben solche Anzeigen das Internet überschwemmt. Trotz eines attraktiven Gehalts kann es nicht anders als irritierend sein, dass darin ein wildes Geschreibsel steht. Zunächst wird angenommen, dass "DevOps" und "Ingenieur" irgendwie zu einem Wort zusammengeklebt werden können, und danach folgt eine willkürliche Liste von Anforderungen, von denen ein Teil offensichtlich aus einer Ausschreibung für Systemadministratoren kopiert wurde.

In diesem Beitrag möchte ich ein wenig darüber sprechen, wie wir zu dieser Lebensweise gekommen sind, was DevOps wirklich bedeutet und was wir jetzt damit tun können.

Solche Stellenangebote kann man auf jede erdenkliche Weise kritisieren, doch die Tatsache bleibt: Es gibt viele davon, und der Markt ist im Moment so strukturiert. Wir haben eine DevOps-Konferenz veranstaltet und sagen offen: „DevOops – nicht für DevOps-Ingenieure“. Viele werden hier seltsam und verrückt finden: Warum gehen Menschen, die eine völlig kommerzielle Veranstaltung machen, gegen den Markt? Das wird jetzt alles erklärt.

Über Kultur und Prozesse

Lassen Sie uns zunächst klären, dass DevOps keine Ingenieurdisziplin ist. Alles begann damit, dass die historisch gewachsenen Rollenteilungen nicht zur Qualität der Produkte beitragen. Wenn Programmierer nur programmieren und nichts über Tests hören wollen, wird die Software mit Bugs übersät. Wenn den Administrators egal ist, wie und warum die Software geschrieben ist, wird die Unterstützung zur Hölle.

Ein Beispiel für den Unterschied zwischen dem Ansatz eines Systemadministrators und dem eines SREs im Service Management beginnt mit dem berühmten Google SRE Book.Interessante Studien wurden im Rahmen von der DORA-Umfrage durchgeführt – man sieht, dass die besten Entwickler es irgendwie schaffen, neue Änderungen schneller als einmal pro Stunde in die Produktion zu bringen. Sie testen manuell auch nicht mehr als 10 % (das zeigt die letzte DORA-Umfrage). Wie schaffen sie das? "Excel or die" – sagt einer der Berichte. Für eine detaillierte Diskussion dieser Statistik im Hinblick auf Tests können Sie sich an den Keynote-Vortrag von Baruch Sadogursky wenden. "Wir haben DevOps. Lassen Sie uns alle Tester entlassen" auf einer anderen unserer Konferenzen, Heisenbug.

"Wenn im Freundeskreis kein Einvernehmen herrscht,
wird es zu nichts gut kommen,
und es wird nichts daraus hervorgehen, nur Mühe.
Einmal waren Schwan, Krebs und der Hecht..."

Wie denken Sie, welcher Teil der Webprogrammierer wirklich versteht, unter welchen Bedingungen ihre Anwendungen in der Produktion betrieben werden? Wie viele von ihnen gehen zu den Admins und versuchen herauszufinden, was passiert, wenn die Datenbank ausfällt? Und wer von ihnen geht zu den Testern und bittet um Hilfe, wie man richtig Tests schreibt? Und dann gibt es da noch die Sicherheitsleute, Produktmanager und noch viele andere.

Die Grundidee von DevOps besteht darin, die Zusammenarbeit zwischen Rollen und Abteilungen zu verbessern. Dies wird in erster Linie nicht durch irgendeine ausgeklügelte Software erreicht, sondern durch die Praxis der Kommunikation. DevOps dreht sich um Kultur, Praxis, Methodologie und Prozesse. Es gibt keinen Ingenieurberuf, der diese Fragen beantworten kann.

Teufelskreis

Wie kam es also zur Disziplin „DevOps-Engineering“? Wir haben eine Theorie! Die Ideen von DevOps erwiesen sich als so gut, dass sie Opfer ihres eigenen Erfolgs wurden. Rund um dieses Thema haben sich seltsame Rekruteure und Menschenhändler versammelt, die ihre eigene Atmosphäre haben.

Stellen Sie sich vor: Gestern haben Sie in Chimki Shawarma verkauft und heute sind Sie bereits eine große Persönlichkeit, Senior-Rekruter. Da ist ein ganzer Prozess der Kandidatensuche und -auswahl, es ist nicht einfach, das muss man verstehen. Angenommen, der Abteilungsleiter sagt: Finde einen Spezialisten für X. Wir fügen das Wort „Ingenieur“ zu X hinzu, und das ist es. Brauchen Sie Linux? Nun, dann ist es definitiv ein Linux-Ingenieur, wollen Sie DevOps – DevOps-Ingenieur. Eine Stellenanzeige besteht nicht nur aus einer Überschrift, sondern es muss auch ein Text geschrieben werden. Am einfachsten ist es, eine Sammlung von Keywords aus Google zu verwenden, je nachdem, wie viel Fantasie jemand hat. DevOps besteht aus zwei Wörtern – „Dev“ und „Ops“, also müssen wir Keywords kombinieren, die sich auf Entwickler und Administratoren beziehen, alles in einen Topf. So entstehen Stellenangebote, die die Beherrschung von 42 Programmiersprachen und 20 Jahre Erfahrung mit Kubernetes und Swarm gleichzeitig verlangen. Ein bewährtes Vorgehen.

So hat sich im Bewusstsein der Menschen das sinnlose und gnadenlose Bild eines Superhelden-„DevOps“ verankert, der allen den Deployment-Prozess auf Jenkins einrichtet, und dann wird alles gut. Ach, wenn es nur so einfach wäre. „Und so kann man auch Sysadmins anwerben“, denkt der HRler, „das Wort ist modern, die Keywords sind die gleichen, das müsste funktionieren.“

Nachfrage schafft Angebot, und auf all diese fragwürdigen Stellenanzeigen sind unglaublich viele Systemadministratoren geströmt, die erkannt haben: Man kann alles genauso machen wie früher, aber mehrere Male mehr verdienen, indem man sich "DevOps" nennt. Wie du früher Server über SSH einzeln konfiguriert hast, so wirst du weiterhin konfigurieren, aber jetzt wird das angeblich als DevOps-Praxis bezeichnet. Es ist ein komplexes Phänomen, das teilweise mit der Unterbewertung klassischer Administratoren und dem Hype um DevOps verbunden ist, aber insgesamt – das, was passiert ist, ist passiert.

Also haben wir Angebot und Nachfrage. Ein Teufelskreis, der sich selbst nährt. Mit diesem Kampf wir uns (unter anderem, indem wir die DevOops-Konferenz ins Leben rufen).

Natürlich gibt es neben den Systemadministratoren, die sich in "DevOps" umbenannt haben, auch andere Akteure – beispielsweise professionelle SRE oder Infrastructure-as-Code-Entwickler.

Was Menschen tatsächlich in DevOps tun

Also, du möchtest deine Kenntnisse und Praktiken in DevOps vertiefen. Aber wie machst du das, in welche Richtung solltest du schauen? Offensichtlich solltest du dich nicht blind an beliebten Schlüsselwörtern orientieren.

Wenn es Arbeit gibt, muss jemand sie erledigen. Wir haben bereits herausgefunden, dass das nicht die "DevOps-Engineers" sind, also wer dann? Es scheint richtig zu sein, dies nicht in Begriffen von Positionen, sondern in spezifischen Tätigkeitsbereichen zu formulieren.

Erstens kann man sich mit dem Kern von DevOps beschäftigen – Prozessen und Kultur. Kultur ist keine schnelle oder einfache Sache, und obwohl dies traditionell in den Verantwortungsbereich von Führungskräften fällt, sind letztendlich alle daran beteiligt, von Programmierern bis hin zu Administratoren. Vor ein paar Monaten sagte Tim Lister in einem Interview. „Die Kultur wird von den grundlegenden Werten einer Organisation geprägt. Die Menschen bemerken das normalerweise nicht, aber wir, die jahrelang im Consulting tätig sind, haben uns daran gewöhnt, darauf zu achten. Du kommst in ein Unternehmen und spürst nach wenigen Minuten, was dort passiert. Wir nennen es den 'Duft'. Manchmal ist dieser Duft wirklich angenehm. Manchmal verursacht er Übelkeit. (…) Du kannst die Kultur nicht ändern, bevor die Werte und Überzeugungen, die hinter bestimmten Handlungen stehen, erkannt werden. Verhalten lässt sich leicht beobachten, aber Überzeugungen zu finden – das ist schwierig. DevOps ist ein hervorragendes Beispiel dafür, wie alles immer komplexer wird.“:

«Die Unternehmenskultur wird durch die grundlegenden Werte der Organisation geprägt. Die meisten Menschen merken das nicht, aber wir, die wir seit vielen Jahren im Consulting tätig sind, sind daran gewöhnt, dies zu erkennen. Man betritt ein Unternehmen und spürt buchstäblich innerhalb von Minuten, was dort vor sich geht. Wir nennen das den „Duft“. Manchmal ist dieser Duft wirklich angenehm. Manchmal verursacht er Übelkeit. (…) Man kann die Kultur nicht verändern, bevor die Werte und Überzeugungen, die hinter bestimmten Handlungen stehen, nicht erkannt worden sind. Das Verhalten ist leicht zu beobachten, Überzeugungen zu finden ist schwierig. DevOps ist ein hervorragendes Beispiel dafür, wie alles immer komplexer wird.»

Es gibt natürlich auch eine technische Seite der Frage. Wenn dein neuer Code in einem Monat zum Testen kommt und im Release erst ein Jahr später erscheint, und es physisch unmöglich ist, das alles zu beschleunigen – dann könnte man die guten Praktiken nicht erreichen. Gute Praktiken werden durch gute Werkzeuge unterstützt. Zum Beispiel kann man, wenn man das Konzept von Infrastructure-as-Code im Hinterkopf hat, alles verwenden, von AWS CloudFormation und Terraform bis zu Chef-Ansible-Puppet. All das muss man wissen und können, und das ist schon eine Ingenieursdisziplin. Es ist wichtig, Ursache und Wirkung nicht zu verwechseln: Zuerst arbeitet man nach den Prinzipien von SRE und setzt diese Prinzipien erst dann in spezifische technische Lösungen um. Dabei ist SRE eine sehr umfassende Methodik, die nicht darüber spricht, wie man Jenkins einrichtet, sondern über fünf Grundprinzipien:

• Verbesserung der Interaktion zwischen Rollen und Abteilungen
• Akzeptanz von Fehlern als unvermeidlicher Teil der Arbeit
• Schrittweises Umsetzen von Veränderungen
• Nutzung von Tools und anderer Automatisierung
• Messung aller messbaren Aspekte

Es handelt sich nicht nur um eine Ansammlung von Behauptungen, sondern um konkrete Handlungsanweisungen. Zum Beispiel müssen Sie bei der Akzeptanz von Fehlern die Risiken verstehen, die Verfügbarkeit und Unerreichbarkeit von Diensten mithilfe von etwas wie SLI (Service-Level-Indikatoren) und SLO (Service-Level-Ziele), lernen, Postmortems zu schreiben, und sicherstellen, dass es nicht angsteinflößend ist, sie zu schreiben.

In der Disziplin SRE ist die Nutzung von Werkzeugen nur ein Teil des Erfolgs, jedoch kein unwesentlicher. Wir müssen uns ständig technisch weiterentwickeln, beobachten, was in der Welt geschieht, und wie wir das in unserer Arbeit anwenden können.

Cloud-Native-Lösungen sind derzeit sehr beliebt. Nach dem modernen Verständnis der Cloud Native Computing Foundation ermöglichen Cloud-Native-Technologien Organisationen, skalierbare Anwendungen in modernen, dynamischen Umgebungen zu entwickeln und auszuführen, wie z.B. öffentlichen, privaten und hybriden Clouds. Beispiele hierfür sind Container, Service-Meshes, Microservices, unveränderliche Infrastruktur und deklarative APIs. All diese Techniken ermöglichen es schwach gekoppelten Systemen, elastisch, verwaltbar und gut beobachtbar zu bleiben. Gute Automatisierung ermöglicht es Ingenieuren, häufig große Änderungen mit vorhersehbaren Ergebnissen vorzunehmen, ohne dies in eine anstrengende Arbeit zu verwandeln. All dies wird von einem Stack bekannter Werkzeuge wie Docker und Kubernetes unterstützt.

Diese recht komplexe und vielschichtige Definition hängt damit zusammen, dass das Thema selbst ziemlich kompliziert ist. Einerseits wird behauptet, dass neue Änderungen in dieses System relativ einfach hinzugefügt werden sollten. Andererseits muss man verstehen, wie man eine containerisierte Umgebung schafft, in der schwach gekuppelte Dienste auf einer softwaredefinierten Infrastruktur leben und kontinuierlich über CI/CD bereitgestellt werden, und rund um diese gesamte Struktur DevOps-Praktiken aufbaut – da muss man schon einige Erfahrungen sammeln.

Was kann man damit tun

Jeder geht mit diesen Herausforderungen anders um: Man könnte beispielsweise normale Stellenanzeigen veröffentlichen, um den Teufelskreis zu durchbrechen. Man könnte sich mit Begriffen wie DevOps und Cloud Native vertraut machen und sie korrekt und sinnvoll verwenden. Man könnte sich im Bereich DevOps weiterentwickeln und durch eigenes Beispiel korrekte Ansätze demonstrieren.

Wir veranstalten eine Konferenz DevOops 2020 Moskau, die die Möglichkeit bietet, tiefer in die Themen einzutauchen, über die wir gerade gesprochen haben. Dafür gibt es mehrere Vortragsgruppen:

• Prozesse und Kultur;
• Site Reliability Engineering;
• Cloud Native;

Wie wählt man aus, wohin man gehen möchte? Hier gibt es einen feinen Punkt. Einerseits geht es bei DevOps um Interaktion, und wir wünschen uns sehr, dass Sie Vorträge aus verschiedenen Blöcken besuchen. Andererseits, wenn Sie ein Entwicklungsleiter sind, der zur Konferenz gekommen ist, um sich auf eine bestimmte Aufgabe zu konzentrieren, dann hält Sie niemand auf – offensichtlich wird das ein Block über Prozesse und Kultur sein. Vergessen Sie nicht, dass Sie nach der Konferenz Aufzeichnungen haben werden (nach Ausfüllen des Feedback-Formulars), also können Sie immer später weniger wichtige Vorträge ansehen.

Offensichtlich können Sie während der Konferenz nicht gleichzeitig drei Tracks besuchen, deshalb gestalten wir das Programm so, dass in jedem Zeitfenster Themen für jeden Geschmack vorhanden sind.

Es bleibt nur zu klären, was zu tun ist, wenn Sie ein DevOps-Ingenieur sind! Zunächst versuchen Sie herauszufinden, womit Sie sich tatsächlich beschäftigen. Oft wird dieses Wort für Folgendes verwendet:

• Entwickler, die sich mit Infrastruktur beschäftigen. Für Sie sind insbesondere Gruppen von Vorträgen über SRE und Cloud Native geeignet.
• Systemadministrator. Hier wird es komplizierter. DevOops ist nicht über Systemadministration. Glücklicherweise gibt es viele großartige Konferenzen, Bücher, Artikel, Videos im Internet usw. über Systemadministration. Auf der anderen Seite, wenn Sie Interesse daran haben, mehr über Kultur und Prozesse, Cloud-Technologien und das Leben mit Cloud Native zu erfahren, freuen wir uns, Sie zu sehen! Denken Sie darüber nach: Sie sind ein Administrator, und was machen Sie dann weiter? Um nicht unerwartet in eine unangenehme Situation zu geraten, sollten Sie schon jetzt lernen.

Es gibt noch eine weitere Möglichkeit: Sie bestehen darauf und beharren darauf, dass Sie genau DevOps-Ingenieur sind und sonst nichts, egal was das bedeutet. Leider müssen wir sagen, DevOops ist eine Konferenz nicht für DevOps-Ingenieure!

Folie aus Vortrag von Konstantin Diener in München

DevOops 2020 Moskau findet am 29.-30. April in Moskau statt, Tickets sind bereits erhältlich. auf der offiziellen Website erworben werden.

Außerdem können Sie Ihren Vortrag einreichen bis zum 8. Februar. Bitte beachten Sie, dass Sie beim Ausfüllen des Formulars die Zielgruppe auswählen müssen, die am meisten von Ihrem Vortrag profitieren wird (innerhalb der Liste steckt eine Überraschung).

Quelle: habr.com