Date: สิงหาคม 21, 2026
เหตุใดความพร้อมใช้งาน 99.99% จึงไม่ได้หมายความว่าพร้อมใช้งาน 100%
คุณเคยสังเกตภาชนะบรรจุเจลล้างมืออย่างใกล้ชิดบ้างไหม? โดยปกติแล้วจะมีข้อความ “ฆ่าเชื้อโรคได้ 99.99%” ปรากฏอยู่บนบรรจุภัณฑ์อย่างเด่นชัด หากคุณเป็นเหมือนผม คุณอาจจะตั้งคำถามที่สมเหตุสมผลว่า “แล้วอีก 0.01% ล่ะ?” ทำไมส่วนเล็กๆ นั้นถึงยากนัก? เราพบคำถามเดียวกันนี้กับซอฟต์แวร์ HA คุณอาจเคยเห็นตัวเลข 99.99% เมื่อพูดถึงเวลาทำงานของระบบ HA คำถามยังคงเหมือนเดิม: ทำไมเราถึงไม่สามารถบรรลุเวลาทำงานได้ 100%?
ก่อนอื่น เรามาพูดถึงความหมายที่แท้จริงของเวลาทำงาน 99.99% กันก่อน เวลาทำงานหมายถึงระยะเวลาที่แอปพลิเคชันของคุณทำงานและพร้อมใช้งานสำหรับผู้ใช้ปลายทาง โดยทั่วไปจะวัดจากระยะเวลาหนึ่งปี เพื่อให้ได้เวลาทำงาน 99.99% คุณต้องมีเวลาหยุดทำงานไม่เกิน 52.60 นาที โดยเฉลี่ยแล้ว จะแบ่งออกเป็น:
52 นาที 36 วินาทีต่อปี
4 นาที 23 วินาทีต่อเดือน
1 นาที 0 วินาทีต่อสัปดาห์
0 นาที 8 วินาทีต่อวัน
นั่นเป็นเวลาเพียงเล็กน้อย แต่ก็ถือว่าน้อยมาก แล้วมันมาจากไหนกันแน่?
แหล่งที่มาของการหยุดทำงานโดยเจตนา
มาเริ่มกันที่สาเหตุหลักๆ ที่ทำให้เกิดการหยุดทำงานก่อน ความจริงก็คือ ไม่ว่าซอฟต์แวร์ HA ของคุณจะดีแค่ไหน ก็ยังต้องใช้เวลาในการดำเนินการทั่วไป เช่น การสลับระบบ ทุกครั้งที่คุณเริ่มการสลับระบบโดยตั้งใจ จะเกิดการหยุดทำงานเพียงเล็กน้อย ขึ้นอยู่กับขนาดของลำดับชั้น อาจใช้เวลาตั้งแต่ไม่กี่วินาทีถึงไม่กี่นาที เพื่อให้เข้าใจว่าทำไมถึงเป็นเช่นนั้น เราต้องเข้าใจว่าเกิดอะไรขึ้นเมื่อมีการสลับระบบ ในระดับทรัพยากร เราต้องนำทรัพยากรออกจากระบบบนโหนดที่ใช้งานอยู่ปัจจุบันอย่างสมบูรณ์ก่อน จากนั้นจึงนำทรัพยากรกลับมาใช้งานบนโหนดที่ใช้งานอยู่ใหม่ ขึ้นอยู่กับแอปพลิเคชัน อาจหมายถึงการเรียกใช้คำสั่งอย่างรวดเร็วสองสามคำสั่ง หรืออาจหมายถึงการดำเนินการปิดระบบอย่างนุ่มนวลที่ยาวและซับซ้อน ตามด้วยการเริ่มต้นระบบแบบเย็นที่ช้าบนเซิร์ฟเวอร์อื่น ในระดับลำดับชั้น เราต้องดำเนินการเหล่านี้ทีละรายการในหลายกรณี หากทรัพยากรมีทรัพยากรย่อยใดๆ ทรัพยากรย่อยเหล่านั้นจะต้องถูกนำออกจากระบบอย่างสมบูรณ์ก่อนที่เราจะเริ่มนำทรัพยากรเริ่มต้นออกจากระบบได้ จากนั้นบนเซิร์ฟเวอร์อีกเครื่อง เราต้องทำให้ระบบลูกๆ พร้อมใช้งานอย่างสมบูรณ์ก่อนที่เราจะเริ่มทำให้เครื่องนั้นพร้อมใช้งานได้ สำหรับโครงสร้างลำดับชั้นหลายระดับที่มีกระบวนการสลับการทำงานที่ซับซ้อน อาจทำให้เสียเวลามาก นี่เป็นเวลาหยุดทำงานที่หลีกเลี่ยงไม่ได้ แต่โชคดีที่ในกรณีส่วนใหญ่ ผู้ใช้ปลายทางจะไม่สังเกตเห็นอะไรมากไปกว่าเวลาในการโหลดที่นานขึ้นเล็กน้อย หรือการเชื่อมต่อใหม่ชั่วครู่ อย่างไรก็ตาม มันจะเพิ่มเข้าไปในการคำนวณเวลาหยุดทำงาน
อีกรูปแบบหนึ่งของการหยุดทำงานโดยธรรมชาติคือการบำรุงรักษา โชคดีที่การบำรุงรักษาส่วนใหญ่สามารถดำเนินการได้ในลักษณะที่มีความพร้อมใช้งานสูง ซึ่งหมายถึงการดำเนินการบำรุงรักษาบนโหนดสำรองก่อน จากนั้นทำการสลับระบบ แล้วจึงดำเนินการบำรุงรักษาบนระบบที่ใช้งานอยู่ก่อนหน้านี้ ซึ่งจะทำให้เกิดการหยุดทำงานบ้างตามที่อธิบายไว้ข้างต้น แต่ควรจะน้อยที่สุด อย่างไรก็ตาม มีการบำรุงรักษาบางรูปแบบที่ไม่สามารถดำเนินการได้ในลักษณะที่มีความพร้อมใช้งานสูง ในกรณีเหล่านี้ อาจเกิดการหยุดทำงานจำนวนมาก และทำให้เวลาหยุดทำงานรวมทั้งปีเพิ่มขึ้น
สาเหตุที่ทำให้ระบบหยุดทำงานโดยไม่ตั้งใจ
ตัวเลขต่างๆ จะเริ่มชัดเจนขึ้นเมื่อเราเริ่มพิจารณาถึงวัตถุประสงค์หลักของซอฟต์แวร์ที่มีความพร้อมใช้งานสูง นั่นคือ การกู้คืนจากภัยพิบัติ แม้ว่าทุกอย่างจะดำเนินไปอย่างสมบูรณ์แบบตามแผน แต่ความล้มเหลวใดๆ ก็จะทำให้เกิดช่วงเวลาหยุดทำงานอยู่บ้าง มาดูกันก่อนว่าช่วงเวลาหยุดทำงานเกิดขึ้นได้อย่างไรในระหว่างการสลับระบบที่ประสบความสำเร็จ เพื่อให้สามารถกู้คืนจากความล้มเหลวได้อย่างถูกต้อง เราต้องตรวจจับและตรวจสอบความล้มเหลวก่อน ซึ่งเป็นเรื่องที่ต้องใช้ความสมดุลอย่างมาก หากคุณตรวจจับความล้มเหลวอย่างรวดเร็วเกินไป คุณอาจตรวจพบความล้มเหลวที่ยังไม่เกิดขึ้นจริง (ความล้มเหลวที่ผิดพลาด) หากคุณไม่รวดเร็วพอ คุณอาจตรวจจับความล้มเหลวได้ช้ากว่าที่ควรจะเป็น ความล้มเหลวส่วนใหญ่จะถูกตรวจพบก่อนโดยกระบวนการที่ทำงานเป็นระยะ ในกรณีที่ทรัพยากรแต่ละรายการล้มเหลว โดยทั่วไปจะเป็นสคริปต์ตรวจสอบที่ล้มเหลว ในกรณีของเซิร์ฟเวอร์ทั้งหมด โดยทั่วไปจะตรวจพบโดยการส่งสัญญาณชีพจรที่หายไป ในทั้งสองกรณี เราไม่ได้แค่รับความล้มเหลวเพียงครั้งเดียวแล้วเริ่มการกู้คืนทันที แต่เราจะลองใหม่และรอให้เกิดความล้มเหลวหลายครั้งเพื่อตรวจสอบความล้มเหลวที่แท้จริง ตัวอย่างเช่น สคริปต์ตรวจสอบเชิงลึก ซึ่งทำการทดสอบสถานะทรัพยากรที่ซับซ้อนกว่า จะทำงานโดยค่าเริ่มต้นทุกๆ ห้านาที นี่หมายความว่าอาจใช้เวลาถึงห้านาทีในการตรวจจับความล้มเหลวบางอย่าง และขึ้นอยู่กับประเภทของความล้มเหลว อาจใช้เวลานานกว่านั้นในการตรวจสอบ หลังจากที่เราตรวจพบและตรวจสอบความล้มเหลวแล้ว ขึ้นอยู่กับประเภทของความล้มเหลว เราอาจพยายามกู้คืนในพื้นที่หลายครั้ง หากสำเร็จ จะช่วยลดเวลาหยุดทำงาน แต่หากไม่สำเร็จ ก็จะเพิ่มเวลาให้กับสมการเวลาหยุดทำงานของการสลับระบบ หลังจากตรวจพบความล้มเหลว ตรวจสอบ และพยายามกู้คืนในพื้นที่แล้ว เราจะทำการสลับระบบ ขึ้นอยู่กับประเภทของความล้มเหลวที่เกิดขึ้น อาจใช้เวลาใกล้เคียงกับเวลาหยุดทำงานของการสลับระบบที่อธิบายไว้ก่อนหน้านี้ การรวมแหล่งที่มาของความล่าช้าทั้งหมดเหล่านี้เข้าด้วยกัน อาจทำให้เวลาหยุดทำงานเพิ่มขึ้นอย่างมาก โชคดีที่ความล้มเหลวส่วนใหญ่สามารถตรวจพบได้อย่างรวดเร็ว และเช่นเดียวกับการสลับระบบที่อธิบายไว้ข้างต้น ผู้ใช้ปลายทางแทบจะไม่สังเกตเห็นเลย
สาเหตุประการที่สองของการหยุดทำงานโดยไม่ตั้งใจคือ การสลับระบบสำรอง (failover) ที่ล้มเหลว เมื่อเกิดเหตุการณ์เหล่านี้ขึ้น อาจทำให้เวลาหยุดทำงานเพิ่มขึ้นอย่างมาก เนื่องจากต้องอาศัยช่างเทคนิคที่มีคุณสมบัติเหมาะสมในการเข้าไปแก้ไขและทำให้ระบบกลับมาเสถียรอย่างถูกต้อง เหตุการณ์เหล่านี้ค่อนข้างหายาก แต่ก็เกิดขึ้นได้ โชคดีที่เกือบทุกกรณีสามารถป้องกันได้ วิธีที่ดีที่สุดเพื่อให้แน่ใจว่าการสลับระบบสำรองจะดำเนินไปตามแผนคือการทดสอบล่วงหน้า การตั้งค่าผิดพลาดอาจเกิดขึ้นได้ง่าย แต่การทดสอบการสลับระบบสำรองก็จะช่วยให้พบปัญหาดังกล่าวได้ อีกวิธีหนึ่งเพื่อให้แน่ใจว่าการสลับระบบสำรองจะประสบความสำเร็จคือการตรวจสอบให้แน่ใจว่าคลัสเตอร์ของคุณพร้อมที่จะสลับระบบสำรองบ่อยที่สุดเท่าที่จะเป็นไปได้ ซึ่งหมายถึงการตรวจสอบให้แน่ใจว่าระบบสำรองข้อมูลทำงานอยู่ และทรัพยากรอยู่ในสถานะ ISP (In Service Protected) ตัวอย่างเช่น มิเรอร์ของ DataKeeper ที่ไม่ได้อยู่ในสถานะมิเรอร์ จะไม่อยู่ในสถานะ ISP และเมื่อเกิดความล้มเหลว จะไม่สามารถสลับระบบสำรองได้ เพื่อให้มั่นใจได้ว่าสามารถสลับทรัพยากรได้ คุณควรดำเนินการเพื่อให้แน่ใจว่า DataKeeper ทำการจำลองข้อมูลบ่อยที่สุดเท่าที่จะเป็นไปได้ และทรัพยากรอื่นๆ ก็ได้รับการอัปเดตและพร้อมสำหรับการสลับไปใช้ระบบสำรองเช่นกัน
สาเหตุสุดท้ายของการหยุดทำงานโดยไม่ตั้งใจคือปัญหาที่อยู่นอกเหนือการควบคุมของ LifeKeeper ปัญหาเครือข่ายอาจทำให้การสลับระบบ (failover) สำเร็จและไม่สำเร็จ แต่ก็อาจทำให้คลัสเตอร์ที่ดูเหมือนทำงานได้ดีไม่สามารถเข้าถึงได้ ขึ้นอยู่กับการตั้งค่าระบบ ในทำนองเดียวกัน ปัญหาเกี่ยวกับซอฟต์แวร์คลาวด์หรือเวอร์ชวลไลเซชันพื้นฐานอาจทำให้เกิดปัญหาที่อยู่นอกเหนือขอบเขตของ LifeKeeper เพื่อป้องกันสิ่งเหล่านี้ การแยกระบบออกจากกันให้มากที่สุดเท่าที่จะเป็นไปได้จะช่วยให้ LifeKeeper สามารถรับมือกับปัญหาเหล่านี้ได้ คลัสเตอร์ที่มีระบบทั้งหมดอยู่ใน AZ เดียวกันหรือบนเครือข่ายเดียวกันนั้นมีความเสี่ยงต่อปัญหามากกว่าคลัสเตอร์ที่มีระบบที่หลากหลาย อีกด้านหนึ่งของปัญหาที่อยู่นอกเหนือการควบคุมของ LifeKeeper คือปัญหาภายในแอปพลิเคชันและข้อผิดพลาดของมนุษย์ ตัวอย่างเช่น การลบข้อมูลสำคัญโดยไม่ตั้งใจอาจทำให้เกิดปัญหาสำหรับผู้ใช้ปลายทางซึ่งอาจตรวจไม่พบและ LifeKeeper ไม่สามารถแก้ไขได้ การใช้ซอฟต์แวร์สำรองข้อมูลสามารถช่วยกู้คืนจากปัญหาประเภทนี้ได้ แต่ไม่สามารถเรียกคืนเวลาการทำงานที่สูญเสียไปได้ สุดท้าย ความพร้อมใช้งานสูงไม่ได้ป้องกันผู้ไม่หวังดีและภัยคุกคามทางไซเบอร์เสมอไป การโจมตีบางอย่างอาจส่งผลให้สูญเสียเวลาการทำงาน เพื่อป้องกันสิ่งเหล่านี้ แนะนำให้ใช้ชุดโปรแกรมป้องกันไวรัส/มัลแวร์ที่เชื่อถือได้
สาเหตุที่ทำให้ระบบหยุดทำงานซึ่งสามารถหลีกเลี่ยงได้
ดังที่ได้กล่าวไว้ในหลายหัวข้อข้างต้น มีสาเหตุของการหยุดทำงานหลายอย่างที่สามารถป้องกันได้อย่างสิ้นเชิง ผมจะไม่กล่าวถึงสาเหตุของการหยุดทำงานที่ป้องกันได้ทุกประเภทในที่นี้ แต่จะยกตัวอย่างบางประเภทที่พบบ่อยที่สุด
ในการเริ่มต้นออกแบบโครงสร้างและโครงสร้างของคลัสเตอร์ มีหลายสิ่งที่คุณควรพิจารณา ปัญหา Split brain ซึ่งเกิดขึ้นเมื่อทั้งสองโหนดเข้าใจผิดคิดว่าตัวเองเป็นโหนดหลัก สามารถป้องกันได้โดยการใช้ Quorum หากคุณกำลังสร้างแอปพลิเคชันทั่วไป (gen app) โปรดตรวจสอบให้แน่ใจว่าได้เขียนและใช้สคริปต์ตรวจสอบอย่างรวดเร็วและตรวจสอบอย่างละเอียด เพื่อตรวจจับความล้มเหลวได้อย่างแท้จริง สุดท้ายนี้ โปรดตรวจสอบให้แน่ใจว่าได้ตั้งค่าเส้นทางการสื่อสารมากกว่าหนึ่งเส้นทางที่วิ่งผ่าน NIC และเครือข่ายมากกว่าหนึ่งตัว
การตั้งค่าระบบที่ไม่ถูกต้องอาจนำไปสู่การหยุดทำงานได้เช่นกัน บางส่วนได้อธิบายไปแล้ว ประการแรก ตรวจสอบให้แน่ใจว่าแอปพลิเคชันที่ได้รับการปกป้อง ระบบปฏิบัติการพื้นฐาน และซอฟต์แวร์ความพร้อมใช้งานสูงทั้งหมดได้รับการอัปเดตอย่างสมบูรณ์โดยใช้เวอร์ชันล่าสุด การหยุดทำงานจำนวนมากเกิดขึ้นเนื่องจากข้อบกพร่องที่ได้รับการแก้ไขแล้ว ซึ่งสามารถหลีกเลี่ยงได้อย่างสิ้นเชิง ประการที่สอง ตรวจสอบให้แน่ใจว่าได้ทำการทดสอบการสลับและการเฟลโอเวอร์ของคลัสเตอร์หลังจากการตั้งค่าและเป็นระยะ ปัญหาหลายอย่างที่อาจขัดขวางการเฟลโอเวอร์ที่ประสบความสำเร็จสามารถตรวจพบและป้องกันได้ล่วงหน้าโดยการทำการทดสอบนี้ ประการที่สาม ตรวจสอบให้แน่ใจว่าคุณใช้งานโดยมีโหนดสำรองพร้อมใช้งานอยู่เสมอ
ระบบที่ตั้งค่าไม่ถูกต้องอาจทำให้ระบบหยุดทำงาน เพื่อป้องกันปัญหานี้ LifeKeeper และ DataKeeper มีพารามิเตอร์ที่สามารถปรับแต่งได้เพื่อเพิ่มประสิทธิภาพ ช่วงเวลาการส่งสัญญาณชีพจร การตรวจสอบทรัพยากร และการตั้งค่าการลองใหม่ แม้ว่าการตั้งค่าเริ่มต้นมักจะเพียงพอ แต่การเปลี่ยนแปลงใดๆ ควรทำด้วยความเข้าใจอย่างชัดเจนถึงผลกระทบและความจำเป็น ควรให้ความสำคัญกับคำแนะนำจากฝ่ายสนับสนุนของ SIOS เสมอ เนื่องจากคำแนะนำของพวกเขามีพื้นฐานมาจากความเชี่ยวชาญที่กว้างขวางและควรปฏิบัติตามเพื่อให้มั่นใจถึงความน่าเชื่อถือของระบบ
ผู้เขียน: คาร์เตอร์ แชนด์เลอร์ วิศวกรซอฟต์แวร์ระดับผู้ช่วย บริษัท SIOS
นำมาเผยแพร่ซ้ำโดยได้รับอนุญาตจากSIOS