{"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":"

Derzeit ist dies wohl die teuerste Position auf dem Markt. Der Hype um \u201eDevOps\u201c-Ingenieure \u00fcbersteigt alle erdenklichen Grenzen, und das gilt umso mehr f\u00fcr Senior DevOps Ingenieure.
\nIch arbeite als Leiter der Abteilung f\u00fcr Integration und Automatisierung, die englische Bezeichnung ist DevOps Manager. Spiegelt diese englische Bezeichnung unsere t\u00e4gliche Arbeit wider? Wahrscheinlich nicht, aber die russische Variante ist in diesem Fall treffender. In meinem Beruf ist es nat\u00fcrlich erforderlich, zuk\u00fcnftige Mitglieder meines Teams zu interviewen, und im vergangenen Jahr habe ich etwa 50 Personen durch diese Gespr\u00e4che gef\u00fchrt, w\u00e4hrend noch einmal so viele in den Vorkandidaten f\u00fcr meine Mitarbeiter herausgefiltert wurden.<\/p>\n

<\/p>\n

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

<\/p>\n

Alles, was unten steht, ist meine pers\u00f6nliche Meinung; Sie sind nicht verpflichtet, damit \u00fcbereinzustimmen, aber ich gebe zu, dass es Ihren Blick auf das Thema beeinflussen k\u00f6nnte. Trotz des Risikos, in Ungnade zu fallen, ver\u00f6ffentliche ich meine Meinung, da ich denke, dass sie einen Platz hat.<\/p>\n

<\/p>\n

Unternehmen haben unterschiedliche Vorstellungen davon, wer DevOps-Ingenieure sind, und kleben diesem Label h\u00e4ufig jedem an, um schnell Ressourcen zu finden. Die Situation ist ziemlich merkw\u00fcrdig, da Firmen bereit sind, diesen Personen unrealistische Verg\u00fctungen zu zahlen, w\u00e4hrend sie in den meisten F\u00e4llen nur einen Tools-Administrator erhalten.<\/p>\n

<\/p>\n

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

<\/p>\n

Lassen Sie uns mit der Geschichte beginnen \u2013 Development Operations entstand als weiterer Schritt zur Optimierung der Zusammenarbeit in kleinen Teams, um die Produktgeschwindigkeit zu erh\u00f6hen. Die Grundidee war, das Entwicklungsteam mit Wissen \u00fcber Prozesse und Ans\u00e4tze im Management der Produktumgebung zu bereichern. Mit anderen Worten, ein Entwickler sollte verstehen, wie sein Produkt unter verschiedenen Bedingungen funktioniert, er sollte wissen, wie man sein Produkt bereitstellt und welche Umgebungsparameter angepasst werden m\u00fcssen, um die Leistung zu steigern. So entstanden im Laufe der Zeit Entwickler mit einem DevOps Ansatz. DevOps-Entwickler schrieben Skripte f\u00fcr den Build- und Verpackungsprozess, um ihre Arbeit und die Funktionalit\u00e4t der Produktionsumgebung zu erleichtern. Die Komplexit\u00e4t der L\u00f6sungsarchitektur und das gegenseitige Zusammenspiel der Infrastrukturkomponenten begannen jedoch mit der Zeit, die Leistungskennzahlen der Umgebungen zu verschlechtern. Mit jeder Iteration wurde ein tieferes Verst\u00e4ndnis f\u00fcr bestimmte Komponenten erforderlich, was die Produktivit\u00e4t des Entwicklers aufgrund zus\u00e4tzlicher Anstrengungen zur Verst\u00e4ndnisschaffung und Systemoptimierung f\u00fcr spezifische Aufgaben reduzierte. Die Kosten f\u00fcr den Entwickler stiegen, ebenso die Produktkosten, w\u00e4hrend die Anforderungen an neue Entwickler im Team sprunghaft anstiegen, da diese auch die Pflichten eines \u201eStars\u201c der Entwicklung \u00fcbernehmen mussten; verst\u00e4ndlicherweise wurden solche \u201eStars\u201c immer weniger verf\u00fcgbar. Zudem m\u00f6chte ich anmerken, dass aus meiner Erfahrung nur wenige Entwickler interessiert an den spezifischen Aspekten der Paketverarbeitung durch den Kernel des Betriebssystems, den Regeln der Paketweiterleitung und den Sicherheitsaspekten des Hosts sind. Ein logischer Schritt war daher, einen Administrator hinzuzuziehen, der damit vertraut ist, und ihm diese Aufgaben zu \u00fcbertragen. Dank seiner Erfahrung konnten die gleichen Leistungskennzahlen zu geringeren Kosten im Vergleich zu den Kosten eines \u201eStars\u201c in der Entwicklung erreicht werden. Diese Administratoren wurden in das Team integriert, und seine Hauptaufgabe war das Management der Test- und Produktionsumgebungen gem\u00e4\u00df den spezifischen Regeln des jeweiligen Teams sowie mit den f\u00fcr dieses Team bereitgestellten Ressourcen. So entstanden letztlich die DevOps im Verst\u00e4ndnis der meisten.<\/p>\n

<\/p>\n

Im Laufe der Zeit begannen diese Systemadministratoren zunehmend, die spezifischen Anforderungen ihres Entwicklungsteams zu verstehen. Sie lernten, wie sie das Leben f\u00fcr Entwickler und Tester erleichtern konnten, wie sie Updates erfolgreich einspielen und vermeiden konnten, am Freitagabend im B\u00fcro zu bleiben, um Deployments zu reparieren. Mit der Zeit wurden Systemadministratoren zu den wahren Experten, die die W\u00fcnsche der Entwickler erfassten. Um die Auswirkungen zu minimieren, wurden Verwaltungstools integriert, und alle erinnerten sich an bew\u00e4hrte Isolationstechniken auf Betriebssystemebene, die die Sicherheitsanforderungen, die Netzwerkverwaltung und die gesamte Hostkonfiguration optimierten, wodurch die Anforderungen an die neuen \u201eExperten\u201c gesenkt wurden. <\/p>\n

<\/p>\n

Eine \"bemerkenswerte\" Erfindung ist aufgekommen \u2013 Docker. Warum bemerkenswert? Weil die Erstellung von Isolierungen in chroot oder jail, sowie mit OpenVZ, ein umfangreiches Wissen \u00fcber das Betriebssystem erforderte. Mit dieser praktischen L\u00f6sung k\u00f6nnen Sie jedoch ganz einfach eine isolierte Anwendungsumgebung auf einem Host mit allem Notwendigen schaffen und die Kontrolle wieder an die Entwickler \u00fcbergeben, w\u00e4hrend der Systemadministrator sich ausschlie\u00dflich um einen einzigen Host k\u00fcmmert, um dessen Sicherheit und hohe Verf\u00fcgbarkeit zu gew\u00e4hrleisten \u2013 eine logischere Vereinfachung. Aber der Fortschritt bleibt nicht stehen, und die Systeme werden zunehmend komplexer, mit immer mehr Komponenten. Ein einzelner Host gen\u00fcgt nicht mehr den Anforderungen des Systems, weshalb Cluster aufgebaut werden m\u00fcssen. Hierbei kehren wir wieder zu den Systemadministratoren zur\u00fcck, die in der Lage sind, solche Systeme zu konstruieren.<\/p>\n

<\/p>\n

Mit jeder Iteration entstehen verschiedene Systeme, die die Entwicklung und\/oder Administration vereinfachen. Es entstehen Orchestrierungssysteme, die bis zu dem Punkt einfach zu bedienen sind, an dem man von den Standardprozessen abweichen muss. Auch die mikroservices Architektur wurde eingef\u00fchrt, um all das oben Beschriebene zu vereinfachen \u2013 weniger Wechselwirkungen, einfacher zu verwalten. In meiner Erfahrung habe ich nie eine vollst\u00e4ndig mikroservices Architektur gesehen; ich w\u00fcrde sagen, es ist 50 zu 50 \u2013 50 Prozent Mikroservices, schwarze Boxen, die Informationen verarbeiten, und die anderen 50 Prozent sind monolithisch fragmentierte Systeme, deren Dienste ohne die anderen Komponenten nicht unabh\u00e4ngig funktionieren k\u00f6nnen. All dies schr\u00e4nkt wiederum das Wissen sowohl von Entwicklern als auch von Administratoren ein.<\/p>\n

<\/p>\n

Solche 'Schaukelbewegungen' im Expertenwissen \u00fcber bestimmte Ressourcen halten bis heute an. Aber das f\u00fchrt uns etwas ab vom Thema; es gibt viele Aspekte, die es zu beleuchten gilt.<\/p>\n

<\/p>\n

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

<\/p>\n

Hochspezialisierte Ingenieure, die als Mittel zur Standardisierung der Software-Bauprozesse und deren Bereitstellung entstanden sind. Im Zuge der Einf\u00fchrung von Agile schien es, als w\u00fcrden sie an Bedeutung verlieren, jedoch ist das keineswegs der Fall. Diese Spezialisierung entstand, um genau die Standardisierung der Softwareentwicklung und -liefermengen in einem industriellen Ma\u00dfstab zu erm\u00f6glichen, d.h. durch die Anwendung g\u00e4ngiger Techniken f\u00fcr alle Produkte des Unternehmens. Mit dem Aufkommen von DevOps haben Entwickler teilweise Funktionen verloren, da sie nun selbst f\u00fcr die Vorbereitung des Produkts zur Auslieferung verantwortlich sind. Angesichts der sich ver\u00e4ndernden Infrastruktur und der Ausrichtung auf eine maximal schnelle Lieferung ohne R\u00fccksicht auf die Qualit\u00e4t hat sich dies im Laufe der Zeit in ein Hindernis f\u00fcr Ver\u00e4nderungen verwandelt, denn das Festhalten an Qualit\u00e4tsstandards verlangsamt zwangsl\u00e4ufig die Bereitstellung. So wurde schrittweise ein Teil der Aufgaben der Build-\/Release-Ingenieure auf die Schultern der Systemadministratoren \u00fcbertragen.<\/p>\n

<\/p>\n

Ops sind so unterschiedlich<\/h2>\n

<\/p>\n

Wir machen weiter und erneut zwingt uns ein breites Spektrum an Aufgaben und der Mangel an qualifiziertem Personal zur strikten Spezialisierung. Wie Pilze nach dem Regen entstehen verschiedene Operations:<\/p>\n

<\/p>\n