HighLoad++, Evgeniy Kuzovlev (EcommPay IT): Was tun, wenn eine Minute Ausfallzeit 100000 US-Dollar kostet?

Alle reden von den Prozessen der Entwicklung und des Testens, der Schulung des Personals und der Steigerung der Motivation, aber diese Prozesse reichen nicht aus, wenn eine Minute Serviceausfall enorme Geldsummen kostet. Was ist zu tun, wenn Sie Finanztransaktionen unter einem strengen SLA durchführen? Wie können Sie die Zuverlässigkeit und Fehlertoleranz Ihrer Systeme erhöhen, indem Sie Entwicklung und Tests aus der Gleichung eliminieren?

Die nächste HighLoad++-Konferenz findet am 6. und 7. April 2020 in St. Petersburg statt. Details und Tickets für Link. 9. November, 18:00 Uhr. HighLoad++ Moskau 2018, Delhi + Kolkata-Halle. Thesen und Präsentation.

Evgeniy Kuzovlev (im Folgenden: EC): - Freunde, hallo! Mein Name ist Kuzovlev Evgeniy. Ich komme von der Firma EcommPay, eine spezielle Abteilung ist EcommPay IT, die IT-Abteilung der Unternehmensgruppe. Und heute sprechen wir über Ausfallzeiten – darüber, wie man sie vermeidet, wie man ihre Folgen minimiert, wenn sie sich nicht vermeiden lassen. Das Thema lautet wie folgt: „Was tun, wenn eine Minute Ausfallzeit 100 US-Dollar kostet“? Mit Blick auf die Zukunft sind unsere Zahlen vergleichbar.

Was macht EcommPay IT?

Wer sind wir? Warum stehe ich hier vor dir? Warum habe ich das Recht, Ihnen hier etwas zu sagen? Und worüber werden wir hier ausführlicher sprechen?

Die EcommPay-Unternehmensgruppe ist ein internationaler Acquirer. Wir wickeln Zahlungen auf der ganzen Welt ab – in Russland, Europa, Südostasien (All Around the World). Wir haben 9 Niederlassungen, insgesamt 500 Mitarbeiter, davon sind etwa etwas weniger als die Hälfte IT-Spezialisten. Alles, was wir tun, alles, womit wir Geld verdienen, haben wir selbst gemacht.

Wir haben alle unsere Produkte (und wir haben ziemlich viele davon – in unserer Reihe großer IT-Produkte haben wir etwa 16 verschiedene Komponenten) selbst geschrieben; Wir schreiben uns selbst, wir entwickeln uns selbst. Und im Moment führen wir etwa eine Million Transaktionen pro Tag durch (Millionen ist wahrscheinlich die richtige Formulierung). Wir sind ein recht junges Unternehmen – wir sind erst etwa sechs Jahre alt.

Vor 6 Jahren war es so ein Startup, als die Jungs mit dem Unternehmen kamen. Sie waren durch eine Idee vereint (es gab nichts anderes als eine Idee), und wir rannten los. Wie jedes Startup waren wir schneller... Für uns war Geschwindigkeit wichtiger als Qualität.

Irgendwann haben wir aufgehört: Wir haben gemerkt, dass wir in dieser Geschwindigkeit und mit dieser Qualität irgendwie nicht mehr leben können und dass wir uns zuerst auf die Qualität konzentrieren müssen. In diesem Moment beschlossen wir, eine neue Plattform zu schreiben, die korrekt, skalierbar und zuverlässig ist. Sie begannen mit dem Schreiben dieser Plattform (sie begannen zu investieren, zu entwickeln, zu testen), aber irgendwann wurde ihnen klar, dass Entwicklung und Tests es uns nicht ermöglichten, ein neues Niveau der Servicequalität zu erreichen.

Sie stellen ein neues Produkt her, nehmen es in Produktion, aber trotzdem geht irgendwo etwas schief. Und heute werden wir darüber sprechen, wie wir ein neues Qualitätsniveau erreichen können (wie wir es geschafft haben, über unsere Erfahrungen), indem wir Entwicklung und Tests außer Acht lassen; Wir werden darüber sprechen, was dem Betrieb zur Verfügung steht – was der Betrieb selbst leisten kann, was er dem Testen bieten kann, um die Qualität zu beeinflussen.

Ausfallzeiten. Handlungsbefehle.

Der wichtigste Grundpfeiler, über den wir heute sprechen werden, sind Ausfallzeiten. Ein schreckliches Wort. Wenn wir Ausfallzeiten haben, ist alles schlecht für uns. Wir rennen los, um ihn zu erhöhen, die Admins halten den Server fest – Gott bewahre, dass er nicht zusammenbricht, wie es in diesem Lied heißt. Darüber werden wir heute sprechen.

Als wir begannen, unsere Herangehensweise zu ändern, bildeten wir vier Gebote. Ich habe sie auf den Folien dargestellt:

Diese Gebote sind ganz einfach:

• Identifizieren Sie schnell das Problem.
• Werden Sie es noch schneller los.
• Helfen Sie dabei, den Grund zu verstehen (später für Entwickler).
• Und Ansätze standardisieren.

Ich möchte Sie auf Punkt Nr. 2 aufmerksam machen: Wir beseitigen das Problem, nicht lösen es. Entscheiden ist zweitrangig. Für uns geht es in erster Linie darum, dass der Nutzer vor diesem Problem geschützt ist. Es wird in einer isolierten Umgebung existieren, aber diese Umgebung wird keinen Kontakt damit haben. Eigentlich werden wir diese vier Problemgruppen durchgehen (einige detaillierter, andere weniger detailliert). Ich werde Ihnen sagen, was wir verwenden und welche relevanten Erfahrungen wir mit Lösungen haben.

Fehlerbehebung: Wann treten sie auf und was kann man dagegen tun?

Aber wir beginnen nicht in der richtigen Reihenfolge, wir beginnen mit Punkt Nr. 2 – wie kann man das Problem schnell beseitigen? Es gibt ein Problem – wir müssen es beheben. „Was sollen wir dagegen tun?“ - die Hauptfrage. Und als wir anfingen, darüber nachzudenken, wie wir das Problem beheben könnten, stellten wir für uns selbst einige Anforderungen fest, die bei der Fehlerbehebung beachtet werden müssen.

Um diese Anforderungen zu formulieren, haben wir uns entschieden, uns die Frage zu stellen: „Wann haben wir Probleme?“ Und wie sich herausstellte, treten in vier Fällen Probleme auf:

• Hardwarefehler.
• Externe Dienste sind fehlgeschlagen.
• Ändern der Softwareversion (gleiche Bereitstellung).
• Explosiver Lastanstieg.

Über die ersten beiden werden wir nicht sprechen. Eine Hardwarestörung kann ganz einfach behoben werden: Sie müssen alles duplizieren. Wenn es sich um Festplatten handelt, müssen die Festplatten im RAID zusammengestellt werden; wenn es sich um einen Server handelt, muss der Server dupliziert werden; wenn Sie über eine Netzwerkinfrastruktur verfügen, müssen Sie eine zweite Kopie der Netzwerkinfrastruktur bereitstellen, das heißt, Sie nehmen sie und dupliziere es. Und wenn mal etwas ausfällt, schalten Sie auf Reserveleistung um. Mehr kann man hier kaum sagen.

Der zweite Grund ist das Versagen externer Dienste. Für die meisten ist das System überhaupt kein Problem, für uns jedoch nicht. Da wir Zahlungen abwickeln, sind wir ein Aggregator, der zwischen dem Benutzer (der seine Kartendaten eingibt) und Banken, Zahlungssystemen (Visa, MasterCard, Mira usw.) steht. Unsere externen Dienste (Zahlungssysteme, Banken) neigen dazu, auszufallen. Weder wir noch Sie (sofern Sie über solche Dienste verfügen) können hierauf Einfluss nehmen.

Was ist dann zu tun? Hier gibt es zwei Möglichkeiten. Erstens sollten Sie diesen Dienst, wenn möglich, auf irgendeine Weise duplizieren. Wenn wir zum Beispiel können, übertragen wir den Verkehr von einem Dienst auf einen anderen: Beispielsweise wurden Karten über die Sberbank abgewickelt, die Sberbank hat Probleme – wir übertragen den Verkehr [bedingt] an Raiffeisen. Das zweite, was wir tun können, ist, den Ausfall externer Dienste sehr schnell zu bemerken. Deshalb werden wir im nächsten Teil des Berichts über die Reaktionsgeschwindigkeit sprechen.

Tatsächlich können wir von diesen vieren gezielt Einfluss auf die Änderung der Softwareversionen nehmen – indem wir Maßnahmen ergreifen, die zu einer Verbesserung der Situation im Kontext von Bereitstellungen und im Kontext eines explosionsartigen Anstiegs der Last führen. Genau das haben wir getan. Hier nochmal eine kleine Anmerkung...

Einige dieser vier Probleme werden sofort gelöst, wenn Sie über eine Cloud verfügen. Wenn Sie sich in den Clouds Microsoft Azhur, Ozone befinden oder unsere Clouds von Yandex oder Mail nutzen, dann wird zumindest eine Hardwarestörung zu ihrem Problem und im Zusammenhang mit einer Hardwarestörung wird für Sie sofort alles in Ordnung.

Wir sind ein etwas unkonventionelles Unternehmen. Hier reden alle über „Kubernets“, über Clouds – wir haben weder „Kubernets“ noch Clouds. Aber wir haben in vielen Rechenzentren Hardware-Racks, und wir sind gezwungen, von dieser Hardware zu leben, wir sind gezwungen, für alles verantwortlich zu sein. Deshalb werden wir in diesem Zusammenhang sprechen. Also zu den Problemen. Die ersten beiden wurden aus Klammern herausgenommen.

Ändern der Softwareversion. Basen

Unsere Entwickler haben keinen Zugriff auf die Produktion. Warum so? Es ist nur so, dass wir PCI DSS-zertifiziert sind und unsere Entwickler einfach nicht das Recht haben, in das „Produkt“ einzusteigen. Das ist es, Punkt. Überhaupt. Daher endet die Entwicklungsverantwortung genau in dem Moment, in dem die Entwicklung den Build zur Veröffentlichung einreicht.

Unsere zweite Grundlage, die uns ebenfalls sehr hilft, ist das Fehlen von einzigartigem, undokumentiertem Wissen. Ich hoffe, dass es bei dir genauso ist. Denn wenn dies nicht der Fall ist, werden Sie Probleme haben. Probleme entstehen, wenn dieses einzigartige, undokumentierte Wissen nicht zur richtigen Zeit am richtigen Ort vorhanden ist. Nehmen wir an, Sie haben eine Person, die weiß, wie eine bestimmte Komponente eingesetzt wird – die Person ist nicht da, sie ist im Urlaub oder krank – das war’s, Sie haben Probleme.

Und die dritte Grundlage, zu der wir gekommen sind. Wir sind durch Schmerz, Blut und Tränen dazu gekommen – wir kamen zu dem Schluss, dass jeder unserer Builds Fehler enthält, auch wenn er fehlerfrei ist. Wir haben das selbst entschieden: Wenn wir etwas bereitstellen, wenn wir etwas in die Produktion bringen, haben wir einen Build mit Fehlern. Wir haben die Anforderungen formuliert, die unser System erfüllen muss.

Voraussetzungen für den Wechsel der Softwareversion

Es gibt drei Anforderungen:

• Wir müssen den Einsatz schnell zurückfahren.
• Wir müssen die Auswirkungen einer erfolglosen Bereitstellung minimieren.
• Und wir müssen in der Lage sein, schnell parallel zu implementieren.
  Genau in dieser Reihenfolge! Warum? Denn erstens kommt es bei der Bereitstellung einer neuen Version nicht auf die Geschwindigkeit an, sondern es ist wichtig, dass Sie, falls etwas schiefgeht, schnell ein Rollback durchführen können und die Auswirkungen minimal sind. Wenn Sie jedoch eine Reihe von Versionen in der Produktion haben, bei denen sich herausstellt, dass ein Fehler vorliegt (aus heiterem Himmel gab es keine Bereitstellung, aber es liegt ein Fehler vor), ist die Geschwindigkeit der nachfolgenden Bereitstellung für Sie wichtig. Was haben wir getan, um diesen Anforderungen gerecht zu werden? Wir haben auf die folgende Methodik zurückgegriffen:

  
  
  Es ist ziemlich bekannt, wir haben es nie erfunden – das ist die Blau/Grün-Einführung. Was ist das? Sie benötigen eine Kopie für jede Servergruppe, auf der Ihre Anwendungen installiert sind. Die Kopie ist „warm“: Es gibt keinen Datenverkehr darauf, aber dieser Datenverkehr kann jederzeit an diese Kopie gesendet werden. Diese Kopie enthält die vorherige Version. Und zum Zeitpunkt der Bereitstellung führen Sie den Code in einer inaktiven Kopie aus. Anschließend stellen Sie einen Teil des Datenverkehrs (oder den gesamten) auf die neue Version um. Um den Verkehrsfluss von der alten zur neuen Version zu ändern, müssen Sie also nur eine Aktion ausführen: Sie müssen den Balancer im Upstream ändern und die Richtung ändern – von einem Upstream zum anderen. Dies ist sehr praktisch und löst das Problem des schnellen Umschaltens und schnellen Zurücksetzens.

  Hier ist die Lösung der zweiten Frage die Minimierung: Sie können nur einen Teil Ihres Datenverkehrs an eine neue Leitung senden, an eine Leitung mit einem neuen Code (z. B. 2 %). Und diese 2 % sind nicht 100 %! Wenn Sie aufgrund einer erfolglosen Bereitstellung 100 % Ihres Datenverkehrs verloren haben, ist das beängstigend; wenn Sie 2 % Ihres Datenverkehrs verloren haben, ist das unangenehm, aber nicht beängstigend. Darüber hinaus werden Benutzer dies höchstwahrscheinlich nicht einmal bemerken, da in einigen Fällen (nicht in allen Fällen) derselbe Benutzer durch Drücken von F5 zu einer anderen, funktionierenden Version weitergeleitet wird.

  Blau/Grün bereitstellen. Routenführung

  Allerdings ist nicht alles so einfach „Blau/Grün bereitstellen“... Alle unsere Komponenten lassen sich in drei Gruppen einteilen:

  • Dies ist das Frontend (Zahlungsseiten, die unsere Kunden sehen);
  • Verarbeitungskern;
  • Adapter für die Arbeit mit Zahlungssystemen (Banken, MasterCard, Visa...).

  Und hier gibt es eine Nuance – die Nuance liegt in der Führung zwischen den Zeilen. Wenn Sie einfach 100 % des Datenverkehrs wechseln, treten diese Probleme nicht auf. Wenn Sie jedoch 2 % wechseln möchten, stellen Sie sich Fragen: „Wie geht das?“ Das Einfachste ist ganz einfach: Sie können Round Robin in Nginx per Zufallsauswahl einrichten, und Sie haben 2 % links und 98 % rechts. Dies ist jedoch nicht immer geeignet.

  In unserem Fall interagiert ein Benutzer beispielsweise mit mehr als einer Anfrage mit dem System. Das ist normal: 2, 3, 4, 5 Anfragen – Ihre Systeme können gleich sein. Und wenn es für Sie wichtig ist, dass alle Anfragen des Benutzers in derselben Zeile ankommen, in der die erste Anfrage kam, oder (zweiter Punkt) alle Anfragen des Benutzers in der neuen Zeile nach dem Wechsel eingehen (er hätte früher mit der Arbeit beginnen können). System, vor der Umstellung), - dann ist diese Zufallsverteilung nicht für Sie geeignet. Dann gibt es folgende Möglichkeiten:

  
  
  Die erste Option, die einfachste, basiert auf den Grundparametern des Clients (IP-Hash). Sie haben eine IP und teilen diese von rechts nach links durch die IP-Adresse auf. Dann funktioniert der zweite Fall, den ich beschrieben habe, für Sie: Als die Bereitstellung erfolgte, konnte der Benutzer bereits mit der Arbeit mit Ihrem System beginnen, und ab dem Zeitpunkt der Bereitstellung werden alle Anfragen in eine neue Zeile (z. B. in dieselbe) verschoben.

  Wenn Ihnen dies aus irgendeinem Grund nicht zusagt und Sie Anfragen an die Leitung senden müssen, bei der die ursprüngliche Anfrage des Benutzers eingegangen ist, haben Sie zwei Möglichkeiten ...
  Erste Option: Sie können kostenpflichtiges Nginx+ kaufen. Es gibt einen Sticky-Sessions-Mechanismus, der auf die erste Anfrage des Benutzers dem Benutzer eine Sitzung zuweist und diese an den einen oder anderen Upstream bindet. Alle nachfolgenden Benutzeranfragen innerhalb der Sitzungsdauer werden an denselben Upstream gesendet, an dem die Sitzung gepostet wurde.

  Das passte nicht zu uns, da wir bereits reguläres Nginx hatten. Die Umstellung auf Nginx+ bedeutet nicht, dass sie teuer wäre, sie war nur etwas schmerzhaft für uns und nicht ganz richtig. „Sticks Sessions“ beispielsweise funktionierten bei uns nicht, aus dem einfachen Grund, dass „Sticks Sessions“ kein Routing nach „Entweder-Oder“ erlauben. Dort können Sie angeben, was wir „Sticks Sessions“ tun, zum Beispiel per IP-Adresse oder per IP-Adresse und Cookies oder per Postparameter, aber „Entweder-oder“ ist dort komplizierter.

  Deshalb kamen wir zur vierten Option. Wir haben Nginx auf Steroiden genommen (das ist Openresty) – das ist das gleiche Nginx, das zusätzlich die Einbindung letzter Skripte unterstützt. Sie können ein letztes Skript schreiben, ihm eine „offene Pause“ geben und dieses letzte Skript wird ausgeführt, wenn die Benutzeranforderung eingeht.

  Und wir haben tatsächlich ein solches Skript geschrieben, uns „openresti“ gesetzt und in diesem Skript 6 verschiedene Parameter durch die Verkettung „Oder“ sortiert. Abhängig vom Vorhandensein des einen oder anderen Parameters wissen wir, dass der Benutzer auf die eine oder andere Seite, die eine oder andere Zeile gelangt ist.

  Blau/Grün bereitstellen. Vorteile und Nachteile

  Natürlich wäre es wahrscheinlich möglich, es etwas einfacher zu machen (die gleichen „Sticky Sessions“ zu verwenden), aber wir haben auch eine solche Nuance, dass nicht nur der Benutzer im Rahmen einer Verarbeitung einer Transaktion mit uns interagiert ... Aber auch Zahlungssysteme interagieren mit uns: Nachdem wir die Transaktion verarbeitet haben (indem wir eine Anfrage an das Zahlungssystem senden), erhalten wir ein Coolback.
  Und sagen wir mal, wenn wir innerhalb unseres Schaltkreises die IP-Adresse des Benutzers in allen Anfragen weiterleiten und die Benutzer anhand der IP-Adresse aufteilen können, dann werden wir nicht dasselbe „Visa“ sagen: „Alter, wir scheinen so ein Retro-Unternehmen zu sein.“ um international zu sein (auf der Website und in Russland)... Bitte geben Sie uns in einem zusätzlichen Feld die IP-Adresse des Nutzers an, Ihr Protokoll ist standardisiert“! Es ist klar, dass sie nicht zustimmen werden.

  
  
  Deshalb hat das bei uns nicht funktioniert – wir haben openresty gemacht. Dementsprechend haben wir beim Routing etwa Folgendes erhalten:

  Blue/Green Deployment hat dementsprechend die von mir genannten Vorteile und Nachteile.

  Zwei Nachteile:

  • Sie müssen sich um das Routing kümmern;
  • Der zweite Hauptnachteil sind die Kosten.

  Sie benötigen doppelt so viele Server, Sie benötigen doppelt so viele Betriebsressourcen, Sie müssen doppelt so viel Aufwand betreiben, um diesen gesamten Zoo zu unterhalten.

  Zu den Vorteilen gehört übrigens noch ein weiterer Vorteil, den ich bisher noch nicht erwähnt habe: Sie haben eine Reserve für den Fall eines Lastwachstums. Wenn die Auslastung explosionsartig ansteigt, Sie eine große Anzahl von Benutzern haben, fügen Sie einfach die zweite Zeile in die 50-zu-50-Verteilung ein – und Sie haben sofort x2-Server in Ihrem Cluster, bis Sie das Problem gelöst haben, mehr Server zu haben.

  Wie erfolgt eine schnelle Bereitstellung?

  Wir haben darüber gesprochen, wie das Problem der Minimierung und des schnellen Rollbacks gelöst werden kann, aber die Frage bleibt: „Wie kann man schnell bereitstellen?“

  
  
  Hier ist es kurz und einfach.

  • Sie müssen über ein CD-System (Continuous Delivery) verfügen – ohne können Sie nicht leben. Wenn Sie über einen Server verfügen, können Sie die Bereitstellung manuell durchführen. Wir haben natürlich etwa eineinhalbtausend Server und eineinhalbtausend Handles – wir können eine Abteilung von der Größe dieses Raums einrichten, nur um sie bereitzustellen.
  • Die Bereitstellung muss parallel erfolgen. Wenn Ihre Bereitstellung sequentiell erfolgt, ist alles schlecht. Ein Server ist normal, Sie werden den ganzen Tag über eineinhalbtausend Server bereitstellen.
  • Auch dies ist für die Beschleunigung wahrscheinlich nicht mehr erforderlich. Während der Bereitstellung wird das Projekt normalerweise erstellt. Sie haben ein Webprojekt, es gibt einen Front-End-Teil (Sie erstellen dort ein Webpaket, Sie kompilieren npm – so etwas in der Art), und dieser Prozess ist im Prinzip nur von kurzer Dauer – 5 Minuten, aber diese 5 Minuten können kritisch sein. Deshalb machen wir das zum Beispiel nicht: Wir haben diese 5 Minuten entfernt, wir stellen Artefakte bereit.

    Was ist ein Artefakt? Ein Artefakt ist ein zusammengebauter Bau, bei dem alle Montageteile bereits fertiggestellt sind. Wir speichern dieses Artefakt im Artefaktspeicher. Früher haben wir zwei solcher Speicher verwendet – es war Nexus und jetzt jFrog Artifactory. Wir haben zunächst „Nexus“ verwendet, weil wir begonnen haben, diesen Ansatz in Java-Anwendungen zu praktizieren (er passte gut dazu). Dann fügten sie dort einige der in PHP geschriebenen Anwendungen ein; und „Nexus“ war nicht mehr geeignet, und deshalb haben wir uns für jFrog Artefactory entschieden, das fast alles artefaktisieren kann. Wir sind sogar so weit gekommen, dass wir in diesem Artefakt-Repository unsere eigenen Binärpakete speichern, die wir für Server sammeln.

  Explosiver Lastanstieg

  Wir haben darüber gesprochen, die Softwareversion zu ändern. Das nächste, was wir erleben, ist ein explosionsartiger Anstieg der Belastung. Hier meine ich wahrscheinlich mit explosionsartigem Wachstum der Ladung nicht ganz das Richtige ...

  Wir haben ein neues System geschrieben – es ist serviceorientiert, modisch, schön, überall Arbeiter, überall Warteschlangen, überall Asynchronität. Und in solchen Systemen können Daten über unterschiedliche Flüsse fließen. Für die erste Transaktion können der 1., 3., 10. Arbeiter verwendet werden, für die zweite Transaktion der 2., 4., 5. Arbeiter. Und heute, sagen wir mal, haben Sie morgens einen Datenfluss, der die ersten drei Worker nutzt, und am Abend ändert er sich dramatisch, und alles nutzt die anderen drei Worker.

  Und hier stellt sich heraus, dass Sie die Arbeitskräfte irgendwie skalieren müssen, Sie müssen Ihre Dienste irgendwie skalieren, aber gleichzeitig ein Aufblähen der Ressourcen verhindern.

  
  
  Wir haben unsere Anforderungen definiert. Diese Anforderungen sind recht einfach: Serviceerkennung und Parametrisierung – alles ist Standard für den Aufbau solcher skalierbarer Systeme, bis auf einen Punkt – die Ressourcenverschlechterung. Wir sagten, dass wir nicht bereit sind, Ressourcen zu amortisieren, damit die Server die Luft erwärmen. Wir haben „Consul“ genommen, wir haben „Nomad“ genommen, das unsere Arbeiter verwaltet.

  Warum ist das für uns ein Problem? Lassen Sie uns ein wenig zurückgehen. Mittlerweile haben wir rund 70 Zahlungssysteme hinter uns. Am Morgen läuft der Verkehr über die Sberbank, dann ist die Sberbank beispielsweise zusammengebrochen und wir stellen auf ein anderes Zahlungssystem um. Vor der Sberbank hatten wir 100 Mitarbeiter, und danach müssen wir die Zahl der 100 Mitarbeiter für ein anderes Zahlungssystem deutlich erhöhen. Und es ist wünschenswert, dass dies alles ohne menschliche Beteiligung geschieht. Denn wenn es eine menschliche Beteiligung gibt, sollte rund um die Uhr ein Ingenieur da sein, der nur das tun sollte, denn solche Ausfälle, wenn 24 Systeme hinter einem stehen, passieren regelmäßig.

  Deshalb haben wir uns Nomad angesehen, das über eine offene IP verfügt, und unser eigenes Ding geschrieben, Scale-Nomad – ScaleNo, das ungefähr Folgendes tut: Es überwacht das Wachstum der Warteschlange und reduziert oder erhöht die Anzahl der Arbeiter je nach Dynamik der Warteschlange. Als wir es gemacht haben, dachten wir: „Vielleicht können wir es als Open Source veröffentlichen?“ Dann sahen sie sie an – sie war so einfach wie zwei Kopeken.

  Bisher haben wir es noch nicht als Open Source bereitgestellt, aber wenn Sie nach dem Bericht plötzlich feststellen, dass Sie so etwas brauchen, brauchen Sie es, meine Kontakte finden Sie auf der letzten Folie – schreiben Sie mir bitte. Bei mindestens 3-5 Personen übernehmen wir die Patenschaft.

  
  
  Wie es funktioniert? Werfen wir einen Blick darauf! Blick in die Zukunft: Auf der linken Seite befindet sich ein Teil unserer Überwachung: Dies ist eine Zeile, oben ist die Zeit der Ereignisverarbeitung, in der Mitte die Anzahl der Transaktionen und unten die Anzahl der Arbeiter.

  Wenn Sie hinschauen, gibt es in diesem Bild einen Fehler. Auf dem oberen Chart stürzte einer der Charts innerhalb von 45 Sekunden ab – eines der Zahlungssysteme fiel aus. Der Verkehr wurde sofort innerhalb von 2 Minuten aufgenommen und die Warteschlange auf einem anderen Zahlungssystem, in dem es keine Mitarbeiter gab, begann zu wachsen (wir haben keine Ressourcen genutzt – im Gegenteil, wir haben die Ressource korrekt entsorgt). Wir wollten nicht heizen – es gab eine minimale Anzahl, etwa 5-10 Arbeiter, aber sie kamen nicht zurecht.

  Die letzte Grafik zeigt einen „Buckel“, was lediglich bedeutet, dass „Skaleno“ diesen Betrag verdoppelt hat. Und als die Grafik dann etwas abfiel, reduzierte er sie ein wenig – die Anzahl der Arbeiter wurde automatisch geändert. So funktioniert dieses Ding. Wir haben über Punkt Nummer 2 gesprochen – „Wie man Gründe schnell beseitigt.“

  Überwachung. Wie erkennt man das Problem schnell?

  Der erste Punkt lautet nun: „Wie erkennt man das Problem schnell?“ Überwachung! Wir müssen bestimmte Dinge schnell verstehen. Welche Dinge sollten wir schnell verstehen?

  
  
  Drei Dinge!

  • Wir müssen die Leistung unserer eigenen Ressourcen schnell verstehen und begreifen.
  • Wir müssen Fehler schnell erkennen und die Leistung von Systemen überwachen, die außerhalb unserer Reichweite liegen.
  • Der dritte Punkt ist die Identifizierung logischer Fehler. Dies ist der Fall, wenn das System für Sie arbeitet, nach allen Indikatoren ist alles normal, aber etwas geht schief.

  Ich werde dir hier wahrscheinlich nichts so Cooles erzählen. Ich werde Captain Obvious sein. Wir suchten nach dem, was es auf dem Markt gab. Wir haben einen „Spaßzoo“. Das ist die Art von Zoo, die wir jetzt haben:

  
  
  Wir verwenden Zabbix zur Überwachung der Hardware und zur Überwachung der Hauptindikatoren von Servern. Wir verwenden Okmeter für Datenbanken. Für alle anderen Indikatoren, die nicht zu den ersten beiden passen, verwenden wir „Grafana“ und „Prometheus“, teilweise mit „Grafana“ und „Prometheus“, teilweise mit „Grafana“ mit „Influx“ und Telegraf.

  Vor einem Jahr wollten wir New Relic nutzen. Coole Sache, es kann alles. Aber so sehr sie alles kann, ist sie so teuer. Als wir auf ein Volumen von 1,5 Tausend Servern angewachsen waren, kam ein Anbieter zu uns und sagte: „Lass uns einen Vertrag für nächstes Jahr abschließen.“ Wir haben uns den Preis angeschaut und gesagt: Nein, das machen wir nicht. Jetzt geben wir New Relic auf, wir haben noch etwa 15 Server unter der Überwachung von New Relic. Der Preis erwies sich als absolut wild.

  Und es gibt ein Tool, das wir selbst implementiert haben – das ist Debugger. Zuerst nannten wir es „Bagger“, aber dann kam ein Englischlehrer vorbei, lachte wild und benannte es in „Debagger“ um. Was ist das? Hierbei handelt es sich um ein Tool, das tatsächlich in 15 bis 30 Sekunden an jeder Komponente, wie einer „Black Box“ des Systems, Tests zur Gesamtleistung der Komponente durchführt.

  Gibt es beispielsweise eine externe Seite (Zahlungsseite), öffnet er diese einfach und schaut sich an, wie sie aussehen soll. Wenn dies in Bearbeitung ist, sendet er eine Test-„Transaktion“ und stellt sicher, dass diese „Transaktion“ ankommt. Sollte es sich um einen Zusammenhang mit Zahlungssystemen handeln, lösen wir ggf. eine entsprechende Testanfrage aus und prüfen, ob bei uns alles in Ordnung ist.

  Welche Indikatoren sind für das Monitoring wichtig?

  Was überwachen wir hauptsächlich? Welche Indikatoren sind für uns wichtig?

  
  

  • Die Reaktionszeit/RPS an den Fronten ist ein sehr wichtiger Indikator. Er antwortet sofort, dass mit dir etwas nicht stimmt.
  • Die Anzahl der verarbeiteten Nachrichten in allen Warteschlangen.
  • Anzahl der Arbeiter.
  • Grundlegende Korrektheitsmetriken.

  Der letzte Punkt ist „Geschäft“, die Metrik „Geschäft“. Wenn Sie dasselbe überwachen möchten, müssen Sie ein oder zwei Metriken definieren, die für Sie die Hauptindikatoren sind. Unsere Kennzahl ist der Durchsatz (das ist das Verhältnis der Anzahl erfolgreicher Transaktionen zum gesamten Transaktionsfluss). Wenn sich darin im Abstand von 5-10-15 Minuten etwas ändert, bedeutet das, dass wir Probleme haben (wenn es sich radikal ändert).

  Wie es bei uns aussieht, ist ein Beispiel für eines unserer Boards:

  
  
  Auf der linken Seite befinden sich 6 Diagramme, die sich auf die Zeilen beziehen – die Anzahl der Arbeiter und die Anzahl der Nachrichten in den Warteschlangen. Auf der rechten Seite - RPS, RTS. Nachfolgend finden Sie die gleiche „Geschäfts“-Kennzahl. Und in der „Geschäfts“-Metrik können wir in den beiden mittleren Diagrammen sofort erkennen, dass etwas schief gelaufen ist … Dies ist nur ein weiteres System, das hinter uns steht und gefallen ist.

  Zweitens mussten wir den Niedergang externer Zahlungssysteme überwachen. Hier haben wir OpenTracing verwendet – einen Mechanismus, einen Standard und ein Paradigma, mit dem Sie verteilte Systeme verfolgen können. und es wurde ein wenig verändert. Das Standard-OpenTracing-Paradigma besagt, dass wir für jede einzelne Anfrage einen Trace erstellen. Wir brauchten das nicht und haben es in einen zusammenfassenden Aggregations-Trace verpackt. Wir haben ein Tool entwickelt, mit dem wir die Geschwindigkeit der Systeme hinter uns verfolgen können.

  
  
  Die Grafik zeigt uns, dass eines der Zahlungssysteme innerhalb von 3 Sekunden zu reagieren begann – wir haben Probleme. Darüber hinaus reagiert dieses Ding in Abständen von 20 bis 30 Sekunden, wenn Probleme auftreten.

  Und die dritte Klasse existierender Überwachungsfehler ist die logische Überwachung.

  Ehrlich gesagt wusste ich nicht, was ich auf dieser Folie zeichnen sollte, da wir schon lange auf dem Markt nach etwas gesucht hatten, das zu uns passen würde. Da wir nichts fanden, mussten wir es selbst machen.

  
  
  Was meine ich mit logischer Überwachung? Nun, stellen Sie sich vor: Sie machen sich ein System (zum Beispiel einen Tinder-Klon); Du hast es gemacht, es gestartet. Der erfolgreiche Manager Vasya Pupkin hat es auf sein Handy geschrieben, sieht dort ein Mädchen, mag sie ... und das Gleiche geht nicht an das Mädchen – das Gleiche geht an den Wachmann Mikhalych aus demselben Geschäftszentrum. Der Manager geht nach unten und fragt sich dann: „Warum lächelt ihn dieser Wachmann Michalytsch so freundlich an?“

  In solchen Situationen... Für uns klingt diese Situation etwas anders, weil (ich schrieb) es sich um einen Reputationsverlust handelt, der indirekt zu finanziellen Verlusten führt. Unsere Situation ist das Gegenteil: Wir können direkte finanzielle Verluste erleiden – zum Beispiel, wenn wir eine Transaktion erfolgreich durchgeführt haben, diese jedoch erfolglos war (oder umgekehrt). Ich musste mein eigenes Tool schreiben, das die Anzahl erfolgreicher Transaktionen im Laufe der Zeit anhand von Geschäftsindikatoren verfolgt. Habe nichts auf dem Markt gefunden! Das ist genau die Idee, die ich vermitteln wollte. Es gibt nichts auf dem Markt, das dieses Problem lösen könnte.

  Hier ging es darum, das Problem schnell zu erkennen.

  So ermitteln Sie die Gründe für den Einsatz

  Die dritte Gruppe von Problemen, die wir lösen, besteht darin, dass es, nachdem wir das Problem identifiziert und beseitigt haben, gut wäre, den Grund für die Entwicklung und das Testen zu verstehen und etwas dagegen zu unternehmen. Dementsprechend müssen wir Nachforschungen anstellen und die Protokolle erhöhen.

  
  
  Wenn wir über Protokolle sprechen (der Hauptgrund sind Protokolle), befindet sich der Großteil unserer Protokolle im ELK-Stack – fast jeder hat das Gleiche. Für einige ist es vielleicht nicht in ELK, aber wenn Sie Protokolle in Gigabyte schreiben, werden Sie früher oder später zu ELK kommen. Wir schreiben sie in Terabyte.

  
  
  Hier liegt ein Problem vor. Wir haben es behoben, den Fehler für den Benutzer korrigiert, angefangen auszugraben, was da war, sind in Kibana geklettert, haben dort die Transaktions-ID eingegeben und ein Fußtuch wie dieses erhalten (zeigt viel). Und in diesem Fußtuch ist absolut nichts klar. Warum? Ja, denn es ist nicht klar, welches Teil zu welchem ​​Arbeiter gehört, welches Teil zu welcher Komponente gehört. Und in diesem Moment wurde uns klar, dass wir Tracing brauchten – dasselbe OpenTracing, von dem ich gesprochen habe.

  Das dachten wir vor einem Jahr, richteten unsere Aufmerksamkeit auf den Markt und dort gab es zwei Tools – „Zipkin“ und „Jaeger“. „Jager“ ist tatsächlich ein solcher ideologischer Erbe, ein ideologischer Nachfolger von „Zipkin“. In Zipkin ist alles gut, außer dass es nicht weiß, wie man aggregiert, es weiß nicht, wie man Protokolle in die Ablaufverfolgung einbezieht, sondern nur die Zeitverfolgung. Und „Jager“ unterstützte dies.

  Wir haben uns „Jager“ angesehen: Man kann Anwendungen instrumentieren, man kann in API schreiben (der damalige API-Standard für PHP war allerdings nicht genehmigt – das war vor einem Jahr, aber jetzt wurde er bereits genehmigt), aber da war absolut kein Kunde. „Okay“, dachten wir und schrieben unserem eigenen Kunden. Was haben wir bekommen? So ungefähr sieht es aus:

  
  
  In Jaeger werden für jede Nachricht Spannen erstellt. Das heißt, wenn ein Benutzer das System öffnet, sieht er für jede eingehende Anfrage einen oder zwei Blöcke (1-2-3 – die Anzahl der eingehenden Anfragen des Benutzers, die Anzahl der Blöcke). Um es den Benutzern einfacher zu machen, haben wir den Protokollen und Zeitspuren Tags hinzugefügt. Dementsprechend markiert unsere Anwendung im Fehlerfall das Protokoll mit dem entsprechenden Fehlertag. Sie können nach Fehlertag filtern und es werden nur Bereiche angezeigt, die diesen Block mit einem Fehler enthalten. So sieht es aus, wenn wir die Spanne erweitern:

  
  
  Innerhalb der Spanne gibt es eine Reihe von Spuren. In diesem Fall handelt es sich um drei Test-Traces und der dritte Trace teilt uns mit, dass ein Fehler aufgetreten ist. Gleichzeitig sehen wir hier eine Zeitspur: Wir haben oben eine Zeitskala und sehen, in welchem ​​Zeitintervall dieses oder jenes Protokoll aufgezeichnet wurde.

  Dementsprechend lief es für uns gut. Wir haben unsere eigene Erweiterung geschrieben und sie als Open Source bereitgestellt. Wenn Sie mit Tracing arbeiten möchten, wenn Sie mit „Jager“ in PHP arbeiten möchten, gibt es unsere Erweiterung, die Sie gerne verwenden können, wie es heißt:

  
  
  Wir haben diese Erweiterung – es ist ein Client für die OpenTracing-API, sie ist als PHP-Erweiterung erstellt, das heißt, Sie müssen sie zusammenbauen und auf dem System installieren. Vor einem Jahr war nichts anders. Jetzt gibt es andere Clients, die wie Komponenten sind. Hier liegt es an Ihnen: Entweder Sie pumpen die Komponenten mit einem Composer aus, oder Sie nutzen die Erweiterung ganz nach Ihren Wünschen.

  Unternehmensstandards

  Wir haben über die drei Gebote gesprochen. Das vierte Gebot besteht darin, Vorgehensweisen zu standardisieren. Um was geht es hierbei? Es geht um Folgendes:

  
  
  Warum steht hier das Wort „Unternehmen“? Nicht weil wir ein großes oder bürokratisches Unternehmen sind, nein! Ich wollte das Wort „Unternehmen“ hier in dem Zusammenhang verwenden, dass jedes Unternehmen, jedes Produkt seine eigenen Standards haben sollte, auch Sie. Welche Standards haben wir?

  
  

  • Bei uns gibt es eine Einsatzordnung. Ohne ihn kommen wir nirgendwo hin, das können wir nicht. Wir stellen etwa 60 Mal pro Woche bereit, also fast ständig. Gleichzeitig haben wir beispielsweise in der Einsatzordnung ein Tabu für Einsätze am Freitag – wir rücken grundsätzlich nicht auf.
  • Wir benötigen eine Dokumentation. Kein einziges neues Bauteil gelangt in Produktion, wenn es dafür keine Dokumentation gibt, selbst wenn es unter der Feder unserer F&E-Spezialisten entstanden ist. Wir benötigen von ihnen Bereitstellungsanweisungen, eine Überwachungskarte und eine grobe Beschreibung (so wie Programmierer schreiben können), wie diese Komponente funktioniert und wie sie behoben werden kann.
  • Wir lösen nicht die Ursache des Problems, sondern das Problem – was ich bereits gesagt habe. Es ist uns wichtig, den Benutzer vor Problemen zu schützen.
  • Wir haben Freigaben. Wir betrachten es beispielsweise nicht als Ausfallzeit, wenn wir innerhalb von zwei Minuten 2 % des Datenverkehrs verlieren. Dies ist in unserer Statistik grundsätzlich nicht enthalten. Wenn es prozentualer oder vorübergehender Natur ist, rechnen wir bereits mit.
  • Und wir schreiben immer Obduktionen. Was auch immer mit uns passiert, jede Situation, in der sich jemand in der Produktion ungewöhnlich verhalten hat, wird sich in der Obduktion widerspiegeln. Eine Obduktion ist ein Dokument, in dem Sie aufschreiben, was mit Ihnen passiert ist, einen detaillierten Zeitpunkt angeben, was Sie getan haben, um das Problem zu beheben, und (dies ist ein obligatorischer Block!) Was Sie tun werden, um zu verhindern, dass dies in Zukunft passiert. Dies ist zwingend erforderlich und für die spätere Analyse erforderlich.

  Was gilt als Ausfallzeit?

  
  
  Wozu hat das alles geführt?

  Dies führte dazu, dass unser Stabilitätsindikator in den letzten 6 Monaten bei 99,97 lag (wir hatten gewisse Stabilitätsprobleme, dies passte weder zu unseren Kunden noch zu uns). Wir können sagen, dass das nicht sehr viel ist. Ja, wir haben etwas, wonach wir streben können. Etwa die Hälfte dieses Indikators ist sozusagen die Stabilität nicht unserer, sondern unserer Webanwendungs-Firewall, die vor uns steht und als Dienst genutzt wird, aber den Kunden ist das egal.

  Wir haben gelernt, nachts zu schlafen. Endlich! Vor sechs Monaten konnten wir das nicht. Und zu den Ergebnissen möchte ich noch eine Anmerkung machen. Gestern Abend gab es einen wunderbaren Bericht über das Steuerungssystem eines Kernreaktors. Wenn die Leute, die dieses System geschrieben haben, mich hören können, vergessen Sie bitte, was ich über „2 % sind keine Ausfallzeit“ gesagt habe. Für Sie sind 2 % Ausfallzeit, und sei es nur zwei Minuten!

  Das ist alles! Deine Fragen.

  
  

  Über Balancer und Datenbankmigration

  Frage aus dem Publikum (im Folgenden – B): – Guten Abend. Vielen Dank für einen solchen Admin-Bericht! Eine kurze Frage zu Ihren Balancern. Sie haben erwähnt, dass Sie eine WAF haben, das heißt, so wie ich es verstehe, verwenden Sie eine Art externen Balancer ...

  EK: – Nein, wir nutzen unsere Dienste als Balancer. In diesem Fall ist WAF für uns ausschließlich ein DDoS-Schutztool.

  in: – Können Sie ein paar Worte zu Balancern sagen?

  EK: – Wie ich bereits sagte, handelt es sich hierbei um eine Gruppe von Servern in Openresty. Wir haben jetzt 5 Reservegruppen, die ausschließlich antworten ... das heißt, ein Server, auf dem ausschließlich Openresty läuft, der nur den Datenverkehr weiterleitet. Um zu verstehen, wie viel wir haben: Wir haben mittlerweile einen regelmäßigen Verkehrsfluss von mehreren hundert Megabit. Sie kommen zurecht, fühlen sich gut und überanstrengen sich nicht einmal.

  in: – Auch eine einfache Frage. Hier ist die Blau/Grün-Bereitstellung. Was machen Sie beispielsweise bei Datenbankmigrationen?

  EK: - Gute Frage! Schauen Sie, in der Blau/Grün-Bereitstellung haben wir separate Warteschlangen für jede Zeile. Das heißt, wenn es sich um Ereigniswarteschlangen handelt, die von Worker zu Worker übertragen werden, gibt es separate Warteschlangen für die blaue und die grüne Linie. Wenn wir über die Datenbank selbst sprechen, dann haben wir sie bewusst so weit wie möglich eingegrenzt, alles praktisch in Warteschlangen verschoben; in der Datenbank speichern wir nur einen Stapel von Transaktionen. Und unser Transaktionsstapel ist für alle Linien gleich. Mit der Datenbank in diesem Zusammenhang: Wir unterteilen sie nicht in Blau und Grün, da beide Versionen des Codes wissen müssen, was mit der Transaktion passiert.

  Freunde, ich habe auch einen kleinen Preis als Ansporn für euch – ein Buch. Und ich sollte ihn für die beste Frage erhalten.

  in: - Guten Tag. Danke für den Bericht. Die Frage ist diese. Sie überwachen Zahlungen, Sie überwachen die Dienste, mit denen Sie kommunizieren ... Aber wie überwachen Sie, dass eine Person irgendwie auf Ihre Zahlungsseite gelangt ist, eine Zahlung getätigt hat und das Projekt ihr Geld gutgeschrieben hat? Das heißt, wie stellen Sie sicher, dass der Marchant verfügbar ist und Ihren Rückruf angenommen hat?

  EK: – „Händler“ ist für uns in diesem Fall genau der gleiche externe Service wie das Zahlungssystem. Wir überwachen die Reaktionsgeschwindigkeit des Händlers.

  Informationen zur Datenbankverschlüsselung

  in: - Guten Tag. Ich habe eine etwas verwandte Frage. Sie verfügen über sensible PCI DSS-Daten. Ich wollte wissen, wie man PANs in Warteschlangen speichert, in die man sie übertragen muss? Benutzen Sie eine Verschlüsselung? Und das führt zur zweiten Frage: Laut PCI DSS ist es notwendig, die Datenbank bei Änderungen (Entlassung von Administratoren etc.) regelmäßig neu zu verschlüsseln – was passiert in diesem Fall mit der Erreichbarkeit?

  
  
  EK: - Wunderbare Frage! Erstens speichern wir PANs nicht in Warteschlangen. Wir haben grundsätzlich nicht das Recht, PAN irgendwo in klarer Form zu speichern, deshalb nutzen wir einen speziellen Dienst (wir nennen ihn „Kademon“) – das ist ein Dienst, der nur eines tut: Er empfängt eine Nachricht als Eingabe und sendet sie eine verschlüsselte Nachricht verschicken. Und wir speichern alles mit dieser verschlüsselten Nachricht. Dementsprechend liegt unsere Schlüssellänge unter einem Kilobyte, sodass dies seriös und zuverlässig ist.

  in: – Brauchen Sie jetzt 2 Kilobyte?

  EK: – Mir kommt es vor, als wären es erst gestern 256 gewesen... Na ja, wo sonst?!

  Dementsprechend ist dies der erste. Und zweitens unterstützt die vorhandene Lösung das Neuverschlüsselungsverfahren – es gibt zwei Paare von „Keks“ (Schlüsseln), die „Decks“ ergeben, die verschlüsseln (Schlüssel sind die Schlüssel, Dek sind Ableitungen der Schlüssel, die verschlüsseln). . Und wenn der Vorgang eingeleitet wird (dies geschieht regelmäßig, von 3 Monaten bis ± einige), laden wir ein neues Paar „Kuchen“ herunter und verschlüsseln die Daten erneut. Wir haben separate Dienste, die alle Daten herausreißen und auf neue Weise verschlüsseln; Die Daten werden neben der Kennung des Schlüssels gespeichert, mit dem sie verschlüsselt werden. Sobald wir die Daten mit neuen Schlüsseln verschlüsseln, löschen wir dementsprechend den alten Schlüssel.

  Manchmal müssen Zahlungen manuell getätigt werden...

  in: – Das heißt, wenn für einen Vorgang eine Rückerstattung eingegangen ist, können Sie diese dann trotzdem mit dem alten Schlüssel entschlüsseln?

  EK: - Ja.

  in: – Dann noch eine kleine Frage. Wenn ein Fehler, ein Sturz oder ein Vorfall auftritt, muss die Transaktion manuell durchgeführt werden. Es gibt eine solche Situation.

  EK: - Ja manchmal.

  in: – Woher bekommen Sie diese Daten? Oder gehen Sie selbst zu diesem Lager?

  EK: – Nein, natürlich haben wir eine Art Backoffice-System, das eine Schnittstelle für unseren Support enthält. Wenn wir nicht wissen, in welchem ​​Status sich die Transaktion befindet (z. B. bis das Zahlungssystem mit einem Timeout reagiert), wissen wir es a priori nicht, das heißt, wir weisen den endgültigen Status nur mit voller Sicherheit zu. In diesem Fall weisen wir der Transaktion einen Sonderstatus zur manuellen Bearbeitung zu. Sobald der Support morgens am nächsten Tag die Information erhält, dass bestimmte Transaktionen im Zahlungssystem verbleiben, verarbeitet er sie manuell in dieser Schnittstelle.

  
  
  in: – Ich habe ein paar Fragen. Eine davon ist die Fortsetzung der PCI-DSS-Zone: Wie protokollieren Sie ihre Schaltung? Diese Frage ist darauf zurückzuführen, dass der Entwickler alles in die Protokolle hätte einfügen können! Zweite Frage: Wie führt man Hotfixes aus? Die Verwendung von Handles in der Datenbank ist eine Möglichkeit, aber möglicherweise gibt es kostenlose Hotfixes – wie ist dort die Vorgehensweise? Und die dritte Frage hängt wahrscheinlich mit RTO, RPO zusammen. Ihre Verfügbarkeit betrug 99,97, fast vier Neunen, aber so wie ich es verstehe, haben Sie ein zweites Rechenzentrum, ein drittes Rechenzentrum und ein fünftes Rechenzentrum ... Wie synchronisiert man sie, repliziert sie und alles andere?

  EK: - Beginnen wir mit dem ersten. Bezog sich die erste Frage auf Protokolle? Wenn wir Protokolle schreiben, haben wir eine Ebene, die alle sensiblen Daten maskiert. Sie betrachtet die Maske und die Zusatzfelder. Dementsprechend kommen unsere Protokolle mit bereits maskierten Daten und einer PCI-DSS-Schaltung heraus. Dies gehört zu den regelmäßigen Aufgaben der Testabteilung. Sie müssen jede Aufgabe überprüfen, einschließlich der von ihnen geschriebenen Protokolle. Dies ist eine der regelmäßigen Aufgaben bei Codeüberprüfungen, um sicherzustellen, dass der Entwickler nichts aufgeschrieben hat. Nachfolgende Kontrollen werden regelmäßig etwa einmal pro Woche durch die Informationssicherheitsabteilung durchgeführt: Es werden selektiv Protokolle des letzten Tages erstellt und diese durch einen speziellen Scanner-Analysator von Testservern laufen lassen, um alles zu überprüfen.
  Über Hotfixes. Dies ist in unserer Einsatzordnung enthalten. Wir haben eine separate Klausel zu Hotfixes. Wir glauben, dass wir Hotfixes rund um die Uhr bereitstellen, wenn wir sie brauchen. Sobald die Version zusammengestellt ist, sobald sie ausgeführt wird, sobald wir ein Artefakt haben, ist ein Systemadministrator für einen Anruf vom Support im Einsatz und er stellt es dann bereit, wenn es nötig ist.

  Etwa „vier Neunen“. Den jetzigen Wert haben wir wirklich erreicht, und wir haben ihn in einem anderen Rechenzentrum angestrebt. Jetzt haben wir ein zweites Rechenzentrum und beginnen mit dem Routing zwischen ihnen, und die Frage der rechenzentrumsübergreifenden Replikation ist wirklich keine triviale Frage. Wir haben versucht, es einmal mit verschiedenen Mitteln zu lösen: Wir haben versucht, dieselbe „Vogelspinne“ zu verwenden – es hat bei uns nicht geklappt, das sage ich Ihnen gleich. Deshalb haben wir die „Sens“ letztendlich manuell bestellt. Tatsächlich führt jede Anwendung in unserem System die notwendige „Change – Done“-Synchronisierung zwischen Rechenzentren asynchron durch.

  in: – Wenn du ein zweites hast, warum hast du dann nicht ein drittes bekommen? Weil noch niemand ein Split-Brain hat ...

  EK: – Aber wir haben kein Split Brain. Da jede Anwendung von einem Multimaster gesteuert wird, spielt es für uns keine Rolle, an welches Zentrum die Anfrage gelangt ist. Wir sind darauf vorbereitet, dass wir bereit sind, diesen Benutzer zu verlieren, wenn eines unserer Rechenzentren ausfällt (wir verlassen uns darauf) und mitten in einer Benutzeranfrage zum zweiten Rechenzentrum wechselt. aber das werden Einheiten sein, absolute Einheiten.

  in: - Guten Abend. Danke für den Bericht. Sie haben über Ihren Debugger gesprochen, der einige Testtransaktionen in der Produktion ausführt. Aber erzählen Sie uns von Testtransaktionen! Wie tief geht es?

  EK: – Es durchläuft den gesamten Zyklus des gesamten Bauteils. Für eine Komponente gibt es keinen Unterschied zwischen einer Testtransaktion und einer Produktionstransaktion. Aus logischer Sicht handelt es sich jedoch lediglich um ein separates Projekt im System, auf dem nur Testtransaktionen ausgeführt werden.

  in: -Wo schneidest du es ab? Hier hat Core gesendet...

  EK: – Wir stehen in diesem Fall für Testtransaktionen hinter „Kor“... Wir haben so etwas wie Routing: „Kor“ weiß, an welches Zahlungssystem er senden soll – wir senden an ein gefälschtes Zahlungssystem, das einfach ein http-Signal gibt und das ist alles.

  in: – Sagen Sie mir bitte, wurde Ihre Anwendung in einem riesigen Monolithen geschrieben oder haben Sie sie in einige Dienste oder sogar Mikrodienste zerlegt?

  EK: – Wir haben natürlich keinen Monolithen, wir haben eine serviceorientierte Anwendung. Wir scherzen, dass unser Service aus Monolithen besteht – sie sind wirklich ziemlich groß. Es ist schwer, von Microservices zu sprechen, aber dabei handelt es sich um Dienste, in denen Mitarbeiter verteilter Maschinen arbeiten.

  Wenn der Dienst auf dem Server beeinträchtigt ist ...

  in: – Dann habe ich die nächste Frage. Selbst wenn es ein Monolith wäre, haben Sie immer noch gesagt, dass Sie viele dieser Instant-Server haben, sie alle verarbeiten grundsätzlich Daten, und die Frage ist: „Im Falle einer Kompromittierung eines der Instant-Server oder einer Anwendung, jeder einzelnen Verbindung.“ , gibt es eine Art Zugangskontrolle? Wer von ihnen kann was? An wen kann ich mich für welche Informationen wenden?

  
  
  EK: - Ja auf jeden Fall. Die Sicherheitsanforderungen sind recht hoch. Erstens haben wir offene Datenbewegungen, und die Häfen sind nur diejenigen, über die wir die Verkehrsbewegungen im Voraus antizipieren. Wenn eine Komponente über 5-4-3-2 mit der Datenbank (z. B. mit Muskul) kommuniziert, ist nur 5-4-3-2 für sie geöffnet und andere Ports und andere Verkehrsrichtungen sind nicht verfügbar. Darüber hinaus müssen Sie verstehen, dass es in unserer Produktion etwa 10 verschiedene Sicherheitsschlaufen gibt. Und selbst wenn die Anwendung irgendwie kompromittiert wurde, hat der Angreifer – Gott bewahre – keinen Zugriff auf die Serververwaltungskonsole, da es sich hierbei um eine andere Netzwerksicherheitszone handelt.

  in: – Und was in diesem Zusammenhang für mich interessanter ist, ist, dass man bestimmte Verträge mit Diensten hat – was sie tun können, durch welche „Aktionen“ sie miteinander in Kontakt treten können ... Und im normalen Ablauf fordern einige bestimmte Dienste welche an Zeile, eine Liste von „Aktionen“ auf der anderen Seite. Sie scheinen sich in einer normalen Situation nicht an andere zu wenden und haben andere Verantwortungsbereiche. Wenn einer von ihnen kompromittiert wird, kann er dann die „Aktionen“ dieses Dienstes stören?

  EK: - Ich verstehe. Wenn in einer normalen Situation mit einem anderen Server überhaupt Kommunikation erlaubt wäre, dann ja. Gemäß SLA-Vertrag überwachen wir nicht, dass Ihnen nur die ersten 3 „Aktionen“ erlaubt sind und Ihnen die 4 „Aktionen“ nicht gestattet sind. Dies ist für uns wahrscheinlich überflüssig, da wir im Prinzip bereits über ein 4-stufiges Schutzsystem für Stromkreise verfügen. Wir verteidigen uns lieber mit den Konturen als auf der Ebene des Inneren.

  So funktionieren Visa, MasterCard und Sberbank

  in: – Ich möchte einen Punkt zum Wechsel eines Benutzers von einem Rechenzentrum zu einem anderen klarstellen. Soweit ich weiß, arbeiten Visa und MasterCard mit dem binären Synchronprotokoll 8583, und es gibt dort Mischungen. Und ich wollte wissen, jetzt meinen wir den Wechsel – ist das direkt „Visa“ und „MasterCard“ oder vor Bezahlsystemen, vor der Abwicklung?

  EK: - Das ist vor den Mischungen. Unsere Mixe befinden sich im selben Rechenzentrum.

  in: – Grob gesagt, haben Sie einen Verbindungspunkt?

  EK: – „Visa“ und „MasterCard“ – ja. Ganz einfach, weil Visa und MasterCard erhebliche Investitionen in die Infrastruktur erfordern, um beispielsweise separate Verträge abzuschließen, um ein zweites Mix-Paar zu erhalten. Sie sind innerhalb eines Rechenzentrums reserviert, aber wenn, Gott bewahre, unser Rechenzentrum, in dem es Mischungen für die Verbindung zu Visa und MasterCard gibt, stirbt, dann wird die Verbindung zu Visa und MasterCard verloren gehen ...

  in: – Wie können sie reserviert werden? Ich weiß, dass Visa grundsätzlich nur eine Verbindung zulässt!

  EK: – Sie stellen die Ausrüstung selbst zur Verfügung. Auf jeden Fall haben wir eine Ausstattung erhalten, die im Inneren völlig redundant ist.

  in: – Der Ständer ist also von ihrem Connects Orange?

  EK: - Ja.

  in: – Aber wie wäre es mit diesem Fall: Wenn Ihr Rechenzentrum verschwindet, wie können Sie es dann weiter nutzen? Oder hört der Verkehr einfach auf?

  EK: - Nein. In diesem Fall schalten wir den Traffic einfach auf einen anderen Kanal um, was natürlich für uns teurer und für unsere Kunden teurer wird. Der Verkehr wird jedoch nicht über unsere direkte Verbindung zu Visa, MasterCard, sondern über die bedingte Sberbank laufen (stark übertrieben).

  Ich entschuldige mich aufrichtig, wenn ich Sberbank-Mitarbeiter beleidigt habe. Doch laut unserer Statistik stürzt die Sberbank unter den russischen Banken am häufigsten ab. Es vergeht kein Monat, ohne dass bei der Sberbank etwas schiefgeht.

  
  
  

  Einige Anzeigen 🙂

  Vielen Dank, dass Sie bei uns geblieben sind. Gefallen Ihnen unsere Artikel? Möchten Sie weitere interessante Inhalte sehen? Unterstützen Sie uns, indem Sie eine Bestellung aufgeben oder an Freunde weiterempfehlen. Cloud-VPS für Entwickler ab 4.99 $, ein einzigartiges Analogon von Einstiegsservern, das von uns für Sie erfunden wurde: Die ganze Wahrheit über VPS (KVM) E5-2697 v3 (6 Kerne) 10 GB DDR4 480 GB SSD 1 Gbit/s ab 19 $ oder wie teilt man sich einen Server? (verfügbar mit RAID1 und RAID10, bis zu 24 Kerne und bis zu 40 GB DDR4).

  Dell R730xd 2-mal günstiger im Equinix Tier IV-Rechenzentrum in Amsterdam? Nur hier 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6 GHz 14C 64 GB DDR4 4 x 960 GB SSD 1 Gbit/s 100 TV ab 199 $ in den Niederlanden! Dell R420 – 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gbit/s 100 TB – ab 99 $! Lesen über Wie baut man ein Infrastrukturunternehmen auf? Klasse mit dem Einsatz von Dell R730xd E5-2650 v4 Servern im Wert von 9000 Euro für einen Cent?

Source: habr.com