เราควรออกแบบโปรแกรมเพื่อฆ่าตัวตายแบบสุ่มหรือไม่? [ปิด]

โดยสรุปเราควรออกแบบความตายในโปรแกรมกระบวนการและเธรดของเราในระดับต่ำเพื่อประโยชน์ของระบบโดยรวมหรือไม่

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

ตัวอย่างมาโครของแนวคิดนี้คือChaos Monkeyของ Netflix ซึ่งสุ่มอินสแตนซ์ของ AWS ในบางสถานการณ์ พวกเขาอ้างว่าสิ่งนี้ช่วยให้พวกเขาค้นพบปัญหาและสร้างระบบซ้ำซ้อนมากขึ้น

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

แนวคิดนี้มีชื่ออยู่แล้วหรือไม่? มันถูกใช้ไปแล้วในอุตสาหกรรมหรือไม่?

แก้ไข

จากความคิดเห็นและคำตอบฉันเกรงว่าจะไม่ชัดเจนในคำถามของฉัน เพื่อความชัดเจน:

• ใช่ฉันหมายถึงการสุ่ม
• ใช่ฉันหมายถึงในการผลิตและ
• ไม่ไม่ใช่แค่การทดสอบ

เพื่ออธิบายฉันต้องการวาดสิ่งเปรียบเทียบกับสิ่งมีชีวิตหลายเซลล์

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

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

และถ้าใครได้ลองสิ่งนี้มันจะเรียกว่าอะไร ฉันต้องการอ่านเพิ่มเติมเกี่ยวกับมันหากมีอยู่แล้ว

เลขที่

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

กระบวนการของการแนะนำข้อบกพร่องในซอฟต์แวร์หรือฮาร์ดแวร์เพื่อทดสอบความอดทนความผิดกลไกที่เรียกว่าการฉีดความผิด

จากวิกิพีเดีย:

เทคนิคการฉีดข้อบกพร่องเกิดขึ้นตั้งแต่ทศวรรษ 1970 เมื่อมีการใช้ครั้งแรกเพื่อชักนำข้อบกพร่องในระดับฮาร์ดแวร์ การฉีดข้อผิดพลาดประเภทนี้เรียกว่า Hardware Implemented Fault Injection (HWIFI) และพยายามจำลองความล้มเหลวของฮาร์ดแวร์ภายในระบบ การทดลองครั้งแรกในการฉีดข้อผิดพลาดของฮาร์ดแวร์ไม่ได้เกี่ยวข้องอะไรมากไปกว่าการลัดวงจรการเชื่อมต่อบนแผงวงจรและการสังเกตผลกระทบที่เกิดขึ้นกับระบบ มันถูกใช้เป็นหลักในการทดสอบความน่าเชื่อถือของระบบฮาร์ดแวร์ ฮาร์ดแวร์พิเศษภายหลังได้รับการพัฒนาเพื่อขยายเทคนิคนี้เช่นอุปกรณ์เพื่อทิ้งระเบิดพื้นที่เฉพาะของแผงวงจรที่มีรังสีหนัก ในไม่ช้าก็พบว่าข้อผิดพลาดอาจเกิดจากเทคนิคซอฟต์แวร์และลักษณะของเทคนิคนี้อาจเป็นประโยชน์สำหรับการประเมินระบบซอฟต์แวร์

ใช่. ไม่แน่

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

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

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

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

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

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

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

คุณหมายถึงการสุ่มจริงๆเหรอ? การมีซอฟต์แวร์ของคุณฆ่าตัวเองแบบสุ่มดูเหมือนเป็นความคิดที่แย่มาก สิ่งใดที่จะให้บริการ

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

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

ฉันไม่ได้ทำงานในพื้นที่มาระยะหนึ่งดังนั้นฉันจึงไม่รู้ว่านี่เป็นกรณีนี้หรือไม่

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

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

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

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

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

อย่าเพิ่มรหัสทดสอบทำโปรแกรมสำหรับสถานการณ์ที่สามารถทำได้จากภายนอก

หากสิ่งนี้มีไว้สำหรับการผลิตฉันไม่อยากจะเชื่อเลยว่ามันร้ายแรง!

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

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

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

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

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

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

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

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

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

คำที่คุณกำลังมองหาได้รับการประกาศเกียรติคุณโดย Nassim Nicholas Taleb: Antifragility Antifragileหนังสือของเขาแนะนำอย่างแน่นอน มันแทบจะไม่พูดถึงไอที ​​แต่แนวที่ไม่ได้พูดออกมานั้นเป็นแรงบันดาลใจที่สุด ความคิดของเขาคือการขยายขนาดของความเปราะบาง <-> ที่แข็งแกร่งถึงความเปราะบาง <-> ที่แข็งแกร่ง <-> antifragile เปราะบางแตกหักด้วยเหตุการณ์สุ่มจัดการที่แข็งแกร่งด้วยเหตุการณ์สุ่มและกำไรที่เปราะบางต่อต้านกับเหตุการณ์สุ่ม

มันขึ้นอยู่กับ. ฉันสังเกตเห็นว่าโปรแกรมเมอร์มักจะใช้เทคนิคที่ใช้กับโดเมนของพวกเขามากเกินไปโดยไม่สนใจสิ่งอื่นทั้งหมด ตัวอย่างเช่นการเปิดตัวโปรแกรมที่ค่าใช้จ่ายในการแก้ไขข้อผิดพลาดทั้งหมดอาจจะดี ... เว้นแต่คุณจะตั้งโปรแกรมควบคุมเครื่องบิน, เครื่องปฏิกรณ์นิวเคลียร์ ฯลฯ "อย่าปรับให้เหมาะสม - ค่าใช้จ่ายของโปรแกรมเมอร์มากกว่าค่าใช้จ่ายในการรันโปรแกรม" ไม่จำเป็น ใช้ได้กับ HPC เนื่องจากมีโปรแกรมที่ค่อนข้างง่ายสามารถเข้าใช้คลัสเตอร์เป็นเวลาหลายเดือนเป็นต้น (หรือแม้แต่โปรแกรมยอดนิยมที่ผู้ใช้จำนวนมากใช้) ดังนั้นแม้ว่า บริษัท X กำลังทำ Y ด้วยเหตุผลที่ดีมากคุณไม่จำเป็นต้องทำตามเสียงฝีเท้าของพวกเขาเนื่องจากสถานการณ์ของคุณอาจแตกต่างกัน

โดยปกติแล้วการจัดการข้อผิดพลาดเป็นส่วนที่ทดสอบได้แย่ที่สุดของรหัส - ในขณะที่ดูเหมือนง่าย ๆ มันเป็นการยากที่จะจำลองว่ามีหน่วยความจำไม่เพียงพอหรือไฟล์สำคัญบางไฟล์ไม่มีอยู่ ด้วยเหตุนี้ฉันจึงอ่านข้อความที่เสนอให้เคอร์เนล Unix สุ่มการเรียกระบบบางอย่างล้มเหลว อย่างไรก็ตามมันจะทำให้โปรแกรมง่ายขึ้นยากที่จะเขียน (ถ้าฉันต้องการที่จะเสียบ 3 C ++ ไลบรารีเข้าด้วยกันเพื่อเรียกใช้โปรแกรมใน 2 ไฟล์เมื่อฉันไม่ต้องการที่จะจัดการกับข้อผิดพลาด) แม้จะมีข้อยกเว้น GC คุณจำเป็นต้องตรวจสอบให้แน่ใจว่าคุณทิ้งสถานะที่สอดคล้องกันไว้แล้ว (จินตนาการว่ามีข้อยกเว้นตรงกลางของการเพิ่มโหนดในรายการที่ลิงก์)

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

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

เซิร์ฟเวอร์ IIS มีคุณสมบัติที่สามารถกำหนดค่าได้ซึ่งจะรีไซเคิลกระบวนการของผู้ปฏิบัติงานโดยอัตโนมัติหลังจากที่พวกเขาใช้หน่วยความจำจำนวนหนึ่งหรือหลังจากให้บริการตามจำนวนที่ร้องขอหรือหลังจากที่ใช้งานได้ตามช่วงเวลาที่กำหนด ( http://msdn.microsoft.com/en-us/library/ms525803(v=vs.90).aspx ) และ ( http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/) 1652e79e-21f9-4e89-bc4b-c13f894a0cfe.mspx? mfr = จริง )

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

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

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

มีวรรณกรรมที่เกี่ยวข้องกับแนวคิดนี้เรียกว่าซอฟต์แวร์ Crash-Only (เช่น Recovery Oriented Computing) และคุณสามารถเริ่มต้นด้วยกระดาษ usenix นี้โดย Candea & Fox จากปี 2003 แทนที่จะฆ่าแบบสุ่มผู้เขียนเถียงคุณสามารถปรับปรุงความน่าเชื่อถือของระบบได้เพียง เคยหยุดโปรแกรมของคุณโดยการฆ่าพวกเขาดังนั้นมีสวิตช์ฆ่าคนเดียวเป็นปุ่มปิดและเส้นทางเริ่มต้นใช้งานที่ดีสำหรับการกู้คืน

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

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

ขึ้นอยู่กับประเภทของแอปพลิเคชันที่คุณออกแบบ

การล่มแบบสุ่มเป็นวิธีที่ดีในการทดสอบและปรับปรุงความทนทานของระบบการกระจาย (เครือข่าย)

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

คุณจะทำอย่างไร การเพิ่มความซ้ำซ้อนและการปรับสเกลเป็นโซลูชันทั่วไป

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

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

ต่อไปนี้เป็นคำอธิบายเพิ่มเติมเกี่ยวกับแนวคิดของ Chaos Monkeys http://www.codinghorror.com/blog/2011/04/working-with-the-chaos-monkey.html

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

อย่างไรก็ตามไม่สามารถแก้ไขได้ 100% และความเสียหายของหน่วยความจำยังคงทำให้เกิดปัญหาและปัญหาเหล่านี้ยังคงเกิดขึ้น (ที่มีความน่าจะเป็นต่ำ )

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

หากคุณต้องการออกแบบแอปพลิเคชันเดสก์ท็อปปกติคุณควรดูข้อผิดพลาดแบบสุ่มเป็นข้อบกพร่องในรหัสของคุณ

ดูเหมือนจะไม่ใช่ความคิดที่ผิดปกติ

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