{"id":53925,"date":"2019-12-13T00:00:00","date_gmt":"2019-12-12T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/devops-inzhenerov-ne-sushhestvuet-kto-togda-sushhestvuet-i-chto-s-etim-delat"},"modified":"2020-02-18T14:01:52","modified_gmt":"2020-02-18T11:01:52","slug":"devops-inzhenerov-ne-sushhestvuet-kto-togda-sushhestvuet-i-chto-s-etim-delat","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/devops-inzhenerov-ne-sushhestvuet-kto-togda-sushhestvuet-i-chto-s-etim-delat","title":{"rendered":"DevOps-Ingenieure gibt es nicht. Wer existiert dann und was kann man dagegen tun?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"DevOps-Ingenieure<\/p>\n

<\/p>\n

In letzter Zeit sind solche Anzeigen im Internet \u00fcberall zu finden. Trotz eines attraktiven Gehalts kann man sich nicht des Eindrucks erwehren, dass in den Meldungen eine Menge Unsinn steht. Zun\u00e4chst wird suggeriert, dass sich \u201eDevOps\u201c und \u201eIngenieur\u201c irgendwie zu einem einzigen Wort zusammensetzen lassen, gefolgt von einer willk\u00fcrlichen Liste von Anforderungen, von denen ein Teil offensichtlich aus einer Stellenanzeige f\u00fcr Systemadministratoren kopiert wurde.<\/p>\n

<\/p>\n

In diesem Beitrag m\u00f6chten wir ein wenig dar\u00fcber sprechen, wie wir zu dieser Situation gekommen sind, was DevOps tats\u00e4chlich bedeutet und was wir jetzt damit anfangen sollen.<\/p>\n

<\/p>\n

Solche Stellenangebote k\u00f6nnen 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\u00e4ren offen: \u201eDevOops<\/a><\/noindex> \u2014 ist nicht f\u00fcr DevOps-Ingenieure\u201c. Vielen wird es merkw\u00fcrdig und absurd erscheinen: Warum gehen Menschen, die eine v\u00f6llig kommerzielle Veranstaltung organisieren, gegen den Trend des Marktes? Wir erkl\u00e4ren alles.<\/p>\n

<\/a><\/noindex><\/p>\n

\u00dcber Kultur und Prozesse<\/h2>\n

<\/p>\n

Zun\u00e4chst einmal ist DevOps keine Ingenieurdisziplin. Alles begann mit der Erkenntnis, dass die historisch gewachsene Rollenteilung nicht der Produktqualit\u00e4t zugutekommt. Wenn Programmierer nur programmieren und nichts \u00fcber Tests h\u00f6ren wollen, wird die Software von Bugs \u00fcberflutet. Wenn Administratoren es egal ist, wie und warum die Software geschrieben wurde, verwandelt sich der Support in einen Albtraum. <\/p>\n

<\/p>\n

Zum Beispiel beschreibt es den Unterschied zwischen der Systems-Admin- und der SRE-Ansatzweise im Service Management. Es beginnt mit dem ber\u00fchmten Google SRE Buch<\/a><\/noindex>. Interessante Studien wurden im Rahmen des DORA-Befragung<\/a><\/noindex> durchgef\u00fchrt \u2013 es zeigt sich, dass die besten Entwickler es irgendwie schaffen, neue \u00c4nderungen 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<\/a><\/noindex>). Wie gelingt ihnen das? \"Excel or die\" \u2013 lautet einer der Titel des Berichts. F\u00fcr 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\"<\/a><\/noindex> auf einer unserer anderen Konferenzen, Heisenbug.<\/p>\n

<\/p>\n

\"Wenn es in der Gemeinschaft kein Einvernehmen gibt,
\nwird ihr Werk nicht vorankommen,
\nund es wird nicht zum Ergebnis f\u00fchren, sondern nur zur M\u00fche.\"
\nEinmal, der Schwan, der Krebs und der Hecht\u2026<\/p><\/blockquote>\n

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\u00e4llt? 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.<\/p>\n

<\/p>\n

Die Grundidee von DevOps besteht darin, die Zusammenarbeit zwischen den Rollen und Abteilungen zu f\u00f6rdern. Dies wird in erster Linie nicht durch ausgekl\u00fcgelte Software erreicht, sondern durch Kommunikationspraxis. DevOps handelt von Kultur, Praxis, Methodologie und Prozessen. Es gibt keinen Ingenieurberuf, der diese Fragen beantwortet.<\/p>\n

<\/p>\n

Ein Teufelskreis<\/h2>\n

<\/p>\n

Woher stammt also die Disziplin \u201eDevOps-Engineering\u201c? 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\u00fcrdige Recruiter und Menschenh\u00e4ndler versammelt, die eine ganz eigene Atmosph\u00e4re geschaffen haben.<\/p>\n

<\/p>\n

Stellen Sie sich vor: Gestern haben Sie in Chimki Shawarma gegrillt und heute sind Sie bereits ein gro\u00dfer 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\u00fcr X. Wir f\u00fcgen das Wort \u201eIngenieur\u201c zu X hinzu, und das Thema ist erledigt. Brauchen wir einen Linux-Spezialisten? Na klar, das ist definitiv ein Linux-Ingenieur. M\u00f6chten 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\u00fcgen, je nach Fantasie. DevOps besteht aus zwei W\u00f6rtern \u2013 \u201eDev\u201c und \u201eOps\u201c, also m\u00fcssen wir die Keywords, die sich auf Entwickler und Administratoren beziehen, zu einem Haufen zusammenf\u00fcgen. So entstehen Stellenanzeigen, die 42 Programmiersprachen und 20 Jahre Erfahrung mit Kubernetes und Swarm gleichzeitig erfordern. So funktioniert die Arbeitsweise.<\/p>\n

<\/p>\n

So hat sich im Bewusstsein der Menschen das sinnlose und gnadenlose Bild eines Superhelden-\u201eDevOps\u201c verfestigt, der allen das Deployment auf Jenkins einrichtet, und das Gl\u00fcck wird kommen. Ach, wenn nur alles so einfach w\u00e4re. \u201eUnd so kann man auch Sysadmins jagen\u201c, denkt sich der HR-Manager, \u201edas Wort ist modern, die Keywords sind dieselben, sie m\u00fcssen darauf anspringen.\u201c<\/p>\n

<\/p>\n

Die Nachfrage schafft das Angebot, und auf all diese schlechten Stellenanzeigen haben sich unz\u00e4hlige Systemadministratoren gest\u00fcrzt, die erkannt haben: Man kann das gleiche tun wie fr\u00fcher, aber viel mehr verdienen, indem man sich als \"DevOps\" bezeichnet. Wie du fr\u00fcher die Server manuell \u00fcber SSH konfiguriert hast, wirst du es auch weiterhin tun, nur dass es jetzt angeblich eine DevOps-Praxis ist. Das ist ein komplexes Ph\u00e4nomen, das teilweise mit der Untersch\u00e4tzung klassischer Administratoren und dem Hype um DevOps verbunden ist, aber insgesamt \u2014 das Ergebnis ist, was es ist.<\/p>\n

<\/p>\n

Also haben wir Nachfrage und Angebot. Ein sich selbst ern\u00e4hrender Kreislauf. Mit diesem k\u00e4mpfen wir (unter anderem, indem wir die DevOops-Konferenz veranstalten).<\/p>\n

<\/p>\n

Nat\u00fcrlich gibt es neben den Systemadministratoren, die sich in \"DevOps\" umbenannt haben, auch andere Teilnehmer \u2014 wie professionelle SRE oder Entwickler von Infrastructure-as-Code.<\/p>\n

<\/p>\n

Was Menschen in DevOps wirklich tun<\/h2>\n

<\/p>\n

Du m\u00f6chtest 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\u00e4ren Schl\u00fcsselw\u00f6rtern orientieren solltest.<\/p>\n

<\/p>\n

Wenn es Arbeit gibt, muss sich jemand darum k\u00fcmmern. Wir haben bereits festgestellt, dass dies nicht die \u201eDevOps-Ingenieure\u201c sind. Wer ist es dann? Es scheint sinnvoller, dies nicht in Bezug auf Positionen, sondern in Bezug auf konkrete T\u00e4tigkeitsbereiche zu formulieren.<\/p>\n

<\/p>\n

Zun\u00e4chst kann man sich mit dem Herzen von DevOps besch\u00e4ftigen \u2013 den Prozessen und der Kultur. Kultur ist eine langwierige und komplexe Angelegenheit, und obwohl dies traditionell in der Verantwortung von F\u00fchrungskr\u00e4ften liegt, sind letztlich alle beteiligt, von Programmierern bis hin zu Administratoren. Vor ein paar Monaten sagte Tim Lister in einem Interview dass...<\/a><\/noindex>:<\/p>\n

<\/p>\n

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\u00fcrt man bereits, was hier vor sich geht. Wir nennen das den \"Duft\". Manchmal ist dieser Duft wirklich angenehm. Manchmal verursacht er \u00dcbelkeit. (\u2026) Man kann die Kultur nicht ver\u00e4ndern, bevor die Werte und \u00dcberzeugungen, die hinter bestimmten Handlungen stehen, erkannt wurden. Verhalten l\u00e4sst sich leicht beobachten, jedoch ist es schwierig, \u00dcberzeugungen aufzusp\u00fcren. DevOps ist ein hervorragendes Beispiel daf\u00fcr, wie alles immer komplexer wird.<\/p><\/blockquote>\n

Es gibt nat\u00fcrlich 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\u00f6glich ist, alles zu beschleunigen \u2013 dann k\u00f6nnen gute Praktiken unerreichbar bleiben. Gute Praktiken werden durch gute Werkzeuge unterst\u00fctzt. Wenn man das Konzept von Infrastructure-as-Code im Kopf beh\u00e4lt, kann man alles M\u00f6gliche 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\u00f6sungen um. SRE ist eine sehr komplexe Methodologie, die nicht nur erkl\u00e4rt, wie man Jenkins konfiguriert, sondern sich auf f\u00fcnf grundlegende Prinzipien konzentriert.<\/p>\n

<\/p>\n