လွယ်လွယ်ပြောရရင် chaos engineering ဆိုတာ system တကယ် မကျခင် ကိုယ်တိုင် ရည်ရွယ်ချက်ရှိရှိ ဖြုတ်ချပြီး “ဘယ်လို ပြန်ထမလဲ” စမ်းသပ်တဲ့ ပညာ။ မီးလောင်မှ မီးသတ်ဆေး စမ်းတာမျိုး မဟုတ်ဘဲ မီးမလောင်ခင် လေ့ကျင့်ထားတာမျိုး။
ဒီအယူအဆကို နာမည်ကြီးစေခဲ့တာက Netflix။ ၂၀၁၁ လောက်မှာ Netflix က သူတို့ရဲ့ server တွေကို AWS cloud ပေါ် ရွှေ့တယ်။ ပြဿနာက cloud ဆိုတာ server တစ်လုံး ရုတ်တရက် သေသွားနိုင်တဲ့ နေရာ။ Netflix က တွေးတယ် — “တကယ် သေသွားမှ အံ့ဩနေမယ့်အစား ကိုယ်တိုင် သတ်ပြီး စမ်းကြည့်ရအောင်” တဲ့။ ဒါနဲ့ သူတို့ Chaos Monkey ဆိုတဲ့ tool တစ်ခု ရေးတယ်။ ဒီ monkey က production server တွေထဲက တစ်လုံးကို random ရွေးပြီး အချိန်မရွေး သတ်ပစ်တယ်။ ကြောက်စရာ ကောင်းတယ် ဟုတ်။ ဒါပေမယ့် ရလဒ်က ရှင်းတယ် — server တစ်လုံး သေတိုင်း system က အလိုလို ပြန်ထလာရမယ်။ မထလာရင် အဲဒါ bug ပဲ၊ အခု ပြင်ရမယ်။
ဥပမာနဲ့ ပြောရရင် ငလျင်လေ့ကျင့်ခန်း (earthquake drill) လိုပဲ။ ငလျင် တကယ် လှုပ်မှ “ဘယ်လို ပြေးရမလဲ” စဉ်းစားတာ နောက်ကျတယ်။ ကျောင်းတွေမှာ ခေါင်းလောင်းထိုးပြီး လေ့ကျင့်ခန်း လုပ်တယ် — တကယ် မဟုတ်ပေမယ့် တကယ်လို သဘောထားတယ်။ Chaos engineering လည်း အတူတူပဲ — တကယ့် failure ကို အတုဖန်တီးပြီး လေ့ကျင့်တာ။
ဒီပညာရဲ့ အခြေခံမူတွေ —
Steady state ကို အရင် သတ်မှတ် — “ပုံမှန်ဆို checkout ၉၉.၉% အောင်မြင်ရမယ်” လို့ တိုင်းတာချက် ရှိရမယ်
Hypothesis ချ — “server တစ်လုံး သေရင် checkout rate မကျသင့်ဘူး” လို့ ခန့်မှန်းချက် ချတယ်
Blast radius ကို ကန့်သတ် — အစမှာ server တစ်လုံး၊ region တစ်ခု၊ user ၁% လောက်ပဲ ထိခိုက်အောင် စမ်းတယ်။ Production တစ်ခုလုံး ဖြုတ်ချတာ မဟုတ်ဘူး
အလိုလို ရပ်တန့်နိုင်ရမယ် — တစ်ခုခု မှားရင် experiment က သူ့ဟာသူ ရပ်သွားရမယ်
ဘာတွေ စမ်းလဲ ဆိုတော့ — server သတ်တာ၊ network ကို နှေးအောင် လုပ်တာ၊ disk ပြည့်အောင် ဖြည့်တာ၊ database connection ဖြတ်တာ၊ CPU ၁၀၀% တင်တာ၊ region တစ်ခုလုံး ပိတ်တာ။ ရည်ရွယ်ချက်က တစ်ခုတည်း — “ဒါ ဖြစ်လာရင် ငါတို့ system ဘယ်လို တုံ့ပြန်မလဲ၊ user ထိခိုက်မလား” ဆိုတာ ကြိုသိတာ။
ဒါက ကုမ္ပဏီကြီးတွေအတွက်ပဲ မဟုတ်ဘူး။ ကိုယ့် side project လေးမှာတောင် အတွေးအခေါ် ယူသုံးလို့ ရတယ်။
Backup က တကယ် restore လုပ်လို့ ရလား — တစ်ခါမှ စမ်းမကြည့်ဘဲ “backup ရှိတယ်” လို့ ယုံနေတာ အန္တရာယ်အကြီးဆုံး
Server reboot လုပ်ရင် service အလိုလို ပြန်တက်လား
Database ကျသွားရင် app က ဘယ်လို error ပြမလဲ — user ကို ရိုင်းရိုင်းပြန်ဖြေမလား
ကျွန်တော် ကြိုက်တဲ့ စကားတစ်ခွန်းရှိတယ် — “Hope is not a strategy” တဲ့။ “မကျလောက်ပါဘူး” လို့ မျှော်လင့်နေတာက plan မဟုတ်ဘူး။ ကျမှ ပြင်တာထက် ကြိုဖြုတ်ချပြီး ကြိုပြင်ထားတာ ပိုစျေးသက်သာတယ်။ Netflix က ဒါကို နေ့တိုင်း လုပ်တယ် — သူတို့ရဲ့ monkey တွေက အခု ပိုတောင် ဆိုးလာတယ် (Latency Monkey, Conformity Monkey…)။ ရလဒ်က ကမ္ဘာပေါ်မှာ အယုံကြည်ရဆုံး streaming service တစ်ခု။
မနက်ဖြန် ကိုယ့် project ရဲ့ backup ကို restore စမ်းကြည့်ပါ — မပျက်ခင် သိရတာ အကောင်းဆုံးပဲ။ 🙂
