6 สิ่งที่ช่วยให้ทีม application ทำงาน เร็วขึ้น ดีขึ้น และถูกลง

ยุคนี้เป็นยุค IT Transformation เฟื่องฟู ผมได้คุยกับ Head of delivery มาหลายคน แต่ละคนฝันไปไกล มี mission จะทำอย่างโน้นอย่างนี้ แต่ที่ติดเลยก็คือเรื่อง scale คนเก่งๆ มันก็ไม่ได้มีเยอะ ทำให้ bandwidth ก็ไม่เยอะ แต่งานเยอะ ถ้าเอาเร็วและถูก ก็ไม่ได้ของดี แต่ถ้าจะเอาของดี ก็ต้องเลือกว่าจะเอาเร็ว หรือเอาถูก

สมมติฐานนี้ไม่ได้ถูกเสมอไป มี presentation ของ Damon Edwards และ John Willis ซึ่งถูก vote ว่าเป็น best DevOps presentation of the year เค้าได้ไปศึกษาองค์กรต่างๆ และพบว่ากลุ่มที่เป็น high performer เค้าสามารถทำให้งานพัฒนาสามารถทำได้เร็วกว่า ดีกว่า และถูกกว่าในคราวเดียวกัน พวกเค้าทำได้อย่างไร? ครั้งนี้ผมจะขอยำเนื้อหาใน presentation นี้ มาให้อ่านกัน

  1. ปรับรูปแบบทีม

ถ้าคุณอยู่ในแวดวง devops คุณอาจจะได้ยินคำว่า “You build it, you run it” กล่าวโดย Werner Vogels CTO ของ Amazon ในองค์กรทั่วไป เรามักจะแยกทีมตาม function เวลาที่แยกทีมออกจากกัน ทุกคนก็จะสนใจ area ของตัวเอง ตัว dev เองอาจจะไม่ได้ aware ถึงปัญหาบน production และต่อให้ aware ก็ไม่ใช่คนที่รับผิดชอบปัญหา การให้ dev คุยกับลูกค้าโดยตรง เป็นการเร่ง feedback loop ให้ dev aware ถึงปัญหามากขึ้น และรับผิดชอบปัญหามากขึ้น ในขณะเดียวกัน ก็ให้ทีม dev นี่แหละวางแผนเองด้วย ทำให้ dev เข้าใจ business intent มากขึ้น

โดยทีมแบบ high performer จะเป็นรูปแบบนี้

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

2. งานบน production ไม่ใช่แค่เรื่องของ app

ทีมทั่วๆ ไปสนใจแต่ทำ app ให้เสร็จ ส่วนเรื่องของการ deploy การทำ automation ต่างๆ ถือว่าเป็นอีก process นึง ในขณะที่ทีม high performer เรื่องของ run-time (env spec, automation, run-book) จะอยู่ใน source control มี process การ review มีการทำ version เดียวกันกับ app

การมี CI/CD มีระบบ monitoring มีตัว run-time ที่สามารถ program ได้ นี่เป็นแค่พื้นฐาน คุณต้องสามารถ ทำให้ทั้ง value stream มอง app และ run-time เป็นงานชิ้นเดียวกัน และผลลัพธ์คุณก็จะได้ app และ run-time ในรูปแบบ self-contained ที่คุณจะสามารถ ทำซ้ำ ทดสอบ ในรูปแบบที่ใกล้เคียง production ได้มากที่สุด

3. ทำให้คนทำงานเห็น flow

DevOps จะมองทุกอย่างเป็น flow และคุณควรจะต้องสามารถมองเห็นว่า flow ของคุณติดขัดที่ตรงไหน ทีมทั่วๆ ไปจะสนใจแค่ business และ software architecture ไม่ได้สนว่าการทำงานจะ flow ได้อย่างไร แต่ high performer จะรู้ว่า ตั้งแต่ business requirement ไปยัง production มีขั้นตอนอะไรบ้าง และจะมีเครื่องมือชี้วัด เพื่อให้คนทำงานรู้ได้ว่า จุดไหนที่ควรเปลี่ยน จุดไหนที่ควรแก้

และในระดับองค์กรที่ทำ business transformation ก็ควรจะมี flow ในระดับภาพรวมที่ transparent เพราะปกติแต่ละทีมไม่ได้สนใจ flow แต่สนใจ org chart ในขณะที่ high performer สนใจ flow แล้วค่อยดูว่าจะสร้าง org chart ที่สนับสนุน flow นั้นอย่างไร

4. Immutable delivery

จะว่าไป DevOps นี่ก็เอา concepts ของ Toyota ไปเยอะเหมือนกัน principal ข้อนี้ก็เหมือน 4VL ของ Toyota

  • Variability: ตามหลักการของ immutable delivery คือตั้งแต่ dev environment ไปยัง production ก็ควรจะเหมือนกันทุกอย่าง ถ้าใครยัง deploy มือโดยใช้ checklist ก็ถือว่าสอบตก แต่ถ้าสามารถรวม run-time เข้ากับ app และสามารถ deploy ชิ้นงานแบบเดียวกันทุกๆ environment ได้แล้วละก็ถือว่าผ่าน
  • Visibility: และเมื่อ package ของเราเป็นแบบ immutable เราก็จะสามารถมอง app ของเราเป็นแค่ Lego ชิ้นเดียว และเราก็จะสามารถมอง flow ภาพรวมได้ง่ายขึ้น
  • Velocity: ถ้าคุณสามารถทำ immutable delivery ได้ ก็แปลว่าคุณต้องมี automation ซึ่งเร็วกว่ามือแน่นอน แต่ถ้าจะให้ดี pipeline build/deploy มันต้องอยู่ในระดับวินาที หรือไม่กี่นาที มากกว่านั้นถือว่าเป็น friction แล้ว ลองใช้ container technology อย่าง Docker ดู
  • Variety: และถ้าคุณสามารถสร้างได้เร็ว คุณก็สามารถเล่นกับมันได้เร็ว และคุณก็จะเรียนรู้จากมันได้เร็ว

5. Microservices

Microservices ไม่ใช่แค่มี service หลายๆ ตัว ถ้าคุณยังมี release plan เดียวกัน มันก็เป็น monolithic

Microservices ควรจะอิสระจากกัน ทีมไหนอยากจะ deploy feature เดียวก็ทำได้ทันที ไม่มีคอขวดที่จะต้องรอส่วนที่ไม่เกี่ยวข้อง deploy ไปพร้อมกัน โดยจุดหลักคือ แต่ละทีมสามารถทำงานแยกกันได้แบบ parallel

อีกจุดนึงก็คือเรื่องของ platform standardization ทีมแบบเก่ายังเชื่อว่า platform ต้องเป็น platform เดียวกัน แต่ถ้าองค์กรคุณเป็นแบบ microservices การใช้ technology เดียวกันทำให้องค์กรเชื่องช้า technology มันหมุนเร็วมาก มีของใหม่ๆ มาให้เล่นได้ทุกเดือน ปล่อยให้ทีมใช้ของที่ชอบที่เค้าถนัด แล้วมาคุยกันผ่าน interface ดีกว่า

6. คนสำคัญที่สุด

โดยรวมขององค์กร คนก็คือ input ของระบบ ดังนั้นสิ่งที่จะสร้าง competitive advantage ได้ก็คือ คน

ใน list ด้านบนสิ่งที่ทำให้พนักงาน เบื่องาน ไม่มีประสิทธิภาพ แปลเป็นไทยดังนี้

  • งานหนัก
  • ไม่มีส่วนร่วมในการตัดสินใจ
  • ผลตอบแทนน้อย (ไม่ว่าจะเป็นเงิน recognition หรือคำชมเชย)
  • workplace environment ไม่ดี (ที่นั่งไม่ดี เครื่องช้า จอเล็ก)
  • ไม่แฟร์ (เห็นบ่อยๆ ก็เรื่อง promote)
  • ความเข้ากันได้กับองค์กร

ถ้ารู้ว่าองค์กรเรามีอะไรไม่ดี ก็หาทางลดมันซะ