จากบทความเรื่อง 5 Characteristics of a DevOps Organization
อธิบายคุณลักษณะของการนำ DevOps ไปใช้ในองค์กร มีเป้าหมายเพื่อ
- ปรับปรุงการทำงานร่วมกันให้ราบรื่นมากยิ่งขึ้น
- นำระบบการทำงานแบบ automation มาใช้มากขึ้น
- คุณกันบนพื้นฐานของข้อมูลและหลักฐาน มากกว่า gut feeling
- Fail fast และ Fail safe
จึงทำการแปลและสรุปไว้นิดหน่อย
มาดูว่ามีอะไรที่น่าสนใจบ้าง
1. Product-Based Teams Over Component Teams
บ่อยครั้งเราจะพบว่า ในการสร้าง product หนึ่ง ๆ นั้น
ต้องมีทีมจำนวนมาก มาพูดคุยกัน ตกลงกัน วางแผนร่วมกัน
แต่ละทีมก็ไปทำงานของตนเอง
เมื่อถึงวันที่กำหนดก็นำมารวมกัน
งานบางอย่างต้องขอ approve
งานบางอย่างต้องรอใครบางคน
เยอะไปหมด !!!
ต้องเสียเวลาไปมากกับการทำงานรูปแบบนี้
และก่อให้เกิด drama ต่าง ๆ มากมาย
เรามักเรียกว่า เป้นการทำงานแบบ silo
หรือบางที่อาจจะเรียกว่า component team
แต่การทำงานตามแนวคิด DevOps นั้น
เพื่อแก้ไขปัญหานี้ ดังนั้นจึงแนะนำให้ทำงาน
ในรูปแบบ cross-functional team หรือ product-based team
นั่นคือในทีมจะมีคนที่มีความสามารถต่าง ๆ
ที่ช่วยให้ส่งมอบ product นั้น ๆ ได้
โดยลดปัญหาที่เกิดขึ้นจากรูปแบบที่อธิบายมาก่อนหน้า
แสดงดังรูป
ปล. มีอีก component team คือ DevOps team หรือเปล่านะ ?
2. Obsession With Automation Over Preoccupation With Manual Work
เป้าหมายหลัก ๆ ของ DevOps คือ การลดงานที่ทำซ้ำ ๆ หรือพวก manual process
ให้มาอยู่ในรูปแบบ automation ให้มากที่สุดเท่าที่จะทำได้
(แต่ manual ก็ยังมี)
เพื่อลดงานที่ต้องทำ
เพื่อลดปัญหาที่เกิดจากคน
เพื่อเพิ่มความเร็วในการทำงาน
เพื่อเพิ่มความสะดวกในการทำงาน
ส่งผลให้เราไปทำงานอื่น ๆ ได้มากขึ้น
ต้องเลือกเครื่องมือให้เหมาะกับงานนั้น ๆ ด้วย
ไม่ใช่นำเครื่องมือที่ทำงานแบบ automation มาตั้งก่อน !!
3. Evidence-Based Over Gut feel
หัวใจของ DevOps คือการวัดผลในทุก ๆ อย่าง ที่ทำลงไป และเกิดขึ้นมา
ต้องมีตัวเลขที่วัดผลได้เสมอ
ทั้งในเชิง business, service และ infrastructure
นั่นคือ การคิดและวางแผน ก่อนทำงาน
เพื่อนำข้อมูลเหล่านี้ มาช่วยในการตัดสินใจ
ไม่ใช่การตัดสินใจจากความรู้สึก ประสบการณ์ หรือ gut feeling !!
4. Teamwork Over Individual Work
แน่นอนว่า DevOps ต้องการการทำงานเป็นทีม
และต้องมี teamwork มากกว่า การทำงานคนเดียวหรือฉายเดี่ยว
ดังนั้นแต่ละคนต้องมีความเป็นมืออาชีพ และ มีความสามารถพอตัว
แต่สิ่งสำคัญคือ คำว่า teamwork
ต้องรับผิดชอบในสิ่งที่รับมาและทำลงไป
รับฟังความคิดเห็นจากคนอื่น
เพื่อนำมาปรับปรุงและเพิ่มคุณภาพให้ดีขึ้น
เมื่อไม่เห็นด้วย ต้องแย้งกันด้วยเหตุและผล ไม่ใช้อารมณ์
5. Fail Fast Over Delayed Learning
ความผิดพลาดเป็นส่วนหนึ่งของการเรียนรู้
ประเด็นคือ ใช้เวลาหลังจากสร้างนานเท่าไร กว่าจะรู้ว่ามัน work หรือ ไม่ work ?
ยิ่งใช้เวลานานเพียงใด นั่นคือปัญหา
ส่งผลให้แต่ละคนไม่อยากทำผิดพลาด !!
ดังนั้นสิ่งที่ต้องสร้างให้เกิดขึ้นคือ
ความผิดพลาดมันต้องเล็ก ส่งผลกระทบน้อย
นั่นคือ ทุก ๆ ครั้งที่มีการเปลี่ยนแปลงเกิดขึ้นมา
เราต้องรู้ได้ทันทีว่า มัน work หรือ ไม่ work นั่นเอง
หมายความว่า fail fast และ fail safe ด้วย
ไม่ใช่หาคนมานั่งจับผิดนะ !!
แต่มันคือการพยายามสร้าง feedback loop ที่มีประสิทธิภาพ
และเป็นอีกทางหนึ่งที่ automation process เข้ามามีบทบาทสำคัญ
แต่ถ้า automation มันเข้ามาแล้วทำให้เรารู้ผลช้าลง
ก็ไม่น่าจะทำถูกนะเออ !!
