สิ่งที่น่าสนใจสำหรับคำว่า 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 ให้ดีด้วยเครื่องมือ

Tags: