Foto: Penjelajah Rumit, Unsplash
Hari ini saya teringat salah satu "mitos pemrograman" favorit saya, yang mungkin merupakan legenda urban, dan "kotak hitam" versi saya sendiri yang memerlukan debugging.
Legenda perkotaan menceritakan tentang gerbong kereta radioaktif dari Ukraina yang menyebabkan bug pada sistem komputer, Anda dapat membacanya di sini .
Kita berurusan dengan "kotak hitam" dan seperti sekarang ini
Kotak hitam adalah konsep pemrograman populer yang mengasumsikan bahwa kita berada di luar sistem atau komponen tanpa akses langsung ke kode. Ini bisa disebabkan oleh berbagai faktor:
- Anda bekerja dengan perangkat lunak pihak ketiga yang pengembangnya tidak mengungkapkan kodenya.
- Anda berinteraksi dengan API yang logika internalnya diabstraksi.
- Anda tidak memiliki izin yang diperlukan untuk mengakses repositori Git.
- Bahkan sistem dengan akses penuh dapat menjadi kotak hitam de facto karena kerumitannya.
- Seorang karyawan yang memiliki semua kunci dan pengetahuan tiba-tiba akan berhenti / menghilang / mati.
- Sistem lawas terdiri dari .dll yang "selalu berfungsi" di server, dan tidak tersambung ke sistem kontrol versi. Untuk hanya melihat kodenya, Anda perlu mendekompilasinya, jika memungkinkan, tentunya.
Semua faktor ini bermuara pada fakta bahwa kami memiliki masalah yang tidak dapat kami perbaiki secara instan, dan kami tidak tahu apa kesalahannya. Oleh karena itu, kami harus segera bekerja.
Masalah kita sendiri adalah kombinasi dari semua hal di atas
Daftar faktor yang tercantum di atas mungkin tidak mencakup semua situasi, karena ini adalah daftar langsung dari faktor-faktor yang memengaruhi situasi kita. Kami baru saja memecat pengembang, sistem kompleks yang didistribusikan ke banyak server, dengan inti .dll yang "melakukan tugasnya", meskipun tidak ada yang tahu mengapa atau yang mana.
Itu disebut layanan pihak ketiga, praktis tidak ada login di dalamnya, dan satu-satunya cadangan yang kami miliki adalah penyimpanan dalam sistem file dengan .dll ini
dan tanpa kode apa pun. Seperti yang Anda pahami, semua ini tidak dapat dipertahankan, dan mereka berencana untuk menulis ulang sistem pada waktunya, tetapi kesalahan itu mendesak dan perlu dihilangkan.
Kami dapat mengatakan bahwa sebagian besar waktu sistem hampir sepenuhnya mengatasi pekerjaan, dan kami dapat bertahan dengan solusi parsial untuk masalah jika mereka menunjukkan konsistensi. Namun, kira-kira setiap kumpulan data yang keseratus ternyata memiliki hasil yang salah dan satu-satunya hal yang dapat kami lakukan adalah men-debugnya dari luar (sekarang kami mengingatnya sambil tersenyum).
Ini adalah salah satu saat di mana saya merasa bersyukur atas kekacauan dunia tempat saya dibesarkan, karena kebanyakan perusahaan tidak akan menghadapi masalah yang begitu serius, dan tidak akan menunjuk lulusan baru untuk menyelesaikannya. Saya beruntung dalam hal itu, dan bahkan lebih beruntung lagi, karena saya mendapat dukungan dari pengembang berpengalaman yang membantu saya selama proses tersebut. Jadi inilah solusi kami.
Kami mereproduksi kesalahan (idealnya pada beberapa kasus uji)
Setelah Anda mengetahui bug yang sebenarnya, masalahnya hampir terpecahkan, tetapi akan sangat sulit untuk mendapatkannya jika bug terjadi secara tidak teratur. Pikirkan lagi tentang contoh kereta api - jika tidak mungkin untuk mengidentifikasi polanya, maka alasannya hampir tidak mungkin untuk ditemukan. Karena inilah yang kami cari dalam situasi seperti itu - pola ketika kesalahan terjadi.
Dalam kasus kami, kami menemukannya relatif sederhana: kami mengetahui jenis kesalahan dan itu terjadi berulang kali, tetapi sangat jarang sehingga kami membutuhkan waktu berkali-kali untuk mempersempit ruang pencarian untuk kasus dan mengungkapkan logikanya.
Setelah kami mengidentifikasi banyak kasus pengujian yang secara teratur menyebabkan kegagalan, Anda dapat mulai men-debug sendiri. Berikut adalah contoh proses lain di mana kami mempersempit pencarian sumber masalah dengan mencocokkan pola: salah satu sistem digantung setiap Kamis malam, dan tidak ada yang aneh di file log:
- Kami tahu bahwa sistem kami tidak memberikan pesan kesalahan apa pun, tetapi macet.
- Kami membandingkan kasus sampai kami yakin masalahnya terjadi pada hari Kamis dan tidak ada hari lain.
- Kami memeriksa bahwa tidak ada pembaruan otomatis yang dijadwalkan untuk saat ini, memeriksa semua tugas otomatis yang berjalan di server yang sama - tidak ada.
- Kami melihat apa yang dilakukan sistem di tingkat meta dan mempersempitnya menjadi waktu tunggu disk bersama, yang diakses setiap dua minggu oleh tugas pembersihan disk yang berjalan di server yang sama sekali berbeda saat layanan kami berjalan. Tidak ada yang mengira keduanya mulai diluncurkan pada pukul tiga pagi.
Buat lingkungan pengujian (meskipun itu produksi)
Setelah Anda memiliki sekumpulan kesalahan, Anda dapat mulai mengerjakan penyebab dan solusi sebenarnya, yang memerlukan sistem pengujian.
Maksud saya, Anda membutuhkan dua konstanta:
- Data yang digunakan tidak boleh diubah oleh sistem lain
- Kerusakan yang mungkin terjadi harus dibatasi sebisa mungkin
Dalam kasus kami, kami tidak dapat mereproduksi kesalahan pada server pengujian, ini jelas, karena pustaka .dll berada dalam keadaan yang sama sekali berbeda dibandingkan dengan server dalam produksi. Mengembalikan ke keadaan lama ini tidak berhasil karena merusak elemen lain yang sama pentingnya.
Jadi kami berkumpul dan mengajukan pertanyaan, "Hal terburuk apa yang bisa terjadi jika kita mengacaukannya?" Dan kemudian menulis skrip database yang akan menulis ulang semua hasil ke dalam status kesalahan sehingga sistem berikutnya tidak akan memprosesnya.
Itu mungkin, misalnya, untuk memutuskan server dan tugas, menghapus langkah logis berikutnya dari proses, dan sejenisnya, tetapi kemungkinan ini tergantung pada arsitektur sistem tertentu.
Bandingkan data masukan untuk menemukan persamaan dan perbedaan dengan set data yang berfungsi
Meskipun kami tidak dapat menemukan apa yang sebenarnya dilakukan kode tersebut dalam kasus "kotak hitam", adalah mungkin untuk melakukan semacam "rekayasa balik", yang seringkali memberikan pemahaman yang baik tentang penyebab masalah.
Dalam kasus kami, kami memiliki kemewahan file JSON yang diformat dengan cukup baik dari sistem sebelumnya yang menjadi sandaran masukan kami. Setelah kami mengatur semuanya, itu tetap benar-benar mulai membandingkan beberapa file teks di Notepad ++ sampai kami menemukan kesamaan antara file yang menyebabkan kesalahan, dan kemudian perbedaan di antara mereka dan file yang berfungsi dengan benar.
Kami beruntung di sini - kami dapat dengan cepat mengetahui bahwa bug tersebut menyebabkan kombinasi khusus dari tanda pelanggan, dan kami segera berhasil melewatinya, karena kasus ini dapat "ditiru" dengan tanda yang serupa tetapi berbeda. Oleh karena itu, karena kami telah mengetahui bahwa sistem akan ditulis ulang (pada kenyataannya, kami tidak punya pilihan), diputuskan untuk mengatasi bug ini daripada mendekompilasi dan memperbaikinya.
Memodifikasi masukan untuk memastikan tebakan kami mengarah ke hasil yang diharapkan (dan membatasi kerusakan)
Jelas, mengubah data langsung dalam database dalam produksi adalah ide yang buruk, berharap semuanya akan berfungsi tanpa pengujian nyata, tetapi kami tidak punya pilihan lain.
Ini bekerja dengan baik karena jumlah kasusnya rendah, dan beberapa tes pertama kami jalankan secara manual dan ternyata persis seperti yang kami inginkan.
Jadi kami akhirnya hanya menulis tugas otomatis lainnya untuk memperbaiki masalah ini sebelum masuk ke sistem, dan kemudian memulai proyek tiga bulan untuk menulis ulang program ini dari awal, kali ini secara transparan, dengan kontrol versi dan pipeline build.
Inilah petualangannya.
Kesimpulan: Anda dapat belajar cukup banyak tentang sistem tersebut, bahkan jika Anda hanya berjalan-jalan dan menusuknya dengan tongkat
Saya senang dengan cara debugging dan menemukan kesalahan ini, saya suka ketika pemrograman dikombinasikan dengan adrenalin.
Jika Anda belum menonton video tentang injeksi SQL dan rekayasa balik database pada pesan kesalahan, saya sangat menyarankan untuk menontonnya . Teknik yang digunakan dalam video ini hampir sama dengan teknik yang dapat digunakan untuk debugging tidak berbahaya.
Periklanan
Pesan dan segera bekerja! Pembuatan VDS konfigurasi apa pun dalam satu menit, termasuk server untuk menyimpan data dalam jumlah besar hingga 4000 GB. Epic :)
Berlangganan obrolan kami di Telegram .
