สํารวจการทดสอบ shift-right
ตามที่อธิบายไว้ก่อนหน้านี้ในหลักสูตร การทดสอบในการจัดการวงจรชีวิตของแอปพลิเคชันเป็นสิ่งสําคัญในการเพิ่มคุณภาพโค้ดให้สูงสุดและลดความเสี่ยงในการดําเนินงานที่เกี่ยวข้องกับการปรับใช้และการอัปเดตซอฟต์แวร์ นี่คือเหตุผลสําหรับการใช้ แบบ shift-left ซึ่งแนะนํากิจกรรมการทดสอบโดยเร็วที่สุดในขั้นตอนการพัฒนา อย่างไรก็ตามมีบางแง่มุมของการทดสอบซึ่งไม่มีประสิทธิภาพเมื่อดําเนินการในลักษณะนี้ แทนที่จะทําหน้าที่ตามวัตถุประสงค์ของพวกเขาอย่างเต็มที่ พวกเขาจําเป็นต้องดําเนินการในสภาพแวดล้อมการผลิต ซึ่งเรียกว่าวิธีการ เลื่อนขวาของ องค์กรในสถานการณ์ตัวอย่างของเราจะต้องใช้สิ่งนี้เพื่อประเมินความน่าเชื่อถือของระบบของตนควบคู่ไปกับการฉีดข้อบกพร่อง ในหน่วยนี้ ให้ตรวจสอบเกณฑ์นี้และเกณฑ์อื่น ๆ ที่การทดสอบแบบ shift-right มีความชอบธรรม
อะไรคือเหตุผลของการทดสอบ shift-right
ในขณะที่การทดสอบ shift-left เหมาะสําหรับการทดสอบหน่วยและควัน แต่จะดําเนินการภายใต้เงื่อนไขที่โดยทั่วไปแล้วแตกต่างจากที่สามารถใช้ได้กับเป้าหมายการจัดส่งที่กําหนดไว้ แม้แต่การรับประกันคุณภาพและสภาพแวดล้อมการจัดเตรียมก็แทบจะสะท้อนให้เห็นถึงความซับซ้อนของคู่การผลิตได้ไม่เต็มที่ มีประสิทธิภาพวิธีที่ดีที่สุดในการตรวจสอบลักษณะการทํางานของปริมาณงานที่ตามการปรับใช้อย่างเต็มที่คือการทดสอบณ จุดนั้น
การทดสอบในการผลิตมีประโยชน์ดังต่อไปนี้:
- แสดงเงื่อนไขการทํางานจริง รวมถึงการโหลดเพิ่มเติมที่เกี่ยวข้องกับการจัดการคําขอของผู้ใช้ปลายทาง
- คํานึงถึงปัจจัยต่างๆ ซึ่งจะเป็นการยากที่จะจําลอง เช่น การเชื่อมต่อกับระบบภายนอก
- สะท้อนการเปลี่ยนแปลงในความต้องการของปริมาณงานเมื่อเวลาผ่านไป
สถานการณ์การทดสอบ shift-right ทั่วไปคืออะไร
ในขณะที่วิธีการทดสอบแบบ shift-right อาจเป็นเหตุผลในหลายสถานการณ์ แต่มีหลายสถานการณ์ที่เหมาะสม สถานการณ์เหล่านี้รวมถึง:
การปรับใช้ Microservices: สถาปัตยกรรมไมโครบริการโดยทั่วไปจะประกอบด้วยส่วนประกอบที่พัฒนาขึ้นเองเป็นจํานวนมาก จํานวนชุดรวมของบริการเหล่านี้อาจจัดเต็มการทดสอบ shift-right เพื่อมุ่งเน้นไปที่สถานการณ์ที่เกี่ยวข้องมากที่สุดในสภาพแวดล้อมการผลิตจริง (ตามการใช้งานในชีวิตจริง)
การประเมินผลกระทบของแบนด์วิดท์เครือข่ายและเงื่อนไขเวลาแฝง: สภาพเครือข่ายมีแนวโน้มที่จะท้าทายในการจําลอง ดังนั้นหากประสิทธิภาพของปริมาณงานมีความล่าช้าหรือแบนด์วิดท์ที่สูง การทดสอบ shift-right อาจเป็นตัวเลือกที่เหมาะสมที่สุด
การทดสอบการยอมรับของผู้ใช้: คําติชมของผู้ใช้จริงอาจจําเป็นสําหรับการตรวจสอบประสิทธิภาพและการใช้งานของปริมาณงาน
ขั้นตอนการตรวจสอบการเฟลโอเวอร์ในการกําหนดค่าที่ซ้ําซ้อน: การฉีดข้อบกพร่องและการทดสอบการกู้คืนจากภัยพิบัติมีไว้เพื่อประเมินความยืดหยุ่นของปริมาณงานในการผลิต การฉีดข้อบกพร่องเกี่ยวข้องกับการแนะนําความล้มเหลวอย่างตั้งใจในส่วนประกอบแต่ละส่วนของปริมาณงานในระหว่างการดําเนินการเพื่อระบุจุดอ่อนใด ๆ และลดความอ่อนแอเหล่านี้เพิ่มความน่าเชื่อถือโดยรวม
โน้ต
วิศวกรรมความโกลาหลเป็นอีกแนวคิดหนึ่งในด้านการทดสอบความน่าเชื่อถือของ DevOps เช่นเดียวกับการฉีดข้อบกพร่องจะเกี่ยวข้องกับการจําลองความล้มเหลว (ในกรณีนี้เพื่อสร้าง ความโกลาหล ควบคุมในระบบที่กําลังทดสอบ) อย่างไรก็ตาม ขอบเขตของมันจะกว้างกว่า กําหนดเป้าหมายทั้งระบบ แทนที่จะเป็นแค่ส่วนประกอบแต่ละส่วน และสถานการณ์การทดสอบมีแนวโน้มที่จะครอบคลุมมากขึ้น วิศวกรรมความโกลาหลมักถูกจํากัดไว้ที่ สภาพแวดล้อมของ ควันที่มีผลกระทบการผลิตที่จํากัดมากหรือไม่มีเลย
โน้ต
คุณสามารถใช้ Azure Chaos Studio เพื่อดําเนินการทดลองวิศวกรรมที่โกลาหลที่กําหนดเป้าหมายโซลูชันที่โฮสต์ใน Microsoft Azure ได้ คุณจะผ่านตัวอย่างการทดลองดังกล่าวในแล็บของโมดูลนี้