1. SRE Core Concepts

ในฐานะ Cloud Engineer คุณคุ้นกับการทำให้ระบบ "ทำงานได้" อยู่แล้ว — SRE ต่างตรงที่ มองความน่าเชื่อถือเป็น ตัวเลขที่จัดการได้ และยอมรับว่า 100% reliability คือเป้าหมายที่ผิด

Core Concepts

SLI / SLO / SLA

• SLI (Service Level Indicator) — ตัวเลขที่วัด "คุณภาพบริการ" จริง ๆ เช่น สัดส่วน request ที่สำเร็จ, latency ที่ p99. เป็น สิ่งที่วัด.
• SLO (Service Level Objective) — เป้าหมายภายในที่เราตั้งกับ SLI นั้น เช่น "99.9% ของ request ต้องสำเร็จใน 30 วัน". เป็น สิ่งที่ตั้งเป้า.
• SLA (Service Level Agreement) — สัญญากับลูกค้า + บทลงโทษ (เช่น คืนเงิน) ถ้าไม่ถึงเป้า. SLA มักตั้งหลวมกว่า SLO เสมอ เพื่อให้ทีมมี buffer.

Error Budget

Error budget = 100% − SLO. ถ้า SLO คือ 99.9% ต่อเดือน → มี budget ให้ "พัง" ได้ 0.1% ของเวลา (~43 นาที/เดือน).

Toil

Toil = งาน manual, ซ้ำซาก, automate ได้, ไม่มี lasting value และโตตามขนาดระบบ (เช่น restart service ด้วยมือทุกครั้งที่ล่ม). Google แนะนำให้ toil < 50% ของเวลา SRE ที่เหลือเอาไปทำ engineering เพื่อลด toil.

Reliability vs Availability

• Availability — ระบบ "ตอบสนอง" หรือไม่ (มัก measure เป็น uptime %).
• Reliability — ระบบ "ทำงานถูกต้องตามที่ควร" ในช่วงเวลาหนึ่ง. ระบบอาจ up แต่ ตอบช้าจนใช้ไม่ได้ = available แต่ไม่ reliable.

SRE vs DevOps

พูดสั้น ๆ: "class SRE implements interface DevOps" — DevOps บอกว่าควรทำอะไร (ทลาย silo, automate, วัดผล) ส่วน SRE ให้ วิธีที่เป็นรูปธรรม พร้อมตัวเลขกำกับ.

เชื่อมกับ AWS / Cloud ที่คุณรู้อยู่แล้ว

• CloudWatch Metrics + Alarms = ที่มาของ SLI และการ alert เมื่อ SLO เสี่ยงพลาด.
• ALB/target group health + 5xx metrics = แหล่ง SLI ด้าน availability ตรง ๆ.
• AWS Service Health / RDS Multi-AZ SLA = ตัวอย่าง SLA จริงที่ผู้ให้บริการรับกับคุณ — สังเกตว่า SLA ผู้ให้บริการก็ตั้งหลวม (เช่น 99.99%) พร้อม service credit.
• งาน manual ที่คุณเคยทำ เช่น rotate log, resize disk ด้วยมือ = toil ที่ SRE จะ automate.

ตัวอย่าง SLO ที่คำนวณจาก metric แบบ PromQL:

# availability SLI = สัดส่วน request ที่ไม่ใช่ 5xx ใน 30 วัน
sum(rate(http_requests_total{status!~"5.."}[30d]))
  /
sum(rate(http_requests_total[30d]))

Error budget policy มักเขียนเป็น config ประกอบ automation เช่น:

slo:
  service: checkout-api
  objective: 0.999          # 99.9% ต่อ 30 วัน
  window: 30d
policy:
  freeze_deploys_when_budget_below: 0.1  # เหลือ budget < 10% → หยุด deploy
  page_oncall_when_budget_below: 0.25

คำถาม interview ที่เจอบ่อย + แนวคำตอบ

1. "SLI, SLO, SLA ต่างกันยังไง?" → SLI คือสิ่งที่วัด, SLO คือเป้าที่ตั้งเอง (ภายใน), SLA คือสัญญากับลูกค้า+ค่าปรับ. เน้นว่า SLA หลวมกว่า SLO เสมอเพื่อกัน buffer.

2. "ทำไมไม่ตั้ง SLO ที่ 100%?" → เพราะ 100% แพงมากและไม่คุ้ม, ปิดกั้นการปล่อย feature, และผู้ใช้แทบแยกไม่ออกจาก 99.9%. Error budget ที่ >0 คือสิ่งที่ทำให้ทีม "กล้า" deploy.

3. "Error budget เอาไปทำอะไร?" → ใช้ตัดสินใจ: budget เหลือ → เร่ง ship; budget หมด → freeze + โฟกัส reliability. เป็นกลไก align dev/ops ด้วย data แทนอารมณ์.

4. "SRE ต่างจาก DevOps / จากงาน ops เดิมยังไง?" → DevOps เป็นปรัชญา; SRE เป็น implementation ที่วัดผลด้วย SLO/error budget, จำกัด toil, และใช้ blameless postmortem.

5. "Toil คืออะไร จัดการยังไง?" → งาน manual ซ้ำ ๆ ที่ scale ตามระบบ; วัดมัน, ตั้งเพดาน (<50%), แล้วลงทุน automate.

Pitfalls — จุดที่ผู้สมัครมักพลาด

Quiz ท้ายบท

Cheat Sheet — อ่านก่อนเข้าห้องสัมภาษณ์