Platform engineering สำหรับการพัฒนาด้วย AI

ให้ต้นแบบมีเส้นทางไปสู่ production

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

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

หากบริการต้องทำงานในโครงสร้างพื้นฐานขององค์กร ให้มีวิธี deploy ที่รองรับเข้าสู่บัญชี cloud หรือเครือข่ายขององค์กร ครอบคลุมตัวตน การจัดการ secret หลักฐานการออก release การติดตามระบบ และการกู้คืน ตรวจสอบการไหลของข้อมูลโมเดลแยกต่างหาก การเป็นเจ้าของ runtime ไม่ได้ควบคุมบริการพัฒนาทุกตัว

ดูแลแพลตฟอร์มเป็นผลิตภัณฑ์สำหรับผู้ใช้

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

CNCF อธิบายแพลตฟอร์มว่าเป็นความสามารถที่ออกแบบโดยยึดผู้ใช้ภายใน มี interface สม่ำเสมอ และเปิดให้ใช้ด้วยตนเองตามความเหมาะสม Portal อาจเปิดให้เข้าถึงความสามารถเหล่านี้ แต่ portal เพียงอย่างเดียวไม่ใช่แพลตฟอร์ม ดู CNCF Platforms White Paper

เริ่มจากความต้องการจริง ในบริษัทสมมติ หลายทีมต้องการบริการเว็บภายในที่มีการเข้าสู่ระบบของพนักงานและฐานข้อมูลที่มีผู้ดูแล สร้างวิธีที่รองรับความต้องการนี้ก่อนเพิ่มรายการฟีเจอร์จำนวนมากที่แทบไม่มีใครใช้

รวม agent ไว้ในกลุ่มผู้ใช้แพลตฟอร์ม

AI agent สร้างโค้ดโครงสร้างพื้นฐานได้รวดเร็ว แต่หากไม่มีบริบทแพลตฟอร์มปัจจุบัน ก็อาจเลือก region รูปแบบตัวตน หรือวิธี deploy ที่ไม่รองรับ การสร้างเร็วขึ้นไม่ได้แก้ข้อจำกัดขององค์กรที่ยังไม่ได้ระบุ

ให้ agent มี interface ที่เชื่อถือได้ กำหนด input ค่าที่อนุญาต output และพฤติกรรมเมื่อเกิดความผิดพลาด ให้ตัวอย่างที่ตรงกับเวอร์ชันที่ติดตั้ง ส่งกลับข้อผิดพลาดที่นำไปแก้ไขต่อได้โดยไม่เปิดเผย secret ใช้การตรวจสอบสิทธิ์แบบเดียวกันกับผู้เรียกที่เป็นคนและ agent

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

กำหนดเส้นทางที่รองรับและข้อจำกัด

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

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

ดูแลบริการต่อหลังสร้างแล้ว

Template เป็นเวอร์ชันเริ่มต้น ไม่ได้ patch แอปพลิเคชันที่สร้างจากมันโดยอัตโนมัติ กำหนดว่าการเปลี่ยนแปลงแพลตฟอร์มจะไปถึงบริการเดิมอย่างไร และจะตรวจสอบ compatibility อย่างไร

กำหนดเวอร์ชันของ interface และ module ที่ใช้ร่วมกัน ประกาศเงื่อนไขการยกเลิก ให้เส้นทาง migration ที่รองรับเมื่อจำเป็น เมื่อมีการแก้ไขความปลอดภัย ให้ติดตามว่าบริการใดยังใช้เวอร์ชันที่ได้รับผลกระทบ

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

เชื่อมแพลตฟอร์มกับโรงงานซอฟต์แวร์

Platform engineering กำหนดความสามารถที่รองรับและขอบเขตการเดินระบบ โรงงานซอฟต์แวร์เชื่อมข้อกำหนด การวางแผน การพัฒนา หลักฐาน และการส่งมอบ ทั้งสองส่วนเสริมกันได้เมื่อโรงงานวางแผนตามแพลตฟอร์มจริง

รวมการเดินระบบต่อเนื่องไว้ในการประเมิน ตรวจสอบว่าใครสแกนช่องโหว่ใหม่ deploy การแก้ไข ตอบสนอง incident และดูแลหลักฐานการปฏิบัติตามข้อกำหนด ความสามารถเหล่านี้ต้องมีขอบเขตที่ตกลงกันและผู้รับผิดชอบ คำว่า “โรงงานซอฟต์แวร์” ไม่ได้รับประกันว่าจะมีทั้งหมด

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

งานวิจัยของ DORA พิจารณาความสามารถ AI ร่วมกับบริบทองค์กร ใช้มุมมองนี้ประเมินขั้นตอนการทำงานทั้งหมด รวมถึงงานที่ยังเป็นหน้าที่ทีมแพลตฟอร์ม ดู รายงาน DORA 2025