HighLoad++, Jewgeni Kuzovlew (EcommPay IT): Was tun, wenn eine Minute Ausfallzeit 100.000 $ kostet

Alle sprechen über die Entwicklungs- und Testprozesse, die Schulung des Personals, die Steigerung der Motivation, aber diese Prozesse sind kaum von Bedeutung, wenn eine Minute Ausfallzeit des Services astronomische Kosten verursacht. Was tun, wenn Sie finanzielle Transaktionen unter einem strengen SLA durchführen? Wie können Sie die Zuverlässigkeit und Ausfallsicherheit Ihrer Systeme erhöhen, ohne Entwicklung und Tests zu berücksichtigen?

Die nächste HighLoad++-Konferenz findet am 6. und 7. April 2020 in St. Petersburg statt. Weitere Informationen und Tickets unter dem Link. 9. November, 18:00 Uhr. HighLoad++ Moskau 2018, Saal „Delhi + Kalkutta“. Thesen und Präsentation.

Yevgeny Kuzovlev (im Folgenden – EK): – Freunde, hallo! Mein Name ist Yevgeny Kuzovlev. Ich komme von der Firma EcommPay, genauer gesagt von der Abteilung EcommPay IT, der IT-Abteilung der Unternehmensgruppe. Heute werden wir über Ausfallzeiten sprechen – darüber, wie man sie vermeidet und wie man ihre Folgen minimiert, wenn eine Vermeidung nicht möglich ist. Das Thema, das wir behandeln, ist: „Was tun, wenn eine Minute Ausfallzeit 100.000 Dollar kostet?“ Wir werden im Vorfeld ähnliche Zahlen betrachten.

Womit beschäftigt sich EcommPay IT?

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

Die Unternehmensgruppe EcommPay ist ein internationaler Acquirer. Wir bearbeiten Zahlungen weltweit – in Russland, Europa, in Südostasien (All Around the World). Wir haben 9 Büros, insgesamt 500 Mitarbeiter und etwa die Hälfte davon sind IT-Spezialisten. Alles, was wir tun, alles, womit wir Geld verdienen, haben wir selbst gemacht.

Alle unsere Produkte (wir haben ziemlich viele – in unserer Reihe großer IT-Produkte haben wir etwa 16 verschiedene Komponenten) haben wir selbst entwickelt; wir programmieren selbst, wir entwickeln selbst. Momentan führen wir etwa eine Million Transaktionen pro Tag durch (Millionen – wahrscheinlich ist das die richtige Formulierung). Wir sind ein relativ junges Unternehmen – wir sind erst etwa sechs Jahre alt.

Vor 6 Jahren war das ein Startup, als die Leute zusammen mit dem Geschäft kamen. Sie waren durch eine Idee vereint (es gab nichts anderes als diese Idee), und wir sind losgelaufen. Wie jedes Startup sind wir schneller gelaufen… Für uns war die Geschwindigkeit wichtiger als die Qualität.

Irgendwann hielten wir inne: Wir erkannten, dass wir nicht mehr mit der bisherigen Geschwindigkeit und Qualität weiterleben können und dass wir in erster Linie die Qualität verbessern müssen. In diesem Moment beschlossen wir, eine neue Plattform zu entwickeln, die richtig, skalierbar und zuverlässig sein wird. Diese Plattform haben wir angefangen zu entwickeln (wir haben investiert, die Entwicklung und das Testing vorangetrieben), aber irgendwann erkannten wir, dass die Entwicklung und das Testing es uns nicht erlauben, ein neues Qualitätsniveau des Services zu erreichen.

Sie entwickeln ein neues Produkt, bringen es in die Produktion, aber trotzdem wird irgendwo etwas schiefgehen. Heute sprechen wir darüber, wie wir ein neues qualitatives Niveau erreichen können (wie uns das gelungen ist, über unsere Erfahrungen), wobei die Entwicklung und das Testing außen vor bleiben; wir werden darüber sprechen, was für den Betrieb verfügbar ist – was der Betrieb selbst tun kann, was er dem Testing anbieten kann, um die Qualität zu beeinflussen.

Downtimes. Die Gebote des Betriebs.

Immer der grundlegendste Eckpfeiler, über den wir heute sprechen werden – Downtime. Ein schlimmes Wort. Wenn wir Downtime haben, stehen wir schlecht da. Wir eilen, um alles wieder zum Laufen zu bringen, die Admins halten den Server am Laufen – hoffentlich fällt er nicht aus, wie es in dem Lied heißt. Darum werden wir heute sprechen.

Als wir begannen, unsere Ansätze zu ändern, formulierten wir 4 Gebote. Diese habe ich auf den Folien dargestellt:

Diese Gebote sind ziemlich einfach:

• Das Problem schnell identifizieren.
• Noch schneller es loswerden.
• Die Ursache verstehen helfen (später, für die Entwickler).
• Und die Ansätze standardisieren.

Ich möchte Ihre Aufmerksamkeit auf Punkt Nr. 2 lenken. Wir befreien uns von dem Problem, anstatt es zu lösen. Eine Lösung kommt an zweiter Stelle. Für uns ist entscheidend, dass der Benutzer von diesem Problem abgeschottet ist. Es wird in einer gewissen isolierten Umgebung existieren, aber diese Umgebung wird nicht mit ihm in Kontakt treten. Tatsächlich werden wir uns mit diesen vier Gruppen von Problemen beschäftigen (einige ausführlicher, andere weniger ausführlich), ich werde Ihnen erzählen, was wir verwenden und welche entsprechenden Erfahrungen wir in den Lösungen haben.

Problemlösung: Wann treten sie auf und was ist zu tun?

Aber wir beginnen nicht der Reihenfolge nach, wir beginnen mit Punkt Nr. 2 – wie können wir das Problem schnell loswerden? Es gibt ein Problem – wir müssen es beheben. „Was sollen wir damit machen?“ – die zentrale Frage. Und als wir anfingen, über die Lösung des Problems nachzudenken, haben wir einige Anforderungen entwickelt, denen die Problemlösung folgen sollte.

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

• Hardwareausfall.
• Fehler von externen Diensten.
• Änderung der Softwareversion (das ist das Deployment).
• Explosion des Lastwachstums.

Über die ersten beiden werden wir nicht sprechen. Hardwareausfälle lassen sich recht einfach beheben: Sie müssen alles redundant haben. Wenn es sich um Festplatten handelt – die Festplatten sollten in einem RAID-Verbund konfiguriert sein, wenn es sich um einen Server handelt – der Server sollte dupliziert sein, und wenn Sie eine Netzwerk-Infrastruktur haben – sollten Sie eine zweite Kopie der Netzwerk-Infrastruktur bereitstellen, das heißt, Sie nehmen und duplizieren. Und wenn etwas ausfällt, schalten Sie auf die Backup-Ressourcen um. Hier gibt es nicht viel mehr zu sagen.

Das Zweite ist der Fehler von externen Diensten. Für die meisten Systeme ist das überhaupt kein Problem, aber nicht für uns. Da wir Zahlungen verarbeiten, sind wir ein Aggregator, der zwischen dem Benutzer (der seine Kartendaten eingibt) und den Banken, den Zahlungssystemen („Visa“, „MasterCard“, „Mir“ usw.) steht. Externen Diensten (Zahlungssystemen, Banken) können Fehler unterlaufen. Weder wir noch Sie (wenn Sie solche Dienste haben) können darauf Einfluss nehmen.

Was ist dann zu tun? Hier gibt es zwei Ansätze. Erstens, wenn Sie können, sollten Sie diesen Dienst irgendwie duplizieren. Zum Beispiel leiten wir, wenn wir können, den Traffic von einem Dienst auf einen anderen um: Wir haben beispielsweise Karten über „Sberbank“ verarbeitet, hat die „Sberbank“ Probleme – leiten wir den Traffic [verhältnismäßig] auf „Raiffeisen“ um. Zweitens können wir sehr schnell den Fehler externer Dienste feststellen, und deshalb werden wir in dem nächsten Teil des Berichts über die Reaktionsgeschwindigkeit sprechen.

Tatsächlich können wir aus diesen vier Punkten konkret Einfluss auf den Wechsel der Softwareversion nehmen – Maßnahmen ergreifen, die zu einer Verbesserung der Situation im Hinblick auf Deployments und im Kontext des explosionsartigen Anstiegs der Last führen. Genau das haben wir getan. Hier, nochmals, ein kleiner Hinweis...

Von diesen vier Problemen lassen sich mehrere sofort lösen, wenn Sie eine Cloud haben. Wenn Sie in den Clouds von „Microsoft Azure“, „Ozon“ sind, unsere Clouds von „Yandex“ oder „Mail“ nutzen, wird das Hardwareproblem zumindest zu ihrem Problem und bei Ihnen wird alles gut im Hinblick auf das Hardwareproblem.

Wir sind ein etwas ungewöhnliches Unternehmen. Hier sprechen alle über „Kubernetes“, über Clouds – wir haben weder „Kubernetes“ noch Clouds. Stattdessen haben wir Server mit Hardware in vielen Rechenzentren, und auf dieser Hardware sind wir gezwungen zu leben, wir müssen dafür verantwortlich sein. Daher werden wir in diesem Kontext sprechen. Also, zu den Problemen. Die ersten zwei haben wir ausgeklammert.

Wechsel der Softwareversion. Grundlagen

Unsere Entwickler haben keinen Zugriff auf die Produktion. Warum ist das so? Ganz einfach, wir sind nach PCI DSS zertifiziert, und unsere Entwickler haben einfach nicht das Recht, in die „Produktion“ zu schauen. Punkt. Ganz entschieden. Daher endet die Verantwortung der Entwicklung genau in dem Moment, in dem die Entwicklung den Build an die Veröffentlichung übergibt.

Unsere zweite Grundlage, die wir haben und die uns ebenfalls stark unterstützt – es gibt keine einzigartigen, nicht dokumentierten Kenntnisse. Ich hoffe, dass es bei Ihnen ebenso ist. Denn wenn dem nicht so ist, werden Sie Probleme bekommen. Probleme treten auf, wenn diese einzigartigen, nicht dokumentierten Kenntnisse nicht zur richtigen Zeit am richtigen Ort vorhanden sind. Angenommen, eine Person weiß, wie man eine bestimmte Komponente deployed – dieser Person ist nicht da, sie ist im Urlaub oder krank – dann haben Sie Probleme.

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

Anforderungen an den Wechsel der Softwareversion

Diese Anforderungen sind drei:

• Wir müssen das Deployment schnell zurückrollen.
• Wir müssen die Auswirkungen eines fehlgeschlagenen Deployments minimieren.
• Und wir sollten die Möglichkeit haben, uns schnell parallel bereitzustellen.
  Genau in dieser Reihenfolge! Warum? Weil es beim Deployment einer neuen Version in erster Linie nicht auf die Geschwindigkeit ankommt, sondern Ihnen wichtig ist, dass Sie, falls etwas schiefgeht, schnell zurückschalten und minimale Auswirkungen haben. Wenn Sie jedoch eine Reihe von Versionen im Produktionsumfeld haben, bei denen sich herausgestellt hat, dass es einen Fehler gibt (es gab kein Deployment, aber der Fehler besteht), dann ist die Geschwindigkeit des nachfolgenden Deployments von Bedeutung. Was haben wir also getan, um diese Anforderungen zu erfüllen? Wir haben auf eine solche Methodik zurückgegriffen:

  
  
  Sie ist recht bekannt, wir haben sie nicht erfunden – es ist das Blue/Green Deployment. Was ist das? Für jede Gruppe von Servern, auf denen Ihre Anwendungen stehen, sollte es eine Kopie geben. Eine "warme" Kopie: Auf ihr gibt es keinen Verkehr, aber jederzeit kann dieser Verkehr auf diese Kopie geleitet werden. Diese Kopie enthält die vorherige Version. Und im Moment des Deployments setzen Sie den Code auf die inaktive Kopie auf. Dann leiten Sie einen Teil des Verkehrs (oder den gesamten) auf die neue Version um. Dadurch müssen Sie, um den Verkehrsfluss von der alten Version auf die neue zu ändern, nur eine einzige Maßnahme ergreifen: Sie müssen im Upstream den Load Balancer ändern, die Richtung ändern – von einem Upstream zum anderen. Das ist sehr praktisch und löst das Problem des schnellen Umschaltens, des schnellen Rollbacks.

  Hier ist die Lösung für die zweite Frage – Minimierung: Sie können auf die neue Linie, die Linie mit dem neuen Code, nur einen Teil Ihres Verkehrs leiten (zum Beispiel 2 %). Und diese 2 % sind nicht 100%! Wenn Sie beim fehlerhaften Deployment 100 % des Verkehrs verloren haben – das ist schlimm, wenn Sie 2 % des Verkehrs verloren haben – das ist unangenehm, aber nicht katastrophal. Außerdem werden die Benutzer dies wahrscheinlich nicht einmal bemerken, denn in einigen Fällen (nicht in allen) kann derselbe Benutzer, der F5 drückt, auf eine andere, funktionierende Version gelangen.

  Blue/Green Deployment. Routing

  Doch es ist nicht so einfach, "Blue/Green Deployment" zu machen... Alle unsere Komponenten können in drei Gruppen unterteilt werden:

  • das Frontend (Zahlungsseiten, die unsere Kunden sehen);
  • Kernverarbeitung;
  • Adapter zur Zusammenarbeit mit Zahlungssystemen (Banken, MasterCard, Visa...).

  Und hier gibt es einen wichtigen Punkt – der Punkt betrifft das Routing zwischen den Leitungen. Wenn Sie 100% des Traffics einfach umschalten, gibt es diese Probleme nicht. Aber wenn Sie 2% umschalten möchten, beginnen die Fragen: „Wie macht man das?“ Das Einfachste, ganz direkt: Sie können eine Zufallsauswahl, Round Robin in nginx einstellen, und haben dann 2% nach links, 98% nach rechts. Aber das ist nicht immer geeignet.

  Bei uns interagiert der Benutzer beispielsweise nicht mit der System mit nur einer Anfrage. Das ist normal: 2, 3, 4, 5 Anfragen – Ihre Systeme können genauso sein. Und wenn es Ihnen wichtig ist, dass alle Anfragen des Benutzers auf dasselbe Leitungs kommen, auf das die erste Anfrage kam, oder (der zweite Punkt) dass alle Anfragen des Benutzers auf eine neue Linie nach dem Umschalten geleitet werden (er könnte zuvor schon mit dem System gearbeitet haben, vor dem Umschalten), – dann ist diese zufällige Verteilung nicht geeignet. Dann gibt es folgende Optionen:

  
  
  Die erste Option, die einfachste – basierend auf den grundlegenden Parametern des Clients (IP-Hash). Sie haben eine IP, und Sie teilen nach der IP-Adresse nach rechts und links. Dann funktioniert der zweite von mir beschriebene Fall, wenn ein Deployment stattgefunden hat, der Benutzer bereits mit Ihrem System arbeiten konnte und seit dem Deployment alle Anfragen auf eine neue Leitung (auf dieselbe, sagen wir) geleitet werden.

  Wenn das aus irgendwelchen Gründen nicht geeignet ist und Sie die Anfragen unbedingt auf die Leitung schicken müssen, auf die die primäre, anfängliche Anfrage des Benutzers kam, dann haben Sie zwei Möglichkeiten...
  Die erste Möglichkeit: Sie können nginx+ verwenden. Dort gibt es einen Mechanismus für Sticky Sessions, der beim ersten Anfrage des Benutzers eine Sitzung festlegt und sie an jenen oder anderen Upstream bindet. Alle nachfolgenden Anfragen des Benutzers im Rahmen der Lebensdauer der Sitzung werden an denselben Upstream gesendet, an den die Sitzung festgelegt wurde.

  Das war für uns nicht geeignet, da wir bereits ein normales nginx hatten. Auf nginx+ umzuschalten – es ist nicht so, dass es teuer wäre, nur war es für uns etwas schmerzhaft und nicht ganz richtig. „Sticky Sessions“ haben für uns zum Beispiel nicht funktioniert aus dem einfachen Grund, dass „Sticky Sessions“ die Möglichkeit nicht bieten, nach dem Kriterium „Oder-Oder“ zu routen. Man kann beispielsweise festlegen, dass man „Sticky Sessions” nach der IP-Adresse oder nach IP-Adresse und Cookies oder nach POST-Parametern macht, aber „Oder-Oder“ – da wird es schon schwieriger.

  Daher sind wir zu der vierten Option gekommen. Wir haben nginx in einer „Steroid-Version“ verwendet (das ist openresty) – es handelt sich um dasselbe nginx, das zusätzlich die Unterstützung für das Einfügen von Last-Skripten hat. Sie können ein Last-Skript schreiben, es diesem „openresty“ zur Verfügung stellen, und dieses Last-Skript wird ausgeführt, wenn die Anfrage des Nutzers eingeht.

  Und wir haben tatsächlich ein solches Skript geschrieben, openresty installiert und in diesem Skript durchlaufen wir 6 verschiedene Parameter durch die Verkettung „Oder“. Je nachdem, ob der eine oder andere Parameter vorhanden ist, wissen wir, ob der Nutzer auf eine Seite oder die andere, auf eine Linie oder die andere gekommen ist.

  Blue/Green Deployment. Vor- und Nachteile

  Natürlich hätte man es vielleicht einfacher machen können (die gleichen „Sticky Sessions“ verwenden), aber wir haben noch den Aspekt, dass nicht nur der Nutzer im Rahmen einer Verarbeitung einer Transaktion mit uns interagiert… sondern dass auch Zahlungssysteme mit uns interagieren: wir erhalten einen Callback, nachdem wir die Transaktion verarbeitet haben (nachdem wir die Anfrage an das Zahlungssystem geschickt haben).
  Und nehmen wir an, dass wir innerhalb unseres Umfeldes die IP-Adresse des Nutzers in allen Anfragen weiterleiten können und auf Basis der IP-Adresse der Nutzer trennen können, dann würden wir der gleichen „VISA“ nicht sagen: „Leute, wir sind so ein retro Unternehmen, wir sind irgendwie international (auf der Webseite und in Russland)… Aber könntet ihr uns bitte die IP-Adresse des Nutzers zusätzlich in ein zusätzliches Feld schicken, euer standardisiertes Protokoll!“ Verständlich, dass sie nicht einwilligen werden.

  
  
  Deshalb war das für uns nicht geeignet – wir haben openresty gemacht. Folglich sieht unser Routing so aus:

  Der „Blue/Green Deployment“ hat dementsprechend Vorteile, die ich erwähnt habe, und Nachteile.

  Es gibt zwei Nachteile:

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

  Sie benötigen doppelt so viele Server, sie benötigen doppelt so viele Betriebsmittel, sie müssen doppelt so viel Aufwand für die Wartung dieses Zoos aufbringen.

  Übrigens, unter den Vorteilen gibt es noch eine weitere Sache, die ich bisher nicht erwähnt habe: Sie haben ein Reserve, falls die Last steigt. Wenn Sie einen sprunghaften Anstieg der Last haben und eine große Anzahl von Nutzern auf Sie zukommt, aktivieren Sie einfach die zweite Linie im Verteilungssystem 50 zu 50 – und Sie haben sofort x2 Server in Ihrem Cluster, bis Sie das Problem mit der Verfügbarkeit der Server gelöst haben.

  Wie macht man ein schnelles Deployment?

  Wir haben darüber gesprochen, wie man das Problem der Minimierung und schnellen Rückrollung löst, aber die Frage bleibt: „Wie kann man schnell deployen“?

  
  
  Hier ist alles kurz und einfach.

  • Sie müssen ein CD-System (Continuous Delivery) haben – ohne das geht es nicht. Wenn Sie einen Server haben, können Sie manuell deployen. Wir haben ungefähr tausendfünfhundert Server und manuelles Deployen auf tausendfünfhundert, das ist klar – wir können eine Abteilung in der Größe dieses Saals aufstellen, nur um zu deployen.
  • Das Deployment muss parallel erfolgen. Wenn Ihr Deployment sequenziell ist, ist es schlecht. Ein Server – in Ordnung, jedoch bei tausendfünfhundert Servern werden Sie den ganzen Tag deployen.
  • Nochmals, zur Beschleunigung ist das wahrscheinlich nicht erforderlich. Beim Deployment wird in der Regel das Projekt gebaut. Sie haben ein Webprojekt, eine Frontend-Komponente (dort machen Sie Webpack, npm sammeln – sowas in der Art), und dieser Prozess dauert eigentlich nicht lange – etwa 5 Minuten, aber diese 5 Minuten könnten kritisch sein. Deshalb machen wir beispielsweise das nicht: Wir haben diese 5 Minuten entfernt, wir deployen Artefakte.

    Was ist ein Artefakt? Ein Artefakt ist ein gebauter Build, in dem bereits der gesamte Build-Prozess durchgeführt wurde. Dieses Artefakt speichern wir in einem Artefakt-Repository. Früher haben wir zwei solcher Repositories verwendet – Nexus und jetzt jFrog Artifactory. "Nexus" haben wir ursprünglich verwendet, weil wir diesen Ansatz bei java-Anwendungen praktiziert haben (es war dafür gut geeignet). Dann haben wir auch einige PHP-Anwendungen hineingepackt; und "Nexus" war dafür nicht mehr geeignet, und dann haben wir uns für jFrog Artifactory entschieden, das praktisch alles archivieren kann. Wir haben sogar dazu gekommen, dass wir in diesem Artefakt-Repository unsere eigenen binären Pakete speichern, die wir für Server bauen.

  Sprunghafter Anstieg der Last

  Wir haben über den Versionswechsel der Software gesprochen. Das Nächste, was wir haben, ist der sprunghafte Anstieg der Last. Hier verstehe ich unter sprunghafter Last wahrscheinlich nicht ganz das Richtige…

  Wir haben ein neues System entwickelt – es ist serviceorientiert, modisch und schön, überall Worker, überall Warteschlangen, überall Asynchronität. In solchen Systemen können die Daten durch verschiedene Flows fließen. Bei der ersten Transaktion können der 1., 3. und 10. Worker eingesetzt werden, und bei der zweiten Transaktion der 2., 4. und 5. Und heute, sagen wir mal, haben Sie am Morgen einen Datenstrom, der die ersten drei Worker verwendet, und am Abend ändert sich dieser schlagartig und alle verwenden die anderen drei Worker.

  Hier ergibt sich die Situation, dass Sie die Worker irgendwie skalieren müssen, dass Sie Ihre Dienste irgendwie skalieren müssen, dabei aber eine Aufblähung der Ressourcen vermeiden sollten.

  
  
  Wir haben unsere Anforderungen definiert. Diese Anforderungen sind recht einfach: es sollte Service Discovery geben, Parametrisierung – alles Standard für den Aufbau solcher skalierbaren Systeme, außer einem Punkt – das ist die Amortisation der Ressourcen. Wir haben gesagt, 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 Worker verwaltet.

  Warum ist das für uns ein Problem? Lassen Sie mich etwas zurückspringen. Momentan stehen hinter uns ca. 70 Zahlungssysteme. Am Morgen fließt der Traffic über die ‘Sberbank’, dann fällt beispielsweise die ‘Sberbank’ aus und wir schalten auf ein anderes Zahlungssystem um. Wir hatten 100 Worker bis zur ‘Sberbank’, und danach müssen wir plötzlich 100 Worker für ein anderes Zahlungssystem hochfahren. Und das sollte alles idealerweise ohne menschliches Eingreifen geschehen. Denn wenn menschliches Eingreifen notwendig ist, muss ein Ingenieur 24/7 bereitstehen, der sich nur darum kümmert, denn solche Ausfälle mit 70 Systemen hinter einem passieren regelmäßig.

  Deshalb haben wir uns ‘Nomad’ angesehen, das eine offene IP hat, und haben unser Tool Scale-Nomad – ScaleNo – entwickelt, das Folgendes macht: es überwacht das Wachstum der Warteschlange und verringert oder erhöht die Anzahl der Worker je nach Dynamik der Warteschlangenänderungen. Als wir es entwickelt hatten, dachten wir: ‘Vielleicht sollten wir es Open Source machen?’ Dann sahen wir uns das an – es ist so einfach wie zwei Cent.

  Bis jetzt haben wir es nicht open-sourcete, aber falls Sie nach dem Vortrag, nach dem Verständnis, dass Sie so etwas brauchen, Bedarf daran haben, finden Sie meine Kontaktdaten auf der letzten Folie – schreiben Sie mir bitte. Wenn sich mindestens 3-5 Personen zusammenfinden, werden wir es open sourcen.

  
  
  Wie funktioniert das? Lassen Sie uns einen Blick darauf werfen! Vorausgeschaut: Links gibt es einen Abschnitt unserer Überwachung: das ist eine Linie, oben – die Zeit zur Verarbeitung von Ereignissen, in der Mitte – die Anzahl der Transaktionen, unten – die Anzahl der Worker.

  Wenn man sich dieses Bild ansieht, gibt es einen Ausfall. Auf dem oberen Diagramm ist einer der Graphen nach 45 Sekunden abgestürzt – eines der Zahlungssysteme war ausgefallen. Hier wurde der Traffic über 2 Minuten angezeigt und es gab einen Anstieg der Warteschlange bei einem anderen Zahlungssystem, bei dem es keine Worker gab (wir haben keine Ressourcen verbraucht – im Gegenteil, wir haben die Ressource korrekt genutzt). Wir wollten nicht überlasten – dort gab es eine minimale Anzahl, ungefähr 5-10 Worker, aber sie konnten das nicht bewältigen.

  Im letzten Diagramm ist ein „Buckel“ zu sehen, der genau darauf hinweist, dass „Skaleno“ diese Anzahl verdoppelt hat. Und dann, als das Diagramm ein wenig gesunken ist, hat es ein wenig reduziert – die Anzahl der Worker wurde automatisch geändert. So funktioniert dieses Teil. Wir haben über Punkt Nr. 2 gesprochen – „Wie man schnell die Ursachen beseitigt“.

  Überwachung. Wie erkennt man schnell ein Problem?

  Jetzt der erste Punkt – „Wie erkennt man schnell ein Problem?“ Überwachung! Wir müssen bestimmte Dinge schnell verstehen. Welche Dinge müssen wir schnell verstehen?

  
  
  Drei Dinge!

  • Wir müssen schnell verstehen und schnell die Funktionsfähigkeit unserer eigenen Ressourcen erfassen.
  • Wir müssen schnell erkennen, wenn etwas ausfällt, und die Funktionsfähigkeit von Systemen überwachen, die für uns extern sind.
  • Der dritte Punkt – das Erkennen von logischen Fehlern. Das ist, wenn das System bei Ihnen arbeitet, alle Anzeigen in Ordnung sind, aber etwas nicht stimmt.

  Hier werde ich wahrscheinlich nicht viel Erstaunliches erzählen. Ich werde Captain Offensichtlich sein. Wir haben geschaut, was auf dem Markt verfügbar ist. Wir haben einen „fröhlichen Zoo“ erstellt. So sieht unser Zoo jetzt aus:

  
  
  Wir verwenden „Zabbix“ zur Überwachung von „Hardware“, zur Überwachung der wichtigsten Serverkennzahlen. „Okmeter“ verwenden wir für Datenbanken. „Grafana“ und „Prometheus“ nutzen wir für alle anderen Kennzahlen, die nicht in die ersten beiden passen, dabei teilweise – mit „Grafana“ und „Prometheus“, teilweise – „Grafana“ mit „Influx“ und Telegraf.

  Vor einem Jahr wollten wir New Relic verwenden. Eine großartige Sache, sie kann alles. Aber je mehr sie kann, desto teurer ist sie auch. Als wir auf 1.500 Server gewachsen sind, kam ein Anbieter zu uns und sagte: „Lass uns einen Vertrag für das nächste Jahr abschließen“. Wir sahen uns den Preis an und sagten, dass wir das nicht machen werden. Jetzt verzichten wir auf New Relic; wir haben noch etwa 15 Server, die unter New Relic überwacht werden. Der Preis war einfach wahnsinnig.

  Es gibt ein Tool, das wir selbst umgesetzt haben – den Debugger. Zuerst nannten wir ihn „Bagger“, aber dann hatte wir einen Englischlehrer, der darüber lauthals lachte, und wir benannten es um in „Debugger“. Was ist das? Es ist ein Tool, das innerhalb von 15-30 Sekunden auf jedem Komponent, wie ein „Black Box“ System, Tests auf die allgemeine Funktionsfähigkeit des Komponenten durchführt.

  Zum Beispiel, wenn die externe Seite (Zahlungsseite) – öffnet sie einfach und schaut, wie sie aussehen sollte. Wenn es sich um eine Verarbeitung handelt, führt es einen Testtransaktionsdurchlauf durch – prüft, ob dieser „Transaktionsdurchlauf“ ankommt. Wenn es um die Verbindung zu Zahlungssystemen geht – senden wir entsprechend eine Testanfrage, wo wir können, und überprüfen, ob alles in Ordnung ist.

  Welche Kennzahlen sind wichtig für das Monitoring?

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

  
  

  • Reaktionszeit / RPS an den Fronten – eine sehr wichtige Kennzahl. Sie zeigt sofort an, dass etwas nicht stimmt.
  • Anzahl der verarbeiteten Nachrichten in allen Warteschlangen.
  • Anzahl der Worker.
  • Wesentliche Metriken zur Richtigkeit.

  Der letzte Punkt – eine „geschäftliche“ Metrik. Wenn Sie das Gleiche überwachen möchten, müssen Sie eine oder zwei Metriken bestimmen, die für Sie die wichtigsten Indikatoren sind. Eine solche Metrik bei uns ist die Durchsatzrate (das Verhältnis erfolgreicher Transaktionen zum gesamten Transaktionsdurchfluss). Wenn sich daran alle 5-10-15 Minuten etwas ändert – haben wir Probleme (wenn es sich grundlegend ändert).

  So sieht das bei uns aus – Beispiel eines unserer Dashboards:

  
  
  Auf der linken Seite – 6 Grafiken, dies entspricht den Linien – die Anzahl der Mitarbeiter und die Anzahl der Nachrichten in den Warteschlangen. Auf der rechten Seite – RPS, RTS. Unten – die besagte "geschäftliche" Kennzahl. Und bei der "geschäftlichen" Kennzahl sehen wir sofort, dass auf den beiden mittleren Grafiken etwas nicht stimmt... Das ist genau das, was mit dem nächsten System passiert ist, das hinter uns steht.

  Zweitens mussten wir das Fallen externer Zahlungssysteme überwachen. Hier haben wir OpenTracing verwendet – ein Mechanismus, ein Standard, ein Paradigma, das das Tracing verteilter Systeme ermöglicht; und wir haben es ein wenig verändert. Das standardmäßige OpenTracing-Paradigma besagt, dass wir das Tracing jeder einzelnen Anfrage erstellen. Das brauchten wir nicht, also haben wir es in ein summiertes, aggregiertes Tracing umgewandelt. Wir haben ein Tool entwickelt, das es uns ermöglicht, die Geschwindigkeit der Systeme zu überwachen, die hinter uns stehen.

  
  
  Das Diagramm zeigt uns, dass eines der Zahlungssysteme eine Antwortzeit von 3 Sekunden hat – wir haben Probleme. Dabei reagiert dieses System, sobald die Probleme beginnen, im Intervall von 20-30 Sekunden.

  Die dritte Fehlerklasse im Monitoring, die es gibt, ist das logische Monitoring.

  Ehrlich gesagt wusste ich nicht, was ich auf diesem Slide zeichnen sollte, da wir lange nach einem passenden Produkt auf dem Markt gesucht haben. Wir haben nichts gefunden, also mussten wir es selbst machen.

  
  
  Was meine ich mit logischem Monitoring? Nun, stellen Sie sich vor: Sie erstellen ein System (zum Beispiel einen Klon von "Tinder"); Sie haben es erstellt, gestartet. Erfolgreicher Manager Vasja Pupkin hat es auf seinem Telefon, sieht ein Mädchen, liked sie... aber der Like geht nicht an das Mädchen – der Like geht an Sicherheitsmann Michalitsch aus demselben Business-Center. Der Manager geht nach unten und fragt sich dann: „Warum lächelt dieser Sicherheitsmann Michalitsch ihm so angenehm zu?“

  In solchen Situationen… Diese Situation klingt für uns ein wenig anders, denn (ich habe geschrieben), es ist ein solcher Reputationsverlust, der indirekt zu finanziellen Verlusten führt. Bei uns ist die Situation umgekehrt: Wir können direkte finanzielle Verluste erleiden – zum Beispiel, wenn wir eine Transaktion als erfolgreich durchgeführt haben, sie aber nicht erfolgreich war (oder umgekehrt). Wir mussten ein eigenes Tool schreiben, das die Anzahl erfolgreicher Transaktionen im Zeitverlauf anhand von Geschäftszahlen überwacht. Wir haben nichts auf dem Markt gefunden! Genau diese Überlegung wollte ich vermitteln. Für die Lösung solcher Aufgaben gibt es nichts auf dem Markt.

  Das war zur Frage, wie man Probleme schnell identifizieren kann.

  Wie man die Ursachen des Deployments bestimmt

  Die dritte Gruppe von Aufgaben, die wir lösen, besteht darin, nachdem wir das Problem identifiziert haben, nachdem wir es beseitigt haben, gut zu verstehen, warum dies passiert ist, um etwas für die Entwicklung, das Testen zu tun. Entsprechend müssen wir Untersuchungen anstellen, wir müssen die Logs durchsehen.

  
  
  Wenn wir über Logs sprechen (der Hauptgrund sind die Logs), ist der größte Teil der Logs bei uns im ELK-Stack – bei fast allen so. Manche haben vielleicht nicht ELK, aber wenn man Logs in Gigabyte schreibt, kommt man früher oder später zu ELK. Wir schreiben sie in Terabyte.

  
  
  Hier gibt es ein Problem. Wir haben einen Fehler für den Benutzer behoben, sind dargestellt worden, was da war, sind in "Kibana" gegangen, haben dort die Transaktions-ID eingegeben und eine solche Ansammlung erhalten (zeigt viel an). Und in diesem Dokument ist nichts klar zu erkennen. Warum? Weil es unklar ist, welcher Teil zu welchem Worker gehört, welcher Teil zu welchem Component gehört. In diesem Moment haben wir verstanden, dass wir eine Tracing-Lösung benötigen – das ist das OpenTracing, von dem ich sprach.

  Das haben wir vor einem Jahr gedacht, haben unseren Blick auf den Markt gerichtet, und dort gab es zwei Tools – das sind "Zipkin" und "Jaeger". "Jaeger" ist im Grunde der ideologische Nachfolger, der ideologische Fortsetzer von "Zipkin". Bei "Zipkin" ist alles gut, außer dass er nicht aggregieren kann, nicht die Logs in das Tracing einbeziehen kann, nur das Zeit-Tracking. Und "Jaeger" hat das unterstützt.

  Wir haben uns «Eger» angeschaut: Man kann Anwendungen instrumentieren, man kann in die API schreiben (die API-Norm für PHP war damals noch nicht genehmigt – das war vor einem Jahr, aber jetzt ist sie genehmigt), aber es gab überhaupt keinen Client. „Okay“, dachten wir, und haben unseren eigenen Client geschrieben. Was haben wir erreicht? So sieht das ungefähr aus:

  
  
  In «Eger» werden für jede Nachricht Spans erstellt. Das heißt, wenn der Benutzer das System öffnet, sieht er ein oder zwei Blöcke für jede eingehende Anfrage (1-2-3 – je nachdem, wie viele eingehende Anfragen vom Benutzer kamen, gibt es so viele Blöcke). Um es den Benutzern zu erleichtern, haben wir Tags zu den Logs und zur zeitlichen Nachverfolgung hinzugefügt. Im Falle eines Fehlers wird unsere Anwendung das Log mit dem entsprechenden Tag Error markieren. Man kann nach dem Tag Error filtern, und es werden nur die Spans angezeigt, die diesen Block mit dem Fehler enthalten. So sieht es aus, wenn wir einen Span ausklappen:

  
  
  Innerhalb eines Spans gibt es eine Reihe von Traces. In diesem Fall sind das drei Test-Traces, und der dritte Trace sagt uns, dass ein Fehler aufgetreten ist. Dabei sehen wir hier auch die zeitliche Nachverfolgung: Oben haben wir eine Zeitachse, und wir sehen, in welchem Zeitintervall unser entsprechendes Log aufgezeichnet wurde.

  Dementsprechend ist es uns hervorragend gelungen. Wir haben eine eigene Erweiterung geschrieben und diese als Open Source veröffentlicht. Wenn Sie mit der Nachverfolgung arbeiten möchten, wenn Sie mit «Eger» in PHP arbeiten möchten – es gibt unsere Erweiterung, willkommen in der Nutzung, wie man so schön sagt:

  
  
  Unsere Erweiterung ist ein Client für die Nutzung der OpenTracing-API, erstellt als PHP-Extension, das heißt, Sie müssen es selbst zusammenstellen und in das System einfügen. Vor einem Jahr gab es nichts anderes. Jetzt sind noch andere Clients als Komponenten hinzugekommen. Hier liegt es an Ihnen: Entweder Sie laden die Komponenten mit Composer herunter, oder Sie verwenden die Extension – ganz wie Sie möchten.

  Unternehmensstandards

  Wir haben über die drei Gebote gesprochen. Das vierte Gebot besteht darin, die Ansätze zu standardisieren. Worum geht es dabei? Es geht ungefähr um Folgendes:

  
  
  Warum steht hier das Wort «unternehmerisch»? Nicht weil wir ein großes oder bürokratisches Unternehmen sind, nein! Das Wort «unternehmerisch» wollte ich hier im Kontext verwenden, dass jedes Unternehmen, jedes Produkt seine eigenen Standards haben sollte, und das gilt auch für Sie. Welche Standards haben wir?

  
  

  • Wir haben eine Regelung für Deployments. Ohne sie kommen wir nicht weiter, das ist unmöglich. Wir führen etwa 60 Deployments pro Woche durch, das heißt, bei uns finden Deployments praktisch ständig statt. Dabei haben wir zum Beispiel in der Regelung ein Verbot für Deployments am Freitag – generell deployen wir nicht.
  • Bei uns ist Dokumentation Pflicht. Kein neues Modul gelangt in die Produktion, wenn es keine Dokumentation gibt, selbst wenn es unter den Händen unserer RnD-Leute entstanden ist. Wir verlangen von ihnen eine Anleitung für das Deployment, ein Monitoring-Diagramm und eine grobe Beschreibung (na ja, wie Programmierer es schreiben können) dessen, wie dieses Modul funktioniert, wie man es troubleshooten kann.
  • Wir behandeln nicht die Ursache des Problems, sondern das Problem selbst – das habe ich bereits erwähnt. Es ist uns wichtig, den Nutzer von Problemen abzuschirmen.
  • Wir haben Toleranzen. Zum Beispiel betrachten wir es nicht als Ausfall, wenn wir innerhalb von zwei Minuten 2 % des Traffics verloren haben. Das fällt grundsätzlich nicht in unsere Statistik. Wenn es prozentual oder zeitlich mehr ist, zählen wir es bereits.
  • Und wir schreiben immer Postmortems. Egal was passiert, jede Situation, in der sich etwas im Produktionsumfeld nicht normal verhält, wird in einem Postmortem festgehalten. Ein Postmortem ist ein Dokument, in dem Sie aufschreiben, was passiert ist, eine detaillierte Zeitleiste, was Sie zur Behebung getan haben und (das ist ein obligatorischer Abschnitt!) was Sie tun werden, um solche Vorfälle in Zukunft zu vermeiden. Das ist verpflichtend, erforderlich für eine spätere Analyse.

  Was zählt als Ausfall?

  
  
  Wozu hat das alles geführt?

  Das hat dazu geführt, dass (wir hatten gewisse Probleme mit der Stabilität, die uns und die Kunden nicht zufriedenstellten) unser Stabilitätswert in den letzten 6 Monaten 99,97 betrug. Man kann sagen, dass das nicht viel ist. Ja, wir haben noch Luft nach oben. Von diesem Wert ist ungefähr die Hälfte die Stabilität, die nicht wirklich unsere ist, sondern die unseres Web Application Firewalls, die uns vorgesetzt ist und als Dienst genutzt wird, aber das ist den Kunden egal.

  Wir haben gelernt, nachts zu schlafen. Endlich! Vor einem halben Jahr konnten wir es nicht. Und an diesem Punkt möchte ich eine Bemerkung zu den Ergebnissen machen. Gestern Abend gab es einen großartigen Vortrag über das Management eines Kernreaktors. Falls die Personen, die dieses System geschrieben haben, zuhören – bitte vergessen Sie, was ich über „2% – das ist kein Ausfall“ gesagt habe. Für Sie sind 2 % ein Ausfall, selbst wenn es nur zwei Minuten lang ist!

  Das ist alles! Ihre Fragen.

  
  

  Über Load Balancer und Migration aus der Datenbank

  Frage aus dem Publikum (im Folgenden – F): – Guten Abend. Vielen Dank für diesen administrativen Vortrag! Die Frage ist kurz und betrifft Ihre Load Balancer. Sie haben erwähnt, dass Sie ein WAF haben, das heißt, ich verstehe, dass Sie als Load Balancer einen externen Dienst verwenden…

  EK: – Nein, als Load Balancer verwenden wir unsere eigenen Dienste. In diesem Fall ist das WAF für uns ausschließlich ein Instrument zum Schutz vor DDoS.

  Frage: – Kann ich ein paar Worte über die Load Balancer sagen?

  EK: – Wie ich bereits sagte, handelt es sich um eine Gruppe von Servern in OpenResty. Wir haben derzeit 5 Gruppen von dedizierten Servern, die ausschließlich… das heißt, der Server, auf dem nur OpenResty läuft, dient nur der Weiterleitung des Traffics. Um das Verständnis zu erleichtern, wie viel Traffic wir verarbeiten: Wir haben derzeit einen regulären Traffic von mehreren Hundert Megabit. Sie kommen gut damit zurecht, sie sind nicht einmal gestresst.

  Frage: – Auch eine einfache Frage. Es gibt Blue/Green Deployments. Was machen Sie zum Beispiel mit Migrationen aus der Datenbank?

  EK: – Gute Frage! Sehen Sie, im Blue/Green Deployment haben wir separate Warteschlangen für jede Linie. Das heißt, wenn wir über Ereigniswarteschlangen sprechen, 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, haben wir diese absichtlich so weit wie möglich eingegrenzt und fast alles in Warteschlangen umgelegt. In der Datenbank speichern wir nur den Transaktionsstapel. Dieser Transaktionsstapel ist für alle Linien identisch. Bezüglich der Datenbank in diesem Kontext: Wir teilen sie nicht in blau und grün auf, weil beide Codevarianten wissen müssen, was mit der Transaktion passiert.

  Freunde, ich habe noch einen kleinen Preis für Sie, um Sie anzuspornen – ein Buch. Und ich muss es für die beste Frage überreichen.

  Frage: – Guten Tag. Vielen Dank für den Vortrag. Die Frage ist folgende. Sie überwachen Zahlungen, Sie überwachen die Dienste, mit denen Sie kommunizieren… Aber wie überwachen Sie, dass eine Person irgendwie auf Ihre Zahlungsseite gekommen ist, die Zahlung durchgeführt hat und das Projekt ihr das Geld gutgeschrieben hat? Wie überwachen Sie, dass der Merchant verfügbar ist und Ihr Callback angenommen hat?

  EK: – Der „Merchant“ ist für uns in diesem Fall genau derselbe externe Dienst wie die Zahlungsmethode. Wir überwachen die Antwortgeschwindigkeit des Merchants.

  Über die Verschlüsselung der Datenbank

  Frage: – Guten Tag. Ich hätte da eine kurze Frage. Sie haben sensible Daten gemäß PCI DSS. Ich wollte wissen, wie Sie die PANs in den Warteschlangen speichern, die Sie weiterverarbeiten müssen? Verwenden Sie eine Art von Verschlüsselung? Und die daraus resultierende zweite Frage: Laut PCI DSS müssen die Datenbanken regelmäßig neu verschlüsselt werden im Falle von Änderungen (z.B. bei der Entlassung von Administratoren) – wie sieht es in diesem Fall mit der Verfügbarkeit aus?

  
  
  EK: – Eine hervorragende Frage! Zunächst einmal speichern wir keine PANs in den Warteschlangen. Wir haben grundsätzlich nicht das Recht, PANs in offener Form irgendwo zu speichern, daher verwenden wir einen speziellen Dienst, den wir „Keydemon“ nennen – dies ist ein Dienst, der nur eines macht: er nimmt eine Nachricht entgegen und gibt eine verschlüsselte Nachricht zurück. Und wir speichern alles in dieser verschlüsselten Nachricht. Entsprechend haben wir eine Schlüssellänge von etwa einem Kilobyte, damit das ernsthaft und sicher ist.

  Frage: – Braucht man jetzt bereits 2 Kilobyte?

  EK: – Gestern waren es noch 256… Wo soll das noch hinführen?!

  Das ist das Erste. Und zweitens unterstützt die vorhandene Lösung das Verfahren zur Neuverschlüsselung – es gibt zwei Paare von KEKs (Schlüsseln), die DEKs erzeugen, die verschlüsseln (key ist der Schlüssel, dek sind die derivativen Schlüssel, die verschlüsseln). Wenn das Verfahren initiiert wird (es läuft regelmäßig, alle 3 Monate bis ± ein paar), laden wir ein neues Paar von KEKs hoch, und wir führen die Neuverschlüsselung der Daten durch. Wir haben separate Dienste, die alle Daten herausholen und neu verschlüsseln; den Daten wird ein Identifikator des Schlüssels zugeordnet, mit dem sie verschlüsselt sind. Sobald die Daten mit den neuen Schlüsseln verschlüsselt sind, löschen wir die alten Schlüssel.

  Manchmal müssen Zahlungen manuell durchgeführt werden…

  Frage: – Das heißt, wenn eine Rückerstattung für eine bestimmte Transaktion eintritt, entschlüsseln Sie vorerst mit dem alten Schlüssel?

  EK: – Ja.

  Frage: – Dann noch eine kleine Frage. Wenn es zu einem Ausfall, einem Sturz oder einem Vorfall kommt, muss die Transaktion manuell angestoßen werden. Solche Situationen gibt es.

  EK: – Ja, die gibt es.

  Frage: – Woher beziehen Sie diese Daten? Oder gehen Sie selbst mit den Händen in dieses Lager?

  EK: – Nein, klar, wir haben ein gewisses Backoffice-System, das eine Schnittstelle für unseren Support enthält. Wenn wir nicht wissen, in welchem Status sich die Transaktion befindet (zum Beispiel solange das Zahlungssystem nicht mit einem Timeout antwortet) – wissen wir es grundsätzlich nicht, das heißt, wir weisen den finalen Status nur mit vollständiger Sicherheit zu. In diesem Fall stufen wir die Transaktion in einen speziellen Status für die manuelle Bearbeitung ein. Am Morgen des nächsten Tages, sobald der Support die Information erhält, dass im Zahlungssystem bestimmte Transaktionen offen geblieben sind, bearbeiten sie diese manuell in dieser Schnittstelle.

  
  
  Frage: – Ich habe ein paar Fragen. Eine davon betrifft die Fortsetzung des PCI DSS: Wie exportieren Sie die Logs aus deren Umgebung? Die Frage ergibt sich, weil der Entwickler beliebige Daten in die Logs eintragen könnte! Die zweite Frage: Wie führen Sie Hotfixes durch? Manuell in der Datenbank – das ist eine Möglichkeit, aber es könnte auch kostenlose Hotfixes geben – wie ist da die Vorgehensweise? Und die dritte Frage hängt wahrscheinlich mit RTO, RPO zusammen. Ihre Verfügbarkeit betrug 99,97, also fast vier Neunen, aber ich verstehe, dass Sie auch ein zweites, drittes und fünftes Rechenzentrum haben… Wie synchronisieren und replizieren Sie diese, wie handelt man den Rest?

  EK: – Lassen Sie uns mit der ersten Frage beginnen. War die erste Frage über die Logs? Wenn wir Logs schreiben, gibt es eine Schicht, die alle sensiblen Daten maskiert. Sie prüft anhand einer Maske und zusätzlicher Felder. Folglich gelangen die Logs bereits mit maskierten Daten und im PCI DSS-Umfeld in die Auswertung. Das ist eine der regelmäßigen Aufgaben, die der Testabteilung zugewiesen sind. Sie müssen jede Aufgabe auch hinsichtlich der Logs prüfen, die sie erstellen, und das ist eine regelmäßige Aufgabe bei Code-Reviews, um zu kontrollieren, dass der Entwickler nichts Unzulässiges aufzeichnet. Die nachfolgende Überprüfung wird etwa einmal pro Woche regelmäßig von der Abteilung für Informationssicherheit durchgeführt: Es werden stichprobenartig die Logs des letzten Tages entnommen und durch einen speziellen Scanner-Analysator von Testservern geprüft, um alles zu überprüfen.
  Über Hotfixes. Dies ist in unseren Deployment-Richtlinien enthalten. Wir haben einen speziellen Punkt über Hotfixes. Wir sind der Meinung, dass wir Hotfixes rund um die Uhr bereitstellen, wann immer wir es benötigen. Sobald die Version erstellt und getestet ist und wir ein Artefakt haben, wird ein diensthabender Systemadministrator auf einen Anruf vom Support hin aktiv und deployt es genau dann, wenn es nötig ist.

  Über die "vier Neunen". Die Zahl, die wir derzeit haben, wurde tatsächlich erreicht, und wir haben dies auch in einem anderen Rechenzentrum angestrebt. Jetzt haben wir ein zweites Rechenzentrum und beginnen, zwischen ihnen zu routen. Die Frage der Cross-Rechenzentrum-Replikation ist wirklich eine nicht triviale. Wir haben versucht, es damals mit verschiedenen Mitteln zu lösen: Wir haben versucht, dasselbe "Tarantula" zu verwenden – das hat bei uns nicht funktioniert, sage ich gleich. Deshalb sind wir zu der Entscheidung gekommen, dass wir die "Sensa" manuell bestellen. Jedes unserer Anwendungen führt tatsächlich die notwendige asynchrone Synchronisation "change – done" zwischen den Rechenzentren aus.

  Frage: – Wenn ihr das zweite habt, warum gibt es dann kein drittes? Weil Split-Brain ...

  EK: – Wir haben kein "Split-Brain". Da jede unserer Anwendungen ein Multi-Master-System verwendet, ist es für uns egal, in welches Rechenzentrum die Anfrage eingegangen ist. Wir sind darauf vorbereitet, dass, wenn unser erstes Rechenzentrum ausfällt (darauf legen wir Wert) und wir in der Mitte des Benutzeranfrages auf das zweite Rechenzentrum umschalten, wir tatsächlich diesen Benutzer verlieren können; aber das werden nur absolute Einzelereignisse sein.

  Frage: – Guten Abend. Danke für den Vortrag. Sie haben von Ihrem Debugger gesprochen, der in der Produktion einige Testtransaktionen ausführt. Können Sie uns mehr über die Testtransaktionen erzählen? Wie tief geht es da?

  EK: – Es durchläuft den vollständigen Zyklus der gesamten Komponente. Für die Komponente gibt es keinen Unterschied zwischen einer Testtransaktion und einer produktiven Transaktion. Aus Sicht der Logik ist es einfach ein separates Projekt im System, auf dem nur Testtransaktionen durchgeführt werden.

  Frage: – Wo schneiden Sie sie ab? Core hat gesendet...

  EK: – In diesem Fall следуем wir für die Testtransaktionen nach "Core"... Wir haben ein Konzept, das Routing heißt: "Core" weiß, in welches Zahlungssystem es senden muss – wir senden es an ein falsches Zahlungssystem, das einfach eine http-Antwort liefert und das war's.

  Frage: – Sagen Sie bitte, ist Ihre Anwendung als ein großes Monolith geschrieben oder haben Sie sie in einige Dienste oder sogar Mikrodienste unterteilt?

  EK: – Wir haben natürlich keinen Monolithen, unser System ist serviceorientiert. Es gibt einen Scherz, dass wir Monolith-Service haben – sie sind tatsächlich ziemlich groß. Es wäre nicht korrekt, sie als Mikrodienste zu bezeichnen, aber es sind definitiv Dienste, in denen Arbeiter auf verteilten Maschinen arbeiten.

  Wenn der Dienst auf dem Server kompromittiert ist…

  Frage: – Dann habe ich die nächste Frage. Selbst wenn es ein Monolith gewesen wäre, haben Sie trotzdem gesagt, dass Sie viele dieser Instant-Server haben, die im Grunde genommen Daten verarbeiten, und die Frage ist: „Bei der Kompromittierung eines der Instant-Server oder einer Anwendung, eines bestimmten Elements, gibt es dort eine Art Zugriffskontrolle? Wer kann was tun? An wen kann man sich wenden, um welche Daten zu erhalten?

  
  
  EK: – Ja, zweifellos. Die Sicherheitsanforderungen sind ziemlich streng. Erstens haben wir offene Datenbewegungen, und die Ports sind nur die, von denen wir im Voraus den Datenverkehr erwarten. Wenn ein Komponenten mit der Datenbank (sagen wir, mit MySQL) über 5-4-3-2 kommuniziert, werden nur 5-4-3-2 geöffnet, und andere Ports, andere Verkehrsrichtungen werden nicht zugänglich sein. Darüber hinaus muss man verstehen, dass es in der Produktion etwa 10 verschiedene Sicherheitszonen gibt. Und selbst wenn die Anwendung irgendwie kompromittiert wurde, Gott bewahre, kann der Angreifer keinen Zugang zur Server-Management-Konsole erhalten, weil dies eine andere Sicherheitszone ist.

  Frage: – In diesem Zusammenhang interessiert mich mehr der Punkt, dass Sie ja Verträge mit den Diensten haben – was sie tun dürfen, über welche „Aktionen“ sie miteinander kommunizieren können... In einem normalen Ablauf fragen bestimmte Dienste eine Reihe von „Aktionen“ von einem anderen an. Gegenüber anderen wenden sie sich normalerweise nicht, und sie haben andere Verantwortungsbereiche. Wenn jedoch einer von ihnen kompromittiert wird, kann er dann die „Aktionen“ des anderen Dienstes auslösen?...

  EK: – Ich verstehe. Wenn in einer normalen Situation mit einem anderen Server die Kommunikation überhaupt erlaubt war, dann – ja. Laut SLA-Vertrag monitorieren wir nicht, dass dir nur die ersten 3 "Aktionen" erlaubt sind, während dir die 4. "Aktion" nicht gestattet ist. Das ist für uns wahrscheinlich überflüssig, da wir sowieso ein 4-stufiges Schutzsystem für die Konturen haben. Wir ziehen es vor, durch Konturen zu schützen und nicht auf der Ebene der Inneren.

  Wie Visa, MasterCard und "Sberbank" funktionieren

  Frage: – Ich möchte den Punkt klären, wie der Benutzer von einem Rechenzentrum zu einem anderen wechselt. Soweit ich weiß, arbeiten "Visa" und "MasterCard" nach dem binären synchronen Protokoll 8583, und dort gibt es Mixe. Ich wollte wissen, ob sich die Umschaltung jetzt direkt auf "Visa" und "MasterCard" bezieht oder bis zu den Zahlungssystemen, bis hin zu den Prozessoren?

  EK: – Das sind bis zu den Mixen. Mixe haben wir in einem Rechenzentrum.

  Frage: – Im Großen und Ganzen habt ihr einen einzigen Verbindungspunkt?

  EK: – Für "Visa" und "MasterCard" – ja. Einfach weil "Visa" und "MasterCard" erhebliche Investitionen in die Infrastruktur erfordern, um separate Verträge für den Erhalt eines zweiten Paares von Mixen abzuschließen, zum Beispiel. Sie sind im Rahmen eines Rechenzentrums reserviert, aber falls unser Rechenzentrum, Gott bewahre, ausfällt, wo die Mixe für die Verbindung zu "Visa" und "MasterCard" stehen, wird die Verbindung zu "Visa" und "MasterCard" verloren gehen...

  Frage: – Wie können sie reserviert sein? Ich weiß, dass "Visa" grundsätzlich nur eine Verbindung erlaubt!

  EK: – Sie liefern die Ausrüstung selbst. Auf jeden Fall haben wir Ausrüstung erhalten, die intern redundanten Schutz hat.

  Frage: – Das heißt, das Rack von ihren Connects Orange..?

  EK: – Ja.

  Frage: – Wie ist es in diesem Fall: Wenn euer Rechenzentrum ausfällt, wie geht es dann weiter? Oder stoppt einfach der Verkehr?

  EK: – Nein. In diesem Fall schalten wir einfach den Verkehr auf einen anderen Kanal um, der uns natürlich teurer sein wird und auch teurer für die Kunden. Aber der Verkehr wird nicht über unsere direkte Verbindung zu "Visa", "MasterCard" gehen, sondern über eine hypothetische "Sberbank" (sehr vereinfacht).

  Ich entschuldige mich vielmals, falls ich Mitarbeiter von "Sberbank" beleidigt habe. Aber laut unserer Statistik fällt "Sberbank" am häufigsten im Vergleich zu anderen russischen Banken aus. Kein Monat vergeht, ohne dass bei "Sberbank" irgendetwas ausfällt.

  
  
  

  

  Ein wenig Werbung 🙂

  Danke, dass Sie bei uns bleiben. Gefallen Ihnen unsere Artikel? Möchten Sie mehr interessante Inhalte sehen? Unterstützen Sie uns, indem Sie eine Bestellung aufgeben oder uns Freunden empfehlen, Cloud-VPS für Entwickler ab 4,99 $, ein einzigartiges Äquivalent zu Einsteigerservern, das wir für Sie entwickelt haben: Die ganze Wahrheit über VPS (KVM) E5-2697 v3 (6 Kerne) 10GB DDR4 480GB SSD 1Gbps ab 19 $ oder wie man einen Server richtig teilt? (es sind Optionen mit RAID1 und RAID10 bis zu 24 Kernen und bis zu 40GB DDR4 verfügbar).

  Dell R730xd ist im Equinix Tier IV Rechenzentrum in Amsterdam doppelt so günstig? Nur bei uns 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TB ab $199 in den Niederlanden! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — ab $99! Lesen Sie, wie man eine Unternehmensinfrastruktur der Klasse C mit Dell R730xd E5-2650 v4-Servern für 9000 Euro im Preis-Leistungs-Verhältnis aufbaut?

Quelle: habr.com