ระบบอัตโนมัติหยุดกลางทาง จะตรวจพบและทำงานต่อได้อย่างไร

ระบบอัตโนมัติที่พร้อมใช้ในงานจริงจึงควรบอกได้ทั้งงานที่สำเร็จ งานที่ล้มเหลว และงานที่ยังไม่ทราบผล พร้อมมีทางให้คนรับช่วงต่อ ไม่จำเป็นต้องให้ทุกความผิด⁠พลาดแก้ตัวเองได้ แต่ต้องไม่ปล่อยให้งานหายไปเงียบ ๆ

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

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

แยกวันที่ไม่มีงานจริงออกจากวันที่ข้อมูลไม่เข้าระบบ ใช้หลักฐานจากต้นทางหรือการ⁠ตรวจรอบล่าสุดมาประกอบ ไม่ตั้งเงื่อนไขว่าไม่มี​อ⁠อ⁠เ⁠ด⁠อ⁠ร์​เท่ากับระบบเสียทุก⁠ครั้ง เพราะจะสร้างการแจ้งเตือนที่คนต้องคอยปิดทิ้ง

เอกสาร AWS Step Functions เรื่องการ⁠จัดการข้อ⁠ผิด⁠พลาด แยกกลไกลองใหม่กับการส่งไปเส้นทางจัดการเมื่อเกิดปัญหา และกำหนดจำนวนครั้งกับช่วงห่างได้ แนวทางนี้ช่วยออก⁠แบบระบบที่ควบคุมการลองใหม่ แต่ไม่แทนการ⁠ตรวจว่าคำสั่งทางธุรกิจเดิมถูกทำไปแล้วหรือยัง

กำหนดจำนวนครั้งและช่วงรอให้เข้ากับข้อจำกัดของระบบที่เชื่อม หากทุกงานลองใหม่พร้อมกันทันทีหลังปลายทางกลับมา อาจทำให้ระบบนั้นรับภาระมากอีกครั้ง ควรกระจายการลองใหม่และให้คนเห็นรายการที่ยังรออยู่

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

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

ขั้น⁠ตอนที่สำเร็จแล้วควรมีหลักฐาน เช่น เลขเอกสารปลายทางหรือเวลายืนยัน การรู้ว่า “ผ่านขั้นที่⁠สอง” โดยไม่มีข้อมูลอ้างอิงอาจไม่พอเมื่อทีมต้องตรวจผลภายหลัง สำหรับรายการที่ยกเลิกกลับได้ยาก ให้กำหนดคนตัด⁠สิน⁠ใจก่อนทำการชดเชยหรือย้อนรายการ

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

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

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

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

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

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

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