Rekayasa kekacauan

Hal terakhir yang ingin Anda lihat selama debugging kode adalah kekacauan . Tetapi bagaimana jika kekacauan ini dikendalikan dan diluncurkan oleh tangan pengembang sendiri? Mengapa dengan sengaja mengatur turbulensi dalam kelancaran aplikasi Anda, cara mencapai ketenangan pikiran saat merilis fitur-fitur penting dan di mana tepatnya praktik rekayasa chaos bermanfaat , baca PavelOsipov dalam percakapan antara podcast AppsCast terkemuka dan Pavel Osipov.



Alexey Kudryavtsev: Halo semuanya! Hari ini, tamu kami adalah Pavel Osipov dari Mail.ru Cloud, yang dengannya kami akan berbicara tentang rekayasa kekacauan.

Pavel Osipov: Halo semuanya! Selama enam tahun saya telah mengelola pengembangan Cloud Mail.ru. Selama ini, kami telah mengumpulkan banyak praktik pengujian ekonomi, dan salah satunya adalah rekayasa chaos. Praktek ini memungkinkan Anda untuk melakukan serangkaian percobaan terkontrol untuk mengidentifikasi kesehatan sistem Anda di lingkungan yang tidak bersahabat. Berdasarkan hasil percobaan ini, Anda mendapatkan wawasan yang bermanfaat. Misalnya, Anda tidak mungkin melihat secara teratur bagaimana sistem berperilaku dalam jaringan yang tidak stabil. Jika pengguna Anda sering bepergian di kereta bawah tanah atau beristirahat di lingkungan wifi hotel, jaringannya tidak stabil seperti di tempat kerja programmer. Setelah setiap liburan saya di laut, saya membawa seluruh "portofolio" log tentang apa yang salah dengan aplikasi tersebut.

Secara pribadi, membiakkan kekacauan manual memungkinkan saya mendapatkan dosis tambahan kepercayaan bahwa semuanya akan berjalan dengan baik, bahkan jika semuanya buruk di luar aplikasi.

Ada situasi ketika saya lebih mempercayai kekacauan manual daripada tes otomatis.

Melihat akar kekacauan

Alexei Kudryavtsev: Dari mana asalnya praktik seperti itu?

Pavel Osipov: Ini adalah praktik server, di mana ada banyak masalah lagi. Kita terbiasa dengan konsep utang teknis, dan di Barat juga ada utang gelap - utang tersembunyi yang tak terhindarkan muncul dalam sistem yang kompleks. Tidak seperti utang teknis, di mana kita secara sadar meminjam waktu masa depan dari masa kini, utang tersembunyi tidak terlihat pada tahap menciptakan sistem. Itu terjadi di persimpangan komponen atau perangkat keras dan perangkat lunak dan dapat menyebabkan kaskade masalah: sesuatu rusak pada satu komponen, tumpang tindih yang lain, dan sekarang seluruh sistem terletak.

Misalnya, pada tahun 2016, karena shutdown basis data cascading, 2,5 jam berbaring Facebook. Kemudian sistem yang memeriksa validitas file konfigurasi mulai menghapusnya secara tidak sengaja, tidak hanya dalam subsistem caching, tetapi juga dalam database yang merupakan sumber utama.

Saya sangat suka wawancara dengan Oleg Anastasiev dari Odnoklassniki tentang melakukan latihan untuk mencegah kecelakaan infrastruktur. Mereka memiliki tiga pusat data, yang harus siaga 24/7, tetapi sekali seperempat jenis kegagalan terjadi. Mereka melakukan latihan produksi. Di satu sisi, ini tampak menakutkan, karena jika sesuatu yang tidak terduga terjadi, seluruh pusat data akan jatuh dan tidak akan tersedia di prod. Tetapi di sisi lain, proses ini dikendalikan dan jika terjadi kesalahan, maka Anda akan segera melihatnya, hentikan, dan semuanya akan dipulihkan. Jika ini terjadi dalam kondisi kehidupan tempur, maka menyalakannya kembali tidak akan berhasil, dan analisis alasan penutupan akan berlarut-larut untuk waktu yang lama.

Manfaat kekacauan dalam pengembangan ponsel

Daniil Popov: Sejauh ini, kita berbicara tentang pengembangan server, di mana layanan microser populer dan pemadaman cascading dimungkinkan. Bisakah Anda memberikan lebih banyak contoh tentang apa yang harus diperiksa melalui rekayasa kekacauan dalam pengembangan seluler?

Pavel Osipov: Contoh favorit saya adalah pendataan aplikasi. Dalam kondisi pengujian, tindakan kami dapat menjadi sangat lembut sehubungan dengan aplikasi: kami masuk ke pengaturan akun, mengklik tombol "keluar", aplikasi keluar dan, saat melihat layar masuk, semuanya tampak baik-baik saja. Pengguna sering memiliki situasi yang lebih eksotis. Misalnya, klien mengubah kata sandi melalui antarmuka web atau sejumlah besar log terjadi pada perangkat lain dan token penyegaran digantikan. Pencatatan ini terjadi bukan di jendela dengan akun pengguna, tetapi, misalnya, pada saat penampil foto layar penuh.

Kami menemukan banyak situasi ketika masuk ke berbagai tempat aplikasi menyebabkan konsekuensi seperti kebocoran memori. Penampil yang sama dengan blok penyelesaian dapat mengambil layanan penting, yang akhirnya bocor.

Kami mensimulasikan kondisi menggunakan rekayasa kekacauan. Sistem memiliki layanan yang transparan untuk layanan aplikasi tingkat tinggi memperbarui token akses aplikasi menggunakan token penyegaran aplikasi. Kami memperkenalkan kekacauan di mana layanan, alih-alih memperbarui token, dengan tingkat probabilitas tertentu merusaknya, dan setiap pengembang menemukan log beberapa kali sehari di tempat yang tidak terduga.

Berkat ini, kami menemukan perilaku UIKit yang menarik di iOS: jika, ketika ViewController yang di-root disorot, jendela lain diblokir secara modern dari jendela, maka ViewController yang di-root bocor dan tetap berada dalam sistem selamanya. Jika pada saat yang sama ViewController memiliki tautan ke layanan yang, menurut logika arsitektur, harus ada dalam sistem dalam satu contoh, maka masalah tidak dapat dihindari. Misalnya, Cloud memiliki layanan pengisian-otomatis foto, dan jika dua layanan seperti itu tetap ada dalam sistem, mereka akan melakukan banyak pekerjaan yang tidak perlu dan menempatkan baterai perangkat dua kali lebih cepat dari yang seharusnya.

Kasus penasaran lain. Ketika iOS 8 muncul, ada masalah dengan ekstensi: pada beberapa perangkat, ketika semua izin dalam pengaturan aplikasi diberikan, di awal sistem menyatakan bahwa aplikasi tidak memiliki akses ke grup aplikasi bersama.

Tipologi kekacauan

Daniil Popov: Kekacauan dimasukkan ke dalam sistem secara otomatis berdasarkan minat atau konfigurasi, tetapi apakah seseorang perlu melihat untuk memahami apa yang salah?

Pavel Osipov: Kekacauan berbeda: baik manual maupun otomatis. Dalam kasus sistem operasi, yang mengatakan bahwa aplikasi tidak memiliki akses ke grup aplikasi bersama, dan ekstensi tidak dapat mengakses sumber daya bersama dan database, kekacauan manual digunakan, yang dihidupkan menggunakan tanda centang dalam pengaturan sistem aplikasi. Ini bisa dengan mudah dimodelkan oleh orang-orang dari tim QA.

Ada kekacauan otomatis. Secara khusus, ini adalah kesalahan yang dimodelkan dari layanan microser dari backend kami, dan kekacauan terkait dengan memperbarui token. Konsekuensinya berbeda. Tata letak perjalanan dapat ditentukan melalui pengamatan visual. Ada tempat yang memungkinkan Anda mendeteksi anomali dalam mode otomatis. Misalnya, dalam aplikasi kami, kebocoran memori secara otomatis terdeteksi. Ada dua wadah IoC dalam sistem. Satu manajer adalah masa pakai layanan global, yang bertepatan dengan masa pakai aplikasi itu sendiri, wadah lainnya adalah pengelola layanan yang bertepatan waktu dengan pengguna. Setiap wadah IoC, membuat layanan, memeriksa apakah ada dalam satu contoh.

Mari kita kembali ke contoh dengan log. Di beberapa tempat, masuk tiba-tiba terjadi dan pengembang memasukkan kembali akun untuk terus bekerja. Pada titik ini, wadah IoC melaporkan bahwa kebocoran memori telah terjadi, dan layanan, yang secara teori seharusnya ada dalam satu contoh, terdeteksi lagi.

Kapan waktu kekacauan?

Alexei Kudryavtsev: Apa yang menjadi pemicu implementasi praktik ini?

Pavel Osipov: Kami sampai pada ini melalui kebutuhan untuk mengurangi biaya pengujian. Bagaimana kita bisa mengatasi masalah razlogin yang sama? Anda dapat menulis unit test untuk kebocoran, Anda bisa bingung dan menulis tes UI.

Rekayasa kekacauan adalah praktik termurah, karena tidak terikat pada kasus pengguna, tetapi bertindak secara otomatis untuk semua kasus pengguna bersama-sama.

Pemicu kedua - sebelum praktik diperkenalkan, dalam laporan kerusakan kami, sering terjadi kemacetan serupa dengan akar penyebab yang sama. Misalnya, kecelakaan itu terjadi bukan karena sistem masuk ke profil, tetapi karena pengguna sedang menelusuri galeri foto pada waktu itu. Situasinya berbeda, dan tidak mungkin menguji semua kombinasi razlogin. Jadi saya ingin membuat sesuatu yang mengotomatiskan proses.

Rekayasa kekacauan memiliki praktik terkait - pengujian mutasional . Dalam praktik ini, kami memodifikasi potongan kode kecil dan melihat bagaimana ini memengaruhi tes. Jika, setelah perubahan, tes dilakukan dengan benar, itu berarti bahwa untuk fragmen kode tes tidak cukup.

Perbedaan antara rekayasa kekacauan dan pengujian mutasi adalah bahwa kita tidak secara otomatis mengubah kode produksi itu sendiri, tetapi lingkungannya.

Alexei Kudryavtsev: Mungkinkah untuk melokalisasi penyebab dan memperbaikinya tanpa rekayasa kekacauan?

Pavel Osipov: Tidak ada alasan tunggal yang memancing crash. Setiap kasing unik dengan caranya sendiri. Sebagai contoh, tombol modal muncul di atas jendela, dan ini menyebabkan ViewController yang rusak bocor selama razlog. Tidak mungkin untuk meramalkan semua kombinasi hierarki jendela yang Anda miliki selama pencatatan. Teknik kekacauan pola lokal di mana kebocoran dan crash terjadi.

Alexei Kudryavtsev: Berapa lama Anda menggunakan latihan ini?

Pavel Osipov: Kami mulai menggunakannya pada awal proyek pada 2012, karena itu perlu untuk mengembangkannya dengan cepat, dan tidak ada waktu yang dialokasikan untuk pengujian skala besar. Selain itu, ini tidak hanya mengesankan, tetapi juga pengalaman yang positif.

Daniil Popov: Jika ada sesuatu yang gagal pada aplikasi saya dan saya harus memulai tugas di JIRA, apa yang dapat saya perbaiki di masa depan, bagaimana saya dapat mereproduksi situasi ini?

Pavel Osipov: Tidak ada resep universal. Rekayasa kekacauan diaktifkan pada saat debugging aplikasi dan dinonaktifkan pada saat pembuatan versi rilis, oleh karena itu situasi seperti itu dapat dilihat melalui log di konsol lingkungan pengembangan, dari mana Anda dapat mengetahui cara menempatkan tugas di JIRA.

Alexei Kudryavtsev: Apakah Anda mencoba membuat perilaku yang dapat direproduksi sehingga sistem kekacauan Anda memberi tahu Anda tentang masalah dan menyarankan untuk memasukkannya ke dalam konfigurasi di awal untuk mengulangi keadaan ini?

Pavel Osipov: Kedengarannya kosmik dan mungkin dalam arsitektur seperti Redux. Jika arsitektur memungkinkan Anda untuk merekam semua tindakan yang mendahului peristiwa penting, maka hal ini dimungkinkan. Ini tidak terjadi pada kita. Ini dipraktekkan ketika saya bekerja sebagai programmer serveride di bidang telekomunikasi. Ada tes yang mengacak pintu masuk ke subsistem dan memeriksa output yang memadai. Kami mencapai bahwa ketika pengujian dengan input acak menabrak sistem, dan dalam program yang bertanggung jawab untuk pengujian otomatisasi, semua parameter yang diperlukan dari permintaan input ditunda sehingga dapat direproduksi.

Terapkan kekacauan dalam aplikasi

Daniil Popov: Apakah benar kekacauan seperti itu dimasukkan ke dalam kode dengan tangan?

Pavel Osipov: Ya, klien jaringan kami memiliki fungsionalitas bawaan di mana Anda dapat mengirim konfigurasi, yang menjelaskan parameter kekacauan yang harus direproduksi. Berdasarkan konfigurasi, ia memutuskan untuk mem-proxy permintaan klien ke server atau untuk menanggapi omong kosong sendiri. Lapisan untuk bekerja dengan jaringan sedemikian rupa sehingga Anda dapat menyesuaikan kekacauan yang diperkenalkan oleh layanan mikro di backend. Tidak masuk akal untuk memodelkan kesalahan dalam validitas data otorisasi jika permintaan layanan mikro tidak memerlukan otorisasi.

Kami tidak hanya mengacak semuanya, memainkan kode yang sempurna, tetapi juga mengacak apa yang dapat direproduksi oleh pengguna di kehidupan nyata.

Alexei Kudryavtsev: Apa yang Anda acakkan dari jaringan dan file?

Pavel Osipov: Kami mendebat praktik pengacakan respons dari titik akhir spesifik untuk memodelkan perilaku dan kekacauan masing-masing layanan mikro secara terpisah. Kami telah menyelesaikan pekerjaan memindahkan sistem file ke memisahkan subsistem, dan saya mencoba memodelkan berbagai jenis kesalahan ketika aplikasi mencoba menulis atau membaca file. Akses yang disimulasikan secara manual ke grup aplikasi bersama dalam aplikasi, dan saya benar-benar ingin memulai memodelkan perilaku aplikasi ketika dimulai dengan ruang disk yang sangat kecil, di mana bahkan tidak mungkin untuk membuat database.

Alexei Kudryavtsev: Apakah hanya itu yang Anda lakukan?

Pavel Osipov: Pada prinsipnya, ya. Kami belum membersihkan semua bug yang ditemukan menggunakan kekacauan yang ada. Tentu saja, menarik untuk meningkatkan kekacauan dan mentransfer ke subsistem lain, tetapi kita tidak akan punya waktu untuk memperbaiki sebanyak kekacauan akan ditemukan.

Di mana tempat kekacauan? Anda selalu dapat menemukan tempat di mana Anda dapat membuat turbulensi lain untuk aplikasi tersebut. Penting untuk membangun di atas masalah. Kami membuat kekacauan untuk penebangan karena kami mengamati sejumlah besar masalah serupa.

Jika pemantauan menunjukkan bahwa dalam subsistem lain tidak ada masalah khusus, maka tidak masuk akal untuk menghabiskan waktu memodelkan keadaan yang tidak terduga.

Ini tidak berlaku untuk penagihan, di mana operasi yang benar adalah penting.

Alexei Kudryavtsev: Di sisi lain, kami tidak tahu apa yang terjadi dengan pengguna - ini adalah kekacauan itu sendiri, karena Anda tidak tahu di mana harus meletakkannya atau tidak, dan Anda hanya perlu mensimulasikannya.

Pavel Osipov: Anda selalu perlu melihat ROI. Tentu saja, Anda dapat mereproduksi kasus-kasus yang paling eksotis, tetapi jika mereka lajang, maka mungkin mereka tidak kritis, dan tidak ada gunanya memodelkannya.

Tantangan memperkenalkan kekacauan

Alexei Kudryavtsev: Manakah dari yang sudah dilakukan itu mudah bagi Anda, dan apa yang menyebabkan kesulitan?

Pavel Osipov: Membiasakan diri dengan kekacauan bukanlah hal yang biasa bagi seorang pemula, karena ini bukan praktik yang biasa digunakan. Sulit untuk beradaptasi dengan fakta bahwa Anda memiliki banyak kesalahan. Di hampir setiap layar, Anda bisa mendapatkan paket "lima ratus" atau "404" yang tidak bisa dipahami, server merespons sekali. Hanya dengan waktu Anda terbiasa dengan kenyataan bahwa semua ini membosankan, dan tanggapan dari server dimodelkan oleh sistem itu sendiri.

Sulit ketika Anda memiliki fitur kritis yang sedang menyala, dan Anda harus menyelesaikannya sesegera mungkin, dan kemudian razlogin tiba-tiba muncul di tempat akumulasi permintaan. Sebagai contoh, Anda perlu membuat layar dengan benar dan Anda membutuhkan semua permintaan untuk menyelesaikan dengan sukses, dan ini sangat tidak mungkin bahwa Anda harus pergi beberapa lusin kali untuk mencapai keadaan yang diinginkan. Dalam kasus seperti itu, penonaktifan kekacauan menjadi tindakan balasan, dan penting untuk tidak lupa menyalakannya lagi.

Poin lain yang menyebabkan ketidakpuasan adalah penggunaan kekacauan dalam layanan infrastruktur dengan sejumlah besar efek samping.

Daniil Popov: Jadi, apakah pengembang selalu memiliki kekacauan yang dihidupkan secara default?

Pavel Osipov: Tentu saja. Kadang-kadang, ketika Anda bahkan tidak peduli dengan kekacauan dan situasi eksotis yang dapat ia tiru untuk Anda, itu mengganggu. Anda harus bertahan, tetapi Anda selalu dapat menyesuaikan tingkat kekacauan jika layar Anda bekerja secara intensif dengan jaringan. Di sisi lain, kekacauan dapat mengungkapkan masalah jauh dari tempat Anda mencarinya, dan bukan dari pengembang yang mengembangkan fitur ini. Kebetulan fitur Anda, di mana kekacauan ditambahkan, mengarah pada konsekuensi yang memengaruhi fitur rekan Anda. Anda tidak akan tahu tentang ini jika kekacauan hanya akan dimasukkan pada saat perkembangan tertentu.

Arti kekacauan adalah untuk mengidentifikasi konsekuensi yang tidak terduga dalam interaksi sejumlah besar komponen.

Jika Anda memasukkan kekacauan dengan cara yang terukur dan akurat, maka bidikan langka namun bertujuan baik ini tidak akan terlihat.

Daniil Popov: Apakah kekacauan mencegah pembacaan kode?

Pavel Osipov: Ketika kekacauan diperkenalkan di luar sistem, menempel pada yang sudah jadi, maka ya, itu tampak berantakan. Pada kami, karena pengalaman penggunaan yang lama, kekacauan ditenun secara organik ke dalam sistem dan begitu terisolasi sehingga Anda tidak melihatnya dalam kode.

Alexei Kudryavtsev: Anda menangkap banyak kasus langka, memperbaikinya, dan kode dikelilingi oleh kruk. Apakah ini mempersulit logika aplikasi?

Pavel Osipov: Ini selalu merupakan bagian besar dari kode kami, tetapi sebaliknya aplikasi produksi besar tidak ditulis. Tentu saja, itu semua tergantung pada keahlian pengembang, siapa yang tahu cara memperbaiki kode sehingga tidak mengganggu mata.

Pro memperkenalkan kekacauan

Daniil Popov: Apakah ada indikator kuantitatif yang membaik setelah diperkenalkannya rekayasa kekacauan?

Pavel Osipov: Bagi saya, metrik yang paling penting adalah ketenangan pikiran ketika saya mengirim fitur untuk dirilis.

Alexey Kudryavtsev: Perdamaian tidak bisa dijual ke bisnis. Bagaimana memperdebatkan pengenalan rekayasa kekacauan di perusahaan?

Pavel Osipov: Rekayasa kekacauan membebaskan waktu bagi penguji, karena ada tes otomatis. Kecelakaan yang sama dengan razlogin setelah pengenalan praktik kekacauan hampir menghilang dari JIRA kami.

Rekayasa kekacauan memiliki efek menguntungkan pada siklus rilis, karena Anda mendapatkan umpan balik cepat. Adalah satu hal ketika fitur yang telah selesai diuji, dan setelah lama Anda diberi tahu tentang jumlah bug yang ditemukan, itu sama sekali berbeda ketika Anda memiliki robot penguji yang berfungsi di seluruh program debug.

Saya memiliki perasaan percaya diri dari hasil unit test yang jauh lebih rendah daripada dari kekacauan yang dinyalakan hingga 50% saat mengunduh ribuan file. Dengan beban seperti itu, semua kombinasi paling luar biasa pasti akan diperbaiki.

Siapa yang harus belajar dan mulai dari mana?

Alexei Kudryavtsev: Alat apa yang Anda gunakan untuk ini? Mengambil perpustakaan terbuka atau menulis dan memposting di sumber terbuka?

Pavel Osipov: Kami telah memposting perpustakaan jaringan dalam sumber terbuka, tetapi tidak ada alat khusus. Satu-satunya yang saya tahu adalah Netflix Chaos Monkey , yang secara acak “berjalan” melalui AWS dan menghentikannya, melihat apakah semuanya berjalan baik jika sejumlah kontainer dipadamkan. Saya percaya bahwa menulis konfigurasi tempat Anda bersentuhan dengan sistem yang berdekatan tidak memerlukan otomatisasi yang mendalam.

Daniil Popov: Di mana saya bisa membaca lebih lanjut tentang chaos engineering?

Pavel Osipov: Pertama, situs web Principles of Chaos , yang ditautkan oleh semua sumber daya pada topik ini. Kedua, buku Learning Chaos Engineering dan Chaos Engineering Observability .

Secara umum, chaos engineering adalah praktik akal sehat dan pengetahuan fundamental tidak ada. Anda selalu perlu memahami di mana harus menanamkan kekacauan. Pada saat yang sama, apakah kekacauan itu unik untuk setiap aplikasi? dan Anda harus terlebih dahulu memahami apa yang perlu diterapkan bersama Anda.

Alexei Kudryavtsev: Di mana untuk memulai jika Anda masih memutuskan untuk memperkenalkan kekacauan?

Pavel Osipov: Mulailah dengan menganalisis masalah dalam sistem, yang macet dan mengapa mereka muncul. Setelah mengidentifikasi akar kejahatan, Anda harus memahami cara membuat model situasi yang mengarah ke masalah. Dan langkah ketiga adalah memperkenalkan kekacauan dengan hati-hati dan mengendalikannya.

Alexei Kudryavtsev: Banyak hal dapat merusak aplikasi, tetapi bagaimana memprioritaskan? Di mana lebih baik tidak ikut campur?

Pavel Osipov: Tidak ada hal yang tidak nyata. Rasio harga dan knalpot penting. Jika ada API sistem kaya, maka membungkusnya dengan bungkus Anda sendiri mahal. Jika Anda tidak sepenuhnya memahami sesuatu, maka Anda akan mulai memancing kekacauan, yang pada dasarnya tidak mungkin dan akan mengarah pada perjuangan yang sia-sia. Misalnya, jika seluruh UIKit atau API belanja dicakup oleh kekacauan.

Kekacauan bukanlah poke acak, tetapi pemahaman yang jelas tentang situasi yang disimulasikan.

Alexei Kudryavtsev: Berapa banyak yang Anda rekomendasikan untuk menerapkan praktik ini?

Pavel Osipov: Saya biasanya merekomendasikan memulai dengan memperkenalkan rekayasa kekacauan, daripada tes unit, karena ini adalah praktik termurah.

Tertarik dengan chaos engineering? Tangkap Pavel Osipov di AppsConf musim gugur di St. Petersburg pada 21-21 Oktober, tempat ia akan mempresentasikan laporan barunya tentang basis data Nilai-kunci .