Learn DevOps ตอนที่ 2 : DevOps คืออะไร ?

Learn DevOps ตอนที่ 1 : จุดเริ่มต้นของการเปลี่ยนแปลง
→ Learn DevOps ตอนที่ 2 : DevOps คืออะไร ?
Learn DevOps ตอนที่ 3: หลักการของ Flow
Learn DevOps ตอนที่ 4: หลักการของ Feedback
Learn DevOps ตอนที่ 5: หลักการของการทดลองและเรียนรู้อย่างต่อเนื่อง

จากบทความตอนที่แล้ว เราพูดถึงประวัติศาสตร์และทฤษฎีต่างๆ จากวงการอุตสาหกรรมที่เป็นรากฐานสำคัญให้เกิด DevOps ขึ้นมา สำหรับบทความตอนนี้เราจะมาลงลึกถึงรายละเอียดกันว่า DevOps คืออะไร และมีประโยชน์อย่างไรต่อบริษัท

ปัญหาทั่วไปของหน่วยงาน IT

ความรวดเร็วในการปล่อย software ออกสู่ตลาดของบริษัทเป็นตัวสร้างความได้เปรียบทางการแข่งขันเหนือคู่แข่ง แต่จากตารางผลสำรวจปี 2012 ถึงความถี่ในการ ปล่อย software เพื่อเพิ่ม feature ใหม่ๆหรือแก้ไขปัญหาของระบบ พบว่าบริษัทส่วนใหญ่ใช้เวลาเป็นเดือนหรือไตรมาสถึงจะปล่อย software version ใหม่ออกสู่ตลาดได้ ในขณะที่บริษัท IT ชั้นนำสามารถปล่อย software โดยใช้ระยะเวลาแค่เป็นวัน ชั่วโมง หรือนาทีเท่านั้น

ที่มา : หนังสือ The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win

คำถามที่เกิดขึ้นคือเกิดปัญหาอะไร ทำไมบริษัทส่วนใหญ่ไม่สามารถปล่อย software ได้เร็วเท่าบริษัทชั้นนำ จุดเริ่มต้นของปัญหาเกิดจากสองเป้าหมายสำคัญที่หน่วยงาน IT จะต้องทำให้บริษัทนั่นก็คือ

• พัฒนาระบบให้ทันการเปลี่ยนของตลาดอย่างรวดเร็ว เพื่อคงความสามารถในการแข่งขัน
• ให้บริการระบบที่มีความเสถียร มั่นคง เชื่อถือได้ และปลอดภัยให้กับลูกค้า

ฝ่าย Development จะเป็นคนรับผิดชอบเป้าหมายในข้อแรก และฝ่าย Operations จะรับผิดชอบเป้าหมายในข้อถัดมา ปัญหาก็คือ การบรรลุเป้าหมายทั้งสองอย่างในเวลาเดียวกันเป็นเรื่องยากมาก เนื่องจากเป้าหมายทั้งสองขัดแย้งกันเอง หน่วยงาน IT ไม่สามารถ change ระบบด้วยความรวดเร็วในขณะที่ทำให้ระบบเสถียรไปพร้อมกันได้ เพราะการ change ระบบแต่ละครั้งอาจจะทำให้เกิดอันตรายต่อระบบได้ แม้ว่าจะ change เพียงเล็กน้อยก็ตาม ในกรณีนี้บริษัทจะมีทางเลือกสองทางคือ

1. ใช้เวลาในการพัฒนาและทดสอบระบบให้นานขึ้น เพื่อให้ระบบมีความเสถียรและปลอดภัย
2. เร่งพัฒนาและทดสอบระบบให้ออกใช้งานได้อย่างรวดเร็วที่สุด แต่อาจจะส่งผลกระทบต่อความเสถียรของระบบ และเกิดปัญหาได้ง่ายในภายหลัง

แน่นอนว่าถ้าเป็นระบบที่มีความสำคัญต่อธุรกิจสูง ส่วนใหญ่แล้วบริษัทจะเลือกทางที่สอง เพราะต้องการใช้งานแบบเร่งด่วน ซึ่งมีโอกาสเกิดสิ่งที่เรียกว่า technical debt มากกว่าทางแรก

คำว่า technical debt นั้นหมายถึงปัญหาสะสม ที่เกิดขึ้นจากการพัฒนาระบบในแนวทางที่ไม่ถูกต้อง ซึ่งจะใช้เวลาแก้ไขมากขึ้นและยากขึ้นเรื่อยๆ ถ้ายังปล่อยให้มี technical debt อยู่ในระบบ เหมือนกับหนี้ทางการเงินที่ถ้าไม่ไปใช้หนี้แล้ว ดอกเบี้ยทบต้นทบดอกก็จะสูงขึ้นเรื่อยๆจนกระทั่งไม่สามารถจ่ายหนี้ก้อนนั้นได้

เมื่อเกิด technical debt มากขึ้นก็จะเกิด incident และปัญหาอื่นๆตามมามากขึ้นเรื่อยๆ จนกระทั่งเราไม่มีเวลาที่จะทำงานอื่นๆ เพราะต้องเอาเวลามาแก้ incident ที่ไม่รู้ว่าจะเกิดขึ้นอีกเมื่อไหร่ การแก้ไข software เพียงเล็กน้อยอาจจะทำให้เกิดปัญหาอย่างคาดไม่ถึง การ change software แต่ละครั้งจึงทำได้ลำบากมากขึ้น ต้องใช้เวลาในการสื่อสาร ประสานงาน และมี change approval process มากขึ้นเพื่อรับประกันคุณภาพของ software ส่งผลให้บริษัทปล่อย software ออกสู่ตลาดได้ช้าลง

โดยสรุปแล้วการมีเป้าหมายที่ขัดแย้งกันระหว่าง Development และ Operations ทำให้บริษัทไม่สามารถสำเร็จเป้าหมายที่ต้องการปล่อย software คุณภาพสูงออกสู่ตลาดอย่างรวดเร็วได้

DevOps คืออะไร ?

DevOps คือรูปแบบวิธีการปฏิบัติ วัฒนธรรม และกระบวนการต่างๆ เพื่อแก้ไขปัญหาที่เกิดจากความขัดแย้งระหว่าง Development และ Operations ดังที่กล่าวมาแล้วในหัวข้อด้านบน รวมถึงช่วยเพิ่มประสิทธิภาพในการทำงานให้สามารถผลิต software ออกสู่ตลาดได้รวดเร็วขึ้น มีคุณภาพและเสถียรภาพมากขึ้น ในขณะที่ cost ลดลง เพื่อให้บริษัทสำเร็จตามเป้าหมายที่วางไว้

คำถามที่พบได้บ่อยๆก็คือบริษัทจะได้ประโยชน์อะไรเมื่อนำ DevOps ไปปรับใช้ จาก State of DevOps Report ปี 2016 ที่นำบริษัทที่ใช้ DevOps กับไม่ใช้มาเปรียบเทียบกัน ได้ผลลัพท์ดังนี้

• สามารถ deploy software ได้บ่อยกว่า 200 เท่า
• สามารถแก้ปัญหาที่เกิดขึ้นกับระบบได้ไวกว่า 24 เท่า
• สามารถลดอัตราล้มเหลวของการ change ระบบได้มากกว่า 3 เท่า
• สามารถลดเวลาในการผลิต software ได้มากกว่า 2,555 เท่า
• สามารถลดเวลาในการแก้ปัญหาด้าน security ได้มากกว่า 50%
• สามารถลดเวลาการทำงาน ทำให้พนักงานมีเวลาเพิ่มขึ้นมากกว่า 29 %
• สามารถลด cost ให้บริษัทได้มากกว่า จาก cost ที่เกิดขึ้นเมื่อระบบมีปัญหา และ cost จากการจ้างบุคลากร

3 หลักการสำคัญของ DevOps

ที่มา : https://www.dynatrace.com/resources/ebooks/devops-hidden-risks-and-how-to-achieve-results/

1. หลักการของ flow
   หมายถึงการปรับปรุง flow การทำงานหรือการส่งต่องานระหว่างหน่วยงานจากซ้ายไปขวาตั้งแต่ Business เริ่มคิด requirement ไป Development ไป Operations จนถึงลูกค้าให้ไหลไปอย่างราบรื่น และรวดเร็วที่สุด โดยลดขนาดของงานชิ้นใหญ่ เป็นชิ้นย่อยๆ แล้ว deploy ให้บ่อยขึ้น, การไม่ส่ง defect ไปที่หน่วยงานลำดับถัดไปเพื่อไม่ให้เกิดการแก้ไขและต้องส่งต่องานกลับไปกลับมา, การปรับปรุงงานโดยมองที่เป้าหมายหลักของบริษัทไม่ใช่แค่เป้าหมายของหน่วยงาน(เช่น Dev มองที่ความรวดเร็วในการพัฒนาระบบ Ops มองที่ความเสถียรของระบบ) นอกจากนี้ยังจำเป็นต้องมีวิธีการปฏิบัติอย่างเช่น continuous integration, การสามารถสร้างหรือจำลอง production environment ตามความต้องการ, การจำกัด work in process เป็นต้น
2. หลักการของ feedback
   หลักการนี้กล่าวถึง feedback ในแง่ของปัญหาระหว่างหน่วยงานจากขวามาซ้ายของทุกๆจุดในกระบวนการทำงานเช่นจาก Operations ไป Development ต้องค้นหาและแก้ไขให้ได้อย่างรวดเร็ว รวมถึงการป้องกันปัญหาไม่ให้เกิดขึ้นอีกเป็นครั้งที่สอง บริษัทสามารถทำสิ่งเหล่านี้ได้โดยสร้างคุณภาพตั้งแต่แหล่งที่มา (เช่นสร้างคุณภาพตั้งแต่ source code ของโปรแกรม) หรือสร้างองค์ความรู้ขึ้นมา นอกจากนี้ยังจำเป็นต้องมีวิธีการปฏิบัติอย่างเช่นการทำ automate test, การแก้ไขปัญหาทันทีเมื่อปัญหาเกิดขึ้น , การ monitoring ระบบให้ผู้เกี่ยวข้องสามารถเข้าไปดูได้ รวมถึงการแจ้งเตือนเมื่อระบบเกิดปัญหา
3. หลักการของการทดลองและเรียนรู้อย่างต่อเนื่อง
   เป็นหลักการเกี่ยวกับการสร้างวัฒนธรรมเพื่อสนับสนุนสองอย่าง อย่างแรกคือการทดลองสิ่งใหม่ๆเพื่อปรับปรุงกระบวนการทำงานซึ่งทำให้เกิดการเรียนรู้จากทั้งความสำเร็จและความล้มเหลว อย่างที่สองคือความเข้าใจว่าการปฏิบัติอย่างต่อเนื่อง เป็นหนทางสู่ความเชี่ยวชาญและความสำเร็จ การทดลองนำสิ่งใหม่ๆมาใช้เพื่อปรับปรุงการทำงานแบบเดิมๆจะมีประสิทธิภาพเพิ่มขึ้นเมื่อนำไปใช้กับหลักการของ feedback เพราะเมื่อเกิดปัญหาจากการทดลองก็จะได้แก้ไขปัญหาได้อย่างรวดเร็ว ส่งผลให้บริษัทเรียนรู้ได้อย่างรวดเร็วกว่าเมื่อเทียบกับคู่แข่งดังคำที่ว่า “fail fast win big” บริษัทสามารถทำสิ่งเหล่านี้ได้โดยสร้างวัฒนธรรมเรื่องความกล้าที่จะเสี่ยงที่จะเปลี่ยน(แทนที่จะกลัว) และสร้างความไว้ใจซึ่งกันและกัน รวมถึงออกแบบกระบวนการทำงานให้สามารถนำความรู้หรือความผิดพลาดที่เกิดจากการทำงานของพนักงานแต่ละคนไปกระจายให้พนักงานคนอื่นๆรับรู้ จนกลายมาเป็นองค์ความรู้ของบริษัทในที่สุด

ความเข้าใจผิดเกี่ยวกับ DevOps

1. DevOps มีไว้สำหรับ Startup เท่านั้น
   ในขณะที่ DevOps ถูกเริ่มต้นนำมาใช้โดยบริษัท Startup ระดับ “unicorn” (คือ Startup ที่มีมูลค่าเกิน 1 พันล้านดอลลาร์) อย่างเช่น google, amazon, netflix, etsy ในช่วงเวลาหนึ่งบริษัทเหล่านี้ก็เคยมีปัญหาเหมือนๆกับบริษัททั่วไป เช่นปัญหาจากการ release feature ใหม่ๆ ที่ไปกระทบ code เก่าทำให้ระบบทำงานผิดปกติ, ปัญหา release feature ช้าไม่ทันคู่แข่ง, ปัญหาจากการ scale ระบบ, ปัญหาการทำงานร่วมกันระหว่าง Development กับ Operations อย่างไรก็ตามบริษัทเหล่านี้สามารถที่จะเปลี่ยนแปลงสถาปัตยกรรมของระบบ, วัฒนธรรมและวิธีการปฏิบัติ และสร้างผลลัพธ์ที่สามารถเปลี่ยนแปลงโลกได้ ในเมื่อ Startup เหล่านี้ที่เคยมีปัญหาเหมือนบริษัททั่วไป นำ DevOps ไปใช้แล้วได้ผล บริษัททั่วไปก็สามารถนำ DevOps ไปปรับใช้ได้เช่นกัน
2. DevOps จะมาแทนที่ Agile
   DevOps สามารถใช้ร่วมกันกับ Agile ได้ หลักการบางอย่างของ DevOps ก็พัฒนาหรือเอามาจาก Agile การใช้ Agile ร่วมกันกับ DevOps จะช่วยเพิ่มประสิทธิภาพของกระบวนการพัฒนา softwareให้ดีขึ้นไปอีกอย่างเช่นใช้ Agile ในการพัฒนา idea ของ business ให้กลายเป็น software และใช้ DevOps ในการ deploy และการบริหารจัดการเมื่อ software อยู่ใน production environment (หมายเหตุ ​: ถึงแม้ว่าบริษัทจะไม่ใช้ Agile แต่ก็สามารถนำ DevOps ไปปรับใช้ได้)
3. DevOps ไม่สามารถใช้ร่วมกับ ITIL ได้
   DevOps สามารถใช้ร่วมกันกับ ITIL ได้ (Best Practices สำหรับ IT service management) อย่างไรก็ตามเพื่อที่จะสนับสนุน DevOps ที่เน้นเรื่องลดเวลาการออก Software สู่ตลาดและแก้ไข incident ให้ได้อย่างรวดเร็วแล้ว หลายๆกระบวนการของ ITIL จะต้องทำให้กลายเป็นแบบ Automation
4. DevOps ไม่สามารถใช้ร่วมกับหน่วยงาน Security และ Compliance
   การที่ DevOps ขาดในเรื่องของกระบวนการควบคุมบางอย่างเช่น เรื่องของ segregation of duty (คือการควบคุมเพื่อป้องกันการทุจริตและข้อผิดพลาดโดยแบ่งงานเป็นส่วนๆ แล้วมอบหมายให้คนอย่างน้อยสองคนรับผิดชอบ), change approval process หรือการที่ไม่มี security review ช่วงท้ายๆของ project อาจจะทำให้ Security และ Compliance รู้สึกตะขิดตะขวงใจอยู่บ้าง แต่อย่างไรก็ตามนั่นไม่ได้หมายความว่า DevOps ไม่มีกระบวนการควบคุมเลย แทนที่จะทำกระบวนการควบคุมในช่วงท้ายของ project
   DevOps เปลี่ยนวิธีใหม่โดยให้กระบวนการควบคุมเหล่านี้ไปแทรกอยู่ในทุกๆจุดใน software development life cycle แทน ซึ่งให้ผลลัพธ์ที่ดีกว่าในแง่ของคุณภาพและความรวดเร็ว
5. DevOps หมายถึงการยุบหน่วยงาน Operations หรือ NoOps
   หน่วยงาน Operations ยังคงมีความสำคัญแต่กระบวนการทำงานอาจจะเปลี่ยนแปลงไป และเข้ามายุ่งเกี่ยวกับกระบวนการพัฒนา software มากขึ้น เช่นช่วยสร้าง self-serviced platforms ให้ developer สามารถสร้าง environment และ deploy code เองได้ รวมถึงสามารถ monitor ข้อมูล production ได้ด้วยตนเอง
6. DevOps ต้องใช้ open source software เท่านั้น
   ถึงแม้ว่าบริษัทที่นำ DevOps ไปใช้และประสบความสำเร็จจะใช้ software อย่าง linux, apache, mysql, php, java แต่ว่าความสำเร็จของ DevOps ไม่ได้ขึ้นกับ technology ที่ใช้ บริษัทที่ใช้ Microsoft.NET, COBOL หรือแม้กระทั่ง embedded system ก็สามารถประสบความสำเร็จกับ DevOps ได้
7. DevOps คือแค่การใช้ Tools และการ Automation
   Tools และการ Automation เป็นแค่ส่วนประกอบหนึ่งของ DevOps เท่านั้น แต่สิ่งที่สำคัญมากกว่าก็คือ หลักการ, แนวคิด และกระบวนการ ที่ทำให้ทุกๆฝ่าย ทำงานเพื่อให้บริษัทสำเร็จตามเป้าหมายที่วางไว้

ในบทความตอนนี้เรารู้เรื่องราวปัญหาเป้าหมายที่ขัดแย้งกันระหว่างหน่วยงานภายใน IT ได้รู้ว่า DevOps คืออะไร และประโยชน์ที่บริษัทจะได้รับเมื่อนำ DevOps ไปปรับใช้คืออะไร ได้รู้ถึงความเข้าใจผิดเกี่ยวกับ DevOps หวังว่าผู้อ่านทุกท่านคงจะเข้าใจ DevOps กันมากขึ้น ในบทความตอนหน้าเราจะมาลงลึกรายละเอียดในเรื่องหลักการของ flow ซึ่งเป็น 1 ใน 3 หลักการสำคัญของ DevOps พบกันได้ใหม่ในตอนหน้าขอบคุณครับ

เอกสารอ้างอิง
หนังสือ DevOps Handbook : How to Create World-Class Agility, Reliability, and Security in Technology Organizations (2016). โดย Gene Kim, Jez Humble, Patrick Debois, John Willis.

หนังสือ The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win (2013). โดย Gene Kim, Kevin Behr, George Spafford.