WNDW: Teknik pemecahan masalah yang baik

From OnnoWiki
Revision as of 06:25, 10 September 2009 by Onnowpurbo (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Tidak ada metodologi troubleshooting yang dapat secara keseluruhan mengatasi semua masalah yang anda temukan ketika bekerja dengan jaringan-jaringan nirkabel. Namun seringkali, masalah biasanya berupa satu dari beberapa kesalahan yang umum. Berikut ini adalah beberapa petunjuk yang sebaiknya diingat agar usaha pemecahan masalah anda berada di jalur yang benar.

  • Jangan panik. Jika anda meng-troubleshoot sebuah sistem, ini berarti bahwa alat itu pernah berfungsi, bahkan mungkin baru-baru saja. Sebelum bergerak dan membuat perubahan, surveilah situasi dan teliti secara seksama apa yang rusak. Jika anda memiliki log historis atau data statistik yang anda bisa acu, semakin baik. Pastikan untuk pertama-tama mengumpulkan informasi, sehingga anda dapat mengambil keputusan berinformasi sebelum membuat perubahan.
  • Apakah sudah tercolok? Langkah ini seringkali diabaikan sampai semua pilihan tereksplorasi. Colokan dapat baik secara sengaja ataupun tidak sengaja terlepas secara mudah. Apakah tembaga tersambung pada sumber daya yang baik? Apakah ujung yang lain tersambung ke alat anda? Apakah lampu sumber daya menyala? Ini mungkin terkesan bodoh, tetapi anda akan merasa lebih bodoh jika anda meluangkan banyak waktu mengecek sebuah jalur input antena hanya untuk menyadari bahwa colokan titik akses ternyata terlepas. Percayalah, ini lebih sering terjadi daripada kebanyakan dari kita yang mau mengaku.
  • Apa yang terakhir kali dirubah? Jika anda merupakan satu-satunya orang dengan akses ke sistem, apakah yang paling terakhir anda rubah? Jika orang lain memiliki akses, apakah perubahan terakhir yang mereka buat dan kapan? Kapan terakhir kali sistem bekerja? Seringkali, perubahan-perubahan sistem memiliki konsekuensi yang tidak diinginkan yang mungkin tidak dapat secara langsung ditemukan. Kembalikan ke konfigurasi semula dan perhatikan efek apa yang dilakukannya terhadap permasalahan.
  • Buatlah backup. Ini berlaku sebelum anda menemukan masalah, serta setelahnya. Jika anda membuat perubahan perangkat lunak yang rumit pada sebuah sistem, memiliki sebuah backup berarti anda dapat secara cepat mengembalikannya ke konfigurasi sebelumnya dan memulai kembali. Ketika memecahkan masalah yang sangat rumit, memiliki sebuah konfigurasi yang “kira-kira” dapat bekerja jauh lebih baik daripada menghadapi kerumitan yang tidak dapat bekerja sama sekali (dan ini bukanlah sesuatu yang anda dapat kembalikan secara mudah dari memori).
  • Sesuatu yang baik yang diketahui. Gagasan ini berlaku pada perangkat keras, serta lunak. Sesuatu yang baik yang diketahui adalah komponen apapun yang anda dapat tukar dalam sebuah sistem yang kompleks untuk mengecek bahwa komponen yang sama yang terpasang berada dalam kondisi yang baik dan berfungsi. Misalnya, anda mungkin membawa sebuah kabel Ethernet yang sudah diuji dalam kotak perlengkapan anda. Jika anda menduga ada masalah dengan kabel di lapangan, anda dapat secara mudah mengganti kabel yang bermasalah tersebut dengan kabel yang sudah diuji tersebut dan melihat apakah kondisinya membaik. Ini jauh lebih cepat dan memiliki kerentanan kesalahan yang lebih sedikit dibandingkan dengan meng-crimping sebuah kabel, dan secara langsung memberitahu anda apakah perubahan tersebut menyelesaikan masalah. Begitu pula, anda juga dapat memasukan sebuah baterai, kabel antena, atau CD-ROM cadangan dengan konfigurasi yang sudah dianggap baik untuk sistem tersebut. Ketika memperbaiki masalah yang rumit, menyimpan pekerjaan anda pada suatu tahap memungkinkan anda untuk kembali ke sesuatu yang baik yang diketahui, walaupun masalah tersebut belum sepenuhnya teratasi.
  • Rubahlah variabel satu per satu. Ketika dalam tekanan untuk menghidupkan sistem yang rusak kembali online, sangatlah menggiurkan untuk langsung bergerak dan merubah beberapa variabel sekaligus. Jika anda tetap melakukan ini, dan perubahan anda sepertinya memperbaiki permasalahannya, maka anda tidak akan mengerti secara persis apa yang sebenarnya menimbulkan masalah tersebut pada awalnya. Lebih buruk lagi, perubahan anda mungkin memperbaiki permasalahan utama, namun menimbulkan konsekuensi yang tidak diinginkan yang merusak bagian lain sistem. Dengan merubah variabel anda satu per satu, anda dapat secara persis memahami apa yang mula-mula salah, dan dapat melihat efek langsung dari perubahan yang anda buat.
  • Jangan merusak. Jika anda tidak sepenuhnya mengerti bagaimana sebuah sistem berfungsi, janganlah ragu-ragu untuk memanggil seseorang yang ahli. Jika anda tidak yakin apakah sebuah perubahan akan merusak bagian sistem, maka carilah seorang yang ahli dengan banyak pengalaman atau buat sebuah cara untuk menguji perubahan anda tanpa merusak. Meletakan sebuah koin logam sebagai pengganti sekering mungkin akan menyelesaikan masalah secara langsung, namun mungkin juga akan menyebabkan kebakaran.
  • Sepertinya tidak mungkin orang yang mendesain jaringan anda akan tersedia 24 jam setiap hari untuk memperbaiki kesalahan ketika mereka muncul. Tim troubleshooting anda akan memerlukan keahlian troubleshooting yang baik, tetapi mungkin tidak cukup kompeten untuk mengkonfigurasi router dari nol atau untuk meng-crimp sebuah bagian dari LMR-400. Adalah seringkali lebih efisien untuk membuat beberapa komponen backup selalu tersedia, dan melatih tim anda untuk dapat mengganti seluruh bagian yang rusak. Ini dapat berarti memiliki sebuah titik akses yang sudah dikonfigurasikan dan tersedia di lemari yang terkunci, dilabel secara sederhana, dan disimpan dengan kabel dan sumber daya cadangan.

Tim anda dapat menukar komponen yang gagal, dan entah mengirim bagian yang rusak ke yang ahli untuk diperbaiki, atau mengatur agar cadangan dikirim. Mengasumsikan cadangan tersebut tersimpan dengan aman dan diganti ketika digunakan, ini akan menghemat banyak waktu untuk siapa saja.


Pranala Menarik