Cloud ခေါင်းဆောင် သင်တန်း (The Cloud Leader Course)

အခြေခံဗဟုသုတ လုံးဝမရှိသည့်အခြေအနေမှ cloud engineer အဖွဲ့ကို ကျွမ်းကျင်စွာ ဦးဆောင်နိုင်သည်အထိ။

ဤသင်တန်း မည်သို့အလုပ်လုပ်သနည်း

သင်သည် cloud engineer ဖြစ်ရန် လေ့ကျင့်နေခြင်း မဟုတ်ပါ။ cloud engineer များကို ဦးဆောင်ရန် လေ့ကျင့်နေခြင်း ဖြစ်သည် — အစည်းအဝေးခန်းထဲရှိ စကားဝိုင်းတိုင်းကို လိုက်နာနားလည်နိုင်ရန်၊ အရေးကြီးသည့် မေးခွန်းများကို မေးနိုင်ရန်၊ ငွေကြေး၊ အန္တရာယ် (risk) နှင့် လူများနှင့်ပတ်သက်၍ ကောင်းမွန်သော ဆုံးဖြတ်ချက်များ ချနိုင်ရန်၊ ကျွမ်းကျင်သူယောင်ဆောင်စရာမလိုဘဲ ကျွမ်းကျင်သူများ၏ လေးစားမှုကို ရယူနိုင်ရန် ဖြစ်သည်။ ၎င်းသည် လုံးဝကွဲပြားပြီး အပြည့်အဝ သင်ယူ၍ရနိုင်သော ကျွမ်းကျင်မှုတစ်ခုဖြစ်ကာ — ဤသင်တန်းက သင်ပေးမည့် ကျွမ်းကျင်မှုလည်း ဖြစ်သည်။

သင်တန်းတွင် အဆင့်သုံးဆင့် ရှိသည်။ အဆင့် ၁ (အပတ်စဉ် ၁–၈): ဘာသာစကားကို ပြောတတ်အောင်လုပ်ပါ။ Cloud ဆိုသည်မှာ အမှန်တကယ် ဘာလဲဆိုတာနှင့် အဓိက အခြေခံအုတ်မြစ်တိုင်း၏ ဝေါဟာရများကို သင်ယူမည်ဖြစ်၍ အစည်းအဝေးများသည် ဆူညံသံသက်သက် မဟုတ်တော့ပါ။ အဆင့် ၂ (အပတ်စဉ် ၉–၁၆): အခန်းထဲရှိလူများလို တွေးတတ်အောင်လုပ်ပါ။ Architecture (စနစ်တည်ဆောက်ပုံ)၊ security (လုံခြုံရေး) နှင့် ငွေကြေး — cloud အဖွဲ့တိုင်း အပတ်တိုင်း ပြောဆိုကြသည့် စကားဝိုင်းသုံးမျိုးဖြစ်ပြီး ခေါင်းဆောင်တစ်ယောက်အနေနှင့် တန်ဖိုးထပ်ဖြည့်နိုင်သည် သို့မဟုတ် လျစ်လျူရှုခံရမည့် နေရာသုံးခုလည်း ဖြစ်သည်။ အဆင့် ၃ (လ ၅–၂၄): ဦးဆောင်ပါ။ Certification (အသိအမှတ်ပြုလက်မှတ်) များ၊ ဝန်ထမ်းခန့်အပ်ခြင်း၊ ဆုံးဖြတ်ချက်ချ အစည်းအဝေးများ ဦးဆောင်ခြင်းနှင့် senior engineer များနှင့် ရင်ဘောင်တန်းနိုင်သည်အထိ ရိုးသားစွာ လျှောက်ရမည့် နှစ်နှစ်တာ ခရီးလမ်း။

သင်တန်းတစ်ခုလုံးအတွက် စည်းကမ်းများ — တစ်ရက်လျှင် တစ်နာရီ၊ တစ်ပတ်လျှင် ခြောက်ရက် လေ့လာပါ — ပြင်းထန်မှုထက် တစ်သမတ်တည်း ရှိမှုက ပိုအရေးကြီးသည်။ Module (သင်ခန်းစာအခန်း) တိုင်း၏ အဆုံးတွင် Fluency Drill (သဘာဝကျသည်အထိ အသံထွက်၍ ပြောလေ့ကျင့်ရမည့် စာကြောင်းများ) နှင့် Milestone (ရှေ့ဆက်ရန် အသင့်ဖြစ်ကြောင်း သက်သေ) တစ်ခုစီ ပါရှိသည်။ ၎င်းတို့ကို မဖြစ်မနေ လုပ်ပါ — ဖတ်ရုံသက်သက်ဖြင့် မှတ်မိရုံသာ ရရှိပြီး ကျွမ်းကျင်ပြောဆိုနိုင်စွမ်း (fluency) မရနိုင်ပါ။ ထို့ပြင် အပတ်စဉ် ၁ မှစ၍ Decision Journal (ဆုံးဖြတ်ချက် မှတ်တမ်းစာအုပ်) တစ်အုပ် ထားပါ — သဘောတရားတစ်ခု သင်ယူမိတိုင်း ၎င်းသည် ငွေကြေး၊ အန္တရာယ် သို့မဟုတ် လူများအပေါ် မည်သို့သက်ရောက်သည်ကို စာကြောင်းတစ်ကြောင်း ရေးမှတ်ပါ — အကြောင်းမှာ ထိုသို့ ဘာသာပြန်ချိတ်ဆက်ပေးနိုင်ခြင်းသည် သင်၏ တာဝန်တစ်ခုလုံးပင် ဖြစ်သောကြောင့်တည်း။

အဆင့် ၁ — ဘာသာစကားကို ပြောတတ်အောင်လုပ်ပါ (အပတ်စဉ် ၁–၈)

Module 1 (အပတ်စဉ် ၁–၂): Cloud ဆိုသည်မှာ အမှန်တကယ် ဘာလဲ

အဓိက အယူအဆကြီး: Cloud (အင်တာနက်မှတစ်ဆင့် ငှားရမ်းသုံးစွဲသော ကွန်ပျူတာစနစ်များ) ဆိုသည်မှာ သူတစ်ပါးပိုင် ကွန်ပျူတာများကို နာရီအလိုက် ငှားရမ်းပြီး software ဖြင့် စီမံခန့်ခွဲထားခြင်း ဖြစ်သည်။ Cloud မပေါ်မီက ကုမ္ပဏီတစ်ခုသည် server (ဝန်ဆောင်မှုပေး ကွန်ပျူတာ) များကို ကိုယ်တိုင်ဝယ်၊ အခန်းတစ်ခန်းထဲ ထည့်ထား၍ ပြုပြင်ထိန်းသိမ်းရန် လူများကို လခပေးခဲ့ရသည် — နှေးကွေး၊ ကုန်ကျစရိတ်ကြီးပြီး ပြောင်းလွယ်ပြင်လွယ် မရှိပါ။ AWS၊ Microsoft Azure နှင့် Google Cloud တို့သည် ကွန်ပျူတာသန်းပေါင်းများစွာ ထည့်သွင်းထားသော ဂိုဒေါင်ကြီးများ (data center များ) ကို တည်ဆောက်ကာ မည်သူမဆို မည်သည့်နေရာမှမဆို webpage တစ်ခု သို့မဟုတ် code တစ်ကြောင်းမှတစ်ဆင့် စက္ကန့်အလိုက် အပိုင်းလိုက် ငှားရမ်းသုံးစွဲနိုင်အောင် လုပ်ပေးလိုက်ကြသည်။ ဒါပါပဲ။ ဤသင်တန်းထဲရှိ ကျန်အရာအားလုံးသည် ထိုအယူအဆတစ်ခုတည်းပေါ်တွင် အသေးစိတ်ချဲ့ထွင်ထားခြင်းသာ ဖြစ်သည်။

အကြီးဆုံး provider သုံးခု၏ အဓိပ္ပာယ်ဖွင့်ဆိုချက်:

သင်၏ အခမဲ့ AWS account — အပတ်စဉ် ၁ တွင် ဖွင့်ပါ။ https://aws.amazon.com/free သို့သွား၍ “Create a Free Account” ကို နှိပ်ပါ (တိုက်ရိုက် sign-up စာမျက်နှာမှာ https://signin.aws.amazon.com/signup?request_type=register ဖြစ်သည်)။ Email လိပ်စာ၊ ဖုန်းနံပါတ်နှင့် မိမိမည်သူမည်ဝါဖြစ်ကြောင်း အတည်ပြုရန် credit/debit ကတ်တစ်ခု လိုအပ်မည် — Free Tier (အခမဲ့သုံးစွဲခွင့် အဆင့်) က အခြေခံဝန်ဆောင်မှုများကို လစဉ် အခမဲ့ခွင့်ပြုချက်ဖြင့် ပေးထားသည် (ပထမနှစ်တွင် EC2 server အသေးတစ်လုံးကို တစ်လလျှင် နာရီ ၇၅၀ အပါအဝင်) ဖြစ်ပြီး ဤသင်တန်း၏ လေ့ကျင့်ခန်းများသည် ထိုအခမဲ့ဘောင်အတွင်း၌သာ ရှိသည်။ ပထမနေ့မှစ၍ လုံခြုံရေးအလေ့အထ နှစ်ခု — MFA ကို ဖွင့်ထားပါ (Module 6 တွင် ရှင်းပြမည်) နှင့် billing alert (ကုန်ကျစရိတ် သတိပေးချက်) ကို $5 တွင် သတ်မှတ်ထားပါ (Module 7 တွင် နည်းလမ်းရှင်းပြမည်) — ထိုအခါ ဘယ်တော့မှ အံ့အားသင့်စရာ ဘေလ်မလာနိုင်တော့ပါ။ Sign-up ပြီးလျှင် https://console.aws.amazon.com တွင် ဝင်ရောက်နိုင်သည် — “console” ဆိုသည်မှာ AWS ၏ ထိန်းချုပ်ရေး webpage သာ ဖြစ်သည်။

ကုမ္ပဏီများ cloud ကို ဘာကြောင့် သုံးကြသနည်း: မြန်ဆန်မှု (server အသစ်တစ်လုံး ၆ ပတ်အစား ၆၀ စက္ကန့်အတွင်း ရ)၊ ပြောင်းလွယ်ဆန့်လွယ်မှု (elasticity — အရောင်းပွဲကြီးနေ့အတွက် server ၁၀၀ ငှားပြီး နောက်တစ်နေ့ ၉၀ ကို ပြန်အပ်)၊ ကြိုတင်ကုန်ကျစရိတ် မရှိခြင်း (capital expense အစား operating expense) နှင့် ကမ္ဘာလုံးဆိုင်ရာ လက်လှမ်းမီမှု (ဘာမှဆောက်စရာမလိုဘဲ ဘန်ကောက်၊ တိုကျိုနှင့် Frankfurt ရှိ ဖောက်သည်များအနီးတွင် သင့် app ကို ထားနိုင်ခြင်း)။

ဝန်ဆောင်မှု အလွှာသုံးလွှာ — cloud တွင် အသုံးဝင်ဆုံး တွေးခေါ်ပုံစံ:

Region များနှင့် availability zone များ: Region ဆိုသည်မှာ ပထဝီအရ စုစည်းထားသော data center အစုအဝေး ဖြစ်သည် (ထိုင်းနိုင်ငံသည် ၂၀၂၅ ခုနှစ် ဇန်နဝါရီလမှစ၍ ဘန်ကောက်နှင့် အနီးတစ်ဝိုက်တွင် ကိုယ်ပိုင် AWS Region ရှိပြီ)။ Availability Zone (AZ) ဆိုသည်မှာ region တစ်ခုအတွင်းရှိ သီးခြားခွဲထားသော data center တစ်ခု သို့မဟုတ် တစ်ခုထက်ပို ဖြစ်သည်။ အရေးကြီးသော app များကို အနည်းဆုံး AZ နှစ်ခုတွင် လည်ပတ်စေသည် — ထိုအခါ အဆောက်အအုံတစ်လုံး ပျက်သွားလည်း စနစ်မရပ်ပါ။ Engineer များက “we’re multi-AZ” ဟုပြောလျှင် “data center တစ်ခု မီးလောင်သွားလည်း ကျွန်တော်တို့ ဆက်လည်ပတ်နေမယ်” ဟု ဆိုလိုခြင်း ဖြစ်သည်။

ဝေါဟာရများ:

ဤ module အတွက် ဗီဒီယိုများ (အားလုံး အခမဲ့၊ link များ စစ်ဆေးပြီး):

Fluency drill — သဘာဝကျသည်အထိ ပြောပါ: “Is that workload on-prem or in the cloud?” (အဲဒီ workload က on-prem မှာလား၊ cloud ထဲမှာလား။) · “Which region are we in — and are we multi-AZ?” (ကျွန်တော်တို့ ဘယ် region ထဲမှာလဲ — ပြီးတော့ multi-AZ ဖြစ်ရဲ့လား။) · “Is this an IaaS approach or is there a managed service that removes the maintenance?” (ဒါက IaaS နည်းလမ်းလား၊ ဒါမှမဟုတ် ပြုပြင်ထိန်းသိမ်းမှုကို ဖယ်ရှားပေးမယ့် managed service တစ်ခုခု ရှိသလား။)

လေ့ကျင့်ခန်းများ: (၁) https://aws.amazon.com/free တွင် သင့်အခမဲ့ AWS account ကို ဖွင့်ပါ — sign-up လုပ်ငန်းစဉ်ကိုယ်တိုင်က စာအုပ်တစ်အုပ်ဖတ်တာထက် ဝေါဟာရ ပိုသင်ပေးသည်။ (၂) အထက်ပါဇယားထဲရှိ ဗီဒီယိုလေးခုကို ကြည့်ပါ (စုစုပေါင်း မိနစ် ၂၀ အောက်)။ (၃) သင့် journal ထဲတွင် — ထိုင်းကျောင်းအုပ်ကြီးတစ်ဦးကို အသက်တစ်ရှူတည်းနှင့် ပြောပြနိုင်မည့် cloud အကြောင်း အကျဉ်းချုပ် ရှင်းလင်းချက်ကို ရေးပါ။

Milestone: IaaS၊ PaaS နှင့် SaaS ကွာခြားချက်ကို ကိုယ်ပိုင်ဥပမာဖြင့် ရှင်းပြနိုင်ပြီး AWS ဘန်ကောက် region ဖွင့်ခြင်းက ထိုင်းဘဏ်များအတွက် ဘာကြောင့် အရေးကြီးခဲ့သည်ကို ရှင်းပြနိုင်ရမည် (အဖြေ — latency + data residency၊ Module 6 တွင် ကြည့်ပါ)။

Module 2 (အပတ်စဉ် ၃–၄): အခြေခံအုတ်မြစ်များ — compute၊ storage နှင့် database

Compute — code ကို လည်ပတ်စေသော အင်ဂျင်များ။ Virtual machine (VM/instance) ဆိုသည်မှာ ကွန်ပျူတာတစ်လုံးလိုပင် အလုပ်လုပ်သော ရုပ်ပိုင်း server တစ်လုံး၏ အပိုင်းတစ်ပိုင်း ဖြစ်သည် — အရွယ်အစား (CPU/RAM) ရွေးပြီး လည်ပတ်သည့် စက္ကန့်အလိုက် ပေးရသည်။ Container (application တစ်ခုကို ထုပ်ပိုးထားသော ပေါ့ပါးသည့် ပက်ကေ့ဂျ်) ဆိုသည်မှာ application တစ်ခုကို ဘယ်နေရာမှာမဆို တစ်ပုံစံတည်း လည်ပတ်နိုင်အောင် ပိုပေါ့ပါးမြန်ဆန်စွာ ထုပ်ပိုးသည့် နည်းလမ်းဖြစ်သည် — Docker က ၎င်းတို့ကို ထုပ်ပိုးပေးပြီး Kubernetes (K8s) က ၎င်းတို့ အုပ်စုလိုက်ကြီးများကို စနစ်တကျ ညွှန်ကြားစီမံပေးသည် (orchestrate) — “K8s” ဟုကြားလျှင် “ကျွန်တော်တို့ရဲ့ container ရာနှင့်ချီကို အလိုအလျောက် လည်ပတ်စေပြီး ပြုပြင်ကုစားပေးတဲ့ စနစ်” ဟု တွေးပါ။ Serverless (server ကို လုံးဝစီမံစရာမလိုသော ပုံစံ — AWS Lambda) ဆိုသည်မှာ code function တစ်ခုသာ တင်ရပြီး cloud က အချက်ပြခံရချိန် (triggered) တွင် လည်ပတ်ပေးကာ ခေါ်သုံးသည့်အကြိမ်အလိုက် ပေးရသည် — စီမံရမည့် server လုံးဝမရှိပါ။ သတိထားရမည့် ပုံစံမှာ — VM → container → serverless သည် “ထိန်းချုပ်မှုပို၊ ပြုပြင်ထိန်းသိမ်းမှုပို” မှ “ထိန်းချုပ်မှုနည်း၊ ပြုပြင်ထိန်းသိမ်းမှု သုညနီးပါး” သို့ ရွေ့သွားသော slider တစ်ခုဖြစ်သည်။ ကောင်းသောအဖွဲ့များသည် ခေတ်စားမှုအလိုက်မဟုတ်ဘဲ workload တစ်ခုချင်းစီအလိုက် ရွေးချယ်ကြသည်။

Storage — ပုံစံသုံးမျိုး။ Object storage (Amazon S3): ဖိုင်များအတွက် အောက်ခြေမရှိသော ခြင်းတောင်းကြီး — ဓာတ်ပုံ၊ ဗီဒီယို၊ backup၊ dataset များ။ စျေးသက်သာပြီး eleven-nines (ကိုးဂဏန်း ၁၁ လုံး) ခံနိုင်ရည်ရှိကာ “ဖိုင်တွေ ဘယ်မှာထားမလဲ” ၏ ပုံသေအဖြေ ဖြစ်သည်။ Block storage (EBS): VM တစ်လုံးတွင် တပ်ဆင်ထားသော virtual hard disk။ File storage (EFS): စက်များစွာက တစ်ပြိုင်နက် ချိတ်ဆက်သုံးနိုင်သော မျှဝေ drive။ ထို့နောက် tier (စျေးနှုန်း/အမြန်နှုန်း အဆင့်) များ — hot (မကြာခဏသုံး၊ စျေးကြီး) နှင့် cold/archive (Glacier — စျေးပေါ၊ နှေး) — ဒေတာဟောင်းများကို cold tier သို့ ရွှေ့ခြင်းသည် မည်သည့်အဖွဲ့မဆို အလွယ်ဆုံးရနိုင်သော ကုန်ကျစရိတ် လျှော့ချမှုတစ်ခု ဖြစ်သည်။

Database — မိသားစုနှစ်စု။ Relational/SQL (MySQL၊ PostgreSQL — Amazon RDS/Aurora အဖြစ် စီမံပေးသည်): တင်းကျပ်သော ဖွဲ့စည်းပုံရှိ ဇယားများထဲရှိ ဒေတာ။ ငွေကြေး၊ အော်ဒါ၊ user များ — မှန်ကန်မှုက အသက်တမျှ အရေးကြီးသော အရာအားလုံးအတွက် ပုံသေရွေးချယ်မှု။ NoSQL (DynamoDB၊ MongoDB): ပြောင်းလွယ်ပြင်လွယ်ရှိပြီး အလွန်ကြီးမားစွာ ချဲ့ထွင်နိုင်သည် — ကြီးမား၊ မြန်ဆန်ပြီး ပုံစံရိုးရှင်းသော ဒေတာ (session၊ catalog၊ feed) များအတွက် ပုံသေရွေးချယ်မှု။ “Managed database” ဆိုသည်မှာ provider က backup၊ patch နှင့် failover များကို တာဝန်ယူပေးခြင်းဖြစ်သည် — အဖွဲ့များအနေနှင့် ကိုယ်တိုင်ထိန်းသိမ်း လည်ပတ်မည်ဆိုလျှင် ခိုင်လုံသော အကြောင်းပြချက် ရှိသင့်သည်။

ဝေါဟာရများ:

ဤ module အတွက် ဗီဒီယိုများ:

Fluency drill: “Should this run on VMs, containers, or serverless — and what’s the operational cost of each choice?” (ဒါက VM၊ container ဒါမှမဟုတ် serverless ပေါ်မှာ ပြေးသင့်သလဲ — ရွေးချယ်မှုတစ်ခုချင်းစီရဲ့ လည်ပတ်ရေး ကုန်ကျစရိတ်က ဘယ်လောက်လဲ။) · “Is that data hot or can it go to a cheaper tier?” (အဲဒီဒေတာက hot လား၊ ဒါမှမဟုတ် ပိုစျေးသက်သာတဲ့ tier ကို ရွှေ့လို့ရမလား။) · “Why are we self-managing that database instead of using RDS?” (RDS သုံးမယ့်အစား အဲဒီ database ကို ဘာကြောင့် ကိုယ်တိုင် ထိန်းသိမ်းနေတာလဲ။)

လေ့ကျင့်ခန်းများ: (၁) သင့်အခမဲ့ account ထဲတွင် — အသေးဆုံး EC2 instance တစ်လုံး launch လုပ်ပြီး ပြန် terminate လုပ်ပါ။ S3 ထဲသို့ ဖိုင်တစ်ဖိုင် တင်ပါ။ ယခုအခါ သင်ကိုယ်တိုင် IaaS ကို သုံးဖူးပြီ။ (၂) AI assistant တစ်ခုကို မေးခွန်းထုတ်ခိုင်းပါ — “Scenario ၁၀ ခု ပေးပါ။ ကျွန်တော်က VM၊ container ဒါမှမဟုတ် serverless လို့ ဖြေမယ်၊ ခင်ဗျားက အမှတ်ပေးပါ။”

Milestone: စာကြောင်းတစ်ကြောင်းဖြင့် ဖော်ပြထားသော မည်သည့် app ရိုးရိုးကိုမဆို (“ကျောင်းသားတွေ နေ့လယ်စာ မှာယူတဲ့ website”) ပေးလိုက်လျှင် ၎င်း၏ compute၊ storage နှင့် database အစိတ်အပိုင်းများကို ၆၀ စက္ကန့်အတွင်း အသံထွက်ပြောပြနိုင်ရမည်။

Module 3 (အပတ်စဉ် ၅–၆): Network များနှင့် အစိတ်အပိုင်းများ အချင်းချင်း ဆက်သွယ်ပုံ

VPC — သင့်ကိုယ်ပိုင် ရပ်ကွက်။ Virtual Private Cloud (provider ၏ network အတွင်း သင့်ကိုယ်ပိုင် သီးသန့်ခြံခတ်နယ်မြေ) ဆိုသည်မှာ provider ၏ network ထဲမှ သင့်အတွက် ခြံခတ်ခွဲထားသော အပိုင်းဖြစ်သည်။ ၎င်းအတွင်း၌ subnet (VPC ၏ အခွဲငယ်) များ ရှိသည် — public subnet (အင်တာနက်မှ လက်လှမ်းမီနိုင်၊ ဥပမာ web server များ) နှင့် private subnet (လက်လှမ်းမမီနိုင်၊ ဥပမာ database များ)။ သင်အကြားရဆုံးဖြစ်မည့် လုံခြုံရေးစာကြောင်းမှာ — “the database sits in a private subnet” (database က private subnet ထဲမှာ ရှိတယ်)။ ဘာကြောင့်လဲ နားလည်လျှင် — အင်တာနက်မှ လမ်းကြောင်းမရှိသောအရာကို တိုက်ခိုက်သူများ မထိနိုင် — network လုံခြုံရေး၏ တစ်ဝက်ကို သင်နားလည်ပြီးသား ဖြစ်သည်။

Traffic အလွှာ: Load balancer (ဝင်လာသော traffic ကို server များစွာအပေါ် ခွဲဝေပေးသည့်ကိရိယာ) သည် ဝင်လာသော traffic ကို server များစွာအကြား ဖြန့်ဝေပေးသည် (ကျန်းမာရေးမကောင်းသည့် server များကိုလည်း တိတ်တဆိတ် ဖယ်ထုတ်ပေးသည်)။ DNS (Route 53) သည် yourcompany.com ကဲ့သို့ နာမည်များကို လိပ်စာများအဖြစ် ပြောင်းပေးသည်။ CDN (CloudFront) သည် သင့် content ကို မြို့ရာနှင့်ချီတွင် cache (ယာယီမိတ္တူသိမ်း) ထားပေးသဖြင့် နေရာတိုင်းတွင် မြန်မြန်ပွင့်သည်။ API ဆိုသည်မှာ software တစ်ခုက အခြား software တစ်ခုအား ပေးထားသော တံခါးပေါက်ဖြစ်သည် — engineer များက “we’ll expose an API” ဟုပြောလျှင် “အခြား software တွေ ကျွန်တော်တို့ software ကို ထိန်းချုပ်မှုအောက်မှာ သုံးနိုင်အောင် လမ်းဖွင့်ပေးမယ်” ဟု ဆိုလိုသည်။ API gateway ဆိုသည်မှာ ထိုတံခါးပေါက်များကို စီမံပေးသော ဧည့်ကြိုစားပွဲ ဖြစ်သည်။

ကမ္ဘာနှစ်ခု ချိတ်ဆက်ခြင်း: VPN (အင်တာနက်ပေါ်မှ ကုဒ်ဝှက်ထားသော လမ်းကြောင်း) သို့မဟုတ် Direct Connect (သီးသန့် ရုပ်ပိုင်းဆိုင်ရာ ဆက်သွယ်ကြိုးလိုင်း) ဖြင့် ကုမ္ပဏီ၏ ရုံးများ/on-prem စနစ်များကို ၎င်း၏ cloud နှင့် ချိတ်ဆက်သည်။ Hybrid cloud = on-prem နှင့် cloud နှစ်ခုစလုံး တွဲသုံးခြင်း (ထိုင်း enterprise အများစု)။ Multi-cloud = provider တစ်ခုထက်ပို သုံးခြင်း။

ဝေါဟာရများ:

ဤ module အတွက် ဗီဒီယို: AWS Networking Basics — VPC & Subnets for Beginners — KodeKloud — https://www.youtube.com/watch?v=QM63dyA_4Pc (ပထမတစ်ဝက်ကို ယခုကြည့်ပါ။ ကျန်အပိုင်းကို Module 5 ပြီးမှ ပြန်လာကြည့်ပါ။)

Fluency drill: “Is the database in a private subnet?” (Database က private subnet ထဲမှာလား။) · “What happens when one web server dies — is the load balancer health-checking?” (Web server တစ်လုံး သေသွားရင် ဘာဖြစ်မလဲ — load balancer က health-check လုပ်နေရဲ့လား။) · “Are we exposing that as an API or is it internal only?” (အဲဒါကို API အဖြစ် ဖွင့်ပေးမှာလား၊ ဒါမှမဟုတ် အတွင်းသုံး သီးသန့်လား။)

လေ့ကျင့်ခန်းများ: (၁) AI တစ်ခု၏ လမ်းညွှန်မှုဖြင့် အစားအစာပို့ဆောင်ရေး app တစ်ခု၏ network ကို စက္ကူပေါ်တွင် ဆွဲပါ — users → CDN → load balancer → web servers (public subnet) → database (private subnet)။ အလွတ်ဆွဲနိုင်သည်အထိ သုံးကြိမ် ဆွဲပါ။ (၂) သင့်ကုမ္ပဏီ၏ (သို့မဟုတ် နမူနာ) architecture diagram တစ်ခုကို ရှာပြီး ယခုနာမည်ပြောနိုင်ပြီဖြစ်သော အကွက်တိုင်းကို ဝိုင်းပါ။

Milestone: ထိုစံ three-tier diagram ကို whiteboard ပေါ်တွင် ဆွဲပြနိုင်ပြီး ဖောက်သည်တစ်ဦး၏ click တစ်ချက် ထို diagram ထဲ ဖြတ်သန်းသွားပုံ လမ်းကြောင်းကို ပြောပြနိုင်ရမည်။

Module 4 (အပတ်စဉ် ၇–၈): Cloud အဖွဲ့များ အလုပ်လုပ်ပုံ — DevOps၊ IaC နှင့် အခန်းအခြေအနေကို ဖတ်ခြင်း

DevOps (software ရေးသူများနှင့် လည်ပတ်ထိန်းသိမ်းသူများ ပေါင်းစည်းသည့် လုပ်ငန်းယဉ်ကျေးမှု) ဆိုသည်မှာ “software ရေးသူများ” (Dev) နှင့် “၎င်းကို လည်ပတ်ထိန်းသိမ်းသူများ” (Ops) ကို အဖွဲ့တစ်ဖွဲ့တည်း ပေါင်းစည်းကာ ပြောင်းလဲမှုသေးသေးများကို မကြာခဏ၊ ဘေးကင်းစွာ ထုတ်လွှင့်ပြီး လေးလံသောအလုပ်များကို automation က လုပ်ပေးသည့် ယဉ်ကျေးမှုဖြစ်သည်။ ၎င်း၏ နှလုံးခုန်သံမှာ CI/CD pipeline (code ပြောင်းလဲမှုတိုင်းကို အလိုအလျောက် တည်ဆောက်၊ စမ်းသပ်၊ ထုတ်လွှင့်ပေးသော စက်ရုပ်လမ်းကြောင်း — Continuous Integration / Continuous Delivery) ဖြစ်သည်။ အဖွဲ့တစ်ဖွဲ့က “it’s in the pipeline” ဟုပြောလျှင် စက်ရုပ်က စမ်းသပ်ပြီး ထုတ်လွှင့်နေပြီ ဟု ဆိုလိုသည်။

Infrastructure as Code (IaC) — အရာအားလုံးကို ပြောင်းလဲပစ်ခဲ့သော အယူအဆ: console ထဲ ကလစ်နှိပ်၍ server များ ဖန်တီးမည့်အစား engineer များသည် infrastructure ကို ကြေညာသည့် text ဖိုင်များ ရေးကြသည် (“server နှစ်လုံး၊ load balancer တစ်ခု၊ database တစ်ခု၊ ဒီ firewall စည်းကမ်းများ”) — ထို့နောက် ကိရိယာတစ်ခု (Terraform၊ CloudFormation) က လက်တွေ့အခြေအနေကို ဖိုင်နှင့်ကိုက်ညီအောင် လုပ်ပေးသည်။ ခေါင်းဆောင်များ ဂရုစိုက်ရသည့်အကြောင်းမှာ — ထိုဖိုင်များသည် Git (version control စနစ်) ထဲတွင် ရှိသောကြောင့် infrastructure ပြောင်းလဲမှုတိုင်းသည် ပြန်လည်သုံးသပ်နိုင်၊ ပြန်ပြင်နိုင်၊ စစ်ဆေးနိုင် (auditable) ဖြစ်သည် — အလက်ကားလုပ်ငန်းခွင်နှင့် စက်ရုံကြီး ကွာခြားချက်ပင်။

သင်ထိုင်ရမည့် ဓလေ့ထုံးစံများ: Stand-up (နေ့စဉ် ၁၅ မိနစ် — ပြီးသွားတာ၊ ဆက်လုပ်မယ့်ဟာ၊ ပိတ်ဆို့နေတာ — blocker (အဟန့်အတား) များကို နားစွင့်ပါ၊ ၎င်းတို့ကို ဖယ်ရှားပေးခြင်းက သင့်တာဝန်)၊ sprint (၁–၂ ပတ်စာ စီစဉ်ထားသောအလုပ် ယူနစ်)၊ retro (ဘာတွေ ပိုကောင်းအောင်လုပ်မလဲ)၊ post-mortem/incident review (စနစ်ရပ်တန့်မှု (outage) ပြီးနောက် — ဘာပျက်ခဲ့သလဲ၊ ဘာက နောက်တစ်ကြိမ် မဖြစ်အောင် ကာကွယ်မလဲကို အပြစ်မတင်ဘဲ (blameless) ခွဲခြမ်းစိတ်ဖြာခြင်း — ဤအစည်းအဝေးများ ရိုးသားမှုရှိမရှိတွင် အဖွဲ့တစ်ဖွဲ့၏ ကျန်းမာရေး ပေါ်လွင်သည်)၊ on-call (နံနက် ၃ နာရီတွင် နှိုးခံရမည့်သူ အလှည့်ကျစနစ် — on-call က ဒုက္ခပေးနေလျှင် သင့်လူတော်များ ထွက်သွားလိမ့်မည်၊ လစဉ် မေးမြန်းပါ)။

အရေးကြီးသော ကျန်းမာရေး metric များ: Uptime/availability (“three nines” = 99.9% ≈ တစ်နှစ်လျှင် ၈.၈ နာရီ ရပ်တန့်ချိန်။ nine တစ်လုံးထပ်တိုးတိုင်း ကုန်ကျစရိတ် ဆတိုးသည်)၊ SLA (ဒဏ်ကြေးပါသော ကတိ)၊ SLO (အတွင်းပိုင်း ရည်မှန်းချက်)၊ MTTR (ဘယ်လောက်မြန်မြန် ပြန်ကောင်းသလဲ — ရင့်ကျက်သောအဖွဲ့များသည် ဘယ်တော့မှမပျက်ရေးဆိုသော စိတ်ကူးယဉ်ထက် ပြန်လည်ကောင်းမွန်မှုကို အကောင်းဆုံးဖြစ်အောင် လုပ်ကြသည်)၊ deployment frequency (ကျန်းမာသောအဖွဲ့များသည် ပြောင်းလဲမှုသေးသေးများကို မကြာခဏ ထုတ်လွှင့်ကြသည်။ Deploy လုပ်ရမှာ ကြောက်နေခြင်းသည် မကောင်းသော လက္ခဏာ)။

ဝေါဟာရများ:

ဤ module အတွက် ဗီဒီယိုများ:

Fluency drill: “Is that change through the pipeline or was it manual?” (အဲဒီပြောင်းလဲမှုက pipeline ကနေ သွားတာလား၊ လက်နဲ့ လုပ်တာလား။) · “What did the post-mortem conclude, and what’s the prevention item?” (Post-mortem က ဘာကောက်ချက်ချသလဲ၊ ကာကွယ်ရေး လုပ်ငန်းစဉ်က ဘာလဲ။) · “What’s our MTTR trending like?” (ကျွန်တော်တို့ MTTR အလားအလာက ဘယ်လိုရှိလဲ။) · “Is this in Terraform, or did someone click it into existence?” (ဒါက Terraform ထဲမှာလား၊ ဒါမှမဟုတ် တစ်ယောက်ယောက်က ကလစ်နှိပ်ပြီး ဖန်တီးထားတာလား။) — နောက်ဆုံးအမျိုးအစားကို မျက်မှောင်ကြုတ်လျက် “ClickOps” ဟု ခေါ်ကြသည်။

လေ့ကျင့်ခန်းများ: (၁) တကယ့် incident post-mortem မှတ်တမ်းတစ်ခု ဆွေးနွေးခြင်းကို ကြည့်ပါ (အများပြည်သူကြည့်နိုင်သည်များ ရှိသည် — Cloudflare နှင့် AWS တို့၏ outage report များ ကျော်ကြားသည်) ပြီးလျှင် သင့် journal ထဲတွင် စာကြောင်းငါးကြောင်းဖြင့် အကျဉ်းချုပ်ရေးပါ။ (၂) မည်သည့် stand-up တွင်မဆို ဝင်ထိုင် (သို့မဟုတ် အသံသွင်းချက် ကြည့်) ပြီး ကြားခဲ့ရသော blocker သုံးခုကို ချရေးပါ။

Milestone — အဆင့် ၁ အဆုံး: မိနစ် ၃၀ ကြာ နည်းပညာ စီမံကိန်းအစည်းအဝေးတစ်ခုကို အစအဆုံးထိုင်ပြီး ≥80% လိုက်နာနားလည်နိုင်ရမည် — သင့် journal ကလည်း သက်သေပြရမည် — တကယ့် (သို့မဟုတ် စမ်းသပ်ဇာတ်တိုက်) အစည်းအဝေးတစ်ခုမှ မှတ်စုများတွင် အတိုကောက် (acronym) တိုင်း မှန်ကန်စွာ အပြည့်အစုံ ဖြည့်ရေးထားရမည်။ ဤအချိန်သည် AWS Cloud Practitioner စာမေးပွဲ (CLF-C02) ကို ရက်ချိန်းယူသင့်သည့်အချိန်လည်း ဖြစ်သည် — ဤ module များအပေါ်ထပ်၍ အာရုံစိုက်ပြင်ဆင်ချိန် ၂–၄ ပတ်သည် ထုတ်ပြန်ထားသော ပုံမှန်ကြာချိန်ဖြစ်ပြီး အောင်မြင်ခြင်းသည် သင်၏ ပထမဆုံး ပြင်ပသက်သေ ဖြစ်သည်။

အဆင့် ၂ — အခန်းထဲရှိလူများလို တွေးတတ်အောင်လုပ်ပါ (အပတ်စဉ် ၉–၁၆)

Module 5 (အပတ်စဉ် ၉–၁၀): Architecture — ဒီဇိုင်းမဆွဲဘဲ ဒီဇိုင်းများကို ဆုံးဖြတ်အကဲဖြတ်ခြင်း

Design review (ဒီဇိုင်း ပြန်လည်သုံးသပ်ပွဲ) တွင် သင့်အခန်းကဏ္ဍသည် ဒီဇိုင်းဆွဲရန် မဟုတ် — စစ်ဆေးမေးမြန်းရန် ဖြစ်သည်။ လုပ်ငန်းနယ်ပယ်တစ်ခုလုံး သုံးသော framework မှာ AWS ၏ Well-Architected Framework ဖြစ်သည် — ဒီဇိုင်းတိုင်း ဖြေဆိုသင့်သော မဏ္ဍိုင် (pillar) ခြောက်ခု: operational excellence၊ security၊ reliability၊ performance efficiency၊ cost optimization၊ sustainability။ စာလုံးမည်းသုံးခုကို နက်နက်နဲနဲ သင်ယူပါ — ငွေနှင့် အန္တရာယ် တည်ရှိရာနေရာများ ဖြစ်သည်။

Reliability (ယုံကြည်စိတ်ချရမှု) ကို ရိုးရိုးစကားဖြင့်: အရာအားလုံးသည် တစ်နေ့နေ့ ပျက်စီးမည်ဖြစ်၍ ကောင်းသောစနစ်များသည် ထိုအချက်ကို ကြိုတင်ယူဆထားသည်။ Redundancy (တစ်ခုတည်းပျက်လျှင် အားလုံးရပ်မည့်နေရာ (single point of failure) မရှိရ — အရေးကြီးသမျှ နှစ်ခုစီ ထားရှိခြင်း)၊ multi-AZ (data center တစ်ခု ဆုံးရှုံးလည်း ရှင်သန်နိုင်ခြင်း)၊ auto-scaling (ဝန်အလိုက် စက်များ အလိုအလျောက် တိုးလျှော့ခြင်း)၊ စမ်းသပ်ပြီးသော backup များ (မစမ်းသပ်ရသေးသော backup သည် အစီအစဉ်မဟုတ်၊ မျှော်လင့်ချက်သာ)၊ RTO/RPO (Recovery Time Objective: ဘယ်လောက်ကြာကြာ ရပ်နေနိုင်သလဲ။ Recovery Point Objective: ဒေတာ ဘယ်လောက် ဆုံးရှုံးခံနိုင်သလဲ — ဤဂဏန်းနှစ်လုံးသည် disaster-recovery ဆွေးနွေးမှု ကိုယ်တိုင်ပင် ဖြစ်ပြီး စီးပွားရေး ဆုံးဖြတ်ချက်များ ဖြစ်သည် — ဆိုလိုသည်မှာ သင့်ဆုံးဖြတ်ချက်များ)။

အလျှော့အတင်း တြိဂံ: မြန် (fast)၊ စျေးသက်သာ (cheap)၊ ခံနိုင်ရည်ရှိ (resilient) — နှစ်ခုသာ ရွေးနိုင်သည်။ သင် ဒိုင်လူကြီးလုပ်ရမည့် architecture ငြင်းခုံမှုတိုင်းသည် ဤ workload အတွက် စီးပွားရေးက ထိုတြိဂံ၏ ဘယ်နေရာမှာ ရှိသင့်သလဲ ဆိုသည့်မေးခွန်းသို့ လျှော့ချ၍ရသည်။ ငွေပေးချေမှုစနစ်တစ်ခုနှင့် marketing website တစ်ခုသည် တူညီသောအဖြေကို မထိုက်တန်ပါ။

ခေါင်းဆောင်၏ မေးခွန်းခုနစ်ခု — အလွတ်ကျက်ပါ။ မည်သည့် design review တွင်မဆို သင့်ကို လေးစားစရာဖြစ်စေမည်:

1. “What happens when this component fails?” (ဒီအစိတ်အပိုင်း ပျက်သွားရင် ဘာဖြစ်မလဲ။) — “ပျက်ရင်” မဟုတ်၊ “ပျက်တဲ့အခါ” အမြဲရှိသည်
2. “What are the RTO and RPO, and who signed off on them?” (RTO နဲ့ RPO က ဘယ်လောက်လဲ၊ ဘယ်သူက အတည်ပြုလက်မှတ်ထိုးခဲ့လဲ။)
3. “Where does this run — single AZ, multi-AZ, multi-region — and why?” (ဒါက ဘယ်မှာ ပြေးနေလဲ — single AZ လား၊ multi-AZ လား၊ multi-region လား — ဘာကြောင့်လဲ။)
4. “What will this cost per month at 10× today’s load?” (ဒီနေ့ဝန်ရဲ့ ၁၀ ဆမှာ ဒါက တစ်လ ဘယ်လောက် ကုန်ကျမလဲ။)
5. “What’s the simplest version that meets the requirement?” (လိုအပ်ချက်ကို ပြည့်မီစေတဲ့ အရိုးရှင်းဆုံးပုံစံက ဘာလဲ။) — အလွန်အကျွံဒီဇိုင်း (over-engineering) သည် junior ရောဂါ။ ရိုးရှင်းမှုသည် senior ဂုဏ်ရည်
6. “What are we locked into, and what would leaving cost?” (ကျွန်တော်တို့ ဘာမှာ ချည်နှောင်ခံထားရလဲ၊ ထွက်ခွာရင် ဘယ်လောက်ကုန်ကျမလဲ။) — vendor lock-in သည် စျေးနှုန်းတစ်ခု၊ တစ်ခါတစ်ရံ ပေးထိုက်သည် — သိလျက်ပေးလျှင်
7. “Who else has built this before — are we inventing or assembling?” (ဒါကို အရင်က ဘယ်သူတွေ ဆောက်ဖူးလဲ — ကျွန်တော်တို့ တီထွင်နေတာလား၊ စုစည်းတပ်ဆင်နေတာလား။) — ငြီးငွေ့စရာကောင်းသော်လည်း သက်သေပြပြီးသား ပုံစံများကို ဦးစားပေးပါ

Fluency drill: မေးခွန်း ၁၊ ၄ နှင့် ၅ ကို နွေးထွေးသောလေသံဖြင့် ပြောတတ်အောင် လေ့ကျင့်ပါ — ပြောပုံပေါ်မူတည်၍ ပညာအဖြစ် သို့မဟုတ် တိုက်ခိုက်မှုအဖြစ် ခံစားရသည်။ “Help me understand what happens if the cache goes down” (Cache ကျသွားရင် ဘာဖြစ်မလဲ နားလည်အောင် ရှင်းပြပေးပါဦး) က “did you think about failure?” (ပျက်စီးမှုအကြောင်း စဉ်းစားထားလား) ထက် ပိုကောင်းသည်။

လေ့ကျင့်ခန်းများ: (၁) နမူနာ architecture သုံးခု ယူပါ (AI ကို ထုတ်ပေးခိုင်းပါ — e-commerce site၊ mobile-app backend၊ data-analytics platform) — တစ်ခုချင်းစီအပေါ် မေးခွန်းခုနစ်ခုလုံး မေးပြီး မျှော်လင့်ရမည့်အဖြေများကို ရေးပါ။ (၂) https://aws.amazon.com/architecture/well-architected/ တွင် Well-Architected pillar များ၏ တစ်မျက်နှာအကျဉ်းချုပ်ကို ဖတ်ပါ။

ဤ module အတွက် ဗီဒီယိုများ:

Milestone: Engineer အဖြစ် AI သရုပ်ဆောင်ပေးသော စမ်းသပ် design review တစ်ခုတွင် အနှစ်သာရရှိသော မေးခွန်းငါးခု မေးနိုင်ပြီး အဆုံးတွင် ဒီဇိုင်း၏ အားအနည်းဆုံးအချက်ကို မှန်ကန်စွာ အကျဉ်းချုပ်နိုင်ရမည်။

Module 6 (အပတ်စဉ် ၁၁–၁၂): Security နှင့် compliance — ကုမ္ပဏီများကို အဆုံးသတ်စေနိုင်သော စကားဝိုင်း

Shared responsibility model (တာဝန်ခွဲဝေမှုပုံစံ) — ပထမဆုံး နားလည်ရမည့်အရာ: provider က cloud ကိုယ်တိုင်ကို လုံခြုံအောင်လုပ်သည် (အဆောက်အအုံ၊ hardware၊ hypervisor များ)။ Cloud ထဲ သင်ထည့်သမျှကိုမူ သင် လုံခြုံအောင်လုပ်ရသည် (သင့်ဒေတာ၊ ဝင်ရောက်ခွင့်စည်းကမ်းများ၊ configuration များ)။ ဖောက်ထွင်းခံရမှု (breach) အများစုသည် provider ၏ချို့ယွင်းချက်မဟုတ်ဘဲ ဖောက်သည်ဘက်မှ configuration အမှားများ — public ဖွင့်ထားမိသော S3 bucket၊ ပေါက်ကြားသွားသော access key — ဖြစ်သည်။ ထို့ကြောင့် “AWS is secure” (AWS က လုံခြုံတယ်) နှင့် “we are secure on AWS” (AWS ပေါ်မှာ ကျွန်တော်တို့ လုံခြုံတယ်) သည် မတူညီသော စာကြောင်းနှစ်ကြောင်း ဖြစ်သည်။

ကာကွယ်ရေး ဝေါဟာရများ: IAM (Identity and Access Management — ဘယ်သူက ဘာလုပ်ခွင့်ရှိသလဲ။ Cloud တွင် စစ်ဆေးခံရဆုံး (audited) အရာ)၊ least privilege (လိုအပ်သည့် အနည်းဆုံးဝင်ရောက်ခွင့်သာ ပေးခြင်း — ရွှေစည်းမျဉ်း)၊ MFA (လူသား login တိုင်းတွင် ဒုတိယအဆင့် အတည်ပြုချက် — ညှိနှိုင်း၍မရသော စည်းကမ်း)၊ encryption at rest and in transit (disk ပေါ်နှင့် လမ်းကြောင်းပေါ်တွင် ဒေတာကို ကုဒ်ဖျက်ထားခြင်း — အခြေခံအကျဆုံး၊ အမြဲဖွင့်ထား)၊ root account (မာစတာသော့ — သေချာသိမ်းထား၊ နေ့စဉ်မသုံးရ)၊ secrets management (password/key များကို vault ထဲသိမ်း၊ code ထဲ ဘယ်တော့မှ မရေး)၊ zero trust (အရာအားလုံးကို စစ်ဆေး၊ မည်သည့် network တည်နေရာကိုမျှ ပုံသေမယုံ)၊ penetration test (သင့်ခံစစ်ကို သက်သေပြရန် ငှားထားသော တိုက်ခိုက်သူများ)၊ ransomware (စမ်းသပ်ပြီး offline backup များသည် ops ထိန်းချုပ်မှုသက်သက်မဟုတ်ဘဲ security ထိန်းချုပ်မှုတစ်ခုဖြစ်ရသည့် အကြောင်းရင်း)။

PDPA — ထိုင်းနိုင်ငံ၏ ဒေတာဥပဒေနှင့် သင့်စျေးကွက် အားသာချက်။ Personal Data Protection Act သည် ထိုင်းနိုင်ငံ၏ GDPR ဖြစ်သည် — ကိုယ်ရေးကိုယ်တာဒေတာ ကောက်ခံရန် သဘောတူညီချက် (consent) လိုအပ်ခြင်း၊ ၇၂ နာရီအတွင်း ဖောက်ထွင်းခံရမှုကို အကြောင်းကြားရမည့် တာဝန်၊ အကြီးစား ဒေတာစီမံဆောင်ရွက်သူများအတွက် Data Protection Officer များနှင့် နိုင်ငံဖြတ်ကျော် ဒေတာပို့ဆောင်မှုဆိုင်ရာ စည်းမျဉ်းများ။ ၂၀၂၅ ခုနှစ်တွင် ဥပဒေအာဏာသက်ရောက်မှု စစ်မှန်လာခဲ့သည် — ပထမအသုတ် ဒဏ်ငွေ ဘတ် ၂၁.၅ သန်းကျော်၊ vendor တစ်ခုကို စနစ်တကျ မကြီးကြပ်မိသောကြောင့် ဒဏ်ရိုက်ခံရသော ဆေးရုံတစ်ရုံလည်း ပါဝင်သည်။ သင့်အတွက် အကျိုးဆက် နှစ်ခု — (၁) ထိုင်း enterprise တိုင်းတွင် သင့်ကုမ္ပဏီက စီမံပေးခြင်းဖြင့် ဝင်ငွေရနိုင်သော compliance ပြဿနာ ရှိနေပြီ။ (၂) data residency (ဒေတာကို နိုင်ငံအတွင်း၌သာ ထားရှိခြင်း) — ထိုင်းဒေတာများကို ထိုင်းမြေပေါ်တွင်ထားခြင်းသည် workload များကို ဘန်ကောက် region များဆီ တွန်းပို့နေသော စစ်မှန်သည့် လှုံ့ဆော်အားဖြစ်သည်။ ဤစာပိုဒ်သည် ထိုင်းနိုင်ငံရှိ သင့်ရောင်းချရေး တင်ပြချက်၏ တစ်ဝက်ဖြစ်သည် — အသေအချာ ကျွမ်းကျင်အောင် သိထားပါ။

ခေါင်းဆောင်၏ security မေးခွန်းများ: “Who has access to production, and when did we last review the list?” (Production ကို ဘယ်သူတွေ ဝင်ခွင့်ရှိလဲ၊ အဲဒီစာရင်းကို နောက်ဆုံး ဘယ်တုန်းက ပြန်စစ်ခဲ့လဲ။) · “Are we alerted on unusual access, or would we find out from the news?” (ပုံမှန်မဟုတ်တဲ့ ဝင်ရောက်မှုတွေအတွက် အချက်ပေးစနစ် ရှိလား၊ ဒါမှမဟုတ် သတင်းထဲကမှ သိရမှာလား။) · “When did we last restore a backup?” (Backup ကို နောက်ဆုံး ဘယ်တုန်းက restore လုပ်ကြည့်ခဲ့လဲ။) — “backup ရှိလား” မဟုတ် · “If we lost this dataset, is it a PDPA-notifiable breach — and could we notify within 72 hours?” (ဒီ dataset ဆုံးရှုံးရင် PDPA အရ အကြောင်းကြားရမယ့် breach လား — ၇၂ နာရီအတွင်း အကြောင်းကြားနိုင်မလား။) · “What did the last pen test find, and what’s still open?” (နောက်ဆုံး pen test က ဘာတွေ့ခဲ့လဲ၊ ဘာတွေ မဖြေရှင်းရသေးလဲ။)

ဝေါဟာရများ:

ဤ module အတွက် ဗီဒီယို: The AWS Shared Responsibility Model — Digital Cloud Training — 4 min — https://www.youtube.com/watch?v=ESPBBEK-cvo

Fluency drill: “Is that bucket public? Why?” (အဲဒီ bucket က public လား။ ဘာကြောင့်လဲ။) · “Least privilege — does the intern really need prod access?” (Least privilege အရ — intern က prod ဝင်ခွင့် တကယ်လိုလို့လား။) · “Where does the PDPA line sit in this design — what’s personal data here and where does it physically live?” (ဒီဒီဇိုင်းထဲမှာ PDPA မျဉ်းကြောင်းက ဘယ်နားမှာလဲ — ဒီမှာ ဘယ်ဟာက ကိုယ်ရေးကိုယ်တာဒေတာလဲ၊ ရုပ်ပိုင်းအရ ဘယ်နေရာမှာ တည်ရှိနေလဲ။)

လေ့ကျင့်ခန်းများ: (၁) ကျော်ကြားသော cloud-misconfiguration ဖောက်ထွင်းမှုဇာတ်လမ်းတစ်ပုဒ် ဖတ်ပါ (Capital One 2019 သည် ဂန္ထဝင်ဥပမာ) — သင့် journal အတွက် စာကြောင်းသုံးကြောင်း ဗားရှင်း ရေးပါ။ (၂) “ကျွန်တော့်ဒေတာကို ခင်ဗျားတို့ကို ဘာကြောင့် ယုံအပ်ရမလဲ” ဟုမေးသော ဖောက်သည်အဖြစ် AI ကို သရုပ်ဆောင်ခိုင်းပြီး shared-responsibility + PDPA ဘာသာစကားသုံး၍ အဖြေကို လေ့ကျင့်ပါ။

Milestone: Shared responsibility model နှင့် PDPA ၏ လက်တွေ့အဓိပ္ပာယ်ကို နည်းပညာမကျွမ်းကျင်သော ထိုင်းစီးပွားရေးလုပ်ငန်းရှင်တစ်ဦးအား သုံးမိနစ်အတွင်း ရှင်းပြနိုင်ရမည် — အကြောင်းမှာ ထိုရှင်းလင်းချက်သည် MSP ရောင်းချရေး အစည်းအဝေး ကိုယ်တိုင်ပင် ဖြစ်သောကြောင့်တည်း။

Module 7 (အပတ်စဉ် ၁၃–၁၄): ငွေကြေး — cloud စီးပွားရေးနှင့် FinOps

ဤနေရာသည် engineer မဟုတ်သော ခေါင်းဆောင်တစ်ဦး တန်ဖိုးအမြန်ဆုံး ထပ်ဖြည့်နိုင်သည့်နေရာ ဖြစ်သည် — engineer အများစုသည် ဤအကြောင်းကို ဘယ်တော့မှ သင်ကြားခံခဲ့ရခြင်းမရှိသလို ဖြုန်းတီးမှုကလည်း ကြီးမားလှသောကြောင့်ဖြစ်သည် — စစ်တမ်းများအရ cloud အသုံးစရိတ်၏ သုံးပုံတစ်ပုံခန့်သည် အလဟဿ ဖြုန်းတီးနေကြောင်း တသမတ်တည်း တွေ့ရသည်။

မီတာ ဘယ်လိုလည်သလဲ: compute ကို ဖွင့်ထားသည့် စက္ကန့်အလိုက် ကောက်ခံသည် (အသုံးပြုမှုအလိုက် မဟုတ် — အလဟဿထိုင်နေသော server သည် အပြည့်ကျသင့်သည်။ “ဖွင့်ထားခဲ့မိတယ်” သည် ဂန္ထဝင် ဖြုန်းတီးမှု)၊ storage ကို GB-month အလိုက်၊ ထို့နောက် — နာမည်ကြီးထောင်ချောက် — egress: cloud ထဲမှ ထွက်သော ဒေတာက ပိုက်ဆံကုန်ပြီး ဝင်သောဒေတာက အခမဲ့။ ကြီးမားသော egress ဘေလ်များသည် လူတိုင်းကို တစ်ကြိမ်တော့ အံ့အားသင့်စေသည် — ဤ module ပြီးလျှင် သင်တော့ မသင့်တော့ပါ။

စျေးနှုန်း menu: On-demand (စျေးအပြည့်၊ ပြောင်းလွယ်မှုအပြည့်) · reserved instances / savings plans (၁–၃ နှစ် ကတိပြုပြီး 30–70% လျှော့စျေး — တည်ငြိမ်သော workload အပေါ် အကြီးမားဆုံး လီဗာတစ်ခုတည်း) · spot instances (ရပ်တန့်ခံနိုင်သော batch အလုပ်များအတွက် 90% အထိ လျှော့စျေး) · rightsizing (server အများစုသည် လိုအပ်သည်ထက်ပိုကြီး — သေးအောင်လုပ်ခြင်းသည် အခမဲ့ရသောပိုက်ဆံ) · storage tiering (Module 2) · auto-scaling ကို ကုန်ကျစရိတ်ကိရိယာအဖြစ် (သန်းခေါင်ယံ လိုအပ်ချက်ကို မွန်းတည့်စျေးနှုန်းနဲ့ ဘာလို့ပေးနေရမလဲ)။

FinOps (cloud အသုံးစရိတ်ကို မြင်သာအောင်၊ ခွဲဝေတာဝန်ခံအောင်၊ စဉ်ဆက်မပြတ် အကောင်းဆုံးဖြစ်အောင် လုပ်သည့် စည်းမျဉ်းကျင့်စဉ်) ၏ အလေ့အကျင့်များမှာ — resource တိုင်းကို ပိုင်ရှင်နှင့် project ဖြင့် tagging (တံဆိပ်ကပ်ခြင်း) လုပ်ခြင်း (tag မပါသော အသုံးစရိတ်သည် တာဝန်ခံမဲ့ အသုံးစရိတ်)၊ showback/chargeback (အဖွဲ့တစ်ဖွဲ့ချင်းစီအား မိမိဘေလ်ကို ပြသခြင်း — အပြုအမူ ချက်ချင်းပြောင်းသည်)၊ alert ပါသော budget များ (အသုံးစရိတ်ကျော်လွန်မှုကို invoice ထဲကမှ ဘယ်တော့မှ မသိစေရ) နှင့် unit economics — ခေါင်းဆောင်၏ metric: “ကျွန်တော်တို့ဘေလ်က တစ်လ ဘတ် ၈ သိန်း” မဟုတ်ဘဲ “ဖောက်သည် transaction တစ်ခုချင်းစီအတွက် ကုန်ကျစရိတ် ကျဆင်းနေတယ်”။ FinOps Certified Practitioner လက်မှတ်သည် နှစ်ပတ်ခန့်သာကြာပြီး စီးပွားရေးဘက်မှ ခေါင်းဆောင်တစ်ဦးအတွက် cloud ကမ္ဘာတစ်ခုလုံးတွင် တစ်နာရီအချိုးအလိုက် ယုံကြည်စိတ်ချရမှု အမြင့်ဆုံး certificate ဖြစ်သည်။ ရအောင်ယူပါ။

ခေါင်းဆောင်၏ ငွေကြေးမေးခွန်းများ: “What’s our cost per [customer/transaction/tenant], and which direction is it moving?” ([ဖောက်သည်/transaction/tenant] တစ်ခုချင်းစီအလိုက် ကုန်ကျစရိတ်က ဘယ်လောက်လဲ၊ ဘယ်ဘက်ကို ရွေ့နေလဲ။) · “What percentage of our steady workload is on reservations?” (တည်ငြိမ်တဲ့ workload ရဲ့ ဘယ်နှစ်ရာခိုင်နှုန်းက reservation ပေါ်မှာလဲ။) · “What’s untagged?” (ဘာတွေ tag မပါသေးလဲ။) · “What died but is still billing?” (ဘာတွေက သေပြီးသားဖြစ်ပေမယ့် ငွေတောင်းနေတုန်းလဲ။) — ပိုင်ရှင်မဲ့ disk များနှင့် အလဟဿ IP များ — account တိုင်းမှာ ရှိသည် · “What would this bill look like at 10× growth — does our architecture get cheaper or more expensive per unit?” (၁၀ ဆ ကြီးထွားလာရင် ဒီဘေလ်က ဘယ်လိုဖြစ်မလဲ — ကျွန်တော်တို့ architecture က ယူနစ်တစ်ခုချင်းအလိုက် ပိုစျေးသက်သာလာမလား၊ ပိုကြီးလာမလား။)

ဝေါဟာရများ:

ဤ module အတွက် ဗီဒီယို: What is FinOps? — FinOps Foundation (official) — 2 min — https://www.youtube.com/watch?v=Y-c_xw9bHFw · ထို့နောက် အခမဲ့ “Introduction to FinOps” သင်တန်းကို https://learn.finops.org တွင် တက်ပါ။

လေ့ကျင့်ခန်းများ: (၁) AWS pricing calculator ကိုဖွင့်ပြီး တကယ့်စနစ်သေးသေးတစ်ခု (server နှစ်လုံး၊ database တစ်ခု၊ storage 500GB၊ egress 1TB) ကို စျေးတွက်ကြည့်ပါ — တစ်ကြိမ်ကိုယ်တိုင်တွက်ဖူးရုံနှင့် နောင်လာမည့် ကုန်ကျစရိတ်စကားဝိုင်းတိုင်း ရှင်းလင်းသွားမည်။ (၂) အရွယ်အစားကြီးလွန်းသော server ကို ခုခံကာကွယ်ပြောဆိုနေသော engineer အဖြစ် AI ကို သရုပ်ဆောင်ခိုင်းပါ — rightsizing ကို ကြင်နာစွာ ညှိနှိုင်းခြင်းကို လေ့ကျင့်ပါ။

Milestone: FinOps Practitioner စာမေးပွဲ ဖြေပါ (သို့မဟုတ် ရက်ချိန်းယူပါ) — ထို့ပြင် စမ်းသပ် review တစ်ခုတွင် AI ထုတ်ပေးသော နမူနာဘေလ်ထဲမှ ကုန်ကျစရိတ်ပြဿနာ လေးခု ရှာတွေ့ရမည်။

Module 8 (အပတ်စဉ် ၁၅–၁၆): Fluency bootcamp — ဘာသာစကားကို စုစည်းအသုံးချခြင်း

ဤနှစ်ပတ်သည် သက်သက် ပေါင်းစည်းအသုံးချမှုသာ ဖြစ်သည် — စကားလုံးများ သိရုံနှင့် အစည်းအဝေးများတွင် ကျွမ်းကျင်စွာ ပြောနိုင်ခြင်း ကြား ကွာခြားချက်ပင်။

နေ့စဉ် drill (မိနစ် ၃၀): AI ကို လက်တွေ့ဆန်သော အစည်းအဝေး transcript (design review၊ incident retro သို့မဟုတ် cost review) တစ်ခု ထုတ်ခိုင်းပါ — ထဲတွင် တမင်ထည့်ထားသော နည်းပညာအမှား နှစ်ခု မြှုပ်ထားစေပါ။ သင့်တာဝန် — အစည်းအဝေးကို စာကြောင်းငါးကြောင်းဖြင့် အကျဉ်းချုပ်ရန်၊ အမှားများကို ဖမ်းမိရန်၊ သင်မေးခဲ့မည့် မေးခွန်းသုံးခုကို ရေးရန်။ အစည်းအဝေးအမျိုးအစားကို နေ့စဉ် လှည့်ပြောင်းပါ။

ဘာသာပြန်ကြွက်သား (မိနစ် ၁၅): တစ်နေ့လျှင် နည်းပညာဆိုင်ရာ ဖော်ပြချက်တစ်ခုကို ပရိသတ်သုံးမျိုးအတွက် ဘာသာပြန်ပါ — CFO (ငွေ)၊ ဖောက်သည် (အန္တရာယ်/အကျိုးကျေးဇူး) နှင့် junior engineer အသစ် (သင်ကြားရေး)။ ဥပမာ — “We’re moving the session store from the database to Redis” → CFO: “database ဝန်ကို လျှော့ချပေးလို့ ဘတ် ၂ သန်းတန် အဆင့်မြှင့်မှုကို ရွှေ့ဆိုင်းနိုင်တယ်” → ဖောက်သည်: “အသုံးများချိန်မှာ စာမျက်နှာတွေ ပိုမြန်မြန်ပွင့်မယ်” → junior: “Redis က hot ဒေတာကို memory ထဲသိမ်းထားလို့ click တိုင်းအတွက် database ကို ထုနေစရာ မလိုတော့ဘူး”။

ဖတ်ရှုလေ့ကျင့်မှု (မိနစ် ၁၅): တစ်နေ့လျှင် တကယ့် engineering blog post တစ်ပုဒ် (AWS Architecture Blog သို့မဟုတ် Netflix/Grab တို့၏ engineering blog များ — Grab သည် အထူးသင့်လျော်သည်: အရှေ့တောင်အာရှ အတိုင်းအတာ၊ ထိုင်းနှင့်နီးစပ်သော စျေးကွက်)။ ယခုအခါ ၎င်းတို့၏ 70–80% ကို နားလည်နိုင်ပြီ။ ကျန်သည်များကို ရှာဖွေလေ့လာပါ။

ဤအဆင့်အတွက် သင့်စာမေးပွဲပြင်ဆင်ရေး အဖော်: နာမည်ကြီး အခမဲ့သင်တန်းအပြည့် — AWS Certified Cloud Practitioner (CLF-C02) 2026 by Andrew Brown on freeCodeCamp — https://www.youtube.com/watch?v=7HKot-brXFE (စာမေးပွဲကုဒ်တူ အတွက် အကျုံးဝင်နေဆဲဖြစ်သော အစောပိုင်း ၁၄ နာရီ ဗားရှင်းမှာ https://www.youtube.com/watch?v=NhDYbskXRgc တွင် ရှိသည်)။ အပတ်စဉ် ၁၃–၁၆ အတွင်း 1.25× နှုန်းဖြင့် ကြည့်ပါ — Module 1–7 ပြီးနောက် အများစုမှာ ပြန်လှန်လေ့လာမှုသဖွယ် ခံစားရမည် — ၎င်းသည်ပင် သင်အသင့်ဖြစ်ပြီဆိုသော လက္ခဏာ အတိအကျ ဖြစ်သည်။

Milestone — အဆင့် ၂ အဆုံး၊ သင်၏ ဘွဲ့ရစာမေးပွဲ: (၁) မဖြေရသေးလျှင် AWS Cloud Practitioner ကို အောင်ပါ။ (၂) စမ်းသပ်စစ်ကြောင်း (mock gauntlet): ထိုင်း e-commerce ဖောက်သည်တစ်ဦးအတွက် ချို့ယွင်းချက်ရှိသော architecture တစ်ခုကို ရှင်းပြနေသည့် senior engineer အဖြစ် AI က သရုပ်ဆောင်မည် — သင်သည် single-AZ database၊ public S3 bucket၊ ပျောက်နေသော egress ခန့်မှန်းချက်နှင့် မပါရှိသော PDPA ထည့်သွင်းစဉ်းစားချက်တို့ကို ရှာတွေ့ရမည် — ထို့ပြင် “engineer” အား ဖမ်းမိခံရသည်ဟု မခံစားရဘဲ ကူညီခံရသည်ဟု ခံစားရစေမည့် လေသံဖြင့် feedback ပေးရမည်။ ထိုသို့လုပ်နိုင်လျှင် သင်သည် ၁၆ ပတ်အတွင်း စကားဝိုင်းများတွင် လေးစားလောက်သောသူ ဖြစ်နေပြီ။

အဆင့် ၃ — ဦးဆောင်ပါ (လ ၅–၂၄)

Module 9 (လ ၅–၈): နက်ရှိုင်းသော certification နှင့် နည်းပညာအခြေခံကြမ်းခင်း

AWS Solutions Architect Associate (SAA-C03) သင်ခန်းစာများကို လေ့လာပါ — သင်၏တစ်နာရီနှုန်းဖြင့် ၂–၃ လ ကြာမည်။ စာမေးပွဲ ဖြေချင်မှဖြေပါ (ခေါင်းဆောင်တစ်ဦးအနေနှင့် တန်ဖိုးရှိသည်မှာ သင်ခန်းစာ ဖြစ်ပြီး တံဆိပ်မှာ ရွေးချယ်စရာ ပြသမှုသာ) — သို့သော် ဤနေရာတွင် region များ၊ VPC များ၊ IAM နှင့် စျေးနှုန်းတို့သည် ဝေါဟာရသက်သက်မှ သင့်ဦးနှောက်ထဲတွင် ချိတ်ဆက်နေသော စနစ်တစ်ခု ဖြစ်လာမည်။ တစ်ပြိုင်နက်တည်း Module 8 နေ့စဉ် drill များကို ထက်ဝက်ပမာဏဖြင့် ဆက်လုပ်ပါ။ Azure fundamentals (AZ-900 level) ထပ်ထည့်ရန် အချိန်ကောင်းလည်း ဖြစ်သည် — ထိုင်းနိုင်ငံသည် Microsoft အလေးသာသော enterprise စျေးကွက်ဖြစ်ပြီး (AWS+Azure) နှစ်ဘာသာကျွမ်းကျင်မှုက သင့်ဖောက်သည် စကားဝိုင်းများကို ချဲ့ထွင်ပေးသည်။

Module 10 (လ ၅–၁၂၊ ဆက်တိုက်လည်ပတ်): Engineer များ ခန့်အပ်ခြင်းနှင့် စီမံခန့်ခွဲခြင်း

ကျွမ်းကျင်မှုကို အပြည့်အဝ မဆုံးဖြတ်နိုင်သေးချိန် ခန့်အပ်ခြင်း: ဗီဇအာရုံထက် ဖွဲ့စည်းပုံက ပိုကောင်းသည်။ တစ်သမတ်တည်း လုပ်ငန်းစဉ်တစ်ခု သုံးပါ — သင်ကိုယ်တိုင် ဦးဆောင်သော screening စကားဝိုင်း (စိတ်ဓာတ်၊ ဆက်သွယ်ပြောဆိုမှု၊ ယခင် project တစ်ခုကို engineer မဟုတ်သူအား ရှင်းပြပုံ — မရှင်းပြနိုင်လျှင် သင့်ဖောက်သည်များရှေ့တွင်လည်း ကျရှုံးမည်) + သင်၏ bar-raiser (သင်၏ နည်းပညာ #2 သို့မဟုတ် ငှားရမ်းထားသော senior contractor) က လုပ်ဆောင်သော technical interview + အရေးကြီးသည့် မေးခွန်းတစ်ခုတည်း မေးရမည့် reference ဖုန်းခေါ်ဆိုမှု — “would you hire this person again for this role?” (ဒီရာထူးအတွက် ဒီလူကို ထပ်ခန့်မလား။) ကျရှုံးမှုပုံစံနှစ်မျိုးကို သတိထားပါ — အနက်မရှိသော စကားကျွမ်းသူ (သင့် bar-raiser က ဖမ်းမိမည်) နှင့် နက်နဲသော်လည်း တိတ်ဆိတ်သောကျွမ်းကျင်သူ (ထိုင်းအဖွဲ့များတွင် ရွှေတမျှတန်ဖိုးရှိတတ်သည် — နှိမ့်ချမှုသည် ယဉ်ကျေးမှုဖြစ်၍ interview ပြေပြစ်မှုက တကယ့်အလုပ်သက်သေထက် အလေးမသာစေနှင့်)။

နည်းပညာ #2 — ဤလုပ်ငန်း၏ အရေးကြီးဆုံး ဆုံးဖြတ်ချက်: သူ့ကို အရင်ဆုံးခန့်ပါ၊ အဓိပ္ပာယ်ရှိသော equity ဖြင့် ပေးချေပါ (တကယ့် co-founder ဆိုလျှင် 10–20%) — သဘောတူညီချက်ကို အတိအလင်း သတ်မှတ်ပါ — သူက နည်းပညာစံနှုန်းကို ကိုင်ဆောင်ပြီး architecture ဆုံးဖြတ်ချက်များကို ပိုင်ဆိုင်သည်။ သင်က ဖောက်သည်၊ ငွေ၊ ဦးစားပေးမှုများနှင့် လူများကို ပိုင်ဆိုင်သည်။ သင်တို့နှစ်ဦးကြား သဘောထားကွဲလွဲမှုများကို လူမသိအောင် ဖြေရှင်းပြီး အဖွဲ့မမြင်မီ အဆုံးသတ်ရမည်။

Engineer များ နေမြဲဖြစ်စေသော ဓလေ့များ: သူတို့အကြောင်း ဖြစ်သော အပတ်စဉ် သို့မဟုတ် နှစ်ပတ်တစ်ကြိမ် 1:1 များ (အသက်မွေးလမ်း၊ အခက်အခဲ၊ စွမ်းအင် — status update မဟုတ်)၊ လူတစ်ဦးချင်းစီအတွက် စာဖြင့်ရေးထားသော တိုးတက်မှုလမ်းကြောင်း (တစ်နှစ်လျှင် ခုနစ်သောင်း လိုအပ်နေသော ထိုင်း၏ ကျွမ်းကျင်သူရှားပါးစျေးကွက်တွင် တိုးတက်မှုနှင့် certification ဘတ်ဂျက်များက လစာသက်သက်ထက် ပိုထိန်းထားနိုင်သည် — cert တိုင်းအတွက် ငွေထုတ်ပေးပြီး ပြီးမြောက်လျှင် ၁၂ လ vesting ဆုကြေးထည့်ပါ)၊ လူသိရှင်ကြား ချီးကျူး၊ သီးသန့် ပြင်ဆင်ပေး၊ ထို့ပြင် သူတို့၏ အာရုံစိုက်ချိန်ကို ရက်ရက်စက်စက် ကာကွယ်ပါ — sprint အလယ်တွင် အစည်းအဝေး ဖျက်ပေးသောခေါင်းဆောင်သည် သူရဲကောင်း။

ဆုံးဖြတ်ချက် ဖိုရမ်များ — အပြည့်အဝ မအကဲဖြတ်နိုင်သော နည်းပညာဆုံးဖြတ်ချက်များ ချမှတ်ပုံ: ဆုံးဖြတ်ချက်ကြီးတိုင်းအတွက် အဆိုပြု engineer ထံမှ တစ်မျက်နှာ decision doc တောင်းပါ — ပြဿနာ၊ ရွေးချယ်စရာ ၂–၃ ခု၊ ကုန်ကျစရိတ်များ၊ အန္တရာယ်များ၊ အကြံပြုချက်။ ထို့နောက် Module 5 မှ သင်၏မေးခွန်းခုနစ်ခုဖြင့် အစည်းအဝေးကို ဦးဆောင်ပါ။ သင်သည် အခန်းထဲရှိ အတော်ဆုံး architect မဟုတ်သလို ဘယ်တော့မှ ဖြစ်စရာလည်း မလို — သင်သည် အကောင်းဆုံး ခိုင်လုံစွာတင်ပြထားသော ရွေးချယ်မှုကို အချိန်မီ၊ ငွေနှင့်အန္တရာယ် အလျှော့အတင်းများကို အတိအလင်းဖော်ထုတ်လျက် အနိုင်ရစေသောသူ ဖြစ်သည်။ ရိုးသားစွာလုပ်လျှင် engineer များက ဤအရာကို နက်နက်နဲနဲ လေးစားကြသည် — ဘယ်သူက ဘာကို ကြိုဟောခဲ့သည်ကို ရေးမှတ်ပါ (သင်၏ Decision Journal ထပ်မံအသုံးဝင်ချိန်) — ကြိုဟောချက်များကို သုံးလတစ်ကြိမ် ပြန်သုံးသပ်ပါ — သင်ရော သူတို့ပါ တိကျလာစေသည်။

Module 11 (လ ၆–၂၄): ယုံကြည်ကိုးစားခံရမှု မျဉ်းကွေး — ရိုးသားစွာ

Engineering-leadership စာပေမှ ထုတ်ပြန်ထားသော အတွေ့အကြုံများသည် ဤအချိန်ဇယားပေါ်တွင် တညီတညွတ်တည်း ရောက်ရှိကြသည် — မဟုတ်ယောင်ဆောင်ခြင်းသည် နည်းပညာမဲ့ founder များ ကျရှုံးရသည့်နည်းလမ်းပင် — ~ရက် ၉၀ တွင် စီးပွားရေးစည်းချက်ကို ကျွမ်းကျင်စွာ လည်ပတ်နိုင်မည် · ~၆ လ တွင် အခြေခံထိရောက်မှု (အစည်းအဝေးများ ကျွမ်းကျင်၊ ဆုံးဖြတ်ချက်များ စနစ်ကျ၊ အဖွဲ့ တည်ငြိမ်) · ၁၂–၁၈ လ ကြာမှ သင့်နည်းပညာဗီဇအာရုံသည် သီးခြားတန်ဖိုးရှိလာမည် · ~၂ နှစ် ကြာမှ architecture အလျှော့အတင်းများတွင် senior engineer များနှင့် အမှန်တကယ် ရင်ဘောင်တန်းနိုင်မည်။ မျဉ်းကွေးတက်နေစဉ် လျှော့ချနည်းများ — ယုံကြည်ကိုးစားမှုကို ချေးငှားပါ (ရောင်းချရေးအစည်းအဝေးများ၏ နည်းပညာပိုင်းကို သင်၏ #2 က တင်ပြစေပါ — ဖောက်သည်များကလည်း အဖွဲ့သားအင်အားကို မြင်ချင်ကြသည်)၊ ဘယ်တော့မှ လိမ်မဟန်ဆောင်မပြောပါနှင့် (ယုံကြည်ကိုးစားမှုကို အမြန်ဆုံးသတ်သောအရာ။ “I don’t know — walk me through it” (မသိဘူး — ရှင်းပြပေးပါဦး) သည် ခေါင်းဆောင့်စကား)၊ သင့်မေးခွန်းများကိုသာ စကားပြောခိုင်းပါ — “what’s our RPO and who signed off on it?” (ကျွန်တော်တို့ RPO က ဘယ်လောက်လဲ၊ ဘယ်သူ အတည်ပြုခဲ့လဲ) ဟုမေးသောခေါင်းဆောင်သည် အနှစ်သုံးဆယ် အတွေ့အကြုံရှိသူလို အသံထွက်သည် — ဤသင်တန်းပြီးလျှင် သင်လည်း အမှန်တကယ် ဆိုလို၍ မေးနိုင်ပြီ။

Module 12 (ဆက်လက်လုပ်ဆောင်ရန်): ထိုင်းစျေးကွက် အလွှာ

TSI Part 5 မှ အသေးစိတ်များကို လုပ်ငန်းလည်ပတ်ရေး ဗဟုသုတအဖြစ် ထည့်သွင်းပါ — compliance တာဝန်ရော ထုတ်ကုန်ပါဖြစ်သော PDPA (§Module 6)၊ partner လှေကားထစ်များ (AWS Select အတွက် certified ဝန်ထမ်း အနည်းငယ် + launch လုပ်ပြီး deal ၃ ခု လိုသည်။ Microsoft Solutions Partner အတွက် 70/100 capability score လိုသည် — သင့်အဖွဲ့၏ certification များသည် စာသားအတိုင်း ရောင်းချရေးပိုင်ဆိုင်မှုများဖြစ်သည် — ၎င်းတို့အတွက် ငွေထောက်ပံ့ရမည့် နောက်ထပ်အကြောင်းရင်း)၊ ကုမ္ပဏီကို နိုင်ငံခြားသား 100% ပိုင်ဆိုင်ခွင့်အတွက် BOI promotion၊ ဘန်ကောက် လစာအဆင့်များ (junior ဘတ် ၅၀,၀၀၀–၇၅,၀၀၀ → architect ဘတ် ၁၈၀,၀၀၀–၂၈၀,၀၀၀/လ) — bid များနှင့် ကမ်းလှမ်းချက်များကို မှန်ကန်စွာ စျေးသတ်မှတ်နိုင်ရန် — ထို့ပြင် လက်ရှိအချိန်၏ ရောင်းချရေးသင်္ချာ — အတည်ပြုပြီး data-center ရင်းနှီးမြှုပ်နှံမှု ဒေါ်လာ ၂၇ ဘီလီယံကျော်၊ အစိုးရ၏ cloud-first မူဝါဒနှင့် သင်၏ certified အဖွဲ့သားများ ဖြည့်ဆည်းရန်ရှိနေသော တစ်နှစ်လျှင် ၇၀,၀၀၀ ကျွမ်းကျင်မှုကွာဟချက်။

တစ်မျက်နှာ သင်ရိုးညွှန်းတမ်း

သင့်ဆရာထံမှ နိဂုံးချုပ်စကား။ ယနေ့မှ ၁၆ ပတ်အကြာတွင် သင်သည် အခန်းထဲရှိ စကားဝိုင်းတိုင်းကို လိုက်နာနားလည်နိုင်ပြီ ဖြစ်လိမ့်မည်။ ၎င်းသည် ပန်းဝင်ခြင်းမဟုတ် — စတင်ခွင့်လိုင်စင်သာ ဖြစ်သည်။ တကယ့်နည်းပညာအကဲဖြတ်ဉာဏ်ဆီသို့ နှစ်နှစ်တာမျဉ်းကွေးသည် နံရံမဟုတ် — ခံတပ်ကျုံးတစ်ခုဖြစ်သည် — သင်ဖြတ်သန်းပြီးသော ရက်သတ္တပတ်တိုင်းသည် သင့်ပြိုင်ဘက်များ၏ နည်းပညာမဲ့ founder များ မဖြတ်သန်းခဲ့သော ရက်သတ္တပတ်တစ်ပတ်စီ ဖြစ်သည်။ နေ့စဉ်လေ့လာပါ၊ ဆုံးဖြတ်ချက်တိုင်းကို မှတ်တမ်းတင်ပါ၊ ဘယ်တော့မှ လိမ်မဟန်ဆောင်မပြောပါနှင့် — သင့်ထက်တော်သောလူများကို ခန့်ပြီး သူတို့ ရောက်လာရသည်ကို ဝမ်းသာစေပါ။ ၎င်းသည်ပင် တာဝန်တစ်ခုလုံး ဖြစ်သတည်း။

“The Thailand Strategic Investment (TSI)” Part 5 ၏ တွဲဖက်စာစောင် ဖြစ်သည်။ Certification ပြင်ဆင်ချိန် ခန့်မှန်းချက်များနှင့် ခေါင်းဆောင်မှုအချိန်ဇယားများကို ထိုစာစောင်တွင် ကိုးကားထားသော ရင်းမြစ်များ (CBT Nuggets၊ StudyTech၊ FinOps Foundation၊ First Round Review၊ The Pragmatic Engineer) မှ ရယူထားသည်။