แพลตฟอร์ม observability สำหรับฟินเทค 40 ไมโครเซอร์วิส
จาก dashboard 60 อันที่ไม่มีใครดู สู่ SLO 12 ตัวที่ทีมใช้ตัดสินใจจริง — MTTR ลดลง 63% ในหนึ่งไตรมาส
- ลูกค้า
- ฟินเทค · กรุงเทพฯ
- บทบาท
- ผู้ออกแบบ observability และที่ปรึกษา SRE
- ระยะเวลา
- 10 สัปดาห์
- เทคโนโลยี
- Prometheus, Grafana, Loki
-63%
MTTR
12
SLO ที่ใช้งานจริง
-78%
alert ตอนกลางคืน
40
ไมโครเซอร์วิส
01 — โจทย์
ทีมมี dashboard เยอะแต่ไม่มีใครรู้ว่าอะไรสำคัญ เวลาเกิดเหตุต้องใช้เวลา 45 นาทีแค่หาว่าอะไรพัง และ log กระจัดกระจายใน 4 ระบบ
02 — แนวทาง
เริ่มจาก SLO ของเส้นทางธุรกิจหลัก 12 เส้นทาง นิยาม error budget และสร้าง alert จาก burn rate แทน threshold คงที่ รวม log เข้า Loki และทำ tracing แบบ sampling ที่จุดสำคัญ
03 — ผลลัพธ์
MTTR ลดจาก 46 นาทีเหลือ 17 นาที สัญญาณเตือนตอนกลางคืนลดลง 78% และทีมมีภาษาเดียวกันในการคุยเรื่องความเสี่ยง
เทคโนโลยี
PrometheusGrafanaLokiTempoAlertmanagerKubernetes
หลักคิด
เราลบ dashboard 60 อันลงเหลือ 12 อัน — ไม่ใช่เพราะกราฟไม่สวย แต่เพราะทุกอันต้องตอบคำถามได้ว่า "ถ้าค่านี้ผิด ผู้ใช้จะเจ็บอย่างไร"
Burn rate alert แทน threshold
yaml
- alert: CheckoutErrorBudgetBurn
expr: |
(sum(rate(http_requests_total{route="checkout",status=~"5.."}[5m]))
/ sum(rate(http_requests_total{route="checkout"}[5m]))) > (14.4 * 0.001)
for: 2m
labels: { severity: page }ผลลัพธ์ที่วัดได้
- MTTR 46 → 17 นาที
- alert ที่ไม่ต้องลงมือทำ ลดลง 78%
- onboarding วิศวกรใหม่ใช้เวลาเข้าถึงระบบ 2 วัน (เดิม 2 สัปดาห์)