ภาพในหัว: สะพานไม้ไผ่ vs สะพานเหล็กแข็ง#

สะพานเหล็กที่แข็งมาก — ดีตอนปกติ แต่เวลาน้ำท่วมแรงๆ จะหัก เพราะไม่ยืดหยุ่น

สะพานไม้ไผ่ที่ engineering ดี — โน้มไปตามกระแสน้ำ ทนแรงกระแทกได้ดี

resilience = ความสามารถที่จะ absorb แรงกระแทก ไม่ใช่ความสามารถที่จะป้องกันการกระแทก

Clustering: หัวใจของ resilience#

application ที่รันบน server เดียว = single point of failure ตอน server fail = application ล่ม

clustering = รัน application กระจายบน multiple node ถ้า node ใดล้ม node อื่นรับช่วงต่อ

มี 2 model หลัก ที่ exam ออกซ้ำๆ:

Active-Active#

ทุก node ทำงานพร้อมกัน — load share

ตัวอย่างในชีวิตจริง: ด่านเก็บเงินทางด่วนที่เปิดทุกช่อง — ถ้าช่องใดเสีย ช่องอื่นยังเปิด

ข้อดี:

• ใช้ resource เต็ม — ไม่มี node idle
• failover เร็วที่สุด — เพราะ node อื่นทำงานอยู่แล้ว

ข้อเสีย:

• application ต้อง design ให้ tolerate concurrent processing
• complexity ในการ sync state ระหว่าง node สูง

ใช้กับ: web server (stateless), load balancer, API gateway

Active-Passive#

มี active node ที่ทำงาน + passive node ที่ standby ถ้า active ล้ม passive จะ takeover

ตัวอย่างในชีวิตจริง: นักบินกับนักบินรอง — ปกตินักบินทำงาน ถ้านักบินไม่สบาย นักบินรองรับช่วง

ข้อดี:

• application ที่ไม่ tolerate concurrent ก็ใช้ได้
• ราคาถูกกว่า active-active

ข้อเสีย:

• passive node = idle ไม่ได้ใช้ resource
• failover ช้ากว่า — มี delay ระหว่าง detect failure → takeover

ใช้กับ: database (state-heavy), legacy application

กรณีจริง: ICU monitoring ที่ขาด clustering#

โรงพยาบาลกรุงเทพแห่งหนึ่ง — ICU monitoring system รันบน server เดียว

วันที่ apply OS patch โดยไม่ test — application crash

พยาบาลต้อง monitor ผู้ป่วยด้วยมือ 45 นาที ระหว่าง IT restore จาก backup

แต่ — BIA ระบุว่า ICU monitoring มี RTO = 5 นาที

ระยะเวลาจริง = 45 นาที = ไม่ผ่าน RTO

control gap: resilience design (no clustering) ไม่ตอบ RTO requirement ที่ BIA กำหนด

นี่คือ pattern ที่ exam ออกบ่อย — BIA กำหนด RTO อย่างหนึ่ง แต่ resilience architecture ไม่ achievable

Telecom Resilience#

ที่หลายองค์กรลืม — resilience ของ network/internet connection

มี data center ดีแค่ไหน ถ้า internet ขาด ก็เหมือน data center ปิด

ตัวอย่างจริง: e-commerce ที่กรุงเทพ ใช้ ISP เจ้าเดียว — fiber cable ในกรุงเทพถูกตัด → website inaccessible 4 ชั่วโมง

ทางออก:

• 2 ISP จาก carrier คนละราย
• diverse routing — fiber 2 เส้นที่ไม่อยู่ในท่อเดียวกัน
• last-mile protection — connection 2 เส้นที่เข้าอาคารคนละทาง

cost ของ second connection อาจเป็นแค่ 8,000-15,000 บาท/เดือน — เทียบกับ 4 ชั่วโมง outage ตอน flash sale → ROI ชัดเจน

Metro cluster: protect site แต่ไม่ protect region#

clustering 2 site ในเขตเมืองเดียวกัน (เช่น 2 data center ในกรุงเทพ — สีลม + บางนา) = metro cluster

protect ได้: server fail, อาคารหนึ่งไฟดับ, fire ใน data center หนึ่ง

protectไม่ได้: เหตุการณ์ที่กระทบทั้งกรุงเทพ — flood ใหญ่ (เหมือนปี 2554), เหตุการณ์ทางการเมืองที่กระทบทั้งเมือง, blackout ทั้งภูมิภาค

ถ้าต้องการ region-level protection → ต้อง geographically diverse (กรุงเทพ + เชียงใหม่ + Singapore เป็นต้น)

Trap ของ exam เรื่อง resilience#

Backup เป็น safety net ไม่ใช่ first line#

หลายองค์กรเข้าใจผิด — “เรามี backup = เราพร้อม”

ไม่ใช่ครับ — backup คือ last resort เมื่อ resilience ไม่พอ

ถ้า application clusters ทำงาน — recovery ใช้แค่ failover (วินาที) ถ้า application clusters fail — recovery ใช้ backup restoration (ชั่วโมง)

backup ที่ดี = “ถ้าโลกจบจริงๆ — ข้อมูลกลับมาได้”

Types of backup ที่ต้องรู้#

ในมุม exam — incremental ใช้ resource น้อย แต่ restoration ซับซ้อนกว่า differential

Replication: real-time backup#

สำหรับระบบ critical — ใช้ replication (real-time copy) ไม่ใช่ scheduled backup

trade-off: synchronous = RPO เล็กที่สุด แต่ performance overhead (primary ต้องรอ secondary confirm)

Storage media: ไม่ทุกอันเหมาะกัน#

CRM list หลายแบบ ผมขอ summary:

• Tape — ราคาถูกที่สุด แต่ restore ช้า — เหมาะกับ long-term archive
• Disk — เร็วกว่า tape — เหมาะกับ frequent restore
• VTL (Virtual Tape Library) — disk ที่ทำตัวเหมือน tape — combo speed + management
• Cloud — offsite by default แต่ต้อง manage egress cost + latency

ที่หลายคนพลาด — fireproof cabinet สำหรับเอกสารกระดาษ ≠ fireproof สำหรับ tape

magnetic media ทนความร้อนได้น้อยกว่ากระดาษมาก ตู้เก็บเอกสารที่ rated 1000°F ในเวลา 1 ชั่วโมง อาจไม่ปลอดภัยสำหรับ tape

ตัวอย่างจริง: โรงงาน Bangpoo เก็บ tape ใน fireproof cabinet ในห้อง server ตอนเกิดไฟไหม้ — cabinet ทน แต่ tape เสีย เพราะ rating ของ cabinet เป็นสำหรับเอกสาร

Offsite storage = เป็น must#

ถ้า backup เก็บที่เดียวกับ production → site disaster = ทั้งคู่หาย

offsite ต้อง:

• Geographically separate — ไม่อยู่ในระยะ disaster เดียวกัน
• Same security level — physical + logical security เท่า production
• Tested transportation chain — ใครย้าย tape อย่างไร, chain of custody มั้ย

Cloud backup = offsite by default? — ไม่เสมอ#

ความเข้าใจผิดที่บ่อย: “ใช้ cloud backup = offsite แล้ว”

ไม่จำเป็น — cloud provider อาจมี data center ในเมืองเดียวกัน หรือใน region เดียวกันที่กระทบจาก disaster เดียวกัน

ต้องตรวจ:

• Region ของ cloud backup ห่างจาก production
• Data residency requirement ตาม PDPA ของไทย

Ransomware: ภัยใหม่ของ backup#

ransomware รุ่นใหม่ — design มาเพื่อ encrypt backup ก่อน production เพราะรู้ว่า backup คือทางรอด

ถ้า backup sync แบบ real-time → ransomware encrypt production → sync ไป backup → backup ก็ถูก encrypt

ทางป้องกัน:

• Immutable backup — backup ที่ล็อกไม่ให้ overwrite/delete (WORM — Write Once, Read Many)
• Air-gapped backup — backup ที่ disconnect จาก network จริงๆ (ใช้ tape, ใช้ cloud ที่มี cooldown period)
• Multiple version retention — เก็บ backup หลาย version (รายวัน 30 วัน + รายสัปดาห์ 12 สัปดาห์ + รายเดือน 12 เดือน)

ตัวอย่างจริง: hospital ที่ใช้ cloud backup แบบ sync — ransomware encrypt production แล้ว sync overwrite clean backup ใน 3 วัน

ต้องไป recovery จาก backup ที่ 4 วันก่อน — เสีย patient record 4 วัน

control gap: cloud backup ไม่ได้ configure ให้ immutable

Backup ≠ Restoration — เรื่องที่ exam ออกแน่ๆ#

ที่ผมขอย้ำ — backup ที่ไม่เคย test restore ไม่ใช่ control

backup ทำสำเร็จ = ข้อมูลถูก copy restoration test = พิสูจน์ว่า copy นั้นใช้ได้จริง

ทั้ง 2 ไม่เหมือนกัน

ตัวอย่างจริง: convenience store chain — backup รายวัน 3 ปี ตอน disk fail → restore ไม่ได้ เพราะ backup format ไม่ compatible กับ database version ใหม่ (database upgrade ไป 8 เดือนก่อน) restoration ไม่เคย retest

ต้อง test restoration:

1. เป็นประจำ — ตามรอบที่กำหนด (รายไตรมาส / รายปี)
2. Full restoration — ไม่ใช่แค่ partial spot check
3. Time the restoration — เทียบกับ RTO ที่ BIA กำหนด
4. หลังการเปลี่ยนแปลง — version upgrade, migration, infrastructure change → ต้อง retest

Trap ของ exam เรื่อง backup#

Resilience คุม availability — Backup คุม data integrity#

ถ้าเกิด — server fail แต่ data ยังอยู่:

• มี cluster → ทำงานต่อทันที
• ไม่มี cluster → restore จาก same data แต่ใช้เวลา

ถ้าเกิด — data corruption / loss:

• มี backup → restore data ก่อน → ระบบกลับมา
• ไม่มี backup → ข้อมูลหายตลอดกาล

ดังนั้น — resilience ไม่ได้ทดแทน backup และ backup ไม่ได้ทดแทน resilience

ทั้งคู่ตอบคำถามคนละคำถาม

ทั้ง 2 layer ต้อง align กับ BIA#

resilience architecture → ตอบ RTO backup frequency → ตอบ RPO

ทั้ง 2 ตัวเลขมาจาก BIA

ถ้า BIA บอกว่า RPO = 1 ชั่วโมง — backup รายวันไม่พอ ต้อง replication ถ้า BIA บอกว่า RTO = 30 นาที — manual restore จาก tape ไม่ทัน ต้อง hot standby