Catatan. terjemahan: Artikel ini melanjutkan serangkaian artikel hebat dari penginjil teknologi AWS Adrian Hornsby, yang ingin menjelaskan dengan cara yang sederhana dan jelas pentingnya eksperimen untuk mengurangi konsekuensi kegagalan dalam sistem TI.
“Jika Anda gagal mempersiapkan sebuah rencana, maka Anda berencana untuk gagal.” - Benyamin Franklin
В Dalam rangkaian artikel ini, saya memperkenalkan konsep chaos engineering dan menjelaskan bagaimana hal ini membantu menemukan dan memperbaiki kelemahan dalam sistem sebelum menyebabkan kegagalan produksi. Pertemuan ini juga membahas bagaimana chaos engineering mendorong perubahan budaya positif dalam organisasi.
Di akhir bagian pertama, saya berjanji untuk berbicara tentang “alat dan metode untuk memasukkan kegagalan ke dalam sistem.” Sayangnya, kepala saya punya rencana sendiri dalam hal ini, dan dalam artikel ini saya akan mencoba menjawab pertanyaan paling populer yang muncul di antara orang-orang yang ingin terjun ke dalam chaos engineering: Apa yang harus dipatahkan terlebih dahulu?
Pertanyaan bagus! Namun, dia sepertinya tidak terlalu peduli dengan panda ini...
Jangan main-main dengan panda kekacauan!
Jawaban singkat: Menargetkan layanan penting di sepanjang jalur permintaan.
Jawaban yang lebih panjang tetapi lebih jelas: Untuk memahami di mana harus mulai bereksperimen dengan kekacauan, perhatikan tiga bidang:
- Lihatlah riwayat kecelakaan dan mengidentifikasi pola;
- Memutuskan ketergantungan kritis;
- Gunakan apa yang disebut efek terlalu percaya diri.
Ini lucu, tapi bagian ini bisa dengan mudah disebut "Perjalanan Menuju Penemuan Diri dan Pencerahan". Di dalamnya kita akan mulai “bermain” dengan beberapa instrumen keren.
1. Jawabannya terletak pada masa lalu
Jika Anda ingat, di bagian pertama saya memperkenalkan konsep Correction-of-Errors (COE) - sebuah metode yang digunakan untuk menganalisis kesalahan kita - kesalahan dalam teknologi, proses, atau organisasi - untuk memahami penyebabnya dan mencegahnya. terulang kembali di masa depan. Secara umum, di sinilah Anda harus memulai.
“Untuk memahami masa kini, Anda perlu mengetahui masa lalu.” —Carl Sagan
Lihatlah riwayat kegagalan, tandai di COE atau postmortem dan klasifikasikan. Identifikasi pola umum yang sering menimbulkan masalah, dan untuk setiap COE, tanyakan pada diri Anda pertanyaan berikut:
“Mungkinkah hal ini telah diprediksi dan dicegah dengan injeksi kesalahan?”
Saya ingat satu kegagalan di awal karir saya. Hal ini dapat dengan mudah dicegah jika kita melakukan beberapa eksperimen kekacauan sederhana:
Dalam kondisi normal, instance backend merespons pemeriksaan kondisi dari ). ELB menggunakan pemeriksaan ini untuk mengalihkan permintaan ke instance yang sehat. Ketika ternyata sebuah instance “tidak sehat”, ELB berhenti mengirimkan permintaan ke instance tersebut. Suatu hari, setelah kampanye pemasaran yang sukses, volume lalu lintas meningkat dan backend mulai merespons pemeriksaan kesehatan lebih lambat dari biasanya. Harus dikatakan bahwa pemeriksaan kesehatan ini , artinya, status dependensi telah diperiksa.
Namun, semuanya baik-baik saja untuk sementara waktu.
Kemudian, dalam kondisi yang cukup menegangkan, salah satu instance mulai menjalankan tugas cron ETL reguler yang tidak kritis. Kombinasi traffic tinggi dan cronjob mendorong pemanfaatan CPU hingga hampir 100%. Kelebihan beban CPU semakin memperlambat respons terhadap pemeriksaan kesehatan, sehingga ELB memutuskan bahwa instance tersebut mengalami masalah kinerja. Seperti yang diharapkan, penyeimbang berhenti mendistribusikan lalu lintas ke sana, yang pada gilirannya menyebabkan peningkatan beban pada instance lain dalam grup.
Tiba-tiba, semua instansi lain juga mulai gagal dalam pemeriksaan kesehatan.
Memulai instance baru memerlukan pengunduhan dan penginstalan paket dan membutuhkan waktu lebih lama daripada yang dibutuhkan ELB untuk menonaktifkannya - satu per satu - di grup penskalaan otomatis. Jelas bahwa seluruh proses segera mencapai titik kritis dan aplikasi terhenti.
Kemudian kami selamanya memahami poin-poin berikut:
- Menginstal perangkat lunak saat membuat instance baru membutuhkan waktu lama, lebih baik memberikan preferensi pada pendekatan yang tidak dapat diubah dan .
- Dalam situasi sulit, respons terhadap pemeriksaan kesehatan dan ELB harus diprioritaskan - hal terakhir yang Anda inginkan adalah mempersulit hidup pada situasi lainnya.
- Caching lokal dari health check sangat membantu (bahkan untuk beberapa detik).
- Dalam situasi sulit, jangan jalankan tugas cron dan proses tidak kritis lainnya - hemat sumber daya untuk tugas yang paling penting.
- Saat melakukan penskalaan otomatis, gunakan instance yang lebih kecil. Sekelompok 10 spesimen kecil lebih baik daripada kelompok 4 spesimen besar; jika satu contoh gagal, dalam kasus pertama 10% lalu lintas akan didistribusikan ke 9 titik, di kasus kedua - 25% lalu lintas di tiga titik.
Dengan demikian, dapatkah hal ini diramalkan, dan oleh karena itu dicegah dengan menimbulkan masalah?
Ya, dan dalam beberapa cara.
Pertama, dengan mensimulasikan penggunaan CPU yang tinggi menggunakan alat seperti или :
❯ stress-ng --matrix 1 -t 60s
stres-ng
Kedua, dengan membebani instance secara berlebihan dan utilitas serupa lainnya:
❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health
Eksperimennya relatif sederhana, tetapi dapat memberikan bahan pemikiran yang baik tanpa harus melalui tekanan karena kegagalan yang nyata.
Tetapi jangan berhenti di situ. Cobalah untuk mereproduksi kerusakan di lingkungan pengujian dan periksa jawaban Anda atas pertanyaan "Mungkinkah hal ini telah diramalkan dan oleh karena itu dicegah dengan menimbulkan kesalahan?" Ini adalah eksperimen kekacauan kecil dalam eksperimen kekacauan untuk menguji asumsi, namun dimulai dengan kegagalan.
Apakah itu mimpi, atau benar-benar terjadi?
Jadi pelajari sejarah kegagalan, analisa EOC, tandai dan klasifikasikan mereka berdasarkan “radius hit”—atau lebih tepatnya, jumlah pelanggan yang terpengaruh—lalu cari polanya. Tanyakan pada diri Anda apakah hal ini bisa diprediksi dan dicegah dengan memperkenalkan masalahnya. Periksa jawaban mu.
Kemudian beralih ke pola paling umum dengan rentang terbesar.
2. Buat peta ketergantungan
Luangkan waktu sejenak untuk memikirkan lamaran Anda. Apakah ada peta ketergantungannya yang jelas? Tahukah Anda apa dampaknya jika terjadi kegagalan?
Jika Anda tidak begitu paham dengan kode aplikasi Anda atau kodenya menjadi sangat besar, akan sulit untuk memahami fungsi kode dan ketergantungannya. Memahami ketergantungan ini dan kemungkinan dampaknya terhadap aplikasi dan pengguna sangat penting untuk mengetahui di mana harus memulai rekayasa chaos: titik awalnya adalah komponen dengan radius dampak terbesar.
Mengidentifikasi dan mendokumentasikan dependensi disebut "membangun peta ketergantungan» (pemetaan ketergantungan). Hal ini biasanya dilakukan untuk aplikasi dengan basis kode yang besar menggunakan alat pembuatan profil kode. (profil kode) dan instrumentasi (Peralatan). Anda juga dapat membuat peta dengan memantau lalu lintas jaringan.
Namun, tidak semua dependensi itu sama (yang semakin memperumit prosesnya). Beberapa kritis, lainnya - sekunder (setidaknya secara teori, karena crash sering terjadi karena masalah dependensi yang dianggap tidak kritis).
Tanpa ketergantungan kritis, layanan tidak dapat berfungsi. Ketergantungan non-kritis "jangan» untuk mempengaruhi layanan jika terjadi terjatuh. Untuk memahami dependensi, Anda harus memiliki pemahaman yang jelas tentang API yang digunakan oleh aplikasi Anda. Ini bisa menjadi jauh lebih sulit daripada yang terlihat - setidaknya untuk aplikasi besar.
Mulailah dengan menelusuri semua API. Soroti yang paling banyak signifikan dan kritis. Mengambil зависимости dari repositori kode, periksa log koneksi, lalu lihat dokumentasi (tentu saja, jika ada - jika tidak, Anda masih memilikinyaоmasalah yang lebih besar). Gunakan alat untuk pembuatan profil dan penelusuran, menyaring panggilan eksternal.
Anda dapat menggunakan program seperti netstat - utilitas baris perintah yang menampilkan daftar semua koneksi jaringan (soket aktif) di sistem. Misalnya, untuk mencantumkan semua koneksi saat ini, ketik:
❯ netstat -a | more
Di AWS Anda dapat menggunakan (log aliran) VPC adalah metode yang memungkinkan Anda mengumpulkan informasi tentang lalu lintas IP yang menuju atau dari antarmuka jaringan di VPC. Log semacam itu juga dapat membantu tugas lain - misalnya, menemukan jawaban atas pertanyaan mengapa lalu lintas tertentu tidak mencapai instance.
Anda juga bisa menggunakan . X-Ray memungkinkan Anda mendapatkan detail, "yang terbaik" (ujung ke ujung) ikhtisar permintaan saat berpindah melalui aplikasi, dan juga membuat peta komponen dasar aplikasi. Sangat nyaman jika Anda perlu mengidentifikasi dependensi.
Konsol AWS X-Ray
Peta ketergantungan jaringan hanyalah solusi parsial. Ya, ini menunjukkan aplikasi mana yang berkomunikasi dengan aplikasi mana, tetapi ada ketergantungan lain.
Banyak aplikasi menggunakan DNS untuk terhubung ke dependensi, sementara yang lain mungkin menggunakan penemuan layanan atau bahkan alamat IP yang dikodekan dalam file konfigurasi (mis. /etc/hosts).
Misalnya, Anda bisa membuat melalui iptables dan lihat apa yang rusak. Untuk melakukannya, masukkan perintah berikut:
❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"
Lubang hitam DNS
Jika dalam /etc/hosts atau file konfigurasi lainnya, Anda akan menemukan alamat IP yang tidak Anda ketahui (ya, sayangnya, ini juga terjadi), Anda dapat menyelamatkannya lagi iptables. Katakanlah Anda menemukannya 8.8.8.8 dan tidak tahu bahwa ini adalah alamat server DNS publik Google. Dengan menggunakan iptables Anda dapat memblokir lalu lintas masuk dan keluar ke alamat ini menggunakan perintah 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
Aturan pertama menghapus semua paket dari DNS publik Google: ping berfungsi, tetapi paket tidak dikembalikan. Aturan kedua membuang semua paket yang berasal dari sistem Anda ke DNS publik Google - sebagai respons terhadap ping kita dapatkan Operasi tidak diizinkan.
Catatan: dalam kasus khusus ini akan lebih baik digunakan whois 8.8.8.8, tapi ini hanya sebuah contoh.
Kita bisa mendalami lebih jauh lagi, karena segala sesuatu yang menggunakan TCP dan UDP sebenarnya bergantung pada IP juga. Dalam kebanyakan kasus, IP terkait dengan ARP. Jangan lupakan firewall...
Jika kamu meminum pil merah, kamu akan tetap berada di Negeri Ajaib, dan aku akan menunjukkan seberapa dalam lubang kelinci itu."
Pendekatan yang lebih radikal adalah dengan memutuskan mobil satu per satu dan lihat apa yang rusak... jadilah "monyet kekacauan". Tentu saja, banyak sistem produksi yang tidak dirancang untuk serangan brute force seperti itu, tetapi setidaknya sistem ini dapat dicoba di lingkungan pengujian.
Membangun peta ketergantungan seringkali merupakan pekerjaan yang sangat panjang. Saya baru-baru ini berbicara dengan klien yang menghabiskan hampir 2 tahun mengembangkan alat yang secara semi-otomatis menghasilkan peta ketergantungan untuk ratusan layanan mikro dan perintah.
Namun hasilnya sangat menarik dan bermanfaat. Anda akan belajar banyak tentang sistem Anda, ketergantungan dan pengoperasiannya. Sekali lagi, bersabarlah: perjalanan itu sendirilah yang paling penting.
3. Waspadai rasa percaya diri yang berlebihan
“Siapapun yang memimpikan sesuatu, percaya padanya.” — Demosthenes
Pernahkah Anda mendengarnya efek terlalu percaya diri?
Menurut Wikipedia, efek terlalu percaya diri adalah “bias kognitif di mana kepercayaan diri seseorang terhadap tindakan dan keputusannya jauh lebih besar daripada keakuratan obyektif penilaian tersebut, terutama ketika tingkat kepercayaannya relatif tinggi.”
Berdasarkan naluri dan pengalaman...
Menurut pengalaman saya, distorsi ini adalah petunjuk bagus tentang di mana harus memulai rekayasa chaos.
Waspadalah terhadap operator yang terlalu percaya diri:
Charlie: “Benda ini belum jatuh dalam lima tahun, semuanya baik-baik saja!”
Crash: “Tunggu… Saya akan segera ke sana!”
Bias akibat terlalu percaya diri merupakan suatu hal yang berbahaya bahkan berbahaya karena berbagai faktor yang mempengaruhinya. Hal ini terutama berlaku ketika anggota tim telah mencurahkan seluruh isi hatinya pada suatu teknologi atau menghabiskan banyak waktu untuk “memperbaikinya”.
Menyimpulkan
Pencarian titik awal untuk rekayasa kekacauan selalu membawa hasil lebih dari yang diharapkan, dan tim yang mulai memecahkan masalah terlalu cepat akan melupakan esensi yang lebih global dan menarik dari (kekacauan-)rekayasa - aplikasi kreatif metode ilmiah и bukti empiris untuk desain, pengembangan, pengoperasian, pemeliharaan dan peningkatan sistem (perangkat lunak).
Ini mengakhiri bagian kedua. Silakan tulis ulasan, bagikan pendapat, atau sekadar bertepuk tangan . Pada bagian selanjutnya I benar-benar Saya akan mempertimbangkan alat dan metode untuk memasukkan kegagalan ke dalam sistem. Sampai!
PS dari penerjemah
Baca juga di blog kami:
- «»;
- «»;
- «»;
- «'.
Sumber: www.habr.com