{"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 es immer wieder notwendig ist, die Diskussion dar\u00fcber neu zu beginnen. Allein auf Habr gibt es tausende von Ver\u00f6ffentlichungen zu diesem Thema. Aber wenn Sie dies lesen, wissen Sie wahrscheinlich, was DevOps ist. Denn ich wei\u00df es nicht. Hallo, ich hei\u00dfe 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 \u00fcberlegt, wie ich meine Erz\u00e4hlung n\u00fctzlich gestalten kann, daher wird es hier viele Fragen geben \u2013 die, die ich mir selbst stelle, und die, die ich unseren Kunden stelle. Indem ich auf diese Fragen antworte, wird das Verst\u00e4ndnis besser. Ich werde erz\u00e4hlen, warum DevOps aus meiner Sicht notwendig ist, was es ist, wiederum aus meiner Perspektive, und wie man erkennt, dass man sich auf dem Weg zu DevOps befindet, wiederum aus meiner Sicht. Der letzte Punkt wird durch Fragen erfolgen. Indem Sie sich diese selbst stellen, k\u00f6nnen Sie verstehen, ob Ihr Unternehmen auf dem Weg zu DevOps ist oder ob es dabei Probleme gibt.
\n<\/a><\/noindex>
\n

\r\n \"Video\r\n
<\/div>\r\n <\/div><\/center>
\nEine Zeit lang war ich auf den Wellen von Fusionen und \u00dcbernahmen unterwegs. Zun\u00e4chst arbeitete ich in einem kleinen Startup namens Qik, das dann von einer etwas gr\u00f6\u00dferen Firma namens Skype \u00fcbernommen wurde, die sp\u00e4ter von einer noch gr\u00f6\u00dferen Firma, Microsoft, gekauft wurde. In diesem Moment bekam ich Einblicke, wie sich die Vorstellung von DevOps in Unternehmen unterschiedlicher Gr\u00f6\u00dfenordnungen transformiert. Danach wurde es f\u00fcr mich interessant, DevOps aus Marktsicht zu betrachten, und wir gr\u00fcndeten mit Kollegen die Firma Express 42. Bereits seit 6 Jahren navigieren wir auf diesem Markt.<\/p>\n

Nebenbei bin ich einer der Organisatoren der Community DevOps Moscow und Organisator von DevOps-Days 2017, die 2018 jedoch nicht organisiert wurden. Express 42 arbeitet mit vielen Firmen zusammen. Wir etablieren dort DevOps, beobachten, wie das geschieht, ziehen Schlussfolgerungen, analysieren und teilen unsere Ergebnisse mit allen, schulen Menschen in DevOps-Praktiken. Kurz gesagt, wir f\u00f6rdern in dieser Hinsicht unsere Erfahrungen und unsere Expertise.<\/p>\n

Warum DevOps<\/h2>\n

\nDie erste Frage, die alle und immer verfolgt \u2013 warum? Viele glauben, dass DevOps einfach Automatisierung oder eine \u00e4hnliche Sache ist, die bereits in jedem Unternehmen vorhanden war.<\/p>\n

\u2014 Wir hatten Continuous Integration \u2013 das hei\u00dft, wir hatten bereits DevOps, und warum brauchen wir diesen ganzen Kram? Da dr\u00fcben am\u00fcsiert man sich, w\u00e4hrend uns die Arbeit im Weg steht!<\/i><\/p>\n

Nach 9 Jahren der Entwicklung der Gemeinschaft und Methodik ist bereits klar geworden, dass es sich dabei nicht um Marketingflitter handelt, aber es ist trotzdem nicht ganz klar, wozu es notwendig ist. Wie bei jedem Werkzeug und Prozess hat DevOps bestimmte Ziele, die es letztendlich erreicht.<\/p>\n

Das alles h\u00e4ngt damit zusammen, dass sich die Welt ver\u00e4ndert. Sie entfernt sich von dem unternehmerischen Ansatz, bei dem Unternehmen gem\u00e4\u00df einer bestimmten Strategie, wie unser Petersburger Klassiker sang, von Punkt A nach Punkt B aufbrechen, unterst\u00fctzt von einer daf\u00fcr aufgebauten Struktur. <\/p>\n

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

Im Grunde sollte alles im IT-Bereich auf diesem Ansatz basieren. Hier wird IT ausschlie\u00dflich zur Automatisierung von Prozessen eingesetzt.<\/p><\/blockquote>\n

\nAutomatisierung \u00e4ndert sich nicht oft, denn wenn ein Unternehmen auf den gewohnten Pfaden voranschreitet \u2013 was soll man da \u00e4ndern? Es funktioniert \u2013 also nicht anfassen. Derzeit \u00e4ndern sich die Ans\u00e4tze in der Welt, und der, der als Agile bezeichnet wird, besagt, dass das endg\u00fcltige Ziel B nicht sofort sichtbar ist.<\/p>\n

\"Was
\n
\nWenn ein Unternehmen den Markt durchl\u00e4uft und mit dem Kunden arbeitet, erforscht es st\u00e4ndig den Markt und \u00e4ndert das endg\u00fcltige Ziel B. Je h\u00e4ufiger ein Unternehmen seine Richtung \u00e4ndert, desto erfolgreicher ist es letztendlich, da es mehr Marktsegmente ausw\u00e4hlt.<\/p>\n

Eine interessante Firma zeigt diese Strategie, von der ich k\u00fcrzlich erfahren habe. One Box Shave \u2013 ein Lieferdienst f\u00fcr Rasierer und Rasurartikel im Abonnement in einer Box. Sie k\u00f6nnen ihre \u201eBox\u201c f\u00fcr verschiedene Kunden individuell anpassen. Das erledigt eine spezielle Software, die dann die Bestellung an eine koreanische Fabrik sendet, die das Produkt herstellt.<\/p>\n

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

\u2014 4 Klingen? Sind Sie im Ernst? Warum brauchen Sie das \u2013 das verbessert die Rasurqualit\u00e4t nicht. Ein speziell ausgew\u00e4hlter Rasiercreme, Duft und ein qualitativ hochwertiger Rasierer mit zwei Klingen l\u00f6sen viel mehr Fragen als diese l\u00e4cherlichen 4 Klingen von Gillette! Gehen wir bald auf 10 \u00fcber?<\/i><\/p>\n

So ver\u00e4ndert sich die Welt. Unilever behauptet, dass sie ein gro\u00dfartiges IT-System haben, das dies erm\u00f6glicht. Am Ende sieht das aus wie das Konzept Time-to-market<\/b>, \u00fcber das bereits viele gesprochen haben.<\/p>\n

\"Was
\n
\nDie Bedeutung von Time-to-market liegt nicht darin, wie oft wir deployments durchf\u00fchren. Man kann h\u00e4ufig deployen, doch die Release-Zyklen k\u00f6nnen dabei lang sein. Wenn man drei\u00dfig monatliche Release-Zyklen \u00fcbereinanderlegt und um eine Woche verschiebt, scheint es, als ob das Unternehmen einmal pro Woche deployt. Aber von der Idee bis zur endg\u00fcltigen Umsetzung vergehen 3 Monate.<\/p>\n

Time-to-market 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 interagiert die Website von One Box Shave mit dem Kunden. Sie haben keine Verk\u00e4ufer \u2013 nur die Website, auf der die Besucher klicken und W\u00fcnsche hinterlassen. Daher muss die Website st\u00e4ndig neue Inhalte bereitstellen und aktualisiert werden, um den W\u00fcnschen gerecht zu werden. Zum Beispiel rasieren sich die Menschen in S\u00fcdkorea anders als in Russland und sie bevorzugen im Duft nicht den Geruch von Kiefer, sondern zum Beispiel den von Vanille-M\u00f6hren.<\/p>\n

Da der Inhalt der Website schnell ge\u00e4ndert werden muss, ver\u00e4ndert sich auch die Softwareentwicklung erheblich. Durch die Software m\u00fcssen wir herausfinden, was der Kunde will. Fr\u00fcher haben wir das auf indirektem Weg erfahren, zum Beispiel \u00fcber das Business-Management. Dann entwarfen wir und legten die Anforderungen in das IT-System, und alles lief glatt. Heute ist es anders \u2013 die Software wird von allen, die an dem Prozess beteiligt sind, einschlie\u00dflich der Ingenieure, entworfen, da sie durch technische Spezifikationen erfahren, wie der Markt funktioniert, und auch ihre Einsichten mit dem Gesch\u00e4ft teilen.<\/p>\n

Zum Beispiel haben wir bei der Firma Qik pl\u00f6tzlich erfahren, dass die Leute es sehr m\u00f6gen, Kontaktlisten auf den Server hochzuladen, und sie haben uns eine App gegeben. Zuvor hatten wir dar\u00fcber nicht nachgedacht. In einem klassischen Unternehmen h\u00e4tte man wahrscheinlich gesagt, das sei ein Bug, weil in der Spezifikation nicht steht, dass es gut funktionieren sollte, und es wurde schlie\u00dflich improvisiert. Man h\u00e4tte die Funktion abgeschaltet und gesagt: \"Das braucht keiner, das Wichtigste ist, dass die Grundfunktionen funktionieren.\" Aber ein technologieorientiertes Unternehmen sieht darin eine Chance 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 erstellt, ist durch das Design eingeschr\u00e4nkt, das die Kommunikationsstruktur dieser Organisation widerspiegelt.<\/p><\/blockquote>\n

\nWenn wir ins Detail gehen, um Systeme eines anderen Typs zu produzieren, ben\u00f6tigen wir zus\u00e4tzlich eine Kommunikationsstruktur innerhalb des Unternehmens, die ebenfalls anders ist. Wenn Sie eine hierarchische Kommunikationsstruktur haben, wird dies es Ihnen nicht erm\u00f6glichen, Systeme zu schaffen, die eine sehr hohe Time-to-Market-Rate bieten k\u00f6nnen.<\/p>\n

Lesen \u00fcber das Conway-Gesetz<\/a><\/noindex> kann man \u00fcber 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, Betrieb, linear.\"Was
\nIm Fall von DevOps laufen all diese Prozesse gleichzeitig.<\/p>\n

\"Was
\n
\nTime-to-Market kann nur so erf\u00fcllt werden. F\u00fcr Menschen, die im alten Prozess gearbeitet haben, wirkt das etwas futuristisch und im Grunde auch unpraktisch.<\/p>\n

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

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

DevOps \u00fcberwindet die Geschwindigkeitsgrenzen des sequentiellen Softwareproduktionsplans<\/b>. In ihm laufen alle Prozesse gleichzeitig.<\/p>\n

Die Komplexit\u00e4t nimmt zu.<\/b> Wenn DevOps-Evangelisten erz\u00e4hlen, 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 \u00fcbermenschlich, man muss viele B\u00e4lle gleichzeitig jonglieren.<\/p>\n

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

Fragen f\u00fcr den Spezialisten<\/h3>\n

\nUnd was ist mit Ihnen? Fragen, die Sie sich stellen k\u00f6nnen, w\u00e4hrend Sie im Unternehmen arbeiten und sich als Spezialist 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 noch eine Stufe h\u00f6her steigen k\u00f6nnen, interessantere Dinge tun \u2013 aus der Sicht von DevOps, um genau zu sein. Nur aus dieser Perspektive spreche ich.<\/p>\n

Ist Ihr Unternehmen einer der Marktf\u00fchrer in der Nische mit einem digitalen Produkt?<\/b> Spotify, Yandex, Uber \u2013 Unternehmen, die sich derzeit an der Spitze des technologischen Fortschritts befinden.<\/p>\n

Stellen Sie sich diese Fragen, und wenn alle Antworten negativ sind, sollten Sie vielleicht nicht in diesem Unternehmen DevOps praktizieren. Wenn Ihnen jedoch das Thema DevOps wirklich interessiert, sollten Sie vielleicht\u2026 in ein anderes Unternehmen wechseln? Wenn Ihr Unternehmen DevOps umsetzen m\u00f6chte, Sie aber auf alle Fragen mit \u201eNein\u201c geantwortet haben, \u00e4hnelt es diesem wunderbaren Nashorn, das sich nie ver\u00e4ndern wird.<\/p>\n

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

Organisation<\/h2>\n

\nWie ich bereits gesagt habe, ver\u00e4ndert sich die Organisation in einem Unternehmen gem\u00e4\u00df dem Conway-Gesetz. Ich beginne mit dem, was DevOps daran hindert, intern im Unternehmen einzudringen, und zwar aus organisatorischer Sicht.<\/p>\n

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

\nDas englische Wort \u201eSilo\u201c wird hier auf Russisch als \u201e\u043a\u043e\u043b\u043e\u0434\u0435\u0446\u201c \u00fcbersetzt. Der Sinn dieses Problems ist, dass es keinen Informationsaustausch zwischen den Teams gibt.<\/b>Jedes Team gr\u00e4bt seine Expertise tief, ohne eine gemeinsame Karte zu erstellen, auf der man sich orientieren kann.<\/p>\n

Das erinnert an jemanden, der gerade in Moskau angekommen ist und noch nicht wei\u00df, wie man sich mit der U-Bahn-karte orientiert. Muskoviten wissen normalerweise sehr gut Bescheid \u00fcber ihren Stadtteil, und in ganz Moskau orientieren sie sich mit der U-Bahn-Karte. Wenn Sie zum ersten Mal nach Moskau kommen, haben Sie diese F\u00e4higkeit nicht und sind einfach orientierungslos.<\/p>\n

DevOps schl\u00e4gt vor, diesen Moment der Desorientierung zu \u00fcberwinden und allen Abteilungen gemeinsam eine gemeinsame Interaktionskarte zu erstellen.<\/p><\/blockquote>\n

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

Folge der Corporate Governance.<\/b> Sie ist aus separaten hierarchischen \u201eSilos\u201c aufgebaut. Zum Beispiel gibt es bestimmte KPIs in Unternehmen, die dieses System unterst\u00fctzen. Andererseits stehen die Gedanken des Menschen dem im Wege, der Schwierigkeiten hat, \u00fcber seine Expertise hinauszublicken und sich im gesamten System zurechtzufinden. Das ist einfach unbequem. Stellen Sie sich vor, Sie befinden sich am Flughafen von Bangkok \u2013 dort ist es schnell schwierig, sich zurechtzufinden. Auch in DevOps ist es kompliziert, den \u00dcberblick zu behalten, und deshalb sagen die Leute, dass man einen F\u00fchrer finden muss, um dorthin zu gelangen.<\/p>\n

Aber das Wichtigste ist, dass das Problem der \u201eSilos\u201c f\u00fcr einen Ingenieur, der den Geist von DevOps verinnerlicht hat, Fowlers B\u00fccher gelesen hat und viele andere B\u00fccher, darin besteht, dass \u201eSilos\u201c nicht erlauben, \u201eoffensichtliche\u201c Dinge zu tun.<\/b>Wir treffen uns oft nach 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 Management das nicht braucht.<\/i><\/p>\n

Das geschieht genau aus dem Grund, dass\u00a0CI <\/b>und\u00a0Continuous Delivery Prozess<\/b> an der Grenze vieler Fachgebiete liegen. Wenn das Problem der 'Brunnen' auf organisatorischer Ebene nicht \u00fcberwunden wird, wird es nicht m\u00f6glich sein, weiterzukommen, egal was Sie tun und wie traurig das auch sein mag.<\/p>\n

\"Was
\n
\nJeder Teilnehmer des Prozesses im Unternehmen: Backend- und Frontend-Entwickler, Test, DBA, Betrieb, Netzwerk, arbeitet in seiner eigenen Richtung, w\u00e4hrend niemand au\u00dfer dem Manager eine gemeinsame \u00dcbersicht hat, der sie auf eine Art \u00fcberwacht und nach der Methode \"teile und herrsche\" verwaltet.<\/p>\n

Die Leute k\u00e4mpfen um irgendwelche Sternchen oder F\u00e4hnchen, jeder bearbeitet sein eigenes Fachgebiet.<\/p><\/blockquote>\n

\nLetztendlich, wenn die Aufgabe auftaucht, all dies zusammenzuf\u00fcgen und eine gemeinsame Pipeline zu erstellen, und um Sternchen und F\u00e4hnchen braucht man nicht mehr zu k\u00e4mpfen, stellt sich die Frage \u2013 was soll man \u00fcberhaupt tun? Man muss irgendwie einen Konsens finden, aber niemand hat uns in der Schule dazu gelehrt. Wir sind schon seit der Schule daran gew\u00f6hnt: Acht Klasse \u2013 wow! \u2013 im Vergleich zur Siebten! Hier ist es ganz \u00e4hnlich.<\/p>\n

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

\nUm das zu \u00fcberpr\u00fcfen, kann man sich folgende Fragen stellen.<\/p>\n

Nutzen die Teams gemeinsame Werkzeuge, 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> Insbesondere im DevOps-Umfeld wird dies zur Norm, da es manchmal schwierig ist, die T\u00e4tigkeiten eines anderen Fachbereichs zu verstehen. Man wechselt in eine andere Abteilung, arbeitet dort ein paar Wochen, um sich eine Orientierungskarte und Interaktionsm\u00f6glichkeiten mit dieser Abteilung zu schaffen.<\/p>\n

Kann ein Komitee zur \u00c4nderung gegr\u00fcndet und etwas ge\u00e4ndert werden? <\/b>Oder ist daf\u00fcr eine starke Hand der obersten F\u00fchrungsebene und eine Anweisung erforderlich? K\u00fcrzlich habe ich auf Facebook geschrieben, wie eine wenig bekannte Bank durch Anweisungen Werkzeuge einf\u00fchrt: Sie haben eine Anweisung geschrieben, setzen es ein Jahr um und schauen, was passiert. Das ist nat\u00fcrlich langwierig und traurig.<\/p>\n

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

Wenn Sie diese Fragen f\u00fcr sich selbst beantworten, wird klarer, ob Sie ein solches Problem im 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 weiterzukommen \u2013 das ist Infrastruktur als Code<\/b>. <\/p>\n

Meistens wird Infrastructure as Code so verstanden:<\/p>\n

\u2014 Lass uns alles mit bash automatisieren, uns mit Skripten eindecken, damit die Administratoren weniger manuelle Arbeit haben!<\/i><\/p>\n

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

Infrastructure as Code bedeutet, dass Sie die IT-Systeme, mit denen Sie arbeiten, in Form von Code beschreiben, um st\u00e4ndig ihren Zustand zu verstehen.<\/p><\/blockquote>\n

\nGemeinsam mit anderen Teams erstellen Sie eine Karte in Form von Code, die allen verst\u00e4ndlich ist und nach der man navigieren kann. Es spielt keine Rolle, womit das gemacht wird \u2013 ob mit Chef, Ansible, Salt oder YAML-Dateien in Kubernetes \u2013 es macht keinen Unterschied.<\/p>\n

Auf der Konferenz erz\u00e4hlte ein Kollege von 2GIS, wie sie ihr internes Tool f\u00fcr Kubernetes entwickelt haben, das die Struktur einzelner Systeme beschreibt. Um 500 Systeme zu beschreiben, ben\u00f6tigten sie ein separates Werkzeug, das diese Beschreibung generiert. Wenn man diese Beschreibung hat, kann jeder sich gegenseitig abgleichen, \u00c4nderungen \u00fcberwachen, wie man sie ver\u00e4ndern und verbessern kann und was fehlt. <\/p>\n

Sie m\u00fcssen zustimmen, dass separate bash-Skripte normalerweise nicht zu diesem Verst\u00e4ndnis f\u00fchren. In einer der Firmen, in denen ich gearbeitet habe, gab es sogar den Begriff \u201ewrite only\u201c-Skript \u2013 wenn das Skript geschrieben ist, kann man es nicht mehr lesen. Ich glaube, das ist Ihnen auch bekannt.<\/p>\n

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

Der Code wird entsprechend den besten Praktiken f\u00fcr die Arbeit mit Code gepflegt<\/b>: gemeinsame Entwicklung, Code-Reviews, XP-Programmierung, Tests, Pull-Requests, CI f\u00fcr Infrastructure as Code \u2013 das alles ist wertvoll und kann verwendet werden.<\/p>\n

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

\n\u00c4nderungen an der Infrastruktur im Code nehmen nicht viel Zeit in Anspruch<\/b>. Ja, auch im Infrastrukturcode kann es technische Schulden geben. Normalerweise sto\u00dfen Teams nach anderthalb Jahren auf diese, nachdem sie angefangen haben, \u201eInfrastructure as Code\u201c in Form von vielen Skripten oder sogar Ansible einzuf\u00fchren, das sie wie Spaghetticode schreiben und dazu noch bash-Skripte hineinschieben! <\/p>\n

Wichtig<\/b>: Wenn Sie diesen Mist noch nicht ausprobiert haben, merken Sie sich, dass Ansible \u2013 nicht bash<\/b>Bitte lesen Sie die Dokumentation sorgf\u00e4ltig und erfahren Sie, was dar\u00fcber gesagt wird.<\/p>\n

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

\nIn unserem Unternehmen unterscheiden wir 3 grundlegende Schichten, die sehr klar und einfach verst\u00e4ndlich sind, aber es k\u00f6nnen auch mehr sein. Sie k\u00f6nnen Ihren Infrastrukturcode \u00fcberpr\u00fcfen und feststellen, ob Sie diese Bedingung erf\u00fcllen oder nicht. Wenn keine Schichten erkennbar sind, sollten Sie sich Zeit nehmen, um ein wenig zu refaktorisieren.
\n\"Was
\n
\nBasis-Schicht<\/b>\u00a0\u2014 das sind die Einstellungen f\u00fcr das Betriebssystem, Backups und andere Low-Level-Dinge, wie zum Beispiel, wie Kubernetes auf Basisniveau bereitgestellt wird.<\/p>\n

Service-Ebene<\/b>\u00a0\u2014 das sind die Dienste, die Sie den Entwicklern anbieten: Logging als Dienst, Monitoring als Dienst, Datenbank als Dienst, Lastenausgleich als Dienst, Warteschlange als Dienst, Continuous Delivery als Dienst \u2013 viele Dienste, die verschiedene Teams der Entwicklung zur Verf\u00fcgung stellen k\u00f6nnen. All dies muss in Ihrer Konfigurationsverwaltung als separate Module beschrieben werden.<\/p>\n

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

Kontrollfragen<\/h3>\n

\nHaben Sie in Ihrem Unternehmen ein gemeinsames Infrastruktur-Repository? \u00dcberwachen Sie die technische Schuld in der Infrastruktur? Setzen Sie Entwicklungspraktiken im Infrastruktur-Repository ein? Ist Ihre Infrastruktur in Schichten unterteilt? Sie k\u00f6nnen sich an dem Schema Base-service-APP orientieren. Wie schwierig ist es, eine \u00c4nderung vorzunehmen? <\/p>\n

Wenn Sie festgestellt haben, dass \u00c4nderungen eineinhalb Tage in Anspruch genommen haben, bedeutet das, dass Sie technische Schulden haben, mit denen Sie sich befassen sollten. Sie sind auf die Stolpersteine der technischen Schulden im Infrastrukturcode gesto\u00dfen. Ich erinnere mich an viele Geschichten, in denen man, um einen bestimmten CCTL zu \u00e4ndern, die H\u00e4lfte des Infrastrukturcodes neu schreiben musste, weil Kreativit\u00e4t und der Wunsch, alles zu automatisieren, dazu gef\u00fchrt haben, dass \u00fcberall alles zugeschraubt wurde, alle Handgriffe entfernt wurden und Refaktorisierung notwendig ist.<\/p>\n

Kontinuierliche Lieferung<\/h2>\n

\nLassen Sie uns das Debit mit dem Kredit abgleichen. Zun\u00e4chst erscheint eine Beschreibung der Infrastruktur, die ziemlich einfach sein kann. Es ist nicht erforderlich, alles im Detail zu beschreiben, aber eine grundlegende Beschreibung ist erforderlich, damit Sie damit arbeiten k\u00f6nnen. Andernfalls ist es unklar, auf welcher Grundlage Sie die kontinuierliche Lieferung durchf\u00fchren k\u00f6nnen. All diese Praktiken entfallen gleichzeitig, wenn Sie zu DevOps kommen, aber Sie m\u00fcssen mit dem Verst\u00e4ndnis beginnen, was Sie haben und wie Sie es verwalten. Dies ist die Praxis der Infrastruktur als Code.<\/p>\n

Nachdem verst\u00e4ndlich wurde, was Sie haben und wie Sie damit umgehen, beginnen Sie zu \u00fcberlegen, wie der Entwicklercode so schnell wie m\u00f6glich in die Produktion gebracht werden kann. Ich meine zusammen mit dem Entwickler - denken wir an das Problem der \u201eBrunnen\u201c, das hei\u00dft, es sind nicht einzelne Personen, die das erdenken, sondern das Team.<\/p>\n

Als wir\u00a0Ivan Evtuchovich<\/b> das erste Buch sahen Jez Humble<\/b> und die Gruppe von Autoren \u201eContinuous Delivery\u201c<\/b>, das 2009 ver\u00f6ffentlicht wurde, dachten wir lange dar\u00fcber nach, wie wir seinen Titel ins Russische \u00fcbersetzen k\u00f6nnen. Wir wollten es als \u201eSt\u00e4ndig liefern\u201c \u00fcbersetzen, aber leider \u00fcbersetzten wir es als \u201eKontinuierliche Lieferung\u201c. Ich glaube, dass in unserem Titel etwas Russisches steckt, mit Schwung.<\/p>\n

St\u00e4ndig liefern bedeutet<\/h3>\n

\nDer Code, der im Produktrepository liegt, kann jederzeit in die Produktion gebracht werden<\/b>. Er kann ungenutzt bleiben, ist aber immer bereit daf\u00fcr. Daher schreiben Sie immer Code mit einem schwer zu erkl\u00e4renden Gef\u00fchl der gewissenhaften Besorgnis im Hinterkopf. Dieses Gef\u00fchl tritt h\u00e4ufig auf, wenn Sie Infrastrukturcode ausrollen. Dieses Gef\u00fchl der Besorgnis sollte vorhanden sein - es f\u00f6rdert Denkprozesse, die es erm\u00f6glichen, Code ein wenig anders zu schreiben. Das sollte in den Regeln innerhalb der Entwicklung verankert werden.<\/p>\n

Um st\u00e4ndig zu liefern, ben\u00f6tigen Sie ein Artefaktformat, das durch die Infrastrukturplattform geht. <\/b>Wenn Sie unterschiedliche Formate von \u201eAbf\u00e4llen der Lebensf\u00fchrung\u201c durch die Infrastrukturplattform werfen, wird sie nicht mehr einheitlich, es wird schwierig, sie zu unterst\u00fctzen, und es entsteht ein technisches Schuldenproblem. Das Artefaktformat muss angeglichen werden - das ist auch eine kollektive Aufgabe: Alle m\u00fcssen sich zusammenfinden, ihre K\u00f6pfe zusammenstecken und dieses Format erarbeiten.<\/p>\n

Das Artefakt verbessert sich kontinuierlich und \u00e4ndert sich gem\u00e4\u00df der Produktionsumgebung w\u00e4hrend des Durchlaufs durch die Lieferpipeline. <\/b>Wenn das Artefakt durch die Pipeline bewegt wird, begegnet es st\u00e4ndig einigen unangenehmen Dingen, die dem \u00e4hneln, mit denen es im Produktionsumfeld konfrontiert wird. W\u00e4hrend in der klassischen Softwareentwicklung dies ein Systemadministrator \u00fcbernimmt, der das Deployment durchf\u00fchrt, geschieht dies im DevOps-Prozess kontinuierlich: Hier wurde es durch einige Tests gedreht, dort wurde es in einen Kubernetes-Cluster eingef\u00fcgt, der mehr oder weniger der Produktionsumgebung \u00e4hnelt, und hier wurde pl\u00f6tzlich ein Lasttest gestartet.<\/p>\n

Das erinnert an das Spiel Pac-Man \u2013 das Artefakt durchl\u00e4uft eine Art Geschichte. Dabei ist es wichtig zu \u00fcberwachen, ob der Code tats\u00e4chlich die Geschichte durchl\u00e4uft und ob sie mit Ihrer Produktionsumgebung verbunden ist. Geschichten aus der Produktion k\u00f6nnen in den Continuous Delivery-Prozess integriert werden: Es gab zum Beispiel einen Vorfall, als etwas ausgefallen ist, also lassen Sie uns dieses Szenario einfach in das System programmieren. Jedes Mal wird der Code auch dieses Szenario durchlaufen, und Sie werden das n\u00e4chste Mal nicht mit diesem Problem konfrontiert. Sie werden viel fr\u00fcher davon erfahren, bevor es zu Ihrem Kunden kommt.<\/p>\n

Verschiedene Deployment-Strategien. <\/b>Zum Beispiel verwenden Sie A\/B-Tests oder Canary-Deployments, um den Code auf verschiedene Arten bei unterschiedlichen Kunden zu testen, Informationen dar\u00fcber zu erhalten, wie der Code funktioniert, und das viel fr\u00fcher, als wenn er an 100 Millionen Benutzer freigegeben wird.<\/p>\n

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

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

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

\nWenn Sie Code f\u00fcr Infrastruktur haben, der als Basisdienst-App beschrieben ist, hilft er nicht alle Szenarien zu vergessen,<\/b>, und sie ebenfalls in Form von Code f\u00fcr dieses Artefakt zu dokumentieren, das Artefakt voranzubringen<\/b> und es unterwegs zu \u00e4ndern.<\/p>\n

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

\nDauert es von der Beschreibung des Features bis zur Ver\u00f6ffentlichung in der Produktion in 95 % der F\u00e4lle weniger als eine Woche? Steigt die Qualit\u00e4t des Artefakts in jeder Phase der Pipeline? Gibt es eine Geschichte, durch die es l\u00e4uft? Verwenden Sie verschiedene Deployment-Strategien?<\/p>\n

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

Feedback<\/h3>\n

\nDies ist die schwierigste Praxis von allen. Auf der Konferenz DevOpsConf war ein Kollege von Infobip, der dar\u00fcber sprach, etwas verwirrt in seinen Worten, denn es ist wirklich eine sehr komplexe Praxis, bei der man alles \u00fcberwachen muss!<\/p>\n

\"Was
\n
\nVor langer Zeit, als ich bei Qik arbeitete und wir festgestellt haben, dass wir alles \u00fcberwachen m\u00fcssen. Wir haben das getan und in Zabbix hatten wir 150.000 Items, die st\u00e4ndig \u00fcberwacht werden. Das war be\u00e4ngstigend, der technische Direktor hat sich nur am Kopf gekratzt:<\/p>\n

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

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

Einer der Dienste begann st\u00e4ndig abzust\u00fcrzen. Interessanterweise ist er anfangs nicht abgest\u00fcrzt, da dort kein Code hinzugef\u00fcgt wurde, denn es war ein Basisbroker, in dem praktisch keine Business-Funktionalit\u00e4ten waren \u2013 er \u00fcbertrug einfach Nachrichten zwischen einzelnen Diensten. Der Dienst hatte sich vier Monate lang nicht ge\u00e4ndert und begann pl\u00f6tzlich mit einem \u201eSegmentation fault\u201c abzust\u00fcrzen.<\/p>\n

Wir waren schockiert, \u00f6ffneten unsere Grafiken in Zabbix, und es stellte sich heraus, dass vor anderthalb Wochen das Verhalten der Anfragen im API-Dienst, der diesen Broker verwendet, sich stark ge\u00e4ndert hatte. Danach sahen wir, dass sich die H\u00e4ufigkeit des Sendens eines bestimmten Nachrichtentyps ge\u00e4ndert hatte. Sp\u00e4ter haben wir festgestellt, dass es sich um die Android-Clients handelte. Wir fragten:<\/p>\n

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

Als Antwort erhielten wir eine interessante Geschichte, dass sie das UI umgestaltet hatten. Kaum jemand w\u00fcrde sofort sagen, dass er die HTTP-Bibliothek gewechselt hat. F\u00fcr Android-Clients ist es wie wenn man die Seife im Bad wechselt \u2013 sie erinnern sich einfach nicht daran. Letztendlich haben wir nach 40 Minuten Gespr\u00e4ch herausgefunden, dass sie tats\u00e4chlich die HTTP-Bibliothek gewechselt hatten und sich die Standard-Timings ge\u00e4ndert hatten. Das f\u00fchrte dazu, dass sich das Verhalten des Traffics auf dem API-Server \u00e4nderte, was zu der Situation f\u00fchrte, die eine Kollision innerhalb des Brokers verursachte, und er begann abzust\u00fcrzen.<\/p>\n

Ohne tiefgehende \u00dcberwachung ist das \u00fcberhaupt nicht zu erkennen.<\/b>. Wenn es in der Organisation jedoch noch das Problem der \"Brunnen\" gibt, bei dem jeder die Verantwortung auf den anderen schiebt, kann das jahrelang bestehen bleiben. Sie starten einfach den Server neu, weil das Problem nicht gel\u00f6st werden kann. Wenn Sie alle Ereignisse, die Sie haben, \u00fcberwachen, verfolgen und analysieren und das Monitoring als ein Test-Tool verwenden \u2013 indem Sie Code schreiben und sofort angeben, wie er \u00fcberwacht werden soll, auch in Form von Code (wir haben bereits Infrastruktur als Code), wird alles so klar wie der Handballen. Sogar solch komplexe Probleme sind leicht nachzuvollziehen.<\/p>\n

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

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

\nLaden Sie das Monitoring in CI, und dort werden bereits einige grundlegende Dinge sichtbar sein. Au\u00dferdem werden Sie diese auch im Test, im PredProd und im Lasttest sehen. Sammeln Sie Informationen in allen Phasen, nicht nur Metriken, 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\u00f6tigt man eine angemessene Analytik.<\/b>.<\/p>\n

Fragen zur Selbstkontrolle<\/h3>\n

\nIst Ihr Monitoring und Logging ein Entwicklungswerkzeug f\u00fcr Sie?<\/b> Denken Ihre Entwickler, einschlie\u00dflich Ihnen, beim Schreiben von Code dar\u00fcber nach, wie er \u00fcberwacht werden kann?<\/p>\n

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

Wenn Sie diese drei Komponenten haben, k\u00f6nnen Sie \u00fcber die infrastrukturelle Plattform in Ihrem Unternehmen nachdenken.<\/p>\n

Infrastrukturelle Plattform <\/h2>\n

\nEs geht nicht darum, dass dies eine Sammlung von voneinander unabh\u00e4ngigen Werkzeugen ist, die in jedem Unternehmen vorhanden sind.<\/p>\n

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

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

Alle Teams entwickeln eine Infrastrukturplattform und behandeln sie sorgf\u00e4ltig wie ihre eigene IDE.<\/b>. In Ihrer IDE installieren Sie verschiedene Plugins, um alles sch\u00f6n und schnell zu gestalten, und konfigurieren Tastenkombinationen. Wenn Sie Sublime, Atom oder Visual Studio Code \u00f6ffnen, fallen sofort Fehler im Code auf und Sie merken, dass es \u00fcberhaupt unm\u00f6glich ist zu arbeiten. Sofort wird Ihnen schlecht und Sie laufen los, um Ihre IDE zu reparieren.<\/p>\n

Behandeln Sie Ihre Infrastrukturplattform genauso. Wenn Sie merken, dass etwas nicht stimmt, stellen Sie eine Anfrage, wenn Sie es nicht selbst reparieren k\u00f6nnen. Wenn es jedoch etwas Einfaches ist \u2013 beheben Sie es selbst, senden Sie eine Pull-Request \u2013 die Kollegen pr\u00fcfen, f\u00fcgen hinzu. Dies ist ein etwas anderer Ansatz im Ingenieurwesen f\u00fcr den Kopf des Entwicklers.<\/p>\n

Die Infrastrukturplattform sorgt daf\u00fcr, dass Artefakte von der Entwicklung zum Kunden mit st\u00e4ndig steigender Qualit\u00e4t \u00fcbertragen werden.<\/b>. In der IP ist eine Reihe von Geschichten programmiert, die mit dem Code in Produktion passieren. \u00dcber die Jahre der Entwicklung werden diese Geschichten sehr zahlreich, einige davon sind einzigartig und beziehen sich nur auf Sie \u2013 sie sind nicht googlbar. <\/p>\n

In diesem Moment wird die Infrastrukturplattform zu Ihrem Wettbewerbsvorteil.<\/b>, weil darin Dinge eingebaut sind, die kein Werkzeug des Wettbewerbers hat. Je tiefer Ihre IP ist, desto gr\u00f6\u00dfer ist Ihr Wettbewerbsvorteil in Bezug auf die Time-to-market. Hier tritt das Problem des Vendor Lock-in<\/b>auf: Sie k\u00f6nnen sich eine fremde Plattform nehmen, aber wenn Sie auf die Erfahrung anderer zur\u00fcckgreifen, werden Sie nicht verstehen, inwieweit diese relevant f\u00fcr Sie ist. Ja, nicht jedes Unternehmen kann eine Plattform wie Amazon aufbauen. Das ist eine schwierige Grenze, wo die Erfahrung des Unternehmens f\u00fcr seine Position auf dem Markt relevant ist, und den Vendor Lock-in sollte man dort nicht herunterlassen. Dar\u00fcber muss man auch nachdenken.<\/p>\n

Diagramm<\/h3>\n

\nDas ist das grundlegende Schema einer Infrastrukturplattform, das Ihnen helfen wird, alle Praktiken und Prozesse in einem DevOps-Unternehmen zu etablieren.<\/p>\n

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

Ein System zur Orchestrierung von Ressourcen<\/b>, das CPU, Speicher, Festplatten f\u00fcr Anwendungen und andere Dienste bereitstellt. Dar\u00fcber hinaus gibt es niedrigere Dienste<\/b>: \u00dcberwachung, Protokollierung, CI\/CD-Engine, Artefakt-Speicher, Infrastruktur als Code-Systeme.<\/p>\n

H\u00f6here Dienste.<\/b>: Datenbank als Dienst, Warteschlangen als Dienst, Load Balancer als Dienst, Bildgr\u00f6\u00dfen\u00e4nderung als Dienst, Big Data Fabrik als Dienst. Dar\u00fcber hinaus\u00a0\u2014 pipeline, die st\u00e4ndig modifizierten Code an Ihren Kunden liefert<\/b>.<\/p>\n

Sie erhalten Informationen dar\u00fcber, wie Ihre Software beim Kunden funktioniert, \u00e4ndern, liefern diesen Code erneut, erhalten Informationen \u2014 und entwickeln damit st\u00e4ndig sowohl die Infrastrukturplattform als auch Ihre Software weiter.<\/p>\n

In dem Diagramm besteht die Delivery-Pipeline aus mehreren Phasen. Aber das ist ein grundlegendes Schema, das als Beispiel dient \u2014 es muss nicht eins zu eins wiederholt werden. Die Phasen interagieren mit Diensten, als w\u00e4ren es Dienste \u2014 jeder Baustein der Plattform erz\u00e4hlt seine eigene Geschichte: wie Ressourcen zugewiesen werden, wie die Anwendung gestartet wird, mit Ressourcen arbeitet, \u00fcberwacht wird und sich \u00e4ndert.<\/p>\n

Es ist wichtig zu verstehen, dass jeder Teil der Plattform eine Geschichte erz\u00e4hlt, und sich zu fragen \u2014 welche Geschichte erz\u00e4hlt dieser Baustein, vielleicht sollte man ihn wegwerfen und durch einen externen Dienst ersetzen. Zum Beispiel, k\u00f6nnte man anstelle des Bausteins Okmeter verwenden? M\u00f6glicherweise haben die Leute diese Expertise bereits viel mehr entwickelt als wir. Aber vielleicht auch nicht \u2014 vielleicht haben wir eine einzigartige Expertise, und wir m\u00fcssen Prometheus einsetzen und das weiterentwickeln.<\/p>\n

Plattformerstellung<\/h3>\n

\nDas ist ein komplexer Kommunikationsprozess. Wenn Sie grundlegende Praktiken haben, initiieren Sie die Kommunikation zwischen verschiedenen Ingenieuren und Spezialisten, die Anforderungen und Standards entwickeln und diese st\u00e4ndig f\u00fcr verschiedene Werkzeuge und Ans\u00e4tze anpassen. Hier ist die Kultur wichtig, die in DevOps vorhanden ist.<\/p>\n

\"Was
\nMit der Kultur ist alles sehr einfach \u2014 es sind Zusammenarbeit und Kommunikation<\/b>, das hei\u00dft, der Wunsch, gemeinsam im selben Bereich zu arbeiten, der Wunsch, ein Werkzeug gemeinsam zu beherrschen. Es gibt hier keine Raketenwissenschaft \u2014 alles ist sehr einfach, banal. Zum Beispiel leben wir alle im Treppenhaus und halten es sauber \u2014 so sieht diese Kultur aus.<\/p>\n

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

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

Wurde die Infrastrukturplattform \u0432\u044b\u0434\u0435\u043b\u0435\u043d\u0430? Wer ist f\u00fcr ihre Entwicklung verantwortlich? Verstehen Sie die Wettbewerbsvorteile Ihrer Infrastrukturplattform?<\/p>\n

Diese Fragen sollte man sich st\u00e4ndig stellen. Wenn etwas an externe Dienste ausgelagert werden kann, sollte man es auslagern. Wenn ein externer Dienst beginnt, Ihre Bewegungen zu blockieren, muss man ein System in sich selbst aufbauen.<\/p>\n

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

\n... es ist ein komplexes System, das Folgendes enthalten sollte:<\/p>\n