Beginner Book

โหมดมืด

บทที่ 0 — DevOps คืออะไร ​

สารบัญ | บทถัดไป →

TL;DR: บทนี้ตอบ "DevOps คืออะไร และต่างกับ SRE/Platform Engineering ยังไง" — เน้น mindset (วิธีคิด) ผ่านกรอบ CALMS (Culture, Automation, Lean, Measurement, Sharing — อธิบายเต็มในหัวข้อ 3) + วิธีวัดทีมผ่าน DORA 4 metrics:

  • deployment frequency = ความถี่ในการ deploy ขึ้น production
  • lead time = เวลาตั้งแต่ commit code → ขึ้น production
  • change failure rate = % deploy ที่ทำให้ระบบพัง
  • MTTR (Mean Time to Recovery) = เวลาเฉลี่ยที่ใช้กู้ระบบกลับมาหลังพัง

ข้ามได้ถ้า: คุณรู้ DORA + CALMS + ความต่าง SRE vs DevOps อยู่แล้ว

📝 DORA "4 vs 5 metrics": ตั้งแต่รายงาน DORA ปี 2021 มี metric ที่ 5 = Reliability / Operational Performance (ความเสถียร/ความน่าเชื่อถือของระบบ) เพิ่มเข้ามา แต่ industry (วงการ) ส่วนใหญ่ยังพูดถึง 4 ตัวเดิม บทนี้ใช้ 4 ตัวเดิมเป็นหลัก — ดูฉบับล่าสุดที่ dora.dev (last reviewed: 2026-06 — ตรวจ release notes (บันทึกการอัปเดตของรายงานปีล่าสุด) ทางการก่อนใช้)

0. ก่อนเริ่ม — Prerequisites ​

หนังสือเล่มนี้เริ่มที่ "เคยเขียนโปรแกรมแล้ว, เคย deploy app ขึ้นที่ไหนสักที่ (อาจจะแค่ Heroku, Vercel)"

  • ✅ เคยใช้ command line (หน้าจอพิมพ์คำสั่ง — Terminal/PowerShell) อย่างน้อย ls (ดูไฟล์), cd (เปลี่ยน folder), git (commit/push พื้นฐาน)
  • ✅ มี GitHub account
  • ✅ เคย deploy หรือเห็นการ deploy ของจริง
  • ❌ ไม่จำเป็นต้องรู้ Linux ลึก / Docker / Cloud มาก่อน — สอนใน 7 บทถัดไป

ถ้ายังไม่เคย deploy เลย: เริ่มที่บทที่ 0 นี้เพื่อรู้ภาพรวม แล้วข้ามไปบท 3 (Docker) + บท 5 (CI/CD) จะเห็นการ deploy ของจริงครั้งแรกในนั้น

บทนี้ — มือใหม่จะได้อะไร ​

จบบท คุณจะตอบได้ว่า:

  1. DevOps คืออะไร ที่ไม่ใช่ list ของ tool
  2. ทำไมบริษัทต้องการ DevOps (problem-driven = เริ่มจากปัญหาที่ต้องแก้ ไม่ใช่เริ่มจาก tool ที่อยากเล่น)
  3. วัดทีม DevOps ที่ดีได้ยังไง (DORA)
  4. SRE / Platform Engineering ต่างกับ DevOps ยังไง

📖 กางศัพท์ที่จะเจอบ่อยในบทนี้ (ยังไม่ต้องท่อง — กลับมาเปิดดูได้):

  • DORA = ทีมวิจัยของ Google ที่ออกรายงาน State of DevOps ทุกปี — กำหนด 4 metrics วัดทีม DevOps
  • MTTR (Mean Time to Recovery) = "เวลาเฉลี่ยที่ใช้กู้ระบบกลับมาหลังพัง"
  • SRE (Site Reliability Engineering) = "วิศวกรรมความน่าเชื่อถือของระบบ" — แบบฉบับ DevOps ของ Google
  • SLI / SLO / SLA = indicator (วัด) / objective (เป้าหมาย) / agreement (สัญญากับลูกค้า)
  • Toil = "งานมือซ้ำ ๆ น่าเบื่อ ที่ควร automate ทิ้ง"
  • Postmortem = เอกสารสรุปหลังเกิด incident — โทษระบบ ไม่โทษคน (blameless)
  • Runbook = "คู่มือเมื่อระบบพัง" — production พัง X → ทำตามนี้
  • Wall of Confusion = "กำแพงความสับสน" ระหว่าง dev กับ ops ก่อนยุค DevOps — dev โยน code ให้ ops, ops โยน bug กลับ
  • IaC (Infrastructure as Code) = "ระบบเขียนเป็นโค้ด" จัดการ infra ผ่านไฟล์ที่ git track ได้
  • GitOps = "deploy ผ่าน git commit" — git repo คือ source of truth ของ production

1. DevOps ไม่ใช่ Tool ​

หลายคนคิดว่า DevOps = Docker + Kubernetes + Jenkins
ผิด — DevOps = culture (วัฒนธรรมการทำงานของทีม) + practice (วิธีปฏิบัติ) + tools

ลองคิดเทียบ: "Agile" (กรอบการพัฒนา software แบบวนซ้ำ ส่งงานเป็นรอบสั้น ๆ) ก็ไม่ใช่ Jira หรือ standup — มันคือวิธีคิดเรื่องการพัฒนา software Tool เป็นแค่ "วิธีบังคับใช้" culture เท่านั้น เปลี่ยน tool ได้เสมอ แต่ culture เปลี่ยนยาก

💬 คำคมจาก Jez Humble (ผู้เขียน Continuous Delivery):

ภาษาไทย: "DevOps ไม่ใช่เป้าหมายปลายทาง แต่เป็นกระบวนการปรับปรุงให้ดีขึ้นเรื่อย ๆ ที่ไม่มีวันจบ"

ต้นฉบับ: "DevOps is not a goal but a never-ending process of continual improvement."

2. ปัญหาก่อน DevOps ​

text
Developer (คนเขียนโค้ด):              Operations (คนดูแลเซิร์ฟเวอร์):
"Code works on my machine"             "Production is on fire"
(โค้ดทำงานได้บนเครื่องผมนะ)             (production กำลังพังอยู่!)

"Deploy whenever!"                     "Don't change anything!"
(จะ deploy เมื่อไหร่ก็ได้)               (อย่าเปลี่ยนอะไรเด็ดขาด!)

                ↓
Conflict — Dev อยาก push ของใหม่ตลอด แต่ Ops กลัวพังเลยต้านไว้

dev เขียนโค้ดเสร็จก็ "โยน" งานให้ ops ไปจัดการ deploy ต่อเองเลย โดยไม่ได้คุยกันก่อน → ของพัง → ปวดหัวทั้งคู่ ฝรั่งเรียกภาพแบบนี้ว่า Wall of Confusion (กำแพงความสับสน) — เหมือนมีกำแพงกั้นระหว่าง dev กับ ops ต่างคนต่างโยนงานข้ามกำแพงไปให้อีกฝั่ง ไม่มีใครรับผิดชอบร่วมกัน

DevOps แก้ ​

  • Dev + Ops = ทีมเดียว (DevOps)
  • Automation ที่ทำซ้ำ
  • Shared responsibility
  • Feedback loop เร็ว

3. CALMS Framework ​

CALMS = 5 pillars (เสาหลัก) ของ DevOps — คำว่า CALMS เผยแพร่โดยกลุ่ม DevOps ยุคแรก (Damon Edwards, John Willis ราวปี 2010) และถูกนำมาใช้ในงานเขียนของ Jez Humble (ผู้เขียน Continuous Delivery) เพื่อสรุปว่าทีม DevOps ที่ดีต้องมีอะไรครบ 5 อย่าง:

Pillar (เสาหลัก)คืออะไรตัวอย่างที่ทีมขาด
Culture (วัฒนธรรม)Dev + Ops ทำงานร่วมกัน, blameless (โทษที่ระบบ ไม่โทษตัวคน), shared ownership (รับผิดชอบร่วม)"เป็นปัญหาของฝั่ง Ops ไม่ใช่ของเรา"
Automation (อัตโนมัติ)CI/CD (ดูบท 5), IaC (Infrastructure as Code — เขียน infra เป็นโค้ด, ดูบท 6), monitoring, test"ทำ manual (ทำมือ) ไปก่อน เดี๋ยวค่อย script"
Lean (เพรียว/ไม่อ้วน)งานชิ้นเล็ก, feedback เร็ว, ไม่สะสม WIP (Work In Progress = งานที่ทำค้างไว้ยังไม่เสร็จ)PR (Pull Request — ขอรวมโค้ด, สอนละเอียดในบท 2) 5,000 บรรทัด รอ review 2 สัปดาห์
Measurement (วัดผล)Metrics, SLI/SLO (ดูหัวข้อ 7), DORA (ดูหัวข้อ 4) — วัดได้, ไม่เดา"รู้สึกว่าน่าจะเร็วขึ้น"
Sharing (แบ่งปัน)Knowledge, runbook (คู่มือเมื่อระบบพัง), postmortem (บันทึกหลัง incident, ดูหัวข้อ 14) แชร์ทั้ง orgbus factor = 1 (ถ้าคนเดียวที่รู้เรื่องนี้หายไป ทีมเจ๊งทันที = ความเสี่ยงที่ความรู้กระจุกคนเดียว)

📖 ศัพท์ตัวหนา (CI/CD, IaC, runbook, postmortem, SLI/SLO) จะอธิบายเต็มในหัวข้อ/บทที่อ้างถึง — ตอนนี้พอรู้ว่ามันคืออะไรคร่าว ๆ ก็พอ ดูสรุปสั้นได้ที่ glossary หัวข้อ 10 ของบทนี้

→ Culture สำคัญที่สุด — เครื่องมือเปลี่ยนได้ แต่ถ้าทีมไม่ trust กัน, automation ก็ช่วยไม่ได้ → ลำดับการสร้าง: Culture → Sharing → Lean → Automation → Measurement (วัดเพื่อปรับปรุง)

4. DORA Metrics — วัด DevOps Performance ​

DORA = DevOps Research and Assessment (กลุ่มวิจัยที่ Google ซื้อกิจการมาในปี 2018; ตีพิมพ์รายงานทุกปีในชื่อ State of DevOps Report) — เป็น มาตรฐานของวงการ ในการวัดว่าทีม DevOps "ดี" จริงไหม ไม่ใช่แค่ "รู้สึก"

ทำไมแค่ 4 metrics? ​

DORA วิจัยพบว่า 4 ตัวนี้สัมพันธ์โดยตรงกับผลลัพธ์ทางธุรกิจทั้งหมด (รายได้, ความพอใจของลูกค้า, ส่วนแบ่งตลาด) ทีมที่ทำดี 4 ตัวนี้ = ทีมที่ส่งของได้เร็ว + ของไม่พัง แบ่งเป็น 2 คู่:

  • Speed (ความเร็ว) = Deployment Frequency + Lead Time → "ส่งของเร็วไหม"
  • Stability (ความเสถียร) = Change Failure Rate + MTTR (Mean Time to Recovery = เวลาเฉลี่ยที่ใช้กู้ระบบกลับมาหลังพัง) → "ของพังบ่อยไหม + กู้คืนเร็วไหม"

💡 Insight (ข้อสังเกตสำคัญ): speed กับ stability ไม่ใช่ trade-off (ไม่ใช่ต้องแลกอันหนึ่งกับอีกอัน) — ทีม Elite (ระดับสูงสุด) ทำได้ดีทั้งคู่ ทีมที่อ้างว่า "เราช้าเพราะเราเน้น quality" มักเป็นทีมที่ deploy ไม่บ่อยจนลืมวิธีทำให้ stable

📝 หมายเหตุเรื่อง tier (ระดับ): ตั้งแต่รายงาน DORA 2022 เป็นต้นมา จำนวน tier ขยับมาเป็น 3 ระดับในบางปี (Elite/High/Medium ไม่มี Low — รายงาน 2023/2024 ก็มีการเปลี่ยน label และช่วงตัวเลข) ตารางด้านล่างใช้แบบ 4 tier เดิมเพื่อให้เห็นภาพต่อเนื่อง เกณฑ์ตัวเลข exact ต้องเช็คฉบับล่าสุดที่ dora.dev ก่อนนำไปใช้จริง

1. Deployment Frequency (ความถี่ในการ deploy) ​

"ส่ง code ขึ้น production บ่อยแค่ไหน?"

Tier (ระดับ)Frequency (ความถี่)
Elite (สูงสุด)หลายครั้งต่อวัน (Multiple deploys per day)
High (สูง)สัปดาห์ละครั้ง → วันละครั้ง (Once per week → once per day)
Medium (กลาง)เดือนละครั้ง → สัปดาห์ละครั้ง (Once per month → once per week)
Low (ต่ำ)น้อยกว่าเดือนละครั้ง (Less than once per month)

2. Lead Time for Changes (เวลาตั้งแต่ commit → production) ​

"จาก commit แรก → ขึ้น production = ใช้เวลาเท่าไหร่?" (ไม่ใช่เวลา build แค่ขั้นเดียว)

Tier (ระดับ)Lead Time (เวลา)
Elite< 1 ชั่วโมง
High1 วัน → 1 สัปดาห์
Medium1 สัปดาห์ → 1 เดือน
Low> 1 เดือน

📝 ช่วงตัวเลข Elite ในรายงานต้นฉบับของ DORA หลายปีคือ "< 1 วัน" ตัวเลข "< 1 ชั่วโมง" ที่ใช้ในตารางนี้เป็นเกณฑ์เข้มขึ้นที่ทีม Elite ระดับ Google/Netflix ทำได้จริง — ใช้เป็นเป้าหมายในใจได้ แต่ถ้าจะอ้างอิงงานทางการให้ใช้เลขจาก dora.dev ฉบับปีล่าสุด

3. Change Failure Rate (% deploy ที่ทำให้ระบบพัง) ​

"% ของ deploy ที่ทำให้ production พัง / ต้อง rollback (ย้อน version กลับ) / hotfix (แก้ด่วน)"

Tier (ระดับ)Failure Rate (%)
Elite0–15%
High0–15% (ใกล้เคียง Elite ในรายงานปีหลัง)
Medium16–30%
Low> 30% (รายงานบางปี: 46–60%)

📝 เกณฑ์นี้แก้ตามรายงาน DORA 2022 เป็นต้นมา: Elite และ High ถูก "ยุบ" เป็น 0–15% เหมือนกัน (ก่อนหน้านี้ในเล่มเก่าระบุ Elite 0–5%, High 5–15% — เป็นเกณฑ์ของรายงานปี 2019 ที่ถูกปรับใหม่) ตัวเลข exact ของปีล่าสุดให้เช็คที่ dora.dev

4. Mean Time to Recovery (MTTR — เวลากู้ระบบ) ​

"production พัง → กลับมาทำงานได้ใน?" (ตั้งแต่ alert → service กลับมา)

Tier (ระดับ)MTTR
Elite< 1 ชั่วโมง
High< 1 วัน
Medium1 วัน → 1 สัปดาห์
Low> 1 สัปดาห์

→ บริษัทระดับท็อป (Google, Netflix, Amazon) = Elite ทุก metric พร้อมกัน (เป็นความเห็นทั่วไปของวงการ ไม่ใช่ผลสำรวจ DORA โดยตรง — DORA ไม่เปิดเผยข้อมูลรายบริษัท)

วิธีใช้ในชีวิตจริง ​

  1. อย่าวัดเพื่อแข่ง — วัดเพื่อเห็น trend (แนวโน้ม) (ดีขึ้น/แย่ลง) เทียบกับตัวเองเดือนก่อน
  2. ทีม Low → Medium ก่อน — กระโดด Elite ในปีเดียวเป็นไปไม่ได้ ค่อย ๆ ขยับ
  3. เริ่มที่ Lead Time — ถ้า lead time ลดลง อีก 3 ตัวมักดีขึ้นตาม
  4. เครื่องมือวัด:
    • GitHub Insights (DORA metrics) (ต้องใช้ GitHub Enterprise Cloud — ไม่ใช่ฟรีสำหรับ repo ทั่วไป ตรวจสอบแผนราคาล่าสุดก่อนใช้จริง)
    • Sleuth (เสียเงิน, มี free trial)
    • LinearB (เสียเงิน, มี free tier จำกัด)
    • Faros (open-source + cloud เสียเงิน)

5. DevOps Maturity Model ​

ทีมไม่ได้เป็น DevOps เต็มตัวในวันเดียว — มันมี "ระดับวุฒิภาวะ" (maturity) ไล่จากทำมือทุกอย่าง ไปจนถึง automate เต็มระบบ โมเดล 5 ระดับนี้ช่วยให้คุณประเมินได้ว่าทีมตัวเองอยู่ตรงไหน และขั้นถัดไปควรลงทุนเรื่องอะไร

⚠️ ไม่ใช่ benchmark (เกณฑ์เปรียบเทียบ) ทางการ: มี maturity model หลายแบบ (Atlassian, Forrester, CNCF ฯลฯ) — ตัวที่แสดงด้านล่างเป็น mental aid (เครื่องช่วยจำให้นึกภาพออก) ที่หนังสือเล่มนี้สังเคราะห์เพื่อช่วยให้เห็นภาพ ไม่ใช่มาตรฐานสากล อย่าใช้เป็น scorecard (ใบให้คะแนน) ทางการ

📖 ศัพท์ในตารางนี้ส่วนใหญ่ยังไม่ได้นิยามในบทนี้ — มีคำอธิบายสั้นในวงเล็บ และจะเจอแบบเต็มในบทถัดไป (CI/CD บท 5, Docker บท 3, IaC/Terraform บท 6, Observability บท 7, SLO/Error budget หัวข้อ 7 ของบทนี้)

Level 1 — Manual (ทำมือทั้งหมด) ​

  • Deploy by hand — copy ไฟล์ขึ้น server ด้วยมือ
  • ตั้งค่า server ผ่าน SSH (Secure Shell — โปรแกรม remote เข้า Linux server ผ่าน command line, ดูบท 1)
  • ดู log ด้วยคำสั่ง cat /var/log/app.log บน server โดยตรง

Level 2 — Scripted (มี script แต่ยังกดเอง) ​

  • เขียน Bash script ช่วย deploy (ดูบท 1)
  • Cron job = ตัวตั้งเวลาให้ Linux รันคำสั่งอัตโนมัติ (เช่น สำรอง DB ตี 3 ทุกวัน)
  • เก็บ log ลงไฟล์

Level 3 — Automated (อัตโนมัติเต็มขั้น) ​

  • CI/CD pipeline — สายพานอัตโนมัติ build → test → deploy (ดูบท 5)
  • Docker — container ที่ wrap app + dependency ไปด้วยกัน (ดูบท 3 / Docker Book)
  • Centralized logging — รวม log จากทุก server ไว้ที่เดียว — ตัวอย่าง stack:
    • ELK (Elasticsearch + Logstash + Kibana) — stack คลาสสิก
    • Loki + Grafana — stack ใหม่ที่ได้รับความนิยมเพิ่มขึ้นในปี 2024-2026
    • OpenSearch — ทางเลือก open-source ของ Elasticsearch
  • Monitoring = เฝ้าระบบเก็บ metric — ตัวอย่าง: Prometheus (เครื่องมือเก็บ metric ของ server/app เป็น time-series — ดูบท 7)

Level 4 — Self-service (ทีมอื่นเข้ามาใช้เองได้) ​

  • IaC (Infrastructure as Code) — เขียน infra เป็นโค้ดด้วย Terraform (ดูบท 6)
  • Auto-scaling — ขยายหด server อัตโนมัติตาม load
  • Blue/green deployment = run 2 version พร้อมกัน (blue=เก่า, green=ใหม่) แล้วสลับ traffic เมื่อพร้อม (ดูบท 5)
  • Distributed tracing = ตามรอย request ข้าม service ได้ครบทุก hop (ดูบท 7)

Level 5 — Optimized (เพิ่ม resilience + ส่งของแบบควบคุมความเสี่ยง) ​

  • Chaos engineering = จงใจทำให้บางส่วนของระบบพังในช่วงเวลาที่ควบคุม เพื่อทดสอบว่าระบบทนได้ไหม (เช่น Netflix Chaos Monkey)
  • Progressive delivery = ปล่อยของแบบค่อย ๆ เปิด:
    • canary = ปล่อยให้ user 1-10% ก่อน → ค่อยขยาย
    • feature flag = เปิด/ปิด feature ด้วย config โดยไม่ต้อง deploy ใหม่
  • SLO + error budget = ตั้งเป้า reliability + อนุญาตให้พังได้ในขอบเขต (ดูหัวข้อ 7)
  • Platform engineering = ทีมกลางที่สร้าง platform ให้ทีมอื่นใช้ (ดูหัวข้อ 8)

6. DevOps Tools Landscape ​

เครื่องมือ DevOps มีเป็นร้อย จนมือใหม่มักงงว่าตัวไหนทำอะไร วิธีจำที่ง่ายที่สุดคือมองตาม "ขั้นตอนของ pipeline" (สายพานงาน) แผนภาพและตารางด้านล่างจับเครื่องมือยอดนิยมมาวางตามหน้าที่ในแต่ละขั้น ให้เห็นภาพรวมทั้งหมด:

Category (หมวด)Toolsคำอธิบายสั้น
Source Control (เก็บโค้ด)Git, GitHub, GitLab, Bitbucketระบบเก็บ + version โค้ด
CI/CD (สายพาน build/deploy)GitHub Actions, GitLab CI, Jenkins, CircleCI, Tekton, Argo CD / FluxCDArgo CD/FluxCD = ตัว GitOps sync จาก git → cluster (ดูบท 5)
ContainerDocker, Podman, containerdwrap app + dependency เป็น container
Orchestration (จัดการ container เป็นฝูง)Kubernetes, Nomad, ECS (Elastic Container Service ของ AWS)scale/heal/schedule container อัตโนมัติ
IaC (Infrastructure as Code — เขียน infra เป็นโค้ด)Terraform, OpenTofu, Pulumi (เขียนเป็นภาษาทั่วไป เช่น TypeScript/Python), CloudFormation (ของ AWS เฉพาะ), Ansible, Crossplane (IaC ผ่าน Kubernetes API)ดูบท 6
Config ManagementAnsible, Chef, Puppet, Saltตั้งค่า/configure server ที่มีอยู่
CloudAWS, GCP, Azure, DigitalOcean, Hetznerผู้ให้บริการ cloud (ดูบท 6)
Monitoring (เฝ้า metric)Prometheus, Grafana, Datadog, New Relicดูบท 7
Logging (เก็บ log)Loki (ของ Grafana), ELK Stack, Splunk, Datadog
Tracing (ตามรอย request)Jaeger, Tempo (ของ Grafana), Honeycomb (cloud SaaS)
SecurityVault (จัดการ secret), Snyk (สแกน dependency หาช่องโหว่), Trivy (สแกน container image)
Secret Mgmt (จัดการ password/key)Vault, AWS Secrets Manager, 1Password, SOPS (เข้ารหัส secret ในไฟล์), External Secrets Operator (sync secret เข้า Kubernetes)
Supply chain securitySigstore / Cosign (เซ็นชื่อ container image ยืนยันว่า image ไม่ถูกแก้), SLSA (Supply-chain Levels for Software Artifacts — กรอบมาตรฐานความปลอดภัย build), SBOM (Software Bill of Materials — รายการ dependency ทั้งหมดของ software)หัวข้อร้อนแรงตั้งแต่ปี 2023+ — เริ่มเป็นมาตรฐานในปี 2026
Policy as code (บังคับกฎเป็นโค้ด)OPA Gatekeeper (Open Policy Agent — บังคับ policy ด้วยภาษา Rego), Kyverno (บังคับ policy ด้วย YAML ไม่ต้องเรียนภาษาใหม่)บังคับ policy ลง Kubernetes เช่น "ห้าม deploy image ที่ไม่ผ่าน scan"
eBPF observabilityeBPF (Extended Berkeley Packet Filter — วัดประสิทธิภาพระดับ kernel โดยไม่ต้องแก้โค้ด): Pixie (เครื่องมือ debug pod real-time), Parca (เครื่องมือ profiling แบบต่อเนื่อง), Coroot (dashboard observability แบบ zero-code)observability ระดับ kernel ที่ overhead ต่ำ — มือใหม่ข้ามได้ก่อน
CNI (Kubernetes networking — ปลั๊กอิน network ของ K8s)Cilium (CNI ที่ใช้ eBPF — network policy + observability ในตัว), Calico (CNI คลาสสิก — network policy เน้น compatibility)CNI = Container Network Interface: กำหนดว่า pod คุยกันยังไง

🚀 2 แถวสุดท้าย (eBPF observability, CNI) ข้ามได้ตอนนี้ — เป็นเครื่องมือระดับ production scale ใหญ่ ที่มือใหม่ยังไม่ต้องรู้จัก แค่รู้ว่ามีอยู่พอ

→ เลือก 1 ตัวต่อ category — อย่าใช้ทุกตัว

7. SRE — Site Reliability Engineering ​

🚀 โซนขั้นสูง — ข้ามได้ หัวข้อ 7 (SRE) และ 8 (Platform Engineering) เป็นแนวคิดของทีมใหญ่/บริษัทระดับ scale มาก ถ้าเพิ่งเริ่ม DevOps อ่านผ่าน ๆ พอรู้ว่ามีอยู่ก็พอ ไม่ต้องเข้าใจลึกตอนนี้ — เดี๋ยวเรื่อง SLI/SLO/Error Budget จะกลับมาเจอแบบลงมือทำจริงใน Observability Book บท 06 (Observability Book = เล่มแยกที่สอนเรื่องการเฝ้าระบบ — log/metric/trace อยู่ใน folder observability/ อ่านหลังจบ DevOps Book แล้ว)

SRE = "DevOps แบบฉบับของ Google" — Google เริ่มทำ SRE ภายในตั้งแต่ปี 2003 แต่เผยแพร่ออกมาให้คนนอกรู้จักผ่านหนังสือ Site Reliability Engineering ปี 2016 (ดังนั้นปี 2003 = วันเริ่มภายใน, ปี 2016 = วันที่วงการรู้จัก)

แนวคิดสำคัญ (อ่านทีละบรรทัด):

  • มองงาน operations เป็นปัญหา software engineering — แก้ด้วยโค้ดได้ ไม่ใช่แก้ด้วยมือ (ต้นฉบับ: "Treat operations as a software engineering problem")
  • ลด toil (งานมือซ้ำ ๆ น่าเบื่อ ที่ควร automate ทิ้ง)
  • Error budget (งบความผิดพลาด) — ยอมให้พังได้บ้างในขอบเขตที่กำหนด

Concepts ​

ศัพท์ภาษาไทยคืออะไร
SLI (Service Level Indicator)ตัวชี้วัดmetric ที่วัดได้จริง เช่น latency (เวลาตอบกลับ), error rate (% error)
SLO (Service Level Objective)เป้าหมายtarget ของ SLI เช่น "99.9% uptime ใน 30 วัน"
SLA (Service Level Agreement)สัญญากับลูกค้าสัญญาทางธุรกิจ — ถ้าทำไม่ได้ตามสัญญาต้องคืนเงิน/ชดเชย
Error Budgetงบความผิดพลาด100% - SLO = "พังได้แค่ไหนใน 1 เดือน"
text
SLO = 99.9% uptime (เวลา 1 เดือน)
→ Error budget = 100% - 99.9% = 0.1%

วิธีคิดเป็นนาที:
30 วัน × 24 ชม. × 60 นาที = 43,200 นาที / เดือน
43,200 × 0.1% = 43.2 นาที / เดือน
→ พังได้ ~43 นาที / เดือน

ถ้าใช้ budget หมดเร็ว (เช่นเดือนนี้พังไปแล้ว 40 นาที):
→ freeze feature (หยุดปล่อยของใหม่) แล้วโฟกัสที่ความเสถียร
ถ้ายังมี budget เหลือเยอะ:
→ ship feature เร็วได้ตามปกติ

Toil (งานมือซ้ำ ๆ น่าเบื่อที่ควร automate ทิ้ง) ​

ต้นฉบับ: "Manual, repetitive, automatable work" (งานที่ทำมือ ทำซ้ำ ๆ และ automate ได้)

  • Restart server (กดรีเซ็ตทุกอาทิตย์)
  • Apply same fix (แปะ fix เดิมซ้ำ ๆ)
  • Manual deploy (deploy ด้วยมือทีละขั้น)

SRE target: ใช้เวลากับ toil ไม่เกิน 50% ของเวลาทำงาน — ที่เหลือไปทำ engineering ที่ทำให้ระบบดีขึ้น (ตัวเลข 50% มาจากหนังสือ Google "Site Reliability Engineering" บทที่ 5 — เป็น ceiling (เพดาน) แนะนำ ไม่ใช่กฎเหล็ก ทีมขนาดเล็กอาจปรับตาม context ของตัวเอง)

8. Platform Engineering ​

ปัญหาที่ Platform Engineering แก้ ​

DevOps ดั้งเดิมพูดว่า "ทุกคนต้องทำ ops" — ใน startup 10 คน ใช้ได้. พอ scale เป็น 100+ engineers:

  • ทุก team ต้องเขียน Terraform เอง → คนละ pattern → infra ยุ่งเหยิง
  • ทุก team setup CI/CD เอง → 20 pipelines แตกต่าง → maintain ไม่ไหว
  • App engineer ต้องเรียน K8s ลึก ทั้งที่ควรเน้น business logic

แนวคิด ​

Platform Engineering = สร้าง Internal Developer Platform (IDP — แพลตฟอร์มภายในให้ทีม dev ใช้) — เหมือนทำ "Heroku ของตัวเอง" ให้ทีมในบริษัท

คำในแผนภาพ:

  • Golden path = เส้นทาง/วิธีมาตรฐานที่ platform team รับรองว่า "เดินตามนี้แล้วเร็ว ปลอดภัย ผ่านมาตรฐาน" — ทีมไม่ต้องคิดเองตั้งแต่ศูนย์
  • Observability defaults = พอสร้าง service ใหม่ ก็ได้ log/metric/trace + dashboard เริ่มต้นมาเลย ไม่ต้อง config เอง
  • Compliance built-in = security/กฎหมาย (เช่น GDPR, PCI) ฝังในแม่แบบ ไม่ต้องตามทำทีหลัง

ตัวอย่าง ​

  • Spotify — สร้าง Backstage (open source แล้ว) — portal ที่ engineer สร้าง service ใหม่ได้ใน 5 นาที, log/metric/dashboard เปิดให้อัตโนมัติ
  • Netflix — Spinnaker (deploy platform), Atlas (observability)
  • บริษัทเล็ก — Render, Railway, Vercel, Heroku = Platform ที่ "เช่า" ได้ ไม่ต้องสร้างเอง (PaaS — Platform as a Service)

Tools ยอดนิยม (last reviewed: 2026-06) ​

หมายเหตุ: tool ส่วนใหญ่ในตารางนี้เปิดตัวก่อนปี 2024 — ไม่ใช่ tool "เฉพาะปี 2026" ปีที่ระบุไว้บอกว่า "list นี้ตรวจล่าสุดเมื่อไหร่" (ไม่มี source สำรวจที่ลิงก์ได้ตรง ๆ — เป็นการสรุปจาก CNCF landscape + บทความ Platform Engineering 2024-2026)

ใช้สำหรับToolคำอธิบายสั้น
Developer portal (หน้าเว็บกลางให้ dev ใช้)Backstage, Port, Humanitec, Mia-Platform, devtronBackstage = ของ Spotify; Port/Humanitec = SaaS portal; Score = spec กลางอธิบาย workload
Infra abstraction (ห่อ infra ให้เรียบ)Crossplane, Terraform modules, KratixCrossplane = IaC ผ่าน Kubernetes API
Service template (แม่แบบ service)Backstage scaffolder, Cookiecutterสร้าง service ใหม่จากแม่แบบ
Cost visibility (ดูค่าใช้จ่าย cloud)OpenCost, Kubecost (UI/feature เพิ่มบน OpenCost), Infracost (คำนวณค่า Terraform ก่อน apply), CloudHealth (SaaS ระดับ enterprise)

→ DevOps generation (รุ่น) ใหม่ — scale ได้สำหรับ org ใหญ่

9. ความเข้าใจผิดที่พบบ่อย ​

❌ "DevOps = job title (ตำแหน่งงาน)"
✅ DevOps = practice + culture (วิธีปฏิบัติ + วัฒนธรรม) — ใครก็ทำได้ ไม่ต้องมีตำแหน่ง

❌ "DevOps = ต้องใช้ Kubernetes"
✅ tool optional (เครื่องมือเลือกได้) — Kubernetes overkill (ใช้เกินจำเป็น) สำหรับ project เล็ก

❌ "DevOps = Dev ทำ Ops + Ops ทำ Dev"
✅ collaboration (ร่วมมือ) — แต่ละคน specialize (เชี่ยวชาญเฉพาะทาง) ของตัวเอง

❌ "DevOps = ทำเร็วขึ้น = ลด quality (คุณภาพ)"
✅ DevOps = ทั้งเร็วขึ้น + ปลอดภัยขึ้น โดยอาศัย automation ช่วย (faster + safer)

❌ "Microservices = ต้องการ DevOps"
✅ ใช่ — แต่ monolith (app ใหญ่ก้อนเดียว) ก็ได้ประโยชน์เช่นกัน

10. คำศัพท์พื้นฐาน (Glossary) ​

คำเหล่านี้จะกลับมาเจอเรื่อย ๆ ในบทถัดไป — ไม่ต้องท่องตอนนี้ กลับมาเปิดดูได้

คำความหมายเจอครั้งแรกที่บท
CI (Continuous Integration)merge code บ่อย + auto build/test ทุก commit5
CD (Continuous Delivery)build เสร็จพร้อม deploy แต่ต้องกดปุ่ม5
CD (Continuous Deployment)deploy auto ถ้า test ผ่าน — ไม่ต้องกดปุ่ม5
Pipelineลำดับขั้นตอนทำงานอัตโนมัติต่อกัน (lint → test → build → deploy)5
Artifactoutput ของ build ที่ deploy ได้ (jar, docker image, zip)3, 5
Registryคลังเก็บ artifact — Docker Hub, GHCR (GitHub Container Registry), ECR (Elastic Container Registry ของ AWS)3
Orchestrationmanage container เป็น cluster — start/stop/scale/heal4
IaC (Infrastructure as Code)infra เขียนเป็น code → version, review, recreate ได้6
Immutable Infrastructureserver = build ใหม่เสมอ ไม่ patch ของเก่า3, 6
Blue/Green Deploymentrun 2 versions (blue=เก่า, green=ใหม่), switch traffic เมื่อพร้อม5
Canarydeploy ใหม่ให้ 1% user ก่อน → 10% → 100% (ค่อยเปิด)5
Rollbackกลับไป version เก่า (เมื่อ version ใหม่พัง)5
Observabilitymonitoring + logging + tracing — "เห็นว่ากำลังเกิดอะไรในระบบ"7
SLI/SLO/SLAindicator/objective/agreement — วัด/ตั้งเป้า/สัญญากับลูกค้า0, 7
Toilmanual repetitive work ที่ควร automate0
Incidentproduction problem ที่กระทบ user7
Postmortemincident analysis — เขียนหลังเกิด incident (blameless)0, 7
Runbookdocument "production พัง X → ทำตามนี้"7
GitOpsdeploy = git commit (ArgoCD/Flux sync จาก git → cluster)4, 5

11. Roadmap ของ DevOps ​

Level 1 — Foundation (รากฐาน, เดือนที่ 1-3) ​

  • Linux + Shell (บทที่ 1)
  • Git (บทที่ 2)
  • Docker (บทที่ 3)
  • CI/CD basics (บทที่ 5)

Level 2 — Apply (เริ่มใช้งานจริง, เดือนที่ 4-6) ​

  • Deploy app บน cloud (บทที่ 6)
  • Monitoring + logging (บทที่ 7)
  • IaC (Terraform) (บทที่ 6)

Level 3 — Scale (ขยายเป็นระบบใหญ่, เดือนที่ 7-12) ​

  • Kubernetes (บทที่ 4) — เริ่มหลังเข้าใจ Docker แล้วเท่านั้น
  • Service mesh = ชั้นกลางจัดการ traffic ระหว่าง service (เช่น Istio, Linkerd) — ใช้เมื่อมี microservices หลายตัว
  • Distributed tracing = ตามรอย request ที่ข้ามหลาย service เพื่อ debug ว่าช้าตรงไหน (เช่น Jaeger, Tempo)
  • Chaos engineering = จงใจสร้างความล้มเหลวในระบบเพื่อทดสอบความทนทาน (เช่น Chaos Monkey ของ Netflix)

Level 4 — Master (เชี่ยวชาญ, 1+ year) ​

  • Platform engineering (ดูหัวข้อ 8)
  • SRE practices (ดูหัวข้อ 7)
  • Cost optimization (ลดค่าใช้จ่าย cloud)
  • Multi-cloud / hybrid (ใช้หลาย cloud / ผสม on-prem + cloud)

12. คำแนะนำสำหรับมือใหม่ ​

✅ Do (ควรทำ) ​

  1. เริ่มเล็ก ๆ ก่อน — deploy 1 app ด้วย Docker → ทำ CI/CD → ค่อย K8s
  2. ใช้ cloud แทน on-prem (AWS Free Tier, GCP, Azure) — เรียนเร็วกว่า ไม่ต้องตั้ง server เอง
  3. ลงมือทำ — อ่าน 20%, ลงมือ 80%
  4. อ่าน postmortem จริง — GitHub, Cloudflare เผยแพร่บ่อย — เรียนจาก incident คนอื่น
  5. เข้าร่วม community — DevOps Subreddit, HackerNews, Twitter/X

❌ Don't (ไม่ควรทำ) ​

  1. ข้าม Linux/Shell — เป็นรากฐานที่จำเป็น
  2. เริ่มที่ Kubernetes เลย — overkill (ใช้เกินจำเป็น) ถ้ายังไม่เข้าใจ Docker
  3. อย่ารัน Kubernetes ใน production ลำพังคนเดียวก่อนพื้นฐานแน่น — K8s ผิดพลาดทีนึงคืนไม่ได้ง่าย ๆ ในขณะที่ Docker Compose / PaaS (Heroku, Render, Railway) จัดการง่ายกว่าเยอะสำหรับมือใหม่
  4. copy-paste ตามไม่คิด — เข้าใจก่อนใช้
  5. ไม่ใส่ใจ security — ทำตั้งแต่แรก (HTTPS, secret, IAM = Identity and Access Management = ระบบจัดการตัวตน + สิทธิ์เข้าถึง resource ของ cloud)
  6. ทำทุกอย่างด้วยมือ — ถ้าทำซ้ำ 3 ครั้ง → automate

13. ตัวอย่าง — DevOps Pipeline ที่ดี ​

เพื่อให้เห็นภาพว่าแนวคิดทั้งหมดในบทนี้ประกอบกันเป็นของจริงยังไง ลองดูตัวอย่าง pipeline ที่ครบวงจร — ตั้งแต่ developer push code จนถึง production แบบ canary และมี monitoring ครบ สังเกตว่าทุกขั้นเป็นอัตโนมัติ ไม่มีขั้นทำมือ:

📝 หมายเหตุเรื่องแผนภาพ: ในรูปข้างบน lint/test/build/scan วาดต่อกันเป็นเส้นเดียว (sequential gates — ผ่านขั้นนึงจึงไปขั้นถัดไป) เพราะในชีวิตจริงเรามักให้ test ผ่านก่อนค่อย build, build เสร็จค่อย scan image — ไม่ได้รันขนานกันทั้งหมด (ทีมใหญ่ที่ optimize เร็วอาจรัน lint + test ขนานกันได้, แต่ build ต้องรอ test ผ่านเสมอ)

อธิบาย node ที่ย่อไว้:

  • Trivy = เครื่องมือ open-source สแกนช่องโหว่ (CVE) ใน Docker image
  • E2E Tests = End-to-End tests = ทดสอบทั้งระบบเหมือนผู้ใช้จริง (กดจริง คลิกจริง)
  • Canary Deploy = deploy ขึ้น production แบบค่อย ๆ ปล่อย: 10% ของ traffic → 50% → 100% (ถ้า metric ปกติ ค่อยขยาย)
  • Monitoring = สแต็ก observability ครบชุด: Prometheus + Grafana (metric), Loki (log), Tempo (trace), PagerDuty (ระบบส่ง alert ปลุกทีม on-call — on-call คือเข้าเวรรับแจ้งเหตุนอกเวลางาน หมุนเวียนกันในทีม)

→ จาก commit → production = 15-30 นาที, ไม่มีขั้นทำมือ

14. ตัวอย่าง — Postmortem (Format) ​

หลังเกิด incident (เหตุการณ์ระบบมีปัญหา) ทีม DevOps ที่ดีจะเขียน "postmortem" — เอกสารสรุปว่าเกิดอะไร กระทบแค่ไหน สาเหตุรากคืออะไร และจะป้องกันยังไง หัวใจคือ blameless (โทษระบบ ไม่โทษคน) เพื่อให้คนกล้าเล่าความจริง เทมเพลตด้านล่างเป็นโครงมาตรฐานที่ปรับใช้ได้เลย:

คำแปลหัวข้อ (ใช้ในเทมเพลตด้านล่าง):

  • Summary = สรุปสั้น
  • Impact = ผลกระทบ (กระทบใคร เท่าไหร่)
  • Timeline = ลำดับเหตุการณ์ตามเวลา
  • Root Cause = สาเหตุรากที่แท้จริง
  • What Went Well / Wrong = อะไรทำได้ดี / อะไรพลาด
  • Action Items = สิ่งที่ต้องทำต่อ (พร้อมเจ้าของงาน + กำหนดส่ง)
  • Lessons Learned = บทเรียนที่ได้
markdown
# Incident: API Outage on 2026-05-18
(เหตุการณ์: API ล่ม วันที่ 2026-05-18)

## Summary (สรุปสั้น)
API was unresponsive for 23 minutes due to database connection pool exhaustion.
→ API ไม่ตอบสนอง 23 นาที เพราะ connection pool ของฐานข้อมูลเต็ม

## Impact (ผลกระทบ)
- 12,000 affected users (ผู้ใช้กระทบ 12,000 คน)
- $5,400 estimated revenue loss (สูญรายได้ประมาณ $5,400)
- 0 data loss (ไม่มีข้อมูลหาย)

## Timeline (UTC) — ลำดับเหตุการณ์
- 14:00 - Spike in traffic (3x normal) — traffic พุ่ง 3 เท่าจากปกติ
- 14:05 - Connection pool exhausted (alert fired) — pool เต็ม, alert ทำงาน
- 14:08 - Engineer on call paged — วิศวกร on-call ได้รับแจ้ง
- 14:15 - Root cause identified — เจอสาเหตุราก
- 14:20 - Pool size increased + app restarted — เพิ่มขนาด pool + รีสตาร์ท app
- 14:23 - Service restored — service กลับมาทำงาน

## Root Cause (สาเหตุราก)
The connection pool was configured at 20, but a marketing campaign
launched at 14:00 brought 3x normal traffic. Pool exhausted, requests
queued, timeout, cascading failure.
→ ตั้ง connection pool ไว้ที่ 20 แต่ campaign การตลาดที่เปิดตัว 14:00 ทำให้
traffic พุ่ง 3 เท่า → pool เต็ม → request ค้างคิว → timeout → ล้มต่อกันเป็นโดมิโน

## What Went Well (อะไรทำได้ดี)
- Alert fired within 5 minutes — alert ดังภายใน 5 นาที
- On-call engineer responded in 3 minutes — engineer ตอบใน 3 นาที
- Service restored in 23 minutes total — กู้ระบบใน 23 นาที

## What Went Wrong (อะไรพลาด)
- Pool size was never tuned for marketing campaigns — ไม่เคยปรับ pool ให้เผื่อ campaign
- No auto-scaling on connection pool — pool ไม่ scale อัตโนมัติ
- No load test before launch — ไม่ได้ load test ก่อนปล่อย campaign

## Action Items (สิ่งที่ต้องทำต่อ)
1. [ ] Increase default pool to 50 (owner: @sre, due: this week)
       → ปรับ default pool เป็น 50 (เจ้าของ: @sre, กำหนดส่ง: สัปดาห์นี้)
2. [ ] Auto-scale based on metrics (owner: @platform, due: 2 weeks)
       → ทำ auto-scale ตาม metric (เจ้าของ: @platform, กำหนดส่ง: 2 สัปดาห์)
3. [ ] Load test runbook for campaigns (owner: @dev, due: 1 month)
       → ทำ runbook (คู่มือ) สำหรับ load test ก่อน campaign (เจ้าของ: @dev, กำหนดส่ง: 1 เดือน)
4. [ ] Document campaign launch checklist
       → เขียน checklist สำหรับการเปิดตัว campaign

## Lessons Learned (บทเรียน)
Marketing should notify engineering 48 hours before campaigns
that affect API traffic >2x normal.
→ ทีม marketing ควรแจ้งทีม engineering ล่วงหน้า 48 ชม. ก่อนเปิด campaign
ที่ทำให้ traffic เกิน 2 เท่าของปกติ

→ Blameless (โทษระบบ ไม่โทษคน) — โฟกัสที่ ระบบ ไม่ใช่ คน

15. Checkpoint (จุดตรวจสอบ) ​

🛠️ Checkpoint 0.1 — DORA Assessment (ประเมินทีมตาม DORA)
ให้คะแนน project ของคุณ:

  • Deployment frequency — deploy ขึ้น production กี่ครั้งต่อสัปดาห์?
  • Lead time — ตั้งแต่ commit → production ใช้เวลานานแค่ไหน?
  • Change failure rate — กี่ % ของ deploy ที่ต้อง rollback / hotfix?
  • MTTR — ระบบพังแล้วใช้เวลากู้กลับมานานเท่าไหร่?

ระบุว่าอยู่ระดับไหน — Elite / High / Medium / Low?

🛠️ Checkpoint 0.2 — Read Postmortem (อ่าน postmortem จริง)
อ่าน postmortem จริง — เช่น:

แล้วเขียน "บทเรียนที่ได้" (lesson learned) 3 ข้อ

🛠️ Checkpoint 0.3 — Toil Audit (สำรวจงานมือ)
ลิสต์งานที่คุณทำมือซ้ำใน 1 สัปดาห์ → ระบุว่าตัวไหน automate ได้บ้าง

🛠️ Checkpoint 0.4 — Setup (ติดตั้งเครื่องมือพื้นฐาน)
ติดตั้ง:

  • Docker — Mac/Windows ใช้ Docker Desktop, Linux ใช้ Docker Engine (Docker Desktop บน Linux ก็ได้แต่ optional)

  • Git

  • VS Code หรือ IntelliJ (เลือกอันที่ถนัด)

  • AWS / GCP free account

    ⚠️ ต้องตั้ง billing alert ก่อนทำอะไรอื่นทุกครั้ง — เพราะต้องผูกบัตรเครดิต ถ้าหลุด free tier จะถูกชาร์จเงินทันที

    ขั้นตอนสำหรับ AWS (ทำทันทีหลังสร้าง account):

    1. สร้าง account ที่ aws.amazon.com
    2. ก่อนทำอะไรอื่น: ไปที่ AWS Billing → Budgets → Create budget
    3. ตั้ง alert ที่ $1 (เตือนเร็ว) และ $5 (เตือนอีกครั้ง) — ใส่ email ที่เช็คบ่อย
    4. ทบทวน free tier usage ทุกเดือนที่ Free Tier dashboard

    GCP: ไปที่ Billing → Budgets & alerts → Create budget ทำนองเดียวกัน

  • GitHub account

16. สรุปบท ​

✅ DevOps = culture (วัฒนธรรม) + practice (วิธีปฏิบัติ) + tool — ไม่ใช่แค่ tool
✅ CALMS (5 เสาหลัก): Culture, Automation, Lean, Measurement, Sharing
✅ DORA metrics (4 ตัววัด): deployment frequency, lead time, failure rate, MTTR
✅ SRE: SLI/SLO/SLA + error budget + ลด toil
✅ Platform Engineering = scale DevOps สำหรับบริษัทใหญ่ (สร้าง IDP)
✅ เริ่มเล็ก — Docker → CI/CD → Cloud → Kubernetes (เมื่อจำเป็นเท่านั้น)
✅ Postmortem = blameless (โทษระบบ ไม่โทษคน) — โฟกัสที่ระบบ
✅ ทำซ้ำเกิน 3 ครั้งด้วยมือ → automate ทิ้ง

บทถัดไป → Linux + Shell

🔤 Glossary · 📋 Style guide · 📅 last_verified: 2026-06-12