Vom Systemadministrator zur Person

DevOps hat mindestens zwei etablierte Ansichten - von Seiten der Systemadministratoren und von Seiten der Entwickler. Die ersteren rühmen sich normalerweise, Chef / Puppet / Ansible / Docker seit 200X zu verwenden, die letzteren glauben, dass DevOps sich selbst überlebt hat und zu NoOps führt, oder dass „ich alles in einen Behälter gewickelt habe und dann, wie es geht.“

Gleichzeitig liest das Unternehmen in Artikeln über DevOps und hofft, dass die Jungs unten herausfinden, was sie damit anfangen sollen. Gleichzeitig passiert DevOps selbst nicht, das Geschäft sieht nicht wie Google aus, das Unternehmen wird nicht türkis, die Menschen entwickeln keine neuen Ansätze, um Hypothesen in der Welt zu testen.

Dieser Artikel befasst sich mit DevOps als System. Wie hilft es dem Unternehmen, welche Kompetenzen von Ingenieuren für DevOps erscheinen sollten, welche Geschäftsaufgaben mit der DevOps-Methode der Softwareproduktion gelöst werden können und welche Fehler auf dem Weg zur DevOps-Produktion möglich sind und wie sie vermieden oder gestoppt werden können. Wie kann ein Ingenieur am Ende ein Mann werden und ein Schöpfer in dieser Welt sein, wie man einen Karriereweg dafür aufbaut und wie man anfängt, Technologie menschlich zu betrachten.

Das Material basiert auf der Abschrift des Berichts von Alexander Osminog Titov von unserer DevOops-Konferenz im Oktober 2017.



Für diejenigen, die es gewohnt sind, Berichte von Konferenzen in Aufzeichnungen anzusehen, fügen wir ein Video bei.



Ich arbeite für Express 42. Meine Geschichte handelt von meinem Karriereweg, aber ich werde ihm interessante Tipps und Schlussfolgerungen geben. Es hat einen eingängigen Namen "Vom Systemadministrator zur Person." Ich trenne die Rolle des Systemadministrators von einem menschlichen Zustand. DevOps bewegt uns dazu, nicht nur Künstler zu sein, sondern auch Schöpfer neuer digitaler Produkte und mehr.

Da meine Geschichte auf meiner Erfahrung basiert, erzähle ich Ihnen ein wenig über mich. Ich habe als Systemadministrator angefangen, als ich an der Universität war. Er arbeitete in der Nachtschicht, begann dann in der Tagschicht zu arbeiten und stieg dann in die Position des leitenden Systemadministrators auf. Dann arbeitete ich in sozialen Netzwerken connectect.ua und fakultet.ru, dann als technischer Direktor in der Firma Oversan-Skalaksi. Dies war einer der ersten Versuche, Cloud-Hosting in Russland zu starten, wie sich herausstellte, ein sehr früher Versuch. Der Bedarf an Cloud-Hosting in Russland entstand erst jetzt. Wir haben gerade verstanden, wie man sie verwendet, haben erkannt, dass dies flexible Ressourcen sind, dass sie Anwendungen anders schreiben müssen und so weiter. In jenen Tagen verstand das überhaupt niemand, so dass es sehr schwierig war, es zu verkaufen.

Dann arbeitete ich bei einem Qik-Startup aus dem Silicon Valley, dessen Entwicklungsbüro hier in Russland war. Bei Qik habe ich den Vorteil des DevOps-Konzepts wirklich gespürt, da wir in zwei Monaten ein Produkt entwickelt haben, das von 0 auf 5 Millionen Benutzer angewachsen ist. Wenn ich in Oversan-Skalaxi aus Sicht des Dienstes der Meinung war, dass DevOps benötigt wird und die Leute verstehen müssen, was DevOps für die Verwendung von Cloud-Hosting bedeutet, dann habe ich dies in Qik als Systemadministrator und als Leiter der Abteilung Systemadministratoren empfunden. Dann wurden wir von Skype gekauft und begannen dort zu integrieren und auch die Entwicklungen im Bereich DevOps dort zu integrieren, da es nicht in Skype war. Und dann kaufte Skype Microsoft. Es scheint, dass er zu einer Firma gekommen ist, in der ungefähr 40 Mitarbeiter beschäftigt sind, und nach einigen Jahren arbeiten Sie in einer großen Firma mit 100.000 Mitarbeitern. Es war eine sehr interessante Erfahrung.

Infolgedessen fand ich in diesen Unternehmen keinen Ort, an dem ich mich weiter bewegen konnte, und meine Kollegen und ich eröffneten Express 42, das DevOps in die Massen bringt. Diese Idee stammt ursprünglich aus Oversan-Skalaksi und treibt mich an. Unter anderem bin ich sehr verwurzelt für die DevOps-Community in Russland. Ich bin der Organisator von DevOpsDays Moscow und Moscow DevOps-Meetings.

Ich habe lange befürchtet, dass die Verwendung von Ansible schlecht oder gut sein kann. Das Tool als Ganzes löst nichts. Sie können Docker, Kubernetes, verwenden und den neuesten Prometheus installieren. Gleichzeitig unterscheidet sich das, was Sie tun, nicht von dem, was Benutzer von Bash-Skripten verwenden. Ich werde versuchen zu beantworten, warum dies passiert. In vielerlei Hinsicht liegt diese Antwort in uns, daher heißt der Artikel so. Der Systemadministrator überlegt, wie er Bash-Skripte für ihn schreibt, und die Person denkt etwas anders.

Wie erscheint DevOps im Unternehmen?

DevOps Entwickler

Es gibt verschiedene Möglichkeiten, wie DevOps in einem Unternehmen angezeigt werden kann. Eine dieser Möglichkeiten besteht darin, dass Entwickler, die es satt haben, Systemadministratoren zu bitten, etwas zu tun, und nachdem sie von DevOps erfahren haben, versuchen, es zu implementieren. Gleichzeitig haben sie ein besonderes Verständnis von DevOps. Sie glauben, dass sie jede Technologie verwenden, alles in einen Docker-Container packen und an Systemadministratoren senden können, aber sie denken überhaupt nicht darüber nach, wie ihr Code in der Produktion funktionieren wird. Sie haben nichts an ihren Köpfen geändert, um zu DevOps zu wechseln, aber gleichzeitig beginnen sie, neue Technologien einzusetzen.

Ich habe viele solcher Unternehmen gesehen. Sie kommen zu ihnen - sie haben vier Entwicklungsabteilungen. Jede Abteilung schreibt ihren eigenen Microservice, jede Abteilung hat ihre eigene Datenbank. Jemand Redis, jemand PostgreSQL, jemand PostgreSQL und MySQL gleichzeitig. Und sie begleiten dies, bis die Datenbanken so groß werden, dass sie nicht mehr können.

An diesem Punkt beginnt alles zusammenzubrechen und auseinanderzufallen, und es entstehen schreckliche Konsequenzen. Dies ist ein Technologie-Zoo, mit dem nicht klar ist, was zu tun ist. Die Besonderheit des Entwicklers besteht außerdem darin, dass er das Problem durch Ziehen einer neuen Bibliothek löst. Ich denke, diejenigen, die mit Node.js Entwicklern arbeiten, sind damit vertraut. Wenn Node.js-Entwickler feststellen, dass die Datenbank nicht ordnungsgemäß funktioniert, können sie von PostgreSQL zu einer bestimmten Version springen, eine Erweiterung hinzufügen oder JSONB verwenden. Infolgedessen entsteht ein schrecklicher Zustand der Architektur, aber im Großen und Ganzen sind sie mit allem zufrieden. Die Anwendung ist schwer zu verwalten, Sie können nicht herausfinden, was dort passiert, sie hat eine geringe Stabilität und stürzt ständig ab. Als Reaktion auf die abgestürzte Anwendung kleben die Entwickler etwas anderes dort fest, und es fällt weiter ab, und infolgedessen wird überhaupt nichts verstanden.

Sysadmin DevOps

Es gibt so etwas wie DevOps-sysadmin. Normalerweise sind das sehr mächtige Leute, die sich gut bewährt haben. Sie kommen und sagen: "Leute, so kannst du nicht leben, wir haben es satt, diese Flüssigkeit zu ziehen. Wir automatisieren jetzt alles. Wir werden die Lieferpipeline so süß, wunderbar und gut machen." Wir wissen sehr gut, wie die Anwendung in der Produktion funktionieren soll. Viel besser als diese Dummköpfe, die auf Node.js schreiben. Und wir wissen, was verwendet werden muss, damit alles perfekt ist. “

Mehrmals bin ich auf die Tatsache gestoßen, dass solche Leute DevOps auf FreeBSD erstellt haben. Das Ergebnis war ein geschlossenes System, das sie selbst geschrieben haben, und nur sie haben verstanden, wie es funktioniert. Trotz der Erfahrung meines Systemadministrators konnte ich es nicht herausfinden, aber wenn ich es nicht konnte, wie sollte der Entwickler dann verstehen, wie er über dieses CI-System bereitgestellt wird? Infolgedessen habe ich die Verwendung von FreeBSD im Unternehmen administrativ verboten, obwohl ich das System selbst aufrichtig liebe und respektiere, insbesondere OpenBSD. Aber eine Woche später tauchten unter den Linux-Servern wieder FreeBSD-Server auf, wie Fliegenpilze.

Sowohl DevOps-Systemadministratoren als auch Entwickler sind der Meinung, dass Technologie das Wichtigste ist. Ohne sie geht nichts. Wenn sie die Technologie mögen, versuchen sie, sie überall festzuhalten.
Bei Oversan-Skalaxi haben wir den Begriff Nur-Schreib-Konfigurationen und -Skripte geprägt. Dies ist, wenn eine Person schreiben könnte, aber niemand lesen könnte.

Gleichzeitig reparieren Systemadministratoren weiterhin etwas in der Seife. Sie kommen zu ihm und bieten Hilfe an, und er gibt Ihnen etwas mit einer dreistöckigen Matte. Du verstehst nichts, weil du herausfinden musst, was er getan hat. Nun, wenn der Entwickler kommt und zum Beispiel sagt, dass er eine fehlertolerante Datenbank benötigt? Er wird etwas mit dieser dreistöckigen Matte bekommen, er wird sich setzen und nicht verstehen, was er damit machen soll. Alle segelten, die Entwickler und Systemadministratoren kommunizieren nicht. Obwohl innen das modernste, raffinierteste verwendet wird.

Von hier kam die traditionelle Idee der Systemadministratoren: Dies ist eine so mehrarmige Person, die etwas tut, aber Sie werden nicht genau verstehen, was. Übrigens suchen die meisten HR-Mitarbeiter jetzt genau nach solchen. Ich kann Ihnen sagen, dass Sie durch die Suche nach einer solchen Person im Unternehmen nicht zu 100% vor Problemen bewahrt werden.

DevOps für Unternehmen

Ein anderer Weg für die Entstehung von DevOps ist von der Geschäftsseite. Einige Ihrer Top-Manager gingen zu einer Geschäftskonferenz, zum Beispiel ins Tal, wo sie ihm sagten, dass Sie nicht in Betracht gezogen werden können, wenn Sie nicht über Docker, eine kontinuierliche Integration (CI) und etwas anderes verfügen Technologieunternehmen. Der Manager kehrt zurück, sammelt Mitarbeiter und liest Wörter aus einem Notizbuch: DevOps, Docker, Concourse CI. Die Jungs beginnen zu verstehen, und dann passieren die oben genannten gemischten Szenarien: DevOps-Entwickler, DevOps-Systemadministrator, und das alles führt zu einem Durcheinander, das Sie nicht erkennen können.

Tatsächlich sehe ich ständig solche Situationen. Warum passiert das: Sie kommen zur Konferenz, jeder hat eine rationale, normale Sichtweise - dann gehen Sie in die Gräben, in die Produktion, und dann gibt es Müll und Dämpfe? Das heißt, jeder versteht alles, aber aus irgendeinem Grund funktionieren sie nicht. Ich habe die Hypothese, dass jeder einen Teil versteht, nicht alle. Und jetzt werde ich versuchen, ganzheitlich über DevOps zu sprechen.

Vom Unternehmen zum Agilen

Erstens erleben wir aus geschäftlicher Sicht einen Wendepunkt: Wir entfernen uns von einem Unternehmen, das monumentale Projekte umsetzt, um das Geschäft selbst von Punkt A nach Punkt B zu verlagern (zum Beispiel eine Fünfjahresstrategie zur Eroberung von 70% des Marktes) ...

... und komm in die Welt von Agile. Der Punkt von Agile soll nicht flexibel sein, aber dieser Punkt A ist bekannt und B nicht. Und das ist das Tiefste, was passieren kann. Weil weder wir noch das Geschäft daran gewöhnt sind, damit zu arbeiten. Stellen Sie sich vor, Sie wissen nicht, was in ein oder zwei Wochen passieren wird, der Anführer kam zu Ihnen und sagte: "Also, versuchen Sie, mir etwas zu besorgen, das nicht sein kann, schreiben Sie Ihren Namen auf, damit Sie es nicht so schnell vergessen . " Und Sie wissen nicht, was Sie tun sollen, aber die Welt und das Geschäft werden so, und Sie müssen sich daran gewöhnen. Und bei all diesen Praktiken wie Agile, Scrum, Kanban geht es nicht darum, wie man damit lebt.


Wir bewegen uns vom Weg von Unternehmen und Konzernen zum Weg der Technologie. Einige Softwareprodukte beginnen mit uns auf dem Markt zu interagieren. Wenn frühere Leute, Firmen mit uns interagierten, Verkäufer anriefen und so weiter, um jetzt ein Taxi zu rufen, Pizza zu bestellen, Musik zu hören, gehen wir zur Anwendung. Und eine Anwendung ist eine Software, die jemand schreiben und kontinuierlich an den Markt anpassen muss. Und wir Ingenieure und diejenigen, die geschäftlich tätig sind, müssen anhand der Anwendung verstehen, was mit dem Markt geschieht. Und am Ende bewegt es uns in Richtung DevOps.

DevOps wird nicht angezeigt, weil einer von Ihnen sich wohlfühlen sollte und nicht, weil Sie kühlere Technologien verwenden müssen. NoSQL ist nicht cooler als SQL, außerdem ist es vom Staat vor 3-4 Jahren viel schlimmer als SQL. SQL-Datenbanken werden seit 20 Jahren und NoSQL-Datenbanken seit 1 Jahr entwickelt. Und wir erinnern uns an den bedauernswerten Zustand von MongoDB vor 4 Jahren, als es überhaupt keine Datenbank war.


DevOps ist das gleiche wie zuvor, nur dass wir jetzt alles gleichzeitig machen. Wenn Sie Entwickler sind, schreiben Sie Code und schreiben sofort Tests, einen Wrapper für Kubernetes oder nur einen Docker-Container, wie er in der Produktion funktionieren soll. Dabei müssen Sie eine Mindestbedingung erfüllen: Führen Sie diesen Code aus. Weil viele Entwickler in der vorherigen Ära dies nicht getan haben: Der Compiler wurde kompiliert, und was dort begann und im Anwendungscontainer zu arbeiten begann, ist bereits das zehnte. Schreiben Sie gleichzeitig Metriken und Protokolle, die gesammelt werden sollen. Und dann verlieren Sie alles in Delivery Pipeline, Jenkins, TeamCity oder etwas anderem. Dies ist ein grundlegender Unterschied zwischen einem Entwickler in einem Unternehmen und einem Entwickler in einem Technologieunternehmen. Hier beginnt der Entwickler, nicht nur Algorithmen, sondern das gesamte Produkt zu schreiben.

Geschichte von DevOps

Hier ist die Zeit, sich der Geschichte von DevOps zuzuwenden. Wie kam das alles zustande? Ich lebte das, las ständig die Nachrichten, folgte der historischen Kette, wie alles aussah. Und jetzt erzählen mir verschiedene Leute aus verschiedenen Jahren verschiedene Versionen von DevOps und wie es dazu kam. Und es scheint mir wichtig, zu den Wurzeln zurückzukehren.

2003 gründete Ben Trainor von Google das SRE-Team. Google ist das weltweit erste große digitale Unternehmen. Bereits 2003 standen sie vor dem Problem, dass sie auf klassische Weise, wie es alle Softwareentwickler gewohnt sind, nicht tun können, was sie wollen. Und sie haben durch die Einführung des SRE-Teams Innovationen hervorgebracht und diese Praxis seitdem weiterentwickelt.

Im Jahr 2009 hielten John Alspaw und Paul Hammond einen Vortrag über die Zusammenarbeit bei Flickr und wie sie sich zehnmal am Tag austauschen. Zu dieser Zeit war es eine Sensation und eine Explosion. Und Patrick Deboit hat diesen Bericht ausspioniert und den Begriff DevOps geprägt, die Weltgemeinschaft organisiert, um diese Praxis weiterzuentwickeln.

Es entstanden Technologieunternehmen, die schnell teilen mussten. Alte Ansätze passten nicht und sie kamen auf neue. Und natürlich wurden sie reibungslos neu angeordnet, sodass sie eine neue Praxis beim Erstellen von Software hatten.

Wir befinden uns in einer sehr schwierigen Situation, weil wir diese natürliche Veränderung nicht hatten. Solche Technologien kommen zu uns, wenn dort bereits etwas passiert ist, aber wir wissen immer noch nicht, wie wir sie verwenden sollen. Dort kamen die Menschen evolutionär dazu, und wir müssen eine Revolution machen, all dies überdenken und es irgendwie auf ihren eigenen Boden verlagern.

Wie wende ich DevOps an?

Bei der Verwendung von DevOps ist es sehr wichtig zu wissen, dass Sie ein digitales Produkt herstellen und dass Time-to-Market (TTM) für Unternehmen wichtig ist.

Es ist wichtig, alle Teams in Entwicklungsteams zu verwandeln. Es gibt keinen separaten Systemadministrator mehr, keinen separaten Entwickler. Weil diejenigen, die wir Systemadministratoren nennen, eine sogenannte Infrastrukturplattform schreiben und Entwickler ein sogenanntes Produkt schreiben und sich gegenseitig einen Service bieten.

Eine andere nicht offensichtliche und sehr wichtige Sache, die wir alle vergessen, ist die Organisation der Anhäufung und des Wissensaustauschs innerhalb des Teams und zwischen Teams. Wir haben große Probleme damit. Wir möchten nicht etwas teilen, das zum Beispiel noch nicht fertig ist, und dies ist der Schlüssel zur Existenz von DevOps. Wir müssen darüber sprechen, was nicht bereit ist, Hypothesen testen, wir müssen offen sein für jemanden, der uns sagt, dass er nicht bereit ist. Weil wir es zum Beispiel gewohnt sind, wenn die Systemadministratoren etwas Cooles getestet haben, kamen sie und sagten: "Nein, aber wie funktioniert es in der Produktion, was haben Sie getestet?"

Sysadmins, die erkennen, dass sie irgendwo nicht verstanden haben, irgendwo nicht getestet haben, gehen, schließen, und dieses Wissen verschwindet, und wir machen keinen Schritt nach vorne. Und es ist richtig zu sagen: "Leute, schau! Sie haben einen wirklich coolen Job gemacht, einen tollen Job, aber es gibt eine Frage, die ich Ihnen wirklich stellen möchte: Wie wird das in der Produktion funktionieren? Hast du darüber nachgedacht? "Wenn Sie uns das nächste Mal zeigen, wie diese Funktion in der Produktion implementiert wird, wird es sehr cool!"
Sie gehen bereits mit der Aufgabe. Und im Fall unseres klassischen russischen Ansatzes „Ja, nein, nein, alles Müll“ gehen sie mit dem Gedanken „Warum sollten wir das tun, wenn wir alle abgelehnt wurden?“ . Und dies ist ein großes Problem innerhalb der DevOps-Community. Wir teilen nicht miteinander, weil wir nicht sicher sind, ob dies nicht als offensichtlich oder nicht so hardcore erkannt wird, wie es scheint, und so weiter.

Ich habe bereits von Konferenzorganisatoren gehört, dass jeder einen Mega-Hardcore benötigt. Nun, vielleicht können Sie keinen Megahardcore machen, aber damit eine Person echte Erfahrungen teilt und Sie darüber sprechen können, ist es auch cool.

Entwickler bei DevOps

Der Entwickler bei DevOps schreibt nicht den Code, sondern das Produkt. Und dies ist keine offensichtliche Sache, denn in Instituten, Kursen und Büchern wird uns als Programmierer beigebracht, Algorithmen zu schreiben, nicht Produkte. Sie lernen, kein Geschäftsproblem, sondern ein algorithmisches Problem zu lösen. Das ist ein großes Problem. In Ihrem Kopf ist es sehr wichtig zu verfolgen, an welchem ​​Punkt Sie ein algorithmisches Problem lösen und an welchem ​​Punkt es sich um ein echtes Geschäftsproblem handelt.

In einem Unternehmen, das DevOps praktiziert, denkt der Entwickler sofort darüber nach, wie sich sein Code in andere Komponenten integrieren lässt. Beginnt sofort darüber zu kommunizieren. Zum Beispiel, um in einem Chat eine Roadmap einer API-Änderung zu klären, die zur Überprüfung verwendet wird. Dies ist der Beginn der Zusammenarbeit.

Der Entwickler hat eine Vorstellung von der Architektur der Anwendung - dies ist sehr wichtig, da es unmöglich ist, über Integration nachzudenken, ohne zu verstehen, wie die Architektur funktioniert, welche technologischen Schichten sie haben und wie sie miteinander interagieren.

Der Entwickler weiß, wie der Code im Kampf funktioniert, und weiß, was mit dieser Anwendung passiert. In meinem Beispiel sollte ein Entwickler, der sowohl Code als auch einen Docker-Container schreibt und gleichzeitig überwacht, eine Vorstellung davon haben, wie die Architektur funktioniert, wie der Code in der Produktion funktioniert und in die Anwendung integriert wird. Diejenigen unter Ihnen, die als Systemadministratoren oder Infrastrukturingenieure arbeiten, überlegen, wie sie dieses Wissen an Entwickler weitergeben können. Ihre Aufgabe ist es, ihnen davon zu erzählen. Sie können Berater einstellen, aber besser selbst.

Infrastrukturingenieur

Die nächste Rolle, die DevOps spielt, ist der Infrastrukturingenieur, der früher als Systemadministrator bezeichnet wurde. Ich mag den Begriff „DevOps-Ingenieur“ überhaupt nicht, da DevOps eine gängige Praxis ist, die Entwicklung, Test und Betrieb umfasst. Wie ich bereits sagte, können Sie einen DevOps-Ingenieur, ein DevOps-Team und die beste Technologie haben, und Sie haben kein DevOps.

Ein Infrastrukturingenieur erstellt eine Plattform hauptsächlich für die Produktentwicklung, die jedoch für Entwickler praktisch sein sollte. Dieses Gleichgewicht muss versucht werden, zu entsprechen.
Ein Infrastrukturingenieur verwendet mehrere Abstraktionsebenen, um Dienste bereitzustellen. Zum Beispiel gab es einen guten Bericht von Nikolai Ryzhikov über Kubernetes, er zeigte dort, wie man mehrere Abstraktionsebenen auswählt und verwendet. Dort hatte er ein ideales Modell, das in die Praxis umgesetzt wird. Ein solches Modell kann in separate Abstraktionsebenen unterteilt werden. Dies geschieht, um die Komplexität der Problemlösung und -integration zu verringern. Wenn Sie verständliche Abstraktionsebenen haben, können Sie zwischen diesen wechseln und sehen, wo die Diskrepanzen liegen. Sie müssen Abstraktionsschichten nicht vertrauen, aber sie sind sehr nützlich, um darüber zu sprechen. Das heißt, sie sollten kein absolutes, sondern ein nützliches Werkzeug sein.

Der Infrastrukturingenieur entwirft die Plattform als Produkt, weiß, wie man ein Product Owner ist, was Design Thinking ist und wie man Anforderungen von Entwicklern sammelt. Dies ist jedoch ein hohes Niveau, und ich bin mir nicht sicher, ob solche Ingenieure in Form von Infrastrukturingenieuren auf dem Markt präsent sind.

Testtechnologe

Der Tester ändert sich auch ein wenig und wird ein Technologe, der eine Verbesserung der Softwarequalität erreicht und diesen Prozess in Code umwandelt.

Release Manager / Service Station

Der Manager berücksichtigt den Prozess der kontinuierlichen Softwarebereitstellung, verwaltet die Geschäftserwartungen und technischen Fähigkeiten und erstellt Releases und Releases. Er produziert, nicht plant, weil der Übergangsprozess von Punkt A zu Punkt B nicht linear ist und er unter solchen Umständen nicht planen kann.

Infolgedessen bilden alle zusammen eine Infrastrukturplattform, die für alle ein Werkzeug ist: Infrastrukturingenieure, Entwickler und Tester.


Hierbei ist es wichtig, dass der Code rechts entlang des Lieferprozesses verläuft und die Informationen darüber, wie er abläuft, links bleiben. Sie erhalten ständig Informationen darüber, wie Ihr Code die Übermittlungspipeline durchläuft, und nehmen anhand dieser Informationen Änderungen vor.

Die Hauptsache, die untereinander, an Entwickler und an alle weitergegeben werden muss, ist, dass all diese Infrastruktur ein gemeinsames Werkzeug (wie ein Git) ist, das von allen verbessert wird. Sie können nicht sagen, dass dies Petinas Problem ist, da er überlastet ist, die Komplexität der aus dem Code stammenden Informationen nicht bewältigen kann und Sie daher eine schlecht funktionierende Pipeline für die kontinuierliche Lieferung erhalten.

Innerhalb eines solchen Systems ist es notwendig, nicht die Verantwortung, sondern das Wissen und die Erfahrung zu teilen. Einige Leute (Release Manager oder CTO) haben Wissen und Erfahrung über alles - sie haben das ganze Bild. Andere haben Kenntnisse und Erfahrungen über das Ressourcen-Orchestrierungssystem, andere haben Kenntnisse über die Datenbank usw., und dies sind verschiedene Teams, verschiedene Personen, die hier einen Platz einnehmen und gleichzeitig für die gesamte Infrastrukturplattform verantwortlich sind.


In Express 42 nennen wir dieses Leveling das Konzept der Base-Service-App. Es gibt eine bestimmte Grundebene - die Ebene der Orchestrierung (Zuweisung) von Ressourcen und verschiedener Infrastrukturdienste auf niedriger Ebene. Infrastrukturingenieure haben hier mehr Wissen und Erfahrung. Es gibt einen Service Level: verschiedene Datenbanken, Load Balancer, Überwachung, Protokollierung, CI-Engines (TeamCity als Engine oder Jenkins als Engine). Es gibt eine Anwendungsebene, die diese Ebenen über alle Arten von APIs, Funktionen usw. zusammenfasst. Ich beziehe mich wieder auf den Bericht von Nikolai Ryzhikov, er hat perfekt gezeigt, wie dies alles zusammenarbeitet und wie CI zusätzlich zu Kubernetes implementiert wird.


Prozesse und Technologien sind entscheidend. Die Technologien, die Sie außer sich selbst verwenden, können verwendet werden. Zum Beispiel können Sie mit einem Messer Brot schneiden oder eine Person töten. So ist es hier, nur in unserem Fall ist es noch komplizierter, noch mehr Abstraktionsebenen. Die Prozesse, die Sie darum herum erstellen, sind sehr wichtig. Und diese Prozesse kann im Prinzip niemand außer Ihnen im Unternehmen erstellen, da sie in hohem Maße auf bestimmte Anwendungen zugeschnitten sind. Grundsätzlich ist es jetzt unmöglich, dass Sie nach wie vor einen ITIL-Berater eingestellt haben, der alle Prozesse für Sie eingerichtet hat. Die Internet-Banking-Anwendung und Yandex.Music unterscheiden sich von Himmel und Erde. Es gibt allgemeine Prinzipien, aber der Prozess selbst ist völlig anders.

Jede der Technologieebenen hat ihre eigenen Prozesse, die erstellt werden müssen. Und hier beziehe ich mich auf die Worte von Alan Kay, der einmal in einem Interview mit Habru einen erstaunlichen Satz sagte: "Computer können mit Musikinstrumenten verglichen werden, ihre Musik ist Ideen . "
Dementsprechend sollten die Technologien, über die wir verfügen, in die Prozesse einbezogen werden, die die Idee schaffen (die Idee, das Produkt zu verbessern, die Idee, Prozesse zu ändern, die Idee, ein neues Produkt zu schaffen). Es ist sehr wichtig.

Unternehmen, die DevOps praktizieren, sollten eine Plattform in sich selbst und ein Wertesystem organisieren, mit dem wir diskutieren können, welche Ideen wir mit den von uns verwendeten Technologien erstellen und wie häufig wir diese Technologien verwenden (Kubernetes, Prometheus, Docker usw.). , um Musik zu spielen und nicht die Gitarre auf dem Kopf eines Nachbarn zu brechen.

Grundsätzlich sollte der DevOps-Prozess aus Sicht der Person innerhalb des Unternehmens wie folgt gestaltet werden. Es muss Organisationseinheiten wie Ausschüsse geben, die von Personen stammen, die darüber diskutieren müssen. Dies sollte keine Architekturabteilung oder Integrationsabteilung oder eine Abteilung für kontinuierliche Lieferung oder eine Qualitätsabteilung sein - dies sollten Komitees sein, die zusammenkommen und diskutieren, wie wir jetzt arbeiten und welche neuen Ideen wir basierend auf unseren Technologien entwickeln. Sie schaffen und verändern Arbeitsweisen und schaffen auf dieser Grundlage Wissen, von dem ein Teil informell sein wird, und das ist normal. Im Allgemeinen wissen die Russen gut, wie man Wissen in Metaphern überträgt, zum Beispiel wenn ein Mechaniker sagt "gib mir diesen Mist". Durch Kooperation und Kommunikation wird dieses Wissen geschaffen und in die Art und Weise des Einsatzes von Technologien und die Technologien selbst eingebettet.und dieser Wissensstandard wird auf Technologie implementiert.

Der aktuelle Moment unterscheidet sich vom alten Unternehmensmoment darin, dass die Standards dort festgenagelt wurden und sich nun kontinuierlich ändern. In den letzten drei bis vier Jahren haben sich viele Technologien und Nutzungsstandards geändert. Es ist sogar sinnlos, sie in Dokumenten zu fixieren, nur in den Köpfen der Menschen.

Wenn Ihnen dieser Bericht gefallen hat, besuchen Sie die DevOops 2018- Konferenz : Dort können Sie nicht nur die Berichte anhören, sondern auch mit jedem Redner im Diskussionsbereich chatten. Die Konferenz wird in St. Petersburg am 14. Oktober mit dem ersten September, sind die Kosten statt der Tickets wird zunehmen.