การเลือกเครื่องมือ Infrastructure as Code ที่เหมาะกับทีมเป็นการตัดสินใจที่ส่งผลระยะยาว เพราะโครงสร้างพื้นฐานทั้งหมดจะถูกเขียนในภาษาและรูปแบบของเครื่องมือนั้น ๆ การเปลี่ยนทีหลังมีต้นทุนสูงทั้งเรื่องเวลาและการฝึกทีม Terraform, AWS CloudFormation และ Pulumi เป็นสามตัวเลือกที่นิยมมากที่สุด แต่ละตัวเหมาะ
การใช้งาน Terraform ในชีวิตประจำวันหมุนเวียนอยู่รอบ 4 คำสั่งหลัก คือ init, plan, apply และ destroy แต่ละคำสั่งทำหน้าที่แตกต่างกันและออกแบบมาให้ทำงานเป็นขั้นตอนที่ปลอดภัย เปิดโอกาสให้ตรวจสอบก่อนเปลี่ยนแปลงโครงสร้างพื้นฐานจริง การเข้าใจ workflow นี้ให้ลึกช่วยให้ใช้ Terraform ได้อย่างมั่นใจและหลีกเลี่ย
Infrastructure as Code (IaC) เป็นแนวทางที่เปลี่ยนวิธีการบริหารจัดการโครงสร้างพื้นฐานไอทีจากการคลิกคอนโซลด้วยมือ ไปสู่การนิยามทุกอย่างเป็นโค้ดที่ทำซ้ำได้ แต่องค์กรแต่ละแห่งนำ IaC ไปใช้ในระดับที่แตกต่างกัน บางแห่งเพียงเขียนสคริปต์ Bash ไว้เรียกซ้ำ บางแห่งใช้ Terraform เต็มรูปแบบพร้อม CI/CD pipeline ขณ
ค่าใช้จ่ายของ Cloud Infrastructure มักสูงเกินจำเป็นเพราะการตั้ง resource เกินกว่าที่ใช้งานจริง (over-provisioning) หรือปล่อยให้ server/disk/bandwidth ที่ไม่ได้ใช้ทำงานเปล่า ๆ การทำ Cost Optimization ด้วยการ Monitor Resource Usage อย่างเป็นระบบช่วยให้ทีมสามารถปรับขนาด VPS ให้เหมาะกับ workload จริง ลด
การมีระบบ Monitoring ที่ดีไม่เพียงพอหากไม่มี On-Call Alerting ที่สามารถแจ้งเตือนทีมได้ทันเวลาเมื่อเกิดปัญหาในเวลากลางคืนหรือวันหยุด การตั้ง Alertmanager ร่วมกับ PagerDuty ช่วยให้ทีม SRE/DevOps สามารถ rotate เวร รับ alert ผ่านโทรศัพท์ และจัดการ incident ได้อย่างเป็นระบบ ลด MTTR (Mean Time To Recovery
การรัน Kubernetes cluster ใน production โดยไม่มี monitoring ที่เหมาะสมเปรียบเหมือนการขับรถโดยปิดตา เราไม่เห็น pod ที่กำลัง crash loop ไม่รู้ว่า node ไหน CPU แตะ 90% และไม่ทราบว่า HPA ทำงานถูกต้องหรือเปล่า ผลคือเมื่อเกิดปัญหาผู้ใช้งานจะเจอ error ก่อนทีม DevOps รับรู้ การติดตั้ง Prometheus กับ Grafana
ในระบบ production ยุคปัจจุบัน การมีแค่ metrics ไม่เพียงพอต่อการแก้ปัญหาซับซ้อน ทีม DevOps และ SRE จึงต้องรวม 3 เสาหลักของ observability เข้าด้วยกัน นั่นคือ metrics, logs และ traces เพื่อให้มองเห็นระบบแบบ 360 องศา เมื่อเกิดปัญหาก็สามารถไล่หาสาเหตุได้ตั้งแต่ตัวเลขภาพรวม ลงไปถึง log บรรทัดที่ error และ
Grafana เป็น visualization layer ที่ทีม DevOps ใช้ดู metrics จาก Prometheus, Loki, Elasticsearch และ data source อื่น ๆ เมื่อ dashboard ไม่แสดงข้อมูลตามที่คาดหรือ alert ไม่ถูกส่งออกไป การ troubleshoot ต้องตรวจตั้งแต่ data source, query, panel settings, ไปจนถึง notification policy — บทความนี้รวมวิธีต
เมื่อระบบ monitoring ที่ใช้ Prometheus เริ่มมีปัญหา เช่น metrics บางชุดหายไปจากกราฟ, dashboard ใช้เวลาโหลดนาน, query ที่เคยเร็วกลับช้าผิดปกติ หรือเก็บข้อมูลย้อนหลังไม่ได้ — ปัญหาเหล่านี้ส่วนใหญ่สาเหตุซ้ำกันและแก้ได้ด้วยการตรวจสอบอย่างเป็นระบบ การรู้ว่าจุดไหนควรดูก่อนและเครื่องมือใดใช้ได้เมื่อไหร่ จะ
ทีมพัฒนาต้องตัดสินใจทุกวันว่าควร release ฟีเจอร์ใหม่เร็วแค่ไหน รับความเสี่ยงได้เท่าไหร่ และเมื่อไหร่ควรหยุดเพื่อเน้นแก้ปัญหา เสถียรภาพ การตัดสินใจแบบอาศัย "feeling" หรือความเห็นของหัวหน้ามักนำไปสู่ความขัดแย้งระหว่างฝ่ายที่อยากทำฟีเจอร์ใหม่กับฝ่ายที่ดูแลระบบ Error Budget คือเครื่องมือเชิงวิศวกรรมที่แ
