6 เรื่องเล่าความขัดข้องสุดสยอง
(thenewstack.io)1. Charity Majors, CTO of Honeycomb
-
ผู้ใช้ในบางภูมิภาค (ยุโรปตะวันออก) ไม่ได้รับ push noti
-
เริ่มเกิดขึ้นทันทีหลังจากเปลี่ยนขนาด ASG
-
เกิดจาก Round Robin DNS record มีขนาดเกิน UDP packet size
2. Matthew Fornaciari, CTO of Gremlin
-
ดิสก์เต็มจนไม่สามารถเขียนล็อกได้ ทำให้เกิดเหตุขัดข้อง
-
พัฒนาฟังก์ชัน log rotating
-
ตั้งค่า alert การใช้งานดิสก์
-
เพิ่มให้สามารถทดสอบผ่าน Gremlin ได้ (chaos engineering)
3. Lirran Haimovitch, CTO of Rookout
"ตำนานเมืองที่ว่าเซิร์ฟเวอร์ล่มทุกวันในเวลาหนึ่ง
หลังจากสืบสวนอยู่นานหลายสัปดาห์ ก็พบสาเหตุจากกล้องวงจรปิด
ภารโรงถอดปลั๊กการเชื่อมต่อเซิร์ฟเวอร์เพื่อเสียบเครื่องดูดฝุ่น"
4. Daniel "Spoons" Spoonhower, CTO of Lightstep
-
แอปโหลดไม่ขึ้น
-
วันนั้นไม่มีการ deploy หรือเปลี่ยนแปลง infrastructure
-
ตรวจสอบแล้วพบว่าใช้ไม่ได้เฉพาะผู้ใช้ภายใน
-
ระหว่างตรวจสอบ API สำหรับโหลดแอป พบว่าสำหรับผู้ใช้ภายในมีส่วนที่ส่งคืนข้อมูลเพิ่มเติม
-
ตลอดหลายสัปดาห์ก่อนหน้า payload ค่อย ๆ เพิ่มขึ้น และบ่ายวันนั้นก็เกินขนาด payload สูงสุด ทำให้แอปโหลดไม่สำเร็จ
5. Lee liu, CTO of LogDNA
6. Ting Huang, CTO of Transpoit
-
อ่านไม่ได้บน Twitter mobile
-
พบปัญหาว่าไลบรารีใหม่ไม่สามารถ parse session cookie ได้
6 ความคิดเห็น
กรณีที่ 5 ซึ่งไม่ได้มีการสรุปเนื้อหา ดูเหมือนจะเกี่ยวกับการหมดอายุของใบรับรอง
เดิมคิดว่าแม้ใบรับรองจะหมดอายุตามกำหนดก็ไม่น่ามีปัญหา แต่เรื่องนั้นใช้ได้เฉพาะกับระบบที่พัฒนาขึ้นใหม่เท่านั้น ส่วนในระบบเลกาซีที่ยังใช้งานอยู่กลับเกิดปัญหาขึ้น และบังเอิญว่าในโซลูชัน CI/CD ที่ใช้อยู่ก็เกิดปัญหาเดียวกันด้วย เลยทำให้เรื่องยิ่งซับซ้อนเข้าไปอีก
"ภารกิจความขัดข้องสุดสยอง 6 เรื่อง"
"เจ้าหน้าที่ทำความสะอาดถอดสายเซิร์ฟเวอร์เพื่อเสียบปลั๊กเครื่องดูดฝุ่น"
โอ้โห...
พอไปอ่านต้นฉบับแล้ว เนื้อหาส่วนนั้นก็เป็นแค่การเกริ่นนำเท่านั้น และปัญหาขัดข้องที่เกิดขึ้นจริงก็คือ ทุกครั้งที่ผู้ดูแลฝั่งลูกค้าไปรันคิวรีที่ใช้ตอนประชุมหรือใช้เป็นครั้งคราว คิวรีนั้นจะล็อกทั้งตาราง ทำให้ latency ของบริการแบ็กเอนด์เพิ่มขึ้นได้แบบไร้ขีดจำกัดในทุกครั้ง ตอนแรกก็ลองปรับแต่งคิวรีที่น่าสงสัย แต่ก็เป็นการจับผิดจุด สุดท้ายพอฝั่งลูกค้ารู้สึกว่าหน้าเว็บช้าเกินไปแล้วกดรีเฟรชซ้ำ ๆ ปรากฏการณ์เดิมก็ยิ่งเกิดซ้ำต่อเนื่อง
มีประสบการณ์ส่วนตัวคล้าย ๆ กันอยู่เรื่องหนึ่ง ตอนที่รับงานเกี่ยวกับร้านค้าออนไลน์แบบเร่งด่วนในฐานะฟรีแลนซ์
ช่วงเช้ามืดได้ทำงานใหญ่กับร้านค้าออนไลน์นั้นอยู่ครั้งหนึ่ง (อัปเกรดเวอร์ชันของโซลูชันครั้งใหญ่) และหลังจากตรวจสอบแล้วว่าฟังก์ชันหลักอย่างการชำระเงินสินค้าไม่มีปัญหา ก็เปิดให้บริการอีกครั้ง แต่พอเข้าช่วงบ่าย จู่ ๆ เว็บไซต์ร้านค้าออนไลน์ก็ช้าลงมาก จนแทบจะหยุดนิ่งไปเลยทีเดียว พอตรวจดูจึงพบว่าสาเหตุมาจากหน้าสำหรับผู้ขายที่เชื่อมแยกไว้ต่างหากกับร้านค้าออนไลน์ เดิมทีมีการพัฒนาแบบคัสตอมและนำหน้าจัดการสำหรับผู้ขายมาต่อเข้ากับโซลูชันร้านค้าออนไลน์เพื่อใช้งานอยู่ และทันทีที่เข้าไปหน้านั้นก็มีการรันคิวรีที่หนักมาก หลังจากร้านค้าออนไลน์กลับมาเปิดให้บริการอีกครั้ง ทุกครั้งที่ผู้ขายแต่ละรายเข้ามาดูสถานะการขาย ภาระบน MySQL ก็เพิ่มขึ้น จนสุดท้ายทำให้ตัวร้านค้าออนไลน์เองช้าลง พอดูแล้วก็พบว่าในตารางที่เกี่ยวข้องนั้น ไม่ทราบด้วยเหตุผลใด อินเด็กซ์ถูกตั้งไว้ไม่ถูกต้อง สุดท้ายก็สามารถแก้ปัญหาที่ร้านค้าออนไลน์ช้าลงได้ด้วยการตั้งอินเด็กซ์ให้ถูกต้องและปรับแต่งพารามิเตอร์บางส่วน
โอ ขอบคุณที่แชร์ประสบการณ์ครับ
ก็จริงแหละครับ ข้อมูลสำหรับใช้ตัดสินใจฝั่งแอดมินหรือเชิงธุรกิจพอใช้ aggregation แล้วก็น่าจะมีภาระโหลดสูงพอสมควร ผมไม่ใช่นักพัฒนาเว็บเลยอาจจะไม่ค่อยรู้ละเอียดนัก แต่ช่วงนี้ดูเหมือนเขาจะเรียกกันว่า data engineering แล้วก็แยกไปรวบรวมข้อมูลไว้อีกชุดครับ
อย่างที่คุณบอก การแยกข้อมูลแบบนั้นออกไปประมวลผลต่างหากคงเป็นแนวทางที่ถูกต้องตามหลัก แต่เว็บช็อปปิงที่ผมเคยทำงานด้วยเป็นระบบเลกาซีที่มีหลายจุดไม่สมเหตุสมผล จึงไม่ได้คำนึงถึงสถาปัตยกรรมในลักษณะนั้นเลย MySQL เวอร์ชันเก่ามาก (เป็นยุคที่เอนจินเริ่มต้นยังเป็น MyISAM ไม่ใช่ InnoDB) รันอยู่ภายใน VM instance เดียวกันกับ Apache web server เวอร์ชันเก่ามากเช่นกัน ส่วนโซลูชันสำหรับใช้บริหารเว็บช็อปปิงเองก็ถูกจัดเป็นเลกาซีไปแล้ว และอยู่ในสถานะที่มีแค่ออกแพตช์มาให้เท่านั้น ปัญหาเชิงโครงสร้างของโซลูชันที่ผมรู้สึกได้ระหว่างทำงาน ดูเหมือนว่าจะถูกแก้ไขไปแล้วในเวอร์ชันใหม่ที่พัฒนาขึ้นมาใหม่ตั้งแต่ต้น แต่สำหรับผมที่ต้องไปแตะเวอร์ชันเลกาซี เรื่องนั้นก็ไม่ได้ช่วยอะไรได้เลย นั่นก็เป็นเรื่องเมื่อปีที่แล้วเองนะครับ