{"id":33725,"date":"2019-10-31T21:54:21","date_gmt":"2019-10-31T18:54:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/chto-takoe-devops\/"},"modified":"2019-10-31T21:54:21","modified_gmt":"2019-10-31T18:54:21","slug":"chto-takoe-devops","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/chto-takoe-devops","title":{"rendered":"Was ist DevOps","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Die Definition von DevOps ist sehr komplex, weshalb wir jedes Mal die Diskussion dar\u00fcber neu beginnen m\u00fcssen. Allein auf Habr\u00e9 gibt es tausende von Ver\u00f6ffentlichungen zu diesem Thema. Aber wenn Sie das hier lesen, wissen Sie sicherlich, was DevOps ist. Denn ich \u2013 wei\u00df es nicht. Hallo, ich bin Alexander Titov (@osminog<\/a><\/noindex><\/b>), und wir werden einfach \u00fcber DevOps sprechen und ich werde meine Erfahrungen teilen.<\/p>\n

\"Was
\n
\nIch habe lange dar\u00fcber nachgedacht, wie ich meine Erz\u00e4hlung n\u00fctzlich gestalten kann, weshalb es hier viele Fragen geben wird \u2013 sowohl die, die ich mir selbst stelle, als auch die, die ich unseren Kunden stelle. Indem ich diese Fragen beantworte, wird das Verst\u00e4ndnis klarer. Ich werde erkl\u00e4ren, warum DevOps meiner Meinung nach notwendig ist, was es ist, wieder aus meiner Sicht, und wie Sie erkennen k\u00f6nnen, ob Sie auf dem Weg zu DevOps sind \u2013 wieder aus meiner Perspektive. Der letzte Punkt wird durch Fragen vermittelt. Wenn Sie diese selbst beantworten, k\u00f6nnen Sie verstehen, ob Ihr Unternehmen auf dem Weg zu DevOps ist oder ob es irgendwo Probleme gibt.
\n<\/a><\/noindex>
\n

\r\n \"Video\r\n
<\/div>\r\n <\/div><\/center>
\nEinst bin ich durch die Wellen von Fusionen und \u00dcbernahmen geschwommen. Zuerst arbeitete ich bei einem kleinen Startup namens Qik, dann wurde es von dem etwas gr\u00f6\u00dferen Unternehmen Skype \u00fcbernommen, welches sp\u00e4ter von Microsoft, dem noch gr\u00f6\u00dferen Unternehmen, gekauft wurde. In diesem Moment wurde mir klar, wie sich die Vorstellungen von DevOps in Unternehmen unterschiedlicher Gr\u00f6\u00dfen ver\u00e4ndern. Danach begann ich, den Markt aus der Perspektive von DevOps zu betrachten, und zusammen mit meinen Kollegen gr\u00fcndeten wir die Firma Express 42. Seit 6 Jahren navigieren wir mit ihr durch die Marktwellen.<\/p>\n

Nebenbei bin ich einer der Organisatoren der Community DevOps Moscow und Organisator der DevOps-Days 2017, aber 2018 habe ich nicht organisiert. Express 42 arbeitet mit vielen Unternehmen zusammen. Wir entwickeln dort DevOps, beobachten, wie es geschieht, ziehen Schlussfolgerungen, analysieren, teilen unsere Erkenntnisse und schulen Menschen in DevOps-Praktiken. Kurz gesagt, wir f\u00f6rdern in dieser Hinsicht Erfahrung und Expertise.<\/p>\n

Warum DevOps<\/h2>\n

\nDie erste Frage, die alle st\u00e4ndig besch\u00e4ftigt \u2013 warum? Viele glauben, dass DevOps einfach Automatisierung oder ein \u00e4hnliches Konzept ist, das bereits in jedem Unternehmen vorhanden war.<\/p>\n

\u2014 Bei uns gab es Continuous Integration \u2014 das bedeutet, es gab bereits DevOps. Warum ist das alles n\u00f6tig? Im Ausland haben sie Spa\u00df, w\u00e4hrend wir arbeiten m\u00fcssen!<\/i><\/p>\n

Nach 9 Jahren Entwicklung der Community und Methodik ist klar geworden, dass es sich nicht um blo\u00dfe Marketingblitze handelt, aber es ist immer noch nicht ganz klar, wof\u00fcr es n\u00f6tig ist. Wie bei jedem Werkzeug oder Prozess hat auch DevOps spezifische Ziele, die es letztendlich erreicht.<\/p>\n

Das alles h\u00e4ngt damit zusammen, dass sich die Welt ver\u00e4ndert. Sie weicht vom Enterprise-Ansatz ab, wo Unternehmen direkt zu ihrem Ziel eilen, wie unser Petersburger Klassiker sang, von Punkt A nach Punkt B auf einer bestimmten Strategie, mit einer daf\u00fcr festgelegten Struktur. <\/p>\n

\"Was
\n<\/p>\n

Im Prinzip sollte in der IT alles nach diesem Ansatz aufgebaut sein. Hier wird IT ausschlie\u00dflich zur Automatisierung von Prozessen genutzt.<\/p><\/blockquote>\n

\nAutomatisierung \u00e4ndert sich nicht oft, denn wenn ein Unternehmen im alten Trott unterwegs ist \u2013 was gibt es da zu \u00e4ndern? Wenn es l\u00e4uft, lass es so. Jetzt ver\u00e4ndert sich die Herangehensweise in der Welt, und der, der als Agile bezeichnet wird, sagt, dass das endg\u00fcltige Ziel B nicht sofort sichtbar ist.<\/p>\n

\"Was
\n
\nWenn ein Unternehmen den Markt durchquert und mit den Kunden interagiert, erforscht es st\u00e4ndig den Markt und \u00e4ndert seinen Endpunkt B. Je \u00f6fter ein Unternehmen seine Richtung \u00e4ndert, desto erfolgreicher wird es letztlich, da es mehr Marktnischen w\u00e4hlt.<\/p>\n

Eine interessante Strategie wird von einem Unternehmen demonstriert, von dem ich k\u00fcrzlich erfahren habe. One Box Shave ist ein Abonnementdienst, der Rasierklingen und Rasierzubeh\u00f6r in einer Box liefert. Sie k\u00f6nnen ihre \"Box\" f\u00fcr verschiedene Kunden anpassen. Daf\u00fcr wird eine spezielle Software verwendet, die die Bestellung an die koreanische Fabrik weiterleitet, die die Waren produziert.<\/p>\n

Dieses Produkt wurde von Unilever f\u00fcr 1 Milliarde Dollar \u00fcbernommen. Jetzt konkurriert es mit Gillette und hat einen erheblichen Marktanteil bei den Verbrauchern in den USA gewonnen. One Box Shave sagt:<\/p>\n

\u2014 4 Klingen? Wirklich? Warum brauchen Sie das? Es verbessert keinesfalls die Rasierqualit\u00e4t. Ein speziell ausgew\u00e4hlter Rasierschaum, Duft und ein hochwertiger Rasierer mit zwei Klingen l\u00f6sen viel mehr Probleme als diese l\u00e4cherlichen 4 Gillette-Klingen! Gehen wir bald auf 10 zur\u00fcck?<\/i><\/p>\n

So ver\u00e4ndert sich die Welt. Unilever berichtet, dass sie ein beeindruckendes IT-System haben, das dies erm\u00f6glicht. Am Ende sieht das wie ein Konzept aus. Markteinf\u00fchrungszeit<\/b>, \u00fcber das schon viele gesprochen haben.<\/p>\n

\"Was
\n
\nDer Sinn der Markteinf\u00fchrungszeit liegt nicht darin, wie h\u00e4ufig wir bereitstellen. Man kann h\u00e4ufig bereitstellen, aber die Release-Zyklen k\u00f6nnen lang sein. Wenn man drei Monate lange Release-Zyklen aneinanderreiht und jeweils um eine Woche verschiebt, scheint es, als w\u00fcrde das Unternehmen einmal pro Woche bereitstellen. Doch von der Idee bis zur endg\u00fcltigen Umsetzung vergehen drei Monate.<\/p>\n

Die Markteinf\u00fchrungszeit bedeutet, die Zeit von der Idee bis zur endg\u00fcltigen Umsetzung zu minimieren.<\/p><\/blockquote>\n

\nIn diesem Fall interagiert die Software mit dem Markt. So kommuniziert die Website von One Box Shave mit dem Kunden. Es gibt keine Verk\u00e4ufer \u2013 nur eine Website, auf der der Besucher klickt und W\u00fcnsche hinterl\u00e4sst. Daher muss auf der Website st\u00e4ndig etwas Neues bereitgestellt werden, und sie sollte gem\u00e4\u00df den W\u00fcnschen aktualisiert werden. Zum Beispiel wird in S\u00fcdkorea anders rasiert als in Russland, und sie m\u00f6gen es nicht, wenn es nach Kiefer riecht, sondern beispielsweise nach Karottenvanille.<\/p>\n

Da sich die Anforderungen an die Webseite schnell \u00e4ndern, wandelt sich die Softwareentwicklung erheblich. Durch Software m\u00fcssen wir herausfinden, was der Kunde m\u00f6chte. Fr\u00fcher erfuhren wir das \u00fcber Umwege, beispielsweise durch das Business Management. Dann entwarfen wir L\u00f6sungen, \u00fcbertrugen die Anforderungen in das IT-System, und alles funktionierte bestens. Heute l\u00e4uft es anders \u2013 die Software wird von allen Beteiligten im Prozess entworfen, einschlie\u00dflich der Ingenieure, die \u00fcber technische Spezifikationen erfahren, wie der Markt funktioniert, und ebenfalls ihre Einsichten mit dem Business teilen.<\/p>\n

Zum Beispiel erfuhren wir bei Qik pl\u00f6tzlich, dass die Leute es sehr sch\u00e4tzen, Kontaktlisten auf unseren Server hochzuladen, und sie haben uns eine App bereitgestellt. Daran hatten wir anfangs nicht gedacht. In einem traditionellen Unternehmen h\u00e4tte man dies wahrscheinlich als Bug interpretiert, da in den Spezifikationen nicht steht, dass es gut funktionieren sollte und alles improvisiert war. Man h\u00e4tte diese Funktion abgeschaltet und gesagt: \u201eDas ben\u00f6tigt niemand, das Wichtigste ist, dass die grundlegende Funktionalit\u00e4t funktioniert.\u201c Ein technologieorientiertes Unternehmen erkennt jedoch die Chance darin und beginnt, die Software entsprechend zu \u00e4ndern.<\/p>\n

\"Was
\n
\nIm Jahr 1968 formulierte der weitsichtige Melvin Conway die folgende Idee.<\/p>\n

Eine Organisation, die ein System schafft, ist durch ein Design eingeschr\u00e4nkt, das die Kommunikationsstruktur in dieser Organisation kopiert.<\/p><\/blockquote>\n

\nUm genauer zu sein, ben\u00f6tigt man f\u00fcr die Entwicklung anderer Arten von Systemen zudem eine Kommunikationsstruktur in der Firma, die von anderer Art ist. Wenn Ihre Kommunikationsstruktur hierarchisch ist, wird es Ihnen nicht m\u00f6glich sein, Systeme zu schaffen, die eine sehr hohe Time-to-Market gew\u00e4hrleisten k\u00f6nnen.<\/p>\n

Mehr lesen \u00fcber das Conway-Gesetz<\/a><\/noindex> kann durch die Links<\/a><\/noindex>. Es ist wichtig f\u00fcr das Verst\u00e4ndnis der Kultur oder Philosophie von DevOps, da das Einzige, was sich grundlegend in DevOps \u00e4ndert, die Kommunikationsstruktur zwischen den Teams ist.<\/b>.<\/p>\n

Aus der Sicht des Prozesses liefen vor DevOps alle Phasen: Analyse, Entwicklung, Test und Betrieb linear ab.\"Was
\nIm Fall von DevOps verlaufen all diese Prozesse gleichzeitig.<\/p>\n

\"Was
\n
\nNur so kann die Time-to-Market erreicht werden. F\u00fcr Menschen, die im alten Prozess gearbeitet haben, erscheint das etwas futuristisch und insgesamt eher ungewohnt.<\/p>\n

Warum ist DevOps also notwendig?<\/h3>\n

\nF\u00fcr die Entwicklung digitaler Produkte<\/b>. Wenn Ihr Unternehmen kein digitales Produkt hat, ist DevOps nicht erforderlich \u2013 das ist sehr wichtig.<\/p>\n

DevOps \u00fcberwindet die Geschwindigkeitsbeschr\u00e4nkungen des sequenziellen Softwareentwicklungsprozesses.<\/b>. In ihm laufen alle Prozesse gleichzeitig ab.<\/p>\n

Die Komplexit\u00e4t nimmt zu.<\/b> Wenn DevOps-Evangelisten sagen, dass es mit ihm einfacher wird, Software zu ver\u00f6ffentlichen \u2013 das ist Unsinn.<\/p>\n

Mit DevOps wird alles nur komplizierter.<\/p><\/blockquote>\n

\nAuf der Konferenz am Stand von Avito konnte man sehen, was es bedeutet, einen Docker-Container zu deployen \u2013 eine unm\u00f6gliche Aufgabe. Die Komplexit\u00e4t wird \u00fcberdimensioniert, man muss viele B\u00e4lle gleichzeitig jonglieren.<\/p>\n

DevOps \u00e4ndert den gesamten Prozess und die Organisation im Unternehmen.<\/b>\u00a0Genauer gesagt, \u00e4ndert nicht DevOps, sondern das digitale Produkt. Um zu DevOps zu gelangen, muss dieser Prozess vollst\u00e4ndig ge\u00e4ndert werden.<\/p>\n

Fragen f\u00fcr Fachleute.<\/h3>\n

\nUnd wie sieht es bei Ihnen aus? Fragen, die Sie sich stellen k\u00f6nnen, w\u00e4hrend Sie im Unternehmen arbeiten und sich als Fachkraft weiterentwickeln.<\/p>\n

Haben Sie eine Strategie zur Erstellung eines digitalen Produkts?<\/b> Wenn ja \u2013 schon gut. Das bedeutet, dass Ihr Unternehmen in Richtung DevOps geht.<\/p>\n

Erstellt Ihr Unternehmen bereits ein digitales Produkt?<\/b> Das bedeutet, dass Sie eine Stufe h\u00f6her steigen und interessantere Dinge tun k\u00f6nnen \u2013 aus der Perspektive von DevOps. Ich spreche nur aus dieser Perspektive.<\/p>\n

Ist Ihr Unternehmen einer der Marktf\u00fchrer im Bereich digitaler Produkte?<\/b> Spotify, Yandex, Uber \u2013 Unternehmen, die derzeit an der Spitze des technologischen Fortschritts stehen.<\/p>\n

Stellen Sie sich diese Fragen, und wenn alle Antworten negativ sind, dann sollten Sie vielleicht in Ihrem Unternehmen kein DevOps betreiben. Wenn DevOps jedoch wirklich f\u00fcr Sie von Interesse ist, sollten Sie vielleicht in ein anderes Unternehmen wechseln? Wenn Ihr Unternehmen in DevOps investieren m\u00f6chte, aber Sie auf alle Fragen mit 'Nein' geantwortet haben, dann erinnert es an das wundervolle Nashorn, das sich niemals \u00e4ndern wird.<\/p>\n

\"Was
\n<\/p>\n

Organisation<\/h2>\n

\nWie bereits erw\u00e4hnt, \u00e4ndert sich die Organisation im Unternehmen gem\u00e4\u00df dem Conway-Gesetz. Ich beginne mit dem, was DevOps daran hindert, in das Unternehmen einzudringen, insbesondere aus organisatorischer Sicht.<\/p>\n

Das Problem der \u201eSilos\u201c<\/h3>\n

\nDas englische Wort \u201eSilo\u201c wurde hier ins Russische als \u201e\u043a\u043e\u043b\u043e\u0434\u0435\u0446\u201c \u00fcbersetzt. Das Wesen dieses Problems ist, dass zwischen den Teams kein Informationsaustausch stattfindet.<\/b>. Jedes Team vertieft seine Expertise, ohne eine gemeinsame Karte zu erstellen, auf der man sich orientieren kann.<\/p>\n

Das erinnert an jemanden, der gerade nach Berlin gekommen ist und noch nicht wei\u00df, wie man sich im U-Bahn-Netz zurechtfindet. Berliner kennen normalerweise ihren Kiez sehr gut, und in ganz Berlin orientieren sie sich am U-Bahn-Netz. Wenn man zum ersten Mal nach Berlin kommt, hat man diese F\u00e4higkeit nicht, und man f\u00fchlt sich einfach verloren.<\/p>\n

DevOps bietet an, diese Phase der Desorientierung zu \u00fcberwinden und gemeinsam eine Karte der Interaktionen zu erstellen.<\/p><\/blockquote>\n

\nZwei Faktoren stehen dem entgegen.<\/p>\n

Das Ergebnis eines Unternehmensmanagementsystems.<\/b> Es besteht aus separaten hierarchischen \"Brunnen\". Beispielsweise gibt es bestimmte KPIs in Unternehmen, die dieses System unterst\u00fctzen. Auf der anderen Seite stehen die Gedanken der Person, die es schwer hat, \u00fcber ihre Expertise hinauszusehen und sich im gesamten System zurechtzufinden. Das ist einfach unbequem. Stellen Sie sich vor, Sie sind am Flughafen in Bangkok \u2013 dort findet man sich nicht schnell zurecht. Auch im DevOps-Bereich ist es schwierig, sich zu orientieren, weshalb die Leute sagen, dass man einen F\u00fchrer finden muss, um dorthin zu gelangen.<\/p>\n

Das Hauptproblem, das Ingenieure, die sich dem Geist von DevOps verschrieben haben und viele B\u00fccher von Fowler und anderen gelesen haben, betrifft die sogenannten \"Brunnen\". \"Brunnen\" hindern uns daran, \"offensichtliche\" Dinge zu tun.<\/b>Oft treffen wir uns nach dem DevOps Moscow, reden miteinander, und die Leute beklagen sich:<\/p>\n

\u2014 Wir wollten einfach nur CI starten, aber es stellte sich heraus, dass das f\u00fcr das Management nicht notwendig ist.<\/i><\/p>\n

Das passiert genau deshalb, weil\u00a0CI <\/b>und\u00a0der Continuous Delivery-Prozess<\/b> an der Schnittstelle vieler Fachgebiete liegt. Ohne das Problem der \"Brunnen\" auf organisatorischer Ebene zu \u00fcberwinden, wird es nicht m\u00f6glich sein, weiterzukommen, egal was Sie tun und wie traurig das auch sein mag.<\/p>\n

\"Was
\n
\nJeder Teilnehmer im Unternehmen \u2014 Backend- und Frontend-Entwickler, Tester, DBA, Betrieb, Netzwerk \u2014 gr\u00e4bt in seine eigene Richtung, w\u00e4hrend niemand ansonsten eine gemeinsame Karte hat, au\u00dfer dem Manager, der sie irgendwie \u00fcberblickt und nach dem Prinzip \"teile und herrsche\" verwaltet.<\/p>\n

Die Menschen k\u00e4mpfen um irgendwelche Sterne oder Flaggen, jeder gr\u00e4bt in seiner eigenen Expertise.<\/p><\/blockquote>\n

\nWenn die Aufgabe besteht, all dies zusammenzuf\u00fchren und eine gemeinsame Pipeline zu erstellen, stellt sich die Frage \u2013 was sollen wir \u00fcberhaupt tun? Man muss sich irgendwie verst\u00e4ndigen, aber wie? Das hat uns in der Schule niemand beigebracht. Wir haben bereits in der Schule gelernt: die achte Klasse \u2013 wow! \u2013 im Vergleich zur siebten Klasse! Hier ist es dasselbe.<\/p>\n

Ist das auch in Ihrem Unternehmen so?<\/h3>\n

\nUm das zu \u00fcberpr\u00fcfen, k\u00f6nnen Sie sich folgende Fragen stellen.<\/p>\n

Verwenden die Teams gemeinsame Werkzeuge und tragen sie zur \u00c4nderung dieser gemeinsamen Werkzeuge bei?<\/p>\n

Wie oft werden Teams umgebildet \u2013 wechseln Fachleute von einem Team in ein anderes?<\/b> Gerade im DevOps-Umfeld wird dies zur Normalit\u00e4t, da jemand manchmal einfach nicht verstehen kann, womit ein anderer Fachbereich besch\u00e4ftigt ist. Er wechselt in eine andere Abteilung, arbeitet dort zwei Wochen, um sich eine Orientierungskarte und die Interaktionen mit diesem Bereich zu erstellen.<\/p>\n

Kann ein Ver\u00e4nderungskomitee gegr\u00fcndet werden, um etwas zu \u00e4ndern? <\/b>Oder ben\u00f6tigt man daf\u00fcr die Unterst\u00fctzung der h\u00f6chsten F\u00fchrungsebene und einen entsprechenden Befehl? K\u00fcrzlich habe ich auf Facebook geschrieben, wie eine wenig bekannte Bank durch Befehle Tools implementiert: Sie gaben einen Befehl heraus, implementieren ein Jahr lang und beobachten, was passiert. Das ist nat\u00fcrlich langwierig und bedauerlich.<\/p>\n

Wie wichtig ist es f\u00fcr Manager, pers\u00f6nliche Erfolge zu erzielen, unabh\u00e4ngig von den Leistungen des Unternehmens? <\/b><\/p>\n

Wenn Sie sich diese Fragen selbst beantworten, wird klarer, ob Sie dieses Problem in Ihrem Unternehmen haben.<\/p>\n

Infrastruktur als Code<\/h2>\n

\nNachdem dieses Problem \u00fcberwunden ist, ist die erste wichtige Praxis, ohne die es schwierig ist, im DevOps-Bereich weiterzukommen \u2013 Infrastruktur als Code<\/b>. <\/p>\n

Am h\u00e4ufigsten wird Infrastruktur als Code so wahrgenommen:<\/p>\n

\u2013 Lassen Sie uns alles mit Bash automatisieren, uns mit Skripten eindecken, damit die Admins weniger manuelle Arbeit haben!<\/i><\/p>\n

Aber das ist nicht so.<\/p>\n

Infrastruktur als Code bedeutet, dass Sie das IT-System, mit dem Sie arbeiten, in Form von Code beschreiben, um seinen Zustand st\u00e4ndig zu verstehen.<\/p><\/blockquote>\n

\nGemeinsam mit anderen Teams erstellen Sie eine Code-Karte, die f\u00fcr alle verst\u00e4ndlich ist und als Orientierung dient. Es spielt keine Rolle, ob dies mit Chef, Ansible, Salt oder YAML-Dateien in Kubernetes geschieht \u2013 der Unterschied ist irrelevant.<\/p>\n

Auf der Konferenz berichtete ein Kollege von 2GIS, wie sie ein internes Tool f\u00fcr Kubernetes entwickelt haben, das die Struktur einzelner Systeme beschreibt. Um 500 Systeme zu beschreiben, ben\u00f6tigten sie ein spezielles Werkzeug, das diese Beschreibung generiert. Mit dieser Beschreibung kann jeder miteinander abgleichen, \u00c4nderungen \u00fcberwachen und sehen, wie man sie anpassen und verbessern kann, sowie was fehlt. <\/p>\n

Sie werden zustimmen, dass einzelne Bash-Skripte normalerweise nicht dieses Verst\u00e4ndnis bieten. In einem der Unternehmen, in denen ich gearbeitet habe, gab es sogar den Begriff \u201ewrite only\u201c-Skript \u2013 wenn das Skript geschrieben ist, ist es unm\u00f6glich, es sp\u00e4ter zu lesen. Ich denke, das kommt Ihnen ebenfalls bekannt vor.<\/p>\n

Infrastructure as Code \u2013 das ist Code, der den aktuellen Zustand der Infrastruktur beschreibt<\/b>. An diesem Code arbeiten zahlreiche Produkt-, Infrastruktur- und Serviceteams gemeinsam, und das Wichtigste ist, dass alle verstehen, wie dieser Code funktioniert.<\/p>\n

Der Code wird gem\u00e4\u00df den besten Programmierpraktiken behandelt.<\/b>: gemeinschaftliche Entwicklung, Code-Reviews, XP-Programmierung, Tests, Pull-Requests, CI f\u00fcr Infrastruktur-Code \u2013 all das ist wertvoll und anwendbar.<\/p>\n

Code wird zur gemeinsamen Sprache f\u00fcr alle Ingenieure.<\/p><\/blockquote>\n

\nDie \u00c4nderung von Infrastruktur im Code nimmt nicht viel Zeit in Anspruch.<\/b>. Ja, auch im Infrastruktur-Code kann technischer Schulden entstehen. Normalerweise sto\u00dfen Teams nach etwa anderthalb Jahren, nachdem sie \u201eInfrastructure as Code\u201c eingef\u00fchrt haben, auf dieses Problem, wenn sie eine Vielzahl von Skripten oder sogar Ansible verwenden, die sie als Spaghetticode schreiben, und noch bash-Skripte hinzuf\u00fcgen! <\/p>\n

Wichtig<\/b>: Wenn Sie diesen Schrott noch nicht ausprobiert haben, merken Sie sich folgendes: Ansible ist kein Bash.<\/b>! Lesen Sie die Dokumentation sorgf\u00e4ltig und lernen Sie, was dar\u00fcber geschrieben wird.<\/p>\n

Infrastructure as Code bedeutet, den Infrastruktur-Code in separate Schichten zu unterteilen.<\/p><\/blockquote>\n

\nIn unserem Unternehmen unterscheiden wir drei grundlegende Schichten, die sehr verst\u00e4ndlich und einfach sind, aber es k\u00f6nnen auch mehr vorhanden sein. Sie k\u00f6nnen Ihren Infrastrukturcode \u00fcberpr\u00fcfen und feststellen, ob Sie diese Bedingung erf\u00fcllen oder nicht. Wenn keine Schichten definiert sind, sollten Sie sich Zeit nehmen und etwas refaktorisieren.
\n\"Was
\n
\nGrundschicht<\/b>\u00a0\u2014 das ist, wie das Betriebssystem, Backups und andere Low-Level-Aspekte konfiguriert werden, zum Beispiel, wie Kubernetes auf der Basisschicht bereitgestellt wird.<\/p>\n

Service-Level<\/b>\u00a0\u2014 das sind die Dienste, die Sie den Entwicklern zur Verf\u00fcgung stellen: Logging als Dienst, Monitoring als Dienst, Datenbank als Dienst, Lastverteilung als Dienst, Warteschlange als Dienst, Continuous Delivery als Dienst \u2014 eine Vielzahl von Diensten, die verschiedene Teams der Entwicklung anbieten k\u00f6nnen. All dies sollte in Ihrer Konfigurationsmanagement-System in separaten Modulen beschrieben werden.<\/p>\n

Schicht, in der Anwendungen erstellt werden<\/b> und beschrieben wird, wie sie auf den beiden vorherigen Schichten bereitgestellt werden.<\/p>\n

Kontrollfragen<\/h3>\n

\nVerf\u00fcgt Ihr Unternehmen \u00fcber ein gemeinsames Infrastruktur-Repository? Kontrollieren Sie die technische Schulden in der Infrastruktur? Wenden Sie Entwicklungsmethoden in Ihrem Infrastruktur-Repository an? Ist Ihre Infrastruktur in Schichten unterteilt? Sie k\u00f6nnen sich an das Schema Base-service-APP halten. Wie schwierig ist es, \u00c4nderungen vorzunehmen? <\/p>\n

Wenn Sie schon einmal erlebt haben, dass \u00c4nderungen eineinhalb Tage in Anspruch genommen haben, bedeutet das, dass Sie technische Schulden haben, mit denen Sie sich auseinandersetzen m\u00fcssen. Sie sind sozusagen auf die Probleme der technischen Schulden im Infrastrukturcode gesto\u00dfen. Ich erinnere mich an viele solche Geschichten, bei denen man, um ein CCTL zu \u00e4ndern, die H\u00e4lfte des Infrastrukturcodes umschreiben musste, weil Kreativit\u00e4t und der Wunsch, alles zu automatisieren, dazu gef\u00fchrt haben, dass alles \u00fcberladen ist, alle manuellen Eingriffe entfernt wurden und jetzt refaktoriert werden muss.<\/p>\n

Kontinuierliche Bereitstellung<\/h2>\n

\nLassen Sie uns die Debit- mit der Kreditseite ausgleichen. Zun\u00e4chst pr\u00e4sentieren wir eine grundlegende Beschreibung der Infrastruktur, die zwar einfach gehalten sein kann, aber dennoch erforderlich ist, um die weitere Arbeit zu erm\u00f6glichen. Ansonsten ist unklar, auf welcher Grundlage die kontinuierliche Lieferung erfolgen soll. All diese Praktiken laufen parallel, wenn Sie im Bereich DevOps t\u00e4tig werden, aber der Ausgangspunkt ist das Verst\u00e4ndnis, was Sie haben und wie Sie es verwalten. Dies entspricht der Praxis der Infrastruktur als Code.<\/p>\n

Sobald Sie verstanden haben, was Sie haben und wie Sie es verwalten k\u00f6nnen, beginnen Sie, Ideen zu entwickeln, wie der Code des Entwicklers so schnell wie m\u00f6glich in die Produktion gelangt. Ich meine das in Zusammenarbeit mit dem Entwickler \u2013 denken Sie an das Problem der 'Brunnen', das bedeutet, dass nicht Einzelne diese Ideen entwickeln, sondern das Team gemeinsam.<\/p>\n

Als wir mit\u00a0Ivan Evtuhoovich<\/b> das erste Buch von Jez Humble<\/b> und einer Gruppe von Autoren \u00abContinuous Delivery\u00bb<\/b>, die 2009 ver\u00f6ffentlicht wurde, hat lange dar\u00fcber nachgedacht, wie ihr Name ins Deutsche \u00fcbersetzt werden k\u00f6nnte. Wir wollten es als \u201ePermanent liefern\u201c \u00fcbersetzen, aber leider wurde es als \u201eKontinuierliche Lieferung\u201c \u00fcbersetzt. Ich habe das Gef\u00fchl, dass in unserem Namen etwas wirklich Deutsches steckt, mit einem gewissen Nachdruck.<\/p>\n

Permanent liefern bedeutet<\/h3>\n

\nDer Code, der im Produkt-Repository liegt, kann jederzeit in die Produktion \u00fcbernommen werden.<\/b>. Er kann zwar auch nicht \u00fcbernommen werden, ist aber immer bereit dazu. Dementsprechend schreiben Sie immer Code mit einem schwer erkl\u00e4rbaren Gef\u00fchl einer gewissen Unruhe im Nacken. Dieses Gef\u00fchl tritt h\u00e4ufig auf, wenn Sie Infrastrukturcode ausrollen. Dieses Gef\u00fchl der Unruhe sollte vorhanden sein \u2013 es l\u00f6st Denkprozesse aus, die es erm\u00f6glichen, etwas anders zu codieren. Es sollte in den Regeln innerhalb der Entwicklung festgehalten werden.<\/p>\n

Um permanent zu liefern, ist ein Artefaktformat erforderlich, das \u00fcber die Infrastrukturplattform verl\u00e4uft. <\/b>Wenn Sie verschiedene Formate von \u201eAbf\u00e4llen\u201c \u00fcber eine Infrastrukturplattform werfen, wird sie unvereinheitlicht, was die Wartung erschwert und technische Schulden verursacht. Das Format des Artefakts muss angeglichen werden \u2013 das ist auch eine gemeinsame Aufgabe: Alle m\u00fcssen zusammenkommen, kreativ denken und dieses Format entwickeln.<\/p>\n

Das Artefakt wird kontinuierlich verbessert und ver\u00e4ndert sich w\u00e4hrend der Bereitstellung im Produktionsumfeld im Laufe des Pipelines. <\/b>Wenn das Artefakt durch die Pipeline bewegt wird, trifft es st\u00e4ndig auf Herausforderungen, die ihm unangenehm sind und denen \u00e4hnlich sind, auf die das Artefakt st\u00f6\u00dft, das Sie in die Produktion bringen. W\u00e4hrend in der klassischen Entwicklung ein Systemadministrator f\u00fcr das Deployment verantwortlich ist, geschieht dies im DevOps-Prozess kontinuierlich: Hier wurde es durch verschiedene Tests gedreht, dort wurde es in einen Kubernetes-Cluster geworfen, der mehr oder weniger wie die Produktion aussieht, und pl\u00f6tzlich wurde ein Lasttest gestartet.<\/p>\n

Das erinnert ein wenig an das Spiel Pac-Man \u2013 Artefakte durchlaufen eine bestimmte Historie. Dabei ist es wichtig, zu kontrollieren, ob der Code tats\u00e4chlich dieser Historie folgt und ob sie mit Ihrer Produktion in Verbindung steht. Produktionsgeschichten k\u00f6nnen in den Continuous Delivery-Prozess integriert werden: Fr\u00fcher gab es Zeiten, als etwas abgest\u00fcrzt ist. Lassen Sie uns dieses Szenario einfach in das System programmieren. Jedes Mal wird der Code dieses Szenario ebenfalls durchlaufen, und beim n\u00e4chsten Mal werden Sie mit diesem Problem nicht konfrontiert. Sie werden viel fr\u00fcher dar\u00fcber informiert, bevor es Ihren Kunden erreicht.<\/p>\n

Verschiedene Deployment-Strategien. <\/b>Zum Beispiel nutzen Sie A\/B-Tests oder Canary-Deployments, um den Code auf verschiedenen Kunden auszuprobieren, Informationen dar\u00fcber zu erhalten, wie der Code funktioniert, und das viel fr\u00fcher, als wenn er auf 100 Millionen Benutzer ausgerollt wird.<\/p>\n

\u201eKontinuierliche Lieferung\u201c sieht so aus.<\/p>\n

\"Was
\n<\/p>\n

Der Prozess der Bereitstellung \u2013 Dev, CI, Test, PreProd, Prod \u2013 ist keine getrennte Umgebung, sondern Stufen oder Stationen mit festen Summen, durch die Ihr Artefakt l\u00e4uft.<\/p><\/blockquote>\n

\nWenn Sie Code f\u00fcr Infrastruktur haben, der als Base Service APP beschrieben ist, hilft er ihn nicht zu vergessen, alle Szenarien.<\/b>, und sie ebenfalls in Form von Code f\u00fcr dieses Artefakt festzuhalten, das Artefakt zu f\u00f6rdern<\/b> und es w\u00e4hrend des Fortschritts zu \u00e4ndern.<\/p>\n

Fragen zur Selbst\u00fcberpr\u00fcfung<\/h3>\n

\nLiegt die Zeit von der Beschreibung des Features bis zur Produktionsfreigabe in 95 % der F\u00e4lle unter einer Woche? Verbessert sich die Qualit\u00e4t des Artefakts in jeder Phase der Pipeline? Gibt es eine Historie, durch die es geht? Verwenden Sie unterschiedliche Bereitstellungsstrategien?<\/p>\n

Wenn alle Antworten ja sind, dann sind Sie unglaublich cool! Schreiben Sie die Antworten in die Kommentare \u2013 ich w\u00fcrde mich freuen).<\/p>\n

Feedback<\/h3>\n

\nDies ist die komplexeste Praxis von allen. Auf der DevOpsConf hatte ein Kollege von Infobip, der dar\u00fcber sprach, etwas Schwierigkeiten mit den Worten, weil es wirklich eine sehr komplexe Praxis ist, die besagt, dass man alles im Auge behalten muss!<\/p>\n

\"Was
\n
\nZum Beispiel, vor langer Zeit, als ich bei Qik arbeitete und wir erkannten, dass wir wirklich alles \u00fcberwachen mussten. Das haben wir gemacht, und in Zabbix hatten wir 150.000 Items, die st\u00e4ndig \u00fcberwacht wurden. Das war be\u00e4ngstigend, der technische Direktor drehte sich mit dem Finger an der Schl\u00e4fe:<\/p>\n

\u2014 Leute, warum qu\u00e4lt ihr den Server mit unklaren Dingen?<\/i><\/p>\n

Aber dann geschah ein Fall, der zeigte, dass dies tats\u00e4chlich eine sehr coole Strategie war.<\/p>\n

Einer unserer Dienste begann dauerhaft auszufallen. Interessanterweise fiel er urspr\u00fcnglich nicht aus, da dort kein zus\u00e4tzlicher Code hinzugef\u00fcgt wurde, weil es sich um einen einfachen Broker handelte, der fast keine Gesch\u00e4ftsfunktionalit\u00e4t hatte \u2013 er \u00fcbermittelte einfach Nachrichten zwischen verschiedenen Diensten. Der Service hatte sich \u00fcber 4 Monate nicht ver\u00e4ndert, und pl\u00f6tzlich begann er mit dem Fehler \u201eSegmentation fault\u201c auszufallen.<\/p>\n

Wir waren schockiert, als wir unsere Grafiken in Zabbix \u00f6ffneten und feststellten, dass sich das Verhalten der Anfragen im API-Service, der diesen Broker verwendet, vor anderthalb Wochen stark ver\u00e4ndert hatte. Danach \u00fcberpr\u00fcften wir, dass sich die Frequenz des Sendens eines bestimmten Nachrichtentyps ge\u00e4ndert hatte. Schlie\u00dflich fanden wir heraus, dass es sich um Android-Clients handelte. Wir fragten:<\/p>\n

\u2014 Guys, was ist vor anderthalb Wochen passiert?<\/i><\/p>\n

Im Gespr\u00e4ch h\u00f6rten wir eine interessante Geschichte dar\u00fcber, dass sie das UI \u00fcberarbeitet haben. Kaum jemand w\u00fcrde sofort sagen, dass sie die HTTP-Bibliothek gewechselt haben. F\u00fcr Android-Kunden ist es wie der Wechsel von Seife im Bad \u2013 sie merken das einfach nicht. Letztendlich fanden wir nach 40 Minuten Gespr\u00e4ch heraus, dass sie tats\u00e4chlich die HTTP-Bibliothek gewechselt haben und sich die Standard-Zeiten ge\u00e4ndert haben. Dies f\u00fchrte dazu, dass sich das Verhalten des Datenverkehrs auf dem API-Server ver\u00e4nderte, was zu einer Situation f\u00fchrte, die einen Wettlauf innerhalb des Brokers verursachte, wodurch dieser anfing, abzust\u00fcrzen.<\/p>\n

Ohne tiefgehendes Monitoring ist es v\u00f6llig unm\u00f6glich, das zu erkennen.<\/b>Wenn es jedoch in der Organisation das Problem der 'Brunnen' gibt, bei dem jeder die Verantwortung auf den anderen schiebt, kann dies jahrelang bestehen bleiben. Man startet einfach den Server neu, weil das Problem nicht gel\u00f6st werden kann. Wenn Sie alles \u00fcberwachen, nachverfolgen und s\u00e4mtliche Ereignisse dokumentieren, die Sie haben, und Monitoring als Test nutzen \u2013 indem Sie den Code schreiben und sofort angeben, wie er \u00fcberwacht werden soll, ebenfalls im Code (wir haben bereits Infrastruktur als Code), wird alles klar wie der Handfl\u00e4chen. Sogar so komplexe Probleme k\u00f6nnen leicht verfolgt werden.<\/p>\n

\"Was
\n<\/p>\n

Sammeln Sie alle Informationen dar\u00fcber, was mit dem Artefakt in jeder Phase des Lieferprozesses passiert \u2013 nicht in der Produktion.<\/p><\/blockquote>\n

\nLaden Sie das Monitoring in CI hoch, dort werden einige grundlegende Dinge sichtbar sein. Danach sehen Sie diese auch in Test, in PredProd und im Lasttest. Sammeln Sie Informationen in allen Phasen, nicht nur Metriken und Statistiken, sondern auch Logs: wie die Anwendung ausgerollt wurde, Anomalien \u2013 sammeln Sie alles. <\/p>\n

Andernfalls wird es schwierig sein, sich zurechtzufinden. Ich habe bereits gesagt, dass DevOps eine gr\u00f6\u00dfere Komplexit\u00e4t mit sich bringt. Um mit dieser Komplexit\u00e4t umzugehen, ben\u00f6tigen Sie eine solide Analyse.<\/b>.<\/p>\n

Fragen zur Selbstkontrolle<\/h3>\n

\nIst Ihr Monitoring und Logging ein Entwicklungstool f\u00fcr Sie?<\/b> Denken Ihre Entwickler, und Sie selbst auch, beim Codieren daran, wie man das Monitoring einrichtet?<\/p>\n

Erfahren Sie von Problemen durch Kunden? Verstehen Sie den Kunden besser durch Monitoring und Logging?<\/b> Verstehen Sie das System besser durch Monitoring und Logging?<\/b> \u00c4ndern Sie das System einfach, weil Sie sehen, dass der Trend im System steigt und wissen, dass in 3 Wochen alles zusammenbrechen wird? <\/p>\n

Wenn Sie diese drei Komponenten haben, k\u00f6nnen Sie dar\u00fcber nachdenken, welche Infrastrukturplattform Ihr Unternehmen hat.<\/p>\n

Infrastrukturplattform <\/h2>\n

\nEs geht nicht darum, dass es sich um eine Sammlung von separaten Werkzeugen handelt, die in jedem Unternehmen vorhanden sind.<\/p>\n

Der Sinn einer Infrastrukturplattform besteht darin, dass alle Teams diese Werkzeuge gemeinsam nutzen und weiterentwickeln.<\/p><\/blockquote>\n

\nEs ist klar, dass es separate Teams gibt, die f\u00fcr die Entwicklung bestimmter Teile der Infrastrukturplattform verantwortlich sind. Doch die Verantwortung f\u00fcr die Weiterentwicklung, Funktionsf\u00e4higkeit und F\u00f6rderung der Infrastrukturplattform tr\u00e4gt jeder Ingenieur. Auf interner Ebene wird dies zu einem gemeinsamen Werkzeug.<\/b>. <\/p>\n

Alle Teams entwickeln die Infrastrukturplattform und pflegen sie, als w\u00e4re sie ihr eigenes IDE.<\/b>. In Ihrem IDE installieren Sie verschiedene Plugins, um alles sch\u00f6n und schnell zu gestalten, und konfigurieren die Tastenkombinationen. Wenn Sie Sublime, Atom oder Visual Studio Code \u00f6ffnen, sehen Sie viele Code-Fehler und erkennen, dass es unm\u00f6glich ist, zu arbeiten, und das stimmt Sie sofort traurig, sodass Sie eilig beginnen, Ihr IDE zu reparieren.<\/p>\n

Behandeln Sie Ihre Infrastrukturplatform ebenso. Wenn Sie feststellen, dass etwas nicht stimmt, hinterlassen Sie eine Anfrage, falls Sie es nicht selbst beheben k\u00f6nnen. Wenn es jedoch etwas Einfaches ist, beheben Sie es selbst und senden Sie einen Pull-Request \u2013 das Team wird es pr\u00fcfen und hinzuf\u00fcgen. Dies ist ein etwas anderer Ansatz f\u00fcr das Ingenieurwerkzeug im Kopf des Entwicklers.<\/p>\n

Die Infrastrukturplatform erm\u00f6glicht den Transfer von Artefakten von der Entwicklung zum Kunden mit einer st\u00e4ndigen Qualit\u00e4tsverbesserung.<\/b>In der IP wurden eine Reihe von Geschichten programmiert, die mit dem Code in Produktion auftreten. Im Laufe der Jahre sind diese Geschichten sehr zahlreich geworden, einige davon sind einzigartig und beziehen sich nur auf Sie \u2013 sie sind nicht \u00fcber das Internet zu finden. <\/p>\n

In diesem Moment wird die Infrastrukturplatform zu Ihrem Wettbewerbsvorteil,<\/b>da darin enthalten ist, was beim Werkzeug des Wettbewerbers fehlt. Je tiefer Ihre IP ist, desto gr\u00f6\u00dfer ist Ihr Wettbewerbsvorteil in Bezug auf die Time-to-Market. Hier stellt sich die Problematik des Vendor-Lockings<\/b>: Sie k\u00f6nnen eine Plattform eines anderen \u00fcbernehmen, aber indem Sie die Erfahrung anderer nutzen, werden Sie nicht verstehen, wie relevant sie f\u00fcr Sie ist. Ja, nicht jedes Unternehmen kann eine Plattform wie Amazon aufbauen. Es ist eine komplexe Angelegenheit, bei der die Erfahrung eines Unternehmens mit seiner Marktposition zusammenh\u00e4ngt, und Vendor Lock sollte hier vermieden werden. Auch dar\u00fcber sollten Sie nachdenken.<\/p>\n

Schema<\/h3>\n

\nDies ist ein grundlegendes Schema der Infrastrukturplattform, das Ihnen hilft, alle Praktiken und Prozesse in einem DevOps-Unternehmen zu etablieren.<\/p>\n

\"Was
\n
\nLassen Sie uns betrachten, woraus sie besteht.<\/p>\n

Das Ressourcenorchestrierungssystem<\/b>, das CPU, Speicher und Speicher f\u00fcr Anwendungen und andere Dienste bereitstellt. Dar\u00fcber hinaus gibt es Basisdienste<\/b>: \u00dcberwachung, Protokollierung, CI\/CD-Engine, Artefakt-Repository, Infrastruktur als Code-System.<\/p>\n

H\u00f6here Dienste<\/b>: Datenbank als Dienst, Warteschlangen als Dienst, Load Balancing als Dienst, Bildvergr\u00f6\u00dferung als Dienst, Big Data-Fabrik als Dienst. Dar\u00fcber hinaus gibt es eine Pipeline, die st\u00e4ndig modifizierten Code an Ihren Kunden liefert.<\/b>.<\/p>\n

Sie erhalten Informationen dar\u00fcber, wie Ihre Software bei den Kunden funktioniert, ver\u00e4ndern sie, liefern diesen Code erneut und erhalten Informationen zur\u00fcck \u2013 so entwickeln Sie kontinuierlich sowohl Ihre Infrastrukturplattform als auch Ihre Software weiter.<\/p>\n

Das Diagramm des Delivery-Pipelines besteht aus mehreren Phasen. Doch dies ist ein grundlegendes Diagramm, das nur als Beispiel dient \u2013 es sollte nicht eins zu eins repliziert werden. Die Phasen interagieren mit den Services, als ob sie Services w\u00e4ren \u2013 jeder Baustein der Plattform hat seine eigene Geschichte: wie die Ressourcen zugewiesen werden, wie die Anwendung gestartet wird, wie sie mit den Ressourcen arbeitet, \u00fcberwacht wird und ver\u00e4ndert wird.<\/p>\n

Es ist wichtig zu verstehen, dass jeder Teil der Plattform eine Geschichte hat. Fragen Sie sich \u2013 welche Geschichte erz\u00e4hlt dieser Baustein? Vielleicht sollten wir ihn entfernen und durch einen externen Service ersetzen. Zum Beispiel, k\u00f6nnte man Okmeter anstelle des Bausteins verwenden? M\u00f6glicherweise haben die Kollegen diese Expertise bereits viel weiter entwickelt als wir. Aber vielleicht auch nicht \u2013 vielleicht haben wir eine einzigartige Expertise und sollten Prometheus einsetzen und dies weiterentwickeln.<\/p>\n

Erstellung der Plattform<\/h3>\n

\nDies ist ein komplexer Kommunikationsprozess. Wenn Sie \u00fcber grundlegende Praktiken verf\u00fcgen, initiieren Sie die Kommunikation zwischen verschiedenen Ingenieuren und Fachleuten, die Anforderungen und Standards entwickeln und diese kontinuierlich an verschiedene Werkzeuge und Ans\u00e4tze anpassen. In diesem Kontext ist die vorhandene Kultur im DevOps-Bereich entscheidend.<\/p>\n

\"Was
\nMit Kultur ist alles sehr einfach \u2013 es geht um Zusammenarbeit und Kommunikation<\/b>, das hei\u00dft, den gemeinsamen Wunsch, in einem gemeinsamen Bereich miteinander zu arbeiten und zusammen ein Werkzeug zu beherrschen. Hier gibt es nichts, was besonders kompliziert ist \u2013 es ist alles sehr einfach, sogar banal. Zum Beispiel leben wir alle in einem Wohnhaus und halten es sauber \u2013 das ist eine solche Ebene der Kultur.<\/p>\n

Wie sieht es bei Ihnen aus?<\/h3>\n

\nWieder Fragen, die Sie sich selbst stellen k\u00f6nnen.<\/p>\n

Ist die Infrastrukturplattform klar definiert? Wer ist verantwortlich f\u00fcr ihre Weiterentwicklung? Verstehen Sie die Wettbewerbsvorteile Ihrer Infrastrukturplattform?<\/p>\n

Diese Fragen sollten Sie sich st\u00e4ndig stellen. Wenn etwas an externe Dienstleistungen ausgelagert werden kann \u2013 sollten Sie es auslagern. Wenn ein externer Dienstleister Ihr Vorankommen behindert, sollten Sie ein internes System aufbauen.<\/p>\n

Also, DevOps\u2026<\/h2>\n

\n\u2026ist ein komplexes System, und es sollten folgende Elemente vorhanden sein:<\/p>\n