CSI203 สถาปัตยกรรมดิจิทัลและระบบปฏิบัติการ

ครั้งที่ 13: การบริหารจัดการปัญหา | Workshop ครบวงจร (Demo #1 Performance + Demo #2 Security)
ภาควิชาวิทยาการคอมพิวเตอร์ | Sripatum University
บทนำ วัตถุประสงค์ กระบวนการจัดการปัญหา โครงสร้างนำเสนอ 📁 Demo #1 📡 Demo #2 ทบทวน

📖 ทำไมต้องการการบริหารจัดการปัญหา

หัวข้อในสัปดาห์นี้ของรายวิชา CSI203 สถาปัตยกรรมดิจิทัลและระบบปฏิบัติการ คือ ‘การบริหารจัดการปัญหา’ (Problem Management) ในการพัฒนาระบบหรือการดูแลโครงสร้างพื้นฐานดิจิทัล สิ่งหนึ่งที่หลีกเลี่ยงไม่ได้คือ ‘ปัญหา’ ไม่ว่าจะเป็นระบบทำงานช้า ผู้ใช้ไม่สามารถเข้าถึงข้อมูลได้ หรือแม้กระทั่งช่องโหว่ด้านความปลอดภัยที่อาจถูกโจมตีได้ การแก้ปัญหาแบบ ‘ปุบปับ’ หรือแก้ที่ปลายเหตุ อาจทำให้ปัญหาเดิมกลับมาซ้ำอีกครั้งโดยไม่รู้ตัว ดังนั้น ในภาคเรียนนี้ เราจะมาเรียนรู้ กระบวนการจัดการปัญหาอย่างเป็นระบบ ตั้งแต่การตรวจจับ การวิเคราะห์หาสาเหตุที่แท้จริงด้วยเทคนิคต่างๆ เช่น 5 Whys หรือ Root Cause Analysis (RCA) ไปจนถึงการแก้ไขและป้องกันในระยะยาว นอกจากนั้น ในส่วนของ Workshop วันนี้ เราจะได้เห็นการประยุกต์ใช้จริงผ่าน Demo 2 สถานการณ์ ได้แก่ ปัญหาด้านประสิทธิภาพ (Performance) ของระบบไฟล์ และปัญหาด้านความปลอดภัย (Security) ของการสื่อสารแบบ Real-time พร้อมทั้งฝึกการนำเสนอโปรเจกต์ตามโครงสร้างมาตรฐานอีกด้วย

📚 วัตถุประสงค์การเรียนรู้

📖 ภาคทฤษฎี

  • เข้าใจกระบวนการจัดการปัญหา (Incident Management)
  • พัฒนาทักษะการวิเคราะห์ด้วยเทคนิค 5 Whys และ Root Cause Analysis (RCA)
  • เรียนรู้เครื่องมือวิเคราะห์ปัญหา: Log Files, Performance Monitor, Network Analyzer, Wireshark
  • ศึกษาวิธีการป้องกันปัญหาทั้งด้าน Performance และความปลอดภัยในการสื่อสาร

💻 ภาคปฏิบัติ (2 Workshop Demos)

  • Demo #1: การจัดการปัญหา Performance - ระบบไฟล์ทำงานช้า
  • Demo #2: Real-time Dashboard + สถานะการเข้ารหัส (Encryption Status Monitor)
  • ฝึกนำเสนอตามโครงสร้างแผนภาพและรับ Feedback
  • เรียนรู้การตรวจจับปัญหาความปลอดภัยแบบ Real-time
🎯 สรุป: การบริหารจัดการปัญหาที่มีประสิทธิภาพ = ตรวจจับไว + วิเคราะห์แม่นยำ + แก้ไขตรงจุด + ป้องกันระยะยาว ครอบคลุมทั้งด้าน Performance และ Security

🔄 กระบวนการจัดการปัญหา (Incident Management Process)

Incident Management คือกระบวนการจัดการกับเหตุการณ์ผิดปกติที่เกิดขึ้นในระบบไอที โดยมีเป้าหมายเพื่อ ฟื้นฟูระบบให้กลับมาทำงานตามปกติได้เร็วที่สุด และ ลดผลกระทบต่อการดำเนินธุรกิจ ให้มากที่สุด

🔍

1. Detection
(ตรวจจับ)

การรับรู้ว่ามีเหตุการณ์ผิดปกติ ผ่านการแจ้งผู้ใช้, Alert จากระบบ Monitoring, หรือการตรวจสอบ Log

📊

2. Analysis
(วิเคราะห์)

ระบุสาเหตุและประเมินผลกระทบ จำแนกประเภทปัญหา ระดับความรุนแรง และวิเคราะห์หาสาเหตุเบื้องต้น

🛠️

3. Resolution
(แก้ไข)

ดำเนินการแก้ไขปัญหา ทั้งแบบชั่วคราว (Workaround) และแบบถาวร (Permanent Fix) หรือส่งต่อทีมที่เกี่ยวข้อง

✅

4. Closure
(ปิดงาน)

ยืนยันการแก้ไข บันทึกข้อมูล สรุปบทเรียน และปรับปรุงกระบวนการเพื่อป้องกันการเกิดซ้ำ

🔍 Detection
ตรวจจับ
📊 Analysis
วิเคราะห์
🛠️ Resolution
แก้ไข
✅ Closure
ปิดงาน

📊 ตารางสรุปกระบวนการจัดการปัญหา

ขั้นตอนกิจกรรมหลักเป้าหมายระยะเวลาโดยประมาณ
Detectionตรวจจับ, รับแจ้ง, Alertรู้ว่ามีปัญหาโดยเร็วภายใน 5-15 นาที
Analysisวิเคราะห์สาเหตุ, ประเมินผลกระทบเข้าใจปัญหาและขอบเขต15-60 นาที
Resolutionแก้ไขชั่วคราว/ถาวร, ส่งต่อทีมระบบกลับมาทำงานปกติตามความซับซ้อน
Closureยืนยัน, บันทึก, สรุปบทเรียนป้องกันการเกิดซ้ำ30-60 นาที
💡 เคล็ดลับสำคัญ: การบันทึกทุกเหตุการณ์ด้วยระบบ Ticket System (เช่น Jira, ServiceNow) การจัดลำดับความสำคัญ (Critical > High > Medium > Low) และการสื่อสารกับผู้ใช้อย่างสม่ำเสมอ เป็นหัวใจสำคัญของ Incident Management ที่มีประสิทธิภาพ

🔗 ความสัมพันธ์ระหว่าง Incident Management และ Problem Management

Incident ManagementProblem Management
แก้ไขเหตุการณ์เฉพาะหน้าวิเคราะห์หาสาเหตุที่แท้จริง
ฟื้นฟูระบบให้เร็วที่สุดป้องกันไม่ให้เกิดซ้ำ
ตอบคำถาม "อะไรเกิดขึ้น"ตอบคำถาม "ทำไมถึงเกิดขึ้น"
มุ่งเน้นระยะสั้นมุ่งเน้นระยะยาว

🎯 โครงสร้างการนำเสนอโปรเจกต์ (Presentation Flow)

🌟
Introduction
ที่มา แนวคิด ความเป็นมา
2-3 นาที
▼
❓
Problem Statement
ปัญหาที่โปรเจกต์ต้องการแก้ไข
2-3 นาที
▼
💡
Solution
วิธีการแก้ปัญหา / สถาปัตยกรรม
3-4 นาที
▼
✨
Features
ฟีเจอร์หลักของระบบ
🎁
Benefits
ประโยชน์ที่ผู้ใช้ได้รับ
▼
⚡
Challenges & Solutions
ปัญหาที่พบ + วิธีการแก้ไข
3-4 นาที
▼
🎬
Demo
การสาธิตการทำงานจริง (2 Demos)
5-7 นาที
▼
📌
Conclusion
สรุปผล + แผนงานต่อ
2-3 นาที
🕐 รวมทั้งหมด: 15-20 นาที
🎤 เทคนิค: เน้น Demo ให้ชัดเจน
💬 Q&A: เตรียมตอบคำถาม 5 นาที

📁 Demo #1: การจัดการปัญหา Performance Performance Tuning

⚠️ ระบบบริหารจัดการไฟล์ทำงานช้า CRITICAL ISSUE

เมื่อมีผู้ใช้งานพร้อมกันมากกว่า 50 คน ส่งผลกระทบต่อประสิทธิภาพการทำงานขององค์กร

⏱️
> 8 วินาที
Response Time
💻
95%
CPU Usage
💾
สูงผิดปกติ
Disk I/O
🔍 การวิเคราะห์ด้วยเครื่องมือ

📄 Log Files

พบ Query แบบ Full Table Scan บนตาราง file_metadata ทำให้ฐานข้อมูลทำงานหนัก

📊 Performance Monitor

Disk Queue Length สูงผิดปกติ เนื่องจากการอ่านไฟล์ซ้ำซ้อนโดยไม่มี Cache

🗄️ Database Profiler

พบ Slow Query จำนวนมากที่ไม่มี Index ส่งผลให้การค้นหาช้าลง

🌐 Network Analyzer

มีการเรียก API เดิมซ้ำโดยไม่มี Cache ทำให้เกิดการโหลดข้อมูลซ้ำซ้อน

✅ แนวทางแก้ไข (Solutions)
🗂️ เพิ่ม Index
เพิ่ม Index บนคอลัมน์ที่ใช้ค้นหาบ่อย (user_id, created_at, file_type) เพื่อเพิ่มความเร็วในการค้นหา
⚡ Redis Caching
ใช้ Redis Caching สำหรับ Metadata ที่เรียกใช้ซ้ำ ลดการเข้าถึงฐานข้อมูลลงได้ถึง 70%
📄 Pagination & Lazy Loading
ปรับปรุง Pagination และ Lazy Loading สำหรับรายการไฟล์ ลดการโหลดข้อมูลครั้งละมากๆ
🌍 CDN Integration
เพิ่ม CDN สำหรับไฟล์สาธารณะ ลดภาระการทำงานของเซิร์ฟเวอร์ต้นทาง
🔌 Connection Pool
ปรับ Connection Pool และเพิ่ม Async Processing เพื่อรองรับการเชื่อมต่อพร้อมกันมากขึ้น

📈 ผลลัพธ์หลังการแก้ไข

↓ 82%
Response Time
↓ 60%
CPU Usage
↑ 4x
รองรับผู้ใช้พร้อมกัน
🔎 เทคนิค 5 Whys - การวิเคราะห์สาเหตุที่แท้จริง
1
Why? ฐานข้อมูลมี query ช้า → เพราะไม่มี Index บนตาราง file_metadata
2
Why? ไม่มีการออกแบบ Index → เพราะขาดการวิเคราะห์ workload และรูปแบบการใช้งาน
3
Why? ทีมพัฒนาไม่ได้รับการอบรม DB tuning → เพราะไม่มีแผนพัฒนาทักษะด้านฐานข้อมูล
4
Why? ไม่มี process review query → เพราะไม่มี code review ที่เน้นประสิทธิภาพฐานข้อมูล
5
Why? องค์กรไม่มีมาตรฐาน performance testing → เพราะขาดการกำหนด KPIs ด้านประสิทธิภาพระบบ
🎯
สาเหตุที่แท้จริง (Root Cause): องค์กรขาดมาตรฐานและกระบวนการในการออกแบบ ตรวจสอบ และทดสอบประสิทธิภาพฐานข้อมูล ส่งผลให้เกิดปัญหาสะสมเมื่อระบบขยายขนาด
🔧 แนวทางป้องกันระยะยาว: จัดทำ Database Performance Standard, อบรมทีมพัฒนา, เพิ่ม Code Review Checklist, นำ Performance Testing เข้าสู่ CI/CD Pipeline

📡 Demo #2: Real-time Dashboard + สถานะการเข้ารหัส Security Monitoring

🎯 สอดคล้องกับโครงสร้างนำเสนอ: ส่วนนี้คือการสาธิต (Demo) ที่แสดงฟีเจอร์หลักและความสามารถในการตรวจจับปัญหาความปลอดภัยแบบ Real-time
📊 Real-time Communication Monitor
🔒 Secure (TLS 1.3)
📨 ข้อความที่ส่ง
0
📥 ข้อความที่รับ
0
🔐 การเข้ารหัส
AES-256-GCM
⏱️ Latency (ms)
32
--:--:--🟢 ระบบพร้อมทำงาน | สถานะการเข้ารหัส: ACTIVE (TLS 1.3)
--:--:--🔐 WebSocket Secure (wss://) เชื่อมต่อสำเร็จ

💡 สถานะสีเขียว = การสื่อสารปลอดภัย (เข้ารหัส) | สีแดง = ตรวจพบการเชื่อมต่อที่ไม่ปลอดภัย (ต้องแก้ไขทันที)

🔐 การวิเคราะห์ปัญหาความปลอดภัยด้วยเทคนิค 5 Whys

ปัญหา: ข้อมูลถูกส่งในรูปแบบ plain text แม้ติดตั้ง SSL Certificate แล้ว


1
Why? WebSocket ใช้ ws:// แทน wss:// → เพราะ configuration mismatch
2
Why? ไม่มีการบังคับใช้ HSTS (HTTP Strict Transport Security) → ขาด security header
3
Why? ทีมพัฒนาไม่ทราบถึงความเสี่ยง → ขาดการอบรมด้าน Security
4
Why? ไม่มี automated test ตรวจสอบ protocol → CI/CD ขาด security testing stage
5
Why? องค์กรไม่มีมาตรฐานความปลอดภัยสำหรับระบบ Real-time → ต้องจัดทำมาตรฐาน
✅ Root Cause: กระบวนการพัฒนาไม่รวมการตรวจสอบความปลอดภัยของช่องทางการสื่อสาร
🔧 แนวทางแก้ไข: บังคับใช้ TLS 1.3, ตั้งค่า HSTS, ใช้ mTLS สำหรับอุปกรณ์ IoT, เพิ่ม Encryption Status Dashboard

🔍 กรณีศึกษาเปรียบเทียบ: Performance vs Security

📊 Performance Issue (Demo #1)

อาการ: ระบบช้า, CPU สูง, Response time นาน

เครื่องมือ: Log, Profiler, Monitor, JMeter

แก้ไข: Index, Cache, Pagination, CDN

ป้องกัน: Performance Testing, Code Review, Load Testing

🔐 Security Issue (Demo #2)

อาการ: ข้อมูลไม่เข้ารหัส, เสี่ยง MITM Attack

เครื่องมือ: Wireshark, SSL Labs, Network Analyzer

แก้ไข: TLS 1.3, HSTS, wss://, mTLS

ป้องกัน: Security Audit, Pen Testing, Encryption Monitor

📌 บทเรียนรวม: การบริหารจัดการปัญหาที่มีประสิทธิภาพต้องครอบคลุมทั้งด้าน Performance และ Security โดยใช้กระบวนการ Incident Management (Detection → Analysis → Resolution → Closure) ร่วมกับเทคนิค 5 Whys และเครื่องมือที่เหมาะสม พร้อมการตรวจสอบแบบ Real-time

❓ คำถามทบทวน

  1. กระบวนการจัดการปัญหา (Incident Management) มีกี่ขั้นตอน อะไรบ้าง แต่ละขั้นตอนมีเป้าหมายอย่างไร?
  2. โครงสร้างการนำเสนอโปรเจกต์ที่แนะนำมีทั้งหมดกี่ส่วน แต่ละส่วนใช้เวลาเท่าไร (อ้างอิงจากแผนภาพ)
  3. จาก Demo #1 ปัญหา Performance ที่เกิดขึ้นมีสาเหตุหลักจากอะไร และแนวทางแก้ไขใดที่เห็นผลชัดเจนที่สุด
  4. จาก Demo #2 หากสถานะการเข้ารหัสเปลี่ยนเป็นสีแดง หมายถึงอะไร และควรดำเนินการอย่างไรตามกระบวนการ Incident Management
  5. เทคนิค 5 Whys ช่วยในการวิเคราะห์ปัญหาทั้ง Performance และ Security ได้อย่างไร ยกตัวอย่างอย่างน้อย 1 ปัญหา
  6. การเตรียมตัวสำหรับการสาธิต (Demo) ควรมีแผนสำรองอะไรบ้าง และเพราะเหตุใดจึงสำคัญ?
  7. เปรียบเทียบความแตกต่างระหว่าง Incident Management และ Problem Management
  8. เครื่องมือใดบ้างที่ใช้ในการตรวจจับปัญหาความปลอดภัยของการสื่อสารแบบ Real-time

📊 เกณฑ์การประเมิน

รายการคะแนนหมายเหตุ
การมีส่วนร่วมในชั้นเรียน (ถาม-ตอบ)1%การถาม-ตอบเกี่ยวกับกระบวนการจัดการปัญหาและ Demo ทั้งสอง
แบบทดสอบความเข้าใจ2%ทดสอบเนื้อหาทฤษฎี การประยุกต์ใช้ และการวิเคราะห์ปัญหา

📌 หมายเหตุ: นักศึกษาสามารถทดลองใช้งาน Demo #2 เพื่อทำความเข้าใจการตรวจจับสถานะการเข้ารหัส และนำไปประยุกต์ใช้ในการนำเสนอโปรเจกต์จริง

CSI203 สถาปัตยกรรมดิจิทัลและระบบปฏิบัติการ | Sripatum University

กระบวนการจัดการปัญหา (Incident Management) | Demo #1: Performance Tuning | Demo #2: Real-time Security Monitoring