SLO กับ Error Budget: วัดความน่าเชื่อถือแบบมีตัวเลข

"ระบบต้องเสถียร" เป็นเป้าหมายที่เถียงกันได้ไม่จบ เพราะไม่มีเส้นบอกว่าพอแล้ว SLO แก้ปัญหานี้ด้วยการกำหนดตัวเลขที่ทั้งทีม dev และทีม business ตกลงร่วมกันได้

SLI, SLO, SLA ต่างกันตรงไหน

SLI คือสิ่งที่วัดจริง เช่น สัดส่วน request ที่ตอบกลับสำเร็จภายใน 300ms
SLO คือเป้าที่ตั้งไว้กับ SLI นั้น เช่น 99.9% ในรอบ 30 วัน
SLA คือสัญญาที่มีบทลงโทษเมื่อทำไม่ได้ ซึ่งควรตั้งหลวมกว่า SLO เสมอ

ถ้าตั้ง SLA เท่ากับ SLO แปลว่าทีมไม่เหลือพื้นที่ให้พลาดเลยแม้แต่นิดเดียว

Error budget คือส่วนที่เหลือให้พัง

SLO 99.9% ในรอบ 30 วัน แปลว่าอนุญาตให้ล้มเหลวได้ประมาณ 43 นาที

error budget = (1 - 0.999) * 30 * 24 * 60 = 43.2 นาที

ตัวเลขนี้ใช้ตัดสินใจได้จริง ถ้าเดือนนี้ใช้ budget ไปแล้ว 80% ทั้งที่เพิ่งผ่านไปครึ่งเดือน นั่นคือสัญญาณให้ชะลอการ deploy ฟีเจอร์ใหม่แล้วหันไปแก้ต้นเหตุก่อน ในทางกลับกัน ถ้าเหลือ budget เยอะแปลว่าทีมกำลังระมัดระวังเกินจำเป็น และสามารถปล่อยของได้เร็วขึ้น

เลือก SLI ที่สะท้อนประสบการณ์ผู้ใช้

CPU usage ไม่ใช่ SLI ที่ดี เพราะผู้ใช้ไม่ได้รู้สึกอะไรกับ CPU ให้วัดจากมุมผู้ใช้แทน เช่น

อัตราความสำเร็จของ request ที่ endpoint สำคัญ
latency ที่ p95 และ p99 ไม่ใช่ค่าเฉลี่ย
ความสดของข้อมูลใน pipeline ที่ทำงานแบบ batch

ค่าเฉลี่ยซ่อนปัญหาได้เก่งมาก ระบบที่ตอบเร็ว 90% ของ request แต่ช้า 10 วินาทีอีก 10% จะมีค่าเฉลี่ยดูดีทั้งที่ผู้ใช้กลุ่มหนึ่งเจอประสบการณ์แย่มาก

ตั้ง alert จาก burn rate ไม่ใช่จาก threshold ดิบ

การเตือนทุกครั้งที่ error เกิน 1% ทำให้เกิด alert ซ้ำซ้อนจนคนเลิกอ่าน วิธีที่ใช้ได้จริงคือดูอัตราการเผา budget เทียบกับเวลา เช่นเตือนเมื่อเผา budget เร็วกว่าปกติ 14 เท่าในหน้าต่าง 1 ชั่วโมง ซึ่งแปลว่าถ้าปล่อยไว้ budget ทั้งเดือนจะหมดภายในสองวัน