การสังเกตและการคำนวณ: การนำประสบการณ์ไปใช้เพื่อการตัดสินใจทางธุรกิจที่ดีขึ้น

การสังเกตและการคำนวณ: การนำประสบการณ์ไปใช้เพื่อการตัดสินใจทางธุรกิจที่ดีขึ้น

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

เหตุใดการสังเกตจึงมีความสำคัญต่อการตัดสินใจที่ดีขึ้น

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

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

นำประสบการณ์มาใช้เพื่อปรับปรุงการตัดสินใจในอนาคต

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

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

วัฏจักรของการสังเกตและการคำนวณ

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

การประยุกต์ใช้การสังเกตในการประชุมและความสัมพันธ์ทางธุรกิจ

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

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

สิ่งสำคัญที่คุณอาจต้องการบันทึกข้อสังเกตของคุณ ได้แก่:

• จังหวะเวลา
• วัฒนธรรมที่สังเกตได้
• ประวัติศาสตร์ที่บอกเล่า
• รายชื่อผู้เข้าร่วม (พร้อมหน้าที่ความรับผิดชอบ)
• ข้อกังวลที่นำเสนอ

จากนั้น เมื่อคุณต้องทำซ้ำอีกครั้ง คุณสามารถย้อนกลับไปดูข้อสังเกตต่างๆ และเริ่มตั้งคำถามเช่น:

• “ครั้งต่อไปฉันจะทำอย่างไรให้ดีขึ้นได้?” หรือ “ฉันจะทำแบบนี้ได้อย่างไร?”
• “ฉันจะทำอย่างไรถ้าพวกเขาพูดแบบนี้แทน?”

นั่นเป็นผลการคำนวณของคุณ

สร้างวิจารณญาณทางธุรกิจที่ดีขึ้นผ่านประสบการณ์

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

ผู้เขียน: แมทธิว พอลลาร์ด

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

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

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

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

ทัศนคตินั้นกำลังเปลี่ยนแปลงไป

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

ความพร้อมใช้งานสูง (High Availability: HA) และการกู้คืนจากภัยพิบัติ (Disaster Recovery: DR) ไม่ได้เป็นเพียงแค่ข้อกำหนดทางเทคนิคอีกต่อไป แต่เป็นส่วนสำคัญของการดำเนินธุรกิจอย่างต่อเนื่อง การจัดการความเสี่ยง และความยืดหยุ่นในระยะยาว

ประเด็นสำคัญ

• การหยุดทำงานเป็นความเสี่ยงขององค์กร:ความพร้อมใช้งานสูงและการกู้คืนระบบหลังภัยพิบัติไม่ใช่แค่ภารกิจของฝ่ายไอทีอีกต่อไป แต่เป็นสิ่งสำคัญยิ่งต่อรายได้ ความน่าเชื่อถือของแบรนด์ และความต่อเนื่องทางธุรกิจ
• ความสามารถในการรับมือกับภัยคุกคามทางไซเบอร์เป็นสิ่งจำเป็น:เนื่องจากแรนซัมแวร์มุ่งเป้าไปที่ข้อมูลสำรอง ระบบกู้คืนภัยพิบัติสมัยใหม่จึงต้องการโครงสร้างพื้นฐานที่แยกจากเครือข่ายและไม่สามารถเปลี่ยนแปลงได้ เพื่อรับประกันการกู้คืนที่สมบูรณ์แบบ
• ความซับซ้อนจำเป็นต้องใช้ระบบอัตโนมัติ:สภาพแวดล้อมแบบไฮบริด มัลติคลาวด์ และคอนเทนเนอร์สมัยใหม่ ต้องการการสลับระบบอัตโนมัติและการตรวจสอบด้วย AI เพื่อจัดการความยืดหยุ่นได้อย่างมีประสิทธิภาพ
• การทดสอบเชิงรุกเป็นสิ่งสำคัญ:เทคนิคต่างๆ เช่น วิศวกรรมความโกลาหล (Chaos Engineering) ช่วยให้ทีมไอทีสามารถตรวจสอบความพร้อมในการกู้คืนระบบได้โดยไม่รบกวนการทำงานของระบบหลัก
• ผสานความยืดหยุ่นเข้ากับผลกระทบทางธุรกิจ:เป้าหมายเวลาในการกู้คืน (RTOs) และเป้าหมายจุดกู้คืน (RPOs)ต้องเป็นไปตามความต้องการทางการเงิน การดำเนินงาน และข้อกำหนดทางกฎหมายที่เฉพาะเจาะจง

การคำนวณต้นทุนที่แท้จริงของการหยุดทำงานของระบบไอที

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

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

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

ความซับซ้อนของระบบคลาวด์และไอทีแบบไฮบริดส่งผลกระทบต่อการกู้คืนระบบหลังภัยพิบัติอย่างไร

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

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

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

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

การผสานรวมระบบ HA และ DR เข้ากับการดำเนินงานด้านไอทีประจำวัน

ความพร้อมใช้งานสูง (High Availability: HA) และการกู้คืนจากภัยพิบัติ (Disaster Recovery: DR) เคยถูกมองว่าเป็นศาสตร์ที่แยกจากกัน HA มุ่งเน้นไปที่การรักษาระบบให้ทำงานต่อไปได้ในระหว่างที่เกิดความล้มเหลวในระดับท้องถิ่น ในขณะที่ DR มุ่งเน้นไปที่การกู้คืนจากเหตุการณ์หยุดชะงักในวงกว้าง เช่น การหยุดทำงานของศูนย์ข้อมูล เหตุการณ์ในระดับภูมิภาค หรือภัยพิบัติทางธรรมชาติ

ในปัจจุบัน องค์กรต่างๆ จำเป็นต้องมีแนวทางที่เป็นหนึ่งเดียวกันมากขึ้น

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

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

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

ทดสอบความล้มเหลวก่อนที่จะเกิดขึ้น

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

การทดสอบความยืดหยุ่นแบบควบคุม ซึ่งรวมถึงแนวทางปฏิบัติเช่น วิศวกรรมความโกลาหล สามารถช่วยได้

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

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

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

ระบบอัตโนมัติเป็นสิ่งจำเป็นสำหรับความยืดหยุ่น

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

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

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

ลำดับความสำคัญทางธุรกิจควรเป็นตัวกำหนดแนวทางการคุ้มครอง

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

ด้วยเหตุนี้ การวางแผน HA และ DR จึงควรเริ่มต้นด้วยผลกระทบต่อธุรกิจ

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

วิธีนี้ช่วยหลีกเลี่ยงปัญหาทั่วไปสองประการ ได้แก่ การปกป้องเวิร์กโหลดที่ไม่สำคัญมากเกินไป และการปกป้องระบบที่จำเป็นน้อยเกินไป

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

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

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

การสร้างวัฒนธรรมแห่งความพร้อม

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

องค์กรที่มีความยืดหยุ่นสูงที่สุดไม่ได้เพียงแค่สร้างระบบสำรองเท่านั้น แต่ยังสร้างวัฒนธรรมแห่งความพร้อมอีกด้วย

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

การเตรียมความพร้อมไม่ใช่โครงการที่ทำเพียงครั้งเดียว แต่เป็นวินัยที่ต้องทำอย่างต่อเนื่อง

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

บทสรุป

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

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

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

เป้าหมายไม่ใช่แค่การฟื้นตัวหลังจากความล้มเหลวอีกต่อไปแล้ว เป้าหมายคือการทำให้ธุรกิจดำเนินต่อไปได้อย่างต่อเนื่อง!

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

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

การตอบสนองต่อเหตุการณ์ฉุกเฉินและการฟื้นฟูหลังภัยพิบัติ: วินัยแห่งการไม่ตอบสนองอย่างหุนหันพลันแล่น

การตอบสนองต่อเหตุการณ์ฉุกเฉินและการฟื้นฟูหลังภัยพิบัติ: วินัยแห่งการไม่ตอบสนองอย่างหุนหันพลันแล่น

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

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

เหตุใดการตอบสนองต่อเหตุการณ์อย่างหุนหันพลันแล่นจึงอาจเพิ่มความเสี่ยง

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

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

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

ความแตกต่างระหว่างการสังเกตและการตั้งสมมติฐาน

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

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

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

เหตุใดการแก้ไขปัญหาอย่างมีระเบียบวินัยจึงมีความสำคัญในระหว่างที่ระบบขัดข้อง

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

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

บทบาทของระบบอัตโนมัติในการกู้คืนระบบหลังภัยพิบัติ

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

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

SIOS LifeKeeper ช่วยสนับสนุนการตัดสินใจฟื้นฟูร่างกายอย่างชาญฉลาดได้อย่างไร

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

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

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

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

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

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

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

เขียนโดย เอดัน แม็คเลน (ผู้ช่วยผู้เชี่ยวชาญด้านการสนับสนุนผลิตภัณฑ์)

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

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

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

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

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

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

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

ทบทวนอย่างรวดเร็ว

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

เนื่องจากบทความนี้ในชุดบทความนี้ควรพิจารณาควบคู่ไปกับบทความก่อนหน้า ดังนั้นนี่คือการทบทวนสั้นๆ เกี่ยวกับแนวคิดที่นำเสนอในบทความที่ 1

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

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

ใช้ข้อมูลที่ให้มา

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

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

คิดแบบไลฟ์คีปเปอร์

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

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

• กู้คืนการดำเนินการ: เริ่มแอปพลิเคชัน
• ลบการดำเนินการ: หยุดการทำงานของแอปพลิเคชัน
• การดำเนินการ quickCheck: แอปพลิเคชันสอบถามข้อมูล
  • บันทึกการดำเนินการ QuickCheck เป็นทางเลือกสำหรับทรัพยากรแอปพลิเคชันทั่วไป และการตรวจสอบจะไม่เกิดขึ้นหากไม่ได้กำหนดการดำเนินการ QuickCheck ไว้ อย่างไรก็ตาม ขอแนะนำอย่างยิ่งให้ตรวจสอบแอปพลิเคชันเป็นประจำเพื่อให้ได้ผลลัพธ์ที่ดีที่สุดสำหรับการใช้งานระบบความพร้อมใช้งานสูงและการกู้คืนจากภัยพิบัติ!
• การดำเนินการฟื้นฟูในระดับท้องถิ่น: หยุดแอปพลิเคชันและเริ่มแอปพลิเคชัน (ตามลำดับ)
  • บันทึกการดำเนินการกู้คืนภายในเครื่อง (Local Recovery Actions) เป็นตัวเลือกเสริมสำหรับทรัพยากรแอปพลิเคชันทั่วไป (Generic Application Resources) หากไม่ได้กำหนดการดำเนินการกู้คืนภายในเครื่องไว้ ทรัพยากรแอปพลิเคชันทั่วไปจะไม่พยายามเริ่มต้นใหม่เพื่อซ่อมแซมตัวเองบนระบบที่ตรวจพบความล้มเหลว แต่จะหยุดทำงานบนระบบที่ล้มเหลว และลำดับชั้นทั้งหมดของแอปพลิเคชันจะย้ายไปยังระบบสำรอง

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

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

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

บทสรุป

LifeKeeper มีวิธีการมากมายในการปกป้องแอปพลิเคชัน แต่บางแอปพลิเคชันก็มีความต้องการที่นอกเหนือไปจากสิ่งที่ LifeKeeper Application Recovery Kits นำเสนอ ในกรณีเช่นนี้ การปกป้องระบบที่มีความพร้อมใช้งานสูงและการกู้คืนจากภัยพิบัติยังคงเป็นไปได้ และอาจทำได้ง่ายกว่าที่คิดไว้ แอปพลิเคชันทั่วไปไม่ใช่สิ่งที่องค์กรควรหลีกเลี่ยง แต่เป็นหนึ่งในเครื่องมือที่มีประสิทธิภาพมากมายที่ LifeKeeper นำเสนอเพื่อยกระดับความสามารถด้านความพร้อมใช้งานสูงและการกู้คืนจากภัยพิบัติของสภาพแวดล้อม เฟรมเวิร์กแอปพลิเคชันทั่วไปถูกสร้างขึ้นเพื่อให้เข้าถึงได้ง่ายและใช้งานได้หลากหลาย แต่หากองค์กรของคุณไม่มีทรัพยากรเพียงพอที่จะเขียนชุดกู้คืนแอปพลิเคชันทั่วไปด้วยตนเอง SIOS ก็มีบริการระดับมืออาชีพที่วิศวกรของ SIOS จะประสานงานความต้องการและพัฒนาชุดกู้คืนแอปพลิเคชันทั่วไปในนามขององค์กรของคุณ หากต้องการการสนับสนุนอย่างต่อเนื่อง บริการระดับมืออาชีพของ SIOS ยังมีบริการที่ขยายการสนับสนุนผลิตภัณฑ์ปกติให้ครอบคลุมถึงแอปพลิเคชันทั่วไปที่พัฒนาโดยบริการระดับมืออาชีพของ SIOS ด้วย อุปสรรคในการเข้าถึงการปกป้องแอปพลิเคชันที่สำคัญต่อธุรกิจขององค์กรของคุณนั้นลดลงเรื่อยๆ และ SIOS Protection Suite สำหรับ Linux หรือ Windows มุ่งมั่นที่จะเป็นผู้นำในการทำให้แอปพลิเคชันที่ไม่ได้รับการปกป้องกลายเป็นเรื่องในอดีต

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

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

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

การเข้าควบคุม SIOS LifeKeeper สำหรับคลัสเตอร์ Linux

การเข้าควบคุม SIOS LifeKeeper สำหรับคลัสเตอร์ Linux

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

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

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

พูดตามตรง โอกาสที่ทีม A-Team ตัวจริงหรือเวอร์ชั่นใดๆ ที่คล้ายกันจะขับรถมินิแวนมาจอดข้างๆ คุณแล้วพาคุณไปร่วมภารกิจลับสุดยอดที่สำคัญยิ่งยวดเพื่อช่วยชาติคงเป็นไปได้ยาก เช่นเดียวกัน การเลียนแบบ Jimi Hendrix หรือ Sheila E ที่ดีที่สุดของคุณ ไม่ว่าจะใช้หลอดดูดขนาดใหญ่หรือไม่ก็ตาม ก็คงไม่ทำให้คุณโดดเด่นจากฝูงชนขึ้นไปอยู่บนเวทีคอนเสิร์ตที่ขายบัตรหมดเกลี้ยงได้ และถึงแม้คุณอาจจะได้เจอกับ Carlos หรือผู้เข้าแข่งขันคนโปรดหรือผู้ชนะคนอื่นๆ แต่ถ้าคุณไม่ใช่เจ้าของ ผู้ฝึกสอน หรือกรรมการ คุณก็คงไม่ได้ใช้เวลาอยู่กับพวกเขาโดยลำพัง ถึงแม้สถานการณ์เหล่านี้จะไม่น่าเกิดขึ้น แต่ก็เป็นไปได้ที่คุณอาจถูกขอให้ดูแลคลัสเตอร์ LifeKeeper สำหรับ Linux ซึ่งมาพร้อมกับความเสี่ยง ความรับผิดชอบ และความสำคัญที่คล้ายคลึงกัน

สิ่งที่ควรทำเมื่อคุณได้รับมรดกเป็นคลัสเตอร์ LifeKeeper สำหรับ Linux

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

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

แล้วคุณจะทำอย่างไรหากจู่ๆ คุณต้องรับผิดชอบในฐานะผู้ดูแลระบบหลักหรือผู้ใช้งานเพียงคนเดียวของสภาพแวดล้อม LifeKeeper for Linux (LK-L) ที่สร้างรายได้มากกว่าซอฟต์แวร์ Carlos หลายสิบเวอร์ชัน?

8 ขั้นตอนในการเข้าควบคุมคลัสเตอร์ SIOS LifeKeeper สำหรับ Linux

แปดขั้นตอนสำคัญในการเข้าควบคุมคลัสเตอร์ SIOS LifeKeeper สำหรับ Linux มีดังนี้:

1. ค้นหาและตรวจสอบคู่มือการปฏิบัติงานที่มีอยู่

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

2. ค้นหารุ่นผลิตภัณฑ์ LifeKeeper for Linux ของคุณ

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

1. ผลิตภัณฑ์ของคุณอยู่ในช่วงใดของวงจรชีวิตผลิตภัณฑ์และการสนับสนุน?
2. คุณใช้ผลิตภัณฑ์เวอร์ชันล่าสุดอยู่หรือไม่?
3. มีการเพิ่มฟีเจอร์ใหม่หรือแก้ไขข้อบกพร่องอะไรบ้างในผลิตภัณฑ์นับตั้งแต่เวอร์ชันที่คุณใช้งาน?
4. จะหาเอกสารเฉพาะเวอร์ชันได้จากที่ไหน?

คุณสามารถตรวจสอบเวอร์ชันของผลิตภัณฑ์ได้ผ่านทาง UI หากคู่มือการใช้งานของคุณระบุว่า LifeKeeper เป็นเวอร์ชัน 9.8.x หรือใหม่กว่า คุณสามารถใช้ https://<servername>:5110 (หรือ https://<server_IP>:5110) เพื่อเปิดใช้งาน LifeKeeper Web Management Console (LKWMC) เมื่อเข้าสู่ระบบแล้ว ให้เลือกคุณสมบัติ:

หลังจากหน้าคุณสมบัติโหลดเสร็จแล้ว ให้ค้นหาข้อมูลเวอร์ชันของคุณในส่วนที่อยู่ใต้ชื่อผลิตภัณฑ์:

หากคุณใช้ LifeKeeper เวอร์ชันเก่าสำหรับ Linuxเปิดใช้งานการส่งต่อ X11 และเรียกใช้ Java UIผ่านคำสั่ง /opt/LifeKeeper/bin/lkGUIapp จากเซสชันไคลเอ็นต์ SSH

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

# rpm -qi steeleye-lk

เมื่อคุณเปิดใช้งาน Java UI และเข้าสู่ระบบแล้ว คุณจะสามารถไปยังส่วนช่วยเหลือได้ เมื่อคุณได้รับเวอร์ชันผลิตภัณฑ์แล้ว โปรดตรวจสอบวงจรชีวิตผลิตภัณฑ์และข้อมูลเฉพาะเวอร์ชันผ่านทางdocs.us.sios.com

3. ตรวจสอบข้อตกลงการสนับสนุนทางเทคนิคของคุณ

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

4. เข้ารับการฝึกอบรมผู้ดูแลระบบ SIOS

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

5. สร้างคลัสเตอร์สาธิตหรือทดสอบ

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

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

1. การสลับด้วยตนเอง
2. การสลับเซิร์ฟเวอร์เมื่อเกิดข้อผิดพลาด
3. การกู้คืนแอปพลิเคชัน
4. การบำรุงรักษา

6. กำหนดเวลาตรวจสอบสุขภาพของกลุ่มคลัสเตอร์

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

7. ใช้ประโยชน์จากการสนับสนุนและบริการระดับมืออาชีพของ SIOS

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

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

8. ติดต่อสื่อสารกับ SIOS อยู่เสมอ

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

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

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

ผู้เขียน:แคสเซียส รูห์ รองประธานฝ่ายประสบการณ์ลูกค้า บริษัท SIOS Technology Corp.

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