လေ့ကျင့်ခန်း - Deployment ပြဿနာရှာဖွေခြင်း

နားလည်ထားရမယ့် အချက်

Deploy လုပ်ထားတဲ့ website ပျက်သွားတဲ့အခါ server ကို restart လုပ်တာ၊ ပြန် deploy လုပ်တာ၊ DNS ချိန်ညှိတာ၊ code စစ်တာ - ဒါတွေကို အစီအစဉ်မရှိဘဲ ကျပန်းလုပ်ချင်စိတ် ပေါ်လာတတ်ပါတယ်။ ဒါက အချိန်ကုန်ပြီး ပြဿနာအသစ်တွေ ထပ်ဖြစ်စေနိုင်ပါတယ်။

ပိုကောင်းတဲ့ နည်းလမ်းက decision tree ပါ - system ရဲ့ အပြင်ဘက်ကနေ အထဲကို တစ်ဆင့်ချင်း ချဉ်းကပ်ပြီး ပြဿနာ ဘယ်နေရာမှာ တကယ်ရှိနေလဲဆိုတာကို ကျဉ်းလိုက်ပေးမယ့် Yes/No စစ်ဆေးမှု အစီအစဉ်ပါ။

၁။ Domain resolve ဖြစ်လား?

DNS lookup မအောင်မြင်ရင် ဒီနေရာကျော်ပြီး ဘာမှမစစ်ရသေးပါ - ပြဿနာက DNS ဖြစ်ပါတယ်၊ application မဟုတ်ပါ။

၂။ HTTPS အလုပ်လုပ်လား?

DNS အောင်မြင်ပေမယ့် browser က connection ကို ငြင်းပယ်တာ (သို့) certificate warning ပြရင် ပြဿနာက TLS (သို့) certificate configuration ပါ။

၃။ Server က response တစ်ခုခု ပြန်ပေးလား?

DNS နဲ့ HTTPS နှစ်ခုလုံး ကောင်းပေမယ့် request တွေက response လုံးဝ မရဘူးဆိုရင် ပြဿနာက hosting platform (သို့) runtime ဖြစ်နိုင်ပါတယ် - port မှား၊ process crash၊ start command မှား။

၄။ Application-level error ရှိလား?

Server က response ပြန်ပေးပေမယ့် 500 status (သို့) မှန်ကန်တဲ့ behavior မဟုတ်ဘူးဆိုရင် bug က code၊ environment variable (သို့) database connection ထဲမှာ ရှိနေပါတယ်။

Order ဟာ ဘာကြောင့် အရေးကြီးလဲ

စစ်ဆေးမှု တစ်ခုချင်းစီက နောက် layer ကို မထိခင် အကြောင်းရင်း category တစ်ခုလုံးကို ဖယ်ထုတ်ပေးပါတယ်။ DNS/HTTPS ကောင်းမကောင်း အတည်မပြုရသေးဘဲ log ထဲ ရှေ့ကျော်ဝင်ရှာတာက layer တစ်ခုကွာနေတဲ့ symptom ကို လိုက်ရှာနေသလိုပါပဲ။

ဒါက deployment debugging skill တစ်ခုတည်း မဟုတ်ဘဲ debugging skill အထွေထွေပါပဲ - system ရဲ့ အပြင်ဘက် boundary ကို အရင်အတည်ပြုပြီးမှ အောက်ခြေ layer ကို သံသယဝင်ပါ။

text

DEPLOYMENT TROUBLESHOOTING DECISION TREE
----------------------------------------
DEPLOYMENT TROUBLESHOOTING DECISION TREE
-----------------------------------------
START: "My website isn't working"
  |
  v
STEP 1: Does the domain resolve (DNS lookup succeeds)?
  |-- NO  -> DNS ISSUE (check DNS records / nameservers)
  |-- YES
      |
      v
STEP 2: Does HTTPS load (no cert/TLS error)?
  |-- NO  -> TLS / CERTIFICATE ISSUE (cert expired, misconfigured)
  |-- YES
      |
      v
STEP 3: Does the server respond at all (any status code)?
  |-- NO  -> PLATFORM / RUNTIME ISSUE (wrong port, crashed
  |          process, wrong start command)
  |-- YES
      |
      v
STEP 4: Is there an application-level error (500, broken page)?
  |-- YES -> CHECK APP LOGS / ENV VARS / DATABASE CONNECTIVITY
  |-- NO  -> Site is healthy - stop here

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

တွဲဖက်လုပ်ဖော်ကိုင်ဖက်တစ်ဦးက backend အသစ်ကို deploy လုပ်ပြီး site က "500 Internal Server Error" page ကို ပြနေတယ်လို့ report လုပ်ပါတယ်။ Platform dashboard က deployment succeeded ဖြစ်ပြီး health check က green ဖြစ်နေတယ် - process run နေတာ သေချာပါတယ်။

Check 1: Domain resolve ဖြစ်လား?

Domain အတွက် DNS lookup က မှန်ကန်တဲ့ IP address ကို ပြန်ပေးပါတယ်။ DNS ကောင်းပါတယ် - နောက် check ဆီ ဆက်သွားပါ။

Check 2: HTTPS အလုပ်လုပ်လား?

Browser မှာ padlock မှန်ကန်စွာ ပြနေပြီး certificate warning မရှိပါ။ TLS လည်း ကောင်းပါတယ် - နောက် check ဆီ ဆက်သွားပါ။

Check 3: Server က response ပြန်ပေးလား?

Server ဆီ curl request တိုက်ရိုက်ပို့လိုက်တော့ HTTP 500 status ပြန်လာပါတယ် - timeout မဟုတ်ဘူး၊ connection refused လည်း မဟုတ်ဘူး။ Server run နေပြီး ဖြေနေတာပါ - error နဲ့ ဖြေတာပါ။

Check 4: Application-level error ရှိလား?

ဟုတ်ကဲ့ - 500 status ကိုယ်တိုင်က အတည်ပြုနေပါတယ်။ နောက်အဆင့်က platform ရဲ့ log viewer ဖြစ်ပါတယ်၊ DNS setting (သို့) certificate panel မဟုတ်ပါ။

Log တွေက ဘာပြနေလဲ

Stack trace က database client အထဲမှာ ဆုံးသွားပြီး၊ အပေါ်ကနေ log ဝင်လာတဲ့ warning တစ်ခုက startup မှာ connection-string value တစ်ခု empty ပြန်လာကြောင်း မှတ်ချက်ပေးထားပါတယ်။

အလုပ်လုပ်နေတဲ့ code ပေါင်း environment ဒီတစ်ခုမှာသာ empty ဖြစ်နေတဲ့ value ဆိုတာ logic bug နဲ့ မတူတဲ့ pattern တစ်ခုပါ - code ကို မထိခင် platform configuration မှာ အရင် စစ်ဆေးသင့်ပါတယ်။

DNS -> HTTPS -> server response -> application error ဆိုတဲ့ fixed decision tree က ကျပန်း စမ်းသပ်ခြင်းထက် deployment ပျက်နေတဲ့ အကြောင်းရင်းကို ပိုမြန်စွာ ကျဉ်းချပေးပါတယ်။
HTTP 500 လို error status တစ်ခုက server run နေပြီး response ပြန်ပေးနေကြောင်း သက်သေပြသလို timeout (သို့) connection refused ကတော့ server မဖြေနိုင်ကြောင်း သက်သေပြပါတယ် - ဒါတွေက layer လုံးဝကွဲပြားနေပါတယ်။
System ရဲ့ အပြင်ဘက် boundary ကနေ အထဲကို အလုပ်လုပ်ပါ - layer တစ်ခုချင်းစီကို အောက်ခြေ layer ကို သံသယမဝင်ခင် အရင်အတည်ပြုပါ။

အတူတူ စမ်းရေးကြည့်မယ်

javascript

function diagnose({ dnsResolves, httpsWorks, serverResponds, hasAppError }) {
  if (!dnsResolves) return "DNS_ISSUE";
  if (!httpsWorks) return "TLS_CERTIFICATE_ISSUE";
  if (!serverResponds) return "PLATFORM_RUNTIME_ISSUE";
  if (hasAppError) return "APP_ERROR_CHECK_LOGS_ENV_DB";
  return "SITE_HEALTHY";
}

const scenarios = [
  {
    name: "Blank page, DNS_PROBE_FINISHED_NXDOMAIN in browser",
    checks: { dnsResolves: false, httpsWorks: false, serverResponds: false, hasAppError: false },
  },
  {
    name: "Domain loads over HTTPS, but curl to the server times out",
    checks: { dnsResolves: true, httpsWorks: true, serverResponds: false, hasAppError: false },
  },
  {
    name: "Server returns HTTP 500 with a stack trace in the logs",
    checks: { dnsResolves: true, httpsWorks: true, serverResponds: true, hasAppError: true },
  },
];

for (const s of scenarios) {
  console.log(`${s.name} -> ${diagnose(s.checks)}`);
}

You should see

diagnose() function ကို scenario သုံးခုနဲ့ run ကြည့်တဲ့အခါ tree ရဲ့ layer တစ်ခုချင်းစီအလိုက် မှန်ကန်တဲ့ category ကို ပြန်ပေးပါတယ် -

Blank page, DNS_PROBE_FINISHED_NXDOMAIN in browser -> DNS_ISSUE
Domain loads over HTTPS, but curl to the server times out -> PLATFORM_RUNTIME_ISSUE
Server returns HTTP 500 with a stack trace in the logs -> APP_ERROR_CHECK_LOGS_ENV_DB

၅ မိနစ် စမ်းကြည့်

အဖြေတွေ မကြည့်ခင် decision tree ကို ကိုယ်တိုင် သုံးကြည့်ပါ - visitor တစ်ဦးက site 'မ load ဖြစ်ဘူး' လို့ report လုပ်ပြီး browser မှာ certificate warning ပြနေတယ်၊ blank page မဟုတ်ပါ။ check လေးခုထဲက ဘယ်ခုက ဒါကို ဖမ်းမိပြီး ဘယ် category ထဲ ကျရောက်မလဲ? ပြီးရင် ဒုတိယ case တစ်ခု စမ်းကြည့်ပါ - site က error တစ်ခုမှမပါဘဲ ချက်ချင်း load ဖြစ်ပေမယ့် button တစ်ခုကို နှိပ်တိုင်း တိတ်တဆိတ် fail ဖြစ်နေတယ်။ ဒီ failure ဟာ tree ထဲမှာ ဘယ်နေရာမှာ ရှိနေလဲ၊ ဘာကို အရင်စစ်ဆေးမလဲ?

သတိလေးတစ်ချက်

DNS နဲ့ HTTPS ကို အတည်မပြုရသေးဘဲ application log ထဲကို တည့်တည့်ဝင်ရှာတာက layer တစ်ခုကွာနေတဲ့ ပြဿနာရဲ့ symptom တွေကိုသာ လိုက်ရှာနေသလို ဖြစ်ပြီး အချိန်ကုန်စေပါတယ်။

'HTTP 500' နဲ့ 'connection refused' ကို failure အမျိုးအစား တူတူလို့ မှားထင်တာ - တစ်ခုက server က error နဲ့ ဖြေပေးတာ၊ နောက်တစ်ခုက server လုံးဝ မဖြေဘူးဆိုတာကို ဆိုလိုပြီး fix ကွဲပြားစွာ လိုအပ်ပါတယ်။

MDN Web Docs - DNS — Cloud & Deployment