Identifying Systems Problems - စနစ်ဆိုင်ရာ ပြဿနာများကို ဖော်ထုတ်ခြင်း

Identifying Systems Problems - စနစ်ဆိုင်ရာ ပြဿနာများကို ဖော်ထုတ်ခြင််း

Hardware, Software, Networking, Web Server စသည့် မည်သည့် ပြဿနာကို ဖြေရှင်းရသည် ဖြစ်စေ ပြဿနာတစ်ခု ဖြစ်ပေါ်ကြောင်း စတင်သိရှိရသည့် နေရာမှာ - အများအားဖြင့် ၄င်း Hardware, Software, Network ကို အသုံးပြုနေသူများ - ထံမှ ဖြစ်သည်။ (တစ်ခါတရံတွင် သင်၏ Boss ထံမှလည်း လာတတ်သည်။) “ပရင်တာ ထုတ်လို့ မရဘူး” ၊ “အီးမေးလ် ပို့လို့ မရဘူး” ၊ “အင်တာနက် လိုင်းမရဘူး” ၊ “ကွန်ပျူတာ ဖွင့်မရတော့လို့” ၊ “ဒီ Web page က ဒီ Browser မှာတစ်မျိုး ဟို Browser မှာတစ်မျိုး” စသည့် ပြဿနာပေါင်းများစွာကို မရိုးနိုင်အောင် သယ်ဆောင်လာသူများမှာ ထိုပစ္စည်းများ (ထို Software သို့မဟုတ် ထို Web Application) ကို သုံးနေသူများထံမှ ဖြစ်လေသည်။

ထို့နောက် သေချာပေါက် ထပ်မံကြားရလေ့ရှိသည့် အဆုံးသတ် စကားလုံးမှာ “ကျွန်တော်/ကျွန်မကတော့ ဘာမှ မလုပ်ဘူး၊ ဘာမှ မပြောင်းဘူး၊ သူ့ဘာသာသူ ဖြစ်သွားတာ” စသည့် စကားမျိုးက အများဆုံး ဖြစ်ကြသည်။ “ကျွန်တော်/ကျွန်မက လျှောက်ကလိရင်း ဖြစ်သွားလို့” ဟူသည့် စကားမျိုးပြောလာသူက တစ်ရာတွင် ဆယ်ယောက်မျှပင် ရှိမည်မဟုတ်ပေ။

Are End Users Helpful?

စနစ်ဆိုင်ရာ ပြဿနာ (Systems Problem) တစ်ခုကို ဖြေရှင်းနေရသူ တစ်ဦးအနေဖြင့် အခြေအနေ အမျိုးမျိူးကို ရင်ဆိုင်ကြုံတွေ့ရမည် ဖြစ်သည်။ ပြဿနာ၏ အကြောင်းရင်းကို စီစစ် အဖြေရှာရာတွင် End User များထံမှ အကူအညီကို နောက်ဆုံးမှ ရယူသင့်သည်။ ဆိုပါစို့ - ပြဿနာမှာ Server သို့မဟုတ် Network နှင့် သက်ဆိုင်နေသည် ဆိုလျှင် ကျွန်တော်တို့ အနေဖြင့် ထို ဆာဗာနှင့် ကွန်ရက်ကို အသုံးပြုနေသူများထံမှ “ဆာဗာနှင့် အဆက်အသွယ်မရ” ဆိုသည့် တူညီသော အဖြေမှတပါး မည်သည့် အကူအညီကိုမျှ ရနိုင်မည် မဟုတ်ပေ။
(သို့သော် Web Application သို့မဟုတ် တည်ဆောက်နေဆဲ ၀က်ဘ်ဆိုက်တစ်ခုကို စမ်းသပ်ရတော့မည့် အချိန်အခါတွင်တော့ End User များ၏ အကူအညီမှာ အသုံး၀င်သည်။ အထူးသဖြင့် အသုံးပြုသူများ၏ အတွေ့အကြုံ (User Experience) ကို စမ်းသပ်ရာတွင် ပိုသိသာသည်။)

What is the Problem?

ပြဿနာကို စတင်အဖြေရှာရသည့် ပထမဆုံးအဆင့်တွင် ကျွန်တော်တို့ အနေဖြင့် “ပြဿနာက ဘာ ဖြစ်သည်” (What is the problem?) ဆိုသည်ကိုသာ ဖော်ထုတ်ရန် ကြိုးစားသင့်သည်။ ပြဿနာကို သိမှ နောက်ပိုင်း အဆင့်များတွင် “အဘယ်ကြောင့်” (Why?) ထိုပြဿနာ ဖြစ်ရသည်ကို ဆက်လက် အဖြေရှာနိုင်မည် ဖြစ်သည်။

  • Front End Developer တစ်ယောက်အနေဖြင့် ဤအခြေအနေမှာ - Web page အတွင်းရှိ စာလုံးပုံစံ (Font face) များ လိုအပ်သလို ထွက်မလာခြင်း၊ Layout များ ပျက်ယွင်းနေခြင်း၊ အင်တာနက်ကြည့် ဆော့ဖ်၀ဲ အမျိုးမျိုးဖြင့် စမ်းသပ်ရာတွင် (Cross browser testing) ပုံစံအမျိုးမျိုး ပြောင်းလဲ တွေ့မြင်နေရခြင်း (ဥပမာ - Firefox, Google Chrome, Apple Safari တို့တွင် တစ်မျိုး၊ IE 6, 7, 8 တို့တွင် တစ်ဘာသာစီ) စသည်တို့ ဖြစ်နိုင်သည်။
  • Backend Developer တစ်ယောက်အတွက် Visitor များထံမှ Web Site ပိုင်ရှင်များဆီသို့ Contact Form မှတဆင့် အီးမေးလ် ပို့သည့်စနစ်ကို ရေးသားနေရင်း အီးမေးလ်များ လိုရာလိပ်စာသို့ ပို့မရ ဖြစ်နေခြင်းမျိုး ဖြစ်နိုင်သည်။
  • .Net Developer တစ်ယောက်အနေဖြင့် SQL Server နှင့် ချိတ်ထားပြီး ဖြစ်သော်လည်း Database မှ အချက်အလက်များကို ခေါ်ကြည့်၍မရသည့် အဖြစ်မျိုး ကြုံနေနိုင်သည်။
  • Webmaster တစ်ယောက်အနေဖြင့် Server ကို Cache လုပ်မထားသည့်အတွက် မလိုအပ်ပဲ Server တွင် Loading ပိုများနေခြင်း၊ Busy ဖြစ်နေခြင်း ဖြစ်နေနိုင်သည်။
  • System/Network Engineer တစ်ယောက်အနေဖြင့် အီးမေးလ်ဆာဗာများ အလုပ်လုပ်တော့သည့် အခြေအနေမျိုး ကြုံကောင်း ကြုံနေရ နိုင်သည်။

Document the Problem - ပြဿနာကို မှတ်တမ်းပြုစုပါ

What is the Problemsမည်သို့ပင် ဖြစ်စေ ကြုံနေရသည့် ပြဿနာကို သိရသည်နှင့် အသေအချာ ရေးသား မှတ်တမ်းပြုစုခြင်းမှာ (Documenting the problem) အကောင်းဆုံး ဖြစ်သည်။ ဥပမာ - မောင်မြ၏ ကွန်ပျူတာမှာ ကုမ္ပဏီ၏ အင်တာနက်ဆာဗာဆီသို့ အဆက်အသွယ်မရ ဖြစ်နေသည် - စသည်ဖြင့် ရေးမှတ်နိုင်သည်။ ဤသို့ မှတ်သားလိုက်ခြင်းအားဖြင့် -

  • နောင်တစ်ချိန် အလုပ်ပိုများလာသည့်အခါ၊ သို့မဟုတ် ကျွန်တော်တို့ ရှင်းနေဆဲ ပြဿနာကို အကြောင်း အမျိုးမျိုးကြောင့် နောက်ထပ် လုပ်ဖော်ကိုင်ဖက် တစ်ဦးသို့ ချက်ချင်း လွှဲပေးရတော့မည် ဆိုလျှင် အလွယ်တကူ ပြန်ကြည့်နိုင် ပြန်လွှဲနိုင်သည်။
  • ထို့ပြင် ရှေ့ဆက် အဖြေရှာရာတွင်လည်း စနစ်တကျ မှတ်သားထားသည့် Documentation များက အထောက်အကူပြုသည်။
  • နောက်ထပ် အလားတူ ပြဿနာများကို မိမိဖြစ်စေ၊ အခြားသူတစ်ဦးမှ ဖြစ်စေ၊ တစ်ချိန်ချိန်တွင် ကြုံတွေ့လာ သည့်အခါတွင်လည်း အဆင်သင့် ဖြစ်နိုင်သည်။
  • Blog သို့မဟုတ် Forum များတွင် မိမိ၏ အတွေ့အကြုံနှင့် ပြဿနာ ဖြေရှင်းနည်းများကို ပြန်လည် ေ၀မျှနိုင်သည်။
  • မိမိ၏ ဖြေရှင်းလိုက်သည့် ပြဿနာကို F.A.Q သို့မဟုတ် Knowledgebase အဖြစ်လည်း ပြုစုထားနိုင်သေးသည်။
  • ကုမ္ပဏီတစ်ခုအတွက် ပြဿနာ လာရှင်းပေးရသည့် System Engineer, Network Engineer တစ်ဦး ဖြစ်နေပါက မိမိ၏ မိခင် ကုမ္ပဏီတွင် Report ပြန်တင်ရန်နှင့် ပြဿနာ ဖြစ်ပေါ်နေသည့် နေရာတွင် Report လုပ် (ပိုက်ဆံတောင်းရန်) အတွက် ရေးမှတ်ထားသည့် ပြဿနာမှာ များစွာ အသုံး၀င်သည်။

After Knowing the Problem

ပြဿနာကို ဖော်ထုတ်ကာ ရေးမှတ်ပြီးသည်နှင့် နောက်တစ်ဆင့်မှာ ထိုပြဿနာနှင့် ဆက်စပ်နေသည့် အစိတ်အပိုင်းများကို လေ့လာခြင်း ဖြစ်သည်။ ဥပမာ - ကွန်ပျူတာများမှ ဆာဗာသို့ အဆက်အသွယ်မရဖြစ်နေလျှင် ဆာဗာကွန်ပျူတာကို စစ်ဆေးခြင်း၊ Network Service များကို စစ်ဆေးခြင်း၊ ကြားခံ Switch များ၊ Router များကို စစ်ဆေးခြင်း၊ Cable များကို စစ်ဆေးခြင်း၊ ယုတ်စွအဆုံး Power ခလုတ်များ ဖွင့်ထားမထားကို စစ်ဆေးခြင်း စသည်အားဖြင့် ဖော်ထုတ်ထားသည့် ပြဿနာနှင့် ဆက်စပ်နေသည့် ဖြစ်တန်ရာသော အကြောင်းရင်းများကို ဆက်လက် ရှာဖွေကြရသည်။ အခြားသော Front End Developer, Backend Developer, Webmaster များလည်း ထိုနည်းတူပင် ဖြစ်သည်။ တခါတရံတွင် ကော်မာ (Comma) လေးတစ်ခု မေ့ကျန်ခဲ့သည့် အတွက် Website, Web application, Computer Software တစ်ခုလုံး အလုပ်မလုပ်တော့ခြင်းမျိုးလည်း ကြုံရနိုင်သည်။

Be Patient, Be Patient - စိတ်ရှည် သီးခံပါ

ဤနေရာတွင် ကျွန်တော်တို့ သတိထားရမည့် အချက်တစ်ခုမှာ -

  • ကွန်ပျူတာက ပြန်ပေးလာသည့် အမှားအယွင်း သတိပေးဖော်ပြချက် (Error Message) များကို သေချာစွာမဖတ်ဘဲ OK, Yes စသည့် ခလုတ်များကို အလွယ်တကူ နှိပ်လိုက်ခြင်းမျိုး ဖြစ်သည်။
  • အကယ်၍ ကွန်ပျူတာ သို့မဟုတ် System တစ်ခုမှ Error Message များဖော်ပြနေပါက သေချာစွာ အချိန်ယူ ဖတ်ရှုသင့်သည်။
  • အထူးသဖြင့် အရေးကြီး၊ အမြန်လိုနေသည့် အခြေအနေတွင် ပိုသတိထားသင့်သည်။ ပို၍ စိတ်ရှည်သင့်သည်။
  • ပို၍ ခေါင်းအေးအေးထားကာ စဉ်းစား အဖြေရှာသင့်သည်။
  • ထိုအချိန်တွင် အမြန်လိုနေသည့် Boss၊ မိမိတို့၏ လုပ်ငန်းသဘာ၀ကို နားမလည်သည့် အခြားသော လုပ်ဖော်ကိုင်ဖက်များ၊ စိတ်မရှည်နိုင်ဖြစ်နေသည့် Customer များ စသည်ဖြင့် ဘေးမှ အနှောက်အယှက်များလည်း ရှိနေတတ်သေးသည်။

မည်သည့် အခြေအနေသို့ ရောက်နေသည် ဖြစ်စေ စနစ်တစ်ခုခုနှင့် သက်ဆိုင်သည့် ပြဿနာတစ်ခုကို ဖြေရှင်းရတော့မည် ဆိုပါက “အလျင်လိုလျင် လမ်းအိုလိုက်” ကာ ပြဿနာကို စိတ်ရှည်လက်ရှည် ဂရုတစိုက် အဖြေရှာနိုင်မှ “အမြန်လို အနှေးတွေ့” ရသည့် အဖြစ်မျိုးမှ ရှောင်နိုင်မည် ဖြစ်သည်။

Add new comment

Featured Articles