အခန်း ၁၃ :: DevOps and Site Reliability Engineering (SRE)

Software Development လောကမှာ အရင်တုန်းက Developer (Dev) နဲ့ Operations (Ops) ကြားမှာ ကြီးမားတဲ့ တံတိုင်းကြီး တစ်ခု ရှိခဲ့ပါတယ်။ Developer တွေက Feature အသစ်တွေ မြန်မြန် ထွက်ချင်တယ်။ Operations သမားတွေကတော့ System တည်ငြိမ်မှု (Stability) ကို လိုချင်တာမို့ အပြောင်းအလဲ လုပ်ရမှာကို ကြောက်တယ်။ ဒီလို ပဋိပက္ခတွေကြောင့် "It works on my machine" (ငါ့စက်မှာတော့ ရတယ်၊ Server ပေါ်ရောက်မှ မရတာ ငါမသိဘူး) ဆိုတဲ့ စကားတွေ၊ Deployment လုပ်တိုင်း Error တက်တာတွေ ဖြစ်လာပါတယ်။

ဒီပြဿနာတွေကို ဖြေရှင်းဖို့ DevOps ယဉ်ကျေးမှု ပေါ်ပေါက်လာပါတယ်။ DevOps ဆိုတာ Development နဲ့ Operations ပေါင်းစပ်ထားခြင်း ဖြစ်ပြီး၊ Software ကို မြန်မြန်ဆန်ဆန် (Speed) နဲ့ ယုံကြည်စိတ်ချစွာ (Reliability) အသုံးပြုသူ လက်ထဲ ထည့်ပေးနိုင်ဖို့ ရည်ရွယ်ပါတယ်။

သတိပြုရန်: DevOps ဆိုတာ Tools (Docker, Kubernetes, Jenkins) မဟုတ်ပါဘူး။ Culture (ယဉ်ကျေးမှု) ဖြစ်ပါတယ်။ Team တစ်ခုလုံး ပူးပေါင်းဆောင်ရွက်တဲ့ စိတ်ဓာတ်မရှိရင် ကမ္ဘာ့အကောင်းဆုံး Tool တွေ သုံးထားလည်း DevOps မဖြစ်လာနိုင်ပါဘူး။

Google ကတော့ "DevOps ဆိုတာ Abstract Interface ဖြစ်ပြီး၊ SRE (Site Reliability Engineering) ဆိုတာ အဲဒီ Interface ကို Implement လုပ်ထားတဲ့ Class ဖြစ်တယ်" လို့ တင်စားထားပါတယ်။

CI/CD အကြောင်းကို Developer Intern စာအုပ်မှာ ပြောပြခဲ့ဖူးပါတယ်။ ဒါကြောင့် အသေးစိတ်ကို အဲဒီ စာအုပ် မှာ ဖတ်ကြည့်တာ ပိုအဆင်ပြေပါလိမ့်မယ်။ အခု စာအုပ်မှာတော့ သဘောတရား နှင့် နားလည် ရုံ သာ ဖော်ပြထားပါတယ်။

၁၃.၁ The CI/CD Pipeline

DevOps ရဲ့ အသက်သွေးကြော ကတော့ CI/CD Pipeline ပါပဲ။ စက်ရုံတွေမှာ ကုန်ပစ္စည်းတွေကို စက်ပန်းတောင်း (Conveyor Belt) ပေါ်တင်ပြီး အဆင့်ဆင့် တပ်ဆင်သွားသလိုပါပဲ၊ Code ကိုလည်း အလိုအလျောက် စနစ်တွေနဲ့ တည်ဆောက်ပါတယ်။

Continuous Integration (CI)

Developer တွေက ရေးပြီးသား Code တွေကို နေ့စဉ် (သို့) တစ်ရက်ကို အကြိမ်ကြိမ် Main Repository (Git) ထဲကို ပေါင်းထည့် (Merge) ခြင်း ဖြစ်ပါတယ်။ Merge လုပ်လိုက်တာနဲ့ Automated Test တွေ Run ပြီး Code ကောင်းမကောင်း ချက်ချင်း စစ်ဆေးပါတယ်။

ဒါဟာ ရှေ့အခန်းတွေမှာ ပြောခဲ့တဲ့ QA လုပ်ငန်းစဉ်ကို Automate လုပ်လိုက်တာ ပါပဲ။ Unit Testing, Browser Testing တွေကို လူက လိုက်စစ်နေစရာမလိုဘဲ၊ စက်ကနေ Code Quality ကို စစ်ဆေးပေးပြီးမှ Deployment အတွက် ပြင်ဆင်ပေးတာ ဖြစ်ပါတယ်။

Continuous Delivery & Deployment (CD)

• Continuous Delivery: Code တွေကို Production ပေါ်တင်ဖို့ အဆင်သင့် ဖြစ်နေတဲ့ အခြေအနေပါ။ ဒါပေမယ့် Production ပေါ် တင်ဖို့အတွက် လူက ခလုတ်နှိပ်ပေးရပါဦးမယ် (Manual Approval)။
• Continuous Deployment: Test တွေ အကုန် Pass တာနဲ့ လူက ဘာမှ လုပ်စရာ မလိုဘဲ Production ပေါ်ကို အလိုအလျောက် ရောက်သွားတာပါ။

CI/CD မရှိရင် ဘာဖြစ်မလဲ?

• Deployment Nightmare: Version အသစ်တင်တိုင်း ညဘက်ကြီး OT ဆင်းပြီး လက်နဲ့ လိုက်တင်နေရမယ်။
• Slow Feedback: Code ရေးလိုက်တဲ့ အမှားကို Production ရောက်ပြီး User တွေ ဆဲမှ သိရမယ်။
• Deployment Fear: တင်လိုက်ရင် မှားမလားဆိုတဲ့ အကြောက်တရားကြောင့် Feature အသစ်တွေ ထုတ်ရမှာ နှေးကွေးသွားမယ်။

Tools and Workflow

CI/CD ကို GitHub Actions, GitLab CI တို့မှာ လွယ်ကူစွာ ပြုလုပ်နိုင်သလို၊ Cloud သုံးသူတွေအတွက် AWS CodePipeline လိုမျိုး Service တွေလည်း ရှိပါတယ်။ Workflow ကတော့ ရိုးရှင်းပါတယ်။ ဥပမာ - dev branch ကို push လုပ်လိုက်ရင် Dev Server မှာ အလိုအလျောက် Deploy လုပ်မယ်၊ main (Production) branch ကို push လုပ်ရင် Production မှာ Deploy လုပ်မယ် ဆိုပြီး သတ်မှတ်ထားနိုင်ပါတယ်။

CI/CD Process တွေဟာ ကိုယ်အသုံးပြုမည့် နည်းပညာ (Tech Stack) ပေါ် မူတည်ပြီး ကွာခြားနိုင်ပါတယ် -

• PHP/Python: Compile လုပ်စရာ မလိုတဲ့ Interpreted Language တွေဆိုရင် Unit Test Run တာ၊ Lint (Syntax) စစ်တာတွေ ပါဝင်ပါမယ်။
• Go/Java: Compiled Language တွေဆိုရင်တော့ Source Code ကို Production Server ပေါ် မတင်ဘဲ၊ Build လုပ်ပြီးသား Executable Binary (Artifact) ကိုပဲ Production ပေါ် တင်ပေးတာမျိုး ကွာခြားနိုင်ပါတယ်။

graph TB
    Code[Developer Push Code] --> Git{Git Branch?}
    
    subgraph CI [Continuous Integration - GitHub Actions]
        Git -->|feature/dev branch| GHA1[GitHub Actions Trigger]
        Git -->|main/master branch| GHA2[GitHub Actions Trigger]
        
        GHA1 --> Docker1[Build Docker Image]
        GHA2 --> Docker2[Build Docker Image]
        
        Docker1 --> Unit1[Run Unit Tests]
        Docker2 --> Unit2[Run Unit Tests]
        
        Unit1 --> Int1[Run Integration Tests]
        Unit2 --> Int2[Run Integration Tests]
    end
    
    subgraph CD [Continuous Deployment]
        Int1 -->|Tests Pass| Staging[Deploy to Staging]
        Staging --> E2E1[Run E2E Tests on Staging]
        E2E1 --> Done1[Done - Review in Staging]
        
        Int2 -->|Tests Pass| Prod[Deploy to Production]
        Prod --> E2E2[Run E2E/Smoke Tests]
        E2E2 --> Monitor[Monitor & Rollback if needed]
    end
    
    Unit1 -.->|Tests Fail| Notify1[Notify Developer]
    Unit2 -.->|Tests Fail| Notify2[Notify Developer]
    
    style CI fill:#e1f5fe,stroke:#01579b,stroke-width:2px
    style CD fill:#e8f5e9,stroke:#1b5e20,stroke-width:2px
    style Git fill:#fff3e0,stroke:#e65100,stroke-width:2px

၁၃.၂ Infrastructure as Code (IaC)

အရင်တုန်းက Server တစ်လုံး ဆောက်မယ်ဆိုရင် System Admin က လက်နဲ့ Command တွေ ရိုက်၊ Software တွေ Install လုပ်ရပါတယ်။ Server အလုံး ၁၀၀ ဆိုရင် လူသေလောက်တဲ့ အလုပ်ပါ။ မှားနိုင်ချေလည်း များပါတယ်။

DevOps ခေတ်မှာတော့ Infrastructure as Code (IaC) ကို သုံးပါတယ်။ Server တွေ၊ Network တွေ၊ Database တွေကို Code (Configuration Files) အနေနဲ့ ရေးသား သိမ်းဆည်းထားတာပါ။

ဥပမာ - Terraform သို့မဟုတ် Ansible ကို သုံးပြီး "RAM 8GB ရှိတဲ့ Server ၃ လုံး လိုချင်တယ်" လို့ Code ရေးလိုက်ရင်၊ Cloud (AWS/Google) ပေါ်မှာ အလိုအလျောက် ဆောက်ပေးသွားမှာပါ။

Tools and Evolution

Infrastructure Code ရေးသားရာမှာ Tool ပေါ်မူတည်ပြီး ကွာခြားမှုရှိပါတယ် -

• Terraform: ပုံမှန်အားဖြင့် HCL (HashiCorp Configuration Language) လို့ခေါ်တဲ့ .tf file တွေကို အသုံးပြုပါတယ်။ (CDKTF ကဲ့သို့သော Tool တွေသုံးမှသာ TypeScript .ts လိုမျိုး ဘာသာစကားတွေကို သုံးလေ့ရှိပါတယ်)။
• Ansible: YAML (.yml) file တွေကို အသုံးပြုပြီး ရေးသားရပါတယ်။

Terraform ကတော့ Industry Standard အဖြစ် လူသုံးအများဆုံး ဖြစ်ပါတယ်။ သူ့ရဲ့ အားသာချက်က တခါရေးပြီးရင် နောက် Project တွေမှာ အလွယ်တကူ ပြန်လည် အသုံးပြုနိုင်ခြင်း (Reusability) ဖြစ်ပါတယ်။ ဒါပေမယ့် လေ့လာရတဲ့ Learning Curve ကတော့ နည်းနည်း မြင့်ပါတယ်။

IaC in the AI Era

ကံကောင်းတာက ၂၀၂၅ နောက်ပိုင်းမှာ AI တွေရဲ့ အခန်းကဏ္ဍက IaC ဘက်ကိုပါ ရောက်လာပါပြီ။ Terraform က MCP (Model Context Protocol) ကို Support ပေးလာပြီး၊ AI Tools တွေကို အသုံးပြုကာ Infrastructure Code တွေကို လွယ်ကူလျင်မြန်စွာ ရေးသားလာနိုင်ပါပြီ။ ဒါကြောင့် DevOps Engineer တွေအတွက် အလုပ်ဝန် အရမ်းပေါ့သွားစေပါတယ်။

Software Engineer's Responsibility

Software Engineer တစ်ယောက်အနေနဲ့ "ဒါ DevOps အလုပ်ပဲ" ဆိုပြီး လုံးဝ လွှတ်ထားလို့ မရပါဘူး။ ကိုယ်တိုင် Script တွေ အစအဆုံး မရေးတတ်ရင်တောင်၊ သူတို့ရေးထားတဲ့ Terraform Code ကို ဝင်ဖတ်ပြီး Audit လုပ်နိုင်စွမ်း ရှိရပါမယ်။

• "ငါလိုချင်တဲ့ Infra ပုံစံနဲ့ ကိုက်ညီမှု ရှိရဲ့လား"
• "Database setting တွေ မှန်ရဲ့လား"

ဒါတွေကို Code ကြည့်ပြီး စစ်ဆေးနိုင်တဲ့အထိ နားလည်ထားရင် Senior Engineer ကောင်း တစ်ယောက် ဖြစ်လာမှာပါ။

Pets vs. Cattle Analogy

IaC ရဲ့ အဓိက သဘောတရားကတော့ Server တွေကို Pets (အိမ်မွေးတိရစ္ဆာန်) လို သဘောမထားဘဲ Cattle (မွေးမြူရေး တိရစ္ဆာန်) လို သဘောထားရမယ် ဆိုတာပါပဲ။

• Pets: နာမည်ပေးထားတယ်။ နေမကောင်းရင် ဆေးကုတယ်။ (အရင်ခေတ်က Server တွေပါ)။
• Cattle: နာမည်မပေးဘူး။ နံပါတ်ပဲ တပ်ထားတယ်။ နေမကောင်းရင် (Error တက်ရင်) အသစ်တစ်ကောင် နဲ့ ချက်ချင်း အစားထိုးလိုက်တယ်။ (Cloud Server တွေပါ)။

၁၃.၃ Containers and Orchestration

Docker (Containers)

"ငါ့စက်မှာတော့ အလုပ်လုပ်တယ်၊ Server ပေါ်ရောက်မှ Error တက်တယ်" ဆိုတဲ့ ပြဿနာကို ဖြေရှင်းဖို့ Docker ပေါ်လာပါတယ်။ Software တစ်ခု run ဖို့ လိုအပ်တဲ့ Code, Library, Settings အားလုံးကို Container ဆိုတဲ့ သေတ္တာလေး တစ်ခုထဲ ထည့်ပြီး ထုပ်ပိုးလိုက်တာပါ။ ဒီသေတ္တာ (Container) ကို ဘယ်စက်မှာ သွား run run ပုံစံတူ အလုပ်လုပ်မှာ သေချာပါတယ်။

Docker အကြောင်းအသေးစိတ်ကိုတော့ Developer Intern စာအုပ်မှာ ဖော်ပြပြီးသား ဖြစ်သည့် အတွက် ဒီမှာ ထပ်ပြီး မဖော်ပြတော့ပါဘူး။ Developer Intern စာအုပ်ကို ဖတ်ကြည့်ဖို့ အကြံပြုလိုပါတယ်။

Kubernetes (Container Orchestration)

Docker ကြောင့် Application တစ်ခုကို Container ထဲထည့်ပြီး Run ရတာ လွယ်သွားပါပြီ။ ဒါပေမယ့် လက်တွေ့လုပ်ငန်းခွင်မှာ Container တစ်လုံးတည်းနဲ့ မလုံလောက်ပါဘူး။ Microservices တွေ မှာ Container ပေါင်း မြောက်များစွာ run နေရပါတယ်။

ဒီ Container အများကြီးကို လူက လိုက်ထိန်းဖို့ (Manage လုပ်ဖို့) ဆိုတာ မဖြစ်နိုင်ပါဘူး။ ဒီပြဿနာကို ဖြေရှင်းဖို့ Container Orchestration နည်းပညာ လိုအပ်လာပြီး၊ ဒီနေရာမှာ Kubernetes (K8s) က မရှိမဖြစ် ဖြစ်လာပါတယ်။

Kubernetes ကို သံစုံတီးဝိုင်း ခေါင်းဆောင် (Orchestra Conductor) နဲ့ တူပါတယ်။ ဂီတသမား (Container) တစ်ယောက်ချင်းစီ ဘယ်အချိန်မှာ တီးရမယ်၊ ဘယ်လောက်ကျယ်ကျယ် တီးရမယ် ဆိုတာကို ခေါင်းဆောင်က ထိန်းကျောင်းပေးသလိုပါပဲ။

Kubernetes ရဲ့ အဓိက စွမ်းဆောင်ရည် (Superpowers) ၄ ခုကတော့ -

1. Self-healing (အလိုအလျောက် ပြုပြင်ခြင်း)

Container တစ်ခု Error တက်ပြီး သေသွားရင် (Crash ဖြစ်သွားရင်)၊ လူက ဝင်ပြင်စရာမလိုဘဲ Kubernetes က အလိုအလျောက် အသစ်ပြန် Run ပေးပါတယ်။ System Admin အိပ်နေရင်တောင် Server က မပျက်မကွက် အလုပ်လုပ်နေမှာပါ။

2. Auto-scaling (အလိုအလျောက် အတိုးအလျှော့ လုပ်ခြင်း)

User ဝင်ရောက်မှု များလာတဲ့အချိန် (ဥပမာ - Sale promotion လုပ်တဲ့အချိန်) မှာ Container အရေအတွက်ကို အလိုအလျောက် တိုးပေး (Scale Out) ပြီး၊ လူနည်းသွားရင် ပြန်လျှော့ပေး (Scale In) ပါတယ်။ ဒါကြောင့် Server ဖိုး ကုန်ကျစရိတ်ကို သက်သာစေပါတယ်။

3. Load Balancing (ဝန်မျှဝေခြင်း)

Container တွေ အများကြီးရှိတဲ့အခါ Traffic တွေကို တစ်နေရာတည်းမှာ ပြုံမနေစေဘဲ၊ Container အားလုံးဆီကို မျှတအောင် ခွဲဝေပေးပါတယ်။ ဒါမှ User Experience ကောင်းမွန်မှာ ဖြစ်ပါတယ်။

4. Rolling Updates (Zero Downtime Deployment)

အရင်တုန်းက Version အသစ်တင်ရင် "Server Maintenance လုပ်နေပါသည်" ဆိုပြီး ပိတ်ထားရပါတယ်။ Kubernetes မှာတော့ Version အဟောင်းတွေကို တစ်လုံးချင်းစီ လျှော့ချပြီး၊ Version အသစ်တွေကို တစ်လုံးချင်း အစားထိုး မောင်းနှင်သွားပါတယ်။ User တွေက System ပြင်နေမှန်းတောင် မသိလိုက်ဘဲ ဆက်သုံးနိုင်တာကို Zero Downtime လို့ ခေါ်ပါတယ်။

Kubernetes Architecture (အလုပ်လုပ်ပုံ)

Kubernetes မှာ အဓိက အပိုင်း ၂ ပိုင်း ပါဝင်ပါတယ် -

1. Control Plane (Master Node): ဦးနှောက် ဖြစ်ပါတယ်။ ဘယ် Container ကို ဘယ်နေရာမှာ ထားမယ်၊ ဘယ်လောက် Run မယ်ဆိုတာ ဆုံးဖြတ်ချက်ချပါတယ်။
2. Worker Nodes: လက်တွေ့ အလုပ်လုပ်တဲ့ ကောင်တွေပါ။ Container တွေဟာ ဒီ Worker Node တွေပေါ်မှာပဲ Run တာဖြစ်ပါတယ်။

Declarative Configuration (YAML)

Kubernetes ကို ခိုင်းစေတဲ့အခါ "ဘယ်လိုလုပ်ပါ" လို့ မခိုင်းဘဲ "ဘာလိုချင်တယ်" လို့ပဲ ခိုင်းရပါတယ်။ ဒါကို Declarative လို့ ခေါ်ပါတယ်။ Developer က YAML file လေးရေးပြီး "ငါ့ကို Web Server ၃ လုံး ပေးပါ" လို့ ပြောလိုက်ရင်၊ လက်ရှိ ၁ လုံးပဲ ရှိနေရင် K8s က နောက်ထပ် ၂ လုံး ထပ်ဆောက်ပေးပါလိမ့်မယ်။

Note for Beginners: Kubernetes ဟာ သင်ယူရ ခက်ခဲပြီး Complex ဖြစ်ပါတယ်။ ဒါကြောင့် ကုမ္ပဏီအများစုဟာ ကိုယ်တိုင် K8s Install မလုပ်ကြဘဲ Cloud Provider တွေရဲ့ Managed Kubernetes Services တွေဖြစ်တဲ့ GKE (Google), EKS (AWS), AKS (Azure) တို့ကို အသုံးပြုကြပါတယ်။

၁၃.၄ Site Reliability Engineering (SRE)

SRE ဆိုတာ Google က စတင်ခဲ့တဲ့ နည်းစနစ် ဖြစ်ပြီး၊ Software Engineer တွေက Operation ပြဿနာတွေကို ဖြေရှင်းဖို့ ကြိုးစားရာက ပေါ်လာတာပါ။ System Admin တွေလို လက်နဲ့ လိုက်လုပ်မယ့်အစား၊ Automation Tools တွေ ရေးပြီး System ကို တည်ငြိမ်အောင် လုပ်ပါတယ်။

SRE မှာ အရေးကြီးတဲ့ အသုံးအနှုန်း (၃) ခု ရှိပါတယ်။

1. SLA (Service Level Agreement)

ဒါက ကတိ ပါ။ ကုမ္ပဏီက Customer ကို ပေးထားတဲ့ ကတိ။ "ကျွန်တော်တို့ System က ၉၉.၉% အလုပ်လုပ်ပါမယ်။ မရရင် လျော်ကြေးပေးပါမယ်" ဆိုတာမျိုးပါ။ Business နဲ့ Legal ပိုင်း ပိုဆန်ပါတယ်။

2. SLO (Service Level Objective)

ဒါက ရည်မှန်းချက် ပါ။ Engineering Team က ထားရှိတဲ့ Target ဖြစ်ပါတယ်။ "ငါတို့ System က တစ်လမှာ ၄၃ မိနစ်ထက် ပိုပြီး Down လို့ မဖြစ်ဘူး" ဆိုတာမျိုးပါ။ SLA ထက် ပိုပြီး တင်းကျပ်လေ့ ရှိပါတယ်။

3. SLI (Service Level Indicator)

ဒါက လက်တွေ့ အခြေအနေ ပါ။ တကယ်တိုင်းတာ ရရှိတဲ့ ကိန်းဂဏန်းတွေပါ။ (ဥပမာ - လက်ရှိ Error Rate က 0.01% ရှိနေတယ်)။

Error Budgets (အမှားလုပ်ခွင့် ဘတ်ဂျက်)

SRE ရဲ့ စိတ်ဝင်စားစရာ အကောင်းဆုံး Concept ပါ။ 100% Uptime ဆိုတာ မဖြစ်နိုင်သလို၊ ဖြစ်အောင် လုပ်ရင်လည်း စရိတ်စက အရမ်းကြီးပါတယ်။ ဒါကြောင့် Error Budget သတ်မှတ်ပါတယ်။

ဥပမာ - SLO က 99.9% ဆိုပါစို့။ ဒါဆိုရင် 0.1% က Error Budget ပါ။
ဒါကို အချိန်နဲ့ တွက်လိုက်ရင် -

• တစ်ရက်မှာ = ၁.၄၄ မိနစ်
• တစ်လမှာ = ၄၃.၂ မိနစ် (43.2 minutes)

ဆိုလိုတာက တစ်လလုံးနေမှ ၄၃ မိနစ်ပဲ Down ခွင့်ရှိတာပါ။

• ဒီ Budget ကျန်နေသရွေ့ Developer တွေက Feature အသစ်တွေကို စိတ်ကြိုက် Deploy လုပ်ခွင့် ရှိတယ်။ Risk ယူလို့ရတယ်။
• တကယ်လို့ Error တွေများပြီး ဒီ ၄၃ မိနစ် ပြည့်သွားပြီ (Budget ကုန်သွားပြီ) ဆိုရင်တော့၊ Feature အသစ် တင်တာတွေကို ရပ်လိုက်ရပါမယ်။ System ပြန်ငြိမ်အောင် (Reliability) ကိုပဲ ဦးစားပေး လုပ်ရပါမယ်။

၁၃.၅ Observability (မြင်သာထင်သာရှိမှု)

Monitoring နဲ့ Observability မတူပါဘူး။

• Monitoring: "System ကြီး Down သွားပြီလား" လို့ မေးတာပါ။ (Known Unknowns)
• Observability: "System ကြီး ဘာလို့ နှေးနေတာလဲ၊ ဘယ်နားမှာ ကြာနေတာလဲ" ဆိုတာကို အဖြေရှာနိုင်စွမ်းပါ။ (Unknown Unknowns)

Observability အတွက် မဏ္ဍိုင်ကြီး ၃ ခု (Three Pillars) ရှိပါတယ်။

1. Metrics: ကိန်းဂဏန်းများ (CPU 80%, RAM 4GB, Request per second 500)။
2. Logs: ဖြစ်ပျက်သမျှ မှတ်တမ်းများ (Error text, Info messages)။
3. Traces: Request တစ်ခု ဝင်လာချိန်ကနေ ပြီးသွားတဲ့အထိ Service ပေါင်းစုံကို ဖြတ်သန်းသွားပုံ လမ်းကြောင်း။ Microservices တွေမှာ Bottleneck ရှာဖို့ မရှိမဖြစ် လိုအပ်ပါတယ်။

၁၃.၆ Incident Management (Case Study)

System ဆိုတာ တစ်ချိန်ချိန်မှာတော့ ပျက်မှာပါပဲ။ ပျက်တဲ့အခါ SRE သမားတွေ ဘယ်လို ကိုင်တွယ်သလဲ ဆိုတာ နားလည်အောင် Mini Case Study လေးတစ်ခုနဲ့ ကြည့်ရအောင်။

Scenario: The Friday Night Nightmare

Without DevOps:
သောကြာနေ့ည ၆ နာရီမှာ Developer တစ်ယောက်က ကုဒ်အသစ်တင်လိုက်တယ်။ Server ကြီး Down သွားတယ်။ Ops သမားက ဖုန်းဆက်လှမ်းဆဲတယ်။ "ဘယ်သူလုပ်တာလဲ" ဆိုပြီး တရားခံရှာကြတယ်။ Log တွေမရှိလို့ ဘာမှားမှန်းမသိဘူး။ မနက် ၃ နာရီမှ ပြန်ကောင်းတယ်။ တနင်္လာနေ့ကျတော့ Developer နဲ့ Ops ရန်ဖြစ်ကြပြီး ဘယ်သူမှ Code အသစ် မတင်ရဲတော့ဘူး။

With DevOps & SRE:
သောကြာနေ့ညမှာ ကုဒ်အသစ်တင်တယ်။ Canary Deployment နဲ့ User ၁၀% ကိုပဲ အရင်ပေးသုံးတယ်။ Error Rate တက်လာတာကို Monitoring System က ချက်ချင်းသိပြီး Auto-Rollback လုပ်လိုက်တယ်။ User အနည်းငယ်ပဲ ထိခိုက်လိုက်တယ်။
တနင်္လာနေ့မှာ Team တစ်ခုလုံး ထိုင်ပြီး Blameless Post-Mortem လုပ်တယ်။ "ဘယ်သူမှားလဲ" မမေးဘူး။ "ဘာကြောင့် Canary တုန်းက မမိလိုက်တာလဲ" ကို ဆွေးနွေးတယ်။ Test Case အသစ်ထပ်ဖြည့်ပြီး System ကို ပိုကောင်းအောင် ပြင်လိုက်တယ်။

Summary

DevOps နဲ့ SRE ဟာ Modern Software Engineering ရဲ့ မရှိမဖြစ် အစိတ်အပိုင်းတွေ ဖြစ်လာပါပြီ။

• Automate everything: လူလုပ်ရင် မှားနိုင်တယ်၊ စက်ကို ခိုင်းပါ။
• Measure everything: Metrics တွေ မရှိရင် ဘာဖြစ်နေလဲ မသိနိုင်ဘူး။
• Share everything: Team တွေကြားမှာ နံရံတွေ မရှိစေပါနဲ့။

Software Engineer တစ်ယောက် အနေနဲ့ Code ရေးရုံတင် မကဘဲ၊ ကိုယ်ရေးလိုက်တဲ့ Code က Production ပေါ်မှာ ဘယ်လို Run နေလဲ၊ ဘယ်လို Deploy လုပ်လဲ ဆိုတာကို နားလည်ထားခြင်းက Senior Level ကို တက်လှမ်းဖို့ အရေးပါတဲ့ အရည်အချင်း တစ်ခု ဖြစ်ပါတယ်။