การหยุดให้บริการครั้งใหญ่ของ Cloudflare เมื่อวันที่ 18 พฤศจิกายน - สรุป

เมื่อวันที่ 18 พฤศจิกายน 2568, ส่วนใหญ่ของอินเทอร์เน็ตล่ม.
หากคุณเปิด ChatGPT, X (Twitter), League of Legends, Shopify, Coinbase หรือเว็บไซต์ขนาดเล็กนับไม่ถ้วน คุณจะพบกับหน้าข้อผิดพลาด 5xx ที่มีแบรนด์ของ Cloudflare หรือไม่ก็เว็บไซต์เหล่านั้นไม่โหลดเลยสิ่งที่ดูเหมือนในตอนแรกเป็นเพียงอีกหนึ่งช่วงเวลาใหญ่ที่ "อินเทอร์เน็ตพัง" กลายเป็นบางสิ่งที่ละเอียดอ่อนกว่าและในบางแง่มุมก็น่ากังวลยิ่งกว่า: ข้อบกพร่องที่เกิดจากตัวเองซึ่งฝังลึกอยู่ในโครงสร้างพื้นฐานของ Cloudflare เอง

ด้านล่างนี้คือรายละเอียดขั้นตอนโดยละเอียดของเหตุการณ์การหยุดให้บริการของ Cloudflare เมื่อวานนี้ (18 พฤศจิกายน 2025) สาเหตุที่เกิดขึ้น ผลกระทบที่ได้รับ และบทเรียนที่ทีมโครงสร้างพื้นฐานควรนำไปปรับใช้

เมื่อวานนี้เกิดอะไรขึ้นจริง ๆ?

ในวันอังคารที่ 18 พฤศจิกายน 2568 เวลาประมาณช่วงสายตามเวลามาตรฐานสากล (UTC) Cloudflare ได้เริ่มส่งคืนข้อผิดพลาด HTTP 5xxในปริมาณมากสำหรับทราฟฟิกที่ผ่านเครือข่ายของตน สำหรับผู้ใช้ปลายทาง นั่นหมายถึงการแสดงหน้า "ข้อผิดพลาดของเซิร์ฟเวอร์ภายใน" หรือ "ข้อผิดพลาดของเกตเวย์" เมื่อพยายามเข้าถึงเว็บไซต์และแอปพลิเคชันยอดนิยมหลายแห่ง

ตามบล็อกหลังเหตุการณ์ของ Cloudflare เอง การหยุดให้บริการ:

• เริ่มส่งผลกระทบต่อการรับส่งข้อมูล HTTP ของลูกค้าเมื่อเวลา11:28 UTC

• พบข้อผิดพลาด 5xx อย่างกว้างขวางในบริการ CDN และความปลอดภัยหลัก

• มีขั้นตอนการบรรเทาผลกระทบที่สำคัญประมาณ13:05–14:30 UTC

• ปริมาณข้อผิดพลาด 5xx กลับมาสู่ระดับพื้นฐานแล้วเมื่อเวลา17:06 UTC บล็อกของ Cloudflare

Cloudflare ได้อธิบายเหตุการณ์นี้ว่าเป็นเหตุการณ์ขัดข้องที่รุนแรงที่สุดนับตั้งแต่ปี 2019 เนื่องจากไม่ได้ส่งผลกระทบเพียงแค่ฟีเจอร์หรือแดชบอร์ดเดียวเท่านั้น แต่ได้รบกวนชั้นพร็อกซีหลักที่เป็นเส้นทางหลักในการส่งผ่านทราฟฟิกของลูกค้าส่วนใหญ่ผ่านเครือข่ายของตนบล็อกของ Cloudflare

การตรวจสอบจากบุคคลที่สามได้สนับสนุนข้อมูลนี้ Cisco ThousandEyesพบการหยุดให้บริการทั่วโลกที่ส่งผลกระทบต่อ Cloudflare โดยมีปัญหาการหมดเวลาและข้อผิดพลาด 5xx บนบริการต่างๆ เช่น X, OpenAI (ChatGPT) และ Anthropic ในขณะที่เส้นทางเครือข่ายเองดูมีสุขภาพดี สิ่งนี้ชี้ให้เห็นอย่างชัดเจนว่าเป็นการล้มเหลวของบริการแบ็กเอนด์ ไม่ใช่ปัญหาในระดับ ISP หรือปัญหาการกำหนดเส้นทางThousandEyes

ใครได้รับผลกระทบ?

เนื่องจาก Cloudflare อยู่ด้านหน้าของส่วนที่ใหญ่มากของอินเทอร์เน็ต (ประมาณ20% ของเว็บไซต์ทั้งหมดพึ่งพา Cloudflare สำหรับประสิทธิภาพและความปลอดภัย) รัศมีการระเบิดจึงมีขนาดใหญ่มากAP News+1

บริการที่รายงานว่าได้รับผลกระทบ ได้แก่:

• แชทจีพีที / โอเพ่นเอไอ

• X (เดิมชื่อ Twitter)

• Canva, Shopify, Dropbox, Coinbase

• ลีกออฟเลเจนด์และแพลตฟอร์มเกมอื่น ๆ

• เว็บไซต์ขนส่งสาธารณะและหน่วยงานรัฐบาลต่าง ๆ รวมถึงระบบดิจิทัลของรถไฟ New Jersey Transit และ SNCF ของฝรั่งเศสAP News+1

ตัวติดตามการหยุดทำงาน เช่น Downdetectorบันทึกการรายงานปัญหาที่เกิดขึ้นพร้อมกันหลายพันรายการในช่วงสูงสุด สำนักข่าวรอยเตอร์รายงานว่ามีผู้ใช้ที่ได้รับผลกระทบประมาณ 5,000 รายสำหรับ X เพียงอย่างเดียวในช่วงหนึ่ง ก่อนที่จำนวนจะลดลงเมื่อมีการแก้ไขปัญหาสำนักข่าวรอยเตอร์

จากมุมมองของผู้ใช้ สิ่งนี้ปรากฏเป็น:

• เว็บไซต์ไม่โหลดเลย

• การเข้าสู่ระบบค้างหรือล้มเหลว (โดยเฉพาะในกรณีที่มีการใช้งาน Cloudflare Access หรือ Turnstile)

• API ตอบสนองเป็นระยะหรือแสดงข้อผิดพลาด 5xx

• แดชบอร์ดและแผงควบคุมของผู้ดูแลระบบหมดเวลา

กล่าวอีกนัยหนึ่ง: ส่วนสำคัญของอินเทอร์เน็ต "รู้สึกเหมือนล่ม" แม้ว่าสาเหตุที่แท้จริงจะกระจุกตัวอยู่ในระบบภายในของผู้ให้บริการรายเดียว

การทำงานของ Cloudflare โดยทั่วไป (ในรูปแบบที่เข้าใจง่าย)

เพื่อทำความเข้าใจว่าทำไมการหยุดให้บริการครั้งนี้จึงรุนแรงมาก การทราบเส้นทางคร่าว ๆ ของคำขอที่ผ่านเครือข่ายของ Cloudflare จะช่วยได้

Cloudflare ทำหน้าที่เป็นCDN แบบพร็อกซีย้อนกลับและชั้นความปลอดภัย:

1. เบราว์เซอร์หรือแอปของคุณเชื่อมต่อกับ Cloudflare แทนที่จะเชื่อมต่อโดยตรงกับเว็บไซต์ต้นทาง

2. Cloudflare ทำการยุติการเชื่อมต่อ TLS และ HTTP ที่ขอบเครือข่ายของตน

3. คำขอจะไหลเข้าสู่ระบบพร็อกซีหลักของ Cloudflare ที่เรียกว่าFL ("Frontline")และFL2 ซึ่งเป็นรุ่นใหม่กว่า

4. พร็อกซีหลักนั้น:

   • ใช้กฎWAF (เว็บแอปพลิเคชันไฟร์วอลล์)

   • รันโมเดลการจัดการบอท

   • จัดการการป้องกัน DDoS, การแคช, การส่งข้อมูลออกสู่ต้นทาง

   • ส่งทราฟฟิกไปยังผลิตภัณฑ์ภายในอื่น ๆ เช่นWorkers,R2,Access, เป็นต้นบล็อกของ Cloudflare

ในการทำงานปกติ สถาปัตยกรรมนี้มีความทนทานสูง: หากศูนย์ข้อมูลแห่งหนึ่งมีปัญหา การจราจรจะถูกเปลี่ยนเส้นทางไปยังศูนย์ข้อมูลอื่น ๆ; การเปลี่ยนแปลงการตั้งค่าจะถูกดำเนินการอย่างระมัดระวัง; คุณลักษณะแต่ละอย่างควรล้มเหลวในลักษณะที่จำกัดอยู่เฉพาะส่วน

การหยุดทำงานเมื่อวานนี้แย่มากเพราะความล้มเหลวเกิดขึ้นภายในเส้นทางพร็อกซีที่ใช้ร่วมกันเอง และมันเชื่อมโยงอย่างแน่นแฟ้นกับไฟล์การตั้งค่าที่ถูกส่งไปทั่วโลกบ่อยครั้งและโดยอัตโนมัติ

สาเหตุหลัก: ไฟล์ฟีเจอร์การจัดการบอทที่ทำงานผิดปกติ

คำอธิบายอย่างเป็นทางการของ Cloudflare ชี้ให้เห็นถึงสาเหตุสำคัญเพียงหนึ่งประการ:
ไฟล์กำหนดค่าคุณสมบัติที่ใช้โดยระบบจัดการบอทของพวกเขา บล็อกของ Cloudflare

นี่คือลำดับเหตุการณ์ในรูปแบบภาษาที่เข้าใจง่าย:

1. การจัดการบอทใช้ "ไฟล์ฟีเจอร์"

   • โมเดลการตรวจจับบอทของ Cloudflare อาศัยชุดของ "คุณสมบัติ" ซึ่งเป็นสัญญาณเกี่ยวกับแต่ละคำขอที่ใช้ในการตัดสินใจว่าคำขอนั้นมาจากมนุษย์หรือบอท

   • คุณสมบัติเหล่านี้ถูกรวมไว้ในไฟล์การกำหนดค่าซึ่งจะถูกสร้างขึ้นใหม่ทุก ๆ ไม่กี่นาทีและเผยแพร่ทั่วโลก เพื่อให้ Cloudflare สามารถปรับตัวได้อย่างรวดเร็วต่อรูปแบบการโจมตีใหม่ ๆบล็อกของ Cloudflare

2. การเปลี่ยนแปลงพฤติกรรมของคำสั่งค้นหาใน ClickHouse

   • ไฟล์คุณสมบัติถูกสร้างขึ้นโดยการค้นหาข้อมูลจากฐานข้อมูล ClickHouse

   • Cloudflare ได้ทำการเปลี่ยนแปลงเมื่อเวลาประมาณ11:05 UTCเพื่อปรับปรุงความปลอดภัยและสิทธิ์การเข้าถึงสำหรับการสืบค้นแบบกระจาย – อนุญาตให้ผู้ใช้สามารถดูเมตาดาต้าได้ไม่เพียงแค่จากสคีมาเริ่มต้นเท่านั้น แต่ยังรวมถึงจากตารางr0ที่อยู่เบื้องหลังด้วยบล็อกของ Cloudflare

   • คำสั่งค้นหาที่สร้างรายการคุณลักษณะไม่ได้กรองตามชื่อฐานข้อมูล; ทันใดนั้นก็เริ่มได้รับคอลัมน์ซ้ำจากทั้งค่าเริ่มต้นและ r0 ซึ่งทำให้จำนวนแถวคุณลักษณะเพิ่มขึ้นเป็นสองเท่า

3. ไฟล์ฟีเจอร์ขยายขนาดจนใหญ่มาก

   • โมดูลการจัดการบอทมีขีดจำกัดที่แน่นอนเกี่ยวกับจำนวนฟีเจอร์ที่สามารถรองรับได้ (ตั้งค่าไว้ที่ 200 ซึ่งสูงกว่าปกติที่ใช้ประมาณ 60 มาก)

   • เมื่อไฟล์ที่สร้างใหม่เกินขีดจำกัด โมดูลจะถึงขีดจำกัดและเกิดอาการตื่นตระหนก เนื่องจากข้อผิดพลาดที่ไม่ได้จัดการในโค้ด Rust ที่ใช้Result::unwrap()กับค่าที่เป็นข้อผิดพลาดบล็อกของ Cloudflare

4. บริการพร็อกซีหลักเริ่มส่งคืนข้อผิดพลาด 5xx

   • เนื่องจากการจัดการบอทถูกผสานรวมเข้ากับเส้นทางพร็อกซีหลัก ความตื่นตระหนกจึงปรากฏขึ้นในรูปแบบของการตอบกลับ HTTP 5xxสำหรับทราฟฟิกทั้งหมดที่พึ่งพาโมดูลนั้น

   • บนเครื่องยนต์FL2รุ่นใหม่ ลูกค้าพบข้อผิดพลาด 5xx อย่างชัดเจน

   • ในเครื่องยนต์FLรุ่นเก่า คะแนนของบอทจะลดลงเป็นศูนย์โดยไม่มีเสียงแจ้งเตือน ซึ่งอาจทำให้เกิดการบล็อกบอทผิดพลาดในกฎการบล็อกบอทได้บล็อกของ Cloudflare

5. ส่วนที่แย่จริงๆ คือ: ไฟล์สลับไปมาระหว่าง "ดี" และ "ไม่ดี" อยู่ตลอดเวลา

   • คลัสเตอร์ ClickHouseกำลังถูกอัปเดตอย่างค่อยเป็นค่อยไป และไฟล์ฟีเจอร์ถูกสร้างขึ้นใหม่ทุกห้านาที

   • บางครั้งการค้นหาทำงานบนโหนดที่ได้รับการอัปเดต (ทำให้เกิดไฟล์ที่ไม่ดี) บางครั้งทำงานบนโหนดที่ไม่ได้อัปเดต (ทำให้เกิดไฟล์ที่ดี)

   • นั่นหมายความว่าในช่วงเวลาหนึ่ง เครือข่ายของ Cloudflare สลับไปมาระหว่างการทำงานปกติและความล้มเหลว เนื่องจากไฟล์เวอร์ชันต่างๆ ถูกเผยแพร่ไปทั่วเครือข่ายของ Cloudflare บล็อก

การสั่นไหวนี้ทำให้สถานการณ์ภายในเกิดความสับสนอย่างมาก ในตอนแรก ทีมของ Cloudflare สงสัยว่าอาจเกิดการโจมตี DDoS ขนาดใหญ่เนื่องจากรูปแบบข้อผิดพลาดไม่เหมือนกับการขัดข้องของซอฟต์แวร์ทั่วไปแม้แต่หน้าสถานะของ Cloudflare ซึ่งโฮสต์อยู่นอกโครงสร้างพื้นฐานของตนเอง ยังแสดงข้อผิดพลาดชั่วคราว—ซึ่งเป็นการบังเอิญที่ยิ่งเพิ่มความสงสัยเกี่ยวกับการโจมตีจากภายนอกCloudflare Blog+1

เมื่อพวกเขาตระหนักว่าปัจจัยร่วมคือไฟล์คุณสมบัติของบอทเท่านั้น ภาพจึงชัดเจนขึ้น

ลำดับเหตุการณ์ของเหตุการณ์

จากรายงานการวิเคราะห์หลังเหตุการณ์ของ Cloudflare และรายงานจากบุคคลที่สาม เราสามารถรวบรวมลำดับเหตุการณ์คร่าวๆ สำหรับวันที่ 18 พฤศจิกายน 2025 ได้ดังนี้: บล็อกของCloudflare+ 2ThousandEyes + 2

• 11:05 UTC– มีการเปลี่ยนแปลงการควบคุมการเข้าถึงฐานข้อมูลใน ClickHouse

• 11:20–11:30 UTC– ไฟล์ฟีเจอร์การจัดการบ็อตเวอร์ชันที่ไม่ดีเริ่มถูกสร้างและแพร่กระจาย

• 11:28 UTC– ผลกระทบต่อลูกค้าครั้งแรก: พบข้อผิดพลาด HTTP 5xx เพิ่มขึ้นในทราฟฟิกของลูกค้า

• 11:30–11:32 UTC– เครื่องมือตรวจสอบภายนอกและการทดสอบอัตโนมัติเริ่มตรวจพบความล้มเหลวเป็นระยะ

• 11:35 UTC– Cloudflare เปิดการเรียกประชุมเหตุการณ์ภายใน; การสืบสวนเริ่มต้นขึ้น

• ~11:48 UTC– Cloudflare เผยแพร่การอัปเดตสถานะยืนยันเหตุการณ์ที่เกิดขึ้นส่งใหม่

• 11:30–13:05 UTC– ทีมมุ่งเน้นไปที่พฤติกรรมของ Workers KV ที่ดูเหมือนจะเสื่อมลง และทำการตรวจสอบสาเหตุที่เป็นไปได้หลายประการ (รวมถึงสถานการณ์การโจมตี)

• 13:05 UTC– มาตรการบรรเทาผลกระทบหลัก: ได้ย้ายผู้ใช้ KV และ Cloudflare Access ไปยังเส้นทางที่ไม่ต้องผ่านพร็อกซีหลัก ส่งผลให้ผลกระทบลดลงบล็อกของ Cloudflare

• 14:30 UTC– ระบุสาเหตุที่แท้จริงได้; การสร้างและการแพร่กระจายของไฟล์ฟีเจอร์ที่ไม่ดีถูกหยุดลง ไฟล์การกำหนดค่าที่ทราบว่าเป็นปกติถูกแทรกด้วยตนเองและพร็อกซีหลักถูกเริ่มต้นใหม่ การจราจรหลักส่วนใหญ่กลับสู่ภาวะปกติบล็อกของ Cloudflare

• 14:40–15:30 UTC– ปัญหาเกี่ยวกับแดชบอร์ดและการเข้าสู่ระบบยังคงมีอยู่ เนื่องจาก Turnstile และคิวการพยายามยืนยันตัวตนที่ค้างอยู่ทำให้เกิดการเพิ่มขึ้นของโหลดรองบล็อกของ Cloudflare

• 17:06 UTC– อัตราความผิดพลาดกลับสู่ระดับปกติ; Cloudflare ประกาศว่าระบบทั้งหมดกลับมาเป็นปกติอย่างสมบูรณ์บล็อกของ Cloudflare

จากมุมมองของผู้ใช้ การหยุดให้บริการรู้สึกแย่ที่สุดในช่วงสายถึงบ่ายต้นตามเวลา UTC แม้ว่าช่วงเวลาที่ผลกระทบเกิดขึ้นจริงจะแตกต่างกันไปตามภูมิภาคและผลิตภัณฑ์ของ Cloudflare ที่แต่ละบริการพึ่งพาอยู่

เหตุใดการหยุดให้บริการครั้งนี้จึงมีความสำคัญอย่างยิ่ง

ความเสี่ยงจากการรวมศูนย์

Cloudflare เป็นส่วนหนึ่งของกลุ่มผู้ให้บริการโครงสร้างพื้นฐานอินเทอร์เน็ตหลักที่มีขนาดเล็ก ร่วมกับแพลตฟอร์มคลาวด์รายใหญ่ (AWS, Azure, GCP) และ CDN ขนาดใหญ่อื่น ๆ เมื่อผู้ให้บริการรายใดรายหนึ่งในกลุ่มนี้ล้มเหลว ผลกระทบจะกว้างขวางและมักไม่ชัดเจน

การหยุดให้บริการครั้งนี้:

• ไม่ได้เกิดจากความผิดพลาดในการกำหนดเส้นทาง BGP หรือการตัดสายเคเบิลของผู้ให้บริการอินเทอร์เน็ต

• ไม่ได้มาจากการโจมตีที่มีเจตนาร้าย (แม้จะมีความสงสัยในตอนแรก)

• มาจากค่ากำหนดเดียวและข้อบกพร่องในการจำกัดในคอมโพเนนต์ภายใน

นั่นสำคัญเพราะมันแสดงให้เห็นว่าระบบที่ซับซ้อนและเชื่อมโยงกันอย่างแน่นหนาสามารถล้มเหลวอย่างรุนแรงได้แม้ไม่มีการแทรกแซงจากภายนอก เมื่อหลายองค์กรสร้างระบบบนผู้ให้บริการรายเดียวกัน ผู้ให้บริการรายนั้นจะกลายเป็นส่วนที่มีความสำคัญเชิงระบบโดยปริยายของอินเทอร์เน็ต

การพึ่งพาแบบ "อ่อน" ก็สร้างความเสียหายได้เช่นกัน

บริการบางส่วนที่ได้รับผลกระทบไม่ได้ใช้ Cloudflare เป็นเพียง CDN แบบธรรมดาเท่านั้น แต่พวกเขายัง:

• ใช้Cloudflare Accessสำหรับการตรวจสอบสิทธิ์และการเข้าถึงแบบศูนย์ความไว้วางใจ

• การใช้Workers KVเป็นส่วนหนึ่งของระบบควบคุมภายใน

• พึ่งพาTurnstileสำหรับการเข้าสู่ระบบที่ต้านทานบอท บล็อกCloudflare+1

เมื่อผลิตภัณฑ์เหล่านั้นล้มเหลว ไม่ใช่แค่เนื้อหาบนเว็บไซต์เท่านั้นที่หายไป –การเข้าสู่ระบบ, ฟังก์ชันผู้ดูแลระบบ, และ API ภายในก็เสียหายไปด้วยเช่นกัน นั่นทำให้การกู้คืนซับซ้อนมากขึ้น: หน้าสถานะของคุณ, เครื่องมือจัดการเหตุการณ์, หรือ UI ผู้ดูแลระบบอาจพึ่งพาผู้ให้บริการเดียวกันที่เพิ่งล้มเหลวไป

สิ่งที่ Cloudflare ระบุว่าจะเปลี่ยนแปลง

บล็อกของ Cloudflare ได้ระบุขั้นตอนแก้ไขหลายประการที่บริษัทกำลังดำเนินการอยู่แล้วเพื่อลดความเสี่ยงของการเกิดเหตุการณ์ที่คล้ายกันขึ้นอีก:บล็อกของ Cloudflare

1. การป้องกันการเข้าถึงไฟล์การกำหนดค่าที่สร้างโดยอัตโนมัติ
   จัดการกับการตั้งค่าที่สร้างขึ้นภายในองค์กรด้วยความระมัดระวังและการตรวจสอบความถูกต้องเช่นเดียวกับข้อมูลที่ผู้ใช้ป้อนเข้ามา รวมถึงการตรวจสอบรูปแบบและขนาดอย่างเข้มงวดก่อนการใช้งานจริง

2. สวิตช์ปิดระบบทั่วโลกเพิ่มเติม
   ทำให้ง่ายต่อการปิดใช้งานโมดูลภายในที่มีปัญหา (เช่น การจัดการบอท) ทั่วทั้งเครือข่ายได้อย่างรวดเร็วเพื่อป้องกันไม่ให้ระบบเกิดข้อผิดพลาดทั่วทั้งเส้นทางพร็อกซี

3. ปกป้องทรัพยากรของระบบจากพายุข้อผิดพลาด
   ตรวจสอบให้แน่ใจว่าไฟล์ core dump, ข้อมูลเมตาสำหรับการดีบัก และเครื่องมือสำหรับการสังเกตการณ์ ไม่สามารถทำให้ CPU และหน่วยความจำทำงานหนักเกินไปเมื่อเกิดข้อผิดพลาดเพิ่มขึ้นอย่างรวดเร็ว

4. ทบทวนรูปแบบความล้มเหลวของโมดูลตัวแทนหลัก
   ตรวจสอบอย่างเป็นระบบว่าแต่ละโมดูลภายในทำงานอย่างไรภายใต้ข้อมูลหรือการกำหนดค่าที่ไม่คาดคิด และให้แน่ใจว่าการทำงานลดลงอย่างราบรื่นแทนที่จะล้มเหลวทั้งหมด

5. ปรับปรุงการเปิดตัวและการแยกส่วน
   แม้ว่าจะไม่ได้ระบุรายละเอียดอย่างชัดเจน แต่เหตุการณ์นี้บ่งชี้ว่า Cloudflare น่าจะแบ่งแยกการกระจายค่าคอนฟิกใหม่และพฤติกรรมของฐานข้อมูลให้มากขึ้น เพื่อลดโอกาสที่การเปลี่ยนแปลงที่ไม่ดีเพียงครั้งเดียวจะส่งผลกระทบต่อทั้งระบบ

พวกเขายังได้กล่าวถึงเหตุการณ์นี้ว่าเป็นการล้มเหลวอย่างสิ้นเชิงของความคาดหวังในความยืดหยุ่นของตน โดยเรียกมันว่า "ไม่สามารถยอมรับได้" และยอมรับอย่างชัดแจ้งถึงความเจ็บปวดที่มันได้ก่อให้เกิดแก่ลูกค้าและผู้ใช้ทั่วไปของอินเทอร์เน็ตบล็อกของ Cloudflare

บทเรียนสำหรับทีมโครงสร้างพื้นฐานและ SRE

แม้ว่าคุณจะไม่ได้ดำเนินธุรกิจขนาดใหญ่เช่น Cloudflare แต่เหตุการณ์ระบบล่มครั้งนี้ก็มีบทเรียนด้านการออกแบบและการดำเนินงานที่เป็นประโยชน์อย่างมาก:

จัดการการตั้งค่าภายในเหมือนข้อมูลที่ไม่น่าเชื่อถือ

มันง่ายที่จะคิดว่า "ของเราเอง" ที่สร้างการกำหนดค่าไว้ถูกต้องเสมอ เมื่อวานนี้แสดงให้เห็นว่าทำไมนั่นถึงอันตราย:

• ตรวจสอบขนาด, รูปร่าง, และขีดจำกัดของไฟล์การกำหนดค่าให้ถูกต้องก่อนนำไปใช้

• พิจารณาการใช้งานคอนฟิกแบบทดลองกับปริมาณการเข้าใช้งานหรือโหนดจำนวนน้อยก่อน โดยมีการย้อนกลับโดยอัตโนมัติหากพบความผิดปกติ

• กำหนดขีดจำกัดสูงสุดและมาตรการตัดวงจรโดยรอบจำนวนฟีเจอร์ การจัดสรรหน่วยความจำล่วงหน้า และการใช้ CPU อย่างเคร่งครัด

ออกแบบเพื่อรองรับความล้มเหลวบางส่วนอย่างสง่างาม

มีข้อบกพร่องในโมดูลการจัดการบอทที่ไม่ควรทำให้เส้นทางพร็อกซีทั้งหมดเกิดความตื่นตระหนก:

• ตั้งค่าเริ่มต้นเป็นเปิดเมื่อล้มเหลว (fail-open) แทนปิดเมื่อล้มเหลว (fail-closed) ในบางชั้นของระบบความปลอดภัย เมื่อทางเลือกคือการหยุดทำงานทั้งหมด

• สร้างสวิตช์ตัดการทำงานที่ชัดเจนและผ่านการทดสอบสำหรับฟีเจอร์ที่ไม่ใช่แกนหลัก

• ตรวจสอบให้แน่ใจว่าระบบย่อยที่สำคัญ (ระบบยืนยันตัวตน, หน้าสถานะ, เครื่องมือจัดการเหตุการณ์) สามารถทำงานได้ในโหมดที่มีประสิทธิภาพลดลงหรือผ่านเส้นทางสำรอง

สังเกตสัญญาณที่ถูกต้อง

การสลับไปมาระหว่าง "การตั้งค่าที่ดี" และ "การตั้งค่าที่ไม่ดี" ทุกห้านาทีทำให้สัญญาณดูเหมือนการโจมตีหรือพฤติกรรมภายนอกที่มีสัญญาณรบกวน:

• ตรวจสอบให้แน่ใจว่าคุณมีการเชื่อมโยงข้อมูลแบบเฉพาะเวอร์ชันหรือ เฉพาะการตั้งค่าในกระบวนการเฝ้าระวังของคุณ

• สร้างแดชบอร์ดที่ทำให้การเปลี่ยนแปลงการตั้งค่าเห็นได้ชัดเจนในเชิงภาพบนกราฟแสดงข้อผิดพลาด

• รวมการทดสอบสังเคราะห์ที่แข็งแกร่งจากมุมมองภายนอก เพื่อให้คุณสามารถแยกแยะความล้มเหลวภายในจากปัญหาเครือข่าย/เส้นทางได้อย่างรวดเร็ว

อย่าลงทุนทุกอย่างไว้ในโครงสร้างพื้นฐานเพียงอย่างเดียว

สำหรับองค์กรที่ใช้ Cloudflare:

• พิจารณาการตั้งค่าหลาย CDNสำหรับทรัพย์สินที่มีความสำคัญอย่างยิ่ง

• หลีกเลี่ยงการทำให้หน้าสถานะของคุณขึ้นอยู่กับผู้ให้บริการรายเดียวกับโครงสร้างหลักของคุณทั้งหมด (Cloudflare ทำเช่นนี้ แต่เมื่อวานนี้เกิดปัญหาโดยบังเอิญกับโฮสต์ของหน้าสถานะของพวกเขา ซึ่งทำให้สถานการณ์สับสนยิ่งขึ้น) บล็อก Cloudflare+1

• คิดให้รอบคอบก่อนที่จะเชื่อมโยงระบบตรวจสอบสิทธิ์,ระบบควบคุม API,และระบบส่งมอบหน้าเว็บของคุณกับผู้ให้บริการรายเดียวกันโดยไม่มีเส้นทางสำรอง.

ภาพรวมที่ใหญ่กว่า

ในช่วงไม่กี่เดือนที่ผ่านมาเพียงอย่างเดียว เราได้เห็นการหยุดให้บริการครั้งใหญ่ที่Microsoft Azure,Amazon Web Services และล่าสุดคือ Cloudflare ซึ่งทั้งหมดนี้ได้ทำให้บริการของผู้บริโภคและองค์กรขนาดใหญ่จำนวนมากต้องหยุดชะงักชั่วคราวAPNews+2The Washington Post+2

รูปแบบชัดเจน:

• อินเทอร์เน็ตกำลังพึ่งพาผู้ให้บริการโครงสร้างพื้นฐานรายใหญ่เพียงไม่กี่รายมากขึ้นเรื่อยๆ

• การหยุดชะงักมักเกิดจากการกระทำของตนเอง มากกว่าที่จะเกิดจากการโจมตีจากภายนอก โดยมักมีสาเหตุมาจากการเปลี่ยนแปลงภายในที่ซับซ้อน

• ผู้ให้บริการที่มีแนวปฏิบัติ SRE ระดับโลกก็ยังสามารถสะดุดกับปัญหาที่เกิดจากการโต้ตอบที่ไม่คาดคิดระหว่างการตั้งค่า พฤติกรรมของฐานข้อมูล และข้อจำกัดที่ฝังไว้อย่างถาวร

เหตุการณ์ Cloudflare เมื่อวานนี้เป็นเครื่องเตือนใจอย่างชัดเจนว่า"คลาวด์" ไม่ใช่เวทมนตร์ ที่เบื้องล่างมันยังคงเป็นซอฟต์แวร์ที่เขียนโดยมนุษย์ ซึ่งต้องเผชิญกับข้อบกพร่องประเภทเดียวกันกับแอปพลิเคชันอื่นๆ เพียงแต่มีผู้คนจำนวนมากขึ้นที่ต้องพึ่งพาอาศัยมัน

สำหรับผู้ใช้ เหตุการณ์นี้จะถูกจดจำส่วนใหญ่ว่าเป็น "เช้าวันนั้นที่ X และ ChatGPT ไม่โหลด"
สำหรับวิศวกร นี่อาจถูกศึกษาเป็นตัวอย่างในตำราเกี่ยวกับวิธีที่ข้อบกพร่องในการกำหนดค่าที่ละเอียดอ่อนในระบบกระจายหลักสามารถส่งผลกระทบเป็นวงกว้างจนกลายเป็นเหตุการณ์ระดับโลกบนอินเทอร์เน็ต