So sánh hosting, SaaS, tư vấn và hỗ trợ; đọc ToS, SLO, SLA, phân công bảo mật, kiểm tra phục hồi và khả năng xuất dữ liệu qua hai phương án DEMO.
Một văn phòng cần hệ thống tiếp nhận yêu cầu hỗ trợ. Hai đơn vị cùng chào dịch vụ dựa trên một ứng dụng nguồn mở, nhưng một bên chỉ cho thuê máy chủ, bên kia vận hành ứng dụng và hỗ trợ người dùng. So sánh phí tháng sẽ bỏ sót phần việc mà đội IT phải tự làm. Câu hỏi cần trả lời trước là: mỗi bên đang nhận trách nhiệm nào, và bằng chứng nào xác nhận điều đó?
Bài 054.2, Mô hình kinh doanh của nhà cung cấp dịch vụ, tham chiếu Open Source Essentials 050-100 trang in 164–177, biên soạn độc lập và đối chiếu ngày 23/10/2026. Kiến thức tiên quyết gồm các mô hình cloud, quyền giấy phép và SLI/SLO/SLA ở những bài trước. Môi trường thực hành là bảng đánh giá với dữ liệu DEMO, không cần mua dịch vụ hoặc gửi dữ liệu thật.
Sau bài học, bạn có thể phân biệt các dòng doanh thu, đọc phạm vi dịch vụ, phân công trách nhiệm và chuẩn bị phương án rời nhà cung cấp. Kết quả cần nộp là hồ sơ quyết định có những câu hỏi còn bỏ ngỏ, thay vì một điểm số tưởng như chính xác.
Hosting cung cấp chỗ chạy phần mềm; mức quản lý cụ thể phụ thuộc gói. Một máy ảo có hệ điều hành chưa đồng nghĩa với ứng dụng đã được cập nhật, dữ liệu đã được sao lưu hoặc có người trực xử lý sự cố. Với SaaS, khách hàng sử dụng ứng dụng có sẵn, nhưng vẫn phải quản lý người dùng, dữ liệu và các cấu hình thuộc quyền mình.
Tư vấn có thể bán khảo sát, thiết kế hoặc chuyển đổi hệ thống. Đào tạo bán thời gian giảng dạy và tài liệu trong phạm vi thỏa thuận. Hỗ trợ có thể tính theo tài khoản, số yêu cầu, giờ làm hoặc subscription. Doanh nghiệp phần cứng có thể bán thiết bị cài phần mềm nguồn mở kèm bảo hành, cập nhật và dịch vụ triển khai.
Nguồn thu còn có quảng cáo, hoa hồng giao dịch hoặc quyên góp cho nội dung mở. Mỗi mô hình tạo động lực khác nhau. Với quảng cáo, cần xem dữ liệu được thu thập và chia sẻ ra sao; việc phần mềm quảng cáo có source không chứng minh rằng hoạt động theo dõi của dịch vụ ít xâm phạm quyền riêng tư.
Đối với nội dung mở, một đơn vị có thể thu phí lớp học, bản in hoặc công việc biên tập dù người dùng có quyền truy cập nội dung theo giấy phép. Điều kiện của từng nội dung vẫn cần được kiểm tra. Không suy ra rằng mọi tài liệu tải được đều cho phép bán lại hoặc chuyển thể.
Tự vận hành cho phép đội IT trực tiếp quyết định cấu hình và lịch thay đổi, trong giới hạn kỹ năng, thiết bị và giấy phép. Đổi lại, nhóm cần người xử lý cập nhật, giám sát, sao lưu, phục hồi và bàn giao khi nhân sự nghỉ việc. Một máy chủ rẻ có thể đi kèm nhiều giờ công chưa được tính.
Thuê dịch vụ có thể chuyển một phần công việc sang đội chuyên môn. Điều đó cần được xác nhận bằng phạm vi hợp đồng, khả năng thực tế và đầu mối hỗ trợ. Không mặc định rằng hosting loại bỏ rủi ro, luôn rẻ hơn hoặc đáp ứng sẵn mọi quy định của tổ chức.
Microsoft mô tả trách nhiệm cloud thay đổi theo IaaS, PaaS và SaaS; dữ liệu, tài khoản và kiểm soát truy cập vẫn có phần việc của khách hàng. Đây là ví dụ cụ thể để luyện cách đọc, không phải ma trận áp dụng nguyên xi cho mọi nhà cung cấp.
Khi so sánh, hãy viết từng công việc bằng động từ: ai tạo tài khoản, ai vá ứng dụng, ai duyệt quyền hỗ trợ, ai thử phục hồi? Nếu câu trả lời là “hai bên phối hợp”, cần nêu bước chuyển giao và người có quyền quyết định. Trách nhiệm chung mà không có quy trình dễ trở thành khoảng trống khi sự cố xảy ra.
Giấy phép phần mềm quy định các quyền đối với mã và những điều kiện liên quan. ToS, tức điều khoản dịch vụ, có thể quy định việc sử dụng hệ thống được cung cấp, thanh toán, đình chỉ tài khoản hoặc chấm dứt dịch vụ. AUP mô tả hành vi sử dụng được chấp nhận. Chúng trả lời những câu hỏi khác nhau; không dùng ToS thay cho việc kiểm tra license.
Việc sử dụng phần mềm nguồn mở không ngăn nhà cung cấp thu tiền dịch vụ hoặc bán bản sao theo điều kiện giấy phép. Cấp phép kép cần đủ quyền cấp các lựa chọn tương ứng. Khách hàng và nhà cung cấp không thể chỉ thỏa thuận riêng để xóa nghĩa vụ của mã bên thứ ba mà họ không sở hữu quyền thích hợp.
Với copyleft, cần xác định phiên bản, sửa đổi và hành vi cung cấp phần mềm. Chạy dịch vụ mạng và chuyển giao binary là các tình huống cần đọc riêng; không khẳng định mọi dịch vụ đều phải công bố toàn bộ hệ thống. Bài về copyleft đã tách GPL và AGPL. Hồ sơ mua dịch vụ nên ghi câu hỏi cần chuyên gia xem xét thay vì tự đưa ra kết luận pháp lý.
Các gói còn có thể gồm extension, giao diện, tài liệu hoặc dịch vụ độc quyền. Có source của lõi chưa bảo đảm khách hàng có quyền dùng mọi tính năng ở bản đang được chào. Tên community hay enterprise là đầu mối để hỏi tiếp, chưa đủ để kết luận quyền.
Google SRE phân biệt SLI, SLO và SLA. Trong hồ sơ đánh giá, ghi chỉ số đo, mục tiêu, cửa sổ đánh giá và hệ quả thỏa thuận. Một SLO tự nó không tạo khoản bồi thường hoặc cam kết hợp đồng.
“Phản hồi trong bốn giờ làm việc” có thể chỉ là thời điểm tiếp nhận và phân loại ticket. Nó không có nghĩa lỗi đã được sửa trong bốn giờ, cũng không chứng minh ứng dụng luôn khả dụng. Hãy hỏi múi giờ, ngày phục vụ, mức ưu tiên và cách liên hệ khi cổng ticket không hoạt động.
Nếu nhà cung cấp nêu tỷ lệ khả dụng, cần đọc phạm vi thành phần, cách đo, thời gian bảo trì, ngoại lệ và thủ tục yêu cầu xử lý khi không đạt. Chưa có định nghĩa thì hai con số giống nhau vẫn có thể mô tả hai mức dịch vụ khác nhau.
Một bản đánh giá bảo mật có phạm vi và thời điểm. Nó có thể cung cấp bằng chứng hữu ích nhưng không xác nhận mọi phiên bản, cấu hình hoặc quy trình vận hành đều an toàn. Yêu cầu nhà cung cấp giải thích phát hiện liên quan đã được xử lý ra sao, thay vì chỉ ghi nhận một logo hoặc tên chứng nhận.
Các câu hỏi thực tế gồm phương thức xác thực quản trị, quyền nhân viên hỗ trợ, nhật ký truy cập, cập nhật dependency và quy trình báo sự cố. Với dữ liệu, cần biết loại nào được lưu, mục đích, thời gian giữ và bên nào có thể xử lý. Mã hóa đường truyền không tự trả lời câu hỏi ai được xem dữ liệu sau khi giải mã.
Thỏa thuận xử lý dữ liệu cần được đánh giá theo vai trò, hoạt động và yêu cầu áp dụng của tổ chức. Không mặc định một quy định nước ngoài áp dụng cho mọi văn phòng hoặc một mẫu DPA đủ cho mọi tình huống. Chuyển câu hỏi pháp lý tới người phụ trách có thẩm quyền, kèm sơ đồ dữ liệu và điều khoản thực tế.
Tạo hồ sơ giả định cho mười nhân viên, dữ liệu ticket chỉ là chuỗi DEMO, giờ hỗ trợ theo lịch văn phòng. Yêu cầu bắt buộc gồm phân quyền quản trị, sao lưu có bằng chứng phục hồi và khả năng xuất dữ liệu dùng được. Không tạo tài khoản thật hoặc tải log công ty lên dịch vụ để làm bài.
Phương án A cung cấp máy ảo; khách hàng quản lý ứng dụng và bản sao lưu. Phương án B vận hành ứng dụng, nhưng báo giá chưa nói rõ phục hồi và xuất tệp đính kèm. Hai mô tả này là fixture do bài viết đặt ra, không phải sản phẩm hoặc lời chào hàng thật.
| Công việc | A, máy ảo | B, ứng dụng được quản lý |
|---|---|---|
| Vá ứng dụng | Khách hàng | Nhà cung cấp theo fixture |
| Thu hồi tài khoản nhân viên | Khách hàng | Khách hàng yêu cầu và kiểm tra |
| Thử phục hồi dữ liệu | Khách hàng tổ chức | Chưa đủ thông tin |
| Xuất ticket và tệp đính kèm | Khách hàng thiết kế | Chưa đủ thông tin |
Kết quả mong đợi là nhìn thấy hai khoảng trống của B và khối lượng tự làm của A. Không đánh dấu “đạt” cho một chức năng chỉ vì chưa thấy điều khoản cấm. Ghi người cần trả lời và bằng chứng mong muốn cho từng ô còn thiếu.
Viết ba câu hỏi: bản sao lưu có bao gồm tệp đính kèm không; lần phục hồi được kiểm chứng gần nhất dùng phạm vi nào; định dạng xuất có giữ liên kết giữa ticket và tệp không? Sau đó thêm câu hỏi về chi phí và thời gian thực hiện khi chấm dứt dịch vụ.
Đáp án tốt mô tả đầu ra cần quan sát: số bản ghi, tệp đọc được và quan hệ dữ liệu có thể đối chiếu. Một thông báo “đã bật backup” chưa chứng minh các đầu ra này. Bài tập mới chuẩn bị tiêu chí; chưa thực hiện phục hồi trên bất kỳ dịch vụ nào.
Có thể đề xuất tiếp tục đánh giá B nếu câu trả lời đáp ứng các yêu cầu bắt buộc. Nếu chưa có bằng chứng, trạng thái là chờ làm rõ, không tự chuyển thành đạt nhờ giá thấp. Với A, phải xác nhận đội IT có người và thời gian nhận những công việc được liệt kê.
Bổ sung chi phí chuyển đổi, vận hành, hỗ trợ và rời dịch vụ vào cùng một khoảng thời gian so sánh. Phần chi phí chưa biết giữ nguyên là chưa biết. Không điền số tự nghĩ để tạo tổng chi phí có vẻ đầy đủ. Hồ sơ này chưa phải phê duyệt mua hàng.
Lỗi phổ biến là xem license mở như lời bảo đảm vận hành; so tỷ lệ SLA mà bỏ cách tính; hoặc nhận bản xuất dữ liệu mà không kiểm tra khả năng sử dụng. Khi gặp thiếu thông tin, quay lại phạm vi và đầu ra cần chứng minh. Nếu có dữ liệu nhạy cảm hoặc điều khoản chưa rõ, chuyển hồ sơ cho người phụ trách thay vì tự cam kết.
Tự trả lời: ai vá ứng dụng ở A; vì sao B chưa đạt yêu cầu phục hồi; phản hồi ticket khác giải quyết lỗi thế nào; và ToS khác license ở đâu? Câu trả lời cần trỏ về công việc, bằng chứng hoặc điều khoản cụ thể.
Khung mục tiêu: LPI Open Source Essentials 054.2. Phần trách nhiệm cloud đối chiếu Microsoft Learn; thuật ngữ mức dịch vụ đối chiếu Google SRE tại các liên kết trong bài. Giá, điều khoản và bằng chứng của nhà cung cấp phải được kiểm tra lại tại thời điểm lựa chọn.
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.