lean release တွေဘာကြောင့်လုပ်သင့်သလဲ
monolith ပဲဖြစ်ဖြစ်၊ microservice တွေပဲဖြစ်ဖြစ် software release တွေမှာ မလုပ်သင့်တာတခုက Big Bang release လို့ခေါ်တဲ့ feature တွေအများကြီး၊ hot fix နဲ့ patch တွေအများကြီးကို တပြိုင်တည်း rollout ထုတ်ပေးလိုက်တာပဲ။ ယေဘုယျအားဖြင့် ဒါက လိုက်နာသင့်တဲ့ practice တခုလို့ လက်ခံထားကြပေမယ့် တကယ်တမ်း နောက်ကွယ်မှာ ဒီ idea ကကိုယ့် system ဟာ ဆိုးဆိုးဝါးဝါး နောက်ဆက်တွဲတွေ ရှိမလာပဲ ဘယ်လို risk မျိုးကို ယူနိုင်လဲဆိုတဲ့အချက်နဲ့ ဆက်စပ်နေတယ်။
software တခုက ခြောက်ပြစ်ကင်း သဲလဲစင်တော့မဖြစ်နိုင်ဘူး။ traffic spike တွေမှာ နောက်က scaling မလိုက်နိုင်ခင် request queuing အရှည်ကြီးဖြစ်ပြီး tail latency တက်မယ်။ အကြောင်းအမျိုးမျိုးကြောင့် node နှစ်လုံးဆက်တိုက် fail ပြီး request chain ထဲက downstream service တခုခုရဲ့ instance တွေအကုန်ကျသွားရင် uptime ထိခိုက်မယ်။ regression test မှာ မဖမ်းလိုက်မိတဲ့ bug တခုက production ဆီရောက်မှ 500 (Internal Server Error) တွေလွှတ်တော့တာလည်း ဖြစ်နိုင်တယ်။ ဒီတော့ failure ဆိုတာ တချိန်မဟုတ်တချိန် မလွှဲမသွေ ကြုံရမယ်လို့ မျှော်လင့်ထားရမယ့်အရာမျိုးဖြစ်တယ်။
ဆိုပေမယ့် failure တွေမှာ လက်ခံနိုင်တဲ့ failure ပုံစံဆိုတာရှိတယ်။ ဥပမာ uptime ပဲဆိုပါတော့။ 99.99% uptime ရှိရမယ်လို့ ရည်မှန်းထားတဲ့ system တခုက ရက် ၃၀ လကို window အဖြစ်ယူတွက်မယ်ဆိုရင် 4.32 မိနစ် downtime ဖြစ်လို့ရတယ်။ ဒါပေမယ့် ကိုယ့် system က တလလုံးနီးပါး အလုပ်လုပ်နေပါရဲ့။ ဒီ 4.32 မိနစ်ဆက်တိုက်တော့ unavailable ဖြစ်သွားခဲ့မယ်ဆိုရင် အဆင်ပြေမလားဆိုတဲ့ မေးခွန်းကို ဖြေရလိမ့်မယ်။ system အများစုအတွက် အဖြေက ဟင့်အင်းပါ။ ဒီတော့ 99.99 system အတွက် လက်ခံနိုင်တဲ့ 0.01% downtime ဆိုတာ တတ်နိုင်သလောက် spread ဖြစ်နေဖို့လိုတယ်။ ဥပမာ instance အသစ်တွေ scale out လုပ်နေတုန်း system မှာ 6 စက္ကန့်လောက် glitch ဖြစ်သွားတာမျိုး တပတ်ကို 10 ကြိမ်လောက်ဖြစ်ခွင့်ရှိတယ် စသဖြင့်ပေါ့။ ဒီတော့ ဒီ risk model ကို accommodate လုပ်နိုင်မယ့် lean release cycle ကိုတည်ဆောက်ဖို့လိုလာတယ်။
lean release ဆိုတာ change တွေအများကြီးကို ခပ်ကျဲကျဲနဲ့ တပြိုင်နက်တည်း လွှတ်တာထက် change သေးသေးလေးတွေကို အကြိမ်အရေအတွက် ခပ်စိပ်စိပ် လွှတ်ပေးတဲ့ ပုံစံဖြစ်တယ်။ ဒီအတွက် အားသာချက် ၃ ခုရှိတယ်။ နံပါတ်တစ်က လွှတ်လိုက်တဲ့ rollout တခုချင်းရဲ့ performance နဲ့ impact ကိုရှင်းရှင်းလင်းလင်းမြင်ရ၊ တိုင်းတာလို့ရတယ်။ feature တွေအများကြီး rollout လုပ်လိုက်ရင်ကျ ဘယ်တခုက ကုမ္ပဏီအတွက် ပိုက်ဆံပိုရှာပေးနေတယ်၊ ဘယ်တခုကြောင့် error တွေပိုတက်လာစေတယ်ဆိုတာ ချက်ချင်းထောက်ပြဖို့ မလွယ်ပါဘူး။ နံပါတ်နှစ်က အပေါ်မှာပြောခဲ့သလို lean release တွေက failure အကြီးကြီးတွေ ဖြစ်လာစေမယ့် အခွင့်အလမ်း သိသိသာသာ နည်းသွားစေတယ်။ နံပါတ်သုံးက change တွေကို release အလိုက် သပ်သပ် isolate လုပ်ပြီး ခွဲထုတ်ထားလိုက်တဲ့အတွက် debug ရတာ အများကြီး ပိုလွယ်သွားပြီး နောက် testing cycle မှာအခုပြဿနာကို ဖြေရှင်းပြီးဖြစ်သွားမယ်ဆိုတဲ့ ယုံကြည်မှုမျိုးကိုပေးတယ်။
ဒါပေမယ့် lean rollout တွေသုံးပြီး Big Bang release တွေမလုပ်တော့တာက ပြဿနာအကုန်လုံးကို ဖြေရှင်းပေးလိုက်လိမ့်မယ်လို့တော့ မတွေးစေချင်ဘူး။ အရေးကြီးဆုံးက testing ပါ။ service တခု version အသစ်ထွက်တိုင်း သူ့ကိုမှီခိုထားတဲ့ upstream service တွေ၊ သူကမှီခိုထားတဲ့ downstream service တွေ၊ ဒီ service တွေမှီခိုထားတဲ့ platform service တွေအကုန်လုံးပါဝင်တဲ့ integration test, regression test တွေကို အသေးစိတ် cover ဖြစ်အောင် စစ်နေဖို့လိုတယ်။ နောက်ပြီး ကိုယ့် system က load (overloaded traffic) နဲ့ stress (crash and recovery) အောက်တွေမှာ ကောင်းကောင်း functional ဖြစ်သေးသလားဆိုတာကိုလည်း စစ်ရပါမယ်။ ဒီအတွက် production မပို့ခင် staging environment မှာ chaos engineering ကို healthy ဖြစ်တဲ့ ပမာဏလောက် ထည့်ထားဖို့လိုတယ်။