Blockdit Logo (Mobile)
ณัฐมาคุย
ยืนยันแล้ว
•
7 ก.ย. 2022 เวลา 01:40 • ความคิดเห็น
การรองรับสถานการณ์แอปล่ม ตอนที่ 4: วันเกิดเหตุ
ผมขอข้ามสิ่งที่ควรทำในช่วงก่อนการ launch ออกไป หากมีใครอยากฟังไว้วันหลังจะมาเขียนถึงครับ
เราข้ามกันไปวันเกิดเหตุหลังจาก launch เลยนะครับ ปกติเรามักจะเลือกวัน launch ที่เป็นวันดี นอกจากจะไปดูดวง เลือกวัน go live ที่เป็นวันดีที่สุด ไปไหว้ศาล ขออำนาจสิ่งศักดิ์สิทธิ์ทั้งหลายให้คุ้มครองแล้ว เรายังมักต้องเลือกวันที่จะมีการใช้งานไม่สูงมากนัก หากเกิดเหตุ เราจะได้มีโอกาสแก้ไขได้ทันท่วงที
1
ดังนั้นด้วยอำนาจสิ่งศักดิ์สิทธ์นั้น ๆ และถ้าทีมงานไม่แย่จนเกินไป การ launch 🚀 ในวันแรก ๆ มักจะเป็นไปได้ค่อนข้างโอเค เพราะทีมงานจะคอยระวังโน่นนี่นั่น ประกอบกับคนอาจจะยังไม่เปลี่ยนมาใช้แอปใหม่ทันที
1
ปัญหามักจะเกิดขึ้น หลังจากนั้นสักพัก ยามที่ทางทีมเริ่มลดการ์ดลง ผู้ใช้และปริมาณการใช้งานก็จะเริ่มถ่าโถมมาเหมือนผู้ติดเชื้อโควิด
หากระบบถูกออกแบบมาไม่ดี และไม่ได้มีการทดสอบความสามารถของระบบที่ดีพอ ปัญหาก็จะเริ่มเกิดขึ้นในเวลานี้ ถ้าทีมงานไม่ได้มีระบบ monitoring ที่ดีพอ ทีมงานก็จะไม่รู้เลยว่าเกิดอะไรขึ้น แต่ลูกค้าจะเริ่มด่าว่าอยู่ในใจ ถ้าทนไม่ไหวก็จะเริ่มโทรไปที่ contact center หรือโพสต์ลงสื่อโซเชียล
ในที่สุด ทีมงานก็จะเริ่มโดนสะกิดให้รู้ตัว แต่เนื่องจากปัญหา scalability มักจะไม่ได้เป็นอยู่ตลอดเวลา ทางทีมงานที่ไร้เครื่องมือในการ monitor ก็มักจะบอกว่า ระบบปกตินะ แล้วก็ปล่อยให้เรื่องนั้นผ่านไป เจ้าหน้าที่ contact center ก็จะบอกให้ลูกค้าลองใหม่ ซึ่งก็มักจะได้
แต่เหตุการณ์นั้นเอง เป็นเสมือนภูเขาไฟที่มีควันพวยพุ่งออกมาเล็กน้อย เป็นลางบอกเหตุล่วงหน้าว่า ภูเขาไฟกำลังจะปะทุขึ้นในอนาคต
และแล้ว วันเกิดเหตุก็มาถึง วันนั้นมักจะเป็นวันที่มีเหตุการณ์ที่ไม่เหมือนวันธรรมดาเกิดขึ้น ไม่ว่าจะเป็นวันที่ shopee ลดราคาสินค้า วันหวยออก วันเงินเดือนออก ที่คนแห่กันใช้แอปของธนาคารพร้อม ๆ กันในช่วงเวลาอันสั้น
และเวลานั้นเองที่ระบบถูกผลักไปอยู่ในจุดที่เกินความสามารถของระบบ ที่ผมขอเรียกว่า performance cliff เพราะมันเหมือนการที่รถวิ่งขึ้นภูเขา แล้วพอไปสุดทางก็ตกเหว เปรียบได้กับจำนวนธุรกรรมต่อวินาทีที่จะเพิ่มสูงขึ้นเรื่อย ๆ แต่พอไปถึงจุดนั้น จำนวนธุรกรรมต่อวินาทีกลับลดลง เวลาที่ใช้ต่อธุรกรรม (latency) เพิ่มสูงขึ้นอย่างรวดเร็ว
ทีมงานที่ไม่พร้อมจะงงทันทีว่าจะต้องทำอะไร ในขณะที่หัวหน้าก็เริ่มที่จะร้อนรน จะคอยถามลูกทีมอยู่ว่าเกิดอะไรขึ้น สาเหตุคืออะไร แล้วเราทำอะไรกันดี
ความสับสนก็จะเริ่มบังเกิด ทีมงานที่ดูแลระบบยังไม่เคยชินกับระบบต่าง ๆ แถมยังไม่ได้เป็นคนพัฒนาเองด้วย ก็จะได้แต่เดาว่า เป็นอย่างนั้นมั้ง เป็นอย่างนี้มั้ง คนเป็นหัวหน้าก็จะเริ่มลังเลว่าจะต้องแก้ไขปัญหาสถานการณ์อย่างไร เพราะลูกน้องก็ดูไม่น่าเชื่อถือเอาเสียเลย
ในจังหวะนี้ หัวหน้าก็จะเริ่มร้อนรน และพยายามหาคนอื่นมาช่วยก่อความสับสนให้มากขึ้นไปอีก จะเริ่มดึงทุกคนที่เกี่ยวข้องมารวมกัน เพื่อช่วยกันหาสาเหตุ แต่หากดึงมามากไป จะเกิดอีกปัญหาหนึ่ง คือ ไม่มีใครพูดอะไร เพราะคนที่มีข้อมูลของปัญหา ก็ไม่ใช่คนที่สร้างระบบ คนที่สร้างระบบก็งง ๆ ว่าเกิดอะไรขึ้น เพราะไม่มีข้อมูล
1
และปัญหานี้จะถูกทำให้เลวร้ายลงไปอีก ถ้าคนที่เกี่ยวข้องไม่ได้อยู่องค์กรเดียวกัน ทีมที่พัฒนาระบบอาจจะถูกจ้างมาจากที่อื่น ทีมที่บริหารโครงการอาจจะเป็นอีกบริษัทหนึ่ง ทีมที่ดูแลระบบอาจจะเป็นอีกบริษัทหนึ่ง
ส่วนโครงการพื้นฐานของระบบก็อาจจะถูกดูแลโดยอีกบริษัทหนึ่ง พอเวลาเกิดปัญหา จึงต้องใช้เวลานาน และต้องตัดสินใจว่าจะดึงคนเหล่านี้เข้ามาจริง ๆ หรือไม่ เพราะจะมีค่าใช้จ่ายเพิ่มเติม แถมคนเหล่านี้อาจจะไม่ว่าง เพราะเขาอาจจะไปทำโครงการอื่นกับนายจ้างใหม่เรียบร้อยแล้ว
หากเราตกอยู่ในสถานการณ์แบบนี้ เราควรจะต้องทำอย่างไร เรามาติดตามกันในตอนหน้ากันครับ
1
สามารถติดตามตอนอื่นๆ ได้จากซีรีย์ "การรองรับสถานการณ์แอปล่ม" ด้านล่างนี้ครับ

ดูเพิ่มเติมในซีรีส์

โฆษณา