Was ist DevOps?

Das Definieren von DevOps ist sehr kompliziert, daher müssen Sie die Diskussion jedes Mal neu starten. Nur auf Habré tausend Publikationen zu diesem Thema. Aber wenn Sie dies lesen, wissen Sie wahrscheinlich, was DevOps ist. Weil ich es nicht tue. Hallo, mein Name ist Alexander Titov (@ osminog ) und wir werden nur über DevOps sprechen 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 - die, die ich mir selbst stelle, und die, die ich den Kunden unseres Unternehmens stelle. Durch die Beantwortung dieser Fragen wird das Verständnis besser. Ich werde Ihnen sagen, warum DevOps aus meiner Sicht benötigt wird, was es wiederum aus meiner Sicht ist und wie Sie verstehen, dass Sie aus meiner Sicht wieder zu DevOps wechseln. Der letzte Punkt wird durch Fragen sein. Wenn Sie sie selbst beantworten, können Sie verstehen, ob sich Ihr Unternehmen in Richtung DevOps bewegt oder ob es Probleme mit etwas gibt.


Einmal ging ich durch die Wellen von Fusionen und Übernahmen. Zuerst habe ich in einem kleinen Startup Qik gearbeitet, dann wurde es von einer etwas größeren Firma Skype gekauft, die dann von einer etwas größeren Firma Microsoft gekauft wurde. In diesem Moment wurde mir eine Vision zur Verfügung gestellt, wie die Idee von DevOps in verschiedenen Unternehmen umgesetzt wurde. Danach wurde es für mich interessant, DevOps aus Sicht des Marktes zu betrachten, und meine Kollegen und ich organisierten die Firma Express 42. Seit 6 Jahren bewegen wir uns auf den Wellen des Marktes.

Unter anderem bin ich einer der Organisatoren der DevOps Moscow Community und der Organisator der DevOps-Tage 2017, aber ich habe 2018 nicht organisiert. Express 42 arbeitet mit vielen Unternehmen zusammen. Wir keimen dort DevOps, sehen, wie dies geschieht, ziehen Schlussfolgerungen, analysieren, teilen unsere Ergebnisse allen mit und bringen den Menschen DevOps-Praktiken bei. Im Allgemeinen erweitern wir in jeder Hinsicht unsere Erfahrung und unser Fachwissen.

Warum DevOps?

Die erste Frage, die alle verfolgt und immer - warum? Viele Leute denken, dass DevOps nur Automatisierung oder eine ähnliche Sache ist, die jedes Unternehmen bereits hatte.

- Wir hatten eine kontinuierliche Integration - das heißt, es gab bereits DevOps, und warum werden all diese Tops benötigt? Sie haben Spaß im Ausland, aber sie stören unsere Arbeit!

In den 9 Jahren der Entwicklung der Community und der Methodik ist bereits klar geworden, dass es sich nicht um Marketing-Flitter handelt, aber es ist immer noch nicht ganz klar, warum dies erforderlich ist. Wie jedes Tool und jeder Prozess hat DevOps bestimmte Ziele, die es letztendlich löst.

All dies ist auf die Tatsache zurückzuführen, dass sich die Welt verändert. Er entfernt sich vom Unternehmensansatz, wenn Unternehmen direkt zum Traum übergehen, wie unser St. Petersburger Klassiker nach einer bestimmten Strategie von Punkt A nach Punkt B sang, wobei eine bestimmte Struktur dafür geschaffen wurde.

Grundsätzlich sollte in der IT alles für diesen Ansatz aufgebaut sein. Hier wird die IT ausschließlich zur Prozessautomatisierung eingesetzt.

Die Automatisierung ändert sich nicht oft, denn wenn ein Unternehmen auf einer geriffelten Strecke rollt - was kann sich ändern? Es funktioniert - nicht berühren. Jetzt auf der Welt ändern sich die Ansätze, und der mit dem Wort Agile bezeichnete sagt, dass der Endpunkt B nicht sofort sichtbar ist.



Wenn sich ein Unternehmen auf dem Markt bewegt, mit einem Kunden zusammenarbeitet, den Markt ständig erforscht und seinen Endpunkt B ändert, ist es am Ende umso erfolgreicher, je öfter das Unternehmen die Richtung ändert, da es mehr Marktnischen auswählt.

Die Strategie wird von einem interessanten Unternehmen demonstriert, von dem ich kürzlich erfahren habe. One Box Shave - Ein Lieferservice für Rasierer und Rasierer per Box. Sie wissen, wie sie ihre "Box" für verschiedene Kunden anpassen können. Dies geschieht durch bestimmte Software, die dann eine Bestellung an eine koreanische Fabrik sendet, die Waren produziert.

Dieses Produkt wurde von Unilever für 1 Milliarde US-Dollar gekauft. Jetzt konkurriert er mit Gillette und hat ihm einen bedeutenden Anteil der Verbraucher auf dem US-Markt geraubt. One Box Shave sagen:

- 4 Klingen? Ist das dein ernst Warum brauchen Sie das - es verbessert nicht die Qualität der Rasur. Eine speziell ausgewählte Creme, ein Parfüm und ein hochwertiges Rasiermesser mit zwei Klingen lösen viel mehr Fragen als diese dummen 4 Klingen von Gillette! So bald werden wir 10 erreichen?

Die Welt verändert sich also. Unilever behauptet, ein cooles IT-System zu haben, das dies ermöglicht. Am Ende sieht es nach einem Time-to-Market- Konzept aus, über das noch niemand gesprochen hat.



Der Punkt der Markteinführungszeit ist nicht, wie oft wir bereitstellen. Sie können häufig bereitstellen, die Freigabezyklen sind jedoch lang. Wenn sich die dreimonatigen Veröffentlichungszyklen überlappen und sich um eine Woche verschieben, stellt sich heraus, dass das Unternehmen anscheinend einmal pro Woche bereitgestellt wird. Und von der Idee bis zur endgültigen Umsetzung vergehen 3 Monate.

Bei der Markteinführung geht es darum, die Zeit von der Idee bis zur endgültigen Implementierung zu minimieren.

In diesem Fall interagiert Software mit dem Markt. So interagiert One Box Shave mit der Site. Sie haben keine Verkäufer - nur eine Seite, auf der der Besucher klickt und Wünsche hinterlässt. Dementsprechend muss die Site ständig etwas Neues posten, es entsprechend den Wünschen aktualisieren. In Südkorea zum Beispiel rasieren sie sich anders als in Russland und sie mögen den Geruch von Kiefern, aber zum Beispiel Vanille- Karotten im Duft.

Da Sie den Inhalt der Website schnell ändern müssen, ändert sich die Softwareentwicklung erheblich. Durch Software müssen wir herausfinden, was der Kunde will. Zuvor haben wir dies durch einige Problemumgehungen gelernt, beispielsweise durch Unternehmensführung. Dann entwarfen sie, stellten die Anforderungen an das IT-System und alles war cool. Jetzt ist es anders: Die Software wird von allen am Prozess Beteiligten, einschließlich Ingenieuren, entwickelt, da sie anhand technischer Spezifikationen lernen, wie der Markt funktioniert, und ihre Erkenntnisse auch mit dem Unternehmen teilen.

Zum Beispiel haben wir bei Qik plötzlich herausgefunden, dass Leute wirklich gerne Kontaktlisten auf den Server hochladen, und sie haben uns die Anwendung gestellt. Darüber haben wir zunächst nicht nachgedacht. In einem klassischen Unternehmen würde jeder entscheiden, dass es sich um einen Fehler handelt, da die Spezifikation nicht besagt, dass es cool funktionieren sollte und im Allgemeinen auf dem Knie implementiert wurde. Sie würden die Funktion ausschalten und sagen: "Dies benötigt niemanden, das Wichtigste ist, dass die Hauptfunktionalität funktioniert." . Und das Technologieunternehmen sieht dies als Chance und beginnt, die Software entsprechend zu ändern.



1968 formulierte der Visionär Melvin Conway die folgende Idee.

Die Organisation, die das System erstellt, ist auf ein Design beschränkt, das die Kommunikationsstruktur in dieser Organisation kopiert.

Genauer gesagt, um Systeme eines anderen Typs herzustellen, muss man auch eine Kommunikationsstruktur innerhalb eines Unternehmens eines anderen Typs haben. Wenn Ihre Kommunikationsstruktur oberste Hierarchie aufweist, können Sie auf diese Weise keine Systeme erstellen, die einen sehr hohen Time-to-Market-Indikator liefern können.

Sie können das Gesetz von Conway lesen, indem Sie den Links folgen . Es ist wichtig, die Kultur oder Philosophie von DevOps zu verstehen, da sich in DevOps nur die Kommunikationsstruktur zwischen den Teams grundlegend ändert .

Aus Sicht des Prozesses waren vor DevOps alle Phasen: Analyse, Entwicklung, Test, Betrieb linear.
Bei DevOps laufen alle diese Prozesse gleichzeitig ab.



Time-to-Market kann nur auf diese Weise erfolgen. Für Leute, die im alten Prozess gearbeitet haben, sieht es etwas kosmisch aus und im Allgemeinen so lala.

Warum brauchst du DevOps?

Für die Entwicklung digitaler Produkte . Wenn Sie kein digitales Produkt in Ihrem Unternehmen haben, wird DevOps nicht benötigt - dies ist sehr wichtig.

DevOps überwindet die Geschwindigkeitsbegrenzungen eines konsistenten Softwareproduktionsschemas . Darin laufen alle Prozesse gleichzeitig ab.

Erhöht den Schwierigkeitsgrad. Wenn DevOps-Evangelisten Ihnen sagen, dass es für Sie einfacher sein wird, Software damit zu veröffentlichen, ist dies Unsinn.

Mit DevOps werden die Dinge nur noch komplizierter.

Auf der Konferenz am Stand von Avito konnte man sehen, was es heißt, einen Docker-Container bereitzustellen - eine unrealistische Aufgabe. Komplexität wird unerschwinglich, man muss mit vielen Bällen gleichzeitig jonglieren.

DevOps verändert den Prozess und die Organisation im Unternehmen vollständig - genauer gesagt, es ändert nicht DevOps, sondern ein digitales Produkt. Um zu DevOps zu gelangen, müssen Sie diesen Prozess noch vollständig ändern.

Fragen an einen Spezialisten

Was ist mit dir? Fragen, die Sie sich stellen können, wenn Sie in einem Unternehmen arbeiten und sich als Spezialist entwickeln.

Haben Sie eine digitale Produktstrategie? Wenn ja, ist es schon gut. Dies bedeutet, dass Ihr Unternehmen auf DevOps umsteigt.

Schafft Ihr Unternehmen bereits ein digitales Produkt? Dies bedeutet, dass Sie noch einen Schritt weiter gehen und die Dinge interessanter machen können - wiederum aus Sicht von DevOps. Ich spreche nur von diesem Standpunkt aus.

Ist Ihr Unternehmen einer der Marktführer in einer Nische mit einem digitalen Produkt? Spotify, Yandex, Uber - Unternehmen, die sich derzeit auf dem Höhepunkt des technologischen Fortschritts befinden.

Stellen Sie sich diese Fragen, und wenn alle Antworten negativ sind, sollten Sie sich möglicherweise nicht mit DevOps in diesem Unternehmen befassen. Wenn das DevOps-Thema für Sie wirklich interessant ist, sollten Sie vielleicht zu einem anderen Unternehmen wechseln? Wenn Ihr Unternehmen zu DevOps gehen möchte, Sie aber alle Fragen mit „Nein“ beantwortet haben, ähnelt es diesem wunderschönen Nashorn, das sich nie ändern wird.

Organisation

Wie gesagt, nach dem Gesetz von Conway ändert sich eine Organisation in einem Unternehmen. Was hindert DevOps zunächst daran, aus Sicht der Organisation in das Unternehmen einzutreten?

Das Problem der "Brunnen"

Das englische Wort "Silo" wird hier auch ins Russische übersetzt. Die Bedeutung dieses Problems ist, dass zwischen den Teams kein Informationsaustausch stattfindet . Jedes Team greift sein Fachwissen tief ein, ohne eine gemeinsame Karte zu erstellen, in der Sie navigieren können.

In gewisser Weise ähnelt es einer Person, die gerade in Moskau angekommen ist und immer noch nicht weiß, wie man auf der U-Bahn-Karte navigiert. Die Moskauer kennen ihre Gegend normalerweise sehr gut und werden in ganz Moskau von der U-Bahn-Karte geleitet. Wenn Sie zum ersten Mal nach Moskau kommen, gibt es diese Fähigkeit nicht und Sie sind einfach desorientiert.

DevOps bietet an, diesen Moment der Desorientierung und an alle Abteilungen gemeinsam weiterzugeben, um eine gemeinsame Karte der Interaktion zu erstellen.

Zwei Faktoren stören dies.

Eine Folge des Corporate Management Systems. Es besteht aus separaten hierarchischen "Brunnen". Beispielsweise gibt es in Unternehmen bestimmte KPIs, die dieses System unterstützen. Auf der anderen Seite stören die Gehirne einer Person, die nur schwer über die Grenzen ihres Fachwissens hinausgeht und durch das System navigiert. Es ist einfach unangenehm. Stellen Sie sich vor, Sie sind am Flughafen von Bangkok angekommen - dort werden Sie sich nicht schnell orientieren. DevOps ist auch schwierig zu navigieren, und daher sagen die Leute, dass Sie einen Leitfaden finden müssen, um ihn zu finden, um dorthin zu gelangen.

Vor allem aber drückt sich das Problem der „Brunnen“ für einen Ingenieur, der vom Geist von DevOps inspiriert war, von Fowler und einer Reihe anderer Bücher gelesen wurde, darin aus, dass „Brunnen“ es Ihnen nicht erlauben, „offensichtliche“ Dinge zu tun . Nach DevOps Moskau treffen wir uns oft, reden miteinander und die Leute beschweren sich:

- Wir wollten CI nur starten, aber es stellte sich heraus, dass das Management es nicht brauchte.

Dies liegt genau daran, dass CI und der Continuous Delivery-Prozess an der Grenze vieler Untersuchungen stehen. Wenn Sie das Problem der „Brunnen“ auf organisatorischer Ebene nicht überwinden, können Sie nicht weiter vorankommen, was auch immer Sie tun und wie traurig es sein mag.



Jeder Teilnehmer am Prozess im Unternehmen: Backend- und Frontend-Entwickler, Test, DBA, Betrieb, Netzwerk, gräbt in seine eigene Richtung, und niemand hat eine gemeinsame Karte außer einem Manager, der die Divide- und Conquer-Methode irgendwie beobachtet und kontrolliert.

Die Leute kämpfen um ein paar kleine Sterne oder Flaggen, jeder gräbt sein eigenes Fachwissen.

Wenn die Aufgabe zu bestehen scheint, all dies miteinander zu verbinden und eine gemeinsame Pipeline aufzubauen, und es nicht notwendig ist, um die Sterne und Flaggen zu kämpfen, stellt sich die Frage: Was soll ich tun? Wir müssen uns irgendwie einig sein, aber niemand hat uns beigebracht, wie das geht. Wir wurden von der Schule unterrichtet: die achte Klasse - wow! - im Vergleich zur siebten Klasse! Hier ist es genauso.

Ist es in Ihrem Unternehmen dasselbe?

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

Verwenden Teams gemeinsame Tools, tragen sie zu Änderungen an diesen gemeinsamen Tools bei?

Wie oft reformieren sich Teams? Wechseln einige Spezialisten von einem Team zu einem anderen Team? In der DevOps-Umgebung wird dies normal, da eine Person manchmal einfach nicht verstehen kann, was ein anderes Fachgebiet tut. Er zieht in eine andere Abteilung und arbeitet dort zwei Wochen lang, um sich eine Karte der Orientierung und Interaktion mit dieser Abteilung zu erstellen.

Ist es möglich, einen Ausschuss für Veränderung zu schaffen und etwas zu ändern? Oder erfordert dies eine starke Hand der höchsten Führung und Richtung? Ich habe kürzlich auf Facebook geschrieben, wie eine wenig bekannte Bank Tools durch Bestellungen implementiert: Wir haben eine Bestellung geschrieben, wir haben sie ein Jahr lang implementiert und wir werden sehen, was passiert. Das ist natürlich lang und traurig.

Wie wichtig ist es für Manager, persönliche Leistungen zu erhalten, ohne die Leistungen des Unternehmens zu berücksichtigen?

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

Infrastruktur als Code

Nachdem dieses Problem behoben wurde, ist die erste wichtige Praxis, ohne die es schwierig ist, weiter in DevOps einzusteigen, die Infrastruktur als Code .

Am häufigsten wird die Infrastruktur als Code wie folgt wahrgenommen:

- Lassen Sie uns alles auf Bash automatisieren, uns mit Skripten abdecken, damit der Admin-Bereich weniger manuelle Arbeit hat!

Aber das ist nicht so.

Infrastruktur als Code bedeutet, dass Sie das IT-System beschreiben, mit dem Sie arbeiten, um dessen Status ständig zu verstehen.

Zusammen mit anderen Teams erstellen Sie eine Karte in Form eines Codes, den jeder versteht und in dem Sie navigieren und navigieren können. Es spielt keine Rolle, was getan wird - Chef-, Ansible-, Salt- oder YAML-Dateien werden in Kubernetes verwendet - es gibt keinen Unterschied.

Auf der Konferenz sprach ein Kollege von 2GIS darüber, wie sie ihre eigene interne Sache für Kubernetes gemacht haben, die 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 miteinander prüfen, Änderungen überwachen, wie sie geändert und verbessert werden können, was fehlt.

Stimmen Sie zu, separate Bash-Skripte geben dieses Verständnis normalerweise nicht. In einer der Firmen, in denen ich gearbeitet habe, gab es sogar einen Namen "nur schreiben" - ein Skript - wenn das Skript geschrieben wurde, und es ist bereits unmöglich, es zu lesen. Ich denke, das ist dir auch vertraut.

Infrastruktur als Code ist ein Code, der den aktuellen Status der Infrastruktur beschreibt . Viele Produkt-, Infrastruktur- und Serviceteams arbeiten gemeinsam an diesem Code, und vor allem müssen sie alle verstehen, wie dieser Code im Allgemeinen funktioniert.

Der Code wird gemäß den Best Practices für die Arbeit mit Code begleitet : gemeinsame Entwicklung, Codeüberprüfung, XP-Programmierung, Testen, Pull-Quests, CI für Code-Infrastrukturen - all dies ist geeignet und kann verwendet werden.

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

Das Ändern der Infrastruktur im Code nimmt nicht viel Zeit in Anspruch . Ja, möglicherweise enthält der Infrastrukturcode auch technische Schulden. Normalerweise begegnen Teams ihm anderthalb Jahre, nachdem sie begonnen haben, "Infrastruktur als Code" in Form einer Reihe von Skripten oder sogar Ansible, die sie als Spaghetti-Code schreiben, zu implementieren, und sogar Bash-Skripte legen es in die Feuerbox!

Wichtig : Wenn Sie dieses Zeug noch nicht ausprobiert haben, denken Sie daran, dass Ansible keine Bash ist ! Lesen Sie die Dokumentation sorgfältig durch und lesen Sie, was sie allgemein darüber schreiben.

Infrastruktur als Code ist die Aufteilung des Infrastrukturcodes in separate Schichten.

In unserem Unternehmen unterscheiden wir drei grundlegende Schichten, die sehr klar und einfach sind, aber möglicherweise mehr. Sie können sich Ihren Infrastrukturcode ansehen und sagen, ob Sie an dieser Bedingung leiden oder nicht. Wenn keine Ebenen hervorgehoben sind, müssen Sie Zeit zuweisen und ein wenig umgestalten.


Auf der Basisebene wird festgelegt, wie das Betriebssystem, Sicherungen und andere Dinge auf niedriger Ebene konfiguriert werden, z. B. wie Kubernetes auf einer Basisebene bereitgestellt wird.

Die Serviceebene sind die Services, die Sie dem Entwickler zur Verfügung stellen: Protokollierung als Service, Überwachung als Service, Datenbank als Service, Balancer als Service, Warteschlange als Service, Continuous Delivery als Service - eine Reihe von Services, die einzelne Teams für die Entwicklung bereitstellen können. All dies muss als separate Module in Ihrem Konfigurationsmanagementsystem beschrieben werden.

Die Ebene, auf der die Anwendungen erstellt werden und wie sie über den beiden vorherigen Ebenen bereitgestellt werden.

Sicherheitsfragen

Haben Sie ein gemeinsames Infrastruktur-Repository in Ihrem Unternehmen? Kontrollieren Sie die technischen Schulden in der Infrastruktur? Verwenden Sie Entwicklungspraktiken im Infrastruktur-Repository? Ist Ihre Infrastruktur in Scheiben geschnitten? Sie können das Base-Service-APP-Schema überprüfen. Wie schwierig ist es, eine Änderung vorzunehmen?

Wenn Sie mit der Tatsache konfrontiert sind, dass die Einführung von Änderungen anderthalb Tage gedauert hat, bedeutet dies, dass Sie eine technische Verschuldung haben und damit arbeiten müssen. Sie sind gerade auf einen Rechen mit technischen Schulden im Infrastrukturcode gestoßen. Ich erinnere mich an viele solcher Geschichten, in denen zum Ändern einer CCTL die Hälfte des Infrastrukturcodes neu geschrieben werden muss, da Kreativität und der Wunsch, alles zu automatisieren, dazu geführt haben, dass überall alles kurzgeschlossen wird, alle Stifte entfernt werden und eine Umgestaltung erforderlich ist.

Kontinuierliche Lieferung

Ähnliche Belastung mit einem Darlehen. Zunächst erscheint eine Beschreibung der Infrastruktur, die recht einfach sein kann. Es ist nicht notwendig, alles im Detail zu beschreiben, aber eine grundlegende Beschreibung ist erforderlich, damit Sie damit arbeiten können. Andernfalls ist nicht klar, was weiter zu tun ist. All diese Praktiken entfalten sich gleichzeitig, wenn Sie zu DevOps kommen, aber Sie müssen zunächst verstehen, was Sie haben und wie Sie damit umgehen. Dies ist nur die Praxis der Infrastruktur als Code.

Nachdem klar wurde, dass Sie dies verwalten können, überlegen Sie, wie Sie den Entwicklercode so schnell wie möglich an die Produktion senden können. Ich meine, zusammen mit dem Entwickler - wir erinnern uns an das Problem der "Brunnen", das heißt, nicht einzelne Leute haben sich das ausgedacht, sondern das Team.

Als Vanya Yevtukhovich und ich das erste Buch von Jes Hamble und die Autorengruppe „Continuous Delivery“ sahen, das 2009 veröffentlicht wurde, haben wir lange darüber nachgedacht, wie wir seinen Namen ins Russische übersetzen können. Sie wollten es als "Ständig liefern" übersetzen, aber leider übersetzt als "Kontinuierliche Lieferung". Es scheint mir, dass unser Titel etwas Russisches mit Druck enthält.

Ständig liefern - das heißt

Der Code, der sich im Lebensmittel-Repository befindet, kann jederzeit in der Produktion heruntergeladen werden . Es darf nicht entleert werden, aber es ist immer bereit dafür. Dementsprechend schreiben Sie immer Code mit einem schwer zu erklärenden Gefühl der Besorgnis unter dem Steißbein. Es wird häufig angezeigt, wenn Sie den Infrastrukturcode bereitstellen. — , -. .

, , . « », , , . — : , .

- . , - , , , . , , DevOps- : - , — Kubernetes- , - , .

- — - . , - . Continuous Delivery : , - , . , . , .

. , AB- , - «» , , , , 100 .

« » .

Dev, CI, Test, PreProd, Prod — , , .

, Base Service APP, , , .

95 % ? ? , ? ?

, ! — ).

Rückkopplung

. DevOpsConf Infobip, , , , !



, -, Qik , . , Zabbix 150 000 items, . , :

— , ?

, , .

. , , , , - — . 4 , «Segmentation fault».

, Zabbix, , , , API-, . , . , android-. :

— , ?

, UI. , HTTP-. android- — . , 40 , , - HTTP-, . , API , , , .

. «», , . , . , , , , — , , ( ), . .

, — .

CI, - . Test, PredProd, . , , , : , — .

. , DevOps — . , .

— ? , , , , ?

? ? ? , , , 3 ?

, , .

, , .

, .

, , . , , . .

, IDE . IDE , , . Sublime, Atom Visual Studio Code, , , IDE.

. , - , , . - — , pull request — , . .

. , . , — .

, , . , Time-to-market. vendor lock : , , , . , . , , vendor lock . .

Schema

, DevOps-.



, .

, CPU, , . — : , , CI/CD Engine, , .

: , , , Load Balance , resizing , Big Data . — , .

, , , , — , .

delivery pipeline . , — . , — : , , , , .

, , — , , . , Okmeter? , , . — , , Prometheus .

. , , , . , DevOps.


— , , . rocket science — , . , — .

?

, .

? ? ?

. - — , , .

, DevOps...

… , :

• .
  
• , .
  
• , .
  
• Continuous Delivery.
  
• .
  
• .
  
• .
  
• , DevOps.
  
• , .
  

, , - : .

DevOpsConf 2019 . ++. , , DevOps-. , 20