---
title: "แผนการถ่ายโอนระบบ (Transition Plan)"
titleEn: "Transition Plan"
clauses: ["4.11.2"]
phase: 3
category: "ส่งมอบ"
generated: false
---

# แผนการถ่ายโอนระบบ (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. วัตถุประสงค์

1. ส่งมอบระบบ MBU Buddhist AI พร้อมซอร์สโค้ด การตั้งค่า prompt ชุดทดสอบ ข้อมูล และเอกสาร ให้มหาวิทยาลัยดูแลต่อได้ด้วยตนเอง
2. ถ่ายทอดความรู้ให้ทีมผู้ดูแลระบบ ผู้ดูแลเนื้อหา (ฐานองค์ความรู้/ชุดทดสอบ) และผู้ใช้หลัก
3. โอนสิทธิ์การเข้าถึงโครงสร้างพื้นฐาน บัญชี และความลับทั้งหมดให้มหาวิทยาลัย และถอนสิทธิ์ของผู้รับจ้างตามกำหนด
4. รักษาความต่อเนื่องของบริการระหว่างและหลังการถ่ายโอน และกำหนดการสนับสนุนช่วงรับประกัน

## 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. ระยะและกำหนดการ (อิงวันที่สมมติ)

```mermaid
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. การส่งมอบสิทธิ์และความลับ

1. จัดทำทะเบียนบัญชี/สิทธิ์ทั้งหมด: Git repository, container registry, GitHub environments (`dev`/`test`/`prod`) และ secrets (`KUBE_CONFIG` หรือ OIDC), Kubernetes namespaces, บริการข้อมูล, DNS/TLS, SMTP, OAuth client, บัญชี SUPER_ADMIN ของระบบ
2. โอนความเป็นเจ้าของ repository และ registry ให้องค์กร/บัญชีของมหาวิทยาลัย
3. ส่งมอบความลับผ่านช่องทางปลอดภัย (secret manager ของมหาวิทยาลัย) ต่อหน้าผู้รับมอบ และบันทึกการส่งมอบโดยไม่บันทึกค่าความลับลงเอกสาร
4. **หมุนเวียนความลับหลังส่งมอบ:** `AUTH_SECRET` (ผู้ใช้ต้องเข้าสู่ระบบใหม่), รหัสผ่านฐานข้อมูล/บริการ, OAuth/SMTP secret, kubeconfig — ส่วน `DATA_ENCRYPTION_KEY` เปลี่ยนไม่ได้โดยไม่เข้ารหัสข้อมูลใหม่ทั้งหมด จึงส่งมอบและเก็บรักษา (หรือวางแผนเข้ารหัสใหม่เป็นงานแยก)
5. เปลี่ยนรหัสผ่านบัญชีผู้ดูแลทั้งหมด ลบ/ระงับบัญชีสาธิตและบัญชีของผู้รับจ้าง ตั้ง `ADMIN_IP_ALLOWLIST` เป็นเครือข่ายของมหาวิทยาลัย
6. ถอนสิทธิ์ผู้รับจ้างทั้งหมดเมื่อสิ้นสุด 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 คนต่อบทบาท |