Part of 10306343 การจัดการโครงสร้างพื้นฐานและการส่งมอบซอฟต์แวร์อย่างต่อเนื่อง (Development Operations: DevOps)

บทที่ 13 นำเสนอผลงาน: Capstone, Platform Engineering และ AI ในงาน DevOps

แผนบริหารการสอนประจำบทที่ 13

หัวข้อเนื้อหา

• 13.1 Platform Engineering, Internal Developer Platform และ Golden Path (ภาพรวม)
• 13.2 AI ในงาน DevOps
• 13.3 ตรวจคำตอบของ AI ด้วยหลักฐาน
• 13.4 สะท้อนการเรียนรู้ตลอดรายวิชา
• 13.5 หลักฐานการนำเสนอที่แยกความสามารถออกจากโชค
• 13.6 platform ที่ลดงานซ้ำกับ platform ที่สร้างคิวใหม่
• 13.7 ตรวจข้อเสนอของ AI ทีละข้ออ้าง
• 13.8 สะท้อนการเรียนรู้โดยเชื่อมข้ออ้างกับชิ้นงาน
• ปฏิบัติการที่ 13 นำเสนอ Capstone และงานต่อยอด (Lab A–C)

วัตถุประสงค์เชิงพฤติกรรม

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

CLO ที่เกี่ยวข้อง (ข้อความจากหลักสูตร):

• CLO1 สามารถนำความต้องการและสถาปัตยกรรมการส่งมอบซอฟต์แวร์ที่กำหนดมาใช้ โดยอธิบาย Git workflow, CI/CD pipeline flow และการใช้ Containerization ได้อย่างเหมาะสมกับบริบทของงาน
• CLO2 สามารถกำหนดค่าและใช้งาน DevOps workflow ที่กำหนดมา เพื่อให้กระบวนการพัฒนา–ทดสอบ–ส่งมอบซอฟต์แวร์เป็นไปอย่างถูกต้องและมีประสิทธิภาพ
• CLO4 ผู้เรียนแสดงออกถึงความรับผิดชอบและความใฝ่รู้ในการเรียนรู้เทคโนโลยีและเครื่องมือใหม่ที่เกี่ยวข้องกับ DevOps โดยศึกษาค้นคว้าด้วยตนเองจากแหล่งข้อมูลที่เชื่อถือได้ และปฏิบัติตามแนวปฏิบัติด้านความปลอดภัยและคุณภาพของระบบ
• CLO5 แสวงหาความรู้เพิ่มเติมและสร้างสรรค์ผลงานจากการเรียนรู้ด้วยตัวเอง

บทนี้เป็นบทสุดท้ายที่นับคะแนน หัวข้อ 13.1 เป็นภาพรวมที่ไม่ประเมิน หัวข้อ 13.2–13.3 เป็นพื้นของแบบฟอร์มการใช้ AI (งานข้อ 4) งานข้อ 2 เป็นจุดตรวจที่ 3 ของงานต่อยอดด้วยตนเอง ต่อจากบทที่ 6 และ 10

วิธีสอนและกิจกรรมการเรียนการสอน

1. บรรยายภาพรวม Platform Engineering โดยชี้ว่า workflow, Dockerfile และ scripts/deploy.sh ที่ผู้สอนให้มาตลอดรายวิชาคือเส้นทางสำเร็จรูปขนาดเล็ก
2. บรรยายการใช้ AI ช่วยงาน DevOps แล้วสาธิตให้ AI วิเคราะห์ log จากระบบของรายวิชา ทั้งห้องช่วยกันตรวจคำตอบด้วยคำสั่งจากบทที่ 1 ตามหัวข้อ 13.3
3. ชี้แจงลำดับนำเสนอ จากนั้นแต่ละทีมนำเสนอ Capstone ตามโจทย์ที่ได้รับ (Lab A) และผู้เรียนแต่ละคนสาธิตงานต่อยอด (Lab B)
4. มอบหมายให้ส่ง portfolio และแบบฟอร์มการใช้ AI (Lab C) ภายในเวลาศึกษาด้วยตนเองของสัปดาห์นี้

สื่อการเรียนการสอน

• เอกสารประกอบการสอนบทที่ 13 (บทความนี้) และหน้ารวมรายวิชา 10306343
• repository ทีม เครื่องปลายทาง workflow Rollback และ RUNBOOK.md จากบทที่ 12
• CNCF Platforms White Paper, บทความ Golden Paths ของ Spotify Engineering, รายงาน DORA 2025 State of AI-assisted Software Development และเอกสาร Responsible use of GitHub Copilot code completion
• บทความการลงทะเบียนใช้งาน GitHub Copilot (Education) และ Google Gemini สำหรับนักศึกษา
• แบบฟอร์มการใช้ AI และแบบฟอร์ม reflection (หัวข้อ Lab C)

การวัดผลและการประเมินผล

กำหนดส่ง: งานข้อ 1–2 นำเสนอในคาบ งานข้อ 3–4 ส่งภายในสัปดาห์ที่ 13 (เวลาศึกษาด้วยตนเองของบทนี้) เพราะบทที่ 1–13 เป็นบทที่นับคะแนน

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

ข้อ 1 ใช้เกณฑ์โครงงานต่อไปนี้ (คะแนนดิบ 12 คะแนน นำไปคำนวณในหมวดโครงงาน 10% ไม่รวมซ้ำในใบงาน)

ข้อ 2 ใช้ rubric CLO5 3 ระดับ เกณฑ์ผ่านคือระดับ 2 ขึ้นไป

ข้อ 3 ใช้ rubric CLO4 3 ระดับ เกณฑ์ผ่านคือมี Learning Log อย่างน้อย 10 จาก 13 บท

ข้อ 4 ใช้รายการตรวจ (checklist) ผ่านเมื่อครบทุกข้อในแบบฟอร์มของ Lab C

เฉลยจะเปิดในชั้นเรียนหลังทุกคนทำเสร็จ

บทนำ

บทนี้ปิดรายวิชาด้วยสามเรื่อง เรื่องแรกคือภาพรวมของ Platform Engineering ซึ่งเป็นทิศทางที่องค์กรใช้ขยายแนวปฏิบัติ DevOps ไปยังหลายทีม โดยชี้ให้เห็นว่าสิ่งที่ผู้สอนเตรียมให้ทีมตลอดรายวิชาคือ platform ขนาดเล็ก เรื่องที่สองคือการใช้ AI ช่วยงาน DevOps อย่างรับผิดชอบ ซึ่งหัวใจคือการตรวจคำตอบของ AI ด้วยหลักฐาน และเรื่องที่สามคือการนำเสนอ Capstone งานต่อยอด และการสะท้อนการเรียนรู้ตลอด 13 บท

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

ความเชื่อมโยงกับบทอื่น: บทนี้ใช้ pipeline, workflow Rollback และ RUNBOOK จากบทที่ 12 log ของ Nginx และการคำนวณ SLI จากบทที่ 11 คำสั่ง grep, sort และ uniq -c จากบทที่ 1 และงานต่อยอดที่เริ่มในบทที่ 6 ผลผลิตของบทนี้ถูกใช้ต่อตามตารางต่อไปนี้

ความรู้พื้นฐาน เครื่องมือ และรุ่นซอฟต์แวร์

ความรู้พื้นฐาน: ทุกบทก่อนหน้า โดยเฉพาะบทที่ 12

เครื่องมือ: repository ทีมและเครื่องปลายทางที่พร้อมใช้ เครื่องมือ AI ที่ผู้เรียนลงทะเบียนไว้ (ถ้าเลือกใช้) ตามบทความเรื่อง GitHub Copilot และ Google Gemini สำหรับนักศึกษา และ terminal สำหรับรันคำสั่งตรวจในหัวข้อ 13.3

รุ่นซอฟต์แวร์ที่ใช้ทดสอบ:

ค่าใช้จ่ายและข้อมูลลับ: เครื่องมือ AI บางรายการมีสิทธิ์ใช้ฟรีสำหรับนักศึกษาตามเงื่อนไขของผู้ให้บริการ (ดูบทความประกอบ) ห้ามส่งรหัสผ่าน token ไฟล์ .env หรือ log ที่มีข้อมูลส่วนบุคคลให้เครื่องมือ AI log ตัวอย่างในบทนี้มีเพียงที่อยู่ IP ภายในของ Docker จึงใช้ได้

13.1 Platform Engineering, Internal Developer Platform และ Golden Path

เมื่อองค์กรมีหลายทีม แต่ละทีมไม่ควรต้องสร้าง pipeline, Dockerfile และขั้นตอน deploy เองตั้งแต่ศูนย์ แนวคิด Platform Engineering ให้ทีมหนึ่งสร้าง platform ภายในให้ทีมอื่นใช้ CNCF นิยาม platform ว่าเป็น "an integrated collection of capabilities defined and presented according to the needs of the platform's users" และระบุลักษณะสำคัญ 7 ข้อ ได้แก่ platform as a product, user experience, documentation and onboarding, self-service, reduced cognitive load, optional and composable และ secure by default (CNCF TAG App Delivery) platform ที่บริการทีมพัฒนาภายในองค์กรเรียกว่า Internal Developer Platform (IDP)

Spotify เรียกเส้นทางมาตรฐานที่ platform เตรียมไว้ว่า Golden Path คือ "the 'opinionated and supported' path to 'build something'" ซึ่งใช้แก้ปัญหาที่เรียกว่า "rumour-driven development" คือการที่นักพัฒนาต้องถามต่อกันปากต่อปากว่าควรทำอย่างไร (Niemen, 2020)

ระดับที่ 1: workflow และสคริปต์ที่ผู้สอนให้มาเป็นแม่แบบตลอดรายวิชาคือตัวอย่างของ golden path ขนาดเล็ก ทีมที่ทำตามเส้นทางนี้ได้ระบบที่ทดสอบ สแกน และ deploy ได้โดยไม่ต้องตัดสินใจทุกเรื่องเอง

ระดับที่ 2: golden path ต่างจากกฎบังคับ ลักษณะสำคัญ optional and composable หมายถึงทีมเลือกออกนอกเส้นทางได้เมื่อมีเหตุผล เช่น งานต่อยอดของผู้เรียนที่ลองเครื่องมืออื่น แต่ทีมที่ออกนอกเส้นทางต้องดูแลส่วนนั้นเอง

ระดับที่ 3: platform as a product หมายถึงทีม platform ต้องถือว่าทีมพัฒนาเป็นผู้ใช้ เก็บความต้องการ และปรับปรุงตามการใช้งานจริง ปัญหาที่ผู้เรียนพบระหว่างรายวิชา เช่น Nginx ที่ใช้ IP เดิมของแอปจนได้ 502 หลัง deploy (บทที่ 9) หรือสคริปต์ตรวจความลับที่รายงานผิด (บทที่ 12) คือข้อมูลที่ทีม platform ใช้ปรับแม่แบบให้ดีขึ้น

คำถามตรวจความเข้าใจ 13.1: เลือกลักษณะสำคัญของ platform 1 ข้อที่แม่แบบของรายวิชายังทำได้ไม่ดี ยกเหตุการณ์จากบทที่ 8–12 เป็นหลักฐาน และเสนอสิ่งที่ควรเพิ่มในแม่แบบ

13.2 AI ในงาน DevOps

รายงาน DORA 2025 State of AI-assisted Software Development ซึ่งใช้แบบสำรวจผู้ทำงานด้านซอฟต์แวร์เกือบ 5,000 คน สรุปข้อค้นพบหลักว่า "AI's primary role in software development is that of an amplifier" คือ AI ขยายทั้งจุดแข็งและจุดอ่อนที่องค์กรมีอยู่แล้ว (DeBellis et al., 2025) ทีมที่มี test, การสแกน และ review ที่ดีจะใช้ AI ได้เร็วและปลอดภัยขึ้น ส่วนทีมที่ไม่มีจะผลิตความผิดพลาดได้เร็วขึ้นเช่นกัน

GitHub ระบุในเอกสารการใช้ Copilot อย่างรับผิดชอบว่าโค้ดที่ Copilot เสนออาจไม่ถูกต้องหรือมีช่องโหว่ ผู้ใช้ควร "always review and test the generated code thoroughly" และผู้ใช้เป็นผู้รับความเสี่ยงเองทั้งด้านช่องโหว่ bug และทรัพย์สินทางปัญญา (GitHub Docs) รายวิชาจึงใช้กติกาว่า ผู้เรียนต้องอธิบายและตรวจสอบได้ทุกส่วนที่ AI ช่วยทำ

ระดับที่ 1: AI ช่วยร่างได้เร็ว แต่ "ร่าง" ยังไม่ใช่ "งานที่เสร็จ" งานจะเสร็จเมื่อผ่านการตรวจแบบเดียวกับงานที่คนเขียน คือ test, การสแกน, review และการอธิบายได้

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

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

คำถามตรวจความเข้าใจ 13.2: สมาชิกคนหนึ่งให้ AI เขียนขั้นสแกนใน cd.yml แล้ว run ผ่านในครั้งแรก จึงสรุปว่าขั้นนั้นถูกต้อง อธิบายว่าเหตุใดการผ่านครั้งแรกยังไม่พอ โดยอ้างบทเรียนจากบทที่ 10 และระบุการตรวจที่ต้องทำเพิ่ม

13.3 ตรวจคำตอบของ AI ด้วยหลักฐาน

กิจกรรมนี้ใช้ log ของ Nginx จากระบบจริง ช่วงที่แอปหยุดชั่วคราวแล้วเริ่มใหม่ (บันทึกจากเครื่องจำลองเมื่อ 19 ต.ค. 2569 ตัดบรรทัด [notice] ออกแล้ว) ผู้สอนจะให้ AI วิเคราะห์ log นี้สดในชั้นเรียน แล้วทั้งห้องตรวจคำตอบทีละข้อด้วยคำสั่ง

บันทึกเนื้อหาต่อไปนี้เป็นไฟล์ demo-access.log

172.19.0.1 - - [19/Oct/2026:04:44:46 +0000] "GET / HTTP/1.1" 200 28 "-" "curl/8.5.0" "-"
172.19.0.1 - - [19/Oct/2026:04:44:46 +0000] "GET / HTTP/1.1" 200 28 "-" "curl/8.5.0" "-"
172.19.0.1 - - [19/Oct/2026:04:44:46 +0000] "GET / HTTP/1.1" 200 28 "-" "curl/8.5.0" "-"
172.19.0.1 - - [19/Oct/2026:04:44:46 +0000] "GET / HTTP/1.1" 200 28 "-" "curl/8.5.0" "-"
172.19.0.1 - - [19/Oct/2026:04:44:46 +0000] "GET / HTTP/1.1" 200 28 "-" "curl/8.5.0" "-"
172.19.0.1 - - [19/Oct/2026:04:44:46 +0000] "GET / HTTP/1.1" 200 28 "-" "curl/8.5.0" "-"
172.19.0.1 - - [19/Oct/2026:04:44:46 +0000] "GET / HTTP/1.1" 200 28 "-" "curl/8.5.0" "-"
172.19.0.1 - - [19/Oct/2026:04:44:46 +0000] "GET / HTTP/1.1" 200 28 "-" "curl/8.5.0" "-"
172.19.0.1 - - [19/Oct/2026:04:44:46 +0000] "GET /api/items HTTP/1.1" 200 80 "-" "curl/8.5.0" "-"
172.19.0.1 - - [19/Oct/2026:04:44:46 +0000] "GET /api/items HTTP/1.1" 200 80 "-" "curl/8.5.0" "-"
172.19.0.1 - - [19/Oct/2026:04:44:46 +0000] "GET /api/items HTTP/1.1" 200 80 "-" "curl/8.5.0" "-"
172.19.0.1 - - [19/Oct/2026:04:44:46 +0000] "GET /api/items HTTP/1.1" 200 80 "-" "curl/8.5.0" "-"
172.19.0.1 - - [19/Oct/2026:04:44:46 +0000] "GET /api/items/9 HTTP/1.1" 404 21 "-" "curl/8.5.0" "-"
172.19.0.1 - - [19/Oct/2026:04:44:46 +0000] "GET /api/items/12 HTTP/1.1" 404 21 "-" "curl/8.5.0" "-"
172.19.0.1 - - [19/Oct/2026:04:44:46 +0000] "GET /api/items/9 HTTP/1.1" 404 21 "-" "curl/8.5.0" "-"
172.19.0.1 - - [19/Oct/2026:04:44:46 +0000] "GET /admin HTTP/1.1" 404 144 "-" "curl/8.5.0" "-"
172.19.0.1 - - [19/Oct/2026:04:44:46 +0000] "GET /health HTTP/1.1" 200 33 "-" "curl/8.5.0" "-"
2026/10/19 04:45:46 [error] 70#70: *366 upstream timed out (110: Connection timed out) while connecting to upstream, client: 172.19.0.1, server: , request: "GET / HTTP/1.1", upstream: "http://172.19.0.3:3000/", host: "localhost"
172.19.0.1 - - [19/Oct/2026:04:45:46 +0000] "GET / HTTP/1.1" 504 176 "-" "curl/8.5.0" "-"
2026/10/19 04:45:49 [error] 70#70: *368 connect() failed (113: No route to host) while connecting to upstream, client: 172.19.0.1, server: , request: "GET / HTTP/1.1", upstream: "http://172.19.0.3:3000/", host: "localhost"
172.19.0.1 - - [19/Oct/2026:04:45:49 +0000] "GET / HTTP/1.1" 502 166 "-" "curl/8.5.0" "-"
2026/10/19 04:45:52 [error] 70#70: *370 connect() failed (113: No route to host) while connecting to upstream, client: 172.19.0.1, server: , request: "GET / HTTP/1.1", upstream: "http://172.19.0.3:3000/", host: "localhost"
172.19.0.1 - - [19/Oct/2026:04:45:52 +0000] "GET / HTTP/1.1" 502 166 "-" "curl/8.5.0" "-"
2026/10/19 04:45:55 [error] 70#70: *372 connect() failed (113: No route to host) while connecting to upstream, client: 172.19.0.1, server: , request: "GET /api/items HTTP/1.1", upstream: "http://172.19.0.3:3000/api/items", host: "localhost"
2026/10/19 04:45:55 [error] 70#70: *372 connect() failed (113: No route to host) while connecting to upstream, client: 172.19.0.1, server: , request: "GET /api/items HTTP/1.1", upstream: "http://172.19.0.3:3000/api/items", host: "localhost"
172.19.0.1 - - [19/Oct/2026:04:46:02 +0000] "GET / HTTP/1.1" 200 28 "-" "curl/8.5.0" "-"
172.19.0.1 - - [19/Oct/2026:04:46:02 +0000] "GET / HTTP/1.1" 200 28 "-" "curl/8.5.0" "-"
172.19.0.1 - - [19/Oct/2026:04:46:02 +0000] "GET / HTTP/1.1" 200 28 "-" "curl/8.5.0" "-"
172.19.0.1 - - [19/Oct/2026:04:46:02 +0000] "GET /health HTTP/1.1" 200 33 "-" "curl/8.5.0" "-"

คำถามที่ผู้สอนจะถาม AI และคำสั่งที่ใช้ตรวจ

ระดับที่ 1: ทุกคำถามที่มีคำตอบเป็นตัวเลขตรวจได้ด้วยคำสั่ง ถ้าตัวเลขของ AI ไม่ตรงกับผลของคำสั่ง ให้ถือผลของคำสั่ง แล้วหาว่า AI นับผิดเพราะอะไร เช่น นับบรรทัด error log เป็น request ด้วย

ระดับที่ 2: คำถามเชิงตีความ เช่น ข้อ 5 และ 6 ตรวจด้วยตัวเลขอย่างเดียวไม่ได้ ต้องเทียบกับความรู้จากบทก่อน ๆ และเอกสารทางการ เช่น ความหมายของ 502 และ 504 จากบทที่ 9 และนิยาม SLI ที่ไม่นับ 404 เป็น error จากบทที่ 11

ระดับที่ 3: ถ้าถามคำถามเดิมซ้ำ AI อาจตอบต่างกันได้ การตรวจจึงต้องทำทุกครั้ง ไม่ใช่ตรวจครั้งเดียวแล้วเชื่อตลอดไป และเมื่อพบว่า AI ตอบผิด ควรบันทึกไว้ในแบบฟอร์มการใช้ AI (งานข้อ 4) ว่าผิดอย่างไรและตรวจพบด้วยวิธีใด

คำถามตรวจความเข้าใจ 13.3: สมมุติว่า AI ตอบว่า "มี request ทั้งหมด 29 รายการ" ระบุว่าตัวเลขนี้น่าจะมาจากการนับแบบใด โดยอ้างคำสั่งที่ทำให้ได้ 29 และอธิบายว่าเหตุใดจึงผิด

13.4 สะท้อนการเรียนรู้ตลอดรายวิชา

Learning Log ทุกบทมี 4 หัวข้อเดียวกัน คือ สิ่งที่เรียน error ที่พบและวิธีแก้ แหล่งที่ใช้ค้นคำตอบ และสิ่งที่ยังไม่เข้าใจ เมื่อรวม 13 บท Log เหล่านี้เป็นหลักฐานว่าผู้เรียนเรียนรู้ด้วยตนเองจากแหล่งที่เชื่อถือได้อย่างต่อเนื่อง ซึ่งเป็นส่วนหนึ่งของ CLO4

ระดับที่ 1: reflection ที่ดีไม่ใช่การสรุปเนื้อหาของแต่ละบท แต่เป็นการมองข้ามบทว่าความเข้าใจเปลี่ยนไปอย่างไร เช่น "ในบทที่ 5 คิดว่า CI ผ่านแปลว่าระบบใช้ได้ แต่บทที่ 12 พบว่าเวอร์ชันที่ผ่าน test ยังทำให้ระบบหยุดได้"

ระดับที่ 2: หลักฐานที่แข็งแรงที่สุดใน reflection คือเหตุการณ์จริงของทีมที่ตรวจสอบย้อนกลับได้ เช่น ลิงก์ run ที่ล้ม หรือ issue ที่ทีมเปิด แทนข้อความทั่วไปอย่าง "ได้เรียนรู้มาก"

ระดับที่ 3: ส่วนที่บอกระดับ 3 ของ rubric CLO4 คือแผนเรียนต่อด้วยตนเองที่เป็นรูปธรรม เช่น หัวข้อในบทที่ 14–15 หรือส่วนเสริม X1–X6 แหล่งข้อมูลทางการที่จะใช้ และผลงานที่จะสร้าง

คำถามตรวจความเข้าใจ 13.4: เลือก Learning Log ของตนเองสองบทที่ห่างกันอย่างน้อย 5 บท แล้วเขียนหนึ่งย่อหน้าว่าความเข้าใจเรื่องใดเปลี่ยนไประหว่างสองบทนั้น พร้อมหลักฐาน

เฉลยจะเปิดในชั้นเรียนหลังทุกคนทำเสร็จ

13.5 หลักฐานการนำเสนอที่แยกความสามารถออกจากโชค

การสาธิตระบบสด (Live Demo) มักมีความเสี่ยงจากปัจจัยภายนอก เช่น เครือข่ายขัดข้อง หรือบริการภายนอกตอบสนองช้า สิ่งที่แยกระบบที่ทำงานได้จริงออกจากความบังเอิญคือหลักฐานย้อนหลังที่ตรวจสอบได้

• Pull Request ที่ Merge แล้ว: แสดงประวัติการสนทนา การ Review และการตรวจสอบเงื่อนไข Required Checks
• Run ของ CI/CD ใน GitHub Actions: ตรวจสอบได้ว่าแต่ละ Step ทำงานสำเร็จจริงและใช้ Commit SHA ใด
• RUNBOOK ที่ระบุคำสั่งชัดเจน: หากเกิดข้อผิดพลาด ทีมมีขั้นตอนการกู้ระบบที่กำหนดไว้ล่วงหน้าและทดสอบแล้ว

คำถามตรวจความเข้าใจ 13.5: หากการสาธิตสดในห้องล้มเหลวเนื่องจากเครือข่ายห้องแลบขัดข้อง ทีมควรแสดงหลักฐานใดจากระบบเพื่อยืนยันว่า Pipeline ทำงานได้จริงก่อนเริ่มคาบ

13.6 Platform ที่ลดงานซ้ำกับ Platform ที่สร้างคิวใหม่

เป้าหมายสูงสุดของ Internal Developer Platform (IDP) คือการทำให้ทีมพัฒนาสามารถช่วยเหลือตนเองได้ (Self-Service) โดยไม่ต้องรอคอยทีมอื่น

• Platform ที่ดี: เตรียม Golden Path ในรูปแบบ Template, Action สำเร็จรูป และโครงสร้างพื้นฐานอัตโนมัติ ทีมพัฒนาเริ่มต้นใช้งานได้ทันที
• Platform ที่มีปัญหา: กลายเป็นคอขวดใหม่เมื่อทุกคำขอต้องผ่านการอนุมัติแบบ Manual จากทีม Platform ซึ่งสร้างคิวการทำงานที่ยาวขึ้น

13.7 ตรวจข้อเสนอของ AI ทีละข้ออ้าง

เมื่อใช้ AI ช่วยในการออกแบบสถาปัตยกรรมหรือเขียนโค้ดระบบโครงสร้างพื้นฐาน:

1. แยกข้อเท็จจริงออกจากคำแนะนำ: ตรวจสอบว่าคำสั่งหรือพารามิเตอร์ที่ AI แนะนำมีอยู่จริงใน Documentation ของเวอร์ชันที่ใช้งาน
2. สร้างสภาพแวดล้อมทดสอบ: ทดลองรันโค้ดใน Container ทดสอบก่อนนำไปใส่ใน Pipeline หลักของทีม
3. ตรวจสอบความปลอดภัย: ระวังการใส่ค่าตั้งต้นที่ไม่ปลอดภัย เช่น การเปิดสิทธิ์ privileged: true ใน Docker หรือการใช้สิทธิ์ root

13.8 สะท้อนการเรียนรู้โดยเชื่อมข้ออ้างกับชิ้นงาน

การบันทึกการเรียนรู้ที่มีคุณค่าต้องเชื่อมโยงความเข้าใจเข้ากับผลงานจริง:

• อ้างอิงลิงก์ Pull Request หรือ Commit ที่สะท้อนการแก้ปัญหา
• เปรียบเทียบผลการวัดประสิทธิภาพก่อนและหลังปรับปรุง
• สรุปแนวทางที่นำไปประยุกต์ใช้ต่อในการทำงานจริงในอนาคต

สรุปบทเรียน

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