ข้อผิดพลาดเกี่ยวกับสถาปัตยกรรมระบบคลาวด์: องค์กรต้องการเวลาเฉลี่ยที่สั้นกว่าในการกู้คืน – ข้อมูล

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

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

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

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

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

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

แนะนำ

องค์กรสามารถใช้หลายขั้นตอนเพื่อหลีกเลี่ยง MTTR ที่ยาว:

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

สรุป

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

ในบทความห้าส่วนนี้ ฉันได้ให้รายละเอียดเกี่ยวกับข้อผิดพลาดหลัก XNUMX ประการที่องค์กรต่างๆ ทำในการสร้างสถาปัตยกรรมระบบคลาวด์ และวิธีหลีกเลี่ยงปัญหาเหล่านั้น แพลตฟอร์มเครือข่ายคลาวด์ที่ยืดหยุ่นและปรับขนาดได้ซึ่งรองรับ CSP หลักทั้งหมดสามารถ:

1. ตรวจสอบให้แน่ใจว่าคุณยังคงมองเห็นและควบคุมการประมวลผลข้อมูลของคุณ สร้างสถาปัตยกรรมคลาวด์ที่สอดคล้องกันบนคลาวด์เดียวหรือหลายคลาวด์
2. จัดเตรียมตัวควบคุมแบบรวมศูนย์และระนาบข้อมูลแบบกระจาย หลีกเลี่ยงความยุ่งเหยิงที่อาจเป็นผลมาจากแนวทาง DIY แพลตฟอร์มเครือข่ายจะช่วยให้สามารถใช้คุณสมบัติต่างๆ เช่น การวิเคราะห์พฤติกรรมเครือข่ายและการตรวจจับความผิดปกติตามการเรียนรู้ของเครื่อง (ML) ความสามารถในการรักษาตัวเอง และการสนับสนุนแบบรวมสำหรับแอปที่สำคัญต่อธุรกิจ 
3. ให้การมองเห็นต้นทุนที่ลึกยิ่งขึ้นใน LOBs ทั้งหมด ซึ่งเป็นรากฐานสำหรับโซลูชันการคิดต้นทุนและการเรียกเก็บเงินอัจฉริยะที่ครอบคลุมทรัพยากรที่ใช้ร่วมกันและไม่ใช้ร่วมกัน เมื่อตัวเลือก Showback และการปฏิเสธการชำระเงินหายไป แต่ละทีมและ LOB จะสร้างและสั่งซื้อบริการโดยอิสระ ทำให้ต้นทุนเพิ่มขึ้นอย่างมาก
4. ฝังการรักษาความปลอดภัยลงในระนาบข้อมูล ทำให้องค์กรสามารถสร้างและบังคับใช้นโยบายความปลอดภัยตามความตั้งใจในสภาพแวดล้อมแบบมัลติคลาวด์ การใช้วิธีการในสถานที่เพื่อความปลอดภัยในระบบคลาวด์นั้นมีค่าใช้จ่ายสูงและไม่มีประสิทธิภาพ และยังก่อให้เกิดช่องโหว่อีกด้วย 
5. ลดระยะเวลาเฉลี่ยขององค์กรในการกู้คืน (MTTR) ด้วยการให้การมองเห็นทั่วทั้งสภาพแวดล้อมพร้อมกับความสามารถในการใช้เครื่องมือแก้ไขปัญหาขั้นสูง แดชบอร์ดระดับแอปพลิเคชัน และเครื่องมืออื่นๆ ที่สามารถป้องกันความล้มเหลวในเชิงรุก การสูญเสียรายได้นั้นแพงพอๆ กับ MTTR ที่ยาวนาน ซึ่งในระหว่างนั้นธุรกิจสามารถปิดตัวลงได้จนกว่าจะตรวจพบและแก้ไขสาเหตุของความล้มเหลว

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

• เนื้อหาที่ขับเคลื่อนด้วย SEO และการเผยแพร่ประชาสัมพันธ์ รับการขยายวันนี้
• การเงิน EVM ส่วนต่อประสานแบบครบวงจรสำหรับการเงินแบบกระจายอำนาจ เข้าถึงได้ที่นี่.
• กลุ่มสื่อควอนตัม IR/PR ขยาย เข้าถึงได้ที่นี่.
• เพลโตไอสตรีม. ข้อมูลอัจฉริยะ Web3 ขยายความรู้ เข้าถึงได้ที่นี่.
• ที่มา: https://www.dataversity.net/cloud-architecture-mistakes-organizations-need-shorter-mean-time-to-recovery/