ข้อผิดพลาดเมื่อนำ DevOps มาประยุกต์ใช้งาน

เรื่องที่ 1 Speed vs Quality แน่นอนว่าต้องเร็วมาก่อน !!

เมื่อมีการนำ DevOps เข้ามาในองค์แล้ว พบว่าสิ่งที่ให้ความสำคัญมาก ๆ คือความเร็วในการพัฒนาละส่งมอบ นั่นคือกระบวนการทำงานเร็วขึ้น แต่เมื่อเข้าไปดูในรายละเอียดกลับพบว่า สาเหตุที่ทำให้เร็วขึ้นคือ ลดหรือตัดกระบวนการทดสอบไป ซึ่งเป็นสิ่งที่น่ากลัวมาก ๆ คุณภาพต่อรองไม่ได้ ต้องดีเสมอ

เรื่องที่ 2 มักจะแยก DevOps ไปอีกแผนกหรือกลุ่มใหม่ !!

เนื่องจากเมื่อมีการนำ DevOps มาในองค์กรแล้ว มักจะมีขั้นตอนการทำงานที่แตกต่าง มักจะมีเครื่องมือที่แตกต่าง มักจะมีเป้าหมายที่แตกต่าง ไปจากเดิม ดังนั้นเพื่อความง่าย ก็แยกเป็นแผนกใหม่ไปเลย คำถามคือ ปัญหาของการทำงานร่วมกันระหว่าง IT และ Operation team ยังคงอยู่เช่นเดิม นี่คือเป้าหมายของการนำ DevOps มาใช้งานหรือ ? สิ่งที่ควรเข้าใจคือ DevOps ไม่ใช่แผนกใหม่ ไม่ใช่ตำแหน่งใหม่ มันเป็นเพียงแนวทางหรือเส้นทางใหม่ของการพัฒนา ดูแล และ ส่งมอบระบบเท่านั้น

เรื่องที่ 3 ต้องการเห็นผลอย่างรวดเร็ว !!

สิ่งที่ชอบตั้งคำถามมายังทีมพัฒนาและ operation คือ ทำอย่างไรที่จะส่งมอบหรือ release ระบบงานได้ X ครั้งต่อวันหรือสัปดาห์หรือเดือน นั่นคือ ต้องการขั้นตอนการทำงานที่สมบูรณ์ตั้งแต่ต้นยันจบเลย !! แต่เมื่อเข้าไปดูรายละเอียดกลับพบว่า ยิ่งองค์กรมีขนาดใหญ่เพียงใด ยิ่งมีขั้นตอนการทำงานที่ซับซ้อนมากขึ้นเท่านั้น ซึ่งเป็นการยากที่จะเขียนหรือสร้างกระบวนการทำงานขึ้นมาใหม่ !! ดังนั้นสิ่งที่องค์กรต้องเข้าใจและพิจารณาคือ การนำ DevOps เข้ามาใช้นั้น ต้องทำแบบค่อยเป็นค่อยไป เป็นขั้นตอนเป็น phase แน่นอนว่าในแต่ละขั้นตอนต้องมีการวัดผล เลือกสิ่งที่จะทำหรือปรับปรุงขึ้นมา 1 เรื่อง หาค่าที่จะใช้วัดตั้งแต่ก่อนทำ จากนั้นลงมือทำ และ วัดผลต่อไป ซึ่งจะทำให้เราเห็นได้อย่างชัดเจนว่า สิ่งที่ลงมือทำไปนั้นเป็นอย่างไร ต้องการการอบรมหรือเรียนอะไรบ้าง ต้องการคน ขั้นตอน และ เครื่องมืออะไรรบ้างที่เหมาะสม มันทำให้คนทำงานพูดคุยกันและทำงานร่วมกันมากขึ้น ตามแนวคิดของ DevOps เพื่อปรับปรุงการทำงานให้ดีขึ้น

เรื่องที่ 4 DevOps เอามาใช้แล้วต้องดีขึ้น !!

มันไม่ใช่ของวิเศษอะไรเลย จำเป็นต้องมีทีมที่ดีและเหมาะสม ทั้งแนวคิด มุมมอง ความสามารถ และการเรียนรู้ รวมทั้งต้องมีการจัดการหลายสิ่งอย่าง ทั้ง resource ทั้ง scope ทั้งเวลา ทั้งการ tracking process การทำงาน รวมไปถึงการแบ่ง project ใหญ่ ๆ ออกเป็น project เล็ก ๆ เพื่อให้ง่ายต่อการจัดการ และ ลดความเสี่ยงจากผลกระทบต่าง ๆ อีกทั้งเวลาที่วางแผนไว้ต้องเหมาะสม (คนทำมักจะไม่ได้วางแผนหรือไม่ ?) หัวใจหลัก ๆ ของ DevOps คือ รู้ปัญหาของตัวเอง แก้ไขทีละปัญหา วัดผล แก้ไขต่อ นั่นคือการเรียนรู้และปรับปรุงอย่างต่อเนื่อง

สุดท้ายการทดสอบอยู่ช่วงท้ายของขั้นตอนการพัฒนา !!

แนวคิดของ DevOps พยายามรวมเรื่องของ configuration management continuous integration/deployment/delivery automation testing เข้าไปในทิศทางเดียวกัน เพื่อเพิ่มประสิทธิภาพ ไม่ใช่ต่างฝ่ายต่างทำงานกันไป สิ่งหนึ่งที่พบได้บ่อย ๆ คือ การทดสอบมักอยู่ในช่วงท้ายของการพัฒนา ทั้ง functional testing ทั้ง non-functional testing เช่น performance/load testing และ security testing เนื่องจากเข้าใจกันว่า จะทดสอบได้นั้น ระบบงานต้องเสร็จแล้ว ต้องมีหน่วยงานหรือคนอื่น ๆ มาทดสอบ เนื่องจากทีมพัฒนาและทีมทดสอบไม่มีความรู้ และ เครื่องมือ ทำให้การทดสอบนั้นใช้เวลาและค่าใช้จ่ายสูงมาก ๆ ดังนั้นต้องเข้าใจตรงกันก่อนว่า การทดสอบต่าง ๆ เหล่านี้ต้องเกิดขึ้นอย่างต่อเนื่อง (Continuous testing) แน่นอนว่า จะทำได้การทดสอบต้องเป็นอัตโนมัติให้ได้มากที่สุด ถามว่าต้องมีเยอะเท่าไร ตอบได้เลยว่าต้องมากว่าเดิมอย่างต่อเนื่อง

จำไว้ว่า การทดสอบที่ดีนั้น ต้องไม่เพิ่มเวลาของการส่งมอบหรือ deploy ระบบงาน

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