Phân biệt on-premises, public/private/hybrid cloud và IaaS, PaaS, SaaS; lập bảng trách nhiệm, tính chi phí DEMO, chuẩn bị phục hồi và kế hoạch chuyển dữ liệu.
Một văn phòng muốn chuyển công cụ quản lý phiếu hỗ trợ lên cloud. Người phụ trách nghĩ rằng thuê dịch vụ đồng nghĩa không còn phải vá ứng dụng, sao lưu hoặc quản lý tài khoản. Nhóm khác muốn giữ mọi thứ tại chỗ vì cho rằng dữ liệu sẽ tự an toàn. Cả hai cách suy luận đều bỏ qua câu hỏi quan trọng: ai thực hiện từng trách nhiệm và bằng chứng nào xác nhận công việc đã hoàn tất?
Bài 051.3, Giải pháp tại chỗ và điện toán đám mây, tham chiếu Open Source Essentials 050-100 trang in 38–51, viết độc lập và đối chiếu ngày 23/10/2026. Bạn cần hiểu client/server và thành phần phần mềm. Sau bài học, bạn nên phân loại mô hình dịch vụ, lập bảng trách nhiệm, nhận biết chi phí và kiểm tra kế hoạch phục hồi.
On-premises mô tả hạ tầng tại cơ sở của tổ chức. Không phải văn phòng nào cũng có một datacenter hoàn chỉnh; có thể chỉ có tủ máy nhỏ hoặc thuê dịch vụ hoàn toàn. Remote hosting chuyển nơi đặt máy ra ngoài nhưng chưa đủ để kết luận đó là cloud. Cần xem khả năng cấp phát, quản lý và đo lường dịch vụ.
NIST SP 800-145 nêu năm đặc trưng: tự phục vụ theo yêu cầu, truy cập qua mạng, dùng chung nguồn lực, co giãn nhanh và đo lường sử dụng. Public cloud cung cấp cho công chúng; private cloud dành riêng một tổ chức và có thể ở ngoài cơ sở. Community cloud phục vụ một cộng đồng có yêu cầu chung. Hybrid kết hợp các hạ tầng cloud riêng biệt có cơ chế liên kết.
Trong giao tiếp công việc, “hybrid” cũng thường được dùng rộng cho kết nối hệ thống tại chỗ với cloud. Khi viết hồ sơ, hãy mô tả các thành phần thực tế thay vì dựa vào nhãn: ứng dụng ở đâu, dữ liệu ở đâu, đường truy cập nào và bên nào vận hành. Một máy chủ thuê cố định với quy trình thủ công có thể là hosting, dù quảng cáo dùng từ cloud.
Không đồng nhất cloud với mọi máy ảo chia sẻ phần cứng. EC2 Dedicated Hosts là ví dụ dịch vụ cloud có máy vật lý dành riêng. Dùng máy riêng cũng chưa tự bảo đảm an toàn cho tài khoản, cấu hình hoặc ứng dụng. Việc chọn kiểu tài nguyên phải gắn với nhu cầu và điều kiện dịch vụ cụ thể.
IaaS cung cấp tài nguyên hạ tầng để khách hàng triển khai hệ điều hành và ứng dụng. PaaS cung cấp nền tảng chạy ứng dụng, giảm phần hệ thống bên dưới mà khách hàng trực tiếp quản lý. SaaS cung cấp ứng dụng sẵn dùng. Bảng trách nhiệm của Microsoft cho thấy dữ liệu, danh tính, cấu hình và quyền truy cập vẫn cần khách hàng quản lý theo phạm vi dịch vụ.
PaaS không có nghĩa mọi thư viện của ứng dụng đều được nhà cung cấp chọn và vá thay. Nếu nhóm đưa dependency của mình lên, cần xác định ai cập nhật nó. Serverless cũng không có nghĩa không tồn tại server; người sử dụng làm việc ở mức trừu tượng cao hơn. Xem tài liệu dịch vụ để biết runtime, giới hạn và trách nhiệm cụ thể.
Managed database là dịch vụ quản lý cơ sở dữ liệu theo phạm vi công bố. Đừng gọi mọi nơi lưu dữ liệu là database: Amazon S3 là object storage. Nó có thể chứa tệp xuất từ database nhưng không tự trở thành một SQL server.
Tại chỗ thường có mua sắm, bảo trì, điện, chỗ đặt máy, nhân sự và khả năng dư tải. Cloud thường có chi phí tài nguyên, dung lượng, truy cập dữ liệu, truyền tải, hỗ trợ và vận hành của khách hàng. Không thể khẳng định lựa chọn nào luôn rẻ hơn chỉ từ một đơn giá máy ảo. Cần tính cùng nhu cầu, cùng thời gian và cùng mức phục hồi mong đợi.
Bảng dự toán nên tách chi phí một lần với chi phí định kỳ; ghi đơn vị cho từng dòng. Dung lượng GB và truyền tải GB là hai hạng mục khác nhau dù cùng đơn vị. Một tài nguyên đã dừng xử lý cũng có thể còn thành phần lưu trữ hoặc dịch vụ khác cần trả phí. Không áp dụng suy luận “không dùng CPU thì hóa đơn bằng không” cho mọi sản phẩm.
AWS Budgets có cảnh báo chi phí thực tế hoặc dự báo, nhưng dữ liệu và thông báo có độ trễ. Đặt cảnh báo không tự tạo một giới hạn chi tiêu cứng tức thời. Nếu cần hành động tự động, phải hiểu cơ chế, quyền và ảnh hưởng trước khi cấu hình. Lab bên dưới không mở console hoặc thay đổi ngân sách thật.
Hãy bắt đầu bằng hai câu hỏi có thể kiểm tra: người dùng chấp nhận gián đoạn bao lâu và có thể mất tối đa bao nhiêu dữ liệu đã ghi? Chúng giúp thảo luận mục tiêu phục hồi theo thời gian và điểm dữ liệu, nhưng giá trị phải do tổ chức xác định. Không chép một con số từ ví dụ thành cam kết dịch vụ.
Nhiều bản sao ở các vị trí khác nhau chỉ hữu ích nếu ứng dụng biết chuyển sang nơi còn hoạt động và dữ liệu phù hợp. Replication cũng có thể sao chép thao tác xóa nhầm, nên không thay thế mọi nhu cầu sao lưu. Để đánh giá phục hồi, cần thử lấy đúng dữ liệu, mở bằng ứng dụng phù hợp và ghi thời gian cùng các phụ thuộc.
Địa điểm lưu dữ liệu là một thuộc tính cần ghi nhận cùng tài khoản quản trị, khóa mã hóa, bản sao, log và quyền hỗ trợ của nhà cung cấp. Chọn một region không tự chứng minh đáp ứng mọi nghĩa vụ pháp lý. Bài này không kết luận luật nào bắt buộc đặt dữ liệu ở đâu; hồ sơ có dữ liệu nhạy cảm cần được người có trách nhiệm của tổ chức đánh giá.
Nguồn mở có thể giúp kiểm tra mã và lựa chọn nơi chạy, nhưng việc chuyển đi còn phụ thuộc định dạng dữ liệu, API, dependency và giấy phép. Không chỉ hỏi “có export không”; hãy hỏi export gồm trường nào, có attachment và lịch sử không, import bằng gì, thời gian ngừng bao lâu và ai giữ quyền tải về khi kết thúc hợp đồng.
Giả sử nhóm nhỏ quản lý phiếu nội bộ, không chứa dữ liệu cá nhân. Tạo tài liệu riêng với bốn mục: workload, trách nhiệm, dự toán và phục hồi. Đây là tình huống học tập tự biên soạn, chưa phản ánh dịch vụ đã mua hoặc triển khai.
Ghi hai ca sử dụng: đọc phiếu trong giờ làm và xuất báo cáo cuối tháng. Giả định dữ liệu mẫu nhỏ, một người quản trị và chưa có yêu cầu đa vùng. Liệt kê điều chưa biết: số người đồng thời, tăng trưởng attachment, thời gian gián đoạn chấp nhận được. Chưa có các dữ liệu này thì chỉ lập phương án sơ bộ.
Đề xuất ba lựa chọn minh họa: tự vận hành máy tại chỗ, thuê VM IaaS hoặc dùng một ứng dụng SaaS phù hợp. Không chấm điểm sản phẩm có thật khi chưa nghiên cứu điều khoản. Kết quả mong đợi là ba phương án đều phục vụ cùng ca sử dụng; không so một máy đơn giản với gói nhiều chức năng rồi kết luận từ giá.
Tạo các dòng “vá hệ điều hành”, “cập nhật ứng dụng”, “tắt tài khoản nghỉ việc”, “kiểm tra quyền chia sẻ” và “thử phục hồi dữ liệu”. Với phương án VM, nhóm khách hàng cần người xử lý OS và ứng dụng theo phạm vi quản lý đã chọn. Với SaaS giả định, để dòng OS thuộc nhà cung cấp, nhưng giữ quản trị người dùng và cấu hình chia sẻ ở phía khách hàng.
Dòng nào chưa có thông tin thì ghi “cần xác minh”, kèm câu hỏi và người sẽ tìm câu trả lời. Không điền “nhà cung cấp” chỉ vì dịch vụ nằm ngoài văn phòng. Tiêu chí đạt là không còn công việc quan trọng bị bỏ trống giữa hai phía; đây là kiểm tra tính đầy đủ của hồ sơ, chưa xác nhận hợp đồng thật.
Dùng đơn vị học tập DEMO, không phải tiền hay bảng giá của bất kỳ nhà cung cấp nào. Giả định 20 giờ xử lý với mức 0,08 DEMO/giờ; 10 GB-tháng lưu trữ với 0,02 DEMO/GB-tháng; 5 GB truyền ra với 0,03 DEMO/GB. Tổng lần lượt là 1,60 + 0,20 + 0,15 = 1,95 DEMO.
Nếu quên tắt workload và số giờ thành 200, giữ các giả định khác, tổng thành 16,35 DEMO. Phần chênh 14,40 DEMO chỉ minh họa tác động của thời gian. Nó không dự báo hóa đơn thật: còn thiếu thuế, lưu lượng request, mức miễn phí, cam kết sử dụng hoặc quy tắc tính của sản phẩm cụ thể.
Bản kiểm chứng dùng Python Decimal để kiểm lại các phép tính này; không gọi API cloud và không phát sinh tài nguyên. Người học có thể tính bằng giấy hoặc bảng tính. Nếu tổng khác, kiểm tra dấu thập phân, đơn vị và số giờ trước; tránh sửa đơn giá chỉ để khớp kết quả mong muốn.
Giả sử người dùng đăng nhập thất bại nhưng trang công khai vẫn mở. Ghi ít nhất ba giả thuyết: danh tính bị khóa, cấu hình xác thực sai hoặc dịch vụ phụ thuộc gặp lỗi. Chọn bằng chứng ít tác động: thông báo đã khử dữ liệu riêng, thời gian, phạm vi người bị ảnh hưởng và trạng thái dịch vụ. Chưa có bằng chứng thì không gọi đây là mất toàn bộ cloud.
Tình huống thứ hai: cần rời nhà cung cấp. Liệt kê bản xuất, schema, attachment, công cụ nhập và người giữ quyền truy cập. Đánh dấu “chưa thử import” nếu chưa thực hiện. Kết quả mong đợi là một danh sách thử phục hồi có thể giao việc, không phải lời khẳng định dữ liệu đã di chuyển an toàn.
Bài tập đã được rà soát logic và tính đúng các số DEMO. Chưa kiểm thử tài khoản, khả dụng, phục hồi hoặc chi phí của dịch vụ cloud thật. Các kết luận về hiệu quả năng lượng hay phát thải cũng cần phạm vi và dữ liệu đo riêng; không mặc định cloud luôn tốt hơn hoặc xấu hơn cho mọi workload.
Chọn chat, email, issue, ticket và tài liệu theo mục tiêu; hiểu federation, wiki, CMS, DMS, rồi lập báo cáo, ghi chú quyết định và dàn ý tài liệu DEMO.
Phân biệt Git với nền tảng hosting, working tree, index, commit, branch và tag; thực hành nhánh, fast-forward, tag và revert trong repository riêng.
Phân biệt IDE, build, linter, debugger, các loại test và môi trường CI/CD; chạy lab Node để thấy cú pháp hợp lệ vẫn có thể sai hành vi rồi khôi phục.
Nhận diện maintainer, contributor, quản trị và tài trợ; đọc DCO, CLA, quy tắc ứng xử, rồi soạn phản hồi đóng góp tài liệu qua tình huống DEMO riêng.