Get best of the week

Fakapov Cyan Teratas



Baik untuk semua! 

Nama saya Nikita, saya pemimpin tim insinyur Cyan. Salah satu tanggung jawab saya di perusahaan adalah mengurangi jumlah insiden terkait dengan infrastruktur pada prod menjadi nol.
Apa yang akan didiskusikan nanti telah membawa kita banyak kesakitan, dan tujuan artikel ini adalah untuk mencegah orang lain mengulangi kesalahan kita atau setidaknya meminimalkan dampaknya. 

Pembukaan


Sekali waktu, ketika Cyan terdiri dari monolit, dan belum ada petunjuk tentang layanan mikro, kami mengukur ketersediaan sumber daya dengan memeriksa 3-5 halaman. 

Jawab - semuanya baik-baik saja, jangan merespons untuk waktu yang lama - waspada. Berapa banyak waktu mereka seharusnya tidak bekerja agar ini dapat dianggap sebagai insiden, orang memutuskan pada pertemuan. Tim insinyur selalu terlibat dalam penyelidikan insiden tersebut. Ketika penyelidikan selesai, mereka menulis post-mortem - semacam laporan ke kantor pos dalam format: apa, berapa lama, apa yang mereka lakukan saat ini, apa yang akan kita lakukan di masa depan. 

Halaman utama situs ini, atau seperti yang kita pahami, telah merusak dasarnya

 
Untuk memahami prioritas kesalahan, entah bagaimana, kami menyoroti halaman paling kritis situs untuk fungsionalitas bisnis. Menurut mereka, kami mempertimbangkan jumlah permintaan dan batas waktu yang berhasil / tidak berhasil. Jadi kami mengukur waktu aktif. 

Misalkan kita mengetahui bahwa ada sejumlah bagian super penting dari situs yang bertanggung jawab atas layanan utama - pencarian dan penyerahan pengumuman. Jika jumlah permintaan yang gagal lebih besar dari 1%, ini adalah insiden kritis. Jika dalam waktu 15 menit dalam prime time persentase kesalahan melebihi 0,1%, maka ini juga dianggap sebagai insiden kritis. Kriteria ini mencakup sebagian besar insiden, sisanya berada di luar cakupan artikel ini.



Insiden cyan terbaik terbaik


Jadi, kami justru belajar menentukan fakta bahwa kejadian itu terjadi. 

Sekarang setiap kejadian di negara kita dijelaskan secara rinci dan tercermin dalam epos Jira. Ngomong-ngomong: untuk ini kami memulai proyek terpisah, menyebutnya GAGAL - hanya epos yang dapat dibuat di dalamnya. 

Jika Anda mengumpulkan semua kegagalan selama beberapa tahun terakhir, maka pemimpinnya adalah: 

  • insiden terkait mssql;
  • insiden yang disebabkan oleh faktor eksternal;
  • kesalahan admin.

Mari kita membahas lebih rinci tentang kesalahan admin, serta beberapa kegagalan menarik lainnya.

Tempat kelima - "Menertibkan dalam DNS"


Itu hari Selasa hujan. Kami memutuskan untuk membersihkan cluster DNS. 

Saya ingin mentransfer server dns internal dari bind ke powerdns, menyoroti server yang sepenuhnya terpisah untuk itu, di mana tidak ada selain dns. 

Kami menempatkan satu server dns di setiap lokasi DC kami, dan saatnya tiba untuk memindahkan zona dari bind ke powerdns dan mengalihkan infrastruktur ke server baru. 

Pada puncak pergerakan, dari semua server yang ditunjukkan dalam caching bind lokal pada semua server, hanya ada satu yang ada di pusat data di St. Petersburg. DC ini awalnya dinyatakan tidak kritis bagi kami, tetapi tiba-tiba menjadi satu-satunya titik kegagalan.
Hanya selama periode relokasi seperti itu, saluran antara Moskow dan St. Petersburg jatuh. Kami benar-benar tetap tanpa DNS selama lima menit dan bangun ketika hoster memperbaiki masalah. 

Kesimpulan:

Jika sebelumnya kita mengabaikan faktor-faktor eksternal selama persiapan untuk pekerjaan, sekarang mereka juga termasuk dalam daftar apa yang sedang kita persiapkan. Dan sekarang kami berusaha untuk memastikan bahwa semua komponen dicadangkan n-2, dan selama pekerjaan kami dapat menurunkan level ini ke n-1.

  • Saat menyusun rencana tindakan, tandai poin-poin di mana layanan tersebut dapat jatuh, dan pikirkan skenario di mana semuanya menjadi "lebih buruk daripada tempat", di muka.
  • Mendistribusikan server DNS internal oleh geolokasi / pusat data / rak / switch / input yang berbeda.
  • Pada setiap server, letakkan server cns dns lokal, yang mengalihkan permintaan ke server dns utama, dan jika tidak tersedia, server akan merespons dari cache. 

Tempat keempat - "Membersihkan Nginx"


Suatu hari, tim kami memutuskan bahwa "cukup untuk menanggungnya", dan proses refactoring nginx configs dimulai. Tujuan utamanya adalah untuk membawa konfigurasi ke struktur intuitif. Sebelumnya, semuanya "secara historis didirikan" dan tidak ada logika dalam dirinya sendiri. Sekarang setiap server_name telah dibawa ke file dengan nama yang sama dan mendistribusikan semua konfigurasi ke dalam folder. By the way, konfigurasi berisi 253949 baris atau 7836520 karakter dan memakan waktu hampir 7 megabyte. Struktur tingkat atas: 

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


Itu menjadi jauh lebih baik, tetapi dalam proses penggantian nama dan distribusi konfigurasi, beberapa dari mereka memiliki ekstensi yang salah dan tidak termasuk dalam direktori * .conf. Akibatnya, bagian dari host menjadi tidak tersedia dan mengembalikan 301 ke yang utama. Karena fakta bahwa kode responsnya bukan 5xx / 4xx, ini tidak segera diketahui, tetapi hanya di pagi hari. Setelah itu, kami mulai menulis tes untuk menguji komponen infrastruktur.

Temuan: 

  • Konfigurasi struktur dengan benar (tidak hanya nginx) dan pikirkan struktur pada tahap awal proyek. Jadi Anda akan membuat mereka lebih dimengerti oleh tim, yang pada gilirannya akan mengurangi TTM.
  • Untuk beberapa komponen infrastruktur, tulis tes. Sebagai contoh: memeriksa bahwa semua nama server kunci mengembalikan status yang benar, + badan tanggapan. Ini akan cukup untuk memiliki hanya beberapa skrip yang memeriksa fungsi dasar komponen sehingga Anda tidak ingat dengan panik pada pukul 3 pagi. Apa lagi yang perlu diperiksa. 

Tempat ketiga - “Tempat yang tiba-tiba berakhir di Cassandra”


Data tumbuh dengan mantap, dan semuanya baik-baik saja sampai saat ketika perbaikan kasus besar mulai jatuh di gugus Cassandra, karena pemadatan tidak dapat bekerja pada mereka. 

Pada suatu hari hujan, gugusan itu hampir berubah menjadi labu, yaitu:

  • tempat tetap sekitar 20% dari total kluster;
  • tidak mungkin untuk menambahkan sepenuhnya node, karena pembersihan tidak berfungsi setelah menambahkan node karena kurangnya ruang pada partisi;
  • kinerja sedikit menurun, karena pemadatan tidak berfungsi; 
  • cluster berada dalam mode darurat.



Keluar - menambahkan 5 node lain tanpa pembersihan, setelah itu mereka mulai secara sistematis menghapus dari cluster dan memasukkannya kembali sebagai node kosong di mana tempat itu berakhir. Waktu menghabiskan lebih banyak daripada yang kita inginkan. Ada risiko tidak dapat diaksesnya sebagian atau seluruhnya cluster. 

Temuan:

  • Semua server cassandra tidak boleh mengambil lebih dari 60% ruang di setiap partisi. 
  • Mereka harus dimuat tidak lebih dari 50% cpu.
  • Jangan menyumbat perencanaan kapasitas dan memikirkannya untuk setiap komponen, berdasarkan spesifiknya.
  • Semakin banyak node dalam cluster, semakin baik. Server yang mengandung sejumlah kecil data dimigrasikan lebih cepat, dan cluster seperti itu lebih mudah untuk dianimasi kembali. 

Tempat kedua - "Data dari penyimpanan nilai kunci konsul telah menghilang"


Untuk penemuan layanan, kami, seperti banyak orang, menggunakan konsul. Tapi di sini, nilainya juga digunakan untuk perhitungan monolit biru-hijau. Ini menyimpan informasi tentang hulu aktif dan tidak aktif, yang mengubah tempat selama penyebaran. Untuk ini, sebuah layanan penyebaran ditulis yang berinteraksi dengan KV. Pada titik tertentu, data dari KV menghilang. Dipulihkan dari memori, tetapi dengan sejumlah kesalahan. Akibatnya, selama perhitungan, beban di hulu tidak terdistribusi secara merata, dan kami mendapat banyak kesalahan 502 karena membebani backend pada CPU. Akibatnya, kami pindah dari konsul KV ke postgres, dari tempat tidak mudah untuk menghapusnya.  

Temuan:

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

— « » 


Pada titik tertentu, kami melihat distribusi beban yang tidak merata di hulu nginx dalam kasus di mana ada 10+ server di backend. Karena fakta bahwa round-robin mengirim permintaan dari 1 ke hulu terakhir secara berurutan, dan setiap pemuatan nginx dimulai dari awal, hulu pertama selalu memiliki lebih banyak permintaan daripada yang lain. Akibatnya, mereka bekerja lebih lambat dan seluruh situs menderita. Ini menjadi lebih terlihat karena jumlah lalu lintas meningkat. Hanya memperbarui nginx untuk mengaktifkan acak tidak berfungsi - Anda perlu mengulang banyak kode lua yang tidak lepas landas pada versi 1.15 (pada saat itu). Saya harus menambal nginx 1.14.2 kami, memperkenalkan dukungan acak di dalamnya. Ini memecahkan masalah. Bug ini memenangkan nominasi "kapten tidak jelas".

Kesimpulan:

Sangat menarik dan menyenangkan untuk menyelidiki bug ini). 

  • Atur pemantauan sehingga membantu menemukan fluktuasi sedemikian cepat. Misalnya, Anda dapat menggunakan ELK untuk memonitor rps di setiap backend dari masing-masing hulu, dan memantau waktu respons mereka dari sudut pandang nginx. Dalam hal ini, ini membantu kami mengidentifikasi masalah. 

Akibatnya, sebagian besar kegagalan bisa dihindari dengan pendekatan yang lebih cermat terhadap apa yang Anda lakukan. Anda harus selalu ingat Hukum Murphy:  Apa pun yang bisa salah akan salah, dan membangun komponen berdasarkan itu. 

More articles:


All Articles