รายการตรวจสอบความพร้อมสำหรับใช้งานจริง

รายการตรวจสอบที่คุณสามารถบันทึกเพื่ออนุมัติก่อนที่จะเปิดระบบ Opsta AI Gateway เพื่อรับข้อมูลใช้งานจริง โดยทุกหัวข้อเป็นสิ่งที่สามารถลงมือปฏิบัติและตรวจสอบความถูกต้องได้จริง ซึ่งให้ทำเครื่องหมายเมื่อคุณได้ตรวจสอบยืนยันการตั้งค่าบนคลัสเตอร์เรียบร้อยแล้ว รายการเหล่านี้สอดคล้องกับข้อมูลใน ตารางความรับผิดชอบร่วมกันและระดับความพร้อมในการใช้งาน (Shared responsibility & maturity) โดยทุกรายการที่เป็นของ "ลูกค้า" จะมีหัวข้อให้ตรวจสอบย้อนกลับในหน้านี้

เอกสารนี้เหมาะสำหรับใคร

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

ข้อควรระวังในการอนุมัติ

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

โครงสร้างพื้นฐานแพลตฟอร์ม

• [ ] ระบบ Kubernetes อยู่ในเกณฑ์รุ่นเวอร์ชันที่ผ่านการทดสอบมาตรฐาน ซึ่งสถาปัตยกรรมอ้างอิงหลักจะใช้งาน RKE2 บนเซิร์ฟเวอร์เสมือนระบบปฏิบัติการ Linux
• [ ] มี worker node ตั้งแต่ 3 โหนดขึ้นไป เพื่อรองรับการกระจายตัวของ replicas แบบ HA และกฎ anti-affinity ของ pod ได้จริง สำหรับระบบ HA
• [ ] มีการกำหนดใช้งาน StorageClass แบบ RWO เริ่มต้น และสำหรับระบบ HA จะต้องมี ระบบจัดเก็บออบเจกต์ที่เข้ากันได้กับ S3 ที่เชื่อมต่อได้ปกติสำหรับใช้เก็บข้อมูล LGTM และข้อมูลสำรอง สำหรับระบบ HA
• [ ] มีระบบ LoadBalancer เช่น cloud LB หรือใช้ MetalLB ในกรณีเซิร์ฟเวอร์ bare-metal หรือระบุช่องทางเข้า ingress ไว้อย่างชัดเจน เพื่อให้สามารถนำไอพีของ ingress ไปผูกกับระบบ DNS ได้
• [ ] ระบบเครือข่ายของคลัสเตอร์ CNI รองรับการบังคับใช้ NetworkPolicy เนื่องจากแพลตฟอร์มมีกฎการบล็อกการเชื่อมต่อเริ่มต้นมาให้ ซึ่งกฎดังกล่าวจะไม่มีผลใดๆ หาก CNI ไม่รองรับมาตรการนี้
• [ ] ระบบเทียบเวลา NTP และระบบ DNS สามารถทำงานได้อย่างถูกต้องบนทุกโหนด

การป้องกันข้อมูล

• [ ] กำหนดค่า postgres.backup.enabled: true และตรวจสอบว่าปลายทางของถังเก็บข้อมูลสำรองสามารถเข้าถึงได้ปกติ
• [ ] ได้ดำเนินการฝึกซ้อมการกู้คืนระบบจริง บนคลัสเตอร์จำลองชุดใหม่ และทำการบันทึกค่า RPO และ RTO จริง เรียบร้อยแล้ว ซึ่งสามารถดูรายละเอียดได้ที่หน้า การสำรองข้อมูลและการกู้คืน (Backup & DR)
• [ ] เปิดใช้งานมาตรการเข้ารหัสความลับขณะจัดเก็บ เช่น การเข้ารหัส etcd การใช้งาน Sealed Secrets หรือเชื่อมต่อกับระบบความลับภายนอกอย่าง KMS เนื่องจากค่าเริ่มต้นข้อมูลความลับจะเป็นเพียงข้อความธรรมดาใน Kubernetes Secrets เท่านั้น
• [ ] กำหนดระยะเวลาการจัดเก็บข้อมูลของประวัติการตรวจสอบ ตัววัดผล ล็อก และประวัติเส้นทางข้อมูล เรียบร้อยแล้ว รวมถึงตัดสินใจแนวทางบันทึกหรือปิดบังข้อมูลข้อความตัวอย่างที่ถูกบล็อกโดย guardrail เรียบร้อยดีแล้ว

ความปลอดภัย

• [ ] เลือกช่องทางการขอใบรับรอง TLS แล้ว ไม่ว่าจะเป็นแบบ letsencrypt หรือ provided และมีใบรับรอง wildcard สำหรับโดเมน *.<baseDomain> ที่ใช้งานได้จริง
• [ ] เชื่อมโยงระบบยืนยันตัวตน SSO และ OIDC เรียบร้อย และจำกัดการเข้าใช้งานเฉพาะกลุ่มโดเมนอีเมลขององค์กรที่กำหนด
• [ ] เปิดใช้งาน NetworkPolicies เรียบร้อย และรายการที่อนุญาตให้ส่งข้อมูลออกภายนอกครอบคลุมปลายทางบริการ LLM ที่เกตเวย์จำเป็นต้องเข้าถึงทั้งหมด
• [ ] อ้างอิงอิมเมจระบบแบบล็อกด้วยรหัสระบุเฉพาะ (digest) ซึ่งเป็นมาตรการป้องกันห่วงโซ่อุปทานในระยะแรก และมีการตั้งค่าสแกนช่องโหว่เมื่อดึงอิมเมจมาใช้งาน
• [ ] กำหนดผู้รับผิดชอบกระบวนการหมุนเวียนคีย์ความลับเรียบร้อยแล้ว สำหรับคีย์ผู้ให้บริการภายนอก ค่าความลับของระบบ IdP และข้อมูลใบรับรอง TLS ต่างๆ

ระบบระบุตัวตน

• [ ] เชื่อมต่อระบบ IdP ภายนอกเรียบร้อยแล้ว ผ่านทางระบบ Keycloak ไม่ว่าจะเป็นบัญชีภายใน ระบบ LDAP หรือ Active Directory ระบบ OIDC หรือ SAMล ตามที่ใช้งานจริง
• [ ] บันทึกข้อมูลบัญชีผู้ดูแลระบบเริ่มต้นสำหรับกู้คืนระบบเป็นลายลักษณ์อักษร และเก็บรหัสผ่านไว้ในคลังความลับของคุณเรียบร้อยแล้ว
• [ ] มีคู่มือกระบวนการลบผู้ใช้ออกจากระบบเตรียมพร้อมไว้ เนื่องจากระบบยังไม่รองรับการทำงาน SCIM อัตโนมัติในปัจจุบัน จึงต้องลบผู้ใช้งานแบบแมนนวลใน Keycloak ไปก่อนเมื่อมีพนักงานพ้นสภาพ

ระบบตรวจสอบสถานะการทำงาน

• [ ] ระบบ Grafana สามารถเข้าใช้งานได้จริงและแดชบอร์ดแสดงผลข้อมูลเป็นปกติ
• [ ] เชื่อมโยงระบบการแจ้งเตือนไปยังระบบของทีมงาน เช่น PagerDuty หรือ Opsgenie เมื่อเกิดสัญญาณความผิดปกติหลักเรียบร้อยแล้ว
• [ ] ตั้งค่าระยะเวลาการเก็บรักษาข้อมูลสำหรับล็อก ตัววัดผล และประวัติเส้นทางข้อมูลตามนโยบายขององค์กรเรียบร้อยแล้ว

การดำเนินงานของระบบ

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

การลงนามอนุมัติ

หัวข้อการอนุมัติ	รายละเอียดการตรวจสอบ
สภาพแวดล้อมระบบ หรือ คลัสเตอร์
สถาปัตยกรรม (Standalone หรือ HA)
เวอร์ชันของผลิตภัณฑ์
ค่า RPO และ RTO ที่บันทึกได้จากการซ้อมกู้คืน
ความเสี่ยงที่ยอมรับได้และผู้รับผิดชอบดูแล
ผู้ลงนามอนุมัติและวันที่อนุมัติ