JobRunr 9 เปิดทางดูงานค้าง ใบเสร็จช้าตรงไหนไม่ต้องเดา

JobRunr 9.0.0 เปิดให้ใช้ทั่วไปแล้ว แปลว่าทีมดูแลระบบมีรุ่นพร้อมใช้งานที่เพิ่มกราฟตามรอยงานหลังบ้าน ตามรายงาน InfoQ วันที่ 5 ตุลาคม 2026 ครับ ใบเสร็จที่ยังไม่ถึงอีเมลจึงมีทางให้ทีมตรวจว่า งานกำลังรอ หรือกำลังทำส่วนไหนอยู่ ด้วยมุมมองใหม่ที่ JobRunr ประกาศ

JobRunr คือเครื่องมือจัดการงานเบื้องหลังสำหรับโปรแกรมภาษา Java รุ่นนี้เพิ่ม Chart หรือกราฟในหน้าประวัติงาน ให้เห็นทั้งเวลารอและเวลาทำจริง (JobRunr) แต่การเห็นงานละเอียดขึ้นกับการป้องกันงานซ้ำเป็นคนละเรื่อง แล้วระบบจะรู้ได้อย่างไรว่าส่วนไหนทำเสร็จไปแล้ว?

สรุป 30 วินาที: เกิดอะไรขึ้น

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

กราฟนี้อยู่ทั้งใน OSS หรือรุ่นเปิดเผยซอร์สโค้ด และรุ่น Pro โดยไม่ต้องตั้งค่าเพิ่ม ส่วน Job Analytics ซึ่งสรุปภาพรวมงาน และปุ่มพักงานเป็นชุด เป็นฟีเจอร์ Pro (JobRunr) อย่าเอารายการฟีเจอร์ทั้งหมดมารวมแล้วเข้าใจว่ารุ่นฟรีได้ทุกอย่างครับ

อีกส่วนที่ทำให้กราฟมีประโยชน์คือ durable execution หรือการทำงานหลายขั้นที่จำความคืบหน้าได้ เครื่องมือ runStepOnce ใช้บันทึกส่วนที่เสร็จแล้ว เพื่อข้ามเมื่อเรียกงานซ้ำหลังล้มเหลว (คู่มือ durable executions) แต่คู่มือระบุว่าใช้ได้ตั้งแต่ JobRunr 8.0.0 แปลว่ารุ่นใหม่นี้เพิ่มการมองเห็นงานเดิม ไม่ได้เพิ่งคิดกลไกดังกล่าวขึ้นมา

ทำไมเรื่องนี้เกี่ยวกับคุณ

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

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

ความต่างนี้ช่วยให้คุยกับทีมดูแลระบบตรงประเด็นขึ้นครับ การเห็นอีเมลมาช้าอย่างเดียวไม่บอกว่าปัญหาอยู่ตรงไหน ขณะที่ Chart แสดงช่วงถูกนัดไว้ ช่วงอยู่ในคิว และช่วงประมวลผลของแต่ละครั้งที่ลองทำ (JobRunr) ทีมจึงมีหลักฐานให้ตรวจต่อ แทนการสรุปจากอาการหน้าจอเพียงอย่างเดียว

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

ทำงานยังไง

ตาม คู่มือ durable executions ระบบเก็บเครื่องหมายว่าขั้นตอนไหนเสร็จไว้ในฐานข้อมูลเดียวกับงาน ก่อนทำแต่ละขั้น runStepOnce จะตรวจเครื่องหมายนั้น ถ้าพบว่าทำเสร็จแล้วก็ข้าม ถ้ายังไม่เสร็จก็ลงมือ และบันทึกเมื่อสำเร็จ

ถ้าขั้นตอนโยน exception ซึ่งหมายถึงแจ้งความผิดพลาดให้โปรแกรมหยุดส่วนนี้ เครื่องหมายสำเร็จจะไม่ถูกเขียน งานจึงเข้าสถานะล้มเหลวและถูกลองใหม่ ขั้นที่ยังไม่เสร็จจะได้ทำอีกครั้ง ส่วนที่เสร็จและบันทึกแล้วจะถูกข้าม (คู่มือ durable executions) การลองใหม่แบบนี้เรียกว่า retry ครับ

เปรียบเหมือนหน้าติดตามพัสดุที่บอกทุกจุดแวะ ส่วนคนส่งของมีบันทึกว่าจุดไหนส่งแล้ว หากยางแบนระหว่างทาง เขากลับมาส่งจุดที่เหลือต่อ ไม่ต้องเริ่มเส้นทางจากคลังใหม่ทั้งหมด Chart คือหน้าตามรอย และ durable steps คือบันทึกจุดที่ทำเสร็จ ภาพนี้อธิบายกลไกตาม คู่มือ ไม่ใช่กรณีขนส่งจริงของบริษัทใด

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

แต่โค้ดที่อยู่นอกขั้นตอนยังรันใหม่ทุกครั้ง คู่มือจึงแนะนำให้ส่วนนี้ไม่มีการกระทำที่เปลี่ยนข้อมูลภายนอก หากการตัดสินใจขึ้นกับเวลาปัจจุบันหรือการสุ่ม ก็ควรบันทึกการตัดสินใจเป็นขั้นตอนด้วย (JobRunr) เรื่องนี้เกี่ยวกับการรักษาเส้นทางการทำงานให้เหมือนเดิมเมื่อกลับมาทำต่อ

ใน Chart ทีมเลือกดูภาพย่อหรือรายละเอียด และเลือกบีบช่วงรอยาวให้สั้นลงหรือแสดงเวลาตามจริงได้ ระยะเวลาและผลของขั้นตอนยังปรากฏใน Timeline เดิมด้วย (ประกาศ JobRunr) กราฟจึงช่วยอ่านประวัติ ไม่ได้เปลี่ยนงานที่ล้มเหลวให้สำเร็จเอง

จุดหักมุม: เปลี่ยนชื่อขั้นตอน งานเก่าอาจกลายเป็นงานใหม่

แต่ชื่อขั้นตอนมีผลกับความถูกต้องครับ คู่มือกำหนดให้ step ID หรือรหัสประจำขั้นตอน ต้องไม่ซ้ำกันในงานเดียวและคงเดิมข้ามการนำโปรแกรมรุ่นใหม่ขึ้นใช้ (JobRunr) มันเป็นตัวระบุที่ระบบใช้จำงาน ไม่ได้มีไว้ให้อ่านสวยอย่างเดียว

ถ้าเปลี่ยนรหัส ระบบจะมองว่าเป็นขั้นตอนใหม่ที่ไม่เคยทำ หากใช้รหัสเดียวกันกับคนละขั้น ขั้นหลังอาจถูกมองว่าเสร็จแล้วและถูกข้าม (คู่มือ durable executions) การเก็บเงินซ้ำหรือข้ามงานจึงไม่ได้ป้องกันด้วยการเพิ่ม runStepOnce แล้วจบ ทีมต้องรักษาตัวตนของแต่ละขั้นด้วย

เรื่องเงิน / ผลกระทบ

JobRunr ระบุ ว่า Chart ฟรีทั้งใน OSS และ Pro ส่วน Analytics ที่ดูปริมาณงาน การลองซ้ำ และเวลาประมวลผลตามชนิดงานหรือเครื่อง อยู่ใน Pro เช่นเดียวกับการพักงานเป็นชุดและการเริ่มงานทันทีผ่านฐานข้อมูล PostgreSQL แหล่งที่ให้มาไม่ได้ระบุราคา Pro เป็นเงินบาท จึงยังคำนวณค่าลิขสิทธิ์ให้ร้านไทยไม่ได้

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

ด้านการป้องกันงานซ้ำ คำว่า idempotent หมายถึงเรียกซ้ำแล้วไม่สร้างผลเพิ่มจากครั้งเดิม คู่มือแนะนำให้ขั้นที่ติดต่อบริการชำระเงินส่ง idempotency key หรือรหัสให้บริการนั้นรู้ว่าเป็นคำขอเดิม (JobRunr) กลไกจำขั้นตอนกับกลไกกันคำขอซ้ำต้องช่วยกัน โดยเฉพาะงานที่ค้างอยู่ตอนเครื่องหยุด

จุดนี้รุ่นฟรีกับ Pro ต่างกัน คู่มือ durable executions ระบุว่า Pro บันทึกสถานะลงฐานข้อมูลทันทีเมื่อขั้นเสร็จ ส่วน OSS บันทึกตามรอบปกติ หากเครื่องดับหลังขั้นเสร็จแต่ก่อนบันทึก OSS อาจทำขั้นนั้นซ้ำได้ แต่การ retry จากความผิดพลาดที่โปรแกรมแจ้งตามปกติกลับมาทำต่อได้ตรงขั้นในทั้งสองรุ่น

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

ข้อมูลที่ยังไม่ชัด และจุดที่แหล่งข่าวพูดไม่ตรงกัน

เสียงสนับสนุนจาก JobRunr คือกราฟช่วยเปิดให้เห็นภายในงาน และ InfoQ ยก Chart เป็นความเปลี่ยนแปลงเด่นของรุ่นนี้ ส่วนเสียงทักท้วงเรื่องความทนทานมาจากคู่มือของ JobRunr เอง ซึ่งย้ำว่าขั้นที่กำลังทำยังต้องกันผลซ้ำ และ OSS มีช่วงก่อนบันทึกที่ต้องระวัง (คู่มือ durable executions) ไม่มีบทวิจารณ์คัดค้านจากผู้ใช้จริงในชุดแหล่งข้อมูลนี้ จึงไม่ควรสร้างฝ่ายค้านขึ้นมา

มีจุดที่สรุปข่าวไม่ตรงกับเอกสารต้นทาง InfoQ เขียนเชื่อมคำเตือนงานที่แปลงเป็นข้อมูลจัดเก็บแล้วมีขนาดใหญ่ กับการ unwrap StepExecutionException หรือแกะข้อผิดพลาดของขั้นตอน แต่ release notes บน GitHub ลงรายการเพียงคำเตือนขนาดข้อมูล และ คู่มือย้ายรุ่น อธิบายคำเตือนบนหน้าควบคุมกับฝั่งระบบแยกกัน บทความนี้จึงไม่ยืนยันว่าขนาดใหญ่เป็นเหตุให้เกิดการแกะข้อผิดพลาดดังกล่าว

คู่มือบอกว่าหน้าควบคุมเตือนก่อนฝั่งระบบ โดยใช้เกณฑ์ขนาดต่ำกว่า แต่ไม่ได้ให้ค่าขนาดที่แน่นอนในข้อความที่มี (JobRunr) ยังตอบไม่ได้ว่าข้อมูลเท่าไรจะเตือนในระบบคุณ และไม่มีผลทดสอบจากทีมไทยในชุดแหล่งข่าว ผมยังไม่ได้ทดลองรุ่นนี้ จึงไม่รับรองว่ากราฟจะลดเวลาตามปัญหาได้เท่าไร

วันที่ก็ต้องอ่านอย่างระวัง ข้อความประกาศบอกว่ารองรับ Quarkus รุ่น LTS ใหม่ตั้งแต่วันแรก ส่วนคู่มือบอกว่า LTS ออกช่วงปลายกันยายน (ประกาศ, คู่มือ) บทความนี้ยึดวันที่รายงานของ InfoQ เป็นหลักในการเล่าข่าว ไม่ใช้วันที่ metadata ของหน้าที่ไม่สอดคล้องกับเนื้อหาเป็นวันเปิดตัว

อีกข้อที่ต้องรู้ก่อนเลือกติดตั้งคือ GitHub releases มี JobRunr 9.0.1 อยู่แล้ว แปลว่ามีรุ่นแก้ไขต่อจากรุ่นหลักที่บทความนี้อธิบาย โดยระบุการแก้ชื่อโมดูลอัตโนมัติของชุดเชื่อม Spring Boot ซึ่งเป็นโครงช่วยสร้างแอป Java และกล่าวถึงการแก้งานชุดใน Pro ด้วย ไม่มีเหตุให้เรียกรุ่นหลักในข่าวนี้ว่าเป็นรุ่นล่าสุดของทุกแพ็กเกจ

แล้วเราควรทำอะไร

คนทั่วไปและเจ้าของร้านที่ไม่ได้ดูแลโค้ด

1. เวลาตามใบเสร็จหรือการยืนยันคำสั่งซื้อ ให้เก็บเลขรายการไว้ถามทีมดูแล และถามว่างานค้างที่การรอหรือการทำจริง หากระบบใช้ JobRunr ทีมสามารถตรวจช่วงเหล่านี้จาก Chart ได้ (JobRunr)
2. ถามผู้พัฒนาว่างานเก็บเงินและส่งอีเมลป้องกันผลซ้ำอย่างไร อย่าตัดสินจากคำว่า durable อย่างเดียว เพราะคู่มือยังแนะนำให้ทุกขั้นปลอดภัยเมื่อเรียกซ้ำ (JobRunr)

ทีม IT และผู้รับผิดชอบการอัปเกรด

1. อ่าน migration guide ก่อนเปลี่ยนเลขรุ่น และเช็กรายการ API ซึ่งเป็นจุดเรียกใช้เครื่องมือจากโค้ด ที่เลิกใช้แล้วถูกถอดออก เช่น useMicroMeter ต้องเปลี่ยนเป็น useMetrics ส่วน withDetails ต้องใช้ withJobLambda
2. หากใช้ Micronaut ซึ่งเป็นโครงช่วยสร้างแอป Java ให้ตรวจการย้ายไป Micronaut 5 ก่อน แปลว่าต้องปรับตัวแอปตามข้อกำหนดนี้ด้วย (คู่มือย้ายรุ่น) ส่วน Quarkus รองรับสาย 3.40 LTS แปลว่าใช้กับสายดูแลระยะยาวที่เอกสารระบุได้ โดยไม่ต้องรอส่วนเชื่อมแยก
3. ทดลองใน staging หรือระบบซ้อมก่อนขึ้นระบบจริง วัดเวลาปรับฐานข้อมูล และจำลองงานล้มเหลวเพื่อดูว่ากลับมาทำตรงขั้นไหน คู่มืออนุญาตให้เครื่องรุ่นเดิมกับรุ่นใหม่ใช้ฐานข้อมูลร่วมกันได้ แต่ Analytics ทำงานกับงานที่ประมวลผลบนรุ่นใหม่เท่านั้น (คู่มือย้ายรุ่น)
4. ทีม Pro ที่ตั้งค่าการส่งสัญญาณระหว่างเครื่องเอง ต้องตรวจการเปลี่ยนไปใช้ EventTransport ตามคู่มือ เพราะค่าตั้ง multicast เดิมถูกถอดแล้ว ทีมที่สร้างส่วนประกอบภายในเองต้องอ่านรายการเปลี่ยนจุดสร้างออบเจ็กต์ด้วย (JobRunr)

นักพัฒนาที่ออกแบบงานหลายขั้น

1. กำหนด step ID ให้ไม่ซ้ำและคงเดิมข้ามการนำรุ่นใหม่ขึ้นใช้ แยกการกระทำแต่ละขั้นให้ชัด พร้อมออกแบบการติดต่อระบบภายนอกให้เรียกซ้ำได้โดยไม่เกิดผลเพิ่ม (คู่มือ durable executions)
2. ทดสอบทั้งความผิดพลาดที่โปรแกรมแจ้งและการหยุดเครื่องกะทันหัน เพราะข้อจำกัดการบันทึกสถานะของ OSS กับ Pro ต่างกัน ตรวจผลปลายทางจริง เช่น รายการชำระเงิน ไม่ดูเพียงสถานะว่าสำเร็จ (คู่มือ durable executions)
3. เปิด Chart ของงานที่ช้า ตรวจว่ารอนานหรือขั้นไหนทำจริงนาน แล้วค่อยเลือกแก้จุดนั้น หากมีคำเตือนขนาดข้อมูลของงาน ให้ตรวจสิ่งที่ส่งเข้าไปด้วย (ประกาศ, คู่มือย้ายรุ่น)

ผมมองว่า…

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

ผมมองว่า ทีมเล็กควรเริ่มจากงานที่เกี่ยวกับเงินหรือความเชื่อมั่นก่อน แล้วใช้ Chart ที่มีในรุ่นฟรีตรวจพฤติกรรมจริง (JobRunr) การตัดสินใจซื้อ Pro ควรมาจากความต้องการ Analytics การพักงานชุด หรือรูปแบบบันทึกสถานะ ไม่ควรซื้อเพราะเข้าใจว่าดูกราฟต้องจ่ายเงิน

ปิดท้าย: สิ่งที่ต้องจับตา

ความน่าเชื่อถือของงานหลังบ้านวัดจากสิ่งที่เกิดกับรายการของลูกค้า และหลักฐานที่ทีมใช้ตามรอยได้ครับ จับตารุ่นแก้ไขใน GitHub releases พร้อมตรวจว่าข้อแก้ไขเกี่ยวกับชุดเชื่อมที่ทีมใช้อยู่หรือไม่ อีกเรื่องคือแผนรองรับ Java 8 แปลว่าทีมที่ยังอยู่บน Java สายเก่านี้ต้องวางแผน เพราะคู่มือระบุว่ารุ่นหลักนี้เป็นสายสุดท้ายของ OSS ที่รองรับ (JobRunr)

ในงานของคุณ ระหว่างใบเสร็จอีเมลกับไฟล์ที่ต้องส่งตอนกลางคืน งานไหนอยากให้ทีมตามรอยได้ชัดเจนก่อน?

Recap

• เกิดอะไรขึ้น: JobRunr เพิ่ม Chart แสดงเวลารอ เวลาทำ และขั้นตอนในประวัติงาน ทั้ง OSS และ Pro
• เลขรุ่นที่ต้องจำ: JobRunr 9.0.0 คือรุ่นหลักของข่าวนี้ แปลว่าอย่าสับสนกับรุ่นแก้ไขที่มีตามมา
• กลไกสำคัญ: runStepOnce ข้ามขั้นที่สำเร็จและบันทึกแล้ว แต่ step ID ต้องคงเดิมและไม่ซ้ำ
• ใครทักท้วง: คู่มือ JobRunr เองเตือนเรื่องเครื่องดับและผลซ้ำ ส่วน InfoQ เชื่อมคำเตือนขนาดงานกับข้อผิดพลาดต่างจากรายละเอียดต้นทาง
• ยังไม่รู้: ราคา Pro เป็นเงินบาท เกณฑ์ขนาดที่เริ่มเตือน และเวลาปรับฐานข้อมูลจริงของทีมคุณ
• กระทบคุณ: ใช้หลักฐานแยกงานรอออกจากงานช้า และถามเรื่องป้องกันผลซ้ำในรายการเงิน
• จับตา: รุ่นแก้ไข ความเข้ากันได้ของระบบ และแผนย้ายจาก Java สายเก่าก่อนอัปเกรดต่อ
• แหล่งอ้างอิง: 1 — ประกาศ JobRunr · 2 — คู่มือย้ายรุ่น · 3 — InfoQ · 4 — GitHub releases · 5 — คู่มือ durable executions