ถ้าได้เข้าไปดูระบบนี้ใหม่ จะเริ่มยังไง

พอดีเห็นข่าว ประกันสังคมเสนอแผนสำรองโยกกลับไปใช้เมนเฟรม หลังระบบใหม่รองรับโหลดไม่ไหว เห็นข่าวแล้วหงุดหงิดเลย เพราะผมเคยย้ายระบบเก่า แต่ Scale ไม่ได้ใหญ่ขนาดนี้ แต่พอย้ายแล้วมีสะดุด จนโดนผู้ใหญ่มาตำหนิใช้ระบบใหม่ทำไม ของเดิม VB6 ใช้มา 20-30 ปีไม่เกิดปัญหาเลย พอปรับแล้วลูกค้าบ่นยับ หน้าที่การเก็บเงินงวดนี้ 1x ล้านคุณต้องรับผิดชอบนะ

แต่จริงๆแล้ว เราต้องมาปรับ Mindset กันก่อนเลย จากนั้นค่อยมาทำความเข้าใจระบบ และเอา Pattern + Constraint ไปเสียบตามนี้

ปรับ Mindset ใช้มา 20-30 ปีไม่เกิดปัญหาเลย

จากระบบเดิมที่ผมเคยดูมา ปัญหามันมีเพียบ แต่เสียงจาก User อาจจะไม่เข้าไปถึงผู้ใหญ่ หรือ คนรอบข้างไม่กล้าบอก เลยกลายเป็นว่าแกคิดว่ามันดี ทั้งที่จริงมันช้า และมี Bug รวมถึง อาจจะเรื่องการทำงานแบบ Concurrent พอ Feedback ไม่ถึง มันจะกลายเป็นว่าทุกคนปลง เหมือนมันปกติแล้ว

และอีกอัน การ Scale HW มันแก้ปัญหาแบบปลายเหตุสุดๆ เพราะเอาจริงๆ มันช่วย แค่ไม่คุ้ม เพราะสุดท้ายจะไปเจอข้อจำกัด แบบ SW มันใช้ HW ได้ไม่เต็มที่

แล้วถ้าพังอย่าไปทวงเงินกับพนักงาน !! อย่า Blame นี่แหละมีสติ

ถ้าได้เข้าไปดูระบบนี้ใหม่ จะเริ่มยังไง

อย่างแรกต้องรู้พฤติกรรมเดิมของระบบก่อนเลย ว่าระบบนี้มีใครที่เกี่ยวข้องบ้าง แล้วมี Event อะไรบ้าง เพื่อสกัด

• Functional Requirement - ของเดิมที่มี จุดที่อยากปรับปรุง
• Quality Attribute (Non-Functional Requirement) พวก Availability / Performance / Scale

รวมถึงข้อมูลในอดีตด้วย อย่างการขยายของข้อมูล / Peak Load (ถ้าไม่รู้ต้องลอง Load Test) / Max User / คำสบถกับของเดิม

ที่สำคัญ Flow การทำงานของคนข้างใน ระบบใหม่มันช่วยเค้า แต่สุดท้าย อาจจะต้อง replace เค้าด้วย อาจจะต้องหาทางช่วย เพื่อไม่ให่มันไวเกิดไป จนเค้าปรับตัวไม่ทัน ของผม 4-5 ปี แล้วคนเดิม Rotate ไปส่วนอื่นกัน ถ้าไม่รู้ตรงนี้ ถ้าปรับทัศนคติไม่ดี เวลาเราไปทำงานจะต่อต้านเยอะมาก

พอเราได้ Quality Attribute มันช่วยเลือกได้ว่าต้องใช้ Architecture และมาดูเรื่อง Trade-Off

อีกส่วน คือ พวก Data มันต้องมาแยก อย่างน้อยตาม DDD (Domain Driven Design) เพื่อที่เราจะได้รู้ว่ามันเกิดจากใคร ใครเป็นเจ้าของ แล้วข้อมูลพวกนี้ มันต้องเชื่อมโยงกับใครไหม ต้องมีทำ API กลางเป็น Open Data ให้ไหม

ถ้าเราแบ่งตาม Domain จะได้ Functional ที่มันชัดเจนมี Bounded Context จะได้ว่า Sub System ได้ สมัยนี้จะเรียก Microservice สินะ การแยกย่อย พอมันเล็ก เรารู้ว่าจุดไหนต้อง Scale เยอะ อันไหนใช้แบบปกติได้

จากนั้นเอาภาพ Draft ที่ได้มาวาง Architecture + Trade-Off + Constrait ของแต่ละจุด เพื่อเอาของ

• API จะคุยกับแบบไหน ปกติ REST หรือ งาน Batch
• จำเป็นต้องมี UI ไหม
• User ที่ใช้งานหลักเป็นใคร พนักงานภายใน 2000 คน หรือ User ในระบบทั้งหมด มันจะไป Refer ส่วน Peak Load / Max User / คำสบถกับของเดิม ตอนต้น
• ต้องใช้ Storage / File System
• การเก็บ Data แต่ละแบบ RDBMS / NoSQL
  - จัดการ Schema อย่างไร
  - แยก DB เพื่อ Scale เฉพาะจุดไหม ? ถ้ารวมหมดตอน Scale จะยิ่งแพงนะฅ
  - Data นี้ใครใช้บ้าง ระบบที่เคยดูทุกคนสร้าง View / Table ตัวเองครอบหมดเลยปรับทีลำบาก วนมา App ทำ API กลางเป็น Open Data ไหม
• อื่นๆอีกมากมาย การทำ Caching / Scale / Retry Flow

และอย่างลืมแผนพัฒนาด้วยนะ ถ้าระบบใหญ่ เราสามารถแยกส่วนได้ไหม เช่น ระบบเดิมมี 10 Feature แยกงานย่อยๆ มาให้ 10 Sub System ขึ้นที่ละอัน ค่อยลดงานระบบเดิมลง ไปจนครบ

และแนวทางการทดสอบ Feature / Quality Attribute / System Transition

ยิ่งทำระบบที่ยิ่งใหญ่ มันต้องยิ่งคิดให้เยอะ มันไม่มีแบบแผนที่ตายตัวด้วยครับ

แถมสำหรับระบบที่มันพังตอนนี้จะแก้อย่างไร

• ดับไฟ
  - หาก่อนว่าจุดที่ข้างเกิดจากอะไร ต้องมาดู Monitoring/Logs แล้วที่ช้าเกิดจากอะไร เขียน Code ไม่ดี หรือ Data Migrate มันแปลก App เลยทำงานประหลาดตาม
  - ระยะสั้น อาจจะต้อง Scale HW และปรับ Config เพิ่ม Index / Config ของ App Server ช่วย Cache / Limit ของ API Gateway

• ระยะยาว
  - เอา Caching มาช่วย ซึ่งมันต้องแก้ Code และต้องยอมรับว่า Refactor อาจจะดีกว่าได้
  - Optimize Database - Slow Query Log ต้องแก้ยังไง ปรับ SQL ไหม บางอันมีจริงๆ แบบที่รุ่ยเจี๋ยมันพูด
  - Load Testing ใหม่ด้วยข้อมูลจริง
  - จัดการหนี้ทางเทคนิค (Technical Debt) ทยอยแก้ให้หมด

ถ้าต้องรื้อ Architecture ยาวนะ ดังนั้นวางแผน และคิดให้เรียบร้อย