nok/wms-app
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(sdlc): close training and operational actions

Browse Source
This commit is contained in:
Thanakorn
2026-08-26 13:10:06 +07:00
parent 5d93e87771
commit c4d3c6ea9e
9 changed files with 55 additions and 42 deletions
Download Patch File Download Diff File Expand all files Collapse all files
sdlc/2-SI Process (12 Work Product)/19.Product Operation Guide/200-WMS-26-001-00 Product Operation Guide 25690817 V1.0.md
+18 -5
View File
@@ -8,6 +8,7 @@
| 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 |
@@ -57,20 +58,32 @@ BRN WMS supports two deployment paths, evidenced in the repository:
- **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`) | Scheduled `mysqldump` script, run daily, output stored off-server with a retention policy | Operated and verified manually by the Developer; a restoration has been performed successfully. Because backup operation is manual, the script location, exact schedule, off-server destination, and retention period are not recorded in a controlled configuration reference — see Section 7 |
| 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 |
## 7. Accepted operational follow-up actions
### 6.1 Database restoration procedure
| ID | Follow-up action | Owner | Target | Closure criterion |
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 | Record the operated `mysqldump` backup control for `wms`/`wms2` in a controlled reference. | Developer | Before go-live | The controlled reference identifies the script location, exact schedule, off-server destination, retention period, responsible operator, and restoration procedure. |
| OP-002 | Document monitoring and failure alerting for the Node.js service beyond local log review. | Developer | Before go-live | The controlled procedure identifies the health check, alert trigger, recipient, escalation path, and recovery response for `server.js` and `scheduler.js`. |
| 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