แชร์ผ่าน

คำแนะนำสำหรับการออกแบบเพื่อความเรียบง่ายและความมีประสิทธิภาพ

  • บทความ

นำไปใช้กับคำแนะนำรายการตรวจสอบความน่าเชื่อถือของ Power Platform Well-Architected:

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

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

คำนิยาม

เงื่อนไข ข้อกำหนด
ปริมาณงาน ความสามารถแบบแยกส่วนหรืองานการคำนวณที่คุณสามารถแยกออกจากงานอื่นๆ ได้ในเชิงตรรกะ

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

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

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

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

แบบฝึกหัดความร่วมมือในการการออกแบบ

ทำงานร่วมกับผู้เกี่ยวข้องเพื่อ:

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

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

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

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

    สำหรับข้อมูลเพิ่มเติม โปรดดูโมดูลการฝึกอบรมที่มีชื่อว่า ทำงานกับความต้องการสำหรับ Microsoft Power Platform และ Dynamics 365

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

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

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

คำแนะนำการออกแบบเพิ่มเติม

คุณสามารถปฏิบัติตามคำแนะนำต่อไปนี้ได้โดยไม่ต้องมีส่วนร่วมของผู้เกี่ยวข้อง:

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

    • หากคุณแก้ไขความต้องการด้านระบบอัตโนมัติของกระบวนการด้วย Power Automate การแบ่งกระบวนการขนาดใหญ่ออกเป็นโฟลว์บนระบบคลาวด์ที่มีขนาดเล็กลงหลายๆ สตรีมอาจทำให้เข้าใจ ทดสอบ และบำรุงรักษาได้ยากขึ้น ในทางกลับกัน การทำทุกอย่างให้เป็นโฟลว์ขนาดใหญ่อาจส่งผลเสียต่อประสิทธิภาพและปริมาณการเรียก API

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

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

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

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

พัฒนาโค้ดแค่เท่าที่จำเป็น

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

  • ใช้ความสามารถของแพลตฟอร์มเมื่อตรงตามความต้องการทางธุรกิจของคุณ ตัวอย่าง

    • ใช้การควบคุมที่ทันสมัยแทนการพัฒนาส่วนประกอบโค้ดของคุณเองเพื่อให้ได้มาตรฐานการออกแบบ Fluent 2
    • ใช้ตัวเชื่อมต่อดั้งเดิมแทนการพัฒนาตัวเชื่อมต่อแบบกำหนดเองเพื่อลดโค้ดที่กำหนดเอง
    • ใช้คำตอบที่สร้างอัตโนมัติใน Microsoft Copilot Studio เพื่อช่วยให้เอเจนต์ของคุณสามารถค้นหาและแสดงข้อมูลจากแหล่งที่มาต่างๆ ภายในหรือภายนอกได้ โดยไม่มีหัวข้อที่สร้างขึ้นด้วยตนเอง

  • ใช้เซสชันการตรวจสอบโค้ดโดยเฉพาะเพื่อเป็นแนวปฏิบัติในการพัฒนา

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

  • พิจารณาชุดทักษะของทีมพัฒนาของคุณ ใช้เวลาในการเรียนรู้ทักษะใหม่หรือนำเทคโนโลยีใหม่มาใช้

พิจารณาตำแหน่งที่จะใช้ข้อมูลของคุณ

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

  • ข้อมูลใหม่: หากแอปของคุณสร้างข้อมูลที่ไม่ได้มีอยู่แล้ว เช่น เมื่อกระบวนการที่มีอยู่ทำในกระดาษ เราขอแนะนำให้เก็บข้อมูลไว้ใน Microsoft Dataverse

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

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

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

สำหรับคำแนะนำการออกแบบที่ใช้ได้จริง โปรดดูบทความต่อไปนี้:

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

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

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