สวัสดีผู้อ่านทุกท่านค่ะ วันนี้ DPM (Thailand) นำหัวข้อที่น่าสนใจมาก ๆ มาเล่าให้คุณผู้อ่านได้เข้าใจถึงการเปลี่ยนแปลงของ DevOps culture ที่กำลังจะถูกแทนที่ด้วย culture อื่น ทั้ง ๆ ที่เราเพิ่งจะรู้จักมันเมื่อไม่กี่ปีนี้เอง เพราะอะไร DevOps ถึงกำลังจะตาย? แล้วอะไรจะมาแทนล่ะ? แล้วเราจะต้องปรับตัวอะไรบ้าง? วันนี้เราจะมาเล่าให้ฟังค่ะ
ปัจจุบันนี้ AI, automation และเทคโนโลยี cloud ได้เข้ามาผลักดันวงการไอทีของเราให้เดินหน้าไปอย่างรวดเร็ว ทำให้องค์กรต่าง ๆ ต้องเริ่มปรับตัวให้เท่าทันโลกและความต้องการของผู้บริโภค ซึ่งทำให้การมี DevOps culture ในองค์กรเป็นเรื่องที่หลีกเลี่ยงไม่ได้อีกต่อไป
DevOps เป็น framework ที่มุ่งหมายให้องค์กรสามารถ delivery software ได้อย่างรวดเร็ว, ปลอดภัย และมั่นคง โดยการใช้เครื่องมือชุดหนึ่งในการพัฒนาและส่งมอบประสบการณ์ที่ดีให้แก่ผู้ใช้งาน ซึ่งจะต้องสามารถปิดช่องว่างในการทำงานร่วมกันของแต่ละทีม
เนื่องจากองค์กรต่าง ๆ เริ่มย้าย IT environment จาก on-premise ขึ้นไปอยู่บน cloud มากขึ้นอย่างมาก ทำให้ทีม development และทีม operation ต้องปรับตัวในการทำงานร่วมกัน การทำงานแบบ Silo จึงไม่เวิร์คอีกต่อไป ซึ่งคุณผู้อ่านอาจจะเคยได้ยินคำว่า “Breaking the silo” กันมาบ้างแล้ว สิ่งนี้ก็คือการเปลี่ยนผ่านการทำงานแบบเดิมที่เป็นแบบ silo สู่การใช้ DevOps framework เข้ามาแทนที่ กล่าวคือ เราจะไม่ทำงานแยกแผนกกันแบบชัดเจนอีกต่อไป ทุกคนจะต้อง collaborate กันได้โดยใช้เครื่องมืออะไรสักอย่างที่ทำให้ชีวิตของทุกคนง่ายขึ้น ไม่ต้องมานั่ง connect the dot ปะติดปะต่อเรื่องราวในองค์กรตัวเองอีกต่อไป
จากรายงานของ Dynatrace CIO report 2022 พบว่าองค์กรต่าง ๆ ใช้ monitoring tool เฉลี่ยอยู่ที่ 10 เครื่องมือ แต่สามารถตรวจสอบปัญหาที่เกิดขึ้น รวมไปถึงการสังเกตุการณ์และคาดการณ์ปัญหาจากต้นเหตุถึงปลายเหตุได้เพียงแค่ 9% เท่านั้น เนื่องจากต้องใช้เวลาในการตรวจสอบข้อมูลในเครื่องมือทุกเครื่องมือในขณะที่ปัญหาเกิดขึ้น ว่ามันบอกเราว่าอะไรบ้าง ข้อมูลที่ได้เรามาจึงมหาศาลมาก แม้องค์กรเราได้นำ DevOps เข้ามาใช้งานแทน ก็ยังอาจจะไม่สามารถแก้ไขปัญหาตรงนี้ได้
สมมติว่า องค์กรของเราเป็นสถาบันการเงิน การค้นหาและรวบรวมสาเหตุของปัญหาจากหลายเครื่องมือก็อาจจะไม่ทันการณ์ ลูกค้าเริ่มตั้ง hashtag ใน Twitter กันแล้ว ส่งผลไปถึงการสูญเสีย revenue ที่องค์กรควรจะได้รับขณะที่กำลังแก้ปัญหา แม้แต่ DevOps ก็ยังไม่เวิร์คเลย
แล้วเราจะทำอย่างไรกันดี?
Andreas Grabner, Dynatrace DevOps Activist และ Brian Wilson, Director of sales engineering ได้ถามคำถามนี้ในพอดแคสต์ของ PurePerformance ซึ่งใน session นั้นมี Stephen Thair, co-founder and former CTO of DevOpsGroup ร่วมด้วย และได้ตั้งข้อสังเกตของการเปลี่ยนแปลงไปของ DevOps culture ไว้ 3 ข้อ คือ
ข้อสังเกตที่ 1: หลักการของ Core DevOps กำลังค่อย ๆ เปลี่ยนแปลงไป ไม่ได้เปลี่ยนแปลงไปทั้งหมดแบบฉับพลัน
จุดประสงค์หลักของ DevOps คือการลดการทำงานแบบ silo หรือการทลายขอบเขต ของทีม development และทีม operation ให้น้อยลง หรือไม่มีเลย เพื่อให้การ delivery software เป็นไปได้อย่างมั่นคง (มั่งคั่ง) และยั่งยืน
ใน podcast ดังกล่าว Grabner ได้บอกไว้ว่า “ในบางกรณี เรายังคงต้องมีขอบเขตงานที่ชัดเจนและสัญญาที่แน่ชัดเพื่อแจ้งให้ทุกฝ่ายทราบว่าใครควรทำอะไรบ้าง ดังนั้น การการทลายขอบเขตระหว่างทีมทั้งหมดลง ก็อาจจะไม่ใช่วิธีที่เหมาะสม”
Thair ยังได้ให้ไอเดียเกี่ยวกับการแบ่งความรับผิดชอบในงาน software delivery ที่ไม่เพียงแต่ต้องทลายขอบเขตของทีม แต่ต้องเป็นการเพิ่มการร่วมแรงร่วมใจ (collaboration) ไม่ใช่การเป็นเจ้าของ (ownership) อีกด้วย
“หากเราย้อนกลับไปที่จุดเริ่มต้นของ DevOps และเรื่องการทลายขอบเขตของทีม (Breaking down the silo) ผมไม่คิดว่า ‘You built it, you run it’ จะเป็นแนวคิดที่สามารถจบปัญหาได้ทุกสิ่ง เพราะเรายังต้องการคนจากทีม operation มาทำงานร่วมกับคนในทีม development ใน war room เดียวกันอยู่ ไม่ใช่ว่าหากทีมนึงทำงานของตัวเองเสร็จก็หมดหน้าที่เลย”
ด้วยเหตุนี้ จึงทำให้ทีม development สามารถจัดการข้อจำกัดในด้านการปฏิบัติงานได้ก่อนเวลา และยังสามารถปรับปรุงให้ดียิ่งขึ้นได้อีกด้วย
Thair ยังได้อธิบายแนวคิด “designing for operations” โดยเปรียบเทียบกับการใช้รถยนต์ไว้ว่า
“เมื่อมีคนอยากจะเปลี่ยนชิ้นส่วนสักอย่างของรถที่ไม่ได้ซับซ้อนหรือยากมาก ผมต้องถอดชิ้นส่วนอื่น ๆ อีก 5 ชิ้นออก เพื่อให้พวกเขาเข้าไปเปลี่ยนชิ้นส่วนนั้นได้ง่ายขึ้น นั่นไม่ใช่การวางแผนที่ดีสำหรับการทำงานเลย” และได้ตั้งคำถามว่า “นักพัฒนาซอฟต์แวร์ จะทำอย่างไรให้เข้าถึงชิ้นส่วนที่มีโอกาสเสียหายได้ง่ายที่สุด?” เขาแนะนำว่า การแก้ปัญหานี้ คือการทลายกำแพงระหว่างทีม development และทีม operation ลง “เราต้องให้ทีม development เข้าใจสิ่งนี้ เพราะการที่เราย้าย product ไปอยู่กับอีกทีม ไม่ได้หมายความว่าพวกเขาไม่ต้องรับผิดชอบในการดูแล product ต่อไป”
ข้อสังเกตที่ 2: อนาคตของคำว่า “DevOps”
เมื่อความเข้าใจคำว่า “DevOps” ของเรากำลังเปลี่ยนไป ก็อาจจะมีคำถามเพิ่มเติมที่เราต้องอัพเดทตาม
“ถ้าเราพูดถึง Platform engineering vs SRE (Site reliability engineering) vs DevOps การพูดว่า DevOps แล้วนั้นก็อาจจะโลกสวยเกินไป เพราะในโลกความเป็นจริงนั้น DevOps ได้เปลี่ยนแปลงไปแล้ว” Wilson กล่าว
จริง ๆ แล้ว DevOps เป็นส่งเสริมการร่วมแรงร่วมใจกันระหว่างทีม development กับทีม operation เพื่อทำให้การ deliver software เป็นไปได้อย่างรวดเร็ว ส่วน Platform engineering (วิศวกรรมแพลตฟอร์ม) นั้น กลายเป็นการแก้ไขปัญหาเพื่อปิดจุดอ่อนของ DevOps โดยวิศวกรแพลตฟอร์ม (platform engineer) มีหน้าที่สร้าง workflow และออกแบบการทำงานร่วมกันของเครื่องมือต่าง ๆ เพื่อช่วยให้ผู้พัฒนาซอฟต์แวร์และทีม operation ทำงานร่วมกันอย่างไร้รอยต่อ เมื่อความต้องการของผู้บริโภคมากขึ้น DevOps ก็ต้องพัฒนาตาม ด้วยการนำ platform engineering มาใช้เพื่อทำให้ DevOps cycle เป็นไปได้อย่างราบรื่น
Wilson ได้เปรียบเทียบการเปลี่ยนแปลงไปของ DevOps กับ Observability หรือความสามารถในการสังเกตการณ์ โดยได้อ้างถึงการเริ่มต้นของ Dynatrace ที่สามารถตรวจสอบประสิทธิภาพของแอปพลิเคชัน เมื่อความสามารถในการสังเกตการณ์ กลายเป็นประเด็นร้อนที่ทุกคนพูดถึง
“ในตอนนั้น ส่วนประกอบหลักของการสังเกตุการณ์คือ metrics, logs และ traces” Wilson กล่าว “เราตื่นเต้นกับมันมาก แล้วอะไรคือความแตกต่างของมันล่ะ?”
คำตอบคือ “ความสามารถในการสังเกตการณ์ (observability) นั้นเป็นโมเดลที่ล้ำลึกกว่า metrics, logs และ traces มาก มันถูกสร้างมาจาก 3 องค์ประกอบพื้นฐาน แต่ถูกขยายไปมากกว่านั้นเพื่อตอบสนองความต้องการที่เปลี่ยนแปลงไป” Wilson กล่าวต่อ “จากแนวคิดเดิมของ Dynatrace ในวันนั้น ทำให้วันนี้เราได้เปลี่ยนจากการมองแยกทีละระบบ ไปเป็นการมองภาพรวมของระบบมากขึ้น”
Thair ได้ชี้ให้เห็นว่า ผลของการเปลี่ยนแปลงความหมายของ DevOps นั้น จะนำผู้คนหน้าใหม่มาสู่วงการนี้ อย่างไรก็ตาม เขายังได้แนะนำว่า การขยายความนี้อาจส่งผลกระทบต่อผู้คนที่ยังใหม่กับแนวคิดนี้บ้าง
ในช่วงท้ายของ webinar “Is DevOps dead?” นั้น Grabner ได้กล่าวว่า “เราเห็นด้วยว่าทุกคนต้องตระหนักถึงการเปลี่ยนแปลงนี้ เพราะเมื่อมีการเปลี่ยนแปลง ก็จะมีความสับสนตามมา หลังจากมีการเปลี่ยนแปลง ไม่ว่าจะเป็น 5, 10 หรือ 15 อย่าง เราน่าจะลองหาความหมายหรือศัพท์ใหม่เพื่อให้ผู้ที่เพิ่งเริ่มต้นสามารถเข้าใจสิ่งต่าง ๆ ได้ แทนที่จะต้องเริ่มใหม่จากศูนย์”
ข้อสังเกตที่ 3: องค์กรต่าง ๆ สามารถปรับตัวให้เข้ากับการเปลี่ยนแปลงของ DevOps ได้
ในขณะที่องค์กรต่าง ๆ ต้องเผชิญกับการเปลี่ยนแปลงของ DevOps ความสามารถในการปรับตัวสามารถช่วยให้เอาชนะอุปสรรคเหล่านั้นได้ ซึ่งหนึ่งในอุปสรรคนั้น เกิดขึ้นจากคำจำกัดความที่กว้างขึ้นของ DevOps หมายถึงความรับผิดชอบที่มากขึ้นตามไปด้วย
Grabner ได้เสนอตัวอย่างหนึ่ง ซึ่งเขาได้ทำการระดมความคิดเรื่องผลิตภัณฑ์ใหม่ และพิจารณาว่ามันมีคุณสมบัติอะไรที่จะทำให้ผู้ใช้งานพึงพอใจบ้าง ใครจะเป็นผู้รับผิดชอบในการพัฒนาบ้าง? ซึ่งการพัฒนานี้ต้องผ่านมือหลายทีม ตั้งแต่ product managers ไปสู่ product owner และ product architects และทุกการเปลี่ยนผ่านจากทีมสู่ทีม จะต้องเป็นไปอย่างราบรื่นและต้องมีผู้รับผิดชอบในทุก ๆ ขั้นตอน
Thair ได้ขยายความเรื่องความสำคัญของการหาสมดุลของธุรกิจ, software และองค์ประกอบต่าง ๆ ที่ส่งผลกระทบต่อประสบการณ์ของผู้ใช้งาน เขากล่าวว่า “Product manager ควรเป็นผู้ที่รบวมรวมความต้องการและข้อกำหนดต่าง ๆ ในการทำงาน ซึ่ง product manager นี้มีพื้นเพมาจากหลากหลายด้าน ไม่ว่าจะเป็นด้านธุรกิจ, เทคโนโลยี หรือด้านประสบการณ์ของผู้ใช้งาน และ Product manager ที่ดี จะต้องหาสมดุลระหว่างสามด้านนี้ให้ได้”
การนำ Site Reliability engineering culture มาใช้งาน ช่วยให้องค์กรต่าง ๆ พัฒนาไปพร้อม ๆ กับการเปลี่ยนแปลงไปของ DevOps ได้ เพราะ SRE มีจุดมุ่งหมายให้ทีม development และ operation ทำงานร่วมกันได้อย่างราบรื่น และลดการทำงานแบบซ้ำ ๆ ลงได้ โดย Site reliability engineer จะเน้นหนักในเรื่องของการทำงานแบบอัตโนมัติ (automation), ความพร้อมใช้ของแอปพลิเคชัน (application availability) และประสิทธิภาพ และช่วยตรวจสอบปัญหาล่วงหน้าในการพัฒนาซอฟต์แวร์
Thair ได้กล่าวว่า Site reliability engineer เป็นหน่วยงานที่สำคัญมาก เพราะการพัฒนา ไม่ใช่แค่การส่งมอบ code แต่ต้องเป็นการทำให้ระบบพร้อมใช้งานตลอดเวลา โดยพวกเขาจะลดการทำงานของผู้พัฒนาลง เพื่อให้ผู้พัฒนาสามารถทำงานของตัวเองได้อย่างมีประสิทธิภาพมากขึ้น
อนาคตของ DevOps
Digital Transformation หรือการเปลี่ยนผ่านสู่ยุคดิจิทัล จะส่งผลกระทบต่อ software delivery อย่างต่อเนื่อง จาก DevOps สู่ Observability ส่งผลกระทบโดยตรงต่อ software deliver practice ขององค์กรต่าง ๆ ที่ต้องเป็นไปอย่างรวดเร็ว, มั่นคง และปลอดภัย
การเปรียบเทียบมุมมองแบบเดิมกับแนวคิดแบบใหม่จะช่วยให้องค์กรสามารถก้าวทันการเปลี่ยนแปลงของโลก และสามารถเรียนรู้สิ่งใหม่ที่ทำให้เกิดผลประโยชน์สูงสุดได้