VTRC Knowledge Manual (V2)

ธีม

14.8 Debug playbooks — top 10 scenarios ​

บทนี้รวบรวม 10 สถานการณ์ที่พบบ่อยในการดูแลระบบ พร้อมขั้นตอนตรวจสอบและแก้ไข

Scenario 1 — ผู้ใช้ login ไม่สำเร็จ ​

อาการ ​

ผู้ใช้แจ้งว่ากรอก username/password ถูกต้อง แต่ login ไม่ผ่าน

ขั้นตอนตรวจสอบ ​

bash
# 1. ตรวจสอบว่า service ทั้งหมดรัน
docker ps --filter "name=vtrc-api"
docker ps --filter "name=cu-central"

# 2. ตรวจสอบ log ของ vtrc-api
docker logs --tail 100 vtrc-api-nodejs | grep -i 'login\|ldap\|error'

# 3. ตรวจสอบ log ของ cu-central-api (LDAP)
docker logs --tail 100 cu-central-api | grep -i 'ldap\|bind\|error'

# 4. ตรวจสอบ LDAP reachability
docker exec cu-central-api ping -c 3 sso.redcross.or.th
docker exec cu-central-api nc -zv sso.redcross.or.th 389

สาเหตุที่เป็นไปได้ ​

  1. LDAP/AD ล้มเหลว — log cu-central-api แสดง ECONNREFUSED หรือ Invalid Credentials → ประสานงานผู้ดูแล AD
  2. cu-central-api ไม่รัน → docker-compose up -d ที่ cu-central host
  3. Network ระหว่าง vtrc-api และ cu-central-api หาย → ตรวจ END_POINT_CENTRALIZE ใน .env
  4. User ถูกล็อคใน AD → ประสานงานผู้ดูแล AD
  5. device key ไม่ตรง → ตรวจ apiKey header ที่ส่งจาก client

Scenario 2 — เว็บเปิดไม่ได้ (502 Bad Gateway) ​

อาการ ​

ผู้ใช้เข้า https://vtrc.redcross.or.th/ ได้รับ 502 Bad Gateway

ขั้นตอนตรวจสอบ ​

bash
# 1. ตรวจ nginx
docker logs --tail 50 vtrc-web-server
tail -50 /home/dev/vtrc-api/nginx-log/error-web-443.log

# 2. ตรวจ upstream — vtrc-api ทุก replica ตายหรือไม่
docker ps --filter "name=vtrc-api"

# 3. ตรวจ vtrc-web build
docker exec vtrc-web-server ls /usr/share/nginx/html/
ls /home/dev/vtrc-web/build/

# 4. ทดสอบ nginx upstream
docker exec vtrc-web-server curl -I http://localhost:8081/api/graphql

สาเหตุที่เป็นไปได้ ​

  1. vtrc-api ทุก replica ตาย → restart ตามบท 13.2
  2. nginx config ผิด → docker exec vtrc-web-server nginx -t
  3. build directory ว่าง → redeploy vtrc-web ตามบท 13.3
  4. Cert SSL หมดอายุ → ดูบท 13.9
  5. DNS ผิด → ตรวจ DNS record ของโดเมน

Scenario 3 — PDF payslip ไม่ออก ​

อาการ ​

ผู้ใช้กดดาวน์โหลด payslip แต่ได้รับ error หรือไม่มีไฟล์

ขั้นตอนตรวจสอบ ​

bash
# 1. ตรวจ slipError log
tail -100 /home/dev/vtrc-api/api-logs/slipError_$(date +%Y-%m-%d).log

# 2. ตรวจว่า qpdf binary อยู่ครบ
docker exec vtrc-api-nodejs which qpdf
docker exec vtrc-api-nodejs qpdf --version

# 3. ตรวจ disk space (PDF เขียนลง disk)
df -h
du -sh /home/dev/vtrc-api/api-storage/prs/

# 4. ตรวจ HTML template
docker exec vtrc-api-nodejs ls /usr/src/app/api/templates/slip/

# 5. ทดสอบ PDF generation ด้วยตนเอง (ผ่าน GraphQL mutation)

สาเหตุที่เป็นไปได้ ​

  1. qpdf ไม่ได้ติดตั้งใน image → rebuild Docker image ให้แน่ใจว่ามี qpdf
  2. password PDF มีอักขระพิเศษ → แก้ที่ source code ที่ escape shell argument
  3. disk เต็ม → ลบไฟล์ PDF เก่า
  4. PhantomJS ค้าง → restart replica ที่ค้าง
  5. Template HTML หาย → redeploy image

Scenario 4 — cron job ไม่รัน ​

อาการ ​

การแจ้งเตือนอัตโนมัติไม่ส่ง, ข้อมูลบางอย่างไม่ sync, หรือ fund rate ค้าง PENDING

ขั้นตอนตรวจสอบ ​

bash
# 1. ตรวจ APP_NO ของแต่ละ container (สำคัญสำหรับ job ที่ถูก gate)
docker ps --filter "name=vtrc-api-nodejs"
docker exec vtrc-api-nodejs printenv APP_NO
docker exec vtrc-api-nodejs-2 printenv APP_NO
docker exec vtrc-api-nodejs-3 printenv APP_NO
docker exec vtrc-api-nodejs-5 printenv APP_NO

# 2. ตรวจ cron log (ทุก replica — เพราะ delegate/stat รันทุกตัว)
docker logs --tail 200 vtrc-api-nodejs | grep -i 'schedule\|cron\|job\|fund\|delegate\|statLog'
docker logs --tail 200 vtrc-api-nodejs-2 | grep -i 'schedule\|cron\|job\|delegate\|statLog'

# 3. ตรวจ notificationLog
tail -100 /home/dev/vtrc-api/api-logs/notificationLog_$(date +%Y-%m-%d).log

# 4. ตรวจ timezone
docker exec vtrc-api-nodejs date

สาเหตุที่เป็นไปได้ ​

  1. APP_NO=1 ตาย → กระทบเฉพาะ updateSuccessFundChangeRateByJob (และ cron ทั้งชุดของ cu-central) — ไม่ใช่ updateDelegatesExpire / statLog ซึ่งรันทุก replica
  2. timezone ผิด → cron schedule อ้างเวลา UTC แต่คาดไว้ท้องถิ่น (หรือกลับกัน)
  3. External service (FCM, KBank) ล้มเหลว → log แสดง ECONNREFUSED
  4. Code bug / รันซ้ำ → delegate/stat บนหลาย replica อาจแข่งกัน — ดู error ใน notificationLogError
  5. cu-central APP_NO=1 ตาย → cron ของ cu-central ทั้งชุดหยุด (ต่างจาก vtrc)

Scenario 5 — GraphQL query ช้ามาก ​

อาการ ​

หน้าเว็บ load ช้า, API response time > 5 วินาที

ขั้นตอนตรวจสอบ ​

bash
# 1. ดู nginx access log หา request ที่ช้า
awk '$NF > 2.0' /home/dev/vtrc-api/nginx-log/access-api-443.log | tail -20

# 2. ตรวจ database process
mysql -h <db-host> -u root -p -e "SHOW PROCESSLIST"

# 3. ตรวจ MariaDB slow query log
tail -50 /var/log/mysql/slow.log

# 4. ตรวจ Redis (cache / session — ไม่ใช่ OTP)
docker exec vtrc-redis redis-cli INFO memory
docker exec vtrc-redis redis-cli SLOWLOG GET 10
docker exec cu-centralize-redis redis-cli INFO memory

# 5. ตรวจ CPU/memory ของ container
docker stats

สาเหตุที่เป็นไปได้ ​

  1. Query ที่ไม่มี index → ใช้ EXPLAIN วิเคราะห์
  2. N+1 query → ดู Sequelize log
  3. Connection pool เต็ม → ดู SHOW STATUS LIKE 'Threads_connected'
  4. Redis ช้า → ดู SLOWLOG (กระทบ cache/session ไม่ใช่ OTP)
  5. CPU ของ container เต็ม → docker stats
  6. Memory leak → restart container ที่ใช้ memory มาก

Scenario 6 — ผู้ใช้ไม่ได้รับ OTP ​

อาการ ​

ผู้ใช้กดขอ OTP สำหรับ registration หรือ forget password แต่ไม่ได้รับ SMS

ขั้นตอนตรวจสอบ ​

bash
# 1. ตรวจ OTP ใน MariaDB ของ cu-central (ตาราง otp — ไม่ใช่ vtrc Redis)
mysql -h <cu-central-db-host> -u <user> -p -e "
  SELECT otpId, sentTo, refCode, expiredAt, ableResendAt, createdAt
  FROM otp
  WHERE sentTo = '0812345678'
  ORDER BY otpId DESC
  LIMIT 5;
"

# 2. ตรวจ SMS / OTP log ที่ cu-central (ผู้สร้าง OTP และส่ง SMS จริง)
docker logs --tail 100 cu-central-api | grep -i 'sms\|otp\|OTP_DELAY'

# 3. ตรวจ vtrc-api ว่า proxy requestOtpCD สำเร็จหรือไม่
docker logs --tail 100 vtrc-api-nodejs | grep -i 'requestOtp\|otp\|sms'

# 4. ทดสอบ SMS gateway
curl -X POST https://sms-gateway-url/... \
  -d "msg=test&phone=0812345678"

อย่า รัน KEYS 'otp:*' บน vtrc-redis — OTP ไม่ได้เก็บที่นั่น

สาเหตุที่เป็นไปได้ ​

  1. SMS gateway ล้มเหลว → ประสานงานผู้ให้บริการ SMS
  2. เครดิต SMS หมด → ตรวจบัญชีผู้ให้บริการ
  3. เบอร์โทรผิด → ตรวจใน DB ว่าเบอร์ถูกต้อง
  4. ยังอยู่ในช่วง ableResendAt → cu-central คืน OTP_DELAY (ยังไม่ถึงเวลาขอใหม่)
  5. แถว OTP หมดอายุแล้ว → TTL เริ่มต้น 3 นาที (SMS_OTP_EXPIRE_MINUTES)
  6. Rate limit บล็อค → ดู cu-central-api rate limit config

Scenario 7 — ข้อมูล user ไม่ sync จาก HRMI ​

อาการ ​

ข้อมูล user ใน vtrc ไม่ตรงกับ HR data ล่าสุด

ขั้นตอนตรวจสอบ ​

bash
# 1. ตรวจ log ของ cu-central-api
docker logs --tail 100 cu-central-api | grep -i 'sync\|hrmi\|sourceDb'

# 2. ตรวจ MSSQL HRMI reachability
docker exec cu-central-api nc -zv <hrmi-host> 1433

# 3. ตรวจ sync job schedule
docker logs --tail 200 cu-central-api | grep -i 'schedule'

# 4. ตรวจตาราง mirror ใน vtrc-centralize
mysql -h <db-host> -u root -p vtrc-centralize -e "SELECT COUNT(*) FROM Users;"

สาเหตุที่เป็นไปได้ ​

  1. MSSQL HRMI ล้มเหลว → ประสานงานผู้ดูแล MSSQL
  2. Sync job ค้าง → restart cu-central-api
  3. SourceDB sharding config ผิด → ตรวจ .env ของ cu-central-api
  4. Data stale ใน vtrc-centralize → trigger sync manual

Scenario 8 — service restart เอง (OOM) ​

อาการ ​

Container restart เองบ่อย, ผู้ใช้บ่นว่าใช้งานไม่ได้เป็นระยะ

ขั้นตอนตรวจสอบ ​

bash
# 1. ดู restart count
docker inspect vtrc-api-nodejs | grep RestartCount

# 2. ดู OOMKilled
docker inspect vtrc-api-nodejs | grep OOMKilled

# 3. ดู memory limit
docker inspect vtrc-api-nodejs | grep -i memory

# 4. ดู memory usage ตลอดเวลา
docker stats --no-stream

สาเหตุที่เป็นไปได้ ​

  1. Memory limit ต่ำเกินไป → เพิ่มใน docker-compose.yml mem_limit
  2. Memory leak ใน Node → รัน --inspect และใช้ Chrome DevTools profile
  3. PDF generation ใช้ memory เยอะ → จำกัด concurrent PDF generation
  4. cron job ที่ประมวลผลข้อมูลจำนวนมาก → แบ่ง batch เล็กลง

แก้ชั่วคราว ​

bash
# เพิ่ม memory limit
docker-compose stop vtrc-api
# แก้ docker-compose.yml: mem_limit: 4g
docker-compose up -d vtrc-api

Scenario 9 — disk เต็ม ​

อาการ ​

service ค้าง, file upload ล้มเหลว, log ไม่เขียน

ขั้นตอนตรวจสอบ ​

bash
# 1. ดู disk usage
df -h

# 2. หา directory ที่ใช้ disk เยอะ
du -h --max-depth=2 /home/dev/vtrc-api/ | sort -hr | head -20

# 3. หาไฟล์ใหญ่
find /home/dev/vtrc-api/ -type f -size +100M -exec ls -lh {} \;

# 4. ดู docker disk usage
docker system df

สาเหตุที่เป็นไปได้ ​

  1. log ไม่ rotate → ลบ log เก่า ตั้ง logrotate
  2. PDF payslip สะสม → ลบไฟล์เก่ากว่า 30 วัน
  3. Docker image เก่า → docker image prune
  4. Docker volume ที่ไม่ใช้ → docker volume prune
  5. Upload file ที่ไม่ถูกอ้างถึง → ตรวจ storage/ directory

แก้ด่วน ​

bash
# ลบ log เก่ากว่า 30 วัน
find /home/dev/vtrc-api/api-logs/ -mtime +30 -delete
find /home/dev/vtrc-api/nginx-log/ -mtime +30 -delete

# ลบ PDF เก่า
find /home/dev/vtrc-api/api-storage/prs/ -mtime +30 -delete

# prune docker
docker system prune -a --volumes
# ระวัง — จะลบ image ที่ไม่ได้ใช้ทั้งหมด

Scenario 10 — SSL certificate หมดอายุ ​

อาการ ​

เบราว์เซอร์แสดง warning "Certificate not valid", API call ล้มเหลว

ขั้นตอนตรวจสอบ ​

bash
# 1. ตรวจ expiry date
echo | openssl s_client -servername vtrc.redcross.or.th -connect vtrc.redcross.or.th:443 2>/dev/null | openssl x509 -noout -dates

# 2. ตรวจ cert file
ls -la /home/dev/vtrc-api/cert/
openssl x509 -in /home/dev/vtrc-api/cert/vtrc.redcross.or.th.crt -noout -dates

สาเหตุที่เป็นไปได้ ​

  1. Cert หมดอายุ → ต่ออายุกับผู้ออกใบรับรอง
  2. Cert chain ไม่ครบ → ตรวจ intermediate cert
  3. Cert ไม่ตรงกับ domain → ตรวจ SAN ใน cert

แก้ ​

รายละเอียดเต็มอยู่ในบท 13.9

สรุป ​

ทุก scenario มีรูปแบบเดียวกัน:

  1. ตรวจสอบสถานะ service — docker ps, docker logs
  2. ดู log ที่เกี่ยวข้อง — api-logs/, nginx-log/, docker logs
  3. ทดสอบ reachability — curl, nc -zv, ping
  4. วิเคราะห์ pattern ใน log — grep error code, status code
  5. ลองแก้ ทีละขั้น — start เสมอด้วยสิ่งที่ไม่ทำลายข้อมูล

เมื่อแก้ไขแล้ว ให้บันทึก root cause และ prevention ไว้ใน postmortem (บท 13.11)