ช่วงเวลาที่น่าตื่นเต้นที่สุดในโปรเจกต์ Software คือวัน Go-Live — ทีมเฉลิมฉลอง ลูกค้าเริ่มใช้งาน ทุกอย่างดูสมบูรณ์แบบ
แต่นั่นไม่ใช่จุดสิ้นสุด เป็นแค่จุดเริ่มต้นของ Phase ใหม่ที่เรียกว่า Maintenance
ทำไม Software ถึงต้องการ Maintenance?
Software ไม่เหมือนสิ่งก่อสร้างที่เมื่อสร้างเสร็จแล้วก็ใช้ได้เลย มีปัจจัยหลายอย่างที่ทำให้ Software เสื่อมสภาพตามเวลา:
1. Environment เปลี่ยน
- Browser Version ใหม่ออก (Chrome, Safari Update บ่อยมาก)
- Operating System เปลี่ยน (Windows Update, iOS Update)
- Cloud Provider เปลี่ยน API หรือ Deprecate Feature
- Third-party Library ที่ใช้ Release Version ใหม่พร้อม Breaking Change
2. Security Vulnerabilities ใหม่ถูกค้นพบ
ทุกปีมี CVE (Common Vulnerabilities and Exposures) ใหม่หลายพัน รายการ Library ที่ Software ใช้อาจมี Security Hole ที่ต้องรีบ Patch
3. Business เปลี่ยน
- Tax Rate เปลี่ยน
- Product และ Pricing เปลี่ยน
- Regulation ใหม่ (เช่น PDPA)
- Business Process ที่ Evolve
4. Technical Debt สะสม
Code ที่ดีในวันแรกอาจกลายเป็น Code ที่ยาก Maintain ตามเวลา โดยเฉพาะถ้า Business Logic ซับซ้อนขึ้นเรื่อยๆ
ประเภทของกิจกรรม Maintenance
1. Corrective Maintenance (Bug Fix)
แก้ Bug ที่พบหลัง Go-Live ไม่ว่าจะเป็น Bug ที่ผ่าน Testing มาแต่ไม่ถูก Detect หรือ Edge Case ที่ User จริงเจอ
2. Preventive Maintenance
- Dependency Update — Update Library, Framework เป็นระยะ ป้องกัน Security Issue
- Code Refactoring — ปรับปรุง Code ให้อ่านง่ายขึ้น Maintain ง่ายขึ้น
- Performance Optimization — Monitor และแก้ Bottleneck ก่อนที่จะกลายเป็นปัญหาใหญ่
3. Adaptive Maintenance
ปรับ Software ให้ Compatible กับ Environment ที่เปลี่ยนแปลง เช่น iOS 18 Update บางอย่างที่ทำให้ UI ผิดเพี้ยน
4. Perfective Maintenance
เพิ่ม Feature เล็กๆ หรือปรับปรุง UX ที่ไม่ใช่ Bug แต่ทำให้ User Experience ดีขึ้น
สิ่งที่ต้อง Monitor หลัง Go-Live
Infrastructure Monitoring
- Server CPU/Memory/Disk — แจ้งเตือนเมื่อ Resource ใกล้เต็ม
- Uptime Monitor — แจ้งเตือนทันทีเมื่อระบบล่ม
- Database Performance — Query ที่ช้ากว่า Threshold
Application Monitoring
- Error Rate — จำนวน 4xx/5xx Error ต่อวัน
- Response Time — เวลาเฉลี่ยที่ API ตอบกลับ
- User Drop-off — ผู้ใช้ออกจากหน้าไหนบ่อยที่สุด
Security Monitoring
- Failed Login Attempts — สัญญาณของ Brute Force
- Unusual Traffic Patterns — อาจเป็น DDoS หรือ Scraping
- Dependency Vulnerability Scan — เช่น GitHub Dependabot
Maintenance SLA ที่ควรมี
เมื่อเซ็น Maintenance Agreement กับ Software House ควรกำหนด SLA ที่ชัดเจน:
| ประเภท Bug | Response Time | Resolution Target |
|---|---|---|
| Critical (ระบบล่ม, Data Loss) | 1 ชั่วโมง | 4–8 ชั่วโมง |
| Major (Feature หลักไม่ทำงาน) | 4 ชั่วโมง | 24–48 ชั่วโมง |
| Minor (ปัญหาเล็กน้อย) | 1 วัน | 1 สัปดาห์ |
| Enhancement (Feature ใหม่) | 3 วัน | ตาม Scope |
ต้นทุน ถ้าไม่ทำ Maintenance
กรณีที่เกิดขึ้นจริง:
ระบบ E-commerce ที่ไม่ Update SSL Certificate → Browser แสดง "ไม่ปลอดภัย" → ลูกค้าออกจากหน้า → Revenue หาย
Library มี Security Vulnerability ที่ไม่ได้ Patch → Hacker ใช้ช่องโหว่เข้าระบบ → ข้อมูลลูกค้ารั่วไหล → ค่า Compliance และ Reputational Damage มหาศาล
ไม่ทำ Database Optimization → Query ช้าลงเรื่อยๆ → User Complaint → เสียลูกค้า
เมื่อ Software ต้องการ Major Upgrade หรือ Rebuild
สัญญาณที่บอกว่า Maintenance อย่างเดียวไม่พอ:
- Codebase เก่ามากจน Dev ใหม่ใช้เวลาเรียนนานกว่าจะ Work ได้
- Performance แย่มากแม้ Optimize แล้ว
- Feature ใหม่ที่ต้องการขัดแย้งกับ Architecture เดิมมากเกิน
- Tech Stack ที่ใช้ End-of-Life (ไม่มีผู้หรือ Community Support แล้ว)
ในกรณีนี้ควรคุยกับ Software House เรื่อง Refactoring หรือ Rewrite Strategy
สรุป
Maintenance ไม่ใช่ "ค่าใช้จ่ายเพิ่ม" — มันคือ การลงทุนป้องกัน ที่ถูกกว่า Emergency Fix มาก
Software ที่ดูแลดีจะ:
- Secure ต่อ Threat ใหม่ๆ
- Compatible กับ Environment ที่เปลี่ยน
- เสถียรและ Perform ดีตลอดอายุการใช้งาน
- แก้ไขต่อยังง่ายเมื่อ Business ขยาย
ตั้งแต่ต้นควรมองหา Software House ที่มี Maintenance Plan ที่ชัดเจน ไม่ใช่คนที่ส่งงานแล้วหายไป
Adowbig มี Maintenance Package ที่ครอบคลุม Bug Fix, Security Update และ Monthly Monitoring ดูรายละเอียด
