อ่านบทความเรื่อง How observability is redefining the roles of developers
ทำการอธิบายเรื่องของ Observability ของระบบ
ซึ่งถ้าเคยได้ยินจะพูดถึงเรื่องของ
- Application metrics
- Distributed tracing
- Centralized logging
แต่ปัญหาที่น่าสนใจคือ สิ่งต่าง ๆ เหล่านี้มักจะถูกสร้างเพื่อระบบ
หรือหน่วยงานใดหน่อวยงานหนึ่ง เช่น DevOps และ Ops เป็นต้น
แต่ไม่ได้ทำเพื่อทีมพัฒนาสักเท่าใดนัก
ดังนั้นจึงเป็นมาของคำว่า Developer Observability
ซึ่งระบบ Observability นั้นควรออกแบบมาจากความต้องการของทีมพัฒนาด้วย
เป็นเครื่องมือที่ช่วยให้นักพัฒนา
ง่ายต่อการพัฒนา
ง่ายต่อการหาข้อผิดพลาด
ตั้งแต่ source code ยันไปถึงการ deploy ที่ production เลย
ไม่ใช่ทำมาเพื่อส่วนใดส่วนหนึ่งเท่านั้น
ดังนั้นข้อมูลที่จัดเก็บมี 2 ประเภทคือ
- ข้อมูลการ request ของผู้ใช้งาน ที่เข้ามายังระบบ
- ข้อมูลของ source code เช่น ไฟล์ไหน บรรทัดอะไร commit อะไร เป็นต้น
ยกตัวอย่างข้อมูลของ log ต่าง ๆ ควรเป็นไปตาม demand หรือ ความต้องการ
เช่นในการพัฒนานั้นสามารถเขียน log ได้ในระดับ method เลย
แต่เมื่อขึ้น production mode แล้ว สามารถเลือกเฉพาะที่จำเป็นเท่านั้น
เพราะว่า พบบ่อยมากที่ log ที่จัดเก็บอ่านไม่รู้เรื่องเลย
แถมใช้ที่จัดเก็บเยอะจนเกินเหตุ
ทำให้ performance ของระบบลดลงไปอีก !!
หรือสามารถระบบลงไปได้เลยว่า
code แต่ละไฟล์ แต่ละบรรทัด ถูกใช้งานจาก feature ไหนบ้าง ?
ก็จะทำให้เห็นว่า code ที่เราเขียน และดูแลนั้น ถูกใช้งานจริง ๆ หรือไม่
จะได้ช่วยลดค่าใช้จ่ายในการดูแลรักษาต่อไป
อีกทั้งยังช่วยดูการทำงานหรือปัญหาต่าง ๆ ของระบบอีกด้วย
เช่น
- ปัญหาเรื่อง performance
- ปัญหาเรื่องของ security เช่น บรรดา library ต่าง ๆ ที่นำมาใช้งาน มีช่องโหว่หรือไม่ โดยการใช้ SBOM (Software Bill of Materials) มาใช้เช่นกัน
จะเห็นได้ว่าแนวคิด Developer Observability นั้น เพื่อลดการทำงานแบบ Silo
หรือการทำงานแบบต่างคนต่างทำงาน
นั่นคือ การทำงานแบบเป็นทีมนั่นเอง
แถมช่วยป้องกันปัญหาต่าง ๆ ไม่ให้เกิดบน production
หรือเมื่อเกิดปัญหาจะได้แก้ไขได้อย่างรวดเร็วอีกด้วย