ลูกค้าเป็นบริการโลจิสติกส์ที่จัดการคำสั่งซื้อหลายหมื่นรายการต่อวัน มีช่วงพีกในตอนเย็นและช่วงแคมเปญ พร้อม SLA ที่เข้มงวดต่อร้านค้าพันธมิตร โครงสร้างพื้นฐานเติบโตอย่างไร้แผน มี VPS กระจัดกระจาย การตั้งค่าอยู่บนเซิร์ฟเวอร์ และการปล่อยเวอร์ชันทำด้วยมือตามคำแนะนำในวิกิ ทุกเวอร์ชันต้องปล่อยตอนกลางคืนและมีช่วงหยุดให้บริการ ทุกช่วงพีกเสี่ยงทำคำสั่งซื้อสูญหาย จุดเริ่มต้นของโครงการคือเหตุการณ์ในแคมเปญก่อนปีใหม่ เมื่อแพลตฟอร์มหยุดทำงานสี่ชั่วโมงและบริการต้องจ่ายค่าชดเชยให้พันธมิตร
ย้ายแพลตฟอร์มไปสู่โครงสร้างพื้นฐานที่บริหารจัดการได้โดยไม่หยุดธุรกิจ:
กำหนดโครงสร้างพื้นฐานเป็นโค้ด ส่งมอบอัตโนมัติ ทำคอนเทนเนอร์และออร์เคสเตรชัน เพิ่มการสังเกตการณ์ และกู้คืนจากความขัดข้องได้อย่างคาดการณ์ได้ ผู้ก่อตั้งระบุเกณฑ์ความสำเร็จว่า “ปล่อยเวอร์ชันในเวลาทำงาน ไม่มี downtime และไม่ต้องมีคนที่เข้าถึงผ่าน SSH”
เราดำเนินตามลำดับที่พิสูจน์แล้ว: เริ่มจากคอนเทนเนอร์และสภาพแวดล้อมที่สร้างซ้ำได้ ต่อด้วยการทำส่งมอบให้เป็นอัตโนมัติ แล้วจึงทำออร์เคสเตรชันพร้อม auto-scaling
- ตรวจสอบโครงสร้างพื้นฐาน ทำแผนผังบริการและการพึ่งพากัน วัดรูปแบบโหลดช่วงพีก และรวบรวมรายการงานด้วยมือที่ทำให้เกิดเหตุขัดข้องบ่อยที่สุด
- ทำบริการให้เป็นคอนเทนเนอร์ ทำขั้นตอน build ให้เป็นมาตรฐาน ย้ายการตั้งค่าออกจากโค้ดไปไว้ใน environment variable และสร้างสภาพแวดล้อม dev/stage/prod ที่เหมือนกัน
- อธิบายโครงสร้างพื้นฐานเป็นโค้ดด้วย Terraform ระบบสร้างสภาพแวดล้อมจาก repository และห้ามแก้ไขด้วยมือในคอนโซลของผู้ให้บริการคลาวด์
- สร้าง GitLab CI pipeline ให้การทดสอบและ build image ทำงานอัตโนมัติ stage ปล่อยได้ทันที ส่วน prod กดปุ่มหลังการ review และ rollback ได้ในการดำเนินการเดียว
- ย้ายแพลตฟอร์มไป Kubernetes พร้อม auto-scaling ช่วงพีกตอนเย็นและแคมเปญมี instance เพิ่มขึ้นแทนที่จะต้องแก้ปัญหาด้วยมือแบบฉุกเฉิน
- ติดตั้ง monitoring และ alerting วัดสัญญาณหลักสี่อย่าง ได้แก่ latency, errors, traffic และ saturation พร้อมเวรดูแลและการ escalation ตามกำหนด
- ตั้งค่าการสำรองข้อมูลและ disaster recovery จัดทำขั้นตอนกู้คืน และซ้อมเหตุขัดข้องใน stage พร้อมวัด MTTR จริง
คุณค่าที่สำคัญที่สุดของโครงการไม่ใช่เทคโนโลยี แต่คือการเปลี่ยนความรับผิดชอบ โครงสร้างพื้นฐานไม่ต้องพึ่ง “คนที่เข้าถึงผ่าน SSH” อีกต่อไป ทุกการปล่อยเวอร์ชันทำซ้ำได้ ทุกสภาพแวดล้อมกู้คืนจากโค้ดได้ และแดชบอร์ดแสดงความขัดข้องก่อนลูกค้าคนแรกจะเขียนมา การหยุดให้บริการจึงเปลี่ยนจากภัยพิบัติเป็นเหตุการณ์ประจำที่มี playbook ชัดเจนและเวลาฟื้นตัววัดได้
ผลทางเศรษฐกิจมีสามส่วน: ประหยัดค่าโครงสร้างพื้นฐานโดยตรง 32% จาก auto-scaling และการเลิกเปิดกำลังรองรับช่วงพีกทิ้งไว้ตลอดเวลา ประหยัดชั่วโมงทีมที่เคยใช้ปล่อยเวอร์ชันตอนกลางคืน และที่สำคัญที่สุดคือรักษารายได้ในช่วงพีกซึ่งตอนนี้ผ่านไปโดยไม่มีเหตุขัดข้อง ลูกค้ารายใหญ่ซึ่งเป็นเครือร้านค้าต่อสัญญาหลังแคมเปญแรกบนโครงสร้างพื้นฐานใหม่
| ตัวชี้วัด | ผลลัพธ์ |
|---|---|
| เวลาปล่อยเวอร์ชัน | ทำด้วยมือ 3–4 ชั่วโมง → อัตโนมัติ 15 นาที |
| ความถี่ในการปล่อยเวอร์ชัน | 2–3 ครั้งต่อเดือน → เกือบทุกวัน |
| ความพร้อมใช้งานของแพลตฟอร์ม | 97,8% → 99,95% |
| โหลดช่วงพีก | เสี่ยงหยุดให้บริการ → auto-scaling โดยไม่ต้องมีคนลงมือ |
ตัวชี้วัดนำมาจากเอกสารต้นฉบับของกรณีศึกษา ระบุช่วงเวลาไว้เมื่อแหล่งข้อมูลระบุ
- ปล่อยเวอร์ชัน (เดิมทำมือ 3–4 ชั่วโมง)
- 15 นาที
- ความพร้อมใช้งานของแพลตฟอร์ม (เดิม 97.8%)
- 99.95%
- กู้คืนหลังระบบล่ม (เดิม 2–4 ชั่วโมง)
- 20–30 นาที
- ต้นทุนโครงสร้างพื้นฐาน
- −32%
แสดงค่าขอบบนของช่วง (4 ชั่วโมง, 30 นาที) Downtime = 100% − ความพร้อมใช้งาน
- 01คอมมิต
- 02ทดสอบ
- 03สร้างอิมเมจ
- 04Stageทันที
- 05Prodกดปุ่มหลังรีวิว
แนวทางพัฒนาโครงสร้างพื้นฐานในรอบถัดไป:
- แนวปฏิบัติ FinOps แจ้งเตือนต้นทุนที่ผิดปกติและแสดงต้นทุนอย่างโปร่งใสแยกตามทีม
- แนวทาง GitOps บันทึกสถานะ prod ไว้ใน repository และเปลี่ยนแปลงผ่าน pull request เท่านั้น
- Multi-region ทำสำเนาบริการสำคัญเพื่อทนต่อเหตุขัดข้องของผู้ให้บริการ
เมื่อก่อนการปล่อยเวอร์ชันคือกลางคืน กาแฟ และการภาวนา ตอนนี้เหลือแค่กดปุ่มกับสิบห้านาที เราฉลองแคมเปญแรกที่ไม่มีเหตุขัดข้องกันทั้งบริษัท
— ผู้อำนวยการฝ่ายเทคนิคของบริการโลจิสติกส์