Blockdit Logo (Mobile)
ณัฐมาคุย
ยืนยันแล้ว
•
7 ก.ย. 2022 เวลา 14:56 • ความคิดเห็น
การรองรับสถานการณ์แอปล่ม ตอนที่ 5: เอาตัวรอดในวันเกิดเหตุ
ผมได้มีโอกาสทำงานที่เกี่ยวข้องกับการรองรับสถานการณ์บนระบบ production มาตั้งแต่ปี 2000 และที่ได้เรียนรู้มากที่สุดคือ การทำงานในทีมของ AWS ของ Amazon.com (ไม่ใช่ร้านกาแฟ)
ซึ่งผมเป็นหนึ่งในคนที่ต้องรับมือกับปัญหา โดยรับกะ หนึ่งกะกินเวลา 1 อาทิตย์ ทุก ๆ 2-3 เดือน
เหตุการณ์​ (incidents) สามารถมีได้มากน้อยแตกต่างกันมาก เพราะขึ้นอยู่กับปริมาณการใช้งานของลูกค้า และปัญหาเกี่ยวกับฮาร์ดแวร์ต่าง ๆ ในช่วงแรกที่ผมเข้าไปทำงาน การรับกะ (on call) เป็นเรื่องที่ทุกคนขยะแขยงกันมาก ๆ ทุกคนจะต้องมีเพจเจอร์ (pager) ใช่ครับ เพจเจอร์ที่เราเคยใช้ส่งข้อความหวาน ๆ แสบไส้ให้สาว ๆ นั่นแหล่ะครับ เพราะมันแน่ใจได้ว่าส่งถึง จะปิดโทรศัพท์เป็น silent ยังไง มันก็ดัง
และเราก็จะต้องตอบรับว่าเราได้รับทราบปัญหาแล้วภายในระยะเวลา 5-15 นาที หากไม่รับ ระบบจะ escalate ขึ้นไปเรื่อย ๆ
ตามสายการบังคับบัญชา สมัยก่อนที่บริษัทยังเล็ก ๆ อยู่ ถ้าระบบ escalate ไปจนถึงคนใหญ่คนโต (ไม่ต้องถึงมือ Jeff Bezos) เรื่องเล็ก ๆ ก็จะกลายเป็นเรื่องใหญ่เลยทีเดียว
ช่วงที่ได้เรียนรู้วิธีการรองรับสถานการณ์ที่ดีที่สุด ก็คือช่วงนั้นของชีวิตผม ในเดือนแรก ๆ ที่ควงกะ เรียกได้ว่า เพจเจอร์แทบจะดังตลอดเวลา แต่ไม่ใช่สาว ๆ ส่งข้อความมาหา เป็นระบบที่ส่ง alert มาอยู่ตลอดเวลาว่าระบบมีปัญหา ให้เข้าไปดูหน่อย
ตอนพีคที่สุด คือ เจอปัญหาเข้าไปมากกว่า 400 ปัญหาใน 1 อาทิตย์ นี่ยังไม่รวมปัญหาซ้ำซากที่มันเตือนแล้วเดือนอีก เรียกได้ว่า แทบไม่ต้องหลับต้องนอนเลยทีเดียว คอมพิวเตอร์ก็เปิดมันไว้ตลอด แทบจะเอาไว้ข้างหมอนเลยทีเดียว
และผมได้เรียนรู้ประสบการณ์ในฐานะคนอยู่หน้างานดังนี้
1. อย่าคิดว่า error/latency เป็นเรื่องเล็กน้อย
Amazon.com ให้ความสำคัญกับประสบการณ์ของลูกค้าเป็นอย่างมาก ทีมงานจะแทบไม่สนใจดูว่าค่าเฉลี่ยว่าลูกค้าต้องรอให้ระบบตอบรับคำสั่งนาน (latency) แค่ไหน เราจะดูที่ 99.0, 99.9, 99.99 percentile ของลูกค้าว่าต้องรอนานแค่ไหน ส่วน error นั้น error เกิน 1% เราก็จะต้องถือว่าเป็นเรื่องที่ serious มาก ๆ แล้ว
หัวหน้าคนหนึ่งของผมให้ข้อคิดที่ดีมากว่า เวลาเราเห็น error เพียงแค่ 1% เราอาจจะรู้สึกเฉย ๆ แต่ 1% นั้น อาจจะเป็น 100% ของ error ของลูกค้าก็ได้ ลูกค้าเขาไม่สนใจหรอกว่า เราจะทำงานได้ดี 99% เขาจะให้ความสนใจและผิดหวังเวลาที่ 1% นั้นมัน fail นั่นแหล่ะ
ในเคสของแอปธนาคารเอง เลวร้ายยิ่งกว่านั้นอีก วันที่ที่ไหน ๆ ก็รับพร้อมเพย์ มันมาพร้อมกับความยากลำบากของคนทำงาน เพราะลูกค้าเลิกที่จะถือเงินสด หันมาพึ่งแอปแทบจะ 100% ตั้งแต่ชานมไข่มุก ยันค่าบ้าน ปัญหาเรื่องค่าบ้านมันยังไม่เลวร้ายเท่ากับสั่งชานมไข่มุกไปแล้ว แต่จ่ายตังไม่ได้ สั่งข้าว แต่จ่ายเงินไม่ได้ หากมัน fail ตอนที่กำลังจะจ่ายเงินพอดี แป๊บๆ ยังทำรายการใหม่ได้ แต่ถ้ามันหลายชั่วโมงล่ะ จะเอาน้ำ เอาข้าวที่ไหนกิน ดังนั้น วันนี้เป้าหมายของหลาย ๆ ธนาคาร ก็คือ มันต้องไม่ล่มเลย
2. รู้ว่าเมื่อไหร่ควรจะยกระดับเหตุการณ์
คนที่อยู่หน้างานมีหน้าที่ที่จะต้องประเมินสถานการณ์อยู่เสมอ เมื่อไหร่ที่เหตุการณ์เกินกว่าที่ตัวเองจะแก้ได้แล้ว ต้องรีบแจ้งหัวหน้า และเตรียมติดต่อผู้เกี่ยวข้อง ทุกวินาทีมีค่า
และอีกอย่างที่ต้องรู้ และทำ ก็คือ ต้องรู้ว่าเมื่อไหร่ควรจะประกาศสถานการณ์ฉุกเฉิน และปฏิบัติตามสถานการณ์ฉุกเฉิน ก็คือ ทำทุกสิ่งทุกอย่าง รวมไปถึงการพร้อมที่ฝ่ากฎทั้งหลายที่มีอยู่ เพื่อนำระบบให้เข้าสู่ภาวะปกติให้เร็วที่สุด
หากลูกค้าใช้งานไม่ได้ จนต้องทำอะไรที่ในภาวะปกติไม่ทำกัน เช่น เอาระบบลง แก้โน่นแก้นี่ แม้ว่าสิ่งนั้นจะเป็นการทดลอง พิสูจน์สมมติฐาน หรือเพื่อเก็บข้อมูล ก็ต้องทำ และต้องรีบด้วย
แต่ก็ไม่ใช่ประกาศสถานการณ์ฉุกเฉินกันเป็นปี ๆ พองานเสร็จก็ต้องกลับไปทำงานตามระเบียบปฏิบัติเช่นเดิม
3. เรียกคนทั้งแผ่นดิน
ในกรณีที่สถานการณ์เลวร้าย คนที่ได้รับการมอบหมายให้เป็น incident manager จะต้องพร้อมเรียกคนที่เกี่ยวข้องเข้ามาให้มากที่สุด แต่คนเหล่านั้นไม่ได้จำเป็นต้อง "พูด" incident manager มีหน้าที่ที่จะต้อง recap ให้ทุกคนฟังว่า สถานการณ์ตอนนี้เป็นอย่างไร และใครมีหน้าที่ต้องทำอะไร
หลังจากถูกมอบหมาย ต่างคนก็ต่างไปปฏิบัติหน้าที่แก้ไขสถานการณ์ให้รวดเร็วที่สุด แต่หากยังไม่รู้ว่าสาเหตุคืออะไร แต่ละคนก็จะต้องไปทำหน้าที่สืบสวน เก็บข้อมูล และตั้งข้อสันนิษฐานว่าเกิดอะไรขึ้น เฉกเช่นเดียวกับนักสืบ และตำรวจ
แต่สิ่งหนึ่งที่ห้ามลืม คือ เราต้องทำหน้าที่ตำรวจ และพยาบาลไปพร้อมกัน ถึงแม้เราจะต้องการแก้ไขปัญหาให้เร็วที่สุด เรามีหน้าที่ต้องเก็บหลักฐานให้ได้มากที่สุดอีกด้วย ถ้ามุ่งแต่แก้ไขปัญหา แล้วการแก้ไขปัญหาจะทำให้หลักฐานหายไปด้วย เราต้องทำการเก็บข้อมูลก่อนที่จะดำเนินการแก้ไขปัญหาโดยเฉพาะเวลาที่เรายังไม่รู้แน่ชัดว่าเกิดอะไรขึ้น
เพราะไม่เหมือนคดีฆาตกรรมที่คนตายแล้วตายเลย ปัญหาด้านไอทีเกิดแล้วเกิดอีกได้บ่อย ๆ หากยังไม่ทราบที่มาของปัญหา แล้วแก้แบบขอไปที และไม่ได้ไปแก้ที่ต้นตอ ปัญหาก็อาจจะเกิดขึ้นได้อีกเรื่อย ๆ
หากใครที่ทราบปัญหาแล้ว ก็ต้องกลับมารายงานให้กับ incident manager ทราบ และตัดสินใจร่วมกันว่า จะต้องทำอะไรต่อไป โดยเฉพาะถ้าการแก้ไขที่ส่งผลกระทบในทางลบ แต่ถ้าเป็นการแก้ไขที่ทำให้สถานการณ์ดีขึ้นแน่ ๆ เช่น เครื่องตาย ก็สตาร์ทขึ้นมาใหม่ ก็อาจจะทำได้เลย เพื่อไม่ได้เป็นการเสียเวลา
แต่ถ้าทีมงานที่มีอยู่ ไม่รู้ในเรื่องหนึ่งเรื่องใดที่เป็นข้อสงสัยกันอยู่ incident manager ก็ต้องพร้อมที่จะเรียกคนที่ "น่าจะรู้" ในเรื่องนั้น ๆ เข้ามาเพิ่มเติมเพื่อตอบข้อสงสัยให้ได้เร็วที่สุด
4. กล้าตัดสินใจ
incident manager หรือคนที่ได้รับการมอบหมายจาก incident manager มีหน้าที่ในการตัดสินใจ เวลาเกิดเหตุการณ์ เราจะพะวงหน้าพะวงหลังว่า ทำไอ้นั่น เดี๋ยวจะกระทบไอ้นี่ ทำไอ้นี่ เดี๋ยวจะไปกระทบตรงโน้น incident manager ต้องพยายามเก็บข้อมูลจากคนที่เกี่ยวข้องให้ได้มากที่สุด และตัดสินใจจากข้อมูลที่มีว่าจะต้องดำเนินการอะไรบ้างอย่างไร
หลาย ๆ ครั้ง การตัดสินใจจะมีถูกบ้าง ผิดบ้าง เดาบ้าง มั่วบ้าง แต่ระบบมันแย่ถึงขึ้นคอขาดบาดตาย การเลือกที่จะทำอะไร ดีกว่าการอยู่เฉย ๆ เสียอีก อย่างน้อยก็เหมือนกับที่ Thomas Edison ที่ว่า การล้มเหลวจริง ๆ คือ การที่เราได้เรียนรู้หนึ่งสิ่งที่มันไม่ work นั่นเอง เพราะพอเลือกทำอะไร เราก็จะได้ข้อมูลเพิ่มขึ้นเสมอว่า การกระทำนั้น ๆ ส่งผลกับระบบอย่างไรบ้าง ดีขึ้น หรือแย่ลง ขอเพียงให้การตัดสินใจนั้น ๆ ควรจะถอยกลับได้ง่าย ๆ หากมันทำให้เรื่องแย่ลง หรือไม่ช่วย
5. กล้าสื่อสารกับลูกค้า
เมื่อไรก็ตามที่เหตุการณ์คอขาดบาดตายเกิดขึ้น และเรายังไม่รู้ว่าสถานการณ์จะคลี่คลายเมื่อไร การบอกลูกค้า และยอมรับว่ามีปัญหาอยู่ หลาย ๆ ครั้งเป็นเรื่องที่ควรทำ และควรทำให้เร็วที่สุด เพื่อลูกค้าจะได้วางแผนกับชีวิตตัวเองด้วยเช่นกัน
การเงียบ ๆ หรือการปฏิเสธว่าไม่มีปัญหา มักจะส่งผลร้ายเสียมากกว่า ควรจะรีบขอโทษ​ และให้คำมั่นสัญญาว่า เรากำลังดูปัญหานี้อยู่ และจะคอยอัพเดทสถานการณ์อยู่เรื่อย ๆ
อย่างของ AWS และผู้ให้บริการอื่น ๆ ก็มักจะทำหน้า status dashboard ให้ลูกค้าเห็นกันจะจะไปเลย ถ้ามีปัญหาก็จะมาแจ้งตรงนี้ แถมยังมีข้อมูลย้อนหลังอีกด้วย จะได้มีความโปร่งใส และกระตุ้นให้ทั้งทีมทำระบบให้ดี และมีเสถียรภาพ
6. อย่าแค่ดับไฟ ทำไงไม่ให้ไฟไหม้
อีกหนึ่งในสิ่งที่สำคัญที่สุดในขั้นตอนการแก้ไขปัญหา คือ การเข้าใจต้นตอของปัญหา และใช้เวลาแก้ไขไม่ให้เหตุการณ์นั้นเกิดขึ้นอีก ระบบที่ดีคือระบบที่ปัญหาถูกแก้ไขและไม่เกิดขึ้นอีก นั่นรวมไปถึงการวางแผนความสามารถของระบบให้รองรับการใช้งานในอนาคต ไม่ใช่แค่ขับรถไปเรื่อย ๆ จนน้ำมันหมด ค่อยมาคิดกัน
จริง ๆ เรื่องนี้ยังมีรายละเอียดอีกมาก แต่ขอจบแค่นี้ก่อนล่ะกันนะครับ ถ้าวันหลังมีโอกาส ไว้จะหยิบยกมาเล่าเพิ่มเติมครับ
ท้ายสุดนี้ คงต้องขอให้กำลังใจกับทีมงานทุกคน ที่เขียนนี้เพียงอยากจะเล่าให้ผู้ใช้ทุกคนได้มองเห็นภาพจากมุมมองของทีมงานบ้างครับ
เครดิตภาพจาก :
สามารถติดตามตอนอื่นๆ ได้จากซีรีย์ "การรองรับสถานการณ์แอปล่ม" ด้านล่างนี้ครับ

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

โฆษณา