🗽 🚆 👩🏿‍🏭 Top Fakapov Cyan 🏙️ 🏰 🗨️

Gut zu allen!

Mein Name ist Nikita, ich bin Teamleiter der Cyan-Ingenieure. Eine meiner Aufgaben im Unternehmen ist es, die Anzahl der Vorfälle im Zusammenhang mit der Infrastruktur auf dem Produkt auf Null zu reduzieren.
Was später besprochen wird, hat uns viel Schmerz bereitet, und der Zweck dieses Artikels ist es, andere Menschen daran zu hindern, unsere Fehler zu wiederholen oder zumindest ihre Auswirkungen zu minimieren.

Präambel

Es war einmal, als Cyan aus Monolithen bestand und es noch keine Hinweise auf Mikrodienste gab. Wir haben die Verfügbarkeit der Ressource durch Überprüfen von 3-5 Seiten gemessen.

Antwort - alles ist in Ordnung, antworten Sie nicht lange - Alarm. Wie viel Zeit sie nicht arbeiten sollten, damit dies als Vorfall betrachtet wird, entschieden die Leute bei Besprechungen. Ein Team von Ingenieuren war immer an der Untersuchung des Vorfalls beteiligt. Als die Untersuchung abgeschlossen war, schrieben sie eine Obduktion - eine Art Bericht an die Post in dem Format: Was war, wie lange, was wurde im Moment getan, was wird in Zukunft getan werden.

Die Hauptseiten der Website oder wie wir es verstehen, haben den Boden gebrochen

Um die Priorität des Fehlers irgendwie zu verstehen, haben wir die wichtigsten Seiten der Website für die Geschäftsfunktionalität hervorgehoben. Demnach berücksichtigen wir die Anzahl erfolgreicher / erfolgloser Anfragen und Timeouts. Also messen wir die Betriebszeit.

Nehmen wir an, wir finden heraus, dass es eine Reihe sehr wichtiger Bereiche auf der Website gibt, die für den Hauptdienst verantwortlich sind - die Suche und Einreichung von Ankündigungen. Wenn die Anzahl der fehlgeschlagenen Anforderungen mehr als 1% beträgt, ist dies ein kritischer Vorfall. Wenn der Prozentsatz der Fehler innerhalb von 15 Minuten zur Hauptsendezeit 0,1% überschreitet, wird dies ebenfalls als kritischer Vorfall angesehen. Diese Kriterien decken die meisten Vorfälle ab, der Rest geht über den Rahmen dieses Artikels hinaus.

Top besten Cyan Vorfälle

Wir haben also genau gelernt, festzustellen, dass der Vorfall passiert ist.

Jetzt wird jeder Vorfall in unserem Land detailliert beschrieben und im Jira-Epos widergespiegelt. Übrigens: Dafür haben wir ein separates Projekt namens FAIL gestartet - darin können nur Epen erstellt werden.

Wenn Sie alle Fehler der letzten Jahre sammeln, sind die Führer:

mssql-bezogene Vorfälle;
Vorfälle durch externe Faktoren;
Admin-Fehler.

Lassen Sie uns näher auf die Fehler von Admins sowie auf einige andere interessante Fehler eingehen.

Fünfter Platz - "Bestellung im DNS aufgeben"

Es war ein regnerischer Dienstag. Wir haben beschlossen, den DNS-Cluster zu bereinigen.

Ich wollte die internen DNS-Server von bind auf powerdns übertragen und dabei völlig separate Server hervorheben, auf denen es außer DNS nichts gibt.

Wir haben an jedem Standort unserer Domänencontroller einen DNS-Server platziert, und der Moment kam, als die Zonen von Bind zu PowerDNS verschoben und die Infrastruktur auf neue Server umgestellt wurden.

Auf dem Höhepunkt des Umzugs befand sich von allen Servern, die in der lokalen Caching-Bindung auf allen Servern angegeben waren, nur einer im Rechenzentrum in St. Petersburg. Dieser DC wurde ursprünglich für uns als unkritisch deklariert, wurde aber plötzlich zu einem einzigen Fehlerpunkt.
Gerade während einer solchen Umsiedlungsperiode fiel der Kanal zwischen Moskau und St. Petersburg. Wir blieben tatsächlich fünf Minuten ohne DNS und standen auf, als der Hoster die Probleme behebte.

Schlussfolgerungen:

Wenn wir bei der Vorbereitung der Arbeit früher externe Faktoren vernachlässigt haben, sind diese jetzt auch in der Liste der Vorbereitungen enthalten. Und jetzt bemühen wir uns sicherzustellen, dass alle Komponenten n-2 reserviert sind, und für die Dauer der Arbeit können wir dieses Niveau auf n-1 senken.

Markieren Sie bei der Erstellung eines Aktionsplans die Punkte, an denen der Dienst möglicherweise ausfällt, und überlegen Sie sich im Voraus das Szenario, in dem alles „schlimmer als nirgendwo“ gelaufen ist.
Verteilen Sie interne DNS-Server nach verschiedenen Standorten / Rechenzentren / Racks / Switches / Eingängen.
Legen Sie auf jedem Server einen lokalen DNS-Caching-Server ab, der Anforderungen an die wichtigsten DNS-Server umleitet. Wenn dieser nicht verfügbar ist, antwortet er aus dem Cache.

Vierter Platz - "Nginx aufräumen"

Eines schönen Tages entschied unser Team, dass „genug, um es auszuhalten“, und der Prozess der Umgestaltung von Nginx-Konfigurationen begann. Das Hauptziel ist es, Konfigurationen in eine intuitive Struktur zu bringen. Zuvor war alles „historisch etabliert“ und es gab keine Logik an sich. Jetzt wurde jeder Servername in die gleichnamige Datei aufgenommen und alle Konfigurationen in Ordnern verteilt. Die Konfiguration enthält übrigens 253949 Zeilen oder 7836520 Zeichen und nimmt fast 7 Megabyte ein. Struktur der obersten Ebene:

Nginx-Struktur

├── access
│   ├── allow.list
...
│   └── whitelist.conf
├── geobase
│   ├── exclude.conf
...
│   └── geo_ip_to_region_id.conf
├── geodb
│   ├── GeoIP.dat
│   ├── GeoIP2-Country.mmdb
│   └── GeoLiteCity.dat
├── inc
│   ├── error.inc
...
│   └── proxy.inc
├── lists.d
│   ├── bot.conf
...
│   ├── dynamic
│   └── geo.conf
├── lua
│   ├── cookie.lua
│   ├── log
│   │   └── log.lua
│   ├── logics
│   │   ├── include.lua
│   │   ├── ...
│   │   └── utils.lua
│   └── prom
│       ├── stats.lua
│       └── stats_prometheus.lua
├── map.d
│   ├── access.conf
│   ├── .. 
│   └── zones.conf
├── nginx.conf
├── robots.txt
├── server.d
│   ├── cian.ru
│   │   ├── cian.ru.conf
│   │   ├── ...
│   │   └── my.cian.ru.conf
├── service.d
│   ├── ...
│   └── status.conf
└── upstream.d
    ├── cian-mcs.conf
    ├── ...
    └── wafserver.conf

Es wurde viel besser, aber beim Umbenennen und Verteilen der Konfigurationen hatten einige von ihnen die falsche Erweiterung und fielen nicht in die include * .conf-Direktive. Infolgedessen war ein Teil der Hosts nicht mehr verfügbar und gab 301 an den Haupt-Host zurück. Aufgrund der Tatsache, dass der Antwortcode nicht 5xx / 4xx war, wurde dies nicht sofort bemerkt, sondern nur am Morgen. Danach haben wir begonnen, Tests zum Testen von Infrastrukturkomponenten zu schreiben.

Ergebnisse:

Strukturieren Sie Konfigurationen richtig (nicht nur Nginx) und denken Sie in einem frühen Stadium des Projekts über die Struktur nach. So machen Sie sie für das Team verständlicher, was wiederum die TTM verringert.
Schreiben Sie für einige Infrastrukturkomponenten Tests. Beispiel: Überprüfen Sie, ob alle wichtigen Servernamen den richtigen Status + Antworttext zurückgeben. Es reicht aus, nur ein paar Skripte zur Hand zu haben, die die Grundfunktionen der Komponente überprüfen, damit Sie sich nicht um 3 Uhr morgens daran erinnern, was noch überprüft werden muss.

Dritter Platz - "Plötzlich beendeter Platz in Cassandra"

Die Daten wuchsen stetig und alles war in Ordnung, bis die Reparatur großer Fälle in den Cassandra-Cluster fiel, weil die Komprimierung nicht funktionieren konnte.

An einem regnerischen Tag verwandelte sich der Haufen fast in einen Kürbis, nämlich:

Plätze blieben etwa 20% des gesamten Clusters;
Es ist unmöglich, Knoten vollständig hinzuzufügen, da die Bereinigung nach dem Hinzufügen eines Knotens aufgrund von Platzmangel auf Partitionen nicht funktioniert.
Die Leistung nimmt leicht ab, da die Verdichtung nicht funktioniert.
Der Cluster befindet sich im Notfallmodus.

Beenden - fügte weitere 5 Knoten ohne Bereinigung hinzu. Danach wurden sie systematisch aus dem Cluster entfernt und als leere Knoten, auf denen der Ort endete, erneut eingegeben. Die Zeit verbrachte viel mehr als wir möchten. Es bestand die Gefahr einer teilweisen oder vollständigen Unzugänglichkeit des Clusters.

Ergebnisse:

Alle Cassandra-Server sollten nicht mehr als 60% des Speicherplatzes auf jeder Partition einnehmen.
Sie sollten nicht mehr als 50% CPU geladen sein.
Verstopfen Sie nicht die Kapazitätsplanung und denken Sie für jede Komponente anhand ihrer Besonderheiten nach.
Je mehr Knoten im Cluster vorhanden sind, desto besser. Server mit einer geringen Datenmenge werden schneller migriert, und ein solcher Cluster lässt sich leichter wiederbeleben.

Zweiter Platz - „Daten aus dem Schlüsselwertspeicher des Konsuls sind verschwunden“

Für die Serviceerkennung verwenden wir, wie viele andere auch, den Konsul. Hier wird sein Schlüsselwert aber auch für blau-grüne Monolithenberechnungen verwendet. Es speichert Informationen zu aktiven und inaktiven Upstreams, die während der Bereitstellung die Position wechseln. Zu diesem Zweck wurde ein Bereitstellungsdienst geschrieben, der mit KV interagierte. Irgendwann verschwanden die Daten von KV. Aus dem Speicher wiederhergestellt, jedoch mit einer Reihe von Fehlern. Infolgedessen war die Last im Upstream während der Berechnung ungleichmäßig verteilt, und wir haben viele 502 Fehler aufgrund der Überlastung der Backends auf der CPU erhalten. Infolgedessen sind wir vom Konsul KV zu Postgres gewechselt, von wo aus es nicht so einfach ist, sie zu entfernen.

Ergebnisse:

- . , ES — , , , action.destructive_requires_name: true.
. , ( , python), .

— « »

Irgendwann stellten wir eine ungleichmäßige Lastverteilung auf dem Nginx-Upstream fest, wenn sich im Backend mehr als 10 Server befanden. Aufgrund der Tatsache, dass Round-Robin Anfragen von 1 bis zum letzten Upstream in der richtigen Reihenfolge sendete und jedes Nginx-Reload von Anfang an begann, hatte der erste Upstream immer mehr Anfragen als der Rest. Infolgedessen arbeiteten sie langsamer und die gesamte Site litt darunter. Dies machte sich mit zunehmendem Verkehrsaufkommen bemerkbar. Nur Nginx zu aktualisieren, um Random zu aktivieren, hat nicht funktioniert - Sie müssen eine Reihe von Lua-Code wiederholen, der in Version 1.15 (zu diesem Zeitpunkt) nicht gestartet wurde. Ich musste unser Nginx 1.14.2 patchen und zufällige Unterstützung einführen. Dies löste das Problem. Dieser Fehler gewinnt die Nominierung "Captain Non-Offensichtlichkeit".

Schlussfolgerungen:

Es war sehr interessant und aufregend, diesen Fehler zu untersuchen.

Richten Sie die Überwachung so ein, dass solche Schwankungen schnell erkannt werden können. Sie können beispielsweise ELK verwenden, um die RPS auf jedem Backend jedes Upstreams zu überwachen und ihre Antwortzeit aus Sicht von Nginx zu überwachen. In diesem Fall hat es uns geholfen, das Problem zu identifizieren.

Infolgedessen hätten die meisten Fehler mit einer gewissenhafteren Herangehensweise an das, was Sie tun, vermieden werden können. Sie müssen sich immer an das Murphy-Gesetz erinnern: Alles, was schief gehen kann, wird schief gehen und darauf basierende Komponenten bauen.

Top Fakapov Cyan