SRE — Site Reliability Engineering ที่ DevOps ต้องรู้ 🚒

จากโพสต์ที่แล้วเราเรียน Cloud Architecture — ออกแบบระบบบน Cloud ให้แข็งแกร่ง แต่สร้างเสร็จแล้ว... ใครจะดูแลให้มันทำงานต่อเนื่อง 24/7?

คำตอบคือ SRE — Site Reliability Engineering — แนวคิดจาก Google ที่ทำให้ "ระบบไม่ล่ม" เป็นเรื่องของ engineering ไม่ใช่โชค 🚒🐕

"SRE is what happens when you ask a software engineer to design an operations team." — Ben Treynor, VP Engineering @ Google (ผู้ก่อตั้ง SRE)

🤔 SRE คืออะไร? ต่างจาก DevOps ยังไง?

SRE (Site Reliability Engineering) คือ discipline ที่ใช้ software engineering approach มาแก้ปัญหา operations:

หลายคนงงว่า SRE กับ DevOps ต่างกันยังไง? ตารางด้านล่างจะช่วยให้เข้าใจความแตกต่างชัดเจน โดยเฉพาะการที่ SRE มีแนวคิด "วัดผลด้วยตัวเลข" และ "จำกัด toil work" ที่ชัดเจนกว่า DevOps ที่เน้นเรื่อง culture และ process เป็นหลัก

จากตารางจะเห็นว่า SRE เป็น "การทำให้ DevOps เป็นรูปธรรม" ด้วยการกำหนดเมตริกที่ชัดเจน ตัวอย่างเช่น แทนที่จะบอกว่า "ระบบต้องเสถียร" SRE จะบอกว่า "ระบบต้อง uptime 99.9%" และมีวิธีวัดผลที่ชัดเจน แนวคิด Error Budget ทำให้การสมดุลระหว่างความเสถียรและการ deploy feature ใหม่เป็นเรื่องของ data ไม่ใช่ความรู้สึก

💡 จำง่ายๆ: DevOps = "วัฒนธรรม" (philosophy) | SRE = "วิธีทำจริง" (implementation) — SRE implements DevOps

📊 SLI / SLO / SLA — วัด Reliability ยังไง?

หัวใจของ SRE คือการ วัด reliability ด้วยตัวเลข ไม่ใช่ความรู้สึก:

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

จากไดอะแกรมเห็นได้ว่า SLI เป็นตัววัดที่เก็บข้อมูลจริงจากระบบ SLO เป็นเป้าหมายที่เรากำหนดขึ้นจาก SLI และ SLA เป็นข้อตกลงกับลูกค้าที่มี consequence จริง (เช่น คืนเงิน) หลักสำคัญคือ SLO ต้อง "เข้มงวดกว่า" SLA เพราะต้องมี buffer ไว้จัดการความเสี่ยง

SLI ที่สำคัญ — "The Four Golden Signals"

Google แนะนำให้เริ่มต้นด้วยการวัด "สี่สัญญาณทอง" ซึ่งครอบคลุมประสบการณ์ผู้ใช้และสุขภาพระบบอย่างครอบคลุม การมี SLI ทั้งสี่ตัวจะช่วยให้เราเห็นภาพรวมของระบบและสามารถตรวจจับปัญหาได้รวดเร็ว

สิ่งสำคัญคือ Latency ต้องแยก "success requests" กับ "error requests" เพราะ error มักจะเร็วกว่า (fail fast) และอาจทำให้เราไม่เห็นปัญหาจริง Traffic จะบอกความต้องการ (demand) Errors บอกคุณภาพ และ Saturation บอกขีดจำกัดของระบบ การมีทั้งสี่ตัวจะให้ภาพที่สมบูรณ์

# Prometheus — วัด SLI
# Latency (p99)
histogram_quantile(0.99,
  rate(http_request_duration_seconds_bucket[5m])
)

# Error Rate
sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))

# Availability (ใน 30 วัน)
1 - (
  sum(rate(http_requests_total{status=~"5.."}[30d]))
  /
  sum(rate(http_requests_total[30d]))
)

โค้ด Prometheus ข้างต้นแสดงวิธีการคำนวณ SLI พื้นฐาน การใช้ histogram สำหรับ latency จะให้ความยืดหยุ่นในการคำนวณ percentile ต่างๆ ส่วนการคำนวณ error rate ต้องระวังเรื่อง division by zero และควรมี fallback value การคำนวณ availability แบบ 30 วันจะให้มุมมองระยะยาวที่เสถียรกว่าการดูแค่ช่วงเวลาสั้นๆ

ตัวอย่าง SLO Document

# SLO: User API Service
# ──────────────────────
# SLI: Availability
#   Definition: % of non-5xx responses
#   SLO: 99.9% over 30-day rolling window
#   Error Budget: 0.1% = ~43 minutes/month
#
# SLI: Latency
#   Definition: p99 response time
#   SLO: p99 < 300ms for 99% of requests
#
# SLI: Freshness
#   Definition: data staleness
#   SLO: 95% of reads return data < 1 min old
#
# Consequences:
#   If error budget exhausted:
#   → Freeze feature deployments
#   → Focus on reliability improvements
#   → Require SRE approval for any change

💰 Error Budget — งบสำหรับ "พลาด"

Error Budget คือ "งบ" ที่ระบบ "ผิดพลาดได้" — คำนวณจาก SLO:

Error Budget เป็นแนวคิดปฏิวัติที่ทำให้การสมดุลระหว่างความเสถียรและการพัฒนา feature ใหม่เป็นเรื่องของคณิตศาสตร์ ไม่ใช่การต่อสู้กันระหว่างทีม Dev กับ Ops ตารางด้านล่างแสดงให้เห็นว่า SLO ที่สูงขึ้น (99.99%) จะมี Error Budget น้อยมาก ซึ่งหมายความว่าต้องระมัดระวังมากขึ้นในการ deploy

จากตารางจะเห็นว่าความแตกต่าง 0.09% ระหว่าง 99.9% กับ 99.99% ส่งผลให้ Error Budget ต่างกัน 10 เท่า! นี่คือเหตุผลที่ SLO ต้องกำหนดให้สมเหตุสมผลกับ business requirement ไม่ใช่ยึดติดที่ "9 ยิ่งเยอะยิ่งดี" กราฟด้านล่างแสดงตัวอย่างการ track Error Budget ที่ช่วยให้ทีมเห็นภาพปัจจุบันและตัดสินใจได้ทันเวลา

Error Budget bar ข้างต้นแสดงสถานการณ์ต่างๆ ที่อาจเกิดขึ้น เมื่อเหลือ 65% (สีเขียว) ยังสามารถ deploy ได้ตามปกติ เมื่อเหลือ 15% (สีเหลือง) ต้องเริ่มระมัดระวังและอาจต้องชะลอการ deploy บาง feature เมื่อหมด (สีแดง) ต้อง freeze การ deploy feature ใหม่ทันทีและ focus ที่การแก้ปัญหา reliability นโยบายนี้ทำให้ทีมมี incentive ที่ชัดเจนในการสร้างระบบที่เสถียร

💡 หลักการ: Error Budget เหลือเยอะ → deploy features เร็วได้ | Error Budget ใกล้หมด → ชะลอ focus reliability | Error Budget หมด → Feature Freeze!

# Grafana Dashboard — Error Budget Tracker
# ─────────────────────────────────────────
# Total requests (30d)
total = sum(increase(http_requests_total[30d]))

# Failed requests (30d)
failed = sum(increase(http_requests_total{status=~"5.."}[30d]))

# Error budget (SLO 99.9%)
budget_total = total * 0.001        # 0.1% allowed failures
budget_used  = failed
budget_remaining = (budget_total - budget_used) / budget_total * 100

# Alert เมื่อ budget < 20%
# → Slack notification to team
# → Require SRE review for deploys

🚨 Incident Management — เมื่อระบบล่ม

Severity Levels

การกำหนด severity levels ที่ชัดเจนช่วยให้ทีมสามารถ prioritize และ respond ได้อย่างเหมาะสม ไม่ใช่ว่าทุกปัญหาต้องถือเป็น "emergency" ทั้งหมด การมี response time ที่แตกต่างกันจะช่วยให้ทีมใช้พลังงานอย่างมีประสิทธิภาพและไม่เกิด burnout

จากตารางจะเห็นว่า P1 เป็นเรื่องจริงจัง (5 นาที) เพราะ impact ต่อ user ทั้งหมด ส่วน P4 สามารถรอได้เพราะไม่กระทบ functionality หลักการสำคัญคือ "impact ต่อ user" ไม่ใช่ว่า server ตัวไหนพัง เช่น monitoring server down อาจเป็นแค่ P3 ถ้าไม่กระทบ user experience โดยตรง

Incident Response Flow

กระบวนการ incident response ต้องมีขั้นตอนที่ชัดเจนและฝึกซ้อมเป็นประจำ ไม่ใช่รอให้เกิดปัญหาจริงแล้วค่อยคิดว่าต้องทำอะไร flow ด้านล่างเน้น "mitigation ก่อน investigation" เพราะการหยุดปัญหาสำคัญกว่าการหา root cause ในช่วงแรก

Flow นี้แสดงให้เห็นว่าการ "detect" เร็วมีความสำคัญมาก และการ "mitigate" ไม่จำเป็นต้องเป็น permanent fix อาจเป็นการ rollback หรือ workaround ก่อน จุดสำคัญคือ Postmortem ไม่ใช่ "optional" แต่เป็นส่วนหนึ่งของ incident response เพื่อป้องกันปัญหาเดิมไม่ให้เกิดซ้ำ

Incident Timeline ตัวอย่าง

Timeline ที่ดีจะแสดงให้เห็น decision making process และ lesson learned การจดเวลาที่แม่นยำช่วยให้ postmortem มีความน่าเชื่อถือ และการ track action items จะทำให้การตอบสนองใน incident ครั้งต่อไปดีขึ้น ตัวอย่างด้านล่างแสดง incident ที่ resolve ภายใน 12 นาที ซึ่งถือว่าเร็วมาก

จาก timeline จะเห็นว่าการมี deployment tool ที่ดี (ArgoCD) ทำให้ rollback ได้เร็ว (2 นาที) การ communicate กับ customer ทำหลังจากระบบ stable แล้ว ไม่ใช่ตอนที่กำลัง firefighting อยู่ การจด timeline แบบนี้จะกลายเป็น input สำคัญของ postmortem เพื่อวิเคราะห์ว่าทำอะไรได้ดี ทำอะไรควรปรับปรุง

Incident Commander — Roles

# Incident Roles (P1/P2)
# ──────────────────────
# 🎖️ Incident Commander (IC)
#    - ตัดสินใจ, coordinate, สั่งการ
#    - ไม่ต้อง debug เอง
#
# 🔧 Technical Lead
#    - วิเคราะห์ root cause
#    - Execute mitigation
#
# 📢 Communications Lead
#    - อัพเดท status page
#    - แจ้ง stakeholders
#    - เขียน customer comms
#
# 📝 Scribe
#    - จด timeline ทุกอย่าง
#    - Record decisions & actions

📝 Blameless Postmortem — เรียนรู้จากความผิดพลาด

Postmortem คือ document ที่เขียนหลังเกิด incident — เน้น "เรียนรู้" ไม่ใช่ "โทษคน" (blameless!):

Blameless postmortem เป็นหัวใจสำคัญของ SRE culture เพราะถ้าคนกลัวถูกโทษ จะไม่มีใครอยากรายงานปัญหาหรือเขียน postmortem ที่ซื่อสัตย์ การสร้าง culture ที่เน้น "เรียนรู้จากความผิดพลาด" จะทำให้ระบบแข็งแกร่งขึ้นในระยะยาว template ด้านล่างแสดงโครงสร้างที่ครบถ้วนของ postmortem ที่ดี

# Postmortem Template
# ═══════════════════

## Incident: Production API Outage
## Date: 2026-03-07 14:23-14:35 UTC
## Duration: 12 minutes
## Severity: P1
## Impact: 100% of API requests failed for 12 minutes
##         ~18,000 failed requests, ~2,400 users affected

## Summary
Deploy v2.4.1 contained a memory leak in the user session
handler. Under load, pods exceeded memory limits and were
OOMKilled. The auto-scaler created new pods that also crashed,
causing a cascading failure.

## Root Cause
Memory leak in UserSessionMiddleware — each request allocated
a new 2MB buffer that was never garbage collected due to a
circular reference. Under 500 req/s, memory grew ~1GB/min.

## Timeline
- 14:20 — Deploy v2.4.1 rolled out (3/6 pods)
- 14:23 — Alert: Error rate > 5%
- 14:25 — IC assigned, war room opened
- 14:30 — Identified memory leak in v2.4.1
- 14:32 — Rollback to v2.4.0
- 14:35 — Service restored

## What Went Well
- Alert fired within 3 minutes of impact
- Quick rollback via ArgoCD (2 minutes)
- Clear incident response process followed

## What Went Wrong
- No memory profiling in CI pipeline
- Load test only ran at 100 req/s (prod = 500 req/s)
- Canary deployment was skipped for "small change"

## Action Items
1. [P1] Add memory leak detection to CI — @somchai — Due: Mar 14
2. [P1] Load test at 2x production traffic — @somying — Due: Mar 14
3. [P2] Enforce canary deployment for all changes — @team — Due: Mar 21
4. [P3] Add OOMKill alert (before cascade) — @ops — Due: Mar 28

## Lessons Learned
- "Small changes" can have big impacts — always canary
- Memory profiling should be part of CI, not manual
- Rollback capability (ArgoCD) saved us — invest in it

จาก postmortem template จะเห็นว่าการแยก "What Went Well" กับ "What Went Wrong" ช่วยให้เกิด balanced view ไม่ใช่โฟกัสแค่สิ่งที่ผิดพลาด Action Items ต้องมี owner และ due date ที่ชัดเจน ไม่ใช่แค่ "เราจะปรับปรุง" อย่างคลุมเครือ การ track action items completion เป็นสิ่งสำคัญที่บ่อยครั้งถูกมองข้าม

🐕 Blameless Culture: "สมชาย deploy code ที่มี bug" → ❌ | "ระบบไม่มี memory check ใน CI pipeline ที่จะ catch bug นี้" → ✅

🔧 Toil Reduction — ลดงาน manual

Toil = งานที่ manual, ซ้ำๆ, automate ได้, ไม่มี lasting value — Google กำหนดว่า SRE ต้องใช้เวลาทำ toil ไม่เกิน 50%:

จากตารางเปรียบเทียบจะเห็นว่า toil มักจะเป็นงานที่ซ้ำซาก คาดการณ์ได้ และไม่สร้างคุณค่าระยะยาว ส่วน engineering work จะสร้าง "leverage" คือลงทุนครั้งเดียวแต่ได้ประโยชน์ต่อเนื่อง การแปลง manual task เป็น automation ไม่ใช่แค่การเขียน script แต่รวมถึงการออกแบบ monitoring, error handling และ maintenance ระยะยาว

# วัด Toil — track เวลาที่ใช้
# ──────────────────────────
# Week 1: SRE Team Time Breakdown
#
# Engineering work:  25 hours (50%)  ← target: > 50%
# Toil:              15 hours (30%)  ← target: < 50%
# On-call:            5 hours (10%)
# Training/misc:      5 hours (10%)
#
# Top Toil Items:
# 1. Manual DB backups         — 4h/week → AUTOMATE
# 2. Certificate renewals      — 3h/week → cert-manager
# 3. Capacity request tickets  — 3h/week → self-service
# 4. Log investigation         — 5h/week → better alerting

การ track เวลาแบบนี้จะให้ insight ที่ชัดเจนว่าทีมใช้เวลาไปกับอะไรบ้าง การมี target 50% engineering work ไม่ใช่ตัวเลขมหัศจรรย์ แต่เป็น guideline ที่ช่วยให้ทีมไม่จมอยู่กับงาน manual จนไม่มีเวลาปรับปรุงระบบ การระบุ "Top Toil Items" จะช่วยให้ prioritize การ automate ตาม impact

📟 On-Call Best Practices

On-Call Rotation

# PagerDuty Schedule Example
# ──────────────────────────
# Primary:   สมชาย → สมหญิง → สมศักดิ์ (rotate weekly)
# Secondary: สมศักดิ์ → สมชาย → สมหญิง (backup)
#
# Rules:
# - Primary responds within 5 min (P1) / 30 min (P2)
# - If no response in 10 min → escalate to Secondary
# - If no response in 20 min → escalate to Engineering Manager
#
# Compensation:
# - On-call allowance per week
# - Time off after high-severity incidents
# - No more than 25% of time on-call per quarter

โครงสร้าง on-call ข้างต้นแสดงระบบ rotation ที่สมดุลระหว่าง coverage และ fairness การมี secondary backup ช่วยลดความเครียดของ primary และสร้าง safety net การจำกัดไม่เกิน 25% ต่อไตรมาสช่วยป้องกัน burnout ที่สำคัญคือการมี escalation path ที่ชัดเจนเพื่อไม่ให้เกิดสถานการณ์ที่ on-call engineer ต้องรับผิดชอบเกินขีดจำกัด

Alerting — Alert ที่ดี vs Alert ที่แย่

การออกแบบ alerting ที่ดีเป็นศิลปะที่ต้องสมดุลระหว่าง "จับปัญหาได้ครบ" กับ "ไม่รบกวนโดยไม่จำเป็น" Alert fatigue คือศัตรูใหญ่ของ SRE เพราะเมื่อ alert มากเกินไป คนจะเริ่มเพิกเฉยแม้กระทั่งปัญหาจริง หลักสำคัญคือ alert ต้อง "actionable" เสมอ

จากตารางจะเห็นว่า alert ที่ดีมุ่งเน้น "impact ต่อ user" ไม่ใช่ "server metrics" เพราะ CPU สูงไม่ได้แปลว่า user ได้รับผลกระทบเสมอไป การมี runbook link ช่วยให้ on-call engineer สามารถ respond ได้เร็ว โดยเฉพาะช่วงกลางคืนหรือคนใหม่ที่ยังไม่คุ้นเคยระบบ

# Prometheus Alert Rules
groups:
  - name: sre-alerts
    rules:
      # ✅ ดี: User-facing, actionable
      - alert: HighErrorRate
        expr: |
          sum(rate(http_requests_total{status=~"5.."}[5m]))
          / sum(rate(http_requests_total[5m])) > 0.01
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Error rate > 1% for 5 minutes"
          runbook: "https://wiki.example.com/runbooks/high-error-rate"
          dashboard: "https://grafana.example.com/d/api-overview"

      # ✅ ดี: SLO-based alert
      - alert: ErrorBudgetBurnRate
        expr: |
          error_budget_remaining < 0.2
        labels:
          severity: warning
        annotations:
          summary: "Error budget < 20% remaining this month"
          action: "Consider slowing deployments"

      # ❌ แย่: CPU alert (not user-facing)
      # - alert: HighCPU
      #   expr: cpu_usage > 80
      #   → CPU สูงไม่ได้แปลว่า user ได้รับผลกระทบ!

Prometheus alert rules ข้างต้นแสดงความแตกต่างระหว่าง alert ที่ดีกับแย่ HighErrorRate alert เน้น user impact และมี context ครบ (runbook, dashboard) Error Budget alert เป็น proactive warning ที่ช่วยป้องกันปัญหาก่อนเกิด ส่วน CPU alert ถูก comment ออกเพราะไม่ relate กับ user experience โดยตรง ข้อสำคัญคือ `for: 5m` ช่วยกรอง transient spike

📈 Capacity Planning

Capacity Planning คือการ "เดาอนาคต" อย่างมีหลักการ แทนที่จะรอให้ระบบ overload แล้วค่อย panic buying การทำ forecasting ด้วย data จะช่วยให้วางแผนและจัดซื้อ infrastructure ได้ทันเวลา โดยเฉพาะในยุคที่ hardware procurement ใช้เวลานาน

# Capacity Planning Questions
# ──────────────────────────
# 1. ปัจจุบันใช้ resource เท่าไร? (baseline)
# 2. Growth rate เท่าไร? (trend)
# 3. เมื่อไรจะถึง limit? (forecast)
# 4. ต้องเพิ่มอะไร เมื่อไร? (plan)

# PromQL — Forecast disk full
predict_linear(
  node_filesystem_avail_bytes{mountpoint="/"}[7d],
  30 * 24 * 3600    # predict 30 days ahead
) < 0
# → Alert: "Disk will be full in < 30 days"

# PromQL — Traffic growth trend
rate(http_requests_total[30d])
# → ถ้าโต 20%/month → plan capacity 3 months ahead

PromQL ข้างต้นแสดงการใช้ predict_linear() ในการคาดการณ์ disk usage และ traffic growth การ predict 30 วันข้างหน้าให้เวลาเพียงพอในการ procure resource ใหม่ แต่ต้องระวังว่า linear prediction อาจไม่เหมาะกับ seasonal traffic หรือ sudden spike การมี alert ที่แจ้งล่วงหน้าจะช่วยให้ไม่ต้องมา firefighting ตอนดึก

🛡️ Chaos Engineering — ทดสอบความแข็งแกร่ง

Chaos Engineering = ทำลายระบบตัวเองก่อนที่ระบบจริงจะพัง เพื่อหาจุดอ่อน:

Chaos Engineering คือการ "ทำลายระบบตัวเอง" อย่างมีเป้าหมายเพื่อค้นหาจุดอ่อนก่อนที่มันจะพังจริงในเวลาที่ไม่เหมาะ การทำ controlled failure จะช่วยให้เราเข้าใจพฤติกรรมของระบบในสถานการณ์ที่ไม่ปกติ และเตรียม recovery process ให้พร้อม

# Chaos Experiments ที่ควรทำ
# ──────────────────────────
# 1. Kill random pod       → K8s จะสร้างใหม่มั้ย?
# 2. Increase latency      → App handle timeout ดีมั้ย?
# 3. Fill disk 100%        → Alert ทันมั้ย? App crash มั้ย?
# 4. Kill database primary → Failover ทำงานมั้ย?
# 5. DNS failure           → Retry logic ทำงานมั้ย?
# 6. Network partition     → Split-brain มั้ย?

# LitmusChaos — K8s Chaos Engineering
apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: pod-kill-test
spec:
  appinfo:
    appns: production
    applabel: app=myapp
  chaosServiceAccount: litmus-admin
  experiments:
    - name: pod-delete
      spec:
        components:
          env:
            - name: TOTAL_CHAOS_DURATION
              value: '30'          # 30 seconds of chaos
            - name: CHAOS_INTERVAL
              value: '10'          # kill pod every 10 sec
            - name: FORCE
              value: 'true'

รายการ chaos experiments ข้างต้นเริ่มจากสิ่งง่ายๆ (kill pod) ไปยังซับซ้อนขึ้น (network partition) LitmusChaos configuration แสดงการทดสอบ pod resilience โดยการ kill pod ทุก 10 วินาทีเป็นเวลา 30 วินาที การตั้ง FORCE=true จะทำ immediate kill ไม่ใช่ graceful shutdown เพื่อจำลอง real-world failure ที่มักจะเป็น unexpected

💡 กฎ Chaos: เริ่มจาก staging ก่อน → ค่อยทำ production | ทำในเวลาทำการ (มีคนดู) | มี rollback plan เสมอ

📋 SRE Checklist — เริ่มต้นยังไง?

การเริ่มต้น SRE ในองค์กรต้องทำทีละขั้น ไม่ใช่กระโดดไปทำทั้งหมดพร้อมกัน เพราะ SRE ต้องอาศัยทั้ง technical implementation และ culture change ที่ใช้เวลา checklist ด้านล่างเรียงตามลำดับความสำคัญ โดย foundation (ข้อ 1-3) ต้องแข็งแกร่งก่อนไปขั้นตอนถัดไป

1. กำหนด SLIs — วัด latency, error rate, availability
2. ตั้ง SLOs — เป้าหมายที่สมเหตุสมผล (ไม่ต้อง 100%!)
3. Track Error Budget — dashboard แสดง budget remaining
4. Setup Alerting — SLO-based alerts, ไม่ใช่ CPU/memory alerts
5. Incident Process — severity levels, response playbooks, war room
6. Blameless Postmortems — เขียนทุก P1/P2, track action items
7. Reduce Toil — measure → automate → measure อีก
8. On-Call Policy — rotation, compensation, escalation
9. Capacity Planning — forecast growth, plan ahead
10. Chaos Engineering — break it before it breaks itself

การเริ่มที่ SLI/SLO ไม่ใช่เพราะมันง่าย แต่เพราะมันเป็น "ภาษาร่วม" ที่ทำให้ทีมคุยกันรู้เรื่อง เมื่อมี SLO แล้ว error budget จะตามมาเป็นธรรมชาติ และ alerting จะมี direction ที่ชัดเจน การทำ postmortem ที่ blameless จะค่อยๆ เปลี่ยน culture และขั้นตอนสุดท้ายจะช่วย optimize ระบบให้แข็งแกร่งขึ้น

สรุป

• SRE = Software engineering approach to operations — "SRE implements DevOps"
• SLI/SLO/SLA = วัด reliability ด้วยตัวเลข (Indicator → Objective → Agreement)
• Four Golden Signals = Latency, Traffic, Errors, Saturation
• Error Budget = "งบสำหรับพลาด" — หมด = feature freeze!
• Incident Management = Detect → Triage → Mitigate → Resolve → Postmortem
• Blameless Postmortem = โทษระบบ ไม่โทษคน → สร้าง culture ที่เรียนรู้
• Toil < 50% = วัด manual work แล้ว automate ให้ได้
• Chaos Engineering = ทดสอบความแข็งแกร่งก่อนจะพังจริง 🚒🐕