Top fakapov Cyan

Saé kanggo sadayana! 

Nami abdi Nikita, abdi pamingpin tim ti tim teknik Cian. Salah sahiji tanggung jawab kuring di perusahaan nyaéta ngirangan jumlah insiden anu aya hubunganana sareng infrastruktur dina produksi janten nol.
Naon anu bakal dibahas di handap nyababkeun urang nyeri pisan, sareng tujuan tulisan ieu nyaéta pikeun nyegah jalma sanés ngulang kasalahan urang atanapi sahenteuna ngaminimalkeun dampakna. 

Mukadimah

Baheula, nalika Cian diwangun ku monoliths, sareng teu acan aya petunjuk ngeunaan microservices, urang ngukur kasadiaan sumberdaya ku pariksa 3-5 halaman. 

Aranjeunna ngajawab - sagalana henteu kunanaon, lamun maranéhna teu ngajawab keur lila - waspada. Sabaraha lami aranjeunna kedah pareum kanggo éta dianggap kajadian diputuskeun ku jalma-jalma dina rapat. Hiji tim insinyur sok kalibet dina panalungtikan kajadian. Nalika panalungtikan réngsé, aranjeunna nyerat postmortem - jinis laporan ku email dina format: naon anu kajantenan, sabaraha lami éta, naon anu urang laksanakeun ayeuna, naon anu bakal urang laksanakeun ka hareup. 

Kaca utama situs atanapi kumaha urang ngartos yen kami geus pencét handap

 
Dina raraga kumaha bae ngartos prioritas kasalahan, kami geus ngaidentifikasi kaca situs paling kritis pikeun fungsionalitas bisnis. Ngagunakeun aranjeunna, urang ngitung jumlah requests suksés / gagal jeung timeouts. Ieu kumaha urang ngukur uptime. 

Hayu urang terang yén aya sababaraha bagian anu paling penting dina situs anu tanggung jawab pikeun jasa utama - milarian sareng ngirimkeun pariwara. Lamun jumlah requests nu gagal ngaleuwihan 1%, ieu téh kajadian kritis. Upami dina 15 menit dina waktos prima laju kasalahan ngaleuwihan 0,1%, maka ieu ogé dianggap insiden kritis. Kriteria ieu nyertakeun sabagéan ageung kajadian; sésana aya di luar ruang lingkup artikel ieu.

Top kajadian pangalusna Cian

Ku kituna, urang geus pasti diajar nangtukeun kanyataan yén hiji kajadian lumangsung. 

Ayeuna unggal kajadian dijelaskeun sacara rinci sareng ditingali dina epik Jira. Ngomong-ngomong: pikeun ieu kami ngamimitian proyék anu misah, anu disebut FAIL - ngan ukur epik anu tiasa didamel di jerona. 

Upami anjeun ngumpulkeun sadaya kagagalan dina sababaraha taun katukang, pamimpinna nyaéta: 

• insiden patali mssql;
• kajadian disababkeun ku faktor éksternal;
• kasalahan admin.

Hayu urang nempo leuwih jéntré kasalahan pangurus, kitu ogé sababaraha gagal metot séjén.

Tempat kalima - "Nempatkeun hal dina urutan dina DNS"

Ieu Salasa ribut. Kami mutuskeun mulangkeun pesenan dina kluster DNS. 

Kuring hayang nransper server DNS internal tina meungkeut powerdns, allocating server lengkep misah pikeun ieu, dimana aya nanaon iwal DNS. 

Urang nempatkeun hiji server DNS di unggal lokasi DCs kami, sarta momen sumping ka mindahkeun zona ti meungkeut powerdns sarta pindah infrastruktur ka server anyar. 

Di satengahing move, sadaya server anu dieusian dina cache lokal ngiket dina sagala server, ngan hiji tetep, nu aya di puseur data di St. DC ieu mimitina dinyatakeun salaku non-kritis pikeun urang, tapi ujug-ujug jadi titik tunggal gagal.
Dina mangsa relokasi ieu terusan antara Moscow jeung St. Kami saleresna ditinggalkeun tanpa DNS salami lima menit sareng nyadangkeun nalika hoster ngalereskeun masalahna. 

conclusions:

Lamun saméméhna kami neglected faktor éksternal salila persiapan pikeun digawé, ayeuna maranéhna ogé kaasup dina daptar naon urang nyiapkeun. Tur ayeuna urang narékahan pikeun mastikeun yén sakabéh komponén ditangtayungan n-2, sarta salila gawé bisa nurunkeun tingkat ieu n-1.

• Nalika nyusun rencana aksi, cirian titik-titik dimana jasa éta tiasa gagal, sareng pikirkeun skenario dimana sadayana "ti goréng ka parah" sateuacanna.
• Nyebarkeun server DNS internal sakuliah geolocations béda / puseur data / rak / switch / inputs.
• Dina unggal server, pasang server DNS cache lokal, anu alihan pamundut ka server DNS utama, sareng upami henteu sayogi, éta bakal ngabales tina cache. 

Tempat kaopat - "Ngatur barang dina Nginx"

Hiji dinten anu saé, tim kami mutuskeun yén "kami parantos cekap ieu," sareng prosés refactoring nginx configs dimimitian. Tujuan utama nya éta mawa configs kana struktur intuitif. Saméméhna, sagalana geus "sajarah ngadegkeun" na teu ngandung logika nanaon. Ayeuna unggal server_name parantos dipindahkeun ka file anu sami sareng sadaya konfigurasi parantos disebarkeun kana polder. Ku jalan kitu, config ngandung 253949 garis atawa 7836520 karakter jeung nyokot nepi ampir 7 megabyte. Tingkat luhur struktur: 

Struktur Nginx

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

Éta janten langkung saé, tapi dina prosés ngarobih nami sareng ngadistribusikaeun konfigurasi, sababaraha di antarana ngagaduhan ekstensi anu salah sareng henteu kalebet kana * .conf diréktif. Hasilna, sababaraha host janten teu sadia tur balik 301 ka kaca utama. Alatan kanyataan yén kode respon teu 5xx / 4xx, ieu teu noticed langsung, tapi ngan isuk-isuk. Saatos éta, urang ngamimitian nyerat tés pikeun mariksa komponén infrastruktur.

conclusions: 

• Struktur configs anjeun leres (sanes ngan nginx) jeung pikir ngaliwatan struktur dina tahap awal proyek. Ku cara ieu anjeun bakal ngajantenkeun aranjeunna langkung kaharti ku tim, anu bakal ngirangan TTM.
• Tulis tés pikeun sababaraha komponén infrastruktur. Contona: mariksa yen sakabeh server_names konci méré status bener + awak respon. Ieu bakal cukup ngan boga sababaraha Aksara dina leungeun nu pariksa fungsi dasar komponén, ku kituna teu frantically apal di 3:XNUMX naon nu sejenna kudu dipariksa. 

Tempat katilu - "Ujug-ujug béak rohangan di Cassandra"

data tumuwuh steadily, sarta sagalana éta rupa nepi ka momen nalika perbaikan casespaces badag mimiti gagal dina klaster Cassandra, sabab compaction teu bisa dipake dina eta. 

Dina hiji poe gugusan teh meh robah jadi waluh, nyaeta:

• aya ngeunaan 20% tina total spasi ditinggalkeun dina klaster;
• Teu mungkin pikeun nambahkeun pinuh titik, sabab cleanup teu ngaliwatan sanggeus nambahkeun titik alatan kurangna spasi dina partitions;
• produktivitas laun turun salaku compaction teu jalan; 
• Kluster aya dina modeu darurat.

Kaluar - kami nambihan 5 deui titik tanpa ngabersihkeun, saatos éta kami sacara sistematis ngahapus aranjeunna tina kluster sareng lebetkeun deui, sapertos titik kosong anu parantos kaluar tina rohangan. Langkung seueur waktos diséépkeun tibatan anu dipikahoyong. Aya résiko unavailability parsial atawa lengkep klaster. 

conclusions:

• Dina sadaya server cassandra, henteu langkung ti 60% rohangan dina unggal partisi kedah dieusi. 
• Éta kudu dimuat dina henteu leuwih ti 50% cpu.
• Anjeun teu kedah hilap ngeunaan perencanaan kapasitas sareng kedah dipikirkeun pikeun tiap komponén, dumasar kana spésifikna.
• Beuki titik dina kluster, langkung saé. Server nu ngandung jumlah leutik data anu overloaded gancang, sarta klaster saperti leuwih gampang pikeun nyegerkeun. 

Tempat kadua - "Data ngiles tina panyimpen nilai konci konsul"

Pikeun penemuan jasa, kami, sapertos seueur, nganggo konsul. Tapi kami ogé nganggo nilai konci na pikeun perenah biru-héjo monolith. Éta nyimpen inpormasi ngeunaan hulu anu aktip sareng teu aktif, anu robih tempat nalika panyebaran. Pikeun tujuan ieu, jasa penyebaran ditulis anu berinteraksi sareng KV. Di sawatara titik, data ti KV ngiles. Dibalikeun tina mémori, tapi ku sababaraha kasalahan. Hasilna, nalika unggah, beban di hulu disebarkeun henteu rata, sareng kami nampi seueur kasalahan 502 kusabab backends overloaded dina CPU. Hasilna, urang dipindahkeun ti konsul KV ka postgres, ti mana teu jadi gampang pikeun ngahapus aranjeunna.  

conclusions:

• Jasa tanpa otorisasina henteu kedah ngandung data anu penting pikeun operasi situs. Contona, upami anjeun teu boga otorisasina di ES, eta bakal leuwih hadé mungkir aksés di tingkat jaringan ti madhab mana teu diperlukeun, ninggalkeun ngan nu diperlukeun, sarta ogé nyetél action.destructive_requires_name: leres.
• Prakték mékanisme cadangan sareng pamulihan sateuacanna. Contona, nyieun naskah sateuacanna (contona, dina python) nu bisa nyieun cadangan tur malikkeun.

Tempat kahiji - "Kaptén Unobvious" 

Di sawatara titik, urang perhatikeun distribusi beban anu henteu rata dina hulu nginx dina kasus dimana aya 10+ server di backend. Alatan kanyataan yén round-robin ngirim requests ti 1st nepi ka hulu panungtungan dina urutan, sarta unggal ulang nginx dimimitian deui, hulu mimiti salawasna narima requests leuwih ti sésana. Ieu janten beuki noticeable salaku jumlah lalulintas ngaronjat. Kantun ngamutahirkeun nginx pikeun ngaktipkeun acak teu jalan - urang kudu redo kebat kodeu lua nu teu take off dina versi 1.15 (dina momen éta). Urang kedah nambal nginx 1.14.2 kami, ngenalkeun dukungan acak kana éta. Ieu direngsekeun masalah. Bug ieu meunang kategori "Kaptén Non-Obviousness".

conclusions:

Ieu pisan metot sarta seru ngajajah bug ieu). 

• Atur pangimeutan anjeun supados ngabantosan anjeun mendakan turun naik sapertos kitu gancang. Salaku conto, anjeun tiasa nganggo ELK pikeun ngawas rps dina unggal backend unggal hulu, ngawas waktos résponna tina sudut pandang nginx. Dina hal ieu, ieu mantuan kami ngaidentipikasi masalah. 

Hasilna, kalolobaan kagagalan tiasa dihindari kalayan pendekatan anu langkung ati-ati kana naon anu anjeun lakukeun. Urang kudu salawasna inget hukum Murphy urang: Naon waé anu salah bakal salah, sareng ngawangun komponén dumasar kana éta. 

sumber: www.habr.com