ข้อแนะนำในการกำหนดเป้าหมายความน่าเชื่อถือ

ใช้กับคำแนะนำรายการตรวจสอบความน่าเชื่อถือที่ได้รับการออกแบบอย่างดีนี้: Power Platform

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

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

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

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

พิจารณาใช้เมตริกต่อไปนี้เพื่อระบุปริมาณความต้องการทางธุรกิจ

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

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

กลยุทธ์การออกแบบที่สำคัญ

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

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

ปฏิบัติตามรูปแบบนี้เมื่อคุณตรวจสอบโฟลว์และสร้างรายการเป้าหมายทั้งหมด

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

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

เมตริกความพร้อมใช้งาน

เป้าหมายความพร้อมใช้งานสอดคล้องกับตัววัด SLO, SLA และ SLI

SLO และ SLA

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

หากต้องการกำหนด SLO ให้คำนึงถึง:

• ข้อกำหนดที่ไม่สามารถใช้งานได้สำหรับภาระงานของคุณ (เช่น อัตราคำขอสูงสุด ผู้ใช้ที่ใช้งานพร้อมกัน) ในอีก 1-2 ปีข้างหน้า

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

หลังจากที่คุณรวบรวม SLA สำหรับส่วนประกอบภาระงานแต่ละรายการแล้ว ให้คำนวณ SLA แบบรวม SLA แบบรวมควรตรงกับ SLO เป้าหมายของภาระงาน การคำนวณ SLA แบบรวมเกี่ยวข้องกับหลายปัจจัย ขึ้นอยู่กับการออกแบบสถาปัตยกรรมของคุณ

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

ค่า SLA

ตารางต่อไปนี้กำหนดค่า SLA ทั่วไป

SLA	เวลาหยุดทำงานต่อสัปดาห์	เวลาหยุดทำงานต่อเดือน	เวลาหยุดทำงานต่อปี
99%	1.68 ชั่วโมง	7.2 ชั่วโมง	3.65 วัน
99.9%	10.1 นาที	43.2 นาที	8.76 ชั่วโมง
99.95%	5 นาที	21.6 นาที	4.38 ชั่วโมง
99.99%	1.01 นาที	4.32 นาที	52.56 นาที
99.999%	6 วินาที	25.9 วินาที	5.26 นาที

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

SLI

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

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

เมตริกการกู้คืน

เป้าหมายการกู้คืนสอดคล้องกับเมตริก RTO, RPO, MTTR และ MTBF เมื่อเทียบกับเป้าหมายความพร้อมใช้งาน เป้าหมายการกู้คืนสำหรับการวัดผลเหล่านี้จะไม่ขึ้นอยู่กับ Microsoft SLA มากนัก Microsoft เผยแพร่การรับประกัน RTO และ RPO เฉพาะบางผลิตภัณฑ์ เช่น ฐานข้อมูล SQL

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

หมายเหตุ

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

การสร้างโมเดลความสมบูรณ์

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

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

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

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

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

หมายเหตุ

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

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

สำหรับคำแนะนำโดยละเอียดเกี่ยวกับการกำหนดค่าการติดตามและการแจ้งเตือน โปรดดูคู่มือ การตรวจสอบความสมบูรณ์

การจัดรูปแบบการแสดง

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

การอำนวยความสะดวก Power Platform

Power Platform SLA กำหนดข้อผูกมัดในเรื่องเวลาการทำงานและการเชื่อมต่อ Microsoft บริการที่แตกต่างกันมี SLA ที่ต่างกัน และบางครั้ง SKU ภายในบริการก็มี SLA ที่แตกต่างกัน สำหรับข้อมูลเพิ่มเติม โปรดดู ข้อตกลงระดับการให้บริการสำหรับบริการออนไลน์

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

Microsoft แอปพลิเคชันธุรกิจมอบความสามารถความต่อเนื่องทางธุรกิจและการกู้คืนจากภัยพิบัติ (BCDR) ให้กับสภาพแวดล้อม ประเภทการผลิต ทั้งหมดใน Dynamics 365 และแอปพลิเคชัน Power Platform SaaS เรียนรู้วิธีการ Microsoft ช่วยให้มั่นใจได้ว่าข้อมูลการผลิตของคุณมีความยืดหยุ่นระหว่างการหยุดให้บริการในแต่ละภูมิภาค

การจัดตำแหน่งองค์กร

Cloud Adoption Framework ให้คำแนะนำสำหรับ SLO และ SLI ที่เกี่ยวข้องกับการตรวจสอบทั่วทั้งองค์กร

สำหรับข้อมูลเพิ่มเติม โปรดดู SLO การตรวจสอบระบบคลาวด์

รายการตรวจสอบความน่าเชื่อถือ

โปรดดูชุดคำแนะนำทั้งหมด

รายการตรวจสอบความน่าเชื่อถือ