# หลักการ SRE ปี 2026: วิศวกรรมความน่าเชื่อถือ SLO และคำถามสัมภาษณ์งาน

> หลักการ SRE สำหรับปี 2026: วิธีเลือก SLI ตั้ง SLO คำนวณ error budget เขียน alert แบบ burn rate หลายช่วงเวลาใน Prometheus และตอบคำถามสัมภาษณ์งาน SRE ที่พบบ่อยที่สุด

- Published: 2026-11-07
- Updated: 2026-11-07
- Author: Anthony Fillion-Maillet
- Tags: devops, sre, slo, error-budget, prometheus, observability
- Reading time: 13 min

---

หลักการ SRE เปลี่ยนความน่าเชื่อถือของระบบจากเป้าหมายที่จับต้องไม่ได้ให้กลายเป็นตัวเลขที่ทีมวิศวกรรมและทีมผลิตภัณฑ์ตกลงร่วมกัน จากนั้นจึงใช้ตัวเลขนั้นตัดสินใจว่าเมื่อใดควรปล่อยฟีเจอร์ใหม่และเมื่อใดควรหยุด Site reliability engineering ซึ่งเริ่มต้นที่ Google และปัจจุบันถูกนำไปใช้ในทีม platform แทบทุกแห่ง ตั้งอยู่บนแนวคิดหลักไม่กี่ข้อ ได้แก่ วัดสิ่งที่ผู้ใช้สัมผัสได้จริง (SLI) ตั้งเป้าหมายต่ำกว่า 100% (SLO) ใช้ส่วนต่างนั้นเป็น error budget และจำกัดงานที่ต้องทำด้วยมือเพื่อประคองระบบ คำถามสัมภาษณ์งาน SRE ในปี 2026 ทดสอบแนวคิดเหล่านี้โดยตรง โดยมักให้ผู้สมัครกำหนด SLO ของบริการจริงและเขียน alert ที่ใช้ปกป้อง SLO นั้น

> **SLI, SLO และ SLA ในหนึ่งประโยค**
>
> SLI คือค่าที่วัดได้ ซึ่งเป็นอัตราส่วนระหว่างเหตุการณ์ที่ดีกับเหตุการณ์ที่ถูกต้องทั้งหมด เช่น จำนวน request ที่สำเร็จหารด้วย request ทั้งหมด SLO คือเป้าหมายภายในของอัตราส่วนนั้นในช่วงเวลาหนึ่ง เช่น 99.9% ใน 30 วัน ส่วน SLA คือคำมั่นตามสัญญาที่ให้กับลูกค้าพร้อมบทลงโทษ และต้องหลวมกว่า SLO เสมอ

## หลักการพื้นฐานของ site reliability engineering

[หนังสือ SRE ของ Google](https://sre.google/sre-book/service-level-objectives/) มองความน่าเชื่อถือเป็นฟีเจอร์ที่มีต้นทุน เลขเก้าทุกตัวที่เพิ่มขึ้นต้องใช้เวลาทางวิศวกรรมมากขึ้นและทำให้การปล่อยเวอร์ชันช้าลง ขณะที่ผู้ใช้แทบไม่รู้สึกถึงความแตกต่างระหว่าง 99.99% กับ 99.999% เพราะเครือข่าย อุปกรณ์ และผู้ให้บริการอินเทอร์เน็ตของผู้ใช้เองยังเชื่อถือได้น้อยกว่านั้น เป้าหมายจึงอยู่ที่ระดับความน่าเชื่อถือที่เหมาะสม ไม่ใช่ระดับสูงสุด

จากจุดเริ่มต้นดังกล่าว จึงเกิดหลักการสำคัญตามมาดังนี้

- **วัดความน่าเชื่อถือจากมุมของผู้ใช้** การใช้ CPU และการ restart ของ pod เป็นเพียงสาเหตุ การชำระเงินที่ล้มเหลวและหน้าเว็บที่โหลดช้าคือสิ่งที่ผู้ใช้ประสบจริง และนั่นคือสิ่งที่ SLI ต้องจับให้ได้
- **100% เป็นเป้าหมายที่ผิด** SLO ที่ 100% เท่ากับห้ามการเปลี่ยนแปลงทุกอย่าง เพราะการ deploy ทุกครั้งมีความเสี่ยง ช่องว่างที่ต่ำกว่า 100% เรียกว่า error budget และมีไว้เพื่อใช้จ่ายไปกับการปล่อยเวอร์ชัน การทดลอง และการย้ายระบบ
- **จำกัดปริมาณ toil** แนวทางของ Google ใน[บทว่าด้วยการกำจัด toil](https://sre.google/sre-book/eliminating-toil/) กำหนดให้งานปฏิบัติการไม่เกิน 50% ของเวลาทำงานของ SRE โดย toil คืองานที่ทำด้วยมือ ซ้ำซาก สามารถทำให้เป็นอัตโนมัติได้ และเพิ่มขึ้นตามขนาดของบริการ เวลาที่เหลือใช้กับงานวิศวกรรมที่กำจัด toil เหล่านั้น
- **Postmortem ต้องไม่กล่าวโทษ (blameless)** การทบทวนเหตุขัดข้องตั้งคำถามว่าสิ่งใดในระบบเปิดโอกาสให้ความผิดพลาดเกิดขึ้น ไม่ใช่ถามว่าใครเป็นคนพิมพ์คำสั่ง วิศวกรที่ถูกกล่าวโทษจะปิดบังข้อมูล ในขณะที่การทบทวนแบบไม่กล่าวโทษจะทำให้ข้อมูลถูกเปิดเผยออกมา
- **การมอนิเตอร์แจ้งเตือนตามอาการ** page จะถูกส่งเมื่อผู้ใช้ได้รับผลกระทบหรือกำลังจะได้รับผลกระทบ ไม่ใช่เมื่อ node ใด node หนึ่งดูผิดปกติ

ในการสัมภาษณ์ หลักการข้อที่สองคือสิ่งที่แยก SRE ที่มีประสบการณ์จริงออกจากผู้ที่เพียงอ่านหนังสือมา คำตอบระดับ junior มอง error budget ว่าเป็นค่าความคลาดเคลื่อนที่ยอมรับได้ ส่วนคำตอบระดับ senior มองว่าเป็นเครื่องมือบริหารการปล่อยเวอร์ชัน เป็นกลไกที่ทำให้ทีมผลิตภัณฑ์และทีมความน่าเชื่อถือถกเถียงกันด้วยข้อมูลแทนความเห็นส่วนตัว

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

SLI ที่ดีคืออัตราส่วนที่มีค่าระหว่าง 0 ถึง 1 คำนวณจากเหตุการณ์ที่ผู้ใช้รับรู้ได้ [SRE workbook](https://sre.google/workbook/implementing-slos/) แนะนำตัวเลือกสั้น ๆ ตามประเภทของบริการ

| ประเภทบริการ | SLI ที่ใช้บ่อย | จุดที่วัด |
|---|---|---|
| API ที่ทำงานตาม request | ความพร้อมใช้งาน, latency | log ของ load balancer หรือ ingress, metric ของเซิร์ฟเวอร์ |
| Data pipeline | ความสดใหม่, ความถูกต้อง, ความครอบคลุม | timestamp ของผลลัพธ์ pipeline, job ตรวจสอบความถูกต้อง |
| ระบบจัดเก็บข้อมูล | ความคงทนของข้อมูล, latency ของการอ่านและเขียน | ชั้น storage, synthetic probe |
| Frontend | เวลาโหลดหน้าเว็บ, อัตรา error ที่เบราว์เซอร์เห็น | Real user monitoring |

การวัดที่ load balancer จับความล้มเหลวที่แอปพลิเคชันมองไม่เห็นได้ เช่น pod ที่ crash แล้วไม่ตอบกลับอะไรเลย การวัดที่เบราว์เซอร์จับปัญหาของ CDN และ DNS ได้ แต่มีสัญญาณรบกวนจากการเชื่อมต่อมือถือที่ไม่เสถียร ทีมส่วนใหญ่จึงเริ่มต้นที่ load balancer หรือ ingress เพราะมีข้อมูลพร้อมอยู่แล้ว

เมื่อใช้ Prometheus SLI แบบคลาสสิกสองตัวของบริการ HTTP คืออัตราส่วนความพร้อมใช้งานและอัตราส่วน latency โดย SLI ด้าน latency นับ request ที่เร็วกว่าเกณฑ์ที่กำหนดว่าเป็น request ที่ดี ทำให้ยังคงเป็นอัตราส่วนเหมือน SLI อื่น แทนที่จะเป็นค่า percentile

```promql
# checkout-sli.promql
# Availability SLI: share of requests that did not fail with a 5xx
sum(rate(http_requests_total{job="checkout-api", code!~"5.."}[5m]))
/
sum(rate(http_requests_total{job="checkout-api"}[5m]))

# Latency SLI: share of requests served in under 300 ms
# Uses the histogram bucket with le="0.3", so 0.3 must be a configured bucket boundary
sum(rate(http_request_duration_seconds_bucket{job="checkout-api", le="0.3"}[5m]))
/
sum(rate(http_request_duration_seconds_count{job="checkout-api"}[5m]))
```

มีรายละเอียดสองข้อที่มักถูกถามในการสัมภาษณ์ ข้อแรก response ประเภท 4xx มักถูกนับว่าถูกต้องและดี เพราะ 404 หรือ error จากการตรวจสอบข้อมูลเป็นความผิดพลาดฝั่ง client หากนับเป็นความล้มเหลว client ที่ทำงานผิดพลาดเพียงรายเดียวก็อาจเผา budget จนหมด ข้อที่สอง เกณฑ์ latency ต้องตรงกับขอบของ bucket ใน histogram มิฉะนั้น query จะไม่คืนผลลัพธ์หรือใช้ bucket ผิดโดยไม่มีการแจ้งเตือน Prometheus 3.16 ซึ่งออกเมื่อวันที่ 5 พฤศจิกายน 2026 รองรับ native histogram ที่ช่วยปลดข้อจำกัดเรื่อง bucket แบบตายตัว แต่ต้องเปิดใช้งานที่ฝั่ง scrape

## การตั้งเป้าหมาย SLO และคำนวณ error budget

SLO ประกอบด้วย SLI เป้าหมาย และช่วงเวลา (window) โดยทั่วไปช่วงเวลาจะเป็นแบบเลื่อน (rolling) 28 หรือ 30 วัน เพื่อให้ budget ฟื้นตัวทีละน้อย แทนที่จะถูกรีเซ็ตทุกวันที่หนึ่งของเดือน เป้าหมายเลือกจากประสิทธิภาพในอดีตและความคาดหวังของผู้ใช้ ไม่ใช่ตัวเลขที่ดูดีบนสไลด์นำเสนอ

ตารางด้านล่างแสดงสิ่งที่แต่ละเป้าหมายอนุญาตในช่วงเวลา 30 วัน การคำนวณเป็นเลขคณิตธรรมดา คือ budget เท่ากับ `(1 - SLO) × 30 วัน`

| เป้าหมาย SLO | Error budget | เวลาที่ระบบล่มได้ทั้งหมดใน 30 วัน |
|---|---|---|
| 99% | 1% | 7 ชั่วโมง 12 นาที |
| 99.5% | 0.5% | 3 ชั่วโมง 36 นาที |
| 99.9% | 0.1% | 43 นาที 12 วินาที |
| 99.95% | 0.05% | 21 นาที 36 วินาที |
| 99.99% | 0.01% | 4 นาที 19 วินาที |

สำหรับ SLO ที่อิงตาม request นั้น budget จะคิดเป็นจำนวน request แทนจำนวนนาที ที่ 99.9% และมี request 12 ล้านครั้งในช่วงเวลานั้น ระบบยอมให้ request ล้มเหลวได้ 12,000 ครั้ง budget แบบนี้ยุติธรรมกว่าสำหรับบริการที่มีทราฟฟิกไม่สม่ำเสมอ เพราะระบบล่มตอนตีสามจะใช้ budget น้อยกว่าการล่มแบบเดียวกันในช่วงที่มีผู้ใช้มากที่สุด

โจทย์สัมภาษณ์ที่พบบ่อยคือให้คำนวณ budget ที่เหลืออยู่และความเร็วในการใช้ budget สคริปต์ต่อไปนี้เป็นรูปแบบคำตอบที่ผู้สัมภาษณ์คาดหวังเมื่อโจทย์ต้องการให้เขียนโค้ด

```python
# error_budget.py
from dataclasses import dataclass

@dataclass
class SloWindow:
    objective: float      # 0.999 for a 99.9% SLO
    window_days: int      # rolling window, usually 28 or 30
    total_requests: int   # valid events seen in the window so far
    failed_requests: int  # bad events seen in the window so far

    @property
    def budget_fraction(self) -> float:
        return 1 - self.objective  # 0.001 for 99.9%

    def budget_remaining(self) -> float:
        """1.0 means untouched, 0 means spent, negative means SLO breached."""
        allowed_failures = self.budget_fraction * self.total_requests
        return 1 - self.failed_requests / allowed_failures

    def burn_rate(self, recent_errors: int, recent_total: int) -> float:
        """1.0 means the budget lasts exactly the window; 10 means ten times too fast."""
        return (recent_errors / recent_total) / self.budget_fraction

    def hours_to_exhaustion(self, burn: float) -> float:
        # Remaining share of budget, consumed at `burn` times the sustainable pace
        return self.budget_remaining() * self.window_days * 24 / burn

slo = SloWindow(objective=0.999, window_days=30, total_requests=12_000_000, failed_requests=7_800)
burn = slo.burn_rate(recent_errors=240, recent_total=16_000)
print(f"budget left: {slo.budget_remaining():.0%}")             # 35%
print(f"burn rate: {burn:.1f}")                                 # 15.0
print(f"exhausted in: {slo.hours_to_exhaustion(burn):.1f} h")   # 16.8 h
```

Burn rate เท่ากับ 15 หมายความว่าบริการล้มเหลวที่ 1.5% ของ request ในขณะที่ SLO อนุญาตเพียง 0.1% ด้วยอัตรานี้ budget ที่เหลือ 35% จะหมดภายในเวลาไม่ถึง 17 ชั่วโมง ซึ่งเป็นเหตุผลเพียงพอที่จะปลุกวิศวกรเวร on-call

## การแจ้งเตือน burn rate ด้วยหลายช่วงเวลา

การตั้ง alert บน SLI โดยตรง ("อัตรา error เกิน 0.1%") จะทำให้เกิด page ทุกครั้งที่มีค่าพุ่งขึ้นชั่วขณะ แต่กลับพลาดการรั่วไหลที่เกิดขึ้นอย่างช้า ๆ [บทว่าด้วยการแจ้งเตือนจาก SLO ใน SRE workbook](https://sre.google/workbook/alerting-on-slos/) จึงแนะนำ alert แบบหลายช่วงเวลาและหลาย burn rate แต่ละ alert ตอบคำถามเดียว คือ budget กำลังถูกใช้เร็วจนจะหมดก่อนที่จะมีคนเข้ามาตรวจสอบหรือไม่

เกณฑ์อ้างอิงสำหรับช่วงเวลา 30 วันมีดังนี้

| ระดับความรุนแรง | ช่วงเวลายาว | ช่วงเวลาสั้น | Burn rate | Budget ที่ใช้ไปเมื่อ alert ทำงาน |
|---|---|---|---|---|
| Page | 1 ชั่วโมง | 5 นาที | 14.4 | 2% |
| Page | 6 ชั่วโมง | 30 นาที | 6 | 5% |
| Ticket | 3 วัน | 6 ชั่วโมง | 1 | 10% |

ช่วงเวลายาวให้นัยสำคัญทางสถิติ หนึ่งนาทีที่แย่จะไม่ทำให้เกิด page ส่วนช่วงเวลาสั้นซึ่งยาวเพียงหนึ่งในสิบสองของช่วงเวลายาว ทำให้ alert หยุดทำงานได้เร็วเมื่อเหตุขัดข้องสิ้นสุด page จะไม่ดังต่อไปอีกหนึ่งชั่วโมงหลังจากแก้ไขแล้ว เงื่อนไขทั้งสองต้องเป็นจริงพร้อมกัน

บล็อกแรกบันทึกอัตรา error ในแต่ละช่วงเวลาไว้ล่วงหน้า เพื่อให้ expression ของ alert ทำงานได้เบา บล็อกที่สองกำหนด alert ระดับ page สองตัวสำหรับ SLO 99.9% ซึ่งมีสัดส่วน budget เท่ากับ 0.001

```yaml
# checkout-slo-recording.rules.yml
groups:
  - name: checkout-slo-recording
    interval: 30s
    rules:
      - record: slo:sli_error:ratio_rate5m
        expr: |
          sum(rate(http_requests_total{job="checkout-api", code=~"5.."}[5m]))
          / sum(rate(http_requests_total{job="checkout-api"}[5m]))
      - record: slo:sli_error:ratio_rate1h
        expr: |
          sum(rate(http_requests_total{job="checkout-api", code=~"5.."}[1h]))
          / sum(rate(http_requests_total{job="checkout-api"}[1h]))
      # Same pattern for 30m and 6h, omitted for brevity
```

```yaml
# checkout-slo-alerts.rules.yml
groups:
  - name: checkout-slo-alerts
    rules:
      - alert: CheckoutErrorBudgetFastBurn
        # 2% of the monthly budget spent in one hour
        expr: |
          slo:sli_error:ratio_rate1h > (14.4 * 0.001)
          and slo:sli_error:ratio_rate5m > (14.4 * 0.001)
        labels:
          severity: page
        annotations:
          summary: "checkout-api burns its error budget 14x too fast"
      - alert: CheckoutErrorBudgetSlowBurn
        # 5% of the monthly budget spent in six hours
        expr: |
          slo:sli_error:ratio_rate6h > (6 * 0.001)
          and slo:sli_error:ratio_rate30m > (6 * 0.001)
        labels:
          severity: page
```

การเขียน rule เหล่านี้ด้วยมือสำหรับทุกบริการจะกลายเป็นงานซ้ำซากอย่างรวดเร็ว [Sloth](https://github.com/slok/sloth) เครื่องมือสร้าง SLO แบบโอเพนซอร์ส รับ spec สั้น ๆ แล้วสร้าง recording rule และ alert แบบหลาย burn rate ตามตัวอย่างข้างต้นให้ โดย placeholder `{{.window}}` จะถูกแทนที่ด้วยแต่ละช่วงเวลาที่ Sloth ต้องใช้

```yaml
# checkout-slo.sloth.yml
version: "prometheus/v1"
service: "checkout-api"
labels:
  owner: "payments-team"
slos:
  - name: "requests-availability"
    objective: 99.9
    description: "Checkout requests that do not fail with a 5xx"
    sli:
      events:
        error_query: sum(rate(http_requests_total{job="checkout-api",code=~"5.."}[{{.window}}]))
        total_query: sum(rate(http_requests_total{job="checkout-api"}[{{.window}}]))
    alerting:
      name: CheckoutHighErrorRate
      page_alert:
        labels:
          severity: page
      ticket_alert:
        labels:
          severity: ticket
```

ทีมที่ต้องการรูปแบบที่ไม่ผูกกับผู้ให้บริการรายใดสามารถศึกษา[ข้อกำหนด OpenSLO](https://github.com/OpenSLO/OpenSLO) ซึ่งอธิบาย SLO ด้วย YAML โดยไม่ขึ้นกับ backend ของระบบมอนิเตอร์

## นโยบาย error budget และการตัดสินใจปล่อยเวอร์ชัน

Error budget ที่ไม่มีนโยบายรองรับก็เป็นเพียง dashboard ที่ไม่มีใครลงมือทำอะไร [ตัวอย่าง error budget policy](https://sre.google/workbook/error-budget-policy/) ใน SRE workbook ระบุชัดเจนว่าจะเกิดอะไรขึ้นเมื่อ budget หมด และใครเป็นผู้อนุมัติเรื่องนี้ไว้ล่วงหน้า

นโยบายโดยทั่วไปประกอบด้วย

- **เงื่อนไขที่กระตุ้น** บริการใช้ error budget เกินกำหนดในช่วงเวลาแบบเลื่อน
- **ผลที่ตามมา** หยุดปล่อยฟีเจอร์ ยกเว้นการแก้ไขด้านความปลอดภัยและการเปลี่ยนแปลงที่เพิ่มความน่าเชื่อถือ จนกว่าบริการจะกลับมาอยู่ในเกณฑ์ SLO
- **ช่องทางข้อยกเว้น** เหตุขัดข้องครั้งเดียวที่เกิดจาก dependency นอกเหนือการควบคุมของทีมอาจได้รับการยกเว้น โดยต้องบันทึกการตัดสินใจเป็นลายลักษณ์อักษร
- **การยกระดับปัญหา** ความเห็นที่ไม่ตรงกันจะถูกส่งต่อให้ตำแหน่งที่กำหนดไว้ เช่น CTO ไม่ใช่ตัดสินโดยผู้ที่พูดเสียงดังที่สุด

ทีมผลิตภัณฑ์และทีมวิศวกรรมลงนามในนโยบายนี้ก่อนที่จะเกิดการละเมิดครั้งแรก และนั่นคือหัวใจของเรื่องนี้ การระงับการปล่อยเวอร์ชันจะกลายเป็นกฎที่ตกลงกันไว้แล้ว ไม่ใช่การโต้เถียงกันกลางเหตุขัดข้อง ผู้สัมภาษณ์มักถามด้วยว่าจะเกิดอะไรขึ้นหาก budget แทบไม่เคยถูกใช้ คำตอบที่คาดหวังคือ SLO อาจหลวมเกินไป หรือทีมปล่อยเวอร์ชันอย่างระมัดระวังเกินเหตุ และควรใช้ budget นั้นไปกับการปล่อยเวอร์ชันที่เร็วขึ้นหรือการย้ายระบบที่กล้าเสี่ยงมากขึ้น

> **กับดักเรื่อง SLA ในการสัมภาษณ์**
>
> การตั้ง SLO ภายในให้เท่ากับ SLA ที่ให้ลูกค้าจะไม่เหลือระยะปลอดภัยเลย การละเมิด SLO ครั้งแรกก็คือค่าปรับตามสัญญาทันที SLO จึงต้องเข้มงวดกว่า SLA เพื่อให้ alert ทำงานและการระงับการปล่อยเวอร์ชันเริ่มต้นขึ้นในขณะที่ยังรักษาสัญญาได้อยู่

## การลด toil, เวร on-call และ postmortem แบบไม่กล่าวโทษ

เวลาของ SRE แบ่งออกเป็นงานปฏิบัติการและงานวิศวกรรม งานปฏิบัติการครอบคลุมเวร on-call, ticket และการแทรกแซงด้วยมือ ส่วนงานวิศวกรรมครอบคลุมระบบอัตโนมัติ การวางแผนขีดความสามารถ และฟีเจอร์ด้านความน่าเชื่อถือ เมื่อ toil เกินเกณฑ์ 50% ทีม SRE จะส่งงานบางส่วนกลับไปให้ทีมพัฒนาหรือลงทุนกับระบบอัตโนมัติ มิฉะนั้นทีม SRE ก็จะกลายเป็นเพียงทีมปฏิบัติการที่เปลี่ยนชื่อตำแหน่งใหม่

สุขภาพของเวร on-call ต้องถูกวัด ไม่ใช่คาดเดา สัญญาณที่มีประโยชน์ได้แก่ จำนวน page ต่อกะ สัดส่วนของ page ที่ต้องลงมือแก้ไขจริง และเวลาที่ใช้ในการรับทราบ (time to acknowledge) page ที่ไม่ต้องทำอะไรเลยถือเป็นข้อบกพร่องของระบบแจ้งเตือน และต้องแก้ไขหรือลบทิ้ง alert ตามอาการที่อิงกับ burn rate ของ SLO ดังเช่น rule ข้างต้น ช่วยลดจำนวน page ได้มากเมื่อเทียบกับ alert ที่อิงกับ CPU, หน่วยความจำ หรือการ restart ของ pod แต่ละตัว

เมื่อเกิดเหตุขัดข้อง [บทว่าด้วยวัฒนธรรม postmortem](https://sre.google/sre-book/postmortem-culture/) ในหนังสือ SRE อธิบายกระบวนการทบทวนที่ตามมา postmortem จะบันทึกผลกระทบในหน่วยของ SLO (ใช้ budget ไปเท่าใด) ลำดับเหตุการณ์ ปัจจัยที่มีส่วนทำให้เกิดปัญหา และ action item พร้อมผู้รับผิดชอบและกำหนดเวลา โดยไม่ระบุชื่อบุคคลใดว่าเป็นต้นเหตุ คำถามต่อเนื่องที่พบบ่อยมีสองข้อ ข้อแรกคือจะทำอย่างไรให้ action item ถูกดำเนินการจริง (ติดตามใน backlog เดียวกับฟีเจอร์และทบทวนในการประชุมประจำ) ข้อที่สองคือเมื่อใดที่ต้องเขียน postmortem (ทุกเหตุขัดข้องที่ใช้ budget ไปในสัดส่วนที่มีนัยสำคัญ ทุก page ที่ปลุกใครสักคน และทุกกรณีที่ข้อมูลสูญหาย)

Golden signal ทั้งสี่จากหนังสือ SRE ได้แก่ latency, ทราฟฟิก, error และ saturation ช่วยเติมเต็มภาพรวมของการมอนิเตอร์ latency และ error มักกลายเป็น SLI ส่วนทราฟฟิกและ saturation ใช้กับการวางแผนขีดความสามารถและ dashboard มากกว่าการส่ง page

## คำถามสัมภาษณ์ SRE พร้อมแนวคำตอบที่คาดหวัง

ต่อไปนี้คือคำถามที่วนกลับมาในการสัมภาษณ์ตำแหน่ง SRE และ DevOps ระดับ senior พร้อมแก่นของคำตอบที่ดี [โมดูลสัมภาษณ์เรื่องหลักการ SRE](/technologies/devops/interview-questions/sre-principles) ฝึกหัวข้อเดียวกันนี้อย่างละเอียด และ[โมดูล alerting และ incident response](/technologies/devops/interview-questions/alerting-incident-response) ครอบคลุมด้านเวร on-call

**ถาม: SLI, SLO และ SLA ต่างกันอย่างไร**

SLI คืออัตราส่วนที่วัดได้ SLO คือเป้าหมายภายในของอัตราส่วนนั้นในช่วงเวลาหนึ่ง และ SLA คือสัญญากับภายนอกที่มีบทลงโทษ SLO ต้องเข้มงวดกว่า SLA เพื่อให้ทีมตอบสนองได้ก่อนเกิดความเสียหายทางการเงิน

**ถาม: ทำไมไม่ตั้ง SLO ไว้ที่ 100%**

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

**ถาม: จงกำหนด SLO สำหรับ API ระบบชำระเงิน (checkout)**

คำตอบที่ดีจะเลือก SLI สองตัว (ความพร้อมใช้งานโดยไม่นับ 4xx เป็นความล้มเหลว และ latency ที่ต่ำกว่าเกณฑ์ ทั้งคู่วัดที่ load balancer) ใช้ช่วงเวลาแบบเลื่อน 30 วัน ตั้งเป้าหมายจากข้อมูลไตรมาสล่าสุด แล้วอธิบายว่าการแจ้งเตือนและ error budget policy ต่อยอดจาก SLO นี้อย่างไร คำตอบที่อ่อนแบบคลาสสิกคือการพูดเพียงว่า "uptime 99.99%" โดยไม่บอกว่าวัดอะไร

**ถาม: ทำไม alert ที่อิงกับ percentile เช่น latency p99 จึงไม่เหมาะเป็น alert ของ SLO**

ค่า p99 ในช่วงเวลาสั้นมีสัญญาณรบกวนสูงและไม่สามารถรวมค่าข้าม instance ได้ การแปลง latency ให้เป็นอัตราส่วนของ request ที่ต่ำกว่าเกณฑ์ทำให้นำมารวมกันได้ เปรียบเทียบกับ SLI ด้านความพร้อมใช้งานได้ และใช้ร่วมกับ alert แบบ burn rate ได้

**ถาม: จงอธิบาย burn rate และเหตุผลที่ alert ใช้สองช่วงเวลา**

Burn rate คืออัตรา error ที่สังเกตได้หารด้วยสัดส่วน budget ค่า 1 หมายความว่า budget จะหมดพอดีเมื่อสิ้นสุดช่วงเวลา ช่วงเวลายาวช่วยกรองค่าที่พุ่งขึ้นชั่วขณะ ส่วนช่วงเวลาสั้นช่วยให้ alert หยุดทำงานได้เร็วหลังระบบฟื้นตัว

**ถาม: toil คืออะไร และควบคุมอย่างไร**

คืองานที่ทำด้วยมือ ซ้ำซาก ทำเป็นอัตโนมัติได้ ไม่สร้างคุณค่าระยะยาว และเพิ่มขึ้นตามขนาดของบริการ toil ต้องถูกวัด ถูกจำกัด (Google ใช้เกณฑ์ 50%) และลดลงด้วยระบบอัตโนมัติหรือการส่งงานคืนให้ทีมที่เป็นเจ้าของบริการ

**ถาม: อะไรทำให้ postmortem เป็นแบบ blameless**

postmortem ที่ดีมุ่งเน้นเงื่อนไขของระบบที่เปิดโอกาสให้เกิดความล้มเหลว สันนิษฐานว่าทุกคนตัดสินใจอย่างสมเหตุสมผลตามข้อมูลที่มีในขณะนั้น และสร้าง action item ที่ถูกติดตามผล บททดสอบง่าย ๆ คือ วิศวกรที่เกี่ยวข้องกล้าเล่ารายละเอียดทุกอย่างโดยไม่หวาดกลัวหรือไม่

คำถามเรื่องการมอนิเตอร์มักตามมาหลังคำถามเรื่อง SLO ในการสัมภาษณ์ครั้งเดียวกัน [คู่มือคำถามสัมภาษณ์ Prometheus](/blog/devops/prometheus-vs-grafana-vs-datadog-monitoring-devops-interview) ครอบคลุม PromQL ประเภทของ metric และ cardinality ส่วน[หน้าเทคโนโลยี DevOps](/technologies/devops) รวบรวมทุกโมดูลไว้สำหรับการเตรียมตัวในภาพกว้าง

## สรุป: SLO และ error budget ในการใช้งานจริง

- กำหนด SLI แต่ละตัวเป็นอัตราส่วนของเหตุการณ์ที่ดีต่อเหตุการณ์ที่ถูกต้อง วัดให้ใกล้ผู้ใช้มากที่สุดเท่าที่ข้อมูลเอื้ออำนวย และสำหรับ API ส่วนใหญ่ไม่นับ 4xx เป็นความล้มเหลว
- เลือก SLO จากข้อมูลในอดีตพร้อมช่วงเวลาแบบเลื่อน 28 หรือ 30 วัน และต้องเข้มงวดกว่า SLA ของลูกค้าเสมอ
- แปลงเป้าหมายให้เป็น budget ในหน่วยนาทีหรือจำนวน request และจำตัวเลขให้ขึ้นใจ: 99.9% ใน 30 วันเท่ากับ 43 นาที
- ตั้ง alert ตาม burn rate ด้วยคู่ช่วงเวลา (14.4 ที่ 1 ชั่วโมงและ 5 นาที, 6 ที่ 6 ชั่วโมงและ 30 นาที) ไม่ใช่อัตรา error ดิบหรือ CPU
- ใช้ Sloth หรือเครื่องมือที่คล้ายกันสร้าง rule เมื่อมีบริการที่ใช้ SLO มากกว่าสองสามตัว เพื่อให้เกณฑ์สอดคล้องกันทั้งหมด
- เขียนและลงนาม error budget policy ก่อนการละเมิดครั้งแรก รวมถึงกฎการระงับการปล่อยเวอร์ชันและขั้นตอนการยกระดับปัญหา
- ติดตาม toil จำนวน page และ action item จาก postmortem ด้วยความเข้มงวดเช่นเดียวกับการพัฒนาฟีเจอร์

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/th/blog/devops/sre-principles-2026-slos-error-budgets-interview-questions