การวิเคราะห์หลังเหตุขัดข้องของ Cloudflare Control Plane และระบบวิเคราะห์
(blog.cloudflare.com)- ตั้งแต่วันที่ 2 พฤศจิกายน 2023 เวลา 11:43 UTC control plane และบริการวิเคราะห์ของ Cloudflare ขัดข้อง ส่งผลกระทบต่อการเปลี่ยนแปลงผ่านแดชบอร์ด/API รวมถึงฟังก์ชันบันทึกและวิเคราะห์
- จุดเริ่มต้นของเหตุขัดข้องคือ ไฟฟ้าขัดข้องที่ PDX-04 ใน Oregon ซึ่งดำเนินงานโดย Flexential และสถานที่นี้มีคลัสเตอร์วิเคราะห์ที่ใหญ่ที่สุด รวมถึงอุปกรณ์ของคลัสเตอร์ high availability มากกว่าหนึ่งในสาม
- เมื่อการกู้คืน utility feed, generator, UPS และ circuit breaker สั่นคลอนต่อเนื่องกัน การพึ่งพา Kafka·ClickHouse ที่ผูกกับ PDX-04 จึงทำให้การออกแบบ high availability ล้มเหลว
- วันที่ 2 พฤศจิกายน เวลา 13:40 UTC มีการตัดสินใจ failover ไปยังไซต์กู้คืนภัยพิบัติในยุโรป และภายใน 17:57 UTC ผลกระทบต่อลูกค้าส่วนใหญ่ลดลงแล้ว แต่การประมวลผล log, bespoke API บางส่วน, การตั้งค่า Magic WAN แบบ manual และการอัปโหลด Stream ได้รับผลกระทบนานกว่า
- Cloudflare เดินหน้า Code Orange เพื่อผลักดันข้อกำหนด high availability สำหรับผลิตภัณฑ์ GA, แผนกู้คืนภัยพิบัติ ที่ผ่านการตรวจสอบแล้ว, chaos testing ที่รวมถึงการถอดศูนย์ข้อมูลหลักทั้งแห่งออก และแผนป้องกันการสูญหายของ log
ขอบเขตเหตุขัดข้องและผลกระทบต่อลูกค้า
- ตั้งแต่วันที่ 2 พฤศจิกายน 2023 เวลา 11:43 UTC control plane และบริการวิเคราะห์ของ Cloudflare เกิดขัดข้อง
- control plane หมายถึงอินเทอร์เฟซสำหรับลูกค้า ซึ่งรวมถึงเว็บไซต์และ API
- บริการวิเคราะห์รวมถึง logging และรายงานวิเคราะห์
- เหตุการณ์ทั้งหมดดำเนินตั้งแต่วันที่ 2 พฤศจิกายน 11:44 UTC ถึงวันที่ 4 พฤศจิกายน 04:25 UTC
- วันที่ 2 พฤศจิกายน 17:57 UTC control plane ส่วนใหญ่ได้รับการกู้คืนที่สถานที่กู้คืนภัยพิบัติ
- หลังสถานที่กู้คืนภัยพิบัติกลับมาออนไลน์ ลูกค้าจำนวนมากในผลิตภัณฑ์ส่วนใหญ่อาจไม่พบปัญหา
- บางบริการใช้เวลากู้คืนนานกว่า และลูกค้าที่ใช้บริการเหล่านั้นอาจยังเห็นปัญหาจนกว่าจะได้รับการแก้ไขอย่างสมบูรณ์
- บริการ raw log ไม่พร้อมให้บริการสำหรับลูกค้าส่วนใหญ่ตลอดช่วงเวลาส่วนใหญ่ของเหตุการณ์
- บริการเครือข่ายและความปลอดภัย ของ Cloudflare ทำงานตามที่คาดไว้ตลอดเหตุการณ์
- มีช่วงเวลาที่ลูกค้าไม่สามารถเปลี่ยนแปลงบริการเหล่านั้นได้
- ทราฟฟิกที่ผ่านเครือข่าย Cloudflare ไม่ได้รับผลกระทบ
การออกแบบเดิม: high availability บนศูนย์ข้อมูล 3 แห่งใน Oregon
- control plane และระบบวิเคราะห์ของ Cloudflare ทำงานหลักบนเซิร์ฟเวอร์ในศูนย์ข้อมูล 3 แห่งรอบ Hillsboro, Oregon
- ศูนย์ข้อมูลทั้ง 3 แห่งเป็นอิสระจากกัน และแต่ละแห่งมี utility power feed หลายเส้น รวมถึงการเชื่อมต่อเครือข่ายที่ซ้ำซ้อนและเป็นอิสระหลายเส้น
- สถานที่เหล่านี้ถูกเลือกให้ตั้งห่างกันพอที่ภัยธรรมชาติจะส่งผลพร้อมกันได้ยาก แต่ใกล้กันพอที่จะรัน คลัสเตอร์ข้อมูลซ้ำซ้อนแบบ active-active ได้
- ทั้งสามสถานที่ซิงค์ข้อมูลกันอย่างต่อเนื่อง
- ตามการออกแบบแล้ว แม้สถานที่หนึ่งจะออฟไลน์ สถานที่ที่เหลือก็ควรดำเนินงานต่อได้
- การออกแบบ high availability นี้เริ่มนำมาใช้ตั้งแต่ 4 ปีก่อน
- ระบบ control plane หลักส่วนใหญ่ถูกย้ายไปยังคลัสเตอร์ high availability แล้ว
- บริการของผลิตภัณฑ์ใหม่บางส่วนยังไม่ได้รวมอยู่ในคลัสเตอร์ high availability
- ระบบ logging ไม่ได้ถูกรวมไว้ในคลัสเตอร์ high availability โดยเจตนา
- log ถูกมองเป็นปัญหาแบบกระจาย โดยจะเข้าคิวที่ network edge แล้วส่งต่อไปยัง Oregon core หรือสถานที่ logging ระดับภูมิภาค
- หากสถานที่ logging ออฟไลน์ log วิเคราะห์จะรออยู่ที่ edge และถือว่าความล่าช้าในการวิเคราะห์เป็นสิ่งที่ยอมรับได้
จุดเริ่มต้นของไฟฟ้าขัดข้องที่ PDX-04
- ในบรรดาสถานที่ 3 แห่งใน Oregon แห่งที่ใหญ่ที่สุดคือ PDX-04 ซึ่งดำเนินงานโดย Flexential
- Cloudflare วางคลัสเตอร์วิเคราะห์ที่ใหญ่ที่สุดไว้ที่นี่
- อุปกรณ์ของคลัสเตอร์ high availability มากกว่าหนึ่งในสามก็อยู่ในสถานที่นี้ด้วย
- ที่นี่ยังเป็นตำแหน่งหลักของบริการที่ยังไม่ได้ onboarding เข้าสู่คลัสเตอร์ high availability
- Cloudflare เป็นลูกค้ารายค่อนข้างใหญ่ โดยใช้ประมาณ 10% ของความจุทั้งหมดของสถานที่นี้
- วันที่ 2 พฤศจิกายน เวลา 08:50 UTC เกิดเหตุการณ์บำรุงรักษาที่ไม่ได้วางแผนไว้ในหนึ่งใน independent power feed ของ Portland General Electric (PGE) ที่จ่ายไฟให้ PDX-04
- เหตุการณ์นี้ทำให้ feed หนึ่งเส้นที่เข้า PDX-04 หยุดทำงาน
- Flexential เดิน generator เพื่อชดเชย feed ที่หยุดลง
- Flexential ไม่ได้แจ้ง Cloudflare ว่าได้ failover ไปใช้ไฟจาก generator
- เครื่องมือสังเกตการณ์ของ Cloudflare ตรวจไม่พบว่าแหล่งจ่ายไฟเปลี่ยนไป
- หากมีการแจ้งล่วงหน้า Cloudflare จะสามารถเฝ้าติดตามสถานที่นี้อย่างใกล้ชิด และย้ายบริการ control plane ที่พึ่งพาสถานที่นี้ไปที่อื่นได้
- การที่ Flexential ใช้งาน utility feed ที่เหลือควบคู่กับ generator ก็เป็นเรื่องผิดปกติ
- Flexential มี generator 10 เครื่องรวมชุดสำรอง และสามารถรองรับโหลดทั้งสถานที่ได้
- การดำเนินงานสถานที่ด้วย utility feed ที่เหลือเพียงอย่างเดียวก็ทำได้
- Cloudflare ไม่ได้รับคำตอบที่ชัดเจนว่าทำไม Flexential จึงใช้ utility power และ generator power ร่วมกัน
สาเหตุที่ยังไม่ได้ยืนยันและการหยุดทำงานของ generator
- หลังจากนั้น สาเหตุรากและการตัดสินใจบางส่วนของเหตุการณ์ยังไม่ได้รับการยืนยันอย่างชัดเจนจาก Flexential
- หนึ่งในเหตุผลที่เป็นไปได้คือ Flexential อาจเข้าร่วม โปรแกรม DSG ของ PGE
- DSG เป็นโปรแกรมที่ทำให้บริษัทไฟฟ้าท้องถิ่นสามารถใช้ generator ของศูนย์ข้อมูลเพื่อจ่ายไฟเพิ่มเติมเข้าสู่โครงข่ายไฟฟ้า
- เพื่อแลกเปลี่ยน บริษัทไฟฟ้าจะสนับสนุนการบำรุงรักษา generator และการจัดหาเชื้อเพลิง
- Cloudflare ไม่พบบันทึกว่า Flexential แจ้งเรื่องโปรแกรม DSG
- และไม่ได้รับคำตอบว่า DSG ถูกเปิดใช้งานอยู่ในขณะเกิดเหตุหรือไม่
- ราว 11:40 UTC เกิด ground fault ที่ transformer ของ PGE ใน PDX-04
- Cloudflare คาดว่า transformer นี้น่าจะเป็นอุปกรณ์ที่ลดแรงดันของ feed เส้นที่สองซึ่งเข้ามายังศูนย์ข้อมูล แต่ไม่ได้รับการยืนยัน
- ยังไม่ได้รับการยืนยันว่า ground fault นี้มีที่มาจากการบำรุงรักษาที่ไม่ได้วางแผนของ PGE ซึ่งกระทบ feed เส้นแรกหรือไม่
- ground fault บนสายไฟแรงสูง 12,470V ถูกออกแบบให้ระบบไฟฟ้าตัดวงจรอย่างรวดเร็วเพื่อป้องกันความเสียหาย
- มาตรการป้องกันนี้ทำให้ generator ทั้งหมดของ PDX-04 หยุดทำงานด้วย
- ผลคือทั้ง utility line และ generator ทั้ง 10 เครื่องออฟไลน์ทั้งหมด
- PDX-04 มีแบตเตอรี่ UPS bank ซึ่งตามที่ทราบกันว่าสามารถพยุงสถานที่ได้ประมาณ 10 นาที
- เวลานี้มีไว้เพื่ออุดช่องว่างระหว่างไฟฟ้าขัดข้องกับการรีสตาร์ต generator อัตโนมัติ
- จากการสังเกตความขัดข้องของอุปกรณ์ Cloudflare แบตเตอรี่เริ่มล้มเหลวภายใน 4 นาที
- Flexential ใช้เวลานานกว่า 10 นาทีมากในการกู้คืน generator
ความล่าช้าในการกู้คืนไฟฟ้าและการแจ้งครั้งแรก
- แม้ Cloudflare จะไม่ได้รับการยืนยันอย่างเป็นทางการ แต่ได้รับฟังจากพนักงาน Flexential ถึงปัจจัยสามอย่างที่ขัดขวางการกู้คืน generator
- วิธีที่ circuit trip จาก ground fault ทำให้ต้องเข้าถึง generator ทางกายภาพเพื่อรีสตาร์ตแบบ manual
- ระบบควบคุมการเข้าออกของ Flexential ออฟไลน์ เพราะไม่ได้รับไฟสำรองจากแบตเตอรี่
- พนักงานกะกลางคืนไม่มีผู้เชี่ยวชาญด้านปฏิบัติการหรือไฟฟ้าที่มีประสบการณ์ มีเพียงเจ้าหน้าที่รักษาความปลอดภัยและช่างเทคนิคที่เพิ่งเข้าทำงานได้ 1 สัปดาห์โดยไม่มีผู้ประกบ
- ระหว่าง 11:44–12:01 UTC ขณะที่ generator ยังรีสตาร์ตไม่สมบูรณ์ แบตเตอรี่ UPS หมด ทำให้ลูกค้าทั้งหมดในศูนย์ข้อมูลสูญเสียไฟฟ้า
- Flexential ไม่ได้แจ้ง Cloudflare ถึงปัญหาของสถานที่ระหว่างกระบวนการนี้
- Cloudflare รับรู้ปัญหาศูนย์ข้อมูลครั้งแรกเมื่อเราเตอร์ 2 ตัวที่เชื่อมสถานที่กับภายนอกออฟไลน์ในเวลา 11:44 UTC
- เมื่อไม่สามารถเข้าถึงเราเตอร์ได้โดยตรงหรือผ่าน out-of-band management จึงติดต่อ Flexential และส่งทีมในพื้นที่ไปยังสถานที่
- ข้อความแจ้งเหตุขัดข้องครั้งแรกที่ Flexential ส่งถึง Cloudflare คือเวลา 12:28 UTC
- ข้อความระบุว่าปัญหาไฟฟ้าของ PDX-04 เริ่มราว 12:00 UTC วิศวกรกำลังกู้คืน และจะอัปเดตความคืบหน้าทุก 30 นาที
ปัญหาการพึ่งพาที่เผยในดีไซน์ high availability
- PDX-04 ได้รับการออกแบบที่ผ่านการรับรอง Tier III ก่อนการก่อสร้าง และคาดว่าจะให้ SLA แบบ high availability แต่ Cloudflare ก็วางแผนเผื่อความเป็นไปได้ที่สถานที่นี้จะออฟไลน์ไว้แล้ว
- ผลกระทบที่คาดไว้คือการหยุดชะงักของ analytics, การสะสมคิว log และความล่าช้าที่ edge, รวมถึงการหยุดชั่วคราวของบริการลำดับความสำคัญต่ำที่ยังไม่ถูกรวมเข้ากับคลัสเตอร์ high availability
- การที่ศูนย์ข้อมูลอีกสองแห่งรับหน้าที่คลัสเตอร์ high availability และรักษาบริการหลักให้ออนไลน์ โดยรวมทำงานตามแผน
- ปัญหาคือบริการบางส่วนที่ควรอยู่ในคลัสเตอร์ high availability กลับพึ่งพาบริการที่รันเฉพาะใน PDX-04
- Kafka และ ClickHouse ซึ่งรับผิดชอบการประมวลผล log และ analytics ให้บริการเฉพาะที่ PDX-04
- บริการบางส่วนที่รันในคลัสเตอร์ high availability พึ่งพาสิ่งเหล่านี้
- การพึ่งพานี้ควรหลวมกว่านี้ ควรล้มเหลวอย่างนุ่มนวลกว่านี้ และควรถูกค้นพบล่วงหน้า
- Cloudflare เคยทดสอบคลัสเตอร์ high availability โดยทำให้สถานที่อีกสองแห่งแต่ละแห่งและทั้งสองแห่งออฟไลน์ทั้งหมด
- มีการทดสอบที่ทำให้ส่วน high availability ของ PDX-04 ออฟไลน์ด้วย
- แต่ไม่ได้ทดสอบทำให้ทั้งสถานที่ PDX-04 ออฟไลน์ทั้งหมด
- เกณฑ์ที่กำหนดให้ผลิตภัณฑ์ใหม่และฐานข้อมูลที่เกี่ยวข้องต้องถูกรวมเข้ากับคลัสเตอร์ high availability ก็หย่อนเกินไป
- ทีมผลิตภัณฑ์มีเส้นทางเข้าสู่ระยะ alpha แตกต่างกัน
- แนวทางคือค่อยย้าย backend ไปสู่ best practice เมื่อเวลาผ่านไป แต่ไม่ได้กำหนดเป็นข้อกำหนดอย่างเป็นทางการก่อนประกาศ GA
- ผลคือการป้องกันแบบซ้ำซ้อนทำงานไม่สม่ำเสมอในแต่ละผลิตภัณฑ์
การย้ายไปยังไซต์กู้คืนภัยพิบัติ
- เวลา 12:48 UTC Flexential รีสตาร์ต generator และไฟฟ้ากลับมาในบางส่วนของสถานที่
- การกู้คืนไฟฟ้าในศูนย์ข้อมูลโดยทั่วไปจะดำเนินแบบค่อยเป็นค่อยไปทีละวงจร
- เมื่อถึงจังหวะจะเปิดวงจรของ Cloudflare อีกครั้ง พบว่า circuit breaker เสีย
- ไม่ทราบว่า breaker เหล่านี้เสียเพราะ ground fault หรือ surge หรือมีปัญหามาก่อนแล้ว
- Flexential เริ่มเปลี่ยน breaker ที่เสีย
- มี breaker เสียมากกว่าจำนวนอะไหล่ที่มีในสถานที่ จึงต้องจัดหา breaker ใหม่
- เมื่อ Cloudflare พบว่าบริการออฟไลน์มากกว่าที่คาด และ Flexential ไม่สามารถให้เวลาประมาณการกู้คืนได้ จึงตัดสินใจ failover ไปยัง ไซต์กู้คืนภัยพิบัติ ในยุโรปเวลา 13:40 UTC
- ต้อง failover เพียงสัดส่วนเล็ก ๆ ของ control plane ทั้งหมด
- บริการส่วนใหญ่ยังคงรันต่อในระบบ high availability ของศูนย์ข้อมูล core อีกสองแห่ง
- เวลา 13:43 UTC บริการแรกเริ่มทำงานที่ไซต์กู้คืนภัยพิบัติ
- ไซต์นี้ออกแบบมาเพื่อให้บริการ control plane หลักเมื่อเกิดภัยพิบัติ
- ไม่รองรับบริการประมวลผล log บางส่วน
- หลังเริ่มบริการ มี API call ที่เคยล้มเหลวหลั่งไหลเข้ามา ทำให้เกิดปัญหา thundering herd
- Cloudflare ใช้ rate limit เพื่อควบคุมปริมาณคำขอ
- ในช่วงเวลานี้ ลูกค้าผลิตภัณฑ์ส่วนใหญ่อาจเห็นข้อผิดพลาดเป็นครั้งคราวเมื่อทำการเปลี่ยนแปลงผ่านแดชบอร์ดหรือ API
- ภายใน 17:57 UTC บริการที่ย้ายไปยังไซต์กู้คืนภัยพิบัติเสถียรขึ้น และผลกระทบโดยตรงต่อลูกค้าส่วนใหญ่ลดลง
- บางระบบ เช่น Magic WAN ยังจำเป็นต้องตั้งค่าแบบ manual
- บริการที่เกี่ยวข้องกับการประมวลผล log และ bespoke API บางส่วนยังใช้งานไม่ได้จนกว่า PDX-04 จะกู้คืน
การกู้คืนล่าช้าของบางผลิตภัณฑ์และการรีสตาร์ต PDX-04
- บางผลิตภัณฑ์ไม่สามารถทำงานได้อย่างถูกต้องที่ไซต์กู้คืนภัยพิบัติ
- ส่วนใหญ่เป็นผลิตภัณฑ์ใหม่ที่ขั้นตอนกู้คืนภัยพิบัติยังไม่ได้ดำเนินการและทดสอบอย่างสมบูรณ์
- รวมถึงบริการ Stream สำหรับอัปโหลดวิดีโอใหม่ และบริการอื่นบางส่วน
- ทีม Cloudflare ดำเนินการสองแนวทางพร้อมกัน
- นำบริการเหล่านั้นกลับมาใช้งานใหม่ที่ไซต์กู้คืนภัยพิบัติ
- ย้ายไปยังคลัสเตอร์ high availability
- Flexential เปลี่ยน circuit breaker ที่เสีย กู้คืน utility feed ทั้งสองเส้น และยืนยันไฟฟ้าที่เสถียรในเวลา 22:48 UTC
- Cloudflare ตัดสินใจให้บุคลากรส่วนใหญ่พักผ่อนและเริ่มงานนำ PDX-04 กลับมาในเช้าวันถัดไป เนื่องจากทีมรับมือเหตุฉุกเฉินมาตลอดทั้งวัน
- การตัดสินใจนี้ทำให้การกู้คืนโดยรวมล่าช้า แต่เป็นการตัดสินเพื่อช่วยลดโอกาสเกิดความผิดพลาดเพิ่มเติม
- ตั้งแต่เช้าวันที่ 3 พฤศจิกายน การกู้คืนบริการ PDX-04 เริ่มต้นขึ้น
- บูตอุปกรณ์เครือข่ายทางกายภาพ
- เปิดเซิร์ฟเวอร์หลายพันเครื่องและกู้คืนบริการ
- เนื่องจากอาจเกิด power cycle หลายครั้งระหว่างเหตุการณ์ จึงไม่ทราบสถานะของบริการภายในศูนย์ข้อมูล
- ขั้นตอนกู้คืนที่ปลอดภัยคือทำตามการ bootstrap ทั้งสถานที่อย่างสมบูรณ์
- นำเซิร์ฟเวอร์ configuration management กลับมาออนไลน์แบบ manual และใช้เวลา 3 ชั่วโมงในการ rebuild
- จากนั้น rebuild เซิร์ฟเวอร์ที่เหลือด้วยวิธี bootstrap
- การ rebuild แต่ละเซิร์ฟเวอร์ใช้เวลา 10 นาทีถึง 2 ชั่วโมง
- แม้รันแบบขนานบนหลายเซิร์ฟเวอร์ แต่บางส่วนต้องกู้คืนตามลำดับเพราะการพึ่งพาระหว่างบริการ
- บริการทั้งหมดกู้คืนสมบูรณ์ในวันที่ 4 พฤศจิกายน 2023 เวลา 04:25 UTC
- ลูกค้าส่วนใหญ่คาดว่าจะไม่มีข้อมูลสูญหายใน analytics ส่วนใหญ่ของแดชบอร์ดและ API เพราะข้อมูล analytics ถูกเก็บไว้ที่ศูนย์ข้อมูล core ในยุโรปด้วย
- dataset บางส่วนที่ไม่ได้ replicate ไป EU จะยังมีช่องว่างถาวร
- ลูกค้าที่ใช้ Logpush ไม่ได้รับการประมวลผล log ตลอดช่วงเวลาส่วนใหญ่ของเหตุการณ์ และ log ที่ไม่ได้รับจะไม่สามารถกู้คืนได้
Code Orange และแผนปรับปรุง
- Cloudflare ยังมีคำถามจำนวนมากที่ต้องได้รับคำตอบจาก Flexential แต่สรุปว่าต้องคาดการณ์ความล้มเหลวของศูนย์ข้อมูลทั้งแห่งไว้ด้วย
- Cloudflare นำ Code Orange มาใช้ ซึ่งเป็นกระบวนการของบริษัทเองสำหรับโฟกัสทรัพยากรวิศวกรรมไปแก้ปัญหาในเหตุการณ์สำคัญหรือวิกฤต คล้ายกับ Code Yellow และ Code Red ของ Google
- ฟังก์ชันวิศวกรรมที่ไม่ใช่แกนหลักจะถูกปรับไปทำงานที่รับประกันความน่าเชื่อถือสูงของ control plane
- การเปลี่ยนแปลงที่วางแผนไว้มีดังนี้
- ลบการพึ่งพาศูนย์ข้อมูล core ออกจากการตั้งค่า control plane ของทุกบริการ และย้ายให้เครือข่ายแบบกระจายของ Cloudflare ทำงานก่อนเมื่อเป็นไปได้
- รับประกันว่า control plane ที่รันบนเครือข่ายจะยังทำงานต่อได้แม้ศูนย์ข้อมูล core ทั้งหมดออฟไลน์
- กำหนดให้ผลิตภัณฑ์และฟีเจอร์ GA ที่พึ่งพาศูนย์ข้อมูล core ต้องพึ่งพา คลัสเตอร์ high availability โดยไม่มีการพึ่งพาซอฟต์แวร์ต่อสถานที่เฉพาะแห่ง
- กำหนดให้ผลิตภัณฑ์และฟีเจอร์ GA ต้องมีแผนกู้คืนภัยพิบัติที่เชื่อถือได้และผ่านการทดสอบแล้ว
- ทดสอบ blast radius ของความล้มเหลวของระบบ และลดจำนวนบริการที่ได้รับผลกระทบจากความขัดข้องให้เหลือน้อยที่สุด
- ดำเนิน chaos testing ที่เข้มงวดขึ้นสำหรับฟังก์ชันศูนย์ข้อมูลทั้งหมด รวมถึงการถอด facility ของศูนย์ข้อมูล core แต่ละแห่งออกทั้งหมด
- audit ศูนย์ข้อมูล core ทั้งหมดอย่างละเอียด และวางแผน re-audit เพื่อรับรองการปฏิบัติตามมาตรฐาน
- จัดทำแผนกู้คืนภัยพิบัติสำหรับ logging และ analytics เพื่อไม่ให้ log สูญหายแม้เกิดความขัดข้องในสถานที่ core ทั้งหมด
- Cloudflare สรุปว่าแม้จะมีระบบและขั้นตอนที่จำเป็นแล้ว แต่ยังขาดความเข้มงวดในการบังคับให้ปฏิบัติตามและทดสอบการพึ่งพาที่ไม่เป็นที่รู้จัก
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
เป็นการตัดสินใจที่แปลก ที่ใช้พื้นที่ส่วนใหญ่ของบทความไปกับการเอ่ยชื่อ ผู้ให้บริการ รายหนึ่ง โยนความรับผิดชอบ และคาดเดาสาเหตุรากเหง้า
การเปิดเผยว่าเป็นลูกค้ารายใหญ่ภายในสถานที่นั้น และถึงขั้นใส่แผนผังไฟฟ้าที่ผู้ให้บริการทำเครื่องหมายว่าเป็น Confidential ไว้ในบทวิเคราะห์หลังเหตุการณ์ ก็ดูค่อนข้างไม่เหมาะสม
การอธิบายปัจจัยกระตุ้นและบริบทของเหตุการณ์นั้นเข้าใจได้ แต่จุดโฟกัสของบทวิเคราะห์หลังเหตุการณ์ควรเป็น เหตุขัดข้องของ Cloudflare ไม่ใช่ผู้ให้บริการ
Flexential ก็ควรทำบทวิเคราะห์หลังเหตุการณ์ของตัวเอง แต่ Cloudflare ไม่จำเป็นต้องไปคาดเดาแทนแล้วเผยแพร่ต่อสาธารณะ
อีกวัตถุประสงค์หนึ่งอาจเป็นการที่ Cloudflare ชิงอธิบายก่อนที่ใครบางคนจะสร้างเรื่องเล่าขึ้นมาก่อน
ในสถานการณ์ที่มีสามฝ่ายและหลายระบบที่เชื่อมโยงกันเกี่ยวข้องอยู่ การที่ Cloudflare อยากรู้ให้ถึงที่สุดว่าเกิดอะไรขึ้น เพื่อจะนำ โหมดความขัดข้องแบบผสม เช่นนี้ไปสะท้อนในการออกแบบต่อไป ก็เป็นเรื่องสมเหตุสมผล
ส่วนตัวแล้ว ผมขอบคุณข้อมูลที่ Cloudflare แชร์
ความรับผิดชอบ 99% อยู่ที่ Cloudflare ที่ทำงานหลักของตัวเองไม่ได้
การขุดคุ้ยบุคคลที่สามลึกขนาดนี้ ยิ่งแสดงให้เห็นว่าเรื่องนี้น่าอับอายสำหรับ Cloudflare แค่ไหน
ดูเหมือนว่าพวกเขาไม่ได้ตรวจสอบเซอร์กิตเบรกเกอร์อย่างเหมาะสมด้วย และทั้งที่เป็นสถานที่ค่อนข้างใหม่ แต่กลับมีเวลาไม่ถึงครึ่งหนึ่งของ 10 ชั่วโมงในการชาร์จแบตเตอรี่เครื่องกำเนิดไฟฟ้า
ระหว่างการบำรุงรักษานี้ควรสลับไปใช้เครื่องกำเนิดไฟฟ้าเต็มรูปแบบ และมีความเป็นไปได้ว่าไม่ได้ทำเพราะต้องช่วย PGE
ผมคิดว่า CEO ของ Cloudflare พูดถูก บริการศูนย์ข้อมูลเป็นสิ่งที่เราจ่ายเงินโดยคาดหวังความซ้ำซ้อนเต็มรูปแบบ และบอกว่าที่ตำแหน่งนี้มี 18MW แต่จากที่เห็นก็ยังไม่ชัดว่ามีฟีดแค่ 2 เส้นหรือไม่
ถ้าฟีดหนึ่งตาย คอนฟิก 2N ก็ควรเข้ามารับ และถ้ามีเครื่องกำเนิดไฟฟ้าก็ควรไม่มีปัญหา
ถ้าอย่างนั้นก็ถูกแล้วที่ต้องมีคำอธิบายเหตุการณ์เริ่มต้นเท่าที่ทราบมาจนถึงตอนนี้
ดูมีความเป็นไปได้สูงว่าจะมีบทวิเคราะห์ติดตามผลออกมา
https://twitter.com/eastdakota/status/1720688383607861442?t=...
จากเนื้อหาที่ถูกอ้างถึง สาเหตุรากเหง้าของเหตุขัดข้องคือ การพึ่งพาศูนย์ข้อมูลเดียว
ระบุว่าระบบ control plane หลักส่วนใหญ่ถูกย้ายไปยังคลัสเตอร์ high availability แล้ว แต่ผลิตภัณฑ์ใหม่บางส่วนยังไม่ใช่ บริการบางส่วนที่ควรอยู่ในคลัสเตอร์ high availability กลับพึ่งพาบริการที่รันเฉพาะใน PDX-04 และบางผลิตภัณฑ์ไม่ได้ถูกนำขึ้นไซต์ disaster recovery อย่างถูกต้อง
สำหรับบริษัทอย่าง Cloudflare ที่ค้ำจุนส่วนสำคัญของอินเทอร์เน็ตอยู่ นี่ค่อนข้างน่าอับอาย
Cloudflare บอกว่าการยอมให้หลายทีมสร้างนวัตกรรมได้รวดเร็ว ทำให้ผลิตภัณฑ์เลือกเส้นทางต่างกันไปจนถึง alpha ระยะแรก และเมื่อเวลาผ่านไปก็จะย้ายไปสู่ best practices แต่ไม่ได้กำหนดให้เป็นเงื่อนไขบังคับก่อนการเปิดตัวทั่วไป
นี่คือ ความล้มเหลวด้านการจัดการ อย่างสมบูรณ์ แบบนี้เท่ากับว่าลูกค้าถูกขายซอฟต์แวร์ที่ตามมาตรฐานภายในของ Cloudflare เองมีคุณภาพระดับ alpha ไม่ใช่หรือ?
https://news.ycombinator.com/item?id=38113503
ดูเหมือนขาดการตระหนักรู้ตัวเอง
นี่อยู่ระดับสมัครเล่น และยิ่งร้ายแรงตรงที่บริการใหม่ถูกเปิดตัวโดยไม่มี high availability
ในฐานะคนที่ได้รับผลกระทบบ้างจากเหตุขัดข้องนี้ ผมคิดว่าบทวิเคราะห์หลังเหตุการณ์นี้ยังไม่เพียงพอ
75% ของบทความพูดถึงเหตุขัดข้องด้านไฟฟ้าของ PDX-04 และความรับผิดชอบของ Flexential ซึ่งถ้าดูจากตัวหนังสือ สิ่งที่เกิดขึ้นที่นั่นดูเหมือนใกล้เคียงภัยพิบัติ จึงเข้าใจได้
แต่ไฟฟ้าถูกกู้คืนครบถ้วนแล้วตามเวลา UTC วันที่ 2 พฤศจิกายน และหลังจากนั้น Cloudflare ยังใช้เวลาอีกประมาณ 30 ชั่วโมงกว่าจะกู้คืนได้สมบูรณ์
การกู้คืนนานกว่าเหตุขัดข้องเองเสียอีก แต่บทความบอกเพียงว่ามีบริการจำนวนมากเกินไปที่พึ่งพากัน ผมอยากรู้รายละเอียดมากกว่านี้ว่าทำไมการกู้คืนการปฏิบัติการทั้งหมดจึงใช้เวลานานขนาดนั้น
ไม่มีบทเรียนจากกระบวนการกู้คืนเองเลยหรือ? หรือจริง ๆ แล้วเวลาทั้งหมดนั้นใช้ไปกับการซิงก์ข้อมูลจาก edge กลับไปยัง “สมอง” เท่านั้น?
อีกส่วนที่ขาดหายไปคือ การสื่อสารกับลูกค้าองค์กรที่ไม่เพียงพอ โดยเฉพาะ ฝ่ายสนับสนุนของ Cloudflare แทบจะเงียบสนิทนอกจากหน้า status และแม้ในทางปฏิบัติจะทำอะไรได้ไม่มาก แต่ก็ควรพยายามสื่อสาร
ยิ่งหลังจากที่บทวิเคราะห์หลังเหตุการณ์ตำหนิ Flexential เรื่องการสื่อสารไม่เพียงพอ ก็ยิ่งเป็นเช่นนั้น และแม้ผมจะชอบผลิตภัณฑ์ของ Cloudflare แต่คิดว่าควรดึงข้อสรุปจากเหตุการณ์นี้ให้มากกว่านี้
อย่างไรก็ตาม การเรียกสิ่งนี้ว่า บทวิเคราะห์หลังเหตุการณ์ ดูคลาดเคลื่อนไปเล็กน้อย ถ้าเป็นบทวิเคราะห์หลังเหตุการณ์แบบสมบูรณ์ ก็ควรมีรายละเอียดระดับที่กล่าวไว้ข้างต้น
ถ้า logging ล่ม บริการใดกันแน่ที่ล้มเหลว? มันถูกสร้างให้เป็นแบบนั้นโดยไม่ตั้งใจหรือ? ทำไมไม่มีใครสังเกตเห็น?
สิ่งที่ดีคือการวิเคราะห์หลังเหตุการณ์ของ Cloudflare ทำได้ละเอียดรอบคอบ
คำอธิบายที่ตรงไปตรงมาและโปร่งใสถือว่าน่าสดชื่น เมื่อเทียบกับกลยุทธ์การสื่อสารที่คลุมเครือของบริษัทอื่นแทบทั้งหมด
พวกเราก็ได้รับผลกระทบเหมือนกัน แต่เพราะบทความแบบนี้ กลับทำให้ไม่อยากย้ายออกไป ทุกคนทำพลาดและมีวันที่แย่ได้ ความแตกต่างอยู่ที่หลังจากนั้นตอบสนองอย่างไร
เหตุไฟฟ้าขัดข้องอธิบายย่อหน้าเดียวก็พอแล้ว หลังจากนั้นควรหันมาพูดฝั่ง Cloudflare ดาต้าเซ็นเตอร์ขัดข้องเกิดขึ้นได้
บทเรียนจริง ๆ อยู่ที่ การตอบสนองของ Cloudflare ที่ไม่สามารถพิจารณาสถานการณ์นั้นอย่างเหมาะสมและกู้คืนได้
พวกเราพึ่งพา CloudFlare Images อย่างมาก และในช่วง 30 วันที่ผ่านมา มันล่มไปเกิน 67 ชั่วโมง
วันที่ 9 ตุลาคมล่ม 22 ชั่วโมง, วันที่ 2–4 พฤศจิกายน 42 ชั่วโมง และมีเหตุขัดข้องครั้งละราว 1 ชั่วโมงประปราย ระดับความพร้อมใช้งานในเดือนที่ผ่านมาคือ 90.6%
ความโปร่งใสเป็นจุดแตกต่างที่ยอดเยี่ยมในหมู่ผู้ให้บริการที่แข่งขันกันในช่วงความพร้อมใช้งาน 99.9% แต่ถ้าระดับแทบจะเกิน 9 ตัวเดียวไปได้ ก็แทบไม่มีความหมาย
มันไม่ได้ช่วยปรับปรุงการทำงานมากนัก และอาจทำให้แรงจูงใจแย่ลง
ผมชื่นชมที่บอกว่าจะแก้ข้อผิดพลาดของกระบวนการตรงนี้ อย่างไรก็ตาม มันมีแรงตึงระหว่างการเดินหน้าเร็วกับการทำให้แน่ใจ
โดยปกติเรื่องแบบนี้มักถูกจัดการเหมือนสภาพอากาศ คือโดนฝนแล้วค่อยไปซื้อเสื้อกันฝน
ผมสงสัยว่าจะทำให้ความเชื่อถือได้เป็นส่วนหนึ่งของวัฒนธรรมได้อย่างไร โดยไม่ให้กระบวนการไปผูกมัดการพัฒนา
อาจสร้างแบบจำลองระบบด้วยซอฟต์แวร์ และตรวจสอบแบบจำลองนั้นด้วยการวิเคราะห์ทราฟฟิกได้ ถ้าการทดลองเสมือนช่วยลด ต้นทุนการทดลองด้านความเชื่อถือได้ ก็อาจจับปัญหาได้มากขึ้นก่อนปล่อยจริง
แปลกที่พออ่านบทความนี้แล้วกลับทำให้ความเชื่อมั่นต่อ Cloudflare ลดลง
บทความกดดันอย่างหนักว่า Flexential ทำตัวไม่เป็นมืออาชีพ ซึ่งก็อาจเป็นไปได้
แต่ข้อเท็จจริงที่ว่าระบบทั้งหมดที่ผู้คนพึ่งพาล่มลงนั้นคือ ความล้มเหลวด้านการทำซ้ำซ้อน ครั้งใหญ่ของฝั่ง Cloudflare ดาต้าเซ็นเตอร์สักแห่งควรถูกทิ้งไปได้โดยที่บริการยังทำงานต่อ
สิ่งที่น่ากังวลเป็นพิเศษคือการออกแบบที่ตั้งใจไว้เริ่มจาก “control plane และระบบวิเคราะห์ของ Cloudflare ทำงานหลัก ๆ บนเซิร์ฟเวอร์ในดาต้าเซ็นเตอร์ 3 แห่งใกล้ Hillsboro รัฐ Oregon”
ถ้าเป็น control plane ที่คนทั่วโลกใช้ ก็ควรมี การกระจายตัวทางภูมิศาสตร์ ที่กว้างกว่านี้มาก ที่น่าตกใจกว่าคือเรื่องนี้เป็นระดับการออกแบบที่ตั้งใจไว้ ไม่ใช่การใช้งานที่มีข้อบกพร่อง
ถ้าจะนำผลิตภัณฑ์ใหม่ออกให้ผู้บริโภคใช้ การออกแบบเพื่อทำซ้ำซ้อนไม่ควรเป็นสิ่งสำคัญอันดับแรกหรือ? น่าแปลกที่มันเคยเป็นแค่ตัวเลือก
ผมเองก็ใช้ Cloudflare กับบางระบบ เพราะเชื่อว่าถ้าเกิดเหตุแบบนี้ขึ้นจะมีการสลับระบบล้มเหลวที่ยอดเยี่ยม ตอนนี้เลยต้องกลับมาคิดใหม่ว่า Cloudflare Workers ปลอดภัยจากการตัดสินใจออกแบบแบบนี้จริงหรือไม่
การที่เมื่อเปิดไซต์กู้คืนภัยพิบัติแล้ว API call ที่เคยล้มเหลวหลั่งไหลเข้ามาจนบริการรับไม่ไหว ในที่สุดก็เพราะการออกแบบหลักของ Cloudflare ไม่ได้มีการทำซ้ำซ้อนเพียงพอ
ผิดหวังกับบทความนี้ที่พยายามโยนความรับผิดชอบไปให้ Flexential ในมุมลูกค้า แม้พรุ่งนี้ Flexential จะหายไปเพราะแผ่นดินไหว ก็ยังคาดหวังว่า Cloudflare จะจัดการได้อย่างสง่างาม
การเอาคลัสเตอร์สำคัญขนาดนี้ทั้งหมดไปไว้ใน พื้นที่เสี่ยงแผ่นดินไหวและสึนามิ ที่รู้กันอยู่แล้ว เป็นความคิดที่ดีหรือ?
ดูเหมือนการกู้คืนภัยพิบัติในยุโรปก็ทำงานไม่ถูกต้องด้วย
ประโยคที่ว่า “เราไม่เคยทดสอบการทำให้สถานที่ PDX-04 ทั้งหมดออฟไลน์โดยสมบูรณ์” เป็นบทเรียนที่เจ็บปวด
แต่ถ้าไม่ปิดไฟดาต้าเซ็นเตอร์ทางกายภาพ หรืออย่างน้อยตัดเครือข่ายจากโลกภายนอก ก็ยังไม่ได้ทดสอบภัยพิบัติจริง
จะโทษผู้ดำเนินงานสถานที่ก็ได้ แต่ท้ายที่สุดต้องสามารถกู้คืนได้แม้ดาต้าเซ็นเตอร์หนึ่งแห่งจะออฟไลน์โดยสมบูรณ์และไม่มีวันกลับมา
ภัยธรรมชาติอาจลบสถานที่นั้นออกจากโลกไปเลยก็ได้
ชอบส่วนที่ว่า “เพราะทีมถูกระดมทั้งหมดและรับมือเหตุฉุกเฉินมาตลอดทั้งวัน เราจึงตัดสินใจให้คนส่วนใหญ่พัก แล้วเริ่มงานย้ายกลับไป PDX-04 ในตอนเช้า การตัดสินใจนี้ทำให้การกู้คืนเต็มรูปแบบล่าช้า แต่เราเชื่อว่ามันลดโอกาสที่จะซ้อนทับความผิดพลาดเพิ่มเติม”
ในรายงานแบบนี้ ความเหนื่อยล้าของคน มักถูกประเมินต่ำไป การพยายามแก้เหตุขัดข้องครั้งใหญ่ตอนเหนื่อยเกินไปมีแต่จะเพิ่มข้อผิดพลาดที่หลีกเลี่ยงได้
ไม่รู้ว่าในองค์กรระดับ Cloudflare จะทำงานอย่างไร แต่พวกเราก็มีแผนให้พนักงานผลัดกันทำงานและนอนเมื่อเกิดเหตุขัดข้องใหญ่
ปัญหาคือต้องมีวิธีส่งต่อสถานะปัจจุบันของเหตุขัดข้องให้คนชุดใหม่ที่ตื่นขึ้นมาหรือเข้าระบบ
อย่างที่ Mike Tyson พูด ทุกคนมีแผนจนกว่าจะโดนต่อยเข้าหน้า
โครงสร้างบทความค่อนข้างน่าประหลาดใจ ใช้ 75% ของบล็อกพูดถึงบุคคลที่สาม แล้วพูดถึงความพยายามกู้คืนของ Cloudflare เองในย่อหน้าที่น้อยกว่ามาก
การนำเสนอเส้นทางต่อไปเป็นเรื่องบวก แต่สงสัยว่าทำไมตอนนี้ถึงไม่แค่ยอมรับความล้มเหลวและสถานการณ์ แล้วค่อยออก การวิเคราะห์หลังเหตุการณ์ ฉบับเต็มที่ไม่มีการคาดเดาหลังฝุ่นจางลง
นักลงทุนอาจอ่านบทความนี้หรือสรุปแล้วมองข้ามว่าเป็นแค่ ปัญหาผู้ให้บริการ มากกว่าจะเป็นปัญหาลึกที่ต้องแก้งานใหม่หลายเดือนและใช้เงินหลายล้านดอลลาร์
เอกสารไม่ค่อยดี
มีการตั้งค่าความพร้อมใช้งานสูงที่ประกอบด้วยดาต้าเซ็นเตอร์ 3 แห่ง แต่ล้มเหลวอย่างสมบูรณ์
ทำไมส่วนต้นของเอกสารถึงเต็มไปด้วยการโทษผู้ดำเนินงานดาต้าเซ็นเตอร์? การบริหารจัดการสถานที่ดาต้าเซ็นเตอร์อยู่นอกการควบคุมของ Cloudflare
Cloudflare เดิมพันว่าจะไม่มีปัญหา แม้ไม่ได้ทดสอบ การตั้งค่าความพร้อมใช้งานสูง ที่อยู่ภายใต้การควบคุมของตนอย่างเหมาะสม
ปัญหาการดำเนินงานดาต้าเซ็นเตอร์ควรนำไปหารือกับผู้ดำเนินงาน แต่นั่นเป็นเรื่องระหว่างสองฝ่าย ไม่ใช่เนื้อหาที่ควรอยู่ในการวิเคราะห์หลังเหตุการณ์นี้
ซ่อนประเด็นสำคัญไว้ลึกจริง ๆ ต้องเลื่อนลงไปพักใหญ่ถึงจะเจอประโยคแบบนี้
“บริการบางส่วนที่ควรอยู่ในคลัสเตอร์แบบความพร้อมใช้งานสูง กลับพึ่งพาบริการที่รันอยู่เฉพาะที่ PDX-04 เท่านั้น”
นี่แหละคือแก่นของเรื่อง
ถ้าจะสร้างไซต์ “กู้คืนจากภัยพิบัติ” ก็คงต้องหาวิธีทดสอบให้ได้ไม่ทางใดก็ทางหนึ่ง
เขาบอกว่าเมื่อบริการกลับมาเปิด ก็เกิด ปัญหาฝูงฟ้าร้อง ที่ API call ซึ่งเคยล้มเหลวถาโถมเข้ามา และจึง implement rate limiting เพื่อควบคุมปริมาณคำขอ
แต่ดูเหมือนเนื้อหานี้จะหายไปจากรายการท้ายบทความ
ตอนนี้สิ่งที่สงสัยคือ เมื่อระบบซับซ้อนถึงขั้นก่อให้เกิดความล้มเหลวแบบ metastable[1] และไม่มี余裕พอจะทดสอบด้วยทราฟฟิกจริง จะออกแบบ cold failover อย่างไร
พอเดาเทคนิคที่จะใช้ในการ implement ได้ แต่ปัญหาคือการออกแบบและทดสอบเพื่อยืนยันว่าเทคนิคนั้นจะทำงานได้จริงในสถานการณ์จริง
อีกจุดหนึ่งที่เหมือนจะหายไปโดยสิ้นเชิงคือ เหตุขัดข้องเริ่มเมื่อวันที่ 2 พฤศจิกายน เวลา 11:43 UTC แต่จุดที่ตัดสินใจสลับไปยังไซต์กู้คืนจากภัยพิบัติในยุโรปคือเวลา 13:40 UTC
ทำไมการตัดสินใจถึงใช้เวลานานขนาดนั้น? เข้าใจว่าไม่ใช่การตัดสินใจที่ทำได้เบา ๆ แต่แม้จะคาดหวังว่าไฟฟ้าจะกลับมาในไม่ช้าอยู่เกือบตลอดเวลา 2 ชั่วโมงก็ดูเหมือนลังเลนานเกินไป
ไม่ว่าจะมีคำมั่นใด ๆ ก็ตาม ควรมีเกณฑ์ล่วงหน้าว่าถึงจุดไหนต้องกดสวิตช์ เกณฑ์นั้นถูกตั้งไว้ไกลขนาดนั้นจริงหรือ?
[1] http://charap.co/metastable-failures-in-distributed-systems/
สิ่งที่ทำให้ล้มเหลวมักเป็น ระบบสำรองซ้ำซ้อน เอง