Stop Over-Engineering in DevOps/SRE

ယနေ့ခေတ် Cloud-Native နဲ့ DevOps လောကမှာ နည်းပညာအသစ်တွေ ထွက်ပေါ်လာနှုန်းဟာ အံ့မခန်း မြန်ဆန်လွန်းနေပါတယ်။ CNCF (Cloud Native Computing Foundation) ရဲ့ Landscape ကို ဖွင့်ကြည့်လိုက်တယ်ဆိုရင် Observability, Service Mesh, GitOps, Orchestration စတဲ့ ကဏ္ဍအသီးသီးမှာ ရွေးချယ်စရာ Tool ပေါင်း ရာနဲ့ချီ ရှိနေတာကို တွေ့ရပါလိမ့်မယ်။

ဒီလို ရွေးချယ်စရာ ပေါများလာခြင်းနဲ့အတူ DevOps Engineer တွေ၊ SRE (Site Reliability Engineer) တွေကြားမှာ မသိမသာ ကူးစက်လာတဲ့ ပြဿနာတစ်ခု ရှိပါတယ်။ အဲဒါကတော့ ပြဿနာရဲ့ အတိမ်အနက်ကို မကြည့်ဘဲ အရှုပ်ထွေးဆုံး၊ အသစ်လွင်ဆုံး နည်းပညာတွေနဲ့သာ အဖြေရှာချင်ကြတဲ့ Over-Engineering ပြဿနာပဲ ဖြစ်ပါတယ်။

ရိုးရိုးရှင်းရှင်း အဓိပ္ပာယ်ဖွင့်ရရင် လက်ရှိ Business ရဲ့ လိုအပ်ချက်၊ Traffic ပမာဏ၊ Team Capacity တို့ထက် အဆမတန် ပိုမိုရှုပ်ထွေးပြီး ထိန်းသိမ်းရခက်ခဲတဲ့ စနစ်တစ်ခုကို တည်ဆောက်မိခြင်း ဖြစ်ပါတယ်။ DevOps နဲ့ SRE ရဲ့ အဓိက ရည်မှန်းချက်ဟာ Software Delivery ကို မြန်ဆန်ချောမွေ့စေဖို့နဲ့ စနစ်တစ်ခုလုံး Reliable ဖြစ်နေစေဖို့ ဖြစ်ပါတယ်။ ဒါပေမဲ့ Over-Engineering လုပ်မိတဲ့အခါ ကျွန်တော်တို့ တည်ဆောက်လိုက်တဲ့ Automation တွေ၊ Pipeline တွေနဲ့ Infrastructure အလွှာတွေဟာ ပြဿနာကို ဖြေရှင်းပေးမယ့်အစား သူတို့ကိုယ်တိုင်က ထိန်းသိမ်းရမယ့် ပြဿနာအသစ် တွေ ဖြစ်လာတတ်ပါတယ်။

Engineer တော်တော်များများဟာ စေတနာအမှားနဲ့ Over-Engineering လုပ်မိတတ်ကြသလို၊ တစ်ခါတလေမှာတော့ စိတ်ပိုင်းဆိုင်ရာ လှုံ့ဆော်မှုတွေကြောင့်လဲ လုပ်တတ်ကြပါတယ်။ အဓိက အကြောင်းရင်း (၅) ချက်ကတော့ —

1. Hyperscaler Envy

Google, Netflix, Uber, Spotify တို့လို Tech Giant ကြီးတွေရဲ့ Engineering Blog တွေ၊ Conference Talk တွေကို ကြည့်ပြီး သူတို့သုံးတဲ့ Architecture အတိုင်း လိုက်ဆောက်ချင်ကြတာ ဖြစ်ပါတယ်။ သတိပြုရမှာက အဲဒီကုမ္ပဏီကြီးတွေဟာ တစ်စက္ကန့်ကို Request သန်းပေါင်းများစွာနဲ့ ကမ္ဘာအနှံ့က Data Center တွေကို ချိတ်ဆက်နေရတာ ဖြစ်ပြီး၊ သူတို့မှာ အဲဒီ Platform ကိုပဲ သီးသန့်ထိန်းသိမ်းမယ့် Engineer ရာချီ ရှိနေပါတယ်။ သူတို့ရဲ့ ပြဿနာနဲ့ ကိုယ့်ရဲ့ ပြဿနာ မတူညီဘဲ သူတို့ရဲ့Solution ကို ယူသုံးလိုက်တဲ့အခါ မလိုအပ်တဲ့ ဝန်ထုပ်ဝန်ပိုးကြီး ဖြစ်သွားတတ်ပါတယ်။

2. Prompt-Driven Engineering

ယနေ့ခေတ်မှာ Engineer တော်တော်များများဟာ ကိုယ်တိုင် Architecture ကို အခြေခံကနေ စဉ်းစားတာ၊ Documentation ဖတ်တာတွေ မလုပ်တော့ဘဲ ကိစ္စသေးသေးလေးကအစ AI ကိုပဲ Prompt ပေးပြီး အဖြေထုတ်ခိုင်းလာကြပါတယ်။ ဒီလို အရာရာကို Prompt ပေးပြီး လုပ်ခြင်း ကနေ မသိမသာ Over-Engineering ဖြစ်သွားရတဲ့ အကြောင်းရင်းကတော့

• AI သည် ရိုးရှင်းမှုထက် "Maximum Enterprise" ကိုသာ ဦးစားပေးထုတ်ပေးခြင်း: AI ကို "Production အတွက် Kubernetes manifest သို့မဟုတ် Terraform code ရေးပေးပါ" လို့ Prompt ပေးလိုက်တဲ့အခါ၊ AI က သင့်ရဲ့ လက်ရှိ Team အရွယ်အစားနဲ့ တကယ့်လိုအပ်ချက်ကို မသိပါဘူး။ ဒါကြောင့် သူသိသမျှ Enterprise Best Practices တွေ၊ မလိုအပ်တဲ့ Security Policies တွေ၊ Complex Abstractions တွေနဲ့ အလွှာပေါင်းများစွာကို တစ်ပြိုင်တည်း ထည့်ရေးပေးလိုက်ပါတယ်။
• Copy-Paste လုပ်ရ လွယ်ကူသဖြင့် မလိုအပ်သော ကုဒ်များ စုပုံလာခြင်း: အရင်တုန်းက ရှုပ်ထွေးတဲ့ Configuration တစ်ခုရေးဖို့ နာရီပေါင်းများစွာ အချိန်ပေးရတဲ့အတွက် တကယ်လိုအပ်မှသာ ရေးဖြစ်ကြပါတယ်။ အခုချိန်မှာတော့ Prompt တစ်ကြောင်း ရိုက်ထည့်လိုက်ရုံနဲ့ စာကြောင်းရေ ရာချီရှိတဲ့ YAML, HCL သို့မဟုတ် CI/CD Pipeline တွေကို စက္ကန့်ပိုင်းအတွင်း ရရှိနေတာကြောင့် "ပါထားတော့လည်း ကောင်းတာပဲ" ဆိုတဲ့ စိတ်နဲ့ မျက်စိမှိတ် Copy-Paste လုပ်မိကြပါတယ်။
• ကိုယ်တိုင် နားမလည်သော စနစ်ကြီး ဖြစ်လာခြင်း: အရာရာကို AI Prompt နဲ့ပဲ တည်ဆောက်ထားတဲ့အခါ၊ စနစ်ကြီးက အပြင်ပန်းကြည့်ရင် အရမ်းခမ်းနားနေပေမဲ့ တကယ်တမ်း Production မှာ ပြဿနာတက်တဲ့အခါကျမှ အဲဒီ AI ထုတ်ပေးထားတဲ့ Logic တွေ၊ Flags တွေက ဘာအတွက် သုံးထားမှန်း ကိုယ်တိုင်တောင် သေချာမသိဘဲ ပြန်ရှင်းရခက်တဲ့ အခြေအနေ ဖြစ်သွားတတ်ပါတယ်။

3. Premature Optimization

"နောင်တစ်ချိန် User ၁၀ သန်း ဝင်လာရင် ဘယ်လိုလုပ်မလဲ?"၊ "နောက်နှစ်မှာ AWS ကနေ GCP ကို ပြောင်းချင်ရင် လွယ်အောင် အခုကတည်းက Cloud-Agnostic ဖြစ်အောင် ဆောက်ထားမယ်" ဆိုတဲ့ မသေချာသေးတဲ့ အနာဂတ်အတွက် လက်ရှိမှာ အချိန်နဲ့ ငွေကြေး အမြောက်အမြား ရင်းနှီးမြှုပ်နှံမိတာ ဖြစ်ပါတယ်။ လက်တွေ့မှာတော့ Company 95% လောက်ဟာ Cloud Provider တစ်ခုကနေ နောက်တစ်ခုကို အလွယ်တကူ ပြောင်းလေ့မရှိသလို၊ Day-1 မှာ ကြိုဆောက်ထားတဲ့ Architecture ကလည်း တကယ်တမ်း Scale လုပ်ရမယ့်အချိန် ရောက်တဲ့အခါ ခေတ်မမီတော့တာမျိုး ဖြစ်နေတတ်ပါတယ်။

4. Resume-Driven Development

နည်းပညာလောကမှာ ကိုယ့်ရဲ့ Market Value မကျသွားအောင် အသစ်ထွက်တဲ့ Tool တွေကို လေ့လာရတာ သဘာဝကျပါတယ်။ ဒါပေမဲ့ ကိုယ့်ရဲ့ CV မှာ Kubernetes, Istio, Cilium, Crossplane စတဲ့ နာမည်တွေ ထည့်ရေးချင်ရုံသက်သက်နဲ့ မလိုအပ်တဲ့ Production Environment မှာ အတင်းဆွဲသုံးမိတဲ့အခါ ကုမ္ပဏီရော၊ ကိုယ့်ရဲ့ လုပ်ဖော်ကိုင်ဖက်တွေပါ ဒုက္ခရောက်ရတတ်ပါတယ်။

5. The Illusion of Seniority

တချို့သော Engineer တွေဟာ ရိုးရှင်းတဲ့ Architecture Diagram တစ်ခု ဆွဲပြရမှာကို ရှက်တတ်ကြပါတယ်။ Linux VM လေးတွေ၊ Managed Database နဲ့ ရိုးရှင်းတဲ့ CI/CD Pipeline လေးပဲ သုံးထားရင် ကိုယ့်ကိုယ်ကိုယ် "Senior မဆန်ဘူး" လို့ ထင်တတ်ကြပြီး၊ Box တွေ၊ မြားတွေ အရှုပ်အထွေးနဲ့ Diagram ကြီးတွေ ဆွဲပြနိုင်မှ တော်တယ်လို့ မှတ်ယူမိတတ်ကြပါတယ်။

ကိုယ့်ရဲ့ လက်ရှိ System ဟာ လိုအပ်တာထက် ပိုရှုပ်ထွေးနေပြီလားဆိုတာ အောက်ပါ လက္ခဏာတွေနဲ့ တိုက်ဆိုင်စစ်ဆေးကြည့်နိုင်ပါတယ် —

• Infrastructure Overhead > Application Workload: တကယ်အလုပ်လုပ်နေတဲ့ Business Application တွေထက် သူ့ကို ဝန်းရံထားတဲ့ Monitoring agents, Logging collectors, Service Mesh proxies နဲ့ Control plane တွေက CPU နဲ့ Memory ကို ပိုစားနေခြင်း။
• The Multi-Hop Debugging Nightmare: သာမန် Network Timeout သို့မဟုတ် 502 Bad Gateway ပြဿနာလေးတစ်ခု တက်ရင်တောင် အဖြေရှာဖို့အတွက် Network နဲ့ Proxy အလွှာ ၆ လွှာ၊ ၇ လွှာလောက်ကို တစ်ဆင့်ချင်း လိုက်စစ်နေရခြင်း။
• Fragile Abstraction in IaC: Terraform သို့မဟုတ် Ansible မှာ DRY (Don't Repeat Yourself) ဖြစ်ချင်လွန်းလို့ Module တွေ၊ Dynamic Variable တွေ အထပ်ထပ် ခံထားတဲ့အတွက်၊ သာမန် Port တစ်ခုဖွင့်ဖို့ သို့မဟုတ် Environment Variable တစ်ခုထည့်ဖို့ ဖိုင်ပေါင်းများစွာကို လိုက်ပြင်နေရပြီး terraform plan ရိုက်ရမှာကိုတောင် လန့်နေရခြင်း။
• Platform Maintenance Trap: DevOps/SRE အဖွဲ့ရဲ့ အချိန် 70% ကျော်ဟာ Product Feature အသစ်တွေ ထွက်နိုင်အောင် ကူညီပေးဖို့ မဟုတ်ဘဲ၊ ကိုယ်ဆောက်ထားတဲ့ Cluster တွေ၊ Tool တွေ မကျသွားအောင် Upgrade လုပ်ခြင်း၊ Patch ထိုးခြင်းတို့နဲ့သာ လုံးပန်းနေရခြင်းတို့ပဲဖြစ်ပါတယ်။

စနစ်တစ်ခုမှာ အစိတ်အပိုင်း (Moving Parts) များလာလေလေ၊ ပျက်စီးနိုင်ခြေရှိတဲ့ ထောင့်ကွက်တွေ (Failure Modes) က ဆတိုးများလာလေလေ ဖြစ်ပါတယ်။ အလွှာတိုင်းမှာ သူ့ရဲ့ ကိုယ်ပိုင် Bug၊ Configuration Error နဲ့ Network Latency တွေ ရှိနေနိုင်တာကြောင့် Incident တစ်ခုဖြစ်ပြီဆိုရင် ပြန်လည်ကောင်းမွန်လာဖို့ ကြာချိန် MTTR (Mean Time To Recovery) ကို အဆမတန် ကြာမြင့်သွားစေပါတယ်။

Cognitive Load and Bus Factor

Architecture တစ်ခုလုံးရဲ့ အလုပ်လုပ်ပုံကို အဖွဲ့ထဲက စတင်တည်ဆောက်ခဲ့သူ တစ်ယောက်တည်းကပဲ နားလည်ပြီး၊ ကျန်တဲ့သူတွေက မထိရဲ၊ မပြင်ရဲတဲ့ အခြေအနေ ဖြစ်လာတတ်ပါတယ်။ အဲဒီလူ အလုပ်ထွက်သွားရင် သို့မဟုတ် ခွင့်ယူထားရင် တစ်ဖွဲ့လုံး ဘာဆက်လုပ်ရမှန်း မသိတော့တဲ့ Bus Factor အန္တရာယ် ကြုံရသလို၊ အသစ်ဝင်လာတဲ့ Engineer တစ်ယောက် အလုပ်စလုပ်နိုင်ဖို့ (Onboarding) လနဲ့ချီ အချိန်ယူရတတ်ပါတယ်။Over-engineered စနစ်တွေဟာ အမြဲတမ်း ဂရုစိုက်ပေးနေရတဲ့ (High-maintenance) သဘောသဘာဝ ရှိပါတယ်။ မလိုအပ်တဲ့ Component တွေဆီကနေ ထွက်လာတဲ့ False-positive Alert တွေကြောင့် ညဘက် On-call တာဝန်ကျသူတွေ အိပ်ရေးပျက်ရပြီး၊ ရေရှည်မှာ Alert Fatigue နဲ့ Burnout ဖြစ်ပေါ်စေပါတယ်။

Over-Engineering ကို ရှောင်ရှားတယ်ဆိုတာ အဆင့်မမီတဲ့ စနစ်ကို ဖြစ်သလို ဆောက်တာမျိုး (Under-Engineering) မဟုတ်ပါဘူး။ လိုအပ်ချက်နဲ့ အံဝင်ခွင်ကျဖြစ်ပြီး ရေရှည်ထိန်းသိမ်းရ လွယ်ကူတဲ့ စနစ် (Right-Sizing Engineering) ကို တည်ဆောက်ခြင်းသာ ဖြစ်ပါတယ်။ ဒီလို တည်ဆောက်နိုင်ဖို့ အောက်ပါ အချက်များကို လက်ကိုင်ထားသင့်ပါတယ်။

1. Boring Technology

နည်းပညာတစ်ခုဟာ ပျင်းစရာကောင်းလောက်အောင် ရိုးရှင်းပြီး သက်တမ်းရင့်နေပြီဆိုရင် (ဥပမာ - Linux, PostgreSQL, Nginx, Redis) သူ့ရဲ့ ကောင်းကွက်၊ ဆိုးကွက်နဲ့ ပြဿနာဖြေရှင်းနည်း အားလုံးကို တစ်ကမ္ဘာလုံးက သိနေပြီးသား ဖြစ်ပါတယ်။ Production မှာ ဆန်းသစ်မှု (Innovation) ထက် တည်ငြိမ်မှု (Predictability) က ပိုအရေးကြီးပါတယ်။ လက်ရှိ ရိုးရှင်းတဲ့ Tool က မဖြေရှင်းပေးနိုင်တော့တဲ့ တကယ့် အခက်အခဲ (Pain Point) ကြုံလာမှသာ Tool အသစ်ကို ပြောင်းလဲပါ။

2. Practice Evolutionary Architecture

Day-1 မှာ Day-1000 အတွက် ကြိုမဆောက်ပါနဲ့။ လက်ရှိ Traffic ရဲ့ ၂ ဆ သို့မဟုတ် ၅ ဆလောက်ကို ကောင်းကောင်း ကိုင်တွယ်နိုင်မယ့် အရိုးရှင်းဆုံး ပုံစံနဲ့ စတင်ပါ။ ဒါပေမဲ့ နောင်တစ်ချိန် တကယ်လိုအပ်လာရင် အလွယ်တကူ ဖြုတ်တပ်ပြောင်းလဲနိုင်အောင် (Loosely Coupled / Modular) တည်ဆောက်ထားပါ။ Bottleneck တကယ်ပေါ်လာတဲ့ နေရာကိုပဲ Metric တွေကြည့်ပြီး အဆင့်ဆင့် Scale လုပ်သွားတာက အမှန်ကန်ဆုံး နည်းလမ်းဖြစ်ပါတယ်။

3. Prioritize Clarity Over Cleverness in IaC

Terraform, Helm, Ansible သို့မဟုတ် CI/CD Pipeline တွေ ရေးတဲ့အခါ ကိုယ်ဘယ်လောက် Logic ရေးတတ်လဲဆိုတာ ပြသဖို့ မကြိုးစားပါနဲ့။ Code အကြောင်းရေ နည်းနည်းပိုရှည်ပြီး ပြန်ထပ်နေရင်တောင် (WET - Write Everything Twice)၊ ဖတ်လိုက်တာနဲ့ ဘာလုပ်ထားလဲဆိုတာ ရှင်းရှင်းလင်းလင်း မြင်နိုင်တဲ့ ပုံစံက သာလွန်ကောင်းမွန်ပါတယ်။ Infrastructure Code ဆိုတာ နေ့တိုင်းပြင်နေရတဲ့ အရာမဟုတ်လို့ ၆ လနေမှ တစ်ခါပြန်ကြည့်ရင်တောင် ချက်ချင်းနားလည်နိုင်ဖို့ လိုအပ်ပါတယ်။

Final Thoughts

DevOps နဲ့ SRE ပညာရပ်ရဲ့ အနှစ်သာရဟာ ခေတ်အမီဆုံး နည်းပညာတွေ အားလုံးကို စုပြုံသုံးစွဲခြင်း မဟုတ်ပါဘူး။ ရှုပ်ထွေးလှတဲ့ နည်းပညာဆိုင်ရာ ပြဿနာတွေကို အရိုးရှင်းဆုံး၊ အတည်ငြိမ်ဆုံးနဲ့ ကုန်ကျစရိတ် အသက်သာဆုံး နည်းလမ်း နဲ့ ဖြေရှင်းပေးနိုင်ခြင်းသာ ဖြစ်ပါတယ်။

Junior Engineer တစ်ယောက်ဟာ ရိုးရှင်းတဲ့ ပြဿနာကို ရှုပ်ထွေးတဲ့ နည်းလမ်းနဲ့ ဖြေရှင်းတတ်ပြီး၊ တကယ့် ဝါရင့် Senior Engineer တစ်ယောက်ကတော့ ရှုပ်ထွေးတဲ့ ပြဿနာကို အရိုးရှင်းဆုံး နည်းလမ်းနဲ့ ဖြေရှင်းသွားတတ်ပါတယ်။ တစ်ဦးတစ်ယောက်ထဲအတွက်မဟုတ်ပဲ အဖွဲ့သားအားလုံး နားလည်လွယ်တဲ့ Infrastructure တစ်ခုကို တည်ဆောက်နိုင်ခြင်းကသာ SRE တစ်ယောက်ရဲ့ အမြင့်မားဆုံး အောင်မြင်မှု ပဲဖြစ်ပါတယ်။