คำแนะนำสำหรับการออกแบบกลยุทธ์การลดความล้มเหลวในการปรับใช้
นำไปใช้กับคำแนะนำรายการตรวจสอบความเป็นเลิศในการดำเนินงานของ Power Platform Well-Architected:
| OE:11 | ใช้กลยุทธ์การลดความล้มเหลวในการปรับใช้ที่แก้ไขปัญหาการเปิดตัวกลางคันที่ไม่คาดคิดพร้อมการกู้คืนที่รวดเร็ว รวมแนวทางต่างๆ เข้าด้วยกัน เช่น การย้อนกลับ การปิดใช้งานคุณลักษณะ หรือใช้ความสามารถดั้งเดิมของรูปแบบการปรับใช้ของคุณ |
|---|
คู่มือนี้จะอธิบายคำแนะนำสำหรับการออกแบบกลยุทธ์ที่เป็นมาตรฐานเพื่อจัดการกับความล้มเหลวในการปรับใช้อย่างมีประสิทธิภาพ เช่นเดียวกับปัญหาปริมาณงานอื่นๆ ความล้มเหลวในการปรับใช้เป็นส่วนหนึ่งของวงจรชีวิตของปริมาณงานที่หลีกเลี่ยงไม่ได้ ด้วยกรอบความคิดนี้ คุณสามารถดำเนินการเชิงรุกได้โดยมีกลยุทธ์ที่ออกแบบมาอย่างดีและมีเจตนาเพื่อจัดการกับความล้มเหลวในการปรับใช้ กลยุทธ์ดังกล่าวช่วยให้ทีมปริมาณงานของคุณสามารถลดความล้มเหลวได้อย่างมีประสิทธิภาพโดยมีผลกระทบต่อผู้ใช้ของคุณน้อยที่สุด
การไม่มีแผนดังกล่าวอาจนำไปสู่การตอบสนองต่อปัญหาที่วุ่นวายและอาจส่งผลเสีย ซึ่งอาจส่งผลกระทบอย่างมีนัยสำคัญต่อการทำงานร่วมกันของทีมและองค์กร ความไว้วางใจของลูกค้า และการเงิน
กลยุทธ์การออกแบบที่สำคัญ
ในบางครั้ง แม้ว่าแนวทางปฏิบัติในการพัฒนาของคุณจะครบกำหนดแล้ว แต่ปัญหาการปรับใช้ก็เกิดขึ้น การใช้แนวทางปฏิบัติในการปรับใช้ที่ปลอดภัยและการดำเนินงานห่วงโซ่อุปทานปริมาณงานที่แข็งแกร่งสามารถช่วยลดความถี่ของการปรับใช้ที่ล้มเหลวได้ คุณต้องออกแบบกลยุทธ์ที่เป็นมาตรฐานเพื่อจัดการกับการปรับใช้ที่ล้มเหลวเมื่อเกิดขึ้น
กลยุทธ์การลดความล้มเหลวในการปรับใช้ประกอบด้วยห้าขั้นตอนกว้างๆ:
- การตรวจจับ: เพื่อตอบสนองต่อการปรับใช้ที่ล้มเหลว คุณต้องตรวจพบความล้มเหลวก่อน การตรวจจับอาจมีหลายรูปแบบ เช่น การทดสอบควันล้มเหลว รายงานผู้ใช้ หรือการแจ้งเตือนที่แพลตฟอร์มการตรวจสอบของคุณสร้างขึ้น
- การตัดสินใจ: คุณต้องตัดสินใจว่ากลยุทธ์การบรรเทาผลกระทบที่ดีที่สุดสำหรับประเภทความล้มเหลวเฉพาะเจาะจงคืออะไร
- การบรรเทา: คุณต้องดำเนินการบรรเทาผลกระทบที่ระบุ การบรรเทาผลกระทบอาจอยู่ในรูปแบบของทางเลือกสำรอง การย้อนกลับ หรือการดำเนินไปข้างหน้า
- การสื่อสาร: ผู้เกี่ยวข้องและผู้ใช้ที่ได้รับผลกระทบจะต้องรับทราบสถานะในขณะที่คุณตรวจพบและดำเนินการแก้ไขปัญหาตามที่กำหนดโดยแผนรับมือเหตุฉุกเฉินของคุณ
- การพิสูจน์หลังเหตุการณ์: การพิสูจน์หลังเหตุการณ์โดยไร้ข้อตำหนิให้โอกาสแก่ทีมงานภาระงานในการระบุจุดที่ต้องปรับปรุง และสร้างแผนเพื่อประยุกต์การเรียนรู้
ส่วนต่อไปนี้ให้คำแนะนำโดยละเอียดสำหรับแต่ละขั้นตอนเหล่านี้
การตรวจหา
หากต้องการระบุปัญหาเกี่ยวกับการปรับใช้งานอย่างรวดเร็ว คุณต้องมีแนวทางปฏิบัติในการทดสอบและตรวจสอบที่มีประสิทธิภาพซึ่งเกี่ยวข้องกับการปรับใช้งาน เพื่อช่วยตรวจจับความผิดปกติได้อย่างรวดเร็วคุณสามารถเสริมการตรวจสอบปริมาณงานของคุณและการแจ้งเตือนโดยใช้เครื่องมือการจัดการประสิทธิภาพของแอปพลิเคชันและการบันทึกผ่านเครื่องมือวัด
การทดสอบควันและการทดสอบคุณภาพอื่นๆ ควรเกิดขึ้นในแต่ละระยะของการเปิดตัว การทดสอบที่ประสบความสำเร็จในกลุ่มการใช้งานหนึ่งไม่ควรมีอิทธิพลต่อการตัดสินใจในการทดสอบในกลุ่มต่อมา
คุณสามารถใช้การวัดและส่งข้อมูลทางไกลที่สัมพันธ์กับปัญหาของผู้ใช้กับขั้นตอนการปรับใช้ จากนั้น คุณจะระบุกลุ่มการเปิดตัวที่เชื่อมโยงกับผู้ใช้รายใดรายหนึ่งได้อย่างรวดเร็ว แนวทางนี้มีความสำคัญเป็นพิเศษสำหรับการปรับใช้การเปิดใช้แบบก้าวหน้า เนื่องจากคุณอาจมีการกำหนดค่าหลายรายการที่ทำงานทั่วทั้งฐานผู้ใช้ของคุณ ณ จุดใดก็ตามในการปรับใช้
คุณควรพร้อมที่จะตอบสนองต่อปัญหาที่ผู้ใช้รายงานทันที เมื่อใดก็ตามที่ทำได้จริง ให้ปรับใช้ระยะการเปิดตัวของคุณในช่วงเวลาทำงาน เมื่อคุณมีทีมสนับสนุนเต็มรูปแบบ ตรวจสอบให้แน่ใจว่าเจ้าหน้าที่ฝ่ายสนับสนุนได้รับการฝึกอบรมเกี่ยวกับวิธีส่งต่อปัญหาการปรับใช้สำหรับการกำหนดเส้นทางที่เหมาะสม การยกระดับควรสอดคล้องกับแผนการรับมือเหตุฉุกเฉินด้านภาระงานของคุณ
การตัดสินใจ
การตัดสินใจเลือกกลยุทธ์การบรรเทาผลกระทบที่เหมาะสมสำหรับปัญหาการปรับใช้เกี่ยวข้องกับการพิจารณาปัจจัยต่างๆ เช่น:
ประเภทของโมเดลแบบก้าวหน้าที่คุณใช้ ตัวอย่างเช่น คุณอาจใช้โมเดลสีน้ำเงิน-เขียวหรือโมเดลคานารี หากคุณใช้โมเดลสีน้ำเงิน-เขียว ทางเลือกสำรองมีประโยชน์มากกว่าการคืนค่า คุณสามารถเปลี่ยนการรับส่งข้อมูลกลับไปยังสแต็กที่เรียกใช้การกำหนดค่าที่ไม่ได้รับการอัปเดตได้อย่างง่ายดาย จากนั้น คุณสามารถแก้ไขปัญหาในสภาพแวดล้อมที่มีปัญหา และลองปรับใช้อีกครั้งในเวลาที่เหมาะสม
วิธีการที่คุณมีไว้ใช้งานเพื่อเลี่ยงปัญหา ตัวอย่างได้แก่ การใช้แฟล็กคุณลักษณะ ตัวแปรสภาพแวดล้อม หรือคุณสมบัติการกำหนดค่ารันไทม์ประเภทอื่นๆ ที่คุณสามารถสลับเปิดและปิดได้ บางครั้งคุณสามารถหลีกเลี่ยงปัญหาได้อย่างง่ายดายโดยปิดการตั้งค่าสถานะคุณลักษณะหรือสลับการตั้งค่า ในกรณีนี้ คุณอาจสามารถ:
- ดำเนินการเปิดตัวต่อ
- หลีกเลี่ยงการใช้ทางเลือกสำรอง
- ย้อนกลับในขณะที่คุณแก้ไขโค้ดที่ละเมิด
ระดับความพยายามที่จำเป็นในการดำเนินการแก้ไขในโค้ด ถ้าระดับของความพยายามในการแก้ไขโค้ดอยู่ในระดับต่ำ กลิ้งไปข้างหน้า โดยใช้โปรแกรมแก้ไขด่วนเป็นตัวเลือกที่เหมาะสมสำหรับบางสถานการณ์
ระดับวิกฤตสำหรับภาระงานที่ได้รับผลกระทบ ภาระงานที่มีความสำคัญต่อธุรกิจควรได้รับการปรับใช้ในลักษณะเคียงข้างกันเสมอ เช่น ในโมเดลสีน้ำเงิน-เขียว เพื่อให้เกิดการปรับใช้โดยใช้เวลาเป็นศูนย์ ด้วยเหตุนี้ ทางเลือกสำรองจึงเป็นกลยุทธ์การบรรเทาผลกระทบที่ดีกว่าสำหรับภาระงานประเภทนี้
การแก้ไข
ต่อไปนี้เป็นกลยุทธ์การบรรเทาปัญหาทั่วไป:
การย้อนกลับ: ในสถานการณ์การย้อนกลับ คุณจะเปลี่ยนระบบที่อัปเดตกลับเป็นสถานะการกำหนดค่าที่ทราบล่าสุด
เป็นสิ่งสำคัญสำหรับทีมภาระงานทั้งหมดที่จะเห็นพ้องต้องกันเกี่ยวกับความหมายของ "ความดีที่รู้จักล่าสุด" นิพจน์นี้หมายถึงสถานะสุดท้ายของปริมาณงานที่สมบูรณ์ก่อนเริ่มการปรับใช้ ซึ่งไม่จำเป็นต้องเป็นเวอร์ชันแอปพลิเคชันก่อนหน้า
การย้อนกลับอาจมีความซับซ้อน โดยเฉพาะอย่างยิ่งเมื่อเกี่ยวข้องกับการเปลี่ยนแปลงข้อมูล การเปลี่ยนแปลงตามแผนอาจทำให้การย้อนกลับมีความเสี่ยง การนำไปปฏิบัติอย่างปลอดภัยอาจต้องมีการวางแผนอย่างมาก ตามคำแนะนำทั่วไป การอัปเดตแผนควรเป็นแบบเพิ่มเติม ไม่ควรแทนที่เรกคอร์ดด้วยเรกคอร์ดใหม่ แต่เรกคอร์ดเก่าควรเลิกใช้แล้วและควรอยู่ร่วมกับเรกคอร์ดใหม่ จนกว่าจะสามารถลบเรกคอร์ดที่เลิกใช้แล้วได้อย่างปลอดภัย
ทางเลือกสำรอง: ในสถานการณ์ทางเลือกสำรอง ระบบที่อัปเดตจะถูกลบออกจากการกำหนดเส้นทางการรับส่งข้อมูลที่ใช้งานจริง การรับส่งข้อมูลทั้งหมดจะถูกส่งไปยังสแต็กที่ไม่ได้รับการอัปเดต กลยุทธ์ที่มีความเสี่ยงต่ำนี้ช่วยให้คุณแก้ไขปัญหาในโค้ดของคุณได้โดยไม่ทำให้เกิดการหยุดชะงักเพิ่มเติม
ด้วยการปรับใช้คานารี ทางเลือกสำรองอาจไม่ตรงไปตรงมาหรือเป็นไปได้ด้วยซ้ำ ขึ้นอยู่กับโครงสร้างพื้นฐานและการออกแบบแอปของคุณ หากคุณจำเป็นต้องปรับขนาดเพื่อรองรับโหลดบนระบบที่ไม่ได้รับการอัปเดต ให้ดำเนินการปรับขนาดนั้นก่อนที่จะถอยกลับ
ข้ามฟังก์ชันที่ละเมิด: หากคุณสามารถข้ามปัญหาได้โดยใช้ค่าสถานะคุณลักษณะหรือคุณสมบัติการกำหนดค่ารันไทม์ชนิดอื่น คุณอาจตัดสินใจว่าการดำเนินการเปิดตัวต่อเป็นกลยุทธ์ที่เหมาะสมสำหรับปัญหาหรือไม่
คุณควรเข้าใจข้อดีของการเลี่ยงผ่านฟังก์ชันนี้อย่างชัดเจน และคุณควรสามารถสื่อสารข้อดีข้อเสียนั้นกับผู้มีส่วนได้ส่วนเสียได้ ผู้มีส่วนได้ส่วนเสียควรอนุมัติแผนดำเนินการต่อไป ผู้มีส่วนได้ส่วนเสียจำเป็นต้องกำหนดระยะเวลาที่สามารถทนต่อการดำเนินงานในสภาวะประสิทธิภาพลดลงได้ พวกเขายังต้องประเมินการตัดสินใจนั้นเทียบกับเวลาโดยประมาณที่จำเป็นในการแก้ไขโค้ดที่ละเมิดและปรับใช้
การปรับใช้งานกรณีฉุกเฉิน (โปรแกรมแก้ไขด่วน): หากคุณสามารถแก้ไขปัญหาได้ในระหว่างการเปิดตัว โปรแกรมแก้ไขด่วนอาจเป็นกลยุทธ์การบรรเทาผลกระทบที่ใช้งานได้จริงที่สุด
เช่นเดียวกับโค้ดอื่นๆ โปรแกรมแก้ไขด่วนจำเป็นต้องดำเนินการตามแนวทางปฏิบัติในการปรับใช้ที่ปลอดภัยของคุณ แต่ด้วยโปรแกรมแก้ไขด่วนไทม์ไลน์จะถูกเร่งอย่างมาก คุณต้องใช้กลยุทธ์การเพิ่มระดับโค้ดทั่วทั้งสภาพแวดล้อมของคุณ คุณต้องตรวจสอบรหัสโปรแกรมแก้ไขด่วนที่ประตูคุณภาพทั้งหมด แต่คุณอาจต้องลดเวลาในการรอคอยลงอย่างมาก และคุณอาจต้องแก้ไขการทดสอบเพื่อเร่งให้เร็วขึ้น ตรวจสอบให้แน่ใจว่าคุณสามารถทำการทดสอบโค้ดที่อัปเดตทั้งหมดได้โดยเร็วที่สุดหลังจากการปรับใช้ การทดสอบการประกันคุณภาพอัตโนมัติในระดับสูงช่วยให้การทดสอบมีประสิทธิภาพในสถานการณ์เหล่านี้
การสื่อสาร
สิ่งสำคัญคือต้องกำหนดความรับผิดชอบในการสื่อสารให้ชัดเจนเพื่อช่วยลดความวุ่นวายระหว่างเกิดเหตุการณ์ ความรับผิดชอบเหล่านี้ควรกำหนดวิธีที่ทีมภาระงานมีส่วนร่วมกับทีมสนับสนุน ผู้มีส่วนได้ส่วนเสีย และบุคลากรในทีมเผชิญเหตุฉุกเฉิน เช่น ผู้จัดการเผชิญเหตุฉุกเฉิน
สร้างมาตรฐานจังหวะที่ทีมงานภาระงานติดตามเพื่อให้การอัปเดตสถานะ ตรวจสอบให้แน่ใจว่าผู้มีส่วนได้ส่วนเสียตระหนักถึงมาตรฐานนี้ เพื่อที่พวกเขาจะได้รู้ว่าเมื่อใดควรได้รับการอัปเดต
หากทีมปริมาณงานจำเป็นต้องสื่อสารโดยตรงกับผู้ใช้ ให้ชี้แจงประเภทของข้อมูลและระดับของรายละเอียดที่เหมาะสมสำหรับการแบ่งปัน สื่อสารกับทีมภาระงานเกี่ยวกับข้อกำหนดอื่นๆ ที่ใช้กับกรณีเหล่านี้
การพิสูจน์หลังเหตุการณ์
การพิสูจน์หลังเหตุการณ์ควรเกิดขึ้นหลังจากการปรับใช้ที่ล้มเหลวทั้งหมด โดยไม่มีข้อยกเว้น การปรับใช้งานที่ล้มเหลวทุกครั้งคือโอกาสในการเรียนรู้ การพิสูจน์หลังเหตุการณ์สามารถช่วยคุณระบุจุดอ่อนในกระบวนการปรับใช้งานและการพัฒนา และการตั้งค่าที่ผิดพลาดในโครงสร้างพื้นฐานของคุณ
การพิสูจน์หลังเหตุการณ์ไม่ควรตำหนิเสมอเพื่อให้บุคคลที่เกี่ยวข้องกับเหตุการณ์รู้สึกปลอดภัยเมื่อพวกเขาแบ่งปันมุมมองเกี่ยวกับสิ่งที่สามารถปรับปรุงได้ ผู้นำการพิสูจน์หลังเหตุการณ์ควรติดตามแผนสำหรับการดำเนินการปรับปรุงที่ระบุและเพิ่มแผนเหล่านี้ลงในรายการเวิร์กโหลดคงค้าง
ข้อควรพิจารณาและข้อเสนอแนะทั่วไป
ตรวจสอบให้แน่ใจว่าไปป์ไลน์การปรับใช้ของคุณสามารถยอมรับเวอร์ชันที่แตกต่างกันเป็นพารามิเตอร์ เพื่อให้คุณสามารถปรับใช้การกำหนดค่าที่ทราบล่าสุดได้อย่างง่ายดาย
รักษาความสอดคล้องกับการจัดการและส่วนข้อมูลในขณะที่คุณย้อนกลับหรือไปข้างหน้า คีย์ ข้อมูลลับ ข้อมูลสถานะฐานข้อมูล และการกำหนดค่าเฉพาะสำหรับทรัพยากรและนโยบายทั้งหมดจะต้องอยู่ในขอบเขตและคำนึงถึง ตัวอย่างเช่น ให้ความสนใจกับการออกแบบการปรับขนาดโครงสร้างพื้นฐานของคุณในการปรับใช้ที่ทราบถึงผลดีครั้งล่าสุด พิจารณาว่าคุณจำเป็นต้องปรับการกำหนดค่านั้นหรือไม่เมื่อคุณปรับใช้โค้ดของคุณอีกครั้ง
ชอบการเปลี่ยนแปลงเล็กๆ น้อยๆ บ่อยครั้งมากกว่าการเปลี่ยนแปลงขนาดใหญ่ที่ไม่บ่อยนัก เพื่อให้ความแตกต่างระหว่างการปรับใช้ใหม่และการปรับใช้ล่าสุดที่ทราบกันดีของคุณมีน้อย
ดำเนินการวิเคราะห์โหมดความล้มเหลวบนไปป์ไลน์การบูรณาการอย่างต่อเนื่องและการส่งมอบอย่างต่อเนื่อง (CI/CD) เพื่อช่วยระบุปัญหาที่อาจทำให้ความพยายามบรรเทาความยุ่งยากซับซ้อนขึ้น เช่นเดียวกับปริมาณงานของคุณโดยรวม ไปป์ไลน์ของคุณสามารถวิเคราะห์เพื่อระบุพื้นที่ที่อาจมีปัญหาเมื่อคุณพยายามลดประเภทการบรรเทาที่กำหนด
ใช้ฟังก์ชันการย้อนกลับอัตโนมัติอย่างรอบคอบ:
- เครื่องมือ CI/CD บางอย่างเช่น Azure DevOps มีฟังก์ชันการย้อนกลับอัตโนมัติในตัว พิจารณาใช้ฟังก์ชันนี้หากฟังก์ชันนี้ให้คุณค่าที่จับต้องได้แก่คุณ
- คุณควรใช้ฟังก์ชันการย้อนกลับอัตโนมัติหลังจากที่คุณทดสอบไปป์ไลน์อย่างละเอียดและสม่ำเสมอเท่านั้น ตรวจสอบให้แน่ใจว่าไปป์ไลน์ของคุณมีความสมบูรณ์เพียงพอที่จะแนะนำปัญหาเพิ่มเติม หากมีการทริกเกอร์การย้อนกลับอัตโนมัติ
- คุณต้องวางใจได้ว่าระบบอัตโนมัติปรับใช้การเปลี่ยนแปลงที่จำเป็นเท่านั้น และจะมีการทริกเกอร์เมื่อจำเป็นเท่านั้น ออกแบบทริกเกอร์ของคุณอย่างระมัดระวังเพื่อให้ตรงตามข้อกำหนดเหล่านี้
ใช้ความสามารถที่ได้รับจากแพลตฟอร์มระหว่างการย้อนกลับ ตัวอย่างเช่น การสำรองข้อมูลและการกู้คืนข้อมูลในจุดเวลาที่กำหนด สามารถช่วยในการจัดเก็บและการย้อนกลับข้อมูลได้ หรือหากคุณใช้เครื่องเสมือนเพื่อโฮสต์แอปพลิเคชันของคุณการกู้คืนสภาพแวดล้อมของคุณไปยังจุดตรวจสอบตั้งแต่ก่อนเกิดเหตุการณ์อาจเป็นประโยชน์
ทดสอบกลยุทธ์การลดความล้มเหลวในการปรับใช้ทั้งหมดของคุณบ่อยๆ เช่นเดียวกับแผนรับมือกับเหตุฉุกเฉินและแผนการกู้คืนความเสียหาย แผนความล้มเหลวในการปรับใช้ของคุณจะประสบความสำเร็จก็ต่อเมื่อทีมของคุณได้รับการฝึกอบรมและฝึกฝนอย่างสม่ำเสมอ วิศวกรรมความโกลาหลและการทดสอบการอัดฉีดข้อผิดพลาด อาจเป็นเทคนิคที่มีประสิทธิภาพสำหรับการทดสอบกลยุทธ์การลดการปรับใช้งานของคุณ
การอำนวยความสะดวก Power Platform
ไปป์ไลน์ใน Power Platform มุ่งหวังที่จะทำให้การจัดการวงจรชีวิตของแอปพลิเคชัน (ALM) เท่าเทียมกันสำหรับลูกค้า Power Platform และ Dynamics 365 โดยการนำระบบอัตโนมัติของ ALM และความสามารถในการรวมอย่างต่อเนื่องและการจัดส่งอย่างต่อเนื่อง (CI/CD) มาใส่ในบริการ
Microsoft Power Platform Build Tools สำหรับ Azure DevOps สามารถใช้เพื่อทำให้งานการสร้างและปรับใช้งานทั่วไปที่เกี่ยวข้องกับแอปที่สร้างบน Power Platform เป็นแบบอัตโนมัติ
GitHub Actions สำหรับ Power Platform ช่วยให้นักพัฒนาสามารถสร้างเวิร์กโฟลว์วงจรการพัฒนาซอฟต์แวร์อัตโนมัติ ด้วย GitHub Actions สำหรับ Microsoft Power Platform คุณสามารถสร้างเวิร์กโฟลว์ในที่เก็บของคุณเพื่อสร้าง ทดสอบ แพคเกจ นำออกใช้ และปรับใช้แอป ดำเนินการระบบอัตโนมัติ และจัดการบอทและส่วนประกอบอื่นๆ ที่สร้างขึ้นใน Microsoft Power Platform
ALM Accelerator เป็นเครื่องมือโอเพนซอร์สที่ประกอบด้วยชุดแอปพลิเคชัน สคริปต์ และไปป์ไลน์ที่ออกแบบมาเพื่อทำให้กระบวนการรวม/การจัดส่งอย่างต่อเนื่องเป็นไปโดยอัตโนมัติ
ทำการทดสอบอัตโนมัติกับ Azure Pipelines
ใช้ Power CAT Copilot Studio Kit เพื่อให้คุณสามารถกำหนดค่าเอเจนต์และการทดสอบ เมื่อเรียกใช้การทดสอบแต่ละรายการกับ Copilot Studio API (Direct Line) การตอบของเอเจนต์จะได้รับการประเมินเทียบกับผลลัพธ์ที่คาดไว้
ตัวแปรสภาพแวดล้อมในโซลูชัน จัดเก็บคีย์พารามิเตอร์และค่า ซึ่งทำหน้าที่เป็นข้อมูลอินพุตไปยังออบเจ็กต์แอปพลิเคชันอื่นๆ การแยกพารามิเตอร์ออกจากออบเจ็กต์ที่ใช้แล้วช่วยให้คุณสามารถเปลี่ยนค่าภายในสภาวะแวดล้อมเดียวกันหรือเมื่อคุณโอนย้ายโซลูชันไปยังสภาวะแวดล้อมอื่น
สภาพแวดล้อม Power Platform มีฟังก์ชันการกู้คืนจุดในเวลาที่สามารถช่วยคุณย้อนกลับได้
Power Platform ผสานรวมกับ Application Insights ซึ่งเป็นส่วนหนึ่งของระบบนิเวศ Azure Monitor ใช้การผสานรวมนี้ด้วย
รับการวัดและส่งข้อมูลทางไกลในการวินิจฉัยและประสิทธิภาพที่บันทึกโดยแพลตฟอร์ม Dataverse ใน Application Insights คุณสามารถสมัครรับการวัดและส่งข้อมูลทางไกลเกี่ยวกับการดำเนินการที่แอปพลิเคชันดำเนินการบนฐานข้อมูล Dataverse ของคุณและภายในแอปแบบจำลอง การวัดและส่งข้อมูลทางไกลนี้จะให้ข้อมูลที่คุณสามารถใช้เพื่อวินิจฉัยและแก้ไขปัญหาที่เกี่ยวข้องกับข้อผิดพลาดและประสิทธิภาพ
เชื่อมต่อแอปพื้นที่ทำงานกับ Application Insights คุณสามารถใช้การวิเคราะห์เหล่านี้เพื่อวินิจฉัยปัญหาและทำความเข้าใจสิ่งที่ผู้ใช้ทำกับแอปของคุณ คุณสามารถรวบรวมข้อมูลเพื่อช่วยในการตัดสินใจทางธุรกิจที่ดีขึ้น และปรับปรุงคุณภาพแอปของคุณ
กำหนดค่า การวัดและส่งข้อมูลทางไกลของ Power Automate เพื่อส่งเข้าสู่ Application Insights ตัวอย่างเช่น เพื่อตรวจสอบการดำเนินการของโฟลว์ระบบคลาวด์และสร้างการแจ้งเตือนสำหรับความล้มเหลวในการเรียกใช้โฟลว์ระบบคลาวด์
บันทึกข้อมูลการวัดและส่งข้อมูลทางไกลจาก เอเจนต์ Microsoft Copilot Studio ของคุณเพื่อใช้ใน Azure Application Insights คุณสามารถใช้การวัดและส่งข้อมูลทางไกลนี้เพื่อตรวจสอบข้อความและเหตุการณ์ที่บันทึกไว้ซึ่งส่งไปและกลับจากเอเจนต์ หัวข้อที่จะทริกเกอร์ระหว่างการสนทนาของผู้ใช้ และเหตุการณ์การวัดและส่งข้อมูลทางไกลแบบกำหนดเองที่สามารถส่งได้จากหัวข้อของคุณ
รายการตรวจสอบความเป็นเลิศในการดำเนินงาน
โปรดดูชุดคำแนะนำทั้งหมด