TLDR: ဘဏ်တစ်ခုရဲ့ Cloud ရင့်ကျက်မှု (Maturity) ဆိုတာ တိုင်းတာချက်တစ်ခုတည်းနဲ့ ဆုံးဖြတ်လို့မရပါဘူး။ အချို့ဘဏ်တွေက infrastructure automation မှာ အရမ်းကောင်းပေမယ့် security governance မှာ အားနည်းနေတတ်ပါတယ်။ ဒီဆောင်းပါးမှာတော့ Cloud maturity ကို အပြန်အလှန်ဆက်နွှယ်နေတဲ့ အလွှာ ၅ လွှာနဲ့ ခွဲခြမ်းပြသွားမှာ ဖြစ်ပါတယ်- Foundations (မူဝါဒများ)၊ Security (လုံခြုံရေး)၊ Automation (အလိုအလျောက်လုပ်ဆောင်မှု)၊ Operations (လုပ်ငန်းလည်ပတ်မှု) နဲ့ Value Delivery (တန်ဖိုးဖော်ဆောင်မှု) တို့ ဖြစ်ပါတယ်။
ဒါဟာ ဘဏ္ဍာရေးလုပ်ငန်းတွေအတွက် cloud engineering နဲ့ leadership ဆိုင်ရာ ဆောင်းပါးတွဲရဲ့ စတုတ္ထမြောက် ဆောင်းပါးဖြစ်ပါတယ်။ အရင်ဆောင်းပါးတွေမှာတော့ ဘဏ်တွေရဲ့ cloud operating model ၊ governance leader တစ်ယောက်ရဲ့ အခန်းကဏ္ဍနဲ့ APRA စံနှုန်းတွေကို architecture နဲ့ ဘယ်လိုချိတ်ဆက်ရမလဲဆိုတာတွေကို ဆွေးနွေးခဲ့ပါတယ်။ အခုတော့ သင့်ရဲ့ cloud function ဟာ ဘယ်အဆင့်မှာ ရှိနေသလဲဆိုတာကို အလွှာ ၅ လွှာနဲ့ တိုင်းတာကြည့်ရအောင်။
ဘယ်သူမှ မပြောဖြစ်သေးတဲ့ Maturity စကားဝိုင်း
Board risk review လုပ်နေတဲ့ တတိယပတ်မှာ CRO က spreadsheet တစ်ခုကို ကိုင်ထားပါတယ်။ အဲဒီထဲမှာ cloud workloads၊ backup frequency၊ encryption status တွေအားလုံး အစိမ်းရောင်ပြနေပါတယ်။ CIO ကလည်း platform အဖွဲ့ရဲ့ policy-as-code နဲ့ automated compliance scanning လုပ်ငန်းစဉ်တွေကို ရှင်းပြနေပါတယ်။
အဲဒီအချိန်မှာ ဒါရိုက်တာတစ်ယောက်က အားလုံးကို တုန်လှုပ်သွားစေမယ့် မေးခွန်းတစ်ခု မေးလိုက်ပါတယ်- “မင်းတို့မှာ ကောင်းမွန်တဲ့ architecture နဲ့ tools တွေ ရှိတာတော့ ဟုတ်ပါပြီ။ ဒါပေမယ့် ငါတို့ရဲ့ အရေးကြီးဆုံး business application တစ်ခုကို ဒီ platform ပေါ် ဒီနေ့ တင်လိုက်မယ်ဆိုရင်၊ ဘယ်လောက်မြန်မြန် deploy လုပ်နိုင်မလဲ? Observability ကိုရော ဘယ်လောက်မြန်မြန် ရမလဲ? မနက် ၃ နာရီမှာ တစ်ခုခုမှားသွားရင် ဘယ်သူက တာဝန်ယူဖြေရှင်းမှာလဲ?”
ခန်းမတစ်ခုလုံး တိတ်ဆိတ်သွားပါတယ်။
ဒီ spreadsheet က infrastructure ကိုပဲ တိုင်းတာနေတာပါ။ ဒါရိုက်တာရဲ့ မေးခွန်းကတော့ စွမ်းဆောင်ရည် (capability) အကြောင်း ဖြစ်ပါတယ်။ ဒါဟာ maturity model တွေက ဖော်ထုတ်ပေးမယ့် ကွာဟချက်ပါပဲ။
Cloud Maturity ရဲ့ အလွှာ ၅ လွှာ
စည်းမျဉ်းစည်းကမ်း တင်းကျပ်တဲ့ ဘဏ်လုပ်ငန်းပတ်ဝန်းကျင်မှာ cloud maturity ဆိုတာ လမ်းကြောင်းတစ်ခုတည်း မဟုတ်ဘဲ အောက်ပါ အလွှာ ၅ ခု အချိုးကျ တိုးတက်နေဖို့ လိုအပ်ပါတယ်။
Layer 1: Foundations (အခြေခံအုတ်မြစ်များ)
Foundations ဆိုတာ မြန်နှုန်းထက် ဖွဲ့စည်းပုံ (structure) ကို ပိုဦးစားပေးပါတယ်။ multi-tier landing zone တွေ၊ platform controls တွေနဲ့ policy-as-code framework တွေ ပါဝင်ပါတယ်။ ဒါဟာ “prudential engineering” လို့ ခေါ်တဲ့၊ မှန်ကန်တဲ့အရာကို လုပ်ဖို့ architecture အရ ပိုမိုလွယ်ကူအောင် ဖန်တီးထားတဲ့ အလွှာဖြစ်ပါတယ်။
Layer 2: Security (လုံခြုံရေး)
လုံခြုံရေးဆိုတာ တစ်နှစ်တစ်ခါ လုပ်တဲ့ audit မဟုတ်ဘဲ စဉ်ဆက်မပြတ် လုပ်ဆောင်နေရမယ့် စည်းကမ်း (continuous discipline) ဖြစ်ပါတယ်။ Security maturity ရှိတယ်ဆိုရင် encryption က policy-enforced ဖြစ်နေရမယ်၊ threat detection က real-time ဖြစ်နေရမယ်၊ security testing တွေကို deployment pipeline ထဲမှာ (shift-left) ထည့်ထားရပါမယ်။
Layer 3: Automation (အလိုအလျောက်လုပ်ဆောင်မှု)
ဒါဟာ ဘေးကင်းလုံခြုံမှုကို မထိခိုက်စေဘဲ လုပ်ငန်းစဉ်တွေကို မြန်ဆန်အောင် (velocity) လုပ်ဆောင်တာပါ။ Infrastructure-as-code (IaC) ကို သုံးပြီး team တစ်ခုက application အသစ်တစ်ခုကို guardrails တွေနဲ့အတူ တစ်နာရီအတွင်း deploy လုပ်နိုင်ရပါမယ်။
Layer 4: Operations (လုပ်ငန်းလည်ပတ်မှု)
CPS 230 လို စံနှုန်းတွေအရ အရေးကြီးတဲ့ လုပ်ငန်းစဉ်တွေဟာ အခက်အခဲကြားမှာတောင် ပုံမှန်အတိုင်း လည်ပတ်နိုင်ရပါမယ်။ Maturity ရှိတဲ့ operations မှာ ရှင်းလင်းတဲ့ SLOs တွေ၊ error budgets တွေနဲ့ chaos engineering စမ်းသပ်မှုတွေ ရှိနေရပါမယ်။
Layer 5: Value Delivery (တန်ဖိုးဖော်ဆောင်မှု)
နောက်ဆုံးအဆင့်ကတော့ platform ကို product တစ်ခုလို သဘောထားတာပါ။ Application teams တွေအတွက် cloud platform ကို သုံးရတာဟာ အဟန့်အတား မဖြစ်ဘဲ လုပ်ငန်းရလဒ်တွေကို ပိုမိုမြန်ဆန်အောင် ကူညီပေးနိုင်တဲ့ အခြေအနေ ဖြစ်ပါတယ်။
သင့်ဘဏ်က ဘယ်အဆင့်မှာလဲ?
ဘဏ်အများစုဟာ အလွှာအားလုံးမှာ တစ်ပြေးညီ ရင့်ကျက်မှု မရှိကြပါဘူး။ အချို့က Foundations ကောင်းပေမယ့် Operations အားနည်းတတ်ပါတယ်။ အရေးကြီးတာက ဘယ်အလွှာမှာ ကွာဟချက် (gap) ရှိနေလဲဆိုတာကို ရှာဖွေပြီး အဲဒီ gap ကို အရင်ဆုံး ဖြည့်ဆည်းဖို့ ဖြစ်ပါတယ်။
နောင်လာမယ့် Blog 5 မှာတော့ ဒီအလွှာအားလုံးရဲ့ အောင်မြင်မှုကို ဆုံးဖြတ်ပေးမယ့် “Landing Zone Architecture” အကြောင်းကို အသေးစိတ် ဆွေးနွေးသွားမှာ ဖြစ်ပါတယ်။ သင်တို့ရဲ့ cloud program ကရော ဘယ်အလွှာမှာ အားနည်းနေသလဲ?
