ไฟดับในวันที่ 29 เมษายน: เกิดอะไรขึ้น เหตุใดจึงเกิดขึ้น และเราจะตอบสนองอย่างไร

ทำความเข้าใจสถาปัตยกรรมบริการของแพลตฟอร์ม Braze

Braze ดูแลรักษาชุดเซิร์ฟเวอร์แยกกันสำหรับแต่ละคลัสเตอร์ US ทั้งแปดคลัสเตอร์ของเรา คลัสเตอร์ Braze US 01 ถึง 07 โฮสต์บน Amazon Web Services (AWS) ในขณะที่คลัสเตอร์ Braze US 08 โฮสต์บน Microsoft Azure ในแต่ละสภาพแวดล้อมเหล่านี้ Braze ใช้ Availability Zone หลายแห่งและมีความซ้ำซ้อนสำหรับแต่ละส่วนของระบบของเรา ในกรณีที่โซนความพร้อมใช้งานล้มเหลว เราจะปิดใช้งานโซนความพร้อมใช้งานที่บกพร่องจากการกำหนดเส้นทางและการประมวลผลเป็นประจำและโปร่งใส นั่นทำให้เราสามารถรักษาความสามารถในการส่งมอบบริการได้อย่างน่าเชื่อถือในระหว่างที่ผู้ให้บริการระบบคลาวด์หยุดทำงาน

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

เนื่องจากปริมาณงานการประมวลผลแบบเรียลไทม์ของแพลตฟอร์ม Braze เข้มข้น ตั้งแต่ปี 2013 เราได้เสริมการใช้งาน AWS และ Azure โดยการร่วมมือกับ Rackspace เพื่อโฮสต์ฮาร์ดแวร์ที่กำหนดค่าแบบกำหนดเองเพื่อรันฐานข้อมูล MongoDB สภาพแวดล้อม AWS และ Azure ของเราได้รับการกำหนดค่าด้วยตัวเชื่อมต่อคลาวด์ส่วนตัว AWS Direct Connect และ Azure ExpressRoute ซึ่งเชื่อมโยงสภาพแวดล้อมคลาวด์กับเครือข่ายภายในของเราที่ดูแลรักษาในศูนย์ข้อมูล Rackspace ผ่านสายเคเบิลไฟเบอร์ออปติกเฉพาะ การเชื่อมต่อที่เข้ารหัสนี้ ซึ่งขับเคลื่อนโดยลิงก์เครือข่ายที่รองรับหลายอินเทอร์เฟซที่ผลักดันการรับส่งข้อมูลเครือข่ายมากกว่า 100 กิกะบิตต่อวินาที ให้การเข้าถึงที่มีประสิทธิภาพสูงระหว่างระบบคลาวด์ของเราและสภาพแวดล้อม Rackspace

สภาพแวดล้อมแบบกำหนดเองของเราใน Rackspace เป็นที่ตั้งของเซิร์ฟเวอร์กายภาพหลายร้อยตัวที่เก็บไว้ในตู้สำหรับ Braze โดยเฉพาะ การตั้งค่านี้ประกอบด้วยแหล่งจ่ายไฟสำรองและสวิตช์ด้านบนสุดสำรอง สวิตช์แบบท็อปออฟแร็คคืออุปกรณ์เครือข่ายที่อยู่ในชั้นวางเซิร์ฟเวอร์และเชื่อมต่ออุปกรณ์และเซิร์ฟเวอร์เข้าด้วยกันในชั้นวางเซิร์ฟเวอร์เดียวกัน สวิตช์เหล่านี้ได้รับการทดสอบอย่างน้อยปีละครั้งสำหรับการเฟลโอเวอร์โดยไม่มีผลกระทบ การทดสอบปีที่แล้วประสบความสำเร็จในวันที่ 3 สิงหาคม 2023 ในสภาพแวดล้อมที่กำหนดเองนี้ เราดูแลรักษาคอนเทนเนอร์เสมือนจริงนับหมื่นรายการสำหรับฐานข้อมูล MongoDB เช่นเดียวกับสภาพแวดล้อมคลาวด์ของเรา เรารักษาการแยกทางกายภาพในระดับสูงระหว่างคอนเทนเนอร์บนคลัสเตอร์สหรัฐอเมริกาที่แตกต่างกัน เพื่อลดการหยุดชะงักและลดความเสี่ยงที่คอนเทนเนอร์หนึ่งอาจส่งผลกระทบต่อคอนเทนเนอร์อื่นภายในฐานข้อมูลของเรา

สาเหตุของการหยุดทำงานในวันที่ 29 เมษายน และวิธีที่เราตอบสนอง

สวิตช์บางส่วนเริ่มต้นล้มเหลว

ในวันที่ 29 เมษายน เวลา 09:15 UTC เกิดข้อผิดพลาดบางส่วนของสวิตช์เครือข่าย Cisco Nexus หลักที่เชื่อมต่อกับตู้เซิร์ฟเวอร์ Rackspace ของเรา สวิตช์ที่ชำรุดล้มเหลวในลักษณะที่ไม่ได้เปิดใช้งานสวิตช์เครือข่ายรองโดยอัตโนมัติผ่านการเฟลโอเวอร์ และเก็บสวิตช์ที่ชำรุดไว้เป็นสวิตช์หลักแทน

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

ในเครือข่ายขนาดใหญ่ มักจะมีเส้นทางมากกว่าหนึ่งเส้นทางระหว่างอุปกรณ์ ซึ่งอาจทำให้เกิดการ "วนซ้ำ" ของเส้นทาง (กล่าวคือ เงื่อนไขที่แพ็กเก็ตไม่สามารถหยุดที่ปลายทางที่ต้องการ และวนกลับไปยังจุดกำเนิดแทน) ลูปสามารถสร้าง "พายุกระจายเสียง" ซึ่งการรับส่งข้อมูลสิ้นสุดลงแบบวนซ้ำอย่างไม่มีกำหนด ลิงก์เครือข่ายอิ่มตัวและทำให้เกิดการหยุดทำงาน เพื่อป้องกันไม่ให้สิ่งนี้เกิดขึ้น สวิตช์จะถูกตั้งโปรแกรมให้ส่งข้อความที่ช่วยระบุลิงก์ที่ซ้ำซ้อน ข้อความเหล่านั้นเรียกว่า Spanning Tree Bridge Protocol Data Unit (BPDU) และเป็นส่วนหนึ่งของโปรโตคอลเครือข่ายที่เรียกว่า Spanning Tree Protocol (STP) สวิตช์จะใช้ข้อมูลนี้เพื่อบล็อกพอร์ตการรับส่งข้อมูลเพื่อป้องกันไม่ให้เกิดการวนซ้ำเมื่อกำหนดเส้นทางการรับส่งข้อมูล หากลิงก์หรือสวิตช์ทางกายภาพล้มเหลว STP จะช่วยเพิ่มความซ้ำซ้อน เนื่องจากสามารถใช้เพื่อระบุลิงก์ทางกายภาพอื่นๆ ที่สามารถส่งทราฟฟิกได้ และเลื่อนระดับลิงก์แบบพาสซีฟก่อนหน้านี้ (เช่น ที่ถูกบล็อก) ให้ใช้งานได้เพื่อรักษาการเชื่อมต่อไว้

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

การแก้ไข Rackspace

จากกิจกรรมนี้ วิศวกรศูนย์ข้อมูลของ Rackspace ได้รับการแจ้งเตือนเวลาประมาณ 09:20 UTC เกี่ยวกับปัญหาการเชื่อมต่อเครือข่ายที่ไม่คาดคิด และเริ่มแก้ไขปัญหา ระหว่างเวลา 09:39 ถึง 10:03 UTC วิศวกรศูนย์ข้อมูลของ Rackspace ระงับสวิตช์เครือข่าย จ่ายไฟให้กับสวิตช์หลัก และบังคับให้การ์ดอินเทอร์เฟซเครือข่าย (NIC) ในตู้เซิร์ฟเวอร์ทำการเฟลโอเวอร์ไปยังสวิตช์รอง หลังจากเกิดข้อผิดพลาด NIC การเชื่อมต่อจะถูกกู้คืนไปยังเซิร์ฟเวอร์จริงในสภาพแวดล้อม Braze

ฐานข้อมูล Braze MongoDB ทำงานอย่างไร

ฐานข้อมูล MongoDB ที่ Braze ใช้ช่วยให้สามารถจัดเก็บข้อมูลไว้ในเซิร์ฟเวอร์ฐานข้อมูลหลายตัวที่เรียกว่า "ชาร์ด" MongoDB ให้บริการกำหนดเส้นทางที่เรียกว่า "mongoS" ซึ่งประมวลผลการสืบค้นจากบริการของแพลตฟอร์ม Braze กำหนดตำแหน่งของข้อมูลที่เกี่ยวข้องในคลัสเตอร์ที่แบ่งส่วน จากนั้นกำหนดเส้นทางการสืบค้นไปยังฐานข้อมูล MongoDB ที่เหมาะสม Braze มีฐานข้อมูล MongoDB ที่แตกต่างกันหลายร้อยฐานข้อมูล ซึ่งประกอบด้วยกระบวนการ "mongoD" มากกว่า 15,000 กระบวนการ ซึ่งเป็นโปรแกรมที่รันฐานข้อมูลและจัดเก็บข้อมูลสำหรับชาร์ด MongoDB เฉพาะ

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

ผลกระทบของลูปเครือข่ายต่อกระบวนการ MongoDB ของเราและวิธีที่เราตอบสนอง

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

ณ จุดนี้ เพื่อช่วยเหลือทีมผู้ดูแลฐานข้อมูล Rackspace (DBA) ของเรา ทีม Braze DevOps ได้เริ่มแก้ไขจุดบกพร่องอย่างรวดเร็วและทดสอบวิธีการในการกู้คืนการเชื่อมต่อนั้น การตรวจสอบของเราระบุว่าตัวเลือกเดียวที่ใช้ได้คือการรีสตาร์ทกระบวนการ mongoD เกือบ 16,000 รายการและ mongoS เกือบ 16,000 รายการในคอนเทนเนอร์เสมือนจริง เมื่อพิจารณาถึงขนาดที่แท้จริงของการดำเนินการนี้และความจริงที่ว่าระบบอัตโนมัติไม่มีอยู่เพื่อรีสตาร์ทคอนเทนเนอร์จำนวนมากได้อย่างรวดเร็ว วิศวกรของ Rackspace จึงได้เขียนโค้ดใหม่ในระหว่างที่เกิดเหตุการณ์เพื่อสร้างความสามารถอัตโนมัติแบบทันทีทันใด

น่าเสียดายที่เมื่อกระบวนการรีสตาร์ทเพิ่มสูงขึ้น เกิดปัญหาอื่นในระบบชื่อโดเมน (DNS) เมื่อกระบวนการ mongoS และ mongoD ออนไลน์ พวกเขาขอข้อมูลจากตัวแก้ไข DNS ในกระบวนการที่เรียกว่าการค้นหา DNS ด้วยการค้นหา DNS อย่างต่อเนื่องซึ่งขับเคลื่อนโดยความเร็วของการรีสตาร์ท เซิร์ฟเวอร์ DNS จึงมีภาระงานหนัก ส่งผลให้การเชื่อมต่อหมดเวลาบนเลเยอร์ mongoS เมื่อพวกเขาเชื่อมต่อกับกระบวนการ mongoD อีกครั้ง เพื่อรองรับปริมาณงานที่เพิ่มขึ้นนี้ ทีม Rackspace ของเราได้เพิ่มความจุ DNS CPU แต่จากนั้นก็ถูกบังคับให้รีสตาร์ทระดับ mongoS เป็นครั้งที่สองเพื่อสร้างการเชื่อมต่อที่ดีจากแต่ละ mongoS ไปยังกระบวนการ mongoD ที่เกี่ยวข้อง

ประมาณ 17:05 UTC กระบวนการรีสตาร์ททำให้บางคลัสเตอร์เริ่มกลับมาออนไลน์อีกครั้ง เมื่อประสิทธิภาพของฐานข้อมูลฟื้นตัวและคลัสเตอร์มีเสถียรภาพ Braze ยังคงเพิ่มการประมวลผลข้อมูลและความสามารถในการส่งข้อความอย่างต่อเนื่อง อย่างไรก็ตาม ความพยายามดังกล่าวมีความซับซ้อนเนื่องจากมีงานในมือจำนวนมากซึ่งเป็นผลมาจากการไม่พร้อมใช้งานก่อนหน้านี้

เมื่อพิจารณาจากขนาดและความซับซ้อนของสภาพแวดล้อมฐานข้อมูล Rackspace ของเรา ซึ่งประกอบด้วยฐานข้อมูลที่แตกต่างกันหลายร้อยฐานข้อมูล ระยะเวลาของการหยุดทำงาน และปริมาณผลลัพธ์ของ Backlog ของเรา (ซึ่งแสดงถึงข้อความนับพันล้านข้อความและจุดข้อมูลที่นำเข้านับพันล้านจุด) กระบวนการกู้คืนที่จำเป็นใน - การปรับตัวของกระบวนการฟื้นฟูตามปกติของเราในขณะนั้น นี่เป็นสิ่งจำเป็นเพื่อให้แน่ใจว่าทรัพยากรฐานข้อมูลยังคงสมดุลกับความต้องการในการประมวลผลที่กำลังดำเนินอยู่ รวมถึงการแนะนำความสามารถในการประมวลผลโดยรวมจำนวนมหาศาล

อย่างไรก็ตาม ในการทำเช่นนั้น Braze ถึงขีดจำกัด AWS ในด้านจำนวน CPU เสมือนที่เราสามารถจัดเตรียมได้ ซึ่งทำให้เราไม่สามารถเพิ่มความจุของเซิร์ฟเวอร์เพิ่มเติมได้ ทีม Braze ยกระดับสถานการณ์นี้อย่างรวดเร็วด้วยทีม AWS ของเราและได้รับการเพิ่มขึ้น ทำให้วิศวกรของเราสามารถขยายความสามารถในการประมวลผลเซิร์ฟเวอร์ของเราให้อยู่ในระดับสูงสุดเป็นประวัติการณ์ ซึ่งสูงกว่าความจุสูงสุดก่อนหน้าของเราถึง 50% ซึ่งเคยทำได้บน Black วันศุกร์ 2023.

ภายในเวลา 20:30 UTC คลัสเตอร์ US ทั้งหมดของเรา ยกเว้น US 01, US 03 และ US 08 ได้เสร็จสิ้นการประมวลผล Backlog แล้ว และคลัสเตอร์ที่เหลือเหล่านั้นได้รับการประมวลผลในอัตราสูงสุดหรือสูงกว่าจากวันก่อนเกิดเหตุการณ์ ภายในไม่กี่ชั่วโมง คลัสเตอร์ทั้งหมดจะถูกสำรองข้อมูลไปสู่การประมวลผลแบบเรียลไทม์ และเราประกาศว่าเหตุการณ์ได้รับการแก้ไขแล้ว

Braze สื่อสารข้อมูลอัปเดตระหว่างเกิดเหตุการณ์อย่างไร

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

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

ในระหว่างที่เกิดเหตุการณ์ เราใช้หน้าสถานะของเราเพื่อจัดการการสื่อสารและให้ข้อมูลอัปเดตเป็นประจำเกี่ยวกับสถานการณ์ ฉันขอแนะนำให้ลูกค้าสมัครรับข้อมูลอัปเดตจากหน้านั้นเพื่อติดตามข่าวสารให้ทัน ในช่วงการหยุดให้บริการในวันที่ 29 เมษายน เราได้เสริมการอัปเดตหน้าสถานะบ่อยครั้งเหล่านี้ด้วยอีเมลจาก Bill Magnuson ผู้ร่วมก่อตั้งและ CEO ของเรา ข้อความดังกล่าวถูกส่งไปยังผู้ใช้แดชบอร์ด Braze ทุกคน และมอบให้กับทีมบัญชีของเราเพื่อแบ่งปันกับผู้มีส่วนได้ส่วนเสียของลูกค้ารายอื่นตามความจำเป็น

Braze ติดตามเหตุการณ์และแผนการป้องกันในอนาคตอย่างไร

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

นับตั้งแต่เหตุการณ์ดังกล่าว Braze และ Rackspace ได้เปลี่ยนและเปลี่ยนสวิตช์ที่ชำรุด และทีมวิศวกรของ Rackspace ได้ทำการตรวจสอบโครงสร้างพื้นฐานเครือข่ายที่บริการของ Braze ใช้งานอย่างเต็มรูปแบบแล้ว แม้ว่าความล้มเหลวของฮาร์ดแวร์จะคาดการณ์ได้ยากอย่างไม่น่าเชื่อ โดยเฉพาะอย่างยิ่งกับอุปกรณ์ที่อยู่ในการรับประกัน การตรวจสอบก็มีไว้เพื่อตรวจจับความผิดปกติและเพื่อให้มั่นใจถึงการตอบสนองที่รวดเร็ว ทั้งสองทีมกำลังทำงานร่วมกันเพื่อทำการเปลี่ยนแปลงที่จะป้องกันการวนซ้ำของเครือข่ายในอนาคต แม้ว่าอุปกรณ์จะทำงานผิดปกติก็ตาม การเปลี่ยนแปลงเครือข่ายบางอย่างอาจต้องใช้เวลาในการดำเนินการ เนื่องจากเราวางแผนที่จะทำการเปลี่ยนแปลงที่สำคัญกับโทโพโลยีเครือข่ายของเรา เพื่อปรับปรุงการป้องกันลูปให้ดียิ่งขึ้น นอกจากนี้เรายังได้เปิดตั๋วสนับสนุนกับทั้ง Cisco และ MongoDB เพื่อทำความเข้าใจสถานการณ์ความล้มเหลวที่เราพบได้ดีขึ้น และเพื่อปรับปรุงความสามารถของกระบวนการ mongoD และ mongoS ในการรักษาตนเองภายหลังความล้มเหลวของเครือข่าย

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

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

— จอน