คู่มือการสนับสนุน SIOS Enterprise: แผนของคุณครอบคลุมอะไรบ้าง

แพ็คเกจการสนับสนุน SIOS Enterprise ของคุณประกอบด้วยอะไรบ้าง?

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

ให้การสนับสนุนตลอด 24 ชั่วโมง 7 วันต่อสัปดาห์ สำหรับกรณีที่ระบบหยุดทำงานในสถานการณ์วิกฤติ

สถานการณ์ที่ 1: ระบบล่มหลังเวลาทำการ

ทีมของโจแอน: เวลา 19.00 น. ตามเวลา EST ของวันอาทิตย์ การสลับการทำงานระหว่างโหนดคลัสเตอร์ SIOS LifeKeeper ควรจะเป็นเรื่องง่าย แต่เกิดเหตุการณ์ไม่คาดฝันขึ้น ทำให้การสลับการทำงานล้มเหลว แม้ทีมจะพยายามแก้ไขปัญหาอย่างเต็มที่แล้ว แต่คลัสเตอร์ก็ยังคงใช้งานไม่ได้ โจแอนต้องการความช่วยเหลือ แต่เธอไม่แน่ใจว่าแผนการสนับสนุนทางเทคนิคของ SIOS ครอบคลุมวันหยุดสุดสัปดาห์หรือไม่ หรือต้องใช้เวลานานแค่ไหนกว่าจะได้คุยกับเจ้าหน้าที่ฝ่ายสนับสนุนทางโทรศัพท์

ลูกค้าที่ซื้อ (หรือต่ออายุ) การสนับสนุนระดับองค์กรก่อนเกิดเหตุการณ์ จะได้รับการสนับสนุนตลอด 24 ชั่วโมง 7 วันต่อสัปดาห์ ซึ่งรวมถึงวันหยุดสุดสัปดาห์และวันหยุดนักขัตฤกษ์ เพื่อแก้ไขปัญหาที่สำคัญ ปัญหาที่สำคัญหมายถึงระบบหรือแอปพลิเคชันที่ใช้งานจริงหยุดทำงาน ทำให้ไม่สามารถเข้าถึงข้อมูลของลูกค้าได้โดยใช้โปรแกรม SIOS สำหรับปัญหาที่มีลำดับความสำคัญระดับ 1 (วิกฤต) ซึ่งการทำงานปกติส่งผลให้ไม่สามารถเข้าถึงข้อมูลการใช้งานจริงได้ SIOS จะตอบกลับภายใน 2 ชั่วโมง

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

การสนับสนุนการติดตั้งและการกำหนดค่า

สถานการณ์ที่ 2: ต้องการความช่วยเหลือในการติดตั้ง

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

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

การวิเคราะห์สาเหตุหลัก (RCA) หลังการสลับระบบไปยังเครื่องสำรอง

สถานการณ์ที่ 3: การสนับสนุนการวิเคราะห์สาเหตุหลักหลังการสลับระบบ (Post-Failover RCA Support)

ทีมของอามอล: เวลา 2 นาฬิกา EST ของวันอังคาร มีการแจ้งเตือนส่งไปยังทีมพัฒนาแอปพลิเคชันทั้งหมดของบริษัท AjaxBjax Corp. คลัสเตอร์ที่ปกป้องระบบแอปพลิเคชันที่สำคัญที่สุดของบริษัทกำลังทำการสลับระบบ (failover) อามอลตรวจสอบแดชบอร์ดแอปพลิเคชันและพบว่าการสลับระบบสำเร็จและแอปพลิเคชันทั้งหมดทำงานได้ อย่างไรก็ตาม อามอลรู้ว่าฝ่ายบริหารต้องการคำอธิบายและคำรับรอง อามอลต้องการให้แน่ใจว่าบริการแอปพลิเคชันทั้งหมดทำงานได้ แต่เขาไม่แน่ใจว่าแผนการสนับสนุนของพวกเขาครอบคลุมเรื่องนี้หรือไม่

ทีมของ Amol กำลังมองหา RCA (Receiver Analyst) และความมั่นใจว่าระบบของพวกเขาจะยังคงใช้งานได้ต่อไป ข้อมูลของ Amol สามารถเข้าถึงได้ และแอปพลิเคชันของเขาก็ทำงานได้อย่างสมบูรณ์ ระบบของเขาไม่ใช่เซิร์ฟเวอร์ที่ใช้งานไม่ได้อย่างร้ายแรง หรือปัญหา P1 (Priority Level 1) อย่างไรก็ตาม หาก AjaxBjax Corp มีการสนับสนุนระดับองค์กรที่ถูกต้องสำหรับคลัสเตอร์ของพวกเขา พวกเขาจะสามารถติดต่อทีมสนับสนุนของ SIOS เพื่อขอคำแนะนำได้ตลอด 24 ชั่วโมง (เวลาฝั่งตะวันออกของสหรัฐอเมริกา) วันจันทร์ถึงวันศุกร์ สำหรับปัญหา RCA การโทรของ Amol ในเวลาตี 2 จะถูกส่งต่อไปยังศูนย์สนับสนุนของ SIOS ที่มีความรู้ความเชี่ยวชาญแห่งใดแห่งหนึ่ง ซึ่งทีมงานจะเริ่มทำงานร่วมกับ Amol

คำถามเพิ่มเติมเกี่ยวกับการติดต่อฝ่ายสนับสนุนของ SIOS

อามอลและโจนสามารถติดต่อฝ่ายสนับสนุนได้ผ่านทางสายด่วนฝ่ายสนับสนุน (สหรัฐอเมริกา: 877.457.5113; ต่างประเทศ: +1.803.808.4270) โดยได้รับความคุ้มครองจากแพ็คเกจการสนับสนุนระดับองค์กร ส่วนสก็อตต์ได้รับความช่วยเหลือที่ต้องการ ไม่ใช่จากทีมสนับสนุน แต่จากการซื้อบริการเพิ่มเติมเพื่อช่วยในการกำหนดค่าและการติดตั้ง แต่ในกรณีอื่นๆ สก็อตต์ อามอล โจน และคนอื่นๆ จะหาข้อมูลเพิ่มเติมเกี่ยวกับระดับการสนับสนุนและรายละเอียดการสนับสนุนได้จากที่ไหน หรือว่าผลิตภัณฑ์ของพวกเขาอยู่ในช่วงการบำรุงรักษาหรือการสนับสนุนเพิ่มเติมแล้วหรือไม่?

หากคุณต้องการข้อมูลเพิ่มเติมเกี่ยวกับข้อตกลงการสนับสนุน คุณสามารถดูข้อตกลงการสนับสนุนทางเทคนิคของ SIOS (TSA) ซึ่งรวมอยู่ในทุกคำสั่งซื้อ นอกจากนี้ คุณยังสามารถดู TSA ได้อย่างสะดวกบนเว็บไซต์ของเราเว็บไซต์ดาวน์โหลดและสามารถขอรับได้โดยส่งอีเมลไปยังทีมสนับสนุน SIOS ที่support@us.sios.comนอกจากนี้ คุณยังสามารถดูตารางกำหนดการผลิตและข้อมูลระดับการสนับสนุนได้ทางออนไลน์ที่ [ลิงก์เว็บไซต์]วงจรชีวิตของผลิตภัณฑ์หน้าหนังสือ.

ลูกค้าที่ทราบรายละเอียดความคุ้มครองภายใต้แผนประกันของตนอยู่แล้ว แต่ต้องการความช่วยเหลือเกี่ยวกับปัญหา คำตอบสำหรับคำถามทั่วไป การวิเคราะห์สาเหตุที่แท้จริง ซอฟต์แวร์เวอร์ชั่นล่าสุด หรือคำแนะนำเพิ่มเติม สามารถเปิดเคสใหม่ได้ผ่านทาง…พอร์ทัลสนับสนุนเยี่ยมชมเว็บไซต์หรือส่งอีเมลไปยังกล่องข้อความฝ่ายสนับสนุนที่support@us.sios.comเมื่อสร้างเคสของคุณแล้ว ทีมงานจะดำเนินการตอบกลับและแก้ไขปัญหาอย่างทันท่วงที

ผู้เขียน: คาสเซียส รู รองประธานฝ่ายประสบการณ์ลูกค้า

นำมาเผยแพร่ซ้ำโดยได้รับอนุญาตจากSIOS

เหตุใดสภาพแวดล้อมแบบแซนด์บ็อกซ์จึงมีความสำคัญต่อความพร้อมใช้งานสูง

การโน้มน้าวให้ฝ่ายบริหารลงทุนในโครงสร้างพื้นฐานที่ไม่เกี่ยวข้องกับการผลิต

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

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

10 คำถามที่จะช่วยให้เห็นถึงความเหมาะสมของสภาพแวดล้อมแบบแซนด์บ็อกซ์

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

1. เวลาที่ระบบหยุดทำงานนั้นทำให้องค์กรของเราเสียค่าใช้จ่ายไปเท่าไหร่กันแน่?

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

คำถามนี้ช่วยยกระดับการสนทนาจากคำกล่าวอ้างที่คลุมเครือไปสู่ต้นทุนต่อนาทีของรายได้ที่สูญเสียไป เงินเดือนพนักงานที่ไม่ได้ทำงานระหว่างที่ระบบล่ม และต้นทุนที่วัดได้ยากกว่าอย่างความเสียหายต่อชื่อเสียง หากการหยุดชะงักของการผลิตมีต้นทุน 300,000 ดอลลาร์ต่อชั่วโมง การป้องกันการหยุดชะงักเพียง 4 ชั่วโมงต่อปีจะช่วยประหยัดได้ถึง 1.2 ล้านดอลลาร์ เมื่อมีตัวเลขทางธุรกิจที่จับต้องได้แล้ว ผลตอบแทนจากการลงทุน (ROI) ของการนำระบบทดสอบ (sandbox) มาใช้เพื่อลดความเสี่ยงจากการหยุดชะงักที่มีต้นทุนสูงจึงชัดเจนยิ่งขึ้น

2. เราดำเนินการบำรุงรักษาจำนวนกี่ครั้งต่อเดือน?

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

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

ความเร็วในการออกเวอร์ชันใหม่และการอัปเดตบำรุงรักษาทำให้จำเป็นต้องมีระบบสำรองไว้รองรับมากขึ้น

3. เรามั่นใจแค่ไหนในการนำไปใช้งานจริง?

ทีมงานลุ้นระทึกทุกครั้งที่อัปเดตระบบลงในเวอร์ชันใช้งานจริงหรือเปล่า? เราได้ยินวลีที่ว่า “มันแค่เปลี่ยนบรรทัดเดียวเอง” บ่อยแค่ไหน? ข้อผิดพลาดเล็กๆ น้อยๆ เช่น “Off by one” และ “null pointer error” เคยทำให้ระบบล่มมาแล้วหลายครั้ง คุณมั่นใจแค่ไหนในความสามารถของทีมที่จะตรวจสอบให้แน่ใจว่าแพ็กเกจที่เพิ่งติดตั้งใหม่นั้นปราศจากข้อผิดพลาดในการเขียนโค้ด ข้อบกพร่องทางตรรกะ ปัญหาด้านสถาปัตยกรรม ความไม่เข้ากันกับโปรแกรมจากภายนอก หรือข้อผิดพลาดในการเรียงลำดับ?

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

4. เรายอมรับความเสี่ยงได้มากน้อยเพียงใดในการติดตั้งแพทช์รักษาความปลอดภัยโดยตรงในระบบการผลิต?

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

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

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

5. การทุจริตข้อมูลส่งผลกระทบทางการเงินและการดำเนินงานอย่างไรบ้าง?

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

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

6. เรายอมรับได้หรือไม่หากการเชื่อมต่อกับระบบของบุคคลที่สามล้มเหลวโดยไม่มีการแจ้งเตือน?

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

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

7. เราเตรียมพร้อมรับมือกับสถานการณ์ภัยพิบัติที่แท้จริงมากแค่ไหน?

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

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

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

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

9. เราจะดำเนินการรับผู้ขายรายใหม่และฝึกอบรมทีมงานที่มีอยู่ได้อย่างไร?

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

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

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

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

10. ค่าประกันภัยเครื่องมือ HA ถูกกว่าความเสียหายจากภัยพิบัติหรือไม่?

สุดท้ายนี้ เราต้องพูดถึงประเด็นสำคัญที่ทุกคนมองข้ามไป นั่นก็คือ ต้นทุนของเครื่องมือและอุปกรณ์ต่างๆ

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

สภาพแวดล้อมแบบแซนด์บ็อกซ์คือการลงทุนเพื่อความต่อเนื่องทางธุรกิจ

ดังที่ Tristan Allen วิศวกรซอฟต์แวร์ระดับผู้ช่วยของ SIOS สรุปไว้ในบล็อกของเขา:

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

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

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

ผู้เขียน: Cassius Rhue, รองประธานฝ่ายประสบการณ์ลูกค้าของ SIOS

นำมาเผยแพร่ซ้ำโดยได้รับอนุญาตจากSIOS

การสืบทอด DataKeeper

การรับช่วงต่อสภาพแวดล้อม DataKeeper หมายความว่าอย่างไร

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

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

ในโลกของไอที ​​การรับมรดกมีลักษณะเฉพาะทางดิจิทัล เมื่อผู้ดูแลระบบได้รับมรดกเป็นคลัสเตอร์ที่ใช้เครื่องมือต่างๆ เช่นดาต้าคีปเปอร์พวกเขาไม่ได้กำลังจัดการกับสินทรัพย์ที่จับต้องได้ เช่น เครื่องประดับหรืออสังหาริมทรัพย์ แต่เป็นทรัพยากรดิจิทัล—ลองนึกถึงการกำหนดค่า บทบาท และทรัพยากรปริมาณที่สำคัญ และในขณะที่หวังว่ามรดกนี้จะเป็นผลมาจากการที่ใครบางคนเกษียณอายุจากบริษัทหรือได้รับการเลื่อนตำแหน่งที่สมควรได้รับ เราก็ขอภาวนาว่ามันจะไม่ใช่เพราะใครบางคนย้ายไปทำงานที่ “ศูนย์ข้อมูลขนาดใหญ่บนท้องฟ้า” (ใช่แล้ว อารมณ์ขันเป็นกลไกการรับมือของมืออาชีพด้านไอที!)

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

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

คำถามเกี่ยวกับการบริหารจัดการบัญชี

รายละเอียดผู้จัดการบัญชี

• ปัจจุบันใครคือผู้จัดการบัญชีที่รับผิดชอบบัญชีนี้?
  • พวกเขามีข้อมูลติดต่ออะไรบ้าง (อีเมล เบอร์โทรศัพท์ ฯลฯ)?

ข้อมูลเกี่ยวกับใบอนุญาต

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

คำถามเกี่ยวกับการบริหารจัดการ DataKeeper

ความเข้าใจเกี่ยวกับสิ่งแวดล้อม

• ประเมินโครงสร้างพื้นฐานที่มีอยู่ ซึ่งรวมถึงคลัสเตอร์เฟลโอเวอร์ของ Windows Serverการติดตั้ง, เซิร์ฟเวอร์, พื้นที่จัดเก็บข้อมูล ฯลฯ
• ปัจจุบัน DataKeeper กำลังปกป้องเวิร์กโหลดและแอปพลิเคชันใดบ้าง?

การกำหนดค่าและการจัดการ

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

การบำรุงรักษาและการอัปเดตซอฟต์แวร์

• จะติดตามข่าวสารเกี่ยวกับการออกเวอร์ชันใหม่ การแก้ไขข้อบกพร่อง และการอัปเดตต่างๆ ของ DataKeeper ได้อย่างไร?

การทดสอบระบบสำรองและการกู้คืน

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

ทำความเข้าใจเกี่ยวกับการเป็นเจ้าของทรัพยากรและความสัมพันธ์ระหว่างกัน

เมื่อคุณเข้าใจเกี่ยวกับมรดกของคุณมากที่สุดแล้ว ขั้นตอนต่อไปคือการเริ่มดูแลสิ่งที่คุณได้รับมา ดังที่แสดงในภาพประกอบด้านบน เมื่อ “ได้รับมรดก” กรรมสิทธิ์ในทรัพย์สินคลัสเตอร์ SQL Serverการระบุและสื่อสารกับทีมงานข้ามสายงานทั้งหมดที่ได้รับผลกระทบจากการบริหารจัดการคลัสเตอร์นั้นมีความสำคัญอย่างยิ่ง โดยมีประเด็นสำคัญเพียงไม่กี่ประเด็น (เนื่องจากมีอยู่มากมาย) ที่ควรให้ความสำคัญ ได้แก่:

ทีม SQL Server หรือทีมแอปพลิเคชัน

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

ทีมเครือข่าย

• แจ้งแผนการย้ายบทบาท SQL หรือทรัพยากรที่เกี่ยวข้องไปยังเครือข่ายอื่น
• แจ้งข้อมูลเกี่ยวกับที่อยู่ IP ใหม่หรือการเปลี่ยนแปลงอื่นๆ ที่เกี่ยวข้องกับเครือข่ายซึ่งอาจส่งผลกระทบต่อการทำงานของคลัสเตอร์

ทีมจัดเก็บ

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

เหตุใด Runbook จึงมีความสำคัญในสภาพแวดล้อมของ DataKeeper:

คู่มือการปฏิบัติงาน (Runbook) เป็นส่วนสำคัญของการดำเนินงานที่ราบรื่น และเป็นแนวทางแก้ไขที่ดีเยี่ยมสำหรับสภาพแวดล้อมที่ใช้ DataKeeper สำหรับผู้ดูแลระบบคลัสเตอร์และเทคโนโลยีที่เกี่ยวข้อง โดยในอุดมคติแล้ว คู่มือการปฏิบัติงานที่ดีควรเป็น “เอกสารที่มีชีวิต” ที่พัฒนาไปเรื่อย ๆ ตามกาลเวลา สะท้อนถึงการเปลี่ยนแปลงในโครงสร้างพื้นฐาน กระบวนการทำงาน และแนวทางปฏิบัติที่ดีที่สุด หากผู้ดูแลระบบก่อนหน้านี้ได้ดำเนินการอย่างรอบคอบแล้ว คู่มือการปฏิบัติงานของคุณควรครอบคลุมเนื้อหาอย่างครบถ้วนในหัวข้อต่อไปนี้:

• ซ่อมแซม/แก้ไขปัญหา:ดำเนินการแก้ไขปัญหาที่ทราบแล้ว ซึ่งอาจเกิดขึ้นได้ทุกที่ใน “ลำดับชั้น” เช่น ตั้งแต่ชั้นกายภาพไปจนถึงชั้นแอปพลิเคชัน
• ขั้นตอนการทำงาน:การติดตั้งซอฟต์แวร์และการจัดการการดำเนินงานคลัสเตอร์ประจำวัน
• การซ่อมบำรุง:อย่างไรการจัดการแพทช์ดำเนินการสำรองข้อมูลฐานข้อมูล ฯลฯ
• การสนับสนุนจากผู้จำหน่าย:วิธีเข้าถึง SIOSไมโครซอฟต์, AWS และผู้ให้บริการรายอื่นๆ
  • สิ่งสำคัญที่สุดคือ เราควร “ติดต่อ” พวกเขาเมื่อไร?

ประเด็นสำคัญสำหรับการรับช่วงต่อ DataKeeper

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

ขอให้คุณมีความสุขกับ “มรดก” ของคุณ…

อย่าใช้เงินทั้งหมดในที่เดียว…

ขอทดลองใช้งานเพื่อดูว่า SIOS DataKeeper สามารถช่วยลดความซับซ้อนในการบริหารจัดการคลัสเตอร์และรองรับความพร้อมใช้งานสูงได้อย่างไร

ผู้เขียน: เกร็ก ทักเกอร์ วิศวกรสนับสนุนผลิตภัณฑ์อาวุโส บริษัท SIOS

นำมาเผยแพร่ซ้ำโดยได้รับอนุญาตจากSIOS

ความพร้อมใช้งานสูง (High Availability) กับการทนต่อความผิดพลาด (Fault Tolerance): ความแตกต่างที่สำคัญ อธิบายไว้แล้ว

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

ความพร้อมใช้งานสูง (High Availability) คืออะไร?

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

ความพร้อมใช้งานสูงสามารถเป็นได้สาม (99.9%) หรือสี่(99.99%)หรือเลขเก้าห้าตัว (99.999%) โดยเลขเก้าแต่ละตัวแสดงถึงระยะเวลาการทำงานที่คาดหวังของโครงสร้างพื้นฐาน มาตรฐานคือ 99.99% ซึ่งระยะเวลาหยุดทำงานที่คาดหวังต่อปีคือ 52.60 นาที

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

การทนต่อความผิดพลาดคืออะไร?

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

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

การเปรียบเทียบต้นทุนระหว่างระบบความพร้อมใช้งานสูงกับระบบทนต่อความผิดพลาด

ในการเปรียบเทียบระหว่างระบบที่มีความพร้อมใช้งานสูง (High Availability) กับระบบที่ทนต่อความผิดพลาด (Fault Tolerance) โดยทั่วไปแล้วโครงสร้างพื้นฐานที่ทนต่อความผิดพลาดจะมีต้นทุนสูงกว่าโครงสร้างพื้นฐานที่มีความพร้อมใช้งานสูง เนื่องจากมีการใช้ซอฟต์แวร์และฮาร์ดแวร์ในปริมาณที่มากกว่า การบำรุงรักษาโครงสร้างพื้นฐานที่ทำงานได้อย่างต่อเนื่องและมีเวลาหยุดทำงานน้อยมาก จะต้องใช้ฮาร์ดแวร์และซอฟต์แวร์สำรองที่มากกว่า

กรณีการใช้งานที่มีความพร้อมใช้งานสูง

ความพร้อมใช้งานสูงในบริการทางการเงิน

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

ความพร้อมใช้งานสูงสำหรับบริการสตรีมมิ่ง

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

กรณีการใช้งานการทนต่อข้อผิดพลาด

การทนต่อความผิดพลาดในด้านการดูแลสุขภาพ

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

การทนต่อข้อผิดพลาดสำหรับเว็บไซต์

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

สรุป: ความพร้อมใช้งานสูงเทียบกับการทนต่อความผิดพลาด

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

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

ผู้เขียน: อเล็กซัส กอร์, วิศวกรซอฟต์แวร์ด้านประสบการณ์ลูกค้า บริษัท SIOS Technology Corp.

นำมาเผยแพร่ซ้ำโดยได้รับอนุญาตจากSIOS

การวางแผนความต่อเนื่องทางธุรกิจเพื่อความพร้อมใช้งานสูงและการกู้คืนจากภัยพิบัติ

เหตุใดทุกธุรกิจจึงต้องการกลยุทธ์เพื่อความต่อเนื่องทางธุรกิจและความพร้อมใช้งานสูง

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

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

แผนความต่อเนื่องทางธุรกิจคืออะไร?

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

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

องค์ประกอบสำคัญของแผนความต่อเนื่องทางธุรกิจ

แผนความต่อเนื่องทางธุรกิจโดยทั่วไปประกอบด้วย:

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

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

คำอธิบายเกี่ยวกับความพร้อมใช้งานสูง (High Availability)

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

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

ความสำคัญของการจัดการเวลาการทำงาน (Uptime Management)

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

แนวทางปฏิบัติทั่วไปในการบริหารจัดการเวลาการทำงานของระบบ ได้แก่:

• การตรวจสอบสถานะการทำงานของแอปพลิเคชันและเซิร์ฟเวอร์
• การนำระบบสำรองมาใช้ในระบบต่างๆ
• กระบวนการสลับระบบอัตโนมัติ
• รักษาความสม่ำเสมอในการแก้ไขข้อบกพร่องและการอัปเดต

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

ประโยชน์ของการมีระบบพร้อมใช้งานสูงในธุรกิจ

ความพร้อมใช้งานสูงนำมาซึ่งประโยชน์สำคัญหลายประการ:

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

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

การวางแผนการฟื้นฟูหลังภัยพิบัติ

การกู้คืนระบบไอทีหลังภัยพิบัติคืออะไร?

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

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

ขั้นตอนในการพัฒนากลยุทธ์การฟื้นฟูหลังภัยพิบัติที่มีประสิทธิภาพ

มีประสิทธิภาพการวางแผนการฟื้นฟูหลังภัยพิบัติโดยทั่วไปจะประกอบด้วย:

1. การระบุแอปพลิเคชันและโครงสร้างพื้นฐานที่สำคัญ
2. การกำหนดวัตถุประสงค์ในการฟื้นฟู เช่น RTO และ RPO
3. การนำระบบสำรองข้อมูลและการจำลองข้อมูลมาใช้
4. เอกสารขั้นตอนการกู้คืน
5. ทดสอบสถานการณ์การกู้คืนอย่างสม่ำเสมอ

ขั้นตอนเหล่านี้ช่วยให้องค์กรสามารถฟื้นตัวได้อย่างรวดเร็วและหลีกเลี่ยงการหยุดชะงักเป็นเวลานาน

การปรับสมดุลภาระงานเพื่อประสิทธิภาพและความน่าเชื่อถือ

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

ประเภทของเทคนิคการกระจายภาระงาน

เทคนิคการปรับสมดุลภาระงานที่ใช้กันทั่วไป ได้แก่:

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

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

กลยุทธ์การจำลองข้อมูล

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

กลยุทธ์การจำลองข้อมูลที่ใช้กันทั่วไป ได้แก่:

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

การจำลองภาพสแนปช็อตสำหรับการสำรองข้อมูลเป็นระยะ

แนวทางปฏิบัติที่ดีที่สุดสำหรับการนำการจำลองข้อมูลไปใช้

เพื่อให้มั่นใจได้ว่าการจำลองข้อมูลมีความน่าเชื่อถือ:

• จำลองข้อมูลข้ามโครงสร้างพื้นฐานหรือภูมิภาคต่างๆ
• ปรับการจำลองให้สอดคล้องกับวัตถุประสงค์ของการฟื้นฟู
• ตรวจสอบประสิทธิภาพการจำลองข้อมูล
• ทดสอบกระบวนการสลับระบบเมื่อเกิดข้อผิดพลาดเป็นประจำ

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

เสริมสร้างความต่อเนื่องทางธุรกิจและความพร้อมใช้งานสูง

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

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

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

ผู้เขียน: เบน รอย ผู้เชี่ยวชาญด้านการตลาดของ SIOS

นำมาเผยแพร่ซ้ำโดยได้รับอนุญาตจากSIOS