Full Cycle Engineer โมเดลที่ Netflix ปรับปรุงมาอย่างสม่ำเสมอ
ในปัจจุบัน ไม่มีใครไม่รู้จัก Netflix หนึ่งใน Platform Streaming ยักษ์ใหญ่แห่งยุค User กว่า 125 ล้าน ที่ดู Content ต่างๆ ราวๆ 140 ล้านชม. ในแต่ละวัน และการได้รับการจัดอันดับให้เป็น Elite Performer ใน State of DevOps 2018 และ 2019
กับการมองย้อนกลับไปสู่ยุคเริ่มต้นของ Netflix ในปี 2012 ที่กว่าจะ ปล่อย Canary Release แต่ละ Release ใช้ระยะเวลากว่าสัปดาห์เพื่อให้มั่นใจว่าใช้งานได้
ระหว่างทาง Netflix ได้ค้นพบ และเรียนรู้อะไร จนนำมาปรับปรุงเปลี่ยนแปลง วิธีการทำงานของทีม Developer สู่ Model Full Cycle Engineer ที่ Netflix ยึดเป็นวิถีปฎิบัติ
หมายเหตุ: วิธีการสร้างแนวปฎิบัติให้ Developer เป็น Full Cycle Engineer เป็นวิธีที่ Netflix ทดลองและปรับปรุงจนได้มาเป็นแบบทุกวันนี้ ซึ่งโมเดลนี้ มีข้อดีและข้อเสียในตัวเอง ที่หากคนที่อยากลอกโมเดลนี้ไปใช้จะต้องคำนึกในบริบทที่แตกต่างกันขององค์กรและกลุ่มคนด้วย
Netflix and chill
ยุคเริ่มต้น One Team’s Journey — Edge Engineering
ย้อนกลับไปปี 2012 ในยุคที่ทีม Developer ของ Netflix ยังไม่ได้เป็น Full Cycle Engineer เหมือนในปัจจุบัน Netflix ก็มีการแบ่ง ระหว่าง ทีม Dev และทีม Operation โดย จัดตั้งทีม Edge Engineering ขึ้นมา
หน้าที่คือ tier 1 ที่จะต้องคอยดูแลให้ service บน AWS ที่ใช้ในการ streaming ทำงานอยู่ตลอดเวลา ซึ่งทีมนี้จะรวมตัวคนที่โฟกัสในเรื่องของการทำ Operation และ ผู้เชี่ยวชาญทางด้าน SRE มาคอยดูแล Deploy + Operate และ Support ปัญหาที่เกิดขึ้น
ทีมนี้จะต้องทำงานร่วมกับ Dev ในการกำหนด metrics, alerts resource ที่ต้องใช้ และส่งมอบโค้ด (hand off) เพื่อที่จะ Release feature ใหม่ขึ้นบน Production เพื่อให้ dev ไม่ถูก interrupt ในการทำงาน ในเหตุการณ์ปกติ
แต่เมื่อเกิดปัญหาเกิดขึ้น สิ่งที่ตามมาคือ ราคาที่ต้องจ่าย (cost) ในการสื่อสารระหว่างทีม dev และ ops เพื่อที่จะแก้ปัญหาจะต้องมีคุยกันไปคุยกันมา เหมือนโยนบอลให้รับ เพื่อที่จะหาวิธีแก้ปัญหา หรือที่เราได้ยินบ่อยๆ ในการสื่อสารภายในองค์กรที่เป็นในรูปแบบ Ping — pong
ซึ่งทำให้ปัญหาที่เกิดขึ้นระหว่างการ deploy เป็นเรื่องที่ ใช้เวลานานในการ detect ปัญหา และใช้เวลานานในการแก้ไข เพราะทีม Ops ไม่สามารถเข้าใจทุกอย่างที่ dev ทำการแก้ไข (changes) ในแต่ละ release ได้
higher time-to-detect and time-to-resolve
ทำให้เกิด Gap ระหว่าง เขียนโค้ดเสร็จ และ deploy เสร็จ ยาวขึ้นๆ จนกว่าจะ deploy release ใหม่ได้ ต้องใช้เวลาเป็นสัปดาห์ และปัญหาที่เกิดขึ้นที่ ทีม Ops ได้ประสบพบเจอและเจ็บปวด ในการรับ issue production และ support ลูกค้า ไม่ได้สื่อไปถึงทีม dev ผู้ซึ่ง (อาจ) เป็นต้นเหตุของปัญหาเหล่านั้น และทีม dev ก็มองเรื่องของปัญหาที่ทีม Ops เจอว่า
เป็นปัญหาของ ”พวกเขา” ไม่ใช่ปัญหาของ ”เรา”
ในยุคนั้น Netflix จึงเริ่มทดลองโมเดลใหม่แบบ Hybrid หรือก็คือ
ให้ Devs มีสิทธิที่จะ push code และ deploy เอง และหยิบยื่นหน้าที่รับผิดชอบ production issue และ support cases นอกเวลางาน เพื่อให้ dev ได้เข้าใจถึงสิ่งที่ตัวเองสร้าง ส่งผลกระทบอะไรกับคนใช้งาน บ้าง
วิธีนี้ช่วยให้ Dev ได้รับ feedback และเรียนรู้ประสบการณ์ที่เกิดขึ้น
แต่ก็เกิด Gap ความรับผิดชอบเกิดขึ้นระหว่างทีม Dev และทีม Ops
ตัวอย่างเช่น เวลาที่ dev กำลัง deploy งานของตัวเองและ กำลัง debug การทำงานของ pipeline อยู่ ก็จะขอให้ทีม Ops ช่วยดูให้หน่อยแทน ซึ่งทีม Ops ส่วนใหญ่เวลาได้รับการร้องขอ ก็มันจะทำงานด้วยความเต็มใจ สำหรับ day to day work และพวกเค้า มักมองไม่ออกว่าจะเอา automation มาช่วยตรงส่วนไหน
พอสิ่งนี้เริ่มเกิดบ่อยขึ้น บ่อยขึ้นที่ Netflix เราจึงถอยกลับมาที่ภาพใหญ่ และเริ่มมองย้อนกลับมา ที่ principle
อะไรคือสิ่งที่เราอยากทำให้สำเร็จ
ทำไมเราถึงไม่ประสบความสำเร็จ
วงจรชีวิตซอฟต์แวร์ Software Life Cycle
สิ่งที่มองย้อนกลับมาคือ จุดประสงค์ของ Software Life Cycle คือ ระยะเวลาที่ใช้ในการส่งมอบคุณค่า (time to value) จากไอเดียสู่ Product ที่ใช้งานได้จริง
จะเห็นได้ว่านอกเหนือจาก SDLC (Software Development Life Cycle) เราจะเห็นว่ายังมี Area อื่นๆ ด้วย ถ้าเราพูดถึง SLC
วงจรชีวิตของซอฟต์แวร์ ไม่ได้มีเพียงการพัฒนาเพียงอย่างเดียว หน้าที่พัฒนาและให้บริการเป็นความรับผิดชอบ ที่จะต้องมีคนดูแล โดยคนดูแลเหล่านั้น เราก็ได้มีการแต่งตั้ง Role ต่างๆ ขึ้นมารับผิดชอบใน Area ต่างๆ
กลุ่มคนเหล่านี้ล้วนมีความชำนาญในแต่ละเรื่องที่ตัวเองถนัดได้อย่างมีประสิทธิภาพ แต่สิ่งที่แลกกันคือการทำงานระหว่างกระบวนการประสิทธิภาพจะด้อยลง เพราะทุกคน Focus แต่ใน area ของตัวเอง แทนที่จะ focus ในการส่งมอบ value ให้กับลูกค้า ก่อให้เกิด SILOS ทำให้ process end-to-end ช้าลง ดังนั้นเราจึงเห็นไอเดียการเอา Expert ในแต่ละด้านมาทำงานร่วมกันเป็นทีมเดียวกันเพื่อไม่ให้เกิดภาพเหล่านั้น แต่สิ่งที่ต้องแลกกัน ตามมาคือ overhead ในการสื่อสารกันภายในทีมจะเพิ่มขึ้นอีกทั้งอาจทำให้เกิดคอขวดในการรับ feedback ด้วย
ยุคเปลี่ยนแปลง ดูแลของที่คุณสร้างมากับมือ Operating what you build
หลังจากที่ใน Netflix เริ่มพิจารณาแนวทางของตัวเองใหม่ ก็หยิบ principles of the devops movement มาเป็นแรงบรรดาลใจ เพื่อให้ทีมสามารถรับ feedback ได้ตลอดกระบวนการ และสร้างความเป็นเจ้าของงานร่วมกัน (Shared ownership)
โดยแนวคิด ดูแลสิ่งที่ตัวเองสร้าง เป็นการนำ devops principle มาปรับใช้ ให้ทีมพัฒนาได้มีส่วนร่วมในการ deploy และ support การกระจายความรับผิดชอบในการ deploy และ support ไปในแต่ละทีมพัฒนา แทนที่จะ แยกทีม deploy & support ออกไปต่างหาก ช่วยให้ทีมพัฒนา ได้เข้าใจความเจ็บปวดและความรู้สึกของคนที่ต้องรับแก้ปัญหาที่เกิดขึ้นจากเนื้อมือของทีมพัฒนาเอง ไม่ว่าจะเป็น deployment issue เจอ bug บน production ตลอดจนการวางแผนว่าต้องใช้ resource เท่าไหร่ ในการให้บริการ อะไรที่จะต้องทำเป็น alert ให้รู้ว่าเริ่มมีปัญหาเกิดขึ้นที่ไหน รวมถึงการ support case ที่เกิดขึ้น
Scaling Through Developer Tools
ถ้าเราสอนเค้าจับปลาเป็นเค้าจะจับปลาได้ทีละตัว
แต่ถ้าเราสร้างแห ให้เค้า เค้าจะจับปลาได้เป็นสิบตัว
เมื่อหน้าที่ของนักพัฒนามีเรื่องที่ต้องรับผิดชอบมากขึ้น หากเรายังทำด้วยวิธีการเดิมๆ โดยไม่มีเครื่องมือไว้ใช้ทุ่นแรง ก็จะทำให้ทีมพัฒนาใช้ระยะเวลานาน ในการทำงาน
ใน Netflix จึงเกิดการสร้าง Centralized Team หรือ ทีมส่วนกลางขึ้นมา หน้าที่คือสร้างเครื่องมือที่ใช้ในการแก้ปัญหา ที่แต่ละทีมพัฒนามักประสบปัญหาเหมือนกันบ่อยๆ ตั้งแต่เครื่องมือที่ช่วยเพิ่ม productivity จนถึงการ setup infra ให้พร้อมสำหรับทำงาน เพื่อให้ ทีมพัฒนาแต่ละทีม ได้โฟกัสในการแก้ปัญหาของตัวเอง
ซึ่งสิ่งที่ทีมส่วนกลางสร้างจะเป็นเครื่องมือที่สามารถใช้ได้ทุกทีม ไม่ได้ทำเฉพาะเจาะจงให้ทีมใดทีมหนึ่ง ซึ่งก็เป็นอีก challenge หนึ่ง เพราะการเลือกระหว่าง ให้ทีมพัฒนาสร้างเครื่องมือของตัวเองกับให้ทีมส่วนกลางสร้างให้ ต้องชั่งน้ำหนักให้ดี
Full Cycle Developers
หลังจากที่ เรามีทีมนายช่างใหญ่ที่คอยสรรสร้างเครื่องมืออำนวยความสะดวกให้กับเหล่านักพัฒนาแล้ว ก็ถึงคราวที่นักพัฒนาทั้งหลายจะรับผิดชอบหน้าที่อันยิ่งใหญ่ พร้อมเครื่องมือมากมาย ตั้งแต่ design, develop, test, deploy operate และ support
ซึ่งที่ Netflix เราเรียก Developer เหล่านี้ว่า Full Cycle Developer
และสำหรับ Netflix dev หน้าใหม่ที่ยังไม่เคยได้ไปสัมผัสใน area ที่ไม่คุ้นเคยมาก่อน ก็จะต้องผ่าน Boot Camp และ training ต่างๆ เพื่อให้พร้อมสำหรับก่อนไปลงมือทำงานจริง โดยจะต้องสามารถใช้เครื่องมือพื้นฐานได้ด้วยตัวเอง เช่น deployment pipelines และ monitoring
โดยสิ่งที่เราฝึก Full Cycle Developer ด้วย
การตอบคำถามจากมุมมอง developer 2 ข้อ
How can I automate what is needed to operate this system
ทำยังไงที่เราจะทำสิ่งที่จำเป็นต้องทำในการดูแลระบบนี้ให้เป็นอัตโนมัติได้
What self-service tool will enable my partners to answer their equestions without needing me to be involved ?
Tool อะไรที่จะทำให้ คนที่เกี่ยวข้องสามารถหาคำตอบเองได้โดยที่เราไม่ต้องไปเกี่ยวข้อง
คำถามเหล่านี้จะช่วยให้ทีมสามารถสร้างระบบงานที่ตอบสนองคนใช้งานได้ ดีกว่าการที่มองทุกอย่างว่าต้องแปลงทุกอย่างให้เป็นอัตโนมัติเพียงอย่างเดียว
แต่การสร้าง Full Cycle Developer มีสิ่งหนึ่งที่ต้องคำนึก คือการเปลี่ยน Mindset (Minset Shift)
เพราะ Developer บางคนมองว่า คุณค่าในงานของตัวเองคือการออกแบบและเขียนโค้ดเพียงอย่างเดียว และมองว่าเรื่องของการทำ Operation เป็นเรื่องที่คอยมากวนใจ ที่จะรีบๆ ทำให้เสร็จๆ จะได้มีเวลาไปทำงานจริงๆ ของตัวเอง (Real Job)
ดังนั้นต้องเปลี่ยนมุมมองคือ หน้าที่จริงๆ ของ Developer คือการใช้ความรู้ความสามารถในการพัฒนาซอฟต์แวร์ มาแก้ปัญหาที่เกิดขึ้นตลอดวงจรชีวิตของ Product ซึ่ง Full Cycle Developer จะต้องคิดและทำอย่างที่ SWE, SDET และ SRE ทำ ในขณะที่ต้องแก้ปัญหาธุรกิจ บางเวลาก็ต้องคิดและเขียน Test cases และบางเวลาก็ต้องวิเคราะห์ว่าจะปรับการ operation ส่วนไหนให้เป็นอัตโนมัติได้
Model นี้จะประสบความสำเร็จได้ ทีมจะต้องเห็นพ้องต้องว่า
มูลค่าที่จะได้ นั้นมีราคาที่ต้องจ่าย (Trade-off) เพราะ
- ทีมจะต้องมีการจัดการคนให้เหมาะสมและเพียงพอในการ จัดการ build, deploy และจัดการ production issue รวมถึงการตอบ partner support
- ต้องใช้เวลาในการฝึกฝน
- ต้องมีการริเริ่มสร้างเครื่องมือเพื่ออำนวยความสะดวก
- ต้องทำงานร่วมกับ ทีมส่วนกลางในการสร้างเครื่องมือ ที่ reuse ได้
- ทุกๆ area ใน life cycle ต้องถูกพิจารณาทั้งช่วง planning และ retrospectives
- การลงทุนใน alert system และสร้าง self-service support tool ต้องมี priority พอๆ กับ business project
- ด้วยการจัดการบุคคลากร, จัดลำดับความสำคัญ และการมีส่วนร่วมจะช่วยทำให้ทีมประสบความสำเร็จ หากไม่ได้สิ่งเหล่านี้ อาจเกิดอาการ overload และ burnout ของทีมได้
หากจะหยิบ Model นี้ไปใช้นอก Netflix การประยุกต์ใช้เป็นเรื่องสำคัญ
- หาปัญญาทั่วไป (common problem) ในแต่ละทีมพัฒนา ตั้งแต่ continuous delivery pipeline จนถึง monitoring ให้เจอ และดูว่าจะปรับปรุงส่วนไหน
- ถ้า บริษัทไม่อยากลงทุนทีมส่วนกลางก็สามารถลองเอา netflix tool ที่เป็น opensource ไปลองแก้ปัญหาก่อนก็ได้
- อย่างไรก็ตาม solution เหล่านั้นสามารถตอบสนองปัญหาของบริษัทส่วนใหญ่ได้
- เริ่มวิเคราะห์ หา value และ cost ที่ต้องจ่าย และสิ่งที่ต้องปรับ mindset
- ประเมินสิ่งที่คุณต้องการ และสร้างความซับซ้อนเท่าที่จำเป็น
Trade-off มูลค่าที่เราเลือก รับได้กับราคาที่ต้องจ่าย
Full cycle Developer Model เป็นเพียงหนึ่งใน model ที่ netfilx ใช้เป็นพื้นฐาน
ในอุตสาหกรรม ซอฟต์แวร์มีการแก้ปัญหา devops ที่ต่างกันออกไป อีกหลากหลายรูปซึ่งเราต้องรู้ถึง trade-off ที่เลือก ก่อนที่จะเลือก เพราะจะทำให้ โอกาสในความสำเร็จเพิ่มสูงขึ้น
ด้วย full cycle model ต้องใช้ความรู้ค่อนข้างกว้างและหลากหลาย
Model นี้ ไม่เหมาะสำหรับ
- บางคนชอบที่จะรู้ลึกแต่ไม่อยากรู้กว้าง
เราก็ต้องช่วยหาที่ให้เค้า ว่าจะเอาเค้าไว้ส่วนใดขององค์กร - developer บางคนอยากจะเป็น expert ไปเฉพาะเรื่องไปเลย และไม่อยากทำนอก area ตัวเอง
ในประสบการณ์ของ Netflix ที่สร้างและดูแล cloud based system พบว่า
นักพัฒนาที่ให้ความสำคัญกับการรู้รอบจะมีประสิทธิภาพ แต่ความรู้รอบจะสร้างภาระให้กับ developer ดังนั้น ทีมต้องจัดลำดับความสำคัญให้สมดุลในทุกสัปดาห์ มากกว่า จะทำเพียงอย่างเดียว
โดยเราจะผลัดเปลี่ยนให้ dev แต่ละคน ได้มีส่วนร่วมกับการ deploy + operate + support
ในช่วงที่ไปได้ดี จะสร้างพื้นที่ให้กับคนอื่นๆ ได้ focus ถ้าทำไม่ดี ทีมจะถูก interrupt จาก production issue ซึ่งจะก่อให้เกิด burnout ได้
การสร้าง tool และ automation จะช่วย ขยายความเชี่ยวชาญ แต่ ไม่มีเครื่องมือที่แก้ได้ทุกปัญหา
ที่ netflix มี เครื่องมือและ practices ที่เตรียมไว้ให้โดยทีมส่วนกลาง แต่ไม่ได้บังคับให้ใช้ แต่รับประกันได้ว่า ใช้แล้วได้ประสบการณ์ดีกว่าไม่ใช้
การที่เราจะสร้างเครื่องมือให้ ทุกทีมในองค์กรใช้ทุก feature ในทุกเครื่องมือ เป็นเรื่องที่เป็นไปไม่ได้ ดังนั้นการลงทุนในการสร้าง เครื่องมือ ของ centralized team เป็นเรื่องที่ต้องใช้ความพยายาม การตกลงร่วม และปรับปรุงร่วมกัน
ส่งท้าย
การเดินทางจากปี 2012 จนถึงปัจจุบันของ Netflix เต็มไปด้วยการทดลอง เรียนรู้ และปรับปรุง
ทีม Edge Engineering ได้ประสบการณ์ก่อนหน้ามาเป็นแรงจูงใจที่หาโมเดลที่ดีกว่าจนได้เป็น Full cycle developer ในปัจจุบัน การ deploy เป็นเรื่องปกติที่เกิดขึ้นอย่างสม่ำเสมอ canaries ใช้เวลาหลักชม. แทนที่จะเป็นหลักวัน ทีม dev ใช้เวลาไม่นานในการหาปัญหาและแก้ มากกว่าจะโยนความรับผิดชอบข้ามทีม
Original:
