ทุกคนคือ DevOps เพราะ Culture & Mindsets คือพวกเรา!
Digital Transformation ไม่ใช่แค่ธุรกิจ
DevOps ปัจุบันคำนี้ถือว่าเป็นคำที่เพื่อนๆในแวดวง IT ย่อมต้องได้ยินกันอย่างแน่นอนว่า DevOps คือแนวคิดเรื่องการประสานงาน Developer เข้ากับ Operational ให้มีความลื่นไหลตลอด Life Cycle แต่จริงๆแล้วก็ไม่ได้ถือว่าเป็นอะไรที่ใหม่มากเพราะก็มีมาประมาณตั้งแต่ช่วง 2010s แล้วสำหรับในตลาด IT เมืองนอก (Ansible มาตั้งแต่ปี 2012 นู้นนน) เพียงแต่ว่าในประเทศไทยอาจจะเป็นช่วงที่ได้รับความนิยมมากขึ้นเพราะเป็นช่วงที่หลายๆองค์กรทั้ง Startup และ Enterprise ใหญ่ๆกำลังเข้าสู่ Digital Transformation กันอย่างเต็มตัวไม่ว่าจะเป็นอุตสาหกรรมธนาคารอย่าง SCB ที่เริ่มมีการเปิด Open API ให้ Third Party เข้ามาต่อ API การชำระเงินการธนาคารได้ โดยไม่ได้เป็นระบบปิดอีกต่อไปหรือ Startup ซึ่งมาการปล่อย Features ใหม่ๆออกมาเพื่อตอบโจทย์ความต้องการของผู้ใช้งาน ที่ต้องการอะไรรวดเร็วมี Feedback Loop ไวๆ
ซึ่งที่นี้ถ้าเราจะกลับมามองที่ว่า DevOps นั้นเกี่ยวข้องอะไรกับ Digital Transformation ภายในองค์กร ? ก็ต้องลองย้อนกลับไปที่ในมุมของธุรกิจที่ขับเคลื่อนด้วยระบบ IT เป็นหลักอย่างธนาคารที่ต้องมีระบบบันทึก Transaction การเงินลง Database เชื่อมต่อชำระเงินผ่านระบบ Online ที่มีจำนวนผู้ใช้ Concurrent พร้อมกันมากๆการให้ระบบล่มนั้นถือเป็นสิ่งที่ยอมไม่ได้เลย และในขณะเดียวกันก็ต้องมีการนำ Features ใหม่ขึ้นๆในระบบ เพื่อตอบสนอง Business Model ขององค์กรเช่นเดียวกันด้วย แล้วจะทำอย่างไรให้ Enterprise ใหญ่ๆเหล่านี้สามารถ Delivery Features ใหม่ๆได้อย่างรวดเร็วในขณะเดียวกันก็มีเรื่องของ Operational ที่ Available ตลอดเวลาให้สอดคล้องกับ Service Level Agreement ด้วยเช่นกัน ?
นั่นก็คือเราต้องมาทำการเข้าใจปัญหาที่อยู่ในองค์กรเราก่อนว่าปัจจุบันนั้นการทำงานของ Enterprise ใหญ่ๆในบางที่ที่กำลังอยู่ในช่วง Transform ตัวเองใสามารถเข้าไปแข่งกับยุค Digital ซึ่งต้องใช้ IT และความรวดเร็วเป็นหลักมีปัญหาอะไรบ้าง ?
สิ่งที่เรามักจะพบเลยก็คือฝ่าย Development Team ซึ่งเป็นทีมสร้างโปรแกรมหรือออกไอเดียใหม่ๆในการสร้าง Features ให้กับองค์กร ไม่ว่าจะเป้นการเขียนโปรแกรมบนมือถือการสร้าง API หรือการแก้บั้คการประมวลผล Analytics ต่างๆนั้น ตัวชี้วัดความสำเร็จก็คือการ “สร้างสิ่งนั้นสำเร็จ” ยิ่งมี Features มากเท่าไหร่ก็ยิ่งสะท้อนถึงประสิทธิภาพของทีม Development มากเท่านั้น แต่เมื่อเรากลับมาดูที่ Process ขององค์กรจะพบว่าต้องการเรื่องของการทำ Document ที่ชัดเจนซึ่งมีความซับซ้อนผ่านการอนุมัติขั้นตอนต่างๆมากมาย กว่าจะสามารถนำโปรแกรมที่พัฒนามาขึ้นไปปล่อยใช้งาน Deploy ได้ ซึ่งเมื่อได้รับโปรแกรมมาแล้วฝ่าย Operational ที่เป็นทีมดูแลเรื่องของ Infrastructure Network ในองค์กรก็จะต้องนำโปรแกรมเหล่านี้ขึ้น Server และค่อยทำการ Deploy แบบ Manual ด้วยตนเอง ซึ่งตรงจุดนี้สังเกตว่าการที่โปรแกรมจะผ่านขั้นตอนเอกสารมาได้ก็อาจจะผ่านเวลาหลายสัปดาห์และกว่าจะถึงขั้นตอนของทีม Operational นำระบบขึ้น Server หรือไปขึ้น Cloud ก็ยังมีช่วงเวลาที่ต้องรอคอยอีกอาจจะเป็นขั้นต่ำ 2 อาทิตย์หรืออาจจะกลายเป็นหลักเดือนเลยก็เป็นไปได้ ซึ่งแน่นอนว่ากว่า Developer จะมีการขอ Deploy Feature ก็อาจจะเป็นทุกสามเดือนครั้ง หรือบางทีอาจจะสร้างมาปุ๊ปแล้วก็ปล่อยให้มันรันยาวๆไปเป็นปีไม่มีแก้บั้คใดๆ
ปัญหานั้นไม่ได้อยู่เพียงแค่การมี Features เพราะขั้นตอนการทำ Process แบบ Waterfall Traditional เพียงอย่างเดียวแต่ปัญหาจะมาเกาะอยู่ในส่วนของ Technical ด้วยเช่นกันซึ่งการที่ Application ของเรามีการเปลี่ยนแปลงครั้งล่ะมากๆทำให้เกิดปัญหาเรื่องของ Compatibility ที่จะมี Breaking Change เยอะซึ่งอาจจะส่งผลไปยัง Infrastructure ที่เคยเตรียมไว้ด้วยเช่นกัน และทำให้ทีม Operational เองก็ไม่ทราบว่าจะตรวจสอบปัญหาได้จากที่ใดเพราะว่ามีการเปลี่ยนแปลงที่มากเกินไปในเมื่อถึงเวลา Upgrade Version ของ Applciation ดังนั้นการแก้ปัญหาที่ควรจะเป็นคือการ อัพเดทโปรแกรมของเราทีล่ะน้อยๆแต่บ่อยๆ เพราะเมื่อเราค่อยอัพเดทจะทำให้เราสามารถ Indentify กลับไปยังต้นตอของปัญหาที่เกิดขึ้นได้ง่ายขึ้น เพราะเราเองก็ทราบว่าการเปลี่ยนแปลงเหล่านั้นส่งผลกระทบต่อ Component ใดๆในระบบบ้าง ทำให้เราสามารถ Mitigate ปัญหาเหล่านั้นได้ง่ายขึ้น เสมือนการปลูกต้นไม้ที่เราค่อยๆปรับสูตรสารอาหารไปทีล่ะส่วนๆให้เหมาะสม ย่อมดีกว่าการทำตามสูตรครั้งเดียวจำนวนมากๆแล้วไม่มีสังเกตว่าต้นไม้ที่เราปลูกนั้นเราแร่ธาตุหรือสารอาหารส่วนใดมากเกินไปหรือไม่
ผลของการปรับเปลี่ยนทีล่ะน้อยยังทำให้ฝ่าย Operation สามารถเตรียม Infrastructure ได้อย่างเหมาะสมอีกด้วยว่าจะต้องการ Network เพิ่มหรือขยาย Hardware สำหรับ Computing เพิ่มมากแค่ไหน ซึ่งการที่เราค่อยๆทดสอบการเปลี่ยนแปลงทีล่ะน้อยๆทำให้เราทั้งสองฝ่ายคือ Developer ที่ผลิต Features และ Operational ที่ทำหน้าที่การันตีรับรองการใช้งานให้มีความ High Available ไปตาม SLA ที่กำหนดไว้ เข้าใจกันมากขึ้นอีกด้วย
เพราะปัญหาของการทำงานโดยแยกเป็นฝ่ายใครฝ่ายมันทำให้เราไม่สามารถทราบถึงปัญหาเหล่านี้ได้เลยว่า Application ที่พัฒนานั้นมี Bugs ที่เกิดจากการเขียนโปรแกรมของ Developer เองหรือเกิดจาก Infrastructure ที่ไม่รองรับการ Breaking Change ใหม่ๆของ Application ที่ต้องการ Software, OS ใหม่ๆมากันแน่
ดังนั้นหลังจากที่เราเข้าใจถึง Context และข้อเสียจากการทำงานแบบ Silo Based ไปแล้วทีนี้เราจะมาดูกันว่าแล้วเรื่องราวกับแนวคิดใดบ้างที่การจะมุ่งไปสู่คำว่า DevOps มีอะไรบ้าง
CAMS: วัฒนธรรมการคิดของ DevOps
1)Culture คือเรื่องของวัฒนธรรมในองค์กรซึ่งเราต้องมีทีมที่เห็นคุณค่าของแนวคิดของ DevOps ก่อนว่ากระบวนการนำ DevOps มาใช้สามารถช่วยให้องค์กรสามารถ Delivery Product ได้เร็วขึ้น ซึ่งตรงนี้จะไม่ใช่เพียงแค่การที่เรานำคำศัพท์เท่ๆใหม่ๆอย่าง Automation, Zero Trusted Architecture, GitOps และอื่นๆอีกมากมายที่เกิดขึ้นอยู่ทุกวันมาพูดใช้กันเฉยๆ เพราะกระบวนการทำ DevOps คือการที่ทั้งทีม IT และทีม Business ตลอดจนไปถึงระดับโครงสร้างของผู้บริหารเห็นชอบกับแนวคิดของการประสานงานเข้าไปด้วยกันซึ่งจะทำให้ช่องโหว่ระหว่างแต่ล่ะทีมค่อยๆหายไป
เพราะด้วยแนวคิดของการแบ่งแยกทีมแบบ Silo Based ที่เชื่อว่าแต่ล่ะคนควรรับผิดชอบเฉพาะงานของตนเองทำให้ผลงานที่ออกมาขาดความเป็น Ownership ของ Product โดยองค์รวมแต่จะรับผิดชอบเฉพาะงานที่ตนทำเท่านั้น ซึ่งเมื่อเราย้อนไปดูเรื่องของ Product Digital Platform เราไม่สามารถนำแนวคิดว่าแต่ล่ะคนจะแก้ปัญหาเฉพาะจุดของตนเองมาใช้ได้ เพราะปัญหานั้นไม่ได้เกิดจาก Single Root Cause เท่านั้นแต่ทุกๆอย่างในระบบ IT ล้วนมีความเกี่ยวข้องกันตั้งแต่ Business Requirement, Program, Network, Database และ Infrastructure ดังนั้นถ้าหากเกิดปัญหาขึ้นมาแล้วแต่ล่ะคนไม่เห็นภาพรวมของ Product ไม่เข้าใจ Flow การทำงานของระบบ การแก้ไขก็จะขึ้นอยู่แค่กับคนๆเดียว หรือคนเฉพาะกลุ่มเท่านั้น ซึ่งทำให้กลับมาเป็นปัญหาดังภาพคือ แต่ล่ะคนสร้างสินค้าแพ็คลงกล่องและก็โยนไปให้อีกฝ่าย โดยไม่สนใจว่าปัญหาระหว่างการขนส่งนั้นเป็นอย่างไร ตรงจุดนี้คือจุดหลักเลยที่เป็นปัญหาในหลายๆองค์กร ก่อนที่จำนำ DevOps หรือ Cloud Native Application ไปใช้เพื่อ Transform Monolith แต่ยังมีปัญหากับวัฒนธรรมในองค์กร ที่ไม่เอื้ออำนวยต่อการเกื้อกูลกัน โดยเฉพาะ Technology ใหม่ๆที่เข้ามาอย่างต่อเนื่องถ้าหากเรายังไม่สามารถผสานทั้งสองทีมเข้าด้วยกันได้ การเรียนรู้เพื่อไป Cloud Native Technology จะไม่สามารถเกิดขึ้นได้เลย
2)Automation หลังจากที่เราได้เห็นแนวคิดของทัศนคติและวัฒนธรรมองค์กรไปแล้วว่าทำไม DevOps ไม่ใช่เรื่องที่แค่การนำคำศัพท์ Technology ใหม่ๆเข้ามาลงแต่ต้องเกิดจากทัศนคติที่ดีด้วย โดยในข้อต่อมาจะเป็นเรื่องของ Technical ซึ่งนำมาแก้ Pain point คือเรื่องของ Process การ Manual Configuration เพื่อจะเตรียม Infrastructure และการทดสอบ Code ว่ามีปัญหาหรือไม่ซึ่งสังเกตดูว่าขั้นตอนเหล่านี้ล้วนสามารถทำเป็น Automation ได้โดยมีแนวคิดที่ว่าเมื่อใดก็ตามที่ Developer Push Code ไปยัง Version Control แล้วเราจะทำให้มี Trigger ผ่าน Webhook ไปเรียกยัง Continuous Integration Pipeline ของเรา ซึ่งตัว Continuous Integration (CI) Pipeline จะทำหน้าที่ทดสอบว่า Code ของเราผ่าน Test หรือเปล่าและมีการ Scan Quality ของ Code ต่างๆถ้าหากไม่ผ่านมาตราฐานก็จะแจ้งกลับไปยัง Developer ให้กลับไปแก้ Code อัตโตมัติซึ่งตรงจุดนี้ทำให้เกิดสิ่งที่เรียกว่า Fast Feedback Loop ทำให้สามารถเรียนรู้จากจุดบกพร่องได้เร็วขึ้นและเพิ่มประสิทธิภาพของ Code ที่จะออกไปอีกด้วยซึ่งตรงจุดนี้จึงเป็นการหักล้างความเชื่อว่า Automation แล้วคุณภาพของ Code จะลดลงหรือเปล่า ? คำตอบก็คือการทำ Automation ไม่ได้ทำให้ Defect หลุดออกไปมากขึ้นเพราะถ้าเราผ่านเรื่องของ Culture ที่ดีในการเขียนโปรแกรมและความเป็นเจ้าของ Product มาแล้วเราจะทำการทดสอบโปรแกรมของเราอยู่เสมอดังนั้นการมี Unit Test + Integration Test ฝังใน CI จะทำให้เราได้ Feedback Loop ที่รวดเร็วและเสมือนมีการ Review Code ไปในตัวอีกด้วย
โดยจากภาพจะเห็นว่าในส่วนของ Cultures ก็จะเป็นส่วนของ Agile Development และ Automation จะเริ่มที่ Continuous Integration + Continuous Testing เพื่อทดสอบปัญหาต่างๆและมากไปกว่านั้นเรื่องของ Security พื้นฐานเองก็เป็นสิ่งที่ต้องคำนึงถึงดังนั้นปัจจุบันคำว่า DevOps จึงถือว่าตกยุคไปแล้วแต่กลายมาเป็น DevSecOps ซึ่งเพิ่มเรื่องของ Security เข้ามาด้วยเพราะด้วยยุคของ Cloud Native สิ่งที่ตามมาคือ Attack Surface ที่เพิ่มมากขึ้นตามไปด้วยเพราะด้วยหลาย Endpoint ของ Tool หรือ Service ที่เกิดมากขึ้นทำให้การคำนึงถึง Security Endpoint ถือเป็นสิ่งที่สำคัญเช่นกันแต่สำหรับ tools นั้นก็มีให้เลือกมากมายในขึ้นของ CI ไม่ว่าจะเป็น Jenkins, CircleCI, GitlabCI และอื่นๆอีกมากมายซึ่งระหว่างการทำ Integration จึงควรเสริมเรื่องของการ Scan Security หรือ Vulnerable ที่มีโอกาสเกิดขึ้นกับ Source Code เราไปด้วย (ลองสังเกตดูว่า Github จะมีการเตือนเรื่อง Dependency มีช่องโหว่และเตือนให้เราทำการอัพเดท แต่ก็ต้องดูด้วยนะครับว่ากระทบต่อระบบทั้งหมดหรือเปล่าหากอัพเวอร์ชั่น ไม่อย่างนั้นอาจจะเศร้ากว่าเดิมได้ 5555)
ในส่วนต่อมาคือ Continuous Delivery จะเป็นเรื่องของการที่เราจะสามารถนำ Software, Dependency หรือ Product ใดๆต่างๆของเราไปให้ปลายทางแก่ User ได้อย่างไร ซึ่งที่เรามองคำว่า Delivery Software, Dependency และ Product ไปกลุ่มเดียวกันนั้นเพราะว่าการ Delivery ไม่ได้จำกัดแค่การนำ Application สำหรับ End User ไปขึ้น Server แล้วมี Features ใหม่มาเท่านั้นแต่มันหมายถึงการส่งมอบใดๆก็ตามที่จำเป็นต้องใช้ใน System ทั้ง Platform ยกตัวอย่างเช่นก่อนที่เราจะมี Application ได้เราก็ต้องมี Infrastructure ก่อนซึ่งในยุคของ Cloud Native เราก็มี Cloud Provider มากมายไม่ว่าจะเป็น AWS, Azure, Google Cloud หรือกระทั่งของประเทศไทยอย่าง Nipa.Cloud แต่ในขั้นตอนการ Provisioning เครื่อง Virtual Machine เหล่านี้บน Cloud เองก็ยังต้องเสียเวลาในการ Configuration อยู่ดีไม่ว่าจะเป็น Network, Spec Hardware หรือ Access Control ของบัญชีองค์กรต่างๆ ซึ่งถ้าหากเราต้องการ Deploy Application จำนวนมากและ Scaling เพื่อรองรับผู้ใช้จำนวนมากที่เพิ่มขึ้นในช่วงเวลาสั้นๆ อย่างระบบ ไทยไม่ทิ้งกัน, ลงทะเบียน GAT/PAT ก็คงไม่สามารถไปเพิ่ม Provisioning เครื่อง VM บน Cloud ทีล่ะเครื่องแล้วมา Config Network ทีล่ะจุดได้เพราะคงเสียเวลามากมายและมีโอกาสผิดพลาดอีกด้วยเพราะต้องเข้าไปติดตั้ง Software เองทีล่ะจุด สิ่งที่เกิดขึ้นคือเรื่องของ Security ที่มีโอกาสถูก Exposed มากขึ้นหากต้องใช้แรงงานคนไป Config เชื่อมต่อกับ Database ต่างๆ Password ก็มีโอกาสรั่วไหลไปได้ หรือการ Scale เครื่องให้เล็กลงหากผู้ใช้ลดลง ก็ต้องมาปิดทีล่ะเครื่องก็เป็นการเสียเวลาเช่นเดียวกัน ดังนั้นถ้าเรามองลึกลงไประดับของ Continuous Delivery ของ System Platform นั่นก็คือการทำอย่างไรให้เราสามารถ Provisioning เครื่อง Virtual Machine จำนวนมากๆพร้อมๆกันได้เป็นหลักหมื่นเครื่องในระยะเวลาไม่ถึง 10 นาที พร้อมกับติดตั้ง Application ของเราลงไปในเครื่องเหล่านั้นด้วยเมื่อ Server ทำการ Start สำเร็จแล้ว
คำตอบนั่นก็คือการที่ให้ Continuous Delivery ของเราไม่ได้จำกัดแบบ Application แต่เจาะลึกไปถึง System Platform ที่เริ่มตั้งแต่ให้ Infrastructure ถูกเก็บอยู่ในรูปแบบของ Infrastructure as a Code (IaC) เช่น Terraform จะทำให้เราสามารถ Provisioning Resource ไปยัง Cloud Provider ได้อย่างง่ายดายและลดปัญหาเรื่อง State ของ Server บน Cloud Server คลาดเคลื่อนกันเพราะการ Config ที่ผิดพลาด แต่เมื่อมี IaC มาใช้งานจะทำให้เราสามารถ Tracking ความถูกต้องล่าสุดของ Cloud Resource ที่เรามีทั้งหมดได้ซึ่ง Tools เหล่านี้ล้วนเชื่อมเข้ากับ Version Control เหมือนทางฝั่ง Developer เช่นกันทำให้ลดปัญหาของ Operational Team ที่ทำหน้าที่ดูแล Infrastructure ไม่สามารถทดลอง Provisioning Server หรือการปัญหา Configuration Drfiting บน Production Enviroment หลังจากที่เราสามารถจัดการเรื่องของการ Provisioning แบบ System to System ได้แล้วเราก็จะทำการติดตั้ง Software Infrastructure ที่จำเป็นไม่ว่าจะเป็น Docker, Jenkins ผ่าน Ansible ซึ่งก็เป็น IaC ตัวหนึ่งซึ่งเหมาะกับการติดตั้ง Software และเมื่อขึ้นมาที่ระดับ Layer ข้างบนระดับ Software Layer เราก็สามารถนำ Source Code ที่ Build เป็น Artifact พร้อม Deploy ส่งไปให้กับ Continuous Deployment Pipeline ของเราเพื่อทำการ Deploy Application ต่อไปเมื่อต้องการใช้งานควบคู่กับกับ Scaling Infrastructure ผ่าน tools IaC อย่าง Terraform ของเรา และสามารถรับ Feedback ครบทั้ง Pipeline CI/CD ได้ผ่านระบบ Support Ticket System ที่ให้ User สามารถกลับมา feedback ถึงปัญหาหรือ Bugs ที่เราต้องแก้ไข ก็จะแสดงอัตโนมัติผ่านหน้า Dashboard เหล่านั้นทำให้ Team ทราบได้ว่าระบบกำลังมีปัญหาใดที่ต้องทำการ Tracking กลับไปบ้าง
หลังจากที่เราเห็นในเรื่องของ DevOps Pipeline ไปแล้วเราก็จะมาเสริมในส่วนสุดท้ายคือ Security ใน Flow ของ DevSecOps ซึ่งอาจจะมองว่าเป็นกำแพงใหญ่ของการทำ DevOps เพราะในทุกๆ Enterprise ใหญ่ๆล้วนต้องมี Framework สำหรับการทำ Audits ด้วยกันทั้งนั้นเพื่อตรวจสอบความถูกต้องต่างๆ และอะไรจะทำให้ Enterprise สามารถนำ Cloud Native Technology ซึ่งเป็นยุคของ Open Source Project กันทั้งนั้น ในมุมมองของ Security Team เองก็จะมองว่าไม่ผ่านแน่ๆ เพราะว่าเต็มไปด้วยช่องโหว่จำนวนมากที่อาจจะถูกโจมตีได้ ซึ่งกำแพงเหล่านี้คงไม่มีทางหายไปหากเรายังมองว่า Security Audit ก็ยังเป็นอีกทีมหนึ่ง ดังนั้นการรวมกันเพื่อให้ผ่าน Process นี้ไปก็คือนำทีม Security เข้ามาใน Process ระหว่างที่เรากำลัง Build Software ของเราด้วยเช่นกันทำให้เขาทราบหมดว่าระบบของเรานั้นมีช่องโหว่ใดบ้างหรือเปล่าดีกว่าให้ Team Security ไปนั่งหาเองตั้งแต่ต้น ซึ่งการนำ Security มาใช้กับ DevOps นั้นถือเป็นสิ่งที่ถูกต้องและจำเป็นด้วยซ้ำไปเพราะ DevOps คือการทำให้ทุกคนในทีมเห็นคุณค่าของ Product เพื่อส่งมอบ Software ที่มีคุณภาพออกไปจนจบ Flow การทำงาน ดังนั้นหากเราสามารถทำทีม Team Security มาช่วยในเรื่องของการแบ่งปันความรู้พื้นฐานอย่าง OWASP Top Ten หรือการ Monitoring ต่างๆที่มี Tools ออกมามากมายอย่าง Elasticsearch Stack ที่ขยายไปจนถึงระดับ Security Incident Event Management (SIEM) และล่าสุดก็รองรับเรื่องของ Security End Point Management พร้อมกับการทำ Centralize Logs เพื่อทำตาม Compliance ต่างๆไม่ว่าจะเป็น GPDR, HIPAA ก็มี Tools ให้พร้อมแล้วเช่นกัน พร้อมกับการนำ Security Scanner เข้ามาทดสอบโปรแกรมตั้งแต่ในช่วงของ CI Pipeline อย่าง ZAP OWASP เองก็ทำได้เช่นกัน
3)Measurement คือขั้นตอนของการวัดผลว่า Feedback Loop ที่เราได้รับมานั้นช่วยให้ Process การทำงานของทีมดีขึ้นไหมซึ่งหลังจากที่เรามีเรื่องของ Technical ครบแล้วในข้อที่สองสิ่งที่จะทำให้ Process ของเราดีขึ้นั้นก็คือการประเมินผล แต่สิ่งหนึ่งที่เราต้องเข้าใจคือการประเมินของเรานั้นจะไม่ใช่การจัลผิดใครหรือการโทษไปที่ว่าใครผิดเพราะแนวคิดของ DevOps คือการ Blameless ที่เราจะไม่โทษที่บุคคลคนใดคนหนึ่งเพราะทั้งหมดคือ Process ที่เราช่วยกันทำมาด้วยกัน แต่เราจะมาดูที่ว่าเราสามารถมีวิธีใดเพื่อใช้ในการแก้ไขปัญหาได้บ้างโดยปัจจัยที่เราสนใจหลักๆก็อาจจะเป็น Mean Time to Recover (MTTR) หรือช่วงเวลาที่ใช้ในการกู้คืนระบบเมื่อเกิด Failure เกิดขึ้น รวมไปถึง Code Quality ที่ส่งมาจาก Pipeline CI/CD ก่อนหน้า
ซึ่งถ้าเราดูจากภาพเราจะเห็นทั้งสี่มุมมองคือ Release Readiness ที่หมายถึงความพร้อมในการปล่อย Product เราออกไปตั้งแต่ระดับเล็กๆจนไปถึงส่วนของ End to End และก็มีส่วนของ Velocity ที่วัดความรวดเร็วในขั้นตอนระหว่างการ Coding วันหนึ่งมี Commit อัพเข้าไปยัง Version Control เท่าใด มีการ Build Artifact เท่าไหร่ และนำไป Deploy ที่ Staging Server เพื่อทดลองกี่ครั้งเป็นต้น ต่อมาก็จะเป็นเรื่องของ Stability ว่า Software ของเราเสถียรมากแค่ไหน สามารรับ Fault Tolerance ได้มากเพียงใดถ้าหากเกิด Failure จะมีการกู้คืนด้วยวิธีใดบ้างใช้เวลาเป็นเท่าไหร่ซึ่งทาง Tech Company ใหญ่ๆอย่าง Netflix เองก็จะมีการทดสอบเรื่องของ Fault Torelant เหล่านี้บน Production Stream หนังที่เราดูกันทุกวันอยู่ด้วยซึ่งมีแนวคิดของเรื่องการทำให้ Production Server เกิด Fault ขึ้นด้วยการปิด Server หรือ Shutdown Service บางตัวลงเพื่อทดสอบว่า ระบบของตนนั้นสามารถการันตี Uptime ได้เท่าไหร่กันจริงๆกันแน่ในขณะที่มี Users เข้ามาใช้งานจริงๆอยู่ด้วย และในส่วนสุดท้ายก็จะเป็นเรื่องของ Quality Control เพื่อให้มันใจว่า CI/CD Pipeline ของเรานั้นไม่ได้ปล่อยสิ่งที่ Defect ออกไปแก่ผู้ใช้ปลายทางการทดสอบจึงเป็นหัวใจสำคัญที่ไม่ได้ตกไปอยู่ที่ Tester ทีมอย่างเดียวแต่ต้องเริ่มตั้งแต่ระดับจุดเล็กสุดที่คนเข้าใจก็คือ Programmer ที่เป็นคนเขียน Unit Test นั่นเอง รวมไปถึงการคำนึงถึง Security ต่างๆก็ควรจะมีด้วยเช่นกัน
4)Sharing จากทั้งสามข้อของวัฒนธรรมการคิดแบบ DevOps และเรื่องของ Trending Technology ที่เกิดขึ้นอย่างรวดเร็วเราคงทราบแล้วว่าถ้าหากภายในทีมเราไม่มีการแบ่งปันความรู้กันคงเป็นไปไม่ได้เลยที่คนๆเดียวจะสามารถเข้าใจทำทุกอย่างได้ด้วยตัวคนเดียว โดยไม่สอบถามไม่เรียนรู้ Best Practice จากทีมอื่น หรือถึงทำได้ตัวคนเดียวก้คงจะเสียเวลาและช้ามากแถมยังเป็นการใช้เวลาไปกับสิ่งที่ไม่จำเป็นอีกด้วยเพราะเรามีคนที่เคยผ่านขั้นตอนหรือปัญหาเดิมๆเหล่านั้นอยู่แล้ว เราก็ควรนำวิธีการแก้ปัญหาเหล่านั้นมาแชร์กันเลยเพื่อให้เรียนรู้ได้เร็วขึ้นโดยไม่เสียเวลาไปกับปัญหาเดิมๆอีก
ดังนั้นการ Sharing และ Learning Culture จึงเป็นสิ่งที่สำคัญที่ Team ควรจะเรียนรู้ด้วยกันอย่างต่อเนื่องแล้วคอยแบ่งปันซึ่งกันและกันก็จะทำให้เรื่องของ Culture นั้นเกิดความเข้มแข็งมากขึ้นเพราะปัญหาอย่างหนึ่งคือการที่คนในองค์กรไม่กล้าแบ่งปันความรู้กันเพราะคิดว่าจะมีคนอื่นที่เก่งกว่าและตนเองจะไร้คุณค่าไม่สามารถสร้างประโยชน์แก่องค์กรได้ แต่แนวคิดนี้เป็นแนวคิดที่ผิดอย่างมากไม่ใช่แค่เฉพาะสายงาน IT แต่ทุกๆงานการที่เราแบกภาระไว้คนเดียวเมื่อใดก็ตามที่เกิดปัญหาขึ้นคนที่ต้องแก้ปัญหาก็คือเราคนเดียวกลายเป็นว่าคนอื่นๆในทีมไม่สามารถช่วยอะไรได้เลยเพราะยังไม่ทราบถึงปัญหาด้วยซ้ำซึ่งก็จะกลับไปถึงเรื่องของ Silo Team-Based ในตอนต้น แต่เมื่อใดก็ตามที่คนอื่นๆมีความรู้กันแบบ Cross-Functional Team อันหมายถึงทุกๆคนในทีมเข้าใจ Business, Code, Infra, Process, Security แต่ก็มีหน้าที่หลักก็คืองานของตนที่รับผิดชอบและถนัดจะทำให้เวลาแก้ปัญหาทุกคนเห็นภาพรวมเดียวกัน และนำความสามารถที่ตนถนัดเข้าไปวิเคราะห์แก้ปัญหาในส่วนอื่นที่เกิดในระบบได้ ไม่จำกัดแค่ส่วนที่ตนเองรับผิดชอบเท่านั้นซึ่งการ Sharing เหล่านี้ก็จะไปผนวกกับการทำงานแบบ Agile ที่มีความคล่องตัวอีกด้วยพร้อมกับทำให้ทุกๆคนรู้สึกเป็นส่วนหนึ่งของทีมจริงๆไม่ใช่เข้ามาทำงานไปวันๆเพื่อให้จบโปรเจคตามที่มอบหมาย แต่มันคือเราเป็นส่วนหนึ่งของเจ้าของ Products เรารู้สึกว่า Software ที่เราสร้างนั้นมีคุณค่า
ดังนั้นเราจะเห็นแล้วว่าการมุ่งสู่ DevOps ขององค์กรนั้นไม่ใช่แค่การนำ Technology ใหม่ๆเข้ามาเพราะถ้านำเข้ามาแต่ Technology แต่คนในองค์กรยังไม่ทราบถึงเหตุผลและแรงจูงใจสุดท้ายก็ไม่มีใครใช้ แถมยังทำให้มีโอกาสผิดพลาดสูงมากขึ้นเพราะการใช้ Technology ใหม่ๆและไม่เข้าใจก็ทำให้มีโอกาสผิดพลาดจาก Bugs หรือเกิด Vulnerable แต่ในทางกลับกันหากเข้าใจถึงแก่นแท้ของ DevOps องค์กรจะสามารถลดต้นทุนไปได้มากเพราะมีทั้งการ Optimize Software ที่ดีขึ้น การเลือกใช้ Open Source Tools ต่างๆหลายๆตัวที่มาช่วยให้งานง่ายขึ้นอีกด้วย
DevOps The Series Next Chapter >> Technical Part
ก่อนจากกันไปกับ Blog นี้ก็อยากให้เพื่อนๆหรือน้องๆที่กำลังเข้ามาเรียนที่สาย IT แล้วรู้สึกว่า IT นั้นมีเรื่องหลากหลายกลัวตัวเองจะตาม Tech ทั้งหมดไม่ทันว่าไม่ต้องกังวลนะครับ เราค่อยๆเก็บเกี่ยวความรู้จากพื้นฐานในห้องเรียนที่อาจารย์สอนหรือจะ Course Online ที่เราชอบ ที่เรารู้สึกสนุกไปกับมันก็จะทำให้ตลอดเวลาอยู่ในสาย IT ของเราเหมือนกับการเล่นเกม หรือการตามข่าวสนุกๆอย่างหนึ่งที่ออก Product น่าตื่นตาตื่นใจมาให้เราตลอด จากนั้นเราก็นำสิ่งต่างๆมาแลกเปลี่ยนกันก็จะทำให้เราสร้าง Community ที่ดีที่สนุกไปพร้อมๆกันได้
โดยเฉพาะช่วง Covid นี้ถ้าเพื่อนๆที่กำลังเรียนอยู่คนไหนกำลังหาคอร์สเรียนดีๆอยู่ก็ลองเข้าไปดูที่เว็บอย่าง Coursera ได้นะครับลองนำ Email สถานศึกษาไปกรอกดูก็สามารถเรียนคอร์สฟรีได้ครับ โดยจากภาพเป็นภาพของมหาลัยผมครับอิๆ
ซึ่งถ้ามาครั้งหน้าไว้มาเจอกับเรื่อง Flow ของ DevOps กันแบบลึกๆใน Part Technical กันต่อครับกำลังเล็งเรื่องของ Jenkins Pipeline ไว้หรือไม่ก็ Kubernetes ครับ
ซึ่งถ้าเพื่อนๆคนไหนสนใจหรือรู้สึกว่าข้อมูลใน Internet มีเยอะแต่ยังกระจัดกระจายอยากทราบพื้นฐานลึกๆกว่านี้ ก็สอบถามมาได้เลยนะครับที่ส่วนของแสดงความเห็นด้านล่าง ยินดีตอบเสมอครับผมมมม
ซึ่งต้องขอบคุณ “สำนักงานส่งเสริมเศรษฐกิจดิจิทัล (depa)” และอาจารย์ “คณะเทคโนโลยีสารสนเทศ มจธ. (SIT)” ที่ให้การสนับสนุน “ทุนเพชรพระจอมเกล้าเพื่อพัฒนาเทคโนโลยีและนวัตกรรมดิจิทัล (KMUTT-depa)”
ที่ช่วยกันออกแบบคอร์สการเรียนและให้ทุนในการใช้การศึกษาความรู้ดีๆแบบนี้ครับ !
อ้างอิง
https://www.coursera.org/learn/devops-culture-and-mindset (คอร์สที่ผมกำลังเรียนอยู่ครับเนื้อหาดีมากอิๆ)
