ในช่วงสองสามปีที่ผ่านมา คำถามที่ทีม IT หลายองค์กรในไทยถามเข้ามาซ้ำ ๆ คือ "SRE กับ DevOps ต่างกันยังไง แล้วเราควรจ้างอะไรดี?" ความสับสนนี้เข้าใจได้ เพราะทั้งสองคำพูดถึงเรื่องระบบ การ deploy และการทำงานร่วมกันระหว่าง Dev กับ Ops เหมือนกันเกือบทุกบรรทัด แต่ถ้าไม่แยกให้ออก งบประมาณที่ลงทุนอาจไปผิดทาง และระบบที่ควรจะ "แข็งแกร่ง" ก็อาจกลายเป็น "แข็งทื่อ" แทน
DevOps คืออะไร (สรุปสั้น ๆ)
DevOps คือ วัฒนธรรมและแนวปฏิบัติ ที่ดึงทีม Development กับทีม Operations มาทำงานร่วมกัน โดยมีเป้าหมายหลักคือ ส่งซอฟต์แวร์ได้เร็วขึ้น มีคุณภาพขึ้น ผ่านการ automate pipeline ตั้งแต่ code → build → test → deploy
DevOps ไม่ใช่ตำแหน่งงาน ไม่ใช่เครื่องมือ และไม่ใช่ทีมแยกต่างหาก — มันคือ "วิธีคิด" ที่ฝังในกระบวนการทำงาน สำหรับองค์กรที่อยากวางรากฐานวัฒนธรรมและ pipeline แบบนี้ให้ถูกตั้งแต่ต้น ทีม DevOps & SRE Managed ของเราช่วยออกแบบและ implement ได้
SRE คืออะไร
Site Reliability Engineering (SRE) กำเนิดขึ้นที่ Google ในปี 2003 เมื่อ Ben Treynor Sloss ได้รับมอบหมายให้ดูแลระบบ production ขนาดใหญ่ แนวคิดง่ายมาก:
"SRE คือสิ่งที่เกิดขึ้นเมื่อคุณให้ Software Engineer มาทำงานที่เดิมเรียกว่า Operations"
— Ben Treynor Sloss, VP Engineering, Google
แทนที่จะแก้ปัญหาระบบด้วยการเพิ่มคน SRE ใช้ การเขียนโค้ดแก้ปัญหาการดูแลระบบ โดยมีหลักการสำคัญสามอย่าง:
1. SLI — Service Level Indicator
ตัวชี้วัดจริงของระบบ เช่น latency, error rate, availability ที่วัดได้จริงจากฝั่ง user
2. SLO — Service Level Objective
เป้าหมายที่ตกลงกันภายใน เช่น "ระบบต้องมี availability ≥ 99.9% ในแต่ละเดือน"
3. Error Budget
ช่องว่างระหว่าง 100% กับ SLO — ถ้า SLO = 99.9% แสดงว่ามี error budget 0.1% (ประมาณ 43 นาทีต่อเดือน) ทีม Dev สามารถใช้ budget นี้ deploy feature ใหม่ได้ แต่ถ้าใช้หมดแล้ว หน้าที่ของ SRE คือ "ยับยั้ง" การ deploy ใหม่จนกว่าระบบจะกลับมาเสถียร
กลไกนี้เองที่ทำให้ SRE ไม่ใช่แค่ "Ops ที่เขียนโค้ดได้" แต่เป็น ตัวกลางที่สมดุลระหว่างความเร็วและความเสถียร
เปรียบเทียบ DevOps vs SRE
| มิติ | DevOps | SRE |
|---|---|---|
| เป้าหมายหลัก | ส่งซอฟต์แวร์เร็วและต่อเนื่อง | รักษาความเสถียรและ reliability ของ production |
| Focus | Delivery pipeline, CI/CD, collaboration | Incident response, SLO, capacity planning |
| Metrics | Deployment frequency, lead time, MTTR | Availability, error rate, latency (SLI/SLO) |
| ทีม | Culture ที่ฝังทั่วทั้ง Dev+Ops | ทีมเฉพาะทาง (มักอยู่ใน platform/infra) |
| เครื่องมือหลัก | GitHub Actions, Jenkins, ArgoCD, Terraform | Prometheus, Grafana, PagerDuty, Chaos Engineering |
| ต้นกำเนิด | Agile + Lean IT (2009) | Google internal practice (2003) |
| เหมาะกับ | ทุกองค์กรที่ต้องการ ship บ่อยขึ้น | องค์กรที่ระบบ downtime มีผลกระทบสูง |
สรุปง่าย ๆ: DevOps แก้ปัญหา "ส่งได้ช้า" ส่วน SRE แก้ปัญหา "ระบบล่มบ่อย"
ทั้งสองไม่ได้แข่งกัน แต่เป็นเลเยอร์ที่ซ้อนทับกัน — องค์กรที่ลงทุนเรื่อง cloud และ infrastructure แล้วก็มักจะต้องการทั้ง DevOps practice และ SRE discipline ควบคู่กันไป
องค์กรขนาดไหนควรมี SRE?
ไม่มีสูตรตายตัว แต่มีสัญญาณที่บ่งบอกชัดว่าถึงเวลาแล้ว:
- ระบบ production มีผู้ใช้งานจริงตลอด 24 ชั่วโมง และ downtime ทุก 1 นาทีมีมูลค่าความเสียหายที่วัดได้
- ทีม Dev ถูก interrupt ทุกครั้งที่ระบบมีปัญหา จนไม่มีเวลา build feature ใหม่
- ไม่มี SLO ที่ชัดเจน — ไม่รู้ว่าระบบ "ดีพอ" แค่ไหน
- ขนาดทีม Dev เกิน 10 คน และมีหลาย service ที่ต้อง coordinate กัน
องค์กรที่ยังเล็กและมี product เดียวอาจยังไม่จำเป็นต้องมี SRE เต็มรูปแบบ แต่ควรเริ่มฝัง mindset ของ SRE เช่น การกำหนด SLO และการทำ on-call rotation ที่เป็นระบบ ก่อนที่ระบบจะใหญ่เกินควบคุม
ทำไม SRE ถึงยังหายากในไทย และองค์กรควรทำอย่างไร
ความเป็นจริงในตลาดแรงงานไทยปี 2025–2026 คือ SRE Engineer ระดับ Senior แทบไม่มีขาย เหตุผลหลักมีสองข้อ:
1. เส้นทางอาชีพไม่ชัด — มหาวิทยาลัยไทยยังไม่มีหลักสูตร SRE โดยตรง และบริษัทส่วนใหญ่ยังรวม SRE เข้ากับ DevOps Engineer หรือ System Admin ทำให้คนที่มีทักษะจริงไม่รู้ว่าตัวเองอยู่ในสายงานนี้
2. ต้องการประสบการณ์ production จริงระดับสูง — SRE ที่ดีต้องเคยผ่านระบบที่ล้มแล้วลุกขึ้นมาหลายครั้ง ทักษะนี้สร้างได้ยากในสภาพแวดล้อมที่ระบบไม่ซับซ้อนพอ
จ้างเอง vs Outsource
| มิติ | จ้างเอง | Outsource / Managed SRE |
|---|---|---|
| ความเชี่ยวชาญ | ขึ้นกับโชคในการหาคน | ได้ทีมที่มีประสบการณ์ข้ามหลาย industry |
| ต้นทุน | เงินเดือน + เวลา onboard 3–6 เดือน | ควบคุมได้ตามระดับ SLA |
| ความเร็ว | ช้า | เริ่มได้ภายใน 2–4 สัปดาห์ |
| Knowledge transfer | อยู่ใน organization | ต้องวางแผน runbook ร่วมกัน |
| เหมาะกับ | บริษัทที่มี product ซับซ้อน ระยะยาว | องค์กรที่อยากได้ SRE เร็ว หรือยังไม่แน่ใจว่าต้องการเต็มเวลา |
UNIXDEV ทำงานกับองค์กรกว่า 71 แห่งในไทยมาตั้งแต่ปี 2013 และพบว่า โมเดลที่ได้ผลที่สุดสำหรับองค์กรกลาง-ใหญ่ในไทย คือการเริ่มด้วย Managed SRE ก่อน เพื่อสร้าง SLO framework, runbook และ incident response process ที่ถูกต้อง จากนั้นค่อย transfer knowledge ให้ทีมภายในเมื่อพร้อม แทนที่จะรอหาคนเก่งที่หายากและจ้างยาก
สรุป: SRE ไม่ใช่ "DevOps ขั้นสูง" แต่เป็นศาสตร์ที่ต่างออกไป
- DevOps = วัฒนธรรมที่ทำให้ส่งงานได้เร็วและต่อเนื่อง
- SRE = วิศวกรรมที่ทำให้ระบบที่ส่งแล้วยังคงทำงานได้ดี
- ทั้งสองต้องการกัน — DevOps ที่ดีโดยไม่มี SRE มักจบลงด้วยระบบที่ deploy เร็วแต่ล่มบ่อย
- องค์กรที่ระบบมีผล mission-critical ควรกำหนด SLO ก่อนทุกอย่าง แล้วค่อย build process รอบ ๆ มัน
หากองค์กรของคุณกำลังเจอปัญหา incident บ่อย, on-call ไม่เป็นระบบ, หรือไม่มี SLO ที่วัดได้ — UNIXDEV มี Platinum Managed SRE tier ที่ให้ทีม SRE dedicated พร้อม NOC 24×7, error budget tracking และ runbook ที่ออกแบบตามระบบของคุณโดยเฉพาะ ดูรายละเอียดบริการได้ที่ DevOps & SRE Managed
ไม่ต้องรอหาคนเก่งที่ยังไม่มีในตลาด — ทีมงานพร้อมประเมิน SRE readiness ให้องค์กรของคุณ
ขอ Proposal และประเมิน SRE readiness ฟรี →
UNIXDEV Co., Ltd. — Craft code · Ship systems · Scale impact
ISO 9001:2015 · ISO/IEC 29110-4-1:2018 · Founded 2013 · unixdev.co.th
