Failed like a boss at Agoda !!!

เมื่อประมาณเดือนที่แล้ว ได้รับการติดต่อมาจากทาง Agoda Alumni ซึ่งทางนั้นถามขึ้นมาว่าสำหรับเราแล้ว อะไรคือ Culture ที่ประทับใจใน Agoda พอได้ยินเรื่องนี้ขึ้นมาปุ๊บ ผมก็นึกขึ้นมาถึงเรื่องนึงที่มีอยู่ในใจอยู่แล้ว ก็คือเรื่องของการ Fail fast ของ Agoda ที่เป็นมากกว่าแค่ Practice และเรา Fail กันจริงจังมากๆ

0_cxcFhChMaGKMrofW-1
ในตอนที่ทำงานกับ Agoda นั้น ผมทำอยู่กับทีม Core Engineering ซึ่งดูแล Core ของ Frontend ที่ Agoda ซึ่งก็ถือว่าหนักหนาสาหัสพอควร เพราะเป็นเว็บไซต์ที่ต้องรองรับการใข้งานมากกว่า 40 ล้าน users ต่อวัน และทีมเราดูแลเรื่อง Performance/Avialability และ core ของ Website ซึ่งถ้าระบบไม่สามารถทำงานได้เนี่ย เสียรายได้กันในระดับวินาทีละหลายเงินเลยทีเดียว ซึ่งถ้าเทียบกับหัวเรื่องแล้วต่างกันฟ้ากับเหวเลยทีเดียว เพราะดูเหมือนว่าระบบนี้แทบไม่เปิดโอกาสให้เราได้ Fail กันเลยทีเดียว แล้วเราจะ Fail like a boss กันได้ยังไงผมจะเล่าให้ฟัง

เริ่มด้วยการทำความเข้าใจกับโจทย์

ที่ Agoda นั้นเราไม่ได้ออกตัวแรงว่าเรามี culture เป็น Agile กันจ๋า เพราะการบริหารทีมที่ Agoda นั้นเราฟรีสไตล์กันมาก บางทีมก็ทำ Scrum บางทีมก็ทำ Kanban (บางทีมก็ทำ Waterfall ห๊ะ อะไรนะ !!!) ขึ้นอยู่กับบริบทของงาน และ Project ที่แต่ละทีมรับผิดชอบ แต่ไม่ว่าแต่ละทีมจะบริหารกันอย่างไร อย่างแรกที่เป็นสิ่งที่ทุกทีมเห็นตรงกันคือ เราใช้ Feedback loop ในการ evaluate งานของเรา

0_iQGEQwAijrAlIrf_
ก่อนที่เราจะเริ่ม project อะไรสักอย่างนึง สิ่งที่ Peter Coleman สุดยอดบอสของผมคอยถามอยู่เสมอๆคือ Measure อย่างไร เราเรียนรู้อะไรบ้าง และจะนำมาปรับปรุงได้อย่างไร ทุกครั้งที่เราจะเริ่ม project สิ่งที่ต้องตอบให้ได้คือ เรารู้หรือยังว่าอะไรบ้างที่ต้องมีและตอบได้ใน Feedback loop ของเรา ตัวอย่างของคำถามเหล่านี้ได้แก่

ฺBusiness impact คืออะไร — เพราะเราทำบริษัทไม่ใช่องค์กรการกุศล แน่นอนว่าสิ่งที่เราลง effort ไป ควรบ่งชี้ได้ว่าเราได้สร้าง Value อะไรให้แก่บริษัท/ผู้ใช้
เราจะวัด Business impact นี้ได้อย่างไร — ปกติแล้วที่ Agoda เรามี metric ที่ใช้วัด business impact อยู่แล้ว แต่ในหลายๆครั้งเราไม่สามารถใช้ metric ที่มีอยู่ในการวัดได้ เพราะ project อาจจะไม่ได้ส่งผลกับ metrics ที่เรามีอยู่ ดังนั้นมีหลายๆครั้งที่เราต้องเลือกออกแบบวิธีวัดใหม่
จะบอกได้อย่างไรว่า project นี้ success หรือ fail
design ของระบบที่จะป้องกันไม่ให้ความเสียหายลามไปต่อที่องค์ประกอบอื่นๆทางธุรกิจ
จะเห็นได้ว่าขั้นตอนแรกในขั้นตอนแรกนั้น เป็นการทำความเข้าใจ business value/technical value ที่จะได้รับ และองค์ประกอบในการทำความเข้าใจกับความเสี่ยงของงาน เมื่อเราได้ของทุกอย่างที่ควรมีใน Feedback loop แล้ว ก็จะเริ่มสบายใจไปได้ 1 สเตป

การใช้งาน Experiment และ Feature toggle

ในการทำงานใน Agoda นั้น สิ่งหนึ่งที่ทุกคนต้องได้เจอะเจอคือการใช้ Feature toggle และ Experiment เพื่อให้การพัฒนาของเรา Fail อย่างปลอดภัย

1_AEXebGAsxAU5g7Py6in6qw

picture: https://martinfowler.com/articles/feature-toggles.html
การทำ Feature toggle นั้นถ้าจะอธิบายด้วยภาพด้านบนจะเข้าใจง่ายกว่า กล่องสีเขียวคือ code block ที่จะถูก execute และสีส้มก็คือ execution pipeline ที่เชื่อมต่อแต่ละ code block เข้าด้วยกัน และ สีฟ้าคือ execution path

เราจะเห็นว่าสวิทช์(สีเหลือง) เป็นตัวที่ทำให้ execution path นั้นเปลี่ยนแปลงไป โดยปกติเรากำหนดให้ Variant A หรือ Control เป็น Code path หลัก และ B หรือจุดหลัง switch เป็นเป็น Variance ที่จะเราพัฒนาขึ้นมาใหม่ เพื่อทำให้ product มีคุณสมบัติใหม่หรือมีประสิทธิภาพมากขึ้น

ผมขออนุญาตยกตัวอย่างในการทำ feature toggle แต่จะใช้ javascript library ที่ไม่เกี่ยวกับ Agoda แทนดังนี้

var toggles = {
  foo: true, 
  bar: false
};

// load them into the module 
var featureToggles = require('feature-toggles');
featureToggles.load(toggles);


// Sample for feature on/off
if (featureToggles.isFeatureEnabled('foo')) {
  // Feature On PATH
}


// Sample for A/B Testing
if (featureToggles.isFeatureEnabled('foo')) {
  // Path B AKA Variant
}
else
{
  // Path A
}

เช่นเดิม โดยปกติแล้วสิ่งที่เราพยายามทำเป็น practice คือ เอา placeholder ของ feature toggle ของเรา deploy ขึ้นไปก่อนโดยที่ไม่ต้องสนใจว่า feature ทำเสร็จหรือยัง เพื่อให้มั่นใจว่าเรามี feature toggle พร้อมที่จะควบคุมได้

ขั้นตอนถัดไปคือ เพิ่ม measurement metric ลงไปในในแต่ละ execution path เพื่อให้เราสามารถวัดผลได้ว่า งานของเราประสบความสำเร็จหรือไม่
1_bpQ4_CxGcqdrL0lnYFuKdQ

Picture : http://neilpatel.com/blog/how-to-master-ab-split-testing-quickly-and-increase-conversion-rate/
โดยที่ Agoda นั้นเราใช้ Experiment Platform (Calculon) ที่เราพัฒนาขึ้นเอง และเป็นหนึ่งในสิ่งเชิดหน้าชูตาของเรา รวมทั้งเป็นเครื่องมือที่จะช่วยให้เราวัดความสำเร็จของงานได้อย่างแม่นยำอีกด้วย รวมถึงในกรณีที่ metrics มาตรฐานไม่สามารถรองรับความต้องการในการใช้งานของเรา เรายังสามารถส่ง measurement metric ที่เราเลือก/ออกแบบได้เองผ่าน Messaging Platform (Whitefalcon) อันน่าภาคภูมิใจที่เราพัฒนาขึ้นมาเองเช่นกัน

ก่อนจะ Deploy ก็ต้อง automate test สิ

อีกหลักหนึ่งที่เรายึดถือเสมอคือ ถ้าอยากหลับสบาย ต้องเขียนเทสเสมอ ในการทำงานร่วมกันนั้น การเขียนเทสนั้นถือว่าเป็นวิธีในการธำรงรักษาเวลานอนของเราเป็นอย่างดี เพราะไม่มีใครที่จะบอกวิธีในการทดสอบ changes ของเราได้ดีมากกว่าเราอีกแล้ว (เรามี unspoken rule ว่าถ้าไม่มี automate test แล้วมีคนอื่นทำพัง ไม่มีสิทธิ์บ่น ต้องก้มหน้าก้มตาซ่อมไป)

0_BGtSwmfU9FuI0Vt-

Picture: https://dzone.com/articles/learn-how-to-setup-a-cicd-pipeline-from-scratch
ผมเองเคยไปเล่าหลายครั้งเกี่ยวกับ CI/CD ที่ Agoda โดยเฉพาะ Orchestration tools ที่พัฒนาโดย Core Engineering Team นี่เป็นหนึ่งใน project ที่สนุกที่สุดที่เราทำกันมา ซึ่งผมย้ำทุกครั้งว่าเรามี CI เพื่อให้เรามั่นใจมากขึ้นในการ deploy แต่ไม่ได้หมายความว่ามันจะไม่พังบน Production :P

เท่านี้ องค์ประกอบในการ Fail like a boss ก็ครบถ้วนสมบูรณ์ ทีนี้เราก็สามารถ Fail ได้อย่างสบายใจ ที่ Agoda นั้นเมื่อเราทำตาม practice ที่แนะนำและผ่าน process แล้วนั้น การ Fail ไม่ได้ถือเป็นเรื่องร้ายแรงเสมอไป เรามี project มากมายที่ไม่ได้ไปต่อ เพราะว่าไม่สามารถเอาชนะฟีเจอร์เดิมที่มีอยู่ก่อนได้

Fail จริง !!!

ถึงแม้เราจะมีการเตรียมการมาจนพร้อมแล้ว แต่ว่าโอกาสในการผิดพลาดจริงก็เกิดขึ้นได้เสมอ ที่ Agoda นั้น การผิดพลาดไม่ได้หมายถึงความสูญเสียในหน้าที่การงาน แต่หมายถึงโอกาสในการเรียนรู้จากการผิดพลาดอีกด้วย มีเรื่องเล่าไว้ว่า มีหมีสองตัวที่เข้ามาทำงานที่ Agoda ได้ ตัวนึงอยู่มาสักพักแล้ว อีกตัวนึงเพิ่งเข้ามาทำงานได้ไม่ถึงสัปดาห์ดี หมีทั้งสองตัวมีโอกาสดีในการทำ production ล่มอยู่นาทีกว่าๆ (ไล่ตาม timezone มาเลยทีเดียว) และหมีทั้งสองตัวก็ได้รับโอกาสอันยิ่งใหญ่ในการช่วย improve ระบบหลักที่ทำให้เกิด incident ในโอกาสนั้น ตอนนี้ หมีหนึ่งในสองตัวนั้นก็ยังทำงานอยู่ที่ Agoda อย่างสงบสุข

เป็นยังไงกันบ้างครับ จะเห็นว่าที่ Agoda นั้น ด้วยความต้องการในการใช้งานระบบนั้นถึงจะไม่เปิดโอกาสให้เราได้ Fail มากนัก แต่ด้วยทั้ง Engineering practice และ Culture ของบริษัทที่เป็น Data driven company นั้นอนุญาตให้เราสามารถ Fail ได้มากที่เราต้องการ และยังเปิดโอกาสให้เราเรียนรู้จากความผิดพลาดของเรา และพัฒนาให้ดีขึ้นในทุกๆ Feedback loop อีกด้วย ถ้าใครสนใจอยากไปลอง fail จริง เจ็บจริง สามารถเข้าไปตรวจสอบและยื่นสมัครได้ที่ https://careersatagoda.com/ ครับ

Happy Coding ครับ