Làm xong ứng dụng mới là lúc bắt đầu: chi phí vận hành và bảo trì thực sự gồm những gì

Ra mắt không phải điểm kết thúc của chi phí, mà là điểm bắt đầu

Báo giá phát triển ứng dụng thường dừng lại ở ngày ra mắt. Nhưng thời điểm tiền thật sự bắt đầu chảy ra lại là ngày hôm sau. Một ứng dụng đã phát hành nằm trên nền môi trường liên tục thay đổi, và nếu không chỉnh sửa theo môi trường đó thì đến một lúc nào đó nó sẽ ngừng chạy. Vận hành và bảo trì không phải hạng mục tùy chọn, đó là điều kiện để ứng dụng còn sống.

Khi lập ngân sách, chi phí phát triển tương đối dễ hình dung. Có số lượng màn hình, có danh sách tính năng, có thời gian, nên quy ra con số được. Ngược lại, chi phí vận hành thì bản thân các hạng mục đã khó nhìn thấy. Không biết cái gì sẽ phát sinh thì nó được ghi bằng số không trong bảng ngân sách, và hạng mục ghi số không sẽ quay lại vài tháng sau khi ra mắt dưới dạng khoản chi ngoài kế hoạch.

Chi phí sau ra mắt dễ sắp xếp hơn nếu chia thành bốn nhánh có tính chất khác nhau. Thứ nhất là những việc bảo trì bắt buộc, không làm thì ứng dụng dừng. Thứ hai là chi phí hạ tầng tăng theo số người dùng và lượng dữ liệu. Thứ ba là thời gian con người bỏ ra để trả lời người dùng và sửa lỗi. Thứ tư là tính năng mới và cải tiến. Điểm quan trọng là ba nhánh đầu vẫn phát sinh dù bạn không thêm một tính năng nào.

Trên thực tế, nhiều bên đặt hàng chỉ coi nhánh thứ tư là bảo trì khi ký hợp đồng. Từ đó dẫn tới suy nghĩ rằng thời gian tới chưa có kế hoạch làm tính năng mới nên cũng chưa cần bảo trì. Nếu bỏ ba nhánh đầu ra ngoài thì nghe có vẻ hợp lý, nhưng ứng dụng vẫn cũ đi ngay cả khi không có tính năng mới. Để yên không có nghĩa là nó đứng nguyên, mà là mọi thứ xung quanh di chuyển còn nó thì tụt lại.

Yeowubie Interaction vừa phát triển sản phẩm cho khách hàng vừa tự vận hành sản phẩm của mình. Dịch vụ quản lý chấm công onSpots có mặt trên cả App Store và Google Play, chạy bằng ba ngôn ngữ tiếng Hàn, tiếng Việt và tiếng Anh. Dịch vụ tuyển dụng Job Connect VN tại thị trường Việt Nam và Langtori, nền tảng kết nối người học tiếng Hàn với người dạy, cũng được vận hành theo cách tương tự. Những hạng mục viết dưới đây không phải danh sách dựng lên để thuyết phục bên đặt hàng, mà là danh sách chúng tôi tự xử lý hằng tháng.

Bài viết này không nói về số tiền. Mức chi phí chênh lệch rất lớn tùy theo tính chất ứng dụng, quy mô người dùng và tốc độ phản hồi được yêu cầu, nên một con số khái quát chỉ làm nhiễu phán đoán. Thay vào đó, bài viết sắp xếp lại từng hạng mục phát sinh vì lý do gì và trước khi ký hợp đồng thì nên hỏi những gì.

Những việc không làm thì ứng dụng sẽ dừng: cập nhật hệ điều hành, chính sách cửa hàng, gia hạn chứng chỉ

Có những việc bắt buộc phải làm dù bạn không tạo thêm một tính năng nào. Hệ điều hành lên phiên bản mới, tiêu chuẩn xét duyệt của cửa hàng ứng dụng thay đổi, và chứng chỉ dùng để ký ứng dụng hết hạn. Bỏ mặc ba thứ này thì bạn sẽ không tải lên được bản dựng mới, lượt cài đặt mới bị chặn, hoặc ứng dụng của người đã cài bị văng giữa chừng.

iOS và Android ra phiên bản lớn theo từng năm. Khi phiên bản lên, các quy tắc nền tảng như cách xử lý quyền, chạy nền, hoạt động của thông báo, truy cập tệp đều đổi. Mã nguồn giữ nguyên nhưng môi trường chạy đã khác, nên tính năng hôm qua còn hoạt động có thể dừng lại. Ứng dụng càng dùng camera, vị trí, Bluetooth hay đồng bộ nền thì càng chịu ảnh hưởng lớn. Thêm vào đó, nếu thư viện mã nguồn mở đang dùng không hỗ trợ phiên bản mới thì phải thay thư viện, và đó là một khối lượng công việc riêng.

Cả hai cửa hàng đều liên tục cập nhật tiêu chuẩn mà ứng dụng phải tuân thủ. Những điểm hay gặp gồm mức SDK mà bản dựng phải nhắm tới, cách công bố chính sách quyền riêng tư, việc khai báo các loại dữ liệu thu thập, việc cung cấp đường dẫn xóa tài khoản, và cách xử lý thanh toán. Nội dung cụ thể của các yêu cầu này cùng thời điểm áp dụng thay đổi khá thường xuyên, vì vậy xin đừng lấy phần mô tả trong bài này làm chuẩn: trước khi tải bản dựng lên, hãy kiểm tra yêu cầu tại thời điểm đó trong tài liệu chính thức dành cho nhà phát triển của từng cửa hàng. Không đáp ứng được tiêu chuẩn thì bản dựng bị từ chối, và trong một số trường hợp mức hiển thị của ứng dụng hiện có cũng bị hạn chế.

Để đưa ứng dụng lên cửa hàng thì cần chữ ký, và chứng chỉ cùng khóa dùng để ký đều có thời hạn. Bản thân tài khoản nhà phát triển cũng thuộc diện phải gia hạn. Khóa dùng cho thông báo đẩy, khóa dùng để tích hợp bản đồ hay thanh toán cũng vậy. Chu kỳ và quy trình gia hạn khác nhau tùy chính sách nền tảng và đôi khi thay đổi giữa chừng, nên cách an toàn là ghi ngày hết hạn vào lịch và kiểm tra hướng dẫn chính thức ở từng thời điểm. Lỡ hạn thì việc phát hành bị chặn, và ngay cả khi muốn xử lý gấp cũng mất vài ngày chỉ để tìm ra người đang giữ quyền tài khoản.

Trong nhóm này, sự cố khó cứu vãn nhất là làm mất khóa ký ứng dụng. Khóa ký của Android gần như là danh tính của chính ứng dụng, nên nếu không định trước cách lưu giữ và đường khôi phục thì có thể rơi vào tình huống không tải lên được bản cập nhật. Kiểu sự cố lặp đi lặp lại trong thực tế là tài khoản và khóa vẫn đứng tên cá nhân một nhân sự của bên phát triển cho tới khi hợp đồng kết thúc. Mục 5 sẽ nói lại chuyện này, nhưng đây không phải vấn đề kỹ thuật mà là vấn đề hợp đồng.

Các dịch vụ bên ngoài mà ứng dụng đang gắn vào cũng thuộc diện phải duy trì vì lý do tương tự. Bản đồ, đăng nhập mạng xã hội, thanh toán, thông báo đẩy, gửi tin nhắn, công cụ phân tích đều nâng phiên bản API của riêng họ và đóng phiên bản cũ. Thông báo ngừng hỗ trợ thường được đưa ra trước nhiều tháng, nhưng nếu không có ai đọc thì đến ngày đóng, tính năng sẽ chết lặng lẽ. Vận hành không chỉ gồm việc sửa mã, mà còn gồm việc đọc những thông báo như vậy và đưa vào lịch làm việc.

Máy chủ và hạ tầng: những khoản tăng theo số người dùng

Chi phí máy chủ không phải một giá trị cố định được ấn định lúc làm ứng dụng, mà là biến số dịch chuyển theo mức sử dụng. Người dùng tăng thì phần tính toán, cơ sở dữ liệu, dung lượng lưu trữ, lưu lượng truyền tải, nhật ký và số lượng thông báo gửi đi cũng tăng theo. Cái gì tăng nhanh tới mức nào thì phụ thuộc vào cấu trúc ứng dụng, và cấu trúc đó được quyết định ngay trong giai đoạn phát triển.

Nhìn vào những dòng thực sự xuất hiện trên hóa đơn thì thường là như sau. Thời gian tính toán của máy chủ, dung lượng và thông lượng cơ sở dữ liệu, dung lượng lưu ảnh và tệp, lưu lượng đi ra ngoài, dung lượng lưu nhật ký và giám sát, dung lượng lưu bản sao dự phòng, số lượt gửi thông báo đẩy, tin nhắn và email, cùng các API bên ngoài tính phí theo số lần gọi như bản đồ hay xác thực. Bên cạnh đó là những khoản cố định hằng năm không liên quan tới quy mô, chẳng hạn tên miền và tài khoản nhà phát triển của cửa hàng ứng dụng.

Những điểm làm lệch ngân sách thì gần như luôn giống nhau. Thứ nhất là ảnh và video do người dùng tải lên. Nếu lưu nguyên bản gốc rồi trả về nguyên bản gốc thì chi phí lưu trữ và chi phí truyền tải cùng nhảy lên. Thứ hai là nhật ký. Để nguyên mức ghi chi tiết vốn bật lên nhằm gỡ lỗi thì lượng lưu trữ âm thầm chất đống. Thứ ba là xác thực bằng tin nhắn. Vì tính phí theo từng tin nên số người đăng ký tăng bao nhiêu thì nó tăng đúng bấy nhiêu, và khi có các lượt đăng ký tự động thì nó vọt lên ngoài dự tính.

Phần miễn phí của dịch vụ đám mây và các dịch vụ bên ngoài cũng là chỗ cần lưu ý. Giai đoạn đầu hầu hết vẫn nằm trong hạn mức miễn phí nên trông như thể chi phí hạ tầng gần bằng không. Ngay khi vượt hạn mức thì bắt đầu tính phí, và thời điểm đó thường trùng đúng lúc bạn đang vui vì người dùng tăng. Nếu không đặt sẵn cảnh báo ngân sách và giới hạn mức sử dụng thì bạn chỉ biết chuyện sau khi nhận hóa đơn.

Phần lớn cách giảm chi phí vận hành nằm ở giai đoạn thiết kế chứ không phải sau khi ra mắt. Những quyết định như có thu nhỏ kích thước ảnh trước khi lưu hay không, có lưu đệm dữ liệu hay đọc nhiều hay không, viết truy vấn danh sách thế nào, dọn dữ liệu cũ vào lúc nào đều làm thay đổi hẳn độ lớn của khoản chi hằng tháng. Ở giai đoạn đặt hàng, chỉ cần hỏi bên phát triển đang thiết kế với mục tiêu chi phí vận hành hằng tháng ở mức nào là đủ để thấy họ có cân nhắc phần này hay không.

Ngược lại, có những khoản không nên cắt. Quy trình sao lưu và khôi phục, theo dõi lỗi, giám sát trạng thái cơ bản rõ ràng là chi phí, nhưng bỏ đi thì chỉ một sự cố cũng quay lại với cái giá lớn hơn nhiều. Sao lưu không kết thúc ở chỗ đã tạo được bản sao: hạng mục này bao gồm cả thời gian kiểm tra xem bản sao đó có khôi phục được thật hay không. Một bản sao chưa từng được khôi phục thử thì khó có thể nói là đang tồn tại.

Thời gian con người dành cho hỗ trợ người dùng và sửa lỗi

Trong chi phí sau ra mắt, khoản lớn nhất thường không phải máy chủ mà là thời gian con người. Đọc câu hỏi, tái hiện lỗi, tìm nguyên nhân, sửa, kiểm tra xem có làm hỏng tính năng khác không, phát hành, rồi chờ cửa hàng xét duyệt. Một sửa đổi chỉ dài một dòng cũng kéo theo trọn vẹn quy trình này.

Web thì sửa xong là áp dụng ngay trong ngày. Ứng dụng di động thì khác. Phải tạo bản dựng, tải lên cửa hàng, vượt qua xét duyệt, và sau khi vượt qua rồi thì người dùng còn phải nhận bản cập nhật. Người không cập nhật sẽ ở lại phiên bản cũ. Vì vậy trong vận hành di động, người ta chuẩn bị sẵn đường xử lý những việc phải sửa ngay mà không cần phát hành lại ứng dụng. Cấu hình được máy chủ trả về, công tắc để tắt riêng một tính năng, cấu trúc quản lý câu chữ từ phía máy chủ chính là những thiết bị đó. Đưa vào ngay từ đầu thì lúc gấp bạn tiết kiệm được vài ngày.

Chỗ hao thời gian con người nhiều nhất là những lỗi không tái hiện được. Chỉ với một dòng phản hồi rằng thỉnh thoảng không đăng nhập được, muốn tìm nguyên nhân thì phải thu hẹp dần theo thiết bị, phiên bản hệ điều hành, mạng, trạng thái tài khoản. Gắn sẵn báo cáo sự cố và theo dõi lỗi thì quá trình này rút từ vài giờ xuống vài phút. Đây là trường hợp điển hình mà chi phí công cụ rẻ hơn thời gian con người.

Câu hỏi của người dùng không chỉ đến từ một nơi. Chúng phân tán qua đánh giá trên cửa hàng, biểu mẫu liên hệ trong ứng dụng, email, số điện thoại đại diện của công ty, tin nhắn gửi cho nhân viên kinh doanh. Điều cần chốt khi ký hợp đồng là ai tiếp nhận đầu tiên. Việc nhân sự chăm sóc khách hàng của bên đặt hàng nhận trước rồi chỉ chuyển các vấn đề kỹ thuật sang bên phát triển, hay bên phát triển nhận ngay từ đầu, sẽ làm khối lượng công việc hai bên khác hẳn nhau. Không chốt trước thì những lời phàn nàn trong phần đánh giá cứ chất đống mà không ai đọc.

Cam kết tốc độ phản hồi tới đâu thì chính là chi phí tới đó. Trả lời vào ngày làm việc kế tiếp và phản hồi trong một khung giờ ấn định bao gồm cả cuối tuần lẫn ban đêm đòi hỏi hai cách bố trí nhân sự khác nhau. Không có lý do gì phải xử lý mọi câu hỏi ở cùng một tốc độ, nên tốt hơn cho cả hai phía là đừng xếp sự cố chặn thanh toán và lỗi chính tả trên màn hình vào cùng một cấp. Ghi rõ cách phân loại mức khẩn cấp và thời gian phản hồi mục tiêu cho từng cấp vào hợp đồng sẽ giảm hẳn tranh cãi về sau.

Ứng dụng phục vụ nhiều ngôn ngữ thì việc hỗ trợ cũng phải bằng đúng những ngôn ngữ đó. Điều chúng tôi nhận ra khi vận hành onSpots bằng tiếng Hàn, tiếng Việt và tiếng Anh là bản dịch không dừng lại ở màn hình. Câu trả lời cho người dùng, phần mô tả trên cửa hàng, thông báo, thậm chí thông điệp lỗi đều phải giữ cùng một chất lượng, và phần đó cũng tốn thời gian con người. Nếu ứng dụng nhắm tới cả thị trường Việt Nam lẫn Hàn Quốc thì đưa hạng mục này vào ngân sách ngay từ đầu sẽ sát thực tế hơn.

Phạm vi bảo trì cần thống nhất trước khi ký hợp đồng

Với bảo trì, chốt phạm vi trước rồi mới hỏi giá thì hợp lý hơn. Phạm vi khác nhau thì việc đặt các báo giá cạnh nhau để so sánh vốn đã không thành lập. Dưới đây là những mục bên đặt hàng nên kiểm tra khi đọc hợp đồng và đề xuất. Làm việc với bất kỳ nhà thầu nào, bạn cũng chỉ cần hỏi đúng những câu này.

Trước hết là thời hạn bảo hành miễn phí và định nghĩa thế nào là lỗi. Việc không chạy đúng theo tiêu chí nghiệm thu đã thống nhất là lỗi, còn hành vi được yêu cầu mới sau khi đã nghiệm thu là cải tiến. Ranh giới này mà không có trong văn bản thì suốt vài tháng đầu sau ra mắt, hai bên sẽ tranh luận một cách hao mòn. Cũng nên nhớ rằng phải còn giữ tài liệu yêu cầu và tiêu chí nghiệm thu thì mới phân biệt được.

Hình thức hợp đồng bảo trì cũng là mục cần kiểm tra. Có cách xử lý một phạm vi ấn định theo tháng, cách quyết toán theo thời gian thực tế bỏ ra, và cách báo giá theo từng vụ việc, mỗi cách phù hợp với một hoàn cảnh khác nhau. Ứng dụng ít thay đổi và chạy ổn định thì tính theo vụ việc sẽ nhẹ nhàng, còn nếu có kế hoạch chỉnh sửa liên tục thì trọn gói hoặc quyết toán theo giờ dễ quản lý hơn. Dù chọn cách nào, điểm cốt lõi vẫn là liệt kê thành danh sách những việc được bao gồm và những việc không được bao gồm.

Đặc biệt cần ghi rõ những việc bảo trì bắt buộc đã nói ở mục 2 có nằm trong phạm vi bảo trì hay không. Việc xử lý phiên bản lớn của hệ điều hành, xử lý thay đổi chính sách cửa hàng, gia hạn chứng chỉ và khóa, xử lý việc API bên ngoài đóng phiên bản cũ nằm trong hợp đồng cơ bản hay tính riêng sẽ làm gánh nặng thực tế khác hẳn. Nếu những mục này hoàn toàn không xuất hiện trong hợp đồng thì bản thân điều đó đã là chỗ cần hỏi.

Xin hãy ghi rõ cả việc ai chịu chi phí hạ tầng và thanh toán theo cách nào. Cần chốt trước là bên phát triển ứng trước tiền dịch vụ đám mây rồi xuất hóa đơn lại, hay khoản đó trừ thẳng từ tài khoản của bên đặt hàng, và khi mức sử dụng vượt dự tính thì ai là người báo trước. Các khoản tính theo mức sử dụng thay đổi từng tháng, nên gộp cứng vào một số tiền cố định thì sẽ có những tháng một trong hai bên chịu thiệt.

Quyền sở hữu tài khoản và tài sản là mục thường được kiểm tra sau cùng nhưng lại quan trọng nhất. Tài khoản đám mây, tài khoản nhà phát triển trên cửa hàng, tên miền, khóa ký, kho mã nguồn, tài khoản dịch vụ bên ngoài đứng tên ai thì phải ghi lại thành văn bản. Đặt tên bên đặt hàng rồi ủy quyền vận hành cho bên phát triển là hình thức ít rắc rối về sau.

Cuối cùng là cách kết thúc. Hãy ghi rõ khi chấm dứt hợp đồng thì mã nguồn và tài liệu được bàn giao dưới dạng nào, một nhà thầu khác có dựng được đúng bản dựng đó từ mã nguồn ấy hay không, hỗ trợ chuyển giao kéo dài mấy tuần, và thông báo chấm dứt phải gửi trước bao nhiêu ngày. Hợp đồng có phần này rành mạch không phải là văn bản để chia tay, mà là văn bản dễ làm việc lâu dài. Bên đã mở sẵn lối ra cho đối tác thường là bên làm việc tử tế hơn.

Trình tự chúng tôi khuyên khá đơn giản. Khi nhận báo giá phát triển, hãy hỏi luôn các hạng mục vận hành trong cùng một văn bản, phác ra gánh nặng của trọn một năm dù chỉ ở mức ước lượng, rồi mới chốt phạm vi phát triển. Ứng dụng làm được và ứng dụng nuôi được là hai chuyện khác nhau. Chúng tôi cũng đang xử lý đúng những hạng mục này hằng tháng cho sản phẩm của chính mình, nên nếu bạn phân vân nên sắp xếp từ mục nào trước thì cứ hỏi thoải mái.