We did not do DevOps!!
เป็นประโยคที่จำได้ลาง ๆ ในคลิปหนึ่งของ Netflix ในงาน DevOps ซักปีหนึ่ง Netflix ที่ทำ video on demand แบบ streaming หนะแหละ
เขาบอกว่าที่ Netflix ไม่ได้ทำ DevOps แต่มันดันเป็นวัฒนธรรมองค์กรมาตั้งแต่เกิด
ไม่มีรั้ว/คอก/panel, ชั้นทำงานขั้นระหว่าง dev และ operations นั่งทำงานด้วยกัน บริษัทเดียวกัน แต่ก็ต้องยอมรับว่า Netflix ไม่มี servers เป็นของตัวเองเลย ไปใช้บริการ Amazon Web Services (AWS) ทั้งหมด
ที่ Netflix ไม่ได้มีหน้าจอแสดงกราฟของ servers เพราะถ้าต้องเอาทุก servers มาแสดงผลแล้วใช้จอ retina แล้วทุก servers แสดงแค่ 1 pixel ในหน้าจอ retina ต่อให้ใหญ่เท่าภาพฉายจาก projector ก็แสดงได้ไม่หมด
ปล่อยให้ server มันเกิดดับตามธรรมชาติ ถ้าคนใช้เยอะก็เพิ่มเครื่อง ถ้าคนใช้น้อยก็ลดเครื่อง แต่ถ้ามันจะพังจริง ๆ ก็มีระบบ alert
เป้าของ DevOps
Delivery team ที่ดีควรจะส่งมอบ value ที่แท้จริงอย่างต่อเนื่อง
ควรที่จะทำเป็นตั้งแต่รับ requirements ไปจนถึงส่งมอบงานขึ้น productions คล้าย ๆ กับการที่เรามีแฟน แต่งงาน มีลูก เห็นลูกเรียนจบ จนไปแต่งงานมีลูกอีกรอบ (ตัวอย่างนี้ก็ไกลไปหน่อย 🤣)
แล้วอะไรคือ value อย่างแท้จริง ? ผมจะยกตัวอย่างแบบสุดโต่งก่อนนะ สมมุติว่ามีที่ทำงานที่หนึ่งที่มี user หรือ BU (Business Unit) เป็นตัวแทนของผู้ใช้งานจริง
- ทำการประชุมกับ BA (Business Analyst) ถึง software ที่อยากได้
- หลังจากการประชุมนั้น BA ก็ไปทำเอกสารมาชุดหนึ่ง อาจจะเรียกว่า requirement specification
- และทำการนัดประชุมกับ SA (System Analyst, Software Analyst)
- หลังการประชุม SA ก็ไปนั่งเทียนเขียนเอกสารมาอีกชุดหนึ่ง อาจจะเรียกว่า system design specification
- แล้วก็เอาเอกสารที่ได้จาก SA โยนให้ทีมพัฒนา
- ทีมพัฒนาก็รับมาแบบงง ๆ และทำตามเอกสารที่มี จนได้เป็น accidentaly working software หรือ ซอฟต์แวร์ที่บังเอิญทำงานได้
- แล้ว tester, QA แล้วแต่ทีจะเรียกเอาไปเล่น แล้วก็พัง ส่งกลับไปพัฒนาใหม่
- ถ้าผ่านขั้นตอน QA แล้วก็ส่งกลับกลับไปหา BU แล้วก็พบว่าไม่ตรงกับที่คุยกันไว้นี่หว่า
- ไม่เอา path ไม่ตรงสิ เอาเป็นว่าสุดท้ายพอผ่านขั้นตอนทั้งหมดมา เราก็จะมี freaky nearly collapse when something change, kind of working software อยู่
แล้ว operations อยู่ตรงไหน ? เดี๋ยวกลับมาเล่า ซึ่งผมจะพาคลี่คลายไปทีละจุดก่อน
เกมสื่อสาร
ผมเชื่อว่าทุกคนเคยเล่นเกมสื่อสาร ที่แต่ละคนต่อแถวกัน มองไปข้างหน้า และคนข้างหลังจะแตะบ่าคนข้างหน้า แล้วบอกคนข้างหน้าหรือคนถัดไปว่าให้พูด หรือให้ทำอะไร แล้วส่งต่อสารนี้กันไปเรื่อย ๆ ถ้าเราเป็นผู้สังเกตุการณ์ มันจะมีการกลายพันธุ์ของสารที่เราส่งในเกมนี้ อาจจะไม่เหลือเค้าโครงเดิม หรืออาจจะฟลุ๊คจนกลับมาเป็นตัวฉบับ ซึ่งแบบแรกเป็นไปได้สูงกว่ามาก
ถ้าเราลองเทียบกับ working software กับ เอกสารที่ออกจาก BA หรือ SA เราจะตอบได้เลยว่า working software สิ
ตัวอย่าง
ถ้ายังไม่เห็นภาพ ผมจะยกตัวอย่างให้ มีกระทรวงเวทย์มนต์กระทรวงหนึ่งที่มีงบ ลับเยอะมาก ๆ ลับจนไม่รู้ว่าเอาไปทำอะไรบ้าง อยากได้ อุปกรณ์ที่ไว้สอดแนมคนในประเทศ ซึ่งไม่สามารถหาซื้อได้ทั่วไป เพราะกระทรวงเวทย์มนต์ที่อื่นก็ไม่อยากบอกให้โลกรู้หรอกว่าเราก็สอดแนมประชาชนของเราเหมือนกัน จนเป็นที่มาในการสร้างอุปกรณ์สอดแนมดังกล่าว
ก่อนการว่าจ้าง ทางกระทรวงได้ออกเอกสารที่มีชื่อว่า Term of Reference (TOR) ซึ่งขั้นตอนกว่าจะได้มาของ TOR นั้น ต้องไปจ้างผู้เชี่ยวชาญ จากในกระทรวงเอง หรือบุคลากรในสถาบันอุดมศึกษามาเพื่อเขียน ซึ่งก็ใช้งบและเวลาไปนานมาก
ขี้เกียจเล่าละตัดจบเลยละกัน 🤣 สุดท้ายโปรเจคนั้นได้กลับมาแต่เอกสารมาสองสามคันรถบรรทุกจากบริษัทที่รับทำอุปกรณ์ อุปกรณ์สอดแนบนั้นก็ไม่ได้มาด้วย ไม่ได้ใช้งานจริง ละลายเงินทิ้ง ลงเวลาไปเยอะมาก
จะเห็นได้ว่าระหว่างของที่ทำงานได้จริง กับคู่มือที่ดีมาก ๆ แต่ไม่มีของ value ไม่ได้อยู่ที่คู่มือเลย
ถ้าจะบอกว่ามีเอกสารออกแบบแล้วเราจะไปจ้างใครทำเมื่อไหร่ก็ได้ ซึ่งนั่นก็จริงแค่ครึ่งเดียว เพราะในงานการพัฒนาซอฟต์แวร์นั้น สิ่งที่เราออกแบบได้ดีที่สุด ณ วันนี้ อาจจะมีของใหม่กว่าดีกว่าในอีกไม่กี่วันข้างหน้าแล้ว
กลับมามองที่ DevOps
สมมุติว่าปัญหาข้างบนถูกแก้เรียบร้อยแล้ว BU ทำงานกับ delivery team แทบจะเป็นก้อนเดียวกัน ไม่มีคนกลาง ส่งมอบแต่ working software แต่เรายังมีอีกส่วนหนึ่งที่จะไม่ได้เข้ามาอยู่เป็นเนื้อเดียวกันตรงนี้ด้วย คือ operations
ซึ่งพอเราแยก delivery team กับ operations เราก็จะเห็นปัญหาต่าง ๆ เช่น
- งานส่งไม้ผลัด ว่า “นี่ไง มันทำได้บนเครื่อง dev นะ” แล้วไปพังบน production
- ส่ง Word, Presentation, Spreed Sheet ทั้ง spec, config files, sql migration script กันทาง email แทนการส่งมอบ working software
- ทีมพัฒนาอยากได้ server รอไปสิ สองเดือนสามเดือน
- ขอ server ได้แล้ว เล่นปิงปองกันก่อน เช่นขอ Access Control List (ACL)
ทีมที่สร้าง servers หรือทำ ACL ให้ได้ไม่รู้ว่าจะเทสยังไงว่า server A เรียกไปหา server B ได้แล้ว ต้องขอ support ทีมพัฒนามาช่วย
ทีมพัฒนาไม่สามารถสร้าง server หรือขอ ACL ได้ จึงต้องขอทีม operations มาช่วย
- พัฒนาเสร็จแล้ว production server ยังไม่เสร็จ
แล้วทีมจะส่งมอบของได้อย่างต่อเนื่องและราบรื่นได้อย่างไร
ขอยืนยัน
จะเห็นว่าผมจะพูดถึง BU กับ delivery team แล้ว BA, SA, QA ไปไหน ถ้ามันจะมีอยู่ก็มีอยู่ใน delivery team นี่แหละ มันคือทีม ทีมที่จะทำงานไปพร้อม ๆ กัน เป้าหมายเดียวกัน คือส่งมอบซอฟต์แวร์ที่ทำงานได้และมีคุณภาพ
delivery team คือทีมทำของให้คนใช้ที่มีความหลากหลายทางเพศ วัย ศาสนา ความชอบ ด้วย perspective ของคนที่มีความหลากหลาย ไม่ใช่คนไม่กี่คนพร้อมกับเทียนหลาย ๆ เล่ม
- ไม่ใช่ทีม BU มี KPI ว่าส่งของให้ BA ให้ได้มากที่สุด
- ไม่ใช่ทีมที่ BA มี KPI ว่าส่งเอกสารหรือของให้ SA ให้ได้มากที่สุด
- ไม่ใช่ทีมที่ SA ส่งเอกสารหรือของให้ทีมพัฒนาให้ได้มากที่สุด
- ไม่ใช่ทีมที่ดันขยะออกไปหา tester ให้ได้มากที่สุด
- ไม่ใช่ทีมที่ปล่อย tester อยู่ดึกกับขยะจากทีมพัฒนา
delivery team จึงเป็นทีมที่จะส่งมอบของที่มีคุณค่าอย่างแท้จริง เพื่อออกไปสู่ตลาด และได้ใช้งานจริง ได้เงินจริง และเก็บ feedback มาพัฒนาของต่อไป
ซอฟต์แวร์ ที่มีคุณภาพ อย่างต่อเนื่อง
อะไรบ้างที่ทำให้ซอฟต์แวร์มีคุณภาพ
ถ้าภาพกว้างคือเรามี CI/CD ที่แข็งแกร่ง แต่อะไรบ้างที่ทำให้ CI/CD แข็งแกร่ง
- Unit Tests, Integration Tests, System Tests ในทุกอนู ซึ่งส่วนตัวผมชอบ “The Testing Trophy” มากกว่า “Test Ice-Cream Cone” หรือ “Test Pyramids”
ถ้าเรามี pipeline ที่เชื่อถือได้ ผมว่าในอนาคต เราสามารถที่จะส่งมอบของทุก ๆ เดือนครึ่ง เป็น วันละหลาย ๆ ครั้งได้
ตรงนี้ก็ต้องมีเครื่องมากพอที่จะไว้ทำ pipeline ผมเคยลองทำ pipeline ที่ Enterprise แห่งหนึ่ง ผลคือ merge requests เฉพาะวันศุกร์วันเดียว จนวันจันทร์แล้ว ยังทำไม่ครบทุก merge request เลย 😭
สกิลของ DevOps
เรามาอยู่ในยุค Software defined everything แล้ว เพราะฉะนั้น หนีไม่พ้นการที่ dev มีสกิล ops และ ops มีสกิล dev เครื่องมือที่ ops ใช้เช่น
- Unix command
- Shell script, make script
- Vagrant, AWS scripts, etc.
- Containers technologies
อนาคตของ DevOps
Ops จะหายไปเหลือแต่ dev ใช่ developer หนะแหละ ถ้าถามว่าได้ไง
ถ้าบางที่ที่ developer กับ QA ยังแยกกันทำงานอยู่แปลว่าคุณกำลังช้า (lag) กับโลกในปัจจุบันแล้ว
ถ้าตอนนี้คุณทำให้ developer กับ operations มาทำงานในทีมเดียวกันได้ แปลว่าคุณตามทันแล้ว และรู้ไว้เลยว่ายุคหน้า จะไม่มีคำว่า DevOps จะเหลือแต่ Dev ที่ทำ opertation ได้ด้วย
อะไรที่ทำให้ไปต่อได้ยาก
- โครงสร้างองค์กร ไม่ใช่ stopper เหมือนกับการที่คนที่เก่ง BA, SA, BA มานั่งอยู่ใน delivery team เดียวกัน โครงสร้างองค์กร จะเป็นยังไงก็ได้คุณก็สามารถเป็น delivery team หรือ DevOps ได้อยู่ดี
- มีเครื่องไม่พอที่จะทำ pipeline ดี ๆ ให้ทันเวลา สุดท้าย บาง job เช่น Unit Tests จะถูกเอาออกจาก pipeline เพราะ QA รอเทส BU รอเล่นอยู่
- ไม่ยอมทำ automate tests ต่าง ๆ
- ยอมเอา tests pipeline ออก เพราะปล่อยให้พังอยู่ตลอดเวลา ไม่มีการดูแล
- ไม่มีอะไรให้ monitor ตัว pipeline
- ยังต้องเปิด ticket ซึ่งจริง ๆ แล้วเราสามารถทำ Software Configuration Management ใน git แทนได้ ถ้าทุกอย่างอยู่ใน scripts แล้ว ซึ่งถ้าต้องการการยืนยันตัวอย่างแท้จริง git ใหม่ ๆ รอบรับการเซ็น digital ด้วย GPG แล้ว
ยกออกมา ไม่เกี่ยวกับ DevOps ตรง ๆ มันจะออก microservices ละ แต่ไม่อยากลบ
- จะเพิ่มเครื่องลดเครื่องยังไง ถ้า server ยังต้อง lock ด้วย IP ต้องขอ ACL กันด้วย IP ซึ่งจริง ๆ แล้วเราก็ได้ทำระบบยืนยันตัวตนอื่น ๆ ร่วมด้วยอยู่แล้ว เช่น token, ssl handshake, encryption ซึ่งอาจจะยอมถอยออกมาจากการ lock IP
- สังเกตุ เวลาเราต่อกับระบบบางอย่างนั้น เขาจะให้แค่ชื่อ domain ด้วยซ้ำ แต่ก็ยังมีหน้า ip ให้เป็น range กว้าง ๆ ซึ่งบางครั้งทับซ้อนกับบาง services ด้วยซ้ำ เช่น outlook, sharepoint, office 365 เพราะมันควบคุมไม่ได้ว่า จะไปเกิดดับที่ ip ไหน
- จะเพิ่มลดเครื่องยังไงแล้วให้ log ยังอยู่ ถ้าเรายังไม่ออกแบบ log collector ให้ดี
ฝาก
รูปข้างล่างคือ states และมุมต่าง ๆ ของ DevOps โดยเริ่มจาก initial ไปสู่ขั้นซุปเปอร์ไซย่า (optimizing) เรียกว่า DevOps Maturity Model
