title: "Disaster Recovery & BCP: Thiết kế kiến trúc phục hồi sau thảm họa ở cấp độ doanh nghiệp"
series: "TOGAF Mastery: Kiến trúc sư Doanh nghiệp Chuyên sâu"
part: "Phần 4 — Vận hành kiến trúc cấp chuyên gia (Expert Ops)"
order: 38
audience: "Enterprise Architect (EA) & Solutions Architect hướng EA"
reading_time: "13 phút"
tags:

• TOGAF
• Disaster Recovery
• Business Continuity Planning
• RTO
• RPO
• Enterprise Architecture
• Risk Management

Disaster Recovery & BCP: Thiết kế kiến trúc phục hồi sau thảm họa ở cấp độ doanh nghiệp

Một buổi diễn tập DR (Disaster Recovery) toàn công ty, lần đầu tiên sau bốn năm vận hành. Kịch bản: trung tâm dữ liệu chính mất điện hoàn toàn, không rõ thời gian khôi phục. Từng đội hạ tầng đều tự tin — hệ thống thanh toán có kế hoạch failover riêng, đã test hàng quý; hệ thống CRM có bản sao đồng bộ gần thời gian thực sang region phụ; kho dữ liệu có backup hàng đêm. Trên giấy, mọi thứ đều "xanh".

Nhưng khi bấm nút diễn tập thật, mọi thứ vỡ trận theo một cách không ai lường trước. Đội thanh toán failover xong trong 12 phút như kế hoạch — nhưng hệ thống thanh toán phụ thuộc vào dịch vụ xác thực khách hàng, mà đội xác thực lại đang restore từ backup mất 4 giờ. Đội CRM chuyển sang region phụ thành công, nhưng dữ liệu đơn hàng đồng bộ từ hệ thống ERP lại trỏ về database chính đã sập, gây ra vòng lặp lỗi kết nối kéo dài đến khi có người phát hiện. Không ai trong phòng điều phối biết thứ tự khôi phục đúng là gì, vì chưa từng có ai vẽ ra bức tranh phụ thuộc giữa các hệ thống.

Đây không phải lỗi kỹ thuật của từng đội — từng kế hoạch DR riêng lẻ đều đúng chuẩn, đều test định kỳ, đều đạt RTO/RPO cam kết trong phạm vi của mình. Vấn đề là không ai sở hữu bức tranh toàn cảnh: thứ tự khôi phục xuyên hệ thống, các phụ thuộc chéo, và ai là người ra quyết định khi có xung đột ưu tiên giữa các đội trong giờ khủng hoảng. Đây chính xác là khoảng trống mà một Enterprise Architect phải lấp — vì chỉ có EA đứng ở vị trí nhìn xuyên suốt toàn bộ landscape để thấy được những phụ thuộc mà từng đội riêng lẻ không thể thấy.

Bản chất

Cần phân biệt rạch ròi hai khái niệm hay bị gộp lẫn.

High Availability (HA) — đã bàn ở Bài 27 — giải quyết bài toán chịu lỗi cục bộ, liên tục: một node chết, một AZ (Availability Zone) gặp sự cố, một service bị lỗi tạm thời. Cơ chế là redundancy tự động, failover trong vài giây đến vài phút, hệ thống vẫn "sống" trong suốt gián đoạn, người dùng gần như không cảm nhận được.

Disaster Recovery (DR) giải quyết một tầng nghiêm trọng hơn: mất toàn bộ trung tâm dữ liệu hoặc toàn bộ region, thiên tai, tấn công ransomware diện rộng làm mã hóa/hủy hoại dữ liệu ở nhiều hệ thống cùng lúc, hoặc lỗi con người/quy trình nghiêm trọng xóa nhầm hạ tầng production. DR trả lời câu hỏi: "Nếu toàn bộ nơi đặt hệ thống biến mất, chúng ta khôi phục lại hoạt động như thế nào, ở đâu, trong bao lâu?"

Business Continuity Planning (BCP) đi xa hơn DR. DR tập trung vào khôi phục hạ tầng IT và hệ thống kỹ thuật. BCP tập trung vào khôi phục hoạt động kinh doanh — bao gồm cả con người (nhân sự làm việc ở đâu nếu văn phòng không dùng được), quy trình thủ công thay thế tạm thời, kênh liên lạc với khách hàng/đối tác, nghĩa vụ pháp lý và hợp đồng trong thời gian gián đoạn. DR là một cấu phần kỹ thuật nằm trong BCP tổng thể — DR trả lời "hệ thống nào khôi phục khi nào", còn BCP trả lời "doanh nghiệp vận hành ra sao trong lúc chờ khôi phục và sau đó".

Vai trò của EA trong DR/BCP không phải là viết runbook chi tiết cho từng hệ thống — đó là việc của kỹ sư vận hành, SRE, hay Solutions Architect từng hệ thống. Vai trò của EA là:

1. Phân loại mức độ quan trọng (criticality tiering) của toàn bộ danh mục hệ thống theo tác động kinh doanh, không phải theo cảm tính đội kỹ thuật.
2. Gán RTO/RPO có căn cứ cho từng tier, cân bằng giữa chi phí đầu tư DR và rủi ro chấp nhận được.
3. Vẽ bản đồ phụ thuộc xuyên hệ thống (dependency mapping) — vì một kế hoạch DR đúng cho từng hệ thống riêng lẻ vẫn có thể sai khi ráp lại tổng thể, đúng như case mở bài.
4. Điều phối trình tự khôi phục (recovery sequencing) ở cấp toàn doanh nghiệp và làm chủ sở hữu của kịch bản diễn tập tổng thể.
5. Đưa DR/BCP vào Architecture Governance — mọi Target Architecture mới phải trả lời được câu hỏi "kịch bản DR của kiến trúc này là gì" trước khi qua ARB (Architecture Review Board — xem Bài 31).

Hai chỉ số cốt lõi mọi EA phải nắm vững và biết cách gán khác nhau cho từng hệ thống:

RTO (Recovery Time Objective) — khoảng thời gian tối đa hệ thống được phép ngừng hoạt động trước khi thiệt hại kinh doanh trở nên không chấp nhận được. RTO = 15 phút nghĩa là sau thảm họa, hệ thống phải hoạt động trở lại trong vòng 15 phút.

RPO (Recovery Point Objective) — lượng dữ liệu tối đa được phép mất, tính theo thời gian kể từ lần backup/sync gần nhất. RPO = 1 giờ nghĩa là chấp nhận mất tối đa dữ liệu phát sinh trong 1 giờ gần nhất trước sự cố.

Sai lầm phổ biến nhất mà EA phải sửa: mặc định mọi hệ thống đều cần RTO gần 0 và RPO gần 0. Đây là tư duy sai vì hai lý do. Thứ nhất, chi phí tăng theo cấp số nhân khi RTO/RPO tiến về 0 — kiến trúc active-active đa region đắt gấp nhiều lần active-passive với backup định kỳ. Thứ hai, không phải hệ thống nào cũng đáng đầu tư mức đó — một hệ thống báo cáo nội bộ ngừng hoạt động 24 giờ không gây thiệt hại tương đương một hệ thống thanh toán ngừng hoạt động 5 phút. EA phải là người đưa quyết định đầu tư DR về đúng tỷ lệ với rủi ro kinh doanh thực, tránh cả hai thái cực: đầu tư dàn trải lãng phí hoặc bỏ sót hệ thống trọng yếu.

Khung & Kỹ thuật áp dụng

Bước 1 — Business Impact Analysis (BIA) để phân tier

Trước khi gán RTO/RPO, EA cần chạy BIA cho từng Business Capability (liên kết với Bài 14) và ứng dụng hỗ trợ nó, trả lời:

• Thiệt hại tài chính trực tiếp mỗi giờ ngừng hoạt động (doanh thu mất, phạt hợp đồng SLA).
• Rủi ro pháp lý/tuân thủ nếu dữ liệu bị mất hoặc trễ báo cáo.
• Tác động uy tín thương hiệu và niềm tin khách hàng.
• Mức độ phụ thuộc của các hệ thống hạ nguồn (downstream dependency).

Bước 2 — Ma trận Criticality Tiering

Bảng này chính là công cụ EA dùng để đối thoại với lãnh đạo kinh doanh — không nói ngôn ngữ kỹ thuật "replication mode", mà nói ngôn ngữ rủi ro "chấp nhận mất bao nhiêu tiền, mất bao nhiêu dữ liệu, trong bao lâu".

Bước 3 — Dependency Mapping xuyên hệ thống

Đây là kỹ thuật phân biệt EA với kỹ sư vận hành từng hệ thống. Dùng ArchiMate (Bài 23) hoặc một Catalog/Matrix đơn giản (Bài 24) để vẽ:

• Ma trận phụ thuộc: hệ thống A cần hệ thống B sẵn sàng trước mới khôi phục được.
• Xác định "single point of failure" ẩn — dịch vụ dùng chung (shared service) như xác thực, message queue, DNS nội bộ — mà nhiều Tier 0 cùng phụ thuộc nhưng bản thân dịch vụ đó lại được xếp nhầm vào Tier 2.

Đây chính là lỗi trong case mở bài: dịch vụ xác thực khách hàng — một shared service — không được EA nào rà soát ở tầm doanh nghiệp, nên bị đội sở hữu nó xếp tier thấp hơn thực tế mức độ quan trọng của nó đối với toàn hệ sinh thái.

Bước 4 — Recovery Sequencing (trình tự khôi phục)

Sau khi có dependency map, EA xây dựng trình tự khôi phục theo "wave" — hệ thống nền tảng (network, DNS, identity, message broker) khôi phục ở Wave 0, Tier 0 phụ thuộc trực tiếp vào chúng khôi phục ở Wave 1, cứ thế xuống các tier thấp hơn. Đây là artifact quan trọng nhất của bài này.

Bước 5 — Diễn tập phối hợp toàn doanh nghiệp (Coordinated DR Drill)

Khác với test DR từng hệ thống (necessary nhưng không đủ), EA phải là người khởi xướng và điều phối ít nhất một lần mỗi năm diễn tập giả lập kịch bản mất toàn bộ site, huy động tất cả các đội cùng lúc, theo đúng trình tự Wave đã thiết kế, có một "Incident Commander" duy nhất ra quyết định khi xung đột ưu tiên xảy ra.

Case thực tế minh hoạ

Lưu ý: đây là tình huống minh hoạ điển hình tổng hợp từ các mẫu hình phổ biến trong ngành, không phải case của một tổ chức cụ thể có thật, không có số liệu thực tế nào được sử dụng.

Một doanh nghiệp dịch vụ tài chính quy mô vừa vận hành khoảng 20 hệ thống chính. Mỗi hệ thống có kế hoạch DR riêng, được đội sở hữu tự thiết kế và tự test định kỳ theo lịch riêng của mình. Không có EA nào ở vị trí điều phối toàn cảnh — DR bị coi là trách nhiệm vận hành thuần túy (operations), không phải kiến trúc.

Khi tổ chức lần đầu quyết định chạy một cuộc diễn tập "toàn công ty" theo yêu cầu tuân thủ (compliance) từ đối tác/khách hàng lớn, sự cố xảy ra đúng như mô tả ở phần mở bài: các kế hoạch riêng lẻ đều "đạt" khi test độc lập, nhưng khi ráp lại đồng thời thì lộ ra ba vấn đề cấu trúc:

1. Phụ thuộc chéo không được ánh xạ: hệ thống Tier 0 (thanh toán) phụ thuộc vào một shared service (xác thực) bị xếp nhầm Tier 2, do đội sở hữu shared service đó không biết mức độ quan trọng thực sự của nó với các hệ thống hạ nguồn.
2. Không có trình tự khôi phục thống nhất: mỗi đội tự ý bắt đầu khôi phục theo lịch riêng, gây tranh chấp tài nguyên hạ tầng dùng chung (băng thông mạng, năng lực compute dự phòng) trong giờ cao điểm khủng hoảng.
3. Không có Incident Commander cấp doanh nghiệp: khi hai đội cùng cần cùng một tài nguyên dự phòng, không ai có thẩm quyền quyết định ai được ưu tiên trước.

Sau sự cố diễn tập, tổ chức thiết lập một chức năng "DR Architecture Governance" trực thuộc Architecture Capability (liên kết Bài 5), do EA chủ trì, với ba thay đổi cốt lõi: (a) một Dependency Matrix trung tâm được EA duy trì và review định kỳ mỗi khi có Target Architecture mới; (b) một Recovery Sequencing Runbook cấp doanh nghiệp thay vì 20 runbook rời rạc; (c) diễn tập phối hợp toàn doanh nghiệp trở thành hoạt động bắt buộc hàng năm, có Incident Commander luân phiên được chỉ định trước.

Bài học cho EA: DR không thất bại vì thiếu kỹ thuật ở từng hệ thống — nó thất bại vì thiếu một vai trò nhìn xuyên toàn cảnh danh mục. Đó chính là lý do TOGAF đặt trách nhiệm này vào tay Enterprise Architect chứ không phải bất kỳ đội kỹ thuật đơn lẻ nào.

📐 Template/Artifact áp dụng ngay

Enterprise DR Readiness Matrix — dùng ngay trong buổi review Architecture Governance kế tiếp:

Checklist trước mỗi cuộc diễn tập DR toàn doanh nghiệp:

• Đã cập nhật Dependency Matrix trong vòng 90 ngày gần nhất chưa?
• Mọi hệ thống Tier 0/1 có RTO/RPO được ký duyệt bởi chủ sở hữu kinh doanh (business owner), không chỉ đội kỹ thuật?
• Đã xác định Incident Commander cho cuộc diễn tập, có thẩm quyền phân xử xung đột ưu tiên?
• Trình tự Wave khôi phục đã được tất cả các đội liên quan xác nhận, không chỉ EA thiết kế một chiều?
• Có kịch bản giả lập mất một shared service nền tảng (identity, network, DNS) không chỉ mất một ứng dụng đơn lẻ?
• Kết quả diễn tập có được đưa lại vào ARB để cập nhật Target Architecture nếu phát hiện gap?

🎯 Góc nhìn Chief EA

Nếu ngày mai trung tâm dữ liệu chính biến mất, tôi có thể trả lời ngay hệ thống nào khôi phục trước, hệ thống nào chờ, mà không cần họp khẩn cấp để tranh luận không?

RTO/RPO tôi đang cam kết cho từng tier có thực sự được ký duyệt bởi người chịu trách nhiệm kinh doanh, hay chỉ là con số kỹ thuật đội hạ tầng tự đặt ra?

Lần gần nhất chúng ta test DR là test từng hệ thống riêng lẻ, hay test đồng thời toàn bộ landscape với đúng mức độ hỗn loạn của một thảm họa thật?

Ai là người có thẩm quyền phân xử khi hai hệ thống Tier 0 cùng tranh chấp tài nguyên dự phòng trong giờ khủng hoảng — và người đó có biết vai trò của mình trước khi thảm họa xảy ra không?

🔗 Bài viết liên quan

• Giai đoạn D — Technology Reference Model
• Architecture Review Board (ARB)

Bài trước: Vendor Management · Bài tiếp theo: EA Tooling