ในฐานะ tech lead ผมจะเริ่มจากแปลง “ผู้ใช้เพิ่มสิบเท่า” เป็นรูปแบบการใช้งานที่คาดหมาย เป้าหมายบริการ และแผนที่ทีมส่งมอบได้ จำนวนบัญชีที่ลงทะเบียนเพียงอย่างเดียวไม่ได้บอกจำนวน request ในช่วงที่ยุ่งที่สุด
สมมติธุรกิจวางแผนแคมเปญให้แพลตฟอร์มคำสั่งซื้อ คำถามคือลูกค้ายังดูสินค้า ซื้อ และรับการยืนยันได้หรือไม่ระหว่างแคมเปญ ภายใต้เวลาและงบประมาณที่มี
ถามทีม product ว่าผู้ใช้จะเข้ามาเมื่อใดและทำอะไร การเพิ่มทีละน้อยตลอดปีต่างจากแคมเปญที่ทุกคนออนไลน์พร้อมกัน
ตัวอย่างเช่น บัญชีลงทะเบียน 100,000 บัญชี โดยใช้งานพร้อมกัน 1% หมายถึงผู้ใช้พร้อมกัน 1,000 คน หากเป็น 5% จะเป็น 5,000 คน นี่เป็นสมมติฐานตัวอย่าง ไม่ใช่อัตราส่วนมาตรฐาน ยังต้องประเมินความถี่ request และงานต่อ request ด้วย
แจกแจงโหลดที่แคมเปญสร้าง:
สิ่งนี้ทำให้มีภาระงานสำหรับทดสอบ แทนคำสั่งกว้าง ๆ ว่าเพิ่ม server สิบเท่า
กำหนดเวลาตอบสนอง อัตรา error และการทำงานจนเสร็จที่ยอมรับได้สำหรับเส้นทางสำคัญ กำหนดความสดใหม่ของข้อมูลและความคาดหวังการกู้คืนในจุดที่เกี่ยวข้องด้วย รายงานล่าช้าอาจยอมรับได้ แต่ checkout ล้มเหลวไม่ได้
[Campaign assumptions] -> [Expected workload] -> [Service targets]
|
[Acceptance tests]
เป้าหมายเชื่อมงานเทคนิคกับผลที่ลูกค้าได้รับ ช่วยตัดสินว่าการปรับปรุงเพียงพอหรือยัง และยอมลดคุณภาพส่วนใดได้เมื่อโหลดสูง
ใช้ข้อมูล production และ load test ที่ใกล้เคียงจริง ตรวจ query ช้า connection ฐานข้อมูล CPU หน่วยความจำ อายุงานใน queue และ quota บริการภายนอก รวมกรณี traffic กระจุกที่สินค้ายอดนิยม ไม่ใช่สุ่ม request อย่างเดียว
ถ้าจำกัดที่ connection ฐานข้อมูล การเพิ่ม node แอปพลิเคชันอาจเพิ่มการแย่งทรัพยากร ถ้าจำกัดที่ quota ผู้ให้บริการชำระเงิน แอปที่เร็วขึ้นก็ไม่ได้เพิ่ม quota นั้น
ทดสอบ cache ที่ยังไม่มีข้อมูลและ instance ล้มเหลวควบคู่กับการทำงานปกติ เราต้องมีกำลังสำหรับกู้คืนระหว่างแคมเปญ ไม่ใช่แค่พอสำหรับการทดสอบในสภาพสมบูรณ์
| สิ่งที่พบ | แนวทางที่ควรพิจารณา | หลักฐานที่ต้องมี |
|---|---|---|
| อ่านข้อมูลแพงซ้ำ ๆ | ปรับ query หรือ cache ผลที่เหมาะสม | งานฐานข้อมูลลดลงโดยความสดใหม่ยังยอมรับได้ |
| งานเบื้องหลังแย่งทรัพยากรกับการซื้อ | จำกัดหรือแยกกำลังประมวลผล | Checkout ยังปกติขณะมีโหลดเบื้องหลัง |
| Quota ของระบบที่พึ่งพาไม่พอ | ขอเพิ่มหรือควบคุมการรับงาน | ยืนยัน quota และทดสอบเมื่อถึงขีดจำกัด |
| กำลังยังไม่พอหลังแก้จุดเล็กแล้ว | ประเมินการขยายหรือเปลี่ยนแบบครั้งใหญ่ | ประโยชน์ที่วัดได้ แผนย้าย และต้นทุน |
แต่ละงานต้องมีเจ้าของ งบประมาณ dependency กำหนดส่ง และ acceptance test รวมงาน deploy การฝึกปฏิบัติการ และเตรียม on-call ไม่ใช่แค่เขียนระบบ
จัดลำดับตามผลต่อลูกค้าและความเสี่ยงในการส่งมอบ การเขียนใหม่ครั้งใหญ่หรือทำ sharding ต้องมีเหตุผลที่พิสูจน์ได้และเวลาพอสำหรับย้ายและตรวจสอบ
ปล่อยการเปลี่ยนแปลงเป็นส่วนที่จัดการได้และทดสอบเส้นทางใช้งานร่วมกัน กำหนดเมื่อใดเพิ่ม traffic หยุดเพิ่ม หรือ rollback การเปลี่ยนรูปแบบข้อมูลอาจต้องกู้คืนโดยเดินหน้าปรับแก้ แทน rollback ง่าย ๆ
เตรียมการลดบริการอย่างควบคุมได้: เลื่อน export ที่ไม่จำเป็น จำกัดงานเบื้องหลัง หรือปฏิเสธ request ส่วนเกินเพื่อรักษางานสำคัญ ตรวจว่ามาตรการลดโหลดจริงและลูกค้าได้รับผลลัพธ์ชัดเจน
ถ้าเป้าหมายไม่สอดคล้องกับวันส่งหรืองบ ให้เสนอทางเลือกที่เป็นรูปธรรมกับ product: ทยอยรับผู้ใช้ ลดฟีเจอร์ที่แพง หรือเพิ่มงบแก้คอขวดที่วัดได้ อธิบายผลต่อลูกค้าและความไม่แน่นอนของแต่ละทาง
จำไว้: สมมติฐานการเติบโต → เป้าหมายบริการ → ขีดจำกัดที่วัดได้ → แผนที่มีเจ้าของ → การปล่อยที่ซ้อมแล้ว Tech lead ต้องส่งมอบแผนกำลังระบบที่รวมคน เงิน และการกู้คืน
คลังคำถามสัมภาษณ์งาน IT พร้อมคำตอบโดยละเอียด — ตั้งแต่ระดับ Junior ถึง Senior
บริจาค