อ่านเจอบทความต่างๆ เกี่ยวกับ Enterprise DevOps ที่ EnterpriseDevOps.com
แล้วน่าสนใจมากๆ นำมาแปล และ สรุป เพื่อให้เข้าใจว่ามันคืออะไร
ทำไมเราต้องรู้จัก รวมทั้งมีแนวคิดดีๆ ที่ทาง website แนะนำไว้
เริ่มต้นศึกษากันเลยดีกว่า
ก่อนที่จะเริ่มศึกษาว่า Enterprise DevOps คืออะไร
มาดู trend ของคำว่า DevOps จาก Google Trend กันก่อน
จาก trend ก็จะเห็นว่าคำว่า DevOps นั้นมีแนวโน้มที่สูงขึ้นมากๆ ตั้งแต่ปี 2013
และในปี 2014 นั้นยิ่งเพิ่มขึ้นอย่างสูง ดังนั้นไม่ศึกษาไม่ได้แล้ว
Enterprise DevOps คืออะไร
คือ แนวปฏิบัติสำหรับวิธีการส่งมอบ software ที่ดีขึ้นกว่าเดิม
คือ การทำงานแบบ End-to-End หมายถึงตั้งแต่ requirement จนถึง การส่งมอบงานบน production เลย
คือ แนวปฏิบัติสำหรับการเชื่อมโยงสิ่งต่างๆ ที่ใช้งานเข้าด้วยกัน
คือ แนวทางการทำงานที่รวดเร็ว และ Lean
คือ การทำงานที่จะต้องเข้าใจ opertation requirement ของระบบว่าเป็นอย่างไร และทำให้มันง่ายต่อการ support และ deploy
คือ จะต้องเข้าใจข้อดีข้อเสีย ของสิ่งที่ทำว่าทำไมถึงต้อง Automated และไม่ทำ Automated
คือ จะต้องมีความรู้ความเข้าใจเกี่ยวกับแนวปฏิบัติที่ดีของนักพัฒนาด้วย
คือ การทำงานร่วมกัน เพื่อทำลายหรือไม่ให้เกิด silo ภายในองค์กร
คำว่า Automate นั้น รวมไปถึง
- Automate Code Testing
- Automate Workflow
- Automate Infrastructure
- โดยรวมก็คือ Automate ทุกๆ อย่างไปเลย
จะพบว่ามันมีอะไรมากกว่า คำว่า Development + Operation นะ
แล้วมันเกี่ยวกับเราตรงไหน
แน่นอนว่า วันหนึ่งคุณอาจจะขยายไปจนถึงระดับ Enterprise
ดังนั้น Enterprise นั้นจะต้องมาจาก StartUp อย่างแน่นอน
ถ้าคุณปฏิบัติตามแนวคิดนี้แล้ว จะทำให้คุณเติบโตอย่างรวดเร็ว และ ยั่งยืน
และไม่ทำให้เกิดลำดับชั้นที่ซับซ้อนภายในองค์กร
มี VDO อธิบาย DevOps ภายใน 2 นาทีด้วยนะ
และอีกหนึ่ง VDO จาก RackSpace
ยังไม่พอใน website มีคำแนะนำสำหรับการนำแนวคิด DevOps ไปใช้งาน 10 ข้อ
ในการทำงานนั้นส่วนใหญ่ๆ มักจะมองไปถึงเครื่องมือต่างๆ ที่นำมาใช้งาน
มองหา vendor ต่างๆ เพื่อมาช่วยสร้างระบบงาน
หรือลงทุนไปมากมายสำหรับการสร้าง DevOps ขึ้นมา
แต่ไม่เคยพูดถึงแนวปฏิบัติการทำงานว่าต้องทำอย่างไร ทำอะไรก่อน ที่จะไปมองเรื่องอื่นๆ
ซึ่งมีคำแนะนำ 10 ข้อดังต่อไปนี้ แต่ผมอธิบายเพียง 6 ข้อที่สำคัญในมุมมองของผมเท่านั้นนะ
1. กำหนดสิ่งที่ต้องการทำให้สำเร็จว่าคืออะไร และทำไม
สิ่งแรกที่สำคัญมากๆ คือ แสดงให้เห็นว่ามัน work นะ
การอธิบายด้วย powerpoint หรือ presentation สวยๆ นั้นไม่ได้ช่วยอะไรเลย
จนกว่าคุณจะลงมือทำมัน แล้วแสดงให้เห็นว่าสิ่งที่ทำไปมัน work นะ
ต่อจากนั้นให้ทำการเปรียบเทียบระหว่างรูปแบบเก่าและรูปแบบใหม่
ว่าแบบใหม่มันดีอย่างไร และขัดแย้งกับรูปแบบเก่าอย่างไร
เนื่องจาก คนส่วนใหญ่มักจะสนใจ เมื่อเห็นภาพและเข้าใจว่า สิ่งใหม่ๆ ที่จะทำนั้น
มันมีประโยชน์ต่อเขาอย่างไร
2. กำหนดจังหวะการทำงานของส่วนต่างๆ ในระบบของคุณ
อย่าคิดว่าแต่ละส่วนการทำงาน หรือ feature หรือ application ของคุณ
จะมีการพัฒนาหรือ deploy ในความเร็วที่เท่ากันหมด เป็นเรื่องที่อันตรายมากๆ
ดังนั้นคุณควรมาทำการกำหนดว่า แต่ละส่วนของงานในระบบนั้น
มีขั้นตอนการทำงานไปจนถึง production server อย่างไรบ้าง
ตัวอย่างเช่น แบ่งส่วนการทำงานเป็น 3 ระดับ คือ
- Fast เป็นส่วนการทำงานที่ไม่เกี่ยวข้องกับใครเลย สามารถจัดส่งได้รวดเร็ว และทำงานได้แบบอัตโนมัติ 100%
- Medium เป็นส่วนการทำงานที่ยังต้องไปเกี่ยวข้องกับระบบอื่นบ้าง แต่ยังต้องการทำ regression test ก่อนขึ้น production และคาดหวังว่าจะทำงานแบบอัตโนมัติทั้งหมด
- Slow เป็นระบบงานที่ต้องไปยุ่งเกี่ยวกับส่วนงานอื่นๆ ทั้งภายในและภายนอกองค์กรมาก เช่น ระบบ SAP, CRM, Payment, Financial เป็นต้น
เมื่อแยกส่วนการทำงานออกเป็นกลุ่มๆ แล้ว ต้องพยายามทำความเข้าใจระบบที่เกี่ยวข้องกันให้ดี
ต่อจากนั้นให้ทำการสรุปด้วยรูปภาพดังตัวอย่าง
จากภาพตัวอย่าง จะช่วยบอกเราว่า
- จะแยกส่วนการทำงานออกมาอย่างไรให้ดีขึ้นกว่าเดิม
- มีขั้นตอนที่ต้องทำงานแบบ manual อย่างไรบ้าง ก่อนจะนำขึ้น production server
- จะสร้าง Automated test ที่ดีขึ้นมาอย่างไร
- จะจัดการ configuration ต่างๆ อย่างไร ให้สะดวกสบาย
เมื่อเข้าใจและกำหนดการรูปแบบการทำงานของส่วนต่างๆ แล้ว
จะทำให้สามารถสร้างขั้นตอนการทำงานได้ดังรูป
3. ลดส่วนงานที่ขึ้นต่อกัน ( Kill Dependencies )
ก่อนอื่นต้องเข้าใจก่อนว่าระบบมันมีส่วนที่ dependency กันอย่างไร
จึงจะทำให้คุณสามารถควบคุมมันได้
ต่อจากนั้นเริ่มออกแบบและสร้างระบบที่แยกการทำงานออกจากกันอย่างชัดเจน
พยายามแยกทีมหรือคนที่ทำงานเพียงอย่างเดียวใน silo ของเขาออกมา
โดยให้เพิ่มหน้าที่ความรับผิดชอบเข้าไป เพื่อให้ทีมสามารถทำงานแบบ End-to-End ได้
สิ่งที่ต้องให้ความสำคัญอย่างมากก็คือ เมื่อมีการใช้งานพวก 3-party
แต่ก็สามารถลดปัญหาไปได้ด้วยการทำ Stub และ Mocking
ดังนั้นสามารถสรุปได้ว่า
Less Dependencies == Easier Testing
4. ให้เน้นเรื่อง MVP ( Minimum Viable Product ) อยู่เสมอ
สิ่งที่สำคัญก็คือ ว่าอะไรคือสิ่งที่ทำไปแล้ว สามารถเพิ่มคุณค่าให้แก่ลูกค้าของคุณ
ลองทำให้มัน work และทำการปรับปรุงสิ่งนั้นให้ดีขึ้นไปเสมอ
แน่นอนว่ามันเป็นการเปลี่ยนวัฒนธรรมขององค์กร รวมทั้งรูปแบบของ requirement อีกด้วย
ให้ความสนใจว่า DevOps นั่นคือ การทำงานตั้งแต่ขั้นตอนของ requirement จนไปถึง deploy ขึ้น production
5. ข้อควรระวัง DevOps มันจะส่งผลกระทบต่อโครงสร้างองค์กรของคุณมากนะ
มันจะกระทบตั้งแต่ Technology และ Architecture ที่จะเลือกใช้กัน
จะกระทบเรื่องการจ้างพนักงานเข้ามาทำงาน การจ่าย Bonus
จะกระทบเกี่ยวกับบัญชี การเงิน ในเรื่องงบต่างๆ
จะกระทบกับ Vendor และ Contract ต่างๆ
และจะกระทบต่อวิธีการทำงาน ที่จะต้องปรับปรุงให้ดีขึ้นอยู่อย่างเสมอ
ตัวอย่างดังรูป
6. อย่าให้ความสำคัญเพียงการdeployment แบบอัตโนมัติเท่านั้น
ขอย้ำว่า DevOps นั้น ให้ความสำคัญแบบ End-to-End นะ
ดังนั้นต้องให้ความสำคัญส่วนการทำงานต่างๆ ตั้งแต่ requirement จนไปถึง production
- Requirement ของคุณมีคุณภาพไหม เช่น requirement มีคุณสมบัติ INVEST หรือไม่
- Automated test ที่สร้างขึ้นมาไม่ใช้ตัวปัญหาใช้หรือไม่
- การทดสอบคุณสามารถรองรับระบบหรือการทำงานที่เพิ่มมากขึ้นได้หรือไม่
- การทำงานต้องรวดเร็วที่สุดเท่าที่จะเป็นไปได้ แต่มันต้องเป็นความเร็วที่อิงจากความเป็นจริงขององค์กรคุณด้วยนะ ไม่ใช่ไปเอาความเร็วมาจากที่อื่นๆ
สุดท้าย คุณต้องคิดอยู่เสมอว่า คุณจะต้องโตไปเป็น Enterprise อย่างแน่นอน
ดังนั้น ในการเลือกสิ่งต่างๆ มาใช้งาน ต้องคิด วิเคราะห์ แยกแยะ ให้ดี
- ทั้งการ เลือก technology
- ทั้งการ จ้างพนักงาน
- ทั้งการใช้งาน 3-party ต่างๆ
เนื่องจากสิ่งที่คุณเลือกในวันนี้ มันจะมีผลกระทบต่อคุณในอนาคตอย่างแน่นอน
ดังนั้นมาถึงตรงนี้ น่าจะพอทำให้เห็นว่า DevOps -> Enterprise DevOps เป็นอย่างไรนะครับ
