ความแตกต่างระหว่างความทนทานและการยอมรับข้อผิดพลาดคืออะไร?

ระบบ / โปรแกรม / อัลกอริทึมแบบกระจาย / ... มักถูกอธิบายด้วยเพรดิเคตที่ทนทานหรือข้อผิดพลาดที่ยอมรับได้

อะไรคือความแตกต่าง?

รายละเอียด:

เมื่อฉัน google สำหรับ + ​​strong + "fault-tolerant" ฉันจะได้รับสองครั้งเท่านั้นทั้งไม่ช่วยเหลือ

เมื่อฉันไปหาคำศัพท์ฉันพบเอกสารจำนวนมากที่มีทั้งสองคำอยู่ในชื่อของพวกเขา น่าเสียดายที่พวกเขาไม่ได้กำหนดคำอย่างแม่นยำ :( แต่เนื่องจากพวกเขาใช้ทั้งสองคำดูเหมือนว่าทั้งสองไม่มีนัยใด ๆ

ทั้งอธิบายถึงความสอดคล้องของพฤติกรรมของโปรแกรม แต่ "ทนทาน" อธิบายการตอบสนองของโปรแกรมการของการป้อนข้อมูลขณะที่ "ความผิดความอดทน" อธิบายการตอบสนองของโปรแกรมการของสภาพแวดล้อม

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

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

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

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

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

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

• http://static.googleusercontent.com/media/research.google.com/th/us/archive/gfs-sosp2003.pdf ("ระบบของเราให้การยอมรับข้อผิดพลาดโดยการตรวจสอบอย่างต่อเนื่องจำลองข้อมูลที่สำคัญและการกู้คืนที่รวดเร็วและอัตโนมัติ ")

โปรเจ็กต์นี้สำหรับคลาสที่ Rutgers สนับสนุนคำนิยามเชิง "ความล้มเหลวของคอมโพเนนต์" ของ "การยอมรับข้อบกพร่อง":

• http://www.ece.rutgers.edu/~parashar/Classes/03-04/ece572/papers/cristian93understanding.pdf ("ระบบบางระบบได้รับการออกแบบให้มีความทนทานต่อความผิดพลาด: พวกมันแสดงพฤติกรรมการล้มเหลวที่ชัดเจนเมื่อ คอมโพเนนต์ล้มเหลวหรือปิดบังความล้มเหลวของคอมโพเนนต์แก่ผู้ใช้ ... ")

มีเอกสารจำนวนมากเกี่ยวกับ "การสร้างแบบจำลองที่แข็งแกร่ง XYZ" ขึ้นอยู่กับฟิลด์ที่คุณตรวจสอบ ส่วนใหญ่จะอธิบายเกณฑ์ของพวกเขาสำหรับ "แข็งแกร่ง" ในนามธรรมและคุณจะพบว่าทั้งหมดเกี่ยวข้องกับวิธีที่โมเดลเกี่ยวข้องกับอินพุต

บทสรุปจากนักวิทยาศาสตร์ภูมิอากาศของนาซาอธิบายความแข็งแกร่งเป็นเกณฑ์สำหรับการประเมินแบบจำลองสภาพภูมิอากาศ:

• http://www.giss.nasa.gov/research/briefs/schmidt_04/ ("…แข็งแกร่งในการที่มันไม่ได้ขึ้นอยู่กับลักษณะเฉพาะของการกำหนดพารามิเตอร์และการแสดงเชิงพื้นที่")

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

• http://people.csail.mit.edu/grishac/papers/allerton.pdf ("ในระยะสั้นการใช้งานเหล่านี้ต้องการแอปพลิเคชั่นที่แข็งแกร่งที่ทำงานอย่างถูกต้องเสมอแม้ภายใต้เงื่อนไขที่ไม่คาดคิด")

ฉันชอบคำตอบของ @ johnnybและรับรองความหมายที่คมชัด แต่หลังจากทำงานในสาขานี้มาสองสามทศวรรษแล้วฉันก็รู้จักวิธีอื่นที่ไม่ค่อยเป็นทางการและแม่นยำมากกว่านี้ซึ่งเป็นคำที่ใช้บ่อย:

ในฐานะที่เป็นทางการตามจุดต่าง ๆ ตั้งแต่ "ไม่น่าเชื่อถือ" ถึง "เชื่อถือได้อย่างสมบูรณ์แบบ"

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

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

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

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

@johnnyb สัมผัสกับความแตกต่างที่สำคัญ: ความแตกต่างระหว่างสถานะขึ้น / ลงของแพลตฟอร์ม (ความพร้อมใช้งาน) ในมือข้างหนึ่งและอัลกอริทึมแอปพลิเคชันหรือคุณลักษณะของบริการในอีกด้านหนึ่ง

ฉันพูดว่า "คุณสมบัติ" เพราะมีหลายอย่าง: ประสิทธิภาพความถูกต้องและความไม่ลงรอยกันเป็นเพียงกุญแจสำคัญสองสามข้อ ระบบมีความหมายและถูกต้องหรือไม่หากระบบทำงานด้วยประสิทธิภาพเพียง 10% ไม่ได้เป็นไปตามเจ้าของธุรกิจหากเป็นฤดูที่วุ่นวาย! ไม่มีคุณธรรมที่ดีในระบบที่ไม่เคยลงไปจริง ๆ แต่ยังให้คำตอบที่ไม่ถูกต้องมากเวลา ในที่สุดระบบการวิเคราะห์ข้อมูลใช้ "ถูกต้อง" หรือไม่หากการเปลี่ยนแปลงของอินพุท 0.2% ให้คำตอบที่แตกต่างกัน 3,400%? บางที ... แต่มันจะเป็นรูปแบบที่ค่อนข้างแน่นอนและไม่น่าพอใจสำหรับหลาย ๆ คน ฉันจะไม่ผ่านรายการคุณลักษณะเพิ่มเติม แต่ความถูกต้องของข้อมูลความปลอดภัยของข้อมูลความเป็นส่วนตัวของข้อมูลและปัญหาอื่น ๆ ของความถูกต้องและความปลอดภัยเป็นเรื่องที่พบบ่อย (หากคุณเป็นองค์กรขนาดใหญ่หรือหน่วยงานของรัฐ คุณกังวลมากขึ้นเกี่ยวกับการรักษาคุณลักษณะเหล่านั้นไม่เพียงแค่ในช่วงไม่กี่ปีหรือวงจรผลิตภัณฑ์ แต่ครอบคลุมช่วงหลายทศวรรษหรืออาจนานหลายศตวรรษ ยังไม่มีสถาปัตยกรรมกระบวนการหรือแนวทางที่พิสูจน์แล้วเพื่อให้บรรลุเป้าหมายนี้)

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