BCP = ทั้งองค์กร / DRP = เฉพาะ IT#

ความแตกต่างที่ exam ออกซ้ำๆ:

ความสัมพันธ์: DRP เป็น component หนึ่งของ BCP

ถ้าเขียน hierarchy:

1
BCP (ทั้งบริษัท)
2
├── DRP (IT recovery)
3
├── Crisis communication plan (สื่อสาร)
4
├── Supply chain continuity plan
5
├── HR continuity (relocate, work-from-home)
6
└── Facility recovery plan

Trap ที่ exam ออก — “BCP = IT’s job”#

ผิดเด็ดขาด — BCP คือ board / senior management responsibility

IT รับผิดชอบ DRP ที่เป็น component ของ BCP — แต่ BCP เป็นเรื่องของทั้งองค์กร

ถ้า org ไหน “BCP = IT department’s plan” → finding ทันที

ตัวอย่างจริง: น้ำท่วม 2554#

โรงงานในนิคมที่ปทุมธานี — มี BCP เก่า 3 ปี ที่ assume worst case = ไฟดับ 2 วัน

ตอน flood 2554 — โรงงานจม 6 สัปดาห์

BCP ที่มี — ไม่ใช่ผิดทั้งหมด แต่ไม่ครอบ scenario ที่เกิดจริง:

• ไม่มีแผน relocate พนักงาน
• ไม่มีแผน remote payroll
• ไม่มีแผนสื่อสารกับ supplier ระหว่าง 6 สัปดาห์
• ไม่มี procedure เคลม insurance
• ไม่มี contingency operating ที่โรงงานสำรองพื้นที่อื่น

BCP มีอยู่ แต่ scope ผิด — focus เฉพาะ technical incident ไม่ครอบ catastrophic scenario

นี่คือสิ่งที่ผมว่าต้องจำให้แม่น#

Restaurant fire analogy#

ลองนึกถึงร้านอาหารเกิดไฟไหม้ — มี 2 คำถามที่ต่างกัน:

คำถามแรก: “บัญชีรายรับรายจ่ายที่จดไว้ในกระดาษ — เราเสียได้ย้อนหลังเท่าไหร่?”

ถ้าจดทุกชั่วโมง backup → เสียอย่างมาก 1 ชั่วโมง = RPO = 1 ชั่วโมง ถ้าจดทุกวันสรุปวันเดียว → เสียอย่างมาก 1 วัน = RPO = 1 วัน

คำถามที่สอง: “ร้านต้องเปิดอีกครั้งภายในเท่าไหร่ ก่อนจะเสียลูกค้าทั้งหมด?”

ถ้าเป็นร้านแถบ business district → 1 วันก็เริ่มสูญลูกค้าประจำ = RTO = 1 วัน ถ้าเป็นร้านในชุมชนเล็กๆ → 1 สัปดาห์ยังพอ = RTO = 1 สัปดาห์

RPO กับ RTO ต่างกันยังไง?

• RPO = “ข้อมูลที่ recover ได้ ย้อนได้ไกลแค่ไหน”
• RTO = “ใช้เวลานานแค่ไหนถึงกลับมา”

ระบบหนึ่งสามารถมี RPO 4 ชั่วโมง แต่ RTO 1 ชั่วโมง — ยอม lose data 4 ชั่วโมงล่าสุด แต่ต้องกลับมาบริการใน 1 ชั่วโมง

Trap pattern#

ที่ผมเห็นใน practice question บ่อย:

“ระบบมี RPO 2 ชั่วโมง — backup ทุก 24 ชั่วโมงพอมั้ย?”

ไม่พอ — RPO 2 ชั่วโมง = ยอม lose data ย้อนได้ 2 ชั่วโมง ต้อง backup อย่างน้อยทุก 2 ชั่วโมง (หรือใช้ replication)

“ระบบมี RTO 1 ชั่วโมง — restore จาก tape ที่ใช้เวลา 4 ชั่วโมงพอมั้ย?”

ไม่พอ — restore เร็วกว่า RTO ถึงจะ work

MTTR — ตัวเลขที่เกี่ยวข้อง#

อีกตัวที่บางครั้ง exam ออก: MTTR (Mean Time To Repair) = เวลาเฉลี่ยในการแก้ระบบที่ fail

MTTR ต่ำ → recovery เร็ว → support RTO ที่สั้นกว่า

แต่ MTTR ขึ้นกับ — complexity ของ system, parts availability, skill ของช่าง

Other parameters: MTO + SDO#

Mirror Site#

คือ: copy ของ production แบบ real-time — ทั้ง hardware, software, data sync ตลอดเวลา ทำงานเหมือน production ทุกประการ

RPO / RTO: ใกล้ 0 / ใกล้ 0

ราคา: สูงสุด — เหมือนมี production 2 ชุด

ใช้กับ: ระบบ ultra-critical (ตลาดหุ้น, payment processing ของธนาคารใหญ่, monitoring system ของ ICU)

Hot Site#

คือ: site ที่พร้อมใช้งาน — มี hardware, software, network ทุกอย่าง data sync แต่อาจมี delay บ้าง

RPO / RTO: ชั่วโมง / น้อยกว่า 4 ชั่วโมง (โดยทั่วไป)

ราคา: สูง — ค่า maintain hardware + software license + ค่า facility

ใช้กับ: ระบบ Mission Critical ที่ acceptance downtime สั้น

Warm Site#

คือ: site ที่มี hardware + network แต่ software / data ต้อง install + restore ก่อนใช้

RPO / RTO: วัน / 1-3 วัน (โดยทั่วไป)

ราคา: กลาง

ใช้กับ: ระบบ Important ที่ทนได้บ้าง

Cold Site#

คือ: ห้องเปล่าที่มี power + network ทุกอย่างต้องขนเข้าไปติดตั้งหลังเกิดเหตุ

RPO / RTO: สัปดาห์ / 1+ สัปดาห์

ราคา: ต่ำสุด

ใช้กับ: ระบบ low priority ที่ทนได้นาน

Mobile Site#

คือ: truck/container ที่บรรจุ IT equipment พร้อม deploy ที่ไหนก็ได้ ใช้ตอนที่ primary site เสียหายและไม่มีพื้นที่ทดแทน

Reciprocal Agreement — ห้ามใช้สำหรับ critical system#

คือ: ข้อตกลงระหว่าง 2 องค์กร — ตกลงให้ใช้ facility ของอีกฝ่ายได้ ตอน disaster

ฟังดูดี — แต่exam ออกชัดเจนว่า reciprocal agreement = ไม่แนะนำสำหรับ critical system เพราะ:

• Capacity — partner องค์กรมี capacity พอจริงมั้ย?
• Compatibility — hardware/software/version ตรงกันมั้ย?
• Security — ข้อมูลของเราจะ co-mingle กับของ partner
• Licensing — software license ของเราใช้ใน partner site ได้มั้ย?
• Politics — partner อาจเปลี่ยน mind ตอนเกิดเหตุจริง

กรณีจริง: Hot site ที่ไม่ exclusive#

ธนาคารภูมิภาคไทยแห่งหนึ่ง — มีสัญญา hot site ที่สีลม

หลายปีที่ผ่านมา ไม่เคย test

วันที่เกิด fire ใน data center หลัก — ธนาคาร declare disaster, contact hot site provider

provider แจ้ง — มีอีก 3 บริษัทที่ declare disaster พร้อมกัน, hot site เต็ม

สัญญาของธนาคารไม่มี exclusivity clause — ต้องรอ 18 ชั่วโมง

control gap:

• ไม่เคย test hot site
• สัญญาไม่มี exclusivity ระหว่าง simultaneous disaster
• ไม่ได้ verify subscriber limit ของ provider

สิ่งที่ต้องอยู่ในสัญญา recovery site#

ผมขอ list ที่ผมว่าสำคัญที่สุดสำหรับ exam:

1. Exclusive access หรือ subscription-based (priority ของเรา)
2. Capacity guarantee — รับประกันว่ามี hardware พอ
3. Time guarantee — declare ตอนใด ใช้งานตอนใด
4. Duration — ใช้ได้นานสุดเท่าไหร่
5. Test rights — ทดสอบกี่ครั้งต่อปี
6. Configuration update — ใครรับผิดชอบ update hardware/software ใน hot site
7. Confidentiality — security ของ data ที่อยู่ใน site
8. Liability — ใครรับผิดถ้า hot site เสียหาย
9. Termination — เงื่อนไขเลิกสัญญา
10. Insurance — coverage ของ provider

กระดาษที่ไม่เคยซ้อม = ไม่มีค่า#

ตัวอย่างจริงที่ยาก: hospital เอกชนที่กรุงเทพ — annual BCP tabletop test

ระหว่าง test พบว่า:

• emergency contact list มี 12 เบอร์ที่เป็นเบอร์เก่า (พนักงานออก/เปลี่ยนเบอร์)
• backup site access code เป็นของ vendor ที่หมดสัญญา 8 เดือนก่อน
• ไม่มีใคร update ตั้งแต่เขียน BCP เสร็จ

ถ้าเกิดเหตุจริง — BCP ใช้ไม่ได้

control gap: ไม่มีคน assign รับผิดชอบ BCP maintenance

BCP Testing: 3 ระดับที่ต้องรู้#

CRM แบ่ง testing เป็นหลายระดับ ผมขอ list 3 ระดับใหญ่ที่ exam ออก:

ระดับที่ 1 — Tabletop / Walk-through#

คือ: ทีมนั่งคุยกัน — ไล่ scenario, อ่าน BCP ทีละขั้น, discuss ว่าใครทำอะไร

ข้อดี: เร็ว, ราคาถูก, ไม่กระทบ business operations ข้อจำกัด: ไม่ได้ทดสอบจริง — แค่ paper exercise

ใช้ตอน: เริ่มต้น, รุ่นแรกของ BCP, train new member

ระดับที่ 2 — Walk-through Drill / Simulation#

คือ: ทำตามขั้น BCP จริง — ไป backup site, restart system, ทดสอบ procedure แต่ยังไม่ failover production จริง

ข้อดี: ทดสอบ procedure จริง — เจอ gap ที่ paper exercise ไม่เจอ ข้อจำกัด: ใช้ resource เยอะกว่า, ต้อง coordinate

ใช้ตอน: หลังจากผ่าน tabletop, ปีละ 1-2 ครั้ง

ระดับที่ 3 — Full Operational Test / Parallel Test / Full Interruption#

คือ: failover จริง — production switch ไป backup site, ทดสอบ end-to-end

ข้อดี: test ที่ realistic ที่สุด — ทุก dependency, ทุก timing, ทุก human factor ถูก test ข้อจำกัด: risky — ถ้า test fail จริงก็ outage จริง ใช้ resource เยอะที่สุด

ใช้ตอน: ปีละครั้ง สำหรับระบบ critical, ทำในช่วง low-business window

Trap ของ exam — “tabletop = full test”#

ผิดเด็ดขาด tabletop คือจุดเริ่มต้น — full operational test คือ true validation

ถ้าองค์กรทดสอบเฉพาะ tabletop → flag finding เพราะ procedure ที่อยู่บนกระดาษอาจ break ตอน execute จริง

BCP Maintenance: triggers ที่ต้อง update#

BCP ต้อง update เมื่อ:

• พนักงาน turnover ในตำแหน่งที่อยู่ใน emergency contact
• ระบบ IT ใหม่ go-live
• ระบบเก่าเลิกใช้
• regulatory requirement เปลี่ยน
• vendor ที่ระบุใน BCP เปลี่ยน
• business process เปลี่ยน
• หลัง test เจอ gap
• หลังเหตุจริงเกิด

ที่ดีที่สุด — มี named owner ที่รับผิดชอบ BCP maintenance + quarterly review

กรณีจริงที่ misclassify#

convenience store chain — มี ransomware affect 3 ร้านใน 1 เขต

incident response team escalate เป็น crisis → activate ทั้ง BCP

กลายเป็นว่า — ทุก resource ของ crisis response team ทุ่มไปที่ ransomware ใน 3 ร้าน

ระหว่างนั้น — payment network outage ที่กระทบทั้ง 200 ร้าน เกิดขึ้น แต่ทีมหลักไม่ว่าง ต้องให้ทีม junior จัดการ

result: misclassify ของ event แรก → ทรัพยากรไม่พอสำหรับ event ที่ใหญ่กว่า

บทเรียน: classification criteria ต้องชัด + objective — ไม่ใช่ subjective judgment ของคนตอบโทรศัพท์คนแรก

RPO vs RTO#

BCP vs DRP#

Recovery Sites#

Testing#