DevOps Handbooks#9 : The Technical practices of Continual Learning & Experimentation

ใครที่ติดตามตอนก่อนๆ พออ่านมาถึงตรงนี้ อาจจะจินตนาการไปถึงระบบในฝันที่ทุกคนกินอิ่มนอนหลับสบาย ไม่มีปัญหาใดๆเพราะเรามีการ flow และ feedback ที่ดี ชีวิตสวยงามดังอยู่กลางทุ่งลาเวนเดอร์

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

Enable and Inject learning into daily work

ในเมื่อวิกฤตเป็นสิ่งที่เราต้องเผชิญ ก็ทำให้มันเป็นส่วนหนึ่งของงานประจำวันไปซะเลยสิ ในแนวคิดนี้ เคสที่ต้องพูดถึงเลยก็คือ การรอดพ้นวิกฤตการ AWS US-EAST ในปี 2011 ของ Netflix คือ ตอนนั้น AWS ร่วงไปทั้งโซน ย้ำทั้งโซนนะฮะไม่ใช่แค่เครื่องสองเครื่อง บริษัทใหญ่ๆที่ใช้บริการ AWS ก็ร่วงผล็อยไปตามๆกัน ยกเว้น Netflix จ้า รอดอยู่ผู้เดียว ซึ่งนี่ไม่ใช่เรื่องฟลุ้ก ตอนเค้า redesign โครงสร้างก็มีเป้าหมายชัดเจนว่าจะต้องอยู่รอดให้ได้จากการพังทุกๆรูปแบบ ซึ่งมันก็รอดจริง เออ..เอ็งเจ๋ง

นอกจากนี้ Netflix ยังมี “Chaos Monkey” คือระบบที่คอยสุ่มพังเครื่องตัวเองอยู่เรื่อยๆ เพื่อให้มั่นใจว่าระบบจะรอดอยู่ได้ ในสถานการณ์วิกฤต ซึ่งระบบจะต้อง recover ตัวเองได้อัตโนมัติ โดยไม่ต้องให้คนไปแทรกแซง แม้แต่วันที่เกิดเหตุ AWS US-EAST ก็ไม่มีใครต้องเข้าออฟฟิศมากู้ระบบ เพราะว่าเค้าทำให้วิกฤตเหล่านี้เป็นเรื่องธรรมดาๆที่เกิดขึ้นทุกวัน (ปรบมือสิครัช จะรออะไร)

เรื่องอื่นๆที่ควรมี

• Just culture — เป็นอีกแนวคิดในเรื่องนี้คือ เมื่อมีปัญหาเกิดขึ้นก็ให้มองว่านี่เป็น “แค่” ปัญหาเพื่อไม่เพ่งโทษคนทำ แต่มองว่า human error ไม่ใช่สาเหตุของปัญหา แต่เป็นผลจาก tools ที่ design มาไม่ดีพอ ถ้ามัน design มาดีต้องป้องกันความผิดพลาดของคนได้
• Post-Mortem — หลังเกิด incident ใหญ่ๆ ต้องทำ Post-Mortem ก็คือต้องเล่นบท CSI มาสืบหาสาเหตุการตายและหาแนวทางแก้ไขร่วมกันทุกครั้ง และเมื่อสรุปแล้วต้องเผยแพร่เรื่องนี้ออกไปให้มากที่สุด เพื่อเป็น lesson learnt

Convert local discoveries into global improvement

คือ ความรู้ที่เกิดขึ้นที่จุดเล็กๆจุดหนึ่งต้องถูกขยายไปเป็นความรู้ขององค์กรและนำไปปรับปรุงกับทุกระบบ ตอนแรกเห็นชื่อหัวข้อ นึกว่ามันจะพูดว่าก็มี tools กลางเก็บ log incident อะไรแบบนี้นะ แต่ไม่ใช่แฮะ มันพูดถึงเทคนิคต่างๆที่เราสามารถนำมาใช้เป็น machanism ในการทำให้ความรู้ไปสู่ทุกคนได้ เช่น

• Chat rooms/ Chat bots — คนส่วนมากคงคุ้นเคยและรู้ว่า Chatroom เป็นช่องทางนึงในการสื่อสารกับคนทั้งกลุ่มได้ดี เพิ่มเติมคือ การใช้ chatbot ทำ automation เช่น hubot ของ github ที่ถูกนำไปใช้เพื่อ trigger งาน deployment การทำแบบนี้ก็ได้ประโยชน์คือทุกคนรู้ว่าทำอะไรอยู่ คนที่มาใหม่ก็เข้าใจงานได้ง่าย
• Automated process and Automated Test — ในนี้ก็พูดถึงหลายๆแง่ แต่หลักใหญ่คือ เราอยากเปลี่ยนการ share ความรู้กันผ่านเอกสาร word มาเป็นโค้ดที่ executable เช่นการปรับ standard process มาเป็น script และใช้ automated test เป็นจุดควบคุม เช่น ถ้าเรามีเรื่อง security ที่จะ improve ก็ปรับ spec นี้ใน auto test ก่อนเลย หลังจากนั้น ทุกคนที่ทำงานก็ต้องรัน auto test อยู่แล้วก็จะ compile กับ spec ใหม่นี้ไปโดยปริยาย

Reserve Time to Create Organization Learning and Improvement

แม้ทุกคนจะรู้อยู่แล้วว่าการเรียนรู้และปรับปรุงเป็นสิ่งที่ควรทำ แต่สุดท้ายก็มักมีข้ออ้างอันศักดิ์สิทธิ์ คือ ไม่มีเวลา อยู่เรื่อยไป มันก็มีเทคนิคที่จะทำให้เรามีเวลากับเรื่องนี้ให้ได้ เช่น

Kaizen Blitz คือ การรวมคนมาคิดอย่างจริงจังเพื่อทำ process improvement การประยุกต์ใช้ก็เช่น

• ที่บริษัท Target มีสิ่งที่เรียกว่า DevOps Dojo เป็น 30 day challenges ที่ทีม dev จะมาทำงานด้วยกันอย่างเต็มที่กับ Dojo coach และ engineer เป็นเวลาหนึ่งเดือน เพื่อแก้ปัญหา internal และทำ demo ใน two-day sprints หลังจากจบก็คาดว่าจะต้องแก้ปัญหาหลักๆได้
• อีกรูปแบบนึงที่ใช้กันคือ การกำหนด day- or week-long improvement blize คือ เป็นเหมือน hackathons กำหนดเป้าหมายเลยว่าวันนี้ เราจะทำเรื่อง improvement กำหนดและทำให้สำเร็จ

นอกจากนี้เรายังใช้วิธีอื่นๆ เพื่อเผยแพร่ expertise ไปทั้งองค์กร ก็มีได้หลายแบบ เช่น

• Internal coaching ให้ expert เปิดชั่วโมงให้คนมาปรึกษาได้
• Testing on the Toilet ของ Google ที่จะมีการติดข้อมูลเกี่ยวกับ test knowledge ไว้ใกล้ๆห้องน้ำ เพื่อเพิ่มความรู้ ให้กับทีม หรือการกำหนดให้มี mentor ในเรื่องที่เราส่งเสริม

โดยสรุปคือ ทุกๆครั้งที่มีปัญหาเราต้องเข้าใจอย่างถ่องแท้และเรียนรู้จากมัน คอยปรับปรุงแบบไม่โทษกัน ทำปัญหาให้เป็นเรื่องธรรมดา ใช้ automated script เป็นเครื่องมือในการส่งผ่านความรู้ไปทั้งองค์กร สุดท้ายคือต้องหาทางจัดเวลาให้คนทำงานปรับปรุง และให้ทุกคนเรียนรู้และสอนคนอื่นอยู่เสมอ

Note: อันนี้เป็นสรุปจากการอ่านหนังสือ DevOps Handbook อาจมีผิดถูกบ้าง + มีคหสตบ้างเล็กน้อย ถ้าสนใจไปซื้อหาอ่านเล่มจริงกันต่อได้

ติดตามตอนอื่นๆ

• DevOps Handbook #1: Introduction
• DevOps Handbook #2 : The three ways
• DevOps Handbook #3 : The three ways (Cont.)
• DevOps Handbook #4 : Where to start
• DevOps Handbook #5 : Team & Organization
• DevOps Handbook#6 : The technical practices of flow
• DevOps Handbook#7 : Automated and enable low-risk release
• DevOps Handbook#8 : The Technical Practices of Feedback
• DevOps Handbook#9 : The Technical practices of Continual Learning & Experimentation
• DevOps Handbook#10 : Change & Security Compliance