Tự xây, mua sẵn hay thuê dịch vụ quản trị: khung ra quyết định cho hệ thống nội bộ

Mỗi hệ thống nội bộ — cổng phê duyệt chi phí, kho dữ liệu báo cáo, lớp xác thực dùng chung, hệ thống theo dõi đơn hàng — đều bắt đầu bằng cùng một cuộc họp. Một bên nói nên tự viết vì yêu cầu quá đặc thù. Một bên nói nên mua phần mềm có sẵn vì nhanh hơn. Một bên thứ ba, thường là người đang phải trực đêm, nói rằng vấn đề không nằm ở chỗ ai viết mà ở chỗ ai sẽ vận hành nó trong năm năm tới. Cả ba đều có lý, và cuộc họp thường kết thúc bằng lựa chọn của người nói thuyết phục nhất chứ không phải bằng một khung phân tích.

Bài viết đề xuất một khung bốn trục để tách quyết định ra khỏi cảm tính: mức độ khác biệt chiến lược, tổng tải vận hành, độ sâu tích hợp, và chi phí rời bỏ. Bốn trục này không cho ra một điểm số duy nhất và cũng không nên. Chúng cho bạn bốn câu trả lời độc lập, và khi bốn câu trả lời mâu thuẫn nhau thì chính sự mâu thuẫn đó mới là thông tin đáng giá nhất.

Ba lựa chọn thật sự là gì

Trước khi so sánh, cần định nghĩa rõ ba lựa chọn, vì trong thực tế chúng hay bị mô tả sai.

• Tự xây nghĩa là đội của bạn viết mã, sở hữu mã, và chịu trách nhiệm cho toàn bộ vòng đời: kiến trúc, kiểm thử, phát hành, giám sát, vá lỗi bảo mật, nâng cấp thư viện phụ thuộc, và xử lý sự cố lúc hai giờ sáng. Tự xây không kết thúc ở ngày go-live; đó mới là ngày bắt đầu phần tốn kém.
• Mua sẵn nghĩa là bạn trả tiền cho một sản phẩm đã tồn tại, chấp nhận mô hình dữ liệu và quy trình của nó, và đổi lấy việc không phải bảo trì lõi. Bạn vẫn phải cấu hình, tích hợp, phân quyền, đào tạo người dùng và quản lý nhà cung cấp — đây là phần chi phí hay bị bỏ quên nhất.
• Thuê dịch vụ quản trị nghĩa là phần mềm hoặc hạ tầng có thể vẫn là của bạn, nhưng trách nhiệm vận hành thường trực nằm ở một bên khác theo cam kết dịch vụ. Bạn vẫn giữ quyết định kiến trúc và dữ liệu; bạn chuyển giao công việc lặp lại, trực ca và ứng cứu sự cố.

Ba lựa chọn không loại trừ nhau. Một hệ thống hoàn toàn có thể được mua sẵn ở phần lõi, tự xây ở lớp tích hợp đặc thù, và thuê quản trị ở tầng hạ tầng bên dưới. Trên thực tế đây là kết cấu phổ biến nhất ở các tổ chức đã đi qua vài chu kỳ đầu tư.

Trục 1: Hệ thống này có tạo ra khác biệt cạnh tranh không?

Câu hỏi không phải là hệ thống này có quan trọng hay không. Bảng lương rất quan trọng, nhưng không có khách hàng nào chọn bạn vì bảng lương của bạn tốt hơn đối thủ. Câu hỏi đúng là: nếu hệ thống này chỉ ở mức trung bình của ngành, doanh nghiệp có mất đi lợi thế nào không?

Một cách kiểm tra thẳng thắn: hãy tưởng tượng đối thủ trực tiếp của bạn mua đúng sản phẩm bạn định mua và cấu hình y hệt. Nếu điều đó không làm bạn khó chịu, hệ thống này không phải chỗ để tự xây. Nếu điều đó thật sự làm bạn mất một thứ gì đó — cách bạn định giá, cách bạn định tuyến đơn hàng, cách bạn chấm điểm rủi ro tín dụng, một quy trình nghiệp vụ mà khách hàng cảm nhận được — thì đó là ứng viên hợp lý cho việc tự xây.

Phần lớn hệ thống nội bộ trượt bài kiểm tra này. Điều đó không có nghĩa chúng tầm thường; nó chỉ có nghĩa là giá trị của chúng nằm ở việc hoạt động ổn định, không nằm ở việc khác biệt.

Trục 2: Tổng tải vận hành, không chỉ chi phí xây dựng

Sai lầm phổ biến nhất trong các bài toán so sánh là đặt chi phí phát triển một lần cạnh phí thuê bao hằng năm. Hai con số đó không cùng loại. Chi phí xây dựng là một sự kiện; tải vận hành là một dòng chảy kéo dài bằng đúng tuổi thọ hệ thống.

Tải vận hành gồm những hạng mục sau, và bạn nên ước lượng từng hạng mục bằng số giờ người mỗi tháng thay vì bằng tiền, vì giờ người mới là thứ đội của bạn thật sự không thể tạo thêm:

• Giám sát, cảnh báo và xử lý cảnh báo giả.
• Vá lỗi bảo mật cho hệ điều hành, thư viện phụ thuộc và môi trường chạy — kể cả những bản vá khẩn cấp không nằm trong kế hoạch.
• Nâng cấp phiên bản lớn, thứ luôn tốn nhiều hơn dự tính vì kéo theo kiểm thử hồi quy.
• Sao lưu, kiểm tra khôi phục thật (không phải chỉ kiểm tra rằng tệp sao lưu tồn tại), và diễn tập thảm họa.
• Quản lý truy cập: cấp quyền, thu hồi quyền khi nhân sự rời đi, rà soát định kỳ.
• Trực ca ngoài giờ và ứng cứu sự cố.
• Trả lời câu hỏi của người dùng nội bộ, thứ không bao giờ xuất hiện trong bảng ước lượng ban đầu.

Khi cộng lại, nhiều đội phát hiện rằng hệ thống họ tự xây tiêu tốn phần lớn năng lực kỹ thuật chỉ để đứng yên tại chỗ. Đó là chi phí thật, và nó cạnh tranh trực tiếp với những việc tạo ra doanh thu.

Trục 3: Độ sâu tích hợp

Độ sâu tích hợp đo mức độ hệ thống này phải hiểu về phần còn lại trong doanh nghiệp bạn. Một công cụ đứng riêng, nhận dữ liệu qua tệp CSV hằng đêm, có độ sâu thấp. Một hệ thống phải đọc ghi trực tiếp vào cơ sở dữ liệu nghiệp vụ chính, chia sẻ phiên đăng nhập, tuân theo quy tắc phân quyền nội bộ và phản ứng theo thời gian thực với sự kiện từ hệ thống khác thì có độ sâu rất cao.

Độ sâu cao đẩy cán cân theo hai hướng trái ngược nhau cùng lúc, và đây là chỗ nhiều tổ chức mắc kẹt. Nó đẩy về phía tự xây, vì sản phẩm có sẵn hiếm khi khớp với mô hình dữ liệu riêng của bạn. Nhưng nó cũng làm tăng mạnh chi phí rời bỏ ở trục thứ tư, vì mỗi điểm tích hợp là một sợi dây phải cắt sau này.

Một lối thoát thực dụng: giữ độ sâu tích hợp ở lớp bạn kiểm soát. Mua hoặc thuê phần lõi, rồi tự xây một lớp mỏng chuyển đổi giữa mô hình dữ liệu của nhà cung cấp và mô hình của bạn. Lớp mỏng đó là mã bạn sở hữu, nhỏ, dễ kiểm thử, và là thứ bạn giữ lại được khi thay nhà cung cấp.

Trục 4: Chi phí rời bỏ

Trục này gần như luôn bị bỏ qua ở thời điểm quyết định và luôn được nhớ đến vào lúc tệ nhất. Chi phí rời bỏ là công sức cần bỏ ra để gỡ lựa chọn hôm nay và thay bằng lựa chọn khác, tính bằng thời gian, rủi ro gián đoạn và số hệ thống phải sửa theo.

Hãy hỏi bốn câu trước khi ký hợp đồng hoặc trước khi viết dòng mã đầu tiên:

1. Dữ liệu ra đi ở định dạng nào, và ai giữ tài liệu mô tả định dạng đó?
2. Có bao nhiêu hệ thống khác sẽ phải sửa nếu hệ thống này biến mất?
3. Kiến thức vận hành nằm ở đâu — trong tài liệu, trong mã, hay trong đầu hai người?
4. Nếu nhà cung cấp tăng giá mạnh hoặc ngừng sản phẩm, kế hoạch thay thế mất bao lâu?

Điều đáng chú ý là tự xây không tự động cho chi phí rời bỏ thấp. Một hệ thống tự viết, không tài liệu, chỉ một người hiểu, dùng thư viện đã ngừng bảo trì, có chi phí rời bỏ cao hơn nhiều so với một sản phẩm thương mại có API xuất dữ liệu rõ ràng.

Đặt bốn trục cạnh nhau

Trục	Nghiêng về tự xây khi	Nghiêng về mua sẵn khi	Nghiêng về dịch vụ quản trị khi
Khác biệt chiến lược	Cách làm riêng của bạn là thứ khách hàng cảm nhận được	Đây là năng lực chuẩn của ngành	Khác biệt nằm ở độ tin cậy chứ không ở tính năng
Tổng tải vận hành	Đội có năng lực dư và tải vận hành thấp	Tải vận hành chuyển được sang nhà cung cấp phần mềm	Tải cao, liên tục, cần trực ngoài giờ
Độ sâu tích hợp	Rất sâu và đặc thù, không sản phẩm nào khớp	Nông, trao đổi dữ liệu theo lô là đủ	Sâu ở tầng hạ tầng nhưng chuẩn ở tầng ứng dụng
Chi phí rời bỏ	Bạn chấp nhận trả giá để giữ toàn quyền kiểm soát	Dữ liệu xuất được và ranh giới rõ ràng	Hợp đồng có điều khoản bàn giao và trả dữ liệu

Vì sao lựa chọn tự xây thường không sống qua năm thứ hai

Đây là phần trung thực nhất của khung này. Quan sát lặp đi lặp lại trong thực tế: quyết định tự xây hiếm khi sai ở năm thứ nhất và rất hay sai ở năm thứ hai. Lý do không nằm ở kỹ thuật.

Năm thứ nhất, hệ thống có một chủ sở hữu nhiệt tình, có ngân sách riêng, có sự chú ý của lãnh đạo, và mã còn mới nên chưa mang nợ kỹ thuật. Năm thứ hai, người chủ sở hữu chuyển sang dự án khác hoặc rời công ty, ngân sách bị gộp vào chi phí vận hành chung, lãnh đạo đã chuyển sự chú ý sang việc mới, và các thư viện phụ thuộc bắt đầu đòi nâng cấp. Hệ thống không hỏng; nó chỉ dần trở thành thứ không ai muốn chạm vào.

Những lý do thường được dùng để biện minh cho việc tự xây cũng ít khi trụ được:

• Yêu cầu của chúng ta quá đặc thù. Thường thì chỉ một phần nhỏ yêu cầu là thật sự đặc thù, phần còn lại là thói quen. Hãy tách riêng phần đặc thù đó ra và hỏi liệu nó có đáng để tự xây toàn bộ những thứ bao quanh hay không.
• Tự xây rẻ hơn. Đúng khi so chi phí phát triển với phí thuê bao, sai khi cộng thêm tải vận hành ở trục 2 trong toàn bộ vòng đời.
• Chúng ta muốn kiểm soát. Kiểm soát là thật, nhưng kiểm soát mà không có người duy trì thì chỉ còn là trách nhiệm.
• Đội sẽ học được nhiều. Đội sẽ học, nhưng doanh nghiệp phải hỏi liệu bài học đó có nằm trong lĩnh vực bạn muốn giỏi hay không.

Cách kiểm tra đơn giản: viết ra tên cụ thể của người sẽ chịu trách nhiệm hệ thống này vào tháng thứ hai mươi bốn, rồi hỏi chính người đó ngay bây giờ. Nếu không ai trả lời được, lựa chọn tự xây chưa được ra quyết định — nó mới chỉ được hoãn lại.

Khi nào câu trả lời đúng là giữ mọi thứ trong nhà

Khung này không dẫn đến kết luận rằng nên thuê ngoài. Có những trường hợp giữ trong nhà là lựa chọn đúng, và cần nói thẳng ra.

• Hệ thống chạm vào phần khác biệt cạnh tranh cốt lõi và bạn cần tốc độ thay đổi cao hơn bất kỳ hợp đồng nào cho phép.
• Đội của bạn đã có năng lực vận hành thật, có quy trình trực ca bền vững, và hệ thống mới không làm vỡ quy trình đó.
• Ràng buộc pháp lý hoặc chính sách nội bộ khiến việc cấp quyền truy cập cho bên thứ ba tạo ra nhiều rủi ro hơn là giảm rủi ro.
• Quy mô đủ lớn để chi phí đơn vị của việc tự vận hành thấp hơn rõ rệt, và bạn có đủ nhân sự để duy trì điều đó ngay cả khi vài người rời đi.

Nếu ba trong bốn điều trên đúng với bạn, hãy giữ trong nhà và đầu tư vào tài liệu cùng quy trình thay vì đi tìm nhà cung cấp. Một quyết định thuê ngoài được đưa ra chỉ để né tránh việc xây dựng năng lực nội bộ thường quay lại dưới dạng một hợp đồng khó thoát.

Chạy quyết định này trong hai tuần

Khung phân tích chỉ có ích nếu nó kết thúc. Một cách làm gọn: tuần thứ nhất, viết một trang duy nhất cho mỗi trục, mỗi trang có người chịu trách nhiệm cụ thể. Tuần thứ hai, họp một lần để đọc bốn trang cùng nhau, ghi lại điểm mâu thuẫn, và chọn. Nếu bốn trang không đủ để quyết định, vấn đề là phạm vi hệ thống chưa rõ chứ không phải thiếu dữ liệu.

Ghi lại quyết định kèm ngày rà soát lại — thường là mười hai đến mười tám tháng. Ở lần rà soát đó, câu hỏi không phải là chúng ta có sai không, mà là giả định nào đã thay đổi. Quy mô, đội ngũ và bối cảnh thị trường đều thay đổi, và một quyết định đúng ở năm đầu hoàn toàn có thể cần đảo chiều ở năm thứ ba.

HiTechCloud có thể hỗ trợ gì

HiTechCloud cung cấp dịch vụ phát triển phần mềm và dịch vụ quản trị hạ tầng, là đối tác của AWS và Google Premier Partner, đồng thời vận hành hạ tầng đặt trong nước cho các khách hàng có yêu cầu về vị trí dữ liệu. Nếu bạn đang ở giữa quyết định tự xây, mua sẵn hay thuê quản trị, chúng tôi có thể tham gia ở bước phân tích bốn trục cùng đội của bạn, ước lượng tải vận hành thực tế cho phương án tự xây, và nêu rõ phần nào nên giữ trong nội bộ. Trong nhiều trường hợp, kết luận hợp lý là bạn tự vận hành và chúng tôi chỉ hỗ trợ một phần hẹp, hoặc không tham gia — và đó là kết luận chúng tôi sẵn sàng nói ra.