ပျက်ကွက်သော republish သည် အလုပ်လုပ်နေသော backend ကို ဘယ်တော့မှ မဖျက်ပါ

၂၀၂၆ စက်တင်ဘာ ၂၅ ရက်မှာ ပျက်ကွက်သွားတဲ့ republish တစ်ခုက app တစ်ခုရဲ့ backend ကို ဖျက်ပစ်လိုက်ပါတယ်။ အဲဒီ backend ဟာ နှစ်နာရီခွဲလောက် live ဖြစ်ပြီး အလုပ်ကောင်းကောင်း လုပ်နေခဲ့တာပါ။ မှားယွင်းတဲ့ publish ကို ပြန်ဖြုတ်ပေးတဲ့ code က publish က ထိခဲ့တဲ့ server app အားလုံးကို ဖျက်ပစ်ခဲ့ပြီး၊ ဒါတွေထဲမှာ publish မစခင်ကတည်းက ဝန်ဆောင်မှု ပေးနေပြီးသား app တွေလည်း ပါဝင်ခဲ့ပါတယ်။ ယခု ဖန်တီးခဲ့တဲ့ publish က ဖန်တီးထားတဲ့ app တွေကိုသာ ဖျက်ပါတယ်။ ရှိပြီးသား app ကတော့ အရင်က run နေတဲ့ version အတိအကျအတိုင်း ပြန်ထားပေးပါတယ်။ အဲဒီနေ့တည်း ထပ်ပြင်ထားတဲ့ နည်းနှစ်ခုကလည်း ပြန်ဖြုတ်တဲ့ အလုပ်ဟာ hosting platform ရဲ့ deploy tool ပျက်သွားရင်တောင် အလုပ်လုပ်အောင်၊ နေထိုင်ဆဲ app တစ်ခုကို "never started" ဆိုပြီး မမှားအောင် ပြင်ထားပါတယ်။

Mythex မှာ backend ကို publish လုပ်ပုံ

သင့် Mythex app မှာ backend ရှိရင်၊ ဥပမာ API သို့မဟုတ် server ရှိရင် publish လုပ်တဲ့အခါ Dockerfile (app ကို image အဖြစ် ထုပ်ပိုးတဲ့ နည်းစနစ်) ကနေ build လုပ်ပြီး ကျွန်ုပ်တို့ရဲ့ hosting platform ပေါ်က machine တွေပေါ် အဲဒီ image ကို ဖြန့်ချိပါတယ်။ ပြီးရင် health check က version အသစ် တကယ် တက်လာပြီး ဆက်ရပ်တည်နိုင်မှန်း စောင့်ကြည့်ပြီးမှ publish ကို live အဖြစ် မှတ်ပါတယ်။

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

ပြဿနာ ၁: rollback က ပြန်ထားသင့်တာကို ဖျက်ခဲ့တယ်

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

ဒါပေမဲ့ republish အတွက်ဆိုရင် ဒါဟာ လုံးဝမှားနေပါတယ်။ app က အရင်ကတည်းက ရှိနေပြီး တကယ့် visitor တွေကို ဝန်ဆောင်မှု ပေးနေတာပါ။ ၂၀၂၆ စက်တင်ဘာ ၂၅ ရက်မှာ နှစ်နာရီခွဲ live ဖြစ်နေခဲ့တဲ့ app ရဲ့ API ကို ပျက်ကွက်တဲ့ republish က ဖျက်ပစ်လိုက်ပါတယ်။

ဒီ code ထဲမှာ ဒုတိယ failure mode တစ်ခုလည်း ရှိပါတယ်။ ဖျက်တာ မအောင်မြင်ခဲ့ရင် ပျက်စီးနေတဲ့ image အသစ်က machine တွေပေါ် ဆက်ရှိနေမှာပါ၊ ဒါပေမဲ့ ပိုင်ရှင်ကို သူ့ site ကတော့ live ဖြစ်နေဆဲလို့ ပြောထားမိပါတယ်။ health check ပျက်နိုင်ချိန်ရောက်တဲ့အခါ image အသစ်ကို machine အားလုံးပေါ် ရောက်ပြီးသားဖြစ်နေပါတယ်။ ဘာမှ မလုပ်တာနဲ့ ပြန်ဖြုတ်တာဟာ တူပါတယ်လို့ မဆိုနိုင်ပါဘူး။

ပြင်ဆင်ချက်: ဖန်တီးထားတာကိုသာ ဖျက်ပြီး ကျန်တာကို ပြန်ထားပေးမယ်

publish တိုင်းက သူ ထိခဲ့တဲ့ server app တစ်ခုချင်းစီအတွက် အောက်ပါတို့ကို မှတ်ထားပါတယ်:

• ဒီ publish က ဖန်တီးခဲ့တာလား၊ နှင့်
• မဟုတ်ရင် ဘယ် image ကို run နေခဲ့တာလဲ ဆိုတာ၊ အဲဒါက publish မစခင်ကတည်းက ဖြစ်ပါတယ်။

ပျက်ကွက်ချိန်မှာ app တစ်ခုစီက အောက်ပါ ကိုင်တွယ်မှု သုံးမျိုးထဲက တစ်မျိုးကို ရပါမယ်:

1. ဒီ publish က ဖန်တီးခဲ့တာ: အရင်အတိုင်း ဖျက်ပါမယ်။
2. ရှိပြီးသားဖြစ်ပြီး ယခင် image သိနေတာ: အရင် image ကို configuration အတူတူနဲ့ ပြန် deploy ပါမယ်။ build မလုပ်ပါဘူး၊ image ပဲ ပြန်ရွှေ့ပါတယ်။
3. ရှိပြီးသားဖြစ်ပြီး ယခင် image မသိတာ: ဘာမှ မလုပ်ပါဘူး။ ရှိပြီးသား app ကို ပြန်ထားလို့ မရရင်တောင် ဘယ်တော့မှ မဖျက်ပါဘူး။

ဒီစည်းမျဉ်းတွေဟာ ကိုယ်ပိုင် tests ပါတဲ့ function သေးသေးလေး တစ်ခုအဖြစ် ရှိပါတယ်။ ဒီလို အဖြေဆုံးဖြတ်ချက်က "အားလုံးကို ဖျက်" ဆိုတဲ့ အနေအထားကို ပြန်မရောက်အောင် test တစ်ခုက ဖမ်းနိုင်ပါတယ်။

ပြဿနာ ၂: ပြန်ဖြုတ်နည်းကို မှတ်ထားမီ deploy tool က ပျက်နိုင်တယ်

ထို fix ပြီးနောက် မကြာခင်မှာ ကျွန်ုပ်တို့ က အဲဒီ fix ထဲမှာ ကွက်လပ်တစ်ခု တွေ့ခဲ့ပါတယ်။ hosting platform ရဲ့ deploy tool က သူ့ကိုယ်ပိုင် smoke check တွေ run ပါတယ်။ machine အသစ်တွေ crash ဖြစ်ရင် error နဲ့ ထွက်ပါတယ်။ ဒါပေမဲ့ အဲဒါက image အသစ် machine ပေါ် ရောက်ပြီးနောက် မှသာ ဖြစ်ပါတယ်။

ကျွန်ုပ်တို့ရဲ့ code က deploy tool ပြန်ပြီး အောင်မြင်တဲ့အခါမှသာ app ကို rollback စာရင်းထဲ ထည့်ထားတာပါ။ deploy tool ကိုယ်တိုင် deploy ကို ပျက်စေခဲ့ရင် app က rollback စာရင်းထဲ မရောက်သေးလို့ ပြန်ထားစရာ ဘာမှ မရှိခဲ့ပါဘူး။ ကျွန်ုပ်တို့ရဲ့ staging environment မှာ ပျက်ကွက်တဲ့ republish က ပျက်စီးနေတဲ့ image ကို ဆက် serve ထားခဲ့ပါတယ်။

ပြင်ဆင်ချက်: မစခင် ပြန်ဖြုတ်နည်းကို အရင် မှတ်ထားပါ

app ကို ပြင်ဆင်ပြီး အရာတစ်ခုမှ မတင်ခင် rollback စာရင်းထဲ ထည့်ပြီးပါပြီ။ ဖန်တီးခဲ့မခဲ့ဆိုတာနဲ့ ဘယ် image ကို run ခဲ့တာလဲ ဆိုတာလည်း ထည့်ထားပါတယ်။ နောက်ပိုင်းမှာ ဘာပဲ ပျက်ပါစေ၊ rollback က ပြန်ထားရမယ့်အရာကို သိနေပါပြီ။ ကျွန်ုပ်တို့ local မှာ စမ်းသပ်ခဲ့ပြီး ပျက်ကွက်တဲ့ republish က deploy tool ရဲ့ smoke check တွေမှာ ကျရှုံးခဲ့ပြီး၊ ယခင် version က ဆက်ပြီး ဖြေကြားနေဆဲ ဖြစ်ကြောင်း အတည်ပြုခဲ့ပါတယ်။

ပြဿနာ ၃: အိပ်နေတဲ့ app ကို "never started" လို့ ပျက်ကွက်ခဲ့တယ်

Mythex ပေါ်က publish လုပ်ထားတဲ့ app တွေက credits ချွေတာဖို့ အလုပ်မလုပ်တဲ့အခါ အိပ်ပါတယ်။ republish လုပ်တဲ့အခါ အိပ်နေတဲ့ machine ကို ရပ်ထားရပြီး health check က ၎င်းကို နိုးဖို့ လိုပါတယ်။ ဒါပေမဲ့ platform ကို machine စဖို့ တစ်ကြိမ်သာ တောင်းဆိုပြီး ပြန်ဖြေချက်ကို လျစ်လျူရှုခဲ့ပါတယ်။

၂၀၂၆ စက်တင်ဘာ ၂၅ ရက်မှာ အဲဒီ start တောင်းဆိုမှု တစ်ကြိမ်ဟာ ဘာမှ မဖြစ်သွားခဲ့ပါဘူး။ ကျန်းမာနေတဲ့ API က health check ရဲ့ ငါးမိနစ်လုံး ရပ်နေခဲ့ပြီး "1 machine never started (last state: stopped)" ဆိုပြီး ပျက်ကွက်ခဲ့ပါတယ်။

platform က တစ်ခါတစ်လေ start ကို ငြင်းပါတယ်။ ဒီပြဿနာကို ပြန်ဖြစ်အောင် လုပ်နေချိန်မှာတောင် ကျွန်ုပ်တို့ ဘာမှ မလုပ်ဘဲ "lease currently held" conflict ကို ပြန်ပေးခဲ့ပြီး၊ machine တစ်ခု update လုပ်နေချိန်မှာလည်း start ကို ငြင်းပါတယ်။

ပြင်ဆင်ချက်: ဆက်မေးပါ၊ တံခါးကို ခေါက်ပါ

health check က အခု အောက်ပါတို့ကို လုပ်ပါတယ်:

• စောင့်နေစဉ် ရပ်နေတဲ့ machine ကို ၂၀ စက္ကန့်တိုင်း ထပ် start ဖို့ မေးပါတယ်၊
• platform က ငြင်းတဲ့အခါ ပြန်ဖြေချက်ကို မှတ်ပါတယ်၊ နှင့်
• ဧည့်သည်တစ်ယောက်လို app ကို ပုံမှန် request တစ်ခု ပို့ပါတယ်။ platform ရဲ့ proxy က request ရောက်လာတဲ့အခါ အိပ်နေတဲ့ machine ကို နိုးပေးပါတယ်။

တကယ့် platform ပေါ်မှာ ပထမ start ကို ငြင်းပြီး ပျက်ကွက်တဲ့ အဆင့်မြင့်မဟုတ်တဲ့ app တစ်ခုနဲ့ ပြန်ဖြစ်အောင် လုပ်ကြည့်ခဲ့ပါတယ်။ fix မတိုင်ခင် publish က စက္ကန့် ၉၁ အကြာမှာ ပျက်ခဲ့ပါတယ်။ fix ပြီးနောက် စက္ကန့် ၂၀ နဲ့ publish ဖြစ်ခဲ့ပါတယ်။ boot လုပ်ရင်ပဲ တကယ် crash ဖြစ်တဲ့ app ကတော့ ဆက်ပြီး ပျက်ကွက်ပါလိမ့်မယ်၊ ဒါက မှန်ကန်ပါတယ်။

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

• Rollback က ဖန်တီးထားတာနဲ့ ရှိပြီးသားတာကို ခွဲခြားသိရမယ်။ ကိုယ်ဖန်တီးထားတဲ့အရာအတွက် "undo" ဆိုတာ ဖျက်တာပါ။ ရှိနေပြီးသားအရာအတွက် "undo" ဆိုတာ ပြန်ထားတာပါ။ နှစ်ခုကို တူတူ ဆက်ဆံရင် ကာကွယ်ရေး ယန္တရားက အလုပ်လုပ်နေတဲ့ app ကို ဖျက်ပစ်တတ်ပါတယ်။
• မပြန်ခင် ပြန်ဖြုတ်နည်းကို မှတ်ထားပါ။ အဆင့်တစ်ခု အောင်မြင်ပြီးမှ undo ကို မှတ်ရင်၊ ထိုအဆင့်က တစ်ဝက်မှာ ပျက်သွားရင် undo လုပ်ဖို့ ဘာမှ မရှိတော့ပါဘူး။
• မှီခိုနေတဲ့ တောင်းဆိုမှုရဲ့ အဖြေကို ဘယ်တော့မှ မလျစ်လျူရှုပါနဲ့။ "မရ" ဆိုတဲ့ အဖြေတစ်ခုကို လျစ်လျူရှုလိုက်တာက ကျန်းမာနေတဲ့ app ကို ပျက်ကွက်တဲ့ publish ဖြစ်အောင် ပြောင်းလဲပစ်ခဲ့ပါတယ်။

အဲဒီနေ့ ထပ်ပြင်ထားတဲ့ ဆက်စပ် fix တစ်ခုကတော့ publish ပြီးချင်း crash ဖြစ်တဲ့ app တွေကို ဖမ်းခြင်း ဖြစ်ပါတယ်။ သင့် publish ပျက်ကွက်တဲ့အခါ ဘာလုပ်ရမလဲ သိချင်ရင် docs ထဲက publish troubleshooting ကို ကြည့်ပါ။