Die Definition von DevOps ist sehr komplex, weshalb wir jedes Mal die Diskussion darĂŒber neu beginnen mĂŒssen. Allein auf HabrĂ© gibt es tausende von Veröffentlichungen zu diesem Thema. Aber wenn Sie das hier lesen, wissen Sie sicherlich, was DevOps ist. Denn ich â weiĂ es nicht. Hallo, ich bin Alexander Titov (@), und wir werden einfach ĂŒber DevOps sprechen und ich werde meine Erfahrungen teilen.
Ich habe lange darĂŒber nachgedacht, wie ich meine ErzĂ€hlung nĂŒtzlich gestalten kann, weshalb es hier viele Fragen geben wird â sowohl die, die ich mir selbst stelle, als auch die, die ich unseren Kunden stelle. Indem ich diese Fragen beantworte, wird das VerstĂ€ndnis klarer. Ich werde erklĂ€ren, warum DevOps meiner Meinung nach notwendig ist, was es ist, wieder aus meiner Sicht, und wie Sie erkennen können, ob Sie auf dem Weg zu DevOps sind â wieder aus meiner Perspektive. Der letzte Punkt wird durch Fragen vermittelt. Wenn Sie diese selbst beantworten, können Sie verstehen, ob Ihr Unternehmen auf dem Weg zu DevOps ist oder ob es irgendwo Probleme gibt.
Einst bin ich durch die Wellen von Fusionen und Ăbernahmen geschwommen. Zuerst arbeitete ich bei einem kleinen Startup namens Qik, dann wurde es von dem etwas gröĂeren Unternehmen Skype ĂŒbernommen, welches spĂ€ter von Microsoft, dem noch gröĂeren Unternehmen, gekauft wurde. In diesem Moment wurde mir klar, wie sich die Vorstellungen von DevOps in Unternehmen unterschiedlicher GröĂen verĂ€ndern. Danach begann ich, den Markt aus der Perspektive von DevOps zu betrachten, und zusammen mit meinen Kollegen grĂŒndeten wir die Firma Express 42. Seit 6 Jahren navigieren wir mit ihr durch die Marktwellen.
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ördern in dieser Hinsicht Erfahrung und Expertise.
Warum DevOps
Die erste Frage, die alle stĂ€ndig beschĂ€ftigt â warum? Viele glauben, dass DevOps einfach Automatisierung oder ein Ă€hnliches Konzept ist, das bereits in jedem Unternehmen vorhanden war.
â Bei uns gab es Continuous Integration â das bedeutet, es gab bereits DevOps. Warum ist das alles nötig? Im Ausland haben sie SpaĂ, wĂ€hrend wir arbeiten mĂŒssen!
Nach 9 Jahren Entwicklung der Community und Methodik ist klar geworden, dass es sich nicht um bloĂe Marketingblitze handelt, aber es ist immer noch nicht ganz klar, wofĂŒr es nötig ist. Wie bei jedem Werkzeug oder Prozess hat auch DevOps spezifische Ziele, die es letztendlich erreicht.
Das alles hĂ€ngt damit zusammen, dass sich die Welt verĂ€ndert. 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ĂŒr festgelegten Struktur.
Im Prinzip sollte in der IT alles nach diesem Ansatz aufgebaut sein. Hier wird IT ausschlieĂlich zur Automatisierung von Prozessen genutzt.
Automatisierung Ă€ndert sich nicht oft, denn wenn ein Unternehmen im alten Trott unterwegs ist â was gibt es da zu Ă€ndern? Wenn es lĂ€uft, lass es so. Jetzt verĂ€ndert sich die Herangehensweise in der Welt, und der, der als Agile bezeichnet wird, sagt, dass das endgĂŒltige Ziel B nicht sofort sichtbar ist.
Wenn ein Unternehmen den Markt durchquert und mit den Kunden interagiert, erforscht es stÀndig den Markt und Àndert seinen Endpunkt B. Je öfter ein Unternehmen seine Richtung Àndert, desto erfolgreicher wird es letztlich, da es mehr Marktnischen wÀhlt.
Eine interessante Strategie wird von einem Unternehmen demonstriert, von dem ich kĂŒrzlich erfahren habe. One Box Shave ist ein Abonnementdienst, der Rasierklingen und Rasierzubehör in einer Box liefert. Sie können ihre "Box" fĂŒr verschiedene Kunden anpassen. DafĂŒr wird eine spezielle Software verwendet, die die Bestellung an die koreanische Fabrik weiterleitet, die die Waren produziert.
Dieses Produkt wurde von Unilever fĂŒr 1 Milliarde Dollar ĂŒbernommen. Jetzt konkurriert es mit Gillette und hat einen erheblichen Marktanteil bei den Verbrauchern in den USA gewonnen. One Box Shave sagt:
â 4 Klingen? Wirklich? Warum brauchen Sie das? Es verbessert keinesfalls die RasierqualitĂ€t. Ein speziell ausgewĂ€hlter Rasierschaum, Duft und ein hochwertiger Rasierer mit zwei Klingen lösen viel mehr Probleme als diese lĂ€cherlichen 4 Gillette-Klingen! Gehen wir bald auf 10 zurĂŒck?
So verĂ€ndert sich die Welt. Unilever berichtet, dass sie ein beeindruckendes IT-System haben, das dies ermöglicht. Am Ende sieht das wie ein Konzept aus. MarkteinfĂŒhrungszeit, ĂŒber das schon viele gesprochen haben.
Der Sinn der MarkteinfĂŒhrungszeit liegt nicht darin, wie hĂ€ufig wir bereitstellen. Man kann hĂ€ufig bereitstellen, aber die Release-Zyklen können lang sein. Wenn man drei Monate lange Release-Zyklen aneinanderreiht und jeweils um eine Woche verschiebt, scheint es, als wĂŒrde das Unternehmen einmal pro Woche bereitstellen. Doch von der Idee bis zur endgĂŒltigen Umsetzung vergehen drei Monate.
Die MarkteinfĂŒhrungszeit bedeutet, die Zeit von der Idee bis zur endgĂŒltigen Umsetzung zu minimieren.
In diesem Fall interagiert die Software mit dem Markt. So kommuniziert die Website von One Box Shave mit dem Kunden. Es gibt keine VerkĂ€ufer â nur eine Website, auf der der Besucher klickt und WĂŒnsche hinterlĂ€sst. Daher muss auf der Website stĂ€ndig etwas Neues bereitgestellt werden, und sie sollte gemÀà den WĂŒnschen aktualisiert werden. Zum Beispiel wird in SĂŒdkorea anders rasiert als in Russland, und sie mögen es nicht, wenn es nach Kiefer riecht, sondern beispielsweise nach Karottenvanille.
Da sich die Anforderungen an die Webseite schnell Ă€ndern, wandelt sich die Softwareentwicklung erheblich. Durch Software mĂŒssen wir herausfinden, was der Kunde möchte. FrĂŒher erfuhren wir das ĂŒber Umwege, beispielsweise durch das Business Management. Dann entwarfen wir Lösungen, ĂŒbertrugen die Anforderungen in das IT-System, und alles funktionierte bestens. Heute lĂ€uft es anders â die Software wird von allen Beteiligten im Prozess entworfen, einschlieĂlich der Ingenieure, die ĂŒber technische Spezifikationen erfahren, wie der Markt funktioniert, und ebenfalls ihre Einsichten mit dem Business teilen.
Zum Beispiel erfuhren wir bei Qik plötzlich, dass die Leute es sehr schĂ€tzen, Kontaktlisten auf unseren Server hochzuladen, und sie haben uns eine App bereitgestellt. Daran hatten wir anfangs nicht gedacht. In einem traditionellen Unternehmen hĂ€tte man dies wahrscheinlich als Bug interpretiert, da in den Spezifikationen nicht steht, dass es gut funktionieren sollte und alles improvisiert war. Man hĂ€tte diese Funktion abgeschaltet und gesagt: âDas benötigt niemand, das Wichtigste ist, dass die grundlegende FunktionalitĂ€t funktioniert.â Ein technologieorientiertes Unternehmen erkennt jedoch die Chance darin und beginnt, die Software entsprechend zu Ă€ndern.
Im Jahr 1968 formulierte der weitsichtige Melvin Conway die folgende Idee.
Eine Organisation, die ein System schafft, ist durch ein Design eingeschrÀnkt, das die Kommunikationsstruktur in dieser Organisation kopiert.
Um genauer zu sein, benötigt man fĂŒr 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öglich sein, Systeme zu schaffen, die eine sehr hohe Time-to-Market gewĂ€hrleisten können.
Mehr lesen kann . Es ist wichtig fĂŒr das VerstĂ€ndnis der Kultur oder Philosophie von DevOps, da das Einzige, was sich grundlegend in DevOps Ă€ndert, die Kommunikationsstruktur zwischen den Teams ist..
Aus der Sicht des Prozesses liefen vor DevOps alle Phasen: Analyse, Entwicklung, Test und Betrieb linear ab.
Im Fall von DevOps verlaufen all diese Prozesse gleichzeitig.
Nur so kann die Time-to-Market erreicht werden. FĂŒr Menschen, die im alten Prozess gearbeitet haben, erscheint das etwas futuristisch und insgesamt eher ungewohnt.
Warum ist DevOps also notwendig?
FĂŒr die Entwicklung digitaler Produkte. Wenn Ihr Unternehmen kein digitales Produkt hat, ist DevOps nicht erforderlich â das ist sehr wichtig.
DevOps ĂŒberwindet die GeschwindigkeitsbeschrĂ€nkungen des sequenziellen Softwareentwicklungsprozesses.. In ihm laufen alle Prozesse gleichzeitig ab.
Die KomplexitĂ€t nimmt zu. Wenn DevOps-Evangelisten sagen, dass es mit ihm einfacher wird, Software zu veröffentlichen â das ist Unsinn.
Mit DevOps wird alles nur komplizierter.
Auf der Konferenz am Stand von Avito konnte man sehen, was es bedeutet, einen Docker-Container zu deployen â eine unmögliche Aufgabe. Die KomplexitĂ€t wird ĂŒberdimensioniert, man muss viele BĂ€lle gleichzeitig jonglieren.
DevOps Àndert den gesamten Prozess und die Organisation im Unternehmen. Genauer gesagt, Àndert nicht DevOps, sondern das digitale Produkt. Um zu DevOps zu gelangen, muss dieser Prozess vollstÀndig geÀndert werden.
Fragen fĂŒr Fachleute.
Und wie sieht es bei Ihnen aus? Fragen, die Sie sich stellen können, wÀhrend Sie im Unternehmen arbeiten und sich als Fachkraft weiterentwickeln.
Haben Sie eine Strategie zur Erstellung eines digitalen Produkts? Wenn ja â schon gut. Das bedeutet, dass Ihr Unternehmen in Richtung DevOps geht.
Erstellt Ihr Unternehmen bereits ein digitales Produkt? Das bedeutet, dass Sie eine Stufe höher steigen und interessantere Dinge tun können â aus der Perspektive von DevOps. Ich spreche nur aus dieser Perspektive.
Ist Ihr Unternehmen einer der MarktfĂŒhrer im Bereich digitaler Produkte? Spotify, Yandex, Uber â Unternehmen, die derzeit an der Spitze des technologischen Fortschritts stehen.
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ĂŒr Sie von Interesse ist, sollten Sie vielleicht in ein anderes Unternehmen wechseln? Wenn Ihr Unternehmen in DevOps investieren möchte, aber Sie auf alle Fragen mit 'Nein' geantwortet haben, dann erinnert es an das wundervolle Nashorn, das sich niemals Ă€ndern wird.
Organisation
Wie bereits erwÀhnt, Àndert sich die Organisation im Unternehmen gemÀà dem Conway-Gesetz. Ich beginne mit dem, was DevOps daran hindert, in das Unternehmen einzudringen, insbesondere aus organisatorischer Sicht.
Das Problem der âSilosâ
Das englische Wort âSiloâ wurde hier ins Russische als âĐșĐŸĐ»ĐŸĐŽĐ”Ńâ ĂŒbersetzt. Das Wesen dieses Problems ist, dass zwischen den Teams kein Informationsaustausch stattfindet.. Jedes Team vertieft seine Expertise, ohne eine gemeinsame Karte zu erstellen, auf der man sich orientieren kann.
Das erinnert an jemanden, der gerade nach Berlin gekommen ist und noch nicht weiĂ, 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Ă€higkeit nicht, und man fĂŒhlt sich einfach verloren.
DevOps bietet an, diese Phase der Desorientierung zu ĂŒberwinden und gemeinsam eine Karte der Interaktionen zu erstellen.
Zwei Faktoren stehen dem entgegen.
Das Ergebnis eines Unternehmensmanagementsystems. Es besteht aus separaten hierarchischen "Brunnen". Beispielsweise gibt es bestimmte KPIs in Unternehmen, die dieses System unterstĂŒtzen. Auf der anderen Seite stehen die Gedanken der Person, die es schwer hat, ĂŒber ihre Expertise hinauszusehen und sich im gesamten System zurechtzufinden. Das ist einfach unbequem. Stellen Sie sich vor, Sie sind am Flughafen in Bangkok â 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ĂŒhrer finden muss, um dorthin zu gelangen.
Das Hauptproblem, das Ingenieure, die sich dem Geist von DevOps verschrieben haben und viele BĂŒcher von Fowler und anderen gelesen haben, betrifft die sogenannten "Brunnen". "Brunnen" hindern uns daran, "offensichtliche" Dinge zu tun.Oft treffen wir uns nach dem DevOps Moscow, reden miteinander, und die Leute beklagen sich:
â Wir wollten einfach nur CI starten, aber es stellte sich heraus, dass das fĂŒr das Management nicht notwendig ist.
Das passiert genau deshalb, weil CI und der Continuous Delivery-Prozess an der Schnittstelle vieler Fachgebiete liegt. Ohne das Problem der "Brunnen" auf organisatorischer Ebene zu ĂŒberwinden, wird es nicht möglich sein, weiterzukommen, egal was Sie tun und wie traurig das auch sein mag.
Jeder Teilnehmer im Unternehmen â Backend- und Frontend-Entwickler, Tester, DBA, Betrieb, Netzwerk â grĂ€bt in seine eigene Richtung, wĂ€hrend niemand ansonsten eine gemeinsame Karte hat, auĂer dem Manager, der sie irgendwie ĂŒberblickt und nach dem Prinzip "teile und herrsche" verwaltet.
Die Menschen kÀmpfen um irgendwelche Sterne oder Flaggen, jeder grÀbt in seiner eigenen Expertise.
Wenn die Aufgabe besteht, all dies zusammenzufĂŒhren und eine gemeinsame Pipeline zu erstellen, stellt sich die Frage â was sollen wir ĂŒberhaupt tun? Man muss sich irgendwie verstĂ€ndigen, aber wie? Das hat uns in der Schule niemand beigebracht. Wir haben bereits in der Schule gelernt: die achte Klasse â wow! â im Vergleich zur siebten Klasse! Hier ist es dasselbe.
Ist das auch in Ihrem Unternehmen so?
Um das zu ĂŒberprĂŒfen, können Sie sich folgende Fragen stellen.
Verwenden die Teams gemeinsame Werkzeuge und tragen sie zur Ănderung dieser gemeinsamen Werkzeuge bei?
Wie oft werden die Teams umgebildet â wechseln Spezialisten von einem Team in ein anderes? In der DevOps-Umgebung wird das normal, denn manchmal kann eine Person einfach nicht verstehen, was in einem anderen Fachgebiet geschieht. Sie wechselt in eine andere Abteilung, arbeitet dort zwei Wochen lang, um sich eine Orientierungskarte und Interaktionsmuster zu erstellen.
Kann ein VerĂ€nderungskomitee gegrĂŒndet werden, um etwas zu Ă€ndern? Oder benötigt man dafĂŒr die UnterstĂŒtzung der höchsten FĂŒhrungsebene und einen entsprechenden Befehl? KĂŒrzlich 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ĂŒrlich langwierig und bedauerlich.
Wie wichtig ist es fĂŒr Manager, persönliche Erfolge zu erzielen, unabhĂ€ngig von den Leistungen des Unternehmens?
Wenn Sie sich diese Fragen selbst beantworten, wird klarer, ob Sie dieses Problem in Ihrem Unternehmen haben.
Infrastruktur als Code
Nachdem dieses Problem ĂŒberwunden ist, ist die erste wichtige Praxis, ohne die es schwierig ist, im DevOps-Bereich weiterzukommen â Infrastruktur als Code.
Am hÀufigsten wird Infrastruktur als Code so wahrgenommen:
â Lassen Sie uns alles mit Bash automatisieren, uns mit Skripten eindecken, damit die Admins weniger manuelle Arbeit haben!
Aber das ist nicht so.
Infrastruktur als Code bedeutet, dass Sie das IT-System, mit dem Sie arbeiten, in Form von Code beschreiben, um seinen Zustand stÀndig zu verstehen.
Gemeinsam mit anderen Teams erstellen Sie eine Code-Karte, die fĂŒr alle verstĂ€ndlich ist und als Orientierung dient. Es spielt keine Rolle, ob dies mit Chef, Ansible, Salt oder YAML-Dateien in Kubernetes geschieht â der Unterschied ist irrelevant.
Auf der Konferenz berichtete ein Kollege von 2GIS, wie sie ein internes Tool fĂŒr Kubernetes entwickelt haben, das die Struktur einzelner Systeme beschreibt. Um 500 Systeme zu beschreiben, benötigten sie ein spezielles Werkzeug, das diese Beschreibung generiert. Mit dieser Beschreibung kann jeder miteinander abgleichen, Ănderungen ĂŒberwachen und sehen, wie man sie anpassen und verbessern kann, sowie was fehlt.
Sie werden zustimmen, dass einzelne Bash-Skripte normalerweise nicht dieses VerstĂ€ndnis bieten. In einem der Unternehmen, in denen ich gearbeitet habe, gab es sogar den Begriff âwrite onlyâ-Skript â wenn das Skript geschrieben ist, ist es unmöglich, es spĂ€ter zu lesen. Ich denke, das kommt Ihnen ebenfalls bekannt vor.
Infrastructure as Code â das ist Code, der den aktuellen Zustand der Infrastruktur beschreibt. An diesem Code arbeiten zahlreiche Produkt-, Infrastruktur- und Serviceteams gemeinsam, und das Wichtigste ist, dass alle verstehen, wie dieser Code funktioniert.
Der Code wird gemÀà den besten Programmierpraktiken behandelt.: gemeinschaftliche Entwicklung, Code-Reviews, XP-Programmierung, Tests, Pull-Requests, CI fĂŒr Infrastruktur-Code â all das ist wertvoll und anwendbar.
Code wird zur gemeinsamen Sprache fĂŒr alle Ingenieure.
Die Ănderung von Infrastruktur im Code nimmt nicht viel Zeit in Anspruch.. Ja, auch im Infrastruktur-Code kann technischer Schulden entstehen. Normalerweise stoĂen Teams nach etwa anderthalb Jahren, nachdem sie âInfrastructure as Codeâ eingefĂŒhrt haben, auf dieses Problem, wenn sie eine Vielzahl von Skripten oder sogar Ansible verwenden, die sie als Spaghetticode schreiben, und noch bash-Skripte hinzufĂŒgen!
Wichtig: Wenn Sie diesen Schrott noch nicht ausprobiert haben, merken Sie sich folgendes: Ansible ist kein Bash.! Lesen Sie die Dokumentation sorgfĂ€ltig und lernen Sie, was darĂŒber geschrieben wird.
Infrastructure as Code bedeutet, den Infrastruktur-Code in separate Schichten zu unterteilen.
In unserem Unternehmen unterscheiden wir drei grundlegende Schichten, die sehr verstĂ€ndlich und einfach sind, aber es können auch mehr vorhanden sein. Sie können Ihren Infrastrukturcode ĂŒberprĂŒfen und feststellen, ob Sie diese Bedingung erfĂŒllen oder nicht. Wenn keine Schichten definiert sind, sollten Sie sich Zeit nehmen und etwas refaktorisieren.
Grundschicht â das ist, wie das Betriebssystem, Backups und andere Low-Level-Aspekte konfiguriert werden, zum Beispiel, wie Kubernetes auf der Basisschicht bereitgestellt wird.
Service-Level â das sind die Dienste, die Sie den Entwicklern zur VerfĂŒgung stellen: Logging als Dienst, Monitoring als Dienst, Datenbank als Dienst, Lastverteilung als Dienst, Warteschlange als Dienst, Continuous Delivery als Dienst â eine Vielzahl von Diensten, die verschiedene Teams der Entwicklung anbieten können. All dies sollte in Ihrer Konfigurationsmanagement-System in separaten Modulen beschrieben werden.
Schicht, in der Anwendungen erstellt werden und beschrieben wird, wie sie auf den beiden vorherigen Schichten bereitgestellt werden.
Kontrollfragen
VerfĂŒgt Ihr Unternehmen ĂŒber 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önnen sich an das Schema Base-service-APP halten. Wie schwierig ist es, Ănderungen vorzunehmen?
Wenn Sie schon einmal erlebt haben, dass Ănderungen eineinhalb Tage in Anspruch genommen haben, bedeutet das, dass Sie technische Schulden haben, mit denen Sie sich auseinandersetzen mĂŒssen. Sie sind sozusagen auf die Probleme der technischen Schulden im Infrastrukturcode gestoĂen. Ich erinnere mich an viele solche Geschichten, bei denen man, um ein CCTL zu Ă€ndern, die HĂ€lfte des Infrastrukturcodes umschreiben musste, weil KreativitĂ€t und der Wunsch, alles zu automatisieren, dazu gefĂŒhrt haben, dass alles ĂŒberladen ist, alle manuellen Eingriffe entfernt wurden und jetzt refaktoriert werden muss.
Kontinuierliche Bereitstellung
Lassen Sie uns die Debit- mit der Kreditseite ausgleichen. ZunÀchst prÀsentieren wir eine grundlegende Beschreibung der Infrastruktur, die zwar einfach gehalten sein kann, aber dennoch erforderlich ist, um die weitere Arbeit zu ermöglichen. Ansonsten ist unklar, auf welcher Grundlage die kontinuierliche Lieferung erfolgen soll. All diese Praktiken laufen parallel, wenn Sie im Bereich DevOps tÀtig werden, aber der Ausgangspunkt ist das VerstÀndnis, was Sie haben und wie Sie es verwalten. Dies entspricht der Praxis der Infrastruktur als Code.
Sobald Sie verstanden haben, was Sie haben und wie Sie es verwalten können, beginnen Sie, Ideen zu entwickeln, wie der Code des Entwicklers so schnell wie möglich in die Produktion gelangt. Ich meine das in Zusammenarbeit mit dem Entwickler â denken Sie an das Problem der 'Brunnen', das bedeutet, dass nicht Einzelne diese Ideen entwickeln, sondern das Team gemeinsam.
Als wir mit Ivan Evtuhoovich das erste Buch von Jez Humble und einer Gruppe von Autoren «Continuous Delivery», die 2009 veröffentlicht wurde, hat lange darĂŒber nachgedacht, wie ihr Name ins Deutsche ĂŒbersetzt werden könnte. Wir wollten es als âPermanent liefernâ ĂŒbersetzen, aber leider wurde es als âKontinuierliche Lieferungâ ĂŒbersetzt. Ich habe das GefĂŒhl, dass in unserem Namen etwas wirklich Deutsches steckt, mit einem gewissen Nachdruck.
Permanent liefern bedeutet
Der Code, der im Produkt-Repository liegt, kann jederzeit in die Produktion ĂŒbernommen werden.. Er kann zwar auch nicht ĂŒbernommen werden, ist aber immer bereit dazu. Dementsprechend schreiben Sie immer Code mit einem schwer erklĂ€rbaren GefĂŒhl einer gewissen Unruhe im Nacken. Dieses GefĂŒhl tritt hĂ€ufig auf, wenn Sie Infrastrukturcode ausrollen. Dieses GefĂŒhl der Unruhe sollte vorhanden sein â es löst Denkprozesse aus, die es ermöglichen, etwas anders zu codieren. Es sollte in den Regeln innerhalb der Entwicklung festgehalten werden.
Um permanent zu liefern, ist ein Artefaktformat erforderlich, das ĂŒber die Infrastrukturplattform verlĂ€uft. Wenn Sie verschiedene Formate von âAbfĂ€llenâ ĂŒber eine Infrastrukturplattform werfen, wird sie unvereinheitlicht, was die Wartung erschwert und technische Schulden verursacht. Das Format des Artefakts muss angeglichen werden â das ist auch eine gemeinsame Aufgabe: Alle mĂŒssen zusammenkommen, kreativ denken und dieses Format entwickeln.
Das Artefakt wird kontinuierlich verbessert und verĂ€ndert sich wĂ€hrend der Bereitstellung im Produktionsumfeld im Laufe des Pipelines. Wenn das Artefakt durch die Pipeline bewegt wird, trifft es stĂ€ndig auf Herausforderungen, die ihm unangenehm sind und denen Ă€hnlich sind, auf die das Artefakt stöĂt, das Sie in die Produktion bringen. WĂ€hrend in der klassischen Entwicklung ein Systemadministrator fĂŒr 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ötzlich wurde ein Lasttest gestartet.
Das erinnert ein wenig an das Spiel Pac-Man â Artefakte durchlaufen eine bestimmte Historie. Dabei ist es wichtig, zu kontrollieren, ob der Code tatsĂ€chlich dieser Historie folgt und ob sie mit Ihrer Produktion in Verbindung steht. Produktionsgeschichten können in den Continuous Delivery-Prozess integriert werden: FrĂŒher gab es Zeiten, als etwas abgestĂŒrzt ist. Lassen Sie uns dieses Szenario einfach in das System programmieren. Jedes Mal wird der Code dieses Szenario ebenfalls durchlaufen, und beim nĂ€chsten Mal werden Sie mit diesem Problem nicht konfrontiert. Sie werden viel frĂŒher darĂŒber informiert, bevor es Ihren Kunden erreicht.
Verschiedene Deployment-Strategien. Zum Beispiel nutzen Sie A/B-Tests oder Canary-Deployments, um den Code auf verschiedenen Kunden auszuprobieren, Informationen darĂŒber zu erhalten, wie der Code funktioniert, und das viel frĂŒher, als wenn er auf 100 Millionen Benutzer ausgerollt wird.
âKontinuierliche Lieferungâ sieht so aus.
Der Prozess der Bereitstellung â Dev, CI, Test, PreProd, Prod â ist keine getrennte Umgebung, sondern Stufen oder Stationen mit festen Summen, durch die Ihr Artefakt lĂ€uft.
Wenn Sie Code fĂŒr Infrastruktur haben, der als Base Service APP beschrieben ist, hilft er ihn nicht zu vergessen, alle Szenarien., und sie ebenfalls in Form von Code fĂŒr dieses Artefakt festzuhalten, das Artefakt zu fördern und es wĂ€hrend des Fortschritts zu Ă€ndern.
Fragen zur SelbstĂŒberprĂŒfung
Liegt die Zeit von der Beschreibung des Features bis zur Produktionsfreigabe in 95 % der FÀlle unter einer Woche? Verbessert sich die QualitÀt des Artefakts in jeder Phase der Pipeline? Gibt es eine Historie, durch die es geht? Verwenden Sie unterschiedliche Bereitstellungsstrategien?
Wenn alle Antworten ja sind, dann sind Sie unglaublich cool! Schreiben Sie die Antworten in die Kommentare â ich wĂŒrde mich freuen).
Feedback
Dies ist die komplexeste Praxis von allen. Auf der DevOpsConf hatte ein Kollege von Infobip, der darĂŒber sprach, etwas Schwierigkeiten mit den Worten, weil es wirklich eine sehr komplexe Praxis ist, die besagt, dass man alles im Auge behalten muss!
Zum Beispiel, vor langer Zeit, als ich bei Qik arbeitete und wir erkannten, dass wir wirklich alles ĂŒberwachen mussten. Das haben wir gemacht, und in Zabbix hatten wir 150.000 Items, die stĂ€ndig ĂŒberwacht wurden. Das war beĂ€ngstigend, der technische Direktor drehte sich mit dem Finger an der SchlĂ€fe:
â Leute, warum quĂ€lt ihr den Server mit unklaren Dingen?
Aber dann geschah ein Fall, der zeigte, dass dies tatsÀchlich eine sehr coole Strategie war.
Einer unserer Dienste begann dauerhaft auszufallen. Interessanterweise fiel er ursprĂŒnglich nicht aus, da dort kein zusĂ€tzlicher Code hinzugefĂŒgt wurde, weil es sich um einen einfachen Broker handelte, der fast keine GeschĂ€ftsfunktionalitĂ€t hatte â er ĂŒbermittelte einfach Nachrichten zwischen verschiedenen Diensten. Der Service hatte sich ĂŒber 4 Monate nicht verĂ€ndert, und plötzlich begann er mit dem Fehler âSegmentation faultâ auszufallen.
Wir waren schockiert, als wir unsere Grafiken in Zabbix öffneten und feststellten, dass sich das Verhalten der Anfragen im API-Service, der diesen Broker verwendet, vor anderthalb Wochen stark verĂ€ndert hatte. Danach ĂŒberprĂŒften wir, dass sich die Frequenz des Sendens eines bestimmten Nachrichtentyps geĂ€ndert hatte. SchlieĂlich fanden wir heraus, dass es sich um Android-Clients handelte. Wir fragten:
â Guys, was ist vor anderthalb Wochen passiert?
Im GesprĂ€ch hörten wir eine interessante Geschichte darĂŒber, dass sie das UI ĂŒberarbeitet haben. Kaum jemand wĂŒrde sofort sagen, dass sie die HTTP-Bibliothek gewechselt haben. FĂŒr Android-Kunden ist es wie der Wechsel von Seife im Bad â sie merken das einfach nicht. Letztendlich fanden wir nach 40 Minuten GesprĂ€ch heraus, dass sie tatsĂ€chlich die HTTP-Bibliothek gewechselt haben und sich die Standard-Zeiten geĂ€ndert haben. Dies fĂŒhrte dazu, dass sich das Verhalten des Datenverkehrs auf dem API-Server verĂ€nderte, was zu einer Situation fĂŒhrte, die einen Wettlauf innerhalb des Brokers verursachte, wodurch dieser anfing, abzustĂŒrzen.
Ohne tiefgehendes Monitoring ist es völlig unmöglich, das zu erkennen.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öst werden kann. Wenn Sie alles ĂŒberwachen, nachverfolgen und sĂ€mtliche Ereignisse dokumentieren, die Sie haben, und Monitoring als Test nutzen â indem Sie den Code schreiben und sofort angeben, wie er ĂŒberwacht werden soll, ebenfalls im Code (wir haben bereits Infrastruktur als Code), wird alles klar wie der HandflĂ€chen. Sogar so komplexe Probleme können leicht verfolgt werden.
Sammeln Sie alle Informationen darĂŒber, was mit dem Artefakt in jeder Phase des Lieferprozesses passiert â nicht in der Produktion.
Laden 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 â sammeln Sie alles.
Andernfalls wird es schwierig sein, sich zurechtzufinden. Ich habe bereits gesagt, dass DevOps eine gröĂere KomplexitĂ€t mit sich bringt. Um mit dieser KomplexitĂ€t umzugehen, benötigen Sie eine solide Analyse..
Fragen zur Selbstkontrolle
Ist Ihr Monitoring und Logging ein Entwicklungstool fĂŒr Sie? Denken Ihre Entwickler, und Sie selbst auch, beim Codieren daran, wie man das Monitoring einrichtet?
Erfahren Sie von Problemen durch Kunden? Verstehen Sie den Kunden besser durch Monitoring und Logging? Verstehen Sie das System besser durch Monitoring und Logging? Ăndern Sie das System einfach, weil Sie sehen, dass der Trend im System steigt und wissen, dass in 3 Wochen alles zusammenbrechen wird?
Wenn Sie diese drei Komponenten haben, können Sie darĂŒber nachdenken, welche Infrastrukturplattform Ihr Unternehmen hat.
Infrastrukturplattform
Es geht nicht darum, dass es sich um eine Sammlung von separaten Werkzeugen handelt, die in jedem Unternehmen vorhanden sind.
Der Sinn einer Infrastrukturplattform besteht darin, dass alle Teams diese Werkzeuge gemeinsam nutzen und weiterentwickeln.
Es ist klar, dass es separate Teams gibt, die fĂŒr die Entwicklung bestimmter Teile der Infrastrukturplattform verantwortlich sind. Doch die Verantwortung fĂŒr die Weiterentwicklung, FunktionsfĂ€higkeit und Förderung der Infrastrukturplattform trĂ€gt jeder Ingenieur. Auf interner Ebene wird dies zu einem gemeinsamen Werkzeug..
Alle Teams entwickeln die Infrastrukturplattform und pflegen sie, als wÀre sie ihr eigenes IDE.. In Ihrem IDE installieren Sie verschiedene Plugins, um alles schön und schnell zu gestalten, und konfigurieren die Tastenkombinationen. Wenn Sie Sublime, Atom oder Visual Studio Code öffnen, sehen Sie viele Code-Fehler und erkennen, dass es unmöglich ist, zu arbeiten, und das stimmt Sie sofort traurig, sodass Sie eilig beginnen, Ihr IDE zu reparieren.
Behandeln Sie Ihre Infrastrukturplatform ebenso. Wenn Sie feststellen, dass etwas nicht stimmt, hinterlassen Sie eine Anfrage, falls Sie es nicht selbst beheben können. Wenn es jedoch etwas Einfaches ist, beheben Sie es selbst und senden Sie einen Pull-Request â das Team wird es prĂŒfen und hinzufĂŒgen. Dies ist ein etwas anderer Ansatz fĂŒr das Ingenieurwerkzeug im Kopf des Entwicklers.
Die Infrastrukturplatform ermöglicht den Transfer von Artefakten von der Entwicklung zum Kunden mit einer stĂ€ndigen QualitĂ€tsverbesserung.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 â sie sind nicht ĂŒber das Internet zu finden.
In diesem Moment wird die Infrastrukturplatform zu Ihrem Wettbewerbsvorteil,da darin enthalten ist, was beim Werkzeug des Wettbewerbers fehlt. Je tiefer Ihre IP ist, desto gröĂer ist Ihr Wettbewerbsvorteil in Bezug auf die Time-to-Market. Hier stellt sich die Problematik des Vendor-Lockings: Sie können eine Plattform eines anderen ĂŒbernehmen, aber indem Sie die Erfahrung anderer nutzen, werden Sie nicht verstehen, wie relevant sie fĂŒr 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Ă€ngt, und Vendor Lock sollte hier vermieden werden. Auch darĂŒber sollten Sie nachdenken.
Schema
Dies ist ein grundlegendes Schema der Infrastrukturplattform, das Ihnen hilft, alle Praktiken und Prozesse in einem DevOps-Unternehmen zu etablieren.
Lassen Sie uns betrachten, woraus sie besteht.
Das Ressourcenorchestrierungssystem, das CPU, Speicher und Speicher fĂŒr Anwendungen und andere Dienste bereitstellt. DarĂŒber hinaus gibt es Basisdienste: Ăberwachung, Protokollierung, CI/CD-Engine, Artefakt-Repository, Infrastruktur als Code-System.
Höhere Dienste: Datenbank als Dienst, Warteschlangen als Dienst, Load Balancing als Dienst, BildvergröĂerung als Dienst, Big Data-Fabrik als Dienst. DarĂŒber hinaus gibt es eine Pipeline, die stĂ€ndig modifizierten Code an Ihren Kunden liefert..
Sie erhalten Informationen darĂŒber, wie Ihre Software bei den Kunden funktioniert, verĂ€ndern sie, liefern diesen Code erneut und erhalten Informationen zurĂŒck â so entwickeln Sie kontinuierlich sowohl Ihre Infrastrukturplattform als auch Ihre Software weiter.
Das Diagramm des Delivery-Pipelines besteht aus mehreren Phasen. Doch dies ist ein grundlegendes Diagramm, das nur als Beispiel dient â es sollte nicht eins zu eins repliziert werden. Die Phasen interagieren mit den Services, als ob sie Services wĂ€ren â jeder Baustein der Plattform hat seine eigene Geschichte: wie die Ressourcen zugewiesen werden, wie die Anwendung gestartet wird, wie sie mit den Ressourcen arbeitet, ĂŒberwacht wird und verĂ€ndert wird.
Es ist wichtig zu verstehen, dass jeder Teil der Plattform eine Geschichte hat. Fragen Sie sich â welche Geschichte erzĂ€hlt dieser Baustein? Vielleicht sollten wir ihn entfernen und durch einen externen Service ersetzen. Zum Beispiel, könnte man Okmeter anstelle des Bausteins verwenden? Möglicherweise haben die Kollegen diese Expertise bereits viel weiter entwickelt als wir. Aber vielleicht auch nicht â vielleicht haben wir eine einzigartige Expertise und sollten Prometheus einsetzen und dies weiterentwickeln.
Erstellung der Plattform
Dies ist ein komplexer Kommunikationsprozess. Wenn Sie ĂŒber grundlegende Praktiken verfĂŒgen, initiieren Sie die Kommunikation zwischen verschiedenen Ingenieuren und Fachleuten, die Anforderungen und Standards entwickeln und diese kontinuierlich an verschiedene Werkzeuge und AnsĂ€tze anpassen. In diesem Kontext ist die vorhandene Kultur im DevOps-Bereich entscheidend.
Mit Kultur ist alles sehr einfach â es geht um Zusammenarbeit und Kommunikation, das heiĂt, den gemeinsamen Wunsch, in einem gemeinsamen Bereich miteinander zu arbeiten und zusammen ein Werkzeug zu beherrschen. Hier gibt es nichts, was besonders kompliziert ist â es ist alles sehr einfach, sogar banal. Zum Beispiel leben wir alle in einem Wohnhaus und halten es sauber â das ist eine solche Ebene der Kultur.
Wie sieht es bei Ihnen aus?
Wieder Fragen, die Sie sich selbst stellen können.
Ist die Infrastrukturplattform klar definiert? Wer ist verantwortlich fĂŒr ihre Weiterentwicklung? Verstehen Sie die Wettbewerbsvorteile Ihrer Infrastrukturplattform?
Diese Fragen sollten Sie sich stĂ€ndig stellen. Wenn etwas an externe Dienstleistungen ausgelagert werden kann â sollten Sie es auslagern. Wenn ein externer Dienstleister Ihr Vorankommen behindert, sollten Sie ein internes System aufbauen.
Also, DevOpsâŠ
âŠist ein komplexes System, und es sollten folgende Elemente vorhanden sein:
- Ein digitales Produkt.
- Business-Module, die dieses digitale Produkt weiterentwickeln.
- Produktteams, die Code schreiben.
- Praktiken des Continuous Delivery.
- Plattformen als Dienst.
- Infrastruktur als Dienst.
- Infrastruktur als Code.
- Einzelne Praktiken zur GewÀhrleistung der ZuverlÀssigkeit, die in DevOps integriert sind.
- Eine Feedbackpraxis, die all dies beschreibt.
Sie können dieses Schema verwenden und markieren, was Sie bereits in irgendeiner Form in Ihrem Unternehmen haben: Es hat sich entwickelt oder muss noch entwickelt werden.
In nur zwei Wochen findet . im Rahmen von RIT++. Kommen Sie zur Konferenz, bei der viele spannende VortrĂ€ge zu Continuous Delivery, Infrastruktur als Code und DevOps-Transformation auf Sie warten. , die letzte Frist fĂŒr die Preise ist der 20. Mai.
Quelle: habr.com
