แนะนำ DevOps ในระดับหนังกำพร้า
เนื่องจากเมื่อสัปดาห์ที่ผ่านมา ผมได้เข้าร่วมอบรมหัวข้อ DevOps จาก คุณ somkiat.cc ที่คลุกคลีอยู่ในฝั่งการพัฒนาซอฟต์แวร์มานาน มีหลายๆ ประเด็นที่น่าสนใจ เลยจะเอามาฝากกันครับ แต่ต้องออกตัวก่อนว่า ผมไม่ใช่ผู้รู้ทางด้านนี้นะครับ เพียงแต่ได้เข้าอบรมและมีเพียงประเด็นบางส่วนเท่านั้นที่ผมเอามาเล่าให้ฟัง สำหรับใครที่รู้จัก DevOps เป็นอย่างดีอยู่แล้ว ก็สามารถแนะนำกันได้ครับ
DevOps นั้นยังไม่มีนิยามชัดเจน
ขอเริ่มต้นอย่างนี้ละกันครับ เนื่องจาก DevOps นั้นเป็นของใหม่ (แต่บางคนอาจจะรู้จักและคลุกคลีกับมันอยู่แล้ว) ค่าที่มันเป็นของใหม่ ทำให้แต่ละคนก็จะนิยามมันในมุมมองของคนคนนั้น ซึ่งแต่ละคนก็จะมองในมุมที่ต่างกันออกไป ไม่มีใครถูกผิดซะทีเดียว แค่อยากตกลงกันก่อนว่า ให้มองข้ามคำนิยามมันไปก่อน อย่าเพิ่งเถียงกันในประเด็นนี้ครับ ถ้าเราเข้าใจว่ามันมีประโยชน์ยังไงกับเรา ก็น่าจะใช้การได้อยู่
 |
| ภาพจาก: devopsdays.org |
คำนิยามของ DevOps ที่น่าสนใจจากผู้รู้ในแขนงนี้ มีหลายๆ ท่านอธิบายได้ใจความดี เราสามารถหาข้อมูลได้ครับ แต่ส่วนที่ผมจับประเด็นได้ก็คือ DevOps นั้นเป็นการทำงานด้วยวิธีที่ทำให้ นักพัฒนาสามารถส่งมอบคุณค่าได้รวดเร็ว โดยมีความน่าเชื่อถือมากขึ้น
ขั้นตอนของวิธีการแบบเดิมก่อน DevOps
ก่อนจะไปทำความเข้าใจ DevOps เรามารับทราบกันก่อน ว่าวิธีการพัฒนาซอฟต์แวร์ที่ใช้กันมาก่อนหน้านี้ (ในบางที่ยังใช้อยู่) มันมีปัญหายังไง ตรงจุดไหนบ้าง เราจะได้เห็นภาพว่า DevOps จะเข้ามาแก้ปัญหาเหล่านี้ได้ยังไง
 |
| ภาพจาก: mindtheproduct.com |
วิธีการพัฒนาซอฟต์แวร์ในรูปแบบเดิม จะมีการออกแบบขั้นตอนการทำงาน ตามหน้าที่รับผิดชอบ ดังนี้
- นักพัฒนา เขียนซอฟต์แวร์ตาม requirement ของ user ให้ทันตามกรอบเวลาของ project
- ทีมทดสอบ นำซอฟร์แวร์มาตรวจสอบ เพื่อดูว่าซอฟต์แวร์ทำงานได้ตามที่ควรหรือไม่ มี bug ของโปรแกรมตรงจุดไหนบ้าง
- ทีม deploy ซึ่งดูแลระบบ production อยู่ นำซอฟต์แวร์มาติดตั้งในระบบจริง เพื่อให้ end user เริ่มใช้งาน
- เมื่อเริ่มใช้งาน operation จะเป็นคนคอยแก้ปัญหา กรณีเกิดปัญหาขึ้น
ในโลกอุดมคติ ทุกอย่างจะเป็นไปตามขั้นตอน จนถึงการขึ้นระบบจริง ก็จะเป็นความรับผิดชอบของ operation ในการดูแล end user ให้สามารถใช้งานระบบใหม่นี้ได้อย่างราบรื่น ส่วนนักพัฒนาก็จะเริ่มพัฒนาซอฟต์แวร์ใน project ใหม่ๆ ต่อไป
ชีวิตจริง ยิ่งกว่าละคร
ในความเป็นจริงนั้น แต่ละช่วงของการถ่ายงานจะเกิดแรงเสียดทานในทุกๆ จุด สามารถยกตัวอย่างได้ ดังนี้
- การวางแผนโปรเจกต์ และการรายงานสถานะของโปรเจกต์ ทุกคนจะรายงานว่าทุกอย่างเป็นไปตามแผนตลอด จนถึงช่วงท้ายๆ ค่อยมาเจอปัญหาใหญ่ที่ทำให้ต้องเลื่อนเวลาออกไป
- นักพัฒนา บางทีไม่รู้ด้วยซ้ำว่า end user เป็นใคร และต้องการซอฟต์แวร์นี้เพื่อเป้าหมายอะไร จะมุ่งเน้นไปที่การทำตาม requirement ที่กำหนดมาให้ ให้ทันตามกรอบเวลา
- ทีมทดสอบ จะทดสอบโปรแกรมตามที่ถูกกำหนดไว้ ทำให้บางทีก็จะไม่พบปัญหาในการทดสอบ แต่พอ end user เริ่มใช้จริง กลับเจอ bug เพียบ
- ทีม deploy จะกังวลเมื่อมีเปลี่ยนแปลงระบบ กลัวว่าการขึ้นระบบใหม่ จะทำให้ระบบอื่นๆ ที่ทำงานได้ปกติ มีปัญหาไปด้วย จึงไม่ค่อยอยากให้มีการเปลี่ยนแปลงบ่อยๆ จึงกำหนดขั้นตอนที่ยุ่งยากขึ้นมา เพื่อไม่ให้ใครมาขอเปลี่ยนแปลงอะไรได้ง่ายๆ บางที่จะเปิดให้มีการเปลี่ยนแปลงตามรอบเท่านั้น เช่นปีละ 2 ครั้งเป็นต้น
- เมื่อการ deploy ระบบ เป็นวาระพิเศษที่ไม่ได้ทำบ่อยๆ ขั้นตอนการ deploy จึงมีโอกาสผิดพลาดได้ง่าย เช่น config ค่าไม่ครบ หรือลง component ไม่ถูกต้อง
- ทีม deploy เองก็ขึ้นระบบตามคู่มือที่ได้รับมาจากนักพัฒนาอีกที ซึ่งทางนักพัฒนาเองก็ไม่เคยยุ่งรับระบบ production คู่มือการ deploy ที่เขียนขึ้นมาอาจจะไม่ครบถ้วน
- ตอนพัฒนาโปรแกรม ทุกอย่างจะทำงานได้ปกติ แต่พอส่งซอฟต์แวร์ต่อให้ทีม deploy นำไปติดตั้ง จะเจอปัญหามากมาย เนื่องจาก environment ของนักพัฒนาไม่เหมือนกับ production
- การ deploy จะเป็นแบบ big bang เช่น เมื่อเปลี่ยนเวอร์ชันใหม่ หรือติดตั้งระบบใหม่ จะมีการเปลี่ยนแปลงเยอะมาก แต่ด้วยเวลาของ project ที่มีอยู่ ทำให้ไม่สามารถทดสอบได้ทุก feature จึงเกิดการเลือกทดสอบเฉพาะ feature สำคัญ ซึ่งพอขึ้นระบบไปแล้ว ก็จะเจอปัญหาอีก เพราะทดสอบไม่มากพอ
- ทีม operation เมื่อรับปัญหามาจากทาง end user แล้ว ไม่มีความรู้เพียงพอที่จะแก้ไขปัญหาให้ end user ได้ ก็จะส่งต่อให้นักพัฒนา ทำให้นักพัฒนาต้องเสียเวลามาคอยเก็บกวาดตรงส่วนนี้ ไม่มีเวลาไปทำ project ใหม่
จะเห็นว่า ในขั้นตอนเดิมนั้น ถึงแม้ว่าแต่ละตำแหน่งจะทำหน้าที่ของตัวเองได้อย่างดี เช่น นักพัฒนาก็สามารถส่งงานได้ตามเวลา คนทดสอบก็ทดสอบโปรแกรมผ่านทั้งหมด คน deploy ทำตามขั้นตอนที่เขียนในเอกสารครบถ้วน แต่ก็ยังมีปัญหาตามที่ยกตัวอย่างไว้ เรามาดูกันต่อครับ ว่า DevOps เสนอทางเลือกที่ดีกว่าให้เรายังไงบ้าง
แสงสว่างที่ปลายอุโมงค์
สิ่งที่ DevOps จะเข้ามาแก้ปัญหาเดิมนั้น คือการปรับกระบวนการทำงาน ซึ่งกระบวนการเหล่านี้ จำเป็นต้องมีการปรับทั้งวัฒนธรรมในการทำงาน (culture) และเครื่องมือที่ใช้ โดยมีหลักการคร่าวๆ ที่ผมเอามาจับคู่กับปัญหาได้ ดังนี้
ปัญหา: แต่ละคนทำงานส่วนของตัวเองได้ดี แต่ได้ระบบที่ไม่ดี
DevOps: เปลี่ยนจากการทำงานเป็นตอนๆ มาเป็นการทำงานร่วมกันเป็นทีม โดยให้ทุกฝ่ายมาร่วมรับ requirement จาก end user ด้วยกันตั้งแต่แรก เพื่อให้เข้าใจเป้าหมายของการพัฒนาซอฟต์แวร์ และเห็นภาพรวมของโปรเจกต์
culture ที่ต้องเปลี่ยนคือ เปลี่ยนจากความรับผิดชอบของเรา เป็นความรับผิดชอบของทีม ถึงแม้ว่าเราจะทำในส่วนของตัวเองได้ดีแล้ว ก็ต้องดูผลลัพธ์ของทีมด้วย
 |
| ภาพจาก: mindtheproduct.com |
ปัญหา: โปรเจกต์ถูกเลื่อน เนื่องจากเจอปัญหาใหญ่ที่ช่วงท้ายของโปรเจกต์
ปัญหา: ขึ้นระบบแล้ว end user เจอปัญหาที่ทีมงานไม่พบในการทดสอบ เนื่องจากทดสอบไม่มากพอ
ปัญหา: ขึ้นระบบแล้ว ได้ระบบที่ไม่มีใครอยากใช้งาน เพราะไม่ตรงกับความต้องการ หรือใช้งานยาก
DevOps: เปลี่ยนจากการวางแผนการ deploy แบบ big bang เป็นการพัฒนาเป็นรอบย่อยๆ โดยแต่ละรอบจะเลือกพัฒนาเฉพาะ feature สำคัญที่ถูกเลือกมาพัฒนาในรอบนั้นๆ ทำให้ทีมงาน สามารถส่งมอบคุณค่า เป็นซอฟต์แวร์ที่ใช้งานได้อย่างรวดเร็ว (แต่ทำงานได้ไม่ครบทุกอย่าง ความสามารถอื่นๆ จะค่อยๆ ตามมาในรอบถัดๆ ไป)
การพัฒนาเป็นรอบๆ จะช่วยให้ทีมงานสามารถทดสอบ feature ได้ละเอียดขึ้น คือเมื่อถึงรอบใหม่ ก็ทดสอบ feature ใหม่ให้ละเอียด ส่วน feature เดิมก็ทดสอบว่าทำงานได้ตามเดิม เมื่อทดสอบได้ละเอียด ก็จะพบปัญหาหลังจากขึ้นระบบ น้อยลง
การพัฒนาเป็นรอบๆ จะเป็นการปรับให้ต้อง deploy ระบบบ่อยๆ การ deploy ระบบเป็นประจำ จะบังคับให้ขั้นตอนการ deploy มีระบบชัดเจน เชื่อถือได้
การพัฒนาเป็นรอบๆ และส่งมอบไปถึง end user ทันที จะช่วยให้ทีมงานสามารถรับ feedback มาปรับปรุงซอฟต์แวร์ได้เลย ทำให้การพัฒนาเป็นไปตามที่ end user ต้องการจริงๆ
ในข้อนี้ culture ที่ต้องมีคือ ความโปร่งใส ไม่หมกปัญหา มีอะไรให้รีบบอกแต่เนิ่นๆ
ปัญหา: ตอนทดสอบในเครื่องนักพัฒนา สามารถทำงานได้ปกติ แต่พอขึ้นระบบแล้วเจอปัญหา ทำให้ระบบใช้งานไม่ได้ตั้งแต่วันแรก เนื่องจาก environment ในการพัฒนา ไม่เหมือนกับ production
DevOps: ตรงนี้ DevOps จะเสนอเทคโนโลยีเข้ามาช่วย โดยหลักๆ จะเป็นส่วนที่เกี่ยวข้องกับ environment ในการพัฒนาและการ deploy เช่น เทคโนโลยีกลุ่ม container ที่นักพัฒนาสามารถส่งมอบซอฟต์แวร์ไปในรูปแบบ container ที่มีสิ่งที่จำเป็นอยู่ในนั้นครบถ้วน เพื่อลดปัญหาในการ deploy
อีกส่วนหนึ่งจะเป็นขั้นตอนในการทำงานของทั้งทีม ที่จะต้องมีหลัก CI (Continuous Integration) เพื่อให้ทำงานได้ราบรื่น ส่งงานต่อกันได้แบบไร้รอยต่อ ซึ่งขั้นตอนที่ว่านี้ บางส่วนอาจจะเป็นการทำแบบ manual แต่ถ้าเป็นไปได้ ก็ควรจะทำเป็นระบบ automation ที่ขั้นตอนซ้ำๆ เราจะใช้เครื่องมือเข้ามาช่วยทำ เพื่อให้เกิดความรวดเร็ว และลดความผิดพลาดให้น้อยลง
CI เป็นหัวข้อใหญ่ที่เกี่ยวข้องกับ DevOps สำหรับผู้ที่สนใจ สามารถไปค้นคว้าเพิ่มเติมได้ แต่ผมขอไม่ลงรายละเอียดในที่นี้นะครับ
DevOps ไม่ใช่เครื่องมือ แต่ต้องมีเครื่องมือด้วย!?
สิ่งที่เราจะได้การ DevOps นั้น คือนักพัฒนาจะส่งมอบคุณค่า (ซอฟต์แวร์ที่มีประโยชน์กับผู้ใช้) ได้อย่างรวดเร็ว (ไม่ต้องรอนาน ไม่ต้องรอให้เสร็จทั้งหมด) และไว้ใจได้ (ขึ้นระบบแล้วไม่ล่ม ทดสอบ feature มาครบถ้วน)
ส่วนสิ่งที่เราจะต้องมีเพื่อจะเป็น DevOps นั้น เครื่องมือต่างๆ เป็นสิ่งสำคัญ แต่ไม่เพียงพอ เพราะทีมงานจะต้องมี culture ที่เหมาะสมด้วย เช่น ทำงานเป็นทีม ไม่หลอกตัวเอง ไม่หมกปัญหา เห็นความสำคัญของ end user ฯลฯ
หวังว่าบทความนี้น่าจะพอช่วยให้คนที่ไม่เคยรู้จัก DevOps มาก่อนเลย ได้รู้จักกับมันมากยิ่งและสามารถนำมาปรับใช้กับการทำงานของตัวเองได้ ไม่มากก็น้อยนะครับ
---
ความคิดเห็น
แสดงความคิดเห็น