แชร์ผ่าน

คำแนะนำสำหรับการจัดการข้อบกพร่องชั่วคราว

  • บทความ

ใช้กับคำแนะนำรายการตรวจสอบความน่าเชื่อถือที่ได้รับการออกแบบอย่างดี: Power Platform

RE:05 เสริมสร้างความยืดหยุ่นให้กับปริมาณงานของคุณโดยการใช้การจัดการข้อผิดพลาดและการจัดการข้อผิดพลาดชั่วคราว สร้างความสามารถในโซลูชันเพื่อจัดการกับความล้มเหลวของส่วนประกอบและข้อผิดพลาดชั่วคราว

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

กลยุทธ์การออกแบบที่สำคัญ

ข้อผิดพลาดชั่วคราวสามารถเกิดขึ้นได้ในทุกสภาพแวดล้อม บนแพลตฟอร์มหรือระบบปฏิบัติการ และในแอปพลิเคชันทุกประเภท

ความท้าทาย

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

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

  • แอปพลิเคชันจะต้องสามารถลองดำเนินการใหม่ได้ หากพบว่าข้อบกพร่องน่าจะเกิดขึ้นชั่วคราว

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

แนวทางทั่วไป

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

ตรวจสอบว่ามีกลไกการลองอีกครั้งในตัวหรือไม่

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

คุณควรใช้กลไกการลองอีกครั้งในตัวเมื่อพร้อมใช้งาน เว้นแต่คุณจะมีข้อกำหนดเฉพาะและเข้าใจดีที่ทำให้พฤติกรรมการลองอีกครั้งที่แตกต่างกันมีความเหมาะสมมากขึ้น

พิจารณาว่าการดำเนินการนี้เหมาะสมสำหรับการลองอีกครั้งหรือไม่

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

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

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

กำหนดจำนวนและช่วงเวลาการลองอีกครั้งที่เหมาะสม

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

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

โปรดทราบว่าการกำหนดช่วงเวลาที่เหมาะสมระหว่างการลองอีกครั้งเป็นส่วนที่ยากที่สุดในการออกแบบกลยุทธ์ที่ประสบความสำเร็จ กลยุทธ์ทั่วไปใช้ช่วงเวลาการลองอีกครั้งประเภทต่อไปนี้:

  • ช่วงเลขชี้กำลัง แอปพลิเคชันรอสักครู่ก่อนที่จะลองอีกครั้งครั้งแรก จากนั้นจะเพิ่มเวลาแบบทวีคูณระหว่างการลองครั้งต่อไปแต่ละครั้ง ตัวอย่างเช่น อาจลองดำเนินการอีกครั้งหลังจากผ่านไป 3 วินาที, 12 วินาที, 30 วินาที และอื่นๆ

  • ระยะเวลาคงที่ แอปพลิเคชันจะรอเป็นระยะเวลาเท่ากันระหว่างแต่ละความพยายาม

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

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

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

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

พิจารณาการหมดเวลาของการดำเนินการเมื่อคุณเลือกช่วงเวลาการลองใหม่เพื่อหลีกเลี่ยงการเรียกใช้ความพยายามครั้งถัดไปทันที (เช่น หากช่วงการหมดเวลาคล้ายกับช่วงการลองอีกครั้ง)

ใช้ประเภทของข้อผิดพลาดหรือรหัสข้อผิดพลาดและข้อความที่ส่งคืนจากบริการเพื่อเพิ่มประสิทธิภาพจำนวนการลองอีกครั้งและช่วงเวลาระหว่างข้อผิดพลาดเหล่านั้น ตัวอย่างเช่น ข้อยกเว้นหรือรหัสข้อผิดพลาดบางอย่าง (เช่น รหัส HTTP 503 บริการไม่พร้อมใช้งาน โดยมีส่วนหัว Retry-After ในการตอบกลับ) อาจระบุระยะเวลาที่ข้อผิดพลาดอาจคงอยู่ หรือบริการล้มเหลวและจะไม่ตอบสนองใดๆ ความพยายามครั้งต่อไป

หลีกเลี่ยงการต่อต้านรูปแบบ

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

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

อย่าทำการลองอีกครั้งทันทีมากกว่าหนึ่งครั้ง

หลีกเลี่ยงการใช้ช่วงเวลาการลองใหม่ที่กำหนดไว้เมื่อคุณเข้าถึงบริการและทรัพยากรบน Azure โดยเฉพาะอย่างยิ่งเมื่อคุณมีความพยายามในการลองอีกครั้งหลายครั้ง แนวทางที่ดีที่สุดในสถานการณ์นี้คือกลยุทธ์ช่วงเวลาแบบทวีคูณ

ทดสอบกลยุทธ์การลองอีกครั้งและการนำไปใช้งานของคุณ

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

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

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

  • สำหรับบริการแบบกำหนดเองที่คุณสร้างและปรับใช้ บังคับให้เกิดข้อผิดพลาดชั่วคราวโดยการปิดใช้งานชั่วคราวหรือให้บริการมากเกินไป (อย่าพยายามโอเวอร์โหลดทรัพยากรที่ใช้ร่วมกันหรือบริการที่ใช้ร่วมกันใน Azure)

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

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

จัดการการกำหนดค่านโยบายการลองอีกครั้ง

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

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

บันทึกและติดตามข้อผิดพลาดชั่วคราวและไม่ชั่วคราว

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

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

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

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

จัดการการดำเนินงานที่ล้มเหลวอย่างต่อเนื่อง

พิจารณาวิธีจัดการกับการดำเนินการที่ยังคงล้มเหลวทุกครั้งที่พยายาม สถานการณ์เช่นนี้หลีกเลี่ยงไม่ได้

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

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

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

ข้อควรพิจารณาอื่นๆ

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

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

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

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

การอำนวยความสะดวก Power Platform

ส่วนต่อไปนี้จะอธิบายกลไกที่คุณสามารถใช้เพื่อจัดการข้อผิดพลาดชั่วคราว

Power Automate

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

โฟลว์ชั่วคราวบางอย่างอาจเกิดจากปริมาณการประมวลผลและขีดจำกัดคำขอ เรียนรู้เกี่ยวกับ ขีดจำกัดของโฟลว์อัตโนมัติ กำหนดเวลา และทันที และ ขีดจำกัดคำขอและการจัดสรร

กำหนดค่าการจัดการข้อผิดพลาดและข้อยกเว้นในโฟลว์คลาวด์ โดยใช้ขอบเขตและการตั้งค่าการรันหลัง

Power Apps

Power Apps แอปพื้นที่ทำงานให้ความสามารถในการ ตรวจสอบสถานะการเชื่อมต่อ ช่วยให้ทำงานแตกต่างออกไปได้หากแอปออฟไลน์ เรียนรู้วิธีการพัฒนาแอปพลิเคชันแคนวาสที่สามารถใช้งานแบบออฟไลน์ได้

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

เรียนรู้เพิ่มเติมเกี่ยวกับการจัดการข้อผิดพลาดชั่วคราวใน Power Apps:

Azure และตัวเชื่อมต่อแบบกำหนดเอง

หากภาระงานของคุณเชื่อมต่อกับบริการ Azure เรียนรู้วิธีจัดการกับข้อผิดพลาดชั่วคราวโดยใช้ Azure Well-Architected Framework

หากต้องการจัดการการตอบสนองต่อข้อผิดพลาดของตัวเชื่อมต่อที่กำหนดเอง ให้ปฏิบัติตาม มาตรฐานการเขียนโค้ด

Application Insights

ใช้การรวมระบบ Application Insights เพื่อบันทึกข้อผิดพลาดใน Power Automate และ Power Apps:

ความต่อเนื่องทางธุรกิจและการกู้คืนจากภัยพิบัติสำหรับแอป SaaS Dynamics 365

รายการตรวจสอบความน่าเชื่อถือ

โปรดดูชุดคำแนะนำทั้งหมด

รายการตรวจสอบความน่าเชื่อถือ