Top fakapov Cyan

Baik untuk semua! 

Nama saya Nikita, saya ketua pasukan pasukan kejuruteraan Cian. Salah satu tanggungjawab saya di syarikat adalah untuk mengurangkan bilangan insiden yang berkaitan dengan infrastruktur dalam pengeluaran kepada sifar.
Apa yang akan dibincangkan di bawah membawa kita banyak kesakitan, dan tujuan artikel ini adalah untuk menghalang orang lain daripada mengulangi kesilapan kita atau sekurang-kurangnya meminimumkan kesan mereka. 

Mukadimah

Lama dahulu, apabila Cian terdiri daripada monolit, dan belum ada tanda perkhidmatan mikro lagi, kami mengukur ketersediaan sumber dengan menyemak 3-5 halaman. 

Mereka menjawab - semuanya baik-baik saja, jika mereka tidak menjawab untuk masa yang lama - berjaga-jaga. Berapa lama mereka terpaksa berhenti kerja untuk dianggap sebagai insiden telah diputuskan oleh orang ramai dalam mesyuarat. Sepasukan jurutera sentiasa terlibat dalam penyiasatan kejadian itu. Apabila siasatan selesai, mereka menulis postmortem - sejenis laporan melalui e-mel dalam format: apa yang berlaku, berapa lama ia berlangsung, apa yang kami lakukan pada masa ini, apa yang akan kami lakukan pada masa hadapan. 

Halaman utama tapak atau bagaimana kami memahami bahawa kami telah mencapai bahagian bawah

 
Untuk entah bagaimana memahami keutamaan ralat, kami telah mengenal pasti halaman tapak yang paling kritikal untuk fungsi perniagaan. Menggunakannya, kami mengira bilangan permintaan dan tamat masa yang berjaya/tidak berjaya. Inilah cara kami mengukur masa beroperasi. 

Katakan kami mendapati bahawa terdapat beberapa bahagian tapak yang sangat penting yang bertanggungjawab untuk perkhidmatan utama - mencari dan menyerahkan iklan. Jika bilangan permintaan yang gagal melebihi 1%, ini adalah insiden kritikal. Jika dalam masa 15 minit semasa masa utama kadar ralat melebihi 0,1%, maka ini juga dianggap sebagai insiden kritikal. Kriteria ini merangkumi kebanyakan insiden; selebihnya berada di luar skop artikel ini.

Insiden terbaik teratas Cian

Jadi, kami pasti telah belajar untuk menentukan fakta bahawa sesuatu kejadian itu berlaku. 

Kini setiap kejadian diterangkan secara terperinci dan digambarkan dalam epik Jira. Ngomong-ngomong: untuk ini kami memulakan projek berasingan, memanggilnya FAIL - hanya epik boleh dibuat di dalamnya. 

Jika anda mengumpul semua kegagalan sejak beberapa tahun kebelakangan ini, pemimpinnya ialah: 

• insiden berkaitan mssql;
• insiden yang disebabkan oleh faktor luaran;
• kesilapan admin.

Mari kita lihat dengan lebih terperinci kesilapan pentadbir, serta beberapa kegagalan lain yang menarik.

Tempat kelima - "Menyusun sesuatu dalam DNS"

Hari Selasa yang ribut. Kami memutuskan untuk memulihkan susunan dalam kelompok DNS. 

Saya ingin memindahkan pelayan DNS dalaman dari bind ke powerdns, memperuntukkan pelayan yang berasingan sepenuhnya untuk ini, di mana tiada apa-apa kecuali DNS. 

Kami meletakkan satu pelayan DNS di setiap lokasi DC kami, dan tiba masanya untuk mengalihkan zon daripada bind ke powerdns dan menukar infrastruktur kepada pelayan baharu. 

Di tengah-tengah langkah itu, daripada semua pelayan yang dinyatakan dalam ikatan caching tempatan pada semua pelayan, hanya satu yang tinggal, iaitu di pusat data di St. Petersburg. DC ini pada mulanya diisytiharkan sebagai tidak kritikal untuk kami, tetapi tiba-tiba menjadi satu titik kegagalan.
Dalam tempoh pemindahan ini, terusan antara Moscow dan St. Petersburg jatuh. Kami sebenarnya dibiarkan tanpa DNS selama lima minit dan bangun semula apabila hoster membetulkan masalah itu. 

Kesimpulan:

Jika sebelum ini faktor luaran kita abaikan semasa persiapan ke tempat kerja, kini ianya juga termasuk dalam senarai apa yang sedang kita persiapkan. Dan kini kami berusaha untuk memastikan bahawa semua komponen dikhaskan n-2, dan semasa kerja kami boleh menurunkan tahap ini kepada n-1.

• Semasa merangka pelan tindakan, tandai titik di mana perkhidmatan boleh gagal, dan fikirkan senario di mana segala-galanya menjadi "dari buruk kepada lebih teruk" terlebih dahulu.
• Edarkan pelayan DNS dalaman merentas geolokasi/pusat data/rak/suis/input yang berbeza.
• Pada setiap pelayan, pasang pelayan DNS caching tempatan, yang mengubah hala permintaan ke pelayan DNS utama, dan jika ia tidak tersedia, ia akan bertindak balas daripada cache. 

Tempat keempat - "Membersihkan perkara di Nginx"

Pada suatu hari yang baik, pasukan kami memutuskan bahawa "kami sudah cukup dengan ini," dan proses pemfaktoran semula konfigurasi nginx bermula. Matlamat utama adalah untuk membawa konfigurasi kepada struktur intuitif. Sebelum ini, semuanya "ditubuhkan secara sejarah" dan tidak membawa sebarang logik. Kini setiap server_name telah dialihkan ke fail dengan nama yang sama dan semua konfigurasi telah diedarkan ke dalam folder. By the way, konfigurasi mengandungi 253949 baris atau 7836520 aksara dan mengambil hampir 7 megabait. Tahap atas 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

Ia menjadi lebih baik, tetapi dalam proses menamakan semula dan mengedarkan konfigurasi, sesetengah daripada mereka mempunyai sambungan yang salah dan tidak disertakan dalam arahan *.conf sertakan. Akibatnya, beberapa hos menjadi tidak tersedia dan mengembalikan 301 ke halaman utama. Disebabkan fakta bahawa kod respons bukan 5xx/4xx, ini tidak disedari serta-merta, tetapi hanya pada waktu pagi. Selepas itu, kami mula menulis ujian untuk menyemak komponen infrastruktur.

Kesimpulan: 

• Susun konfigurasi anda dengan betul (bukan hanya nginx) dan fikirkan struktur pada peringkat awal projek. Dengan cara ini anda akan menjadikan mereka lebih mudah difahami oleh pasukan, yang seterusnya akan mengurangkan TTM.
• Tulis ujian untuk beberapa komponen infrastruktur. Contohnya: menyemak bahawa semua nama pelayan utama memberikan status + badan respons yang betul. Cukuplah dengan hanya mempunyai beberapa skrip di tangan yang menyemak fungsi asas komponen, supaya tidak terkapai-kapai ingat pada pukul 3 pagi apa lagi yang perlu diperiksa. 

Tempat ketiga - "Tiba-tiba kehabisan ruang di Cassandra"

Data berkembang dengan mantap, dan semuanya baik-baik saja sehingga saat pembaikan ruang kes besar mula gagal dalam kelompok Cassandra, kerana pemadatan tidak dapat berfungsi pada mereka. 

Pada suatu hari yang ribut, gugusan itu hampir berubah menjadi labu, iaitu:

• terdapat kira-kira 20% daripada jumlah ruang yang tinggal dalam kelompok;
• Tidak mustahil untuk menambah nod sepenuhnya, kerana pembersihan tidak dilakukan selepas menambah nod kerana kekurangan ruang pada partition;
• produktiviti secara beransur-ansur menurun kerana pemadatan tidak berfungsi; 
• Kluster berada dalam mod kecemasan.

Keluar - kami menambah 5 lagi nod tanpa pembersihan, selepas itu kami mula mengeluarkannya secara sistematik daripada kluster dan memasukkannya semula, seperti nod kosong yang kehabisan ruang. Lebih banyak masa dihabiskan daripada yang kita mahu. Terdapat risiko ketidaksediaan separa atau lengkap kluster. 

Kesimpulan:

• Pada semua pelayan cassandra, tidak lebih daripada 60% ruang pada setiap partition harus diduduki. 
• Mereka harus dimuatkan pada cpu tidak melebihi 50%.
• Anda tidak seharusnya melupakan perancangan kapasiti dan perlu memikirkannya dengan teliti untuk setiap komponen, berdasarkan spesifikasinya.
• Lebih banyak nod dalam kelompok, lebih baik. Pelayan yang mengandungi sejumlah kecil data dibebankan lebih cepat, dan kluster sedemikian lebih mudah untuk dihidupkan semula. 

Tempat kedua - "Data hilang daripada storan nilai kunci konsul"

Untuk penemuan perkhidmatan, kami, seperti kebanyakan orang, menggunakan konsul. Tetapi kami juga menggunakan nilai kuncinya untuk susun atur biru-hijau monolit. Ia menyimpan maklumat tentang huluan aktif dan tidak aktif, yang menukar tempat semasa penggunaan. Untuk tujuan ini, perkhidmatan penempatan telah ditulis yang berinteraksi dengan KV. Pada satu ketika, data daripada KV hilang. Dipulihkan daripada ingatan, tetapi dengan beberapa ralat. Akibatnya, semasa muat naik, beban di hulu telah diagihkan secara tidak sekata, dan kami menerima banyak ralat 502 disebabkan bahagian belakang terbeban pada CPU. Akibatnya, kami berpindah dari konsul KV ke postgres, dari mana ia tidak lagi begitu mudah untuk mengeluarkannya.  

Kesimpulan:

• Perkhidmatan tanpa sebarang kebenaran tidak seharusnya mengandungi data yang penting kepada pengendalian tapak. Sebagai contoh, jika anda tidak mempunyai keizinan dalam ES, adalah lebih baik untuk menafikan akses pada peringkat rangkaian dari mana-mana sahaja di mana ia tidak diperlukan, biarkan hanya yang perlu dan juga tetapkan action.destructive_requires_name: true.
• Amalkan mekanisme sandaran dan pemulihan anda terlebih dahulu. Sebagai contoh, buat skrip terlebih dahulu (contohnya, dalam python) yang boleh membuat sandaran dan memulihkan.

Tempat pertama - "Kapten Tidak Jelas" 

Pada satu ketika, kami melihat taburan beban yang tidak sekata pada hulu nginx dalam kes di mana terdapat 10+ pelayan di bahagian belakang. Disebabkan oleh fakta bahawa round-robin menghantar permintaan dari 1 ke yang terakhir di hulu secara tertib, dan setiap muat semula nginx dimulakan semula, yang pertama di huluan sentiasa menerima lebih banyak permintaan daripada yang lain. Akibatnya, mereka bekerja lebih perlahan dan keseluruhan tapak menderita. Ini menjadi semakin ketara apabila jumlah trafik meningkat. Hanya mengemas kini nginx untuk mendayakan rawak tidak berfungsi - kami perlu membuat semula sekumpulan kod lua yang tidak berlepas pada versi 1.15 (pada masa itu). Kami terpaksa menampal nginx 1.14.2 kami, memperkenalkan sokongan rawak ke dalamnya. Ini menyelesaikan masalah. Pepijat ini memenangi kategori "Ketidakjelasan Kapten".

Kesimpulan:

Ia sangat menarik dan menarik untuk meneroka pepijat ini). 

• Susun pemantauan anda supaya ia membantu anda mencari turun naik sedemikian dengan cepat. Sebagai contoh, anda boleh menggunakan ELK untuk memantau rps pada setiap hujung belakang setiap huluan, memantau masa tindak balas mereka dari sudut pandangan nginx. Dalam kes ini, ini membantu kami mengenal pasti masalah. 

Akibatnya, kebanyakan kegagalan boleh dielakkan dengan pendekatan yang lebih teliti terhadap apa yang anda lakukan. Kita mesti sentiasa ingat undang-undang Murphy: Apa-apa yang boleh salah akan menjadi salah, dan membina komponen berdasarkannya. 

Sumber: www.habr.com