GCP Pub Sub Service Level Objective SLO — คู่มือฉบับสมบูรณ์ 2026 | SiamCafe Blog

GCP Pub Sub คืออะไร และทำไม SLO ถึงสำคัญกับระบบข้อความบนคลาวด์

GCP Pub/Sub คือบริการส่งข้อความแบบ Publish/Subscribe บนแพลตฟอร์ม Google Cloud Platform ที่ช่วยให้ระบบต่าง ๆ

สื่อสารกันผ่านช่องทางกลางโดยไม่ต้องรู้จักกันโดยตรง ฝั่งผู้ส่งแค่ยิงข้อความเข้าไปในหัวข้อที่กำหนดไว้ ฝั่งผู้รับก็ดึงข้อความจากการสมัครรับข้อมูลที่ผูกกับหัวข้อนั้น ทั้งสองฝั่งไม่จำเป็นต้องออนไลน์พร้อมกัน ไม่ต้องรู้ที่อยู่ของกันและกัน และไม่ต้องรอคอยการตอบกลับ ทำให้สถาปัตยกรรมทั้งหมดยืดหยุ่น ขยายตัวง่าย และทนต่อความผิดพลาดของแต่ละส่วนได้ดีกว่าการต่อกันแบบตรง ๆ ทีละจุด ส่วน Service Level Objective หรือ SLO คือเป้าหมายระดับบริการที่ทีมพัฒนาตั้งไว้ว่า บริการควรทำงานได้ตามปกติมากแค่ไหน เช่น ต้องส่งข้อความสำเร็จอย่างน้อยร้อยละ 99.9 ภายในหนึ่งเดือน เมื่อนำสองสิ่งนี้มารวมกัน จะเป็นการกำหนดกรอบความน่าเชื่อถือของระบบข้อความอย่างเป็นรูปธรรม วัดผลได้จริง และแจ้งเตือนทีมได้ก่อนที่ผู้ใช้จะรู้สึกถึงปัญหา

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

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

ในปี 2026 นี้ ระบบขององค์กรไทยเริ่มพึ่งพาสถาปัตยกรรมแบบกระจายศูนย์กันมากขึ้น บริการหลายตัวต่อกันเป็นสายโซ่ จุดเชื่อมต่อที่สำคัญที่สุดคือช่องทางข้อความพอดี การมี SLO ที่ชัดเจนกับ GCP Pub/Sub จึงไม่ใช่เรื่องของบริษัทใหญ่ต่างประเทศอย่างเดียว แต่เป็นเครื่องมือที่ทีมไอทีไทยสามารถนำไปใช้ได้จริง ตั้งแต่สตาร์ทอัพเล็ก ๆ ที่มีคนดูแลสองสามคน จนถึงธนาคารที่มีทีมปฏิบัติการแยกชัดเจน ข้อดีคือเครื่องมือวัดผลมาพร้อมกับแพลตฟอร์มอยู่แล้ว ไม่ต้องลงทุนซื้อของเพิ่ม แค่ออกแบบให้ถูกตั้งแต่ต้น ผมจะพาไล่ตั้งแต่แนวคิดพื้นฐาน ตัวชี้วัดสำคัญ วิธีตั้งค่าจริง ไปจนถึงแนวปฏิบัติที่ผมใช้ในระบบงานจริงพร้อมเคสที่เกิดขึ้นต่อหน้าผมเอง

ก่อนจะเขียน SLO ได้ ต้องเข้าใจสามคำที่มักสับสนกัน ได้แก่ SLI, SLO และ Error Budget SLI หรือ Service Level Indicator

คือตัวชี้วัดดิบที่วัดจากข้อมูลจริง เช่น สัดส่วนข้อความที่ส่งสำเร็จต่อข้อความทั้งหมด SLO คือเป้าหมายที่ตั้งไว้กับ SLI นั้น เช่น ต้องไม่ต่ำกว่าร้อยละ 99.9 ส่วน Error Budget คือปริมาณความผิดพลาดที่ยอมรับได้ ซึ่งคำนวณจากช่องว่างระหว่างร้อยเปอร์เซ็นต์กับ SLO ถ้า SLO เป็นร้อยเปอร์เซ็นต์ 99.9 ก็มีงบความผิดพลาดอยู่ 0.1 เปอร์เซ็นต์ในหนึ่งช่วงเวลา ฟังดูเหมือนเรื่องเดียวกันแต่จริง ๆ แล้วแต่ละคำทำหน้าที่ต่างกัน SLI คือสิ่งที่วัด SLO คือเป้าที่ตั้งกับสิ่งที่วัด และ Error Budget คือพื้นที่ปลอดภัยที่ทีมใช้ทดลองสิ่งใหม่ได้

ก่อนจะเขียน SLO ได้ ต้องเข้าใจสามคำที่มักสับสนกัน ได้แก่ SLI, SLO และ Error Budget SLI หรือ Service Level Indicator คือตัวชี้วัดดิบที่วัดจากข้อมูลจริง เช่น สัดส่วนข้อความที่ส่งสำเร็จต่อข้อความทั้งหมด SLO คือเป้าหมายที่ตั้งไว้กับ SLI นั้น เช่น ต้องไม่ต่ำกว่าร้อยละ 99.9 ส่วน Error Budget คือปริมาณความผิดพลาดที่ยอมรับได้ ซึ่งคำนวณจากช่องว่างระหว่างร้อยเปอร์เซ็นต์กับ SLO ถ้า SLO เป็นร้อยเปอร์เซ็นต์ 99.9 ก็มีงบความผิดพลาดอยู่ 0.1 เปอร์เซ็นต์ในหนึ่งช่วงเวลา ฟังดูเหมือนเรื่องเดียวกันแต่จริง ๆ แล้วแต่ละคำทำหน้าที่ต่างกัน SLI คือสิ่งที่วัด SLO คือเป้าที่ตั้งกับสิ่งที่วัด และ Error Budget คือพื้นที่ปลอดภัยที่ทีมใช้ทดลองสิ่งใหม่ได้

ผมชอบเปรียบเทียบกับการเทรดให้ลูกศิษย์ฟัง เพราะเข้าใจง่ายที่สุด SLI เหมือนกราฟราคาที่เคลื่อนไหวอยู่ตลอดเวลา SLO เหมือนเป้าหมายกำไรรายเดือนที่เราตั้งไว้ และ Error Budget เหมือนวงเงินขาดทุนสูงสุดที่ยอมรับได้ก่อนต้องหยุดเทรดไปทบทวนกลยุทธ์ ถ้างบขาดทุนยังเหลือ เรายังลองไอเดียใหม่ได้ ถ้างบหมด ก็ต้องหยุดและโฟกัสความเสถียรภาพอย่างเดียว แนวคิดเดียวกันนี้ใช้กับระบบไอทีได้ตรงดิบ เมื่อทีมยังมีงบความผิดพลาดเหลืออยู่ ก็ปล่อยฟีเจอร์ใหม่ได้อย่างมั่นใจ แต่พองบใกล้หมด ทุกการเปลี่ยนแปลงต้องช้าลงและผ่านการตรวจสอบที่รัดกุมขึ้น

Google เองก็เผยแพร่ SLO ของบริการ Pub/Sub ไว้สาธารณะ ทำให้เรามีจุดอ้างอิงที่ดีในการกำหนดเป้าหมายของระบบเราเอง โดยทั่วไปบริการ Pub/Sub ให้ความพร้อมใช้งานระดับภูมิภาคสูงมาก และค่าใช้จ่ายเกิดขึ้นเมื่อใช้งานผ่านตัวช่วยพิเศษบางตัวเท่านั้น สิ่งที่ต้องเข้าใจคือ คำมั่นของผู้ให้บริการคลาวด์ไม่เท่ากับประสบการณ์จริงของผู้ใช้ปลายทาง เพราะระหว่างทางยังมีงานประมวลผลของเราเอง ฐานข้อมูลของเราเอง และบริการภายนอกอีกชั้น ทำให้การวัดจากปลายสายทั้งสองด้านสำคัญกว่าการเชื่อสไลด์การตลาดเพียงอย่างเดียว

ตารางด้านล่างสรุปตัวชี้วัดหลักที่ผมใช้จริงในระบบของผม

การตั้ง SLO บน GCP ทำได้ผ่านหน้า Google Cloud Console ในส่วนของ Cloud Monitoring หรือผ่านคำสั่ง gcloud ก็ได้

ผมจะอธิบายแบบที่ทำได้จริงจากประสบการณ์ตรง ให้สมมติว่าเรามีหัวข้อชื่อ `trade-signals` และรับข้อความผ่านการสมัครรับข้อมูลชื่อ `signal-dispatcher` ซึ่งเป็นโครงสร้างหลักของระบบแจ้งเตือนสัญญาณของผม ก่อนเริ่มให้ตรวจว่าโปรเจกต์เปิดใช้ Cloud Monitoring API แล้ว และบัญชีที่ใช้มีสิทธิ์ระดับผู้แก้ไขในโปรเจกต์ ไม่งั้นจะติดตรงหน้าสิทธิ์การเข้าถึงโดยไม่จำเป็น

วิธีตั้งค่า SLO จริงบน Google Cloud Monitoring ทีละขั้นตอน

การตั้ง SLO บน GCP ทำได้ผ่านหน้า Google Cloud Console ในส่วนของ Cloud Monitoring หรือผ่านคำสั่ง gcloud ก็ได้ ผมจะอธิบายแบบที่ทำได้จริงจากประสบการณ์ตรง ให้สมมติว่าเรามีหัวข้อชื่อ `trade-signals` และรับข้อความผ่านการสมัครรับข้อมูลชื่อ `signal-dispatcher` ซึ่งเป็นโครงสร้างหลักของระบบแจ้งเตือนสัญญาณของผม ก่อนเริ่มให้ตรวจว่าโปรเจกต์เปิดใช้ Cloud Monitoring API แล้ว และบัญชีที่ใช้มีสิทธิ์ระดับผู้แก้ไขในโปรเจกต์ ไม่งั้นจะติดตรงหน้าสิทธิ์การเข้าถึงโดยไม่จำเป็น

ขั้นแรกให้ไปที่เมนู Monitoring แล้วเลือก SLO จากนั้นกด Create SLO ระบบจะให้เลือกบริการที่ต้องการวัด ซึ่ง Pub/Sub จะแสดงเป็นรายการที่เลือกได้เลย จากนั้นให้เลือกประเภทของ SLI มีสองแบบหลักคือ Request-Based ซึ่งนับเหตุการณ์ว่าสำเร็จกี่ครั้งจากทั้งหมด กับ Window-Based ซึ่งดูว่าแต่ละช่วงเวลา เช่น หนึ่งนาที ประสบความสำเร็จหรือไม่ สำหรับการส่งข้อความผมแนะนำแบบ Request-Based เพราะตรงกับธรรมชาติของงาน ที่แต่ละข้อความคือเหตุการณ์อิสระ แต่ถ้าอยากวัดความพร้อมใช้งานของช่องทางทั้งหมดแบบเข้มงวด แบบ Window-Based จะเหมาะกว่า เพราะมันจับความเสียหายแบบต่อเนื่องได้ แม้จำนวนคำขอในช่วงนั้นจะน้อยก็ตาม

ถัดมาเป็นขั้นตอนที่คนมักพลาด คือการเลือกตัวชี้วัดต้นทาง ให้เลือกเมตริกของ Pub/Sub เช่น `topic/sendrequestcount` แล้วกำหนดว่าอะไรคือ "เหตุการณ์ที่ดี" สำหรับการส่งข้อความ เหตุการณ์ที่ดีคือคำขอที่ได้รับการยืนยันสำเร็จ ส่วน "เหตุการณ์ที่ไม่ดี" คือคำขอที่ตอบกลับด้วยรหัสข้อผิดพลาดหรือหมดเวลา กำหนดค่านี้ผ่านตัวกรองของเมตริกโดยใช้ฟิลด์ `response_code` เป็นตัวแยก จากนั้นเลือกช่วงเวลาวัด เช่น 30 วัน และเป้าหมาย เช่น 99.9% สำหรับตัวชี้วัดด้านเวลาหน่วง ให้เลือกเมตริกแบบการกระจายค่าแทน แล้วกำหนดขอบเขตว่าถือว่าดีคือไม่เกินกี่มิลลิวินาที ระบบจะคำนวณสัดส่วนของคำขอที่อยู่ใต้เกณฑ์ให้อัตโนมัติ

ถ้าใครถนัดสั่งงานด้วยบรรทัดคำสั่ง สามารถใช้ gcloud ได้แบบนี้

gcloud monitoring create-slo \ --project=my-project-id \ --display-name="Trade Signals Publish Success" \ --service=pubsub.googleapis.com \ --slo-target=0.999 \ --slo-rollout-period=2592000

SLO ที่ไม่มีนโยบายประกอบ จะกลายเป็นเพียงกราฟสวยในแดชบอร์ดที่ไม่มีใครอ่าน ผมเห็นหลายองค์กรทำแบบนี้ ทีมเปิดแดชบอร์ดทุกเช้า เห็นเปอร์เซ็นต์สีเขียว

ก็ผ่านไป แต่ไม่มีกติกาว่าจะทำอะไรเมื่องบความผิดพลาดหมด ผมจึงยืนยันว่าต้องมี Error Budget Policy เขียนไว้เป็นลายลักษณ์อักษร โดยระบุชัดว่าเมื่องบเหลือเท่าไร ต้องทำอะไร ใครเป็นคนตัดสินใจ และใครรับผิดชอบต่อ นโยบายไม่ต้องยาวเป็นหนังสือ หนึ่งหน้าก็พอ แต่ต้องชัดจนคนใหม่ในทีมอ่านจบแล้วรู้ทันทีว่าตนเองต้องทำอะไรเมื่อสถานการณ์เกิดขึ้น

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

Error Budget Policy — ทำให้ SLO ไม่กลายเป็นตัวเลขบนกระดาษ

SLO ที่ไม่มีนโยบายประกอบ จะกลายเป็นเพียงกราฟสวยในแดชบอร์ดที่ไม่มีใครอ่าน ผมเห็นหลายองค์กรทำแบบนี้ ทีมเปิดแดชบอร์ดทุกเช้า เห็นเปอร์เซ็นต์สีเขียว ก็ผ่านไป แต่ไม่มีกติกาว่าจะทำอะไรเมื่องบความผิดพลาดหมด ผมจึงยืนยันว่าต้องมี Error Budget Policy เขียนไว้เป็นลายลักษณ์อักษร โดยระบุชัดว่าเมื่องบเหลือเท่าไร ต้องทำอะไร ใครเป็นคนตัดสินใจ และใครรับผิดชอบต่อ นโยบายไม่ต้องยาวเป็นหนังสือ หนึ่งหน้าก็พอ แต่ต้องชัดจนคนใหม่ในทีมอ่านจบแล้วรู้ทันทีว่าตนเองต้องทำอะไรเมื่อสถานการณ์เกิดขึ้น

ตัวอย่างนโยบายที่ผมใช้กับทีมจริง ๆ เขียนแบบนี้ เมื่องบความผิดพลาดถูกใช้เกินร้อยละ 25 ในเจ็ดวัน ทีมต้องเริ่มทบทวนการเปลี่ยนแปลงล่าสุดทั้งหมดและงดปล่อยฟีเจอร์ที่ไม่เร่งด่วน เมื่อเกินร้อยละ 50 ต้องจัดประชุมฉุกเฉินภายใน 24 ชั่

คำถามที่พบบ่อย

GCP Pub/Sub คืออะไร และช่วยให้ระบบต่าง ๆ สื่อสารกันอย่างไร?

GCP Pub/Sub คือบริการส่งข้อความแบบ Publish/Subscribe บนแพลตฟอร์ม Google Cloud Platform ที่ช่วยให้ระบบต่าง ๆ สื่อสารกันผ่านช่องทางกลางโดยไม่ต้องรู้จักกันโดยตรง ฝั่งผู้ส่งเพียงยิงข้อความเข้าไปในหัวข้อที่กำหนดไว้ ส่วนฝั่งผู้รับจะดึงข้อความจากการสมัครรับข้อมูลที่ผูกกับหัวข้อนั้น จุดเด่นสำคัญคือทั้งสองฝั่งไม่จำเป็นต้องออนไลน์พร้อมกัน ไม่ต้องรู้ที่อยู่ของกันและกัน และไม่ต้องรอคอยการตอบกลับ ทำให้สถาปัตยกรรมทั้งหมดยืดหยุ่น ขยายตัวง่าย และทนต่อความผิดพลาดของแต่ละส่วนได้ดีกว่าการเชื่อมต่อกันแบบตรง ๆ ทีละจุด ในปี 2026 ที่ระบบขององค์กรไทยพึ่งพาสถาปัตยกรรมแบบกระจายศูนย์มากขึ้น จุดเชื่อมต่อที่สำคัญที่สุดคือช่องทางข้อความพอดี จึงควรออกแบบและติดตามบริการส่วนนี้อย่างจริงจังตั้งแต่ต้น

SLO สำคัญกับระบบข้อความบนคลาวด์อย่างไร ทำไมต้องวัดจากมุมมองผู้ใช้?

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

SLI, SLO และ Error Budget ต่างกันอย่างไร ควรแยกให้ออกก่อนลงมืออย่างไร?

สามคำนี้มักถูกสับสนกันแต่ทำหน้าที่ต่างกันชัดเจน SLI หรือ Service Level Indicator คือตัวชี้วัดดิบที่วัดจากข้อมูลจริง เช่น สัดส่วนข้อความที่ส่งสำเร็จต่อข้อความทั้งหมด SLO คือเป้าหมายที่ตั้งไว้กับ SLI นั้น เช่น ต้องไม่ต่ำกว่าร้อยละ 99.9 ส่วน Error Budget คือปริมาณความผิดพลาดที่ยอมรับได้ คำนวณจากช่องว่างระหว่างร้อยเปอร์เซ็นต์กับ SLO ถ้า SLO เป็น 99.9 ก็มีงบความผิดพลาด 0.1 เปอร์เซ็นต์ในหนึ่งช่วงเวลา ง่าย ๆ คือ SLI คือสิ่งที่วัด SLO คือเป้าที่ตั้งกับสิ่งที่วัด และ Error Budget คือพื้นที่ปลอดภัยที่ทีมใช้ทดลองสิ่งใหม่ได้ เมื่องบความผิดพลาดยังเหลืออยู่ ทีมปล่อยฟีเจอร์ใหม่ได้อย่างมั่นใจ แต่พองบใกล้หมด ทุกการเปลี่ยนแปลงต้องช้าลงและโฟกัสความเสถียรภาพอย่างเดียว

ทีมไอทีไทยหรือสตาร์ทอัพขนาดเล็กควรเริ่มใช้ SLO กับ GCP Pub/Sub อย่างไร?

การมี SLO ที่ชัดเจนกับ GCP Pub/Sub ไม่ใช่เรื่องของบริษัทใหญ่ต่างประเทศอย่างเดียว แต่เป็นเครื่องมือที่ทีมไอทีไทยนำไปใช้ได้จริง ตั้งแต่ส

แนะนำเพิ่มเติม

🎯 เปิดบัญชี XM Forex → สมัคร

📱 แอป iCafeFX → ดาวน์โหลด

📊 สัญญาณฟรี → รับสัญญาณ

📚 คู่มือเทรด → SiamCafeBook

🤝 สมัคร Partner XM → pipaffiliates.com/c?c=72816&l=th&p=6