Có thể “tự phát triển” các công cụ xử lý sự cố không?

Thực trạng về “nợ kỹ thuật” và “chi phí vận hành” trong việc phát triển công cụ nội bộ

Các đội ngũ kỹ sư càng giỏi thì càng có xu hướng đi đến kết luận rằng: “Với chức năng ở mức độ này, tự chúng tôi phát triển sẽ nhanh hơn và tiết kiệm chi phí hơn”. Tuy nhiên, việc tự phát triển công cụ không chỉ đòi hỏi khối lượng công việc phát triển có thể nhìn thấy được mà còn đi kèm với những chi phí ẩn khổng lồ và rủi ro trong vận hành.

Chúng tôi đã tổng hợp 3 khía cạnh cần xem xét để không cản trở sự phát triển cốt lõi của doanh nghiệp.

1. “Cơ hội bị bỏ lỡ” trong nguồn lực phát triển: Tập trung vào sự khác biệt hóa

Thời gian làm việc của các kỹ sư là một trong những nguồn lực quý giá nhất đối với doanh nghiệp. Việc dành thời gian làm việc cho các công cụ tự phát triển đồng nghĩa với việc phải gác lại “công tác phát triển trực tiếp mang lại giá trị cho khách hàng”.

• Tránh các công việc nặng nhọc không tạo ra sự khác biệt: Dù có hoàn thiện cơ sở hạ tầng nội bộ và các công cụ vận hành đến mức nào đi chăng nữa, những yếu tố này hiếm khi đóng góp trực tiếp vào việc tăng doanh số sản phẩm hay nâng cao mức độ hài lòng của khách hàng (CS).

• Tối đa hóa ROI: Lợi ích lớn nhất khi triển khai SaaS là có thể giúp các kỹ sư tập trung 100% vào những công việc tạo ra lợi thế cạnh tranh, chẳng hạn như “phát triển thuật toán độc quyền của công ty” hay “phát triển các tính năng mới”.

2. Chi phí không liên tục trong “giai đoạn vận hành”

Giữa việc “có được nguyên mẫu hoạt động trong vòng 2 tuần” và việc “tiếp tục vận hành như một dịch vụ quan trọng đối với hoạt động của doanh nghiệp” tồn tại một khoảng cách rất lớn.

• Giám sát tình trạng hoạt động 24 giờ mỗi ngày, 365 ngày mỗi năm: Chính trong những lúc dịch vụ của công ty gặp sự cố ngừng hoạt động, các công cụ vận hành mới phải hoạt động bình thường. Việc tự duy trì hệ thống dự phòng và cơ chế giám sát để đảm bảo điều này sẽ tốn kém vô cùng.

• Bảo mật và tuân thủ: Các hoạt động “phát triển phòng thủ” ngoài lĩnh vực kinh doanh chính sẽ diễn ra liên tục, bao gồm việc tuân thủ các tiêu chuẩn bảo mật tương đương SOC2, xử lý ngay lập tức các lỗ hổng bảo mật và triển khai quản lý quyền truy cập (IAM).

• Gánh nặng trong việc theo kịp công nghệ: Chẳng hạn, đối với các công cụ sử dụng LLM hay RAG, cần phải có nguồn nhân lực chuyên trách để liên tục cập nhật các mô hình nền tảng và theo kịp những thay đổi về thông số kỹ thuật của thư viện.

3. Mô phỏng chi phí giữa việc phát triển nội bộ và triển khai SaaS

Trên thực tế, khi tính toán chi phí trong trường hợp 2 kỹ sư tự phát triển nội bộ, kết quả sẽ như sau.

Con số này chưa bao gồm lợi nhuận kinh doanh mà kỹ sư đó lẽ ra có thể tạo ra (lợi nhuận cơ hội bị mất). Ngoài ra, cũng cần phải tính đến những rủi ro như “việc vận hành phụ thuộc vào cá nhân” hay “tài liệu trở nên hình thức” do người phụ trách nghỉ việc.

Kết luận: Chính việc ứng phó với sự cố mới là “nền tảng chuyên môn”

Mục tiêu của các công cụ tự phát triển thường chỉ dừng lại ở việc “hoạt động được”, nhưng giá trị thực sự của một công cụ ứng phó sự cố nằm ở chỗ “dù trong tình huống tồi tệ nhất khi công ty đang rơi vào tình trạng hoảng loạn, công cụ đó vẫn tiếp tục hoạt động với các thiết lập tối ưu và giữ được sự bình tĩnh hơn bất kỳ ai ”.

Đúng như câu nói “Chuyên môn thì để cho người chuyên môn”, việc tách nền tảng vận hành ra thành một dịch vụ chuyên biệt (Incident Lake) không chỉ đơn thuần là để cắt giảm chi phí. Đó là một khoản đầu tư chiến lược nhằm giải phóng đội ngũ kỹ sư của quý công ty khỏi công việc “bảo trì hậu trường” và tái bố trí họ sang lĩnh vực “kỹ thuật chủ động”.