สรุปแนวคิดดี ๆ เกี่ยวกับ devops

จากบทความเรื่อง 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