ภาพในหัว: สะพานไม้ไผ่ 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

MTBF + MTTR: ตัวเลขที่ขับ resilience design#

ก่อนข้ามไปเรื่อง telecom ขอ flag 2 metric ที่ exam ออก:

• MTBF (Mean Time Between Failures) — เวลาเฉลี่ยที่ component ทำงานก่อน fail (ยิ่งสูง = ยิ่งทน)
• MTTR (Mean Time To Repair) — เวลาเฉลี่ยในการแก้หลัง fail (ยิ่งต่ำ = ยิ่งกู้เร็ว)

Availability ของระบบคำนวณจาก 2 ตัวนี้:

Availability = MTBF / (MTBF + MTTR)

ตัวอย่าง: server ที่ MTBF = 1000 ชั่วโมง, MTTR = 4 ชั่วโมง → availability = 1000 / 1004 ≈ 99.6%

ถ้าต้องการ 99.9% — ต้องเพิ่ม MTBF (hardware ที่ทนกว่า) หรือ ลด MTTR (recovery ที่เร็วกว่า เช่น hot spare)

มุม IS auditor: ระบบที่ claim availability 99.99% แต่ MTTR สูง = สมการไม่ลง challenge ทันที

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

Backup Rotation Schemes — เก็บกี่ generation#

backup ที่ทำทุกวันจะกินที่เก็บมหาศาล ต้องมี rotation scheme ที่บอกว่าเก็บอันไหน ทับอันไหน

CRM 4.14 อธิบาย 3 scheme หลักที่ exam ออก:

Trap pattern ของ rotation scheme#

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

ตัวอย่างจริง: โรงงานบางปูเก็บ 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