Aturan pemecahan masalah Anda, pendekatan untuk pemecahan masalah? [Tutup]

Apakah Anda memiliki aturan umum yang Anda gunakan ketika Anda memecahkan masalah jaringan / perangkat keras / perangkat lunak yang sulit?

Misalnya: "Saya mengisolasi sumber masalah dengan menguji periferal dengan komputer kedua" atau "Saya menghapus perangkat keras sebanyak mungkin untuk menghidupkan perangkat, dan kemudian menambahkan kembali komponen satu per satu hingga saya dapat mereproduksi masalah" , dll.

Hanya daftar poin yang saya tulis untuk diri saya sendiri setelah berjuang dengan masalah untuk sementara waktu:

1. Apa tujuan utama Anda ? Harus dinyatakan dengan jelas dan singkat. Tujuannya harus sangat khusus. Seharusnya tidak umum. Lebih disukai satu kalimat .
   
2. Apa masalahmu ?
   
3. Apakah hanya ada satu masalah atau banyak ? Jika ada banyak, selesaikan satu per satu.
   
4. Cobalah untuk mereproduksi masalah dengan kondisi berbeda . Bisakah itu direproduksi dalam semua kondisi yang memungkinkan atau tidak? Apakah itu mengatakan sesuatu tentang sifat masalahnya?
   
5. Jika ini masalah yang mendesak, adakah solusi untuk hal ini ? Cobalah untuk menemukan solusi sebanyak mungkin.
   
6. Cobalah membuat tebakan sebanyak mungkin tentang apa yang menjadi penyebab masalah Anda.
   
7. Coba buktikan tebakan Anda, bereksperimenlah dengan sistem.
   
8. Bersikaplah konsisten dengan apa yang Anda coba lakukan. Lakukan satu per satu.
   
9. Pantau apa yang Anda lakukan, apa yang sudah Anda coba.
   
10. Jangan menyimpang dari tujuan utama Anda. Terus periksa apakah Anda masih menyelesaikan masalah utama Anda, bukan masalah yang berbeda.
    
11. Jangan fiksasi juga.

Ada juga daftar besar aturan debugging, itu dalam bentuk PDF dengan contoh dan penjelasan untuk masing-masing aturan. Saya tidak dapat dengan cepat menemukan PDF, tetapi saya pikir ini adalah poster dari daftar:

• Jika masalahnya terkait Internet, kemungkinan itu adalah DNS.

• Jika masalahnya sulit didiagnosis, mungkin itu adalah RAM.

• Jika masalahnya ada pada workstation Windows, mungkin yang paling cepat adalah reimage-nya.

• Jika masalahnya adalah pada hari Jumat, itu mungkin sesuatu yang serius.

Saya suka kembali ke metode ilmiah .

Dari ( http://en.wikipedia.org/wiki/Scientific_method )

1. Definisikan pertanyaan
2. Kumpulkan informasi dan sumber daya (amati)
3. Bentuk hipotesis
4. Lakukan percobaan dan kumpulkan data
5. Menganalisis data
6. Menafsirkan data dan menarik kesimpulan yang berfungsi sebagai titik awal untuk hipotesis baru
7. Hasil Dokumen

Sebagai aturan umum saya selalu ingin mencoba dan memeriksa ulang asumsi dasar saya. Apakah itu memiliki kekuatan, apakah sudah terpasang, adalah kabel yang baik. Sangat menjengkelkan untuk menghabiskan berjam-jam mencoba melihat masalah perangkat lunak ketika Anda memiliki kabel longgar.

Saya merasa sangat penting selama fase penciptaan hipotesis untuk benar-benar menemukan sebanyak mungkin penyebab masalah yang saya bisa. Kemudian saya mencoba dan memilih ide untuk diuji terlebih dahulu berdasarkan seberapa mudahnya untuk menguji, dan seberapa besar kemungkinan ide tersebut.

Penting juga untuk mendapatkan bantuan. Konsultasikan dengan rekan kerja Anda, vendor, atau siapa pun yang paling tahu tentang sistem yang dimaksud jika Anda bisa. Jangan menghabiskan banyak waktu memutar roda Anda pada masalah jika ada seseorang yang tersedia yang dapat membantu Anda memecahkan masalah.

O'Reilly memiliki buku yang bagus Network Troubleshooting Tools yang memiliki serangkaian langkah untuk diikuti yang sangat mirip dengan metode ilmiah. Saya menemukan buku itu sangat bermanfaat dan sangat merekomendasikannya. Buku ini membahas lebih banyak detail dan menyarankan banyak alat yang bermanfaat.

Dari Alat Pemecahan Masalah Jaringan

1. Nyatakan tujuan Anda
2. Tentukan sistem
3. Identifikasi kemungkinan hasil
4. Identifikasi dan pilih apa yang akan Anda ukur
5. Jika sesuai, identifikasi paramater dan faktor uji
6. Pilih alat
7. Menetapkan batasan pengukuran
8. Tinjau desain eksperimental
9. Mengumpulkan data
10. Menganalisis data

Lihat juga:

• 3COM memiliki panduan pemecahan masalah
• Hukum Murphy - Apa pun yang bisa salah, lakukan.
• Occam's_razor - Semua hal lain dianggap sama, solusi paling sederhana adalah yang terbaik.

(Sorotan ini diparafrasekan dari bab "Debugging" dari "Praktek Sistem dan Administrasi Jaringan" )

Dua hal yang perlu diketahui:

1. Ketahui seperti apa versi "tetap" itu. Lebih disukai perintah yang dapat Anda jalankan yang memberikan output tertentu ketika semuanya bekerja. Sebagai contoh: Saya mencoba mencari tahu mengapa SSH meminta kata sandi ketika saya sudah mengatur kunci dengan benar (atau saya pikir begitu). Jadi pengujian saya adalah: "uptime servername ssh" dan seharusnya berfungsi tanpa meminta kata sandi.

2. Jelaskan masalah di tingkat yang tepat. Seorang pengguna yang mengeluh bahwa mereka tidak dapat melakukan ping ke sebuah server seharusnya tidak mengirim Anda untuk menjalankan dan memperbaiki server. Pekerjaan orang itu bukan duduk-duduk dan mesin ping sepanjang hari. Mereka ingin menyelesaikan beberapa jenis tugas seperti menggunakan mesin sebagai server DNS mereka. Contoh: Sekali pengguna mengeluh bahwa mereka tidak bisa melakukan ping ke mesin di belahan dunia lain. Saya menghabiskan hari melacak sysadmin di bagian perusahaan untuk mencari tahu apa yang salah dengan mesin itu. Itu dinonaktifkan dan mereka panik karena mereka pikir mungkin mereka mematikan mesin yang salah. Saya menghubungi pengguna dan berkata "selain perlu melakukan ping mesin ini, apa yang ingin Anda lakukan dengannya?". Ternyata dia ingin menjalankan pekerjaan tertentu dan jika dia mengikuti prosedur yang tepat, tugasnya akan secara otomatis dialihkan ke mesin pengganti. Saya telah menghabiskan seluruh hari dan waktu sysadmin lokal saya. Alasan lain "Saya tidak bisa ping" bukanlah hal yang tepat untuk diuji: Seringkali firewall dikonfigurasikan untuk menjatuhkan paket ping tetapi mengizinkan paket lain lewat. Uji apa yang ingin Anda lalui.

Dua strategi:

1. Aditif: Terus menambahkan komponen sampai masalah dimulai. Hal terakhir yang Anda tambahkan adalah masalahnya. Contoh: Browser web tidak dapat berbicara dengan server. Antara server dan pengguna adalah penyeimbang beban, firewall, cache, dan proksi web lokal pengguna. Pertama-tama coba kirim pertanyaan langsung ke server, kemudian melalui LB ke server, lalu melalui firewall ke LB ke server, dll. Setiap kali menambahkan satu komponen.

2. Subtraktif: Terus melepas komponen sampai masalah hilang. Hal terakhir yang Anda lepaskan adalah masalahnya: Contoh: Mesin dengan puluhan kartu tidak mau boot. Lepaskan kartu sampai mesin melakukan booting.

Dua bit keberuntungan:

1. Lupakan semua yang saya katakan. Masalahnya disebabkan oleh perubahan terakhir yang dilakukan pada sistem. (ini bekerja 99% dari waktu ... masalahnya adalah 99% dari waktu Anda tidak tahu apa perubahan terakhir yang sebenarnya)

2. Ketika semuanya gagal, periksa hal-hal bodoh. http://whatexit.org/tal/mywritings/dumb-things-to-check.html Contoh: Masalah gila tidak bisa dijelaskan. Kemudian kami memeriksa file konfigurasi: pengguna telah mengeditnya dengan menyalinnya ke kotak Windows, mengeditnya, lalu menyalinnya kembali. Sekarang memiliki ^ M di akhir setiap baris. Kami tidak pernah memperhatikan karena editor teks kami secara diam-diam menyembunyikan fakta ini. Sayangnya, perangkat lunak yang membaca file konfigurasi mengubah ^ Ms menjadi ruang tanpa istirahat yang mengacaukan banyak prosedur lainnya.

Praktik umum yang saya ingat selama seluruh proses:

1. Tuliskan semua yang saya lakukan.
2. Lakukan hanya satu perubahan pada satu waktu.
3. Jika memungkinkan, balikkan perubahan sebelum mencoba yang lain kecuali jika ada kemajuan yang pasti.

Selama pemecahan masalah di sini, saya mendefinisikan metodologi dasar:

• Ketika sistem menyala dan berjalan dengan baik, sebelum ada masalah, saya mencoba belajar untuk melihat apa yang dilakukannya. Joe Richards menjelaskan mengapa jauh lebih baik daripada yang saya bisa dalam ruang pendek ini .
• Saya mulai dengan solusi paling sederhana. Misalnya, tidak ada konektivitas jaringan? Periksa lapisan fisik. Saya tidak bisa memberi tahu Anda berapa kali masalah koneksi terputus-putus bukan masalah server tetapi kabel jaringan yang setengah atau yang sudah buruk.
• Saya mencoba menangkap semua gejala yang bisa saya lihat dari semua sumber yang mungkin sebelum saya mulai membuat perubahan.
• Saya menjalankan tes diagnostik awal. Sebagai contoh, ketika saya diberi tahu server sedang down, hal pertama yang saya lakukan adalah menggunakan ping dan nbtstat (Windows) untuk memverifikasi itu. Masalahnya bisa berada di ujung yang jauh (untuk meminjam pepatah kontrol Angkatan Udara kuno).
• Saya tidak takut melakukan penelitian. Google, support.microsoft.com, eventid.net dan situs-situs seperti itu adalah teman Anda.
• Saya tidak takut meminta bantuan dari masyarakat. Bukan hanya situs seperti serverfault.com, tetapi saya memiliki banyak orang yang saya percayai dan hormati di Twitter yang saya hubungi.
• Saya mengevaluasi jawaban yang saya temukan dengan apa yang saya lihat. Saya tidak berasumsi bahwa ada satu solusi yang tepat sampai saya dapat melakukan pertimbangan yang cukup dari bukti yang saya lihat dengan apa yang dilaporkan dalam solusi.

Sikap yang saya coba pertahankan:

• Keyakinan mutlak yang menyebabkan efek bekerja dan tidak ada yang ajaib. Tidak ada yang terjadi yang sebenarnya aneh, hanya hal-hal yang saya tidak mengerti.
• Keyakinan mutlak bahwa jika saya terus mendorongnya, saya akan menyelesaikannya (ini mungkin melibatkan membawanya ke seseorang yang lebih berpengetahuan, belajar, meminta bantuan, kerja keras, dll).
• Menggerutu tentang bagaimana pengaturan, program atau skenario dirancang dengan buruk atau benar-benar bodoh tidak membantu, jadi jangan lakukan itu. (Saya menemukan ini sulit, menggerutu itu menyenangkan).

Ini adalah sikap yang membantu saya untuk memegang - mereka menghentikan saya mengangkat tangan saya di udara, menyatakan sesuatu yang "aneh" dan kemudian menyerah, atau menjadi tidak bahagia karena rasanya "tidak dapat dipecahkan".

Cara saya berpikir tentang pemecahan masalah:

• Sistem memiliki banyak bagian, jika mereka terhubung bersama atau dikonfigurasi secara acak maka mereka tidak akan berfungsi seperti yang diinginkan. Ada satu atau dua konfigurasi yang sangat spesifik yang akan berhasil - dari jutaan cara menumpuk batu bata dan logam, hanya beberapa yang merupakan jembatan dan hanya satu atau dua yang merupakan jembatan yang cukup baik. Penyebabnya bisa karakter dalam file teks atau server gagal, tetapi setiap bagian harus benar untuk semuanya menjadi benar. Saya harus mau teliti dan teliti jika diperlukan. Sistem tidak dapat melakukan "acara harus berjalan".
• Anda mulai dengan seluruh sistem seperti peta, Anda membayangkan awan probabilitas melayang di atas peta yang mewakili "di mana masalahnya" dan tugas Anda adalah menggunakan pengalaman dan menemukan tes untuk mendorong probabilitas menjauh dari beberapa area dan ke arah yang lain dan untuk menyingkatnya ke titik-titik yang merupakan lokasi masalah probabilitas tinggi, lalu serang mereka. Ini kembali ke titik sebab dan akibat - masalahnya ada di sistem, itu bukan sihir. Ini adalah masalah yang ada sehingga harus ada di suatu tempat.
• Apa pun bisa diatur sesuai keinginan siapa pun. Satu-satunya cara kita dapat mendefinisikan satu perilaku sebagai "OK" dan yang lain sebagai "masalah" adalah karena apa yang diperoleh seseorang bukanlah yang mereka inginkan. Anda harus memahami apa yang mereka inginkan, apa yang mereka dapatkan dengan jelas dan spesifik.

Proses pemecahan masalah:

• Apa masalahnya. Pastikan Anda melihatnya terjadi dan dapat mereproduksi sendiri sehingga tidak ada miskomunikasi. Seringkali masalah telah melalui beberapa orang di helpdesk kami pada saat mereka sampai kepada saya, tidak ada yang bisa menjelaskan kepada saya apa masalahnya sebenarnya.
• Ini membagi dua rekursif lagi - membagi dan menaklukkan, pencarian biner - Anda datang dengan tes yang akan membuktikan jika masalahnya adalah sisi tes ini, atau sisi itu, dan membuat tes sehingga menghilangkan sebanyak mungkin. Ulangi sampai selesai.
• Jangan belajar jika Anda bisa menghindarinya - lebih baik mengunci akun database dan membuktikan bahwa masalahnya masih terjadi ketika database tidak terlibat daripada menghabiskan berjam-jam mempelajari bagaimana database digunakan.
• Terlalu mudah untuk menemukan diri saya berpikir "Saya tidak tahu apa yang harus saya lakukan selanjutnya". Perhatikan kapan hal itu terjadi dan kembalilah ke tes yang menemukan masalahnya.

Internet tidak berfungsi? Periksa masalahnya, temukan itu adalah situs web yang tidak dapat mereka kunjungi. Tes cepat melibatkan koneksi internet mereka (berfungsi), apakah itu memuat untuk saya (tidak). Tes cepat menunjukkan itu menjadi situs. Dengan melihat masalah yang terjadi pada saya, saya telah mendorong probabilitas dengan cepat dari PC, browser, DNS, firewall kantor akun pengguna, dll.

Jadi situs tidak memuat, sekarang bagaimana? Itu belum diperbaiki, jadi cari tempat untuk mengukir masalahnya menjadi lebih kecil. Apakah server aktif? Apakah ini ping? apakah DNS berfungsi? Iya nih. Apakah layanan menjawab pada port 80? Tidak. Apakah layanan berjalan? Apakah ini dimulai? Tidak. Apakah ada kesalahan pada log event / logfiles? Iya nih! Apa yang mereka katakan?

Ini adalah pemecahan masalah yang efisien dan cepat karena tanpa henti fokus pada mempersempit ruang lingkup masalah. Jika saya menerima laporan mereka bahwa internet tidak berfungsi, saya akan keliru menganggapnya sebagai kegagalan koneksi. Jika saya menerima penampakan pertama saya bahwa itu tidak memuat untuk mereka, saya akan membuang waktu di komputer mereka berpikir itu salah.

Buat potongan "hal-hal yang tidak mungkin" sebesar mungkin.

Pahami sistemnya. Semakin banyak pengetahuan umum yang saya miliki tentang suatu sistem, semakin mudah mendapatkannya. Di mana saya memiliki pemahaman yang lemah, masalah lebih menakutkan, lebih sulit, lebih lambat, dan lebih mungkin berakhir dengan solusi daripada perbaikan, atau dengan perbaikan besar-besaran lambat (instal ulang) daripada perbaikan kecil, tepat bedah.

Secara umum saya bertanya "Apa yang telah berubah yang mungkin menyebabkan masalah ini"? Sebagian besar masalah disebabkan oleh perubahan pada konfigurasi yang diketahui baik. Jika Anda dapat mengisolasi siapa yang melakukan perubahan maka Anda biasanya mendapatkan jawaban Anda.

Saya pikir itu keterampilan, bukan ilmu. Ada saat-saat ketika Anda menempuh jalan yang salah tetapi sebagian besar:

• Memiliki pemahaman dasar yang baik tentang semua teknologi terkait - Jaringan, perangkat keras, OS, perangkat lunak, pengembangan, dll. - akan membantu Anda menghilangkan beberapa "jalur yang salah"
• berfikir dasar - jangan langsung ke skenario paling rumit karena ada di kepala Anda, lakukan pemecahan masalah dasar Anda dan biarkan itu menuntun Anda.

Saya pernah meminta atasan memanggil saya dengan seorang insinyur "senior" di telepon - dia mengatakan kepada saya bahwa dia memiliki satu server yang tidak dapat terhubung dan dia telah mencoba mengganti kabel tetapi masih tidak ada sukacita. Saya bisa mendengar bunyi bip di latar belakang seperti UPS dengan baterai. Saya bertanya kepadanya apakah dia bisa melihat aktivitas di sakelar, dia bilang tidak. Saya bertanya kepadanya apakah bunyi bip datang dari UPS, dia berkata ya, saya bertanya kepadanya apakah dia bisa melihat lampu menyala sama sekali di rak, dia bilang tidak ... Lihatlah di balik hidungmu - ini membantu!

Saya mulai dengan memeriksa yang sudah jelas. Apakah ada pesan kesalahan yang menjelaskan apa masalahnya? Apakah semuanya terhubung dengan benar? Saya tidak suka menghabiskan beberapa jam untuk memecahkan masalah, sesuatu yang bisa diselesaikan dalam beberapa menit. Saya pikir mungkin terlalu metodis. Saya telah melihat orang menghabiskan sepanjang hari mereproduksi masalah meskipun faktanya saya mengatakan kepada mereka apa masalahnya. Bukan itu yang saya bayar untuk mereka.

Jika jawabannya tidak jelas, susun beberapa tersangka dan ujilah terlebih dahulu. Hanya setelah Anda menguji kemungkinan tersangka Anda harus menguji tersangka tidak mungkin. Maka Anda bisa seilmiah yang Anda inginkan.