Entwicklungsteams sind möglicherweise lose miteinander verbunden und arbeiten in verschiedene Richtungen, ohne DevOps zu kennen und nicht verwenden zu wollen. In dem heutigen Artikel werden wir darüber sprechen, wie DevOps-Praktiken verzerrt und transformiert werden können, damit sie in Unternehmen mit seit langem etablierten Vorschriften, Richtlinien und Gewohnheiten der Menschen implementiert werden können.



Das Material basiert auf einem Dialogbericht von Sergey Berdnikov (Goldene Krone) und Artem Kalichkin (CFT) von der DevOops- Konferenz im Oktober 2017 . Unter dem Schnitt - Video- und Textprotokoll des Berichts.




Sergey: Ich bin der Leiter der Betriebsabteilung in unserem Unternehmen. Artem und ich haben eine kleine Revolution-Evolution begonnen. Alles begann mit der Revolution, jetzt ist es in die Evolutionsstufe eingetreten.



Artem: Das Unternehmen ist seit 1992 auf dem Finanzmarkt tätig. Die Arbeit besteht aus zwei Hauptteilen. Der erste Teil ist Softwareentwicklung, Core Banking, Bankbuchhaltung und so weiter. Hier agieren wir als Anbieter: Wir haben Ihnen eine Box entwickelt und verkauft, und Sie haben sie bereitgestellt und betrieben.

Der zweite Teil ist die Verarbeitung von Dienstleistungen. Hier bieten wir Dienstleistungen entweder direkt für Einzelpersonen oder über unsere Partner an. Dies sind große Handelsnetzwerke, Banken und andere Teilnehmer am Finanzdienstleistungsmarkt. Hier erarbeiten wir den gesamten Zyklus von der Idee über die Entwicklung, Implementierung bis hin zum weiteren Betrieb.

Wir arbeiten mit Sergey im Verarbeitungsteil unseres Unternehmens. Wir werden erzählen, wie wir in dieser Verarbeitung mit DevOps zur Geschichte gekommen sind.

Was war

Sergey: Unser Vermächtnis war das Bankgeschäft. Das Unternehmen stellte zunächst Bankprodukte her, alles war bekannt: Nur die gesamte Infrastruktur von SPARC, seine eigenen Rechenzentren, der gesamte Kern wurde in Oracle geschrieben. PL / SQL-Code, viele Dinge - es ist nicht einfach zu skalieren.

Wir haben nur vertikal skaliert: Wir haben ein starkes Stück Eisen gekauft, es verwendet, bis es veraltet war, es durch ein neues ersetzt und das alte zur Inszenierung gebracht.

Schrieb auch viel Code in Java. Wir haben durch eine warme Reserve reserviert: Es gibt ein Rechenzentrum und die gesamte kopierte Struktur - Switches, Server, alles in einem, Bolzen zu Bolzen.



Hier sehen Sie, wie die gesamte Struktur aus Sicht der Prozesse aussah. Es gab separate technische Direktionen Dev, dann Firewalls mit Feuer. Als nächstes folgte die zentralisierte IT, die an der Entfernung, Bereitstellung usw. beteiligt war. Das heißt, die Entwickler haben eine große Anweisung geschrieben, und der IT-Betrieb wurde in drei Abteilungen unterteilt:

• Angewandte Administratoren, die an einer Bereitstellung beteiligt waren. Sie hatten keine Wurzel, es waren Benutzer auf den Maschinen, sie konnten Anweisungen ausführen - dies wird als Affencode bezeichnet.
• Unix-Administratoren, die konfigurieren, Hardware hinzufügen usw. konnten und konnten.
• Es gab einzelne Datenbankspezialisten. Und da Datenbanken für uns das Hauptziel unserer Existenz sind, fanden dort viele Prozesse statt.

Artem: DevOps ist zu diesem Zeitpunkt noch nicht hier, wir haben gemäß den Vorschriften gearbeitet, mit denen Sergey nicht zufrieden war.

Sergey: Ich bin dem Team der angewandten Administratoren beigetreten und erinnere mich an die „großartigen Zeiten“. Wir könnten einen Antrag für drei Wochen stellen. Eine Bewerbung kommt herein, sie haben einen Fehler darin gefunden und abgesagt, weil sie glaubten, dass die Narren selbst keine Bewerbungen schreiben konnten. Und das Wissen, das für das korrekte Schreiben des Antrags notwendig war, war bei mir.

Dann kamen die Leute an einem Tag gerannt: "Und was haben wir falsch geschrieben?" Ich erklärte, dass sie irgendwo kein Plus oder Minus gesetzt und ein Komma vergessen haben. Sie schreiben eine Anwendung, ich gebe eine Art Fachwissen über die Arbeit in Oracle und sende es weiter an den DBA, wo speziell geschulte Leute sitzen, die wissen, wie man diese Anwendungen erfüllt.

Und sie arbeiten auch mit mir zusammen und sagen: "Warum haben Sie hier nicht den Hauptindikator angegeben, haben Sie kein Semikolon geschrieben?" Die Anwendung wird abgebrochen, der Zyklus beginnt von neuem. Nun zu solch einer Schande, aber was zu tun ist, bevor man auf diese Weise arbeitet.

Artem: Dann haben wir angefangen uns zu ändern. Es gab wirklich viele Anwendungen. Als Sergey zu unserem Team stieß, war er das Ergebnis einer kleinen Entwicklung und Transformation. Ich war der Autor einer ziemlich großen Anzahl von Vorschriften für verschiedene Arten von Anwendungen, weil ich irgendwie überleben musste. Im Allgemeinen fand unsere gesamte Transformation nicht aufgrund von Hype oder Mode statt, sondern aufgrund der Notwendigkeit, bestimmte Probleme zu lösen.

Zum Beispiel führen Konfigurationsänderungen dazu, dass mein Kampf abgebrochen wurde und nicht richtig funktionierte. Ich habe es an einem Tag oder in der Nacht herausgefunden: Es kam vor, dass sie um sechs Uhr abends etwas rollten, und bis drei Uhr morgens funktionierte das alles falsch.

Es gab Installationen der Version, vor denen niemand gehen wollte und die nicht besprachen, was zu tun ist, wenn etwas schief geht. Die bekannten berühmten mehrseitigen Installationsanweisungen wurden buchstäblich eine halbe Stunde vor Arbeitsbeginn an alle übermittelt. Es war notwendig, etwas zu lösen, und in diesem Moment fanden wir eine Lösung - die adaptive Implementierung von ITIL-Prozessen.

Wir begannen zu überprüfen, ob nach dem Wurf zum Kampf alles richtig rollte, ob der Dienst und die Hauptkennzahlen normal funktionieren. Wir haben mit der Datierung begonnen, bevor wir die Versionen installiert haben. Und dann war tatsächlich der Anfang von DevOps, als das Entwicklungsteam, das das Verteilungskit überträgt, zumindest das Operationsteam traf und diskutierte, was in der Nachtarbeit passieren würde.

Sergey: Und es gab etwas zu besprechen: Wir hatten vier Seiten mit Installationsanweisungen - einen Befehl ausführen, einen Plan ausführen. Es war fast unmöglich, fehlerfrei zu schreiben. Wir schworen ständig zwischen der Entwicklung, die wir falsch geschrieben, gelesen und so etwas. Meetings wurden manchmal zur Hölle.

Artem: Wir haben versucht, mit Anwendungen auf Confluence umzusteigen, da die Übertragung in Word unpraktisch ist - es war möglich, etwas Falsches zu bilden. In Confluence war immer geplant, die aktuelle Version mit allen Änderungen hochzuladen.

Wir haben einen Code eingefügt, um in den Kampf zu rollen. Confluence kaute auf dem Meta-Markup herum, gab etwas anderes Falsches heraus, der Administrator nahm den Code, der sich in Nudeln verwandelte, und begann damit zu arbeiten - es war eine Katastrophe.

Wir stellten fest, dass, egal wie pervers die Seitenanweisung war, all dies zu völligem Unsinn wurde, egal wie sie gerahmt war.

Es gab wichtige Voraussetzungen für längere Ausfallzeiten bei Nachtarbeit, die zu einem schlechten Start nach der Installation, zu Pfosten und einer Vielzahl von Konflikten zwischen Entwicklung und Betrieb führten.

• Viele menschliche Fehler bei der Übertragung von Änderungen;
• Ständige Suche nach den Schuldigen;
• Die Entfernungsrate neuer Module bis zu 3 Wochen;
• Einzelne Fehlerstellen (nur vertikale Skalierung), mangelndes Gleichgewicht;
• Geplante Ausfallzeit während Updates für 2 Stunden.

Transformationshintergrund

Sergey: Es gab viele Veränderungen, wir haben ständig durcheinander gebracht. Jede Woche versammelten wir uns, fluchten, beruhigten uns. Dieser Vorgang wurde für immer wiederholt, sie suchten nach dem Schuldigen: "Dies sind alles Entwickler, die gekrümmten Code schreiben, selbst das Java-Modul kann nicht übertragen werden."

Artem: Aber die Entwickler dachten, dass dies elementare Dinge waren: Ein Fehler in den Protokollen fiel aus - sortieren Sie ihn aus, googeln Sie ihn und verstehen Sie, was in den Konfigurationen behoben werden muss.

Sergey: Sie haben auch sehr lange neue Produkte veröffentlicht. Dies ist nur strukturell verwandt: Sie haben eine Anfrage für uns erstellt, wir mussten eine Anfrage erstellen, um einen Benutzer auf dem Server zu erstellen, und dann ein Schema erstellen. Dann begann der Fußball mit Bewerbungen. Die Entwickler haben Module herausgegeben, aber wir können sie nicht verwenden, wir haben alles gemäß den Vorschriften.

Auch wir haben sehr lange eingestellt. Die Anleitung ist riesig, während Sie lesen, während Sie dies tun, dauerte die Rolle ungefähr zwei Stunden. Die Aktionen selbst wurden nicht in einer Sekunde abgeschlossen.

Artem: Es gab auch Routinemaßnahmen, zum Beispiel 30 Java-Module. Insgesamt gibt es eine Konfiguration, in jeder Konfiguration müssen Sie Änderungen vornehmen. Erstens können Sie verrückt werden, um die gleiche Änderung vorzunehmen: Sie hassen sich selbst und den Rest der Menschheit. Zweitens wird die Wahrscheinlichkeit, einen Fehler in der 25. Konfiguration zu machen, extrem hoch.

Sergey: Ich erinnere mich, wie ich ein Angebot bekam, horizontal zu skalieren. Und wir haben 150 Module mit unterschiedlichen Konfigurationen: Wenn der Fehler in einer Version der Konfiguration auftritt, wird mir eine zweite zugewiesen, und ich werde einen Fehler darin machen. Wir sind schließlich keine Roboter.

Artem: Die geplante Ausfallzeit von 2 Stunden Aktualisierungszeit ist einer der entscheidenden Faktoren dafür, warum wir nach einer Lösung gesucht haben und wie wir uns davon lösen können.

Tatsache ist, dass wir Finanzdienstleistungen und Verarbeitungsdienstleistungen anbieten. Wir arbeiten im Ausland. Dann haben wir in 11 Zeitzonen gearbeitet, 2013 hatten wir nur eine Stunde Zeit, als die Nutzung des Dienstes minimal war, die Anzahl der Kundenanrufe minimiert wurde, Ruhe kam und etwas getan werden konnte.

Bedingt könnten wir nachts von einer Stunde bis zwei Uhr arbeiten. Zwei Stunden sind viel mehr als dieses Fenster. Wir näherten uns einer Katastrophe, wenn nicht für die Transformation, weil wir jetzt physisch keine Fenster haben.

Als Antwort auf all diese Probleme kam mir eine Idee, ein Versuch herauszufinden, was DevOps ist.

Zu dieser Zeit kam unser Kollege mit HighLoad, ich war mit der Implementierung von CMBD beschäftigt, weil ich es brauchte, damit die Konfigurationen nicht kaputt gingen und ich zumindest etwas verwalten konnte. Er hörte sich den Bericht von Sasha Titov an, der über einen Koch sprach. Es scheint auch Konfigurationsmanagement zu sein

2013 las ich alles darüber und entschied, dass etwas Müll nicht das war, was ich brauchte. Ich muss kontrollieren, und sie zwingen den Code, dort zu schreiben. Die Situation änderte sich jedoch nicht, es häuften sich Probleme und ich zwang mich, zu Hause zu sitzen und die Dinge zu regeln. Ich dachte, dass etwas drin ist, eine Art Erlösung.

Und dann entdeckte ich die Postulate und Werte, dass wir dieselbe Umgebung, dasselbe Rollout- und Update-Skript haben sollten, dass wir diese Szenarien überprüfen sollten, beginnend mit der Testumgebung.

Es gab die Möglichkeit, Anweisungen und manuelle Aktionen zu minimieren und alles so weit wie möglich zu automatisieren, nicht nur mit unterschiedlichen Bash-Skripten, bei denen sich ein anderer Administrator später das Bein brechen würde.

Da kam mir diese Idee, mit der ersten Erklärung, was ich erhalten möchte. Dies ist das Dokument von 2013, das erste, das im Unternehmen über DevOps erstellt wurde.

Sergey: Hier ist eine Schlüsselidee: die Geschwindigkeit der Entfernung neuer Module zu verringern, die Anzahl der Fehler während der Entfernung zum Kampf zu verringern. Das heißt, es gab bestimmte Ziele, die wir in der ersten Phase der Veröffentlichung neuer Versionen erreichen wollten.



Es gab viele Argumente dagegen. Zum Beispiel die Angst, dass die Automatisierung alles kaputt macht: Es funktioniert unverständlich, es ist beängstigend, den Code eines anderen auszuführen, es ist ein großartiger Service, die Leute bekommen Geld durch uns. Nicht ernst.

Der nächste, der sich den Wachen anschließt. Sie gingen vollständig durch uns hindurch: eine Art identische Bühne! Und sie haben ein perfektes Bild der Welt: Übertragen Sie die Versionen auf dem Flash-Laufwerk, signieren Sie sie mit einem PGP-Schlüssel, und alles wird gut - der perfekte Service. Wir haben so lange mit ihnen zusammengearbeitet, um das Ende zu erreichen, nur dank der Projektaktivitäten haben wir etwas getan.

Artem: Hier gingen wir von Werten aus : Hier verlieren wir Geld, dieser einfache ist inakzeptabel.

Die Jungs und ich haben einen Weg gefunden, um diese Verluste zu minimieren. Hast du eine bessere Option? Wenn nicht, schweigen Sie, wenn Sie es sind, kritisieren Sie und bieten Sie an. Nichts zu bieten? Dann versuchen wir es.

Es gab einen Prozess der Überzeugung und des Erzwingens: Wir schlugen vor, unsere Ideen auf einer begrenzten Anzahl von Systemen anzuwenden.

Sergey: Wir wurden gebeten, alle Risiken aufzuschreiben, wie wir sie veröffentlichen werden. Es war notwendig, sich mit Leuten abzustimmen, die Geld verlieren konnten. Außerdem sagten die Programmierer: "Wir haben eine Art Code geschrieben, wir haben Zip normal übertragen, wir haben Anweisungen geschrieben und wir haben zusätzlichen Code geschrieben, um ihn zu entfernen ?!"

Artem: „Ich schreibe Geschäftslogik-Anwendungscode und verwende Frameworks, um unnötige Teile des Codes zu minimieren. Und Sie bitten um mehr Code zum Schreiben. Am Ende nehmen und herausnehmen “- solche Dialoge standen am Anfang. Trotzdem funktionierte dies alles allmählich durch Demonstrationen und Überzeugungen.



Sergey: In den ersten Iterationen haben wir viele wichtige Entscheidungen hinsichtlich der Struktur unseres Unternehmens und der Technologie getroffen. Zunächst haben wir das Konfigurationsmanagement implementiert. Dies ersparte uns die Mühe, die falsche Konfiguration mit einer Anweisung von 10 A4-Seiten zu entfernen.

Dann begann der Betrieb zu sinken, und die Anwendungsadministratoren wechselten mit den Entwicklern in die technische Direktion. Es gab ein Gefühl des Befehls, ein Gefühl des Ellbogens. Wir begannen zu verstehen, dass wir ein Produkt herstellten und unverständliche Anwendungen nicht mit dem Wunsch erfüllten, sie abzulehnen - es gab bestimmte Ziele.

Teamwork entsteht, wenn Sie neben Menschen sitzen, wenn Sie sehen, wie sie funktionieren, wenn sie sehen, wie wir arbeiten. Wir haben sogar einen Dialog zwischen den Teams: Dies ist der erste Funke von echten DevOps. Es gab keine Technologie, keine neue Technologie. Aus technologischer Sicht dachten wir, dass überhaupt nichts Wurzeln schlagen würde, wir arbeiteten anders in einer anderen Welt.

Die erste Idee ist, Configuration Management selbst zu schreiben. Es gibt viele Entwickler. Dann erinnerten wir uns an alles, was wir selbst geschrieben hatten, und lehnten ab - wir alle verschleiern.

Artem: Ich werde meinen Kollegen korrigieren. Sergey ist falsch: Alles, was wir selbst schreiben, hat in unserem angewandten Bereich, in dem wir stark sind, perfekt funktioniert. Und als sie versuchten, einige ihrer Spinnen zu schreiben, um automatisch CMDB oder eine Art selbstgeschriebenes Überwachungssystem zur Steuerung der Geschäftslogik zu erstellen, kommt ein System einer anderen Klasse.

Zu diesem Zeitpunkt stellte sich heraus, dass die Anwendungsadministratoren von der IT-Abteilung in unsere technische Abteilung wechselten. Wie Sergey sagte, spürten sie den gesamten geschäftlichen Wert, der aufgrund kaufmännischer Dinge elementar war.

Wir hatten die Möglichkeit, ihnen Projektprämien für Erfolge zu zahlen, das war sehr motivierend. Zu Beginn des Dialogs wurde das Entfernen von Modulen von drei Wochen auf eine Woche oder mehr reduziert, und einige Fortschritte gingen auch ohne tiefgreifende Automatisierung.



Sergey: In diesem Moment haben wir den Entwickler gebeten, etwas zu sagen, wenn wir etwas mit der Anwendung nicht verstanden haben: "Lassen Sie uns gemeinsam entscheiden und schreiben, wie die Anwendung klingen soll."

Artem: Und unter dieser bedingten Kommandostruktur haben wir begonnen, uns der Technologie zuzuwenden.

Sergey: Jetzt werden wir Ihnen sagen, wie wir das System ausgewählt haben. Es war interessant genug. Zuerst haben wir Chef aus einem einfachen Grund ausprobiert - wir kannten einen Guru, der Chef kennt. Dann haben wir Puppet ausprobiert, weil Oracle damals die Unterstützung für Puppet angekündigt hat.

Ansible versuchte es auch, aber beide Teams mochten es nicht als System. Es gab auch Sicherheitsprobleme: Ansible war 2013 ganz anders als das aktuelle.

Wir haben zwei verschiedene Projekte mit derselben Funktionalität parallel gestartet. Und alles funktionierte cool, es gab das Gefühl, dass hier etwas nicht stimmte und in Ruhe gelassen werden sollte. Wie haben wir uns entschieden?

Artem: Programmierer haben über Chef geschrieben, Admins über Puppet. Die Idee war, was wir versuchen werden, dann vergleichen, wo es besser ist und wählen. Aber als wir uns versammelten, als die Zeit verging, begann die Dualität Probleme zu verursachen, weil das Codevolumen wächst, es weiter wächst und jeder alles mag, Entwickler schreiben und automatisieren.

Ich versammelte alle und fragte, worüber wir schreiben würden. Programmierer sagten: "Wir mögen Chef wirklich." Und Admins: "Und zu uns auf Puppet!". Es war eine komplette Dose. Ich habe verglichen und verstanden, dass es in der aktuellen Umgebung und den aktuellen Parametern keine objektive Möglichkeit gibt, dieses oder jenes Produkt auszuwählen.

Infolgedessen habe ich, wie sie in unserem Land gerne sagen, Wahlen mit einem vorhersehbaren Ergebnis durchgeführt. Eine Art "geschlossene" Abstimmung unter den Teilnehmern. Aber es gab keine Fälschung, es gab eine bedingte Wirkung auf das Gehirn, aufgrund derer Puppet ausgewählt wurde. Ich habe beschlossen, beleidigte Entwickler schneller zu beruhigen als beleidigte Administratoren. Es gab einfach kein anderes Auswahlkriterium.

Sergey: In diesem Moment haben wir lange darüber nachgedacht, wie man Binarismus einsetzt. Auf der Folie sehen Sie ein Foto von unserem Board und Meeting. Wir haben beschlossen, dass Sie eine Art Verpackungssystem verwenden müssen und nicht Ihr Fahrrad. Wieder gewann der Verstand.

Tatsächlich haben wir nicht RPM gewählt, sondern IPS - den Solaris-Paketmanager. Wir importierten uns von der 11. Version in die Top Ten, die standen, und begannen, sie zu verwenden. In diesem Moment war es die richtigste Entscheidung, sich von selbstgeschriebenen Bash-Krücken und Reißverschlüssen abzulehnen.

Artem: Deshalb war es immer noch wichtig: Im Rezept erscheint das Ergebnis in Form einer Änderung der Versionsnummer, es erstreckt sich immer weiter vom Repository weg und wird notwendig.

Als wir ankamen, um DevOps, Chef, all diese Dinge zu trainieren, dachten wir: "Jetzt werden sie uns sagen, wie man Binärdateien überträgt", aber sie sagten uns nichts darüber. Die Antworten lauten normalerweise: "Jeder entscheidet auf seine Weise und steigt aus, wie er kann." Daher stellten sie fest, dass die Antwort der Branche darauf „42“ lautet, wie aus dem „Per Anhalter durch die Galaxis“, der Antwort auf die Hauptfrage des Universums.

Sergey: Wir hatten auch eine lange Debatte darüber, wie man eine CI / CD erstellt, was es ist. Wie Configuration Management - ein Dienstprogramm, nahmen sie und lieferten. Und hier sind viele Optionen und Auswahlmöglichkeiten, über die sie lange gestritten haben, die Entwickler haben ihr eigenes System erstellt, und im Betrieb haben wir unser eigenes für die Entfernung erstellt.

Zu diesem Zeitpunkt stellten wir fest, dass es keine perfekte Lösung gab. Nimm einfach alles, was wir gewonnen haben und ertrage es. Die Entwickler hatten ein eigenes Montagesystem, wir haben unsere Lieferung selbst gemacht. Es gab keine perfekte Wahl und arbeiten immer noch auf unterschiedliche Weise mit verschiedenen Teams. Es gibt kein Ideal.

Wir haben auch einen großen Stapel, der größte Teil unseres Codes ist in die Datenbank eingebettet: die gesamte Finanzverarbeitung, die leider das Paradigma beibehält: "Je näher an den Daten, desto schneller funktioniert sie". Oracle verkauft, stimmt Fowler zu. Finanztransaktionen hängen in PS / SQL, wir haben kein OpenSource-Produkt gefunden, das zur Lösung unseres Problems mit der Versionierung und Bereitstellung beitragen könnte. Vielleicht war er es, aber wir fingen an, unser eigenes Instrument zu schreiben.

Artem: Tatsächlich haben wir ein großes Problem, da Production, wie auf der ersten Folie erwähnt, ein großer vertikaler Server ist. Dementsprechend ist es furchtbar teuer und sehr schwierig, denselben großen vertikalen Server auf Stage zu bringen. Das ist nicht so schlimm.

Tatsache ist, dass wir eine Umgebung erstellen müssen, deren Leistung ungefähr ähnlich ist, und die mit Daten gefüllt werden müssen, deren Volumen und, nicht weniger wichtig, Kardinalität ähnlich sind, damit unsere Stage-Tests korrekt bestanden werden.

Hier waren sehr schwierige Entscheidungen. Zunächst einmal haben wir festgestellt, dass wir auf der Bühne nicht die gleichen vertikalen Fahrzeuge wie im Kampf bereitstellen können.Zum Zeitpunkt X können wir jedoch die Referenzindikatoren für Systemleistungsanforderungen in der Stage-Umgebung festlegen und sie vergleichen, wenn neue Pakete eingeführt werden. Wenn sie sich abnormal ändern, bedeutet dies, dass etwas in uns schwebte und etwas nicht falsch funktioniert. Dies ist ein Problem.

Dann entdeckten wir ein Problem beim Übertragen von Daten aus dem Kampf auf die Bühne, um sie mit der gleichen Datenmenge zu füllen. Es ist unmöglich, dass keine der Personen, die laut Dokumenten keinen Zugriff auf Kundendaten haben, Zugriff darauf hat.

Wir haben nicht das Recht, personenbezogene Daten und Bankgeheimnisse von Kunden in Stage einzubringen. Um diese Daten zu übertragen, habe ich Datenverschleierungsskripte geschrieben, damit sie nicht wiederhergestellt werden können und nicht mit echten vergleichbar sind. Gleichzeitig ist es wichtig, dass es unmöglich ist, alle Namen durch aaa bbb zu ersetzen, da wir die Datenkardinalität verlieren und alle unsere Überprüfungen auf der Bühne falsche Informationen zeigen.

Daher haben wir dieses Skript auch mit dem Ziel geschrieben, eine bedingt zufällige Kardinalität dieser Textdaten zu generieren, damit unsere Anfragen ein angemessenes Bild zeigen, das mit einem Kampf vergleichbar ist, und wir die Änderungen verstehen können.

Wir bewegen uns weg von einem absoluten Leistungszustand, wir beobachten Veränderungen. Die Situation hat sich im Vergleich zur Vorgängerversion nicht verschlechtert, die unserer Meinung nach nicht schlecht in der Leistung war.



Dies ist die zweite Iteration. Wahrscheinlich lautet der Schlüsselbegriff hier, dass das Projekt hier endete. Es gab kein DevOps-Projekt. Hier war ursprünglich ein interner Kunde - ich. Ich bekam mein Ergebnis: Die Anweisung wurde reduziert, Fehler während der Veröffentlichung der Version wurden reduziert, die Kampfkonfiguration begann sich zu ändern, wurde über Puppet verwaltet, sie wurde kontrolliert und verständlich. Was ich wollte, war was ich bekam.

Sergey: Es gab geringfügige Änderungen gegenüber Ihrer Einreichung. Die Zuständigkeiten gingen erneut von der zentralen IT an die technische Direktion über.

Es wurde ein vollwertiges OPS mit einer Wurzel. Dies hat tatsächlich dazu beigetragen, die Aufgaben im Hinblick auf das Entfernen neuer Module zu erfüllen. Wir haben begonnen, Module schneller zu machen, nach drei Wochen schien uns die Ausführung in nur drei Tagen ideal. Das Ergebnis war greifbar: Es gab einen Antrieb, das Team begann Ideen zu generieren, wie und wie man sich verbessern kann.



Was wir aus Sicht verwandter Einheiten getan haben: Wir haben ein Team von mehr als 200 Mitarbeitern, 150 Entwicklern und 6 OPS. Es gab viele Eskorten, Sicherheitspersonal. Erstens - die Erkenntnis ist gekommen, dass die beste ideale Anwendung nicht gemacht werden muss. Sie begannen, dies zu tun und zu versuchen: Wenn eine Person die Möglichkeit hat, etwas zu tun, ohne eine Anwendung zu erstellen, geht es allen gut. Und das geht ganz schnell.

Artyom:Hier ist ein Beispiel, wir machen ein Angebot über Git. Der Manager selbst kommt herein und macht ein Angebot für die Schlacht.

Sergey: Wir haben Tools wie Gitlab gefunden. Wir fanden es gut, dass eine Person mit einer grafischen Oberfläche arbeiten kann. Es gibt eine Schaltfläche zum Herunterladen. Der Benutzer versteht möglicherweise nicht einmal, was das Festschreiben tatsächlich bewirkt.

Gleichzeitig haben wir Skripte geschrieben, um den Inhalt zu überprüfen, z. B., dass PDF PDF ist, die Dateigröße und andere Logik gemäß den vom Sicherheitsteam herausgegebenen Regeln zu überprüfen. Die Benutzer hatten die Möglichkeit, diese Dokumente zu aktualisieren, ohne Anwendungen zu erstellen. Die Belastung der Operationen hat abgenommen.

Eine weitere Schwierigkeit bestand darin, solche Momente zu berechnen. In der Routine ist nicht klar, wie nach Problembereichen gesucht werden soll. Deshalb haben wir uns eine eigene Waage ausgedacht und sie „Schakale“ genannt.

Das alte Bild hat uns inspiriert. Wir haben berücksichtigt, dass wir jeder ausgeführten Anwendung die Anzahl der Schakale zuweisen, wie langweilig und langweilig es ist und wir wollen es nicht tun. Am Ende des Monats überlegten sie, welche Anwendungen die Schakale am meisten erzielten.

Sie setzten sich als ganze Einheit und überlegten, wie sie diese Schande loswerden könnten. Wie man es nicht notwendig macht, Anwendungen dafür zu erstellen, war cool und trieb die Leute an.

Die nächste Phase, in der wir Automatisierungsmethoden gefunden haben, sind Bots. Wir beherrschten die Telegramm-API und begannen, Bots für alle hintereinander zu schneiden, insbesondere für uns. Wir haben die letzten Auslöser abgeschlossen.



Das Geschäft mochte es: Es gibt Situationen, in denen etwas lügt, jeder anruft und fragt, was passiert. So kann eine Person das Telefon nehmen, den Befehl „Vorfälle“ auswählen und die neuesten Vorfälle lesen. Die Leute begannen, Vorfälle detaillierter durchzuführen, damit niemand anrief oder nach ihnen fragte.

Dann begannen wir, zusätzliche Funktionen zu schreiben, um Informationen zu erhalten, die früher Abfragen in Jira waren. Das Unternehmen möchte wissen, ob die Übertragung abgeschlossen wurde: Geben Sie eine Nummer ein und erhalten Sie das Ergebnis. Dies erleichterte auch das Leben in Bezug auf Anwendungen erheblich.

Artyom:Gleichzeitig haben wir innerhalb der Abteilung von Sergey eine weitere organisatorische Transformation vorgenommen, die jedoch bereits lokal ist. Dann waren wir sehr infiziert mit der Idee eines Bereitschaftsingenieurs, und dank Sergey konnten wir dieses Schema in der Abteilung aufbauen. Es gibt einen sitzenden Ingenieur für Vorfälle, es gibt einen sitzenden Ingenieur für Anwendungen, alle anderen zerstören die Schakale und sind mit ihren Schüssen beschäftigt.

Arbeite mit DEV

Sergey: Was die Einheit zu tun begann: Umlagerungen erschienen, Menschen waren nicht nur mit Schakalen beschäftigt, sondern auch mit anderen Angelegenheiten. Zunächst hatten wir einen Dialog mit der Entwicklung. Wir haben neuen Teams gesagt, was DevOps ist, wie man es richtig kocht, und CM beigebracht.

Wir haben einen langen Weg zurückgelegt, als wir ihnen selbst Rezepte geschrieben haben, dann haben sie gelernt, sie zu bearbeiten und dann selbst zu schreiben. Wir sprechen auch über CI, helfen beim Einrichten der Pipeline und sammeln Pakete. Wir helfen beim Aufbau einer sicheren Entwicklungsumgebung.

Artem: Aus Sicht von CI ist das alles sehr wichtig. Parallel dazu bin ich als Produktberater tätig, leite Projekte und leite Entwicklungsteams. Und hier ist ein sehr interessanter Fall.

In kleinen Teams haben wir die Funktionen des Betriebs, dh Stage und Prod, in derselben Einheit zusammengefasst. Bei diesen kleinen Projekten, kleinen Produkten, Teams und Infrastrukturen erwies sich dies als sehr praktisch. Sie sehen genau, wie Sie die Schlacht rollen werden.

Sergey: Wenn ein Kampfingenieur eine Testumgebung einrichtet, macht er sie eins zu eins und weiß, dass sie später zu ihm kommt und er darunter leiden wird. Dies ist ein wichtiger psychologischer Faktor, der nicht frei sein kann. Es ist besser, alles auf einmal und normal zu tun.



Was ist daraus geworden? Hier sagen viele, dass es keine DevOps-Abteilung gibt, wir glauben, dass wir eine DevOps-Abteilung haben. Was sind die Hauptaufgaben der Abteilung?

Er geht, fördert, spricht über DevOps. Jeder versteht, was es ist und wie man es kocht. Sie erzählen und zeigen, wie ein neues Produkt mit einer Datenbank in fünf Minuten eingeführt werden kann.

Unsere einzige Einschränkung ist die Sicherheit und die Koordinierung der Systeme. Wenn wir eine virtuelle Maschine haben und die Schemata vereinbart sind, dauert alles fünf Minuten. Alles rollt komplett automatisch.

Artem: Als ich im August ein neues Produkt im Kampf auf den Markt brachte, das heißt ein völlig neues, haben wir 15 bis 20 Releases pro Tag ohne Konflikte und Spannungen herausgebracht. Hier gibt es einen Sinn für Wert: Es ist cool, wenn Sie sich ruhig niedergelassen haben und zum nächsten gehen.



Sergey:Ich werde über Schmerzen sprechen. Wir unterstützen den DRP-Wiederherstellungsplan von Grund auf neu. Und wenn es keine Automatisierung gab, haben wir dort fast Konfigurationen kopiert. Es wurden ständig neue Module hinzugefügt, und der Plan muss ständig aktualisiert werden. Mit dem Aufkommen von DevOps und der Automatisierung schrumpfte der Plan: Wir nehmen die neueste aktuelle Version von Git und fügen Pläne hinzu.

Dieser Bereitstellungsplan wird ehrlich. Dies wird unter anderem durch Testbereitstellungsläufe unterstützt. Wir machen Testläufe und bei einem Kampflauf laufen wir mit dem Wechsel in die Reserve. Die ganze Routinegeschichte ist weg. Dies hat uns übrigens geholfen, den Stapel ein wenig zu bewegen.

Früher verwendeten wir SPARC Solaris, jetzt erschien x86 aus einem einfachen Grund: Heute schreibt oder testet niemand Hipster-Anwendungen für Sparc. Und wir verwenden zum Beispiel Haproxy, zusammen mit den Entwicklern, die wir Fehlerbehebungen für Solaris gesehen haben. Es hat uns gestört, ich wollte es nicht mehr ertragen. Wir haben eine Plattform ausgewählt, auf der jeder Produkte testet, und jetzt arbeiten wir normal daran. Dies hat uns auch dazu bewegt, den gesamten Prozess zu beschleunigen.

Artem: Dies öffnete im Allgemeinen das Tor zu einer neuen Welt voller Wunder. Denn mit dem Aufkommen von x86 konnten wir wirklich relevante und nützliche Dienstprogramme für unsere Aufgaben verwenden. Als wir diese Gelegenheit bekamen, gingen wir gleichzeitig zum Clustering über.

Tatsächlich ist jetzt alles außer der zentralen und nuklearen Verarbeitung gebündelt und funktioniert gut mit uns. Wir machen uns keine Sorgen: Entweder gibt es keine Ausfallzeiten oder es dauert maximal eine Minute, selbst wenn kein Cluster vorhanden ist.

Der einzige Ort, an dem er blieb und der mindestens zwei Stunden alt war, war die Migration zentraler Verarbeitungssysteme. Jetzt dauert es acht Minuten.



Sergey: Auf der Folie befindet sich ein neues Dokument, eine einzeilige Anwendung: In Git zusammenführen. Es gibt diese zehn A4-Blätter nicht mehr.

Die Bereitstellung neuer Module dauert bis zu drei Stunden. Dies sind einige schwierige Fälle, in denen Sie in Oracle etwas tun müssen, z. B. eine virtuelle Maschine. Offsets verschwanden. Ich kann mich nicht erinnern, dass jemand etwas falsch gemacht hat. Natürlich gibt es einige Rauheiten, aber sie sind alle klein, leichtfertig und sehr schnell korrigiert.



Was hat uns zum Erfolg verholfen? Erstens haben wir hier und jetzt keine Revolution begonnen. Ich habe nicht gesagt: "Wir müssen DevOps in drei Wochen implementieren." Wir gingen methodisch an diesen Prozess heran, machten lange Kampagnen, sagten den Menschen, tropften uns ins Gehirn und sprachen über die Ziele, die wir erreichen.

Artem: Ich habe Fragen der Behörden abgewehrt: "Artem, wann ist DevOps?" Er sagte, dass es keine Frist geben wird, wir versuchen es in Prod, fragen nichts.

Sergey:Andererseits ist auch alles sehr cool. Wir haben nicht allen Einheiten die von uns verwendeten Technologien auferlegt. Das Unternehmen ist groß, die Nachbarn sehen aus und sagen: "Ja, großartig, aber wir werden alle sechs Monate eingesetzt." Sie brauchen es nicht. Wir gehen nicht, sagen nicht, dass wir die einzig richtige Entscheidung haben. Irgendwo wollen wir unseren Stack nicht verwenden, für sie haben wir einfache Bash-Skripte zusammengestellt, die die Integration mit anderen Befehlen ermöglichen.

Artem: Hier bin ich überzeugt, dass die Spitze nicht gezwungen werden kann, DevOps zu implementieren. Dies ist für ein solches Projekt unrealistisch.



Sergey: Wir haben analysiert, wo wir die meiste Zeit verlieren: Heute verlieren wir die meiste Zeit für Sicherheit.

Wir wissen, wie man schnell arbeitet, schnell bereitstellt, aber wir vereinbaren ein Bereitstellungsschema - das ist eine Art Hölle. Jetzt haben wir es uns angesehen, es erinnert an dasselbe, als es völlig unterschiedliche Abteilungen von Dev und Ops gab. Jetzt haben wir keinen Plan mehr und überlegen, wie wir Sicherheit in unseren Prozess einbeziehen können, damit sie die Änderungen analysieren können.

Artem: Sie können beispielsweise Merge verwenden, um zu sehen, was sich im Rezept geändert hat. Der Wachmann ist auch Ingenieur.

Sergey:Oft bieten unsere formalen Prozesse keine echte Sicherheit. Wenn wir ein Audit durchführen, verstehen wir, dass alle Verfahren bestanden wurden, wir jedoch nicht das gewünschte Sicherheitsniveau erhalten haben und viel Zeit und Ressourcen aufgewendet wurden. Wir finden ständig einige Probleme, die aufgrund der schlechten Integration von Sicherheitsprozessen und CI / CD aufgetreten sind.

Aus Sicht von OPS haben wir immer noch das Problem, Zeit mit CI zu verschwenden und Rezepte anzupassen. Dieses Ding fängt bereits an, "Schakale" zu gewinnen. Daher schauen wir uns Systeme an, um Frameworks für Entwickler zu präsentieren, und schauen auf Docker, Kubernetes, damit wir schreiben können: "Leute, es gibt Tools, es gibt keine großen Dokumente, Sie können den Bereitstellungsprozess vereinheitlichen."

Wir wollen diese Idee vorantreiben, aber die Sicherheit wehrt sich erneut. Sie sagen: "Welche Art von virtuellen Netzwerken haben Sie, wie werden diese Dienste ohne Firewall funktionieren?" Es gibt einige Widersprüche, aber ich denke, wir werden trotzdem gewinnen.

Artem: Ich habe meinen eigenen Schmerz, ich würde ihn gerne beenden. Wir haben ein sehr großes Problem: Wir sind ein Unternehmen, und wir sind nicht das einzige Unternehmen dieser Art. Es gibt Vertreter, die sich in derselben Situation befinden. Wir stehen unter ständiger Kontrolle der Aufsichtsbehörde, die Zentralbank führt ständig eine Prüfung durch. Wir durchlaufen eine Prüfung, eine scheinbar unabhängige Prüfung.

Es ist schwierig, dem Prüfer die Schuld zu geben. Er arbeitet auf der Grundlage von Standards, die besagen, dass die physische Hardware eine separate, nicht virtuelle Maschine sein sollte. Keine Container.

Derzeit hat kein einziger internationaler Standard ein Jota in Richtung neuer Technologien bewegt. Es gibt ein schwarzes Loch. Sie bemerken nicht, dass dies ein großes Problem ist. Ich kann den Auditoren keine Vorwürfe machen, sie führen Audits nach Standards durch. Sie können dem nirgendwo etwas abnehmen, aber kein einziger Standard versucht in diesem Sinne, sich zu ändern, sich irgendwo zu verwandeln und sich zu bewegen.

Ich muss herausfinden, wie ich mit diesen schrecklichen Worten ein Bild von der Existenz des Unternehmens machen kann, damit alles korrekt und ehrlich ist.

Wenn Sie es satt haben, lange zu lesen, empfehlen wir Ihnen, die Veröffentlichung des Podcasts „Five Minute PHP“ mit unseren Freunden Baruch Sadogursky und Vyacheslav Kuznetsov anzuhören. Trends DevOps, DecSecOps, Kubernetes Sieg und State of DevOps 2018 Bericht von DORA.

Und wenn Sie mehr coole Berichte wünschen, kommen Sie zur DevOops 2018-Konferenz. Es wird Baruch und Glory und sogar John Willis geben ! Alle Sprecher und das Programm sind auf der Website .

Ein schöner Bonus: Bis zum 1. Oktober kann ein Ticket für DevOops 2018 mit einem Rabatt gebucht werden .