docs(sdlc): reformat work products to audited reference layout
Replace the PHP/Markdown seeding with a data-driven generator in scripts/sdlc-seed and regenerate all 59 work products.
This commit is contained in:
Thanakorn
+105
@@ -0,0 +1,105 @@
|
||||
# Product Operation Guide
|
||||
|
||||
<!-- footer: UM -->
|
||||
|
||||
| Document No | Product Operation Guide | Release, Version, By: | 25690817 V1.0 ThS |
|
||||
| Project Name | โครงการพัฒนาระบบบริหารจัดการคลังสินค้า (BRN WMS) บริษัท บี.อาร์.เอ็น เอ็นเตอร์ไพรส์ จำกัด |
|
||||
| Project Code | 200-WMS-26-001-00 |
|
||||
| Title | เอกสารคู่มือปฏิบัติงานสำหรับผู้ดูแลระบบ |
|
||||
| Project Period | 5 มกราคม 2569 – 24 สิงหาคม 2569 |
|
||||
| Organizer | คุณอภิรัชช์ สุภัทรประทีป (Project Manager) |
|
||||
| Recorder | คุณเยาวลักษณ์ บางชมภู (Document Control) |
|
||||
|
||||
## วัตถุประสงค์ (Objective)
|
||||
|
||||
คู่มือฉบับนี้จัดทำขึ้นเพื่อเป็นแนวทางสำหรับผู้ดูแลระบบ (System Administrator) ในการติดตั้ง ตั้งค่า เฝ้าระวัง สำรองข้อมูล และกู้คืนระบบบริหารจัดการคลังสินค้า เพื่อให้การปฏิบัติงานมีมาตรฐานและกู้คืนระบบได้อย่างรวดเร็ว
|
||||
|
||||
## 1 ทางเลือกในการติดตั้ง
|
||||
|
||||
| ลำดับ | วิธีการติดตั้ง | กลไก | ไฟล์อ้างอิง |
|
||||
| :---: | --- | --- | --- |
|
||||
| 1 | ติดตั้งแบบ Container (แนะนำ) | Docker Compose: php-apache, mariadb, node/pm2 | `docker-compose.yml`, `docker/` |
|
||||
| 2 | ติดตั้งแบบ Manual | ติดตั้ง PHP, MariaDB และ Node.js แล้วสร้างฐานข้อมูลด้วยสคริปต์ | `setup.php` |
|
||||
|
||||
## 2 ขั้นตอนการติดตั้งแบบ Container
|
||||
|
||||
1. คัดลอก `.env.example` เป็น `.env` หรือรันสคริปต์ `docker/init-env.sh` ซึ่งจะสอบถามรหัสผ่านฐานข้อมูล ชื่อโฮสต์สาธารณะ ค่า `EMIT_SECRET` และข้อมูล SMTP โดยค่าที่เว้นว่างระบบจะสุ่มให้อัตโนมัติ
|
||||
2. รันคำสั่ง `docker compose up -d --build` เพื่อสร้างและเริ่มบริการทั้งสามส่วน
|
||||
3. ตรวจสอบว่า Container `php-apache` สร้างไฟล์ `app/config.php` จาก `.env` เรียบร้อยแล้ว โดยไฟล์นี้ไม่ถูกเก็บใน Repository และไม่ฝังอยู่ใน Image
|
||||
4. ตรวจสอบว่าฐานข้อมูล `wms` และ `wms2` ถูกสร้างครบถ้วน และเข้าใช้งานระบบผ่านชื่อโฮสต์ที่กำหนดได้
|
||||
|
||||
## 3 ขั้นตอนการติดตั้งแบบ Manual
|
||||
|
||||
1. เตรียมเครื่องแม่ข่าย Linux ที่ติดตั้ง PHP 8 ขึ้นไป, MariaDB และ Node.js
|
||||
2. ตั้งค่าไฟล์ `app/config.php` ได้แก่ ข้อมูลเชื่อมต่อฐานข้อมูล `wms` และ `wms2`, `NODE_PUBLIC_URL`, `NODE_EMIT_URL`, `NODE_EMIT_SECRET` และข้อมูล SMTP
|
||||
3. รัน `setup.php` หนึ่งครั้งเพื่อสร้างโครงสร้างฐานข้อมูลทั้งหมด
|
||||
4. เริ่มบริการ Node.js (`nodejs/server.js` และ `nodejs/scheduler.js`) ด้วย pm2 ตามไฟล์ `nodejs/ecosystem.config.js`
|
||||
|
||||
## 4 การตั้งค่าระบบ
|
||||
|
||||
| รายการ | ที่ตั้ง | หมายเหตุ |
|
||||
| --- | --- | --- |
|
||||
| ค่าตั้งค่าแอปพลิเคชัน | `app/config.php` | สร้างขึ้นตอนติดตั้ง ไม่นำเข้า Repository |
|
||||
| ค่าความลับของสภาพแวดล้อม | `.env` (Docker) หรือตัวแปรสภาพแวดล้อม (Manual) | ยกเว้นจาก Git ด้วย `.gitignore` |
|
||||
| ค่าตั้งค่าระดับบริษัท | เมนูตั้งค่าในระบบ (`app/setting/`) | ข้อมูลบริษัท SMTP และการตั้งค่าการใช้งาน |
|
||||
| เขตเวลา | `$time_zone` ใน `app/config.php` | กำหนดเป็น `Asia/Bangkok` |
|
||||
|
||||
## 5 การเฝ้าระวังระบบ (Monitoring)
|
||||
|
||||
| ลำดับ | รายการตรวจสอบ | วิธีการ | ความถี่ |
|
||||
| :---: | --- | --- | --- |
|
||||
| 1 | บริการเว็บแอปพลิเคชัน | ตรวจสอบว่าระบบตอบสนองและผู้ใช้เข้าสู่ระบบได้ | ทุก 5 นาที (อัตโนมัติ) |
|
||||
| 2 | ฐานข้อมูล | ตรวจสอบว่าฐานข้อมูล `wms` และ `wms2` เชื่อมต่อได้ | ทุก 5 นาที (อัตโนมัติ) |
|
||||
| 3 | บริการ Node.js | ตรวจสอบสถานะ `server.js` และ `scheduler.js` ภายใต้ pm2 และตรวจ Log ใน `nodejs/logs/` | ทุก 5 นาที (อัตโนมัติ) |
|
||||
| 4 | งานตามกำหนดเวลา | ตรวจสอบว่างานสรุปยอดและงานแจ้งเตือนทำงานครบและไม่ซ้ำซ้อน | รายวัน |
|
||||
|
||||
เมื่อการตรวจสอบล้มเหลวติดต่อกัน 2 ครั้ง ระบบจะส่งอีเมลแจ้งเตือนผู้ดูแลระบบ โดย pm2 จะพยายามเริ่มบริการใหม่เป็นลำดับแรก หากไม่สามารถกู้คืนบริการได้ภายใน 30 นาที ผู้ดูแลระบบต้องแจ้งผู้จัดการโครงการ และหากเหตุขัดข้องเกิน 2 ชั่วโมงหรือกระทบการดำเนินธุรกิจอย่างมีนัยสำคัญ ต้องแจ้ง Project Sponsor
|
||||
|
||||
## 6 การสำรองข้อมูลและการกู้คืน
|
||||
|
||||
| รายการ | กลไก | รอบการทำงาน | การเก็บรักษา |
|
||||
| --- | --- | --- | --- |
|
||||
| Source Code และค่าตั้งค่าแม่แบบ | Git 2 Remote (`origin`, `backup`) | ทุกครั้งที่ส่งมอบหรือปรับ Baseline | เก็บถาวรใน Repository |
|
||||
| ฐานข้อมูล `wms` และ `wms2` | Export อัตโนมัติไปยังพื้นที่จัดเก็บบนคลาวด์ที่บริษัทควบคุม | ทุกวัน เวลา 02:00 น. | รายวันเก็บ 30 วัน สิ้นเดือนเก็บ 12 เดือน |
|
||||
| เอกสารโครงการ | ชุด PDF ที่สร้างจากเอกสารต้นฉบับ | ทุกครั้งที่ปรับปรุงเอกสารส่งมอบ | เก็บถาวรใน Repository |
|
||||
|
||||
### 6.1 ขั้นตอนการกู้คืนฐานข้อมูล
|
||||
|
||||
1. ผู้ดูแลระบบเลือกชุดสำรองที่ต้องการจากพื้นที่จัดเก็บบนคลาวด์ และยืนยันวันที่พร้อมความสมบูรณ์ของไฟล์
|
||||
2. กู้คืนชุดสำรองเข้าสู่สภาพแวดล้อมที่ไม่ใช่ระบบใช้งานจริงก่อนเสมอ
|
||||
3. ตรวจสอบการเชื่อมต่อฐานข้อมูล `wms` และ `wms2` พร้อมตรวจสอบข้อมูลหลักและรายการตัวอย่าง
|
||||
4. กรณีกู้คืนระบบใช้งานจริง ให้บันทึกจุดกู้คืน หยุดบริการที่เกี่ยวข้อง กู้คืนชุดสำรองที่ตรวจสอบแล้ว เริ่มบริการแอปพลิเคชันและ Node.js ใหม่ แล้วตรวจสอบสถานะตามหัวข้อ 5
|
||||
5. กรณีการสำรองข้อมูลล้มเหลวหรือไม่ทำงานตามกำหนด ผู้ดูแลระบบต้องตรวจสอบสาเหตุและสั่งทำงานซ้ำ
|
||||
|
||||
การทดสอบกู้คืนดำเนินการเมื่อ 23 สิงหาคม 2569 โดยกู้คืนชุดสำรองลงในสภาพแวดล้อมที่ไม่ใช่ระบบใช้งานจริงสำเร็จ ตรวจสอบการเข้าถึงฐานข้อมูลและข้อมูลตัวอย่างครบถ้วน และผู้จัดการโครงการได้ทบทวนผลการทดสอบในขั้นตอนปิดโครงการ
|
||||
|
||||
## 7 การปิดรายการควบคุมด้านปฏิบัติการ
|
||||
|
||||
| ลำดับ | รายการควบคุม | ผู้รับผิดชอบ | สถานะ | หลักฐานการปิดรายการ |
|
||||
| :---: | --- | --- | --- | --- |
|
||||
| OP-001 | การสำรองและกู้คืนฐานข้อมูล `wms` และ `wms2` แบบอัตโนมัติ | System Administrator | ปิดรายการ 23 สิงหาคม 2569 | หัวข้อ 6 ระบุรอบการสำรอง ที่จัดเก็บ การเก็บรักษา ขั้นตอนกู้คืน และผลการทดสอบกู้คืน |
|
||||
| OP-002 | การเฝ้าระวังระบบและการแจ้งเตือนเมื่อเกิดเหตุขัดข้อง | System Administrator | ปิดรายการ 23 สิงหาคม 2569 | หัวข้อ 5 ระบุรอบการตรวจสอบ เงื่อนไขการแจ้งเตือน ผู้รับแจ้ง และขั้นตอนการยกระดับ |
|
||||
|
||||
## 8 การจัดการผู้ใช้งานและสิทธิ์
|
||||
|
||||
- ผู้ใช้ระดับ Owner หรือ Admin จัดการผู้ใช้งาน บทบาท และสิทธิ์การเข้าถึงแอปพลิเคชันจากเมนูตั้งค่า
|
||||
- การเปลี่ยนบทบาทมีผลกับการทำงานครั้งถัดไปของผู้ใช้รายนั้น
|
||||
- ระบบอนุญาตให้ใช้งานได้ครั้งละหนึ่ง Session ต่อบัญชี เพื่อป้องกันการใช้บัญชีร่วมกัน
|
||||
|
||||
## ผู้จัดทำเอกสาร (Secretary)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณธนกร สถิตวิทยากุล | Developer | | |
|
||||
|
||||
## ผู้ตรวจสอบเอกสาร (Reviewer)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณนพพงษ์ เจริญสุข | System Analyst | | |
|
||||
|
||||
## ผู้อนุมัติ (Approval)
|
||||
|
||||
| ชื่อ | ตำแหน่ง | ลายเซ็น | วันที่ |
|
||||
| --- | --- | --- | --- |
|
||||
| คุณเสรี วิริยะสกุลธรณ์ | Project Sponsor | | |
|
||||
-115
@@ -1,115 +0,0 @@
|
||||
# Product Operation Guide
|
||||
|
||||
| Document field | Value |
|
||||
|---|---|
|
||||
| Document | Product Operation Guide |
|
||||
| Project | BRN WMS |
|
||||
| Project code | 200-WMS-26-001-00 |
|
||||
| Title | Operating Manual Document for System Administrators |
|
||||
| Project period | 05/01/26–24/08/26 |
|
||||
| Release | 17/08/26 V1.0 |
|
||||
| Closure status date | 24/08/26 |
|
||||
| Standard | ISO/IEC 29110 Basic Profile |
|
||||
| Organizer | Apirach Supattaratpateep (Project Manager), Noppong Chareunsook (System Analyst), Thanakorn Sathitwitayakul (Developer) |
|
||||
| Status | Final — reflects the implemented deployment mechanisms at project baseline |
|
||||
|
||||
## Objective
|
||||
|
||||
Guide a System Administrator through installing, configuring, operating, monitoring, backing up, and recovering BRN WMS, so operation is consistent, correct, and quickly recoverable.
|
||||
|
||||
## 1. Deployment options
|
||||
|
||||
BRN WMS supports two deployment paths, evidenced in the repository:
|
||||
|
||||
| Path | Mechanism | Reference |
|
||||
|---|---|---|
|
||||
| Manual installation | One-shot database setup script | `setup.php` |
|
||||
| Containerized deployment | Docker Compose stack: php-apache, mariadb, node/pm2 | `docker-compose.yml`, `docker/` |
|
||||
|
||||
## 2. Containerized installation (recommended)
|
||||
|
||||
1. Copy `.env.example` to `.env`, or run the interactive generator: `docker/init-env.sh` (prompts for DB password, public host, `EMIT_SECRET`, and SMTP credentials; auto-generates secrets left blank).
|
||||
2. Run `docker compose up -d --build`. This brings up:
|
||||
- `php-apache` — the PHP 8+ web application (`docker/php/`), with `app/config.php` generated from `.env` at container start by `docker/php/entrypoint.sh` — never baked into the image or committed.
|
||||
- `mariadb` — the database service, initialized from `docker/mariadb/init-wms2.sql` and `setup.php`.
|
||||
- `node` — the Node.js real-time/scheduler service (`docker/node/`), managed by pm2 (`nodejs/ecosystem.config.js`).
|
||||
3. Confirm the application is reachable at the configured public host and that the Node.js service is running (Section 5).
|
||||
|
||||
## 3. Manual installation
|
||||
|
||||
1. Provision a PHP 8+ / MariaDB / Node.js environment.
|
||||
2. Configure `app/config.php` (database credentials for the `wms` and `wms2` databases, `NODE_PUBLIC_URL`, `NODE_EMIT_URL`, `NODE_EMIT_SECRET`, SMTP).
|
||||
3. Run `setup.php` once to create the database schema (see Software Requirements Specification, SR08, for the full table list).
|
||||
4. Start the Node.js services (`nodejs/server.js`, `nodejs/scheduler.js`), for example under pm2 using `nodejs/ecosystem.config.js`.
|
||||
|
||||
## 4. Configuration
|
||||
|
||||
| Item | Location | Notes |
|
||||
|---|---|---|
|
||||
| Application configuration | `app/config.php` | Generated at deploy time; never committed |
|
||||
| Environment secrets | `.env` (Docker) or shell/deployment environment (manual) | Excluded via `.gitignore` |
|
||||
| Company-level settings | In-application (`app/setting/`) | Per-company profile, SMTP, system settings |
|
||||
| Time zone | `$time_zone` in `app/config.php` | Fixed to `Asia/Bangkok` |
|
||||
|
||||
## 5. Monitoring
|
||||
|
||||
- **Web application**: confirm the PHP application responds and users can authenticate.
|
||||
- **Database**: confirm both `wms` and `wms2` databases are reachable.
|
||||
- **Node.js service**: confirm `server.js` (Socket.IO) and `scheduler.js` (scheduled jobs) are running under pm2; review `nodejs/logs/` (`socket.log`, `scheduler.log`, `scheduler-error.log`) for errors.
|
||||
- **Scheduled jobs**: confirm stock/GL aggregate maintenance and low-stock/overdue-invoice alert jobs are completing on schedule without duplication.
|
||||
|
||||
The production monitoring control performs an automated health check every five minutes. Two consecutive failures trigger an email to the System Administrator. pm2 automatic restart is the first recovery response. If service is not restored within 30 minutes, the System Administrator escalates to the Project Manager; the Project Sponsor is notified when an outage exceeds two hours or materially affects business operations. The System Administrator reviews the affected process state and logs, restores service, confirms application and scheduled-job health, and records the incident through the applicable operational support channel.
|
||||
|
||||
## 6. Backup and recovery
|
||||
|
||||
| Item | Mechanism | Status |
|
||||
|---|---|---|
|
||||
| Source code and configuration templates | Git, two remotes (`origin`, `backup`) | See Project Repository / Project Repository (Backup), work products 9–10 |
|
||||
| Database (`wms`, `wms2`) | Automated database export at 02:00 ICT daily to company-controlled cloud storage | Daily backups retained 30 days; month-end backups retained 12 months; access restricted to the System Administrator and authorized management |
|
||||
| SDLC documents | External PDF export package | See Project Repository (Backup), Section 3 |
|
||||
|
||||
### 6.1 Database restoration procedure
|
||||
|
||||
1. The System Administrator selects the required backup from company-controlled cloud storage and confirms its date and integrity.
|
||||
2. The backup is restored into a non-production MariaDB environment before any production recovery is attempted.
|
||||
3. Connectivity to `wms` and `wms2` and representative master-data and transaction records are verified.
|
||||
4. For a production recovery, the System Administrator records the recovery point, pauses affected services, restores the verified backup, restarts the application and Node.js services, and performs the health checks in Section 5.
|
||||
5. Failed or missing scheduled backups are investigated and rerun by the System Administrator.
|
||||
|
||||
A sample backup dated 22/08/26 was restored successfully to a non-production environment on 23/08/26. Database accessibility and representative records were verified, and the Project Manager reviewed completion during closure.
|
||||
|
||||
## 7. Operational-control closure
|
||||
|
||||
| ID | Control | Owner | Status | Closure evidence |
|
||||
|---|---|---|---|---|
|
||||
| OP-001 | Automated database backup and restoration control for `wms` and `wms2`. | System Administrator | **Closed 23/08/26** | Section 6 records the 02:00 ICT schedule, controlled cloud destination, retention, operator, recovery steps, and successful non-production restoration test. |
|
||||
| OP-002 | Monitoring and failure alerting beyond local log review. | System Administrator | **Closed 23/08/26** | Section 5 records the five-minute health check, two-failure email trigger, recipients, escalation time, and recovery response. |
|
||||
|
||||
## 8. User and access management
|
||||
|
||||
An Owner/Admin manages users, roles (Owner/Admin/Staff/Viewer), and application-access flags from Settings (`app/setting/`). Role changes take effect on the user's next authenticated action; concurrent-session policy blocks a second simultaneous login on the same account.
|
||||
|
||||
## Approval
|
||||
|
||||
### Prepared by
|
||||
|
||||
Name: Thanakorn Sathitwitayakul
|
||||
Role: Developer
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed by
|
||||
|
||||
Name: Apirach Supattaratpateep
|
||||
Role: Project Manager
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
|
||||
### Reviewed and authorized by
|
||||
|
||||
Name: Seri Viriyasakultorn
|
||||
Project roles: Project Sponsor / Customer Representative / Authorized Approver
|
||||
Position: Managing Director
|
||||
Company: B.R.N. Enterprise Co., Ltd.
|
||||
Signature: ______________________________________________
|
||||
Date: ___________________________________________________
|
||||
Reference in New Issue
Block a user