คำแนะนำสำหรับการออกแบบกลยุทธ์การทดสอบความน่าเชื่อถือ
นำไปใช้กับคำแนะนำรายการตรวจสอบความน่าเชื่อถือของ Power Platform Well-Architected:
| RE:06 | ทดสอบสถานการณ์ความยืดหยุ่นและความพร้อมใช้งานโดยใช้หลักการของวิศวกรรมความโกลาหลในสภาพแวดล้อมการทดสอบและการทำงานจริงของคุณ ใช้การทดสอบเพื่อให้แน่ใจว่ากลยุทธ์การดำเนินการลดประสิทธิภาพอย่างค่อยเป็นค่อยไปของคุณจะมีประสิทธิภาพโดยการทำงานผิดพลาดแบบแอ็กทีฟและการทดสอบการโหลดจำลอง |
|---|
คู่มือนี้จะอธิบายคำแนะนำในการออกแบบกลยุทธ์การทดสอบความน่าเชื่อถือเพื่อตรวจสอบและเพิ่มประสิทธิภาพความน่าเชื่อถือของเวิร์กโหลดของคุณ การทดสอบความน่าเชื่อถือมุ่งเน้นที่ความยืดหยุ่นและความพร้อมใช้งานของเวิร์กโหลดของคุณ โดยเฉพาะขั้นตอนสำคัญที่คุณระบุเมื่อคุณออกแบบโซลูชัน คู่มือนี้ให้คำแนะนำในการทดสอบทั่วไปและคำแนะนำและที่เกี่ยวข้องกับการแทรกโค้ดที่สร้างข้อผิดพลาดและวิศวกรรมความโกลาหลโดยเฉพาะ
คำนิยาม
| เงื่อนไข | ข้อกำหนด |
|---|---|
| ความพร้อมบริการ | ระยะเวลาที่เวิร์กโหลดของแอปพลิเคชันทำงานในสถานะคุณภาพดีโดยไม่มีการหยุดทำงานที่มีนัยสำคัญ |
| วิศวกรรมความโกลาหล | แนวทางปฏิบัติในการควบคุมแอปพลิเคชันและบริการตามความเครียดและความล้มเหลวในโลกจริง เป้าหมายของวิศวกรรมความโกลาหลคือ การสร้างและตรวจสอบความยืดหยุ่นต่อสภาวะที่ไม่น่าเชื่อถือและการขึ้นต่อกันที่ขาดหายไป |
| การแทรกโค้ดที่สร้างข้อผิดพลาด | การเพิ่มข้อผิดพลาดให้กับระบบเพื่อทดสอบความยืดหยุ่นของระบบ |
| ความสามารถในการกู้คืน | คำพ้องความหมายสำหรับความยืดหยุ่น |
| ความยืดหยุ่น | ความสามารถของเวิร์กโหลดของแอปพลิเคชันในการต้านทานและกู้คืนจากโหมดความล้มเหลว |
กลยุทธ์การออกแบบที่สำคัญ
การทดสอบถือเป็นสิ่งสำคัญเพื่อให้แน่ใจว่าเวิร์กโหลดของคุณบรรลุเป้าหมายด้านความน่าเชื่อถือและสามารถจัดการกับความล้มเหลวได้อย่างดี การแทรกโค้ดที่สร้างข้อผิดพลาด คือการทดสอบประเภทหนึ่งที่จงใจนำข้อข้อบกพร่องหรือความตึงเครียดเข้าสู่ระบบของคุณเพื่อจำลองสถานการณ์ในโลกจริง ด้วยการใช้เทคนิคการแทรกโค้ดที่สร้างข้อผิดพลาดและวิศวกรรมความโกลาหล คุณสามารถค้นพบและแก้ไขปัญหาเชิงรุกก่อนที่จะส่งผลกระทบต่อสภาพแวดล้อมการทำงานจริงของคุณ ส่วนนี้ให้คำแนะนำทั่วไปเกี่ยวกับการทดสอบ การแทรกโค้ดที่สร้างข้อผิดพลาด และวิศวกรรมความโกลาหลสำหรับเวิร์กโหลดของคุณ
คำแนะนำการทดสอบทั่วไป
ทำการทดสอบเป็นประจำเพื่อตรวจสอบค่าเกณฑ์ เป้าหมาย และสมมติฐานที่มีอยู่ เมื่อมีการเปลี่ยนแปลงที่สำคัญเกิดขึ้นกับเวิร์กโหลดของคุณ ให้ทำการทดสอบเป็นประจำ ทำการทดสอบส่วนใหญ่ในสภาพแวดล้อมการทดสอบและการจัดเตรียม นอกจากนี้ การทำการทดสอบชุดย่อยกับระบบที่ใช้งานจริงยังเป็นประโยชน์อีกด้วย
ทำการทดสอบอัตโนมัติเพื่อช่วยรับประกันความครอบคลุมและความสามารถในการทำซ้ำของการทดสอบที่สอดคล้องกัน ทำให้งานทดสอบทั่วไปเป็นอัตโนมัติและรวมเข้ากับกระบวนการสร้างของคุณ การทดสอบซอฟต์แวร์ด้วยตนเองนั้นน่าเบื่อและเสี่ยงต่อการเกิดข้อผิดพลาด แต่คุณสามารถทำการทดสอบเชิงสำรวจด้วยตนเองได้ สำหรับกรณีที่คุณต้องพัฒนาการทดสอบอัตโนมัติ ให้ใช้การทดสอบด้วยตนเองเพื่อกำหนดขอบเขตของการทดสอบที่จะพัฒนา
นำวิธีการทดสอบแบบเลื่อนซ้ายมาใช้เพื่อทำการทดสอบความยืดหยุ่นและความพร้อมใช้งานในช่วงต้นของวงจรการพัฒนา
ปรับรูปแบบเอกสารที่เรียบง่าย เพื่อให้ทุกคนเข้าใจกระบวนการและผลลัพธ์ของการทดสอบปกติทุกครั้งได้อย่างง่ายดาย
แบ่งปันผลลัพธ์ที่บันทึกไว้กับทีมที่เหมาะสม เช่น ทีมปฏิบัติการ ผู้นำด้านเทคโนโลยี ผู้เกี่ยวข้องทางธุรกิจ และผู้เกี่ยวข้องในการกู้คืนระบบ ผลลัพธ์ควรแจ้งถึงการปรับแต่งสำหรับเป้าหมายด้านความน่าเชื่อถือ เช่น วัตถุประสงค์ระดับการให้บริการ (SLO) ข้อตกลงระดับการให้บริการ (SLA) วัตถุประสงค์เวลาการกู้คืน (RTO) และวัตถุประสงค์จุดกู้คืน (RPO)
สร้างลำดับการทดสอบปกติสำหรับการสำรองข้อมูลของคุณ กู้คืนข้อมูลไปยังระบบที่แยกออกมาเพื่อช่วยให้แน่ใจว่าข้อมูลสำรองนั้นถูกต้องและการคืนค่านั้นทำงานได้
จัดทำเอกสารและแบ่งปันเมตริกเวลาการกู้คืนกับผู้เกี่ยวข้องในการกู้คืนความเสียหายเพื่อให้แน่ใจว่าความคาดหวังในการกู้คืนมีความเหมาะสม
ใช้ขั้นตอนการทดสอบการปรับใช้งานมาตรฐานอุตสาหกรรมเพื่อช่วยให้แน่ใจว่าคุณมีกระบวนการปรับใช้งานแบบอัตโนมัติ คาดการณ์ได้ และมีประสิทธิภาพ
ทดสอบความสามารถของเวิร์กโหลดของคุณในการทนต่อความล้มเหลวชั่วคราว สำหรับข้อมูลเพิ่มเติม โปรดดู คำแนะนำสำหรับการจัดการข้อบกพร่องชั่วคราว
ทดสอบว่าเวิร์กโหลดของคุณจัดการกับความล้มเหลวในบริการที่ต้องขึ้นต่อกันหรือการขึ้นต่อกันอื่นๆ ได้อย่างไรโดยใช้การแทรกโค้ดที่สร้างข้อผิดพลาด
ทดสอบ แผนการกู้คืนความเสียหาย ของคุณเพื่อรับมือความล้มเหลวด้านภัยพิบัติและเหตุการณ์สำคัญอื่นๆ
ทดสอบความสามารถของเวิร์กโหลดของคุณที่จะค่อยๆ ลดประสิทธิภาพลง และลดรัศมีการกระจายของส่วนประกอบที่ทำงานผิดปกติโดยใช้การแทรกโค้ดที่สร้างข้อผิดพลาด
ใช้ประโยชน์จากการหยุดทำงานที่วางแผนไว้และไม่ได้วางแผนไว้
เมื่อเวิร์กโหลดของคุณออฟไลน์เนื่องจากการบำรุงรักษาตามแผนหรือการหยุดทำงานโดยไม่คาดคิด คุณจะมีโอกาสพิเศษในการทำการทดสอบและปรับปรุงความเข้าใจเกี่ยวกับเวิร์กโหลดของคุณ ส่วนต่อไปนี้ให้คำแนะนำเพิ่มเติมสำหรับแต่ละสถานการณ์
การบำรุงรักษาที่วางแผน
เมื่อคุณวางแผนช่วงเวลาการบำรุงรักษาสำหรับการอัปเดตหรือโปรแกรมแก้ไข คุณสามารถทดสอบส่วนประกอบและโฟลว์ที่ไม่เกี่ยวข้องกับงานบำรุงรักษาได้ ทำการทดสอบโดยไม่มีความเสี่ยงที่อาจจะทำให้เวิร์กโหลดลดประสิทธิภาพลงโดยไม่คาดคิดหรือทำให้ไม่ทำงานโดยสิ้นเชิง หากคุณมีเวลาเพียงพอในระหว่างช่วงเวลาการบำรุงรักษา คุณยังสามารถทดสอบส่วนประกอบและโฟลว์ที่เกี่ยวข้องกับการบำรุงรักษาได้หลังจากงานบำรุงรักษาเสร็จสมบูรณ์
การหยุดทำงานโดยไม่คาดคิด
ใช้ทุกเหตุการณ์การหยุดทำงานเป็นโอกาสในการเรียนรู้เพิ่มเติมเกี่ยวกับเวิร์กโหลดของคุณ และปรับปรุงความยืดหยุ่นโดยทำตามขั้นตอนเหล่านี้ เรียงตามลำดับความสำคัญ:
นำเวิร์กโหลดกลับมาออนไลน์สำหรับผู้ใช้ของคุณ คุณอาจต้องดำเนินการแก้ไขปัญหาชั่วคราว แก้ไขปัญหา หรือเริ่มกระบวนการกู้คืน
ระบุสาเหตุหลักของการหยุดทำงานและแก้ไข หากคุณสามารถแก้ไขสาเหตุหลักโดยเป็นส่วนหนึ่งของการสอบสวน ให้บันทึกสาเหตุหลักและมาตรการที่คุณใช้เพื่อแก้ไข หากปัญหาต้องใช้หน้าต่างการบำรุงรักษาอื่นในภายหลังตรวจสอบให้แน่ใจว่ามาตรการบรรเทาผลกระทบของคุณสามารถรองรับภาระที่คาดไว้ได้โดยการทดสอบอย่างละเอียด ตรวจสอบให้แน่ใจว่าคุณได้ตั้งค่าการตรวจสอบที่เพียงพอเพื่อให้ครอบคลุมมาตรการลดผลกระทบของคุณ
หากเป็นไปได้ ให้มองหาปัญหาเดียวกันหรือจุดอ่อนของการกำหนดค่าที่อาจได้รับผลกระทบจากปัญหาที่คล้ายกันในส่วนประกอบทั้งหมดในเวิร์กโหลดของคุณ ใช้โอกาสนี้จัดการกับส่วนประกอบเหล่านั้นในเชิงป้องกัน ดูประวัติเหตุการณ์ของคุณเพื่อตรวจหารูปแบบของปัญหาที่คล้ายกันทั่วทั้งเวิร์กโหลดของคุณ
ใช้สิ่งที่คุณค้นพบเพื่อปรับปรุงกลยุทธ์การทดสอบของคุณ ตรวจสอบให้แน่ใจว่าคุณได้แก้ไขสาเหตุหลักและปัญหาที่คล้ายกันได้สำเร็จโดยการทดสอบความล้มเหลวเดียวกันโดยตรง
คำแนะนำเกี่ยวกับการแทรกโค้ดที่สร้างข้อผิดพลาดและวิศวกรรมความโกลาหล
การทดสอบการแทรกโค้ดที่สร้างข้อผิดพลาดเป็นไปตามหลักการของวิศวกรรมความโกลาหล โดยเน้นไปที่ความสามารถของเวิร์กโหลดในการรับมือความล้มเหลวของส่วนประกอบ ทำการทดสอบการแทรกโค้ดที่สร้างข้อผิดพลาดในสภาพแวดล้อมก่อนทำงานจริงและการทำงานจริง ใช้ข้อมูลที่คุณเรียนรู้จาก การดำเนินการวิเคราะห์โหมดความล้มเหลว เพื่อทำให้แน่ใจว่าคุณทดสอบเฉพาะข้อบกพร่องที่คุณจัดลำดับความสำคัญ และคุณมีกลยุทธ์ในการลดปัญหาที่แก้ไขข้อบกพร่อง
แนวทางที่สำคัญของวิศวกรรมความโกลาหลคือ:
ทำงานเชิงรุก อย่ารอให้ความล้มเหลวเกิดขึ้น พยายามคาดการณ์ความล้มเหลวโดยทำการทดลองที่วุ่นวายเพื่อค้นหาและแก้ไขปัญหาก่อนที่จะส่งผลกระทบต่อสภาพแวดล้อมการทำงานจริงของคุณ
เข้าใจความล้มเหลว ยอมรับและเรียนรู้จากความล้มเหลวที่เกิดขึ้นในระบบของคุณ มองความล้มเหลวเป็นส่วนหนึ่งของระบบที่ซับซ้อนโดยธรรมชาติ และใช้ความล้มเหลวเป็นโอกาสในการเรียนรู้และปรับปรุงความน่าเชื่อถือของระบบของคุณ
แยกระบบ จงใจใส่ข้อบกพร่องหรือความตึงเครียดเข้าไปในระบบของคุณเพื่อทดสอบความยืดหยุ่น จำลองความล้มเหลวหรือการหยุดชะงักในโลกจริงเพื่อทดสอบและปรับปรุงความสามารถในการกู้คืนเวิร์กโหลดของคุณ
สร้างภูมิคุ้มกัน ใช้การทดลองวิศวกรรมความโกลาหลเพื่อปรับปรุงความสามารถของเวิร์กโหลดของคุณในการป้องกันและกู้คืนจากความล้มเหลว
วิศวกรรมความโกลาหลเป็นส่วนสำคัญของวัฒนธรรมทีมจัดการเวิร์กโหลดและการฝึกปฏิบัติอย่างต่อเนื่อง ไม่ใช่ความพยายามทางยุทธวิธีระยะสั้นเพื่อรับมือเหตุขัดข้องเพียงครั้งเดียว ปฏิบัติตามวิธีมาตรฐานนี้เมื่อคุณออกแบบการทดสอบความโกลาหล:
เริ่มต้นด้วยสมมติฐาน การทดลองแต่ละครั้งควรมีเป้าหมายที่ชัดเจน เช่น การทดสอบความสามารถของโฟลว์ในการต้านทานการสูญเสียส่วนประกอบเฉพาะ
วัดผลลักษณะการทำงานพื้นฐาน ตรวจสอบให้แน่ใจว่าคุณมีเมตริกความน่าเชื่อถือและประสิทธิภาพที่สอดคล้องกันสำหรับโฟลว์และส่วนประกอบที่เกี่ยวข้องกับการทดสอบเพื่อเปรียบเทียบกับสถานะด้อยคุณภาพเมื่อทำการทดสอบของคุณ
แทรกโค้ดที่สร้างข้อผิดพลาด การทดลองควรตั้งใจกำหนดเป้าหมายส่วนประกอบเฉพาะที่สามารถกู้คืนได้อย่างรวดเร็ว และคุณควรทราบถึงผลกระทบที่การแทรกโค้ดที่สร้างข้อผิดพลาดจะเกิดขึ้นเพื่อช่วยควบคุมรัศมีการกระจายของการทดลอง
ตรวจสอบลักษณะการทำงานที่เกิดขึ้น รวบรวมข้อมูลการวัดและส่งข้อมูลทางไกลเกี่ยวกับส่วนประกอบของโฟลว์แต่ละรายการและลักษณะการทำงานของโฟลว์ตั้งแต่ต้นทางถึงปลายทางที่การทดสอบตั้งเป้าหมายเพื่อทำความเข้าใจผลกระทบของข้อบกพร่องอย่างเหมาะสม เปรียบเทียบเมตริกที่คุณรวบรวมกับเมตริกพื้นฐานเพื่อดูภาพรวมของผลลัพธ์การแทรกโค้ดที่สร้างข้อผิดพลาด
จัดทำเอกสารกระบวนการและการสังเกต การเก็บบันทึกการทดลองโดยละเอียดจะบอกถึงการตัดสินใจในอนาคตเกี่ยวกับการออกแบบเวิร์กโหลด เพื่อให้มั่นใจว่าคุณจะจัดการกับช่องว่างที่เสี่ยงเมื่อเวลาผ่านไป
ระบุและดำเนินการกับผลลัพธ์ วางแผนขั้นตอนการแก้ไขที่สามารถเพิ่มลงในเวิร์กโหลดที่ค้างอยู่เป็นการปรับปรุงได้ ตรวจสอบให้แน่ใจว่าแผนการปรับปรุงการออกแบบได้รับการทบทวนและทดสอบในสภาพแวดล้อมที่ไม่ใช่การทำงานจริงตามกระบวนการเดียวกันกับการปรับใช้งานอื่นๆ
ตรวจสอบกระบวนการ ตัวเลือกสถาปัตยกรรม และโค้ดของคุณเป็นระยะเพื่อตรวจจับหนี้ทางเทคนิคได้อย่างรวดเร็ว บูรณาการเทคโนโลยีใหม่ และปรับให้เข้ากับข้อกำหนดที่เปลี่ยนแปลง
เมื่อคุณทำการทดลองการส่งต่อข้อบกพร่อง คุณจะ:
ยืนยันว่ามีการตรวจสอบและตั้งค่าการแจ้งเตือนแล้ว
ตรวจสอบกระบวนการของคุณในการมอบหมายบุคคลที่รับผิดชอบโดยตรง (DRI) ให้เป็นเจ้าของเหตุการณ์
ตรวจสอบให้แน่ใจว่าเอกสารและกระบวนการสอบสวนของคุณเป็นข้อมูลล่าสุด
บูรณาการคำแนะนำและข้อควรพิจารณาต่อไปนี้เพื่อปรับกลยุทธ์การทดสอบความโกลาหลของคุณให้เหมาะสม:
สมมติฐานของระบบที่ท้าทาย ด้วยการทดสอบ คุณพยายามปรับปรุงความยืดหยุ่นของเวิร์กโหลดและกลยุทธ์การออกแบบเวิร์กโหลดของคุณ มองหาโอกาสในการแทรกโค้ดที่สร้างข้อผิดพลาดลงในส่วนประกอบและโฟลว์ที่คุณเห็นว่าเชื่อถือได้โดยพิจารณาจากประสบการณ์ที่ผ่านมา สิ่งเหล่านี้อาจไม่น่าเชื่อถือในเวิร์กโหลดใหม่ของคุณ
ตรวจสอบการเปลี่ยนแปลง หากไม่มีการทดสอบอย่างละเอียด รวมถึงการทดสอบการแทรกโค้ดที่สร้างข้อผิดพลาด คุณอาจมีภาพรวมเวิร์กโหลดของคุณที่ไม่สมบูรณ์หลังจากทำการเปลี่ยนแปลง ตัวอย่างเช่น คุณอาจใช้การขึ้นต่อกันใหม่ที่ไม่ปรากฏให้เห็นในทันที
ใช้บัฟเฟอร์ SLA จำกัดการทดสอบความโกลาหลเพื่อให้อยู่ภายใน SLA ของคุณและหลีกเลี่ยงผลกระทบด้านลบที่อาจเกิดขึ้นจากการหยุดทำงาน เป้าหมายการกู้คืนโฟลว์และส่วนประกอบของคุณช่วยกำหนดขอบเขตของการทดสอบของคุณ
กำหนดงบประมาณข้อผิดพลาดโดยเป็นการลงทุนในความโกลาหลและการแทรกโค้ดที่สร้างข้อผิดพลาด ข้อผิดพลาดที่ถือว่ารับได้คือ ความแตกต่างระหว่างการบรรลุผล SLO ครบ 100% และการบรรลุ SLO ตามที่ตกลงกันไว้
หยุดการทดสอบหากเกินขอบเขต ผลลัพธ์ที่ไม่ทราบคือผลลัพธ์ที่คาดหวังจากการทดลองความโกลาหล มุ่งมั่นที่จะทำให้ได้รับความสมดุลระหว่างการรวบรวมข้อมูลผลลัพธ์ที่สำคัญและส่งผลกระทบต่อผู้ใช้ที่ใช้งานจริงให้น้อยที่สุด
ทำงานอย่างใกล้ชิดกับทีมพัฒนาเพื่อให้แน่ใจว่ามีความเกี่ยวข้องของความล้มเหลวที่ใส่เข้ามา ใช้เหตุการณ์หรือปัญหาในอดีตเป็นแนวทาง ตรวจสอบการขึ้นต่อกันและประเมินผลลัพธ์เมื่อคุณลบการขึ้นต่อกันเหล่านั้น
ระบุและจัดทำเอกสารการขึ้นต่อกันที่ยังไม่ถูกค้นพบก่อนหน้านี้ระหว่างส่วนประกอบต่างๆ ภายในเวิร์กโหลดของคุณที่ถูกเปิดเผยผ่านการทดสอบความโกลาหล
ปรับแผนการกู้คืนตามความจำเป็นเพื่อพิจารณาการขึ้นต่อกันที่พบในระหว่างการทดสอบความโกลาหล
ใช้ผลลัพธ์จากการทดลองและการทดสอบของคุณเป็นพื้นฐานสำหรับการทดลองและการทดสอบใหม่ เมื่อมีลักษณะการทำงานที่ไม่คาดคิดเกิดขึ้น การทดสอบใหม่อาจกำหนดเป้าหมายลักษณะการทำงานเหล่านั้นโดยตรง และเปิดโอกาสให้คุณออกแบบกลยุทธ์การแก้ไขสำหรับลักษณะการทำงานเหล่านั้น
การแลกเปลี่ยน: การทดสอบการส่งผิดพลาดในการทำงานจริงอาจสร้างความเสียหายและอาจทำให้ต้องหยุดทำงาน มีความโปร่งใสกับผู้เกี่ยวข้องเกี่ยวกับความเป็นไปได้นี้ และทำให้แน่ใจว่าคุณมีมาตรการป้องกันเพื่อยุติการทดลองและแผนการย้อนกลับเพื่อย้อนกลับความล้มเหลวที่คุณนำมาใช้ได้อย่างรวดเร็ว
การอำนวยความสะดวกของ Power Platform
คุณสามารถใช้ ผลลัพธ์แบบคงที่ใน Power Automate เพื่อส่งคืนผลลัพธ์คงที่ในการทดสอบเวิร์กโหลดของคุณ
เครื่องมือทดสอบ Power Apps (พรีวิว) เป็นส่วนประกอบ Power Platform CLI ที่คุณสามารถใช้เพื่อทดสอบแอปพื้นที่ทำงานแบบสแตนด์อโลนใน Power Apps
แผนทดสอบ Azure เป็นโซลูชันการจัดการกับการทดสอบบนเบราว์เซอร์ที่ใช้งานง่าย ซึ่งมีความสามารถทั้งหมดที่จำเป็นสำหรับการทดสอบด้วยตนเองตามแผน การทดสอบการยอมรับของผู้ใช้ การทดสอบเชิงสำรวจ และการรวบรวมข้อคิดเห็นจากผู้เกี่ยวข้อง
หากเวิร์กโหลดของคุณมีทรัพยากร Azure คุณสามารถใช้ Azure Chaos Studio ซึ่งเป็นบริการที่มีการจัดการที่ใช้เทคโนโลยีวิศวกรรมความโกลาหล เพื่อช่วยคุณวัดผล ทำความเข้าใจ และปรับปรุงแอปพลิเคชันในระบบคลาวด์และความยืดหยุ่นของบริการ
หากเวิร์กโหลดของคุณมีเอเจนต์ Microsoft Copilot Studio คุณสามารถใช้ Power CAT Copilot Studio Kit เพื่อกำหนดค่าเอเจนต์และการทดสอบได้ เมื่อเรียกใช้การทดสอบแต่ละรายการกับ Copilot Studio API (Direct Line) การตอบของเอเจนต์จะได้รับการประเมินเทียบกับผลลัพธ์ที่คาดไว้
รายการตรวจสอบความน่าเชื่อถือ
โปรดดูชุดคำแนะนำทั้งหมด