การทำให้การติดตั้งใช้จริงทำงานอัตโนมัติโดยสมบูรณ์อย่างปลอดภัย

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

ดิฉันเคยอ่านพบว่า Amazon มีข้อปฏิบัติในการติดตั้งใช้จริงอย่างต่อเนื่อง เมื่อดิฉันให้สัมภาษณ์ ดิฉันจึงอยากรู้ว่าในฐานะนักพัฒนาที่ Amazon ดิฉันจะต้องใช้เวลาเท่าใดในการจัดการและเฝ้าดูการติดตั้งใช้จริง ผู้สัมภาษณ์บอกดิฉันว่าการเปลี่ยนแปลงถูกนำไปติดตั้งใช้จริงในการทำงานจริงวันละหลายครั้งโดยอัตโนมัติโดยไปป์ไลน์สำหรับการติดตั้งใช้จริงอย่างต่อเนื่อง เมื่อดิฉันถามว่าในวันหนึ่งๆ เขาต้องใช้เวลาเท่าใดในเฝ้าดูการติดตั้งใช้จริงแต่ละครั้งอย่างระมัดระวัง และเฝ้าดูบันทึกและตัวชี้วัดต่างๆ เพื่อดูผลกระทบใดๆ อย่างที่ดิฉันเคยทำ เขาตอบว่าปกติไม่เคยทำเลย เนื่องจากไปป์ไลน์ทำงานนี้ให้ทีมของเขา จึงไม่มีผู้ใดเฝ้าติดตามการติดตั้งใช้จริงส่วนใหญ่อย่างจริงจัง “โอโห!” ดิฉันกล่าว หลังจากที่ดิฉันเข้าทำงานกับ Amazon แล้ว ดิฉันตื่นเต้นที่จะสำรวจดูว่าการติดตั้งใช้จริงที่ทำงานอัตโนมัติ “โดยไม่ต้องใช้มือ” นี้ทำงานอย่างไร

Amazon ไม่ได้เริ่มต้นด้วยข้อปฏิบัติในการส่งมอบอย่างต่อเนื่อง และนักพัฒนาเคยใช้เวลาเป็นชั่วโมงๆ และเป็นวันๆ เพื่อจัดการกับการนำโค้ดมาติดตั้งใช้จริงในการทำงานจริง เราได้รับเอาการส่งมอบอย่างต่อเนื่องมาใช้ทั่วบริษัท เพื่อเป็นวิธีในการทำให้การนำซอฟต์แวร์ไปติดตั้งใช้จริงทำงานอัตโนมัติและกำหนดมาตรฐานให้กับวิธีการดังกล่าว และเพื่อลดเวลาที่ใช้ในการนำการเปลี่ยนแปลงไปสู่การทำงานจริง การปรับปรุงที่มีต่อกระบวนการออกงานของเราสะสมเพิ่มขึ้นเมื่อเวลาผ่านไปนานๆ เราได้ระบุความเสี่ยงในการติดตั้งใช้จริงและพบวิธีในการบรรเทาความเสี่ยงเหล่านั้นผ่านระบบความปลอดภัยใหม่ที่ทำงานอัตโนมัติในไปป์ไลน์ เราดำเนินการออกงานต่อไปครั้งแล้วครั้งเล่าด้วยการระบุความเสี่ยงใหม่ๆ และวิธีการใหม่ๆ ในการปรับปรุงความปลอดภัยในการติดตั้งใช้จริง หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับการดำเนินการไปสู่การส่งมอบอย่างต่อเนื่องของเราและวิธีการที่เราปรับปรุงอย่างต่อเนื่อง โปรดดูบทความใน Builders’ Library เรื่อง ทำงานเร็วขึ้นด้วยการส่งมอบอย่างต่อเนื่อง

ในบทความนี้ เราจะอธิบายขั้นตอนต่างๆ ที่การเปลี่ยนแปลงโค้ดต้องผ่านในไปป์ไลน์ของ Amazon เพื่อไปสู่การทำงานจริง ไปป์ไลน์ของการส่งมอบอย่างต่อเนื่องโดยทั่วไปมี 4 ระยะสำคัญ ได้แก่ ซอร์ส การสร้าง การทดสอบ และการทำงานจริง (prod) เราจะแสดงรายละเอียดว่ามีอะไรเกิดขึ้นบ้างในแต่ละระยะของไปป์ไลน์ดังกล่าวสำหรับบริการของ AWS โดยทั่วไป และแสดงตัวอย่างวิธีการที่ทีมบริการของ AWS โดยทั่วไปกำหนดไปป์ไลน์

แผนภาพต่อไปนี้แสดงภาพรวมของขั้นตอนซอร์สและการสร้างที่พบได้ในไปป์ไลน์ของทีมบริการของ AWS โดยทั่วไป

ไปป์ไลน์ของ Amazon จะตรวจสอบความถูกต้องโดยอัตโนมัติและนำการเปลี่ยนแปลงซอร์สประเภทใดๆ ไปติดตั้งใช้จริงในการทำงานจริงอย่างปลอดภัย ไม่ใช่แค่เพียงการเปลี่ยนแปลงต่อโค้ดของแอปพลิเคชัน ซึ่งสามารถตรวจสอบความถูกต้องของการเปลี่ยนแปลงและนำไปติดตั้งใช้จริงในซอร์ส เช่น ทรัพยากรคงที่ของเว็บไซต์ เครื่องมือ การทดสอบ โครงสร้างพื้นฐาน การกำหนดค่า และระบบปฏิบัติการ (OS) ที่รองรับของแอปพลิเคชัน การเปลี่ยนแปลงดังกล่าวทั้งหมดมีการควบคุมเวอร์ชันในที่เก็บซอร์สโค้ดแต่ละแห่ง สิ่งที่ขึ้นอยู่กับซอร์สโค้ด เช่น ไลบรารี ภาษาการเขียนโปรแกรม และพารามิเตอร์ต่างๆ เช่น AMI ID จะอัปเกรดโดยอัตโนมัติเป็นเวอร์ชันล่าสุดอย่างน้อยสัปดาห์ละครั้ง

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

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

การเปลี่ยนแปลงทั้งหมดที่จะไปสู่การทำงานจริงเริ่มต้นด้วยการตรวจสอบโค้ด และต้องได้รับอนุมัติจากสมาชิกในทีมก่อนที่จะนำไปรวมในสาขาเมนไลน์ (“Main” หรือ “Trunk” ในเวอร์ชันของเรา) ซึ่งจะเริ่มต้นไปป์ไลน์โดยอัตโนมัติ ไปป์ไลน์จะบังคับใช้ข้อกำหนดที่การยืนยันทั้งหมดในสาขาเมนไลน์จะต้องผ่านการตรวจสอบและอนุมัติโค้ดจากสมาชิกทีมบริการสำหรับไปป์ไลน์นั้น ไปป์ไลน์จะบล็อกการยืนยันที่ยังไม่ได้ตรวจสอบใดๆ ไม่ให้นำไปติดตั้งใช้จริง

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

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

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

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

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

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

ก่อนที่จะติดตั้งใช้จริงในการทำงานจริง เราจำเป็นต้องตรวจสอบให้แน่ใจว่าโค้ดล่าสุดนั้นเข้ากันได้กับรุ่นที่เก่ากว่า และสามารถนำไปติดตั้งใช้จริงร่วมกับโค้ดปัจจุบันได้อย่างปลอดภัย ตัวอย่างเช่น เราจำเป็นต้องตรวจสอบว่าโค้ดล่าสุดเขียนข้อมูลในรูปแบบที่โค้ดปัจจุบันไม่สามารถแยกวิเคราะห์ได้หรือไม่ ระยะการติดตั้งใช้จริงในหน่วยเดียวในสภาพแวดล้อมแกมม่านำโค้ดล่าสุดมาติดตั้งใช้จริงในหน่วยที่เล็กที่สุดของการติดตั้งใช้จริง เช่น ในเครื่องเสมือนเครื่องเดียวหรือคอนเทนเนอร์เดียว หรือใช้กับการเรียกฟังก์ชัน AWS Lambda ในสัดส่วนเล็กน้อย การติดตั้งใช้จริงในหน่วยเดียวนี้จะนำส่วนที่เหลือของสภาพแวดล้อมแกมม่ามาติดตั้งใช้จริงร่วมกับโค้ดปัจจุบันในระยะเวลาหนึ่ง เช่น 30 นาทีหรือหนึ่งชั่วโมง ทั้งนี้ไม่จำเป็นต้องขับเคลื่อนปริมาณข้อมูลไปยังหน่วยเดียวเป็นพิเศษ โดยสามารถเพิ่มในโหลดบาลานเซอร์เดียวกัน หรือสำรวจคิวเดียวกันกับส่วนที่เหลือของสภาพแวดล้อมแกมม่าได้ ตัวอย่างเช่น ในสภาพแวดล้อมแกมม่าที่มี 10 คอนเทนเนอร์หลังโหลดบาลานเซอร์ หน่วยเดียวได้รับ 10% ของปริมาณข้อมูลของแกมม่าที่สร้างขึ้นโดยการทดสอบคานารีต่อเนื่อง การติดตั้งใช้จริงในหน่วยเดียวจะติดตามอัตราความสำเร็จของการทดสอบคานารีและตัวชี้วัดบริการ เพื่อตรวจหาผลกระทบใดๆ จากการติดตั้งใช้จริง หรือจากการนำกลุ่มที่ “ปะปนกัน” มาติดตั้งใช้จริงร่วมกัน

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

นอกจากนี้ เรายังจำเป็นต้องตรวจสอบให้แน่ใจว่าโค้ดล่าสุดนั้นเข้ากันได้กับการขึ้นต่อกันรุ่นเก่าของเรา ตัวอย่างเช่น หากจำเป็นต้องทำการเปลี่ยนแปลงทั่วทั้งไมโครเซอร์วิสในลำดับเฉพาะ โดยทั่วไปแล้ว ไมโครเซอร์วิสในสภาพแวดล้อมก่อนการทำงานจริงจะเรียกตำแหน่งข้อมูลของการทำงานจริงของบริการใดๆ ที่ทีมอื่นเป็นเจ้าของ เช่น Amazon Simple Storage Service (S3) หรือ Amazon DynamoDB แต่จะเรียกตำแหน่งข้อมูลของก่อนการทำงานจริงของไมโครเซอร์วิสอื่นของทีมบริการในระยะเดียวกัน ตัวอย่างเช่น ไมโครเซอร์วิส A ของทีมในสภาพแวดล้อมแกมม่าจะเรียกไมโครเซอร์วิส B ของทีมเดียวกันในสภาพแวดล้อมแกมม่า แต่จะเรียกตำแหน่งข้อมูลของการทำงานจริงสำหรับ Amazon S3

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

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

แต่ละทีมจำเป็นต้องรักษาสมดุลระหว่างความปลอดภัยของการติดตั้งใช้จริงที่มีขอบเขตน้อยกับความรวดเร็วที่เราสามารถส่งมอบการเปลี่ยนแปลงให้แก่ลูกค้าในทุกรีเจี้ยน การนำการเปลี่ยนแปลงไปติดตั้งใช้จริงใน 24 รีเจี้ยนหรือ 76 Availability Zone ผ่านไปป์ไลน์ทีละการเปลี่ยนแปลงมีความเสี่ยงต่ำสุดในการทำให้เกิดผลกระทบในวงกว้าง แต่อาจใช้เวลาหลายสัปดาห์กว่าที่ไปป์ไลน์ส่งการเปลี่ยนแปลงไปยังลูกค้าในทั่วโลก เราพบว่าการปบ่งกลุ่มการติดตั้งใช้จริงออกเป็น “เวฟ” ที่มีขนาดเพิ่มขึ้น ตามที่แสดงในตัวอย่างไปป์ไลน์การทำงานจริงก่อนหน้านี้ จะช่วยให้เราได้รับสมดุลที่ดีระหว่างความเสี่ยงในการติดตั้งใช้จริงกับความรวดเร็ว ระยะของแต่ละเวฟในไปป์ไลน์จะควบคุมการติดตั้งใช้จริงในกลุ่มรีเจี้ยน โดยมีการเปลี่ยนแปลงที่จะขยายจากเวฟหนึ่งไปยังอีกเวฟหนึ่ง การเปลี่ยนแปลงใหม่สามารถเข้าสู่ระยะการทำงานจริงของไปป์ไลน์เมื่อใดก็ได้ หลังจากที่ชุดการเปลี่ยนแปลงขยายจากขั้นตอนแรกไปยังขั้นตอนที่สองในเวฟ 1 ชุดการเปลี่ยนแปลงต่อไปจากแกมม่าจะขยายไปในขั้นตอนแรกของเวฟ 1 เราจึงไม่มีชุดรวมการเปลี่ยนแปลงขนาดใหญ่ที่รอให้นำไปติดตั้งใช้จริงในการทำงานจริง

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

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

การติดตั้งใช้จริงในแต่ละเวฟของการทำงานจริงเริ่มต้นด้วยระยะการติดตั้งใช้จริงในหน่วยเดียว เช่นเดียวกับในระยะการติดตั้งใช้จริงในหน่วยเดียวของแกมม่า แต่ละระยะการติดตั้งใช้จริงในหน่วยเดียวของการทำงานจริงนำโค้ดล่าสุดมาติดตั้งใช้จริงกับหน่วยเดียว (เครื่องเสมือนเครื่องเดียว คอนเทนเนอร์เดียว หรือการเรียกฟังก์ชัน Lambda ในสัดส่วนเล็กน้อย) ในแต่ละรีเจี้ยนหรือ Availability Zone ของเวฟ การติดตั้งใช้จริงในหน่วยเดียวในการทำงานจริงลดผลกระทบที่อาจเกิดขึ้นของการเปลี่ยนแปลงบนเวฟด้วยการจำกัดคำขอในครั้งแรกที่รองรับโดยโค้ดใหม่ในเวฟนั้น โดยทั่วไปแล้ว หน่วยเดียวรองรับอย่างมาก 10% ของคำขอโดยรวมสำหรับรีเจี้ยนหรือ Availability Zone หากการเปลี่ยนแปลงทำให้เกิดผลกระทบในทางลบในหน่วยเดียว ไปป์ไลน์ก็จะย้อนกลับการเปลี่ยนแปลงนั้น และไม่ขยายไปยังส่วนที่เหลือของระยะการทำงานจริง

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

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

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

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

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

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

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

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

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

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

ไปป์ไลน์โดยทั่วไปจะรออย่างน้อยหนึ่งชั่วโมงหลังระยะการติดตั้งใช้จริงในหน่วยเดียวแต่ละครั้ง อย่างน้อย 12 ชั่วโมงหลังเวฟของรีเจี้ยนแรก และอย่างน้อย 2-4 ชั่วโมงหลังแต่ละเวฟที่เหลืออยู่ของรีเจี้ยน โดยมีเวลาเฝ้าติดตามความเสียหายเพิ่มเติมสำหรับแต่ละรีเจี้ยน Availability Zones และเซลล์ภายในแต่ละเวฟ เวลาเฝ้าติดตามความเสียหายรวมถึงข้อกำหนดในการรอให้ถึงจำนวนจุดข้อมูลที่กำหนดในตัวชี้วัดของทีม (ตัวอย่างเช่น "รออย่างน้อย 100 คำขอที่เรียก Create API") เพื่อให้แน่ใจว่ามีคำขอเกิดขึ้นในจำนวนที่เพียงพอ เพื่อทำให้ดูเหมือนว่ามีการใช้โค้ดใหม่อย่างครบถ้วน ตลอดช่วงเวลาเฝ้าติดตามความเสียหาย การติดตั้งใช้จริงจะถูกย้อนกลับโดยอัตโนมัติ หากการแจ้งเตือนรวมที่มีความร้ายแรงสูงของทีมเข้าสู่สถานะการแจ้งเตือน

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

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

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

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

ทีมบริการของ AWS โดยทั่วไปเป็นเจ้าของหลายๆ ไปป์ไลน์ที่จำนำไมโครเซอร์วิสและซอร์สประเภทต่างๆ ของทีม (โค้ดของแอปพลิเคชัน โค้ดของโครงสร้างพื้นฐาน โปรแกรมแก้ไข OS ฯลฯ) ไปติดตั้งใช้จริง แต่ละไปป์ไลน์มีระยะการติดตั้งใช้จริงจำนวนมากสำหรับรีเจี้ยนและ Availability Zone ที่เพิ่มจำนวนขึ้นเรื่อยๆ ซึ่งหมายถึงการกำหนดค่าจำนวนมากที่ทีมจะต้องจัดการในระบบไปป์ไลน์ ในระบบการติดตั้งใช้จริง และในระบบการแจ้งเตือน และการทำงานจำนวนมากเพื่อดูแลให้สอดคล้องกับหลักปฏิบัติที่ดีที่สุดล่าสุดและรีเจี้ยนและ Availability Zone ใหม่ๆ ในช่วงสองสามปีที่ผ่านมา เราได้รับเอาข้อปฏิบัติ “ไปป์ไลน์โดยเป็นโค้ด” มาใช้ เพื่อให้สามารถกำหนดค่าไปป์ไลน์ที่ปลอดภัยและมีข้อมูลล่าสุดได้อย่างง่ายดายและสอดคล้องกันยิ่งขึ้น โดยสร้างต้นแบบการกำหนดค่าเป็นโค้ด เครื่องมือภายในสำหรับไปป์ไลน์โดยเป็นโค้ดของเราจะดึงรายชื่อรีเจี้ยนและ Availability Zone ในส่วนกลาง เพื่อเพิ่มรีเจี้ยนและ Availability Zone ใหม่ๆ ในไปป์ไลน์ทั่วทั้ง AWS เครื่องมือนี้ยังทำให้ทีมสามารถสร้างต้นแบบไปป์ไลน์โดยใช้การสืบทอด เพื่อกำหนดการกำหนดค่าที่ใช้ทั่วไปในไปป์ไลน์ของทีมในคลาสหลัก (เช่น รีเจี้ยนใดบ้างจะเข้าไปในแต่ละเวฟ และระยะเวลาที่เวลาเฝ้าติดตามความเสียหายควรจะเป็นสำหรับแต่ละเวฟ) และการกำหนดการกำหนดค่าไปป์ไลน์ของไมโครเซอร์วิสทั้งหมดเป็นคลาสย่อยที่สืบทอดการกำหนดค่าทั่วไปทั้งหมด

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

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

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

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