การออกแบบระบบ: เตรียมตัวให้พร้อมสำหรับสิ่งที่เลวร้ายที่สุด

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

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

“ความล้มเหลวที่ไม่คาดคิด” ที่เรากำลังพูดถึงคืออะไร?

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

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

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

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

กลไกการลองใหม่

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

• สามารถกำหนดค่าและจำกัดจำนวนครั้งที่แอปพลิเคชันของคุณพยายามดำเนินการใหม่ การลองซ้ำจำนวนไม่สิ้นสุด / จำนวนครั้งสูงอาจทำให้แอปพลิเคชันของคุณค้างและปฏิเสธคำขออื่นๆ เนื่องจากแอปพลิเคชันจะยุ่งกับการลองใหม่ไม่รู้จบ
• ใช้ bakeoff ชี้แจง เพิ่มช่วงเวลาระหว่างการลองใหม่แบบทวีคูณ
  มันจะเพิ่มโอกาสที่ปัญหาชั่วคราว (บนเซิร์ฟเวอร์/ ฐานข้อมูล / บุคคลที่สาม) จะได้รับการแก้ไข และความพยายามครั้งต่อไปของคุณจะสำเร็จ ยิ่งกว่านั้นการใช้ exponential interval ยังให้ความอนุเคราะห์แก่บุคคลที่สามซึ่งอยู่ภายใต้ภาระและดังนั้นจึงไม่สามารถให้บริการลูกค้าได้ การดำเนินการลองใหม่ทันทีโดยไม่ชักช้าอาจทำให้ปัญหาแย่ลงได้
• ตรวจสอบให้แน่ใจว่าคุณเข้าใจว่าข้อผิดพลาดใดควรลองใหม่และข้อผิดพลาดใดไม่ควรลองใหม่ ไม่ใช่ทุกข้อผิดพลาดที่สามารถแก้ไขได้ด้วยการลองใหม่อีกครั้ง ตัวอย่างเช่น สมมติว่าคำขอ http ของคุณล้มเหลวโดยมีรหัสสถานะเป็น 'คำขอไม่ถูกต้อง' (400) หมายความว่าบางสิ่งที่มีข้อมูลของคำขอไม่ถูกต้องและถูกปฏิเสธโดยเซิร์ฟเวอร์ ไม่ว่าแอปพลิเคชันของคุณจะลองใหม่กี่ครั้ง ก็จะจบลงด้วยผลลัพธ์เดียวกันนั่นคือความล้มเหลว
  การลองใหม่กับข้อผิดพลาดประเภทนั้นซ้ำซ้อนและจะส่งผลต่อประสิทธิภาพของแอปพลิเคชันของคุณ คุณต้องแยกความแตกต่างระหว่างข้อผิดพลาดต่างๆ และตัดสินใจว่าจะลองใหม่อีกครั้ง

มีไลบรารีโอเพ่นซอร์สหลายไลบรารีซึ่งให้คุณสมบัติที่เกี่ยวข้องทั้งหมดของกลไกการลองใหม่แก่คุณแล้ว ดังนั้นคุณจึงไม่ต้องเขียนใหม่ทั้งหมด ตัวอย่างเช่น ใน .NET คุณมีไลบรารีชื่อ Polly

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

กำหนดระยะหมดเวลาสำหรับกระบวนการของคุณ

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

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

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

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

อย่าส่งต่อการโทรกลับ/เว็บฮุคเท่านั้น - ใช้กลไกการสำรวจ

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

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

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

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

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

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

หลีกเลี่ยงจากการล็อคผู้ขาย

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

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

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

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

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

รูปแบบเบรกเกอร์วงจร

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

แล้วมันทำงานอย่างไร?
กลไกนี้ทำหน้าที่เป็นพร็อกซีสำหรับการดำเนินการที่คุณต้องการดำเนินการ
มันมี 3 สถานะ:

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

จุดสิ้นสุดเฉพาะสำหรับการแทรกแซงด้วยตนเองที่ง่ายและมีประสิทธิภาพ

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

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

การสร้าง API ภายในนี้ แม้ว่าจะต้องมีคนคอยกระตุ้น แต่ก็มีประโยชน์มากมาย:

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

สรุป

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

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