PMS trên đám mây hay tại chỗ: hướng dẫn quyết định cho khách sạn độc lập

Đâu là khác biệt thực sự giữa đám mây và triển khai tại chỗ?

Trong triển khai trên đám mây, ứng dụng và cơ sở dữ liệu chạy trong một môi trường do nhà cung cấp vận hành. Khách sạn truy cập qua trình duyệt hoặc máy khách gọn nhẹ. Sao lưu, vá lỗi và năng lực hệ thống thuộc trách nhiệm của nhà cung cấp. Phụ thuộc của khách sạn là đường mạng đến nhà cung cấp.

Trong triển khai tại chỗ, ứng dụng và cơ sở dữ liệu chạy trên máy chủ trong khách sạn. Khách sạn kiểm soát phần cứng, mạng và lịch nâng cấp. Sự phụ thuộc chuyển sang năng lực IT tại chỗ: phải có người chịu trách nhiệm về máy chủ, sao lưu và khung thời gian cập nhật.

Sản phẩm về mặt chức năng có thể giống hệt nhau. Điều thay đổi là nơi các kiểu lỗi trú ngụ.

Khi nào đám mây hợp lý hơn?

Đám mây thường là lựa chọn mặc định đúng cho khách sạn độc lập và các tập đoàn nhỏ. Nó loại bỏ máy chủ khỏi danh sách rủi ro của khách sạn, giúp báo cáo đa khách sạn trở nên đơn giản và giữ phần mềm luôn cập nhật mà không cần dự án mỗi năm.

Nó đặc biệt phù hợp khi khách sạn có đường kết nối ổn định, đội IT nhỏ và không có yêu cầu pháp lý phải giữ dữ liệu khách trong tòa nhà. Nó cũng phù hợp với các tập đoàn mở thêm khách sạn nhanh hơn khả năng xây dựng năng lực IT.

• Khách sạn có đường internet chính và dự phòng đáng tin cậy.
• Không có đội IT nội bộ chịu trách nhiệm về máy chủ và sao lưu.
• Tập đoàn muốn báo cáo hợp nhất mà không cần dự án kho dữ liệu.
• Khách sạn dự kiến bổ sung mô-đun hoặc phòng mà không cần lập kế hoạch phần cứng.

Khi nào triển khai tại chỗ vẫn hợp lý?

Triển khai tại chỗ không hề lỗi thời. Đây vẫn là lựa chọn trung thực khi không thể tin cậy mạng, khi dữ liệu phải ở lại một khu vực pháp lý hoặc một tòa nhà cụ thể, hoặc khi khách sạn có kỷ luật IT để vận hành đúng cách.

Sai lầm là chọn triển khai tại chỗ để tránh chi phí thuê đám mây trong khi đánh giá thấp chi phí vận hành: thay máy chủ, kiểm thử sao lưu, vá lỗi, điện năng và một người chịu trách nhiệm.

• Chính sách về nơi cư trú dữ liệu hoặc chủ sở hữu yêu cầu cơ sở dữ liệu phải ở tại khách sạn.
• WAN không ổn định và hệ thống cục bộ là cách duy nhất để quầy lễ tân tiếp tục làm việc.
• Khách sạn đã vận hành phòng máy chủ có kỷ luật với sao lưu được kiểm thử.
• Mô hình chi phí đầu tư ban đầu được ưu tiên và chi phí vòng đời đã được hiểu rõ.

Mô hình kết hợp thực sự có nghĩa là gì?

Mô hình kết hợp thường có nghĩa là một máy chủ tại khách sạn duy trì hoạt động cục bộ, với dữ liệu được đồng bộ về môi trường trung tâm để báo cáo và cung cấp dịch vụ tập đoàn. Nếu WAN mất, nhận phòng, hóa đơn phòng và buồng phòng vẫn tiếp tục cục bộ; khi kết nối trở lại, các giao dịch được đối chiếu.

Mô hình kết hợp phức tạp hơn cả hai mô hình thuần túy, vì việc đối chiếu giữa dữ liệu cục bộ và dữ liệu trung tâm phải được thiết kế. Sự phức tạp này đáng giá khi cả khả năng chịu lỗi cục bộ lẫn tầm nhìn trung tâm đều là yêu cầu thực sự.

Một thiết kế kết hợp chỉ đáng tin khi có người giải thích được, trên một trang giấy, điều gì xảy ra với một hóa đơn phòng được ghi trong thời gian WAN gián đoạn và nó được đối chiếu thế nào sau đó.

Nên so sánh tổng chi phí như thế nào?

Đừng so sánh giá thuê bao với giá máy chủ. Hãy so sánh chi phí sở hữu trong ba năm, bao gồm triển khai, giao diện, thay mới phần cứng, sao lưu và phục hồi, công sức nâng cấp, thời gian của nhân sự nội bộ và chi phí của một lần chốt sổ thất bại.

Một gói thuê bao đám mây trông đắt hơn theo tháng có thể lại rẻ hơn một triển khai tại chỗ cần máy chủ mới, hệ thống sao lưu và 20% thời gian của một nhân viên IT. Một triển khai tại chỗ trông rẻ có thể trở nên đắt đỏ ngay lần đầu cần phục hồi dữ liệu mà chưa ai kiểm thử.

• Công sức triển khai và di chuyển dữ liệu
• Phát triển và bảo trì giao diện
• Phần cứng, điện năng, làm mát và chu kỳ thay mới
• Sao lưu, kiểm thử phục hồi và vá lỗi bảo mật
• Thời gian nhân sự nội bộ cho nâng cấp và sự cố
• Rủi ro gián đoạn trong kiểm toán đêm và các khung giờ cao điểm đón khách

Dù chọn mô hình nào, hợp đồng nên bao gồm những gì?

Nhãn thương mại ít quan trọng hơn các cam kết vận hành. Hãy yêu cầu chúng bằng văn bản, bằng ngôn ngữ dễ hiểu, và bảo đảm chúng khớp với cách khách sạn của bạn thực sự vận hành.

• Ai sở hữu dữ liệu, và dữ liệu có thể được xuất ở định dạng dùng được như thế nào?
• Mục tiêu thời gian phục hồi và mục tiêu điểm phục hồi, cùng lần kiểm thử gần nhất.
• Giờ hỗ trợ, mục tiêu phản hồi và đường leo thang xử lý lúc 02:00.
• Điều gì xảy ra khi nâng cấp thất bại hoặc có sự cố bảo mật.
• Điều khoản chấm dứt: thời hạn báo trước, trích xuất dữ liệu, vận hành song song và xóa dữ liệu.
• Giao diện nào được bao gồm, giao diện nào tính phí và ai chịu trách nhiệm khi bên thứ ba gặp sự cố.

Quyết định triển khai thay đổi như thế nào theo quy mô khách sạn?

Ở quy mô 10–60 phòng, khách sạn thường không có phòng máy chủ và hiếm khi có nhân sự IT chuyên trách. Tổng giám đốc, chủ sở hữu hoặc quản lý trực ca là người gần nhất với vai trò hỗ trợ kỹ thuật, còn nhân viên lễ tân đảm nhận cả tiếp đón, đặt phòng và concierge trong cùng một ca. Trong bối cảnh đó, quyết định triển khai chủ yếu xoay quanh đường truyền mạng và việc ai là người nghe máy lúc 02:00. Điện toán đám mây là lựa chọn mặc định phổ biến vì loại bỏ máy chủ khỏi tòa nhà và để nhà cung cấp đảm nhận vá lỗi và sao lưu. Triển khai tại chỗ vẫn có cơ sở khi quy định pháp lý hoặc chính sách của chủ sở hữu buộc dữ liệu khách phải nằm trong khách sạn, hoặc khi đường truyền duy nhất hiện có không đủ tải cho quầy lễ tân. Dù chọn mô hình nào, hãy ghi rõ quầy lễ tân làm gì khi mất kết nối: những khách đến nào vẫn có thể xử lý, chìa khóa được cấp ra sao và các khoản phí được ghi nhận ở đâu cho đến khi có mạng trở lại. Một khách sạn nhỏ hiếm khi cần trung tâm dữ liệu thứ hai, nhưng cần một đường truy cập internet thứ hai và một người được chỉ định để gọi. Hãy viết quy trình ngoại tuyến trong một trang và kiểm thử vào một tuần ít khách, không phải vào dịp kín phòng.

Ở khoảng 60–250 phòng, khách sạn có thêm các bộ phận, giao diện tích hợp và mô hình ca làm việc. Lễ tân vận hành 24 giờ với 3 ca, và PMS kết nối với POS, khóa cửa, channel manager, thiết bị thanh toán và đôi khi cả hệ thống spa hoặc sân golf. Nhận phòng và night audit đều phụ thuộc vào các giao diện này, nên các kiểu lỗi tăng lên ngay cả khi phần mềm không thay đổi. Đây là nhóm quy mô mà mô hình kết hợp trở thành phương án thực tế thay vì một giải pháp thỏa hiệp: máy chủ tại chỗ giữ cho quầy lễ tân và các điểm bán hoạt động qua sự cố mạng WAN, trong khi dữ liệu đồng bộ về môi trường trung tâm để báo cáo. Đây cũng là nơi khách sạn thường có một nhân sự IT tổng hợp hoặc một nhà cung cấp dịch vụ quản lý, điều này thay đổi câu trả lời trung thực về triển khai tại chỗ. Vấn đề cần giải quyết không phải là đám mây hay tại chỗ, mà là chức năng nào phải tồn tại khi mất kết nối và chức năng nào có thể chờ. Nếu câu trả lời bao gồm nhận phòng, folio và housekeeping, kiến trúc phải phản ánh điều đó. Nếu chỉ báo cáo có thể chờ, triển khai đám mây với quy trình ngoại tuyến được ghi thành văn bản thường đơn giản hơn khi vận hành.

Trên 250 phòng, và tại các resort có nhiều tòa nhà, khách sạn vận hành như một khuôn viên nhỏ. Có nhiều điểm bán, phòng tiệc, khu giải trí, nhiều tủ phân phối cáp và một đội ca đêm có mặt trực tiếp tại chỗ thay vì trực gọi. Đường truyền internet dự phòng, phòng máy chủ có kiểm soát ra vào và một bộ phận IT là những kỳ vọng bình thường ở quy mô này, và quyết định triển khai trở thành một bài toán thiết kế: dịch vụ nào chạy tại chỗ, dịch vụ nào chạy tập trung, và hai bên đối soát thế nào khi một đường truyền gặp sự cố. Một resort cũng có thể phải tuân theo các quy định dữ liệu tại quốc gia nơi hoạt động, và một tập đoàn có thể muốn một lớp báo cáo chung cho các khách sạn nằm dưới những quy định khác nhau. Chính sự kết hợp đó là nơi mô hình kết hợp xứng đáng với độ phức tạp của nó, nhưng chỉ khi việc đối soát được quy định trước. Độ trễ tại quầy lễ tân, hành vi của thiết bị thanh toán trong quá trình chuyển đổi dự phòng và kênh hỗ trợ từ xa của nhà cung cấp đều cần được kiểm thử trước khi khai trương, chứ không chỉ là một đoạn trong hợp đồng. Nguồn điện và làm mát cho tủ rack tại chỗ cũng trở thành trách nhiệm của một ai đó, và trách nhiệm đó cần được nêu rõ trong mô hình vận hành.

Hãy xác định các ràng buộc quyết định trước khi so sánh sản phẩm. Thứ nhất, nghĩa vụ dữ liệu: liệu có luật, thỏa thuận nhượng quyền hoặc chính sách của chủ sở hữu nào buộc dữ liệu khách phải ở trong một khu vực pháp lý hoặc tại khách sạn hay không. Thứ hai, thực tế mạng: liệu có hai đường truyền thực sự độc lập và lần chuyển đổi dự phòng gần nhất được thực hiện khi nào. Thứ ba, trách nhiệm khôi phục: ai thực hiện khôi phục, bao lâu một lần và bằng chứng nào được lưu lại. Thứ tư, chi phí 3–5 năm trên cùng một phạm vi, bao gồm giao diện tích hợp, thay mới phần cứng và thời gian nhân sự chứ không chỉ dòng phí thuê bao. Thứ năm, lối thoát: một bản xuất dữ liệu dùng được trông như thế nào và thời gian chạy song song được phép là bao lâu. Năm câu trả lời này thường thu hẹp lựa chọn về một mô hình trước khi buổi demo diễn ra. Một cách làm hữu ích là viết câu trả lời cho từng ràng buộc trong một đoạn ngắn và yêu cầu nhà cung cấp phản hồi bằng văn bản thay vì bằng bài thuyết trình. Điều kiện biên là phép thử 02:00. Nếu không ai giải thích được ai được gọi, quầy lễ tân làm gì và các giao dịch bị thiếu được đối soát ra sao, thì nhãn trên hợp đồng sẽ không cứu được đêm đó.

• Quầy lễ tân có thể tiếp tục nhận khách trong 4 giờ mà không có WAN không?
• Có đường truyền internet thứ hai không, và việc chuyển đổi dự phòng đã được thực hiện trong năm nay chưa?
• Có luật hoặc chính sách của chủ sở hữu nào buộc dữ liệu khách phải lưu tại khách sạn không?
• Ai thực hiện kiểm thử khôi phục, và kết quả được ghi lại ở đâu?
• Chi phí 3–5 năm có được so sánh trên cùng phạm vi và giao diện tích hợp không?