มาดูการจัดการ Technical Debt ของ TicketMaster กัน

เห็น drama จากการจองตั๋วคอนเสิร์ตผ่านระบบของ ThaiTicketMajor ดูแล้วไม่สนุกเท่าไร

ดังนั้น จึงลองไปดูระบบ TicketMaster กันดีกว่า
มาดูกันหน่อยสิว่า เขาจัดการกับพวก Technical Debt หรือ หนี้จากการพัฒนาระบบอย่างไร ?
น่าจะช่วยลดปัญหาของระบบลงไปได้พอควรเลยนะ

ที่มา :: What Ticketmaster is doing about technical debt

เป็นบทความอธิบายถึงการเดินทางในหนึ่งปีที่ผ่านมาของทีมพัฒนาระบบ TicketMaster
สำหรับการจัดการกับ Technical Debt
มาดูการเดินทางว่ามันน่าสนใจอย่างไร เป็นอย่างไรกันบ้าง ?

เริ่มต้นด้วยการศึกษาและค้นคว้า ซึ่งพบว่า Technical Debt มันอยู่รอบๆ ตัวเรา

ซึ่งการจัดการนั้น มันคือ business decision
ดังนั้นสิ่งที่ทาง IT จะต้องทำคือ การนำเสนอข้อมูลที่ถูกต้อง
เพื่อโน้มน้าวให้คนที่ตัดสินเห็นคุณค่า และ เข้าใจ

เริ่มด้วยขนาดของปัญหา ต้องใช้การเปรียบเทียบกับระบบอื่นๆ ด้วย
แสดงดังรูป

จากรูปจะเห็นได้ว่า
ระบบของ TicketMaster นั้นมี source code จำนวน 4.5 ล้านบรรทัด (Line of Code)
โดยแบ่งออกเป็น code ถึง 13 platform ไม่รู้ว่าจะเยอะไปไหน
ใช้เทคโนโลยีในการพัฒนาที่หลากหลายทั้ง .NET และ LAMP

ดังนั้นในการศึกษาจำเป็นต้องแบ่งคนเป็นกลุ่มตาม platform
ซึ่งทำให้ได้ข้อสรุปหนี้ต่างๆ ออกมาดังนี้

1. Application Debt
2. Infrastructure Debt
3. Architecture Debt

1. Application Debt
เป็นหนี้ที่อยู่ใน source code ที่เราสร้าง product ขึ้นมานั่นเอง
ซึ่งมันจะนำไปสู่ปัญหาต่างๆ เช่น

• ยากต่อการเพิ่ม feature
• ยากต่อการแก้ไข
• ยากต่อการดูแล
• ค่าใช้จ่ายในการดูแล และ ให้บริการต่างๆ สูงขึ้นเรื่อยๆ
• ผู้ใช้งานมีประสบการณ์ใช้งานระบบที่แย่

2. Infrastructure Debt
เป็นหนี้ที่อยู่ใน environment ของระบบ เช่นพวก server, network, software ต่างๆที่ใช้งาน
ซึ่งมันจะนำไปสู่ปัญหาต่างๆ เช่น

• ระบบมีช่องโหว่มากมาย ซึ่งทำให้โดนโจมตีได้ง่าย
• ไม่สามารถรองรับจำนวนผู้ใช้งานมากๆ ได้ หรือ ผู้ใช้งานต้องรอในคิวนานมากๆ
• ระบบทำงานช้า หรือ ตอบสนองช้า
• ทำการ recovery ระบบได้ยาก และ ช้า
• ค่าใช้จ่ายในการดูแล และ ให้บริการต่างๆ สูงขึ้นเรื่อยๆ

3. Architecture Debt
เป็นหนี้ที่เกิดจากการออกแบบระบบที่ไม่เหมาะสม
ซึ่งมันจะนำไปสู่ปัญหาต่างๆ เช่น

• ระบบทำการแก้ไขได้ยาก และ มีค่าใช้จ่ายที่สูง
• ไม่ตอบสนองต่อ requirement ของทาง business
• เรื่องของ Single Point Of Failure (SPOF) ในระบบที่มีอยู๋มากมาย ทำให้ระบบล่มบ่อยๆ
• ระบบที่มีความซับซ้อน มันจะยากต่อการดูแลรักษา และ จัดการ
• สุดท้ายก็จะโดนคู่แข่งแซงหน้า หรือ เหยียบให้จมดิน

เมื่อแบ่งกลุ่มของหนี้ได้แล้ว จากนั้นคือ การสร้าง model เพื่อจัดการหนี้กัน
ซึ่งสรุปออกมาดังรูป

โดยในแต่ละส่วนจะมี Automated tool ช่วยจัดการดังนี้

Application Debt ใช้เครื่องมือดังนี้

• SonarQube สำหรับวัดค่า Code coverage และ Complexity
• Yottaa สำหรับดูเวลาที่ระบบทำการตอบสนองต่อผู้ใช้งาน
• Veracode สำหรับเรื่อง application security หรือเรื่องความปลอดภัยของระบบงาน

Infrastructure Debt ใช้เครื่องมือดังนี้

• Splunk สำหรับดู performance ของ infrastructure ของระบบ
• SOASTA สำหรับเรื่องของ scalability ของระบบ

จะเห็นได้ว่า Automated tools นั้นยังไม่ครอบคลุมในทุกๆ เรื่อง
ตามที่กำหนดไว้ใน model
ดังนั้นจำเป็นต้องทำการวัดผลต่างๆ แบบ manual ด้วย

จึงได้กำหนดขั้นตอนการทำงานขึ้นมา
ซึ่งเรียกว่า Technical Debt Mapping process
มีเป้าหมาย 3 เรื่องคือ

1. Consistent คือ มีความสอดคล้อง ไปในทางเดียวกัน
2. Repeatable คือ สามารถทำซ้ำๆ ได้
3. Transparent คือ ความโปร่งใจ ทุกๆ คนในทีมงานเห็นภาพเดียวกัน

เพื่อทำให้ได้ข้อมูลที่ถูกต้อง และ เป็นประโยชน์ออกมานั่นเอง

แสดงดังรูป

จากรูปมี 3 เรื่องที่น่าสนใจคือ

1. Component diagram ซึ่งจะเป็นภาพ high level ของแต่ละระบบ ซึ่งทุกๆ คนจะต้องเห็น ไม่ใช่เก็บไว้ดูคนเดียว หรือ แผนกเดียวนะ
2. Consensus ในการพูดคุยนั้นทุกๆ คน จะต้องมีความเห็นร่วมกัน และ เดียวกันทั้งหมด
3. Work Item ทีมจะต้องทำการจัดเรียงลำดับความสำคํญของงาน และ เลือกงานที่สำคัญมาทำก่อน มันทำให้ทีม focus กับงาน

ปัญหาต่อมา คือ ทีมมีข้อมูลเรื่องหนี้เยอะมาก จะทำอย่างไรดี ?

เมื่อทีมได้ข้อมูลทาง Technical Debt มาเยอะมากๆ
สิ่งที่ลำบากต่อมา คือ
จะเลือกหนี้ตัวไหนมาจัดการล่ะ ?
หรือหนี้ตัวไหนมันมีคุณค่า และ คุ้มค่าต่อการลงทุนมากๆ ล่ะ ?

สิ่งที่เราต้องการคือ รายงานเพื่อสรุป Technical Debt
และที่สำคัญต้องนำไปใช้เพื่อเสนอให้กับทางฝ่ายบริหาร และ business เข้าใจด้วยนะ
ดังนั้นทีมจึงสร้างรายงานออกเป็น 3 ส่วน ดังนี้

1. Part A สำหรับการสรุปคะแนนของ Technical Debt ในแต่ละกลุ่ม แยกตาม platform ออกมา
2. Part B สำหรับแสดงรายละเอียดในแต่ละกลุ่ม เพื่อทำให้ผู้อ่านเข้าใจว่าจะละส่วนมีปัญหาอะไรบ้าง โดยเรียงจากความสำคัญสูงไปต่ำ
3. Part C สำหรับสรุป Technical Debt ที่ไม่เคยถูกเหลียวแล หรือ ทำการแก้ไขเลย ซึ่งแยกออกเป็นกลุ่มๆ ไว้

มาดูตัวอย่างของรายงาน

สิ่งที่ได้จากการจัดการ Technical Debt ของ TicketMaster

การจัดการ Technical Debt ไม่ใช่เพียงการค้นหาหนี้ในระบบเท่านั้น
การจัดการ Technical Debt ไม่ใช่เพียงการกำหนดตารางเวลาเพื่อมาแก้ไขระบบเท่านั้น
แต่สิ่งที่ต้องทำก็คือ การแสดงรายงานต่างๆ ออกมาจากระบบให้ได้
เพื่อทำให้เราทุกๆ คนเห็นว่ามี issue อะไรบ้าง
เพื่อจะได้เตรียมแผนรับมืออย่างทันท่วงที

ทางทีมพัฒนาก็ต้องมีเครื่องมือช่วยเหลือในการจัดการกับ Technical Debt เช่นกัน
เพื่อทำให้ทีมเห็น issue และจะได้ทำการแก้ไขได้ง่ายขึ้น
รวมทั้งต้องให้ความรู้ ความเข้าใจเกี่ยวกับปัญหาด้วยเช่นกัน
เพื่อไม่ให้เกิดขึ้นซ้ำๆ อีก

โดยการแก้ไข Technical Debt จำเป็นต้องได้รับความยินยอมจากทุกๆ ฝ่าย
ดังนั้น เรื่องการเปิดเผยข้อมูลต่างๆ ให้เห็นอยู่อย่างสม่ำเสมอ เป็นเรื่องที่สำคัญมากๆ
เพื่อทำให้เห็นว่า ระบบกำลังมีปัญหาหรือไม่ กระทบกับอะไรหรือไม่ อย่างไร ??

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

วันนี้คุณจัดการกับ Technical Debt กันหรือยัง ?