Catatan. terjemah: Artikel ini meneruskan siri artikel hebat daripada penginjil teknologi AWS, Adrian Hornsby, yang ingin menerangkan dengan cara yang mudah dan jelas tentang kepentingan percubaan untuk mengurangkan akibat kegagalan dalam sistem IT.
"Jika anda gagal menyediakan rancangan, maka anda merancang untuk gagal." - Benjamin Franklin
Π Dalam siri artikel ini, saya memperkenalkan konsep kejuruteraan huru-hara dan menerangkan cara ia membantu mencari dan membetulkan kelemahan dalam sistem sebelum ia membawa kepada kegagalan pengeluaran. Ia juga membincangkan bagaimana kejuruteraan huru-hara menggalakkan perubahan budaya positif dalam organisasi.
Pada penghujung bahagian pertama, saya berjanji untuk bercakap tentang "alat dan kaedah untuk memperkenalkan kegagalan ke dalam sistem." Malangnya, kepala saya mempunyai rancangan sendiri dalam hal ini, dan dalam artikel ini saya akan cuba menjawab soalan paling popular yang timbul di kalangan orang yang ingin memasuki kejuruteraan huru-hara: Apa yang perlu dipecahkan dahulu?
Soalan yang hebat! Namun, dia nampaknya tidak begitu peduli dengan panda ini...
Jangan main-main dengan panda huru-hara!
Jawapan pendek: Sasarkan perkhidmatan kritikal di sepanjang laluan permintaan.
Jawapan yang lebih panjang tetapi lebih jelas: Untuk memahami tempat untuk mula bereksperimen dengan huru-hara, beri perhatian kepada tiga bidang:
- Lihatlah sejarah kemalangan dan mengenal pasti corak;
- Tentukan pada kebergantungan kritikal;
- Gunakan apa yang dipanggil kesan terlalu yakin.
Ia lucu, tetapi bahagian ini boleh dipanggil dengan mudah "Perjalanan Menuju Penemuan Diri dan Pencerahan". Di dalamnya kita akan mula "bermain" dengan beberapa instrumen yang keren.
1. Jawapannya terletak pada masa lalu
Jika anda masih ingat, pada bahagian pertama saya memperkenalkan konsep Pembetulan Kesilapan (COE) - kaedah yang kami menganalisis kesilapan kami - kesilapan dalam teknologi, proses atau organisasi - untuk memahami puncanya dan mencegah berulang pada masa hadapan. Secara umum, di sinilah anda harus bermula.
"Untuk memahami masa kini, anda perlu mengetahui masa lalu." - Carl Sagan
Lihat sejarah kegagalan, tag mereka dalam COE atau postmortem dan klasifikasikannya. Kenal pasti corak biasa yang sering membawa kepada masalah, dan bagi setiap COE, tanya diri anda soalan berikut:
"Bolehkah ini telah diramalkan dan oleh itu dicegah dengan suntikan kesalahan?"
Saya masih ingat satu kegagalan pada awal kerjaya saya. Ia boleh dicegah dengan mudah jika kami telah menjalankan beberapa eksperimen huru-hara mudah:
Dalam keadaan biasa, kejadian bahagian belakang bertindak balas kepada pemeriksaan kesihatan daripada ). ELB menggunakan semakan ini untuk mengubah hala permintaan kepada keadaan yang sihat. Apabila ternyata kejadian itu "tidak sihat", ELB berhenti menghantar permintaan kepadanya. Pada suatu hari, selepas kempen pemasaran yang berjaya, jumlah trafik meningkat dan bahagian belakang mula bertindak balas terhadap pemeriksaan kesihatan dengan lebih perlahan daripada biasa. Harus dikatakan bahawa pemeriksaan kesihatan ini adalah , iaitu, keadaan kebergantungan telah disemak.
Walau bagaimanapun, semuanya baik-baik saja untuk seketika.
Kemudian, dalam keadaan yang agak tertekan, salah satu contoh mula melaksanakan tugas cron ETL biasa yang tidak kritikal. Gabungan trafik tinggi dan cronjob mendorong penggunaan CPU kepada hampir 100%. Lebihan beban CPU memperlahankan lagi respons kepada pemeriksaan kesihatan, sehinggakan ELB memutuskan bahawa contoh itu mengalami masalah prestasi. Seperti yang dijangkakan, pengimbang berhenti mengedarkan trafik kepadanya, yang seterusnya membawa kepada peningkatan dalam beban pada baki kejadian dalam kumpulan.
Tiba-tiba, semua keadaan lain juga mula gagal dalam pemeriksaan kesihatan.
Memulakan contoh baharu memerlukan memuat turun dan memasang pakej dan mengambil masa lebih lama daripada ELB untuk melumpuhkannya - satu demi satu - dalam kumpulan penskalaan automatik. Adalah jelas bahawa tidak lama lagi keseluruhan proses mencapai titik kritikal dan aplikasi itu ranap.
Kemudian kami selamanya memahami perkara berikut:
- Memasang perisian semasa membuat contoh baharu mengambil masa yang lama; adalah lebih baik untuk memberi keutamaan kepada pendekatan yang tidak berubah dan .
- Dalam situasi yang sukar, respons kepada pemeriksaan kesihatan dan ELB harus diutamakan - perkara terakhir yang anda mahukan ialah merumitkan kehidupan untuk keadaan yang selebihnya.
- Caching tempatan pemeriksaan kesihatan banyak membantu (walaupun untuk beberapa saat).
- Dalam situasi yang sukar, jangan jalankan tugas cron dan proses bukan kritikal lain - simpan sumber untuk tugas yang paling penting.
- Apabila autoscaling, gunakan tika yang lebih kecil. Sekumpulan 10 spesimen kecil adalah lebih baik daripada sekumpulan 4 spesimen besar; jika satu kejadian gagal, dalam kes pertama 10% daripada trafik akan diedarkan melebihi 9 mata, dalam yang kedua - 25% daripada trafik melebihi tiga mata.
Oleh itu, bolehkah ini telah diramalkan, dan oleh itu dicegah dengan memperkenalkan masalah itu?
Ya, dan dalam beberapa cara.
Pertama, dengan mensimulasikan penggunaan CPU yang tinggi menggunakan alatan seperti atau :
β― stress-ng --matrix 1 -t 60s
tekanan-ng
Kedua, dengan melebihkan contoh dengan dan utiliti lain yang serupa:
β― wrk -t12 -c400 -d20s http://127.0.0.1/api/health
Percubaan adalah agak mudah, tetapi boleh menyediakan beberapa makanan yang baik untuk difikirkan tanpa perlu melalui tekanan kegagalan sebenar.
Tetapi jangan berhenti di situ. Cuba untuk menghasilkan semula ranap sistem dalam persekitaran ujian dan semak jawapan anda kepada soalan "Bolehkah ini telah diramalkan dan oleh itu dicegah dengan memperkenalkan kesalahan?Β». ΠΡΠΎ ΠΌΠΈΠ½ΠΈ Ρ Π°ΠΎΡ-ΡΠΊΡΠΏΠ΅ΡΠΈΠΌΠ΅Π½Ρ Π²Π½ΡΡΡΠΈ Ρ Π°ΠΎΡ-ΡΠΊΡΠΏΠ΅ΡΠΈΠΌΠ΅Π½ΡΠ° Π΄Π»Ρ ΠΏΡΠΎΠ²Π΅ΡΠΊΠΈ ΠΏΡΠ΅Π΄ΠΏΠΎΠ»ΠΎΠΆΠ΅Π½ΠΈΠΉ, Π½ΠΎ Π½Π°ΡΠΈΠ½Π°Ρ ΡΠΎ ΡΠ±ΠΎΡ.
Adakah ia mimpi, atau adakah ia benar-benar berlaku?
Jadi kaji sejarah kegagalan, analisa COE, teg dan klasifikasikannya mengikut "jejari pukulan"βatau lebih tepat lagi, bilangan pelanggan yang terjejasβdan kemudian cari corak. Tanya diri anda sama ada ini boleh diramalkan dan dicegah dengan memperkenalkan masalah tersebut. Semak jawapan anda.
Kemudian beralih kepada corak yang paling biasa dengan julat terbesar.
2. Bina peta pergantungan
Luangkan masa untuk berfikir tentang permohonan anda. Adakah terdapat peta yang jelas tentang kebergantungannya? Adakah anda tahu apakah impak yang mereka akan ada jika berlaku kegagalan?
Jika anda tidak begitu biasa dengan kod aplikasi anda atau ia menjadi sangat besar, mungkin sukar untuk memahami apa yang dilakukan oleh kod tersebut dan apakah kebergantungannya. Memahami kebergantungan ini dan kemungkinan kesannya terhadap aplikasi dan pengguna adalah penting untuk mengetahui di mana hendak bermula dengan kejuruteraan huru-hara: titik permulaan ialah komponen dengan jejari impak terbesar.
Mengenal pasti dan mendokumentasikan kebergantungan dipanggil "membina peta pergantunganΒ» (pemetaan kebergantungan). Ini biasanya dilakukan untuk aplikasi dengan pangkalan kod yang besar menggunakan alat pemprofilan kod. (pemprofilan kod) dan instrumentasi (instrumentasi). Anda juga boleh membina peta dengan memantau trafik rangkaian.
Walau bagaimanapun, tidak semua kebergantungan adalah sama (yang merumitkan lagi proses). Beberapa kritikal, lain - menengah (sekurang-kurangnya dalam teori, kerana ranap sistem sering berlaku disebabkan masalah dengan kebergantungan yang dianggap tidak kritikal).
Tanpa kebergantungan kritikal, perkhidmatan tidak boleh berfungsi. Kebergantungan tidak kritikal "tidak patutΒ» untuk mempengaruhi perkhidmatan sekiranya berlaku kejatuhan. Untuk memahami kebergantungan, anda perlu mempunyai pemahaman yang jelas tentang API yang digunakan oleh aplikasi anda. Ini boleh menjadi lebih sukar daripada yang kelihatan - sekurang-kurangnya untuk aplikasi yang besar.
Mulakan dengan melalui semua API. Serlahkan paling banyak signifikan dan kritikal... ambil kebergantungan dari repositori kod, semaknya log sambungan, kemudian lihat dokumentasi (sudah tentu, jika ia wujud - jika tidak, anda masih mempunyaiΠΎmasalah yang lebih besar). Gunakan alatan untuk profil dan pengesanan, tapis panggilan luar.
Anda boleh menggunakan program seperti netstat - utiliti baris arahan yang memaparkan senarai semua sambungan rangkaian (soket aktif) dalam sistem. Contohnya, untuk menyenaraikan semua sambungan semasa, taip:
β― netstat -a | more
Dalam AWS anda boleh gunakan (log aliran) VPC ialah kaedah yang membolehkan anda mengumpul maklumat tentang trafik IP yang pergi ke atau daripada antara muka rangkaian dalam VPC. Log sedemikian juga boleh membantu dengan tugasan lain - contohnya, mencari jawapan kepada soalan mengapa trafik tertentu tidak mencapai contoh.
Anda juga boleh menggunakan . X-Ray membolehkan anda mendapatkan terperinci, "muktamad" (hujung ke hujung) gambaran keseluruhan permintaan semasa mereka bergerak melalui aplikasi, dan juga membina peta komponen asas aplikasi. Sangat mudah jika anda perlu mengenal pasti kebergantungan.
Konsol X-Ray AWS
Peta pergantungan rangkaian hanyalah penyelesaian separa. Ya, ia menunjukkan aplikasi mana yang berkomunikasi dengan mana, tetapi terdapat kebergantungan lain.
Banyak aplikasi menggunakan DNS untuk menyambung kepada kebergantungan, manakala yang lain mungkin menggunakan penemuan perkhidmatan atau alamat IP berkod keras dalam fail konfigurasi (cth. /etc/hosts).
Sebagai contoh, anda boleh membuat melalui iptables dan lihat apa yang rosak. Untuk melakukan ini, masukkan arahan berikut:
β― iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"
lubang hitam DNS
Jika dalam /etc/hosts atau fail konfigurasi lain, anda akan menemui alamat IP yang anda tidak tahu apa-apa (ya, malangnya, ini juga berlaku), anda boleh datang untuk menyelamatkan sekali lagi iptables. Katakan anda menemuinya 8.8.8.8 dan tidak tahu bahawa ini adalah alamat pelayan DNS awam Google. Dengan menggunakan iptables Anda boleh menyekat trafik masuk dan keluar ke alamat ini menggunakan arahan berikut:
β― iptables -A INPUT -s 8.8.8.8 -j DROP -m comment --comment "Reject from 8.8.8.8"
β― iptables -A OUTPUT -d 8.8.8.8 -j DROP -m comment --comment "Reject to 8.8.8.8"
Menutup akses
Peraturan pertama menggugurkan semua paket daripada DNS awam Google: ping berfungsi, tetapi paket tidak dikembalikan. Peraturan kedua menggugurkan semua paket yang berasal dari sistem anda ke DNS awam Google - sebagai tindak balas kepada ping kita mendapatkan operasi tidak dibenarkan.
Nota: dalam kes tertentu ini adalah lebih baik untuk digunakan whois 8.8.8.8, tetapi ini hanyalah contoh.
Kita boleh pergi lebih dalam ke dalam lubang arnab, kerana semua yang menggunakan TCP dan UDP sebenarnya bergantung pada IP juga. Dalam kebanyakan kes, IP terikat dengan ARP. Jangan lupa tentang firewall...
Jika anda mengambil pil merah, anda tinggal di Wonderland, dan saya akan menunjukkan kepada anda sejauh mana lubang arnab itu pergi."
Pendekatan yang lebih radikal ialah putuskan sambungan kereta satu demi satu dan lihat apa yang rosak... menjadi "monyet huru-hara." Sudah tentu, banyak sistem pengeluaran tidak direka untuk serangan kekerasan sedemikian, tetapi sekurang-kurangnya ia boleh dicuba dalam persekitaran ujian.
Membina peta pergantungan selalunya merupakan usaha yang sangat panjang. Baru-baru ini saya bercakap dengan pelanggan yang menghabiskan hampir 2 tahun membangunkan alat yang secara separa automatik menjana peta pergantungan untuk ratusan perkhidmatan mikro dan arahan.
Hasilnya, bagaimanapun, sangat menarik dan berguna. Anda akan belajar banyak tentang sistem anda, kebergantungan dan operasinya. Sekali lagi, bersabarlah: perjalanan itu sendiri yang paling penting.
3. Berhati-hati dengan terlalu yakin
"Barangsiapa yang bermimpi tentang apa, maka beriman kepadanya." - Demosthenes
Pernahkah anda mendengar tentang kesan terlalu yakin?
Menurut Wikipedia, kesan terlalu yakin ialah "kecondongan kognitif di mana keyakinan seseorang terhadap tindakan dan keputusan mereka adalah jauh lebih besar daripada ketepatan objektif pertimbangan tersebut, terutamanya apabila tahap keyakinan agak tinggi."
Berdasarkan naluri dan pengalaman...
Mengikut pengalaman saya, herotan ini merupakan petunjuk yang bagus tentang tempat untuk bermula dengan kejuruteraan huru-hara.
Berhati-hati dengan pengendali yang terlalu yakin:
Charlie: "Perkara ini tidak jatuh dalam lima tahun, semuanya baik-baik saja!"
Kemalangan: "Tunggu... Saya akan ke sana tidak lama lagi!"
Bias akibat daripada terlalu yakin adalah satu perkara yang berbahaya malah berbahaya kerana pelbagai faktor yang mempengaruhinya. Ini benar terutamanya apabila ahli pasukan telah mencurahkan isi hati mereka ke dalam teknologi atau menghabiskan banyak masa untuk "membetulkannya".
Menjumlahkan
Pencarian untuk titik permulaan untuk kejuruteraan huru-hara sentiasa membawa lebih banyak hasil daripada yang dijangkakan, dan pasukan yang mula memecahkan perkara terlalu cepat melupakan intipati yang lebih global dan menarik (huru-hara-)kejuruteraan - penggunaan kreatif kaedah saintifik ΠΈ bukti empirikal untuk reka bentuk, pembangunan, operasi, penyelenggaraan dan penambahbaikan sistem (perisian).
Ini menyimpulkan bahagian kedua. Sila tulis ulasan, berkongsi pendapat atau hanya bertepuk tangan . Dalam bahagian seterusnya I benar-benar Saya akan mempertimbangkan alat dan kaedah untuk memperkenalkan kegagalan ke dalam sistem. Sampai!
PS daripada penterjemah
Baca juga di blog kami:
- «»;
- «»;
- «»;
- Β«'.
Sumber: www.habr.com