Troubleshooting is a form of problem solving, often applied to repair failed products or

processes. It is a logical, systematic search for the source of a problem so that it can be
solved, and so the product or process can be made operational again. Troubleshooting is
needed to develop and maintain complex systems where the symptoms of a problem can
have many possible causes. Troubleshooting is used in many fields such as engineering,
system administration, electronics, automotive repair, and diagnostic medicine.
Troubleshooting requires identification of the malfunction(s) or symptoms within a
system. Then, experience is commonly used to generate possible causes of the symptoms.
Determining which cause is most likely is often a process of elimination - eliminating
potential causes of a problem. Finally, troubleshooting requires confirmation that the
solution restores the product or process to its working state.
In general, troubleshooting is the identification of, or diagnosis of "trouble" in the
management flow of a corporation or a system caused by a failure of some kind. The
problem is initially described as symptoms of malfunction, and troubleshooting is the
process of determining and remedying the causes of these symptoms.
A system can be described in terms of its expected, desired or intended behavior (usually,
for artificial systems, its purpose). Events or inputs to the system are expected to generate
specific results or outputs. (For example selecting the "print" option from various
computer applications is intended to result in a hardcopy emerging from some specific
device). Any unexpected or undesirable behavior is a symptom. Troubleshooting is the
process of isolating the specific cause or causes of the symptom. Frequently the symptom
is a failure of the product or process to produce any results. (Nothing was printed, for
example).
The methods of forensic engineering are especially useful in tracing problems in products
or processes, and a wide range of analytical techniques are available to determine the
cause or causes of specific failures. Corrective action can then be taken to prevent further
failures of a similar kind. Preventative action is possible using failure mode and effects
analysis (FMEA) and fault tree analysis (FTA) before full scale production, and these
methods can also be used for failure analysis.

Contents
[hide]
1 Aspects
2 Half-splitting
3 Reproducing symptoms
4 Intermittent symptoms
5 Multiple problems
6 See also
7 References

Aspects [edit]
Most discussion of troubleshooting, and especially training in formal troubleshooting
procedures, tends to be domain specific, even though the basic principles are universally
applicable.
Usually troubleshooting is applied to something that has suddenly stopped working, since
its previously working state forms the expectations about its continued behavior. So the
initial focus is often on recent changes to the system or to the environment in which it

exists. (For example a printer that "was working when it was plugged in over there").
However, there is a well known principle that correlation does not imply causality. (For
example the failure of a device shortly after it's been plugged into a different outlet
doesn't necessarily mean that the events were related. The failure could have been a
matter of coincidence.) Therefore troubleshooting demands critical thinking rather than
magical thinking.
It's useful to consider the common experiences we have with light bulbs. Light bulbs
"burn out" more or less at random; eventually the repeated heating and cooling of its
filament, and fluctuations in the power supplied to it cause the filament to crack or
vaporize. The same principle applies to most other electronic devices and similar
principles apply to mechanical devices. Some failures are part of the normal wear-andtear of components in a system.
A basic principle in troubleshooting is to start from the simplest and most probable
possible problems first. This is illustrated by the old saying "When you see hoof prints,
look for horses, not zebras", or to use another maxim, use the KISS principle. This
principle results in the common complaint about help desks or manuals, that they
sometimes first ask: "Is it plugged in and does that receptacle have power?", but this
should not be taken as an affront, rather it should serve as a reminder or conditioning to
always check the simple things first before calling for help.
A troubleshooter could check each component in a system one by one, substituting
known good components for each potentially suspect one. However, this process of
"serial substitution" can be considered degenerate when components are substituted
without regards to a hypothesis concerning how their failure could result in the symptoms
being diagnosed.
Simple and intermediate systems are characterized by lists or trees of dependencies
among their components or subsystems. More complex systems contain cyclical
dependencies or interactions (feedback loops). Such systems are less amenable to
"bisection" troubleshooting techniques.
It also helps to start from a known good state, the best example being a computer reboot.
A cognitive walkthrough is also a good thing to try. Comprehensive documentation
produced by proficient technical writers is very helpful, especially if it provides a theory
of operation for the subject device or system.
A common cause of problems is bad design, for example bad human factors design,
where a device could be inserted backward or upside down due to the lack of an
appropriate forcing function (behavior-shaping constraint), or a lack of error-tolerant
design. This is especially bad if accompanied by habituation, where the user just doesn't
notice the incorrect usage, for instance if two parts have different functions but share a
common case so that it isn't apparent on a casual inspection which part is being used.
Troubleshooting can also take the form of a systematic checklist, troubleshooting
procedure, flowchart or table that is made before a problem occurs. Developing
troubleshooting procedures in advance allows sufficient thought about the steps to take in
troubleshooting and organizing the troubleshooting into the most efficient
troubleshooting process. Troubleshooting tables can be computerized to make them more
efficient for users.
Some computerized troubleshooting services (such as Primefax, later renamed
Maxserve), immediately show the top 10 solutions with the highest probability of fixing

the underlying problem. The technician can either answer additional questions to advance
through the troubleshooting procedure, each step narrowing the list of solutions, or
immediately implement the solution he feels will fix the problem. These services give a
rebate if the technician takes an additional step after the problem is solved: report back
the solution that actually fixed the problem. The computer uses these reports to update its
estimates of which solutions have the highest probability of fixing that particular set of
symptoms.[1]

Half-splitting [edit]
Efficient methodical troubleshooting starts with a clear understanding of the expected
behavior of the system and the symptoms being observed. From there the troubleshooter
forms hypotheses on potential causes, and devises (or perhaps references a standardized
checklist of) tests to eliminate these prospective causes. This approach is often called
"Divide and Conquer".
Two common strategies used by troubleshooters are to check for frequently encountered
or easily tested conditions first (for example, checking to ensure that a printer's light is on
and that its cable is firmly seated at both ends). This is often referred to as "milking the
front panel."[2]
Then, "bisect" the system (for example in a network printing system, checking to see if
the job reached the server to determine whether a problem exists in the subsystems
"towards" the user's end or "towards" the device).
This latter technique can be particularly efficient in systems with long chains of serialized
dependencies or interactions among its components. It's simply the application of a
binary search across the range of dependencies and is often referred to as "half-splitting".
[3]

Reproducing symptoms [edit]

One of the core principles of troubleshooting is that reproducible problems can be
reliably isolated and resolved. Often considerable effort and emphasis in troubleshooting
is placed on reproducibility ... on finding a procedure to reliably induce the symptom to
occur.
Once this is done then systematic strategies can be employed to isolate the cause or
causes of a problem; and the resolution generally involves repairing or replacing those
components which are at fault.

Intermittent symptoms [edit]

Some of the most difficult troubleshooting issues relate to symptoms which occur
intermittently. In electronics this often is the result of components that are thermally
sensitive (since resistance of a circuit varies with the temperature of the conductors in it).
Compressed air can be used to cool specific spots on a circuit board and a heat gun can be
used to raise the temperatures; thus troubleshooting of electronics systems frequently
entails applying these tools in order to reproduce a problem.
In computer programming race conditions often lead to intermittent symptoms which are
extremely difficult to reproduce; various techniques can be used to force the particular
function or module to be called more rapidly than it would be in normal operation
(analogous to "heating up" a component in a hardware circuit) while other techniques can
be used to introduce greater delays in, or force synchronization among, other modules or
interacting processes.

Intermittent issues can be thus defined:

An intermittent is a problem for which there is no known procedure to
consistently reproduce its symptom.
Steven Litt, [1]
In particular he asserts that there is a distinction between frequency of occurrence and a
"known procedure to consistently reproduce" an issue. For example knowing that an
intermittent problem occurs "within" an hour of a particular stimulus or event ... but that
sometimes it happens in five minutes and other times it takes almost an hour ... does not
constitute a "known procedure" even if the stimulus does increase the frequency of
observable exhibitions of the symptom.
Nevertheless, sometimes troubleshooters must resort to statistical methods ... and can
only find procedures to increase the symptom's occurrence to a point at which serial
substitution or some other technique is feasible. In such cases, even when the symptom
seems to disappear for significantly longer periods, there is a low confidence that the root
cause has been found and that the problem is truly solved.
Also, tests may be run to stress certain components to determine if those components
have failed. [4]

Multiple problems [edit]

Isolating single component failures which cause reproducible symptoms is relatively
straightforward.
However, many problems only occur as a result of multiple failures or errors. This is
particularly true of fault tolerant systems, or those with built-in redundancy. Features
which add redundancy, fault detection and failover to a system may also be subject to
failure, and enough different component failures in any system will "take it down."
Even in simple systems the troubleshooter must always consider the possibility that there
is more than one fault. (Replacing each component, using serial substitution, and then
swapping each new component back out for the old one when the symptom is found to
persist, can fail to resolve such cases. More importantly the replacement of any
component with a defective one can actually increase the number of problems rather than
eliminating them).
Note that, while we talk about "replacing components" the resolution of many problems
involves adjustments or tuning rather than "replacement." For example, intermittent
breaks in conductors --- or "dirty or loose contacts" might simply need to be cleaned
and/or tightened. All discussion of "replacement" should be taken to mean "replacement
or adjustment or other maintenance."

See also [edit]

Bathtub curve
Cause and effect
Forensic engineering
Problem solving
Root cause analysis
5 Whys
Debugging
No Trouble Found
RPR Problem Diagnosis

References [edit]
1. ^ "Troubleshooting at your fingertips" by Nils Conrad Persson. "Electronics
Servicing and Technology" magazine 1982 June.
2. ^ "Hewlett Packard Bench Briefs". Hewlett Packard. Retrieved 14 October 2011.
3. ^ Sullivan, Mike (Nov 15, 2000). "Secrets of a super geek: Use half splitting to
solve difficult problems". TechRepublic. Retrieved 22 October 2010.
4. ^ http://www.ocf.berkeley.edu/~joyoung/trouble/page1.shtml

Pemecahan Masalah
Dari Wikipedia, ensiklopedia bebas
Langsung ke: navigasi, cari
Artikel ini membutuhkan tambahan kutipan untuk verifikasi. Harap membantu memperbaiki artikel ini
dengan menambahkan kutipan ke sumber terpercaya. Disertai rujukan bahan mungkin sulit dan
dihapus. (Juni 2010)
Masalah adalah suatu bentuk pemecahan masalah, sering digunakan untuk memperbaiki produk gagal
atau proses. Ini adalah logis, pencarian sistematis untuk sumber masalah sehingga dapat diselesaikan,
sehingga produk atau proses dapat dibuat operasional lagi. Pemecahan masalah yang dibutuhkan
untuk mengembangkan dan memelihara sistem yang kompleks dimana gejala masalah dapat memiliki
banyak kemungkinan penyebab. Troubleshooting digunakan di berbagai bidang seperti teknik,
administrasi sistem, elektronik, perbaikan otomotif, dan kedokteran diagnostik. Mengatasi masalah
memerlukan identifikasi kerusakan (s) atau gejala dalam sistem. Kemudian, pengalaman umumnya
digunakan untuk menghasilkan kemungkinan penyebab gejala. Menentukan yang menyebabkan
kemungkinan besar sering merupakan proses eliminasi - menghilangkan potensi penyebab masalah.
Akhirnya, tips memerlukan konfirmasi bahwa solusi mengembalikan produk atau proses ke keadaan
kerja.
Secara umum, pemecahan masalah adalah identifikasi, atau diagnosis "masalah" dalam aliran
manajemen dari sebuah perusahaan atau suatu sistem yang disebabkan oleh kegagalan dari beberapa
jenis. Masalahnya adalah awalnya digambarkan sebagai gejala kerusakan, dan pemecahan masalah
adalah proses untuk menentukan dan menanggulangi penyebab gejala ini.
Sebuah sistem dapat digambarkan dalam hal yang diharapkan, diinginkan atau dimaksudkan perilaku
(biasanya, untuk sistem buatan, tujuannya). Kejadian atau input ke sistem diharapkan untuk
menghasilkan hasil atau output tertentu. (Misalnya memilih "cetak" pilihan dari berbagai aplikasi
komputer yang dimaksudkan untuk menghasilkan hardcopy muncul dari beberapa perangkat tertentu).
Setiap perilaku tak terduga atau tidak diinginkan adalah gejala. Troubleshooting adalah proses
mengisolasi penyebab atau penyebab gejala spesifik. Sering gejala adalah kegagalan produk atau
proses untuk menghasilkan hasil apapun. (Tidak ada yang dicetak, misalnya).
Metode rekayasa forensik sangat berguna dalam menelusuri masalah dalam produk atau proses, dan
berbagai teknik analisis yang tersedia untuk menentukan penyebab atau penyebab kegagalan tertentu.
Tindakan korektif kemudian dapat diambil untuk mencegah kegagalan lebih lanjut dari jenis yang
sama. Tindakan pencegahan adalah mungkin menggunakan modus kegagalan dan analisis efek
(FMEA) dan analisis pohon kesalahan (FTA) sebelum produksi skala penuh, dan metode ini juga
dapat digunakan untuk analisis kegagalan.
Isi
1 Aspek
2 setengah membelah
3 Gejala reproduksi
4 Gejala intermiten
5 Beberapa masalah
6 Lihat juga
7 Referensi
Aspek
Kebanyakan diskusi pemecahan masalah, dan terutama pelatihan dalam prosedur pemecahan masalah
formal, cenderung menjadi domain yang spesifik, meskipun prinsip-prinsip dasar universal yang
berlaku.

Biasanya tips diterapkan ke sesuatu yang tiba-tiba berhenti bekerja, karena negara yang sebelumnya
bekerja membentuk harapan tentang perilaku yang terus menerus. Jadi fokus awal sering pada
perubahan terbaru pada sistem atau lingkungan di mana itu ada. (Sebagai contoh printer yang "sedang
bekerja ketika terpasang di sana"). Namun, ada prinsip diketahui bahwa korelasi tidak berarti
kausalitas. (Sebagai contoh kegagalan perangkat lama setelah itu sudah terpasang ke stopkontak yang
berbeda tidak selalu berarti bahwa kejadian tersebut terkait. Kegagalan bisa saja masalah kebetulan.)
Oleh karena itu tips menuntut pemikiran kritis daripada pemikiran magis.
Ini berguna untuk mempertimbangkan pengalaman umum yang kita miliki dengan bola lampu. Light
bulbs "membakar" lebih atau kurang secara acak, akhirnya pemanasan dan pendinginan berulang
filamen, serta fluktuasi daya yang disediakan untuk itu menyebabkan filamen untuk memecahkan atau
menguap. Prinsip yang sama berlaku untuk sebagian besar perangkat elektronik lainnya dan prinsipprinsip yang sama berlaku untuk perangkat mekanis. Beberapa kegagalan adalah bagian dari yang
normal wear-dan-robek komponen dalam sistem.
Sebuah prinsip dasar dalam mengatasi masalah adalah mulai dari masalah paling sederhana dan
mungkin kemungkinan pertama. Hal ini digambarkan dengan pepatah lama yang mengatakan "Ketika
Anda melihat kuku cetak, mencari kuda, bukan zebra", atau menggunakan pepatah lain, gunakan
prinsip KISS. Hasil Prinsip ini dalam keluhan umum tentang meja bantuan atau manual, yang kadangkadang mereka pertama bertanya: "? Apakah terpasang dan tidak wadah yang memiliki kekuasaan",
tapi ini tidak harus diambil sebagai penghinaan, melainkan harus berfungsi sebagai pengingat atau
pengkondisian untuk selalu memeriksa hal-hal sederhana terlebih dahulu sebelum meminta bantuan.
Sebuah troubleshooter bisa memeriksa setiap komponen dalam sistem satu per satu, menggantikan
komponen baik yang dikenal untuk masing-masing berpotensi tersangka. Namun, proses ini dari "seri
pengganti" dapat dianggap merosot ketika komponen yang diganti tanpa salam untuk hipotesis
mengenai bagaimana kegagalan mereka bisa mengakibatkan gejala yang didiagnosis.
Sederhana dan sistem menengah yang ditandai dengan daftar atau pohon dependensi antara komponen
atau subsistem mereka. Sistem yang lebih kompleks mengandung dependensi atau siklus interaksi
(umpan balik). Sistem seperti ini kurang setuju untuk "pembelahan" teknik pemecahan masalah.
Hal ini juga membantu untuk memulai dari keadaan yang baik, contoh terbaik menjadi reboot
komputer. Sebuah panduan kognitif juga merupakan hal yang baik untuk mencoba. Komprehensif
dokumentasi yang dihasilkan oleh penulis teknis mahir sangat membantu, terutama jika ia
menyediakan teori operasi untuk perangkat subjek atau sistem.
Penyebab umum masalah adalah desain yang buruk, misalnya buruk desain faktor manusia, di mana
perangkat bisa dimasukkan mundur atau terbalik karena kurangnya fungsi memaksa yang sesuai
(perilaku membentuk kendala), atau kurangnya desain kesalahan-toleran . Hal ini sangat buruk jika
disertai dengan pembiasaan, dimana pengguna hanya tidak memperhatikan penggunaan yang salah,
misalnya jika dua bagian yang memiliki fungsi yang berbeda, namun berbagi kasus umum sehingga
tidak jelas pada pemeriksaan kasual yang sebagian sedang digunakan .
Masalah juga dapat mengambil bentuk checklist sistematis, kiat prosedur, diagram alur atau meja yang
dibuat sebelum masalah terjadi. Mengembangkan prosedur pemecahan masalah di muka
memungkinkan berpikir cukup tentang langkah yang harus diambil dalam mengatasi masalah dan
mengorganisir pemecahan masalah tersebut ke dalam proses pemecahan masalah yang paling efisien.
Mengatasi Masalah tabel dapat terkomputerisasi untuk membuat mereka lebih efisien bagi pengguna.
Beberapa layanan tips terkomputerisasi (seperti Primefax, kemudian berganti nama Maxserve), segera
menunjukkan 10 solusi atas dengan probabilitas tertinggi memperbaiki masalah mendasar. Teknisi bisa

menjawab pertanyaan-pertanyaan tambahan untuk maju melalui prosedur pemecahan masalah, setiap
langkah mempersempit daftar solusi, atau segera menerapkan solusi ia merasa akan memperbaiki
masalah. Layanan ini memberikan potongan harga jika teknisi mengambil langkah tambahan setelah
masalah diselesaikan: melaporkan kembali solusi yang sebenarnya tetap masalah. Komputer
menggunakan laporan ini untuk memperbarui estimasi mengenai solusi yang memiliki probabilitas
tertinggi untuk memperbaiki yang mengatur gejala tertentu. [1]
Half-membelah
Tips Efisien metodis dimulai dengan pemahaman yang jelas tentang perilaku yang diharapkan dari
sistem dan gejala yang diamati. Dari sana bentuk pemecah masalah hipotesis tentang penyebab
potensial, dan rencana (atau mungkin referensi checklist standar dari) tes untuk menghilangkan
penyebab prospektif. Pendekatan ini sering disebut "Adu Domba".
Dua strategi yang umum digunakan oleh troubleshooters adalah untuk memeriksa sering ditemui atau
mudah diuji kondisi pertama (misalnya, memeriksa untuk memastikan bahwa lampu printer menyala
dan bahwa kabel adalah tegas duduk di kedua ujungnya). Hal ini sering disebut sebagai "memerah
susu panel depan." [2]
Kemudian, "membagi dua" sistem (misalnya dalam sistem pencetakan jaringan, memeriksa untuk
melihat apakah pekerjaan mencapai server untuk menentukan apakah masalah ada dalam subsistem
"menuju" akhir pengguna atau "menuju" perangkat).
Teknik terakhir akan sangat efisien dalam sistem dengan rantai panjang dependensi serial atau
interaksi antara komponen-komponennya. Ini hanya penerapan pencarian biner di berbagai
ketergantungan dan sering disebut sebagai "setengah membelah". [3]
Gejala reproduksi
Salah satu prinsip inti dari pemecahan masalah adalah bahwa masalah reproducible dapat diandalkan
terisolasi dan diselesaikan. Upaya sering cukup besar dan penekanan dalam mengatasi masalah
ditempatkan pada reproduksibilitas ... untuk menemukan sebuah prosedur untuk andal menginduksi
gejala terjadi.
Setelah ini dilakukan maka strategi sistematis dapat digunakan untuk mengisolasi penyebab atau
penyebab masalah, dan resolusi biasanya meliputi perbaikan atau penggantian komponen yang
bersalah.
Gejala intermiten
Beberapa masalah yang paling sulit berhubungan dengan gejala yang terjadi sebentar-sebentar. Dalam
elektronik ini sering merupakan hasil dari komponen yang sensitif termal (sejak resistansi sirkuit
bervariasi dengan suhu konduktor di dalamnya). Udara terkompresi dapat digunakan untuk titik
tertentu dingin pada papan sirkuit dan senapan panas dapat digunakan untuk menaikkan suhu,
sehingga tips sistem elektronik sering memerlukan menerapkan alat-alat dalam rangka untuk
mereproduksi masalah.
Dalam kondisi lomba pemrograman komputer sering menyebabkan gejala intermiten yang sangat sulit
untuk mereproduksi, berbagai teknik dapat digunakan untuk memaksa fungsi tertentu atau modul
untuk dipanggil lebih cepat dari itu akan di operasi normal (analog dengan "memanas" komponen
dalam rangkaian hardware) sementara teknik lain dapat digunakan untuk memperkenalkan penundaan
besar dalam, atau sinkronisasi kekuatan antara, modul lain atau proses berinteraksi.
Masalah berselang dapat didefinisikan demikian:
Sebuah intermiten merupakan masalah yang tidak ada prosedur yang dikenal secara konsisten

mereproduksi gejala nya.

-Steven Litt, [1]
Secara khusus ia menegaskan bahwa ada perbedaan antara frekuensi kejadian dan "prosedur yang
dikenal secara konsisten mereproduksi" masalah. Misalnya mengetahui bahwa masalah intermiten
terjadi "dalam" satu jam stimulus tertentu atau acara ... tapi itu kadang-kadang terjadi dalam lima
menit dan waktu lain memakan waktu hampir satu jam ... bukan merupakan "prosedur yang dikenal"
bahkan jika rangsangan tidak meningkatkan frekuensi pameran diamati dari gejala.
Namun demikian, kadang-kadang troubleshooters harus menggunakan metode statistik ... dan hanya
dapat menemukan prosedur untuk meningkatkan kejadian gejala untuk titik di mana substitusi serial
atau beberapa teknik lain yang layak. Dalam kasus tersebut, bahkan ketika gejala tampaknya
menghilang untuk waktu yang signifikan lebih lama, ada kepercayaan rendah bahwa akar telah
ditemukan dan bahwa masalah ini benar-benar diselesaikan.
Juga, tes mungkin dijalankan untuk menekankan komponen-komponen tertentu untuk menentukan
apakah komponen telah gagal. [4]
Beberapa masalah
Mengisolasi kegagalan satu komponen yang menyebabkan gejala direproduksi relatif mudah.
Namun, banyak masalah hanya terjadi sebagai akibat dari beberapa kegagalan atau kesalahan. Hal ini
terutama berlaku sistem fault tolerant, atau mereka dengan built-in redundansi. Fitur yang menambah
redundansi, deteksi kesalahan dan failover untuk sistem juga dapat dikenakan kegagalan, dan
kegagalan komponen yang cukup berbeda dalam sistem apapun akan "bawa turun."
Bahkan dalam sistem sederhana pemecah masalah harus selalu mempertimbangkan kemungkinan
bahwa ada lebih dari satu kesalahan. (Mengganti masing-masing komponen, dengan menggunakan
substitusi serial, dan kemudian bertukar setiap komponen baru kembali keluar untuk yang lama saat
gejala ditemukan untuk bertahan, bisa gagal untuk menyelesaikan kasus tersebut. Lebih penting
penggantian komponen dengan satu cacat sebenarnya dapat meningkatkan jumlah masalah daripada
menghilangkan mereka).
Perhatikan bahwa, sementara kita berbicara tentang "komponen menggantikan" resolusi banyak
masalah melibatkan penyesuaian atau menyetel daripada "pengganti." Sebagai contoh, istirahat
sebentar-sebentar dalam konduktor --- atau "kontak yang kotor atau longgar" mungkin hanya perlu
dibersihkan dan / atau diperketat. Semua diskusi tentang "pengganti" harus diambil untuk berarti
"pengganti atau penyesuaian atau perawatan lainnya."

1.2.Rumusan Masalah
Berdasarkan latar belakang di atas maka dapat diambil rumusan
masalah,sebagai berikut:

Bagaimana mengenali jenis kerusakan yang terjadi pada harddisk

denganmemperhatikan keadaan yang terjadi?
1.3.Batasan Masalah
Agar permasalahan yang akan dibahas lebih terfokus, maka perlu
dibatasia s p e k - a s p e k y a n g a k a n d i b a h a s . Tug a s Ak h i r y a n g
d i l a k u k a n m e l i p u t i pendeteksian masalah harddisk dengan
mengenali jenis kerusakan yangdialami, dengan memperhatikan
informasi pada tampilan POST (
Power OnSelfTest
).
3.Sebagai salah satu syarat untuk memperoleh gelar
A h l i M a d y a p a d a Program Study Teknik Elektronika Konsentrasi Teknik
Komputer.
1.5.Manfaat Penelitian
1)Bagi Mahasiswaa.Dapat menjadi bahan untuk
l e b i h m e n a m b a h w a w a s a n d a l a m menangani masalah yang
berhubungan dengan harddisk b.Dapat menerapkan ilmu yang di
peroleh di bangku perkuliahan dalamdunia luar.2 ) B a g i
A k a d e m i k a . U n t u k m e l i h a t d ay a s e r a p m a h a s i s w a t e r h a d a p
m a t a k u l i a h y a n g d i pelajari. b . S e b a g a i b a h a n e v a l u a s i b a g i
a k a d e m i k d a l a m m e n g e m b a n g k a n pendidikan yang
bermutuc . U n t u k m e n g e t a h u i s e j a u h m a n a k e m a m p u a n
m a h a s i s w a d a l a m mendeteksi kerusakan komputer.3 ) B a g i
M a s y a r a k a t Dapat mengetahui jenis kerusakan dari
k o m p u t e r d a n p e n y e b a b kerusakannya dengan meneliti gejalagejala yang ada pada komputer yang bermasalah, serta untuk
mendapatkan solusinya.

Dalam dunia mesin, segala sesuatu masalah/gangguan yang terjadi serta

berhubungan dengan satu dan lainnya disebut dengan troubleshooting.

Permasalahan tersebut kerap muncul pada sebuah mesin, tidak hanya
pada sistem dan siklusnya tetapi juga pada komponen-komponennya. Untuk mengetahui
jenis permasalahan ada dan penyebab masalah tersebut diperlukan analisis yang tajam
dan kemampuan serta
pengalaman. Komponen-komponen di dalam mesin sangat rentan terhadap suatu
benturan atau gesekan yang melebihi batas ketahanannya. sistem dan
Komponen mesin harus saling mendukung antara yang satu dengan yang
lainnya, sisitem yang bermasalah biasanya kebanyakan akan langsung
dilakukan pemeriksaan dan penyetelan sedangkan untuk komponen ada yang dapat
diperbaiki dan ada yang tidak. Untuk komponen yang tidak dapat diperbaiki
solusi utamanya adalah mengganti dengan yang baru jika melebihi standart speknya.
mesin generasi sekarang lebih mudah untuk mengetahui penyebab
masalah dibanding dengan mesin generasi dahulu karena perangkatnya
lebih mudah untuk diteliti dalam mendeteksi masalah.
karena penggunaan yang tidak sesuai atau melebihi batas dari kemampuan
kerja yang dimiliki oleh part atau komponennya tersebut. Jika hal ini terjadi
maka kinerja dari mesin akan menjadi terganggu sehingga akan
berpengaruh pada Sistem Operasinya dan juga pada output atau hasilnya.
Komponen pada mesin yang bermasalah, biasanya dapat dikenali pada saat
penyalaan awal. Pada penyalaan awal, mesin akan menimbulkan berbagai macam suarasuara.
yang sangat berbeda yang dapat digunakan untuk mengenali keadaan
atau kondisi mesin, Untuk memahami dan mengetahui kerusakan yang terjadi serta solusi
pemecahannya dalam masalah atau troubleshooting tersebut, sebaiknya terlebih dahulu
dilakukan pendeteksian penyebab kerusakannya. Hal tersebut sangat diperlukan untuk
mempermudah dalam menangani kerusakan yang terjadi pada sebuah
mesin terutama pada komponennya dan juga sisitemnya.
Berdasarkan permasalahan di atas, maka pada penulisan laporan trouble shooting ini
akan dibahas mengenai troubleshooting engine hunting, dengan memperhatikan
gejala-gejala yang ditimbulkan.