Analisis akar penyebab: 4 Kiat untuk memecahkan masalah kerusakan secara lebih cepat

Bayangkan ini: Anda dan tim Anda bekerja sepanjang hari untuk menyelesaikan versi besar produk perangkat lunak Anda. Anda membuat fitur-fitur baru dengan laju yang baik. Tim memperbaiki bug segera setelah QA melaporkannya. Pengujian unit semuanya hijau. Setelah aplikasi diberi lampu hijau oleh rangkaian pengujian yang lebih komprehensif, inilah waktunya untuk mengirimkannya. Lalu—buum! Segera setelah ia sampai di lingkungan produksi, aplikasi rusak secara luar biasa. Apa yang salah?

Ternyata, lingkungan pengujian tidak dekat dengan produksi seperti yang Anda pikirkan sebelumnya. Perubahan infrastruktur dibuat pada lingkungan itu tanpa ada catatan sama sekali. Hasilnya, kedua lingkungan tersebut perlahan menjauh.

Sebagai profesional dalam industri teknologi, porsi yang cukup besar dari waktu kita dihabiskan untuk memecahkan masalah kerusakan. Dan ya, kita menghabiskan waktu untuk memperbaikinya juga—tapi Anda tidak dapat memperbaiki sesuatu jika Anda tidak tahu apa yang salah. Sebagai developer perangkat lunak yang menghabiskan banyak waktu di depan debugger, saya akan memberitahu Anda bahwa, seringkali, bagian paling sulit adalah mencari bug. Segera setelah Anda tahu apa masalahnya, memperbaikinya mungkin menjadi mudah.

Jadi, mempelajari cara memecahkan masalah dengan lebih cepat adalah salah satu investasi yang dapat Anda buat sebagai developer perangkat lunak atau pekerja IT secara umum.

Mari bahas bagaimana kita dapat mencari masalah dengan cepat dan memperbaikinya lebih cepat.

Analisis akar penyebab: Apa itu dan mengapa Anda harus peduli?

Analisis akar penyebab (RCA) adalah teknik spesifik yang Anda gunakan untuk memecahkan permasalahan. Dengan teknik ini, Anda menganalisis masalah yang dihadapi menggunakan serangkaian langkah tertentu untuk mengidentifikasi penyebab primer dari masalah. RCA didasarkan pada prinsip bahwa tidak berguna untuk menanggapi gejala masalah tapi mengabaikan akarnya.

Dengan menggunakan RCA, Anda akan dapat memahami apa yang telah terjadi. Seringkali, Anda tidak dapat mendapatkan gambaran lengkap hanya dengan mengamati gejalanya. Namun, menentukan apa yang terjadi hanyalah langkah pertama—Anda lalu perlu mendalami dan mengungkap alasan mengapa hal itu terjadi. Dibekali dengan pengetahuan ini, inilah waktunya untuk mempraktikannya dengan merumuskan rencana atau strategi untuk mengurangi kemungkinan hal itu terjadi kembali.

Dengan “apa” dan “kenapa” sudah diketahui, berikut ini adalah empat kiat yang akan membantu menggunakan RCA untuk memiliki lebih sedikit masalah.

Gunakan pendekatan bebek karet
Ya, saya serius, pendekatan bebek karet. Saya tidak membual. Pendekatan ini juga disebut debugging bebek karet, dan mungkin ada beberapa nama lainnya. Ini terdiri dari menjelaskan masalah Anda ke sebuah bebek karet. Apakah Anda punya bebek karet? Jangan khawatir! Anda dapat menggunakan benda mati lainnya yang Anda miliki. Atau Anda dapat berbicara kepada orang lain!

Jadi, apa maksudnya pendekatan bebek karet? Pendekatan ini didasarkan pada efek yang teramati bahwa dengan menjelaskan sesuatu ke orang lain, Anda memaksa diri Anda sendiri untuk menata pikiran Anda. Proses pemikiran kita seringkali berantakan atau kacau. Ketika kita dihadapi dengan prospek harus menjelaskan pikiran kita ke orang lain, kita tidak punya pilihan lain selain menata pikiran kita. Jeff Atwood, salah satu pendiri situs Q&A terkenal yaitu Stack Overflow, berbicara tentang berapa kali developer perangkat lunak pernah memberitahunya bahwa mereka menuliskan pertanyaan baru ke situs, menemukan jawabannya untuk diri sendiri dalam prosesnya, dan tidak pernah mengirimkan pertanyaan!

Apakah pendekatan bebek karet cukup untuk memecahkan masalah apa saja? Tentu tidak. Mungkin iya, tapi seringkali ini hanya langkah pertama dalam strategi yang lebih luas.

Apakah Anda takut bahwa orang lain akan berpikir Anda aneh karena berbicara pada benda mati? Masalahnya, ide tentang bebek karet ini sebenarnya suatu candaan. Bebek karet itu tokoh yang konyol dan berkesan, tidak semestinya dianggap serius. Hal terpenting adalah bahwa Anda memaksa diri sendiri untuk mengungkapkan pikiran dalam kepala Anda secara berurutan, menjelaskan permasalahan yang dihadapi sejelas mungkin.

Anda dapat menggunakan pendekatan berikut:
1. Menuliskan pertanyaan Stack Overflow. Atau Anda dapat berpura-pura bahwa Anda menuliskan pertanyaan Stack Overflow tapi menuliskannya di Notepad.
2. Buat file laporan bug yang detail. Pasti ada yang harus melakukannya, jadi mengapa tidak melakukannya sekalian?
3. Hampiri meja kerja/kantor rekan Anda dan bicara kepada mereka selama beberapa menit. Tentu, selama mereka tidak masalah dengan itu. Jangan ganggu rekan Anda tanpa keperluan.


Kumpulkan banyak data log (dan lakukan pencarian secara efisien)

Jika Anda berhasil menjelaskan masalah dengan jelas tapi masih tidak dapat menemukan akar penyebabnya, maka Anda harus melakukan hal lebih. Hal yang diperlukan saat ini adalah mengumpulkan data tentang masalah dan mengekstraksi wawasan dari data itu.

Pencatatan dan pemantauan dapat sangat berguna di sini—log kerusakan, log aplikasi dan server, dan apa yang Anda lakukan. Anda harus mengumpulkan butki bahwa masalah terjadi tapi juga, jika mungkin, mencari tahu berapa lama hal itu telah terjadi dan seberapa sering.

Namun, Anda tidak boleh berhenti di sini. Mengumpulkan banyak data itu penting, tapi semua data tidak akan banyak berguna jika Anda tidak cukup cepat menemukan hal spesifik yang Anda perlukan. Terjebak dalam situasi “jarum di antara jerami” tidak menyenangkan dan juga tidak produktif.

Ini adalah alasan mengapa Anda harus menggunakan alat yang memberdayakan Anda untuk mencari dan menganalisis semua data log yang telah Anda kumpulkan dalam waktu nyata dan mengubahnya menjadi wawasan berharga yang dapat Anda gunakan untuk mendiagnosis dan memecahkan masalah lebih cepat.


Gunakan teknik lima mengapa
Setelah Anda mengumpulkan informasi, ini adalah waktu untuk menggunakannya dengan mengidentifikasi faktor-faktor kausal. “Faktor kausal” di sini berarti penyebab langsung dari masalah yang dihadapi. Hal yang sebaiknya tidak Anda lakukan adalah mengidentifikasi satu faktor kausal lalu berhenti. Anda harus melakukan lebih. Salah satu teknik yang paling dikenal untuk itu adalah teknik lima mengapa.

Teknik ini terdiri dari mengajukan lima pertanyaan “Mengapa?” secara berulang sampai Anda mencapai akar masalah. Mari kita lihat contohnya:

Masalah: Situs web menampilkan kesalahan 500.
1. Mengapa? Karena komponen perutean kerangka kerja web tidak berfungsi benar.
2. Mengapa? Karena membutuhkan komponen lain, yang juga tidak berfungsi benar.
3. Mengapa? Karena komponen kerangka kerja web ini memerlukan ekstensi intl, yang tidak berfungsi.
4. Mengapa? Karena tidak sengaja dinonaktifkan setelah perangkat lunak server diperbarui.

Seperti yang dapat Anda lihat, angka lima hanya gambaran. Anda mungkin mencapai akar masalah dengan langkah yang lebih sedikit. Atau mungkin lebih.

Teknik lima mengapa ini jauh dari sempurna. Teknik ini menerima sejumlah kritik, dan pastinya memiliki keterbatasan tersendiri. Namun, teknik ini dapat berguna dalam mendorong para teknisi untuk terus mencari akar penyebab masalah dan bukannya berhenti ketika baru saja mendekati solusi.


Dapatkan sepasang mata lain
Satu praktik yang saya hargai dalam karier developer perangkat lunak saya adalah peninjauan kode. Sangat mengagumkan bagaimana sekadar memperoleh pandangan orang lain yang tanpa bias tentang kode Anda dapat mengungkapkan banyak masalah yang sebelumnya tidak Anda lihat. Seiring waktu, ekspektasi untuk mengajak orang lain melihat kode Anda akan membuat Anda semakin menyadari diri. Anda mulai memberikan perhatian lebih daripada biasanya.

Jadi, dengan hal ini, apakah saya merekomendasikan peninjauan kode? Ya, tapi itu bukan satu-satunya cara untuk mendapatkan sepasang mata lain. Saya menyarankan Anda untuk menggunakan proses mirip peninjauan pada hampir seluruh tugas yang dilakukan teknisi. Atau, lebih baik lagi, pasangan. Lakukan pemrograman pasangan, konfigurasi server pasangan, peer debugging, dan dukungan peer yang menghadap pelanggan. Singkatnya: lakukan pemecahan masalah berpasangan.

Sains atau seni?

Pemecahan masalah kerusakan adalah pada tahapan yang lebih bersifat seni daripada sains. Namun, ini tidak boleh menghentikan Anda dari menggunakan teknik dan alat-alat untuk membuatnya lebih efisien.

Jadi, gunakan teknik tersebut untuk melakukan RCA:
1. Gunakan pendekatan bebek karet
2. Kumpulkan banyak data log dan gunakan alat yang sesuai untuk mencari dan menganalisisnya
3. Gunakan teknik lima mengapa
4. Dapatkan sepasang mata lain

Ini waktunya untuk mengambil bebek karet Anda dan mulai menganalisis akar penyebab masalah Anda.

Pelajari selengkapnya tentang harga Amazon OpenSearch Service

Kunjungi halaman harga
Siap membangun?
Mulai Amazon OpenSearch Service
Ada pertanyaan lain?
Hubungi kami