SRE คืออะไร? Site Reliability Engineering แนวคิดจาก Google สำหรับ DevOps Engineer ไทย 2026

ในยุคที่ระบบ Software ต้อง Available ตลอด 24 ชั่วโมง การดูแลระบบแบบเดิมที่ทีม Ops คอยเฝ้าจอ Monitor ไม่เพียงพออีกต่อไป Google ได้สร้างแนวคิดที่เรียกว่า Site Reliability Engineering (SRE) ขึ้นมาตั้งแต่ปี 2003 เพื่อแก้ปัญหานี้อย่างเป็นระบบ และปัจจุบันบริษัท Tech ทั่วโลกนำแนวคิด SRE ไปใช้กันอย่างแพร่หลาย สำหรับ devops engineer ไทย ที่ต้องการยกระดับทักษะ การเข้าใจ SRE ถือเป็นจุดเปลี่ยนสำคัญในสายอาชีพ

บทความนี้จะพาคุณเข้าใจ SRE ตั้งแต่พื้นฐานไปจนถึงการนำไปใช้จริง ครอบคลุมหลักการ SLO/SLI/Error Budget, การจัดการ Toil, Incident Response, Postmortem Culture และ Career Path สำหรับคนไทยที่สนใจสาย SRE

SRE คืออะไร?

Site Reliability Engineering (SRE) คือแนวทางในการดูแลระบบ Production ที่ Google คิดค้นขึ้น โดยนำหลักการ Software Engineering มาใช้ในการแก้ปัญหาด้าน Operations ผู้ก่อตั้งแนวคิดนี้คือ Ben Treynor Sloss VP of Engineering ที่ Google ซึ่งให้คำนิยามว่า:

"SRE is what happens when you ask a software engineer to design an operations function."

พูดง่ายๆ คือ SRE ใช้วิธีคิดแบบ Software Engineer มาทำงาน Ops แทนที่จะทำงานซ้ำๆ ด้วยมือ ก็เขียนโค้ดให้มันทำอัตโนมัติ แทนที่จะรอให้ระบบพัง ก็กำหนดเป้าหมายความเชื่อถือได้อย่างเป็นตัวเลข แทนที่จะโทษคน ก็วิเคราะห์ระบบว่าต้องปรับปรุงตรงไหน

SRE vs DevOps vs Traditional Ops

หลายคนสับสนระหว่าง SRE กับ DevOps จริงๆ แล้วทั้งสองมีเป้าหมายคล้ายกันแต่วิธีการต่างกัน ลองเปรียบเทียบดูจากตาราง:

หลักการ SRE จาก Google

Google ได้สรุปหลักการ SRE ไว้ในหนังสือ "Site Reliability Engineering" ซึ่งเปิดให้อ่านฟรีที่ sre.google ประกอบด้วยหลักการสำคัญดังนี้:

1. Embracing Risk — ยอมรับความเสี่ยง

ระบบที่ Reliable 100% เป็นไปไม่ได้ และถ้าเป็นไปได้ก็แพงเกินไป SRE ยอมรับว่าระบบจะมีปัญหาบ้าง สิ่งสำคัญคือกำหนดว่า "ยอมรับได้แค่ไหน" แล้ววัดผลอย่างเป็นระบบ

2. SLO, SLI, Error Budget

นี่คือหัวใจของ SRE:

• SLI (Service Level Indicator): ตัวชี้วัดที่วัดคุณภาพบริการ เช่น Latency, Availability, Error Rate
• SLO (Service Level Objective): เป้าหมายของ SLI เช่น "99.9% ของ Request ต้องสำเร็จ"
• SLA (Service Level Agreement): สัญญาที่ทำกับลูกค้า ถ้าไม่ถึงต้องชดเชย (SLO ที่มีผลทางกฎหมาย)
• Error Budget: "งบประมาณ" ความผิดพลาดที่ยอมรับได้ = 100% - SLO

3. Toil Elimination — กำจัดงานซ้ำซาก

Google กำหนดว่า SRE ต้องใช้เวลาไม่เกิน 50% กับ Toil (งานที่ทำซ้ำ, ไม่สร้างคุณค่าถาวร, สามารถ Automate ได้) เวลาที่เหลือต้องใช้พัฒนาเครื่องมือหรือปรับปรุงระบบ

4. Automation

ทุกงานที่ทำซ้ำมากกว่า 2 ครั้ง ควร Automate ไม่ใช่แค่เพื่อประหยัดเวลา แต่เพื่อลดความผิดพลาดจากคน

5. Monitoring and Observability

ระบบ Monitoring ต้องตอบคำถามสำคัญ 3 ข้อ:

• What's broken? — Alerting บอกว่ามีปัญหา
• Why? — Debugging/Tracing หาสาเหตุ
• What happened? — Logging บันทึกเหตุการณ์

SLO/SLI อธิบายพร้อมตัวอย่าง

การคำนวณ Availability

Availability มักวัดเป็น "จำนวนเก้า" (nines):

ตัวอย่าง SLI ที่ใช้บ่อย

# SLI: Availability (Request-based)
availability_sli = successful_requests / total_requests * 100
# เช่น 999,000 / 1,000,000 * 100 = 99.9%

# SLI: Latency
latency_sli = requests_under_300ms / total_requests * 100
# เป้า: 95% ของ Request ต้องเร็วกว่า 300ms

# SLI: Error Rate
error_rate = error_responses / total_requests * 100
# เป้า: Error Rate ต้องน้อยกว่า 0.1%

# SLI: Freshness (สำหรับ Data Pipeline)
freshness_sli = pipelines_completed_on_time / total_pipelines * 100
# เป้า: 99% ของ Data Pipeline ต้องเสร็จภายในเวลาที่กำหนด

ตัวอย่าง SLO Document

# SLO Document: Payment Service
# Version: 2.1 | Last Updated: 2026-04-10
# Owner: SRE Team / Payment Squad

Service: Payment API
SLO Window: 30 days (rolling)

SLI 1: Availability
  - Definition: % ของ HTTP requests ที่ return 2xx หรือ 4xx
  - Target: 99.95%
  - Error Budget: 0.05% = ~21.6 นาที/เดือน

SLI 2: Latency (p99)
  - Definition: 99th percentile response time
  - Target: p99 < 500ms
  - Measurement: Prometheus histogram

SLI 3: Correctness
  - Definition: % ของ transactions ที่ยอดเงินถูกต้อง
  - Target: 99.999%

Escalation Policy:
  - Error Budget > 50%: ปกติ ทำฟีเจอร์ใหม่ได้
  - Error Budget 20-50%: เพิ่มความระวัง Review การเปลี่ยนแปลง
  - Error Budget < 20%: Freeze ฟีเจอร์ใหม่ โฟกัส Reliability
  - Error Budget = 0%: หยุด Deploy ทั้งหมด แก้ปัญหาก่อน

Error Budget และ Policy

Error Budget คือแนวคิดที่ทรงพลังที่สุดของ SRE เพราะมันแก้ปัญหาความขัดแย้งระหว่าง Dev (อยากปล่อยฟีเจอร์เร็ว) กับ Ops (อยากให้ระบบเสถียร) ด้วยการใช้ตัวเลขเป็นตัวตัดสิน

# Error Budget Calculation
slo_target = 99.9  # percent
error_budget = 100 - slo_target  # = 0.1%

# ใน 30 วัน = 43,200 นาที
allowed_downtime = 43200 * (error_budget / 100)  # = 43.2 นาที

# ถ้าเดือนนี้ Down ไปแล้ว 20 นาที
used_budget = 20
remaining_budget = allowed_downtime - used_budget  # = 23.2 นาที
budget_remaining_pct = remaining_budget / allowed_downtime * 100  # = 53.7%

Error Budget Policy

ทีม SRE ต้องมี Policy ที่ชัดเจนว่าจะทำอย่างไรเมื่อ Error Budget เหลือน้อย:

• Budget เหลือ > 50%: พัฒนาฟีเจอร์ใหม่ได้ตามปกติ Deploy ได้บ่อย
• Budget เหลือ 20-50%: เพิ่มความระวังในการ Deploy ต้อง Review การเปลี่ยนแปลงละเอียดขึ้น
• Budget เหลือ < 20%: หยุดพัฒนาฟีเจอร์ใหม่ชั่วคราว โฟกัสแก้ปัญหา Reliability
• Budget หมด: Freeze การ Deploy ทั้งหมด ยกเว้น Emergency Fix

Toil — การระบุและกำจัดงานซ้ำซาก

Toil ตามนิยามของ Google คืองานที่มีลักษณะ:

• Manual: ต้องทำด้วยมือ
• Repetitive: ทำซ้ำๆ เหมือนเดิม
• Automatable: สามารถเขียนโปรแกรมทำแทนได้
• Tactical: ตอบสนองเหตุการณ์ ไม่ใช่การวางแผนระยะยาว
• No Enduring Value: ไม่สร้างคุณค่าถาวร
• O(n) with Service Growth: เพิ่มขึ้นตามขนาดระบบ

ตัวอย่าง Toil ที่พบบ่อย

การวัด Toil

# Toil Tracking (ตัวอย่าง Python script)
import csv
from datetime import datetime, timedelta

toil_log = [
    {"task": "restart-api-server", "duration_min": 15, "frequency": "weekly",
     "automatable": True, "category": "manual-intervention"},
    {"task": "create-user-account", "duration_min": 10, "frequency": "daily",
     "automatable": True, "category": "provisioning"},
    {"task": "check-disk-space", "duration_min": 5, "frequency": "daily",
     "automatable": True, "category": "monitoring"},
    {"task": "rotate-api-keys", "duration_min": 30, "frequency": "monthly",
     "automatable": True, "category": "security"},
]

# คำนวณ Toil ต่อเดือน
total_toil_hours = 0
for task in toil_log:
    freq_multiplier = {"daily": 30, "weekly": 4, "monthly": 1}
    monthly_minutes = task["duration_min"] * freq_multiplier[task["frequency"]]
    total_toil_hours += monthly_minutes / 60
    print(f"  {task['task']}: {monthly_minutes} min/month")

print(f"Total Toil: {total_toil_hours:.1f} hours/month")
# เป้าหมาย: Toil < 50% ของเวลาทำงาน (< 80 ชม./เดือน)

SRE Practices

Monitoring Strategy

SRE ใช้แนวคิด The Four Golden Signals ในการ Monitor:

1. Latency: เวลาที่ใช้ตอบ Request (แยก Success vs Error)
2. Traffic: ปริมาณ Request ที่เข้ามา (RPS, QPS)
3. Errors: อัตราส่วน Request ที่ล้มเหลว
4. Saturation: ทรัพยากรถูกใช้ไปมากแค่ไหน (CPU, Memory, Disk)

# Prometheus: Four Golden Signals
# 1. Latency
histogram_quantile(0.99,
  rate(http_request_duration_seconds_bucket[5m])
)

# 2. Traffic
sum(rate(http_requests_total[5m])) by (service)

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

# 4. Saturation
container_memory_usage_bytes / container_spec_memory_limit_bytes

Alerting Best Practices

Alert ที่ดีต้องมีลักษณะ:

• Actionable: ต้องมีสิ่งที่ต้องทำเมื่อได้รับ Alert
• Symptom-based: Alert จาก Symptom (ผู้ใช้ได้รับ Error) ไม่ใช่ Cause (CPU สูง)
• Low Noise: ลด False Positive ให้น้อยที่สุด

# Prometheus Alert Rule ที่ดี (SLO-based)
groups:
  - name: slo-alerts
    rules:
      # Error Budget Burn Rate Alert
      - alert: HighErrorBudgetBurn
        expr: |
          (
            1 - (
              sum(rate(http_requests_total{status!~"5..",job="api"}[1h]))
              /
              sum(rate(http_requests_total{job="api"}[1h]))
            )
          ) > (14.4 * 0.001)  # 14.4x burn rate for 1h window
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Error budget burning too fast"
          description: "At current rate, error budget will be exhausted in less than 2 hours"
          runbook: "https://wiki.company.com/runbooks/high-error-rate"

Incident Response

SRE มีกระบวนการ Incident Response ที่เป็นระบบ:

# Incident Response Procedure
1. DETECT    — Alert แจ้งเตือน หรือ User Report
2. RESPOND   — On-call Engineer Acknowledge ภายใน 5 นาที
3. TRIAGE    — ประเมิน Impact + Severity (SEV1-4)
4. MITIGATE  — แก้ไขเบื้องต้น (Rollback, Scale Up, Failover)
5. RESOLVE   — แก้ไขต้นเหตุ
6. POSTMORTEM — วิเคราะห์หลังเหตุการณ์

# Severity Levels
SEV1: Critical — ระบบล่มทั้งหมด, ผู้ใช้ทุกคนได้รับผลกระทบ
SEV2: Major    — ฟีเจอร์หลักใช้งานไม่ได้, ผู้ใช้จำนวนมากได้รับผลกระทบ
SEV3: Minor    — ฟีเจอร์รองมีปัญหา, ผู้ใช้บางส่วนได้รับผลกระทบ
SEV4: Low      — ปัญหาเล็กน้อย, มี Workaround

Capacity Planning

SRE ต้องวางแผน Capacity ล่วงหน้า ไม่ใช่รอให้ระบบล่มแล้วค่อยเพิ่ม:

# Capacity Planning Checklist
1. Organic Growth: Traffic เพิ่มขึ้นตามธรรมชาติ (~X% ต่อเดือน)
2. Planned Events: โปรโมชัน, Campaign, Product Launch
3. Headroom: เผื่อ Buffer ไว้ 30-50% เหนือ Peak Load
4. Regional Failover: ถ้า Region หนึ่งล่ม Region อื่นรับ Load ได้หมดไหม

# ตัวอย่าง: คำนวณ Capacity ที่ต้องการ
current_peak_rps = 10000
growth_rate_monthly = 0.15  # 15% ต่อเดือน
months_ahead = 6
headroom = 0.3  # 30% buffer

projected_peak = current_peak_rps * (1 + growth_rate_monthly) ** months_ahead
required_capacity = projected_peak * (1 + headroom)
# projected_peak = ~23,130 RPS
# required_capacity = ~30,070 RPS

Change Management

การเปลี่ยนแปลงระบบ Production เป็นสาเหตุหลักของ Incident ถึง 70-80% SRE จึงมีกระบวนการจัดการการเปลี่ยนแปลงอย่างรอบคอบ:

• Progressive Rollout (Canary → Staging → Production)
• Automated Rollback เมื่อ Metric ผิดปกติ
• Change Review สำหรับการเปลี่ยนแปลงที่มีผลกระทบสูง
• Change Freeze ช่วง Peak Season หรือ Error Budget ต่ำ

On-Call Rotation และ Runbooks

On-Call Best Practices

การ On-Call เป็นส่วนสำคัญของ SRE แต่ต้องจัดการให้ดีเพื่อไม่ให้ทีมหมดแรง (Burnout):

• Rotation: หมุนเวียนทุก 1-2 สัปดาห์ อย่าให้คนเดียวรับภาระนานเกินไป
• Primary + Secondary: มีคนสำรองเสมอ ถ้า Primary ไม่สามารถรับได้
• Compensation: จ่ายค่าตอบแทน On-Call ที่เป็นธรรม
• Alert Quality: ลด False Alert ให้เหลือน้อยที่สุด คนที่ถูกปลุกตอนตี 3 ต้องมีสิ่งที่ต้องทำจริง
• Max Pages: ถ้า On-Call ได้รับ Alert เกิน 2 ครั้ง/shift ต้องทบทวน Alert Rules

Runbook Template

# Runbook: API Server High Error Rate
# Last Updated: 2026-04-10 | Owner: SRE Team

## Overview
Alert: HighErrorBudgetBurn fires เมื่อ Error Rate สูงกว่า SLO

## Impact
ผู้ใช้จะพบ HTTP 500 เมื่อเรียก API
Affected Services: Payment, User Auth, Order Processing

## Investigation Steps
1. ตรวจ Grafana Dashboard: https://grafana.internal/d/api-overview
2. ดู Error Logs:
   kubectl logs -l app=api-server --tail=100 -f | grep ERROR
3. ตรวจ Dependency Health:
   - Database: https://grafana.internal/d/postgres
   - Redis: https://grafana.internal/d/redis
   - External APIs: https://statuspage.internal

## Mitigation
Option A: Rollback ถ้า Deploy ล่าสุดเป็นสาเหตุ
  kubectl rollout undo deployment/api-server

Option B: Scale Up ถ้า Traffic สูงผิดปกติ
  kubectl scale deployment/api-server --replicas=10

Option C: Circuit Breaker ถ้า Dependency ล่ม
  kubectl set env deployment/api-server CIRCUIT_BREAKER_ENABLED=true

## Escalation
ถ้าแก้ไม่ได้ใน 30 นาที → เรียก Secondary On-Call
ถ้าเป็น SEV1 → เรียก Incident Commander

Postmortem Culture — วัฒนธรรม Blameless

Blameless Postmortem คือหัวใจของการเรียนรู้จาก Incident ใน SRE หลักการสำคัญคือ:

• ไม่โทษคน: โฟกัสที่ระบบและกระบวนการ ไม่ใช่ว่าใครทำผิด
• เขียนทุก Incident: ทุก SEV1/SEV2 ต้องมี Postmortem
• แชร์ให้ทั่วองค์กร: ทีมอื่นจะได้เรียนรู้ด้วย
• Action Items: ทุก Postmortem ต้องมี Action Items ที่ชัดเจนและมีคน Own

Postmortem Template

# Postmortem: Payment API Outage
# Date: 2026-04-08 | Duration: 47 minutes | Severity: SEV1

## Summary
Payment API ไม่สามารถให้บริการได้เป็นเวลา 47 นาที
เนื่องจาก Database Connection Pool หมด
ผลกระทบ: ผู้ใช้ ~15,000 คน ไม่สามารถชำระเงินได้

## Timeline (UTC+7)
14:23 — Alert: HighErrorRate fires (Error Rate > 5%)
14:25 — On-call Engineer acknowledged
14:28 — เริ่ม Investigation, พบว่า DB connections เต็ม
14:35 — พยายาม Scale DB connections → ไม่สำเร็จ
14:42 — ระบุสาเหตุ: Query ใหม่จาก Feature X ทำให้ Connection ค้าง
14:48 — Rollback Feature X deployment
14:55 — DB connections กลับสู่ปกติ
15:10 — ยืนยันว่าระบบกลับมาทำงานปกติ

## Root Cause
Feature X มี Database Query ที่ไม่มี Timeout ทำให้ Connection ค้าง
เมื่อ Traffic สูง Connection Pool เต็ม ส่ง Request อื่นๆ ไม่ได้

## Action Items
1. [P0] เพิ่ม Query Timeout สำหรับทุก DB Query — Owner: Dev Team — Due: 2026-04-12
2. [P1] เพิ่ม Connection Pool Monitoring Alert — Owner: SRE — Due: 2026-04-15
3. [P2] เขียน Load Test สำหรับ Feature ใหม่ก่อน Deploy — Owner: QA — Due: 2026-04-20
4. [P2] เพิ่ม Circuit Breaker สำหรับ DB Connection — Owner: Dev Team — Due: 2026-04-25

## Lessons Learned
- Database Query ที่ไม่มี Timeout เป็นระเบิดเวลา
- ต้องมี Load Test เป็นส่วนหนึ่งของ CI/CD Pipeline
- Connection Pool Monitoring เป็น Golden Signal ที่ขาดไม่ได้

โครงสร้างทีม SRE

Embedded SRE vs Centralized SRE

SRE Team Responsibilities

• กำหนดและติดตาม SLO/SLI
• จัดการ On-Call Rotation
• เขียน Runbooks และ Automation Tools
• ทำ Incident Response และ Postmortem
• Capacity Planning และ Performance Tuning
• สร้าง Internal Platform และ Developer Tools
• ให้คำปรึกษาทีม Dev เรื่อง Reliability

SRE Tools ที่นิยม

ตัวอย่าง: ตั้งค่า PagerDuty Integration

# Prometheus Alertmanager → PagerDuty
# alertmanager.yml
global:
  resolve_timeout: 5m

route:
  group_by: ['alertname', 'service']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: 'pagerduty-critical'
  routes:
    - match:
        severity: critical
      receiver: 'pagerduty-critical'
    - match:
        severity: warning
      receiver: 'slack-warnings'

receivers:
  - name: 'pagerduty-critical'
    pagerduty_configs:
      - routing_key: 'YOUR_PAGERDUTY_INTEGRATION_KEY'
        severity: critical
        description: '{{ .CommonAnnotations.summary }}'
        details:
          firing: '{{ .Alerts.Firing | len }}'
          dashboard: '{{ .CommonAnnotations.dashboard }}'
          runbook: '{{ .CommonAnnotations.runbook }}'
  - name: 'slack-warnings'
    slack_configs:
      - api_url: 'https://hooks.slack.com/services/XXX/YYY/ZZZ'
        channel: '#sre-alerts'
        title: '{{ .CommonAnnotations.summary }}'

SRE Career Path ในประเทศไทย

ตลาด SRE ในประเทศไทยกำลังเติบโตอย่างรวดเร็ว บริษัท Tech ขนาดใหญ่หลายแห่งเช่น Agoda, LINE MAN Wongnai, SCB TechX, True Digital และ Shopee เปิดรับ SRE อย่างต่อเนื่อง สำหรับคนที่กำลังเรียนรู้ สอน python และ docker เบื้องต้น อยู่ สามารถต่อยอดไปสาย SRE ได้

SRE Career Ladder

ทักษะที่ต้องมีสำหรับ SRE ในไทย

• Programming: Python, Go หรือ Bash สำหรับ Automation (เริ่มจาก สอน python ได้เลย)
• Linux: System Administration, Networking, Troubleshooting
• Containers: Docker, Kubernetes (ดู docker เบื้องต้น)
• Cloud: AWS, GCP หรือ Azure
• Monitoring: Prometheus, Grafana, ELK
• CI/CD: GitHub Actions, GitLab CI, Jenkins
• IaC: Terraform, Ansible
• Soft Skills: Communication, Incident Management, Documentation

SRE Books ที่ต้องอ่าน

1. Site Reliability Engineering (Google) — หนังสือต้นตำรับ อ่านฟรีที่ sre.google อธิบายหลักการ SRE ทั้งหมด
2. The Site Reliability Workbook (Google) — ภาคปฏิบัติ มีตัวอย่างและ Exercise ให้ทำ
3. Seeking SRE (David N. Blank-Edelman) — มุมมอง SRE จากหลากหลายบริษัทนอก Google
4. Implementing Service Level Objectives (Alex Hidalgo) — Deep dive เรื่อง SLO/SLI/Error Budget
5. Incident Management for Operations (Rob Schnepp) — จัดการ Incident อย่างมืออาชีพ

SRE สำหรับบริษัทที่ไม่ใช่ Google

หลายคนคิดว่า SRE เหมาะกับบริษัทใหญ่แบบ Google เท่านั้น แต่จริงๆ หลักการ SRE สามารถนำไปปรับใช้กับบริษัททุกขนาด:

SRE สำหรับ Startup / SME

• เริ่มจากกำหนด SLO สำหรับ Service สำคัญที่สุด 1-2 ตัวก่อน
• ไม่จำเป็นต้องมีทีม SRE แยก ให้ Dev ทุกคนเข้าใจหลักการ SRE
• เริ่ม Toil Tracking ง่ายๆ ด้วย Spreadsheet
• เขียน Postmortem ทุกครั้งที่เกิด Incident ที่มีผลกระทบ
• ใช้ Free Tools เช่น Prometheus + Grafana + Alertmanager

SRE สำหรับทีมเล็ก (2-5 คน)

# แผนเริ่มต้น SRE สำหรับทีมเล็ก

Week 1-2: กำหนด SLO
  - ระบุ SLI สำคัญ (Availability, Latency)
  - ตั้ง SLO เริ่มต้น (เช่น 99.5%)
  - ตั้ง Monitoring ด้วย Prometheus + Grafana

Week 3-4: Incident Response
  - สร้าง On-call Rotation (ทุกคนรับผิดชอบ)
  - เขียน Runbook สำหรับ Alert ที่พบบ่อย
  - ตั้ง PagerDuty/OpsGenie (มี Free Tier)

Week 5-6: Toil Reduction
  - ระบุ Toil ที่ทำบ่อยที่สุด 3 อย่าง
  - Automate อย่างน้อย 1 อย่าง
  - เริ่ม Track Toil Hours

Week 7-8: Postmortem Process
  - เขียน Postmortem Template
  - ทำ Postmortem สำหรับ Incident ล่าสุด
  - แชร์ให้ทีมและสร้าง Action Items

เป้าหมาย 3 เดือน:
  - มี SLO Dashboard ที่ทุกคนดูได้
  - On-call ไม่ถูก Page เกิน 2 ครั้ง/สัปดาห์
  - Toil ลดลง 30% จากเดือนแรก

Chaos Engineering — ทดสอบความทนทาน

SRE ไม่ใช่แค่รอให้ระบบพังแล้วแก้ แต่ต้อง ทำให้ระบบพังอย่างตั้งใจ เพื่อค้นหาจุดอ่อนก่อนที่ผู้ใช้จะเจอ นี่คือแนวคิด Chaos Engineering ที่ Netflix เป็นผู้บุกเบิก

# Chaos Engineering Experiments
# ใช้ Litmus Chaos บน Kubernetes

# Experiment 1: Pod Kill — ลบ Pod แล้วดูว่าระบบ Recover เร็วแค่ไหน
apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: pod-kill-experiment
spec:
  appinfo:
    appns: production
    applabel: "app=api-server"
  chaosServiceAccount: litmus-admin
  experiments:
    - name: pod-delete
      spec:
        components:
          env:
            - name: TOTAL_CHAOS_DURATION
              value: '30'
            - name: CHAOS_INTERVAL
              value: '10'
            - name: FORCE
              value: 'false'

# Experiment 2: Network Latency — เพิ่ม Latency ระหว่าง Service
# ดูว่า Timeout และ Retry ทำงานถูกต้องหรือไม่

# Experiment 3: CPU Stress — ใช้ CPU เต็ม
# ดูว่า Autoscaler ทำงานได้เร็วพอหรือไม่

สรุป

SRE ไม่ใช่แค่ตำแหน่งงาน แต่เป็นแนวคิดและวัฒนธรรมที่เปลี่ยนวิธีการดูแลระบบ Production จาก "ทำด้วยมือ แก้ปัญหาเป็นรายกรณี" มาเป็น "ใช้ Engineering Approach แก้ปัญหาอย่างเป็นระบบ" หลักการสำคัญที่ต้องจำคือ SLO/SLI/Error Budget เป็นเครื่องมือสร้างสมดุลระหว่างความเร็วและความเสถียร Toil ต้องจำกัดไม่เกิน 50% เพื่อให้มีเวลาปรับปรุงระบบ และ Blameless Postmortem สร้างวัฒนธรรมการเรียนรู้จากความผิดพลาด

สำหรับ devops engineer ไทย ที่ต้องการก้าวเข้าสู่สาย SRE แนะนำให้เริ่มจากการอ่านหนังสือ SRE ของ Google จากนั้นลองนำหลักการ SLO/SLI ไปใช้กับ Service ที่ดูแลอยู่ เริ่มเขียน Postmortem ทุกครั้งที่เกิด Incident และค่อยๆ ลด Toil ด้วย Automation ไม่จำเป็นต้องทำทุกอย่างพร้อมกัน เริ่มทีละขั้นก็เพียงพอ

ในปี 2026 SRE เป็นหนึ่งในสายอาชีพที่มีความต้องการสูงและเงินเดือนดีที่สุดในวงการ Tech ไทย การเข้าใจหลักการ SRE ไม่เพียงช่วยให้คุณดูแลระบบได้ดีขึ้น แต่ยังเปิดโอกาสในสายอาชีพที่กว้างขึ้นอีกด้วย