ว่าด้วยเรื่องของการวัดผลของ DevOps

สิ่งที่น่าสนใจสำหรับคำว่า DevOps ซึ่งได้กลายเป็นคำที่ถูกพูดถึงอย่างมาก หนักไปกว่านั้น เรามีการเปิดรับสมัครตำแหน่ง DevOps อีกด้วย ทั้ง ๆ ที่มันไม่ควรจะมีตำแหน่งนี้เลย แต่มันควรเป็นแนวคิด แนวปฏิบัติสำหรับทุกคนที่เกี่ยวข้อง เป็นสิ่งที่ควรเกิดขึ้นในการพัฒนา software เพื่อช่วยปรับปรุงเวลา ตั้งแต่เรื่องของการรับ requirement เปลี่ยนจาก requirement ไปเป็นสิ่งที่อยู่ในมือของผู้ใช้งาน ไปจนถึงการดูแลรักษาระบบ ปรับปรุง และ operate ต่าง ๆ ให้เร็ว และ ดีขึ้นอย่างต่อเนื่อง

ดังนั้นมาดูกันว่า ถ้าที่ใดนำแนวคิด DevOps เข้ามาใช้งานแล้ว น่าจะต้องดูด้วยว่าช่วยปรับปรุงค่าต่าง ๆ เหล่านี้หรือไม่

เป้าหมายหลักของ DevOps คือ

• Velocity
• Quality
• Performance

นั่นคือต้องส่งมอบ software ได้เร็วและบ่อย พร้อมคุณภาพและประสิทธิภาพที่สูง โดยที่จะเร็ว และ ดีเพียงใด ขึ้นอยู่กับระบบ ขึ้นอยู่กับทีมงาน ขึ้นอยู่กับความเสี่ยง จะดีเพียงใดมันตอบยาก จะเร็วเพียงใดมันตอบยาก จะมีคุณภาพสูงเพียงใดมันตอบยาก ดังนั้นมาลองพิจารณาตัวเลขเหล่านี้หน่อยว่า มันเพียงพอสำหรับการวัดเกี่ยวกับ DevOps หรือไม่ ?

ก่อนที่จะวัดอย่าลืมวัดค่าต่าง ๆ เหล่านี้ก่อนที่จะเปลี่ยน หรือนำแนวคิด DevOps มาใช้ด้วยนะครับ จะได้มีค่าที่เป็น based line เอาไว้วัดผล

ขนาดของการ deploy ในแต่ละครั้งใหญ่เพียงใด

ยกตัวอย่างเช่น จำนวนของ feature จำนวนของ story/flow จำนวนของการแก้ไข bug แต่สิ่งที่ต้องกำหนดดี ๆ คือ ขนาดของ feature/story/bug ต้องเท่า ๆ กันนะ

มีการ deploy บ่อยเพียงใด

ซึ่งมันสัมพันธ์กับขนาดของที่จะ deploy ในแต่ละครั้ง ถ้าขนาดของการ deploy มีขนาดเล็กแล้ว การ deploy ก็จะเร็ว การทดสอบก็ง่ายขึ้น ซึ่งควรวัดความถี่ทั้ง QA, Pre-Prod และ Production กันเลย เพื่อทำให้เราค้นหาข้อผิดพลาดได้รวดเร็วขึ้น ยิ่ง development ได้เลยยิ่งดี เป็นแนวทางหนึ่งในการลดข้อผิดพลาดอีกด้วย

ค่า Lead time

เพื่อใช้วัดผลการทำงานว่าเร็วหรือช้าลง สิ่งที่สำคัญคือ ต้องกำหนดจุดเริ่มต้นและสิ้นสุด ยกตัวอย่างเช่น จุดเริ่มต้นคือ การคุย requirement กับลูกค้า จุดสิ้นสุดคือ การ deploy บน production และลูกค้าใช้งาน

จำนวน feedback จากผู้ใช้งานและลูกค้า

ลองคิดดูสิว่า ถ้าลูกค้าและผู้ใช้งานแจ้งปัญหาหรือข้อผิดพลาดมาเยอะมาก ๆ นั่นแสดงว่า ระบบที่คุณพัฒนามันแย่หรือไม่ ? ลองคิดดูนะ ถึงแม้ bug จะน้อย ถึงแม้ feature จะดีมาก ๆ แต่ผู้ใช้งานแจ้ง หรือ ด่ากลับมามาก ๆ มันก็ไม่น่าจะดีนะ !!

จำนวนของ Automation test ที่ผ่าน

ถ้าทีมคุณต้องการที่จะเร็ว สิ่งหนึ่งที่ต้องทำก่อนคือ automation test ทั้ง unit test, integration test และ functional test โดยที่แนวคิด DevOps เน้นกระบวนการแบบอัตโมัติอย่างมาก หนึ่งสิ่งที่สำคัญคือ การทดสอบ ดังนั้นจำนวนของ automation test จึงต้องสูง แต่สิ่งที่สำคัญกว่าคือ จำนวน automation test ที่ผ่าน ยังไม่พอนะ ถ้า automation test มันดีแล้ว จะบอกได้ว่า เมื่อทำการแก้ไข code แล้ว จะมี automation test พังจำนวนเท่าไร

จำนวน defect ที่เจอบน production

ถ้าคุณเจอ defect/bug บน production จำนวนสูงขึ้น นั่นหมายความว่า สิ่งที่คุณกำลังทำอยู่นั้นมันไม่น่าจะดี ทั้งการทดสอบแบบ manual และ อัตโนมัติ ดังนั้นจำเป็นต้องทำการปรับปรุงให้ดีขึ้น

Availability และ Downtime ของระบบ

เพื่อทำให้เห็นคุณภาพของขั้นตอนการ deploy และสิ่ง deploy ขึ้นไป

จำนวน Error rate ของระบบ และประสิทธิภาพการทำงานของระบบ

เป็นค่าที่สำคัญมาก ๆ ของ software เพื่อทำให้เห็นว่า สิ่งที่ deploy ไปนั้นมีคุณภาพหรือไม่ ดังนั้นสิ่งที่ software ควรมีคือ ระบบ tracing เพื่อดูการทำงานของระบบ ว่ามีข้อผิดพลาดเกิดขึ้นหรือไม่ ทั้งการเกิด exception ต่าง ๆ ทั้ง production issue เช่น ปัญหา database connection ปัญหา query timeout

จำนวน Usage และ Traffic ต่าง ๆ ของระบบ

หลังจากทำการ deploy ไปแล้วนั้น การทำงานของระบบยังต้องทำงานเป็นปกติ แต่ถ้าไม่มีการใช้งานเข้ามา หรือ เข้ามาแบบสูงผิดปกติ แสดงว่า น่าจะมีข้อผิดพลาดเกิดขึ้นแล้วนะ

ยังมีค่าอื่น ๆ อีกนะ เช่น

เมื่อเกิดปัญหาบน production แล้วคุณใช้เวลาเท่าไร ในการค้นหา root cause และ แก้ไข นั่นคือ Mean Time to Detection (MTTD) Mean Time to Recovery (MTTR) ดังนั้นเรื่องของ application monitoring จึงสำคัญมาก ๆ โดยรวมแล้วอย่าลืมว่า DevOps นั้นคือ การทำงานร่วมกันของแต่ละฝ่ายที่เกี่ยวข้อง ทั้ง business ทั้งทีมพัฒนา ทั้งขั้นตอนการ deploy ทั้งการ monitoring application

มิใช่ต่างฝ่ายต่างทำกันไป !! อย่าลืมว่า ทุกอย่างมันเริ่มที่คน คนคิด process จากนั้นทำการปรับปรุง process ให้ดีด้วยเครื่องมือ