แผนการถ่ายโอนระบบ (Transition Plan)
อ้างอิง TOR: ข้อ 4.11.2 (Transition Plan, Deployment Guide และ Backup Guide) ประกอบข้อ 4.10 (ฝึกอบรมและเอกสาร), 4.11.1 (ส่งมอบ Source/Config/Prompt/Benchmark), 4.11.3 (ลบ/ทำลายข้อมูล), 7.3 (งวดที่ 3), 11 (รับประกัน) และ 12 (SLA)
ฉบับ: 1.0 — วันที่ 3 ตุลาคม พ.ศ. 2569
สถานะเอกสาร: วันที่ในแผนเป็น วันที่สมมติ ตามสมมติฐานเดียวกับแผนการดำเนินงานโครงการ (/documents/project-plan) คือวันเริ่มสัญญา D0 = 1 ตุลาคม พ.ศ. 2569 และงวดที่ 3 ครบกำหนด D0+365 = 1 ตุลาคม พ.ศ. 2570 เมื่อลงนามสัญญาจริงจะปรับวันที่ให้ตรงกับสัญญา กิจกรรมที่ต้องมีบุคลากรของมหาวิทยาลัย (อบรม ทดลองปฏิบัติ ส่งมอบสิทธิ์) ยังไม่ได้เกิดขึ้นในรอบสาธิตนี้
1. วัตถุประสงค์
- ส่งมอบระบบ MBU Buddhist AI พร้อมซอร์สโค้ด การตั้งค่า prompt ชุดทดสอบ ข้อมูล และเอกสาร ให้มหาวิทยาลัยดูแลต่อได้ด้วยตนเอง
- ถ่ายทอดความรู้ให้ทีมผู้ดูแลระบบ ผู้ดูแลเนื้อหา (ฐานองค์ความรู้/ชุดทดสอบ) และผู้ใช้หลัก
- โอนสิทธิ์การเข้าถึงโครงสร้างพื้นฐาน บัญชี และความลับทั้งหมดให้มหาวิทยาลัย และถอนสิทธิ์ของผู้รับจ้างตามกำหนด
- รักษาความต่อเนื่องของบริการระหว่างและหลังการถ่ายโอน และกำหนดการสนับสนุนช่วงรับประกัน
2. ขอบเขตสิ่งที่ถ่ายโอน
| หมวด | รายการ | ตำแหน่ง/รูปแบบ |
|---|
| ซอร์สโค้ด | แอปพลิเคชัน สคริปต์ ชุดทดสอบ migration | Git repository (ประวัติ commit ครบ) |
| การตั้งค่า | .env.example, .env.development, .env.production, next.config.ts, ค่าตั้งต้น AI config, Helm values 3 environment | repository + ค่าในฐานข้อมูล (AiConfigSetting, ConfigSnapshot) |
| Prompt | config/prompts/*.md + เวอร์ชันในตาราง PromptVersion | repository + ฐานข้อมูล |
| ชุดทดสอบ/Benchmark | seed/benchmarks/*.csv + SOURCES.md + สคริปต์สร้าง + ผลการประเมินทุกรอบ | repository + ตาราง Evaluation* |
| ข้อมูล | ฐานองค์ความรู้ (เอกสาร chunks ไฟล์ต้นฉบับ), ผู้ใช้ บทสนทนา Audit Log ฯลฯ | ฐานข้อมูล + Object Storage/storage/uploads + ไฟล์สำรอง |
| โครงสร้างพื้นฐาน | Helm chart, pipeline CI/CD, การตั้งค่า Ingress/TLS/WAF | infra/helm/, .github/workflows/ci-cd.yml |
| ความลับ | AUTH_SECRET, DATA_ENCRYPTION_KEY, รหัสผ่านฐานข้อมูล/บริการ, OAuth/SMTP secret, kubeconfig/บัญชี CI | ส่งมอบผ่านช่องทางปลอดภัยแยกจากเอกสาร (ไม่อยู่ใน Git) — API key ของ LLM มหาวิทยาลัยเป็นผู้จัดหาและถือครองตั้งแต่ต้น (TOR 4.6.1) |
| เอกสาร | เอกสารส่งมอบ 36 ฉบับ (/documents) | Markdown + PDF (พิมพ์จากศูนย์เอกสาร) 2 ชุดตาม TOR 7.5 |
3. ผู้เกี่ยวข้องและบทบาท
| บทบาท | ฝ่าย | หน้าที่ในการถ่ายโอน |
|---|
| Project Manager | ผู้รับจ้าง | วางแผน ติดตาม และรายงานการถ่ายโอน เป็นผู้ประสานหลัก |
| Tech Lead / DevOps | ผู้รับจ้าง | ถ่ายทอดสถาปัตยกรรม การติดตั้ง CI/CD การสำรอง/กู้คืน |
| AI Engineer | ผู้รับจ้าง | ถ่ายทอด RAG pipeline, prompt, guardrail, การประเมินผล |
| Senior SE / QA | ผู้รับจ้าง | ถ่ายทอดโครงสร้างโค้ด ชุดทดสอบ การแก้ไขข้อบกพร่อง |
| ผู้ดูแลระบบ (IT) | มหาวิทยาลัย | รับมอบโครงสร้างพื้นฐาน ความลับ การติดตั้ง และปฏิบัติการ |
| ผู้ดูแลเนื้อหา | มหาวิทยาลัย | รับมอบงานฐานองค์ความรู้ การนำเข้า 91 เล่ม ชุดทดสอบ และการตรวจคุณภาพคำตอบ |
| ผู้ดูแล Admin Portal | มหาวิทยาลัย | รับมอบการจัดการผู้ใช้ PDPA Audit Dashboard การตั้งค่า AI |
| คณะกรรมการตรวจรับ | มหาวิทยาลัย | ตรวจรับตามเกณฑ์ในหัวข้อ 7 |
4. ระยะและกำหนดการ (อิงวันที่สมมติ)
gantt
title แผนการถ่ายโอนระบบ (วันที่สมมติ — ปรับตามสัญญาจริง)
dateFormat YYYY-MM-DD
axisFormat %d/%m
section เตรียมการ
ทบทวนแผน + รายการส่งมอบ + ผู้รับมอบ :t1, 2027-07-01, 14d
ตั้ง environment ของมหาวิทยาลัย (dev/test/prod) :t2, after t1, 21d
section ถ่ายทอดความรู้
อบรมผู้ใช้/ผู้ดูแล/ทีม IT :t3, 2027-08-01, 21d
Shadowing: ผู้รับจ้างทำ มหาวิทยาลัยดู :t4, after t3, 14d
Reverse shadowing: มหาวิทยาลัยทำ ผู้รับจ้างดู :t5, after t4, 14d
section ส่งมอบ
นำเข้าข้อมูลครบ 91 เล่ม + ประเมิน Acceptance :t6, 2027-08-01, 45d
ส่งมอบสิทธิ์/ความลับ + หมุนเวียนคีย์ :t7, 2027-09-15, 7d
ตรวจรับงวดที่ 3 :milestone, m1, 2027-10-01, 0d
section หลังส่งมอบ
Hypercare 30 วัน :t8, 2027-10-01, 30d
รับประกัน ≥365 วัน :t9, 2027-10-01, 365d
| ระยะ | ช่วงเวลา (สมมติ) | กิจกรรมหลัก | ผลผลิต |
|---|
| 1. เตรียมการ | ก.ค. 2570 | ยืนยันรายชื่อผู้รับมอบ, ทบทวนรายการส่งมอบ (หัวข้อ 2), ประเมินความพร้อมของทีมมหาวิทยาลัย, เตรียม environment บนคลาวด์ของมหาวิทยาลัยตาม /documents/deployment-guide | รายการตรวจสอบการส่งมอบที่ลงนาม |
| 2. ถ่ายทอดความรู้ | ส.ค.–ก.ย. 2570 | อบรมตาม /documents/training-materials (ผู้ใช้, ผู้ดูแล Admin Portal, ทีม IT, ผู้ดูแลเนื้อหา); shadowing และ reverse shadowing งานประจำ (หัวข้อ 5) | บันทึกการอบรม ผลแบบประเมิน |
| 3. ส่งมอบ | ก.ย. 2570 | นำเข้าพระไตรปิฎกฉบับ มมร. ครบ 91 เล่ม (/documents/data-ingestion-plan), รัน Benchmark รอบ Acceptance, ทดสอบ restore บน environment ของมหาวิทยาลัย, ส่งมอบซอร์สโค้ด/ความลับ/สิทธิ์, หมุนเวียนคีย์ | หนังสือส่งมอบ, รายงานผลทดสอบ |
| 4. ตรวจรับ | 1 ต.ค. 2570 | ตรวจรับงวดที่ 3 ตามเกณฑ์หัวข้อ 7 | บันทึกตรวจรับ |
| 5. Hypercare | 30 วันหลังตรวจรับ | ผู้รับจ้างเฝ้าระวังร่วม ตอบปัญหาเร่งด่วน ปรับจูนตามการใช้งานจริง | รายงานสรุป Hypercare |
| 6. รับประกัน | ≥365 วันหลังตรวจรับ | แก้ไขข้อบกพร่องตาม SLA (TOR 11, 12) รายงาน SLA รายเดือน | รายงาน SLA รายเดือน |
5. แผนถ่ายทอดความรู้ (Knowledge Transfer)
| หัวข้อ | กลุ่มเป้าหมาย | เอกสาร/เครื่องมืออ้างอิง | วิธียืนยันว่าทำได้ |
|---|
| การใช้งานระบบ (ถาม-ตอบ Dhamma Talk ประวัติ PDPA) | ผู้ใช้หลัก | /documents/user-manual | ทดลองตามสถานการณ์ |
| Admin Portal ทุกหน้า และตารางสิทธิ์ | ผู้ดูแล Admin Portal | /documents/admin-manual | ทำงานประจำตามหัวข้อ 9 ของคู่มือได้ด้วยตนเอง |
| ฐานองค์ความรู้: นำเข้า metadata precedence re-index ความครอบคลุม | ผู้ดูแลเนื้อหา | /documents/data-ingestion-plan, /admin/knowledge-base | นำเข้าเอกสาร 1 เล่มจนค้นเจอและ citation ถูกต้อง |
| การประเมินคุณภาพ AI: ชุดทดสอบ รัน เปรียบเทียบ รายงาน | ผู้ดูแลเนื้อหา + IT | /admin/evaluation, scripts/eval/run-acceptance.ts | รัน 1 ชุดและเปรียบเทียบกับรอบก่อน |
| Prompt/Guardrail/AI config และการย้อนกลับ | ผู้ดูแล + AI owner | /admin/prompts, /admin/guardrails, /admin/ai-config | สร้างเวอร์ชัน prompt แล้ว rollback |
| สถาปัตยกรรมและโครงสร้างโค้ด | ทีม IT/นักพัฒนา | /documents/srs, /documents/system-documentation, docs/dev-conventions.md | แก้ไขเล็กน้อยพร้อมเพิ่มกรณีทดสอบให้ผ่าน npm test |
| ติดตั้ง/อัปเกรด/rollback | ทีม IT | /documents/deployment-guide, /documents/cicd-pipeline | deploy ไป mbu-test และ rollback |
| สำรอง/กู้คืน | ทีม IT | /documents/backup-restore-guide | ทดสอบ restore และออกรายงาน |
| เฝ้าระวัง แจ้งเตือน SLA Defect | ทีม IT + ผู้ดูแล | /admin/alerts, /admin/sla-report, /admin/defect-log | ออกรายงาน SLA รายเดือน |
| ความมั่นคงปลอดภัยและ PDPA | ทีม IT + DPO | /documents/test-checklist, /documents/pdpa-dpa | ดำเนินคำขอ PDPA และตรวจ Audit Log |
6. การส่งมอบสิทธิ์และความลับ
- จัดทำทะเบียนบัญชี/สิทธิ์ทั้งหมด: Git repository, container registry, GitHub environments (
dev/test/prod) และ secrets (KUBE_CONFIG หรือ OIDC), Kubernetes namespaces, บริการข้อมูล, DNS/TLS, SMTP, OAuth client, บัญชี SUPER_ADMIN ของระบบ
- โอนความเป็นเจ้าของ repository และ registry ให้องค์กร/บัญชีของมหาวิทยาลัย
- ส่งมอบความลับผ่านช่องทางปลอดภัย (secret manager ของมหาวิทยาลัย) ต่อหน้าผู้รับมอบ และบันทึกการส่งมอบโดยไม่บันทึกค่าความลับลงเอกสาร
- หมุนเวียนความลับหลังส่งมอบ:
AUTH_SECRET (ผู้ใช้ต้องเข้าสู่ระบบใหม่), รหัสผ่านฐานข้อมูล/บริการ, OAuth/SMTP secret, kubeconfig — ส่วน DATA_ENCRYPTION_KEY เปลี่ยนไม่ได้โดยไม่เข้ารหัสข้อมูลใหม่ทั้งหมด จึงส่งมอบและเก็บรักษา (หรือวางแผนเข้ารหัสใหม่เป็นงานแยก)
- เปลี่ยนรหัสผ่านบัญชีผู้ดูแลทั้งหมด ลบ/ระงับบัญชีสาธิตและบัญชีของผู้รับจ้าง ตั้ง
ADMIN_IP_ALLOWLIST เป็นเครือข่ายของมหาวิทยาลัย
- ถอนสิทธิ์ผู้รับจ้างทั้งหมดเมื่อสิ้นสุด Hypercare ยกเว้นสิทธิ์จำกัดที่จำเป็นต่อการรับประกันตามที่มหาวิทยาลัยอนุมัติ (บันทึกใน Audit Log)
7. เกณฑ์การส่งมอบสำเร็จ (Exit Criteria)
| # | เกณฑ์ | หลักฐาน |
|---|
| 1 | ระบบทำงานบน environment ของมหาวิทยาลัย ผ่าน smoke test (/api/health) | ผล pipeline / บันทึกการติดตั้ง |
| 2 | ชุดทดสอบอัตโนมัติผ่าน และ coverage ผ่านเกณฑ์ | /documents/coverage-report, ผล CI |
| 3 | Benchmark 7 ชุดผ่านเกณฑ์ขั้นต่ำ TOR ก.5.3 | /documents/baseline-evaluation-report |
| 4 | นำเข้าพระไตรปิฎกฉบับ มมร. ครบตามภาคผนวก ข | /documents/ingestion-report |
| 5 | ไม่มี Defect ระดับ High/Critical คงค้าง | /admin/defect-log |
| 6 | ทดสอบ restore บน environment ของมหาวิทยาลัยผ่าน | /documents/restore-test-report |
| 7 | อบรมครบทุกกลุ่ม และทีมมหาวิทยาลัยทำงานประจำได้เอง (reverse shadowing) | บันทึกการอบรม |
| 8 | ส่งมอบซอร์สโค้ด config prompt benchmark เอกสาร 36 ฉบับ (2 ชุด + PDF + ไฟล์แก้ไขได้) | หนังสือส่งมอบ |
| 9 | ส่งมอบสิทธิ์/ความลับครบ และหมุนเวียนคีย์แล้ว | ทะเบียนสิทธิ์ที่ลงนาม |
| 10 | ผู้รับจ้างลบข้อมูลของมหาวิทยาลัยที่อยู่ในความครอบครองของตนพร้อมหนังสือรับรอง (TOR 4.11.3) | /documents/data-destruction-certificate |
8. ความต่อเนื่องของบริการระหว่างถ่ายโอน
- ย้ายระบบในช่วงเวลาที่มีผู้ใช้น้อย และประกาศล่วงหน้าผ่านโหมด Unavailable พร้อมข้อความ (
/admin/unavailable)
- สำรองข้อมูลก่อนย้าย และทดสอบ restore บนปลายทางก่อนเปิดใช้จริง
- ใช้ pipeline deploy ไป
mbu-test ให้มหาวิทยาลัยทดสอบ (UAT) ก่อนสร้าง tag ขึ้น mbu-prod
- เตรียมแผนย้อนกลับ (helm rollback / กู้คืนจาก backup) ตาม
/documents/deployment-guide หัวข้อ 6
9. การสนับสนุนหลังส่งมอบ
| ช่วง | ระดับการสนับสนุน |
|---|
| Hypercare (30 วัน) | ผู้รับจ้างเฝ้าระวังร่วม ประชุมสรุปรายสัปดาห์ แก้ปัญหาเร่งด่วน |
| รับประกัน (≥365 วัน, TOR 11.1) | แก้ไขข้อบกพร่องโดยไม่คิดค่าใช้จ่าย ตามเวลาแก้ไข: สูง 24 ชม. / กลาง 48 ชม. / ต่ำ 10 วันทำการ นับจากแจ้งจนมหาวิทยาลัยยืนยันผล (TOR 12.3–12.4) บันทึกใน Defect Log |
| รายงาน | รายงาน SLA รายเดือนภายในวันที่ 15 ของเดือนถัดไป (TOR 12.5) |
| ช่องทางติดต่อ | อีเมล โทรศัพท์ และช่องทางเร่งด่วน แสดงที่หน้า /help และ /documents/team-structure (TOR 11.2) |
10. ความเสี่ยงของการถ่ายโอน
| ความเสี่ยง | มาตรการ |
|---|
| ทีมมหาวิทยาลัยยังไม่พร้อมดูแลเทคโนโลยี (Kubernetes, LLM, RAG) | อบรมเชิงปฏิบัติ + reverse shadowing + คู่มือ + Hypercare |
| คีย์เข้ารหัสสูญหาย | เก็บ DATA_ENCRYPTION_KEY ใน secret manager พร้อมสำรองตามนโยบาย |
| ไฟล์ 91 เล่มส่งมอบล่าช้า/เป็นไฟล์สแกน | เริ่มนำเข้าตั้งแต่งวด 2, แผน OCR (/documents/data-ingestion-plan หัวข้อ 12) |
| คุณภาพคำตอบเปลี่ยนเมื่อเปลี่ยนโมเดล/prompt | ใช้ระบบประเมินผลและเปรียบเทียบรอบก่อนเปลี่ยนเสมอ |
| ความรู้กระจุกที่บุคคล | เอกสารใน repository + บันทึกการอบรม + ผู้รับมอบอย่างน้อย 2 คนต่อบทบาท |
