Berurusan dengan bug yang tidak dapat direproduksi

Misalkan tim Anda menulis sistem perangkat lunak yang (sangat mengejutkan!) Berfungsi dengan baik.

Suatu hari salah satu insinyur keliru menjalankan beberapa query SQL yang mengubah beberapa data DB, kemudian melupakannya.

Setelah beberapa waktu Anda menemukan data yang rusak / salah dan semua orang menggaruk kepala bagian mana dari kode yang menyebabkan ini dan mengapa, tidak berhasil. Sementara itu manajer proyek bersikeras bahwa kami menemukan bagian dari kode yang menyebabkannya.

Bagaimana Anda menangani ini?

Jelas tidak ada manajer proyek yang akan menginvestasikan waktu yang tidak terbatas ke dalam masalah seperti itu. Mereka ingin mencegah situasi yang sama terulang kembali.

Untuk mencapai tujuan ini, bahkan jika seseorang tidak dapat menemukan akar penyebab kegagalan seperti itu, seringkali mungkin untuk mengambil beberapa tindakan

• Deteksi kegagalan seperti itu sebelumnya jika terjadi lagi
• Jadikan kecil kemungkinan kegagalan yang sama akan terjadi lagi
• Jadikan sistem lebih kuat dari jenis inkonsistensi tertentu

Misalnya, pencatatan yang lebih terperinci, penanganan kesalahan yang lebih rumit, atau pensinyalan kesalahan segera dapat membantu mencegah kesalahan yang sama menyerang lagi, atau untuk menemukan akar permasalahan. Jika sistem Anda mengizinkan penambahan pemicu basis data, mungkin dimungkinkan untuk menambahkan pemicu yang melarang inkonsistensi yang diperkenalkan.

Pikirkan apa jenis tindakan yang sesuai dalam situasi Anda, dan sarankan ini kepada tim; Saya yakin manajer proyek Anda akan senang.

Suatu hari salah satu insinyur keliru menjalankan beberapa query SQL yang mengubah beberapa data DB, kemudian melupakannya.

Seperti yang disebutkan oleh orang lain, itu juga merupakan ide yang baik untuk melarang prosedur semacam itu (jika Anda memiliki pengaruh pada bagaimana sistem dioperasikan). Tidak seorang pun boleh diizinkan menjalankan kueri ad-hoc tidak berdokumen yang mengubah konten basis data. Jika ada kebutuhan untuk permintaan seperti itu, pastikan ada kebijakan untuk menyimpan permintaan bersama dengan tanggal pelaksanaannya, nama orang yang mengeksekusinya, dan alasan mengapa itu digunakan, di tempat yang terdokumentasi.

Ini bukan bug

Setidaknya tidak pada kode Anda. Ini adalah bug dalam proses Anda . Manajer proyek Anda harus lebih khawatir tentang proses Anda daripada kode Anda.

Bagaimana Anda menangani ini?

Sederhananya, dengan tidak membiarkan para insinyur mengubah produksi atau pengembangan bersama database .

Dengan asumsi ini adalah database pengembangan bersama:

Idealnya, jika memungkinkan, hindari memiliki database bersama di tempat pertama . Sebaliknya, miliki basis data per-pengembang yang berumur pendek. Ini harus diotomatisasi dengan skrip, jika tidak biaya untuk pengujian menjadi terlalu besar, dan ada insentif untuk tidak menguji sesuatu. Anda dapat memiliki database ini di workstation pengembang, atau di server pusat.

Jika, karena suatu alasan, Anda benar-benar HARUS memiliki database bersama, Anda harus menggunakan fixture - pada dasarnya, sesuatu yang mengatur database ke kondisi yang dikenal baik setiap kali Anda perlu menggunakannya. Ini menghindari pengembang digigit oleh perubahan orang lain.

Jika Anda perlu menerapkan perubahan permanen ke database, Anda harus mengkomitnya ke kontrol sumber Anda . Setup database Anda sedemikian sehingga devs tidak memiliki izin untuk menulisnya secara langsung, dan memiliki program yang menarik perubahan dari kontrol sumber dan menerapkannya.

Akhirnya, dari deskripsi Anda tentang cara Anda men-debug sesuatu, sepertinya Anda tidak menggunakan CI . Gunakan CI . Agak sulit untuk setup, tetapi akan menghemat banyak waktu dalam jangka panjang, belum lagi menghentikan Anda dari khawatir tentang bug basis data yang tidak dapat diproduksi kembali. Anda hanya perlu khawatir tentang Heisenbugs sekarang!

Dengan asumsi ini adalah basis data produksi:

Jika pengembang Anda mengubah basis data produksi, banyak hal yang salah, bahkan jika perubahannya benar.

Pengembang tidak boleh mengakses basis data produksi . Sama sekali tidak ada alasan untuk itu, dan begitu banyak hal yang bisa menjadi sangat salah.

Jika Anda perlu memperbaiki sesuatu dalam database produksi, pertama-tama Anda membuat cadangan, mengembalikan cadangan itu pada contoh (pengembangan) yang berbeda , dan kemudian bermain-main dengan database pengembangan itu. Setelah Anda berpikir Anda memiliki perbaikan siap (pada kontrol sumber!), Anda melakukan kembali pemulihan, menerapkan perbaikan, dan melihat hasilnya. Kemudian, setelah mencadangkan semuanya lagi (dan idealnya mencegah pembaruan bersamaan), Anda memperbaiki instance produksi, idealnya melalui tambalan perangkat lunak.

Jika Anda perlu menguji sesuatu di basis data produksi ... tidak, Anda tidak perlu. Apa pun tes yang perlu Anda lakukan, Anda harus lakukan dalam contoh pengembangan. Jika Anda memerlukan beberapa data untuk melakukan tes, Anda mendapatkan data itu di sana.

Database produksi harus memiliki akses penuh logging dan kontrol akses berbasis peran. Dengan demikian, Anda harus memiliki bukti kuat tentang WHO melakukan APA SAJA ke database sehingga memindahkan perhatian dari kode ke keamanan operasional yang buruk.

Dalam hal ini, Anda akhirnya mengetahui penyebabnya, tetapi mengambil hipotesis Anda bahwa Anda tidak ...

Pertama, analisis apa yang berubah. Jika sistem berjalan dengan baik sebelumnya, melihat dengan seksama semua yang telah dilakukan baru-baru ini dapat mengungkapkan perubahan yang menyebabkan bug. Tinjau secara sistematis kontrol versi Anda, CI / sistem penyebaran, dan kontrol konfigurasi untuk melihat apakah ada yang berubah. Jalankan git bisect atau mekanisme yang setara untuk melakukan pencarian biner. Periksa log. Cari-cari log yang tidak Anda ketahui. Bicaralah dengan semua orang dengan akses ke sistem untuk melihat apakah mereka telah melakukan sesuatu baru-baru ini. Untuk masalah Anda, jika Anda cukup teliti dalam proses ini, semoga ini akan mengungkapkan pertanyaan SQL yang terlupakan.

Kedua, instrumentasi. Jika Anda tidak dapat menemukan penyebab bug secara langsung, tambahkan instrumen di sekitarnya untuk mengumpulkan data tentang masalah tersebut. Tanyakan pada diri Anda "jika saya bisa mereproduksi bug ini pada perintah, apa yang ingin saya lihat di debugger," dan kemudian login. Ulangi sesuai kebutuhan sampai Anda memiliki pemahaman yang lebih baik tentang masalah tersebut. Seperti yang disarankan Doc Brown, tambahkan logging untuk status yang relevan dengan bug. Tambahkan pernyataan yang mendeteksi data yang rusak. Misalnya, jika bug Anda adalah aplikasi crash, tambahkan mekanisme crash logging. Jika Anda sudah memilikinya, hebat, tambahkan anotasi ke log kerusakan untuk mencatat keadaan yang berpotensi relevan dengan crash. Pertimbangkan apakah masalah konkurensi mungkin terlibat dan uji coba untuk menggunakan utas keselamatan .

Ketiga, ketahanan. Bug tidak dapat dihindari, jadi tanyakan pada diri Anda bagaimana Anda dapat meningkatkan sistem Anda menjadi lebih tangguh sehingga pemulihan dari bug lebih mudah. Bisakah cadangan Anda ditingkatkan (atau ada)? Pemantauan, kegagalan, dan peringatan yang lebih baik? Lebih banyak redundansi? Penanganan kesalahan yang lebih baik? Layanan saling bergantung satu sama lain? Bisakah Anda meningkatkan proses Anda di sekitar akses database dan permintaan manual? Paling-paling, hal-hal ini akan membuat konsekuensi bug Anda tidak terlalu parah, dan paling buruk, mereka mungkin melakukan hal-hal baik.

1. Jelaskan kepada manajer proyek Anda bahwa menurut Anda penyebab yang paling mungkin adalah akses basis data manual.
2. Jika mereka masih ingin Anda mencari kode yang menyebabkan ini, buka dan lihat lagi kode tersebut.
3. Kembalilah dalam beberapa jam (atau waktu lain yang sesuai) dan katakan Anda tidak dapat menemukan kode apa pun yang menyebabkan hal ini, karena itu Anda masih yakin penyebab yang paling mungkin adalah akses basis data manual.
4. Jika mereka masih ingin Anda mencari kodenya, tanyakan berapa banyak waktu yang mereka ingin Anda habiskan untuk ini. Secara halus mengingatkan mereka bahwa Anda tidak akan mengerjakan fitur X, bug Y atau peningkatan Z saat Anda melakukan ini.
5. Habiskan waktu sebanyak yang mereka minta. Jika Anda masih berpikir kemungkinan penyebabnya adalah akses basis data manual, beri tahu mereka ini.
6. Jika mereka masih ingin Anda mencari kodenya, tingkatkan masalahnya karena hal ini jelas menjadi penggunaan waktu tim Anda yang tidak produktif.

Anda mungkin juga ingin mempertimbangkan apakah Anda harus menambahkan proses tambahan untuk mengurangi kemungkinan akses basis data manual yang menyebabkan masalah seperti ini di masa mendatang.

Saya sedang bekerja pada tim pengembangan untuk produk basis data mainframe ketika seorang pelanggan melaporkan bahwa mereka memiliki basis data yang korup. Korupsi dalam arti bahwa keadaan internal bit pada disk berarti database tidak dapat dibaca melalui perangkat lunak database. Di dunia mainframe, pelanggan membayar Anda $ juta dan Anda harus menganggap ini serius. Inilah yang kami lakukan:

Langkah 0: bantu pelanggan untuk bangkit dan berjalan kembali dengan memperbaiki basis data.

Langkah 1: dengan memeriksa file pada disk di tingkat heks kami menentukan bahwa korupsi itu sistematis: ada banyak contoh korupsi yang sama. Jadi itu pasti disebabkan pada tingkat perangkat lunak basis data. Memang, itu cukup sistematis sehingga kami merasa kami bisa mengesampingkan masalah multi-threading.

Setelah menghilangkan banyak teori lain, kami menggunakan utilitas yang dapat digunakan untuk reorganisasi fisik database. Tampaknya itu satu-satunya kode yang memiliki akses ke data di tingkat yang tepat. Kami kemudian menemukan cara menjalankan utilitas ini, dengan opsi yang dipilih dengan cermat, yang mereproduksi masalah. Pelanggan tidak dapat mengkonfirmasi atau menyangkal bahwa ini adalah apa yang telah mereka lakukan, tetapi karena itu adalah satu-satunya penjelasan yang dapat kami buat, kami memutuskan bahwa itu kemungkinan penyebabnya, dan mereka tidak punya banyak pilihan selain menerima diagnosis kami. .

Langkah 2: Kami kemudian membuat dua perubahan pada perangkat lunak: (a) membuatnya lebih sulit untuk menyebabkan efek ini secara tidak sengaja melalui antarmuka pengguna "ya saya tahu apa yang saya lakukan", dan (b) memperkenalkan file log baru sehingga jika pernah terjadi lagi, kita akan memiliki catatan tindakan pengguna.

Jadi pada dasarnya (a) perbaiki kerusakan dan kembalikan berjalan hidup, (b) temukan akar masalahnya, (c) lakukan apa saja yang diperlukan untuk mencegahnya terjadi lagi, atau untuk memudahkan diagnosa jika itu terjadi lagi.

Dari pengalaman saya apa yang bos Anda inginkan adalah jaminan tingkat bahwa ini tidak akan terulang kembali. Jika tidak ada kode yang menjadi penyebabnya, karena itu dijamin oleh pengujian kesatuan, jadi anggap Anda sudah memiliki cakupan pengujian pada basis kode Anda, solusinya harus menambahkan "pengujian" ke database Anda. Saya akan mengutip Don Gilman, karena dia memaku di sana:

Database produksi harus memiliki akses penuh logging dan kontrol akses berbasis peran. Dengan demikian, Anda harus memiliki bukti kuat tentang WHO melakukan APA SAJA ke database sehingga memindahkan perhatian dari kode ke keamanan operasional yang buruk.

Tetapi juga, Anda harus memiliki Prosedur Operasi Standar untuk mengubah data dalam produksi. Misalnya, tidak ada DBA yang harus mengubah data, tidak ada pengembang yang harus melaksanakan perubahan itu sendiri dan mereka, sebagaimana didefinisikan dalam SOP, harus saling meminta secara resmi perubahan melalui surat atau tiket.

Pasti ada kutipan seperti ini di suatu tempat, jika tidak Anda bisa mengutipnya:

Ada alasan yang sangat bagus untuk koki yang tidak bertanggung jawab untuk membersihkan toilet.

Ada beberapa hal yang harus dilakukan dengan bug yang tidak dapat direproduksi.

1. Buat tiket untuk itu

Buat tiket, dan catat semua yang dapat Anda pikirkan di tiket. Periksa juga apakah "bug" ini telah dicatat sebelumnya, dan tautkan tiketnya. Akhirnya, Anda mungkin mendapatkan tiket yang cukup untuk membentuk pola bagaimana mereproduksi bug. Ini termasuk bekerja di sekitar yang digunakan untuk mencoba menghindarinya. Bahkan jika ini adalah satu-satunya contoh, jika ada yang pertama kali, pada akhirnya akan ada yang kedua kalinya. Ketika Anda menemukan penyebabnya, tutup tiketnya dengan penjelasan tentang apa penyebabnya sehingga Anda memiliki gagasan kuat tentang apa yang terjadi jika itu terjadi lagi (memperbaiki hilang dalam penggabungan yang buruk)

2. Lakukan analisis pengerasan

Lihatlah sistem, apa yang gagal, dan bagaimana itu gagal. Cobalah untuk menemukan area kode yang dapat diperbarui untuk mengurangi kemungkinan kegagalan. Beberapa contoh...

• Ganti kode ad-hoc dengan panggilan khusus (seperti execute(<query>)denganexecuteMyStoredProcedure(<params>)
• Jalankan skrip verifikasi malam hari untuk memverifikasi integritas data (sehingga ini dapat dideteksi dalam 24 jam berikutnya)
• Tambahkan / tingkatkan pencatatan dan pengarsipan (pencadangan).
• Mengubah batas keamanan yang tidak tepat (misalnya, orang / program yang hanya membaca data tidak memiliki izin menulis; Tidak membiarkan pengembang yang tidak bertanggung jawab atas produksi tidak dapat masuk ke server produksi)
• Tambahkan verifikasi data / sanitasi jika tidak ada

Ini mungkin tidak memperbaiki bug, tetapi bahkan jika tidak, sistem sekarang lebih stabil / aman sehingga masih terbayar.

3. Tambahkan peringatan sistem

Agak bagian dari 2, tetapi sesuatu terjadi, dan Anda perlu tahu kapan itu terjadi lagi. Anda harus membuat beberapa skrip / program pemeriksaan kesehatan untuk memantau sistem, sehingga admin dapat diperingatkan dalam waktu 24 jam sejak pelapisan ulang bug (semakin sedikit penundaan, semakin baik, semakin masuk akal). Ini akan membuat pembersihan lebih mudah. (Perhatikan bahwa selain log basis data, OS juga harus mencatat siapa yang log in, dan setiap tindakan yang tidak dibaca yang mereka lakukan. Paling tidak, harus ada log jaringan lalu lintas ke mesin itu)

Masalah Anda bukan disebabkan oleh kesalahan pada perangkat lunak Anda, tetapi oleh seseorang yang mengutak-atik database. Jika Anda menyebut hal-hal yang salah sebagai "bug", maka bug Anda mudah direproduksi: Hal-hal akan selalu salah ketika seseorang melakukan hal-hal bodoh ke database. Dan ada beberapa cara untuk menghindari "bug" ini, dengan tidak mengizinkan database untuk dimodifikasi secara manual atau menggunakan perangkat lunak yang tidak diuji, dan dengan secara ketat mengontrol siapa yang dapat memodifikasi database.

Jika Anda hanya menyebut kesalahan dalam database Anda sebagai "bug", maka Anda tidak memiliki bug yang tidak dapat diproduksi kembali, Anda tidak memiliki bug sama sekali. Anda mungkin memiliki laporan bug, tetapi Anda juga memiliki bukti bahwa masalahnya bukan disebabkan oleh bug. Jadi Anda dapat menutup laporan bug, bukan sebagai "tidak dapat diproduksi ulang", tetapi sesuatu yang lain seperti "database rusak". Tidak jarang ada laporan bug di mana investigasi menunjukkan tidak ada bug, tetapi pengguna menggunakan perangkat lunak yang salah, harapan pengguna salah, dll.

Jika demikian, Anda masih tahu ada masalah yang tidak ingin diulang, jadi Anda mengambil tindakan yang sama seperti pada kasus pertama.