SLO SLI SLA: Define Service Level Objectives ให้ชัดเจน

การรันระบบ production แบบไม่มีเป้าหมายด้าน reliability ที่ชัดเจน เป็นหนึ่งในสาเหตุหลักที่ทำให้ทีมวิศวกรและทีมธุรกิจไม่เข้าใจกันเรื่องคุณภาพบริการ ทีมหนึ่งอาจรู้สึกว่าระบบ “ค่อนข้างเสถียร” ขณะที่อีกทีมมองว่า “ล่มบ่อย” เพราะทั้งสองฝ่ายไม่ได้ใช้ตัววัดเดียวกัน SLO (Service Level Objective), SLI (Service Level Indicator) และ SLA (Service Level Agreement) คือกรอบแนวคิดที่ทีม SRE ใช้เพื่อกำหนดมาตรฐานร่วมกัน วัดผลด้วยข้อมูลจริง และสร้างภาษากลางระหว่างวิศวกรรมกับธุรกิจ

บทความนี้อธิบายความหมายและความสัมพันธ์ของ SLI, SLO, SLA พร้อมวิธีออกแบบตัวชี้วัดให้ตรงกับประสบการณ์ผู้ใช้ วิธีเลือกค่าเป้าหมายที่ทำได้จริง และตัวอย่างการเขียน SLO สำหรับบริการประเภทต่าง ๆ เพื่อให้ทีมนำไปประยุกต์ใช้ในงาน production ได้ทันที

ความแตกต่างระหว่าง SLI, SLO และ SLA

ก่อนออกแบบเป้าหมาย ต้องเข้าใจก่อนว่าสามคำนี้ต่างกันอย่างไร หลายองค์กรใช้คำเหล่านี้สลับกันจนทำให้บทสนทนาในที่ประชุมสับสน

คำศัพท์	ความหมาย	ตัวอย่าง
SLI (Indicator)	ตัววัดที่สะท้อนคุณภาพบริการจากมุมมองผู้ใช้ เป็นตัวเลขจริงที่วัดได้	ร้อยละของคำขอ HTTP ที่ตอบกลับภายใน 300ms และมี status 2xx/3xx
SLO (Objective)	เป้าหมายภายในที่ทีมตั้งเองจาก SLI ใช้เป็นเป้าเพื่อการปรับปรุงและตัดสินใจ release	99.5% ของคำขอต่อ 30 วันต้องผ่าน SLI ข้างต้น
SLA (Agreement)	สัญญาทางธุรกิจกับลูกค้า มีผลทางกฎหมายหรือเครดิต หาก SLO ไม่ผ่านจะมีบทลงโทษ	หาก uptime ต่ำกว่า 99.0% ลูกค้าได้เครดิตคืน 10% ของค่าบริการเดือนนั้น

กฎทั่วไปคือ SLA ต้องหย่อนกว่าเป้าหมายภายใน และเป้าหมายภายในต้องหย่อนกว่า SLI ที่วัดได้จริงในอดีต เพื่อให้มีระยะปลอดภัยก่อนถึงจุดที่ต้องจ่ายเครดิต ตัวอย่างเช่น SLA 99.0%, เป้าหมายภายใน 99.5%, และ SLI จริงที่วัดได้ 99.7% ส่วนต่างคือ margin ไว้รองรับเหตุการณ์ไม่คาดคิด

หลักการออกแบบ SLI ที่ดี

SLI ที่เขียนดีต้องสะท้อน “ผู้ใช้ได้รับประสบการณ์ที่ดีหรือไม่” ไม่ใช่ “ระบบยังเปิดอยู่หรือไม่” ความแตกต่างนี้สำคัญมาก เพราะเซิร์ฟเวอร์อาจยังตอบ ping แต่ตอบช้า 8 วินาทีจนผู้ใช้ปิด browser ไปแล้ว

คุณสมบัติของ SLI ที่ใช้งานได้จริง

User-centric — วัดจากมุมผู้ใช้ ไม่ใช่จากมุมเซิร์ฟเวอร์ เช่น วัดจาก load balancer ไม่ใช่จาก application process
Measurable with data — ต้องมาจาก metric ที่วัดได้ต่อเนื่องและมีประวัติ ไม่ใช่ความรู้สึก
Ratio format — มักใช้รูปแบบ “good events / total events” เช่น คำขอสำเร็จ / คำขอทั้งหมด ทำให้ตีความง่ายและกำหนดเป้าเป็น % ได้
Representative — ครอบคลุม user journey ที่สำคัญ ไม่ใช่วัดเฉพาะ endpoint ที่ทำงานดี
Stable definition — สูตรคำนวณต้องไม่เปลี่ยนบ่อย ถ้าเปลี่ยนต้อง reset baseline ทันที

ประเภทของ SLI ตามลักษณะบริการ

ประเภทบริการ	SLI ที่แนะนำ	หน่วยวัด
Request-driven (API, Web)	Availability, Latency	% คำขอที่ success และ fast
Data processing (ETL, Stream)	Throughput, Freshness, Correctness	% records ที่ประมวลผลทันเวลาและถูกต้อง
Storage	Durability, Read/Write latency	% operations ที่เสร็จภายในเวลาเป้าหมาย
Batch job	Completion, Freshness	% runs ที่สำเร็จตามตารางเวลา

การเลือกค่า SLO ที่เหมาะสม

ค่าเป้าหมายที่ตั้งสูงเกินไป (เช่น 99.999%) จะบีบทีมให้ใช้งบลงทุนด้าน reliability สูงมากจนเสียโอกาสทำฟีเจอร์ใหม่ ในทางกลับกัน ค่าที่ต่ำเกินไปจะไม่สร้างแรงกดดันให้ปรับปรุง และลูกค้าจะรู้สึกถึงปัญหาก่อนที่ทีมจะรู้ตัว หลักในการเลือกค่าที่เหมาะสมมีสามข้อ

1. อ้างอิงจากข้อมูลย้อนหลัง

ดู SLI จริง 3-6 เดือนที่ผ่านมาเพื่อหา baseline หากระบบทำ availability ได้ 99.7% ตลอด การตั้งเป้าหมาย 99.5% จะเป็นเป้าที่สมเหตุสมผล (หย่อนลงเล็กน้อยเพื่อรองรับความผันผวน) การตั้ง 99.99% ทันทีโดยไม่มี infrastructure รองรับจะทำให้ทีมเหนื่อยและท้อ

2. สอดคล้องกับความคาดหวังของผู้ใช้

บริการหลักที่ผู้ใช้ต้องพึ่งพา (เช่น login, payment) ต้องตั้งเป้าหมายสูง 99.9-99.99% ส่วนบริการรองที่ใช้งานนาน ๆ ครั้ง (เช่น export report, admin dashboard) ใช้ 99.0-99.5% ก็เพียงพอ ควรคุยกับ product manager เพื่อเข้าใจว่าบริการใดสำคัญต่อรายได้โดยตรง

3. คำนวณต้นทุน reliability

ทุก ๆ “9” ที่เพิ่มขึ้น ต้นทุนมักเพิ่ม 5-10 เท่า ตารางด้านล่างแสดง downtime ที่อนุญาตต่อปีและต่อเดือน เพื่อให้เห็นภาพว่าแต่ละระดับเป้าหมายหมายถึงอะไรในทางปฏิบัติ

SLO	Downtime/ปี	Downtime/เดือน	Downtime/สัปดาห์
99.0%	3.65 วัน	7.2 ชั่วโมง	1.7 ชั่วโมง
99.5%	1.83 วัน	3.6 ชั่วโมง	50 นาที
99.9%	8.76 ชั่วโมง	43.8 นาที	10 นาที
99.95%	4.38 ชั่วโมง	21.9 นาที	5 นาที
99.99%	52.6 นาที	4.38 นาที	1 นาที
99.999%	5.26 นาที	26 วินาที	6 วินาที

Error Budget และการใช้ SLO ตัดสินใจ release

Error Budget คือ 1 – เป้าหมายภายใน เช่น เป้าหมาย 99.9% หมายถึง Error Budget 0.1% ต่อ 30 วัน = ประมาณ 43 นาทีของ downtime ที่ “ใช้ได้” ทีมใช้ budget นี้เป็นเครื่องมือตัดสินใจ หาก error budget ยังเหลือมาก แสดงว่าระบบเสถียรเกินเป้า สามารถ release ฟีเจอร์ใหม่เร็วขึ้น ยอมรับความเสี่ยงมากขึ้นได้ ในทางกลับกัน หาก error budget หมด ต้องหยุด release ชั่วคราวและเน้นแก้ bug เสถียรภาพก่อน

กฎ error budget ที่ทีม SRE ใช้กันแพร่หลาย:

Budget เหลือมากกว่า 50% — release ปกติ เพิ่มฟีเจอร์ทดลองได้
Budget เหลือ 10-50% — release ระวังขึ้น ใช้ canary/staged rollout
Budget เหลือน้อยกว่า 10% — freeze ฟีเจอร์ใหม่ เน้น reliability work
Budget หมด — stop release, postmortem, และ remediation จนกว่าจะกลับมาอยู่ในเป้า

ตัวอย่าง 1: REST API สำหรับ e-commerce

ระบบตะกร้าสินค้าและ checkout ต้องการเป้าหมายสูง เพราะปัญหาหมายถึงรายได้หาย ตัวอย่าง SLI และเป้าหมายที่ใช้งานจริง:

SLI-1: Availability
  good = sum(http_requests_total{code!~"5.."})
  total = sum(http_requests_total)
  ratio = good / total
  Target: 99.9% ต่อ 28 วัน

SLI-2: Latency (p95)
  good = sum(http_request_duration_seconds_bucket{le="0.3"})
  total = sum(http_request_duration_seconds_count)
  ratio = good / total
  Target: 95% ต่อ 28 วัน

SLI-3: Checkout success rate
  good = sum(checkout_completed_total)
  total = sum(checkout_started_total)
  ratio = good / total
  Target: 99.5% ต่อ 28 วัน

ตัวอย่าง 2: Data pipeline (batch ETL)

ระบบประมวลผลข้อมูลรายวัน ต้องการ SLI ที่สะท้อนเรื่อง freshness และ correctness ไม่ใช่ latency ของ HTTP:

SLI-1: Freshness
  % ของวันที่ pipeline เสร็จก่อนเวลา 06:00 น.
  Target: 99% ต่อ 30 วัน (อนุญาตให้ล่าช้าได้ 0-1 วันต่อเดือน)

SLI-2: Correctness
  % ของ records ที่ผ่าน data quality check
  Target: 99.95% ต่อ 7 วัน

SLI-3: Completeness
  % ของ source records ที่ถูก ingest สำเร็จ
  Target: 99.9% ต่อ 7 วัน

ตัวอย่าง 3: Background job queue

ระบบ job queue เช่น Sidekiq, Celery, RabbitMQ consumers ต้องวัดทั้ง success และ ความล่าช้าใน queue:

SLI-1: Job success rate
  good = sum(jobs_completed_total)
  total = sum(jobs_started_total)
  Target: 99.5% ต่อ 7 วัน

SLI-2: Queue delay (p99)
  % ของ job ที่เริ่มประมวลผลภายใน 60 วินาทีหลัง enqueue
  Target: 99% ต่อ 7 วัน

การวัด SLI ด้วย Prometheus + PromQL

หากใช้ Prometheus เป็น backend สามารถเขียน recording rule เพื่อให้คำนวณ SLI อัตโนมัติและดึงมาใช้ใน dashboard ได้ทันที ตัวอย่างสำหรับ SLI availability ของ HTTP service:

groups:
  - name: slo_http_availability
    interval: 30s
    rules:
      - record: sli:http_availability:ratio_rate5m
        expr: |
          sum(rate(http_requests_total{code!~"5.."}[5m]))
          /
          sum(rate(http_requests_total[5m]))

      - record: sli:http_availability:ratio_rate30d
        expr: |
          sum_over_time(sli:http_availability:ratio_rate5m[30d])
          /
          count_over_time(sli:http_availability:ratio_rate5m[30d])

      - alert: SLOBurnRateHigh
        expr: |
          (1 - sli:http_availability:ratio_rate5m) > (14.4 * 0.001)
        for: 2m
        labels:
          severity: page
        annotations:
          summary: "Error budget burning fast — 5% in 1h"

สูตร 14.4 * 0.001 คำนวณจาก multi-window burn rate alert ที่ Google SRE Workbook แนะนำ: หากเผา budget ที่อัตรา 14.4 เท่าของปกติ ใน 1 ชั่วโมงจะหมด 2% ของ budget ทั้งเดือน ซึ่งถือว่าผิดปกติและควรแจ้งเตือนทันที

ข้อผิดพลาดที่พบบ่อย

ตั้งเป้าหมายแบบเดา — เลือก 99.9% เพราะ “ฟังดูดี” โดยไม่ดูข้อมูลย้อนหลัง ทำให้เป้าไม่สะท้อนความสามารถจริงของระบบ
วัด SLI จากภายในเซิร์ฟเวอร์ — วัดจาก application แทนที่จะวัดจาก load balancer หรือ user เห็น ทำให้พลาดปัญหา network
มีเป้าหมายมากเกินไป — เริ่มจาก 2-3 SLI ต่อบริการก่อน หาก 10+ SLI ทีมจะไม่ทัน maintain
ไม่มี review cycle — เป้าหมายต้องทบทวนทุกไตรมาส เพราะ workload และ architecture เปลี่ยน
ใช้ SLA แทนเป้าหมายภายใน — SLA เป็นสัญญาลูกค้า ไม่ใช่เป้าหมายภายใน ทีมต้องมีเป้าหมายที่เข้มกว่า SLA เสมอ
ไม่แยก severity ระหว่างบริการหลักกับบริการรอง — ตั้ง 99.99% ให้ทุกอย่างเท่ากันทำให้ต้นทุนสูงเกินจำเป็น

Workflow การเริ่มต้นใช้ SLO ในทีม

ทีมที่ยังไม่เคยกำหนดเป้าหมายแบบนี้ ไม่ควรเริ่มด้วยการประกาศทั่วองค์กรทันที ควรทดลองกับบริการเดียวก่อนเพื่อเรียนรู้:

เลือกบริการหนึ่งตัวที่สำคัญและมีข้อมูล metric ครบ
วิเคราะห์ user journey หลัก แล้วระบุ “critical path” ที่ต้องทำงานได้
ออกแบบ 1-2 SLI ที่สะท้อน user experience ของ path นั้น
ดูข้อมูลย้อนหลัง 30-90 วัน หา baseline แล้วตั้งเป้าหมายที่หย่อนกว่า baseline เล็กน้อย
ติด recording rule และ dashboard ให้เห็นเป้าหมายแบบ real-time พร้อม error budget
ทดลอง enforce error budget policy เป็นเวลา 1-2 ไตรมาส
ทบทวนเป้าหมายทุกไตรมาส ปรับให้ตรงกับความเป็นจริงและความต้องการธุรกิจ
ขยายไปบริการอื่นเมื่อทีมเข้าใจกระบวนการแล้ว

สรุป

SLI, SLO, SLA เป็นเครื่องมือสำคัญของทีม SRE ในการวัดและจัดการคุณภาพบริการ โดย SLI คือตัววัดจริง ส่วน SLO คือเป้าหมายภายใน และ SLA คือสัญญากับลูกค้า การออกแบบ SLI ที่สะท้อนประสบการณ์ผู้ใช้จริง การตั้งเป้าหมายโดยอ้างอิงข้อมูลย้อนหลัง และการใช้ Error Budget เพื่อตัดสินใจ release จะช่วยให้ทีมวิศวกรรมและธุรกิจพูดภาษาเดียวกัน มีกรอบการทำงานที่ชัดเจน และสามารถสร้างสมดุลระหว่างการพัฒนาฟีเจอร์ใหม่กับการรักษาเสถียรภาพของระบบ

ในทางปฏิบัติ ไม่จำเป็นต้องเริ่มด้วยเป้าหมายสมบูรณ์แบบตั้งแต่วันแรก การเริ่มจากบริการเดียว วัด 1-2 SLI ที่สำคัญจริง และทบทวนทุกไตรมาสจะได้ผลดีกว่าการวางระบบใหญ่แล้วไม่มีคนดูแล เมื่อทีมคุ้นเคยแล้วจึงขยายไปบริการอื่น และค่อย ๆ ยกระดับเป็นส่วนหนึ่งของวัฒนธรรมการพัฒนา