title: "Kiến trúc hạ tầng (Infrastructure Architecture): Thiết kế hệ thống chịu lỗi cao (High Availability) theo chuẩn EA"
series: "TOGAF Mastery: Kiến trúc sư Doanh nghiệp Chuyên sâu"
part: "Phần 3 — Kỹ thuật thiết kế & Mô hình hóa (Modeling & Artifacts)"
order: 27
audience: "Enterprise Architect (EA) & Solutions Architect hướng EA"
reading_time: "12 phút"
tags:

• TOGAF
• Technology Architecture
• High Availability
• Infrastructure Architecture
• Fault Domain
• Failover
• Enterprise Architecture

Kiến trúc hạ tầng (Infrastructure Architecture): Thiết kế hệ thống chịu lỗi cao (High Availability) theo chuẩn EA

Có một câu tôi nghe đi nghe lại trong hàng chục buổi review kiến trúc: "Hệ thống này HA rồi, tụi em chạy 2 server, có load balancer." Nghe rất yên tâm — cho đến khi tôi hỏi tiếp một câu duy nhất: "Hai server đó trỏ vào một database, database đó chạy trên một instance, đúng không?" Im lặng. Đó chính là khoảnh khắc một kiến trúc "HA trên giấy" lộ nguyên hình là một hệ thống có đúng một điểm lỗi đơn được ngụy trang khéo léo bằng hai con server phía trước.

Đây không phải lỗi kỹ thuật của kỹ sư vận hành. Đây là lỗi tư duy kiến trúc. Redundancy (dự phòng) ở một tầng trong khi tầng khác vẫn là single point of failure (SPOF — điểm lỗi đơn) không phải là High Availability, đó là ảo giác về High Availability — thứ nguy hiểm hơn cả việc không có gì, vì nó tạo cảm giác an toàn giả. Và đây chính xác là chỗ Technology Architecture trong TOGAF ADM (Architecture Development Method) phải can thiệp: không phải để vẽ đẹp sơ đồ hạ tầng, mà để buộc tổ chức trả lời câu hỏi "hệ thống này chịu được loại lỗi nào, và với chi phí bao nhiêu?" trước khi sự cố buộc họ trả lời trong hoảng loạn.

Bài này không nói về cách cấu hình một cụm MySQL hay một Auto Scaling Group cụ thể — đó là việc của Solutions Architect và kỹ sư hạ tầng. Bài này nói về cách một EA tư duy và quản trị quyết định HA ở tầm doanh nghiệp: khi nào cần, cần đến mức nào, và làm sao tránh cả hai thái cực — over-engineering tốn kém vô ích, và under-engineering để lại một quả bom hẹn giờ.

Bản chất

Trong TOGAF, Technology Architecture là giai đoạn D của ADM — nơi kiến trúc sư chuyển Application Architecture và Data Architecture (đã định hình ở giai đoạn C) thành các thành phần hạ tầng vật lý và logic: compute, network, storage, platform. High Availability là một trong những Non-Functional Requirement (NFR — yêu cầu phi chức năng) quan trọng nhất mà Technology Architecture phải hiện thực hóa, cùng với performance, scalability, security.

Bản chất của HA không nằm ở số lượng server. Nó nằm ở một câu hỏi thiết kế duy nhất: nếu thành phần X này chết ngay bây giờ, điều gì xảy ra với dịch vụ? Nếu câu trả lời là "dịch vụ dừng hoàn toàn cho đến khi có người sửa tay", thành phần X đó là một SPOF — bất kể nó là một con server, một sợi cáp mạng, một API key hết hạn, hay một nhân viên duy nhất biết cách khởi động lại hệ thống.

Ba khái niệm nền tảng cần phân biệt rõ, vì chúng thường bị dùng lẫn lộn:

Redundancy (dự phòng) là việc có nhiều hơn một bản sao của một thành phần để nếu một bản chết, bản khác vẫn phục vụ. Nhưng redundancy chỉ có giá trị nếu các bản sao đó không cùng chết vì cùng một nguyên nhân — đây là lý do khái niệm fault domain (vùng lỗi) quan trọng hơn bản thân con số "mấy bản sao".

Failover (chuyển đổi dự phòng) là cơ chế tự động phát hiện một thành phần đã chết và chuyển traffic/trách nhiệm sang thành phần dự phòng mà không cần con người can thiệp thủ công. Redundancy không có failover tự động chỉ là "có sẵn cái để thay, nhưng phải có người thức dậy lúc 2 giờ sáng để thay". Đó vẫn tính là downtime kéo dài — chỉ là downtime có kế hoạch B, không phải HA thực sự.

Fault domain (vùng lỗi) là ranh giới mà trong đó một sự cố (mất điện, hỏng ổ cứng, lỗi phần mềm, sự cố mạng, thậm chí lỗi thao tác của con người) có thể lan ra và ảnh hưởng đồng thời đến nhiều thành phần. Hai server redundancy nhưng đặt cùng một rack, cùng một nguồn điện, cùng một switch mạng — về mặt fault domain, chúng là MỘT thành phần duy nhất khoác hai lớp vỏ. Đây chính là cái bẫy "HA giả" phổ biến nhất mà tôi thấy trong review kiến trúc doanh nghiệp Việt Nam: mở rộng số lượng instance nhưng không mở rộng fault domain.

Một điều quan trọng khác EA phải làm rõ với business: HA không loại bỏ rủi ro, nó chuyển đổi loại rủi ro. Không hệ thống nào "không bao giờ sập" — Availability luôn được đo bằng xác suất (99.9%, 99.95%, 99.99% — dân trong ngành hay gọi vui là "mấy con 9"), không phải bằng con số tuyệt đối. Vai trò của EA là giúp tổ chức chọn đúng "mấy con 9" cho đúng hệ thống, thay vì áp một tiêu chuẩn cho tất cả — đây chính là chủ đề của phần tiếp theo.

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

1. Nguyên tắc thiết kế HA theo tầng (Redundancy theo tầng)

HA không phải một quyết định duy nhất, mà là một chuỗi quyết định lặp lại ở mọi tầng của stack hạ tầng. Một hệ thống chỉ HA thực sự khi KHÔNG có tầng nào trong chuỗi dưới đây là SPOF:

Chú ý dòng cuối cùng — đây là điều nhiều đội kỹ thuật bỏ sót nhất. Một hệ thống có hạ tầng HA hoàn hảo nhưng chỉ một kỹ sư duy nhất biết cách xử lý sự cố vẫn có một SPOF: con người đó đi nghỉ mát, mất sóng điện thoại. TOGAF nhấn mạnh Technology Architecture không chỉ là công nghệ — nó bao gồm cả năng lực vận hành con người, quy trình, tri thức tổ chức.

2. Health check tự động — điều kiện tiên quyết của failover

Redundancy không tự động dẫn đến failover. Phải có một cơ chế liên tục kiểm tra "thành phần này còn sống và còn khỏe không" (health check), và khi phát hiện bất thường, kích hoạt chuyển đổi mà không chờ con người xác nhận. EA cần yêu cầu kiến trúc kỹ thuật trả lời rõ ba câu hỏi cho mỗi thành phần quan trọng:

• Detection time: mất bao lâu để hệ thống phát hiện thành phần đã chết? (Health check mỗi 30 giây khác hoàn toàn với health check mỗi 5 phút.)
• Failover time: từ lúc phát hiện đến lúc traffic thực sự chuyển hướng thành công mất bao lâu?
• False positive handling: nếu health check báo sai (thành phần thực ra vẫn sống nhưng mạng chập chờn), hệ thống có gây ra một "flapping" (chuyển đổi qua lại liên tục) làm tình hình tệ hơn không?

Tổng của detection time + failover time chính là phần lớn con số RTO (Recovery Time Objective) thực tế mà tổ chức sẽ trải nghiệm khi sự cố xảy ra — bất kể SLA trên giấy ghi gì.

3. Khung xác định mức HA cần thiết theo mức độ quan trọng của hệ thống

Đây là đóng góp quan trọng nhất của EA trong chủ đề này: không phải hệ thống nào cũng cần HA cao nhất, vì chi phí và độ phức tạp vận hành của HA tăng gần như theo cấp số nhân khi tiến gần đến 100% uptime — mỗi con "9" thêm vào tốn kém hơn con 9 trước nó rất nhiều lần (nguyên lý này giới kỹ thuật hay gọi là "chi phí của mỗi con chín"). Một EA giỏi không phải người đề xuất Multi-Region Active-Active cho mọi thứ, mà là người phân tầng đúng.

Khung phân loại dựa trên hai trục: Business Impact (tác động kinh doanh nếu ngừng hoạt động) và tính chất downtime chấp nhận được:

Việc phân tầng này phải được quyết định cùng business, không phải áp đặt từ IT. Đây chính là nơi Stakeholder Management (đã bàn ở Bài 12) gặp lại Technology Architecture: một EA đưa bảng phân tầng này ra trong Architecture Board, để chủ sở hữu nghiệp vụ (business owner) của từng hệ thống tự cam kết vào Tier tương ứng — và quan trọng hơn, tự chịu trách nhiệm về ngân sách đi kèm. Khi business chọn Tier 2 để tiết kiệm chi phí, họ phải ký nhận rằng họ chấp nhận rủi ro downtime tương ứng bằng văn bản, không phải để IT một mình gánh khi sự cố xảy ra.

Một nguyên tắc thực dụng cần nói thẳng với đội kỹ thuật: đừng thiết kế Tier 0 cho một hệ thống Tier 2. Over-engineering HA cho hệ thống ít quan trọng không chỉ tốn tiền, nó còn tăng độ phức tạp vận hành, tăng bề mặt lỗi (nhiều thành phần hơn = nhiều thứ có thể hỏng hơn), và làm chậm tốc độ phát triển tính năng vì mọi thay đổi đều phải đi qua quy trình HA nặng nề. HA không phải là mục tiêu tự thân — nó là công cụ phục vụ đúng nhu cầu.

Case thực tế minh hoạ

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

Một công ty dịch vụ tài chính vận hành hệ thống xử lý giao dịch — Tier 0 theo mọi tiêu chí nghiệp vụ. Đội hạ tầng đã đầu tư bài bản: hai cụm ứng dụng chạy song song ở hai Availability Zone khác nhau, load balancer phân phối traffic, database có replica đồng bộ, giám sát 24/7. Trên giấy, đây là một kiến trúc HA mẫu mực.

Sự cố xảy ra không phải ở compute, không phải ở database. Nó xảy ra ở một thành phần mà không ai coi là "hạ tầng chính": dịch vụ xác thực nội bộ (internal authentication service) — cấp token cho mọi service-to-service call trong hệ thống. Dịch vụ này được một đội nhỏ dựng tạm hai năm trước để giải quyết một nhu cầu ngắn hạn, chạy trên đúng một instance, không nằm trong bất kỳ tài liệu Technology Architecture nào, không được đưa vào diễn tập Disaster Recovery, và quan trọng nhất — không nằm trong phạm vi giám sát HA vì nó "chỉ là một service phụ trợ nội bộ".

Instance đó gặp sự cố phần cứng lúc cao điểm giao dịch. Cả hai cụm ứng dụng ở hai AZ vẫn chạy hoàn hảo — nhưng cả hai đều không gọi được service xác thực, nên mọi giao dịch đều bị từ chối ở tầng authorization. Từ góc nhìn người dùng, toàn bộ hệ thống "quan trọng nhất, được đầu tư HA tốt nhất" của công ty sập hoàn toàn, trong khi hai cụm chính vẫn xanh rờn trên dashboard giám sát.

Nguyên nhân gốc rễ không phải kỹ thuật — mà là kiến trúc: Technology Architecture đã dừng lại ở ranh giới của những gì được coi là "thành phần chính", trong khi thực tế mọi dependency, kể cả dependency ẩn, đều nằm trong fault domain của hệ thống. Đây chính xác là lý do TOGAF yêu cầu Architecture Repository (kho lưu trữ kiến trúc) phải có Technology Portfolio Catalog đầy đủ, và yêu cầu mọi thay đổi hạ tầng — kể cả một service "tạm dựng" — phải đi qua Architecture Compliance Review (Bài 20), chứ không được âm thầm trở thành hạ tầng sản xuất chính thức.

Sau sự cố, tổ chức làm ba việc, đúng tinh thần Phase H (Architecture Change Management, Bài 21): (1) rà soát toàn bộ dependency graph thực tế — không dựa vào tài liệu cũ mà dựa vào traffic log thực tế để tìm mọi SPOF ẩn; (2) đưa dịch vụ xác thực vào Tier 0, tái thiết kế với redundancy đa AZ và health check tự động; (3) thiết lập chính sách bắt buộc: bất kỳ service nào được gọi bởi một hệ thống Tier 0 tự động được kế thừa yêu cầu HA tối thiểu của Tier đó — nguyên tắc "HA lan truyền theo dependency" chứ không dừng ở ranh giới module.

📐 Template/Artifact áp dụng ngay

Technology Availability Catalog — artifact TOGAF-style dùng để kiểm kê toàn bộ thành phần hạ tầng, gán Tier, và xác định SPOF còn tồn đọng. Dùng trong Phase D và review định kỳ tại Architecture Board.

Cách dùng:

1. Liệt kê MỌI thành phần hạ tầng — kể cả service "phụ trợ", cron job, message queue, cache layer, third-party integration.
2. Với mỗi thành phần, truy ngược nó phục vụ hệ thống nghiệp vụ nào và Tier tương ứng — nếu một thành phần phục vụ nhiều hệ thống, nó nhận Tier cao nhất trong số đó.
3. Cột "Fault domain độc lập?" là cột quan trọng nhất — trả lời "Có" chỉ khi các bản redundancy thực sự không chia sẻ điểm lỗi vật lý/logic chung (khác rack, khác AZ, khác nguồn điện, khác đội vận hành).
4. Bất kỳ dòng nào có SPOF tồn đọng ở Tier 0/1 phải có deadline khắc phục và được báo cáo lên Architecture Board — không được để "biết mà thôi" mà không có kế hoạch.
5. Yêu cầu diễn tập failover (không chỉ đọc tài liệu) tối thiểu mỗi 6 tháng cho Tier 0, mỗi năm cho Tier 1.

🎯 Góc nhìn Chief EA

Nếu thành phần này chết ngay bây giờ, ai trong tổ chức biết trong vòng bao nhiêu giây, và điều gì xảy ra tiếp theo mà không cần con người can thiệp?
Hai bản redundancy này có thực sự nằm trong hai fault domain độc lập, hay chỉ là hai vỏ bọc của cùng một điểm lỗi?
Chúng ta đang trả tiền cho mức HA nào, và business owner có thực sự đồng ý đánh đổi chi phí đó — bằng văn bản — hay đó là giả định của riêng đội hạ tầng?
Lần cuối chúng ta THỰC SỰ rút phích cắm để kiểm chứng failover, thay vì chỉ đọc lại sơ đồ kiến trúc, là khi nào?

🔗 Bài viết liên quan

• Giai đoạn D: Technology Reference Model
• Giai đoạn G: Governance & Compliance Review

Bài trước: Kiến trúc ứng dụng (Application Architecture) · Bài tiếp theo: Kiến trúc bảo mật (Security Architecture)