Üst fakapov Cyan

Hamısı yaxşı! 

Mənim adım Nikita, mən Cian mühəndis komandasının komanda rəhbəriyəm. Şirkətdəki vəzifələrimdən biri də istehsalatda infrastrukturla bağlı insidentlərin sayını sıfıra endirməkdir.
Aşağıda müzakirə ediləcək şeylər bizə çox ağrı gətirdi və bu məqalənin məqsədi digər insanların səhvlərimizi təkrarlamasının qarşısını almaq və ya ən azı onların təsirini minimuma endirməkdir. 

Başlanğıc

Uzun müddət əvvəl, Cian monolitlərdən ibarət olanda və hələ mikroservislərə dair heç bir işarə yox idi, biz 3-5 səhifəni yoxlayaraq bir resursun mövcudluğunu ölçdük. 

Cavab verirlər - hər şey yaxşıdır, uzun müddət cavab verməsələr - xəbərdarlıq. Bunun insident sayılması üçün nə qədər işdən çıxmalı olduqlarını insanlar yığıncaqlarda qərar verdilər. Hadisənin təhqiqatına hər zaman mühəndislər qrupu cəlb edilib. İstintaq başa çatdıqdan sonra onlar postmortem yazdılar - e-poçt vasitəsilə bir növ hesabat formatında: nə baş verdi, nə qədər davam etdi, bu anda nə etdik, gələcəkdə nə edəcəyik. 

Saytın ana səhifələri və ya necə başa düşdüyünüzü dibinə vurduq

 
Xətanın prioritetini bir şəkildə başa düşmək üçün biz biznes funksionallığı üçün ən kritik sayt səhifələrini müəyyən etdik. Onlardan istifadə edərək, uğurlu/uğursuz sorğuların və fasilələrin sayını hesablayırıq. Biz iş vaxtını belə ölçürük. 

Deyək ki, saytın əsas xidmətə - reklamların axtarışına və təqdim edilməsinə cavabdeh olan bir sıra çox vacib bölmələrinin olduğunu bildik. Əgər uğursuz müraciətlərin sayı 1%-i keçərsə, bu, kritik bir hadisədir. Əgər prime time zamanı 15 dəqiqə ərzində səhv nisbəti 0,1%-i keçərsə, bu da kritik insident hesab olunur. Bu meyarlar hadisələrin əksəriyyətini əhatə edir, qalanları bu məqalənin əhatə dairəsindən kənardadır.

Ən yaxşı hadisələr Cyan

Beləliklə, bir hadisənin baş verdiyini müəyyən etməyi mütləq öyrəndik. 

İndi hər bir hadisə müfəssəl təsvir edilir və Jira dastanında öz əksini tapır. Yeri gəlmişkən: bunun üçün FAIL adlı ayrıca bir layihəyə başladıq - onda yalnız dastanlar yaradıla bilər. 

Son bir neçə il ərzində bütün uğursuzluqları toplasanız, liderlər bunlardır: 

• mssql ilə əlaqəli hadisələr;
• xarici amillərin səbəb olduğu hadisələr;
• admin səhvləri.

İdarəçilərin səhvlərinə, eləcə də bəzi digər maraqlı uğursuzluqlara daha ətraflı baxaq.

Beşinci yer - "DNS-də işləri qaydaya salmaq"

Fırtınalı çərşənbə axşamı idi. DNS klasterində nizamı bərpa etmək qərarına gəldik. 

Daxili DNS serverlərini bağlamadan powerdns-ə köçürmək istədim, bunun üçün DNS-dən başqa heç bir şey olmayan ayrı serverlər ayırdım. 

Biz DC-lərimizin hər yerində bir DNS serveri yerləşdirdik və zonaları bağlamadan powerdns-ə köçürmək və infrastrukturu yeni serverlərə keçirmək anı gəldi. 

Hərəkətin ortasında, bütün serverlərdə yerli keşləmə bağlanmalarında göstərilən bütün serverlərdən yalnız biri Sankt-Peterburqdakı məlumat mərkəzində qaldı. Bu DC əvvəlcə bizim üçün qeyri-kritik elan edildi, lakin birdən bir uğursuzluq nöqtəsinə çevrildi.
Məhz bu yerdəyişmə dövründə Moskva ilə Sankt-Peterburq arasındakı kanal uçub. Biz əslində beş dəqiqə ərzində DNS-siz qaldıq və hoster problemi həll edəndə yenidən ayağa qalxdıq. 

Sonuç:

Əgər əvvəllər işə hazırlaşarkən xarici amilləri nəzərdən qaçırırdıqsa, indi onlar da hazırlaşdığımız siyahıya daxil edilib. İndi biz bütün komponentlərin n-2 qorunub saxlanmasını təmin etməyə çalışırıq və iş zamanı bu səviyyəni n-1-ə endirə bilərik.

• Fəaliyyət planı tərtib edərkən, xidmətin uğursuz ola biləcəyi nöqtələri qeyd edin və əvvəlcədən hər şeyin "pisdən daha pisə" getdiyi bir ssenari üzərində düşünün.
• Daxili DNS serverlərini müxtəlif geolokasiyalar/məlumat mərkəzləri/rəflər/açarlar/girişlər arasında paylayın.
• Hər bir serverdə sorğuları əsas DNS serverlərinə yönləndirən yerli keşləmə DNS serveri quraşdırın və əgər o, mövcud deyilsə, o, keşdən cavab verəcək. 

Dördüncü yer - "Nginx-də işləri qaydaya salmaq"

Gözəl günlərin birində komandamız qərara gəldi ki, “bizdə kifayət qədər var” və nginx konfiqurasiyalarının yenidən qurulması prosesi başladı. Əsas məqsəd konfiqurasiyaları intuitiv bir quruluşa gətirməkdir. Əvvəllər hər şey “tarixi olaraq qurulmuşdu” və heç bir məntiq daşımırdı. İndi hər server_adı eyni adlı fayla köçürülüb və bütün konfiqurasiyalar qovluqlara paylanıb. Yeri gəlmişkən, konfiqurasiya 253949 sətir və ya 7836520 simvoldan ibarətdir və demək olar ki, 7 meqabayt tutur. Strukturun yuxarı səviyyəsi: 

Nginx quruluşu

├── 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

Bu, daha yaxşı oldu, lakin konfiqurasiyaların adının dəyişdirilməsi və paylanması prosesində onlardan bəziləri yanlış genişlənməyə malik idi və *.conf direktivinə daxil edilmədi. Nəticədə bəzi hostlar əlçatmaz oldu və 301-i əsas səhifəyə qaytardı. Cavab kodunun 5xx/4xx olmaması səbəbindən bu dərhal deyil, səhər saatlarında fərq edildi. Bundan sonra biz infrastruktur komponentlərini yoxlamaq üçün testlər yazmağa başladıq.

Sonuç: 

• Konfiqurasiyalarınızı düzgün strukturlaşdırın (yalnız nginx deyil) və layihənin ilkin mərhələsində strukturu düşünün. Bu yolla siz onları komanda üçün daha başa düşülən edəcəksiniz, bu da öz növbəsində TTM-ni azaldacaq.
• Bəzi infrastruktur komponentləri üçün testlər yazın. Məsələn: bütün açar server_adlarının düzgün status + cavab orqanı verdiyini yoxlamaq. Səhər saat 3-də başqa nə yoxlamaq lazım olduğunu xatırlamamaq üçün komponentin əsas funksiyalarını yoxlayan bir neçə skriptin olması kifayətdir. 

Üçüncü yer - "Kassandrada birdən yer tükəndi"

Məlumatlar durmadan böyüdü və Cassandra klasterində böyük korpusların təmiri uğursuzluğa düçar olana qədər hər şey qaydasında idi, çünki sıxılma onlarda işləyə bilməzdi. 

Bir fırtınalı gündə klaster az qala balqabaq halına gəldi, yəni:

• klasterdə ümumi yerin təxminən 20% -i qaldı;
• Düyünləri tam əlavə etmək mümkün deyil, çünki arakəsmələrdə yer olmaması səbəbindən bir node əlavə etdikdən sonra təmizləmə keçmir;
• sıxılma işləmədiyi üçün məhsuldarlıq tədricən azalır; 
• Klaster fövqəladə rejimdədir.

Çıxış - təmizlənmədən daha 5 qovşaq əlavə etdik, bundan sonra onları sistematik olaraq klasterdən çıxarmağa və yer bitmiş boş qovşaqlar kimi yenidən daxil etməyə başladıq. İstədiyimizdən daha çox vaxt sərf olundu. Klasterin qismən və ya tam əlçatmazlığı riski var idi. 

Sonuç:

• Bütün cassandra serverlərində hər bölmədə yerin 60%-dən çoxu tutulmamalıdır. 
• Onlar 50% cpu-dan çox olmamaqla yüklənməlidirlər.
• Siz potensialın planlaşdırılmasını unutmamalısınız və onun xüsusiyyətlərinə əsaslanaraq hər bir komponent üçün düşünməlisiniz.
• Klasterdə nə qədər çox qovşaq olsa, bir o qədər yaxşıdır. Az miqdarda məlumat ehtiva edən serverlər daha sürətli yüklənir və belə bir klasteri canlandırmaq daha asandır. 

İkinci yer - "Konsulun açar-dəyər anbarından məlumat itdi"

Xidmət kəşfi üçün biz də bir çoxları kimi konsuldan istifadə edirik. Lakin biz onun açar-dəyərini monolitin mavi-yaşıl düzümü üçün də istifadə edirik. O, yerləşdirmə zamanı yerləri dəyişən aktiv və qeyri-aktiv yuxarı axınlar haqqında məlumatları saxlayır. Bu məqsədlə, KV ilə qarşılıqlı əlaqədə olan bir yerləşdirmə xidməti yazılmışdır. Bir anda KV-dən məlumatlar itdi. Yaddaşdan bərpa edildi, lakin bir sıra səhvlərlə. Nəticədə, yükləmə zamanı yuxarı axınlardakı yük qeyri-bərabər paylandı və arxa tərəflərin CPU-ya həddindən artıq yüklənməsi səbəbindən çoxlu 502 səhv aldıq. Nəticədə biz konsul KV-dən postqresə keçdik, oradan onları çıxarmaq artıq o qədər də asan deyil.  

Sonuç:

• Heç bir icazəsi olmayan xidmətlər saytın fəaliyyəti üçün kritik məlumatları ehtiva etməməlidir. Məsələn, ES-də avtorizasiyanız yoxdursa, lazım olmayan hər yerdən şəbəkə səviyyəsində girişi rədd etmək, yalnız zəruri olanları tərk etmək, həmçinin action.destructive_requires_name: true təyin etmək daha yaxşı olardı.
• Yedəkləmə və bərpa mexanizminizi əvvəlcədən məşq edin. Məsələn, ehtiyat nüsxəsini çıxara və bərpa edə bilən skripti əvvəlcədən hazırlayın (məsələn, pythonda).

Birinci yer - “Kapitan Unobvious” 

Bir nöqtədə, backenddə 10+ serverin olduğu hallarda nginx upstreams-də yükün qeyri-bərabər paylandığını gördük. Round-robin 1-dən axırıncı yuxarı axınına sorğu göndərdiyinə və hər bir nginx yenidən yüklənməsinə başlandığına görə, ilk yuxarı axınlar həmişə qalanlarına nisbətən daha çox sorğu alırdı.Nəticədə onlar daha yavaş işləyirdilər və bütün sayt zərər çəkdi. Trafikin miqdarı artdıqca bu, getdikcə nəzərə çarpırdı. Təsadüfi aktivləşdirmək üçün sadəcə nginx-i yeniləmək işə yaramadı - 1.15 versiyasında (o anda) çıxmayan bir dəstə lua kodunu yenidən etməliyik. Nginx 1.14.2-yə təsadüfi dəstək təqdim edərək yamaq etməli olduq. Bu problemi həll etdi. Bu səhv "Kapitan Qeyri-Aydınlıq" kateqoriyasını qazanır.

Sonuç:

Bu səhvi araşdırmaq çox maraqlı və həyəcanlı idi). 

• Monitorinqinizi elə təşkil edin ki, o, belə dalğalanmaları tez tapmağınıza kömək etsin. Məsələn, hər bir yuxarı axının hər bir arxa ucunda rps-ə nəzarət etmək, nginx baxımından onların cavab müddətinə nəzarət etmək üçün ELK-dan istifadə edə bilərsiniz. Bu vəziyyətdə bu, problemi müəyyənləşdirməyə kömək etdi. 

Nəticə etibarilə, etdiyiniz işlərə daha ciddi yanaşma ilə uğursuzluqların çoxunun qarşısını almaq olardı. Mörfi qanununu həmişə xatırlamalıyıq: Səhv gedəcək hər şey səhv gedəcək, və onun əsasında komponentlər qurur. 

Mənbə: www.habr.com