จากบทความเรื่อง From DEVOPS to devops
ทำการอธิบายแนวคิดของ devops ไว้อย่างน่าสนใจ
เนื่องจากเมื่อมีการพูดถึง devops แล้วมักจะถามเรื่องต่าง ๆ ดังต่อไปนี้เสมอ
- องค์กรคุณมี devops ไหม ?
- องค์กรคุณเป็น devlops ไหม ?
- ทำการจับวัดประสิทธิภาพของ devops อย่างไร ?
- ใช้เครื่องมืออะไรกันบ้าง ?
ส่วนคำตอบนั้นลองให้คุณเขียนคำว่า devops ออกมาก่อนสิ
ว่ามีตัวพิมพ์ใหญ่กี่ตัว ?
เช่น DevOps หมายความว่า สนใจ Devlopment กับ Operation ใช่ไหม ?
แล้ว e, v, p, s มันไม่สำคัญหรือไง ?
ดังนั้นเราควรทำความเข้าใจกับ DEVOPS แบบนี้กันก่อนนะ
Don’t start with a rename
Evolve your thinking
Variable reduction
Obliterate silos
Prevent the hero
Share the pain
Don’t start with a rename
ไม่ใช่การเปลี่ยนชื่อแผนก หรือ ทีมนะ
เช่นเปลี่ยนจาก operation team มาเป็น devops team
แต่ยังทำงานเหมือนเดิมกับการใช้เครื่องมือใหม่ !!
Evolve your thinking
มันคือเรื่องของกระบวนการคิดที่ดีขึ้น
มันไม่ใช่เรื่องของ automation หรือ การทำงานแบบอัตโนมัติ
แต่มันคือ การสนับสนุนความต้องการของทาง business และ ลูกค้า
ซึ่งลูกค้านั่นประกอบไปด้วย ผู้ใช้งานทั่วไปรวมไปถึงทีมอื่น ๆ ในองค์กร
ถ้ามี devops ไปโดยไม่ได้ให้ความสนใจ และ ใส่ใจ
ว่าจะสนับสนุน business และ ลูกค้าอย่างไร
ก็อย่าทำเลยดีกว่า มันเสียเวลาโดยเปล่าประโยชน์
Variable reduction
ลด ล่ะ เลิก ความหลากหลาย
ยิ่งน้อยยิ่งเรียบง่ายยิ่งจัดการได้ง่าย
ลองคิดดูสิว่า
ถ้าต้องดูแลระบบปฏิบัติการหลากหลาย version
ถ้าต้องดูแลระบบฐานข้อมูล 5 ชนิด
สิ่งที่ต้องทำคือ ลด ล่ะ เลิกซะ
ลดให้เหลือน้อยที่สุด หรือ หนึ่งอย่างไปเลย
รวมทั้งลดปัญหาต่าง ๆ ที่พบเจอลงไปให้มากที่สุด
เพื่อช่วยเพิ่มคำว่าคุณภาพให้มันสูงขึ้นมา
ถ้าเทียบกับการเขียน code คือ ลดเส้นทางการทำงานของ code
หรือลดความซับซ้อนของ code ลงไปนั่นเอง
อย่าพยายามหาเครื่องมือเพื่อมาช่วยจัดการความซับซ้อน
แต่พยายามลดความซับซ้อนก่อนนำเครื่องมือมาใช้งาน
Obliterate silos
ทำลายกำลังของคนในทีม และ ระหว่างทีมซะ
เช่น
- ทีมดูแล network
- ทีมดูแล firewall
- ทีมดูแล DNS
- ทีมดูแล web server
- ทีมดูแล database server
- ทีมดูแลการ deploy
และทีมต่าง ๆ ที่สร้างขึ้นมาจากปัญหา !!
แต่ให้ลองหยุด และ กลับมามองว่า
มีงานอะไรบ้างที่ต้องทำซ้ำแล้วซ้ำอีก
ปรับเปลี่ยนให้ทำงานแบบอัตโนมัติดีไหม
เช่นการแก้ไข configuration และ การ deploy ระบบงาน เป็นต้น
มีงานอะไรที่ต้องส่งต่อกันเป็นทอด ๆ เยอะ ๆ บ้างไหม ?
หาทางลดขั้นตอนการทำงานลงไปไหม ?
นั่นคือ การลดกำแพงต่าง ๆ ของการทำงานลงไป
Prevent the hero
นี่คือเรื่องของวัฒนธรรมของทีม และ องค์กรนั่นเอง
ควรทำงานเหมือนกับ ทีมกีฬา
ที่ทุกคนภายในทีมจะต้องช่วยเหลือซึ่งกันและกัน
เก่งคนเดียวไม่ช่วยทำให้ทีมชนะได้ !!
มีปัญหาก็ต้องช่วยกันแก้ไข
Share the pain
แบ่งปันความเจ็บปวด
อย่าเก็บปัญหาไว้กับทีม และ ตัวเอง
เพื่อทำให้เห็นว่า ปัญหามันมาจากตรงไหนกันบ้าง เช่น
- Development
- Deployment
- Monitoring
เพื่อทำให้เห็นตรงกันว่า ควรจะปรับปรุงส่วนไหนกันบ้าง
ไม่ใช่ทำงานไปตามความรู้สึก !!
สุดท้ายแล้วแนะนำให้เขียน devops เป็นตัวเล็กทั้งหมด
เพื่อให้เข้าใจว่า มันคือคำ ๆ หนึ่ง คำธรรมดาทั่วไป
ไม่ต้องทำการตีความ
ไม่ต้องมาทำการจับวัด
เพียงกลับไปดูว่า devops ของคุณผ่านทุกข้อจากข้างต้นหรือไม่ ?
ถ้าต้องการ checklist เกี่ยวกับ devops สามารถดูเพิ่มเติมได้ที่ devops checklist
