การรองรับสถานการณ์แอปล่ม ตอนที่ 1: ทำไมปล่อยให้ล่มเป็นระยะยาวนาน
จากเหตุการณ์ที่มีแอปของธนาคารแห่งหนึ่งล่ม และผมได้เห็นคอมเมนต์จากผู้ใช้งานหลายรายที่เขียนในเชิงตำหนิเป็นจำนวนมากนั้น ผมขอแสดงความเห็นใจกับทั้งลูกค้า และพนักงานและผู้บริหารของธนาคาร
ขออนุญาตชี้แจงในฐานะคนที่ต้องทำงานแก้ไขสถานการณ์เหล่านี้อยู่เสมอ ๆ และการแก้ไขปัญหาในทุก ๆ ครั้ง คนทำงานทำอะไรกันบ้างเพื่อแก้ไขสถานการณ์กันบ้าง และมันเกิดอะไรขึ้น
Cr : www.tcijthai.com
เวลาเกิดปัญหาระบบล่มนั้น ต้นเหตุของปัญหาแตกต่างกันมาก หากปัญหาเกิดจากการทำงานผิดพลาดของที่ใดที่หนึ่ง เช่น ระบบเก็บข้อมูลมีปัญหา การไปแก้เปลี่ยนอุปกรณ์ก็สามารถที่จะทำได้เร็ว และทำให้ระบบกลับมาทำงานได้
แต่หากปัญหาเกิดจากเรื่องของความสามารถของระบบ (capacity) การแก้ไขจะยากกว่ามากด้วยสาเหตุหลายประการ ไม่ว่าจะเป็นเพราะ
- ●ไม่รู้ว่าปัญหาอยู่ตรงไหน
เวลาเกิดเหตุระบบล่มแบบนี้ หากไม่มีข้อมูล (monitoring & observability) ที่ดี มันจะให้ความรู้สึกเหมือนตึกถล่ม เวลามันถล่ม เราติดอยู่ในนั้น เราจะมองไม่เห็นเลยว่ามันเกิดขึ้นได้อย่างไร
ดังนั้น ข้อมูลของสถานะระบบทั้งที่เป็นแบบในอดีต (historical) และแบบ real-time จึงมีความสำคัญมาก ๆ ทีมงานไอทีจะต้องนำข้อมูลนี้มาตรวจสอบดูว่าเกิดอะไรขึ้น และมีความผิดปกติอะไรบ้าง
โดยวิธีการตรวจสอบนั้น จะต้องมีข้อมูลให้เห็นว่าในสภาวะปกติ ระบบทำงานอย่างไร ในสภาพที่โหลดการทำงานสูงขึ้น แต่ละระบบตอบสนองอย่างไร และระบบติดปัญหาคอขวด (bottleneck) ที่ใด
หากทราบปัญหาคอขวด ก็พอจะสันนิษฐาน (เดา) เอาว่านั่นอาจจะเป็นสาเหตุ เราก็จะต้องทยอยแก้กันไป
- ●ไม่รู้ว่าจะแก้อย่างไร
หากเป็นระบบที่สามารถที่จะขยายระบบ (scale) ได้ การแก้ไขปัญหาก็อาจจะง่ายหน่อย เราอาจจะไปขยายระบบไม่ว่าจะเพิ่ม CPU, Memory, Disk หรือเพิ่มจำนวนโหนด ทำ sharding/partitioning เพิ่มเป็นต้น
แต่หากระบบที่มีปัญหาเป็นระบบที่ไม่สามารถที่จะ scale ได้โดยง่าย หรือระบบที่ไม่ได้ถูกออกแบบมาถูกต้อง การแก้ไขปัญหาก็จะยากขึ้นอีก เราอาจจะต้องเปลี่ยนเทคโนโลยี หรือการเรียกใช้ให้เปลี่ยนไป
อย่างในระบบการเก็บข้อมูลที่มีการเรียกใช้มาก ๆ เรามักประสบปัญหาที่เรียกว่า hot key คือ ข้อมูลบางส่วนอาจจะมีการถูกเรียกใช้ 10-100 เท่าของข้อมูลส่วนอื่น และถ้าปริมาณการเรียกนี้สูงมาก ๆ หรือสูงกว่าความสามารถของระบบ การแก้ไขปัญหาด้วยการ scale ระบบ จะไม่ค่อยช่วยแก้ไขปัญหา เราจึงต้องเริ่มที่จะแก้ไขปัญหาด้วยวิธีการอื่น เช่น การใช้ cache เข้ามาช่วย
แต่ปัญหาคือ การแก้ในลักษณะนี้ ต้องมีการทดสอบที่ดี ระมัดระวังไม่ให้การ cache แล้วเกิดปัญหาข้อมูลไม่สอดคล้องกัน (data inconsistency) การแก้จึงต้องมีการทดสอบที่ดี เพื่อให้มั่นใจว่าจะไม่ทำให้เกิดปัญหาอื่น ๆ ดังนั้นจึงอาจจะใช้เวลานานกว่าที่จะแก้ไขปัญหาได้
- ●ไม่กล้าแก้
นี่คืออีกหนึ่งในปัญหาที่เรียกว่า Analysis-Paralysis คือ ทีมงานอยู่ในสภาวะกดดันที่จะต้องแก้ไขปัญหา แต่ไม่แน่ใจว่าแก้แล้วจะดีขึ้นหรือแย่ลง ทำให้ทีมได้แต่คิดว่าจะทำอะไร แต่ไม่กล้าที่จะฟันธงทำอะไร ได้แต่คิดและเดาเอาไปเรื่อย ๆ ว่าน่าจะเป็นอย่างนั้นอย่างนี้
หากแก้ไปแล้ว สถานการณ์แย่ลง ก็ยิ่งจะโดนผู้บริหารต่อว่าอีก ดังนั้นทีมงานก็จะพยายามวิเคราะห์ และหาคำตอบให้ได้ ซึ่งภายใต้สถานการณ์ในลักษณะแบบนี้ การกอบกู้สถานการณ์ให้เร็วที่สุดนั้นสำคัญที่สุด หากจำเป็นจะต้องปิดระบบเพื่อแก้ไข ก็ควรต้องทำ หากจะยังทดสอบไม่พอ ก็อาจจะต้องรีบลงมือทำเช่นกัน ดีกว่าที่จะปล่อยให้เกิดปัญหาเป็นเวลานาน ซึ่งจะส่งผลทางลบกับภาพลักษณ์ขององค์กร และความเชื่อถือในตัวแบรนด์อีกด้วย
สถานการณ์แบบนี้มักจะเกิดขึ้นในองค์กรที่มีการกระจายการทำงานมากแบบงานใครงานมัน (silo) งานแต่ละส่วนมีการแบ่งหน้าที่กันชัด และแยกให้หลายหน่วยงานทำ บางครั้งหลายองค์กร เช่น ใช้ outsource, consultant, vendor ทำงานให้ พอเวลาเกิดปัญหา ก็ไม่สามารถระดมสรรพกำลังมาเพื่อแก้ไขปัญหาได้อย่างรวดเร็ว แถมแต่ละหน่วยงานก็อาจจะปฏิเสธความรับผิดชอบว่าไม่ใช่ปัญหาของตัวเองอีกด้วย
การแก้ไขปัญหาที่ดี ต้องอาศัยความร่วมมือกันอย่างดี ทุกฝ่าย ทุกทีมต้องใขัจุดแข็ง และทักษะความสามารถของทีม เพื่อที่จะพยายามที่หาจุดต้นตอของปัญหา และพยายามเสนอแนวทางในการแก้ไขปัญหาที่แก้ได้เร็ว มีผลกระทบที่น้อยที่สุด
นอกจากนั้น ยังจะต้องสามารถมองในภาพลบได้ว่า วิธีการแก้ที่นำเสนอนั้น ๆ มีจุดอ่อนอย่างไร มีความเสี่ยงอะไรบ้าง เพื่อที่ทีมงานทั้งหมดสามารถที่จะตัดสินร่วมกันได้ว่าควรจะเลือกเดินทางนั้นหรือไม่
ตอนนี้ยาวแล้ว เดี๋ยวไว้คอยติดตามตอนต่อไปกันครับ
- 10
ดูเพิ่มเติมในซีรีส์
โฆษณา
- ดาวน์โหลดแอปพลิเคชัน
- © 2024 Blockdit
