วิธีปรับขนาดไดรฟ์ข้อมูล SIOS DataKeeper หรือมิเรอร์

ในวิดีโอความยาว 4.5 นาทีนี้ SIOS จะสาธิตวิธีการอย่างถูกต้อง ปรับขนาดไดรฟ์ข้อมูล SIOS DataKeeper ที่มีอยู่ หรือกระจก ในกรณีนี้ เรากำลังปกป้อง SQL Server ทรัพยากรผ่าน การจัดคลัสเตอร์ล้มเหลว . ทรัพยากร SIOS DataKeeper ที่เราจะปรับขนาดจะเป็น Volume 's

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

แจ้งให้เราทราบหากสิ่งนี้มีประโยชน์!

วิธีลบ SIOS DataKeeper Storage ออกจาก SIOS LifeKeeper

Greg Tucker วิศวกรฝ่ายสนับสนุนผลิตภัณฑ์อาวุโสของ SIOS (Windows) จะสาธิตในวิดีโอ 3 นาทีนี้ วิธีลบอย่างถูกต้อง SIOS DataKeeper พื้นที่จัดเก็บ จาก SIOS LifeKeeper

ขอแนะนำเป็นอย่างยิ่งให้คุณลบทรัพยากร DataKeeper ออกจากคลัสเตอร์ก่อนที่จะลบ DataKeeper

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

การปรับปรุงการเดินทางสู่การยอมรับบนคลาวด์ของคุณ

 

ไม่ทางใดก็ทางหนึ่ง เหตุการณ์ที่เปลี่ยนแปลงโลกในปี 2020 และ 2021 ได้เปลี่ยนโฉมหน้าเกือบทุกอย่างที่เรารู้ และ ความพร้อมใช้งานสูง ก็ไม่มีข้อยกเว้น เนื่องจากหลายๆ บริษัทได้ติดตามเส้นทางการนำระบบคลาวด์ไปใช้อย่างรวดเร็ว แม้จะมีการปิดและข้อจำกัด ทีมไอทีจำนวนมากได้แลกเปลี่ยนศูนย์ข้อมูลภายในองค์กรสำหรับระบบคลาวด์ หลายคนถามว่า 'แล้วไง?ต่อไปนี้คือสิ่งที่ต้องทำ 5 ประการเพื่อแก้ไขการเดินทางบนระบบคลาวด์ในปี 2022

1. เพิ่มความพร้อมใช้งานสูงให้กับระบบคลาวด์

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

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

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

2. ขยายความพร้อมใช้งานที่สูงขึ้นสำหรับการกู้คืนจากภัยพิบัติ

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

3. สร้างทีมการเดินทางบนคลาวด์ของคุณ

ในชั่วข้ามคืนบางบริษัทและทีมไอทีของพวกเขา เปลี่ยนจากการทำงานในองค์กรโดยสมบูรณ์เป็นการต่อสู้กับเทมเพลต Cloud Formation, คู่มือการเริ่มต้นอย่างรวดเร็ว, บทบาท IAM, ตัวจัดสรรภาระงานภายใน, IP โอเวอร์เลย์ และการถอดรหัสความหมายของขนาด VM นั้นตอนนี้เป็นเวลาที่จะสร้างทีมเพื่อรองรับการเดินทางสู่ระบบคลาวด์นี่จะหมายถึงหลายสิ่ง: ก. เพิ่มความจุ.เว้นแต่คุณจะสามารถดึงลิฟต์และกะออกได้ทั้งหมด คุณน่าจะมีพนักงานคนเดียวกันที่จัดการแอปพลิเคชันระบบคลาวด์และในองค์กรโซลูชันเดิมเป็นที่รู้จักว่ามีความเจ้าอารมณ์และต้องทำงานเป็นจำนวนมากเพื่อให้มีเสถียรภาพและพร้อมใช้งานเพื่อนำทางบนเส้นทางคลาวด์ข้างหน้า คุณจะต้องมีความจุที่สามารถตอบสนองความต้องการด้านความพร้อมใช้งาน ทำความเข้าใจสถาปัตยกรรมระบบคลาวด์ และวางแผนหลักสูตรล่วงหน้าสำหรับความต้องการขององค์กร

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

4. ผสานการทำงานอัตโนมัติและการวิเคราะห์เพื่อให้แน่ใจว่าพร้อมใช้งาน

ในฐานะรองประธานฝ่ายประสบการณ์ลูกค้าที่ SIOS Technology Corp. ฉันได้ทำงานร่วมกับบริษัทหลายแห่งที่ย้ายมาใช้ระบบคลาวด์ในปี 2564 โดยไม่สูญเสีย HA, DR หรือทีมของพวกเขา หากคุณใช้เวลาถึงเก้าเท่าที่จำเป็น (99.99%) อย่างจริงจัง และมีแผนรองรับภัยพิบัติที่ไม่สามารถต่อรองได้ ก็ถึงเวลาเพิ่มความเข้มงวดของการวิเคราะห์และการตรวจสอบเพิ่มเติม ตรวจสอบให้แน่ใจว่าโซลูชันความพร้อมใช้งานของคุณมีระบบอัตโนมัติที่รับรู้ถึงแอปพลิเคชันและการประสานงานสำหรับการกู้คืนในกรณีที่เกิดภัยพิบัติหรือการหยุดทำงานโดยไม่ได้วางแผนไว้ เพิ่มการวิเคราะห์และระบบอัตโนมัติเพื่อเสริมความแข็งแกร่งให้กับโซลูชันของคุณ และยกระดับการโยกย้ายระบบคลาวด์ของคุณไปอีกขั้นจากหนึ่งในความล้มเหลวเชิงโต้ตอบ ไปจนถึงการแจ้งเตือนเชิงรุกและการบรรเทาความล้มเหลวก่อนที่จะเกิดขึ้นลองนึกภาพว่าได้รับแจ้งเกี่ยวกับแอปพลิเคชันที่มีประสิทธิภาพต่ำ หรือเวลาในการตอบสนองที่เพิ่มขึ้น ข้อผิดพลาด หรือพฤติกรรมไม่ตอบสนองของ VM ทันเวลาเพื่อหลีกเลี่ยงการหยุดทำงานในช่วงเวลาธุรกิจสูงสุด การวิเคราะห์ก็มีความสำคัญเช่นกัน เนื่องจากสามารถเปิดเผยระบบและแอปพลิเคชันที่อาจหลุดจากสถาปัตยกรรมความพร้อมใช้งานดั้งเดิมของคุณ

5. อัปเดตกระบวนการและการกำกับดูแลด้านไอที

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

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

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

-Cassius Rhue, VP, Customer Experience ทำซ้ำโดยได้รับอนุญาตจาก SIOS

วิธีการย้ายมิเรอร์จากเครือข่ายหนึ่งไปยังอีกเครือข่ายหนึ่ง

Greg Tucker วิศวกรฝ่ายสนับสนุนผลิตภัณฑ์อาวุโสของ SIOS (Windows) นำเสนอบทแนะนำ 8 นาทีที่สาธิตวิธีย้าย มิเรอร์บนระบบสองโหนด .
นอกจากนี้ เขายังกล่าวถึง:

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

เมื่อเสร็จสิ้นการสอน Greg จะแชร์ข้อมูลติดต่อของฝ่ายสนับสนุน SIOS ทั้งหมดสำหรับคำถามหรือข้อสงสัยเพิ่มเติม

วิธีการย้ายมิเรอร์จากเครือข่ายหนึ่งไปยังอีกเครือข่ายหนึ่ง | SIOS ทำซ้ำโดยได้รับอนุญาตจาก SIOS

พร้อมใช้งานสูงหรือมีความเสี่ยงสูง? รายการตรวจสอบความพร้อมใช้งานสูง

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

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

องค์กรของคุณมีโครงสร้างพื้นฐานที่เหมาะสมเพื่อรองรับหรือไม่ ความพร้อมใช้งานสูง ?

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

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

องค์กรของคุณมี runbook (หรือ playbook) ที่ครอบคลุมการออกแบบ สถาปัตยกรรม และกระบวนการหรือไม่?

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

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

องค์กรของคุณมีทรัพยากรที่อุทิศให้กับการรักษาแนวทางปฏิบัติที่ดีที่สุดเกี่ยวกับความพร้อมใช้งานสูงหรือไม่

• องค์กรของคุณให้การสนับสนุนและฝึกอบรมพนักงานและผู้รับเหมาเหล่านี้หรือไม่
• องค์กรของคุณให้อิสระแก่ทีมเหล่านี้ในการปรับตัวและสร้างแนวทางปฏิบัติที่ดีที่สุดหรือไม่?

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

องค์กรของคุณมีการควบคุมการจัดการการเปลี่ยนแปลงที่เหมาะสมหรือไม่

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

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

องค์กรของคุณมีการควบคุมการเข้าถึงที่เหมาะสมหรือไม่

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

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

บริษัทของคุณมีขั้นตอนการทดสอบปกติหรือไม่?

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

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

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

ทำซ้ำโดยได้รับอนุญาตจาก SIOS