การตรวจสอบผลิตภัณฑ์ กลยุทธ์การเผยแพร่ และเวิร์กโฟลว์ AI แบบครบวงจร

กำไร:

• ทำความเข้าใจกลยุทธ์การลดความเสี่ยง (สีน้ำเงินเขียว คานารี ธงคุณลักษณะ) และระเบียบวินัยในการตรวจสอบผลิตภัณฑ์ (การตรวจสุขภาพ การทดสอบควัน การตรวจสอบสัญญาณทองคำ)
• ความสามารถในการปรับใช้นิสัยในการเตรียมแผนการย้อนกลับที่ชัดเจนก่อนการใช้งาน และตรวจสอบเส้นทางธุรกิจที่สำคัญหลังจากการปรับใช้
• ความสามารถในการรวมทุกส่วนที่เรียนรู้ตลอดโมดูลในเวิร์กโฟลว์ที่สนับสนุน AI แบบ end-to-end และใช้หลักการ 'AI ผลิต มนุษย์ตรวจสอบและรับรอง' ในทุกขั้นตอน

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

ในหน่วยสุดท้ายนี้ เรารวมสองสิ่งเข้าด้วยกัน: (1) วิธีการเผยแพร่ที่ช่วยลดความเสี่ยง (คานารี ฟ้าเขียว แฟล็กคุณลักษณะ) และระเบียบวินัยในการตรวจสอบผลิตภัณฑ์ (2) วิธีที่ทุกชิ้นที่เราเรียนรู้ในโมดูล ได้แก่ CI/CD, IaC, คอนเทนเนอร์, การตรวจสอบ, เหตุการณ์, ต้นทุน, สคริปต์, ความปลอดภัย มารวมกันเป็นเวิร์กโฟลว์ตั้งแต่ต้นทางถึงปลายทางที่ขับเคลื่อนด้วย AI เพียงหนึ่งเดียว ทำซ้ำคำพูดเริ่มต้นเป็นครั้งสุดท้าย: AI สร้างและเร่งแบบร่างในทุกขั้นตอน แต่คุณคือคนที่กดปุ่ม "ฉันกำลังถ่ายทอดสด" และรับรองผลลัพธ์

เผยแพร่กลยุทธ์ที่ช่วยลดความเสี่ยง

การผลักดันการเปลี่ยนแปลงไปยังผู้ใช้ทั้งหมดพร้อมกันถือเป็นวิธีที่เสี่ยงที่สุด วิธีการสำหรับผู้ใหญ่:

• การปรับใช้สีน้ำเงิน-เขียว: ยังคงรักษาสภาพแวดล้อมที่เหมือนกันสองแบบไว้ — “สีน้ำเงิน” (ใช้งานจริง) และ “สีเขียว” (เวอร์ชันใหม่) เวอร์ชันใหม่ได้รับการจัดเตรียมและทดสอบเป็นสีเขียว จากนั้นการจราจรก็เปลี่ยนเป็นสีเขียวทันที หากเกิดปัญหา การจราจรจะเปลี่ยนเป็นสีน้ำเงินทันที การย้อนกลับอย่างรวดเร็วเป็นข้อได้เปรียบที่ใหญ่ที่สุด
• Canary Deployment: เวอร์ชันใหม่เปิดตัวครั้งแรกสำหรับผู้ใช้ส่วนน้อย (เช่น 5%); หากตัวชี้วัดดี ให้ค่อยๆ เพิ่มเป็น 100% ปัญหาส่งผลกระทบต่อผู้ใช้ส่วนเล็กๆ ไม่ใช่ผู้ใช้ทั้งหมด
• คุณลักษณะธง: คุณลักษณะใหม่ป้อนรหัสแต่ถูกบล็อกโดยธง; เปิดให้ผู้ใช้บางรายเมื่อมีการร้องขอ มีความแตกต่างระหว่างการปรับใช้และ "การเผยแพร่"; หากมีปัญหา แฟล็กจะถูกปิดโดยไม่ย้อนกลับโค้ด

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

การตรวจสอบผลิตภัณฑ์: งานไม่สิ้นสุดเมื่อการปรับใช้งานสิ้นสุดลง

การปรับใช้ดูเหมือนเป็น "สีเขียว" ไม่ได้หมายความว่าใช้งานได้ การตรวจสอบอย่างเป็นระบบ:

1. การตรวจสุขภาพ: บริการใช้งานได้แล้ว /healthz ตอบสนองหรือไม่
2. การทดสอบควัน: เส้นทางผู้ใช้ที่สำคัญที่สุดสองสามเส้นทาง (การเข้าสู่ระบบ การชำระเงิน การค้นหา) ใช้งานได้จริงหรือไม่ อัตโนมัติและรวดเร็ว
3. เฝ้าระวังสัญญาณทอง: อัตราข้อผิดพลาดหลังการติดตั้ง เวลาแฝง การรับส่งข้อมูลเป็นเรื่องปกติหรือไม่ (สี่สัญญาณในหน่วย 6)
4. ค่อยๆ ขยาย: ดูเมตริกในแต่ละขั้นตอนเมื่อคุณเพิ่มเปอร์เซ็นต์ Canary
5. กรอบเวลาสังเกตการณ์: ตรวจสอบอย่างใกล้ชิดเป็นระยะเวลา (เช่น 30 นาที) หลังจากการปรับใช้ ปัญหาร้ายกาจไม่สามารถมองเห็นได้ในทันที

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

การเปรียบเทียบกลยุทธ์การเผยแพร่

กลยุทธ์

ข้อได้เปรียบหลัก

ต้นทุน/ความซับซ้อน

เหมาะสมที่สุด

สีฟ้า-สีเขียว

ย้อนกลับทันที

สองสภาพแวดล้อม = 2x ทรัพยากร

หากการดึงข้อมูลอย่างรวดเร็วเป็นสิ่งสำคัญ

นกขมิ้น

จำกัดผลกระทบต่อชิ้นเล็กๆ

จำเป็นต้องมีการจัดการจราจร

ฐานผู้ใช้ขนาดใหญ่

คุณลักษณะธง

แยกการใช้งานออกจากการเปิดตัว

ธงบริหารหนี้

การเปิดแบบค่อยเป็นค่อยไป/ตามเป้าหมาย

การอัปเดตแบบกลิ้ง

เรียบง่าย เป็นมิตรกับทรัพยากร

ย้อนกลับช้า

บริการที่เรียบง่าย

เวิร์กโฟลว์ที่ขับเคลื่อนด้วย AI แบบครบวงจร

ตอนนี้เรามารวมโมดูลทั้งหมดไว้ในโฟลว์เดียว สมมติว่าคุณกำลังเผยแพร่ไมโครเซอร์วิสใหม่ AI สร้างแบบร่างในแต่ละขั้นตอน คุณยืนยันในแต่ละขั้นตอน:

1. รหัสและคอนเทนเนอร์ (หน่วยที่ 4): AI สร้าง Dockerfile ที่ปลอดภัยและเหมาะสมที่สุด คุณตรวจสอบความลับและขนาด
2. CI/CD (หน่วยที่ 2): เขียนไปป์ไลน์ AI test-build-deploy; คุณจำกัดสิทธิ์ให้แคบลงและตรวจสอบข้อมูลอ้างอิงที่เป็นความลับ
3. โครงสร้างพื้นฐาน (หน่วยที่ 3): กำหนดทรัพยากรที่จำเป็นด้วย AI Terraform คุณอ่านผลลัพธ์ของแผน และไม่ค้นหาการลบที่ไม่คาดคิด
4. การเรียบเรียง (หน่วยที่ 5): AI สร้างรายการ Kubernetes; คุณตรวจสอบขีดจำกัดทรัพยากร โพรบ และ RBAC
5. ความปลอดภัย (หน่วยที่ 10): จัดลำดับความสำคัญของเอาต์พุตการสแกน AI คุณคว้าสิ่งที่เอารัดเอาเปรียบก่อน
6. การตรวจสอบ (หน่วยที่ 6): AI สร้างกฎการเตือนและแดชบอร์ด คุณทดสอบเกณฑ์ด้วยข้อมูลที่ผ่านมาของคุณ
7. การเปิดตัวและการตรวจสอบ (หน่วยนี้): สรุปการทดสอบควันของ AI และแผนการย้อนกลับ คุณเริ่มนกขมิ้น ดูตัวชี้วัด กดปุ่ม
8. หากเหตุการณ์เกิดขึ้น (หน่วยที่ 7): AI จะสร้างสมมติฐานและภาพร่างหลังการชันสูตรพลิกศพ คุณตรวจสอบและเรียนรู้บทเรียน
9. ต้นทุน (หน่วยที่ 8): AI ติดตามการสิ้นเปลืองทรัพยากรใหม่ คุณตัดสินใจเรื่องขนาดได้ถูกต้อง

ในทุกขั้นตอน กฎทั่วไปยังคงไม่เปลี่ยนแปลง: AI สร้างและเร่งความเร็ว ตรวจสอบและรับรองโดยมนุษย์ นี่คือสาระสำคัญของโมดูล

มินิเคสสามอัน

กรณีที่ 1 — นกคีรีบูนจำกัดภัยพิบัติไว้ที่ 5% ทีมงานมอบเวอร์ชันใหม่ให้กับผู้ใช้ 5% ที่มีนกขมิ้น แดชบอร์ดที่ AI สร้างขึ้นแสดงให้เห็นทันทีว่าอัตราข้อผิดพลาดเพิ่มขึ้นเป็น 8% ในส่วนนี้ ทีมงานเอาคืนโดยไม่เพิ่มเป็น 100%; ปัญหานี้ส่งผลกระทบต่อผู้ใช้เพียง 5% เท่านั้น และนั่นเป็นเพียงไม่กี่นาทีเท่านั้น หากมีการใช้งานครั้งใหญ่ ลูกค้าทั้งหมดจะได้รับผลกระทบ

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

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

เทมเพลตที่สามารถคัดลอกได้สี่แบบ

1) การเลือกกลยุทธ์การเปิดตัว:

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

2) รายการทดสอบควัน / ตรวจสอบ:

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

3) แผนการย้อนกลับ:

ฉันใช้ [วิธีการปรับใช้] เขียนแผนการย้อนกลับที่ชัดเจนให้ฉัน: ฉันจะย้อนกลับเป็นเวอร์ชันเก่าด้วยคำสั่ง/ขั้นตอนใด ใช้เวลานานเท่าใด ความเสี่ยงของการย้อนกลับคืออะไร (เช่น การย้ายฐานข้อมูลไม่สามารถย้อนกลับได้) ฉันควรตรวจสอบสิ่งใดก่อนย้อนกลับ

4) รายการตรวจสอบการเผยแพร่ตั้งแต่ต้นทางถึงปลายทาง:

สร้างรายการตรวจสอบการเตรียมการแบบครบวงจรสำหรับการเปิดตัวโครงการ [บริการ] ใหม่: ความปลอดภัยของโค้ด/รูปภาพ ไปป์ไลน์ แผนโครงสร้างพื้นฐาน การตรวจสอบและการเตือน การสแกนความปลอดภัย กลยุทธ์การเปิดตัว การย้อนกลับ และการตรวจสอบ ตรวจสอบแต่ละรายการด้วยคำถาม "ฉันพร้อมหรือยัง" เปลี่ยนมันเป็นคำถาม.

พรอมต์อ่อน / พรอมต์แข็งแกร่ง

อ่อนแอ: "ฉันจะทำให้สิ่งนี้กลายเป็นผลิตภัณฑ์ได้อย่างไร"

ผลลัพธ์: ไม่มีบริบท; AI แสดงรายการขั้นตอนการปรับใช้ทั่วไป แต่ไม่ได้จัดการกับความเสี่ยง ขนาดผู้ใช้ และความต้องการในการย้อนกลับของคุณ

Güçlü: "ฉันจะให้บริการชำระเงินกับผู้ใช้ 10 ล้านคน ความอดทนต่อการหยุดทำงานของฉันต่ำมาก คุณแนะนำ Canary หรือ Blue-Green เพราะเหตุใด ฉันควรทดสอบเส้นทางที่สำคัญใดหลังจากการปรับใช้ ตัววัดใดที่ฉันควรตรวจสอบเป็นเวลากี่นาที และแผนการย้อนกลับ 60 วินาทีควรเป็นอย่างไร ฉันจะตัดสินใจขั้นสุดท้าย"

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

ข้อผิดพลาดทั่วไป

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

โดยสรุป

การไปที่ผลิตภัณฑ์เป็นลิงก์ที่สำคัญที่สุดในห่วงโซ่ และไม่ได้ทำได้โดยการ "หวัง" แต่ด้วยกลยุทธ์ที่ได้รับการควบคุม: สีน้ำเงิน-เขียวจะให้การย้อนกลับทันที โดยจำกัดเอฟเฟกต์คานารีให้เหลือเพียงชิ้นเล็ก ๆ โดยแยกการปรับใช้แฟล็กฟีเจอร์ออกจากรีลีส งานยังไม่สิ้นสุดเมื่อการปรับใช้งานเสร็จสิ้น การตรวจสอบอย่างเป็นระบบผ่านการตรวจสุขภาพ การทดสอบควัน และการตรวจสอบสัญญาณทองถือเป็นสิ่งสำคัญ AI สร้างและเร่งความเร็วแบบร่างในทุกขั้นตอนตลอดทั้งโมดูล ตั้งแต่ Dockerfile ไปจนถึงไปป์ไลน์ จาก Terraform ไปจนถึงกฎการแจ้งเตือน จากการชันสูตรพลิกศพไปจนถึงการวิเคราะห์ต้นทุน แต่บุคคลที่มีความสามารถยังคงเป็นผู้ที่ตรวจสอบแต่ละขั้นตอน กดปุ่มถ่ายทอดสด และรับรองผลลัพธ์ นี่คือกฎทองของ DevOps ที่ขับเคลื่อนด้วย AI แบบครบวงจร

งานสมัคร

เลือกบริการ (จริงหรือตัวละคร) ที่จะเผยแพร่ (1) เลือกกลยุทธ์ที่เหมาะกับบริบทของคุณด้วยเทมเพลต “การเลือกกลยุทธ์การเผยแพร่” และเขียนเหตุผล (2) สร้างรายการการยืนยันที่สร้างด้วยเทมเพลต "การทดสอบควัน / รายการการยืนยัน" และเพิ่มเส้นทางธุรกิจที่สำคัญที่สุดด้วยตัวคุณเอง (3) เตรียมแผนการย้อนกลับ 60 วินาทีด้วยเทมเพลต "แผนการย้อนกลับ" และตรวจสอบว่ามีขั้นตอนที่ไม่สามารถย้อนกลับได้หรือไม่

รายการตรวจสอบ

• [ ] ฉันเลือกกลยุทธ์การเผยแพร่ (canary/blue-green/flag) ที่เหมาะกับบริบทของฉัน
• [ ] ฉันมีแผนย้อนกลับที่ชัดเจนและรวดเร็วพร้อมก่อนใช้งาน
• [ ] ฉันได้เพิ่มเส้นทางธุรกิจที่สำคัญที่สุด (เช่น การชำระเงิน) ให้กับการทดสอบ Smoke ของฉันเอง
• [ ] หลังการติดตั้ง ฉันจะตรวจสอบสัญญาณสีทองผ่านหน้าต่างสังเกตการณ์
• [ ] ฉันยังได้วางแผนขั้นตอนที่ไม่สามารถย้อนกลับได้ (การย้ายฐานข้อมูล ฯลฯ)
• [ ] ฉันตรวจสอบพิมพ์เขียว AI ในทุกขั้นตอน ฉันตัดสินใจที่จะถ่ายทอดสด

การสอบโมดูล

1. ข้อใดต่อไปนี้คือตำแหน่งที่ดีที่สุดสำหรับ DevOps และ AI ในระบบคลาวด์

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

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

2. ข้อใดคือการแสดงออกที่ถูกต้องที่สุดสำหรับระเบียบวินัยในการตรวจสอบก่อนที่จะใช้คำสั่ง DevOps หรือการกำหนดค่าที่ผลิตโดยปัญญาประดิษฐ์

• A) หากเอาต์พุตดูราบรื่นและมั่นใจว่าสามารถรันได้โดยตรงในผลิตภัณฑ์
• B) เอาต์พุตจะปลอดภัยก็ต่อเมื่อไม่มีข้อผิดพลาดทางไวยากรณ์เท่านั้น ไม่จำเป็นต้องตรวจสอบเพิ่มเติม
• C) เชื่อมต่อเอาต์พุตกับต้นทาง วางแผน/ทดลองรัน และกรองด้วยบริบทระบบของคุณ แล้วทา✔
• D) การลองครั้งแรกโดยตรงในผลิตภัณฑ์และการดูผลลัพธ์คือการตรวจสอบที่รวดเร็วที่สุด

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

3. อะไรคือแนวทางที่ถูกต้องเมื่อถามปัญญาประดิษฐ์เกี่ยวกับข้อผิดพลาดหรือปัญหาการปรับใช้กับไฟล์ .env ที่มีรหัสผ่านฐานข้อมูลจริง

• A) ปิดบังความลับที่แท้จริงด้วย <PLACEHOLDER>; แบ่งปันเฉพาะข้อผิดพลาดและบริบทที่ถูกปกปิด✔
• B) การวางไฟล์ .env ทั้งหมดจะช่วยแก้ปัญหาได้เร็วขึ้น
• C) เนื่องจากความลับมีฐาน 64 อยู่แล้ว จึงปลอดภัยที่จะวางแบบธรรมดา
• D) การวางรหัสผ่านนั้นปลอดภัยเพราะปัญญาประดิษฐ์ไม่เคยเก็บไว้

คำอธิบาย: ไม่มีการวางความลับที่แท้จริงลงในพรอมต์ AI ค่าต่างๆ เช่น รหัสผ่านและโทเค็นถูกปกปิดด้วย <PLACEHOLDER>; จะมีการแชร์เฉพาะข้อความแสดงข้อผิดพลาดและบริบทที่จำเป็นเท่านั้น หากความลับรั่วไหลไปแล้ว ควรยกเลิกและหมุนเวียนทันที

4. ข้อใดต่อไปนี้คือการจัดการความลับ (รหัสผ่าน โทเค็น) ในไปป์ไลน์ CI/CD ที่ถูกต้อง

• A) มันถูกเก็บไว้ในที่เก็บข้อมูลลับของแพลตฟอร์มและเรียกโดยการอ้างอิง (เช่น ${{ Secrets.X }}) ไม่ได้เขียนด้วยข้อความธรรมดา ✔
• B) เขียนด้วยข้อความธรรมดาถึงไปป์ไลน์ YAML เพื่อความสะดวก
• C) ได้รับการตรวจสอบโดยการกด echo และ log ที่จุดเริ่มต้นของแต่ละงาน
• D) หากกำหนดด้วยสิทธิ์ที่กว้างที่สุด (เขียนทั้งหมด) ความปลอดภัยจะเพิ่มขึ้น

คำอธิบาย: ข้อมูลลับไม่ได้เขียนถึง YAML ในรูปแบบข้อความธรรมดา มันถูกเก็บไว้ในที่เก็บข้อมูลลับของแพลตฟอร์มและเรียกใช้โดยมีการอ้างอิงเช่น ${{ Secrets.X }} นอกจากนี้ ด้วยหลักการที่มีสิทธิ์น้อยที่สุด การอนุญาตโทเค็นจะถูกจำกัดให้แคบลง และบันทึกข้อมูลลับจะไม่ถูกบันทึก

5. ในการจัดการโครงสร้างพื้นฐานด้วย Terraform ขั้นตอนที่สำคัญที่สุดในการดำเนินการก่อนดำเนินการเปลี่ยนแปลงจริงคืออะไร

• A) การเรียกใช้ 'terraform Apply' โดยตรง แผนนี้เสียเวลา
• B) การสำรองไฟล์ State ไปยังพื้นที่เก็บข้อมูลสาธารณะ
• C) เรียกใช้ 'แผนภูมิประเทศ' และตรวจสอบบรรทัดทำลาย/แทนที่ในเอาต์พุต จากนั้นใช้ ✔
• D) ถอนการติดตั้งเวอร์ชันของผู้ให้บริการและตรวจสอบให้แน่ใจว่าเวอร์ชันใหม่ล่าสุดมาโดยอัตโนมัติ

คำอธิบาย: ต้องเรียกใช้ 'แผนภูมิประเทศ' ก่อน 'ใช้แผนภูมิประเทศ' แผนจะแสดงสิ่งที่ควรเพิ่ม สิ่งที่ต้องเปลี่ยนแปลง และโดยเฉพาะสิ่งที่ควรลบ (ทำลาย) โดยไม่ต้องทำอะไรเลย หากเห็นเส้นทำลายหรือแทนที่โดยไม่คาดคิด ไม่ควรใช้

6. หมายความว่าอย่างไรและควรทำอย่างไรหากบรรทัด '-/+ แทนที่' สำหรับฐานข้อมูลการผลิตปรากฏในเอาต์พุตแผน Terraform

• A) แหล่งที่มาจะได้รับการอัปเดตในสถานที่เท่านั้น ไม่มีความเสี่ยง
• B) ทรัพยากรจะถูกลบและสร้างใหม่ มีความเสี่ยงที่ข้อมูลจะสูญหาย ควรหยุดใช้หากไม่คาดหวัง ✔
• C) การเพิ่มทรัพยากรใหม่ ฐานข้อมูลที่มีอยู่จะไม่ได้รับผลกระทบ
• D) นี่เป็นเพียงคำเตือน สามารถเพิกเฉยได้อย่างปลอดภัย

คำอธิบาย: '-/+ แทนที่' หมายความว่าทรัพยากรจะถูกลบและสร้างใหม่ สำหรับฐานข้อมูล นี่หมายถึงข้อมูลสูญหาย หากไม่เป็นไปตามคาด ควรหยุดใช้ การเปลี่ยนแปลงควรแปลงเป็นวิธีที่ปลอดภัย หรือฟิลด์ที่ไม่เปลี่ยนรูปไม่ควรถูกแตะต้อง

7. ข้อใดต่อไปนี้เป็นจริงสำหรับ Dockerfile ที่จะพร้อมสำหรับการผลิตในแง่ของความปลอดภัยและขนาด

• A) เพื่อความสะดวก ให้ฝังความลับไว้ในอิมเมจด้วย ENV และรันมันในฐานะรูท
• B) ใช้แท็ก ':latest' เสมอ และรักษารูปภาพพื้นฐานให้ใหญ่ที่สุดเท่าที่จะเป็นไปได้
• C) การสร้างแบบขั้นตอนเดียวและปล่อยให้เครื่องมือสร้างทั้งหมดอยู่ในอิมเมจสุดท้าย
• D) ไม่ฝังความลับ ทำงานร่วมกับ USER ที่ไม่ได้รับอนุญาต โดยใช้อิมเมจฐานขนาดเล็กและเสถียรและการสร้างแบบหลายขั้นตอน ✔

คำอธิบาย: อิมเมจที่พร้อมสำหรับการผลิต: ไม่ได้ฝังข้อมูลลับ (แทรกลงในรันไทม์), รันด้วย USER ที่ไม่ได้รับอนุญาตแทนรูท, ใช้อิมเมจพื้นฐานขนาดเล็กและเป็นเวอร์ชัน (สลิม/อัลไพน์ ไม่ใช่ :ล่าสุด) และถูกลดขนาดลงด้วยการสร้างแบบหลายขั้นตอน นอกจากนี้ยังสแกนหาช่องโหว่ก่อนเผยแพร่อีกด้วย

8. อะไรคือความเสี่ยงที่สำคัญที่สุดในการไม่กำหนดขีดจำกัดทรัพยากรสำหรับการปรับใช้ใน Kubernetes?

• A) พ็อดไม่เริ่มทำงานเนื่องจากช่องที่ต้องระบุขีดจำกัด
• B) มีเพียงคำเตือนเท่านั้นที่ปรากฏบนบอร์ดตรวจสอบ การทำงานจะไม่ได้รับผลกระทบ
• C) Kubernetes บังคับใช้ขีดจำกัดเริ่มต้นที่ปลอดภัยโดยอัตโนมัติ ไม่มีความเสี่ยง
• D) พ็อดสามารถเติบโตได้ไม่จำกัดและใช้ทรัพยากรของโหนด ส่งผลให้บริการใกล้เคียงล่ม ✔

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

9. จะหลีกเลี่ยง 'การแจ้งเตือนเมื่อยล้า' ในการตั้งค่าการติดตามและการแจ้งเตือนได้อย่างไร

• A) ตั้งการแจ้งเตือนบนตัวชี้วัดให้ได้มากที่สุด และสร้างการแจ้งเตือนในทุกความผันผวน
• B) ตั้งค่าการเตือนทั้งหมดเป็นระดับความรุนแรงสูงสุด
• C) การเรียกสัญญาณเตือนด้วยค่าทันทีโดยไม่ต้องตั้งเวลา (สำหรับ)
• D) ให้ความสำคัญกับการดำเนินการของสัญญาณเตือนและอยู่ในความเร่งด่วนที่เหมาะสม ทดสอบเกณฑ์ด้วยข้อมูลในอดีต รวมรายการที่ไม่จำเป็นเข้าด้วยกัน ✔

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

10. ลำดับความสำคัญสูงสุดระหว่างเหตุการณ์การผลิตคืออะไร?

• A) ขั้นแรกให้ค้นหาสาเหตุที่แท้จริงและลดสาเหตุเฉพาะเมื่อสาเหตุชัดเจนเท่านั้น
• B) เขียนรายงานการชันสูตรพลิกศพก่อน จากนั้นจึงแตะบริการ
• C) ลดก่อน (กู้คืน/กู้คืนบริการ) ทิ้งการวิเคราะห์สาเหตุไว้ใช้ในภายหลัง ✔
• D) ก่อนอื่นให้ค้นหาบุคคลที่รับผิดชอบต่อเหตุการณ์และรายงานเหตุการณ์นั้น

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

11. จุดประสงค์หลักของวัฒนธรรมการชันสูตรพลิกศพที่ไร้ตำหนิคืออะไร?

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

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

12. ในการเพิ่มประสิทธิภาพต้นทุนคลาวด์ (FinOps) อะไรคือขั้นตอนที่สมเหตุสมผลที่สุดก่อนที่จะเปลี่ยนไปใช้ส่วนลดที่ผูกพัน (แผนสำรอง/ออมทรัพย์)

• A) ให้คำมั่นสัญญาที่ยาวที่สุดเท่าที่จะเป็นไปได้ก่อน แล้วคิดถึงการสิ้นเปลืองในภายหลัง
• B) ขั้นแรก ทำความสะอาดของเสีย (การปิดที่ไม่ได้ใช้งาน ปรับขนาดให้ถูกต้อง) จากนั้นให้คำมั่นสัญญาว่าจะใช้งาน ✔
• C) ย้ายทรัพยากรทั้งหมดไปยังความจุ Spot ทันที
• D) การลบรายการที่แพงที่สุดโดยไม่ตรวจสอบข้อมูลใบแจ้งหนี้

คำอธิบาย: ของเสียต้องได้รับการทำความสะอาดก่อน (การปิดทรัพยากรที่ไม่ได้ใช้งาน ลดทรัพยากรที่มีขนาดใหญ่เกินไป) ไม่เช่นนั้นจะล็อคการใช้งานที่สูญเปล่าในราคาลดพิเศษนาน 1-3 ปี การทำความสะอาดตามขนาดที่เหมาะสมและไม่ได้ใช้งานไม่จำเป็นต้องมีข้อผูกมัดและแทบไม่มีความเสี่ยงเลย

13. อะไรคือมาตรการรักษาความปลอดภัยที่สำคัญที่สุด หากสคริปต์ที่ AI แนะนำมีบรรทัด 'rm -rf "$DIR"/'

• A) การรันสคริปต์โดยตรงใน prod โดยไม่ต้องอ่านจะทำให้เร็วขึ้น
• B) เพิ่ม set -euo pipefail และการควบคุมตัวแปรว่าง แล้วลองใช้ dry-run ก่อน ✔
• C) การย่อชื่อตัวแปรให้สั้นลงก็เพียงพอแล้ว
• D) การใช้ rm -rf --force แทน rm ช่วยแก้ปัญหาได้

คำอธิบาย: หาก $DIR ว่างเปล่า คำสั่งนี้อาจพยายามลบไดเร็กทอรี root การหยุดที่ตัวแปรที่ไม่ได้กำหนดด้วย 'set -u' และตรวจสอบว่าตัวแปรไม่ว่างเปล่าก่อนที่จะลบ (เช่น [ -n "$DIR" ] || ทางออก 1) หลีกเลี่ยงความเสียหาย นอกจากนี้ ควรพยายามดำเนินการทำลายล้างด้วยการทดลองรันก่อน

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

• A) ยกเลิกและต่ออายุ (หมุน) คีย์ทันที ลบอย่างเดียวไม่พอ✔
• B) เพียงลบไฟล์ออกจากที่จัดเก็บข้อมูลและกุญแจก็ปลอดภัย
• ค) ไม่ทำอะไรเพราะไม่มีใครเห็น
• D) การทำให้ที่เก็บข้อมูลเป็นแบบส่วนตัวไม่จำเป็นต้องหมุนคีย์

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

15. วิธีใดต่อไปนี้ช่วยลดความเสี่ยงเมื่อเผยแพร่ Prod เวอร์ชันใหม่

• A) มอบเวอร์ชันใหม่ให้กับผู้ใช้ทุกคนพร้อมกัน (บิ๊กแบง) และไม่ได้เตรียมแผนการย้อนกลับ
• B) พิจารณาว่าการปรับใช้งานเสร็จสิ้นทันทีที่ปรากฏ 'สีเขียว' โดยไม่ได้ดำเนินการตรวจสอบเพิ่มเติม
• C) การใช้กลยุทธ์ที่มีการควบคุม เช่น ธงคานารี/น้ำเงิน-เขียว/คุณลักษณะ แผนการย้อนกลับสำเร็จรูป และการทดสอบควัน + การตรวจสอบหน่วยวัดหลังการใช้งาน ✔
• D) ทิ้งการทดสอบเส้นทางธุรกิจที่สำคัญไปสู่ปัญญาประดิษฐ์โดยสิ้นเชิงและไม่ได้กำหนดเส้นทางเหล่านั้นเลย

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