{"id":38521,"date":"2019-10-31T22:24:16","date_gmt":"2019-10-31T19:24:16","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kto-takie-devops\/"},"modified":"2019-10-31T22:24:16","modified_gmt":"2019-10-31T19:24:16","slug":"kto-takie-devops","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/kto-takie-devops","title":{"rendered":"Was sind DevOps?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Momentan ist dies m\u00f6glicherweise die teuerste Position auf dem Markt. Der Hype um \u201eDevOps\u201c-Ingenieure \u00fcbersteigt alle vorstellbaren Grenzen, und das gilt erst recht f\u00fcr Senior DevOps Ingenieure.
\nIch arbeite als Leiter der Abteilung f\u00fcr Integration und Automatisierung, erraten Sie die englische Abk\u00fcrzung - DevOps Manager. Reflektiert die englische Abk\u00fcrzung tats\u00e4chlich unsere allt\u00e4gliche T\u00e4tigkeit? Wohl kaum, das russische Pendant trifft in diesem Fall besser zu. In meiner Funktion ist es nat\u00fcrlich notwendig, zuk\u00fcnftige Teammitglieder zu interviewen und im vergangenen Jahr sind rund 50 Personen durch meine H\u00e4nde gegangen, ebenso viele wurden bereits im Vorfeld von meinen Mitarbeitern gescreent.<\/p>\n

<\/p>\n

Wir sind weiterhin auf der Suche nach Kollegen, denn hinter dem Label DevOps verbirgt sich eine sehr gro\u00dfe Schicht verschiedener Ingenieure.<\/a><\/noindex><\/p>\n

<\/p>\n

Alles, was im Folgenden geschrieben wird, ist meine pers\u00f6nliche Meinung, Sie sind nicht verpflichtet, mir zuzustimmen, ich erlaube mir jedoch, dass es Ihren Blick auf das Thema beeinflussen k\u00f6nnte. Trotz des Risikos, in Ungnade zu fallen, ver\u00f6ffentliche ich meine Meinung, weil ich der Meinung bin, dass sie Geh\u00f6r finden sollte.<\/p>\n

<\/p>\n

Die Unternehmen verstehen unterschiedlich, wer DevOps Ingenieure sind, und um schnell Personal zu rekrutieren, h\u00e4ngen sie dieses Label allen an. Die Situation ist ziemlich seltsam, da die Unternehmen bereit sind, diesen Personen unrealistische Belohnungen zu zahlen, in den meisten F\u00e4llen erhalten sie jedoch nur einen Administrator-Toolset-Experten daf\u00fcr.<\/p>\n

<\/p>\n

Wer sind also die DevOps Ingenieure?<\/h2>\n

<\/p>\n

Lassen Sie uns mit der Entstehungsgeschichte beginnen \u2013 Development Operations entstand als ein weiterer Schritt zur Optimierung der Zusammenarbeit in kleinen Teams, um die Produktionsgeschwindigkeit zu erh\u00f6hen, was eine erwartete Folge war. Die Idee war, das Entwicklungsteam mit Wissen \u00fcber Verfahren und Ans\u00e4tze im Management von Produktumgebungen zu st\u00e4rken. Mit anderen Worten, der Entwickler muss verstehen und wissen, wie sein Produkt unter bestimmten Bedingungen funktioniert, er muss verstehen, wie man sein Produkt bereitstellt, welche Umgebungsmerkmale optimiert werden sollten, um die Leistung zu steigern. So traten \u00fcber einen gewissen Zeitraum hinweg Entwickler mit DevOps-Ansatz auf. DevOps-Entwickler schrieben Skripte f\u00fcr den Build- und Verpackungsprozess, um ihre T\u00e4tigkeit und die Funktionalit\u00e4t der Produktionsumgebung zu vereinfachen. Die Komplexit\u00e4t der L\u00f6sungsarchitektur und die gegenseitige Beeinflussung der Infrastrukturkomponenten begannen jedoch im Laufe der Zeit, die Leistungskennzahlen der Umgebungen zu verschlechtern; mit jeder Iteration waren tiefere Kenntnisse \u00fcber bestimmte Komponenten erforderlich, was die Produktivit\u00e4t der Entwickler durch den zus\u00e4tzlichen Aufwand f\u00fcr das Verst\u00e4ndnis von Komponenten und die Anpassung von Systemen an spezifische Aufgaben verringerte. Die eigenen Kosten des Entwicklers stiegen, die Kosten des Produkts ebenfalls, und die Anforderungen an neue Entwickler im Team schossen in die H\u00f6he, da sie auch die Aufgaben der \u201eStars\u201c der Entwicklung erf\u00fcllen mussten, und nat\u00fcrlich wurden die \u201eStars\u201c immer weniger verf\u00fcgbar. Es ist auch erw\u00e4hnenswert, dass, meiner Erfahrung nach, nur sehr wenige Entwickler an den Details der Paketverarbeitung im Betriebssystemkern, den Regeln der Paketweiterleitung und den Sicherheitsaspekten des Hosts interessiert sind. Der logische Schritt war es, einen Administrator zu engagieren, der mit diesen Aspekten vertraut ist, und die Verantwortung f\u00fcr diese Art von Aufgaben ihm zu \u00fcbertragen, was dank seiner Erfahrung die Erreichung derselben Kennzahlen zu geringeren Kosten im Vergleich zu den Kosten eines \u201eStars\u201c der Entwicklung erm\u00f6glichte. Solche Administratoren wurden ins Team integriert und ihre Hauptaufgabe war das Management von Test- und Produktionsumgebungen nach den spezifischen Regeln des jeweiligen Teams, mit Ressourcen, die diesem Team zugewiesen wurden. So entstanden tats\u00e4chlich die DevOps aus der Sicht der meisten.<\/p>\n

<\/p>\n

Teilweise oder vollst\u00e4ndig begannen im Laufe der Zeit die Systemadministratoren, die Bed\u00fcrfnisse dieses speziellen Entwicklerteams zu verstehen, wie sie das Leben der Entwickler und Tester erleichtern k\u00f6nnen, wie sie ein Update bereitstellen k\u00f6nnen, ohne an einem Freitagabend im B\u00fcro bleiben zu m\u00fcssen, um Deploymentsfehler zu beheben. Die Zeit verging, und nun wurden die Systemadministratoren zu den \u201eStars\u201c, die verstehen, was die Entwickler wollen. Um die Auswirkungen zu minimieren, begannen Verwaltungstools, sich zu etablieren, und alle erinnerten sich an alte und zuverl\u00e4ssige Methoden zur Isolierung auf Betriebssystemebene, die es erm\u00f6glichten, die Sicherheitsanforderungen, die Verwaltung des Netzwerkteils und die Gesamtkonfiguration des Hosts zu minimieren und somit die Anforderungen an die neuen \u201eStars\u201c zu reduzieren. <\/p>\n

<\/p>\n

Es entstand eine \u201ewunderbare\u201c Sache \u2014 Docker. Warum wunderbar? Nur weil die Schaffung von Isolation in chroot oder jail, ebenso wie bei OpenVZ, umfangreiche Kenntnisse des Betriebssystems erforderte, w\u00e4hrend das entsprechende Tool es erm\u00f6glichte, auf einfache Weise eine isolierte Anwendungsumgebung auf einem Host mit all dem Notwendigen darin zu schaffen und die Kontrolle wieder an die Entwicklung zu \u00fcbergeben, w\u00e4hrend der Systemadministrator nur f\u00fcr einen Host verantwortlich ist und dessen Sicherheit und hohe Verf\u00fcgbarkeit gew\u00e4hrleistet \u2014 eine logische Vereinfachung. Doch der Fortschritt steht nicht still und die Systeme werden erneut immer komplexer, die Komponenten nehmen zu und ein einzelner Host gen\u00fcgt nicht mehr den Anforderungen des Systems, weshalb Cluster gebaut werden m\u00fcssen. Wir kommen wieder zu den Systemadministratoren zur\u00fcck, die in der Lage sind, diese Systeme zu erstellen.<\/p>\n

<\/p>\n

Zyklus f\u00fcr Zyklus tauchen verschiedene Systeme auf, die die Entwicklung und\/oder Administration erleichtern, es entstehen Orchestrierungssysteme, die, bis zu dem Punkt, an dem man vom Standardprozess abweichen muss, einfach zu bedienen sind. Die Microservices-Architektur entstand ebenfalls mit dem Ziel, alles oben Genannte zu vereinfachen \u2014 weniger Abh\u00e4ngigkeiten, einfacher in der Verwaltung. In meiner Erfahrung habe ich die vollst\u00e4ndige Microservices-Architektur nicht erlebt, ich w\u00fcrde sagen 50 zu 50 \u2014 50 Prozent Microservices, schwarze Boxen, was hineinkommt, wird verarbeitet, und die anderen 50 \u2014 ein zerfleddertes Monolith, Dienste, die nicht unabh\u00e4ngig von anderen Komponenten arbeiten k\u00f6nnen. All dies hat erneut die Anforderungen an das Wissensniveau sowohl der Entwickler als auch der Administratoren erh\u00f6ht.<\/p>\n

<\/p>\n

Solche \u201eSchaukelbewegungen\u201c auf Expertenniveau in Bezug auf bestimmte Ressourcen dauern bis heute an. Aber wir haben uns ein wenig abgelenkt, es gibt zahlreiche Punkte, die es wert sind, beleuchtet zu werden.<\/p>\n

<\/p>\n

Build Engineer\/Release Engineer<\/h2>\n

<\/p>\n

Sehr spezialisierte Ingenieure, die als Mittel zur Standardisierung von Softwarebuilds und -Release-Prozessen entstanden sind. Mit der Einf\u00fchrung von Agile schienen sie zwar an Bedeutung zu verlieren, doch das ist nicht der Fall. Diese Spezialisierung entstand als Werkzeug zur Standardisierung genau der Softwareverteilung in industriellem Ma\u00dfstab, d.h. durch Anwendung standardisierter Techniken f\u00fcr alle Produkte des Unternehmens. Mit dem Aufkommen von DevOps haben die Entwickler teilweise Funktionen verloren, da sie nun selbst die Produkte f\u00fcr die Lieferung vorbereiten. Angesichts der sich ver\u00e4ndernden Infrastruktur und dem Ansatz, m\u00f6glichst schnell ohne R\u00fccksicht auf die Qualit\u00e4t zu liefern, sind sie im Laufe der Zeit eher zu einem Hemmnis f\u00fcr Ver\u00e4nderungen geworden, da die Einhaltung von Qualit\u00e4tsstandards die Auslieferung unvermeidlich verlangsamt. So hat nach und nach ein Teil der Aufgaben der Build-\/Release-Ingenieure auf die Schultern der Systemadministratoren \u00fcbergegriffen.<\/p>\n

<\/p>\n

Ops sind so unterschiedlich<\/h2>\n

<\/p>\n

Wir bewegen uns weiter und erneut dr\u00e4ngt uns die Vielzahl an Aufgaben und der Mangel an qualifiziertem Personal zu einer strengen Spezialisierung. Wie Pilze nach dem Regen tauchen verschiedene Operations auf:<\/p>\n

<\/p>\n