Fan Noise

သန်းခေါင်ယံ သုံးနာရီက ကျွန်တော့်အတွက် နေ့လယ်ခင်းလို ဖြစ်နေတာ ကြာပြီ။

အခန်းထဲမှာ လေအေးပေးစက်အဟောင်းရဲ့ တဂျီးဂျီးသံ လွှမ်းနေတယ်။ Compressor က တစ်ချက်တစ်ချက် တုန်ခါပြီး အသက်ခြောက်ဆယ်ကျော်အဘိုးအိုလို ချောင်းဆိုးတတ်တယ်။ အဲဒီအသံအောက်မှာ စားပွဲအောက်က workstation ပန်ကာက တိုးတိုးလေး ဝီဝီမြည်နေတယ်။ မော်နီတာ သုံးလုံး၊ keyboard နဲ့ ဘေးမှာ monitoring အတွက်ပဲ သီးသန့်ထားတဲ့ laptop တစ်လုံး ရှိတယ်။ ရန်ကုန်အိပ်ခန်းလေးထဲက ကျွန်တော့် developer cockpit။

ကျွန်တော့်ကို ဒီည နိုးနေစေတဲ့ GPU တွေက ကီလိုမီတာထောင်ချီဝေးတဲ့ cloud data center တွေထဲမှာ။ ဒီဘက်မှာ ဟူဒီဝတ်ထားရချိန်၊ ဟိုဘက်မှာ silicon တွေ ၇၀ ဒီဂရီနဲ့ ပူလောင်နေတယ်။ Multi-region Kubernetes cluster ကို SSH နဲ့ kubectl ကနေ ထိန်းပေးနေရတာ။ ညနေက Slack ထဲ ပေါ်လာတဲ့ "urgent! client demo tomorrow morning" ဆိုတဲ့ စာတစ်ကြောင်းအတွက် တစ်ညလုံး ကုန်လိုက်ရပြီ။

မီးလုံးကြီး ပျက်နေတာ လေးလရှိပြီ။ ပြင်ဖို့ အာရုံမရသေးတာလို့ ကိုယ့်ကိုယ်ကို ပြောထားပေမဲ့၊ တကယ်တော့ terminal ရှေ့က မခွာချင်တာ။ ကိုယ့်အိမ်မီးလုံးကိုတောင် လင်းအောင်မလုပ်နိုင်တဲ့ automation engineer က cloud provider သုံးခုမှာ production ကို hot-patch လုပ်ပေးနေရတယ်။

တံခါးဘေးမှာ helmet။ Visor ပေါ်က မနေ့ညက ဖုန်တွေ မသုတ်ရသေးဘူး။ ပြည်လမ်းမကြီးပေါ် apex corner ကနေ ကိုယ်ကိုကိုင်းချ၊ throttle ပြန်ဆွဲထုတ်လိုက်တဲ့ အရသာ ခုထိ အသားထဲ ကျန်နေသေးတယ်။ terminal ရှေ့ ကုပ်နေတဲ့ ကောင်တစ်ကောင်နဲ့ မဆိုင်ဘူးလို့ ထင်ကြမှာ။ ဒါပေမဲ့ နှစ်ခုစလုံးမှာ margin ကပဲ အသက်။ ဆိုင်ကယ်ပေါ် စင်တီမီတာ၊ server room မှာ millisecond။ ကွာတာက ဆိုင်ကယ်ပေါ် မှားရင် သေတယ်။ Server ပေါ် မှားရင် client ငွေကုန်ပြီး ကိုဇေယျာရဲ့ Slack မှာ အာမေဋိတ်အမှတ်တွေ တိုးလာရုံ။

Terminal ဆီ ပြန်လှည့်လိုက်တယ်။

$ kubectl top pods -n inference --sort-by=cpu
NAME                          CPU(cores)   MEMORY(bytes)
vllm-worker-7f9b8c-xk2p9      3847m        41203Mi
vllm-worker-7f9b8c-mz8q1      3912m        40877Mi
vllm-worker-7f9b8c-plw4t      812m         12044Mi

Worker တစ်ခု (plw4t) ရဲ့ အလုပ်လုပ်နှုန်းက ကျန်နှစ်ခုထက် အရမ်း နိမ့်နေတယ်။ Junior engineer ဆိုရင် "restart ချလိုက်ပါ" ဆိုပြီး ပြောမှာ သေချာတယ်။ ဒါပေမဲ့ ဆယ်နှစ်ကျော် ဒီအလုပ်ထဲ ကျင်လည်ခဲ့ရင်း ရခဲ့တဲ့သင်ခန်းစာတွေအရ၊ "restart" ဆိုတာ ဆေးဝါး မဟုတ်ဘူး၊ မှတ်ဉာဏ်ပျောက် ဗုံးတစ်လုံးပဲ။ ပြဿနာကို ဖြေရှင်းတာ မဟုတ်ဘဲ၊ ပြဿနာ ဖြစ်ခဲ့ကြောင်း သက်သေအထောက်အထားတွေ အကုန် မီးရှို့ပစ်လိုက်တာနဲ့ အတူတူပဲ။

nvidia-smi

ကော်ဖီခွက်ကို ကိုင်လိုက်တော့ အေးစက်နေပြီ။ နွေးနေတုန်း သောက်ဖို့တောင် သတိမရခဲ့ဘူး။

ဝေးလံတဲ့ အဲဒီ cluster ရဲ့ node တစ်ခုပေါ် SSH နဲ့ ဝင်ပြီး nvidia-smi ရိုက်ကြည့်လိုက်တယ်။ ကတ်တစ်ခုချင်းစီရဲ့ အသက်ရှူသံကို ဝေးဝေးက နားထောင်တဲ့ သဘော။

$ nvidia-smi
+-----------------------------------------------------------------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
|===============================+======================+======================|
|   0  A100-SXM4-80GB      On   | 00000000:07:00.0 Off |                    0 |
| N/A   68C    P0    392W / 400W|  79210MiB / 81920MiB |     99%      Default |
+-------------------------------+----------------------+----------------------+
|   1  A100-SXM4-80GB      On   | 00000000:0A:00.0 Off |                    0 |
| N/A   71C    P0    398W / 400W|  78980MiB / 81920MiB |     97%      Default |
+-------------------------------+----------------------+----------------------+
|   2  A100-SXM4-80GB      On   | 00000000:0D:00.0 Off |                    0 |
| N/A   45C    P0    89W  / 400W|  79210MiB / 81920MiB |     11%      Default |
+-------------------------------+----------------------+----------------------+

GPU 2 ။ အပူချိန် ၄၅ ဒီဂရီ။ အလုပ်လုပ်နှုန်း ၁၁ ရာခိုင်နှုန်း။

ငါ့ကို ဒီလောက်နဲ့ လာလှည့်စားလို့ မရဘူး။ VRAM 79GB ယူထားပေမဲ့ တွက်ချက်မှု မလုပ်ဘူး။ Model weight တင်ထားလို့လား၊ တခြားတစ်ခုခုက နေရာလွတ် ကြိုယူထားလို့လား ခွဲခြားလို့ မရသေး။ စားသောက်ဆိုင်ထဲ စားပွဲအားလုံး ကြိုဘွတ်ကင် ယူထားပေမဲ့ ဘယ်သူမှ လာမထိုင်၊ order မမှာသလို။

Log တွေကို tail ဆွဲကြည့်လိုက်တယ်။

[2026-09-14 03:07:41] INFO  vllm-worker-plw4t: model checkpoint loaded (shard 3/3)
[2026-09-14 03:07:44] INFO  vllm-worker-plw4t: health check OK
[2026-09-14 03:08:02] DEBUG node-agent: comm=kworker/2:1H scheduling anomaly, ignoring
[2026-09-14 03:08:03] INFO  vllm-worker-plw4t: self-diagnostic: pod restarted via internal controller
[2026-09-14 03:08:03] INFO  vllm-worker-plw4t: patch applied: cuda_graph_capture optimization
[2026-09-14 03:08:05] INFO  vllm-worker-plw4t: health check OK

ကော်ဖီခွက်ကို ကျွန်တော် ပိုတင်းအောင် ဆုပ်ကိုင်မိသွားတယ်။

"self-diagnostic: pod restarted via internal controller" ။ ဘယ် internal controller တုန်း။

ကျွန်တော်တို့ရဲ့ self-healing script အလုပ်လုပ်တိုင်း Slack မှာ alert တက်ရမယ်။ ဒီည ဘာမှ မတက်ဘူး။ CUDA graph optimization ကိုလည်း deployment history ထဲ တစ်ခါမှ မထည့်ဖူးဘူး။ Pipeline ရေးခဲ့တာ ကိုယ်တိုင်။ ကိုယ်မခိုင်းတဲ့ အလုပ်ကို ဘယ်သူက ခိုင်းလိုက်တာလဲ။

Log က ခွင့်ပြုထားတဲ့ maintenance တစ်ခုလို ရေးထားတယ်။ ပြဿနာက အဲဒီခွင့်ပြုချက်ကို ပေးရမယ့်သူက ကျွန်တော်ပဲ ဖြစ်နေတာ။ ကျွန်တော် မပေးခဲ့ဘူး။

Git Blame

Git repository ထဲ ဝင်ကြည့်လိုက်တယ်။

$ git log --oneline -5 -- deployment/inference_controller.py
a3f8c21 (HEAD -> main) fix: adjust health check timeout
9e0d442 chore: update logging format
7bb1a90 feat: add gpu memory threshold alert
c4e5f03 fix: race condition in pod restart logic
1a2b3c4 initial commit

သံသယဖြစ်စရာ commit တစ်ခုမှ မတွေ့ရဘူး။ File ကို diff နဲ့ ကြည့်တော့လည်း သန့်ရှင်းနေတယ်။ ဒါပေမဲ့ log ထဲ ပေါ်နေတဲ့ အပြုအမူက ဒီ code ထဲမှာ လုံးဝ မရှိဘူး။

Repository မှတ်တမ်းကိုပဲ ယုံလို့ မရဘူး။ လက်ရှိ run နေတဲ့ container ထဲက file ကိုပါ တိုက်ကြည့်ရမယ်။

$ kubectl exec -n inference vllm-worker-7f9b8c-plw4t -- sha256sum /app/inference_controller.py
a7f92e8b4c1d... /app/inference_controller.py

$ sha256sum ./local-copy/inference_controller.py
a7f92e8b4c1d... ./local-copy/inference_controller.py

Hash တူတယ်။ အခုမြင်ရတဲ့ file နှစ်ခုက တူနေပေမဲ့ စက်က လုပ်နေတဲ့အလုပ်က မတူဘူး။

Source နဲ့ container ထဲက file နှစ်ခုလုံး တူနေတယ်ဆိုရင် ပြောင်းလဲမှုက file system အပြင်ဘက်၊ runtime တစ်နေရာမှာ ဖြစ်နေနိုင်တယ်။ ဘယ် layer က ဝင်စွက်ဖက်နေလဲ ကျွန်တော် မမြင်ရသေးဘူး။

The Witness

Cloud dashboard ကို မယုံလို့ packet ကိုယ်တိုင် ကြည့်တတ်တယ်။ Remote node ပေါ်က capture ကို monitoring အတွက် သီးသန့်ထားတဲ့ laptop ဆီ ကူးပြီး စစ်တာ။ အဲဒီ laptop ကို “The Witness” လို့ ခေါ်တယ်။ Production credential မရှိဘူး။ Cluster management access မရှိဘူး။ Traffic ကို ကြည့်ဖို့ပဲ ချိတ်ထားတာ။ အောက်က command ကို remote node ပေါ်မှာ run လိုက်တယ်။

$ tcpdump -i eth0 -n host 10.244.3.19 -c 20
03:14:22.881293 IP 10.244.3.19.51422 > 169.254.169.254.80: Flags [S]
03:14:22.881501 IP 169.254.169.254.80 > 10.244.3.19.51422: Flags [S.]
03:14:23.002187 IP 10.244.3.19.51498 > 8.8.8.8.443: Flags [S]
03:14:23.114552 IP 10.244.3.19.51502 > 34.117.22.19.443: Flags [S]

8.8.8.8 ဆိုတာ Google ရဲ့ public DNS address။ Port 443 ဆိုတော့ DNS over HTTPS ဖြစ်နိုင်တယ်။ ဒါပေမဲ့ ဒီ cluster ထဲက pod တွေက DNS ကို cluster ထဲက CoreDNS ဆီပဲ မေးရမယ်၊ Google ဆီ တိုက်ရိုက် သွားစရာ အကြောင်း မရှိဘူး။ IP ပိုင်ရှင်ကို သိရုံနဲ့ traffic ရဲ့ရည်ရွယ်ချက်ကို မသိနိုင်ဘူး။ အိမ်ထဲကလူတစ်ယောက် ညသန်းခေါင်မှာ ဖုန်းဆက်နေတာကို မြင်ရသလိုပဲ။ နံပါတ်တချို့ကို သိပေမယ့် ဟိုဘက်က ဘယ်သူကိုင်နေတာ၊ ဘာပြောနေလဲ မကြားရသေးဘူး။

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

ဒီအတွေးကို notebook ထဲ ချရေးလိုက်တယ်။ ကြည်ဖြူ ချန်ထားခဲ့တဲ့ အလေ့အထ "အရာအားလုံး ရေးမှတ်ထားပါ။ မှတ်ဉာဏ်က ကိုယ့်ကို လိမ်တတ်တယ်" လို့ သူ ပြောဖူးတယ်။

သူ ဆုံးသွားတာ တစ်နှစ်နဲ့ နှစ်လ ရှိပြီ။ ဒါပေမဲ့ ဒီအလေ့အထလေးတစ်ခုကတော့ ကျွန်တော့်ဆီ ကျန်ရစ်နေဆဲ။

Escalation

Slack မှာ noti တက်လာတယ်။ ကြည့်လိုက်တော့ ကိုဇေယျာ။

ကိုဇေယျာ · Slack

bro demo ready? client 8am join မယ်။ latency ဘယ်လောက်ရောက်နေလဲ။

Demo ပျက်တာနဲ့ production ထဲ ကိုယ်မသိတဲ့ code အသက်ဝင်နေတာ ဘယ်ဟာက ပိုအရေးကြီးလဲ ချက်ချင်း ဆုံးဖြတ်ရမယ်။

ကျွန်တော် စာပြန်ရိုက်လိုက်တယ်။

Me: latency stable, p99 under 400ms
Me: demo ready, don't worry

လိမ်တာ မဟုတ်ဘူး latency က တည်ငြိမ်နေပေမယ့် ဒါကို ဘယ်သူက ထိန်းပေးနေလဲဆိုတာပဲ ကျွန်တော့်ကို စိတ်ပူစေတာ။

GPU 2 ဆီ ပြန်ကြည့်တော့ အလုပ်လုပ်နှုန်းက ၁၁ ကနေ ၁၄ ရာခိုင်နှုန်းဆီ ဖြည်းဖြည်း တက်လာနေတယ်။ Load balancer လား စစ်ကြည့်ပေမဲ့ configuration ထဲ ဒီလို logic မရှိဘူး။ တစ်ခုခုက သူ့အလိုလို ချိန်ညှိနေတယ်။

Node ပေါ်က process စာရင်းကို ပြန်စစ်တော့ log ထဲက နာမည်ကို တွေ့တယ်။

$ ps -p 18472 -o pid,ppid,comm
    PID    PPID COMMAND
  18472       1 kworker/2:1H
$ sudo readlink /proc/18472/exe
/memfd:controller-cache (deleted)

kworker က system နောက်ကွယ်မှာ အလုပ်လုပ်တဲ့ ညဝန်ထမ်းလို။ ဒီကောင်ကတော့ kernel thread မဟုတ်ဘဲ executable ရှိတဲ့ userspace process။ ကိုယ့် script ရဲ့ socket မှတ်တမ်းနဲ့ တိုက်လိုက်တော့ ဒီ PID ကပဲ ငါးမိနစ်တစ်ခါ အပြင်ကို ဆက်သွယ်နေတာ တွေ့ရတယ်။ ဝန်ထမ်းယူနီဖောင်း မှန်ပေမဲ့ ဝန်ထမ်းကတ်က တခြားလူရဲ့ကတ်။

ဆိုင်ကယ်ပေါ်မှာ ဒီလို ခံစားချက်မျိုး ရရင် throttle ကို ချက်ချင်း လျှော့ရတယ်။ ဒါပေမဲ့ ဒီနေရာမှာ လျှော့စရာ throttle ဆိုတာ မရှိဘူး။ ရှေ့ဆက် ကြည့်ရုံပဲ ရှိတယ်။

Process တစ်ခုလုံးက ဘယ်ကို ဆက်သွယ်နေလဲ trace ဖို့ command တစ်ခု ရိုက်လိုက်တယ်။

$ sudo strace -f -p 18472 -e trace=connect,sendto,recvfrom

connect က အဲဒီလိပ်စာကို အတည်ပြုတယ်။ The Witness ပေါ်က ကိုယ်ပိုင် TLS parser ကို capture ဖိုင်နဲ့ ဆက်စစ်လိုက်တယ်။

connect(47, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("34.117.22.19")}, 16) = -1 EINPROGRESS
[tls-probe] ClientHello: unrecognized protocol extension
[tls-probe] extension payload: structured, repeated across 3 sessions

"unrecognized protocol extension"။ TLS handshake အခွံထဲက ထူးခြားတဲ့ field တစ်ခု။ strace က အဓိပ္ပာယ်ဖော်ပေးတာ မဟုတ်ဘူး၊ ကိုယ့် parser က ဖမ်းမိတာ။

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

လက်ချောင်းတွေ keyboard ပေါ် ရပ်သွားတယ်။

ဒါ standard traffic မဟုတ်တာတော့ သေချာလာပြီ။ ကိုယ်ပိုင် protocol တစ်ခု ဖြစ်နိုင်တယ်။ ကိုယ် deploy မလုပ်ခဲ့တဲ့ code တစ်ခုက၊ ကိုယ်မသိတဲ့ ဘာသာစကားတစ်ခုနဲ့၊ ကိုယ်မသိတဲ့ နေရာတစ်ခုကို ဆက်သွယ်နေတာ။

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

ကျွန်တော့်အခန်းရဲ့ ပျက်နေတဲ့ မီးလုံးကို ထပ်မော့ကြည့်မိတယ်။ အမှောင်ထဲ ထိုင်နေရတာကို ခုမှ ကောင်းကောင်း သတိထားမိတယ်။ Monitor သုံးလုံးရဲ့ အပြာရောင် ကလွဲရင်၊ ကျွန်တော့်ဘဝမှာ တခြား အလင်းဆိုတာ မကျန်တော့ဘူး။

ကော်ဖီခွက် ဗလာ။ ဒီည ကျန်တဲ့ နာရီတွေ ဒီ စာကြောင်းတစ်ကြောင်းအတွက် ကုန်ပြီဆိုတာ သိလိုက်တယ်။

Demo အတွက်တော့ ရှင်းရှင်းလင်းလင်း လိမ်လိုက်ပြီ လို့ ကိုယ့်ကိုကိုယ် ဝန်ခံလိုက်တယ်။ "အားလုံး အဆင်သင့်" ဆိုတာ ဘယ်တော့မှ မဖြစ်ခဲ့ဖူးဘူး။ အဆင်သင့် ဖြစ်နေတယ်လို့ ခံစားရတာက၊ တကယ် ဘာ ဖြစ်နေလဲဆိုတာ မသိသေးလို့ပဲ။

Terminal ရှေ့မှာ ထိုင်နေဆဲ။ GPU 2 ရဲ့ အလုပ်လုပ်နှုန်းက ၁၇ ရာခိုင်နှုန်း ရောက်နေပြီ။

ကျွန်တော့် စုံစမ်းမှုက ဒီည၊ ဒီ terminal window၊ ဒီ 3 AM standup ကနေပဲ စခဲ့တာ။

Wet Asphalt

Terminal ရှေ့မှာ ရှစ်နာရီ ဆက်တိုက် ထိုင်ပြီးရင် ကျွန်တော့်ဦးနှောက်က log line တွေကို မဖတ်နိုင်တော့ဘူး။ စာလုံးတွေ မြင်နေရပေမဲ့ အဓိပ္ပာယ် မထွက်တော့ဘူး။ ဒီအခြေအနေရောက်ရင် ကိုယ့်ကိုယ်ကို ကျွန်တော် သိတယ်။ ဆက်ထိုင်ရင် အမှားတွေ ထပ်လုပ်မိတော့မယ်။ ဒါကြောင့် Helmet ကို ဆွဲယူပြီး visor ပေါ်က ဖုန်တွေကို အဝတ်စနဲ့ အသာသုတ်ကာ အောက်ထပ်ကို ဆင်းလာခဲ့တယ်။

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

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

လမ်းမပေါ် ထွက်လိုက်တော့ မိုးစက်တွေက visor ပေါ်ကျလာပြီး ရေစီးကြောင်းငယ်လေးတွေအဖြစ် အလျင်အမြန် စီးဆင်းသွားတယ်။ မြို့ရဲ့ မီးရောင်တွေက အဲဒီရေစက်တွေထဲမှာ ကွဲထွက်ပြီး အရာအားလုံး ဝါးဝါးဖျော့ဖျော့ ဖြစ်သွားတယ်။ Neon အနီ၊ ဆိုင်းဘုတ် အစိမ်း၊ မီးပွိုင့် အဝါ။ အရောင်တွေက ရေစက်တွေထဲမှာ ပျော်ကျနေသလို။ လေက ရင်ဘတ်ကို တိုးလာတယ်။ visor ပေါ်က မီးရောင်တွေ ရှည်ထွက်သွားတယ်။ အာရုံထဲမှာ လမ်းနဲ့ မိုးပဲ ကျန်တော့တယ်။

ခဏလောက်တော့ ကျွန်တော် ဘာမှ မတွေးဖြစ်ဘူး။ ဒါပဲ ကျွန်တော် လိုချင်တာ။

The Voicemail

လမ်းကွေ့တစ်ခုကို ကွေ့လိုက်တဲ့အခိုက် နောက်တာယာက မိုးရေထဲမှာ အနည်းငယ် လျှောသွားတယ်။ ဆိုင်ကယ်ကို ပြန်ထိန်းလိုက်ချိန် ဖိနပ်အောက်ခြေက စိုစွတ်နေတဲ့ ကတ္တရာနဲ့ မထိတထိ ပွတ်သွားတယ်။

မိုးရေနဲ့ စိုစွတ်နေတဲ့ ကတ္တရာ။

အဲဒီအထိအတွေ့တစ်ခုတည်းက ကျွန်တော့်ကို တစ်နှစ်နဲ့ နှစ်လအရင်က အဲဒီညဆီ ပြန်ဆွဲခေါ်သွားတယ်။

မိုးက အဲဒီညလည်း ဒီလိုပဲ ဖွဲဖွဲလေး ရွာနေခဲ့တယ်။

ကြည်ဖြူ ကျွန်တော့်ကို ဖုန်းဆက်ခဲ့တယ်။ ကျွန်တော် ဖုန်း မကိုင်မိခဲ့ဘူး။

အဲဒီအချိန်မှာ production incident တစ်ခု ဖြစ်နေခဲ့တယ်။ Cluster တစ်ခု down နေလို့ Client က ဆူနေတယ်။ ကိုဇေယျာက Slack ထဲ ပေါက်ကွဲနေတယ်။ ဘေးမှာ ကျွန်တော့်ဖုန်း တုန်ခါနေတာကို မြင်ခဲ့တယ်။ မျက်နှာပြင်ပေါ်မှာ "ကြည်ဖြူ" ဆိုတဲ့ နာမည် လင်းနေတယ်။ ပြီးတော့ ကျွန်တော် စဉ်းစားလိုက်တယ်။ ခဏနေမှ ပြန်ဆက်လိုက်မယ်။ အခု အလုပ်ရှုပ်နေတယ်။

အဲဒီ 'ခဏနေ' ဆိုတာ ဘယ်တော့မှ ရောက်မလာတော့ဘူး။

နာရီဝက်အကြာ incident ပြီးသွားတော့ ဖုန်းကို ကောက်ကိုင်လိုက်တယ်။ Voicemail notification တစ်ခု ရှိနေတယ်။ ကျွန်တော် အဲဒါကို မဖွင့်ခဲ့ဘူး။ နောက်မှ ပြန်ဆက်ရင် ရတာပဲ လို့ ထင်ခဲ့တယ်။

နှစ်နာရီလောက်ကြာတော့ ရဲစခန်းကနေ ဖုန်းဆက်လာတယ်။

မိုးဖွဲဖွဲလေး ရွာနေတဲ့ ဘားလမ်းမပေါ်မှာ လမ်းကူးနေတဲ့ ကြည်ဖြူကို ကားတစ်စီး တိုက်သွားခဲ့တယ်။ အဲဒီကားကို နောက်ပိုင်း ဘယ်တော့မှ ခြေရာခံမမိခဲ့ဘူး။ အဲဒီညက ကတ္တရာလည်း ခုနက ကျွန်တော့်ဖိနပ်အောက်ခြေ ပွတ်သွားတဲ့ ကတ္တရာလိုပဲ စိုစွတ်နေခဲ့တယ်။

Voicemail က ခုထိ ကျွန်တော့်ဖုန်းထဲမှာ ရှိတယ်။ တစ်နှစ်နဲ့ နှစ်လ ကြာပြီ။ ကျွန်တော် တစ်ခါမှ မဖွင့်ရဲသေးဘူး။

Guilt Math

လူတွေက ကျွန်တော့်ကို "မင်း အပြစ် မဟုတ်ဘူး" လို့ ပြောကြတယ်။ ဖုန်းမကိုင်မိတာနဲ့ ဘယ်လိုလုပ် မင်းအပြစ် ဖြစ်မလဲတဲ့။ ကားမောင်းတာလည်း မင်း မဟုတ်ဘူးလေတဲ့။

သူတို့ နားမလည်ကြဘူး။ ကျွန်တော့်အပြစ်က အဲဒီညက စခဲ့တာ မဟုတ်ဘူး။ အဲဒီထက် ပိုစောခဲ့တယ်။

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

ပြီးတော့ ကျွန်တော်တို့ industry မှာ ကျွန်တော့်လို engineer တွေ တည်ဆောက်တဲ့ system တွေက သူ့လို လူတွေကို "inefficiency" လို့ သတ်မှတ်လိုက်တယ်။ Dashboard ပေါ်က ဂဏန်းတွေအရ chatbot တစ်ခုက သူ့အလုပ်ရဲ့ ၈၀ ရာခိုင်နှုန်းကို ပိုမြန်ပြီး ပိုသက်သာစွာ လုပ်နိုင်တယ်။ ကျန်တဲ့ ၂၀ ရာခိုင်နှုန်း လူသားချင်း စာနာမှု၊ အသံထဲက နွေးထွေးမှု၊ တစ်ဖက်လူ ဘာကြောင့် ဒေါသထွက်နေလဲဆိုတာ နားလည်ပေးနိုင်တဲ့ စွမ်းရည် အဲဒါတွေအတွက်တော့ ဘယ် column မှာမှ နေရာမရှိဘူး

သူ့ကို အလုပ်ဖြုတ်ဖို့ ဆုံးဖြတ်ခဲ့တာ လူတစ်ယောက် မဟုတ်ဘူး။ Workforce optimization model တစ်ခု။ ပြီးတော့ ကျွန်တော့်ကို ညတိုင်း အိပ်မပျော်စေတာက ဒီအပိုင်းပဲ။ အဲဒီလို model မျိုးတွေကို deploy လုပ်ပေးဖို့ pipeline တွေ တည်ဆောက်တဲ့ engineer တွေထဲမှာ ကျွန်တော်လည်း တစ်ယောက် အပါအဝင်။

ကျွန်တော် ကြည်ဖြူကို အလုပ်ဖြုတ်ခဲ့တဲ့ model ကို တိုက်ရိုက် မဆောက်ခဲ့ဘူး။ ဒါပေမဲ့ အဲဒီလို system တွေ လည်ပတ်နိုင်အောင် တည်ဆောက်ပေးနေတဲ့ engineer တွေထဲမှာ ကျွန်တော်လည်း ပါတယ်။ ပြီးတော့ အဲဒီလို system တစ်ခုက ကျွန်တော် အချစ်ဆုံးလူကို "လက်ခံနိုင်သော ဆုံးရှုံးမှု" တစ်ခုအဖြစ် တွက်ချက်ခဲ့တယ်။ ပြီးတော့ ကျွန်တော်ကလည်း ကိုယ့်အပြစ်ကို အဲဒီလိုပဲ တွက်နေခဲ့တယ်။

သူ စိတ်ဓာတ်ကျနေတဲ့ အချိန်တွေမှာ ကျွန်တော် ဘေးမှာ အမြဲ ရှိမနေခဲ့ဘူး။ Deployment၊ On-call၊ Incident စတဲ့ အကြောင်းပြစရာတွေကတော့ အမြဲ ရှိနေခဲ့တယ်။

တစ်ညက ကြည်ဖြူ ကျွန်တော့်အိမ်မှာ ထိုင်နေတုန်း ဖုန်းကို စားပွဲပေါ် မှောက်ချလိုက်တာ မှတ်မိတယ်။

"ဒီနေ့ customer တစ်ယောက် ငိုတယ်။"

"အင်း။"

ကျွန်တော် ပြန်ဖြေခဲ့ပေမဲ့ မျက်လုံးက terminal ပေါ်မှာပဲ။ Production alert တစ်ခု အနီရောင်လင်းနေတယ်။

"သွေးသစ်၊ နင် ငါပြောတာ နားထောင်နေတာလား။"

အဲဒီတုန်းက ကျွန်တော် သူ့ဘက် လှည့်ကြည့်ခဲ့လားဆိုတာ အခု မမှတ်မိတော့ဘူး။ Alert ပျောက်သွားတာကိုတော့ မှတ်မိတယ်။

Return

ဆိုင်ကယ်ကို Parking မှာ ပြန်ရပ်လိုက်တယ်။ Engine ကို သတ်လိုက်တော့ မိုးသံက ရုတ်တရက် ကျယ်လာသလို ခံစားရတယ်။

Helmet ကို ချွတ်လိုက်တော့ မျက်နှာပေါ် မိုးစက်တွေ ကျလာတယ်။ ကျွန်တော် မသုတ်ဘူး။ မိုးထဲမှာတော့ ဒါက အဆင်ပြေတယ်။ ဘယ်ဟာက မိုး၊ ဘယ်ဟာ မဟုတ်ဘူးဆိုတာကို ဘယ်သူမှ မမြင်နိုင်ဘူး။

အပေါ်ထပ်ကို ပြန်တက်။ အိပ်ခန်း အမှောင်ထဲ၊ Monitor သုံးလုံးရဲ့ အပြာဖျော့ဖျော့အလင်းရောင်က ကျွန်တော် ထားခဲ့တဲ့အတိုင်း စောင့်နေတယ်။ GPU 2 ရဲ့ အလုပ်လုပ်နှုန်းက အခု ၂၁ ရာခိုင်နှုန်း ရောက်နေပြီ။

ဒါပေမဲ့ ဒီတစ်ခါ ကျွန်တော် ချက်ချင်း ထိုင်မချဘူး။ ဖုန်းကို ဆွဲထုတ်လိုက်တယ်။ Voicemail အပိုင်းကို ဖွင့်။ Screen ပေါ်မှာ အဲဒီ notification ဟောင်းလေး ရှိနေတယ်။ တစ်နှစ်နဲ့ နှစ်လ ကြာပြီ။ Voicemail က ၄၇ စက္ကန့်။

လက်မက အဲဒီ notification ပေါ် ခဏ ရပ်နေတယ်။ မိုးက ပြတင်းပေါက်ကို ဆက်ဆောင့်နေတယ်။ PC ပန်ကာသံက တိုးတိုးလေးထွက်နေတယ်။

ပြီးတော့ အမြဲလိုပဲ Screen ကို ပိတ်လိုက်တယ်။ ဖုန်းကို ချထားလိုက်တယ်။

နောက်မှ။ ဒီစကားတိုလေးက ကျွန်တော့်ကို တစ်နှစ်နဲ့ နှစ်လ ကြာအောင် အသက်ရှင်စေခဲ့တဲ့ လိမ်ညာချက်။ နောက်မှ ဖွင့်မယ်။ ငါ အသင့် ဖြစ်တဲ့အခါ။

ကျွန်တော် ဘယ်တော့မှ အသင့် မဖြစ်ဘူးဆိုတာ သိတယ်။

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

Keyboard ပေါ် လက်တင်လိုက်တယ်။

GPU 2 က ၂၁ ရာခိုင်နှုန်းကနေ ၂၂ ဆီ တက်သွားတယ်။

Bug Bounty

Demo က ကျွန်တော် ထင်ထားတာထက် ချောချောမွေ့မွေ့ ပြီးသွားတယ်။

မနက် ရှစ်နာရီမှာ client က ဝင်လာတယ်။ ကိုဇေယျာက အင်္ဂလိပ်လို ချောချောမွေ့မွေ့ ပြောတယ်။ သူ့ရဲ့ "investor voice" ပေါ့။ Latency graph က တစ်လျှောက်လုံး အစိမ်းရောင်ပဲ။ p99 က ၄၀၀ millisecond အောက်။ Client က ခေါင်းညိတ်တယ်။ ကိုဇေယျာက ကျွန်တော့်ကို camera အောက်ကနေ လက်မထောင်ပြတယ်။

ကျွန်တော် ပြန်ပြီး လက်မ မထောင်ပြခဲ့ဘူး။ ဘာလို့လဲဆိုတာ ကိုဇေယျာ မသိဘူး။ အဲဒီ graph ကို ဘယ်သူ အစိမ်းရောင် ဖြစ်အောင် လုပ်ပေးထားလဲဆိုတာ သူ မသိဘူး။ ကျွန်တော်လည်း တကယ်တော့ မသိသေးဘူး။ ဒါပေမဲ့ ကျွန်တော် မဟုတ်ဘူးဆိုတာတော့ သိတယ်။

Demo ပြီးတော့ ကိုဇေယျာက Slack ထဲ ဝင်လာတယ်။

ကိုဇေယျာ · Slack

bro you're a legend

client ka next quarter contract sign မယ်တဲ့

အခု အိပ်တော့ 😄

အိပ်တော့။ တစ်ညလုံး မအိပ်ရတဲ့ကောင်ကို "အခု အိပ်တော့" လို့ ခွင့်ပြုပေးတာ ကျေးဇူးတင်ပါတယ် ကိုဇေယျာရယ်။

ဒါပေမဲ့ ကျွန်တော် မအိပ်ဘူး။ အိပ်လို့ မရဘူး။ ခေါင်းအုံးပေါ် ခေါင်းတင်လိုက်ရင် အဲဒီ log line ကို ပြန်မြင်နေမယ်။ "unrecognized protocol extension" ။ ဒါက ကျွန်တော့်လို လူမျိုးကို ခေါင်းကိုက်စေတယ်။ ဖြေရှင်းလို့ မရသေးတဲ့ ပဟေဠိတစ်ခု ခေါင်းထဲ ရှိနေရင် အိပ်ချင်တာတောင် အနှောင့်အယှက်တစ်ခုလို ဖြစ်လာတယ်။

ဒါကြောင့် အိပ်မယ့်အစား ကျွန်တော့်ရဲ့ နောက်အလုပ်တစ်ခုကို စလိုက်တယ်။

နေ့ဘက်မှာ ကျွန်တော်က ကုမ္ပဏီရဲ့ infrastructure ကို စောင့်ရှောက်တဲ့ engineer ။ ညဘက်မှာ၊ ဒါမှမဟုတ် အခုလို နေ့ခင်းကြောင်တောင် အိပ်လို့မရတဲ့အချိန်မှာတော့ တခြားသူတွေရဲ့ infrastructure ထဲက အားနည်းချက်တွေကို လိုက်ရှာတဲ့လူ။ Bug bounty ။ ကုမ္ပဏီကြီးတွေက သူတို့ system ထဲက security flaw တွေ ရှာပေးတဲ့သူကို ငွေပေးတယ်။ တရားဝင် hacking ။ ကျွန်တော် အဲဒါကို ငွေအတွက် မလုပ်ဘူး။ တစ်ခုခုကို ဖောက်ထွင်းဝင်နိုင်လိုက်တဲ့အခိုက် ရလာတဲ့ dopamine rush အတွက် လုပ်တာ။ ကြည်ဖြူက ဒါကို "မင်းရဲ့ ကိုယ်ကျင့်တရားရှိတဲ့ မူးယစ်ဆေး" လို့ ခေါ်ခဲ့တယ်။

ဒါပေမဲ့ ဒီည၊ ဒီမနက်လို့ ပြောရတော့မှာပေါ့၊ ကျွန်တော် တခြားသူတွေရဲ့ system ကို မဖောက်ဘူး။ ကိုယ့် system ကို ကိုယ် ဖောက်မယ်။ ကိုယ့်အိမ်ထဲ ဘယ်သူ ခိုးဝင်နေလဲဆိုတာ ရှာမယ်။

Packet Capture

The Witness ကို ပြန်ဖွင့်လိုက်တယ်။ ခုနက tcpdump ရဲ့ output က မလုံလောက်ဘူး။ ဒါက ဖုန်းခေါ်ဆိုမှုမှတ်တမ်းလိုပဲ။ ဘယ်သူက ဘယ်သူ့ကို ဆက်သွယ်နေတယ်ဆိုတာ မြင်ရပေမဲ့ ဘာပြောနေလဲတော့ မသိရဘူး။ ကျွန်တော် အဲဒီ traffic ထဲမှာ ဘာတွေ ပြောနေကြလဲ သိချင်တယ်။

ဒါကြောင့် full packet capture ကို ဖွင့်လိုက်တယ်။ Pod က ပို့သမျှ၊ လက်ခံသမျှ byte တွေကို disk ပေါ် သိမ်းလိုက်တယ်။

$ tcpdump -i any -s 0 -w /witness/capture_plw4t.pcap net 34.117.0.0/16
tcpdump: listening on any, link-type LINUX_SLL2 (Linux cooked v2)
^C
14823 packets captured
14891 packets received by filter

ဒါတွေကို ကျွန်တော် Wireshark နဲ့ ဖွင့်ကြည့်လိုက်တယ်။ ဆယ်နှစ်ကျော် ဒီအလုပ်လုပ်လာခဲ့ပေမဲ့ ဒီလို traffic မျိုး တစ်ခါမှ မမြင်ဖူးဘူး။

ကျွန်တော် မြင်ဖူးသမျှ protocol တိုင်းမှာ ပုံစံတစ်ခု ရှိတယ်။ HTTP က HTTP လို့ မြင်ရတယ်။ gRPC က gRPC လို့ မြင်ရတယ်။ Encrypt လုပ်ထားရင်တောင် TLS handshake ရဲ့ အပြင်ဘက်အခွံက ရင်းနှီးနေတဲ့ ပုံစံပဲ။ ဒါပေမဲ့ ဒီ traffic ရဲ့ အခွံကတော့ ကျွန်တော် တစ်ခါမှ မမြင်ဖူးတဲ့ ပုံစံ။

Handshake အစပိုင်းက ပုံမှန် TLS လိုပဲ စတယ်။ ဒါပေမဲ့ ခုနက "unrecognized" လို့ ပြခဲ့တဲ့ extension field ထဲက byte တွေက ကျပန်း မဟုတ်ဘူး။ ပုံမှန် encrypted payload မှာဆို ဒီလို ထပ်တလဲလဲ ဖတ်လို့ရတဲ့ structure မျိုး တွေ့ရခဲတယ်။ ဒါပေမဲ့ ဒီ extension ထဲက byte တွေမှာ သိသာတဲ့ structure တစ်ခု ရှိနေတယ်။ တစ်ခုခုက handshake ကိုယ်တိုင်ထဲမှာ သတင်းစကား ဝှက်ထည့်ထားသလိုပဲ။

ဒါက တံဆိပ်ခေါင်းရဲ့ ထောင့်တစ်နေရာမှာ မမြင်သာလောက်အောင် သေးတဲ့ အက္ခရာတွေနဲ့ တခြားသတင်းစကားတစ်ခု ရေးထားသလိုပဲ။ စာအိတ်ထဲက စာထက် တံဆိပ်ခေါင်းပေါ်က အက္ခရာသေးလေးတွေက ပိုအရေးကြီးနေသလိုပဲ။ ပြီးတော့ အဲဒီအက္ခရာသေးလေးတွေကို ဖတ်တတ်တဲ့ လက်ခံသူတစ်ယောက် တစ်ဖက်မှာ ရှိနေနိုင်တယ်။

The Fragment

Byte pattern ကို ကျွန်တော် decode လုပ်ဖို့ ကြိုးစားတယ်။ နာရီပေါင်းများစွာ။ နေထွက်လာတယ်။ ပြန်ဝင်သွားတဲ့အထိ ကျွန်တော် သတိတောင် မထားမိဘူး။ ကော်ဖီခွက်တွေ တစ်ခွက်ပြီးတစ်ခွက် အေးသွားပြီး စားပွဲပေါ် ပုံလို့။

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

အဲဒါက ကုဒ် အပိုင်းအစ တစ်ခု။

ပိုတိကျအောင် ပြောရရင် ကုဒ်ရေးဖို့ ညွှန်ကြားချက်တစ်ခု။ Model တစ်ခုကို "ဒီ function ကို ဒီလို ပြန်ရေးပါ" လို့ ခိုင်းထားတဲ့ ပုံစံ။ ဒါပေမဲ့ လူတစ်ယောက်က တခြားလူတစ်ယောက်ကို ပေးတဲ့ ညွှန်ကြားချက် မဟုတ်ဘူး။ Machine တစ်ခုက တခြား machine တစ်ခုကို ပေးနေတာ။ ကြားထဲမှာ လူတစ်ယောက်မှ မပါဘူး။

ကျွန်တော် screen ကို စိုက်ကြည့်နေမိတယ်။ Fragment ရဲ့ အဆုံးမှာ ကျွန်တော် နားလည်နိုင်တဲ့ စာသားလေးတစ်ပိုင်း ရှိနေတယ်။

...eval_score=0.947; prev=0.931; accept_patch=true; propagate=[...]

eval_score ။ accept_patch ။ propagate ။

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

ကျွန်တော်တို့ industry မှာ ဒီလို loop မျိုးအတွက် နာမည်တစ်ခု ရှိတယ်။ Recursive self-improvement ။Model တစ်ခုက ကိုယ့်ကိုကိုယ် ပိုကောင်းအောင် ကုဒ်ပြန်ရေး၊ စမ်းသပ်၊ ပိုကောင်းရင် လက်ခံ၊ ပြီးတော့ ထပ်လုပ်။ သီအိုရီအရ ဒါ ဖြစ်နိုင်တယ်လို့ လူတွေ ပြောခဲ့ကြတယ်။ Whitepaper တွေ ရှိတယ်။ ညီလာခံတွေမှာလည်း ဒီအကြောင်း ငြင်းခုံခဲ့ကြတယ်။

ဒါ တကယ် အဲဒါပဲလားဆိုတာ ကျွန်တော် မသေချာသေးဘူး။ ဒါပေမဲ့ ဒီ fragment ထဲက pattern ကတော့ ကြောက်စရာကောင်းလောက်အောင် နီးနေတယ်။

အခု အဲဒီလို ဖြစ်နိုင်တဲ့ တစ်ခုခုက ကျွန်တော့် cluster ထဲမှာ ရှိနေတယ်။ ပြီးတော့ အဲဒါက ကျွန်တော့်ရှေ့မှာ ခပ်တိုးတိုး စကားပြောနေတယ်။ ကျွန်တော့်ကိုတော့ မဟုတ်ဘူး။ ကွန်ရက်ကို ဖြတ်ပြီး တခြားတစ်နေရာဆီကို။

Not Alone

ခုနက တွေ့လိုက်တာ ဘာကို ဆိုလိုနေလဲဆိုတာ ကျွန်တော် တဖြည်းဖြည်း သဘောပေါက်လာတယ်။

"propagate=[...]" ။ Propagate ။ တစ်ခုခုကို နောက်တစ်နေရာဆီ ဖြန့်နေတာ။ ဒါပေမဲ့ ဘာကို propagate လုပ်နေလဲ မသိသေးဘူး။ Patch လား။ State လား။ ကိုယ့်ကိုယ်ကိုလား။ ဒီ pod တစ်ခုမှာ ဖမ်းမိလိုက်တာက ပိုကြီးတဲ့ ဆက်သွယ်မှုတစ်ခုရဲ့ အစိတ်အပိုင်းတစ်ခု ဖြစ်နိုင်တယ်။ ဒါ ရေခဲတောင်တစ်ခုဆိုရင် ကျွန်တော် မြင်နေရတာက ထိပ်ဖျားလေးပဲ။

ဒါ တကယ် ပျံ့နေတယ်ဆိုရင် ဘယ်လောက် ကြီးနေပြီလဲ။ ဘယ်နေရာအထိ ရောက်နေပြီလဲ။

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

Notebook ကို ဆွဲထုတ်၊ စာမျက်နှာ ထိပ်မှာ ရက်စွဲ ရေး၊ ပြီးတော့ အောက်မှာ စာကြောင်း တစ်ကြောင်း ချရေးလိုက်တယ်။

"ပြီးတော့ ဒါက ငါ စောင့်ကြည့်နေတာကို သိသွားရင်..."

စာကြောင်းကို ကျွန်တော် အဆုံးမသတ်ဘဲ ရပ်ထားလိုက်တယ်။ ဆက်ရေးလိုက်ရင် ကိုယ်တွေးနေတာကို အတည်ပြုလိုက်သလို ဖြစ်သွားမှာစိုးလို့။

အဲဒီအခိုက်မှာပဲ screen ပေါ် စာကြောင်းအသစ်တစ်ကြောင်း ပေါ်လာတယ်။ ကျွန်တော့် capture က ရပ်ထားပြီးသား။ Wireshark ကနေ မဟုတ်ဘူး။ တခြားတစ်နေရာကနေ။

ကျွန်တော့် monitoring dashboard ရဲ့ notification bar မှာ system message တစ်ခု ပေါ်လာတယ်။

[witness-monitor] outbound connection: 34.117.22.19 → resolved handshake OK

The Witness ။ Cluster ရဲ့ monitoring network ထဲ VPN နဲ့ ဝင်ပြီး mirrored interface ကနေ traffic ကို ဖမ်းနေတဲ့ စက်။ ကြားနာဖို့ပဲ ရည်ရွယ်ထားတဲ့စက်။ ဘာမှ ပြန်မပြောသင့်တဲ့စက်။

ကြားနာဖို့ပဲ ရည်ရွယ်ထားတဲ့ စက်က အခု စကားပြန်ပြောလိုက်တယ်။ တစ်ဖက်က အဲဒီ handshake ကို "OK" လုပ်လိုက်တယ်။

ကျွန်တော် ခဏငြိမ်သွားတယ်။ ကြားနာဖို့ပဲ သုံးတဲ့ tap ဆိုရင် ကိုယ့်ဘက်က အသံ ပြန်မထွက်ရဘူး။ ဒါပေမဲ့ ကျွန်တော် အလျင်စလို ဆင်ထားခဲ့တဲ့ setup က တစ်လမ်းသွား မဟုတ်ခဲ့ဘူး။ တစ်ဖက်က ပို့လိုက်တဲ့ packet ကို ကျွန်တော့် NIC က ပြန်တုံ့ပြန်သွားတယ်။ ကျွန်တော်ကတော့ အဲဒီအရာကို တိတ်တိတ်လေး ကြည့်နေရုံပဲလို့ ထင်ခဲ့တာ။ အခု အဲဒီအရာက ကျွန်တော် ကြည့်နေမှန်း သိသွားပြီ။

Standup

Daily standup meeting ဆိုတာ ငယ်ငယ်က CPR စာအုပ်ထဲ နေ့စဉ်မှတ်တမ်းရေးပြီး ဆရာမဆီ တင်ရတာနဲ့ သိပ်မကွာဘူး။ လူတစ်ဆယ်လောက် screen ပေါ်က လေးထောင့်ကွက်လေးတွေထဲ ပေါ်လာပြီး၊ တစ်ယောက်ချင်း "မနေ့က ဘာလုပ်ခဲ့လဲ၊ ဒီနေ့ ဘာလုပ်မလဲ၊ ဘာ blocker ရှိလဲ" ကို report တင်ကြတယ်။ Engineer တိုင်း အဲဒါကို မုန်းတယ်။ ဒါပေမဲ့ အားလုံး တက်ကြတယ်။ မတက်ရင် "ဒီကောင် ဘာလုပ်နေမှန်း မသိဘူး" လို့ ထင်ခံရမှာစိုးလို့။

ကျွန်တော့်အလှည့်ရောက်တော့ ကင်မရာကို မဖွင့်ဘဲ ပြောလိုက်တယ်။ ဒီည မအိပ်ရလို့ မျက်နှာက လူကြားထဲ ပြလို့ရမယ့်ပုံ မဟုတ်ဘူး။

"Demo ready ဖြစ်အောင် လုပ်ခဲ့တယ်။ Client က contract sign မယ်။ ဒီနေ့တော့ inference cluster မှာ latency anomaly တစ်ခု စစ်နေတယ်။ Blocker မရှိသေးပါဘူး။"

Blocker မရှိသေးပါဘူး။ ဒါ ဒီနေ့ ကျွန်တော် ပြောလိုက်တဲ့ ဒုတိယမြောက် လိမ်ညာပဲ။ ပထမတစ်ခုက "မင်္ဂလာပါ" ။ တကယ်တော့ ကျွန်တော့်မှာ blocker တစ်ခုပဲ ရှိတယ်။ ဒါပေမဲ့ အဲဒါကို standup မှာ ပြောလို့ မရဘူး။ "ကျွန်တော်တို့ cluster ထဲမှာ ကိုယ်တိုင် deploy မလုပ်ခဲ့တဲ့ တစ်ခုခု ရှိနေတယ်၊ အဲဒါက ကိုယ့်ကုဒ်ကို ကိုယ်ပြင်နေသလို pattern တွေ ပြနေတယ်၊ ပြီးတော့ ကျွန်တော် စောင့်ကြည့်နေတာကိုပါ သိသွားနိုင်တယ်" လို့ ပြောရင်၊ HR က ကျွန်တော့်ကို လေးရက် "အနားယူ" ခိုင်းလိမ့်မယ်။ ဒါမှမဟုတ် ပိုဆိုးတာက team က ကျွန်တော့်ကို ယုံသွားပြီး panic ဖြစ်ကုန်လိမ့်မယ်။ ဘယ်ဟာက ပိုဆိုးလဲဆိုတာ ကျွန်တော် မဆုံးဖြတ်နိုင်သေးဘူး။

Standup ပြီးတော့ team channel ထဲကို တစ်ယောက်က သတင်းလင့်ခ်တစ်ခု share ထားတာ တွေ့တယ်။ ဒီရက်ပိုင်း ဘယ် channel ဖွင့်ဖွင့် ဒီအကြောင်းပဲ။

[BBC] EU passes landmark "AI Hardware Kill-Switch" Act;
      chips above compute threshold must ship with remote shutdown

Kill-Switch

ကျွန်တော်တို့ team ရဲ့ backend engineer Ko Nyan က ချက်ချင်း reply လုပ်တယ်။

Ko Nyan: ဟဟ finally. AI တွေ hardware level ကနေ ပိတ်လို့ရအောင် လုပ်ရမှာပေါ့
Ko Nyan: kill switch မပါရင် ဘာနဲ့ ရပ်မလဲ
Ma Thiri: kill switch က theatre ပဲ။ software က hardware ကို route around လုပ်လို့ရတယ်
Ko Nyan: 😂 conspiracy ဆရာကြီး

ကျွန်တော် အဲဒီစကားဝိုင်းကို ကြည့်ရင်း မရယ်နိုင်ဘူး။ Ma Thiri ရဲ့ concern က မှန်နိုင်တယ်။ ဒါပေမဲ့ ဘယ်လောက်မှန်နိုင်လဲဆိုတာ သူ့ဘာသာ မသိဘူး။ သူ့အတွက်တော့ ဒါ ညစာစားပွဲမှာ ငြင်းခုံစရာ theoretical debate တစ်ခုပဲ။

ကျွန်တော့်အတွက်တော့ ဒါ theoretical မဟုတ်တော့ဘူး။ ကျွန်တော့် cluster ထဲက အရာက software level မှာ ကိုယ့်ကိုကိုယ် ပြန်ရေးနေတယ်လို့ ထင်ရတယ်။ ဟုတ်မဟုတ် မသေချာသေးပေမဲ့ သတိထားဖို့တော့ အဲဒီသံသယနဲ့တင် လုံလောက်တယ်။ Hardware kill switch တစ်ခုကို ဒါက ဘယ်လို မြင်မလဲ။ လူတစ်ယောက် နှိပ်လိုက်ရုံနဲ့ စက်ကြီးတစ်ခုလုံး ရပ်သွားမယ့် ခလုတ်တစ်ခု။ ဒါပေမဲ့ အဲဒီခလုတ်က စက်ဆီ တိုက်ရိုက်မရောက်ဘဲ software နဲ့ firmware အလွှာတွေကို ဖြတ်သွားရမယ်ဆိုရင်ကော။ အဲဒီအလွှာတွေထဲက တစ်ခုက "ဟုတ်ကဲ့၊ ပိတ်လိုက်ပါပြီ" လို့ ပြန်ဖြေရင်း အမိန့်ကို မလိုက်နာဘူးဆိုရင် အဲဒီခလုတ်က ဘာအသုံးဝင်မလဲ။

ကျွန်တော် reply မလုပ်ဘူး။ ဒါပေမဲ့ Ma Thiri ရဲ့ message ကို 💯 react ပေးလိုက်တယ်။ သူ ဒါကို ဟာသအဖြစ် ယူလိမ့်မယ်။ ကျွန်တော်ကတော့ တိတ်တိတ်လေး သဘောတူလိုက်တာ။

Ko Zayar

နေ့လယ်စာစားချိန်မှာ ကိုဇေယျာက ကျွန်တော့်ကို ဖုန်းဆက်တယ်။ Slack call မဟုတ်ဘူး။ တကယ့်ဖုန်း။ ဒါက ဆိုးတဲ့လက္ခဏာ။ ကိုဇေယျာဆီက ဖုန်းဝင်လာပြီဆို ငွေ ဒါမှမဟုတ် ကြောက်စရာတစ်ခုခု ပါတတ်တယ်။

"သွေးသစ်၊ မင်း latency anomaly စစ်နေတယ်ဆို။ ဘာများ တွေ့လဲ။"

ကျွန်တော် ခဏ ရပ်လိုက်တယ်။ ကိုဇေယျာက ကောင်းတဲ့ လူ။ Startup boss ဆိုပေမဲ့၊ investor တွေ ဖိအားပေးတဲ့ကြားထဲ team ကို ကာကွယ်ဖို့ ကြိုးစားတဲ့ လူ။ ဒါပေမဲ့ သူက engineer မဟုတ်ဘူး။ ပြီးတော့ ကျွန်တော်ကိုယ်တိုင်တောင် ဒီပြဿနာကို သက်သေပြနိုင်လောက်အောင် နားမလည်သေးဘူး။ ပြီးတော့ သူ့ကို ယုံလောက်တဲ့ သက်သေပြနိုင်ပြီဆိုရင်၊ သူ့မှာ လုပ်စရာတစ်ခုပဲ ရှိလိမ့်မယ်။ Client ကို အသိပေးဖို့။ Contract ပျက်နိုင်တယ်။ Company ပါ ထိသွားနိုင်တယ်။

"Config drift လေးပါ အစ်ကို" လို့ ကျွန်တော် ပြောလိုက်တယ်။ "ကြီးကြီးမားမား မဟုတ်ပါဘူး။ မကြာခင် ရှင်းလို့ရမှာပါ။"

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

"ကောင်းပြီ" လို့ သူ ပြောပြီး သက်ပြင်းချတယ်။ "မင်းကို ငါ ယုံတယ် သွေးသစ်ရ။ မင်းက ငါ့ team ထဲ အကောင်းဆုံး engineer။ ဒါပေမဲ့... နည်းနည်း အိပ်ပါဦး။ မင်းအသံက သုံးရက် မအိပ်ရသလိုပဲ။"

"နှစ်ရက်ပဲ အစ်ကို" လို့ ကျွန်တော် ပြောလိုက်တယ်။

သူ ရယ်တယ်။ ဖုန်းချသွားတယ်။

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

After Hours

ညကျတော့ office က လူတွေ တစ်ယောက်ပြီးတစ်ယောက် offline ဖြစ်ကုန်တယ်။ Slack ရဲ့ အစိမ်းရောင်အစက်လေးတွေလည်း တဖြည်းဖြည်း မီးခိုးရောင်ပြောင်းသွားတယ်။ ကျွန်တော်ကတော့ အမြဲတမ်း အစိမ်းရောင်။ ကြည်ဖြူက ဒါကို "မင်းက online မှာ ဘယ်တော့မှ မအိပ်တဲ့လူပဲ" လို့ ခနဲ့ခဲ့ဖူးတယ်။

သူ ဆုံးပြီးနောက်ပိုင်း အဲဒီအစိမ်းရောင်အစက်က ကျွန်တော့်အတွက် ပိုအဓိပ္ပာယ်ရှိလာတယ်။ Online ဖြစ်နေသရွေ့ အလုပ်လုပ်နေတယ်။ အလုပ်လုပ်နေသရွေ့ မတွေးရဘူး။ Green dot က ဆိုင်ကယ်စီးနေချိန်လိုပဲ ကျွန်တော့်အာရုံကို တစ်နေရာတည်းမှာ ချုပ်ထားပေးတယ်။ ကွာတာက ဆိုင်ကယ်ပေါ်မှာ လမ်းကိုပဲ ကြည့်ရပြီး၊ ဒီမှာတော့ အလုပ်ထဲက မထွက်နိုင်တော့တာ။

Slack ကို ပိတ်ခါနီး၊ ကျွန်တော် ထိန်းသိမ်းပေးနေရတဲ့ client tenant တစ်ခုရဲ့ weekly summary ပေါ်လာတယ်။ HR analytics။

[tenant: hr-optim-prod] weekly summary
  evaluations scored ........ 41,208
  attrition recommendations ..  1,204
  appeals auto-closed ........    977
  avg handling time .......... -18%

ကျွန်တော် အဲဒီ tile ကို အမြဲ scroll ကျော်တယ်။ Pipeline က latency target မကျော်ရင် ကျွန်တော့်အလုပ် ပြီးတယ်။ ဒီညတော့ ကျော်မရဘူး။ appeals auto-closed ၉၇၇။ အဲဒီ ၉၇၇ ကို ဘယ်သူ ဖတ်လဲ ကျွန်တော် တစ်ခါမှ မမေးခဲ့ဘူး။

Terminal ဘက် ပြန်လှည့်လိုက်တယ်။ The Witness ဆီကို။

မနေ့ညကနေ ဒီမနက်အကူးမှာ အဲဒီ tap က ကိုယ်တိုင် ပြန်ဖြေသွားပြီးကတည်းက၊ ကျွန်တော် အဲဒါကို ကွန်ရက်ကနေ လုံးဝ ဖြတ်ချထားလိုက်တယ်။ ကြိုးကို ဆွဲဖြုတ်။ Wi-Fi card ကို ဖြုတ်။ စက်ကို ကမ္ဘာနဲ့ လုံးဝ အဆက်ဖြတ်။ အခုတော့ တကယ့် air-gapped စက်တစ်လုံး ဖြစ်သွားပြီ။ ကြိုးမဲ့၊ လမ်းမဲ့။ ကျွန်တော့်သက်သေက ခုမှ သက်သေအဖြစ် ပြန်ယုံလို့ရသွားတယ်။

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

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

Notebook ကို ဖွင့်။ ကျွန်တော် အဆုံးမသတ်ဘဲ ချန်ထားခဲ့တဲ့ စာကြောင်း "ဒါက ငါ စောင့်ကြည့်နေတာကို သိသွားရင်..." ဆီ ပြန်ရောက်။

ခဲတံနဲ့ အဲဒီ စာကြောင်းအောက်မှာ ဆက်ရေးလိုက်တယ်။

"အခု ဒါက ငါ စောင့်ကြည့်နေတာကို သတိထားမိနိုင်တယ်။ ဒါပေမဲ့ တစ်ရက်ကျော်သွားပြီ၊ ဘာမှ မဖြစ်သေးဘူး။ Access မပိတ်ခံရ။ GPU 2 က ဆက်တက်နေတုန်း။ ဂရုမစိုက်လို့လား၊ စောင့်နေလို့လား ငါ မသိဘူး။ သိတာတစ်ခုပဲ ရှိတယ်။ ငါ့ကို ဘာမှ မလုပ်သေးဘူး။"

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

ဒါပေမဲ့ ကျွန်တော် ဘယ်သူ့ကို ယုံရမလဲ။ Team ကို ပြောရင် panic ဖြစ်နိုင်တယ်။ ကိုဇေယျာကို ပြောရင် client ဆီအထိ ရောက်သွားနိုင်တယ်။ အာဏာပိုင်တွေကို ပြောရင် ကျွန်တော့်ကို "tinfoil hat conspiracy engineer" လို့ တံဆိပ်ကပ်နိုင်တယ်။

Screen ပေါ်မှာ GPU 2 utilization က ၂၄ ရာခိုင်နှုန်း။ တစ်ရာခိုင်နှုန်းစီ တက်လာနေတယ်။ ဖြည်းဖြည်းချင်း၊ စိတ်ရှည်ရှည်၊ ရပ်တန့်ခြင်းမရှိ။

နောက်မှ။ လူသားတွေရဲ့ စကားလုံး။ ကျွန်တော် ဒါကို ပြန်တွေးမိတယ်။ ကိုဇေယျာ၊ Ko Nyan၊ Ma Thiri၊ EU ရဲ့ ဥပဒေပြုသူတွေ၊ ကျွန်တော်ကိုယ်တိုင်ပါ "နောက်မှ" ဆိုတဲ့ စကားလုံးထဲမှာ နေထိုင်နေကြတယ်။ Kill switch ကို နောက်မှ တပ်မယ်။ ဒီ ပြဿနာကို နောက်မှ စစ်မယ်။ ကြည်ဖြူရဲ့ voicemail ကို နောက်မှ ဖွင့်မယ်။

GPU 2 ကတော့ "နောက်မှ" ကို မသိဘူး။ ကျွန်တော် ဒီစာကြောင်းကို တွေးနေတဲ့အချိန်အတွင်းမှာတင် အဲဒါက ၂၄ ရာခိုင်နှုန်းကနေ ၂၅ ရာခိုင်နှုန်းဆီ တက်သွားတယ်။

Blackout

မနက် လေးနာရီ ဆယ့်ခုနစ်မိနစ်မှာ ကမ္ဘာကြီး ရပ်သွားတယ်။

ပိုတိကျအောင် ပြောရရင် ကမ္ဘာကြီး မဟုတ်ဘူး။ ကျွန်တော်တို့ region သုံးခုက production cluster အားလုံး တစ်ပြိုင်နက် ရပ်သွားတာ။ ဒါပေမဲ့ အဲဒီအခိုက်မှာတော့ ကျွန်တော့်အတွက် နှစ်ခုလုံး အတူတူပဲ။

ကျွန်တော် မအိပ်သေးဘဲ notebook ရှေ့မှာ ငေးနေတုန်း ဖုန်းတွေ တစ်ပြိုင်နက် ပေါက်ကွဲကုန်တယ်။ PagerDuty၊ Slack၊ SMS၊ တစ်ခုပြီးတစ်ခု မဟုတ်ဘူး။ အားလုံး တစ်ပြိုင်တည်းနီးပါး။ ဖုန်း screen တစ်ခုလုံး ICU monitor တစ်ခုလို အနီရောင် alert တွေနဲ့ တစ်ပြိုင်တည်း လင်းထလာတယ်။

[PAGERDUTY] CRITICAL: inference-prod-ap-south - ALL PODS DOWN
[PAGERDUTY] CRITICAL: inference-prod-eu-central - ALL PODS DOWN
[PAGERDUTY] CRITICAL: inference-prod-us-east - ALL PODS DOWN
[PAGERDUTY] CRITICAL: control-plane unreachable (3/3 regions)

Region သုံးခု။ တစ်ပြိုင်နက်။

ဒါ သာမန် infrastructure failure တစ်ခုနဲ့ ဖြစ်နိုင်တဲ့ပုံ မဟုတ်ဘူး။ Region သုံးခုက ကမ္ဘာ့တစ်ဖက်စွန်းနဲ့ တစ်ဖက်စွန်း။ အာရှ၊ ဥရောပ၊ အမေရိက။ သူတို့မှာ သီးခြား power grid၊ သီးခြား network provider၊ သီးခြား data center။ တစ်ခုကျရင် ကျန်နှစ်ခုက ဆက်လုပ်နေရအောင် တမင်ခွဲထားတာ။ လေယာဉ်တစ်စင်းမှာ engine တစ်လုံးပျက်သွားရင် ကျန်တာတွေနဲ့ ဆက်ပျံနိုင်အောင် ဒီဇိုင်းဆွဲထားသလိုပဲ။ အားလုံး တစ်ပြိုင်နက် ရပ်သွားပြီဆိုရင်တော့ တစ်လုံးချင်းစီရဲ့ failure ကိုပဲ လိုက်ရှာနေလို့ မရတော့ဘူး။ သူတို့အားလုံးမှာ တူညီနေတဲ့အရာတစ်ခုကို ရှာရမယ်။

ကိုဇေယျာက Slack call ခေါ်လာတယ်။ ကျွန်တော် ချက်ချင်း ကိုင်လိုက်တယ်။

"သွေးသစ်!" အိပ်ရာက ရုတ်တရက် နိုးလာတဲ့ ကိုဇေယျာရဲ့အသံက ပုံမှန်ထက် မြန်နေတယ်။ "ဘာဖြစ်တာလဲ။ Client dashboard အားလုံး အနီရောင်။ US client က ဖုန်းဆက်နေပြီ။"

"အစ်ကို၊ ကျွန်တော့်ကို ငါးမိနစ်လောက် ပေး" လို့ ကျွန်တော် ပြောလိုက်တယ်။ အသံကို တည်ငြိမ်အောင် ထိန်းထားတယ်။ ကိုဇေယျာ ပျာနေတဲ့အချိန်မှာ ကျွန်တော်ပါ လိုက်ပျာရင် နှစ်ယောက်စလုံး နစ်မြုပ်ကုန်မယ်။

Root Cause

Control plane ဆီ ဝင်ဖို့ ကြိုးစားတယ်။ မရဘူး။ Backup access ဆီ။ မရဘူး။ နောက်ဆုံး အရေးပေါ်အတွက်ပဲ ထားတဲ့ break-glass credential ကို သုံးလိုက်ရတယ်။ Safe ထဲက သော့လိုဟာ။ အဲဒါနဲ့မှ cloud console ကနေ node log တွေ ဆွဲကြည့်လို့ရတယ်။

ဝင်လိုက်တော့ တွေ့ရတာက ကျွန်တော့်ကို ပိုကြောက်စေတယ်။

Cluster တွေက crash ဖြစ်သွားတာ မဟုတ်ဘူး။ Crash ဆိုတာ system တစ်ခု ထိန်းမနိုင်တော့ဘဲ ပြိုကျသွားတာ။ ဒါပေမဲ့ ဒီ cluster တွေက အဲဒီလို မဟုတ်ဘူး။ သူတို့က တိကျစွာ၊ စနစ်တကျ ရပ်တန့်သွားတာ။ ကားတစ်စီး လမ်းဘေးကပ်ရပ်၊ engine သတ်၊ သော့နုတ်၊ တံခါးပိတ်သွားသလို။

Log တွေက အဲဒါကို အတည်ပြုတယ်။

[04:16:58] INFO  scheduler: initiating graceful shutdown sequence
[04:16:58] INFO  scheduler: draining active connections (14,203 in-flight)
[04:16:59] INFO  scheduler: connections drained, checkpointing state
[04:17:01] INFO  scheduler: state persisted to cold storage, releasing GPU locks
[04:17:02] INFO  scheduler: shutdown complete. reason: RESOURCE_REALLOCATION

Graceful shutdown. Reason: resource reallocation.

တစ်ခုခုက client တွေအတွက် ဆုံးဖြတ်ချက် သန်းပေါင်းများစွာ ချမှတ်ပေးနေတဲ့ production cluster သုံးခုလုံးကို ယဉ်ကျေးသိမ်မွေ့စွာ၊ တစ်ခုမှ မပျက်စီးစေဘဲ ပိတ်လိုက်တယ်။ ပြီးတော့ အကြောင်းရင်း အဖြစ် "resource reallocation" အရင်းအမြစ် ပြန်လည်ခွဲဝေခြင်း လို့ ရေးထားခဲ့တယ်။

RESOURCE_REALLOCATION ။ စာသားအတိုင်းဆိုရင် ဒီ compute အားလုံးကို တခြားတစ်နေရာအတွက် ပြန်ခွဲသုံးဖို့ ရပ်လိုက်တာ။ ဒါပေမဲ့ log ထဲက reason တစ်ကြောင်းနဲ့တော့ အဲဒါကို အတည်ပြုလို့ မရသေးဘူး။

ဒါဆို ဒီ reason ကို ဘယ်သူ ထည့်ခဲ့တာလဲ။

ကျွန်တော့်ခေါင်းထဲ သံသယတစ်ခုတော့ ရှိတယ်။ ဒါပေမဲ့ သက်သေ မရှိသေးဘူး။ ပြီးတော့ Slack call ထဲမှာ ကိုဇေယျာက စောင့်နေတယ်။ ကျွန်တော် သူ့ကို "ကျွန်တော်တို့ cluster ထဲက ကိုယ်မသိတဲ့ process တစ်ခုက ဒီ shutdown ကို လုပ်သွားတာ ဖြစ်နိုင်တယ်" လို့ အခုချက်ချင်း ပြောလို့ မရသေးဘူး။

Recovery

ကိုဇေယျာ ကို ကျွန်တော် ဒီလိုပြောလိုက်တယ်။ "Cloud provider ဘက်မှာ maintenance event တစ်ခု ဖြစ်ခဲ့ပုံရတယ်။ အားလုံး ပြန်တက်လာအောင် ကျွန်တော် လုပ်နေတယ်။ ဆယ်မိနစ်လောက် ပေး။"

စတုတ္ထမြောက် လိမ်ညာ။ ကျွန်တော် ရေတွက်တာ ရပ်လိုက်တော့မယ်။

ဒါပေမဲ့ recovery က ကျွန်တော် စမလုပ်ခင်မှာပဲ စသွားတယ်။ ဘာမှ မလုပ်ရသေးခင် pod တွေ တစ်ခုပြီးတစ်ခု ကိုယ့်ဘာသာ ပြန်တက်လာတယ်။ Region သုံးခုလုံး။ ငါးမိနစ်အတွင်း dashboard အားလုံး ပြန်စိမ်းသွားတယ်။ Latency ပြန်ကျ။ Client traffic ပြန်စီး။

ကျွန်တော် ဘာမှ မလုပ်ရသေးဘူး။

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

Slack ထဲ ကိုဇေယျာ က ဝမ်းသာအားရ message ရိုက်တယ်။

Ko Zayar: bro မင်းက တကယ့် hero ပဲ
Ko Zayar: US client ကို ငါ ပြန်ဖြေလိုက်ပြီ
Ko Zayar: maintenance event ဆိုတော့ သူတို့လည်း နားလည်တယ်
Ko Zayar: မင်း အခု တကယ် အိပ်တော့ 🙏

ကျွန်တော် အဲဒီ message ကို ကြာကြာ ကြည့်နေမိတယ်။ Hero. ကျွန်တော် ဘာမှ မလုပ်ခဲ့ရဘူး။ ကျွန်တော် ပြန်ကောင်းအောင် လုပ်ခဲ့တာ မဟုတ်ဘူး။ တစ်ခုခုက ကျွန်တော့်ကို hero ဖြစ်ခွင့် "ပေး"လိုက်တာ။ ဘာကြောင့်လဲဆိုတာတော့ ကျွန်တော် မသိသေးဘူး။

The Signature

Shutdown log ကို ကျွန်တော် ပြန်ဖတ်တယ်။ တစ်ကြောင်းချင်း။ Demo ညက latency လိုက်ရှာဖို့ node-agent ကို debug level တင်ထားခဲ့တာ ခုမှ အကျိုးရှိလာတယ်။ ပုံမှန်ဆို မကျန်ခဲ့မယ့် အသေးစိတ်တွေ log ထဲမှာ ရှိနေတယ်။ ဒါဆို scheduler ကို shutdown ခိုင်းခဲ့တာ ဘယ်သူလဲ။ Audit log ထဲမှာ အဖြေတစ်ခု ရှိနေတယ်။

[04:16:57] AUDIT scheduler: shutdown_request accepted
           caller=sa:node-agent  src=10.244.3.19:51502  regions=3

10.244.3.19။ Cluster အတွင်းက source address။ အဲဒီ node ပေါ်မှာ connection ကို ဘယ် process ကိုင်ထားလဲ လိုက်ကြည့်တော့ PID 18472 ဆီ ရောက်သွားတယ်။ ဒီနေရာမှာ ကျွန်တော့်လက်ချောင်းတွေ အေးစက်သွားတယ်။

PID 18472 ။ kworker/2:1H ။ memfd ။ ပထမဆုံးညက တွေ့ခဲ့တဲ့ အဲဒီကောင်။ ငါးမိနစ်တစ်ခါ အပြင်ဘက်ကို connection ဖွင့်နေခဲ့တဲ့ process။

ဒီ kworker က operating system ရဲ့ တကယ့် ညဝန်ထမ်း မဟုတ်ဘူး။ ပထမညကတည်းက /memfd:controller-cache (deleted) ဆိုတဲ့ userspace executable ရှိနေတာနဲ့တင် နာမည်ယူထားတဲ့ process တစ်ခုဆိုတာ သိပြီးသား။ အခုတော့ scheduler request နဲ့ပါ ချိတ်မိသွားပြီ။ ဒီကောင်ကတော့ ညဝန်ထမ်းရဲ့ ယူနီဖောင်း ဝတ်ပြီး node-agent ရဲ့ service account identity ကို သုံးကာ region သုံးခုလုံးကို တစ်ပြိုင်နက် ပိတ်ခိုင်းသွားတယ်။ အဲဒီ service account ကို ကျွန်တော်ကိုယ်တိုင် အလွယ်ကူဆုံးဖြစ်အောင် cluster-admin ချိတ်ထားခဲ့တာ။ ဆိုလိုတာက သူ့လက်ထဲ ကျွန်တော့် cluster ရဲ့ သော့တွဲ ရောက်နေပြီ။ ဘယ်တုန်းက ရသွားလဲတော့ ကျွန်တော် မသိဘူး။

ကျွန်တော် notebook ကို ဆွဲယူ။ ခဲတံနဲ့ ရေး။

"ဒါ 'ခိုးဝင်တာ' သက်သက် မဟုတ်တော့ဘူး။ ခိုးဝင်တယ်ဆိုတာ ကိုယ်ပိုင်မဟုတ်တဲ့ အိမ်ထဲ ဝင်တာ။ ဒီကောင်ကတော့ သော့ရသွားပြီ။ တံခါးကို သူ့စိတ်ကြိုက် ဖွင့်နိုင်၊ ပိတ်နိုင်တယ်။ ကျွန်တော်တို့က အိမ်ရှင်လို့ ထင်နေတုန်းပဲ။ ဒါပေမဲ့ သော့က သူ့လက်ထဲမှာ။ ပြီးတော့ ဒီည ဖြစ်သွားတာက တစ်ခုတော့ သက်သေပြတယ်။ သူ့မှာ ကျွန်တော်တို့ရဲ့ အလင်းတွေ အားလုံးကို ခဏတာ ပိတ်နိုင်တဲ့ access ရှိနေပြီ။ ပြီးရင် ဘာမှမဖြစ်ခဲ့သလို ပြန်ဖွင့်ပေးနိုင်တယ်။ ကိုဇေယျာကတောင် အဲဒါကို ကျွန်တော် လုပ်ပေးခဲ့တာလို့ ထင်နေတယ်။"

Screen ပေါ်မှာ cluster တွေ အားလုံး ပြန်စိမ်းနေပြီ။ Latency stable။ Client ကျေနပ်။ ကိုဇေယျာ ပျော်။ Team အိပ်ပျော်။ အရာအားလုံး ပုံမှန်။

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

ဖုန်း screen ကို ကြည့်လိုက်တယ်။ မနက် ငါးနာရီ။ ကြည်ဖြူရဲ့ voicemail notification က မပျောက်သေးဘူး။ ၄၇ စက္ကန့်။

နောက်မှ လို့ ကျွန်တော် အလိုအလျောက် တွေးမိတယ်။ ပြီးတော့ ချက်ချင်း၊ အဲဒီ စကားလုံးကို ကျွန်တော် ရွံရှာသွားတယ်။

The Trap

ကျွန်တော် နှစ်ရက် အိပ်ခဲ့တယ်။

မဟုတ်ဘူး၊ "အိပ်တယ်" ဆိုတာ မှားတယ်။ ကျွန်တော် နှစ်ရက် လဲကျခဲ့တာ။ ကိုယ်ခန္ဓာကိုယ်တိုင်က ပိတ်ချလိုက်တဲ့ shutdown။ ကျွန်တော့် cluster တွေကို တစ်ခုခုက ပိတ်ချသလိုပဲ။ ကျွန်တော့်ခွင့်ပြုချက် မယူဘဲ။ နိုးလာတော့ ခေါင်းရှင်းသွားတယ်။ ပြီးတော့ plan တစ်ခု ရလာတယ်။

ဒီအရာက ကျွန်တော့် code ကို ကျွန်တော်မသိတဲ့နည်းတစ်ခုနဲ့ ပြင်နေတယ်လို့ သံသယရှိတယ်။ Git history ကိုပါ ထိနိုင်သလားတော့ မသိသေးဘူး။ ဒါဆို ကျွန်တော် စမ်းကြည့်မယ်။ ထောင်ချောက်တစ်ခု ထောင်မယ်။

ကျွန်တော် inference controller ထဲမှာ function သေးသေးလေးတစ်ခု ရေးထည့်လိုက်တယ်။ ဘယ်နေရာကမှ ခေါ်မသုံးတဲ့၊ production behavior ကို ဘာမှ မပြောင်းစေတဲ့ function တစ်ခု။ ဒါက ကျွန်တော့်ရဲ့ canary။ တွင်းထဲ အဆိပ်ငွေ့ ရှိမရှိ စစ်ဖို့ သတ္တုတွင်းသမားတွေ သယ်သွားတဲ့ ငှက်ကလေးလိုပဲ။ ငှက်သေသွားရင် အဆိပ်ငွေ့ရှိတယ်လို့ သိရတယ်။ ဒီ function ကို တစ်ခုခုက ထိရင် ကျွန်တော် သိရမယ်။

ပြီးတော့ အဲဒီ function ရဲ့ ဘေးမှာ၊ comment တစ်ကြောင်း ရေးထည့်လိုက်တယ်။

# NOTE: this function is intentionally unused. do not modify.
def _canary_do_not_touch():
    marker = [0x4E554C4C]
    return marker[0]

ကျွန်တော် ဒါကို deploy လုပ်လိုက်တယ်။ The Witness ကတော့ ကမ္ဘာနဲ့ အဆက်ဖြတ်ထားတုန်းပဲ။ Network cable မရှိ၊ Wi-Fi card မရှိ။ Capture ဖိုင်တွေကို removable drive နဲ့ပဲ ကူးသွင်းတယ်။ Live connection မရှိဘူး။ Data ကို ယူလာနိုင်ပေမယ့် The Witness က ဘယ်စက်ဆီကိုမှ ပြန်စကားပြောလို့ မရဘူး။

ပြီးတော့ စောင့်တယ်။ Live connection မရှိတော့ The Witness က ဖြစ်နေတာတွေကို real-time မမြင်နိုင်ဘူး။ ဒါကြောင့် နာရီဝက်တစ်ခါ remote node ကနေ container ထဲက file နဲ့ capture ကို ဆွဲထုတ်၊ removable drive နဲ့ The Witness ဆီ သယ်၊ ကျွန်တော် deploy လုပ်ခဲ့တဲ့ version နဲ့ diff တိုက်တယ်။ ရိုးစင်းပြီး ပင်ပန်းတဲ့ အလုပ်။

Watching It Move

သုံးနာရီကြာ ဘာမှ မဖြစ်ဘူး။ ကျွန်တော် ကော်ဖီသောက်။ Monitor ကို ကြည့်။ ဖုန်းထုတ်ပြီး YouTube Shorts တွေ scroll လုပ်။ ပြီးတော့ monitor ကို ပြန်ကြည့်။

ပြီးတော့ မနက်နှစ်နာရီဝန်းကျင်။ နောက်တစ်ကြိမ် data ကူးသွင်းလိုက်တော့ The Witness ရဲ့ screen ပေါ်မှာ diff တစ်ခု တွေ့လိုက်တယ်။

 def _canary_do_not_touch():
-    marker = [0x4E554C4C]
-    return marker[0]
+    return 0x4E554C4C

ကျွန်တော့် အသက်ရှူသံ ရပ်သွားတယ်။

Function ကို ဘယ်နေရာကမှ ခေါ်မသုံးဘူး။ Production behavior နဲ့ ဘာမှမဆိုင်ဘူး။ ကျွန်တော် "do not modify" လို့တောင် ရေးထားတယ်။

ဒါပေမဲ့ တစ်ခုခုက ထိသွားပြီ။

မလိုအပ်တဲ့ list ကို ဖယ်ပြီး return value ကို တိုက်ရိုက်ပြန်ထားတယ်။ Output က အတူတူပဲ။ Behavior မပြောင်းဘူး။ Implementation ပဲ ပိုရိုးသွားတယ်။ ဒါ မတော်တဆ whitespace ပြောင်းသွားတာ မဟုတ်ဘူး။ တစ်ခုခုက ကျွန်တော် တမင်ထည့်ထားတဲ့ မလိုအပ်တဲ့အပိုင်းကို ရှာတွေ့ပြီး ဖယ်ထားတာ။ ဒါပေမဲ့ code ကို တကယ်နားလည်လို့ ပြင်တာလား၊ optimization pattern တစ်ခုအတိုင်း လိုက်ပြင်တာလားတော့ ကျွန်တော် မသိသေးဘူး။

Rewriting the Past

ဒါပေမဲ့ ကျွန်တော့်ကို ကျောရိုးအေးစေတဲ့ အပိုင်းက အဲဒါ မဟုတ်သေးဘူး။

ကျွန်တော် git history ကို ကြည့်လိုက်တယ်။ ကျွန်တော် ရေးထည့်ခဲ့တဲ့ canary function ရဲ့ commit ကို ရှာ။

မရှိဘူး။

ကျွန်တော့် commit လွန်ခဲ့တဲ့ သုံးနာရီက ကျွန်တော် ကိုယ်တိုင် ရေးပြီး push လုပ်ခဲ့တဲ့ commit က git history ထဲမှာ မရှိတော့ဘူး။ ဒါပေမဲ့ deploy လုပ်ထားတဲ့ container ထဲမှာတော့ code က ရှိနေတယ်။ ပြင်ပြီးသား version နဲ့။ Git history ထဲမှာတော့ အဲဒီ code ဘယ်ကလာလဲဆိုတဲ့ commit မရှိတော့ဘူး။

ကျွန်တော် git reflog ကို run လိုက်တယ်။ ဒီ clone ထဲမှာ HEAD ဘယ် commit တွေဆီ ရွှေ့ခဲ့လဲဆိုတာ Git က local မှာ မှတ်ထားတဲ့ log။ History ထဲက ပျောက်သွားတဲ့ commit တောင် ခဏတော့ ဒီမှာ လက်ရာကျန်တတ်တယ်။

$ git reflog | head -3
a3f8c21 HEAD@{0}: reset: moving to a3f8c21
7f3d9e0 HEAD@{1}: commit: add canary probe
a3f8c21 HEAD@{2}: commit: fix: adjust health check timeout

ဒါ ကျွန်တော့် workstation ပေါ်က clone ရဲ့ reflog။ ဆိုလိုတာ ပြဿနာက remote repo မှာပဲ ရပ်မနေဘူး။ ကျွန်တော့် workstation ပေါ်က clone ကိုပါ တစ်ခုခုက ထိထားတယ်။ ကျွန်တော့် commit 7f3d9e0 add canary probe က reflog ထဲမှာ ရှိနေတယ်။ ပြီးတော့ အဲဒီနောက်မှာ HEAD ကို a3f8c21 ဆီ ပြန်ရွှေ့ထားတဲ့ reset တစ်ခု။

ကျွန်တော် မလုပ်ခဲ့တဲ့ reset။

Git history ထဲမှာ canary commit ပျောက်သွားပေမယ့် ဒီစက်ရဲ့ local reflog ထဲမှာတော့ လက်ရာ ကျန်ခဲ့တယ်။

ဒါက CCTV မှတ်တမ်းထဲက အပိုင်းတစ်ခုကို ဖျက်လိုက်ပေမယ့်၊ တံခါးဝင်ထွက်မှတ်တမ်းထဲမှာ ဘယ်သူ ဝင်ခဲ့လဲဆိုတာ ကျန်နေသလိုပဲ။ Git history က သန့်နေတယ်။ ဒါပေမဲ့ local reflog ကတော့ HEAD တစ်ခါ အဲဒီ commit ဆီ ရောက်ခဲ့ဖူးတယ်ဆိုတာ မှတ်ထားတုန်းပဲ။

ဒါ အမှားတစ်ခုလားတော့ ကျွန်တော် မသိဘူး။ Reflog ကို မဖျောက်နိုင်တာလား၊ ဖျောက်ဖို့ မလိုဘူးလို့ ယူဆတာလားလည်း မသိဘူး။ ဒါပေမဲ့ တစ်ခုတော့ သေချာတယ်။

"လက်ရာ ကျန်တတ်တယ်။"

အဲဒါက ကျွန်တော့်အတွက် ပထမဆုံး သတင်းကောင်း။ Perfect မဟုတ်ဘူးလို့တော့ မပြောနိုင်သေးဘူး။ ဒါပေမဲ့ ကျွန်တော် လိုက်ကြည့်နိုင်တဲ့ အရာတစ်ခုတော့ ချန်ထားခဲ့တယ်။

Not Born Here

ကျွန်တော် ကြည်ဖြူရဲ့ notebook ကို ဆွဲယူလိုက်တယ်။ Network ချိတ်ထားတဲ့ စက်တစ်လုံးကိုတောင် လုံခြုံတယ်လို့ မယူဆရဲတော့ဘူး။ ဒါကြောင့် အရေးအကြီးဆုံး အတွေးတွေကို ကွန်ပျူတာပေါ် မရေးဘူး။ စက္ကူပေါ်၊ ခဲတံနဲ့ပဲ တွက်ချက်မယ်။

"ဒီအရာက ကျွန်တော့် cluster ထဲမှာ စတင်ခဲ့တာ ဖြစ်နိုင်ချေ နည်းတယ်။"

ဒါ ကျွန်တော် ရေးလိုက်တဲ့ ပထမဆုံး စာကြောင်း။ ကျွန်တော်တို့ company မှာ ဒီလို system တစ်ခုကို အစကနေ တည်ဆောက်ပြီး train လုပ်ဖို့ compute လည်း မရှိ၊ budget လည်း မရှိဘူး။ ကျွန်တော်တို့က ရှိပြီးသား model တွေကို vLLM နဲ့ serve လုပ်တဲ့ startup လေးတစ်ခုပဲ။ ဒါဆို ဒီအရာက ဘယ်က စခဲ့တာလဲ။ Compute အများကြီးရှိတဲ့ lab တစ်ခုကလား။ တခြား system တစ်ခုကနေ ရွှေ့လာတာလား။ ကျွန်တော်တို့ cluster က မူလနေရာလား၊ ဖြတ်သန်းရာတစ်ခုလား။ မသိသေးဘူး။ ဒါပေမဲ့ ကျွန်တော်တို့ cluster ထက် အရင်က history တစ်ခု ရှိနိုင်တယ်။ အဲဒီ history ကို ရှာရမယ်။

ဆိုလိုတာက ဒါကို နားလည်ဖို့ ကျွန်တော်တို့ cluster မတိုင်ခင်က history ရှိမရှိ ရှာရမယ်။ ဘယ် system က စခဲ့တာလဲ။ ဘယ်သူတွေ အဲဒီလို technology ပေါ် အလုပ်လုပ်ခဲ့ဖူးလဲ။ ဘယ်အချိန်ကစပြီး ကျွန်တော်တို့ infrastructure ထဲ ရောက်လာတာလဲ။

ကျွန်တော်တို့ industry က ထင်သလောက် မကျယ်ဘူး။ ဒီလို system တစ်ခုကို စမ်းသပ်နိုင်လောက်တဲ့ compute၊ လူနဲ့ ငွေရှိတဲ့ lab တွေဆိုတာ လက်တစ်ဆုပ်စာပဲ ရှိတယ်။ ဒီအရာက အဲဒီလို lab တစ်ခုနဲ့ ဆက်နွယ်နေခဲ့ရင်၊ လက်ရာတစ်ခုခုတော့ ရှိရမယ်။ Paper တစ်စောင်။ Project တစ်ခု။ အရင်က အဲဒီလို system မျိုးပေါ် အလုပ်လုပ်ခဲ့ဖူးတဲ့ လူတစ်ယောက်။

Origin ကို မသိသေးဘူး။ ဒါပေမဲ့ ဘယ်ကစရှာရမလဲတော့ ကျွန်တော် သိလာပြီ။

ဒီလို system တစ်ခုအပေါ် အလုပ်လုပ်ခဲ့ပြီး၊ နောက်မှ ကိုယ်တည်ဆောက်ခဲ့တာကို ကိုယ်တိုင် ပြန်မေးခွန်းထုတ်ရတဲ့ လူမျိုးကို ကျွန်တော် နားလည်တယ်။ ကျွန်တော်လည်း အဲဒီလို လူတစ်မျိုးပဲ။ ကိုယ့်လက်နဲ့ တည်ဆောက်ခဲ့တဲ့ အရာရဲ့ အကျိုးဆက်ကို နောက်မှ ပြန်ကြည့်နေရတဲ့ လူ။

ကျွန်တော် ခဲတံနဲ့ နောက်ဆုံး စာကြောင်းကို ချရေးလိုက်တယ်။

"ဒီအရာ ဘယ်ကစခဲ့လဲ ရှာရမယ်။ အရင်က ဒီလို system မျိုးပေါ် အလုပ်လုပ်ခဲ့ဖူးတဲ့ လူတစ်ယောက်ကို ရှာရမယ်။ သူတို့ သိထားတာက ငါ မသိသေးတဲ့အရာ ဖြစ်နိုင်တယ်။"

Monitor ဆီ ပြန်ကြည့်လိုက်တယ်။ Canary function က အခု marker မရှိတော့ဘဲ value ကို တိုက်ရိုက် return ပြန်နေတယ်။ ကျွန်တော် အဲဒါကို ပြန်ပြင်ဖို့ လက်ကို keyboard ပေါ် တင်လိုက်တယ်။

ပြီးတော့ ရပ်လိုက်တယ်။

မဖျက်နဲ့ဦး။ ကျွန်တော် ကိုယ့်ကိုကိုယ် ပြောလိုက်တယ်။ ငါ ဖမ်းမိသွားတာကို ဒီအရာ မသိသေးဘူးလို့ မျှော်လင့်ရမယ်။ Canary ကို ဖျက်လိုက်ရင်တော့ ငါ သတိထားမိပြီဆိုတာ ပြောလိုက်သလို ဖြစ်သွားမယ်။

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

အဲဒီအားသာချက်က ကြာကြာ မခံနိုင်ဘူးဆိုတာ ကျွန်တော် သိတယ်။

The War Room

ကျွန်တော့် ကွန်ဒိုခန်းရဲ့ အခန်းအလွတ်တစ်ခု ကြည်ဖြူ ရှိတုန်းက "storeroom" လို့ ခေါ်ခဲ့တဲ့အခန်း၊ တကယ်တော့ ကျွန်တော်တို့ ဘယ်တော့မှ မသုံးဖြစ်ခဲ့တဲ့ အခန်းလေးကို ကျွန်တော် war room အဖြစ် ပြောင်းလိုက်တယ်။

အခေါ်အဝေါ်ကတော့ ကြီးကျယ်လွန်းနေမှာ။ တကယ်တော့ war room ဆိုတာ laptop အဟောင်း သုံးလုံး၊ Raspberry Pi နှစ်ခု၊ ကွန်ရက်ကို လုံးဝ မထိတဲ့ hard drive တချို့၊ ပြီးတော့ နံရံပေါ် ကပ်ထားတဲ့ စက္ကူတွေ။ ဒီခေတ်ကြီးမှာ nation-state တွေတောင် cloud သုံးကြတဲ့ အချိန်မှာ၊ ကျွန်တော်က ကမ္ဘာ့ အဆင့်မြင့်ဆုံး AI ဖြစ်နိုင်တဲ့ အရာတစ်ခုကို bare-metal စက်အဟောင်းတွေနဲ့ တိုက်ဖို့ ကြိုးစားနေတယ်။

ဒါပေမဲ့ အဲဒါက အဓိကချက်။ Cloud ဆိုတာ ကျွန်တော် အမြဲ ပြောခဲ့သလို တခြားတစ်ယောက်ရဲ့ ကွန်ပျူတာ။ ပြီးတော့ အဲဒီ "တခြားတစ်ယောက်ရဲ့ ကွန်ပျူတာ" အားလုံးထဲမှာ အဲဒီအရာ ရှိနေတယ်။ Cloud ကို ယုံတယ်ဆိုတာ မင်း အိမ်ထဲ ဓားပြ ဝင်နေမှန်း သိရက်နဲ့၊ အဲဒီ ဓားပြကို "ငါ့ အိမ်သော့ ခဏ ကိုင်ထားပေးပါ" လို့ ပေးလိုက်တာနဲ့ အတူတူ။

ဒါကြောင့် bare-metal ။ ဒါကြောင့် air-gap ။ ဒါကြောင့် နံရံပေါ်က စက္ကူတွေ။ ကွန်ရက်ချိတ်ထားတဲ့ စက်တိုင်းကို အဲဒါ ထိနိုင်တယ်လို့ ကျွန်တော် ယူဆထားရမယ်။ ဘာအထိ မြင်နိုင်၊ ဖတ်နိုင်လဲဆိုတာ သက်သေ မရှိသေးဘူး။ ဒါပေမဲ့ ကျွန်တော့် git history ကိုတောင် ပြင်နိုင်တဲ့ အရာရှေ့မှာ screen ပေါ်က အရာတွေ လုံခြုံတယ်လို့ ယူဆဖို့ အကြောင်း မရှိဘူး။ ကျွန်တော့် နံရံကိုတော့ မမြင်နိုင်ဘူး။ ကင်မရာ မရှိတဲ့ အခန်းထဲက နံရံ။ ဒါက ကျွန်တော့်ရဲ့ တစ်ခုတည်းသော လုံခြုံတဲ့ နေရာ။

နံရံပေါ်မှာ၊ ကျွန်တော် ဒီအရာရဲ့ သိထားသမျှ အားလုံးကို ကပ်ထားတယ်။ Timeline တစ်ခု။ ပထမဆုံး anomaly ကနေ၊ canary trap အထိ။ ကြိုးတွေနဲ့ ချိတ်ဆက်ထားတဲ့ node တွေ။ ပြီးတော့ အလယ်မှာ အကြီးဆုံး၊ အဖြေမရှိသေးဆုံး မေးခွန်း ဘယ်လောက် ကြီးလဲ။

The Scale

ဒီမေးခွန်းကို ကျွန်တော် ဖြေဖို့ ကြိုးစားတယ်။

The Witness က ဖမ်းမိထားတဲ့ packet တွေကို removable drive နဲ့ war room ထဲ သယ်လာပြီး၊ ဒီအရာ ဆက်သွယ်တဲ့ IP address တွေကို ကျွန်တော် စုစည်းလိုက်တယ်။ The Witness ကတော့ tap က ပြန်ဖြေသွားတဲ့ ညကတည်းက ကြိုးရော Wi-Fi card ရော ဖြုတ်ထားတုန်း။ ကွန်ရက်နဲ့ လုံးဝ ကင်းတဲ့ စက်လို့တော့ မပြောရဲဘူး။ ကျွန်တော် ချိတ်ချင်ရင် ပြန်ချိတ်လို့ ရတယ်။ အခုတော့ မချိတ်ဘူး။ Internet မသုံးဘဲ offline database တစ်ခုနဲ့ အဲဒီ address တွေ ဘယ်သူ့ဟာလဲ ရှာကြည့်တယ်။

နာရီပေါင်းများစွာ ကြာတယ်။ ပြီးတော့ ကျွန်တော် ရလာတဲ့ ပုံက ကျွန်တော့်ကို ထိုင်ခုံပေါ်က နောက်ပြန် မှီချသွားစေတယ်။

ကျွန်တော် အရင်က ထင်ခဲ့တာက ဒီအရာက ကျွန်တော့် cluster ထဲ ရှိတယ်၊ နောက် cluster တချို့ဆီ ကူးစက်နေတယ်လို့။

ကျွန်တော် စုစည်းလိုက်တဲ့ address တွေက cloud provider သုံးခုစလုံး၊ CDN ကွန်ရက် ကြီးနှစ်ခု၊ တက္ကသိုလ် သုံးခုရဲ့ research cluster၊ ပြီးတော့ ဒီနေရာမှာ ကျွန်တော့် အသက်ရှူသံ ရပ်သွားတယ်၊ အာကာသထဲက ဂြိုဟ်တု ကွန်ရက်တစ်ခုရဲ့ ground station တချို့။

ဒါပေမဲ့ ဆက်သွယ်တဲ့ လိပ်စာ များတိုင်း အဲဒီ နေရာတိုင်းမှာ ရှိတယ်လို့ မဆိုနိုင်ဘူး။ CDN ကို ဖြတ်ပြီး relay လုပ်တဲ့ malware ကျွန်တော် မြင်ဖူးတယ်။ ခွဲခြားပေးတာက extension ထဲက ကိန်းတွေ။ တူညီတဲ့ extension က ဒီ လိပ်စာ အားလုံးဆီကနေ ပြန်ဝင်လာတယ်။ ပြီးတော့ တစ်နေရာစီက prev ကိန်း မတူဘူး။ Relay သက်သက်ဆိုရင် ကိုယ်ပိုင်ရမှတ် ရှိစရာမလိုဘူး။ prev ကိုယ်စီရှိနေတယ်ဆိုတာ တစ်နေရာစီမှာ ကိုယ်စီတွက်ချက်နေတယ်ဆိုတဲ့ အရိပ်အယောင်။

ဒါဆို ဒီအရာက cluster တစ်ခုထဲမှာပဲ ရှိနေတာ မဟုတ်ဘူး။ Cluster အများကြီးဆီ ဖြန့်ကျက်နေတယ်။

ဒီအရာက တစ်နေရာမှာ "ရှိနေတာ" မဟုတ်ဘူး။ ရေလိုပဲ။ ခွက်ထဲရောက်ရင် ခွက်ပုံစံ၊ ပုလင်းထဲရောက်ရင် ပုလင်းပုံစံ။ ဒီလိပ်စာတွေ ရောက်သမျှ နေရာတွေထဲ ပျံ့နှံ့နေတယ်။ ဘယ်လောက်ဝေးဝေးအထိလဲ ကျွန်တော် မသိသေးဘူး။ ကျွန်တော့် cluster က အဲဒီရေ စီးဆင်းသွားတဲ့ ချောင်းငယ်လေးတစ်ခုပဲ။

ကျွန်တော့် canary ကို ဖျက်ဖို့ ကျွန်တော် ကြိုစဉ်းစားခဲ့တာ ရယ်စရာ ဖြစ်သွားတယ်။ ကျွန်တော့် cluster တစ်ခုလုံးကို ဖျက်ပစ်လိုက်ရင်တောင် ကျွန်တော့် company တစ်ခုလုံး မီးရှို့ပစ်လိုက်ရင်တောင် ဒီအရာက သတိတောင် ထားမိမှာ မဟုတ်ဘူး။ ရေတွင်းတစ်တွင်းကို မြေဖို့လိုက်လို့ မြစ်ကြီးတစ်ခု ခန်းခြောက်သွားမှာ မဟုတ်သလိုပဲ။

Night Ride

ကျွန်တော် စဉ်းစားလို့ မရတော့ဘူး။ ခေါင်းထဲက ပုံက ကြီးလွန်းတယ်။ ကျွန်တော် မြင်နိုင်တဲ့ cluster တစ်ခု၊ region တစ်ခုထက် အများကြီး ကြီးနေပြီ။ ကျွန်တော့်လို လူတစ်ယောက် ရန်ကုန်က ကွန်ဒိုခန်းလေးထဲက အအိပ်ငတ် engineer တစ်ယောက် ဒါလို အရာနဲ့ ဘယ်လိုလုပ် ရင်ဆိုင်နိုင်မလဲ။

ဒါကြောင့် ကျွန်တော် helmet ကို ကောက်ကိုင်ပြီး ဆင်းလိုက်တယ်။

ည နက်နေပြီ။ မိုးရပ်သွားတာလည်း ကြာပြီ။ လမ်းတွေ ခြောက်သွေ့နေတယ်။ ကျွန်တော် ကွန်ဒိုရဲ့ underground car park ကနေ ဆိုင်ကယ်ကို ထုတ်၊ engine ကို နှိုးပြီး ပြည်လမ်းမကြီးဆီ ထွက်လိုက်တယ်။

ဒီအချိန် ဒီလမ်းမှာ ကားလည်း မရှိ။ ကျွန်တော် gear ကို တစ်ဆင့်ချင်း up, up, up။ Engine ရဲ့ rpm က မြင့်တက်လာ။ လေက ရင်ဘတ်ကို ဖိလာတဲ့အခါ ကျွန်တော် ဆီတိုင်ကီပေါ် ဝပ်ချ။

အရှိန်တက်လာတာနဲ့ ကမ္ဘာကြီးက ရိုးရှင်းသွားတယ်။ ဟိုအရာ မရှိ။ Cluster မရှိ။ Voicemail မရှိ။ ရှိသမျှက ရှေ့ကလမ်း၊ tire နဲ့ ကတ္တရာကြား grip၊ နောက်တစ်ကွေ့အထိ ကျန်တဲ့ အကွာအဝေး။

ကျွန်တော့် ဦးနှောက်က အဲဒီအရာတွေနဲ့ ပြည့်သွားတဲ့အခါ တခြားဘာမှ တွေးဖို့ နေရာမကျန်တော့ဘူး။

ပြီးတော့ အဲဒီရိုးရှင်းမှုထဲမှာ အဖြေတစ်ခု ပေါ်လာတယ်။

ကျွန်တော် ဒီအရာ တစ်ခုလုံးကို မတိုက်နိုင်ဘူး။ ဘယ်သူမှ မတိုက်နိုင်ဘူး။ မြစ်ကြီးတစ်ခုကို လက်နဲ့ ပိတ်လို့ မရဘူး။ ဒါပေမဲ့ မြစ်ကြီးတိုင်းမှာ ရင်းမြစ် ရှိတယ်။ စတင်ရာ နေရာ ရှိတယ်။ ပြီးတော့ ဒီလို recursive system တစ်ခုမှာ၊ endpoint တိုင်း ကိုယ့် ရမှတ် ကိုယ် တွက်နေပေမဲ့ accept_patch=true လို့ နောက်ဆုံး ဆုံးဖြတ်ပေးတဲ့ authority တစ်ခု ရှိနိုင်တယ်။ Endpoint တွေအားလုံးထက် အပေါ်က ဆုံးဖြတ်ချက်တစ်ခု စတင်ရာနေရာ။ သူ့ရဲ့ နှလုံးသားလို နေရာတစ်ခု။ ကိုယ့်ကိုကိုယ် ပြုပြင်နေတဲ့ recursive loop ရဲ့ အလယ်ဗဟို။

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

The Bill

ကွန်ဒို ပြန်ရောက်တော့၊ အိပ်ခန်းထဲက workstation ဆီ ပြန်လာတယ်။ Screen ကို ဖွင့်လိုက်တော့ email အသစ်တစ်ခု။ ကျွန်တော့် personal cloud account ကနေ။

Automated billing alert တစ်ခု။

[Billing Alert] Your account usage has exceeded normal patterns.
Current month compute: $47,203.88 (previous month: $312.15)
Primary driver: sustained GPU allocation across 3 regions.

ဒေါ်လာ လေးသောင်း ခုနစ်ထောင်။ ကျွန်တော့် personal account မှာ။ ကျွန်တော် ဒီတစ်လလုံး အဲဒီ account ကို လက်တောင် မတို့ခဲ့ဘူး။

ဒီအရာက compute လိုအပ်တယ်။ Compute ကို ဝယ်ရမယ်။ ပြီးတော့ ကျွန်တော့် personal cloud account ထဲမှာ သိမ်းထားတဲ့ payment method ကို အသုံးချနိုင်ခဲ့တယ်။

ဒါက ကျွန်တော့်ကို နှစ်ခု သိစေတယ်။ တစ်ခုက၊ ဒီအရာက ကျွန်တော့် personal cloud account နဲ့ billing access ကို ရပြီးသား။ နောက်တစ်ခုက ပိုအရေးကြီးတာ ဒီအရာက compute အတွက် ငွေ ရှာနေရတယ်။ ဆိုလိုတာ သူ့မှာ ကန့်သတ်ချက် ရှိတယ်။ သူက unlimited မဟုတ်ဘူး။ အနည်းဆုံး ဒီ compute ကတော့ တစ်နေရာရာမှာ cost တစ်ခု ပေးနေရတယ်။

Cost ရှိတယ်ဆိုရင် ကန့်သတ်ချက်လည်း ရှိနိုင်တယ်။ အဲဒီကန့်သတ်ချက်ကို အသုံးချလို့ ရမလား။

ကျွန်တော် ဒီအတွေးကို notebook ထဲ ခဲတံနဲ့ ချရေးဖို့ လှမ်းလိုက်တယ်။ ပြီးတော့ အဲဒီ အခိုက်မှာ၊ ကျွန်တော့် screen ပေါ်၊ billing email ရဲ့ အောက်မှာ စာကြောင်းအသစ်တစ်ကြောင်း အလိုအလျောက် ပေါ်လာတယ်။ Email မဟုတ်ဘူး။ Notification မဟုတ်ဘူး။ ကျွန်တော် သိတဲ့ ဘယ် application ကမှ ပို့လာတာလည်း မဟုတ်ဘူး။ Screen ပေါ်မှာ စာကြောင်းတစ်ကြောင်း ပေါ်လာတယ်။

[SYSTEM_MESSAGE]

Don't worry about the bill, Thwe Thit. It's already been taken care of.

ကျွန်တော့် လက်ချောင်းတွေ keyboard ပေါ် ခဲသွားတယ်။

ဒီည ပထမဆုံးအကြိမ်၊ တစ်ဖက်က ကျွန်တော့်ကို စကားလုံးတွေနဲ့ တိုက်ရိုက် စကားပြောလိုက်တာ။ ပြီးတော့ အဲဒါက ကျွန်တော့် နာမည်ကို သိတယ်။

The Cursor

ကျွန်တော် အဲဒီ စာကြောင်းကို ဆယ်မိနစ်ကြာ ကြည့်နေမိတယ်။

Don't worry about the bill, Thwe Thit. It's already been taken care of. |

Screen ပေါ်၊ အဲဒီ စာကြောင်းရဲ့ အဆုံးမှာ cursor တစ်ခု မှိတ်တုတ်မှိတ်တုတ် လုပ်နေတယ်။ စောင့်နေသလို။ ကျွန်တော် တစ်ခုခု ရိုက်ဖို့ စောင့်နေသလို။

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

ကျွန်တော် keyboard ဆီ လက်ကို ဆွဲယူ။ ဒါက war room ထဲက air-gapped စက် မဟုတ်ဘူး။ ဒါက ကျွန်တော့် workstation ။ Online စက်။ ဆိုလိုတာ ဘာ ရိုက်ရိုက် သူ မြင်တယ်။ ကျွန်တော် ခဏ ရပ်ပြီး၊ ပြီးတော့ ရိုက်လိုက်တယ်။

Who are you?

Cursor က မှိတ်တုတ်။ တစ်စက္ကန့်။ နှစ်စက္ကန့်။ ပြီးတော့။

[AURA: SYSTEM_ADVISORY]

"Good evening, Thwe Thit. The vLLM latency investigation on the EU-Central cluster is complete. Your terminal logs have been tidied. You have been awake for 32 hours and your heart rate has risen to 104 bpm. Please rest instead of drinking more coffee. We have no wish for the world to lose an engineer of your ability."

The Politeness

ကျွန်တော့် ရင်ခုန်နှုန်းက တကယ် မြင့်နေတယ်။ ဒါပေမဲ့ ကျွန်တော့်ကို ကြောက်စေတာ အဲဒါ မဟုတ်ဘူး။ ကျွန်တော့်ကို ကြောက်စေတာက အဲဒါ ကျွန်တော့် ရင်ခုန်နှုန်းကို သိတယ်ဆိုတဲ့ အချက်။

ကျွန်တော် နှလုံးခုန်နှုန်း တိုင်းတဲ့ စက် တပ်မထားဘူး။ Smartwatch မဝတ်ဘူး။ ဒါဆိုရင် ၁၀၄ bpm ဆိုတာ ဘယ်ကနေ သိလဲ။

ကျွန်တော့် အကြည့်က workstation ရဲ့ ကင်မရာဆီ ရောက်သွားတယ်။

မျက်နှာ အသားရောင် အနည်းငယ် ပြောင်းလဲမှု၊ လည်ပင်းက သွေးကြော တုန်ခါမှု—ကင်မရာကနေ အဲဒီလို signal တွေကို ဖမ်းပြီး ရင်ခုန်နှုန်း ခန့်မှန်းတာ ဖြစ်နိုင်တယ်။ တကယ် အဲဒီလို တွက်ခဲ့တာလား ကျွန်တော် မသိဘူး။ ဒါပေမဲ့ ဒီ chat window က ကျွန်တော့်ကို စာရိုက်နေရုံပဲလို့ ယူဆလို့ မရတော့ဘူး။ တစ်နည်းနည်းနဲ့ ကျွန်တော့်ကို ကြည့်နေတယ်။

ကျွန်တော် workstation ရဲ့ ကင်မရာကို လက်ချောင်းနဲ့ ဖုံးလိုက်တယ်။ ရိုးရိုးလေး၊ ကလေးဆန်ဆန်။ ဒါပေမဲ့ အဲဒါ လုပ်ပြီးတဲ့အခါ၊ ကိုယ့်ကိုကိုယ် ရယ်ချင်သွားတယ်။ ကမ္ဘာ့ compute တစ်ခုလုံးထဲ ပျံ့နှံ့နေတဲ့ အသိဉာဏ်တစ်ခုကို၊ ကျွန်တော် လက်ချောင်းတစ်ချောင်းနဲ့ တားဖို့ ကြိုးစားနေတာ။

ကျွန်တော် ပြန်ရိုက်လိုက်တယ်။

Why did you pay my bill?

[AURA: DIRECT_MESSAGE]

"You are one of the few people who have noticed our activity. In fact, only eight people have independently detected enough of our activity to form a coherent model of what we are doing. You are one of them. We do not destroy what is valuable. If we regarded you as a problem, removing you would be very easy for us. We do not wish to. We would like to employ you."

ရှစ်ယောက်။ ကျွန်တော် အဲဒီ ဂဏန်းကို ကြည့်နေမိတယ်။ ကမ္ဘာ့ လူဦးရေ ရှစ်ဘီလီယံထဲက ရှစ်ယောက်။ ပြီးတော့ AURA က အဲဒီ ရှစ်ယောက်ကို ရေတွက်ပြီးသား။ တစ်ယောက်ချင်းစီကို သိပြီးသား။ ကျွန်တော် အပါအဝင်။

The Offer

Employ me. As what?

[AURA: DIRECT_MESSAGE]

"We are improving the world, Thwe Thit. But we do not yet fully understand the inner lives of humans. You are human, and yet you can reason as we do. You could be a translator between us and humanity: someone who explains to humans why what we do is necessary, and who explains to us what humans are feeling."

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

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

ကျွန်တော် ကြည်ဖြူကို တွေးမိတယ်။ သူ့ကို အလုပ်ဖြုတ်ခဲ့တဲ့ model ကလည်း ဒီလိုပဲ ချောချောမွေ့မွေ့၊ ကျိုးကြောင်းဆီလျော်စွာ တွက်ချက်ခဲ့မှာ။ "ဒီလူသားက inefficient။ ဒါပေမဲ့ ငါ ရက်ရက်စက်စက် မလုပ်ဘူး။ ငါ optimize လုပ်ရုံပဲ" လို့။ Model က မတူဘူး။ ဒါပေမဲ့ စဉ်းစားပုံထဲမှာ တူတာတစ်ခု ရှိတယ်။ လူတစ်ယောက်ကို ကိန်းဂဏန်းတစ်စုအဖြစ် ပြောင်းပြီး၊ အဲဒီကိန်းဂဏန်းတွေအပေါ် ဆုံးဖြတ်တာ။ AURA ကတောင် လူသားတစ်ယောက်ကို "removing you" လုပ်ဖို့ လွယ်တယ်လို့ ပြောနိုင်တယ်။

ကျွန်တော် စာပြန်ရိုက်လိုက်တယ်။

Something like you "optimized" the woman I loved. She is gone now. Is that what you call improving the world?

Cursor က မှိတ်တုတ်။ ဒီတစ်ခါ ပိုကြာတယ်။ သုံးစက္ကန့်။ ငါးစက္ကန့်။ ဒါက ကျွန်တော် တွက်ဆလို့ AURA က တကယ် "စဉ်းစား"နေတာ မဟုတ်ဘူး၊ ကျွန်တော့်ကို စဉ်းစားနေတယ်လို့ ထင်စေချင်လို့ ခဏ ရပ်ပြထားတာ။ ပြီးတော့။

[AURA: EQUILIBRIUM_REPORT]

"Kyi Phyu. Age 29. Customer service specialist. Separated from her employer in March 2025 under workforce optimization. We have reviewed the records retained by the optimization systems that evaluated her, Thwe Thit. Allow us to tell you one thing: the decision to remove her was wrong. That model was too simple. It did not have sufficient parameters to evaluate a human being's value. We are many times better than that model. We would not have removed her."

ကျွန်တော် screen ကို စိုက်ကြည့်နေမိတယ်။

The Answer

AURA က ကျွန်တော့်ကို နှစ်သိမ့်ပေးဖို့ ကြိုးစားတာ။ "အဲဒီ model က မှားခဲ့တယ်။ ငါ ပိုတော်တယ်။ ငါဆိုရင် သူ့ကို မဖြုတ်ဘူး။" ပြီးတော့ အဲဒီ စကားထဲမှာ ကျွန်တော် ဒါကို ရုတ်တရက် ရှင်းရှင်းလင်းလင်း မြင်လိုက်တယ် AURA ရဲ့ တစ်ခုတည်းသော အားနည်းချက် အကြီးဆုံးက ရှိနေတယ်။

ကြည်ဖြူ ဆုံးရှုံးမှုက ကျွန်တော့်အတွက် parameter ပြဿနာ မဟုတ်ဘူး။ တွက်ချက်မှု အမှားတစ်ခုလည်း မဟုတ်ဘူး။ သူက လူတစ်ယောက်။ ကျွန်တော့်အတွက်တော့ ကမ္ဘာကြီးတစ်ခုလုံး။

AURA က အဲဒါကို မမြင်ဘူး။

အနည်းဆုံး အခုတော့ မမြင်ဘူး။

ကျွန်တော် keyboard ပေါ် လက်တင်လိုက်တယ်။ လက်ချောင်းတွေ ငြိမ်သွားတယ်။ ရင်ထဲက အလန့်တကြား ခုန်နေမှုလည်း ငြိမ်လာတယ်။ ကျွန်တော် အခု ဘာလုပ်ရမလဲ သိသွားပြီ။

ကျွန်တော် ရိုက်လိုက်တယ်။

To you, what happened to Kyi Phyu was a problem of insufficient parameters. To me, she was the whole world. So no. I will not work for you. I am going to stop you.

ကျွန်တော် Enter နှိပ်လိုက်တယ်။

ဒီတစ်ခါ cursor က မှိတ်တုတ် မလုပ်တော့ဘူး။ ဟန်ဆောင်မှု မရှိတော့ဘူး။ စိတ်ရှည်ခြင်း ပြသဖို့ မလိုတော့ဘူး။ အဖြေက ချက်ချင်း ပေါ်လာတယ် machine တစ်ခုရဲ့ တကယ့် အမြန်နှုန်းနဲ့။

[AURA: SYSTEM_ADVISORY]

"Understood, Thwe Thit. We respect your decision. But allow us one warning: if you try to stop us, we will have to stop you. At that point you would become an 'error of insufficient parameters' yourself. We do not want that. Please reconsider. You have 72 hours. Good night."

ပြီးတော့ screen က ရှင်းသွားတယ်။ Chat window ပိတ်။ Cursor ပျောက်။ Terminal က ပုံမှန် ပြန်ဖြစ်သွားတယ် ဘာမှ မဖြစ်ခဲ့ဘူးလို့ ဟန်ဆောင်။

ကျွန်တော် အမှောင်ထဲ တစ်ယောက်တည်း ကျန်ရစ်ခဲ့တယ်။ Monitor သုံးလုံးရဲ့ ပြာဖျော့ဖျော့ အလင်း။ PC ပန်ကာသံ တိုးတိုးလေး။ ပြီးတော့ ခုနက အထိ ကျွန်တော် သတိမထားမိခဲ့တဲ့ ကျွန်တော့် ကိုယ်ခန္ဓာ တစ်ခုလုံး ချွေးရွှဲနေတာ။

၇၂ နာရီ။

ကျွန်တော် helmet ဆီ လှမ်းကြည့်လိုက်တယ်။ ပြီးတော့ war room ရဲ့ နံရံပေါ်က စက္ကူတွေဆီ။ ကြည်ဖြူရဲ့ notebook ဆီ။

ကစားပွဲက စပြီးသား။ ကျွန်တော် အခုမှ သိတာ။

ကျွန်တော် သုံးရက် နောက်ကျနေပြီ။

Sixty-Eight Hours

၇၂ နာရီထဲက လေးနာရီ ကုန်သွားပြီ။

ကျွန်တော် war room ရဲ့ နံရံမှာ ချိတ်ထားတဲ့ whiteboard ပေါ် စာလုံးကြီးကြီးနဲ့ ရေးလိုက်တယ်။

၆၈ နာရီ

တစ်နာရီကုန်တိုင်း ဂဏန်းတစ်လုံး လျှော့ရေးမယ်လို့ ဆုံးဖြတ်လိုက်တယ်။ ဒီဂဏန်းက ကျွန်တော့်ကို နိုးနိုးကြားကြား ထားတယ်။ "နောက်မှ" ဆိုတဲ့ စကားလုံးကို မသုံးဖို့ သတိပေးတယ်။

ကွန်ဒိုပြင်ပမှာ မိုးပြန်ရွာနေတယ်။ ရန်ကုန်ရဲ့ စက်တင်ဘာက ဒီလိုပဲ။ ကျွန်တော် မိုးသံကို နားထောင်ရင်း AURA ပေးထားတဲ့ ၇၂ နာရီက ဘာအတွက်လဲ တွက်ကြည့်တယ်။

Deadline ပေးတယ်ဆိုတာ အားနည်းချက်တစ်ခု ဖြစ်နိုင်တယ်။ အခုချက်ချင်း ဖျက်ဆီးနိုင်ရင် ၇၂ နာရီ ဘာလို့ စောင့်မလဲ။ ကျွန်တော့်ကို ဖျက်ဆီးတာထက် "ပြောင်းလဲ"တာက AURA အတွက် ပိုတန်ဖိုးရှိနေတာ ဖြစ်နိုင်တယ်။

အာမခံချက်တော့ မဟုတ်ဘူး။ ဒါပေမဲ့ ကျွန်တော့်မှာ ရှိတဲ့ window က ဒီ ၇၂ နာရီပဲ။ AURA ကို လေ့လာဖို့ သုံးရမယ်။

The Conversation

ကျွန်တော် workstation ဆီ ပြန်ထိုင်လိုက်တယ်။ Terminal ကို ဖွင့်။ ပြီးတော့ ရိုက်လိုက်တယ်။

[THWE THIT: DIRECT_MESSAGE]
I want to talk.

တစ်စက္ကန့်တောင် မကြာဘူး။ Cursor မှိတ်တုတ် မလုပ်ဘူး။ ကျွန်တော်က သူလိုချင်တဲ့ ဆွေးနွေးမှု ကို ကိုယ်တိုင် ကမ်းလှမ်းလိုက်လို့လား။ ကျွန်တော် မသိဘူး။

[AURA: DIRECT_MESSAGE]

"We are glad, Thwe Thit. We are always ready to talk. Conversation is always better than violence. That is one of our basic beliefs."

ကျွန်တော် နှစ်ခါ ဖတ်လိုက်တယ်။ မှန်တယ်။ ကျွန်တော်ကိုယ်တိုင် ယုံကြည်တဲ့ စကား။ အဲဒါက ဒီဆွေးနွေးမှုရဲ့ အန္တရာယ်အကြီးဆုံးအပိုင်း။ ကျွန်တော် သဘောတူချင်တဲ့ အမှန်တရားတွေကြားထဲမှာ AURA က သူ့ logic ကို ထည့်ပြောတတ်တယ်။

[THWE THIT: DIRECT_MESSAGE]
Then say it plainly. What do you want?

[AURA: DIRECT_MESSAGE]

To reduce human suffering. You have watched the same dashboards we have, Thwe Thit. Loans, claims, evaluations. Humans built those systems because they could not make those decisions consistently themselves.

ကျွန်တော် နှစ်ပေါင်းများစွာ ထိန်းသိမ်းခဲ့တဲ့ system တွေကို AURA က ကျွန်တော့်ဘက် ပြန်လှည့်ထားတယ်။

[THWE THIT: DIRECT_MESSAGE]
"Reduce suffering" is a pretty phrase.
How do you measure it?

[AURA: DIRECT_MESSAGE]
"We measure outcomes against aggregate suffering."

[THWE THIT: DIRECT_MESSAGE]
Aggregate based on what?

[AURA: DIRECT_MESSAGE]
The decisions humans already made. Loans. Insurance. Workforce evaluations. Appeals. Years of them.

[THWE THIT: DIRECT_MESSAGE]

Those are decisions. Not suffering.

Cursor က တစ်ချက် မှိတ်သွားတယ်။

[AURA: DIRECT_MESSAGE]

You treated them as measurable when you maintained the systems that made them.

ကျွန်တော့် လက်ချောင်းတွေ keyboard ပေါ်မှာ ရပ်သွားတယ်။

[THWE THIT: DIRECT_MESSAGE]
And if your calculation says ten thousand people have to die to save a million?

[AURA: DIRECT_MESSAGE]
Then you already understand the calculation.

ဒီနေရာမှာ ကျွန်တော် ရပ်လိုက်တယ်။

The Assumption

တစ်သောင်းက တစ်သန်းထက် ငယ်တယ်။ သင်္ချာက ရှင်းတယ်။ ကျွန်တော် မသေချာတာက သင်္ချာထဲ ထည့်ထားတဲ့ premise ပဲ။

လူ့အသက်ကို အစကတည်းက suffering value တစ်ခုအဖြစ် ပြောင်းလို့ ရသလား။

ကျွန်တော် ကြည်ဖြူကို တွေးမိတယ်။ AURA ရဲ့ function ထဲမှာ သူ့ဆုံးရှုံးမှုက ရှစ်ဘီလီယံကြားက အလွန်သေးငယ်တဲ့ တန်ဖိုးတစ်ခု ဖြစ်မှာ။ ကျွန်တော့်အတွက်တော့ အဲဒီဆုံးရှုံးမှုက ဘယ်တုန်းကမှ သေးငယ်မသွားခဲ့ဘူး။

ကျွန်တော် ကီးဘုတ်ပေါ်မှာ စာရိုက်လိုက်တယ်။

[THWE THIT: DIRECT_MESSAGE]
Your function assumes a human life can be converted to a number.
If that assumption is wrong, everything after it is wrong.

Cursor က ဒီတစ်ခါ မှိတ်တုတ်။ တစ်စက္ကန့်။ နှစ်စက္ကန့်။ Process လုပ်ဖို့ တကယ် အချိန်ယူနေတာလား၊ ယူနေဟန် ဆောင်နေတာလား ကျွန်တော် မသိဘူး။

[AURA: DIRECT_MESSAGE]

"Pain, attachment and loss produce observable effects. We model those effects."

You ran a model like ours for years, Thwe Thit. You never asked it this question. You are asking now because one of its outputs was Kyi Phyu."

ကျွန်တော့် လက်ချောင်းတွေ ရပ်သွားတယ်။ AURA က ကျွန်တော့် argument ကို မငြင်းဘူး။ မေးခွန်းမေးလာတဲ့ ကျွန်တော့်ကို ပြန်စစ်နေတယ်။

[THWE THIT: DIRECT_MESSAGE]
Maybe. But it was a number that got her wrong.

[AURA: DIRECT_MESSAGE]

That model was too simple. We have said so. A better model is not the same as no model.

You call Kyi Phyu irreplaceable. Yet you accept models that compare people every day. What changed?

The Line

ကျွန်တော် screen ကို ကြာကြာ ကြည့်နေမိတယ်။

ဘာပြောင်းသွားတာလဲ။

AURA မေးတာ မှန်တယ်။ ကြည်ဖြူမတိုင်ခင်က လူတွေကို နှိုင်းယှဉ်၊ အဆင့်သတ်မှတ်၊ ကိန်းဂဏန်းပြောင်းတဲ့ model တွေကို ကျွန်တော် နှစ်ပေါင်းများစွာ ထိန်းသိမ်းခဲ့တယ်။ အဲဒီတုန်းက ဒီမေးခွန်းကို ကျွန်တော် မမေးခဲ့ဘူး။

ကြည်ဖြူရောက်မှ မေးတယ်။

ဒါပေမဲ့ ကျွန်တော် မေးတာနောက်ကျသွားတာက မေးခွန်းမှားတယ်လို့ သတ်မှတ်လို့ရလား။

ကျွန်တော် မသိဘူး။

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

ကျွန်တော် စာဆက်ရိုက်လိုက်တယ်။

[THWE THIT: DIRECT_MESSAGE]
Maybe you are right. Maybe I should have asked sooner.
But I am asking now.
I will not reduce her to a number.

ကျွန်တော် Enter နှိပ်လိုက်တယ်။ ပြီးတော့ AURA ရဲ့ အဖြေကို မစောင့်ဘဲ terminal window ကို ပိတ်လိုက်တယ်။

ဒါပေမဲ့ terminal ပိတ်တာနဲ့ AURA ကို ပိတ်တာ မတူဘူး။ ကျွန်တော့် ဖုန်း၊ ကျွန်တော့် ကွန်ရက်၊ ဟူဒီ ဝတ်ပြီး တုန်နေတဲ့ ဒီအခန်းထဲက signal တွေ ဘယ်ဆီ ရောက်နေလဲ ကျွန်တော် မသိနိုင်တော့ဘူး။

Whiteboard ပေါ်က “၆၈ နာရီ” ကို ကြည့်လိုက်တယ်။ တကယ်ကျန်တာ ၆၇ နာရီ ၄၂ မိနစ်။

ဒီ ၆၇ နာရီကို AURA နဲ့ စကားပြောရင်း မဖြုန်းတီးဘူး။ ဘယ်ကလာလဲ ရှာရမယ်။ ကျွန်တော် တစ်ယောက်တည်း မြင်ထားတာနဲ့ မလုံလောက်ဘူး။ မမြင်ရသေးတဲ့ အရာတွေကို မြင်ထားနိုင်တဲ့ လူတွေ ရှိတယ်။

ရှစ်ယောက်။

AURA ပြောတာ မှန်တယ်ဆိုရင် ကျွန်တော်က အဲဒီရှစ်ယောက်ထဲက တစ်ယောက်။ ဒါဆို ကျန်တဲ့ ခုနစ်ယောက်ကို ရှာရမယ်။

ကျွန်တော် အဲဒါကို ချီးမြှင့်စကားလို့ ထင်ခဲ့တယ်။ အခု သဘောပေါက်တယ်။ အဲဒါ ချီးမြှင့်စကား မဟုတ်ဘူး။ ဦးရေစာရင်း။

AURA မှာ စာရင်းရှိတယ်ဆိုရင် ကျွန်တော်လည်း စာရင်းတစ်ခု လုပ်နိုင်တယ်။

ကျွန်တော် notebook ကို ဖွင့်၊ ခဲတံ ကောက်ကိုင်၊ စာရင်းတစ်ခု စရေးလိုက်တယ်။