Mở đầu — vì sao bài này quan trọng
Hãy hình dung bạn là Technical BA cho một dự án thay thế hệ thống thanh toán của một ví điện tử lớn. Mọi thứ trên giấy đều đẹp: kiến trúc rõ ràng, API spec đầy đủ, timeline 6 tháng. Rồi đến tuần go-live, đội vận hành phát hiện hệ thống mới không xử lý nổi lưu lượng giờ cao điểm, một thư viện mã hóa đã hết hỗ trợ (end-of-life), và nhà cung cấp cổng thanh toán bất ngờ đổi format response. Dự án trễ 3 tháng, đốt thêm vài tỷ đồng. Câu hỏi đắt giá là: những rủi ro này có thực sự bất ngờ không, hay chúng đã ở đó từ đầu mà không ai gọi tên?
Phần lớn rủi ro kỹ thuật không phải "thiên nga đen" không thể lường trước. Chúng là những điểm yếu đã hiện diện trong thiết kế, trong phụ thuộc công nghệ, trong giả định chưa được kiểm chứng — chỉ là chưa ai ngồi xuống nhận diện, chấm điểm và lập kế hoạch ứng phó một cách có hệ thống. Đó chính xác là việc của một Technical Risk Assessment Framework: biến nỗi lo mơ hồ "không biết có gì hỏng không" thành một bảng rủi ro có thứ tự ưu tiên, có chủ sở hữu, có phương án xử lý.
Với vai trò Technical BA, bạn đứng ở vị trí lý tưởng để làm việc này. Bạn hiểu nghiệp vụ đủ để biết hỏng chỗ nào thì đau, và hiểu kỹ thuật đủ để biết chỗ nào dễ hỏng. Bài này cho bạn một khung làm việc cụ thể để chủ động "soi" rủi ro kỹ thuật trước khi chúng trở thành sự cố production.
Khái niệm cốt lõi
Risk = Likelihood × Impact
Nền tảng của mọi framework đánh giá rủi ro là một công thức đơn giản đến mức dễ bị xem nhẹ:
> Risk Score = Likelihood (Khả năng xảy ra) × Impact (Mức độ tác động)
- Likelihood trả lời câu hỏi: rủi ro này có dễ xảy ra không? Một thư viện đã 5 năm không cập nhật thì khả năng phát sinh lỗ hổng bảo mật rất cao. Một sự kiện thiên tai làm sập data center thì khả năng thấp.
- Impact trả lời câu hỏi: nếu xảy ra thì hậu quả lớn cỡ nào? Một typo trong nhãn nút bấm thì tác động nhỏ. Mất dữ liệu giao dịch tài chính thì tác động thảm họa.
Ma trận rủi ro 5×5
Cách phổ biến nhất để vận hành công thức trên là ma trận 5×5. Bạn chấm Likelihood trên thang 1–5 và Impact trên thang 1–5, nhân lại được điểm từ 1 đến 25.
Thang Likelihood (gợi ý diễn giải để cả team chấm nhất quán):
| Điểm | Nhãn | Diễn giải |
|---|---|---|
| 1 | Rất hiếm | Gần như không xảy ra trong vòng đời dự án |
| 2 | Khó xảy ra | Có thể xảy ra nhưng không kỳ vọng |
| 3 | Có thể | Khả năng ngang ngửa 50/50 |
| 4 | Dễ xảy ra | Nhiều khả năng sẽ xảy ra |
| 5 | Gần như chắc chắn | Sẽ xảy ra nếu không can thiệp |
| Điểm | Nhãn | Diễn giải |
|---|---|---|
| 1 | Không đáng kể | Người dùng gần như không nhận ra |
| 2 | Nhỏ | Phiền toái, có workaround |
| 3 | Trung bình | Ảnh hưởng một phần nghiệp vụ, cần sửa gấp |
| 4 | Lớn | Gián đoạn dịch vụ, tổn thất tài chính/uy tín rõ rệt |
| 5 | Thảm họa | Mất dữ liệu, vi phạm pháp lý, dừng hệ thống diện rộng |
- 1–6 (Thấp / xanh): theo dõi, chưa cần hành động ngay.
- 7–14 (Trung bình / vàng): cần kế hoạch giảm thiểu trong sprint tới.
- 15–25 (Cao / đỏ): phải xử lý ngay, leo thang lên stakeholder.
Các nhóm rủi ro kỹ thuật (Risk categories)
Để không bỏ sót, Technical BA nên rà soát rủi ro theo từng nhóm, giống như một checklist. Sáu nhóm thường gặp nhất:
- Technical debt (Nợ kỹ thuật) — code chắp vá, kiến trúc lỗi thời, thiếu test. Mỗi tính năng mới đắp lên nền yếu sẽ chậm dần và dễ gãy.
- Dependency & technology risk — phụ thuộc thư viện/framework hết hỗ trợ, vendor lock-in, công nghệ team chưa làm chủ.
- Integration risk — phụ thuộc hệ thống bên thứ ba (cổng thanh toán, eKYC, đối tác), format dữ liệu thay đổi, SLA của đối tác.
- Performance & scalability risk — hệ thống không chịu nổi tải đỉnh, nghẽn cổ chai ở database, không co giãn được.
- Security & compliance risk — lỗ hổng bảo mật, dữ liệu nhạy cảm không mã hóa, vi phạm quy định (ví dụ Nghị định 13/2023 về bảo vệ dữ liệu cá nhân tại Việt Nam).
- Data & migration risk — mất mát, sai lệch dữ liệu khi di trú, chất lượng dữ liệu nguồn kém.
Bốn chiến lược ứng phó (4T)
Chấm điểm xong rồi làm gì? Mỗi rủi ro chọn một trong bốn hướng:
- Treat / Mitigate (Giảm thiểu): làm gì đó để hạ Likelihood hoặc Impact. Ví dụ thêm circuit breaker để lỗi đối tác không kéo sập cả hệ thống.
- Transfer (Chuyển giao): đẩy rủi ro cho bên khác — mua bảo hiểm, đưa vào hợp đồng SLA với vendor, dùng dịch vụ managed.
- Tolerate / Accept (Chấp nhận): rủi ro nhỏ, chi phí xử lý lớn hơn lợi ích — ghi nhận và theo dõi.
- Terminate / Avoid (Loại bỏ): thay đổi phương án để rủi ro biến mất hẳn — ví dụ bỏ một công nghệ quá rủi ro, chọn giải pháp khác.
Tình huống thực tế
Ví dụ 1 — Ví điện tử mở rộng eKYC: rủi ro tích hợp
Một công ty fintech tại TP.HCM (gọi là PayNow) ra tính năng định danh điện tử (eKYC) tích hợp với một nhà cung cấp AI nhận diện khuôn mặt bên thứ ba. Technical BA ngồi cùng đội kiến trúc làm risk assessment và nhận diện rủi ro: "API của nhà cung cấp eKYC có thể chậm hoặc downtime vào giờ cao điểm đăng ký, làm nghẽn luồng onboarding."
Chấm điểm: Likelihood = 4 (đối tác mới, chưa có lịch sử SLA ổn định), Impact = 4 (người dùng không đăng ký được, mất khách ngay cửa). Score = 16 → đỏ. Chiến lược chọn: Treat. Đội thiết kế thêm hàng đợi bất đồng bộ — nếu eKYC chậm quá 5 giây, hệ thống cho phép người dùng tiếp tục onboarding và xác minh nền sau, đồng thời đặt timeout + retry có giới hạn.
Một tháng sau go-live, đối tác eKYC thật sự sập 40 phút vào tối thứ Sáu. Nhờ thiết kế giảm thiểu, 2.300 người dùng vẫn hoàn tất đăng ký thay vì bị chặn. Bài học: rủi ro tích hợp với bên thứ ba gần như luôn có Likelihood cao — đừng giả định đối tác luôn sống. Hãy chấm điểm thẳng thắn và thiết kế để "sống sót" khi đối tác chết.
Ví dụ 2 — Sàn TMĐT và rủi ro performance ngày sale 12/12
Một sàn thương mại điện tử tầm trung chuẩn bị cho đợt sale 12/12. Technical BA rà nhóm Performance & scalability và đưa ra rủi ro: "Database đơn (single primary) phục vụ cả đọc lẫn ghi, lưu lượng ngày sale dự kiến gấp 8 lần ngày thường, có thể nghẽn cổ chai và timeout đơn hàng."
Chấm điểm: Likelihood = 5 (năm ngoái đã từng nghẽn nhẹ ở mức tải thấp hơn), Impact = 5 (mất đơn trực tiếp = mất doanh thu trong cửa sổ vài giờ). Score = 25 → đỏ rực. Đây là rủi ro phải leo thang ngay.
Đội chọn kết hợp Treat + Transfer: thêm read replica để tách tải đọc, đưa các trang sản phẩm hot lên CDN/cache, và ký thêm điều khoản autoscaling với nhà cung cấp cloud (chuyển một phần rủi ro hạ tầng sang vendor managed). Kết quả ngày 12/12 hệ thống chịu được đỉnh gấp 9 lần mà không sập. Bài học: với rủi ro performance, dữ liệu lịch sử là vàng. Một rủi ro "đã từng xảy ra ở quy mô nhỏ hơn" gần như chắc chắn lặp lại nặng hơn khi tải tăng — đừng để cảm tính "chắc ổn thôi" che mờ điểm số.
Ví dụ 3 — Ngân hàng và rủi ro nợ kỹ thuật + compliance
Một ngân hàng đang nâng cấp module báo cáo giao dịch. Technical BA phát hiện module cũ dùng một thư viện sinh báo cáo PDF đã end-of-life 3 năm, không còn bản vá bảo mật, và đang xử lý dữ liệu khách hàng chưa mã hóa khi tạm lưu file.
Hai rủi ro được tách ra:
- Nhóm Technical debt: thư viện EOL. Likelihood = 3, Impact = 3 → Score = 9 (vàng).
- Nhóm Security & compliance: dữ liệu nhạy cảm lưu tạm không mã hóa, vi phạm yêu cầu nội bộ và Nghị định 13. Likelihood = 4, Impact = 5 → Score = 20 (đỏ).
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng cho bất kỳ dự án nào:
Bước 1 — Xác định phạm vi (scope). Chốt rõ bạn đang đánh giá rủi ro cho cái gì: một tính năng, một release, hay một dự án di trú? Phạm vi mơ hồ dẫn đến danh sách rủi ro vừa thiếu vừa thừa.
Bước 2 — Nhận diện rủi ro (identify). Duyệt qua 6 nhóm rủi ro như checklist. Tổ chức một buổi workshop ngắn với architect, dev lead, DBA, security. Câu hỏi mồi hữu ích: "Điều gì khiến anh/chị mất ngủ về phần này?" và "Chúng ta đang giả định điều gì mà chưa kiểm chứng?" Ghi mỗi rủi ro thành một câu hoàn chỉnh: nguyên nhân → sự kiện → hậu quả.
Bước 3 — Chấm điểm (assess). Với mỗi rủi ro, cả nhóm cùng chấm Likelihood và Impact theo thang 1–5 đã thống nhất. Nhân ra Risk Score. Khi có bất đồng, hãy để người chấm cao và người chấm thấp giải thích — chính cuộc tranh luận đó mới là giá trị.
Bước 4 — Ưu tiên (prioritize). Sắp xếp theo điểm giảm dần. Tô màu xanh/vàng/đỏ. Nhóm đỏ là tâm điểm — tập trung nguồn lực vào đây.
Bước 5 — Lập kế hoạch ứng phó (plan). Mỗi rủi ro chọn một trong 4T (Treat/Transfer/Tolerate/Terminate). Với Treat, ghi rõ hành động cụ thể, người chịu trách nhiệm (risk owner), và hạn chót.
Bước 6 — Theo dõi & cập nhật (monitor). Risk register không phải tài liệu chết. Mỗi sprint review lại: rủi ro nào đã đóng, rủi ro nào điểm thay đổi, có rủi ro mới phát sinh không. Rủi ro là sống, đánh giá cũng phải sống.
Mẫu một dòng trong risk register nên có các cột: ID | Mô tả rủi ro | Nhóm | Likelihood | Impact | Score | Mức | Chiến lược | Hành động giảm thiểu | Risk owner | Trạng thái.
Lỗi thường gặp & mẹo
Lỗi 1 — Chấm điểm theo cảm tính, không có tiêu chí chung. Khi mỗi người hiểu "Impact = 4" một kiểu, điểm số vô nghĩa. Mẹo: luôn dán bảng diễn giải thang điểm lên màn hình trong lúc chấm, và neo Impact vào con số thật (bao nhiêu phút downtime, bao nhiêu giao dịch ảnh hưởng, bao nhiêu tiền).
Lỗi 2 — Nhận diện rủi ro chỉ một lần rồi quên. Nhiều team làm risk assessment ở kickoff để "cho có" rồi cất tủ. Rủi ro lớn nhất thường lộ ra giữa chừng dự án. Mẹo: đưa "review risk register" thành nghị trình cố định 10 phút mỗi sprint review.
Lỗi 3 — Chỉ liệt kê rủi ro mà không gắn chủ sở hữu. Rủi ro không có owner là rủi ro không ai xử lý. Mẹo: mỗi dòng đỏ/vàng phải có đúng một tên người chịu trách nhiệm.
Lỗi 4 — Bỏ qua rủi ro Impact cao chỉ vì Likelihood thấp. "Hiếm khi xảy ra" không có nghĩa là kệ nó. Mất toàn bộ dữ liệu là điều hiếm nhưng phải có backup/DR. Mẹo: với mọi rủi ro Impact = 5, dù Likelihood thấp, vẫn phải có ít nhất một phương án dự phòng được ghi nhận.
Lỗi 5 — Technical BA tự chấm một mình. Bạn không biết hết ngóc ngách kỹ thuật. Mẹo: rủi ro kỹ thuật phải được chấm bởi nhóm liên chức năng. Vai trò của BA là dẫn dắt buổi đánh giá và đảm bảo mọi rủi ro được nói ra, không phải là người duy nhất biết câu trả lời.
Mẹo nâng cao: phân biệt inherent risk (rủi ro gốc, khi chưa làm gì) và residual risk (rủi ro còn lại sau khi đã giảm thiểu). Stakeholder cần biết sau khi bỏ công sức xử lý, rủi ro còn lại có chấp nhận được không. Ghi cả hai cột này trong register sẽ làm báo cáo của bạn thuyết phục hơn hẳn.
Bài tập thực hành
Hãy lấy một dự án thật bạn đang/sắp tham gia (hoặc dùng tình huống giả định: "tích hợp cổng thanh toán mới VNPay/Momo vào app đặt vé xem phim").
- Nhận diện: viết ra ít nhất 8 rủi ro kỹ thuật, mỗi rủi ro thuộc rõ một trong 6 nhóm. Viết theo cấu trúc nguyên nhân → sự kiện → hậu quả.
- Chấm điểm: với mỗi rủi ro, gán Likelihood (1–5) và Impact (1–5), tính Score. Viết một câu giải thích vì sao bạn chấm như vậy.
- Phân vùng: tô màu xanh/vàng/đỏ. Bạn có bao nhiêu rủi ro đỏ?
- Ứng phó: với mỗi rủi ro vàng và đỏ, chọn một chiến lược trong 4T và đề xuất một hành động cụ thể kèm risk owner giả định.
- Phản biện: tự hỏi — có rủi ro Impact = 5 nào mà bạn đang định "chấp nhận" chỉ vì Likelihood thấp không? Nếu có, hãy nghĩ phương án dự phòng cho nó.
Tóm tắt
- Rủi ro kỹ thuật hiếm khi thực sự bất ngờ — phần lớn đã hiện diện và chỉ cần được nhận diện, chấm điểm, lập kế hoạch một cách có hệ thống.
- Công thức nền tảng: Risk = Likelihood × Impact. Một rủi ro chỉ nguy hiểm khi cả hai chiều đều cao.
- Ma trận 5×5 cho điểm 1–25, phân vùng xanh (1–6) / vàng (7–14) / đỏ (15–25) để ưu tiên nguồn lực. Giá trị thật nằm ở cuộc thảo luận đồng thuận, không phải con số chính xác.
- Rà soát theo 6 nhóm rủi ro: technical debt, dependency, integration, performance/scalability, security/compliance, data/migration — để không bỏ sót.
- Mỗi rủi ro chọn một trong 4T: Treat, Transfer, Tolerate, Terminate; gắn risk owner và hành động cụ thể.
- Risk register là tài liệu sống: review mỗi sprint, cập nhật điểm, đóng rủi ro cũ, ghi nhận rủi ro mới.
- Vai trò Technical BA là dẫn dắt buổi đánh giá liên chức năng — đảm bảo mọi rủi ro được nói ra và neo Impact vào con số thật, chứ không tự chấm một mình theo cảm tính.