IT Manager ของบริษัทผลิตภัณฑ์เสริมอาหารแห่งหนึ่งในนนทบุรีเล่าให้ฟังว่า เมื่อ Server หลักล่มกลางดึก เขาใช้เวลากว่า 2 ชั่วโมงแค่หาว่า "ระบบอะไรพังบ้าง" เพราะไม่มีข้อมูลว่าเซิร์ฟเวอร์ตัวนั้นรันแอปพลิเคชันอะไรบ้าง เชื่อมต่อกับฐานข้อมูลตัวใด และทีมไหนใช้งานอยู่ ถ้ามี CMDB ที่อัปเดตอยู่เสมอ เขาจะรู้คำตอบทั้งหมดในเวลาไม่ถึง 5 นาที
CMDB คืออะไร?
CMDB (Configuration Management Database) คือฐานข้อมูลกลางที่เก็บข้อมูลของ IT Asset ทุกตัวในองค์กร (เรียกว่า Configuration Item หรือ CI) พร้อมกับ ความสัมพันธ์ ระหว่าง CI เหล่านั้น
CMDB ต่างจาก Asset Register ทั่วไปตรงที่ Asset Register บอกแค่ว่า "มีอุปกรณ์อะไรบ้าง" แต่ CMDB บอกว่า "อุปกรณ์แต่ละตัวเชื่อมต่อกับอะไร และถ้าตัวนี้พัง จะกระทบอะไรบ้าง"
ตัวอย่างง่ายๆ: CMDB รู้ว่า Server A รัน Application B ซึ่ง Connect กับ Database C และมีพนักงาน 45 คนในฝ่ายขายที่ใช้งาน Application B ทุกวัน — ข้อมูลนี้เรียกว่า "Impact Analysis" และมีค่ามากในตอนเกิดปัญหาหรือก่อนทำ Change
Configuration Item (CI) คืออะไร?
CI คือทุกอย่างที่ IT ต้องบริหารจัดการ ในองค์กรขนาด SME CI ทั่วไปได้แก่:
ความสัมพันธ์ใน CMDB ทำงานอย่างไร?
หัวใจของ CMDB คือ "Relationship" ระหว่าง CI ตัวอย่างความสัมพันธ์ที่พบบ่อย:
- depends_on — Application X ขึ้นอยู่กับ Database Y (ถ้า Y พัง X ก็พังด้วย)
- runs_on — Application X รันบน Server Z
- connected_to — PC A เชื่อมต่อกับ Switch B ผ่าน Port 12
- hosted_on — Website C โฮสอยู่บน Cloud Instance D
- part_of — RAM Module E เป็นส่วนหนึ่งของ Server F
เมื่อมีความสัมพันธ์เหล่านี้ครบ ระบบสามารถทำ Impact Analysis ได้อัตโนมัติ — ก่อนทำ Change ใดๆ ระบบจะบอกว่า "ถ้าคุณ Restart Server นี้ จะกระทบ Application 3 ตัว และผู้ใช้ 120 คนในช่วงเวลานั้น"
CMDB vs Asset Register ต่างกันอย่างไร?
| ด้าน | Asset Register | CMDB |
|---|---|---|
| เก็บข้อมูลอะไร | รายการอุปกรณ์ + คุณสมบัติ | อุปกรณ์ + ความสัมพันธ์ระหว่างกัน |
| ใช้ทำอะไร | ตรวจสอบทรัพย์สิน, ต่ออายุ warranty | Impact analysis, Change planning, Incident resolution |
| ตอบคำถาม | "มีอะไรบ้าง?" | "ถ้าตัวนี้พัง กระทบอะไรบ้าง?" |
| ความซับซ้อน | ต่ำ — list ธรรมดา | สูงกว่า — ต้องระบุ relationship |
| เหมาะกับ | ทุกองค์กร | องค์กรที่มี IT infrastructure ซับซ้อน |
ประโยชน์หลัก 4 ข้อของ CMDB
1. Impact Analysis ก่อนทำ Change
ก่อน Update Server หรือเปลี่ยน Firewall Rule ทีม IT สามารถดูใน CMDB ว่าจะกระทบระบบอะไรบ้าง และแจ้ง user ที่เกี่ยวข้องล่วงหน้าได้อย่างแม่นยำ แทนที่จะต้องโทรถามทีมละ ถามแต่ละคน
2. Incident Resolution เร็วขึ้น
เมื่อเกิดปัญหา ทีม IT รู้ทันทีว่า CI ตัวไหนเกี่ยวข้อง ไม่ต้องเสียเวลา 2 ชั่วโมงหาว่า "ระบบอะไรพัง" เหมือนตัวอย่างในตอนต้น
3. Root Cause Analysis ถูกต้องขึ้น
เมื่อทำ RCA มีข้อมูลความสัมพันธ์ระหว่าง CI ทำให้หา root cause ได้เร็วและแม่นยำกว่าการ guess
4. Change Management มีข้อมูลประกอบ
การเขียน RFC (Request for Change) มีคุณภาพดีขึ้นเพราะรู้ว่า Change นั้นกระทบ CI อะไรบ้าง ทำให้ CAB approval process รวดเร็วและมั่นใจขึ้น
CMDB กับ SME: หลายคนคิดว่า CMDB เป็นเรื่องขององค์กรใหญ่เท่านั้น แต่จริงๆ แล้วแม้แต่องค์กรที่มี Server เพียง 3-5 ตัว การรู้ว่าแต่ละตัวรันอะไรและเชื่อมต่อกับอะไรก็ช่วยลด downtime ได้มาก โดยเฉพาะเมื่อทีม IT มีแค่ 1-2 คน ข้อมูลเหล่านี้ต้องไม่อยู่แค่ในหัวของ IT Manager คนเดียว
เริ่มทำ CMDB ง่ายๆ สำหรับ SME
ไม่ต้องเริ่มด้วย tool ราคาแพง CMDB ที่ดีเริ่มต้นจากข้อมูลที่ถูกต้องและอัปเดตสม่ำเสมอ:
- เริ่มจาก Asset Register ก่อน — บันทึก IT Asset ทุกตัวพร้อม spec และ location (ดูวิธีทำ IT Asset Audit)
- ระบุ CI ที่สำคัญที่สุด — เลือก Server, Application หลัก และ Network Core ที่ถ้าพังแล้วกระทบทั้งองค์กร
- วาด Relationship Map — แม้แค่ใน Draw.io หรือ Whiteboard ก็มีประโยชน์มากกว่าไม่มีเลย
- บันทึกใน ITSM System — ระบบที่มี CMDB module จะช่วย maintain ความสัมพันธ์ได้ง่ายกว่า spreadsheet
- อัปเดตทุก Change — กฎสำคัญที่สุด: ทุกครั้งที่เพิ่ม/ลบ/เปลี่ยน IT Asset ต้องอัปเดต CMDB ด้วย
CMDB ใน 1StopService ทำงานอย่างไร?
1StopService รวม CMDB Relationship Map ไว้ใน Asset Management module โดย IT Manager สามารถระบุความสัมพันธ์ระหว่าง Asset เช่น "Server A runs_on Rack B" หรือ "Application X depends_on Database Y" แล้วดู Impact Analysis ได้ทันทีว่าถ้า Asset ใด Asset หนึ่งมีปัญหา จะกระทบ CI อะไรบ้างผ่าน BFS traversal
เมื่อเปิด Change Request ระบบจะแสดง linked assets และ impact scope ให้อัตโนมัติ ช่วยให้ทีม CAB เห็นภาพรวมก่อน approve
สรุป: CMDB ไม่ใช่แค่ข้อมูล แต่คือ "แผนที่" ของ IT
CMDB ที่ดีคือแผนที่ที่บอกว่า IT infrastructure ขององค์กรประกอบด้วยอะไร เชื่อมต่อกันอย่างไร และถ้าส่วนไหนมีปัญหา จะกระทบอะไรบ้าง ข้อมูลเหล่านี้มีค่ามากทั้งในยามปกติ (วางแผน Change) และยามฉุกเฉิน (แก้ Incident)
สำหรับ SME ที่มีทีม IT เล็ก CMDB ที่ง่ายแต่อัปเดตสม่ำเสมอดีกว่า CMDB ที่ซับซ้อนแต่ไม่มีคนดูแลเสมอ เริ่มจาก CI ที่สำคัญที่สุดก่อน แล้วค่อยขยายเพิ่มเมื่อทีม IT มีความพร้อมขึ้น