เริ่มเตรียมพร้อมสำหรับการหยุดชะงักของคลาวด์ครั้งถัดไป

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

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

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

นำความกังขาและทำการบ้านของคุณ

บ่อยครั้งที่ทีมจะเดินเข้าสู่ภัยพิบัติโดยไม่ทำการบ้านเกี่ยวกับคลาวด์ โดยคิดว่าบริษัทคลาวด์ที่มีชื่อเสียงเป็นที่เชื่อถือโดยธรรมชาติ แน่นอนว่าบริษัทที่มีชื่อเสียงที่สุดได้รับชื่อเสียงนั้นมาจากเหตุผล แต่ทุกคลาวด์และไฮเปอร์สเกลเลอร์ให้บริการโครงสร้างพื้นฐานหลากหลายตัวเลือก – AWS North America เพียงอย่างเดียวมี 31 Availability Zones และ 31 Edge Network Locations – และบางตัวเลือกมีความน่าเชื่อถือมากกว่าตัวเลือกอื่น ๆ

แท้จริงแล้ว AWS US-EAST-1 Region ซึ่งเป็นสาเหตุของการหยุดชะงักในสัปดาห์นี้ มีการหยุดชะงักครั้งใหญ่ ในปี 2020, 2021 และ 2023 และเป็นที่รู้จักกันในวงการไอทีบางแห่งว่าเป็นภูมิภาคที่ไม่น่าเชื่อถือที่สุด มีหลายบริษัทที่เข้าใจสถานการณ์ แต่เลือกที่จะใช้ภูมิภาคนี้เนื่องจากต้นทุนต่ำและบริการที่หลากหลาย แต่ด้วยขอบเขตของการหยุดชะงัก มันไม่สามารถไม่พิจารณาว่ามีบริษัทจำนวนเท่าใดที่ถูกจับได้โดยไม่คาดคิด – และจะเลือกภูมิภาคที่น่าเชื่อถือมากกว่าหากพวกเขาได้รับทราบถึงการแลกเปลี่ยน

บทเรียนที่นี่คือการทำการบ้านของคุณเกี่ยวกับตัวเลือกโครงสร้างพื้นฐานคลาวด์ ไม่ว่าคุณจะใช้คลาวด์ใดก็ตาม จุดเริ่มต้น ได้แก่ เครื่องมือฟรี เช่น cloudprice, Cloudping และการดูเหตุการณ์ทางประวัติศาสตร์จากเครื่องมือ Cloud Service Health ที่ให้บริการโดยไฮเปอร์สเกลเลอร์

เลือกแบบพกพาเหนือคลาวด์แบบเนทีฟ

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

เพื่อหลีกเลี่ยงชั้นการเสี่ยงเพิ่มเติมของการเสพติดคลาวด์ เลือกผลิตภัณฑ์ที่เป็นอิสระและ/หรือเป็นโอเพ่นซอร์สเมื่อเป็นไปได้ ตัวอย่างของตัวเลือกทดแทน ได้แก่ ต่อไปนี้

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

วิศวกรสำหรับการล้มเหลว

เนื่องจากการหยุดชะงักของคลาวด์จะเกิดขึ้น 请ออกแบบผลิตภัณฑ์ของคุณโดยคำนึงถึงการหยุดชะงักของคลาวด์ ตัวอย่างหนึ่งที่ต้องดูคือ Datadog (DDOG ): ในเหตุการณ์ในปี 2023 บริษัทสูญเสียการเข้าถึงโหนด Kubernetes มากกว่าครึ่งหนึ่งในการผลิต และออกแบบแนวทางภัยพิบัติใหม่ การเปลี่ยนแปลงรวมถึงการเอาโครงสร้างพื้นฐานที่เป็นข้อต่อออก การจัดการหนี้ทางเทคนิคเพื่อให้การหยุดชะงักบางส่วนไม่แพร่กระจายไปทั่วระบบ การปรับปรุงการรับและการจัดเก็บข้อมูลสำหรับการมีอยู่ของข้อมูลที่ดีขึ้นระหว่างการหยุดชะงัก และการสร้างระบบเพื่อการฟื้นตัวอัตโนมัติในระดับใหญ่ จุดเริ่มต้นที่ดีในการเดินทางของคุณคือการปฏิบัติตามคำแนะนำของ Datadog เพื่อ “เริ่มต้นด้วยสิ่งที่สำคัญสำหรับผู้ใช้สิ้นสุด” และสร้างการป้องกันเพื่อปกป้องสิ่งที่สำคัญที่สุด

รันบนคลาวด์อย่างน้อยสองตัว

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

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