---
title: "ความทนทานต่อความล้มเหลว"
description: "สิ่งที่ออกแบบมาเพื่อรองรับในแต่ละเลเยอร์ ภัยคุกคามที่เราพิจารณา ข้อจำกัดที่เรายอมรับ และวิธีติดต่อเราเพื่อหารือในรายละเอียดส่วนที่เหลือภายใต้ข้อตกลงการรักษาความลับ"
lang: th
url: https://clavitor.ai/th/resilience
markdown: https://clavitor.ai/th/resilience.md
translation_of: https://clavitor.ai/en/resilience.md
authoritative: false
publisher: Clavitor LLC
---

> This is the Thai translation of [Resilience](https://clavitor.ai/en/resilience.md). The original English text is authoritative; where the two differ, the English version prevails.

# โครงสร้างพื้นฐาน: ออกแบบมาให้ทำงานต่อไปได้แม้มีบางสิ่งล้มเหลว

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

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

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

### การหยุดทำงานของคลาวด์ระดับ 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

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

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

### เหตุการณ์พายุสุริยะระดับ Carrington

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

### การดำเนินการระดับรัฐที่ประสานงานกันข้ามเขตอำนาจศาลเพื่อต่อต้าน Clavitor โดยตรง

เหตุการณ์ประเภทที่ไม่มีโครงสร้างพื้นฐานเชิงพาณิชย์ใดสามารถป้องกันได้เพียงฝ่ายเดียว

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

## รายละเอียดสถาปัตยกรรมภายใต้ข้อตกลงการรักษาความลับ

รายการด้านบนคือ *สิ่งที่เราพิจารณา* รายละเอียดของ *วิธีการออกแบบระบบป้องกันแต่ละส่วน* — โทโพโลยีที่เฉพาะเจาะจง การเลือกผู้ให้บริการ ขั้นตอนการสลับระบบ และโปรโตคอลการเข้ารหัส — จะถูกแชร์ให้กับลูกค้าระดับ Enterprise ภายใต้ข้อตกลงการรักษาความลับ ร่วมกับทีมรักษาความปลอดภัยของพวกเขาในกระบวนการจัดซื้อ
[ติดต่อเรา](mailto:security@clavitor.ai)
[ติดต่อฝ่ายขาย →](https://clavitor.ai/th/contact-sales)