Design principles

หลักการออกแบบ 5 ประการเพื่อความน่าเชื่อถือ (Reliability) บนคลาวด์ มีดังนี้:

กู้คืนจากความล้มเหลวโดยอัตโนมัติ (Automatically recover from failure): ด้วยการตรวจสอบเวิร์กโหลดผ่านดัชนีชี้วัดผลงานหลัก (KPIs) คุณสามารถเริ่มการทำงานของระบบอัตโนมัติได้ทันทีเมื่อมีการละเมิดเกณฑ์ที่กำหนดไว้ โดย KPIs เหล่านี้ควรเป็นตัววัดคุณค่าทางธุรกิจ ไม่ใช่แค่แง่มุมทางเทคนิคของการทำงานของบริการ สิ่งนี้จะช่วยให้มีการแจ้งเตือนและติดตามความล้มเหลวโดยอัตโนมัติ รวมถึงมีกระบวนการกู้คืนอัตโนมัติเพื่อแก้ไขหรือหลีกเลี่ยงความล้มเหลวนั้น หากใช้ระบบอัตโนมัติที่ซับซ้อนมากขึ้น จะสามารถคาดการณ์และเยียวยาความล้มเหลวก่อนที่จะเกิดขึ้นจริงได้
ทดสอบขั้นตอนการกู้คืน (Test recovery procedures): ในสภาพแวดล้อมแบบ On-premises การทดสอบมักทำเพื่อพิสูจน์ว่าเวิร์กโหลดทำงานได้ในสถานการณ์เฉพาะ แต่ไม่ค่อยได้ใช้เพื่อตรวจสอบกลยุทธ์การกู้คืน อย่างไรก็ตามบนคลาวด์ คุณสามารถทดสอบว่าเวิร์กโหลดของคุณล้มเหลวอย่างไรและตรวจสอบขั้นตอนการกู้คืนได้ คุณสามารถใช้ระบบอัตโนมัติเพื่อจำลองความล้มเหลวในรูปแบบต่างๆ หรือสร้างสถานการณ์ที่เคยนำไปสู่ความล้มเหลวในอดีตขึ้นมาใหม่ แนวทางนี้จะช่วยเผยให้เห็นเส้นทางความล้มเหลวที่คุณสามารถทดสอบและแก้ไขได้ก่อนที่จะเกิดสถานการณ์จริง จึงช่วยลดความเสี่ยงลงได้
ขยายระบบในแนวนอนเพื่อเพิ่มความพร้อมใช้งานโดยรวม (Scale horizontally to increase aggregate workload availability): เปลี่ยนจากทรัพยากรขนาดใหญ่เพียงชิ้นเดียว เป็นทรัพยากรขนาดเล็กหลายชิ้น เพื่อลดผลกระทบจากการล้มเหลวเพียงจุดเดียว (Single failure) ที่มีต่อเวิร์กโหลดทั้งหมด โดยกระจายคำร้องขอไปยังทรัพยากรขนาดเล็กจำนวนมากเพื่อตรวจสอบว่าไม่มีจุดล้มเหลวร่วมกัน (Common point of failure)
เลิกคาดเดาความจุ (Stop guessing capacity): สาเหตุทั่วไปของความล้มเหลวในเวิร์กโหลดแบบ On-premises คือทรัพยากรถึงขีดจำกัด (Resource saturation) เมื่อความต้องการใช้งานเกินกว่าความจุของระบบ (ซึ่งมักเป็นเป้าหมายของการโจมตีแบบ Denial of Service) บนคลาวด์คุณสามารถตรวจสอบความต้องการและการใช้งานทรัพยากร แล้วใช้ระบบอัตโนมัติในการเพิ่มหรือลดทรัพยากรเพื่อรักษาระดับที่มีประสิทธิภาพสูงสุดในการตอบสนองความต้องการ โดยไม่ต้องจัดสรรทรัพยากรมากเกินไปหรือน้อยเกินไป แม้ว่าจะยังมีข้อจำกัดอยู่บ้าง แต่โควตาบางอย่างสามารถควบคุมและจัดการได้
จัดการการเปลี่ยนแปลงผ่านระบบอัตโนมัติ (Manage change through automation): การเปลี่ยนแปลงโครงสร้างพื้นฐานของคุณควรทำผ่านระบบอัตโนมัติ การเปลี่ยนแปลงที่ต้องได้รับการจัดการนั้นรวมถึงการเปลี่ยนแปลงในตัวระบบอัตโนมัติเองด้วย ซึ่งจะทำให้สามารถติดตามและตรวจสอบย้อนหลังได้