ตอนนี้ก็จะพูดถึงเรื่อง feedback ก็ต้องย้ำจุดประสงค์ของเรื่องนี้ก่อน คือ ในทุกๆชิ้นงานย่อยๆที่ทำ เราอยากได้งานคุณภาพ ซึ่งสามารถวัดและได้ feedbackทันทีหลังทำเสร็จ ไม่ใช่ปล่อยไปจนสุด flow แล้วจึงรู้ เพราะจะทำให้การแก้ไขนั้นยากและแพง
Telemetry
เริ่มจากเราต้องมีตัววัดต่างๆเพื่อให้เห็นคุณภาพ ตัววัดเหล่านี้จะอยู่ในทุกๆส่วน ไม่ว่าจะ client software, infrastructure, application, deployment pipeline หรือกระทั่งฝั่ง business ความแตกต่างของวิธีคิดนี้คือ มันไม่ใช่แค่ดูแค่ว่ามี feature ตามต้องการและทุกอย่าง up and run ก็ถือว่าใช้ได้นะเออ แต่มันข้ามไปสู่การวัดว่างานที่เราทำมันตอบโจทย์ธุรกิจจริงๆด้วยรึเปล่า
เราอาจใช้ Telemetry ในการคาดการณ์ load หรือตรวจสอบว่าอะไรน่าจะมีปัญหา หรือใช้เพื่อหา root cause ซึ่งวิธีวิเคราะห์เค้าก็ใช้หลักการทางสถิติตั้งแต่ระดับทั่วไป เช่น ค่าเฉลี่ย (mean), ความแปรปรวน (variance) ไปจนถึงสถิติขึ้นสูง ที่อลังสุดคือ ตัวอย่างในหนังสือมันมีคนใช้ Fast Fourier Transform ด้วย นี่มันมีความชั้นสูงจริงๆฮะ (คหสต..สมัยเด็กไม่ตั้งใจเรียนวิชาพรรค์นี้ คิดว่าใครเค้าจะใช้กัน แต่มันมีคนใช้จริงๆด้วยแฮะ)
สิ่งสำคัญ คือ telemetry นี้ต้องมีให้พร้อมทุกครั้งที่ release ไม่ใช่ release ไปก่อน ค่อยไปตั้ง monitor ทีหลัง ถือว่าผิดหลักมากๆๆ เพราะ telemetry เป็นสิ่งสำคัญที่ช่วยลดความเสี่ยงของการ release และทำให้เรา roll back ได้ทัน
A/B Testing
มีการวัดอังนึงในทางธุรกิจที่นิยมมากคือ A/B testing ซึ่งมักจะเริ่มจากคำถามเช่นว่า ถ้าเราเพิ่มปุ่มซื้อไว้หน้านี้ๆ คนจะซื้อของเยอะขึ้นมั้ย ซึ่งไม่มีใครรู้หรอกจนกว่าจะได้ทดสอบสมมติฐานนี้ แล้วจะทดสอบได้ยังไง ง่ายมาก เราก็สุ่มให้ผู้ใช้กลุ่มนึงเห็น release version ใหม่ที่มีปุ่มนี้ แต่อีกกลุ่มไม่เห็นปุ่มนี้ แล้วมาวัดยอดซื้อกัน ว่าแบบไหนดีกว่า การทำอย่างนี้แหละที่เรียกว่า A/B Testing ซึ่งเป็นแนวคิดที่ใช้การ release มาช่วยวัดผลทางธุรกิจด้วย
Review
พูดถึง review ก็มีเรื่องน่าสนใจอันนึงในนี้คือ เค้าพูดถึงการทำ review ด้วย change control ในรูปแบบเดิมว่าไอ้การที่เราพยายามควบคุม change มากๆเพราะไม่อยากให้มีปัญหาบน production อาจจะทำให้เกิดผลในทางตรงข้ามได้ด้วยนะเอ้อ ที่เค้าคิดคือ การควบคุมมักเพิ่มขั้นตอน ทำให้ใช้ lead time นาน จนทำให้การจะทำ deploy ทีนึงมันก็สะสมเป็น batch ใหญ่ ซึ่งก็ยิ่ง review ได้ยาก ถ้าไม่ ok กว่าจะได้ feedback ก็ช้า แถมคน review ก็ไกลกะงานก็ไม่ค่อยรู้เรื่องอีก มีคนเคยพูดว่า
“Ask a programmer to review ten lines of code, he’ll find ten issues. Ask him to do five hundred lines, and he’ll say it looks good”
คือ ถ้าให้โปรแกรมเมอร์ review code ซัก 10 บรรทัด เราจะเจอ 10 issues แต่ถ้าให้ review 5,000 บรรทัดเค้าจะบอกว่าไม่มี issue อะไรเลย … เออ…ก็จริงนะ เพราะมันเยอะเกินกว่าจะดูได้หมด 555
ซึ่งวิธี review ที่เค้าเชียร์ คือการทำ “peer reviews” ก็คือให้เพื่อนช่วยกัน review เค้ามีวิจัยด้วยว่า องค์กรที่ performance ดีๆนี่มักจะพึ่งพา peer review มากกว่า external approval ที่ review ใน change process ปกติ ซึ่งการทำ peer review ก็มีได้หลายอย่าง เช่น
- Pull request ที่ GitHub จะมีกระบวนการที่ให้ engineer บอกคนอื่นว่า change ของตัวเองทำอะไร ก่อนที่จะ push เข้า repository ซึ่งก็จะมีคนมา review และถือเป็น approval
- Pair programming คือการจับคู่กัน code ซึ่งก็มีหลายรูปแบบย่อย เช่น คนนึงเป็นคนเขียน code (driver) อีกคนเป็นคนกำหนดหลักการชี้เป้า (observer) หรืออีกรูปแบบคือให้คนนึงเขียน automated test อีกคนเขียน code ของ app อะไรแบบนี้
และถึงแม้จะไม่ได้เน้นมาที่ change process แต่ก็ควรมีการคุม schedule ไม่ให้ชนกันอยู่ดีนะ ซึ่งเค้าพยายามทำให้ง่าย เช่นใช้ห้องแชท หรือถ้าบริษัทใหญ่โครงสร้างซับซ้อน ก็ให้ตัวแทนทีมมาคุยกันก่อนว่าจะทำอะไรตอนไหน
โดยสรุปคือ เราควรมีตัววัดให้ครบถ้วน ทั้ง App, Infra, business ให้ตัววัดนี้ช่วยให้เราป้องกันและแก้ปัญหาได้เร็ว ส่วนการ review นั้น จะเน้นไปทาง peer review มากกว่าการ review จากภายนอก
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
