เอาล่ะมาต่อกันด้วยบทที่ว่าด้วยการจัดทีม จัดโครงสร้างกัน
โดยหลักก็จัดได้ 2 แนว คือ
- Functional-oriented คือ แบ่งตามความชำนาญ เช่น Server, DB, network ซึ่งดั้งเดิมก็มักเป็นแบบนี้กัน หรือ
- Market-oriented คือแบ่งตามแนวธุรกิจ เช่น ทีมนึงทำ feature นึง ในทีมก็มีทุกคนที่ต้องทำ feature นี้
ปัญหาของ Traditional IT มักเกิดจากการที่แบ่งงานกัน functional oriented จนเกินเหตุ เช่น มีทีม Network, Server, DB แยกกันเด็ดขาด ซึ่งพอส่งงานข้ามทีมกันปุ๊บก็นานเพราะคุณก็ต้องเปิด ticket ไปรอคิว จัด priority จัดคนทำ แถมคนทำงานก็เห็นแค่ชิ้นเล็กๆที่ตัวเองทำก็ไม่เข้าใจภาพรวม
ในการทำเข้า DevOps จะส่งเสริมให้มาแนว Market-oriented และก็มีแนวคิดในการทำประมาณนี้
Type #1 เปลี่ยนไปใช้ Market-oriented teams แทนเลย ซึ่งแนวทางนี้จะมีคนหลายๆฟังก์ชันรวมกันอยู่ในทีมเดียวกัน บริษัทที่ใช้ก็เช่น Amazon, Netflix ทีนี้เราจะ market-oriented ได้ยังไง ก็โดยการเอาคน Ops ไปใส่ไว้เป็นคนนึงในทีม Dev หรือไม่ก็สร้างทักษะของ Ops ใส่เข้าไปในทีม Dev มันซะเลย ซึ่งถ้าเราเลือกวิธีใส่คน Ops เข้าไป ปัญหาที่มักจะเกิดคือเรามีจำนวนทีม Dev มากกว่าคน Ops ที่มี ก็ทำให้คนไม่พอ
Type#2 ถ้าเราจะเลือกไป DevOps โดยยังคง functional oriented มันก็ได้เหมือนกัน แต่ต้องแน่ใจว่าทีมมีเป้าหมายร่วมกัน และตอบสนองธุรกิจได้เร็วเหมือน Market-oriented โมเดลนี้ก็ใช้กันที่ Etsy, Google, Github ที่ยังใช้ส่วนของ Operation เป็น functional อยู่เพื่อประโยชน์เรื่อง expertise และในการทำให้ระบบมัน consistent กัน
ซึ่งเค้าก็เสนออีกรูปแบบที่เข้าใกล้ market-oriented โดยใช้ Ops liaisons (ผู้ประสานงาน) ซึ่งจะแต่งตั้งคนขึ้นมาทำหน้าที่แบบใดแบบหนึ่ง
- Business relationship manager — ต้องคุ้นกับผลิตภัณฑ์และธุรกิจ สามารถพา Ops จัด priority และดูแลจัดแจง request ได้ แนวนี้จะไม่ technical มาก
- Dedicated release engineer — รู้งานทั้ง Dev และ QA และสามารถทำงาน Ops ได้เองในงานทั่วไปที่ไม่ยากมาก ถ้าทำไม่ได้ก็หาความช่วยเหลือเพิ่มเติมจากทีม Ops หลัก เพื่อทำงานให้เสร็จได้
ซึ่งความยากคือใครมันจะเทพขนาดเข้าใจ Dev แล้วยังทำ Ops ได้ทุกแขนงและได้คุณภาพ ตรงนี้แหละคนที่จัดการ Ops ภาพรวมมีบทบาทอย่างยิ่งในการวางมาตรฐาน และทำ self-service platform ออกมาให้ง่ายต่อการใช้งาน เพื่อให้ release engineer หรือ Dev สามารถสั่งทำงาน Ops ได้เอง on demand โดยไม่ต้องไปเปิด ticket รอคิวงาน และได้งานที่มีคุณภาพเดียวกัน
เรื่องอื่นๆ
- ควรให้ Ops อยู่ใน standup ร่วมกับ Dev และมีงานของ Ops อยู่บน Kanban board ด้วย
- Testing, Operations, and Security as everyone’s job, everyday แนวคิดคือ ทุกคนต้องรับผิดชอบต่อคุณภาพงานที่ตัวเองทำ ไม่ว่าจะเป็น app quality, security มันไม่ใช่หน้าที่ของ QA, Sec แต่เป็นของทุกๆคนในแต่ละชิ้นงานที่ทำ
- ส่งเสริมให้ทุกคนในทีมเป็นคนรู้กว้าง เป็น generalist และทำทีมให้เล็กเข้าไว้ เค้าว่าไม่เกิน 2 ถาดพิซซ่า คือ 5–10 คน
Note: อันนี้เป็นสรุปจากการอ่านหนังสือ DevOps Handbook อาจมีผิดถูกบ้าง + มีคหสตบ้างเล็กน้อย ถ้าสนใจไปซื้อหาอ่านเล่มจริงกันต่อได้
ติดตามตอนอื่นๆ
