Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation on 03/06/2020 in all areas

  1. 1 point
    Terjumpa di archive.org [tulisan saya masa di Ittutor.net & Rangkaian.net] System Engineer : Tips and Trick Written by rizal Monday, 20 June 2005 Jom kita share sama2 pengalaman dan tips untuk memperbaiki dan belajar bagaimana nak jadi seorang sistem engineer yang lebih baik. Saya dah jadi NMS Engineer,Network Analyst,Network Specialist dan apa2lah depa nak panggil tapi secara basicnya saya rasa tetap digelar System Engineer. Kerja system engineer selalunya tak fokus ke sesuatu cabang IT. Selalunya kena tau bit here and there. Kena tau OS UNIX,Windows sebagainya dan kena tau juga part networking , kadang2 kena tau bab eletrikal jugak. Kadang2 kena tau basic programming dan scripting. Sebab selalunya macam kerja saya deliver total solution kita kena siapkan A to Z.Saya dulu agak beruntung jugak sebab kerja pertama saya memang betul2 multivendor+multisystem punya environment. Deliver network management solution untuk telco company so dari pasang kabel,multiplexer,Xterminal, UNIX server, router, install software, OS,patch isk semua buat sendiri lah. Tapi yang best masa tu sebab saya dapat boss yang very understanding dan yakin pada anak buah walaupun majoriti team saya adalah fresh graduate kita orang berjaya deploy sebuah solution yang agak besar. His famous word kalau saya tatau buat.. "Arghh belasah jek dulu". Dia suruh cuba dulu. Dari situ banyak yang saya belajar dari kesalahan dan kelemahan saya dan cuba memperbaiki kekurangan. Selama 8 tahun kerja ni jugak saya dah berkerja dengan berbagai jenis engineer dari luar negara, CCIEs, mat salleh ada, india mari ada local pun sure ada. So dari pemerhatian, saya cuba dapatkan skill yang mereka ada .. cara mereka berkerja... cara troubleshoot.. etc. In short, saya ringkaskan mereka semua taklah hebat mana. But one thing yang membezakan ke"terer" an mereka adalah satu benda. SISTEMATIK. That's the keyword. Mostly yang saya lihat apa yang paling penting dalam kerjaya ini adalah sistematik. Kena buat kerja ikut step yang betul. Kena ada dokumentasi yang baik. Kena pantas berpikir mencari jalan keluar kalau ada problem. Tak semestinya kita kena tahu semua benda. Almost impossible nak pakar dalam semua bidang.. Dalam part ni kita kena perlu ada dokumentasi yang baik dan ada skill untuk mendapatkan maklumat dengan cepat bila diperlukan. Kebanyakan rakan2 saya yang "expert" ni mereka memang mantain a huge collection of docs dalam laptop disusun dengan sistem direktori yang kemas dan mudah dicari. Kebanyakannya PDF yang di download dari internet. Kedua kena cekap guna search engine. Cari solution dengan pantas guna the right keyword. Macam kerja saya di IBM dan Nokia memang ada intranet punya DB untuk koleksi problem dan FAQ. Cara lain cari guna google.. cari kat mailing list etc.. Saya selalu dokumenkan masalah yang telah disolvekan .. walaupun kadang2 kita yakin boleh ingat.. bila tiba masanya especially dalam keadaan kritikal memang cepat lupa..So pastikan anda sendiri ada sistem dokumentasi masalah sendiri maybe boleh buat pakai EXCEL or spreadsheet. Ketiga saya rasa kena guna konsep yang betul dalam troubleshooting. Macam Cisco depa ada outline konsep asas troubleshooting model yang saya rasa agak generik boleh digunakan apabila kita troubleshoot problem. Secara ringkasnya model ini menjelaskan step by step cara untuk troubleshoot sesuatu masalah. Yang penting jangan PANIK dan don't jump to conclusion.. Rujuk http://www.cisco.com/univercd/cc/td/doc/ci...g_v1/tr1901.htm QUOTE General Problem-Solving Model The following steps detail the problem-solving process outlined in Figure 1-1: Step 1 When analyzing a network problem, make a clear problem statement. You should define the problem in terms of a set of symptoms and potential causes. To properly analyze the problem, identify the general symptoms and then ascertain what kinds of problems (causes) could result in these symptoms. For example, hosts might not be responding to service requests from clients (a symptom). Possible causes might include a misconfigured host, bad interface cards, or missing router configuration commands. Step 2 Gather the facts that you need to help isolate possible causes. Ask questions of affected users, network administrators, managers, and other key people. Collect information from sources such as network management systems, protocol analyzer traces, output from router diagnostic commands, or software release notes. Step 3 Consider possible problems based on the facts that you gathered. Using the facts, you can eliminate some of the potential problems from your list. Depending on the data, for example, you might be able to eliminate hardware as a problem so that you can focus on software problems. At every opportunity, try to narrow the number of potential problems so that you can create an efficient plan of action. Step 4 Create an action plan based on the remaining potential problems. Begin with the most likely problem, and devise a plan in which only one variable is manipulated. Changing only one variable at a time enables you to reproduce a given solution to a specific problem. If you alter more than one variable simultaneously, you might solve the problem, but identifying the specific change that eliminated the symptom becomes far more difficult and will not help you solve the same problem if it occurs in the future. Step 5 Implement the action plan, performing each step carefully while testing to see whether the symptom disappears. Step 6 Whenever you change a variable, be sure to gather results. Generally, you should use the same method of gathering facts that you used in Step 2 (that is, working with the key people affected, in conjunction with utilizing your diagnostic tools). Step 7 Analyze the results to determine whether the problem has been resolved. If it has, then the process is complete. Step 8 If the problem has not been resolved, you must create an action plan based on the next most likely problem in your list. Return to Step 4, change one variable at a time, and repeat the process until the problem is solved. Buku Laura Chappell Troubleshooting Campus Network adalah satu rujukan baik untuk orang network. Sambungan kisah lama actually reminder untuk diri saya ORGANIZED Penting jadi system engineer ni untuk jadi well-organized supaya masalah dapat diselesaikan dengan cepat. Macam kerja saya selama jadi Tech Support Engineer atau Care Services Engineer ni kalau berlaku masalah perlu diselesaikan dengan pantas. So kita kenalah pantas mencari solution- kena faham komponen software dan hardware yang kita jaga. Macam saya ni the components in short consists of :- Hardware : Cisco , HP Unix server dan Nokia proprietary network element Software : Cisco-IOS, Oracle , Nokia proprietary software dan Oracle. (ouch! I need to be certified in all these!) Jadi kenalah tahu where to find info untuk semua tu. Mungkin dari dokumentasi laman web vendor itu sendiri, dari forum , dari newsgroup dan saya kerja dalam organisasi saya sendiri pun ada forum internal dan juga problem database. Masa saya keja IBM dulu .. fuhh intranet dia lagi besar problem database yang dia orang ada. Banyak valuable info yang kita tak dapat dari internet ada di sini. Kena cekap guna search engine , saya kumpul gigabytes of pdf documents untuk rujukan (tak baca semua pun) . Kena juga kenal engineers dari vendor tersebut.. so kena buat baik la sket kan dengan orang


×
×
  • Create New...