เรื่องที่ 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 มาใช้งาน
ดังนั้นเราได้เรียนรู้อะไรบ้าง
เพื่อจะได้ไม่ไปในทางที่ผิด ๆ อีกต่อไป
