SLI / SLO / SLA & Error Budget

จนถึงตอนนี้เรารู้แล้วว่า วัดอะไร คำถามถัดไปคือ "แล้วเท่าไหร่ถึงเรียกว่า ดีพอ?" นี่คือที่มาของ SLI/SLO/SLA — หัวใจของ SRE ที่เปลี่ยน "ความน่าเชื่อถือ" จากความรู้สึก เป็น ตัวเลขที่ตัดสินใจได้

3 ตัวย่อที่ต้องแยกให้ออก

ตัวย่อ	ชื่อเต็ม	คืออะไร	ใครสนใจ
SLI	Service Level Indicator	ตัวเลขที่วัดได้จริง ว่าบริการดีแค่ไหน	วิศวกร
SLO	Service Level Objective	เป้าหมาย ที่เราตั้งให้ SLI	วิศวกร + ทีม
SLA	Service Level Agreement	สัญญา กับลูกค้า มีบทลงโทษถ้าทำไม่ได้	ลูกค้า + ฝ่ายกฎหมาย

วิธีจำง่ายๆ:

SLI คือสิ่งที่คุณ วัด · SLO คือสิ่งที่คุณ ตั้งเป้า · SLA คือสิ่งที่คุณ สัญญา (แล้วถ้าผิดสัญญาต้องจ่ายเงินคืน)

SLI — ตัววัดจริง

SLI ที่ดีคือ สัดส่วนของเหตุการณ์ที่ "ดี" ต่อเหตุการณ์ทั้งหมด เป็น % ระหว่าง 0–100

SLI = (จำนวน event ที่ดี / จำนวน event ทั้งหมด) × 100%

ตัวอย่าง SLI ยอดนิยม (มักอิงจาก Golden Signals):

• Availability: (request ที่ตอบ 2xx/3xx) / (request ทั้งหมด) → 99.95%
• Latency: (request ที่เร็วกว่า 300ms) / (request ทั้งหมด) → 99%
• Quality/Correctness: (response ที่ข้อมูลถูกต้อง) / (ทั้งหมด)

SLI ที่ดีควรสะท้อน ประสบการณ์ของผู้ใช้ ไม่ใช่ metric ภายในเครื่อง — "CPU 99% ของเวลาต่ำกว่า 80%" ไม่ใช่ SLI ที่ดี เพราะผู้ใช้ไม่สนใจ CPU เขาสนใจว่าเว็บโหลดขึ้นไหมและเร็วไหม

SLO — เป้าหมาย

SLO คือเส้นที่คุณลากว่า "SLI ต้องไม่ต่ำกว่านี้" เช่น:

SLO: availability ≥ 99.9% ต่อ 30 วัน

เลข 9 แต่ละตัวมีความหมายเรื่อง downtime ที่ยอมได้มหาศาล — ตารางนี้ต้องจำ:

SLO (availability)	Downtime ต่อเดือน (~30 วัน)	Downtime ต่อปี
99% ("two nines")	~7 ชั่วโมง 18 นาที	~3.65 วัน
99.9% ("three nines")	~43 นาที	~8.76 ชั่วโมง
99.95%	~21 นาที	~4.38 ชั่วโมง
99.99% ("four nines")	~4.3 นาที	~52.6 นาที
99.999% ("five nines")	~26 วินาที	~5.26 นาที

อย่าตั้ง SLO ที่ 100% — มัน เป็นไปไม่ได้ และการไล่ตามมันจะทำให้ทีมไม่กล้า deploy อะไรเลย (เพราะทุกการเปลี่ยนแปลงมีความเสี่ยง) SLO ที่ดีคือ "ต่ำพอที่จะยอมให้ล้มเหลวได้บ้าง แต่สูงพอที่ลูกค้าพอใจ"

Error Budget — พระเอกของเรื่อง

นี่คือแนวคิดที่ทรงพลังที่สุด: ถ้า SLO = 99.9% แปลว่าคุณ ได้รับอนุญาตให้พังได้ 0.1% — นั่นคือ error budget

Error Budget = 100% − SLO
             = 100% − 99.9%
             = 0.1%   (≈ 43 นาที/เดือน ที่ "พังได้")

Error budget เปลี่ยนวิธีตัดสินใจของทั้งทีม:

• ยัง budget เหลือเยอะ? → กล้า deploy feature ใหม่, ทดลอง, ลองของเสี่ยงได้
• budget ใกล้หมด/หมดแล้ว? → หยุด feature ใหม่, หันมา fix ความเสถียร, freeze การ deploy

Error budget ยุติสงครามคลาสสิกระหว่าง Dev (อยากปล่อยของเร็วๆ) กับ Ops (อยากให้ระบบนิ่ง) — แทนที่จะเถียงกันด้วยความรู้สึก ทั้งคู่ดูตัวเลขเดียวกัน: "budget เหลือเท่าไหร่" ถ้าเหลือก็ปล่อยได้ ถ้าหมดก็เบรก

Burn rate — budget กำลังไหม้เร็วแค่ไหน

Burn rate คือความเร็วที่ error budget ถูกใช้ไป ใช้ตั้ง alert ที่ฉลาดกว่าการ alert ทุก error:

• burn rate = 1 → ใช้ budget พอดีตามแผน (จะหมดพอดีสิ้นเดือน)
• burn rate = 10 → ไหม้เร็วกว่าแผน 10 เท่า (จะหมดใน 3 วัน) → alert ด่วน!

เราจะใช้ concept นี้ตอนตั้ง alert ในบทที่ 14

SLA — สัญญาที่มีเงินเป็นเดิมพัน

SLA คือ SLO ที่เขียนเป็นสัญญากับลูกค้า พร้อมบทลงโทษ เช่น "ถ้า uptime ต่ำกว่า 99.9% ในเดือนนั้น เราคืนเงินค่าบริการ 10%"

กฎทอง: ตั้ง SLA ให้ "หลวม" กว่า SLO ภายในเสมอ เช่น SLO ภายใน = 99.95% แต่ SLA ที่สัญญากับลูกค้า = 99.9% — เผื่อ buffer ไว้ ถ้า SLO ภายในเริ่มพลาด คุณจะรู้ตัวและแก้ทันก่อนที่จะผิด SLA (เสียเงิน/เสียชื่อ)

เอาไปใช้จริง: ตัวอย่างครบชุด

สมมติทำ API ร้านค้า:

• SLI: สัดส่วน request /checkout ที่ตอบ 2xx และเร็วกว่า 500ms
• SLO: SLI ≥ 99.9% วัดแบบ rolling 30 วัน
• Error budget: 0.1% ของ request ต่อเดือน
• SLA (กับลูกค้า enterprise): 99.5% ไม่งั้นลด bill 5%
• Alert: เมื่อ burn rate สูงจน budget จะหมดใน < 24 ชม.

สรุป

• SLI = ตัวเลขที่วัด (สัดส่วน event ที่ดี) · SLO = เป้าที่ตั้ง · SLA = สัญญาที่มีบทลงโทษ
• อย่าตั้ง SLO = 100% — ต้องเผื่อ error budget ไว้เพื่อกล้าพัฒนา
• Error budget = 100% − SLO ใช้ตัดสินใจว่าจะปล่อยของหรือเบรก
• SLA ต้องหลวมกว่า SLO ภายในเสมอ
• Burn rate = ความเร็วที่ budget ไหม้ ใช้ตั้ง alert ที่ฉลาด (บทที่ 14)

บทหน้า เจาะเทคนิค: metric มีกี่ชนิด และกับดัก cardinality ที่ทำให้ระบบ monitoring ล่มเอง