VTRC Knowledge Manual (V2)

ธีม

0.1 · VTRC คืออะไร ​

นิยามสั้น ​

VTRC คือระบบสารสนเทศทรัพยากรบุคคลและสวัสดิการของสภากาชาดแห่งประเทศไทย

ชื่อ "VTRC" มาจากชื่อโดเมนที่ผู้ใช้เข้า คือ vtrc.redcross.or.th — ตัวอักษร V ไม่มีเอกสารใน repo บอกชัดว่าย่อมาจากอะไร (น่าจะเป็น internal codename ตั้งแต่ต้นโปรเจกต์) ส่วน TRC ย่อมาจาก Thai Red Cross

พูดอีกแบบคือ มันคือเว็บแอปที่พนักงานกาชาดใช้ดูสลิปเงินเดือน ขอลา เบิกค่ารักษาพยาบาล และทำสิ่งอื่นๆ ที่เกี่ยวกับ HR ในชีวิตประจำวัน — และมีอีกเว็บแอปหนึ่งที่ HR ใช้อนุมัติคำขอเหล่านั้น

เจ้าของและผู้ดูแล ​

ระบบมีหลายฝ่ายเกี่ยวข้อง ไม่ใช่แค่ "ใครเขียนโค้ด"

ฝ่ายบทบาท
สภากาชาดแห่งประเทศไทยเจ้าของระบบ (product owner) — องค์กรการกุศลที่มีพนักงานหลายพันคนทั่วประเทศ
ฝ่าย HR ของสภากาชาดpower user ฝั่ง backoffice — คนที่ใช้ระบบทุกวัน และเป็นคนที่รู้ดีที่สุดว่าฟีเจอร์ไหน "ทำงานจริง" หรือ "ใช้บ้าง"
ทีมพัฒนาเดิม (i3 Thailand)vendor ที่เขียนโค้ดและดูแล deployment
พนักงานสภากาชาดทุกคนend-user ฝั่งเว็บและมือถือ

ถ้าเจอ feature ที่ดูแปลกหรือ "น่าจะตาย" อย่าเพิ่งสรุปว่าเป็น bug — อาจเป็นการตัดสินใจของ HR ที่ไม่ได้ document ไว้ ให้ถามฝ่าย HR ก่อน

ใครใช้ระบบบ้าง ​

มีสองกลุ่มหลักที่ใช้งานจริงทุกวัน กลุ่มอื่นๆ มีแต่ไม่ได้ใช้บ่อย

กลุ่มที่ 1 — พนักงาน (end-user) ​

เข้าผ่านสองช่องทาง

  • เว็บ vtrc-web ที่ https://vtrc.redcross.or.th/
  • มือถือ (มี APP_TYPE: MOBILE ในระบบ — ไม่ได้อยู่ใน workspace นี้)

สิ่งที่ทำบ่อยในแต่ละวัน เรียงตามความถี่จากข้อมูลเชิงประจักษ์ (ไม่ใช่การวัดจริง แค่ประเมินจาก typeDef ที่ใช้บ่อย)

  1. ดูสลิปเงินเดือนและดาวน์โหลด PDF
  2. ดูข้อมูลภาษี (รายปี ราย 6 เดือน หลายปี)
  3. ขอลา — มี 12 ประเภท ลาป่วย ลากิจ ลาพักผ่อน ลาคลอด ฯลฯ
  4. เบิกสวัสดิการค่ารักษาพยาบาล (ตัวเอง คู่สมรส บุตร บิดามารดา)
  5. ดูเวลาเข้า-ออกงาน
  6. อ่านข่าวและเอกสารนโยบาย
  7. ดูข้อมูลกองทุนสงเคราะห์
  8. แจ้ง HR เรื่องที่ติดขัด

กลุ่มที่ 2 — HR / เจ้าหน้าที่ (backoffice) ​

เข้าผ่านเว็บ vtrc-rc-backoffice ที่ https://vtrcbackoffice.redcross.or.th/

สิ่งที่ทำบ่อย

  1. อนุมัติคำขอลา (อาจมีหลาย level ตาม org)
  2. อนุมัติคำขอเบิกสวัสดิการ
  3. export ข้อมูลเพื่อส่งธนาคาร (KBANK K-Cash)
  4. จัดการ master data (โรงพยาบาล โรค สาขาธนาคาร ผู้อนุมัติ)
  5. ดูรายงานและสถิติ
  6. จัดการผู้ใช้และสิทธิ์
  7. ดูแล subsystems อื่นๆ (PMS, Recruitment, Meeting, WorkForce) — แต่ละอันมี axios config แยกใน vtrc-rc-backoffice/src/config/

ทำไมระบบถึงเป็นแบบที่เห็น ​

ถ้าเปิดไฟล์ package.json ของแต่ละ repo แล้วเจอ dependency ที่ดูเก่ามาก (Node 12, Apollo v2, React 16) อย่าเพิ่งคิดว่าทีมเลือกผิด — มันคือ snapshot ของเทคโนโลยีปี 2019–2020 ตอนที่เริ่มเขียน

VTRC เขียนโดยทีมเดียวกับที่ดูแลระบบ HR ของจุฬาลงกรณ์มหาวิทยาลัย (CU) ดังนั้นหลายอย่างจึง "สืบทอด" มาจากระบบ CU โดยตรง

  • การ auth ผ่าน LDAP/AD ของจุฬา (เห็นได้จาก cu-central-api ที่ยัง bind LDAP อยู่)
  • การใช้ MSSQL เป็น HR master data — เรียกว่าระบบ HRMI (HR Management Information)
  • โครงสร้าง GraphQL schema ที่ mirror กันระหว่าง vtrc-api และ cu-central-api
  • device key registry ที่มีทั้งของ VTRC เองและของ CU (ดูใน vtrc-api/api/src/config.js:41-148)

ต่อมาทีมเริ่ม "modernize" ทีละส่วน — เลยเกิด centralize-api (NestJS + TypeScript + TypeORM) เป็น modernization template / reference ที่อ่าน MSSQL HR data ผ่าน REST ของตัวเอง

สำคัญ: ใน production path ที่ vtrc-api ใช้จริงวันนี้ ไม่ได้ เรียก NestJS centralize-api — โฟลเดอร์ vtrc-api/api/src/centralize/ ส่ง GraphQL ไปที่ cu-central-api ผ่าน END_POINT_CENTRALIZE / END_POINT_CENTRALIZE_AUTH แทน (ดู centralize/controllers/graphql.js และ centralize/controllers/auth.js)

ผลคือระบบมี 5 repos ที่ทำหน้าที่ต่างกัน — รายละเอียดใน บท 0.2

สิ่งที่ต้องรู้ตั้งแต่วันแรก ​

ระบบนี้มี technical debt สะสมมาก และทีมกำลังวางแผน modernize ไป Go (backend) + Nuxt 3 (frontend) แต่ยังอยู่ในช่วงต้น

รายการ debt เต็มๆ อยู่ใน Volume 15 ส่วนที่คนใหม่ต้องรู้ตั้งแต่ต้นมี 3 อย่าง

  1. runtime เก่า — vtrc-api และ cu-central-api รันบน Node 12 (EOL ตั้งแต่เม.ย. 2022) แปลว่า patch ความปลอดภัยไม่ได้รับการอัปเดตแล้ว
  2. มี vulnerability ที่ยังไม่ได้แก้ — เช่น execSync(qpdf --encrypt ${password} ...) ใน routes.js:73 ที่เป็น command injection vector (ดู audit/05-tech-debt-register.md SEC-1) แก้ทุกอย่างที่แตะเส้นทางนี้ด้วยความระมัดระวัง
  3. มีไฟล์ _bk, _bak, _pentest, _metting กระจัดกระจาย — ทีมไม่ได้ลบไฟล์เก่า แค่ copy เป็น _bk แล้วลืม ถ้าเจอไฟล์ที่ชื่อมี suffix พวกนี้ ให้ถือว่าเป็น dead code และไม่ต้องแก้ ตามกฎใน .cursor/rules/workspace-structure.mdc

ทำไมต้องมีคู่มือเล่มนี้ ในเมื่อมี audit อยู่แล้ว ​

เอกสาร audit ใน docs/audit/ เขียนดีและละเอียด แต่เป็นเอกสาร ตรวจสอบ — สมมติว่าผู้อ่านเข้าใจ codebase แล้ว และอยากรู้ว่าผิดตรงไหน

คู่มือเล่มนี้เป็นเอกสาร เริ่มงาน — สมมติว่าผู้อ่านไม่เคยเห็นระบบนี้เลย และต้องเริ่มจากศูนย์

ทั้งสองชุดอ้างอิง evidence เดียวกัน (file:line เดียวกัน) แต่ reframe คนละแบบ ถ้าเจอ claim ในคู่มือเล่มนี้ที่ดูแปลก ให้ไป cross-check กับ audit ก่อนเชื่อ

ขั้นตอนถัดไป ​

ไป บท 0.2 ภาพรวมระบบใน 1 หน้า →