Mở đầu — vì sao bài này quan trọng
Hãy hình dung bạn đang là BA cho một dự án xây dựng app đặt vé xem phim. Trong buổi họp giải pháp, một anh kiến trúc sư hệ thống (solution architect) nói: "Phần này mình sẽ deploy lên một cái VM trên AWS, dùng RDS cho database, còn xử lý ảnh poster thì để Lambda chạy serverless, gọi qua S3." Cả phòng gật gù. Riêng bạn — nếu không hiểu cloud — sẽ ngồi đó cười cho có lệ, rồi viết requirement mà không nắm được hệ quả về chi phí, bảo mật, hay tốc độ triển khai.
Đây chính là khoảng trống nguy hiểm nhất của BA hiện đại. Bạn không cần biết code hạ tầng, không cần dựng server, nhưng bạn BẮT BUỘC phải hiểu cloud đủ sâu để: (1) viết requirement khả thi về mặt kỹ thuật, (2) ước lượng được tác động chi phí của một quyết định nghiệp vụ, (3) nói cùng ngôn ngữ với dev và DevOps, và (4) đặt đúng câu hỏi khi thu thập yêu cầu phi chức năng (NFR) — thứ chúng ta sẽ học sâu ở Bài 34, nhưng phần lớn NFR ngày nay sống hoặc chết theo lựa chọn cloud.
Ở Việt Nam, làn sóng chuyển dịch lên cloud đang rất mạnh: ngân hàng, fintech, sàn thương mại điện tử, công ty bảo hiểm đều đang migrate hệ thống lên AWS, Azure, GCP hoặc cloud nội địa như Viettel Cloud, VNG Cloud, FPT Cloud, CMC Cloud. Một BA hiểu cloud sẽ là cầu nối quý giá giữa business và đội kỹ thuật. Bài này trang bị cho bạn nền tảng đó — vừa đủ, không lan man vào kỹ thuật sâu của dev.
Khái niệm cốt lõi
Cloud là gì, hiểu theo kiểu BA
Trước cloud, công ty muốn chạy hệ thống phải mua máy chủ vật lý đặt trong phòng server (on-premise), tự bảo trì, tự lo điện, làm mát, an ninh. Đầu tư lớn ngay từ đầu (CAPEX), mở rộng chậm. Cloud lật ngược mô hình này: bạn "thuê" tài nguyên tính toán của một nhà cung cấp lớn qua Internet, dùng bao nhiêu trả bấy nhiêu (OPEX — pay as you go). Cần thêm thì bật lên trong vài phút, không cần thì tắt đi để khỏi tốn tiền.
Với BA, ý nghĩa lớn nhất của cloud là độ linh hoạt (elasticity) và mô hình chi phí biến đổi. Khi bạn viết một requirement kiểu "hệ thống phải chịu được 50.000 người dùng đồng thời vào dịp sale 12/12", trên cloud điều này khả thi vì hệ thống có thể tự co giãn (auto-scaling). Nhưng nó cũng có cái giá — và bạn cần biết để cảnh báo stakeholder.
Ba tầng dịch vụ: IaaS, PaaS, SaaS
Đây là khái niệm xương sống của bài. Cách dễ nhớ nhất: hãy tưởng tượng việc "có một bữa ăn".
- On-premise = tự nấu ở nhà: bạn lo từ mua nguyên liệu, bếp, gas, nồi niêu đến rửa bát. Toàn quyền nhưng cực.
- IaaS (Infrastructure as a Service) = thuê bếp có sẵn: nhà cung cấp lo gian bếp, điện, gas; bạn tự mua nguyên liệu và tự nấu.
- PaaS (Platform as a Service) = mua nguyên liệu sơ chế sẵn và dùng bếp có sẵn: bạn chỉ việc nấu theo công thức của mình.
- SaaS (Software as a Service) = ra nhà hàng gọi món: ăn xong đứng dậy, không lo gì hết.
| Tầng | Bạn quản lý | Provider quản lý | Ví dụ |
|---|---|---|---|
| On-premise | Tất cả: phần cứng, mạng, OS, runtime, app, dữ liệu | Không gì cả | Server tự đặt trong data center riêng |
| IaaS | OS, runtime, ứng dụng, dữ liệu, cấu hình | Phần cứng, ảo hóa, mạng, lưu trữ vật lý | AWS EC2, Azure VM, Google Compute Engine, máy chủ ảo Viettel Cloud |
| PaaS | Ứng dụng và dữ liệu của bạn | Hạ tầng + OS + runtime + middleware | Heroku, AWS Elastic Beanstalk, Azure App Service, Google App Engine, AWS Lambda (serverless) |
| SaaS | Chỉ dữ liệu và cấu hình người dùng | Toàn bộ phần còn lại | Gmail, Salesforce, Jira Cloud, Microsoft 365, Base.vn, MISA |
Public, Private, Hybrid Cloud
Ngoài ba tầng dịch vụ, BA còn cần phân biệt mô hình triển khai:
- Public cloud: dùng chung hạ tầng của nhà cung cấp lớn (AWS, Azure, GCP). Rẻ, nhanh, co giãn tốt, nhưng dữ liệu nằm trên hạ tầng chia sẻ.
- Private cloud: hạ tầng dành riêng cho một tổ chức, có thể đặt nội bộ hoặc thuê riêng. Kiểm soát cao, hợp các ngành nhạy cảm như ngân hàng.
- Hybrid cloud: kết hợp cả hai — dữ liệu nhạy cảm để private, phần còn lại đẩy lên public. Rất phổ biến ở Việt Nam vì lý do tuân thủ.
Các nhà cung cấp lớn và bối cảnh Việt Nam
Ba ông lớn toàn cầu — AWS (Amazon Web Services), Azure (Microsoft), GCP (Google Cloud Platform) — chiếm phần lớn thị trường. Mỗi hãng có tên gọi dịch vụ khác nhau cho cùng một khái niệm, ví dụ máy chủ ảo: AWS gọi EC2, Azure gọi Virtual Machines, GCP gọi Compute Engine. BA không cần thuộc lòng từng dịch vụ, nhưng nên nhận diện được "đây là loại gì".
Điểm cực kỳ quan trọng với BA Việt Nam: chủ quyền dữ liệu (data sovereignty). Nghị định 13/2023/NĐ-CP về bảo vệ dữ liệu cá nhân và các quy định của Ngân hàng Nhà nước thường yêu cầu dữ liệu nhạy cảm (đặc biệt của khách hàng ngân hàng, tài chính) phải lưu trữ trong nước. Đây là lý do các cloud nội địa — Viettel Cloud, VNG Cloud, FPT Cloud, CMC Cloud — trở thành lựa chọn bắt buộc hoặc kết hợp cho nhiều dự án. Khi viết requirement, đừng bao giờ quên hỏi: "Dữ liệu này được phép đặt ở đâu về mặt pháp lý?"
Tình huống thực tế
Tình huống 1 — Startup giao đồ ăn chọn IaaS hay PaaS
Một startup giao đồ ăn ở TP.HCM (gọi là FoodFast) có 8 kỹ sư, cần ra mắt MVP trong 3 tháng. CTO ban đầu định thuê IaaS (EC2 trên AWS) để "toàn quyền kiểm soát". BA của dự án ngồi phân tích: với IaaS, đội phải tự lo cài đặt OS, vá lỗi bảo mật, cấu hình load balancer, set up database — ước tính tốn của 2 kỹ sư khoảng 30% thời gian chỉ để vận hành hạ tầng.
BA đề xuất chuyển sang PaaS (AWS Elastic Beanstalk + RDS managed database). Kết quả: đội không phải vận hành OS, được auto-scaling sẵn, tập trung 100% vào tính năng nghiệp vụ. Chi phí hạ tầng nhỉnh hơn IaaS khoảng 15% nhưng tiết kiệm được công sức tương đương 1 kỹ sư full-time — rẻ hơn nhiều so với lương kỹ sư.
Bài học rút ra: BA tạo giá trị không phải bằng việc chọn công nghệ "ngầu" nhất, mà bằng việc gắn lựa chọn cloud với ràng buộc thực tế của tổ chức — quy mô đội, thời gian ra thị trường, năng lực vận hành. Với startup nhỏ, PaaS thường thắng vì giảm gánh nặng vận hành.
Tình huống 2 — Ngân hàng và bài toán chủ quyền dữ liệu
Một ngân hàng thương mại cổ phần ở Hà Nội muốn xây dựng nền tảng phân tích hành vi khách hàng để gợi ý sản phẩm vay. Đội kỹ thuật mê các dịch vụ AI/ML mạnh mẽ của GCP. Nhưng BA, khi làm việc với bộ phận Compliance, phát hiện một ràng buộc cứng: dữ liệu định danh khách hàng (CMND/CCCD, số tài khoản, lịch sử giao dịch) bị yêu cầu lưu trữ trong lãnh thổ Việt Nam theo quy định của NHNN.
BA đề xuất một kiến trúc hybrid: dữ liệu nhạy cảm được lưu và xử lý trên FPT Cloud (data center trong nước), còn dữ liệu đã ẩn danh hóa (anonymized) mới được đẩy lên GCP để chạy mô hình ML. Requirement phi chức năng được viết rõ: "Mọi dữ liệu PII phải được lưu trữ tại data center trong lãnh thổ Việt Nam; chỉ dữ liệu đã ẩn danh hóa theo chuẩn X mới được phép xử lý trên hạ tầng cloud nước ngoài."
Bài học rút ra: Với ngành quy định chặt, ràng buộc pháp lý và bảo mật phải được phát hiện SỚM, ngay trong giai đoạn elicitation. Một BA giỏi luôn kéo Compliance vào bàn từ đầu, vì một quyết định cloud sai có thể khiến cả dự án phải làm lại từ con số không.
Tình huống 3 — Quyết định build-vs-buy với SaaS
Một chuỗi spa và thẩm mỹ viện 12 chi nhánh cần hệ thống quản lý lịch hẹn, khách hàng và kho mỹ phẩm. Ban giám đốc muốn "tự xây một phần mềm riêng cho oai". BA được giao phân tích.
BA dựng bảng so sánh: tự build (cần thuê đội dev, 6–9 tháng, chi phí hàng trăm triệu cộng chi phí bảo trì dài hạn) so với mua SaaS có sẵn (ví dụ một nền tảng quản lý spa theo mô hình thuê bao, triển khai trong 2 tuần, vài triệu/tháng). Phân tích chỉ ra rằng nghiệp vụ của spa này về cơ bản giống 90% các spa khác — không có lợi thế cạnh tranh nào nằm ở phần mềm đặt lịch. BA kết luận: dùng SaaS, dành tiền và thời gian cho marketing và trải nghiệm khách hàng thực tế.
Bài học rút ra: SaaS thường là lựa chọn đúng khi nghiệp vụ mang tính chuẩn hóa, không phải lợi thế cạnh tranh cốt lõi. BA cần tỉnh táo tách bạch "thứ làm nên sự khác biệt" (nên đầu tư build) khỏi "thứ ai cũng cần như nhau" (nên mua SaaS).
Hướng dẫn từng bước
Khi một dự án có yếu tố cloud xuất hiện, đây là quy trình BA nên đi qua:
- Xác định ràng buộc pháp lý và bảo mật trước tiên. Hỏi ngay: Dữ liệu thuộc loại gì (PII, tài chính, sức khỏe)? Có quy định bắt buộc lưu trong nước không? Cần tuân thủ chuẩn nào (Nghị định 13, PCI-DSS, ISO 27001)? Đây là bộ lọc cứng loại bỏ nhiều phương án ngay từ đầu.
- Làm rõ yêu cầu phi chức năng liên quan cloud. Bao nhiêu người dùng đồng thời? Có mùa cao điểm (sale, lễ Tết) không? Yêu cầu uptime (99,9% hay 99,99%)? Tốc độ phản hồi? Những con số này quyết định nhu cầu auto-scaling và mức SLA cần thương lượng.
- Đánh giá năng lực và quy mô đội. Đội có người vận hành hạ tầng không? Thời gian ra thị trường gấp đến đâu? Đây là yếu tố then chốt để cân nhắc IaaS (kiểm soát cao, gánh nặng lớn) so với PaaS/SaaS (nhanh, nhẹ vận hành).
- Hỗ trợ phân tích build-vs-buy. Với mỗi khối chức năng, hỏi: tính năng này có phải lợi thế cạnh tranh không? Nếu không và đã có SaaS tốt — nghiêng về mua.
- Ước lượng tác động chi phí ở mức nghiệp vụ. Bạn không cần tính chính xác hóa đơn, nhưng cần hiểu mô hình: pay-as-you-go nghĩa là chi phí biến đổi theo lưu lượng. Cảnh báo stakeholder về kịch bản "viral đột biến làm hóa đơn tăng vọt".
- Ghi rõ lựa chọn cloud vào tài liệu requirement và truy vết được. Quyết định "dùng PaaS X, lưu dữ liệu ở vùng Y" phải xuất hiện trong NFR và liên kết được tới ràng buộc nghiệp vụ đã dẫn đến nó — phục vụ traceability sau này.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm lẫn ba tầng dịch vụ. Nhiều BA mới gọi mọi thứ là "lên cloud" mà không phân biệt. Hệ quả là viết requirement mơ hồ. Mẹo: luôn tự hỏi "trong giải pháp này, ai chịu trách nhiệm vận hành phần nào?" để định vị đúng IaaS/PaaS/SaaS.
Lỗi 2 — Quên ràng buộc chủ quyền dữ liệu. Đây là lỗi đắt giá nhất ở Việt Nam. Chọn xong cloud nước ngoài rồi mới phát hiện luật không cho phép — phải làm lại. Mẹo: đưa câu hỏi "dữ liệu được phép đặt ở đâu?" thành mục bắt buộc trong checklist elicitation.
Lỗi 3 — Bỏ qua chi phí ẩn của mô hình pay-as-you-go. Chi phí truyền dữ liệu ra ngoài (egress), chi phí lưu trữ tăng dần, chi phí khi traffic đột biến — đều dễ bị bỏ sót. Mẹo: yêu cầu đội kỹ thuật/FinOps làm ước lượng chi phí theo kịch bản (bình thường, cao điểm) ngay từ giai đoạn thiết kế.
Lỗi 4 — Tin rằng "cloud thì luôn rẻ hơn". Không đúng. Với hệ thống tải ổn định, chạy 24/7 nhiều năm, on-premise hoặc reserved instance đôi khi rẻ hơn. Mẹo: đừng mặc định, hãy để con số quyết định.
Lỗi 5 — Lạm quyền sa vào quyết định kỹ thuật. BA không phải người chốt dùng EC2 hay Lambda. Mẹo: vai trò của bạn là làm rõ nhu cầu nghiệp vụ và ràng buộc, đưa ra trade-off để architect quyết định, không phải tự thiết kế hạ tầng.
Bài tập thực hành
- Phân loại dịch vụ. Cho danh sách sau, hãy phân loại từng cái vào IaaS / PaaS / SaaS: (a) Gmail, (b) AWS EC2, (c) Jira Cloud, (d) Azure App Service, (e) máy chủ ảo VNG Cloud, (f) Base.vn, (g) AWS Lambda. Viết một câu giải thích cho mỗi phân loại dựa trên "ai vận hành phần nào".
- Tình huống ra quyết định. Một sàn thương mại điện tử thời trang dự kiến có 4 đợt sale lớn mỗi năm, mỗi đợt lưu lượng tăng gấp 10 lần ngày thường. Hãy viết 3 yêu cầu phi chức năng liên quan đến cloud (gợi ý: auto-scaling, uptime, hiệu năng) và giải thích mỗi yêu cầu ảnh hưởng thế nào tới lựa chọn hạ tầng.
- Phân tích chủ quyền dữ liệu. Một ứng dụng telehealth (khám bệnh từ xa) muốn lưu hồ sơ sức khỏe và video tư vấn của bệnh nhân Việt Nam. Hãy liệt kê 5 câu hỏi bạn — với vai trò BA — cần đặt ra với bộ phận pháp chế trước khi đội kỹ thuật chọn nhà cung cấp cloud, và đề xuất một kiến trúc hybrid hợp lý.
- Build-vs-buy. Chọn một nghiệp vụ bất kỳ trong công ty/dự án bạn biết, lập bảng so sánh tự build so với mua SaaS theo 4 tiêu chí: thời gian triển khai, chi phí ban đầu, chi phí dài hạn, mức độ là-lợi-thế-cạnh-tranh. Đưa ra khuyến nghị cuối cùng.
Tóm tắt
- Cloud không phải chủ đề của riêng dev — BA hiểu cloud sẽ viết requirement khả thi hơn, nói cùng ngôn ngữ với đội kỹ thuật và bảo vệ dự án khỏi rủi ro pháp lý, chi phí.
- Ba tầng dịch vụ IaaS → PaaS → SaaS khác nhau ở chỗ "ai vận hành phần nào": càng xuống dưới càng nhẹ vận hành, nhanh triển khai, nhưng kém tùy biến hơn. Đây là trade-off cốt lõi.
- Phân biệt thêm public / private / hybrid cloud; hybrid rất phổ biến ở Việt Nam vì lý do tuân thủ.
- Ba ông lớn AWS, Azure, GCP cộng với cloud nội địa (Viettel, VNG, FPT, CMC) — lựa chọn thường bị chi phối bởi chủ quyền dữ liệu theo Nghị định 13 và quy định ngành.
- Quy trình BA: bắt đầu từ ràng buộc pháp lý/bảo mật, làm rõ NFR, đánh giá năng lực đội, hỗ trợ build-vs-buy, ước lượng tác động chi phí, và ghi lại quyết định có truy vết.
- Tránh năm lỗi kinh điển: nhầm ba tầng dịch vụ, quên chủ quyền dữ liệu, bỏ qua chi phí ẩn, mặc định "cloud luôn rẻ", và sa đà quyết định kỹ thuật vượt vai trò.