3 ความท้าทายในการรักษาความพร้อมใช้งานสูงด้วยโครงสร้างพื้นฐานแบบดั้งเดิม

3 ความท้าทายในการรักษาความพร้อมใช้งานสูงด้วยโครงสร้างพื้นฐานแบบดั้งเดิม

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

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

นี่คือตัวอย่างปัญหาบางประการที่คุณอาจพบเจอได้กับโครงสร้างพื้นฐานที่เก่ากว่า:

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

วางแผนการปรับปรุงโครงสร้างพื้นฐานให้ทันสมัยเป็นส่วนหนึ่งของกลยุทธ์ความพร้อมใช้งานสูงของคุณ

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

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

ผู้เขียน: Cassy Hendricks-Sinke, วิศวกรระบบอาวุโส, ฝ่ายปฏิบัติการด้านไอที, SIOS

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

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

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

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

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

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

บล็อกที่เกี่ยวข้องและคำแนะนำสำหรับการอ่านเพิ่มเติม

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

• คลัสเตอร์ลินุกซ์/คลัสเตอร์ Windows(ขอขอบคุณคุณโฮกลันด์ รองประธานฝ่ายขายและการตลาดระดับโลกของ SIOS และทีมการตลาดของ SIOS ที่ได้เขียนบทความนี้)

• ความชาญฉลาดของแอปพลิเคชันที่เกี่ยวข้องกับความพร้อมใช้งานสูง(เขียนโดย คุณเฮนดริกส์-ซิงค์ วิศวกรซอฟต์แวร์อาวุโส บริษัท SIOS)
• การดำเนินการเกี่ยวกับทรัพยากรและข้อมูลเบื้องหลังชุดกู้คืนแอปพลิเคชันทั่วไป(เขียนโดยคุณเบอร์มิงแฮม ผู้เชี่ยวชาญด้านเทคโนโลยีอาวุโส)
• การเลือกใช้ระหว่าง GenApp และ QSP: ปรับแต่งระบบความพร้อมใช้งานสูงสำหรับแอปพลิเคชันที่สำคัญของคุณ(ขอขอบคุณคุณเฮนดริกส์-ซิงค์ วิศวกรซอฟต์แวร์อาวุโสของ SIOS สำหรับบทความนี้)

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

การวางแนวคิดเกี่ยวกับแอปพลิเคชันและการกำหนดแนวทาง

การถามคำถามเล็กๆ น้อยๆ เกี่ยวกับสถานะของแอปพลิเคชัน

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

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

“กระบวนการทำงานของแอปพลิเคชันกำลังทำงานอยู่หรือไม่ และแอปพลิเคชันกำลังตอบสนองต่อคำถามอยู่หรือไม่?”

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

แม้ว่าคำถามจะสามารถแบ่งย่อยได้แทบไม่จำกัด แต่ก็มีขีดจำกัดอยู่ การถามว่า “คำถามที่เล็กที่สุด?” นั้นหมายความว่า “เป็นการถามคำถามที่เล็กที่สุดที่ยังคงให้ข้อมูลที่เป็นประโยชน์/นำไปปฏิบัติได้” การถามว่า “ฉันอยู่บนรถไฟไปฟิลาเดลเฟียหรือไม่?” นั้นเพียงพอแล้ว การถามต่อว่า “ฉันอยู่บนรถไฟไปฟิลาเดลเฟียหรือไม่ และฟิลาเดลเฟียอยู่ทิศไหน?” นั้นให้ข้อมูลเพิ่มเติม แต่ก็ไม่สามารถนำไปปฏิบัติได้ ฉันไม่สามารถเปลี่ยนทิศทางของรถไฟได้ ฉันรู้จากคำตอบของคำถาม “ฉันอยู่บนรถไฟไปฟิลาเดลเฟียหรือไม่?” ว่าฉันต้องโทรไปแจ้งเจ้านายว่าฉันจะมาสายหรือไม่

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

คำถามกว้างๆ ที่ถูกแบ่งย่อยออกเป็นคำถามเล็กๆ ที่เฉพาะเจาะจงและมุ่งเป้าไปที่องค์ประกอบแต่ละส่วน คือพื้นฐานในการสร้างชุดเครื่องมือการกู้คืนแอปพลิเคชันทั่วไป (Generic Application Recovery Kits) แต่ละ “คำถามใหญ่” สามารถตอบได้ด้วยการรวบรวมคำตอบที่ให้ไว้สำหรับแต่ละองค์ประกอบที่เกี่ยวข้อง

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

การทำงานร่วมกับ Application API และ LifeKeeper API

บ่อยครั้งที่แอปพลิเคชันมีส่วนติดต่อผู้ใช้แบบกราฟิก (GUI) เพื่อแสดงข้อมูลหรือแสดงการเปลี่ยนแปลงที่เกิดขึ้นกับแอปพลิเคชัน แม้ว่าจะเป็นเรื่องยอดเยี่ยมสำหรับการใช้งานโดยมนุษย์ แต่ก็มีประโยชน์น้อยลงเมื่อการจัดการทำโดยแอปพลิเคชัน GUI มีไว้สำหรับให้คนใช้งาน และแอปพลิเคชัน (โดยไม่ต้องใช้ความพยายามในการเขียนโปรแกรมจำนวนมากและความซับซ้อนที่ไม่จำเป็น) ไม่ได้ถูกออกแบบมาให้เชื่อมต่อกับ GUI ของแอปพลิเคชันอื่นเหมือนที่มนุษย์ทำ สำหรับวัตถุประสงค์ของ LifeKeeper และ Generic Application Resource การแลกเปลี่ยนข้อมูลระหว่างสคริปต์การทำงานของ Generic Application Recovery Kit และแอปพลิเคชันที่ได้รับการปกป้องจะต้องทำผ่าน Application Programming Interface หรือ “API”

LifeKeeper มี API ของตัวเองสำหรับการโต้ตอบกับ LifeKeeper, ลำดับชั้น และทรัพยากรภายในลำดับชั้นนั้น ในกรณีของ API ของ LifeKeeper นั้น ยูทิลิตี้บรรทัดคำสั่งที่มีอยู่ในผลิตภัณฑ์นั้นใช้งานง่ายที่สุดในแอปพลิเคชันทั่วไป โดยทั่วไปแล้ว ขอแนะนำให้ใช้เฉพาะยูทิลิตี้บรรทัดคำสั่งที่ระบุไว้ในเอกสารประกอบผลิตภัณฑ์ LifeKeeper เท่านั้น (เอกสารคำสั่ง Linux/เอกสารคำสั่งของ Windowsควรใช้คำสั่งดังกล่าว แม้จะมีคำแนะนำนี้ แต่ก็ควรใช้คำสั่งเหล่านี้ด้วยความระมัดระวังและใส่ใจในรายละเอียด เพื่อให้แน่ใจว่าจะไม่มีการกระทำที่ไม่พึงประสงค์เกิดขึ้น

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

การใช้รหัสส่งคืนและสตรีมเอาต์พุตในสคริปต์การกู้คืน

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

• รหัสส่งคืน
• ช่องสัญญาณเอาต์พุต (บางครั้งเรียกว่า “เอาต์พุต STDOUT/STDERR” หรือ “เอาต์พุตเทอร์มินัล”)

รหัสส่งคืนช่วยในการตัดสินว่าการดำเนินการสำเร็จหรือล้มเหลวอย่างไร

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

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

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

สตรีมเอาต์พุตให้ข้อมูลแอปพลิเคชันที่ละเอียดมากขึ้นได้อย่างไร

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

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

การสร้างรากฐานสำหรับการปกป้องแอปพลิเคชันทั่วไป

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

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

ผู้เขียน: ฟิลิป เมอร์รี, วิศวกรฝ่ายสนับสนุนระดับ L3 บริษัท SIOS Technology Corp.

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

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

คู่มือการสนับสนุน 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

การรับช่วงต่อสภาพแวดล้อม 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