Was ist DevOps?

Die Definition von DevOps ist sehr komplex, daher müssen wir die Diskussion darüber jedes Mal von vorne beginnen. Allein auf Habré gibt es tausend Veröffentlichungen zu diesem Thema. Aber wenn Sie dies lesen, wissen Sie wahrscheinlich, was DevOps ist. Weil ich nicht bin. Hallo, ich heiße Alexander Titov (@Osminog), und wir reden einfach über DevOps und ich werde meine Erfahrungen teilen.

Ich habe lange darüber nachgedacht, wie ich meine Geschichte nützlich machen kann, daher wird es hier viele Fragen geben – diejenigen, die ich mir selbst stelle, und diejenigen, die ich den Kunden unseres Unternehmens stelle. Durch die Beantwortung dieser Fragen wird das Verständnis verbessert. Ich werde Ihnen sagen, warum DevOps aus meiner Sicht notwendig ist, was es wiederum aus meiner Sicht ist und wie Sie aus meiner Sicht verstehen können, dass Sie sich wieder in Richtung DevOps bewegen. Der letzte Punkt wird durch Fragen sein. Indem Sie sie selbst beantworten, können Sie verstehen, ob sich Ihr Unternehmen in Richtung DevOps bewegt oder ob es in irgendeiner Weise Probleme gibt.

Früher war ich auf den Wellen von Fusionen und Übernahmen unterwegs. Zuerst arbeitete ich für ein kleines Startup namens Qik, dann wurde es von einem etwas größeren Unternehmen namens Skype gekauft, das wiederum von einem etwas größeren Unternehmen namens Microsoft gekauft wurde. In diesem Moment begann ich zu erkennen, wie sich die Idee von DevOps in Unternehmen unterschiedlicher Größe veränderte. Danach begann ich mich dafür zu interessieren, DevOps aus Marktsicht zu betrachten, und meine Kollegen und ich gründeten das Unternehmen Express 42. Seit nunmehr 6 Jahren bewegen wir uns auf den Wellen des Marktes.

Unter anderem bin ich einer der Organisatoren der DevOps-Moskau-Community und Organisator der DevOps-Days 2017, aber 2018 habe ich nicht organisiert. Express 42 arbeitet mit vielen Unternehmen zusammen. Wir bauen DevOps dort aus, beobachten, wie es passiert, ziehen Schlussfolgerungen, analysieren, erzählen allen unsere Schlussfolgerungen und schulen Menschen in DevOps-Praktiken. Generell tun wir unser Bestes, um unsere Erfahrung und unser Fachwissen in dieser Hinsicht zu erweitern.

Warum DevOps

Die erste Frage, die jeden und immer beschäftigt, ist: Warum? Viele Leute denken, dass DevOps nur Automatisierung oder etwas Ähnliches ist, das jedes Unternehmen bereits hatte.

— Wir hatten Continuous Integration – das bedeutet, dass wir bereits DevOps hatten, und warum wird all dieses Zeug benötigt? Sie amüsieren sich im Ausland, aber sie halten uns von der Arbeit ab!

Im Laufe der 9-jährigen Entwicklung der Community und Methodik ist bereits klar geworden, dass dies immer noch kein Marketing-Glanz ist, aber es ist immer noch nicht ganz klar, warum es notwendig ist. Wie jedes Tool und jeder Prozess hat DevOps bestimmte Ziele, die es letztendlich erreicht.

All dies ist darauf zurückzuführen, dass sich die Welt verändert. Er entfernt sich vom Enterprise-Ansatz, bei dem sich Unternehmen, wie unser St. Petersburger Klassiker besang, direkt auf einen Traum zubewegen, von Punkt A nach Punkt B gemäß einer bestimmten Strategie und mit einer dafür aufgebauten bestimmten Struktur.

Grundsätzlich sollte alles in der IT nach diesem Ansatz aufgebaut sein. Dabei dient die IT ausschließlich der Automatisierung von Prozessen.

Die Automatisierung ändert sich nicht oft, denn was gibt es zu ändern, wenn ein Unternehmen in ausgetretene Pfade gerät? Es funktioniert – nicht anfassen. Mittlerweile ändern sich die Herangehensweisen in der Welt, und der Ansatz namens „Agile“ deutet darauf hin, dass Endpunkt B nicht sofort sichtbar ist.

Wenn ein Unternehmen den Markt betritt, mit einem Kunden zusammenarbeitet, erkundet es ständig den Markt und ändert den Endpunkt B. Darüber hinaus ist es am Ende umso erfolgreicher, je öfter das Unternehmen seine Richtung ändert, da es sich für mehr Märkte entscheidet Nischen.

Die Strategie wird durch ein interessantes Unternehmen demonstriert, von dem ich kürzlich erfahren habe. One Box Shave ist ein Abonnement-Lieferservice für Rasierer und Rasierzubehör in einer Box. Sie wissen, wie sie ihre „Box“ für verschiedene Kunden anpassen können. Dies übernimmt eine bestimmte Software, die die Bestellung dann an die koreanische Fabrik sendet, die die Ware produziert.

Dieses Produkt wurde von Unilever für 1 Milliarde US-Dollar gekauft. Es konkurriert nun mit Gillette und hat dem amerikanischen Markt einen erheblichen Anteil an Verbrauchern abgenommen. One Box Shave sagt:

— 4 Klingen? Meinst du das ernst? Warum brauchen Sie das? Es verbessert nicht die Qualität der Rasur. Eine speziell ausgewählte Creme, ein Duft und ein hochwertiger Rasierer mit zwei Klingen lösen viel mehr Probleme als diese blöden 4 Gillette-Klingen! Werden wir bald 10 erreichen?

So verändert sich die Welt. Unilever behauptet, dass sie über ein cooles IT-System verfügen, das dies ermöglicht. Am Ende sieht es wie ein Konzept aus Time-to-Market, worüber noch niemand gesprochen hat.

Bei der Time-to-Market kommt es nicht darauf an, wie oft wir sie bereitstellen. Sie können häufig bereitstellen, aber die Release-Zyklen werden lang sein. Wenn man dreimonatige Release-Zyklen übereinander legt und sie um eine Woche verschiebt, stellt sich heraus, dass das Unternehmen scheinbar einmal pro Woche ein Deployment durchführt. Und von der Idee bis zur finalen Umsetzung vergehen 3 Monate.

Beim Time-to-Market geht es darum, die Zeit von der Idee bis zur endgültigen Umsetzung zu minimieren.

In diesem Fall interagiert Software mit dem Markt. Auf diese Weise interagiert die One Box Shave-Website mit dem Kunden. Sie haben keine Verkäufer – nur eine Website, auf die Besucher klicken und Wünsche hinterlassen. Dementsprechend muss ständig etwas Neues auf der Seite gepostet und den Wünschen entsprechend aktualisiert werden. In Südkorea beispielsweise rasieren sie sich anders als in Russland und mögen den Duft nicht von Kiefern, sondern beispielsweise von Karotten und Vanille.

Da es notwendig ist, den Inhalt der Website schnell zu ändern, verändert sich die Softwareentwicklung stark. Durch Software müssen wir herausfinden, was der Kunde will. Früher haben wir das auf Umwegen gelernt, zum Beispiel durch die Betriebswirtschaftslehre. Dann haben wir es entworfen, die Anforderungen in das IT-System eingegeben und alles war cool. Jetzt ist es anders: Software wird von allen am Prozess Beteiligten entworfen, auch von Ingenieuren, denn durch technische Spezifikationen lernen sie, wie der Markt funktioniert, und teilen ihre Erkenntnisse auch mit dem Unternehmen.

Bei Qik erfuhren wir beispielsweise plötzlich, dass es den Leuten wirklich Spaß macht, Kontaktlisten auf den Server hochzuladen, und stellten uns eine Anwendung zur Verfügung. Wir haben zunächst nicht darüber nachgedacht. In einem klassischen Unternehmen hätte jeder entschieden, dass dies ein Fehler sei, da die Spezifikation nicht besagte, dass es großartig funktionieren sollte und im Allgemeinen auf der Knie implementiert wurde, hätten sie die Funktion ausgeschaltet und gesagt: „Niemand braucht das, Das Wichtigste ist, dass die Hauptfunktionalität funktioniert.“ . Und das Technologieunternehmen sieht darin eine Chance und beginnt, die Software entsprechend zu verändern.

Im Jahr 1968 formulierte ein Visionär, Melvin Conway, die folgende Idee.

Die Organisation, die das System erstellt, wird durch ein Design eingeschränkt, das die Kommunikationsstruktur dieser Organisation nachbildet.

Genauer gesagt: Um Systeme eines anderen Typs zu produzieren, muss man auch über eine Kommunikationsstruktur innerhalb eines Unternehmens eines anderen Typs verfügen. Wenn Ihre Kommunikationsstruktur auf der obersten Hierarchieebene aufgebaut ist, ist es Ihnen nicht möglich, Systeme zu erstellen, die einen sehr hohen Time-to-Market-Indikator liefern können.

Lesen über Conways Gesetz kann man über Links. Es ist wichtig für das Verständnis der DevOps-Kultur oder -Philosophie, weil Das Einzige, was sich bei DevOps grundlegend ändert, ist die Struktur der Kommunikation zwischen Teams.

Aus Prozesssicht verliefen vor DevOps alle Phasen: Analyse, Entwicklung, Tests, Betrieb linear.
Bei DevOps laufen alle diese Prozesse gleichzeitig ab.

Die Time-to-Market ist die einzige Möglichkeit, dies zu erreichen. Für Leute, die im alten Prozess gearbeitet haben, sieht das etwas kosmisch aus und im Allgemeinen eher mittelmäßig.

Warum brauchen Sie DevOps?

Für die digitale Produktentwicklung. Wenn Ihr Unternehmen kein digitales Produkt hat, ist DevOps nicht erforderlich – es ist sehr wichtig.

DevOps überwindet die Geschwindigkeitsbeschränkungen der sequentiellen Softwareproduktion. Dabei laufen alle Prozesse gleichzeitig ab.

Der Schwierigkeitsgrad nimmt zu. Wenn DevOps-Evangelisten Ihnen sagen, dass es Ihnen die Veröffentlichung von Software erleichtern wird, ist das Unsinn.

Mit DevOps werden die Dinge nur noch komplizierter.

Auf der Konferenz am Avito-Stand konnte man sehen, wie es ist, einen Docker-Container bereitzustellen – eine unrealistische Aufgabe. Die Komplexität wird unerschwinglich; man muss mit vielen Bällen gleichzeitig jonglieren.

DevOps verändert den Prozess und die Organisation im Unternehmen komplett – Genauer gesagt ist es nicht DevOps, das sich verändert, sondern das digitale Produkt. Um zu DevOps zu gelangen, müssen Sie diesen Prozess noch komplett ändern.

Fragen an einen Spezialisten

Was hast du? Fragen, die Sie sich stellen können, während Sie in einem Unternehmen arbeiten und sich als Fachkraft weiterentwickeln.

Haben Sie eine Strategie zur Erstellung eines digitalen Produkts? Wenn ja, ist das schon gut. Das bedeutet, dass sich Ihr Unternehmen in Richtung DevOps bewegt.

Entwickelt Ihr Unternehmen bereits ein digitales Produkt? Dies bedeutet, dass Sie eine weitere Ebene aufsteigen und die Dinge interessanter gestalten können – wiederum aus DevOps-Sicht. Ich spreche nur aus dieser Sicht.

Gehört Ihr Unternehmen zu den Marktführern in der digitalen Produktnische? Spotify, Yandex und Uber sind Unternehmen, die sich derzeit auf dem Höhepunkt des technologischen Fortschritts befinden.

Stellen Sie sich diese Fragen, und wenn alle Antworten „Nein“ lauten, sollten Sie bei diesem Unternehmen vielleicht kein DevOps betreiben. Wenn das Thema DevOps für Sie wirklich interessant ist, sollten Sie vielleicht zu einem anderen Unternehmen wechseln? Wenn Ihr Unternehmen in DevOps einsteigen möchte, Sie aber alle Fragen mit „Nein“ beantwortet haben, dann ist es wie dieses schöne Nashorn, das sich nie ändern wird.

Organisation

Wie gesagt, nach Conways Gesetz ändert sich die Organisation eines Unternehmens. Ich beginne damit, was aus organisatorischer Sicht verhindert, dass DevOps in das Unternehmen vordringt.

Das Problem der „Brunnen“

Das englische Wort „Silo“ wird hier ins Russische mit „well“ übersetzt. Der Sinn dieses Problems besteht darin Es gibt keinen Informationsaustausch zwischen den Teams. Jedes Team greift tief in sein Fachwissen ein, ohne eine gemeinsame Karte zur Navigation zu erstellen.

In gewisser Weise erinnert mich das an eine Person, die gerade in Moskau angekommen ist und noch nicht weiß, wie man sich auf der U-Bahn-Karte zurechtfindet. Moskauer kennen ihre Gegend in der Regel sehr gut und können sich mithilfe der U-Bahn-Karte in ganz Moskau zurechtfinden. Wenn Sie zum ersten Mal nach Moskau kommen, verfügen Sie nicht über diese Fähigkeit und sind einfach desorientiert.

DevOps schlägt vor, diesen Moment der Orientierungslosigkeit zu überstehen und alle Abteilungen zusammenzuarbeiten, um eine gemeinsame Interaktionskarte zu erstellen.

Zwei Faktoren behindern dies.

Konsequenz des Unternehmensführungssystems. Es ist in separaten hierarchischen „Brunnen“ aufgebaut. Beispielsweise gibt es in Unternehmen bestimmte KPIs, die dieses System unterstützen. Andererseits stört das Gehirn einer Person, die Schwierigkeiten hat, über die Grenzen ihres Fachwissens hinauszugehen und sich im gesamten System zurechtzufinden. Es ist einfach unangenehm. Stellen Sie sich vor, Sie befinden sich am Flughafen Bangkok – Sie werden sich nicht schnell zurechtfinden. DevOps ist auch schwierig zu navigieren, und deshalb sagen die Leute, dass man einen Leitfaden finden muss, um dorthin zu gelangen.

Aber das Wichtigste ist, dass das Problem der „Brunnen“ für einen Ingenieur, der vom Geist von DevOps durchdrungen ist, Fowler und eine Reihe anderer Bücher gelesen hat, darin zum Ausdruck kommt „Brunnen“ erlauben es Ihnen nicht, „offensichtliche“ Dinge zu tun. Wir treffen uns oft nach DevOps Moskau, reden miteinander und die Leute beschweren sich:

— Wir wollten CI einfach einführen, aber es stellte sich heraus, dass das Management es nicht brauchte.

Dies geschieht genau deshalb CI и Kontinuierlicher Lieferprozess stehen an der Grenze vieler Prüfungen. Ganz einfach, ohne das Problem der „Brunnen“ auf organisatorischer Ebene zu überwinden, werden Sie nicht in der Lage sein, voranzukommen, egal was Sie tun und egal wie traurig es ist.

Jeder Prozessbeteiligte im Unternehmen: Backend- und Frontend-Entwickler, Test, DBA, Betrieb, Netzwerk, gräbt in seine eigene Richtung, und niemand hat eine gemeinsame Landkarte außer dem Manager, der sie irgendwie überwacht und mithilfe der „Teilung“ verwaltet und erobern“-Methode.

Die Leute kämpfen um einige Sterne oder Flaggen, jeder gräbt sein Fachwissen aus.

Wenn also die Aufgabe entsteht, all dies miteinander zu verbinden und eine gemeinsame Pipeline zu bauen, und es keinen Grund mehr gibt, um Sterne und Flaggen zu kämpfen, stellt sich die Frage: Was tun? Wir müssen uns irgendwie einigen, aber niemand hat uns in der Schule beigebracht, wie das geht. Uns wird seit der Schule beigebracht: Achte Klasse – wow! - im Vergleich zur siebten Klasse! Hier ist es das Gleiche.

Ist das in Ihrem Unternehmen genauso?

Um dies zu überprüfen, können Sie sich die folgenden Fragen stellen.

Nutzen Teams gemeinsame Tools und tragen sie zu Änderungen an diesen gemeinsamen Tools bei?

Wie oft organisieren sich Teams neu – einige Spezialisten von einem Team wechseln zu einem anderen Team? In einer DevOps-Umgebung wird dies zur Normalität, da eine Person manchmal einfach nicht verstehen kann, was ein anderer Fachbereich tut. Er wechselt in eine andere Abteilung, arbeitet dort zwei Wochen lang daran, sich eine Orientierungs- und Interaktionskarte mit dieser Abteilung zu erstellen.

Ist es möglich, ein Change Committee zu bilden und Dinge zu ändern? Oder bedarf es der starken Hand des höchsten Managements und der obersten Leitung? Ich habe kürzlich auf Facebook geschrieben, wie eine wenig bekannte Bank Instrumente durch Aufträge implementiert: Wir schreiben einen Auftrag, führen ihn ein Jahr lang aus und schauen, was passiert. Das ist natürlich langwierig und traurig.

Wie wichtig ist es für Führungskräfte, persönliche Erfolge zu erzielen, ohne die Erfolge des Unternehmens zu berücksichtigen?

Wenn Sie diese Fragen selbst beantworten, wird klarer, ob Sie ein solches Problem in Ihrem Unternehmen haben.

Infrastruktur als Code

Nachdem dieses Problem gelöst ist, ist die erste wichtige Praxis, ohne die es schwierig ist, in DevOps weiter voranzukommen Infrastruktur als Code.

Am häufigsten wird Infrastructure as Code wie folgt wahrgenommen:

— Lasst uns alles in Bash automatisieren und uns mit Skripten bedecken, damit Administratoren weniger manuelle Arbeit haben!

Aber das ist nicht so.

Infrastructure as Code bedeutet, dass Sie das IT-System, mit dem Sie arbeiten, in Form von Code beschreiben, um dessen Zustand jederzeit zu verstehen.

Gemeinsam mit anderen Teams erstellen Sie eine Karte in Form von Code, die jeder verstehen und navigieren und navigieren kann. Es spielt keine Rolle, womit es gemacht wird – Chef, Ansible, Salt oder die Verwendung von YAML-Dateien in Kubernetes – es gibt keinen Unterschied.

Auf der Konferenz erzählte ein Kollege von 2GIS, wie sie ein eigenes internes Ding für Kubernetes erstellt haben, das die Struktur einzelner Systeme beschreibt. Um 500 Systeme zu beschreiben, benötigten sie ein separates Tool, das diese Beschreibung generiert. Wenn es diese Beschreibung gibt, kann jeder sich untereinander erkundigen, Änderungen überwachen, wie man etwas ändern und verbessern kann, was fehlt.

Stimmen Sie zu, einzelne Bash-Skripte bieten dieses Verständnis normalerweise nicht. In einer der Firmen, in denen ich gearbeitet habe, gab es sogar einen Namen für „schreibgeschütztes“ Skript – wenn das Skript zwar geschrieben, aber nicht mehr lesbar ist. Ich denke, das kommt dir auch bekannt vor.

Infrastruktur als Code ist Code, der den aktuellen Zustand der Infrastruktur beschreibt. An diesem Code arbeiten viele Produkt-, Infrastruktur- und Serviceteams zusammen, und vor allem müssen sie alle verstehen, wie dieser Code tatsächlich funktioniert.

Der Code wird gemäß den besten Code-Praktiken gepflegt: gemeinsame Entwicklung, Code-Review, XP-Programmierung, Testen, Pull-Requests, CI für Code-Infrastrukturen – all das ist geeignet und einsetzbar.

Code wird zu einer gemeinsamen Sprache für alle Ingenieure.

Das Ändern der Infrastruktur im Code nimmt nicht viel Zeit in Anspruch. Ja, Infrastrukturcode kann auch technische Schulden haben. Normalerweise stoßen Teams anderthalb Jahre, nachdem sie begonnen haben, „Infrastruktur als Code“ in Form einer Reihe von Skripten oder sogar Ansible zu implementieren, darauf, das sie wie Spaghetti-Code schreiben, und sie werfen auch Bash-Skripte in die Mischung!

Es ist wichtig,: Wenn Sie dieses Zeug noch nicht ausprobiert haben, denken Sie daran Ansible ist kein Bash! Lesen Sie die Dokumentation sorgfältig durch und studieren Sie, was allgemein darüber geschrieben wird.

Unter Infrastructure as Code versteht man die Aufteilung des Infrastrukturcodes in separate Schichten.

In unserem Unternehmen unterscheiden wir 3 grundlegende Schichten, die sehr klar und einfach sind, es können aber auch mehr davon sein. Sie können sich Ihren Infrastrukturcode ansehen und feststellen, ob Sie unter dieser Bedingung leiden oder nicht. Wenn keine Ebenen hervorgehoben sind, müssen Sie sich etwas Zeit nehmen und ein wenig umgestalten.


Grundschicht – Auf diese Weise werden das Betriebssystem, Backups und andere Dinge auf niedriger Ebene konfiguriert, beispielsweise wie Kubernetes auf der Basisebene bereitgestellt wird.

Service Level – Dies sind die Dienste, die Sie dem Entwickler bereitstellen: Protokollierung als Dienst, Überwachung als Dienst, Datenbank als Dienst, Balancer als Dienst, Warteschlange als Dienst, kontinuierliche Bereitstellung als Dienst – eine Reihe von Diensten, die einzelne Teams anbieten zur Entwicklung beitragen kann. Dies alles muss in separaten Modulen in Ihrem Konfigurationsmanagementsystem beschrieben werden.

Die Ebene, auf der Anwendungen erstellt werden und beschreibt, wie sie sich über den beiden vorherigen Schichten entfalten.

Sicherheitsfragen

Verfügt Ihr Unternehmen über ein gemeinsames Infrastruktur-Repository? Beherrschen Sie die technische Verschuldung Ihrer Infrastruktur? Verwenden Sie Entwicklungspraktiken in einem Infrastruktur-Repository? Ist Ihre Infrastruktur in Schichten unterteilt? Sie können das Base-Service-APP-Diagramm überprüfen. Wie schwierig ist es, etwas zu ändern?

Wenn Sie die Erfahrung gemacht haben, dass die Durchführung von Änderungen anderthalb Tage gedauert hat, bedeutet das, dass Sie technische Schulden haben und damit arbeiten müssen. Sie sind gerade auf eine technische Schuldenbremse in Ihrem Infrastrukturcode gestoßen. Ich erinnere mich an viele solcher Geschichten, als man zum Ändern einiger CCTLs die Hälfte des Infrastrukturcodes neu schreiben musste, weil Kreativität und der Wunsch, alles zu automatisieren, dazu führten, dass überall alles korrodierte, alle Griffe entfernt wurden und Es ist eine Umgestaltung erforderlich.

Kontinuierliche Lieferung

Vergleichen wir Lastschrift mit Haben. Zunächst erfolgt eine Beschreibung der Infrastruktur, die recht einfach sein kann. Sie müssen nicht alles im Detail beschreiben, aber eine grundlegende Beschreibung ist erforderlich, damit Sie damit arbeiten können. Ansonsten ist nicht klar, wie es mit Continuous Delivery weitergehen soll. Alle diese Praktiken finden gleichzeitig statt, wenn Sie zu DevOps kommen, aber es beginnt damit, dass Sie verstehen, was Sie haben und wie Sie es verwalten. Genau das ist die Praxis von Infrastructure as Code.

Sobald klar ist, dass Sie es haben und wie Sie es verwalten, beginnen Sie herauszufinden, wie Sie den Entwicklercode so schnell wie möglich an die Produktion senden können. Ich meine, zusammen mit dem Entwickler erinnern wir uns an das Problem der „Brunnen“, das heißt, es sind nicht einzelne Menschen, die sich das ausdenken, sondern ein Team.

Wenn wir dabei sind Wanja Jewtuchowitsch habe das erste Buch gesehen Jez Humble und Autorengruppen „Kontinuierliche Lieferung“, das 2009 erschien, haben wir lange darüber nachgedacht, wie wir seinen Titel ins Russische übersetzen könnten. Sie wollten es mit „Kontinuierliche Lieferung“ übersetzen, aber leider wurde es mit „Kontinuierliche Lieferung“ übersetzt. Es scheint mir, dass in unserem Namen etwas Russisches steckt, mit Druck.

Ständig Mittel liefern

Code, der sich im Produkt-Repository befindet, kann jederzeit in die Produktion heruntergeladen werden. Er lässt sich vielleicht nicht entmutigen, aber er ist immer bereit dafür. Dementsprechend schreiben Sie Code immer mit einem schwer zu erklärenden Gefühl von Angst unter Ihrem Steißbein. Es erscheint häufig, wenn Sie Infrastrukturcode einführen. Dieses Gefühl einer gewissen Angst sollte vorhanden sein – es löst Gehirnprozesse aus, die es Ihnen ermöglichen, Code etwas anders zu schreiben. Dies sollte in den Regeln innerhalb der Entwicklung festgehalten werden.

Für eine konsistente Bereitstellung benötigen Sie ein Artefaktformat, das auf einer Infrastrukturplattform läuft. Wenn man „Lebensabfälle“ unterschiedlicher Formate über eine Infrastrukturplattform wirft, wird sie vereinheitlicht, ist schwer zu warten und es entsteht das Problem der technischen Verschuldung. Das Format des Artefakts muss abgestimmt werden – auch dies ist eine kollektive Aufgabe: Wir alle müssen zusammenkommen, unsere Gehirne schütteln und dieses Format entwickeln.

Das Artefakt wird kontinuierlich verbessert und an die Produktionsumgebung angepasst, während es die Lieferpipeline durchläuft. Wenn sich ein Artefakt entlang der Pipeline bewegt, stößt es ständig auf einige für es unangenehme Dinge, die denen ähneln, denen das Artefakt, das Sie in die Produktion bringen, begegnet. Wenn dies in der klassischen Entwicklung von einem Systemadministrator durchgeführt wird, der den Rollout durchführt, passiert dies im DevOps-Prozess ständig: Hier wurde es mit einigen Tests getestet, hier wurde es in einen Kubernetes-Cluster geworfen, der mehr oder weniger ähnlich ist zur Produktion, dann begannen sie plötzlich mit Lasttests.

Das erinnert ein wenig an das Pac-Man-Spiel – das Artefakt durchläuft eine Art Geschichte. Gleichzeitig ist es wichtig zu kontrollieren, ob der Code tatsächlich die Geschichte durchläuft und ob er irgendwie mit Ihrer Produktion zusammenhängt. Geschichten aus der Produktion können in den Continuous-Delivery-Prozess gezogen werden: Es war so, als etwas fiel, jetzt programmieren wir dieses Szenario einfach im System. Jedes Mal durchläuft der Code auch dieses Szenario, und beim nächsten Mal tritt dieses Problem nicht mehr auf. Sie erfahren davon viel früher, bevor es Ihren Kunden erreicht.

Verschiedene Einsatzstrategien. Beispielsweise verwenden Sie AB-Tests oder Canary-Bereitstellungen, um den Code auf verschiedenen Clients unterschiedlich zu testen und Informationen über die Funktionsweise des Codes zu erhalten, und zwar viel früher als bei der Einführung für 100 Millionen Benutzer.

„Konsequent liefern“ sieht so aus.

Der Bereitstellungsprozess Dev, CI, Test, PreProd, Prod ist keine separate Umgebung, dies sind Stufen oder Stationen mit feuerfesten Summen, die Ihr Artefakt durchläuft.

Wenn Sie über einen Infrastrukturcode verfügen, der als Base Service APP beschrieben wird, ist dies hilfreich Vergessen Sie nicht alle Skripte, und schreibe sie als Code für dieses Artefakt auf, Artefakt fördern und ändern Sie es nach und nach.

Fragen zum Selbsttest

Die Zeit von der Funktionsbeschreibung bis zur Freigabe in die Produktion beträgt in 95 % der Fälle weniger als eine Woche? Verbessert sich die Qualität des Artefakts in jeder Phase der Pipeline? Gibt es eine Geschichte, die es durchläuft? Verwenden Sie unterschiedliche Bereitstellungsstrategien?

Wenn alle Antworten „Ja“ lauten, dann bist du unglaublich cool! Schreiben Sie Ihre Antworten in die Kommentare - ich freue mich.

Kontaktieren Sie uns

Das ist die schwierigste Übung überhaupt. Auf der DevOpsConf-Konferenz war ein Kollege von Infobip, der darüber sprach, etwas verwirrt in seinen Worten, denn es handelt sich tatsächlich um eine sehr komplexe Praxis, da man alles überwachen muss!

Zum Beispiel vor langer Zeit, als ich bei Qik arbeitete und uns klar wurde, dass wir alles überwachen müssen. Wir haben dies getan und haben jetzt 150 Artikel in Zabbix, die ständig überwacht werden. Es war beängstigend, der technische Direktor verdrehte seinen Finger an seiner Schläfe:

- Leute, warum vergewaltigt ihr den Server mit etwas Unklarem?

Doch dann ereignete sich ein Vorfall, der zeigte, dass das wirklich eine sehr coole Strategie ist.

Einer der Dienste begann ständig abzustürzen. Anfangs stürzte es nicht ab, was interessant ist, der Code wurde dort nicht hinzugefügt, da es sich um einen einfachen Broker handelte, der praktisch keine Geschäftsfunktionalität hatte – er verschickte lediglich Nachrichten zwischen einzelnen Diensten. Der Dienst änderte sich vier Monate lang nicht und plötzlich begann er mit dem Fehler „Segmentierungsfehler“ abzustürzen.

Wir waren schockiert, öffneten unsere Charts in Zabbix und es stellte sich heraus, dass sich das Verhalten von Anfragen im API-Dienst, den dieser Broker nutzt, vor anderthalb Wochen stark verändert hatte. Als nächstes sahen wir, dass sich die Häufigkeit des Sendens einer bestimmten Art von Nachricht geändert hatte. Später fanden wir heraus, dass es sich um Android-Clients handelte. Wir fragten:

- Leute, was ist vor anderthalb Wochen mit euch passiert?

Als Reaktion darauf hörten wir eine interessante Geschichte darüber, wie sie die Benutzeroberfläche neu gestaltet hatten. Es ist unwahrscheinlich, dass irgendjemand sofort sagen wird, dass er die HTTP-Bibliothek geändert hat. Für Android-Kunden ist es, als würde man im Badezimmer die Seife wechseln – sie erinnern sich einfach nicht daran. Als Ergebnis stellten wir nach 40 Minuten Gespräch fest, dass sie die HTTP-Bibliothek und deren Standardzeiten geändert hatten. Dies führte dazu, dass sich das Verkehrsverhalten auf dem API-Server änderte, was zu einer Situation führte, die zu einem Wettlauf innerhalb des Brokers führte und zu einem Absturz führte.

Ohne umfassende Überwachung ist es im Allgemeinen unmöglich, dies zu öffnen. Wenn die Organisation immer noch das Problem der „Brunnen“ hat, wenn jeder sich gegenseitig mit Geld bewirft, kann das noch Jahre dauern. Sie starten einfach den Server neu, da das Problem nicht gelöst werden kann. Wenn Sie alle Ereignisse, die Sie haben, überwachen, verfolgen, verfolgen und die Überwachung als Test verwenden – Code schreiben und sofort angeben, wie er überwacht werden soll, auch in Form von Code (wir haben bereits die Infrastruktur als Code), wird alles klar, wie auf der Handfläche. Selbst solch komplexe Probleme lassen sich leicht nachverfolgen.

Sammeln Sie alle Informationen darüber, was mit dem Artefakt in jeder Phase des Lieferprozesses passiert – nicht in der Produktion.

Laden Sie die Überwachung auf CI hoch und einige grundlegende Dinge werden dort bereits sichtbar sein. Später werden Sie sie in Test, PredProd und Lasttests sehen. Sammeln Sie in allen Phasen Informationen, nicht nur Metriken, Statistiken, sondern auch Protokolle: wie die Anwendung eingeführt wurde, Anomalien – sammeln Sie alles.

Sonst wird es schwierig, es herauszufinden. Ich habe bereits gesagt, dass DevOps komplexer ist. Um diese Komplexität zu bewältigen, benötigen Sie normale Analysen.

Fragen zur Selbstkontrolle

Ist Ihre Überwachung und Protokollierung das Entwicklungstool für Sie? Denken Ihre Entwickler, Sie eingeschlossen, beim Schreiben von Code darüber nach, wie sie ihn überwachen können?

Hören Sie von Problemen von Kunden? Verstehen Sie den Client durch Überwachung und Protokollierung besser? Verstehen Sie das System durch Überwachung und Protokollierung besser? Ändern Sie das System, nur weil Sie gesehen haben, dass der Trend im System wächst und Sie verstehen, dass in weiteren 3 Wochen alles sterben wird?

Sobald Sie diese drei Komponenten haben, können Sie darüber nachdenken, welche Art von Infrastrukturplattform Sie in Ihrem Unternehmen haben.

Infrastrukturplattform

Der Punkt ist nicht, dass es sich um eine Reihe unterschiedlicher Tools handelt, über die jedes Unternehmen verfügt.

Der Sinn einer Infrastrukturplattform besteht darin, dass alle Teams diese Tools nutzen und gemeinsam entwickeln.

Es ist klar, dass es separate Teams gibt, die für die Entwicklung einzelner Teile der Infrastrukturplattform verantwortlich sind. Aber gleichzeitig trägt jeder Ingenieur die Verantwortung für die Entwicklung, Leistung und Förderung der Infrastrukturplattform. Auf interner Ebene wird es zu einem gemeinsamen Werkzeug.

Alle Teams entwickeln die Infrastrukturplattform und behandeln sie mit Sorgfalt wie ihre eigene IDE. In Ihrer IDE installieren Sie verschiedene Plugins, um alles schön und schnell zu machen, und konfigurieren Hotkeys. Wenn Sie Sublime, Atom oder Visual Studio Code öffnen, strömen Codefehler herein und Sie erkennen, dass es überhaupt unmöglich ist, überhaupt zu arbeiten. Sie werden sofort traurig und rennen los, um Ihre IDE zu reparieren.

Behandeln Sie Ihre Infrastrukturplattform genauso. Wenn Sie feststellen, dass etwas nicht stimmt, hinterlassen Sie eine Anfrage, wenn Sie das Problem nicht selbst beheben können. Wenn es etwas Einfaches gibt, bearbeiten Sie es selbst, senden Sie eine Pull-Anfrage, die Jungs werden es prüfen und hinzufügen. Dies ist ein etwas anderer Ansatz für Engineering-Tools im Kopf des Entwicklers.

Die Infrastrukturplattform gewährleistet den Transfer des Artefakts von der Entwicklung zum Kunden bei kontinuierlicher Qualitätsverbesserung. Die IP ist mit einer Reihe von Geschichten programmiert, die dem Code in der Produktion passieren. Im Laufe der Jahre der Entwicklung sind viele dieser Geschichten entstanden, einige davon sind einzigartig und beziehen sich nur auf Sie – sie können nicht gegoogelt werden.

An diesem Punkt wird die Infrastrukturplattform zu Ihrem Wettbewerbsvorteil, weil darin etwas eingebaut ist, was im Tool der Konkurrenz nicht enthalten ist. Je tiefer Ihr IP ist, desto größer ist Ihr Wettbewerbsvorteil im Hinblick auf die Time-to-Market. Erscheint hier Problem mit der Anbietersperre: Sie können die Plattform eines anderen übernehmen, aber wenn Sie die Erfahrung eines anderen nutzen, werden Sie nicht verstehen, wie relevant sie für Sie ist. Ja, nicht jedes Unternehmen kann eine Plattform wie Amazon aufbauen. Dies ist ein schwieriger Bereich, bei dem die Erfahrung des Unternehmens für seine Marktposition relevant ist und Sie dort keine Lieferantensperre anwenden können. Darüber ist es auch wichtig, darüber nachzudenken.

Fahren

Dies ist ein grundlegendes Diagramm einer Infrastrukturplattform, das Ihnen bei der Einrichtung aller Praktiken und Prozesse in einem DevOps-Unternehmen hilft.

Schauen wir uns an, woraus es besteht.

Ressourcen-Orchestrierungssystem, das Anwendungen und anderen Diensten CPU, Speicher und Festplatte zur Verfügung stellt. Darüber hinaus - Dienstleistungen auf niedrigem Niveau: Überwachung, Protokollierung, CI/CD-Engine, Artefaktspeicher, Infrastruktur als Systemcode.

Dienstleistungen auf höherem Niveau: Datenbank als Service, Warteschlangen als Service, Load Balance als Service, Bildgrößenänderung als Service, Big Data Factory als Service. Darüber hinaus - Pipeline, die Ihrem Kunden ständig geänderten Code liefert.

Sie erhalten Informationen darüber, wie Ihre Software für den Kunden funktioniert, ändern sie, liefern diesen Code erneut, erhalten Informationen – und entwickeln so sowohl die Infrastrukturplattform als auch Ihre Software ständig weiter.

Im Diagramm besteht die Lieferpipeline aus vielen Stufen. Dies ist jedoch ein schematisches Diagramm, das als Beispiel dient und nicht einzeln wiederholt werden muss. Stufen interagieren mit Diensten, als wären sie Dienste – jeder Baustein der Plattform trägt seine eigene Geschichte: wie Ressourcen zugewiesen werden, wie die Anwendung gestartet wird, wie sie mit Ressourcen arbeitet, wie sie überwacht wird und wie sie sich ändert.

Es ist wichtig zu verstehen, dass jeder Teil der Plattform eine Geschichte trägt, und fragen Sie sich, welche Geschichte dieser Baustein trägt. Vielleicht sollte er weggeworfen und durch einen Drittanbieterdienst ersetzt werden. Ist es beispielsweise möglich, Okmeter anstelle eines Ziegelsteins zu installieren? Vielleicht haben die Jungs diese Expertise schon viel weiter entwickelt als wir. Aber vielleicht auch nicht – vielleicht verfügen wir über einzigartiges Fachwissen, wir müssen Prometheus installieren und weiterentwickeln.

Erstellung der Plattform

Dies ist ein komplexer Kommunikationsprozess. Wenn Sie über grundlegende Praktiken verfügen, beginnen Sie mit der Kommunikation zwischen verschiedenen Ingenieuren und Spezialisten, die Anforderungen und Standards entwickeln und diese ständig an unterschiedliche Tools und Ansätze anpassen. Die Kultur, die wir bei DevOps haben, ist hier wichtig.

Mit Kultur ist alles ganz einfach - es geht um Zusammenarbeit und Kommunikation, also der Wunsch, auf einem gemeinsamen Gebiet miteinander zu arbeiten, der Wunsch, gemeinsam ein Instrument zu bedienen. Hier gibt es keine Raketenwissenschaft – alles ist sehr einfach, banal. Wir wohnen zum Beispiel alle im Eingangsbereich und halten ihn sauber – so ein Kulturniveau.

Was hast du?

Auch hier Fragen, die Sie sich stellen können.

Ist die Infrastrukturplattform dediziert? Wer ist für seine Entwicklung verantwortlich? Kennen Sie die Wettbewerbsvorteile Ihrer Infrastrukturplattform?

Diese Fragen müssen Sie sich ständig stellen. Wenn etwas auf Dienste Dritter übertragen werden kann, sollte es übertragen werden. Wenn ein Dienst Dritter beginnt, Ihre Bewegung zu blockieren, müssen Sie ein System in sich selbst aufbauen.

Also, DevOps...

... das ist ein komplexes System, es muss Folgendes haben:

• Digitales Produkt.
• Geschäftsmodule, die dieses digitale Produkt entwickeln.
• Produktteams, die Code schreiben.
• Kontinuierliche Lieferpraktiken.
• Plattformen als Service.
• Infrastruktur als ein Service.
• Infrastruktur als Code.
• Separate Praktiken zur Aufrechterhaltung der Zuverlässigkeit, integriert in DevOps.
• Eine Feedback-Praxis, die alles beschreibt.

Sie können dieses Diagramm verwenden und darin hervorheben, was Sie bereits in irgendeiner Form in Ihrem Unternehmen haben: Hat es sich entwickelt oder muss es noch entwickelt werden?

In ein paar Wochen ist es vorbei DevOpsConf 2019. als Teil von RIT++. Kommen Sie zur Konferenz, wo Sie viele coole Berichte über Continuous Delivery, Infrastructure as Code und DevOps-Transformation finden. Buchen Sie Ihre Tickets, letzter Preisschluss ist der 20. Mai

Source: habr.com