ออกแบบมาให้ทำงานต่อไปได้แม้มีบางสิ่งล้มเหลว

สิ่งที่ออกแบบมาเพื่อรองรับ

การหยุดทำงานของคลาวด์ระดับ Hyperscale

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

ภัยพิบัติระดับภูมิภาคและเหตุการณ์ความรุนแรง

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

การหยุดทำงานของผู้ให้บริการ DNS

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

การหยุดทำงานของ Certificate Authority

หากไม่สามารถเข้าถึง Certificate Authority เมื่อถึงเวลาต่ออายุใบรับรอง TLS ของคุณจะหยุดทำงาน หาก Certificate Authority ถูกโจมตี ใบรับรองทุกฉบับที่ออกให้จะกลายเป็นโมฆะ เราได้พิจารณาถึงสิ่งที่เกิดขึ้นกับ TLS เมื่อโครงสร้างพื้นฐานของ CA ทำงานผิดปกติ

ปัญหาของผู้รับจดทะเบียนโดเมน

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

ปัญหาของผู้ให้บริการ TLD

องค์กรที่ดูแลโดเมนระดับบนสุด (.com, .ai, .io) ถือเป็น Single Point of Failure ในตัวมันเอง TLD ขนาดเล็กจะถูกดูแลโดยองค์กรขนาดเล็กที่มีทรัพยากรในการดำเนินงานน้อยกว่า เราได้พิจารณาถึงสิ่งที่เกิดขึ้นหากผู้ให้บริการ TLD ประสบปัญหาหนัก

การหยุดทำงานของผู้ให้บริการอีเมล

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

การพึ่งพา SMS / หมายเลขโทรศัพท์

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

การหยุดทำงานของ Operational Control-Plane

เครื่องมือที่เราใช้จัดการโครงสร้างพื้นฐานของเราเองก็อาจหยุดทำงานได้เช่นกัน: Orchestration Mesh, Coordination Layer และ Deployment Pipeline แต่ละส่วนล้วนเกี่ยวข้องกับผู้ให้บริการที่อาจประสบปัญหาได้ เราได้พิจารณาถึงผลกระทบของแต่ละส่วนและค่อยๆ ลดการพึ่งพา Control-Plane ที่จัดการโดยผู้ให้บริการลงอย่างต่อเนื่อง

ข้อบกพร่องของซอฟต์แวร์

สาเหตุที่มีแนวโน้มมากที่สุดของการหยุดทำงานพร้อมกันทุกส่วนคือข้อบกพร่องในซอฟต์แวร์ของเราเองที่ถูกปรับใช้ในทุกที่พร้อมกัน การกระจายตัวทางภูมิศาสตร์ไม่อาจช่วยอะไรได้หากทุกอินสแตนซ์ที่ทำงานอยู่เกิดขัดข้องในลักษณะเดียวกัน เราได้พิจารณาเรื่องนี้และออกแบบแนวทางการปรับใช้ของเรา — เช่น Canary Rollouts, Fast Rollback และ Kill Switches — ให้รองรับสถานการณ์ดังกล่าว

การดำเนินการของผู้ให้บริการระดับบัญชี

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

ความล้มเหลวที่เกิดขึ้นพร้อมกัน

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

การพึ่งพาข้อมูลส่วนบุคคลที่เสี่ยงต่อความเสียหายร้ายแรง

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

การติดต่อทีมปฏิบัติการ

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

แนวโน้มการเข้ารหัสในอนาคต

การเข้ารหัสไม่ได้หยุดนิ่ง เราได้พิจารณาเส้นทางการย้ายระบบในระยะยาวสำหรับทุก Cryptographic Primitive ที่เราพึ่งพา รวมถึง Post-Quantum

สิ่งที่เราไม่ได้รับประกันว่าจะป้องกันได้

เราชี้แจงอย่างชัดเจนเกี่ยวกับขีดจำกัดของสิ่งที่วิศวกรรมโครงสร้างพื้นฐานสามารถทำได้

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