ทีมพัฒนาต้องตัดสินใจทุกวันว่าควร release ฟีเจอร์ใหม่เร็วแค่ไหน รับความเสี่ยงได้เท่าไหร่ และเมื่อไหร่ควรหยุดเพื่อเน้นแก้ปัญหา เสถียรภาพ การตัดสินใจแบบอาศัย “feeling” หรือความเห็นของหัวหน้ามักนำไปสู่ความขัดแย้งระหว่างฝ่ายที่อยากทำฟีเจอร์ใหม่กับฝ่ายที่ดูแลระบบ Error Budget คือเครื่องมือเชิงวิศวกรรมที่แปลงการตัดสินใจเหล่านี้ให้อยู่บนข้อมูลจริง สร้างภาษากลางระหว่างทีม และทำให้การวางแผน release เป็นเรื่องที่มีกรอบชัดเจน

บทความนี้อธิบายวิธีคำนวณ Error Budget จากเป้าหมายที่ตั้งไว้ วิธีออกแบบ Error Budget Policy ที่ใช้งานได้จริง หลักการ Multi-window Burn Rate Alerts ที่ Google SRE แนะนำ รวมถึงตัวอย่างการนำไปใช้กับ release cadence ของทีมจริง เพื่อให้สามารถนำไปปรับใช้ในระบบ production ได้ทันที

Error Budget คืออะไร และคำนวณอย่างไร

Error Budget คือปริมาณความล้มเหลวที่ระบบ “อนุญาต” ให้เกิดได้โดยไม่ละเมิดเป้าหมายที่ตั้งไว้ คำนวณง่าย ๆ คือ 100% ลบด้วยเป้าหมาย availability ที่ตั้งไว้ ตัวอย่างเช่น หากตั้งเป้า availability ไว้ที่ 99.9% ต่อ 30 วัน Error Budget จะเท่ากับ 0.1% ของจำนวนคำขอทั้งหมดในเดือนนั้น หรือคิดเป็นเวลา downtime ที่ยอมให้เกิดได้ประมาณ 43 นาที

สำหรับระบบที่วัดด้วย request-based SLI สูตรคำนวณ budget ที่เหลือจะเป็น:

Error Budget Remaining (%) =
  (1 - (bad_events / total_events) / (1 - SLO_target)) * 100

ตัวอย่าง:
  SLO_target = 99.9%   →   budget = 0.1% = 0.001
  bad_events / total = 0.0004 (คือ 0.04% ที่ fail จริง)
  budget used = 0.04% / 0.1% = 40%
  budget remaining = 60%

ตัวเลข 60% หมายความว่า ณ ช่วงเวลานั้น ระบบยังมี “ส่วนต่าง” ให้เผื่อความผิดพลาดได้อีก 60% ของ budget ทั้งเดือน หากทีมกำลังจะ deploy release ใหญ่ นี่คือสัญญาณว่ายังมีพื้นที่รองรับความเสี่ยง

ทำไมต้องมี Error Budget Policy

การมี Error Budget อย่างเดียวไม่เพียงพอ ต้องมี “policy” ที่กำหนดว่าเมื่อ budget ถึงระดับไหน ทีมต้องทำหรือไม่ทำอะไร policy ที่ชัดเจนช่วยให้ทีมไม่ต้องถกเถียงกันทุกครั้งที่มีปัญหา และทำให้ management สามารถเห็นแนวทางการตัดสินใจได้ล่วงหน้า

โครงสร้าง policy ที่ดีควรครอบคลุม 4 เรื่องหลัก:

1. Threshold levels — กำหนดระดับที่ trigger การเปลี่ยนแปลงพฤติกรรม เช่น 50%, 25%, 10%, 0%
2. Actions per level — ระบุชัดเจนว่าที่แต่ละระดับทีมต้องทำ/ไม่ทำอะไร
3. Escalation — ใครต้องอนุมัติ exception ถ้าต้อง release ขณะงบหมด
4. Recovery path — เมื่อ งบหมดแล้ว ต้องทำอะไรบ้างเพื่อกลับมาอยู่ในเป้า

ตัวอย่าง Error Budget Policy ที่ใช้งานได้จริง

ตัวอย่าง policy นี้ได้รับแรงบันดาลใจจาก Google SRE Workbook และปรับให้เหมาะกับทีมขนาดกลาง (10-50 วิศวกร):

Budget เหลือ	พฤติกรรม Release	ลำดับความสำคัญ
> 50%	Release ปกติ ทุกวัน รวมถึงการทดลองฟีเจอร์ใหม่	ฟีเจอร์ใหม่ > tech debt
25-50%	Release ปกติ แต่เน้น canary หรือ staged rollout	50/50 ฟีเจอร์ : reliability
10-25%	เฉพาะ feature ที่จำเป็น ห้ามทดลอง ต้องผ่าน code review ละเอียดกว่าปกติ	reliability > ฟีเจอร์
0-10%	Feature freeze — เฉพาะ bug fix และงาน reliability เท่านั้น	reliability เท่านั้น
< 0% (หมด)	Stop release ทั้งหมด รวม bug fix ที่ไม่ critical — เน้น incident postmortem และแก้ root cause	เฉพาะงานเพื่อกลับเข้าเป้า

รายละเอียดของแต่ละระดับ:

ระดับ “Healthy” (> 50%)

ระบบทำงานดีเกินเป้า ทีมสามารถเพิ่มความเร็ว deploy ได้ ลองใช้ feature flags ทดลอง A/B test และเพิ่ม percentage ของการ rollout ฟีเจอร์ใหม่ได้ไวขึ้น ช่วงนี้เหมาะกับการทดลองเทคนิคใหม่ เช่น เปลี่ยน database driver หรือ refactor ระบบเก่า

ระดับ “Caution” (25-50%)

ทีมยังคง deploy ได้ปกติ แต่ต้องใช้เทคนิคลดความเสี่ยงมากขึ้น: canary deployment, feature flags, automated rollback หากตัวเลข error เพิ่มขึ้น การ deploy ใหญ่ควรนัดประชุมก่อนและเตรียม rollback plan ชัดเจน

ระดับ “Warning” (10-25%)

Product team ควรรู้ว่าทีม engineering อาจต้องชะลอ feature pipeline ลง ให้ความสำคัญกับ tech debt, incident postmortem actions และการปรับปรุง monitoring ระดับนี้ควรนัด incident review เพื่อหาสาเหตุที่งบลด

ระดับ “Freeze” (0-10%)

Feature freeze อย่างเข้มงวด — ไม่มีฟีเจอร์ใหม่ ไม่มีการทดลอง ทีมทั้งหมดต้องเน้นแก้ reliability bugs เขียน postmortem และ implement preventive actions หาก product team ต้องการ exception ต้องขออนุมัติจาก VP Engineering

ระดับ “Exhausted” (< 0%)

Budget หมดแล้ว ระบบละเมิดเป้า — ต้องหยุดทุกการเปลี่ยนแปลงที่ไม่จำเป็น team จัด “reliability week” ทำงานเฉพาะ action items จาก postmortem และไม่ deploy จนกว่า งบจะกลับมาอยู่เหนือเส้น 0 (หรืออย่างน้อยสัญญาณบวก 3 วันติด)

Multi-window Burn Rate Alerts

การ alert ทุกครั้งที่มี error ขึ้นเล็กน้อยจะทำให้ทีม on-call เหนื่อย และละเลย alert ที่สำคัญจริง ๆ Multi-window Burn Rate Alerts แก้ปัญหานี้ด้วยการ alert เมื่ออัตราการเผางบ (burn rate) สูงผิดปกติเท่านั้น ไม่ใช่ทุก error

Burn rate คืออัตราที่ งบถูกใช้ไปเทียบกับอัตราที่ “ปกติ” หาก burn rate = 1.0 หมายความว่ากำลังใช้ งบในอัตราที่พอดีกับเป้าหมายทั้งเดือน หาก burn rate = 10.0 หมายความว่ากำลังเผางบเร็วกว่าปกติ 10 เท่า — ถ้าคงอัตรานี้ 3 วัน งบจะหมดก่อน 30 วัน

ตาราง Burn Rate threshold ที่แนะนำ

Severity	Long Window	Short Window	Burn Rate	Budget ที่ใช้ไป
Page (ด่วน)	1 ชั่วโมง	5 นาที	14.4	2% ต่อ 1 ชั่วโมง
Page (ด่วน)	6 ชั่วโมง	30 นาที	6	5% ต่อ 6 ชั่วโมง
Ticket	3 วัน	6 ชั่วโมง	1	10% ต่อ 3 วัน
Ticket	3 วัน	1 วัน	1	(slow burn)

หลักการออกแบบคือใช้ 2 window พร้อมกัน: long window ยืนยันว่าปัญหาเกิดจริง (ไม่ใช่ spike ชั่วครู่) short window ทำให้ alert เร็ว ไม่ต้องรอนาน เงื่อนไขต้องเป็น AND ของทั้งสอง เพื่อลด false positive

ตัวอย่าง Prometheus alert สำหรับ fast burn

groups:
  - name: slo_burn_rate_fast
    rules:
      - alert: SLOBurnRateFast
        expr: |
          (
            job:slo_errors_ratio:rate5m{job="api"} > (14.4 * 0.001)
            and
            job:slo_errors_ratio:rate1h{job="api"} > (14.4 * 0.001)
          )
        for: 2m
        labels:
          severity: page
        annotations:
          summary: "API error budget burning fast"
          description: |
            Burn rate > 14.4x detected for 2+ minutes.
            At this rate, 2% of monthly budget will be consumed in 1 hour.
            Check recent deploys and dashboard: https://grafana.example.com/d/api-slo

สูตร 14.4 * 0.001 คำนวณจาก: หาก SLO = 99.9% budget = 0.001 (0.1%) หาก burn rate = 14.4 หมายถึง error rate ขณะนั้นสูงกว่าค่างบปกติ 14.4 เท่า ซึ่งจะกินงบ 2% ของทั้งเดือนภายใน 1 ชั่วโมง — ถือเป็นสถานการณ์ที่ต้อง page คนทันที

การวาง Release Cadence ตาม Error Budget

ทีมที่ใช้ Error Budget จริงจัง จะเห็นผลกระทบต่อ release cadence ชัดเจน แทนที่จะ release ตามตาราง (เช่น Tuesday/Thursday) ทีมจะ release ตามสถานะงบ + ตามความจำเป็นของธุรกิจ ตัวอย่างการวางแผน release cadence:

ทีมที่มี งบเหลือสูง (> 50%)

• Continuous deployment — deploy ได้หลายครั้งต่อวัน
• Canary rollout 5% → 25% → 100% ภายใน 4-8 ชั่วโมง
• ทดลองฟีเจอร์ใหม่ผ่าน feature flag ได้เต็มที่
• รองรับการทดลอง architecture เช่น migration database

ทีมที่มี งบระดับกลาง (25-50%)

• Deploy ได้ 1-3 ครั้งต่อวัน
• Canary rollout ช้าลง 25% → 100% ใน 24 ชั่วโมง
• Feature flags ใหม่ต้องผ่าน review ก่อนเปิดใช้งาน
• Architecture change ต้อง incident review ก่อน

ทีมที่มี งบต่ำ (< 25%)

• Deploy เฉพาะวันอังคาร-พฤหัส (หลีกเลี่ยงวันก่อน weekend)
• ห้าม deploy ช่วง traffic peak
• Canary rollout ช้ามาก 5% → 25% → 100% ใน 48 ชั่วโมง
• ต้องมี on-call ยืนยันก่อน rollout
• ทุก deploy ต้องมี rollback plan เขียนไว้ชัดเจน

กรณีศึกษา: การ release feature ใหม่ช่วง งบต่ำ

ทีม e-commerce ต้องการ release ระบบตะกร้าสินค้าใหม่ แต่ตอนนั้น งบเหลือเพียง 15% (อยู่ในระดับ Warning) ทีมไม่อยาก freeze release เพราะโครงการรอมา 3 เดือน ทางออกที่ทีมใช้คือ

1. เปิด feature flag ให้ internal team ทดสอบก่อน 3 วัน — ไม่กระทบ production users
2. Deploy กับ 1% ของผู้ใช้ monitor 24 ชั่วโมง ดูว่า error rate เพิ่มขึ้นหรือไม่
3. ถ้าปกติ ขยายเป็น 10% อีก 24 ชั่วโมง
4. ถ้ายังปกติ ขยายเป็น 50% อีก 24 ชั่วโมง
5. ถ้ายังปกติ ขยายเป็น 100% พร้อม monitor ต่อ
6. เตรียม rollback script ที่ทีมทดสอบแล้วว่ากลับคืนได้ใน 5 นาที

ผลลัพธ์: release ใช้เวลา 4 วันแทนที่จะ 1 วันตามปกติ แต่ไม่กระทบงบเพิ่มเติม และทีมสามารถหยุดการ rollout ที่จุดใดก็ได้หากตัวเลขผิดปกติ

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

• ไม่ enforce policy จริงจัง — policy ที่เขียนไว้แต่ไม่มีใครปฏิบัติตามจะเสียความหมาย ต้องมี exec sponsor สนับสนุน
• ใช้ burn rate threshold เดียว — ต้องมีทั้ง fast burn (alert page) และ slow burn (ticket) เพื่อจับปัญหาทั้ง 2 รูปแบบ
• Alert ไม่เชื่อมกับ dashboard — alert ต้องมี link ตรงไปยัง dashboard ที่เกี่ยวข้อง ไม่เช่นนั้น on-call ต้องค้นหาเองเสียเวลา
• ลืมคืนงบ — ระยะงบน่าจะ reset ทุก rolling window ไม่ใช่ reset แบบแข็งทุกต้นเดือน
• ไม่มี recovery actions — เมื่องบหมด ต้องรู้ว่าทำอะไรบ้าง ไม่ใช่แค่ “freeze แล้วรอ”
• Budget ถูกใช้โดย infrastructure ไม่ใช่โดย release — หาก 80% ของงบหมดเพราะ cloud provider outage ไม่ใช่เพราะ release ของทีม ต้องแยก source และปรับ policy ให้เป็นธรรม

การสื่อสาร Error Budget กับทีม Product

Error Budget จะไม่มีค่าหากทีม Product ไม่เข้าใจและไม่ใช้ การสื่อสารที่ดีประกอบด้วย

• Dashboard ที่เห็นสถานะงบ real-time พร้อม historical trend
• Weekly report ส่ง product manager แสดงงบ burn ของแต่ละบริการ
• Postmortem ที่ link incident กับ การใช้งบ
• Monthly review ร่วมกัน ว่าเป้าหมาย availability ยังเหมาะสมหรือไม่
• แปลงงบเป็นภาษาธุรกิจ เช่น “งบหมดหมายถึงลูกค้าอาจเจอ error ประมาณ 500 ครั้งต่อชั่วโมงช่วง peak”

สรุป

Error Budget เป็นเครื่องมือที่แปลง “ความรู้สึก” เรื่องเสถียรภาพระบบให้เป็นตัวเลขที่วัดได้ ซึ่งใช้ตัดสินใจเรื่อง release และการจัดลำดับงานของทีม การมี policy ที่ชัดเจน + multi-window burn rate alerts + release cadence ที่ผูกกับงบจะช่วยให้ทีมไม่ต้องถกเถียงกันเองทุกครั้งที่มีปัญหา และทำให้ management เห็นภาพรวมของ reliability ได้ชัดเจน

การเริ่มต้นใช้ Error Budget ควรเริ่มจากบริการที่สำคัญที่สุด 1 ตัว ตั้ง policy เบื้องต้น และทบทวนทุกไตรมาสว่า การใช้งบที่วัดได้สมเหตุสมผลหรือไม่ เมื่อทีมคุ้นแล้ว ขยายไปบริการอื่น และค่อย ๆ ผูกกับ release process อย่างเป็นระบบ