DevOps-Ingenieure gibt es nicht. Wer existiert dann und was kann man dagegen tun?

In letzter Zeit sind solche Anzeigen im Internet überall zu finden. Trotz eines attraktiven Gehalts kann man sich nicht des Eindrucks erwehren, dass in den Meldungen eine Menge Unsinn steht. Zunächst wird suggeriert, dass sich „DevOps“ und „Ingenieur“ irgendwie zu einem einzigen Wort zusammensetzen lassen, gefolgt von einer willkürlichen Liste von Anforderungen, von denen ein Teil offensichtlich aus einer Stellenanzeige für Systemadministratoren kopiert wurde.

In diesem Beitrag möchten wir ein wenig darüber sprechen, wie wir zu dieser Situation gekommen sind, was DevOps tatsächlich bedeutet und was wir jetzt damit anfangen sollen.

Solche Stellenangebote können in vielerlei Hinsicht kritisiert werden, aber eines steht fest: Sie sind zahlreich, und so ist der Markt momentan strukturiert. Wir haben eine DevOps-Konferenz veranstaltet und erklären offen: „DevOops — ist nicht für DevOps-Ingenieure“. Vielen wird es merkwürdig und absurd erscheinen: Warum gehen Menschen, die eine völlig kommerzielle Veranstaltung organisieren, gegen den Trend des Marktes? Wir erklären alles.

Über Kultur und Prozesse

Zunächst einmal ist DevOps keine Ingenieurdisziplin. Alles begann mit der Erkenntnis, dass die historisch gewachsene Rollenteilung nicht der Produktqualität zugutekommt. Wenn Programmierer nur programmieren und nichts über Tests hören wollen, wird die Software von Bugs überflutet. Wenn Administratoren es egal ist, wie und warum die Software geschrieben wurde, verwandelt sich der Support in einen Albtraum.

Zum Beispiel beschreibt es den Unterschied zwischen der Systems-Admin- und der SRE-Ansatzweise im Service Management. Es beginnt mit dem berühmten Google SRE Buch. Interessante Studien wurden im Rahmen des DORA-Befragung durchgeführt – es zeigt sich, dass die besten Entwickler es irgendwie schaffen, neue Änderungen schneller als einmal pro Stunde in die Produktion zu bringen. Sie testen manuell nicht mehr als 10 % (das zeigt sich an den DORA von letztem Jahr). Wie gelingt ihnen das? "Excel or die" – lautet einer der Titel des Berichts. Für eine detaillierte Diskussion dieser Statistik im Hinblick auf das Testen kann auf den Keynote von Baruch Sadogursky verwiesen werden "Wir haben DevOps. Lassen Sie uns alle Tester entlassen" auf einer unserer anderen Konferenzen, Heisenbug.

"Wenn es in der Gemeinschaft kein Einvernehmen gibt,
wird ihr Werk nicht vorankommen,
und es wird nicht zum Ergebnis führen, sondern nur zur Mühe."
Einmal, der Schwan, der Krebs und der Hecht…

Wie denken Sie, welcher Teil der Webentwickler versteht wirklich, unter welchen Bedingungen ihre Anwendungen in der Produktion betrieben werden? Wie viele von ihnen werden zu den Administratoren gehen und versuchen herauszufinden, was passiert, wenn die Datenbank ausfällt? Und wer von ihnen wird zu den Testern gehen und um eine Schulung bitten, wie man richtig Tests schreibt? Und da gibt es auch noch Sicherheitsexperten, Produktmanager und viele andere.

Die Grundidee von DevOps besteht darin, die Zusammenarbeit zwischen den Rollen und Abteilungen zu fördern. Dies wird in erster Linie nicht durch ausgeklügelte Software erreicht, sondern durch Kommunikationspraxis. DevOps handelt von Kultur, Praxis, Methodologie und Prozessen. Es gibt keinen Ingenieurberuf, der diese Fragen beantwortet.

Ein Teufelskreis

Woher stammt also die Disziplin „DevOps-Engineering“? Wir haben eine Theorie! Die Ideen von DevOps waren so gut, dass sie Opfer ihres eigenen Erfolgs wurden. Rund um dieses Thema haben sich merkwürdige Recruiter und Menschenhändler versammelt, die eine ganz eigene Atmosphäre geschaffen haben.

Stellen Sie sich vor: Gestern haben Sie in Chimki Shawarma gegrillt und heute sind Sie bereits ein großer Mann, ein Senior-Recruiter. Hier gibt es einen ganzen Prozess der Kandidatensuche und -auswahl, das ist nicht einfach, man muss es verstehen. Angenommen, der Abteilungsleiter sagt: Finde einen Spezialisten für X. Wir fügen das Wort „Ingenieur“ zu X hinzu, und das Thema ist erledigt. Brauchen wir einen Linux-Spezialisten? Na klar, das ist definitiv ein Linux-Ingenieur. Möchten Sie DevOps? Dann suchen wir einen DevOps-Ingenieur. Eine Stellenanzeige besteht nicht nur aus einem Titel, sondern innerhalb muss auch etwas Text stehen. Am einfachsten ist es, eine Reihe von Keywords aus Google einzufügen, je nach Fantasie. DevOps besteht aus zwei Wörtern – „Dev“ und „Ops“, also müssen wir die Keywords, die sich auf Entwickler und Administratoren beziehen, zu einem Haufen zusammenfügen. So entstehen Stellenanzeigen, die 42 Programmiersprachen und 20 Jahre Erfahrung mit Kubernetes und Swarm gleichzeitig erfordern. So funktioniert die Arbeitsweise.

So hat sich im Bewusstsein der Menschen das sinnlose und gnadenlose Bild eines Superhelden-„DevOps“ verfestigt, der allen das Deployment auf Jenkins einrichtet, und das Glück wird kommen. Ach, wenn nur alles so einfach wäre. „Und so kann man auch Sysadmins jagen“, denkt sich der HR-Manager, „das Wort ist modern, die Keywords sind dieselben, sie müssen darauf anspringen.“

Die Nachfrage schafft das Angebot, und auf all diese schlechten Stellenanzeigen haben sich unzählige Systemadministratoren gestürzt, die erkannt haben: Man kann das gleiche tun wie früher, aber viel mehr verdienen, indem man sich als "DevOps" bezeichnet. Wie du früher die Server manuell über SSH konfiguriert hast, wirst du es auch weiterhin tun, nur dass es jetzt angeblich eine DevOps-Praxis ist. Das ist ein komplexes Phänomen, das teilweise mit der Unterschätzung klassischer Administratoren und dem Hype um DevOps verbunden ist, aber insgesamt — das Ergebnis ist, was es ist.

Also haben wir Nachfrage und Angebot. Ein sich selbst ernährender Kreislauf. Mit diesem kämpfen wir (unter anderem, indem wir die DevOops-Konferenz veranstalten).

Natürlich gibt es neben den Systemadministratoren, die sich in "DevOps" umbenannt haben, auch andere Teilnehmer — wie professionelle SRE oder Entwickler von Infrastructure-as-Code.

Was Menschen in DevOps wirklich tun

Du möchtest also im Studium und in der Anwendung von DevOps-Praktiken vorankommen. Aber wie machst du das, wohin solltest du schauen? Es ist offensichtlich, dass du dich nicht blind an populären Schlüsselwörtern orientieren solltest.

Wenn es Arbeit gibt, muss sich jemand darum kümmern. Wir haben bereits festgestellt, dass dies nicht die „DevOps-Ingenieure“ sind. Wer ist es dann? Es scheint sinnvoller, dies nicht in Bezug auf Positionen, sondern in Bezug auf konkrete Tätigkeitsbereiche zu formulieren.

Zunächst kann man sich mit dem Herzen von DevOps beschäftigen – den Prozessen und der Kultur. Kultur ist eine langwierige und komplexe Angelegenheit, und obwohl dies traditionell in der Verantwortung von Führungskräften liegt, sind letztlich alle beteiligt, von Programmierern bis hin zu Administratoren. Vor ein paar Monaten sagte Tim Lister in einem Interview dass...:

Die Unternehmenskultur wird von den grundlegenden Werten der Organisation bestimmt. Oft nehmen die Menschen das nicht bewusst wahr, aber wir im Consulting haben im Laufe vieler Jahre gelernt, das zu erkennen. Man tritt in ein Unternehmen ein, und innerhalb weniger Minuten spürt man bereits, was hier 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, erkannt wurden. Verhalten lässt sich leicht beobachten, jedoch ist es schwierig, Überzeugungen aufzuspüren. DevOps ist ein hervorragendes Beispiel dafür, wie alles immer komplexer wird.

Es gibt natürlich auch einen technischen Aspekt zu betrachten. Wenn dein neuer Code in einem Monat zum Testen bereitsteht, aber im Release erst in einem Jahr erscheint, und es physisch unmöglich ist, alles zu beschleunigen – dann können gute Praktiken unerreichbar bleiben. Gute Praktiken werden durch gute Werkzeuge unterstützt. Wenn man das Konzept von Infrastructure-as-Code im Kopf behält, kann man alles Mögliche nutzen, von AWS CloudFormation und Terraform bis hin zu Chef-Ansible-Puppet. All dies muss man wissen und beherrschen, und das ist bereits eine ernsthafte Ingenieurdiziplin. Es ist wichtig, Ursache und Wirkung nicht zu verwechseln: Zuerst arbeitet man nach den Prinzipien von SRE und erst dann setzt man diese Prinzipien in konkrete technische Lösungen um. SRE ist eine sehr komplexe Methodologie, die nicht nur erklärt, wie man Jenkins konfiguriert, sondern sich auf fünf grundlegende Prinzipien konzentriert.

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

Es ist nicht einfach eine Sammlung von Aussagen, sondern ein konkretes Handlungsanleitung. Beispielsweise müssen wir bei der Fehlermanagement-Analyse die Risiken verstehen, die Verfügbarkeit und Nichterreichbarkeit von Diensten mithilfe von etwas wie SLI (Service Level Indicators) und SLO (Service Level Objectives), Postmortems schreiben lernen und sicherstellen, dass das Verfassen dieser Berichte nicht beängstigend ist.

Im Bereich SRE ist der Einsatz von Werkzeugen nur ein Teil des Erfolgs, jedoch ein sehr wichtiger. Wir müssen uns kontinuierlich technisch weiterentwickeln, beobachten, was in der Welt geschieht, und überlegen, wie wir dies in unserer Arbeit anwenden können.

Heutzutage sind Cloud-Native-Lösungen sehr gefragt. Laut der Cloud Native Computing Foundation ermöglichen Cloud-Native-Technologien Organisationen die Entwicklung und Bereitstellung skalierbarer Anwendungen in modernen, dynamischen Umgebungen wie öffentlichen, privaten und hybriden Cloud-Umgebungen. Beispiele hierfür sind Container, Service-Meshes, Microservices, unveränderbare Infrastrukturen und deklarative APIs. All diese Techniken sorgen dafür, dass lose gekoppelte Systeme elastisch, steuerbar und gut überwachbar bleiben. Eine robuste Automatisierung ermöglicht es Ingenieuren, häufig große Änderungen mit vorhersehbaren Ergebnissen vorzunehmen, ohne dass dies zu einer übermäßigen Belastung wird. All dies wird durch einen Stack bekannter Tools wie Docker und Kubernetes unterstützt.

Diese recht komplexe und umfangreiche Definition ist damit verbunden, dass auch das Gebiet selbst recht kompliziert ist. Einerseits wird behauptet, dass neue Änderungen in dieses System relativ einfach integriert werden sollten. Andererseits ist es notwendig, zu verstehen, wie man eine containerisierte Umgebung schafft, in der lose gekoppelte Dienste auf einer softwaredefinierten Infrastruktur leben und über kontinuierliches CI/CD bereitgestellt werden, sowie rund um diese Praktiken DevOps-Ansätze aufzubauen — hierfür benötigt man umfangreiche Erfahrung.

Was ist in dieser Hinsicht zu tun?

Jeder geht mit diesen Herausforderungen unterschiedlich um: Man kann beispielsweise reguläre Stellenanzeigen veröffentlichen, um den Teufelskreis zu durchbrechen. Man kann klären, was Begriffe wie DevOps und Cloud Native bedeuten und sie korrekt und sinnvoll verwenden. Man kann sich im DevOps-Bereich weiterentwickeln und durch das eigene Beispiel korrekte Ansätze demonstrieren.

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

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

Wie wählt man aus, wohin man gehen soll? Es gibt hierbei einen feinen Punkt. Einerseits geht es bei DevOps um Interaktion, und wir möchten, dass Sie an Vorträgen aus verschiedenen Bereichen teilnehmen. Andererseits, wenn Sie als Entwicklungsleiter zur Konferenz gekommen sind, um sich auf eine bestimmte Aufgabe zu konzentrieren, steht Ihnen das natürlich frei – in diesem Fall wäre der Bereich über Prozesse und Kultur offensichtlich die richtige Wahl. Denken Sie daran, dass Sie nach der Konferenz Zugriff auf die Aufzeichnungen haben (nachdem Sie das Feedback-Formular ausgefüllt haben), sodass Sie auch weniger wichtige Vorträge später ansehen können.

Es ist offensichtlich, dass Sie auf der Konferenz nicht gleichzeitig an drei Tracks teilnehmen können. Deshalb gestalten wir das Programm so, dass in jedem Zeitfenster Themen für jeden Geschmack vorhanden sind.

Jetzt bleibt nur noch die Frage, was zu tun ist, wenn Sie ein DevOps-Ingenieur sind! Versuchen Sie zunächst herauszufinden, womit Sie tatsächlich beschäftigt sind. Oft wird dieser Begriff verwendet für:

• Entwickler, die sich mit Infrastruktur beschäftigen. Für Sie sind die Vortragsgruppen über SRE und Cloud Native besonders geeignet.
• Systemadministratoren. Hier wird es komplizierter. DevOops ist nicht nur für Systemadministratoren gedacht. Glücklicherweise gibt es eine Fülle von wunderbaren Konferenzen, Büchern, Artikeln und Videos im Internet zum Thema Systemadministration. Auf der anderen Seite, wenn Sie Interesse daran haben, Ihr Verständnis für Kultur und Prozesse zu vertiefen, Cloud-Technologien und die Details des Lebens mit Cloud Native zu lernen, freuen wir uns, Sie zu sehen! Denken Sie darüber nach: Sie sind in der Administration tätig, was werden Sie als Nächstes tun? Um unangenehme Überraschungen zu vermeiden, sollten Sie bereits jetzt lernen.

Es gibt noch eine weitere Möglichkeit: Sie beharren darauf und behaupten weiterhin, dass Sie genau ein DevOps-Ingenieur und sonst nichts, egal was das bedeutet. Leider müssen wir Ihnen mitteilen, dass DevOops eine Konferenz ist, die nicht für DevOps-Ingenieure gedacht ist!

Folien aus dem Vortrag von Konstantin Diener in München

DevOops 2020 Moskau wird am 29.-30. April in Moskau stattfinden, Tickets können bereits auf der offiziellen Website.

erworben werden. Außerdem können Sie Ihr eigenes Referat einreichen bis zum 8. Februar. Bitte beachten Sie, dass Sie bei der Ausfüllung des Formulars die Zielgruppe auswählen müssen, der Ihr Referat den größten Nutzen bringen wird (innerhalb der Liste steckt eine Überraschung).

Quelle: habr.com