Publish ပြီးချင်း crash ဖြစ်တဲ့ App များကို ဖမ်းခြင်း

၂၀၂၆ စက်တင်ဘာ ၂၅ ရက်မှာ publish သုံးခုကို အောင်မြင်ပြီးလို့ မှတ်ခဲ့ပေမဲ့ app ရဲ့ API က boot တိုင်း စက္ကန့်အနည်းငယ်အကြာ crash ဖြစ်နေခဲ့ပါတယ်။ "အောင်မြင်တယ်" ဖြစ်လို့ rollback မလုပ်ခဲ့ပါ။ နောက်ပိုင်း မိနစ်အနည်းငယ်အကြာ နောက်ခံ စစ်ဆေးချက်က ၎င်းတို့ကို ပျက်ကွက်ပြီး site တစ်ခုလုံး 404 ဖြစ်သွားပါတယ်။ health check က hosting platform ရဲ့ event list ထဲမှာ crash တွေကို ရေတွက်နေခဲ့ပါတယ် — ဒီ list က machine တစ်ခုစီအတွက် နောက်ဆုံး event ငါးခုသာ ထိန်းထားပြီး၊ crash loop ဖြစ်ရင် list ပြည့်နေလို့ ရေတွက်တာ တိုးမလာပါဘူး။ ယခုတော့ နောက်ဆုံး crash ရဲ့ အချိန်ကို နှိုင်းယှဉ်ပါတယ်၊ crash-loop ဖြစ်တဲ့ publish ဟာ ပျက်ကွက်ပြီး ယခင် version ကို ပြန်ထားပေးပါတယ်။

publish က ဘာကို စောင့်လဲ

Mythex မှာ backend ပါတဲ့ app ကို publish လုပ်တဲ့အခါ version အသစ်ကို ကျွန်ုပ်တို့ရဲ့ hosting platform ပေါ်က machine တွေ ပေါ်မှာ ဖြန့်ချိပြီး health check က publish live ဖြစ်မလား ပျက်မလား ဆုံးဖြတ်ပါတယ်။ ပျက်ရင် rollback က ယခင် version ကို ပြန်ထားပေးပါတယ်။

ခက်တာက "စတင်ပြီး" ဆိုတာ "ဝန်ဆောင်မှု ပေးနေတယ်" နဲ့ တူတာမဟုတ်ပါဘူး။ platform က machine ထ နိုင်ပြီဆိုတာနဲ့ စတင်ပြီးဟု အစီရင်ခံပါတယ်။ boot လုပ်တဲ့ စက္ကန့်တစ်ခန့်အကြာမှာ crash ဖြစ်တဲ့ app ကို ချက်ချင်း ပြန် start လုပ်ပြီး၊ ခဏကြာတော့ ထပ်ပြီး စတင်ပြီးဟု ဖတ်ပါတယ်။ ဒါကြောင့် health check က အလွှာ အချို့ ကြီးလာခဲ့ပါတယ်:

1. နှစ်ကြိမ် ကြည့်ပါ။ machine က စတင်ပြီးဟု ဖတ်ပြီးနောက် ခဏ စောင့်ပြီး ထပ်ကြည့်ပါ။ boot တွင် crash ဖြစ်တာက ဒုတိယ ကြည့်ချက်မှာ မကြာခဏ ပျက်ပါတယ်။
2. crash loop ကို ကြည့်ပါ။ platform က machine တစ်ခု အကြိမ်ကြိမ် crash ဖြစ်ပြီး restart ဆက်မလုပ်တော့ကြောင်း report လုပ်ရင် ပျက်ပါ။
3. ဒီ publish စတဲ့နောက်မှ crash ရေတွက်ပါ။ ကြည့်ချက် နှစ်ခုက restart တစ်ခုကို ဖြတ်သွားနိုင်တယ်။ ဒါကြောင့် ဒီ publish စတဲ့နောက်မှ crash တစ်ခုခု ဖြစ်ခဲ့ရင် တတိယ အကြိမ် ကြည့်ပါ၊ နောက်ဆုံးကြည့်ချက်မှာ ယခင်ကြည့်ချက်ထက် crash ပိုရှိနေရင် app က တည်တည်ငြိမ်ငြိမ် မရပ်နိုင်ဘူးလို့ သတ်မှတ်ပါ။

သုံးနေတဲ့ တတိယ စစ်ဆေးချက်က ဒီမှာ ပျက်ခဲ့တာပါ။

ဘာကြောင့် ရေတွက်တာ မပြောင်းလဲခဲ့တာလဲ

crash အချက်အလက်က machine တစ်ခုစီရဲ့ event list ကနေ လာပါတယ်: start, exit, restart တို့ ဖြစ်ပါတယ်။ platform က machine တစ်ခုအတွက် နောက်ဆုံး event ငါးခု ကိုသာ ထိန်းထားပါတယ်။

စက္ကန့် ၂.၅ အကြာမှာ boot တိုင်း crash ဖြစ်တဲ့ app ကို ပုံဖော်ကြည့်ပါ၊ တစ်ခုက အဲဒီလို ဖြစ်ခဲ့ပါတယ်။ လည်ပတ်တိုင်း crash တစ်ခုနဲ့ start တစ်ခု ထပ်ထည့်ပါတယ်။ လည်ပတ်နှစ်ကြိမ်လောက်အကြာမှာ list ပြည့်သွားပြီး ထိုနောက် event သစ်တိုင်း အဟောင်းတစ်ခုကို ထုတ်ပစ်ပါတယ်။ list က ရွေ့သွားပေမဲ့ အမြဲတမ်း crash အနည်းငယ်နဲ့ start အနည်းငယ်ရဲ့ ပေါင်းစပ်ပုံ တူတူပဲ ရှိနေပါတယ်။

ဒါကြောင့် "publish စတဲ့နောက် crash ဘယ်နှစ်ခု ဖြစ်လဲ" ဟာ ကြည့်တိုင်း တူညီတဲ့ ဂဏန်းပြန်ပါတယ်။ ဒုတိယ ကြည့်ချက်က crash နှစ်ခု ပြတယ်ဆိုပါစို့။ တတိယ ကြည့်ချက်လည်း crash နှစ်ခု ပြပါတယ် — crash အသစ်တွေ ဖြစ်ပေမဲ့ ဂဏန်းတူ။ စစ်ဆေးချက်က crash တွေ ရပ်သွားပြီလို့ ကောက်ချက်ချပြီး publish ကို အောင်မြင်ခဲ့ပါတယ်။

၎င်းက ၂၅ စက်တင်ဘာမှာ app နှစ်ခုပေါ် သုံးကြိမ် ဖြစ်ခဲ့ပါတယ်။ တစ်ကြိမ်ချင်းစီမှာ:

• publish ကို live အဖြစ် မှတ်ခဲ့ပါတယ်၊
• ပျက်ကွက်တာ မရှိလို့ rollback မလုပ်ခဲ့ပါ၊
• ကျွန်ုပ်တို့ရဲ့ reconciler (deployment တွေကို နောက်မှ စစ်ဆေးတဲ့ နောက်ခံ job) က မိနစ်အနည်းငယ်အကြာ deployment ကို ပျက်ကွက်ပြီးမှတ်ပါတယ်၊
• site တစ်ခုလုံးက 404 ပြန်ပါတယ်။

အချိန်မှန်မှန် ပျက်တဲ့ publish ကို ပြန်ကောင်းလို့ရပါတယ်၊ rollback က ယခင် version ကို ပြန်ထားပေးပါတယ်။ ဒါပေမဲ့ အောင်မြင်တယ်လို့ ကြေညာပြီးမှ မိနစ်အနည်းငယ်နောက်ကျမှ ပျက်တဲ့ publish ဟာ rollback ကို ကျော်သွားပြီးသားဖြစ်ပါတယ်။

ဘယ်လို တွေ့ခဲ့တာလဲ

ကျွန်ုပ်တို့ local မှာ ပြန်ဖြစ်အောင် လုပ်ခဲ့ပါတယ်: အလုပ်လုပ်နေတဲ့ API တစ်ခုကို အိပ်သွားအောင်လုပ်ပြီး၊ boot တွင် crash ဖြစ်အောင် ပြောင်းလဲမှုတစ်ခုနဲ့ ပြန် publish လုပ်ခဲ့ပါတယ်။ health check က live ဟု မှတ်ခဲ့ပါတယ်။

ဒါက production နဲ့ ကိုက်ညီခဲ့ပါတယ်: publish သုံးခုစလုံးမှာ app က boot တိုင်း စက္ကန့်အနည်းငယ်အကြာ သေဆုံးပေမဲ့၊ ကြည့်ချက်တွေကြား နှိုင်းယှဉ်တဲ့ crash ရေတွက်ချက် တိုးမလာခဲ့ပါဘူး။

ပြင်ဆင်ချက်: ဂဏန်းမဟုတ်ဘဲ နောက်ဆုံး crash ကို နှိုင်းယှဉ်ပါ

crash တွေ ရေတွက်တာ အစား စစ်ဆေးချက်က နောက်ဆုံး crash ရဲ့ အချိန် ကို ကြည့်ပါတယ်၊ publish စတဲ့နောက်မှ။

ဒုတိယ ကြည့်ချက်မှာ publish စတဲ့နောက် crash တစ်ခုခု ပြရင် စစ်ဆေးချက်က စောင့်ပြီး တတိယ အကြိမ် ကြည့်ပါတယ်။ တတိယ ကြည့်ချက်က နောက်ဆုံး crash သည် ဒုတိယ ကြည့်ချက်ထက် နောက်ကျရင် machine က ကြားထဲမှာ ထပ်ပြီး crash ဖြစ်ခဲ့တာပါ။ ၎င်းက တည်ငြိမ်မနေသေးဘူးဖြစ်ပြီး publish က မက်ဆေ့ချ် တစ်ခုနဲ့ ပျက်ကွက်ပါတယ်၊ အဲဒါက publish စတည်းက machine က အကြိမ်ကြိမ် crash ဖြစ်ပြီး ဆက် restart ဖြစ်နေတယ်လို့ ပြောတာပါ။

ဒါက event list ဘယ်လောက် တိုနေနေ အလုပ်လုပ်ပါတယ်။ ငါးခု sliding window က crash ဘယ်နှစ်ခုရှိလဲ ဖုံးကွယ်နိုင်ပေမဲ့ အသစ်တစ်ခု ဖြစ်ခဲ့တာကို ဖုံးကွယ်မနိုင်ပါ — နောက်ဆုံး event က အမြဲ ထိန်းထားတာပါ။

ပြန်ဖြစ်အောင် လုပ်ထားတဲ့ local စမ်းသပ်မှုက အခု မှန်ကန်စွာ အလုပ်လုပ်ပါတယ်: publish ပျက်ကွက်ပြီး ယခင် image ကို ပြန်ထားပါတယ်။ platform ရဲ့ အပြုအမူကို ယူဆောင်ထားတဲ့ test တစ်ခုလည်း ရှိပါတယ် — ကြည့်တိုင်း crash တစ်ခုနဲ့ start တစ်ခု ထည့်ပြီး list ကို ငါးခုအထိ ဖြတ်တယ် — ဆုံးဖြတ်ချက်က ပျက်ကွက်မှုဖြစ်ကြောင်း စစ်ဆေးပါတယ်၊ အောင်မြင်မှု မဟုတ်ပါ။

ကျွန်ုပ်တို့ ရလိုက်တဲ့ သင်ခန်းစာများ

• ရေတွက်နေတဲ့ ဒေတာ ပုံသဏ္ဌာန်ကို သိပါ။ ကန့်သတ်ထားတဲ့ list ပေါ်က ရေတွက်ချက်က list ပြည့်သွားရင် အဓိပ္ပါယ် မရှိတော့ပါ။ ကန့်သတ်ချက်ကို ဖုံးကွယ်ထားတာ မဟုတ်ပါ၊ check ကို အဲဒါအတွက် ဒီဇိုင်းမထုတ်ထားခဲ့တာပါ။
• "ဘာအသစ် ဖြစ်ခဲ့လဲ" ကို "ဘယ်နှစ်ခု ဖြစ်ခဲ့လဲ" ထက် ဦးစားပေးပါ။ နောက်ဆုံး timestamp က ဖြတ်တောက်ခံရလည်း ရှင်သန်ပါတယ်။ စုစုပေါင်းက မရှင်သန်ပါ။
• နောက်ကျမှ ပျက်တာက စောစောပျက်တာထက် ဆိုးပါတယ်။ တူညီတဲ့ ပျက်စီးနေတဲ့ build တစ်ခုက publish ပျက်ပြီး rollback လုပ်ရင် အန္တရာယ်မရှိပေမဲ့၊ အောင်မြင်ဟု အရင်ကြေညာပြီးမှ ဖြစ်ရင် site ကို ပိတ်ပစ်ပါတယ်။
• တကယ့် အခြေအနေအတိုင်း ပြန်ဖြစ်အောင် လုပ်ပါ။ bug က machine တစ်ခုက event list ပြည့်ဖို့ လောက်အထိ crash ဖြစ်ပြီးသားလိုအပ်ပါတယ်။ test ထဲက တစ်ကြိမ် မြန်မြန် crash တစ်ခုက ဒါကို မပြနိုင်ပါဘူး။

ဒါက ထိုနေ့ တခြား ပြင်ဆင်ချက်နဲ့ ဆက်စပ်ပါတယ်၊ rollback က ဖျက်တာ မဟုတ်ဘဲ ယခင် version ကို ပြန်ထားကြောင်း သေချာစေတာပါ: ပျက်ကွက်တဲ့ republish က အလုပ်လုပ်နေတဲ့ backend ကို ဘယ်တော့မှ မဖျက်ပါ။ သင့် app က start တွင် crash ဖြစ်လို့ publish မအောင်မြင်ရင် publish troubleshooting docs နဲ့ AI ဖန်တီးထားတဲ့ app ကို debug လုပ်နည်း လမ်းညွှန်တို့က စတင်ရာ ကောင်းပါတယ်။