IT Capacity Planning คืออะไร? วางแผนทรัพยากร IT ให้เพียงพอโดยไม่สิ้นเปลือง 2026

IT Capacity Planning คืออะไร?

IT Capacity Planning คือกระบวนการวางแผนและจัดการทรัพยากร IT (CPU, Memory, Storage, Network, Cloud) ให้เพียงพอต่อความต้องการทั้งในปัจจุบันและอนาคต โดยไม่ Over-provision จนสิ้นเปลืองงบประมาณ หรือ Under-provision จน System ล่มเมื่อ Load เพิ่ม ถ้าเปรียบง่ายๆ Capacity Planning คือการ “ซื้อรองเท้าที่พอดีกับเท้า” — ไม่เล็กจนเจ็บ ไม่ใหญ่จนเดินลำบาก

หลายองค์กรมองข้าม Capacity Planning ว่าเป็นแค่ “ซื้อ Server เพิ่มเมื่อ Server เก่าเต็ม” แต่ Capacity Planning ที่ดีต้องเป็น Proactive ไม่ใช่ Reactive ต้องคาดการณ์ล่วงหน้าจาก Trend data ไม่ใช่รอจนเกิดปัญหาแล้วค่อยแก้ ต้องพิจารณาทั้ง Technical (Performance), Financial (Budget), และ Business (Growth plan) ไปพร้อมกัน

ทำไม Capacity Planning ถึงสำคัญ?

ป้องกัน Outage: System ที่ทรัพยากรเต็มจะทำงานช้าลงหรือล่ม เช่น Database server ที่ Disk เต็ม 100% จะหยุดรับ Write ทันที, Application server ที่ Memory เต็มจะ OOM Kill processes, Network bandwidth ที่เต็มจะทำให้ Latency พุ่งสูง การ Plan ล่วงหน้าป้องกันสถานการณ์เหล่านี้ได้

ควบคุมงบประมาณ: หลายองค์กร Over-provision ทรัพยากรเพราะกลัว System ล่ม ส่งผลให้เสียเงินค่า Hardware, Cloud, License ไปกับทรัพยากรที่ไม่ได้ใช้ จากการสำรวจพบว่าองค์กรทั่วไป Over-provision CPU 40-60% และ Memory 30-50%

รองรับ Business Growth: เมื่อธุรกิจเติบโต User เพิ่ม Transaction เพิ่ม ถ้าไม่วางแผน Capacity ไว้ล่วงหน้า อาจใช้เวลาหลายสัปดาห์ถึงหลายเดือนในการจัดซื้อ Hardware ใหม่ (Lead time) ทำให้ Business เสียโอกาส

Budget Justification: Capacity data ที่ชัดเจนช่วยให้ IT team สามารถ Justify งบประมาณกับผู้บริหารได้ “เราต้องการ Server เพิ่ม 3 เครื่องเพราะ CPU utilization เฉลี่ย 78% และจะถึง 90% ภายใน 6 เดือนตาม Growth trend” น่าเชื่อถือกว่า “เราต้องการ Server เพิ่มเพราะรู้สึกว่ามันช้า”

Capacity Planning Framework

กระบวนการ Capacity Planning ประกอบด้วย 5 ขั้นตอนหลัก:

ขั้นตอนที่ 1: Baseline — รู้สถานะปัจจุบัน

เก็บ Metrics ปัจจุบันของทรัพยากรทั้งหมด: CPU utilization (Average, Peak, P95), Memory usage (Used, Cached, Available), Disk space (Used, Free, Growth rate), Disk I/O (IOPS, Throughput, Latency), Network bandwidth (Utilization, Peak, Error rate) ต้องเก็บข้อมูลอย่างน้อย 30-90 วันเพื่อเห็น Pattern (เช่น Peak ทุกวันจันทร์เช้า, End-of-month batch jobs)

ขั้นตอนที่ 2: Demand Forecasting — คาดการณ์ความต้องการ

ใช้ Trend analysis จาก Historical data เพื่อคาดการณ์ว่าทรัพยากรจะเต็มเมื่อไหร่ วิธี Forecast:

# Linear Regression — วิธีง่ายที่สุด
# ใช้ Prometheus predict_linear function
# คาดการณ์ว่า Disk จะเต็มภายในกี่วัน

# PromQL: Disk เต็มภายในกี่ชั่วโมง
predict_linear(
  node_filesystem_avail_bytes{mountpoint="/"}[30d],
  3600 * 24 * 30  # คาดการณ์ 30 วันข้างหน้า
)

# Alert เมื่อ Disk จะเต็มภายใน 14 วัน
- alert: DiskWillFillIn14Days
  expr: |
    predict_linear(node_filesystem_avail_bytes[30d], 14*24*3600) < 0
  for: 1h
  labels:
    severity: warning
  annotations:
    summary: "Disk on {{ $labels.instance }} will fill within 14 days"

# Zabbix Trending — ใช้ Calculated item
# ดู Disk usage trend ย้อนหลัง 90 วัน แล้วคาดการณ์
# Zabbix > Host > Graphs > เลือก Disk usage graph
# เปิด "Show trend" จะเห็น Linear projection

ขั้นตอนที่ 3: Modeling — สร้างโมเดล

สร้าง Capacity model ที่คำนึงถึง: Business growth rate (เช่น User เพิ่ม 20% ต่อปี), Seasonal patterns (เช่น E-commerce peak ช่วง 11.11, 12.12), New projects ที่จะ Launch, Technology changes (เช่น Migrate จาก VM ไป Container)

ขั้นตอนที่ 4: Planning — วางแผน

กำหนด Capacity thresholds (เช่น เริ่ม Plan เมื่อ Utilization ถึง 70%, ต้อง Act เมื่อถึง 80%, Crisis เมื่อถึง 90%) กำหนด Lead time สำหรับ Procurement (Physical hardware 4-12 สัปดาห์, Cloud provisioning ทันที) วาง Timeline สำหรับ Upgrades

ขั้นตอนที่ 5: Review — ทบทวนสม่ำเสมอ

ทบทวน Capacity plan ทุก Quarter เทียบ Actual กับ Forecast ปรับ Model ตาม Reality

Server Capacity — CPU, RAM, Storage

CPU Capacity

CPU เป็นทรัพยากรที่ Monitor ง่ายที่สุดแต่ Interpret ยากที่สุด:

สิ่งที่ต้องระวัง: ดู Average อย่างเดียวไม่พอ ต้องดู P95/P99 ด้วย เช่น CPU average 50% แต่ P99 อาจถึง 95% (Spike ทุก 5 นาที) ต้องแยก User time vs System time vs IOWait เพราะ IOWait สูงหมายถึง Disk bottleneck ไม่ใช่ CPU ไม่พอ ต้อง Correlate กับ Application performance (Response time, Throughput) ไม่ใช่ดูแค่ CPU%

RAM Capacity

Memory เป็นทรัพยากรที่ถูก Over-provision บ่อยที่สุด:

# Linux Memory — ต้องเข้าใจ Free vs Available
$ free -h
              total        used        free      shared  buff/cache   available
Mem:           62Gi        45Gi       1.2Gi       1.5Gi        16Gi        15Gi

# "free" 1.2 GB ดูเหมือนน้อย แต่ "available" 15 GB
# เพราะ Linux ใช้ Memory ว่างเป็น buff/cache (ดีต่อ Performance)
# available = free + reclaimable cache (ใช้ได้จริง)

# ดังนั้น: ดู "available" ไม่ใช่ "free" ในการวาง Capacity plan
# OOM Risk เมื่อ available < 5% ของ total

Right-sizing Memory: ดู Application ที่ทำงานจริงว่าใช้ RSS (Resident Set Size) เท่าไหร่ บวก Buffer 20-30% สำหรับ OS, Kernel, Cache ถ้า Application ใช้ JVM (Java) ต้อง Size Heap (-Xmx) ให้เหมาะสม ถ้า Database ต้อง Size Buffer pool/Shared buffers ให้เพียงพอ

Storage Capacity

Storage ต้องวางแผนใน 3 มิติ:

Space อาจเหลือเยอะ แต่ IOPS อาจเต็ม (เช่น HDD ที่ 100-200 IOPS vs SSD ที่ 10,000-100,000 IOPS) ถ้า Database query ช้าแต่ CPU/Memory เหลือเยอะ อาจเป็นเพราะ Disk IOPS ไม่พอ

Network Bandwidth Capacity

Network capacity ต้องวางแผนทั้ง LAN, WAN และ Internet:

Network Growth Drivers: Video conferencing (Teams, Zoom) ใช้ 2-4 Mbps/user, Cloud migration (Traffic ย้ายจาก LAN ไป WAN/Internet), IoT devices (เพิ่ม Device จำนวนมาก), SaaS applications (Office 365, Salesforce, SAP)

Cloud Capacity — Reserved vs On-Demand

Cloud Capacity Planning แตกต่างจาก On-prem ตรงที่สามารถ Scale ได้ทันที แต่ต้อง Optimize cost:

Reserved vs On-Demand vs Spot

Cloud Right-sizing Strategy: ใช้ Reserved instances สำหรับ Baseline workload (24/7), ใช้ On-demand สำหรับ Peak/Burst, ใช้ Spot/Preemptible สำหรับ Non-critical batch jobs ทำให้ได้ Cost-effective capacity ที่ยืดหยุ่น

# AWS Cost Explorer — ดู Utilization
# 1. AWS Console → Cost Explorer → Rightsizing Recommendations
# 2. จะเห็น Instance ที่ Under-utilized พร้อมคำแนะนำ
# เช่น "m5.xlarge (4 vCPU, 16 GB) → m5.large (2 vCPU, 8 GB)"
# ประหยัด $120/เดือน

# Azure Advisor — Right-size VMs
# Azure Portal → Advisor → Cost recommendations
# "Resize VM-Web01 from Standard_D4_v3 to Standard_D2_v3"
# ประหยัด 50%

# GCP Recommender
# gcloud recommender recommendations list #   --recommender=google.compute.instance.MachineTypeRecommender #   --location=asia-southeast1-a

เครื่องมือ Capacity Planning

Zabbix Trending

Zabbix มี Trend data ที่เก็บค่า Min, Max, Avg ทุกชั่วโมง สามารถดูย้อนหลังได้หลายปี ใช้ Calculated items สร้าง Trend analysis ได้ ใช้ Graph ที่แสดง Trend line (linear projection) เพื่อคาดการณ์ว่าทรัพยากรจะเต็มเมื่อไหร่ Zabbix 7.0+ มี Forecasting function ในตัว

Prometheus predict_linear

Prometheus มี Function predict_linear() ที่ใช้ Linear regression คาดการณ์ค่าในอนาคต:

# คาดการณ์ Disk usage ใน 30 วันข้างหน้า
predict_linear(node_filesystem_avail_bytes[30d], 30*24*3600)

# Alert เมื่อ Memory จะเต็มใน 7 วัน
- alert: MemoryWillExhaust
  expr: predict_linear(node_memory_MemAvailable_bytes[7d], 7*24*3600) < 0
  for: 1h

# Grafana Dashboard — Capacity Planning
# Panel 1: Current utilization (gauge)
# Panel 2: 30-day trend (time series)
# Panel 3: Forecast (predict_linear)
# Panel 4: Days until full (stat panel)

VMware vROps (vRealize Operations / Aria Operations)

สำหรับ VMware environment, vROps เป็นเครื่องมือ Capacity Planning ที่ดีที่สุด: แสดง Capacity remaining (CPU, Memory, Storage) ของ Cluster, คาดการณ์ Time remaining ก่อน Capacity หมด, Reclamation recommendations (คืน Resources ที่ VM ใช้ไม่หมด), What-if analysis (ถ้าเพิ่ม VM 50 ตัว ต้อง Add Host กี่ตัว?), Cost analysis (ราคาต่อ VM)

Cloud Native Tools

AWS: CloudWatch Metrics + Forecast, Cost Explorer + Rightsizing, Compute Optimizer, Trusted Advisor

Azure: Azure Monitor + Advisor, Cost Management, VM Insights

GCP: Cloud Monitoring + Recommender, Active Assist, Billing Reports

Capacity Reporting Template

Capacity Report ที่ดีควรมีเนื้อหาดังนี้:

# Monthly Capacity Report — Template
# ============================================

## 1. Executive Summary
# - Overall capacity status: GREEN / YELLOW / RED
# - Key risks identified
# - Actions recommended

## 2. Server Capacity
# | Server/Cluster | CPU Avg | CPU P95 | RAM Used | Disk Used | Trend |
# |----------------|---------|---------|----------|-----------|-------|
# | Prod-Cluster-1 | 62%     | 88%     | 71%      | 68%       | ↑ 3%/month |
# | DB-Cluster     | 45%     | 72%     | 85%      | 78%       | ↑ 5%/month |
# | Dev-Cluster    | 22%     | 35%     | 40%      | 52%       | → stable |

## 3. Network Capacity
# | Link            | Avg BW  | Peak BW | Utilization | Trend |
# |-----------------|---------|---------|-------------|-------|
# | WAN-BKK-SG      | 450 Mbps| 850 Mbps| 85% peak    | ↑ 10%/month |
# | Internet-Main   | 2.1 Gbps| 4.5 Gbps| 45%         | ↑ 5%/month |

## 4. Storage Capacity
# | Storage System | Used  | Total | Utilization | Days Remaining |
# |---------------|-------|-------|-------------|----------------|
# | SAN-Prod      | 45 TB | 60 TB | 75%         | 120 days       |
# | NAS-Backup    | 82 TB | 100TB | 82%         | 60 days ⚠️     |

## 5. Cloud Capacity & Cost
# | Account/Sub | Monthly Spend | Reserved Coverage | Waste | Recommendation |
# |------------|---------------|-------------------|-------|---------------|
# | Prod-AWS   | $45,000       | 68%               | $3,200| Buy 10x RI    |
# | Dev-Azure  | $12,000       | 20%               | $5,500| Right-size VMs|

## 6. Forecasts & Recommendations
# - DB-Cluster RAM will reach 90% in 3 months → Plan RAM upgrade
# - WAN-BKK-SG peak utilization critical → Upgrade to 2 Gbps
# - NAS-Backup disk 82% → Add 20TB within 2 months
# - AWS Dev account waste → Right-size 15 VMs, save $4,000/month

Right-Sizing — หลีกเลี่ยง Over-provisioning

Over-provisioning เป็นปัญหาที่พบบ่อยมาก สาเหตุหลัก:

1. "Safety margin" ที่มากเกินไป: Developer request 16 GB RAM แต่ Application ใช้จริงแค่ 4 GB เพราะกลัว OOM จึงขอเผื่อ 4 เท่า

2. Copy-paste specifications: ใช้ Spec ของ Production สำหรับ Dev/Staging ทั้งที่ Load ต่ำกว่ามาก

3. Peak-based provisioning: ซื้อ Hardware สำหรับ Peak traffic ที่เกิดแค่ 5% ของเวลาทั้งหมด

วิธีแก้:

ใช้ Monitoring data ในการ Size ไม่ใช่ "ความรู้สึก" ดู P95 utilization ย้อนหลัง 90 วัน ใช้เป็น Baseline แล้วบวก 30% Buffer กำหนด Standard sizes (T-shirt sizing) แทนที่จะให้ทุกคนเลือก Spec เอง เช่น Small (2 vCPU, 4 GB), Medium (4 vCPU, 8 GB), Large (8 vCPU, 16 GB) ทำ Regular right-sizing review ทุก Quarter ถ้า VM ใช้ CPU ไม่เกิน 20% ติดต่อกัน 90 วัน ลดขนาดลง

Peak vs Average Planning

คำถามสำคัญใน Capacity planning: ควร Plan สำหรับ Average หรือ Peak?

คำตอบ: ขึ้นอยู่กับ Workload type

สำหรับ Cloud environment สามารถ Plan สำหรับ Average แล้วใช้ Auto-scaling สำหรับ Peak ได้ เช่น Reserved instances สำหรับ Baseline (Average), On-demand Auto-scale สำหรับ Peak, ทำให้ Cost-effective ที่สุด

Growth Projections

การคาดการณ์ Growth ต้องพิจารณาจาก:

Historical growth rate: ดูย้อนหลัง 6-12 เดือน เช่น Disk growth 5% ต่อเดือน, User growth 15% ต่อปี, Transaction volume 20% ต่อปี

Business plan: คุยกับ Business team ว่ามีแผนอะไร เช่น Launch product ใหม่ (User อาจเพิ่ม 50%), เปิดสาขาใหม่ 10 แห่ง, Migration จาก Legacy → Modern app, M&A (Merge กับบริษัทอื่น)

Technology changes: เช่น Migrate จาก On-prem ไป Cloud (ลด On-prem capacity, เพิ่ม Cloud), Containerization (ใช้ Resources efficient กว่า VM 20-30%), AI/ML workloads (ต้องการ GPU, High memory)

# Growth Projection Formula
# Current capacity: 100 units
# Monthly growth rate: 5%
# Target utilization: 80%
# Current utilization: 60%

# Headroom = (Target - Current) / Growth rate
# Headroom = (80% - 60%) / 5% = 4 months

# จะถึง 80% threshold ใน 4 เดือน
# ต้องเริ่ม Procurement process ตอนนี้ (ถ้า Lead time > 4 เดือน)

# Compound growth:
# Month 0: 60%
# Month 1: 60% × 1.05 = 63%
# Month 2: 63% × 1.05 = 66.2%
# Month 3: 66.2% × 1.05 = 69.5%
# Month 4: 69.5% × 1.05 = 73%
# Month 5: 73% × 1.05 = 76.6%
# Month 6: 76.6% × 1.05 = 80.4% ← ถึง threshold!

Budget Justification ด้วย Capacity Data

Capacity data ช่วย Justify budget ได้อย่างมีประสิทธิภาพ:

แบบไม่มี Data (ไม่น่าเชื่อถือ): "เราต้องซื้อ Server ใหม่ เพราะ Server เก่ามันช้า" — ผู้บริหารจะถาม "ช้าแค่ไหน? จำเป็นจริงหรือ? Fix Software แทนได้ไหม?"

แบบมี Capacity Data (น่าเชื่อถือ): "Production Database server มี CPU utilization เฉลี่ย 78% (P95 = 95%) โดยเพิ่มขึ้น 5% ต่อเดือน คาดว่าจะถึง 100% ภายใน 4 เดือน ซึ่งจะทำให้ Query response time เพิ่มจาก 50ms เป็น 500ms+ กระทบ User 50,000 คน Revenue ที่อาจสูญเสียประมาณ 2 ล้านบาทต่อเดือน เสนอ Upgrade CPU จาก 16 cores เป็น 32 cores ราคา 350,000 บาท ROI คืนทุนภายใน 1 เดือน"

การมี Data ที่ชัดเจนทำให้ IT team สามารถ ขอ Budget ได้ล่วงหน้า (ไม่ใช่ Emergency purchase), เปรียบเทียบ Options ได้ (Upgrade vs Add server vs Migrate to Cloud), แสดง ROI ที่ชัดเจน, สร้าง Trust กับผู้บริหาร

Capacity Planning สำหรับ Hybrid Cloud

Hybrid Cloud (On-prem + Cloud) ทำให้ Capacity planning ซับซ้อนขึ้น เพราะต้องพิจารณาทั้งสองฝั่ง:

On-prem Capacity: Hardware lifecycle (3-5 ปี), Lead time สำหรับ Procurement (4-12 สัปดาห์), Depreciation cost, DC power/cooling capacity

Cloud Capacity: Reserved instance coverage, Auto-scaling policies, Spending limits/Budgets, Region/AZ capacity (บางกรณี Cloud ก็หมด Capacity)

Hybrid Strategy:

1. Baseline on-prem, Burst to cloud: ใช้ On-prem สำหรับ Steady-state workload, Burst ไป Cloud เมื่อ Peak เหมาะเมื่อ On-prem มี Existing investment

2. Cloud-first, On-prem for compliance: ใช้ Cloud เป็นหลัก, On-prem สำหรับ Data ที่ต้อง Comply กับกฎหมาย (เช่น ข้อมูลส่วนบุคคลตาม PDPA)

3. Multi-cloud: กระจาย Workload ข้าม Cloud providers เพื่อ Avoid vendor lock-in ต้อง Plan capacity ทั้ง AWS + Azure + GCP

Common Capacity Planning Mistakes

Capacity Planning Checklist

ใช้ Checklist นี้สำหรับ Monthly/Quarterly capacity review:

Monitoring & Data: ทุก Critical system มี Monitoring ครบ (CPU, RAM, Disk, Network), Retention data อย่างน้อย 90 วัน, Alert ตั้งค่าสำหรับ Capacity threshold

Analysis: ดู Trend ของทุก Resource (ขึ้น/ลง/คงที่), ระบุ Resources ที่จะถึง Threshold ภายใน 6 เดือน, ระบุ Resources ที่ Over-provisioned (Under-utilized)

Planning: Growth projection ตรงกับ Business plan, Lead time สำหรับ Procurement ถูกคำนวณ, Budget request ถูก Submit ล่วงหน้า

Optimization: Right-sizing recommendations ถูก Implement, Reserved instance coverage ที่เหมาะสม (Cloud), Deprecated/Unused resources ถูก Decommission

สรุป

IT Capacity Planning เป็นกระบวนการที่สำคัญแต่มักถูกมองข้าม การวางแผน Capacity ที่ดีช่วยป้องกัน Outage จาก Resource exhaustion, ควบคุมงบประมาณ IT โดย Right-size ทรัพยากร, รองรับ Business growth อย่างมั่นใจ, Justify budget ด้วยข้อมูลที่ชัดเจน

เริ่มต้นง่ายๆ ด้วยการ Monitor ทุกทรัพยากรที่สำคัญ ใช้ Prometheus/Zabbix เก็บ Trend data ทำ Monthly capacity report แม้จะง่ายๆ แค่ Spreadsheet ก็ยังดี แล้วค่อยๆ พัฒนาให้ซับซ้อนขึ้นเมื่อ Organization maturity เพิ่มขึ้น สิ่งสำคัญที่สุดคือต้อง Proactive ไม่ใช่ Reactive อย่ารอจน System ล่มแล้วค่อยคิดเรื่อง Capacity