สถาปัตยกรรมความพร้อมใช้งานสูงและแนวทางปฏิบัติที่ดีที่สุด
13 ข้อเท็จจริงที่ไม่ค่อยมีใครรู้จักเกี่ยวกับความพร้อมใช้งานสูง
1. Hypervisor HA ไม่เหมือนกับ Application HA
ความเข้าใจผิดที่สำคัญคือฉันมีความพร้อมใช้งานสูงเพราะฉันมีความซ้ำซ้อนในฮาร์ดแวร์หรือไฮเปอร์ไวเซอร์ของฉัน อย่างไรก็ตาม ความซ้ำซ้อนของฮาร์ดแวร์และไฮเปอร์ไวเซอร์ไม่รับประกัน ความพร้อมใช้งานสูง สำหรับการใช้งาน นอกจากนี้ยังไม่รับประกันว่าการประสานแอปพลิเคชันจะดำเนินการอย่างถูกต้องในความล้มเหลว
2. ในความพร้อมใช้งานสูง ใหญ่ขึ้นไม่เท่ากับดีกว่า
หากคุณเป็นนักยกน้ำหนัก น้ำหนักที่มากขึ้นจะดีกว่าและการทำซ้ำที่น้อยลงจะดีกว่า หรือถ้าเรากำลังพูดถึงการกอด (คุณจำได้ว่าการกอดคือสิ่งที่เราเคยทำเมื่อเราเห็นเพื่อนจากเมืองอื่น ซึ่งเราไม่ได้เจอกันมาสักพักแล้ว) แต่การกอดที่ใหญ่กว่านั้นไม่ได้แปลว่าดีกว่าเสมอไป ตัวอย่างเช่นนิ่วในไตที่ใหญ่กว่านั้นไม่ดีกว่าอย่างแน่นอน ในความพร้อมใช้งานที่สูงขึ้น การสร้างโซลูชันที่ใหญ่และซับซ้อนมากขึ้นไม่ได้หมายความว่าคุณจะเพิ่มความพร้อมใช้งานสูงเสมอไป อาจหมายความว่าคุณมีห้องว่างเท่ากันหรือน้อยกว่า นอกจากนี้ยังอาจหมายความว่าคุณมีระบบที่ใหญ่กว่าและซับซ้อนกว่าด้วยชิ้นส่วนที่เคลื่อนไหวจำนวนมากเพื่อจัดเรียงเมื่อหยุดทำงาน
3. ทุกอย่างล้มเหลว… บางครั้ง
ภาษาการเขียนโปรแกรมแอปพลิเคชันมีขึ้นในทศวรรษ 1950 และในขณะที่ภาษา โปรเซสเซอร์ IDE และคุณภาพของโค้ดได้รับการปรับปรุง ความจริงก็คือ "แอปพลิเคชันทั้งหมดล้มเหลวในบางจุด" ความล้มเหลวอันเนื่องมาจากข้อยกเว้น ข้อบกพร่อง การยุติที่ไม่สามารถจัดการได้ การยุติโดยไม่ได้ตั้งใจ การหมดทรัพยากร และอื่นๆ เกิดขึ้น ยังคงจำเป็นต้องมีกลยุทธ์ความพร้อมใช้งานของแอปพลิเคชันแบบแอ็คทีฟ/แอ็คทีฟ หรือแอ็คทีฟ/พาสซีฟ
4. มุ่งเน้นที่ 'ทำไม' มากเท่ากับ 'อย่างไร'
แนวโน้มโดยธรรมชาติของเราในการเข้าสู่โหมดการทำงานให้เสร็จเป็นทรัพยากรที่จำเป็น แต่จำเป็นต้องได้รับการปรับอารมณ์และให้คำแนะนำโดยคำตอบสำหรับคำถามของเราว่าทำไม การเพิ่มโซลูชันให้กับสภาพแวดล้อมโดยไม่เข้าใจข้อกำหนดทางธุรกิจ แอปพลิเคชัน ฐานข้อมูล และผู้มีส่วนได้ส่วนเสียจะนำไปสู่:
- ความล้มเหลว
- ใช้จ่ายเกินตัว
- ประสิทธิภาพต่ำ
- ความสับสนและเหนือสถาปัตยกรรม
- จากทั้งหมดที่กล่าวมา
แทนที่จะมุ่งเน้นไปที่การทำให้พร้อมใช้งาน ให้ใช้ทรัพยากรและความพยายามที่จำเป็นเพื่อทำความเข้าใจความต้องการทางธุรกิจและคำตอบสำหรับ "ทำไม"
5. ปัญหาที่ไม่ได้รับการแก้ไขมักเป็นที่มาของความเสียใจ
ถ้าคุณทำหรือไม่ทำ คุณจะมีผลที่ตามมา ผลที่ตามมาของปัญหาที่ไม่ได้แก้ไขทั้งหมดคือความเสียใจ ในฐานะรองประธานฝ่ายประสบการณ์ลูกค้า ฉันได้เห็นโดยตรงถึงการหยุดทำงานที่เกิดจากการที่ลูกค้าไม่สามารถแก้ไขปัญหาที่ทราบได้ทันท่วงที
6. ปัญหาที่ไม่มีเอกสารทำให้เกิดการหยุดทำงานเช่นกัน
นึกภาพฉาก. ผู้ดูแลระบบคนใหม่กำลังมองหาเซิร์ฟเวอร์บนเครือข่าย รายงานการใช้งานระบุว่าเซิร์ฟเวอร์ไม่ทำงานและไม่มีการเชื่อมต่อไคลเอ็นต์ ไม่รู้จักเซิร์ฟเวอร์และไม่พบ "แท็ก" เอกสารประกอบหรือตัวระบุอื่น ๆ ผู้ดูแลระบบคนใหม่เชื่อว่าควรปิดตัวลง น่าเสียดายที่อินสแตนซ์ที่ไม่มีเอกสารและไม่ได้สื่อสารจริง ๆ แล้วเป็นเซิร์ฟเวอร์สำรองซึ่งการลบออกจะทำให้หยุดทำงานเมื่อหลักขัดข้องโดยไม่คาดคิด นี่ไม่ใช่เรื่องราวสมมติ แต่เป็นเรื่องจริงของผู้ดูแลระบบคนใหม่ซึ่งระบุเซิร์ฟเวอร์ว่าระบบ idle QA ไม่ได้ใช้งานอย่างไม่ถูกต้อง และปิดตัวลงก่อนการฝึกแพตช์
7. ความพอใจยังเป็นศัตรู
เราทุกคนคงจะชอบหากความพร้อมใช้งานในสถานที่หรือในระบบคลาวด์ หรือที่ใดก็ตามในระหว่างนั้นเป็นสิ่งที่เราสามารถ "ตั้งค่าและลืม" แต่มีน้อยคนนักที่จะมีสิ่งใดในชีวิตที่ง่ายพอๆ กับ “ตั้งไว้และลืมมันไป” ศัตรูตัวฉกาจที่ใหญ่ที่สุดอย่างหนึ่งของความพร้อมของคุณในอนาคตคือความสำเร็จของคุณที่มีความพร้อมใช้งานสูงในขณะนี้ เมื่อภัยพิบัติมีอยู่ไม่มากนัก และทีมต่างๆ รู้สึกมั่นใจว่าพวกเขาได้ตระหนักถึงความมั่นคงที่ยั่งยืน ความอิ่มเอมใจก็เข้ามาได้ ความสำเร็จล่อลวงให้เราคิดว่าจะไม่มีอะไรเปลี่ยนแปลง และความพึงพอใจในแง่ของความพร้อมสูงจึงเป็นศัตรูของความพร้อมสูง สิ่งต่างๆ รอบตัวองค์กรและภายในองค์กรของคุณกำลังเปลี่ยนแปลง คลาวด์กำลังเปลี่ยนแปลง ความต้องการทางธุรกิจของคุณเปลี่ยนไป แอปพลิเคชันและระบบปฏิบัติการก็เปลี่ยนไปเช่นกัน
8. การเปลี่ยนแปลงเป็นเรื่องยาก
การเปลี่ยนแปลงเป็นเรื่องยาก แค่ถามใครก็ตามที่มีฟันหวานที่พยายามจะเลิกกินเค้กชิ้นที่สองนี้ก่อนนอน ความต้านทานที่คล้ายคลึงกันเกิดขึ้นได้แม้ในความพร้อมใช้งานสูง ทีมงาน แม้แต่ผู้ที่ประสบภัยพิบัติ มักไม่เต็มใจที่จะเปลี่ยนแปลงแม้ว่าการเปลี่ยนแปลงจะดีก็ตาม พวกเขาต้องการวิสัยทัศน์ ความเข้าใจในเหตุผล และการสนับสนุน ทีมอื่น ๆ ที่มีวิธีแก้ปัญหาไม่เต็มใจที่จะปรับปรุงความพร้อมใช้งานสูงโดยกลัวว่าจะทำให้เกิดความไม่เสถียรหรือเปิดเผยตัวเองต่อความเสี่ยงใหม่
9. การเปลี่ยนแปลงทั้งหมดไม่ใช่การเปลี่ยนแปลงที่ดี
การเปลี่ยนแปลงเป็นสิ่งที่ดี เมื่อการเปลี่ยนแปลงเป็นสิ่งที่ดี เมื่อพิจารณาการเปลี่ยนแปลงในโซลูชันและสถาปัตยกรรมที่มีความพร้อมใช้งานที่สูงขึ้น การเปลี่ยนแปลงจะต้องวิเคราะห์ตามเป้าหมาย ข้อกำหนด และภายในขอบเขตของความพร้อมใช้งานที่เพิ่มขึ้น การเปลี่ยนแปลงที่เพิ่มความเสถียร เพิ่มการป้องกันสำหรับส่วนประกอบที่สำคัญ ขจัดวิธีแก้ไขปัญหาชั่วคราว ปรับความพร้อมใช้งานของบริการให้เหมาะสม และผ่านการทดสอบอย่างละเอียดคือการเปลี่ยนแปลงที่ดี
10. ถูกกว่าไม่ได้ดีกว่าเสมอไป
ถูกกว่าไม่ได้ดีกว่าเสมอไป แม้ว่าโซลูชันที่ถูกกว่ามักจะมีป้ายราคาที่ต่ำกว่า แต่ก็อาจมีข้อจำกัดหลายประการที่ทำให้ไม่เป็นไปตามอุดมคติ เมื่อมีป้ายราคาที่ต่ำกว่า ให้ระวังคุณสมบัติที่ขาดหายไป เช่น การขาดการรับรู้แอปพลิเคชัน การประสานที่จำกัด ความซับซ้อนที่ซ่อนอยู่ การกู้คืนด้วยตนเอง และ ล้มเหลว และจำกัดไม่ให้มีการตรวจสอบผู้ใช้ โซลูชันที่ถูกกว่าอาจไม่สามารถรวมการสนับสนุนลูกค้าได้ อย่าลืมทำความเข้าใจว่าโซลูชันที่ถูกกว่าของคุณมีการสนับสนุนหรือไม่ หรือการสนับสนุนนั้นเป็นค่าใช้จ่ายเพิ่มเติมและมีค่าใช้จ่ายเพิ่มเติมจำนวนมาก
เช่นเดียวกับการปรับใช้ที่ถูกกว่าด้วยการประมวลผล ดิสก์ หรือพื้นที่จัดเก็บที่ลดลง แม้ว่าป้ายราคาและค่าใช้จ่ายรายเดือนอาจต่ำกว่า แต่โซลูชันของคุณอาจทำงานได้น้อยกว่าความจุที่เหมาะสม
11. เสียงดังไม่เท่ากับผล
เคยได้ยินเรื่องราวของเด็กชายที่ร้องไห้หมาป่า โซลูชันการตรวจสอบแอปพลิเคชันที่สร้างพายุแจ้งเตือนเร็วกว่าโซลูชันที่ถูกละเว้นไม่ช้าก็เร็ว การมีโซลูชันที่ให้การแจ้งเตือนนั้นยอดเยี่ยม แต่ถ้าโซลูชันนั้นทริกเกอร์การแจ้งเตือนที่สำคัญด้วยข้อผิดพลาดหรือมากเกินไป จะไม่ได้ผล
12. ความพร้อมใช้งานสูงเป็นวัฒนธรรมและความคิด ไม่ใช่แค่ผลิตภัณฑ์หรือโซลูชันฮาร์ดแวร์เท่านั้น
ซอฟต์แวร์ ฮาร์ดแวร์ กระบวนการ โซลูชัน และบริการล้วนเป็นส่วนหนึ่งของความพร้อมใช้งานสูง อย่างไรก็ตาม หากปราศจากการซื้อในแผนกไอทีและหน่วยธุรกิจ ก็จะเต็มไปด้วยความยุ่งยากและแหล่งที่มาของการอภิปรายเรื่องงบประมาณอย่างต่อเนื่อง แทนที่จะอภิปรายเกี่ยวกับคุณค่า ความมั่นคงทางธุรกิจ ความพึงพอใจของลูกค้าที่เพิ่มขึ้น และความเสี่ยงที่ลดลง
13. ตอนนี้ยังไม่สายเกินไป
ความหวังไม่ใช่กลยุทธ์สำหรับความพร้อมใช้งานสูง และไม่หวังว่าคุณจะไม่เกิดภัยพิบัติร้ายแรงหรือความล้มเหลวของแอปพลิเคชันที่จำเป็นต้องเป็นกลยุทธ์ การออกแบบและการออกแบบสถาปัตยกรรมองค์กรที่มีความพร้อมใช้งานสูงสามารถทำได้ในขณะนี้ แม้ว่าจะผ่านไปหลายสัปดาห์หรือหลายเดือนนับตั้งแต่ภัยพิบัติครั้งล่าสุด
ติดต่อ SIOS เพื่อเรียนรู้เพิ่มเติมเกี่ยวกับ โซลูชันความพร้อมใช้งานสูง สำหรับการสมัครของคุณ
– Cassius Rhue, VP, ประสบการณ์ลูกค้าทำซ้ำจาก SIOS
