ค่าใช้จ่ายของ 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 คือเครื่องมือเชิงวิศวกรรมที่แ
การรันระบบ production แบบไม่มีเป้าหมายด้าน reliability ที่ชัดเจน เป็นหนึ่งในสาเหตุหลักที่ทำให้ทีมวิศวกรและทีมธุรกิจไม่เข้าใจกันเรื่องคุณภาพบริการ ทีมหนึ่งอาจรู้สึกว่าระบบ "ค่อนข้างเสถียร" ขณะที่อีกทีมมองว่า "ล่มบ่อย" เพราะทั้งสองฝ่ายไม่ได้ใช้ตัววัดเดียวกัน SLO (Service Level Objective), SLI (Service
คำว่า Monitoring และ Observability มักถูกใช้สลับกันในหลายทีม แต่ในทางปฏิบัติแล้วสองแนวคิดนี้ไม่ใช่สิ่งเดียวกัน Monitoring เน้นตอบคำถามที่ถูกคาดเดาไว้ล่วงหน้า เช่น "CPU เกิน 80% ไหม" หรือ "API latency เกิน 500ms หรือเปล่า" ในขณะที่ Observability มุ่งให้เราสามารถตั้งคำถามใหม่ที่ไม่เคยคิดไว้และหาคำตอบจ
ปัญหาที่ทีม DevOps เจอบ่อยที่สุดไม่ใช่ "Metrics ไม่พอ" แต่เป็น "Metrics เยอะเกินจนไม่รู้จะดูอะไร" หรือในอีกมุมคือ เก็บทุกอย่างแต่ไม่มี Metric ไหนบอกได้ว่า "ระบบกำลังมีปัญหาหรือเปล่า" การเลือก Metrics ที่ถูกต้องตั้งแต่ต้นจึงเป็นเรื่องสำคัญ เพราะทุก Metric ที่เก็บต้องเสียค่า storage, ค่า ingestion, แล
