6. Linux & Network Administration for Troubleshooting

ทำไมหัวข้อนี้สำคัญกับ interview

เมื่อ dashboard บอกว่า "server ช้า" SRE ต้อง SSH เข้าไปหาต้นตอที่ระดับ OS/network ได้. คำถามคลาสสิก: "load average สูงแต่ CPU ไม่เต็ม แปลว่าอะไร", "server ช้าจะไล่ยังไง", "CLOSE_WAIT เยอะหมายความว่าอะไร". ต้องรู้จักเครื่องมือ (ss, tcpdump, iostat, dig) และ แปลผล ได้.

กรอบคิดที่ดี: ใช้ USE method ไล่ resource ทีละตัว — CPU, memory, disk, network — เช็ก Utilization / Saturation / Errors ของแต่ละอัน.

Core Concepts

CPU & Load Average

load average = จำนวน process โดยเฉลี่ยที่ กำลังรัน + รอ (รวมทั้ง runnable และ uninterruptible I/O wait ใน Linux). ค่า 3 ตัวคือเฉลี่ย 1/5/15 นาที.

กับดักที่ถามบ่อยที่สุด

load สูงแต่ CPU ไม่เต็ม มักแปลว่า process ติด I/O wait (สถานะ D, uninterruptible sleep) — เช่น disk หรือ network ช้า ไม่ใช่ CPU-bound. ดู iowait ใน top/iostat เพื่อยืนยัน. เทียบ load กับจำนวน core เสมอ (load 8 บนเครื่อง 8 core ≈ เต็มพอดี).

bash

uptime                 # load average 1/5/15 นาที
top                    # %us %sy %id %wa (iowait!) + process ที่กิน CPU
vmstat 1               # r (run queue), b (blocked), si/so (swap), wa
pidstat -t 1           # แยกตาม thread

Memory

bash

free -h                # total/used/free/buff/cache/available (ดู "available" ไม่ใช่ "free")

buff/cache ที่สูงไม่ใช่ปัญหา — Linux ใช้ RAM ว่างทำ page cache และคืนได้เมื่อต้องการ. ดูค่า available เป็นหลัก.
RSS = memory จริงในแรม, VSZ = virtual (จองไว้ อาจไม่ได้ใช้จริง).
Swap ทำงานหนัก (si/so ใน vmstat) = ช้าลงมหาศาล.
OOM killer ทำงานเมื่อ memory หมด → kill process ที่ให้คะแนนสูงสุด (ดู dmesg).

Disk

bash

df -h                  # พื้นที่เต็มไหม (ระวัง 100% = เขียนไม่ได้)
df -i                  # inode เต็มไหม (ไฟล์เล็กจำนวนมากทำ inode หมดทั้งที่ยังมีพื้นที่)
iostat -xz 1           # %util, await (latency), r/s w/s ต่อ disk
du -sh /var/* | sort -h  # อะไรกินพื้นที่

Network tools

bash

ss -tulpn              # socket ที่ฟัง (แทน netstat) — process/port
ss -s                  # สรุปจำนวน socket ตามสถานะ
tcpdump -ni eth0 port 443 and host 10.0.1.5   # ดู packet จริง
dig +short api.example.com                     # DNS resolution + ตรวจ record/TTL
mtr api.example.com                            # traceroute + ping ต่อเนื่อง หา hop ที่ loss
curl -v -o /dev/null -w '%{time_total}\n' https://api.example.com/health

TCP states ที่ต้องอ่านออก:

State	ความหมาย	เยอะผิดปกติ = อะไร
`TIME_WAIT`	ฝั่งที่ปิดก่อนรอ 2×MSL	เปิด/ปิด connection ถี่เกิน (ไม่ reuse)
`CLOSE_WAIT`	อีกฝั่งปิดแล้ว แต่ แอปเราไม่ close socket	bug/leak ในแอป (ไม่ปิด fd)
`SYN_RECV` เยอะ	จับมือ (handshake) ไม่จบ	อาจโดน SYN flood หรือ backend ตอบช้า

CLOSE_WAIT vs TIME_WAIT — ข้อที่แยกคนเก่ง

CLOSE_WAIT เยอะ = ปัญหาที่แอปของเรา (ลืม close socket → file descriptor รั่ว จน ชน ulimit -n). TIME_WAIT เยอะ = ปกติกว่า เกิดจากการเปิด/ปิด connection บ่อย (แก้ด้วย connection pooling / keep-alive). อย่าสลับสองอันนี้.

DNS resolution flow

resolver ในแอป → cache//etc/hosts → /etc/resolv.conf (DNS server) → recursive resolver → root/TLD/authoritative → ได้ record + TTL (นานเท่าไรถึง cache ได้). ปัญหา บ่อย: TTL สูงทำให้ค่าเก่าค้างหลังเปลี่ยน IP, หรือ resolver cache stale.

Load Balancing

L4 (transport) — route ด้วย IP/port เร็ว ไม่มองเนื้อหา (เช่น NLB).
L7 (application) — route ด้วย host/path/header, ทำ TLS termination, retry ได้ (เช่น ALB).
Algorithms: round robin, least connections, IP hash. + health check ถอด backend ที่ป่วยออก.

เชื่อมกับ AWS / Cloud ที่คุณรู้อยู่แล้ว

แนวคิด	บริการ/จุดสังเกตบน AWS
CPU/mem/disk ของ instance	CloudWatch (CPUUtilization มีให้; memory/disk ต้องลง CloudWatch agent)
ดู packet / flow	VPC Flow Logs (ไม่ใช่ payload แต่เห็น allow/deny + 5-tuple)
DNS	Route 53 (+ resolver), TTL ต่อ record
L4 vs L7 LB	NLB (L4) vs ALB (L7)
Firewall stateful/stateless	Security Group (stateful) vs Network ACL (stateless)
Network throughput	ENA metrics, instance bandwidth limit

จุดที่มักถูกถามบน AWS

"ทำไม CloudWatch ไม่โชว์ memory ของ EC2?" — เพราะ memory เป็น guest-level metric ที่ hypervisor มองไม่เห็น ต้องติดตั้ง CloudWatch agent ถึงจะเก็บได้. และเรื่อง connectivity ให้แยก Security Group (stateful, allow-only) กับ NACL (stateless, มี deny, ต้องเปิดทั้งขาไป-ขากลับ).

คำถาม interview ที่เจอบ่อย + แนวคำตอบ

"load average 20 บนเครื่อง 4 core แต่ CPU idle เยอะ แปลว่าอะไร?" → process ส่วนใหญ่ติด I/O wait (สถานะ D) ไม่ใช่ CPU-bound. เช็ก iowait/iostat หา disk/network ที่ช้า.
"server ตอบช้า จะไล่ยังไงตั้งแต่ต้น?" → USE method: CPU (top %wa), memory (free, swap si/so), disk (iostat await/%util), network (ss, mtr, dig). ดู "อะไรเปลี่ยนล่าสุด" ประกอบ. ไล่จาก symptom ผู้ใช้ลงมา.
"CLOSE_WAIT เยอะผิดปกติ บอกอะไร?" → แอปเราไม่ปิด socket หลัง peer ปิด → fd รั่ว เสี่ยงชน ulimit. เป็น bug ฝั่งเรา ต่างจาก TIME_WAIT ที่มักเกิดจากเปิด/ปิด connection ถี่.
"อธิบายขั้นตอน DNS resolution และปัญหาที่พบ" → cache → resolv.conf → recursive → authoritative → record+TTL. ปัญหา: TTL สูงทำ IP เก่า ค้าง, cache stale, หรือ resolver ล่ม.
"ทำไม df บอกมีที่ว่างแต่เขียนไฟล์ไม่ได้?" → inode หมด (df -i) จากไฟล์เล็กจำนวนมาก, หรือ process ยังถือ fd ของไฟล์ที่ลบไปแล้ว (พื้นที่ไม่คืนจนปิด fd).

Pitfalls — จุดที่ผู้สมัครมักพลาด

ระวังกับดักเหล่านี้

สับสน load average กับ CPU% — load รวม I/O wait ด้วย.
ตกใจกับ buff/cache สูง — ดู available ไม่ใช่ free.
มองข้าม iowait — ปัญหา disk/network ปลอมตัวเป็น "CPU สูง".
สลับ CLOSE_WAIT กับ TIME_WAIT — คนละต้นเหตุ คนละวิธีแก้.
ลืม file descriptor limit (ulimit -n) — connection/fd รั่วจนแอปรับ connection ใหม่ไม่ได้.
kill -9 ทุกอย่าง — ไม่ให้แอป cleanup; ควรลอง SIGTERM ก่อน.
ลืมว่า EC2 ไม่มี memory metric โดย default (ต้องลง agent).

Quiz ท้ายบท

ตอบแล้ว 0/7

1.load average = 16 บนเครื่อง 4 core แต่ %idle ของ CPU สูง สาเหตุที่เป็นไปได้มากที่สุด?
2.socket จำนวนมากอยู่ในสถานะ CLOSE_WAIT บ่งบอกถึงอะไร?
3.ควรดูค่าใดใน `free -h` เพื่อประเมินว่าหน่วยความจำ 'ใช้ได้จริง' เหลือเท่าไร?
4.`df -h` บอกว่ายังมีพื้นที่ว่าง แต่สร้างไฟล์ใหม่ไม่ได้ ควรตรวจอะไรต่อ?
5.ต้องการตรวจว่า packet เข้า/ออกจริงบน interface eth0 ที่ port 443 ควรใช้เครื่องมือใด?
6.บน EC2 ทำไม CloudWatch ถึงไม่แสดง memory utilization โดย default?
7.ความต่างหลักระหว่าง Security Group กับ Network ACL บน AWS คือข้อใด?

Cheat Sheet — อ่านก่อนเข้าห้องสัมภาษณ์

สรุปเร็ว 30 วินาที

ไล่ด้วย USE method: CPU · memory · disk · network (Utilization/Saturation/Errors)
load สูง + CPU idle = I/O wait (ดู %wa, iostat await)
memory: ดู available ไม่ใช่ free; swap si/so = ช้า; OOM killer อยู่ใน dmesg
disk: df -h (พื้นที่) · df -i (inode) · iostat -xz (await/%util)
net: ss -tulpn · tcpdump · dig · mtr; CLOSE_WAIT = bug เราไม่ close, TIME_WAIT = เปิด/ปิดถี่
L4 (NLB) route ด้วย IP/port · L7 (ALB) route ด้วย host/path
AWS: EC2 ไม่มี memory metric (ต้องลง agent) · SG stateful vs NACL stateless