Top Fakapov Cyan

Gutt un all! 

Mäin Numm ass Nikita, ech sinn den Teamleader vum Cian Ingenieursteam. Eng vu menge Verantwortung bei der Firma ass d'Zuel vun den Tëschefäll am Zesummenhang mat der Infrastruktur an der Produktioun op Null ze reduzéieren.
Wat hei drënner diskutéiert gëtt huet eis vill Péng bruecht, an den Zweck vun dësem Artikel ass et ze verhënneren datt aner Leit eis Feeler widderhuelen oder op d'mannst hiren Impakt minimiséieren. 

Präambel

Virun enger laanger Zäit, wéi de Cian aus Monolithen bestoung, an et waren nach keng Hiweiser vu Mikroservicer, hu mir d'Disponibilitéit vun enger Ressource gemooss andeems Dir 3-5 Säiten iwwerpréift. 

Si äntweren - alles ass gutt, wa se net laang äntweren - alert. Wéi laang si hu misse vun der Aarbecht sinn, fir datt et als Tëschefall ugesi gëtt, gouf vun de Leit a Versammlungen decidéiert. Eng Equipe vun Ingenieuren war ëmmer an der Enquête vum Tëschefall involvéiert. Wéi d'Enquête ofgeschloss war, hunn se en Postmortem geschriwwen - eng Aart Bericht per E-Mail am Format: wat ass geschitt, wéi laang et gedauert huet, wat mir am Moment gemaach hunn, wat mir an Zukunft maachen. 

D'Haaptsäiten vum Site oder wéi mir verstinn datt mir de Buedem getraff hunn

 
Fir iergendwéi d'Prioritéit vum Feeler ze verstoen, hu mir déi kriteschste Site Säiten fir d'Geschäftsfunktionalitéit identifizéiert. Mat hinnen zielen mir d'Zuel vun erfollegräichen / net erfollegräichen Ufroen an Timeouts. Dëst ass wéi mir Uptime moossen. 

Loosst d'soen mir erausfonnt, datt et eng Rei vun super-wichteg Rubriken vun der Säit sinn, datt fir den Haapt Service responsabel sinn - Sich a Reklammen ofginn. Wann d'Zuel vun den Ufroen déi versoen 1% iwwerschreift, ass dëst e kriteschen Tëschefall. Wann bannent 15 Minutten während der Prime Time de Fehlerquote méi wéi 0,1% iwwerschreift, da gëtt dëst och als kriteschen Tëschefall ugesinn. Dës Critèren decken déi meescht Tëschefäll; de Rescht sinn iwwer den Ëmfang vun dësem Artikel.

Top beschte Tëschefäll Cyan

Also, mir hunn definitiv geléiert d'Tatsaach ze bestëmmen datt en Tëschefall geschitt ass. 

Elo gëtt all Tëschefall am Detail beschriwwen an am Jira Epos reflektéiert. Iwwregens: dofir hu mir e separate Projet gestart, deen et FAIL genannt gëtt - nëmmen Epos kënnen dran erstallt ginn. 

Wann Dir all Feeler an de leschte Joeren sammelt, sinn d'Leader: 

• mssql Zesummenhang Tëschefäll;
• Tëschefäll verursaacht duerch extern Faktoren;
• admin Feeler.

Loosst eis méi detailléiert op d'Feeler vun den Administrateuren kucken, wéi och e puer aner interessant Feeler.

Fënneften Plaz - "Saachen an der DNS an Uerdnung setzen"

Et war e stiermeschen Dënschdeg. Mir hunn decidéiert d'Uerdnung am DNS-Cluster ze restauréieren. 

Ech wollt intern DNS-Server vu Bind op Powerdns transferéieren, fir dëst komplett getrennte Server ze verdeelen, wou et näischt ass ausser DNS. 

Mir hunn en DNS-Server op all Plaz vun eisen DCs plazéiert, an de Moment ass komm fir Zonen vu Bind op Powerdns ze réckelen an d'Infrastruktur op nei Serveren ze wiesselen. 

An der Mëtt vun der Beweegung, vun all de Serveren, déi am lokalen Cache-Bindungen op all Server präziséiert goufen, blouf nëmmen een, deen am Rechenzentrum zu St. Dësen DC gouf am Ufank als net kritesch fir eis deklaréiert, awer gouf op eemol en eenzege Punkt vum Echec.
Et war während dëser Period vun Ëmsetzung datt de Kanal tëscht Moskau a St. Mir waren tatsächlech fënnef Minutten ouni DNS gelooss a sinn erëm opgaang wéi den Hoster de Problem fixéiert huet. 

Konklusiounen:

Wa mir fréier extern Faktoren während der Virbereedung op d'Aarbecht vernoléissegt hunn, sinn se elo och an der Lëscht vun deem wat mir virbereeden. An elo beméien mir eis ze garantéieren datt all Komponente reservéiert sinn n-2, a während der Aarbecht kënne mir dësen Niveau op n-1 erofsetzen.

• Wann Dir en Aktiounsplang opstellt, markéiert d'Punkten, wou de Service ka falen, an denkt am Viraus en Szenario duerch, wou alles "vu schlecht op méi schlëmm" gaangen ass.
• Verdeelt intern DNS Server iwwer verschidde Geolocatiounen / Datenzenteren / Racken / Schalteren / Inputen.
• Op all Server installéiert e lokalen Caching DNS-Server, deen Ufroen op d'Haapt-DNS-Server viruleet, a wann et net verfügbar ass, reagéiert se aus dem Cache. 

Véiert Plaz - "Saachen an Uerdnung setzen am Nginx"

Ee schéinen Dag huet eis Team decidéiert datt "mir hunn genuch vun dësem", an de Prozess vun der Refaktoréierung vun nginx Konfiguratiounen huet ugefaang. D'Haaptziel ass d'Konfiguratioun an eng intuitiv Struktur ze bréngen. Virdrun war alles "historesch etabléiert" an huet keng Logik. Elo ass all Server_name an eng Datei mam selwechten Numm geplënnert an all Konfiguratioune goufen an Ordner verdeelt. Iwwregens enthält d'Konfiguratioun 253949 Zeilen oder 7836520 Zeechen an hëlt bal 7 Megabytes. Top Niveau vun der Struktur: 

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

Et gouf vill besser, mä am Prozess vun ëmbenennen an Verdeelung configs, e puer vun hinnen haten déi falsch Extensioun a waren net an der include *.conf Direktiven abegraff. Als Resultat sinn e puer Hosten net verfügbar an hunn 301 op d'Haaptsäit zréckginn. Wéinst der Tatsaach, datt den Äntwertcode net 5xx/4xx war, gouf dat net direkt gemierkt, mä just moies. Duerno hu mir ugefaang Tester ze schreiwen fir Infrastrukturkomponenten ze kontrolléieren.

Konklusiounen: 

• Strukturéiert Är Konfiguratiounen korrekt (net nëmmen nginx) an denkt duerch d'Struktur an enger fréicher Etapp vum Projet. Sou wäert Dir se fir d'Equipe méi verständlech maachen, wat am Tour den TTM reduzéiert.
• Schreift Tester fir e puer Infrastrukturkomponenten. Zum Beispill: Iwwerpréift datt all Schlëssel Server_names de richtege Status + Äntwert Kierper ginn. Et wäert genuch sinn just e puer Scripten op der Hand ze hunn, déi d'Basisfunktiounen vun der Komponent iwwerpréiwen, fir net frantesch um 3 Auer ze erënneren wat soss kontrolléiert muss ginn. 

Drëtt Plaz - "Plötzlech ass de Raum an der Cassandra ausgaang"

D'Daten sinn stänneg gewuess, an alles war gutt bis de Moment wou d'Reparatur vu grousse Kofferraum am Cassandra-Cluster ugefaang huet ze versoen, well d'Verdichtung net op hinnen funktionnéiert. 

Ee stiermeschen Dag huet de Stärekoup bal zu engem Kürbis verwandelt, nämlech:

• et waren ongeféier 20% vum Gesamtraum am Stärekoup lénks;
• Et ass onméiglech fir komplett Wirbelen ze addéieren, well d'Botzen net duerchgeet nodeems Dir e Knuet bäigefüügt huet wéinst Mangel u Plaz op de Partitionen;
• Produktivitéit fällt lues a lues well d'Verdichtung net funktionnéiert; 
• De Cluster ass am Noutmodus.

Exit - mir hunn 5 méi Wirbelen ouni Botzen bäigefüügt, duerno hu mir ugefaang se systematesch aus dem Cluster ze entfernen an erëm anzeginn, wéi eidel Knäppercher déi aus dem Raum gelaf sinn. Vill méi Zäit gouf verbruecht wéi mir wëllen. Et war e Risiko fir deelweis oder komplett Onverfügbarkeet vum Cluster. 

Konklusiounen:

• Op all Cassandra Server sollten net méi wéi 60% vum Raum op all Partition besat sinn. 
• Si sollten net méi wéi 50% CPU gelueden ginn.
• Dir sollt d'Kapazitéitsplanung net vergiessen a musst et fir all Komponent nodenken, baséiert op seng Spezifizitéiten.
• Wat méi Noden am Stärekoup, wat besser. Serveren, déi eng kleng Quantitéit un Daten enthalen, gi méi séier iwwerlaascht, an esou e Cluster ass méi einfach ze beliewen. 

Zweet Plaz - "Daten verschwonnen aus Konsul Schlësselwäert Stockage"

Fir Service Entdeckung, mir, wéi vill, benotzen Konsul. Awer mir benotzen och säi Schlësselwäert fir blo-gréng Layout vum Monolith. Et späichert Informatioun iwwer aktiv an inaktiv Upstream, déi Plazen wärend der Deployment änneren. Fir dësen Zweck gouf en Détachement Service geschriwwen, deen mat KV interagéiert. Irgendwann sinn d'Donnéeë vum KV verschwonnen. Restauréiert aus Erënnerung, awer mat enger Rei vu Feeler. Als Resultat, wärend der Eroplueden, gouf d'Laascht op den Upstreams ongläich verdeelt, a mir krute vill 502 Feeler wéinst de Backends op der CPU iwwerlaascht. Als Resultat si mir vum Konsul KV op Postgres geplënnert, vu wou et net méi sou einfach ass, se ze läschen.  

Konklusiounen:

• Servicer ouni Autorisatioun däerfen keng Daten enthalen déi kritesch sinn fir d'Operatioun vum Site. Zum Beispill, wann Dir keng Autorisatioun an ES hutt, wier et besser, den Zougang um Netzwierkniveau vun iwwerall ze refuséieren, wou et net néideg ass, nëmmen déi néideg verloossen, an och action.destructive_requires_name setzen: wouer.
• Praxis Äre Backup- an Erhuelungsmechanismus am Viraus. Zum Beispill, maachen e Skript am Viraus (zum Beispill, am Python) datt Backupsatellit kann a restauréiert.

Éischt Plaz - "Captain Unobvious" 

Irgendwann hu mir eng ongläich Verdeelung vun der Belaaschtung op nginx Upstreams gemierkt a Fäll wou et 10+ Serveren am Backend waren. Wéinst der Tatsaach, datt de Round-Robin Ufroe vun 1. bis de leschte Upstream an Uerdnung geschéckt huet, an all nginx Reload ugefaang huet, kruten déi éischt Upstreams ëmmer méi Ufroe wéi déi aner, doduerch hunn se méi lues geschafft an de ganze Site huet gelidden. Dëst gouf ëmmer méi bemierkbar wéi de Betrag vum Traffic eropgaang ass. Einfach nginx aktualiséieren fir zoufälleg z'aktivéieren huet net geschafft - mir mussen e puer lua Code nei maachen, deen net op der Versioun 1.15 (zu deem Moment) ofgeholl huet. Mir hu missen eisen nginx 1.14.2 patchen, zoufälleg Ënnerstëtzung an et aféieren. Dëst huet de Problem geléist. Dëse Feeler gewënnt d'Kategorie "Captain Non-Obviousness".

Konklusiounen:

Et war ganz interessant a spannend dëse Käfer ze entdecken). 

• Organiséiert Är Iwwerwaachung sou datt et Iech hëlleft esou Schwankungen séier ze fannen. Zum Beispill kënnt Dir ELK benotzen fir rps op all Backend vun all Upstream ze iwwerwaachen, hir Äntwertzäit aus der Siicht vun nginx ze iwwerwaachen. An dësem Fall huet dëst eis gehollef de Problem z'identifizéieren. 

Als Resultat konnten déi meescht vun de Feeler vermeit ginn mat enger méi suergfälteg Approche fir wat Dir maacht. Mir mussen ëmmer dem Murphy säi Gesetz erënneren: Alles wat falsch ka goen wäert falsch goen, a bauen Komponente baséiert op et. 

Source: will.com