Từ Di sản Cũ đến Chủ quyền Công nghệ: Platform Engineering thúc đẩy tương lai ngành Bảo hiểm

Công nghệ25 tháng 5, 2026·6 phút đọc

Sergiu Petean chia sẻ hành trình chiến lược chuyển đổi từ DevOps sang Platform Engineering trong môi trường doanh nghiệp chịu sự kiểm soát chặt chẽ. Bài viết đề cập đến việc tối ưu hóa hiệu quả thông qua kiến trúc tham chiếu động, đồng bộ hóa KPI với mục tiêu kinh doanh, giảm tải nhận thức và duy trì khả năng đổi mới sáng tạo thông qua công nghệ mã nguồn mở.

Từ Di sản Cũ đến Chủ quyền Công nghệ: Platform Engineering thúc đẩy tương lai ngành Bảo hiểm

Trong bối cảnh kinh tế hiện tại, hiệu quả là từ khóa then chốt. Tuy nhiên, nhiều tổ chức đang mắc kẹt giữa việc theo đuổi những đột phá công nghệ mang tính "hype" (như xe bay) và việc xây dựng nền móng vững chắc cho hệ thống công nghệ của mình. Tại hội nghị InfoQ Dev Summit Munich, Sergiu Petean, một chuyên gia hàng đầu trong lĩnh vực chuyển đổi số tại ngành tài chính và bảo hiểm, đã có bài trình bày sâu sắc về hành trình phát triển từ DevOps truyền thống sang Platform Engineering (Kỹ thuật Nền tảng) để định hình tương lai của ngành bảo hiểm.

Hình ảnh trình bày về Platform Engineering trong bảo hiểmHình ảnh trình bày về Platform Engineering trong bảo hiểm

Định nghĩa lại Platform Engineering trong doanh nghiệp

Petean bắt đầu bằng một phép ẩn dụ thú vị: thay vì chỉ tập trung vào những "xe bay" mang tính đột phá như AI, các kỹ sư và lãnh đạo cần tập trung xây dựng nền tảng vững chắc. Ông nhấn mạnh rằng Platform Engineering không chỉ đơn thuần là xây dựng một Internal Developer Platform (IDP). Trong môi trường doanh nghiệp chịu sự kiểm soát chặt chẽ như bảo hiểm, các bên liên quan (stakeholders) quan trọng nhất không chỉ là các lập trình viên, mà còn bao gồm bộ phận An ninh, Tuân thủ, CEO và văn phòng Chuyển đổi.

Do đó, định nghĩa về Platform Engineering phải mở rộng để bao gồm trải nghiệm của tất cả các bên này, không chỉ là trải nghiệm của nhà phát triển. Nó là câu chuyện về việc xây dựng một sản phẩm được thúc đẩy bởi các nguyên tắc rõ ràng, đáp ứng các lực lượng tác động như quy định, tuân thủ và giảm thiểu rủi ro.

Hành trình từ "Fake SRE" đến Đo lường hiệu quả

Petean chia sẻ về giai đoạn đầu khi ông gia nhập Allianz Direct vào năm 2021. Khi đó, đội ngũ đang rơi vào tình trạng "Anti-Type H: Fake SRE Technology" – tức là tự nhận mình làm SRE nhưng thực tế không phải vậy. Bước đầu tiên là nhận ra antipattern này và thay đổi bản sắc đội ngũ.

Đội ngũ đã chuyển đổi sang tư duy sản phẩm, xác định rõ sứ mệnh và nguyên tắc hoạt động. Họ xây dựng một nền tảng tương lai dựa trên mã nguồn mở (open-source) để đảm bảo "chủ quyền đổi mới" (innovation sovereignty), thay vì chỉ trở thành người tiêu dùng các dịch vụ đám mây có sẵn.

Một điểm nhấn quan trọng là việc đo lường tác động. Đội ngũ đã áp dụng các chỉ số DORA để so sánh hiệu suất với chính mình và với ngành công nghiệp. Kết quả là họ đã đạt được nhóm "Elite" với khả năng triển khai theo yêu cầu nhiều lần mỗi ngày. Hơn nữa, Petean còn sáng tạo ra chỉ số "chi phí trên mỗi thay đổi" (cost per change unit), giảm từ 49 euro xuống còn 13 euro, giúp chứng minh giá trị tài chính rõ ràng cho ban lãnh đạo.

Tích hợp An ninh và Mở rộng quy mô

Trong môi trường bảo hiểm, an ninh là ưu tiên hàng đầu. Đội ngũ đã tích hợp an ninh một cách tự nhiên vào quy trình CI/CD. Thay vì bị ngập trong hàng chục nghìn lỗ hổng bảo mật, họ đã xây dựng một module quản lý lỗ hổng để lọc nhiễu và đưa ra các thông tin có thể hành động được (actionable insights), giảm số lượng lỗ hổng cần xử lý xuống dưới 100.

Khi tổ chức mở rộng quy mô từ 150 lên 2.000 kỹ sư, mô hình DevOps truyền thống không thể mở rộng theo cùng tốc độ. Petean đã áp dụng mô hình "Federated SRE" (SRE liên kết), nơi kiến thức được phân phối và cộng đồng SRE được thành lập. Họ cũng đàm phán để đảm bảo 20% thời gian của mỗi đội nhóm được dành cho hoạt động vận hành, bảo mật và SRE.

Giảm tải nhận thức và Đảo ngược quy tắc Conway

Một thách thức lớn khi nền tảng phát triển là sự phức tạp của kỹ thuật (tech stack) gây ra "tải nhận thức" (cognitive load) cho các kỹ sư. Để giải quyết vấn đề này mà không đợi một năm để nhân viên mới học hết mọi thứ, Petean đã áp dụng "Reverse Conway's Maneuver" (Đảo ngược quy tắc Conway).

Ông tạo ra các nhóm làm việc tạm thời gọi là DDO (Distributed DevOps). Trong mỗi DDO, các kỹ sư có các vai trò khác nhau như học viên, người thực thi hoặc tư vấn. Mỗi kỹ sư được yêu cầu luân chuyển qua các DDO khác nhau, giúp họ có đóng góp ngay từ ngày đầu tiên và dần dần nắm bắt được cái nhìn toàn diện về sản phẩm sau 2 năm.

Chủ quyền công nghệ và Chiến lược mã nguồn mở

Cuối cùng, Petean nhấn mạnh tầm quan trọng của "Chủ quyền" (Sovereignty). Trong bối cảnh địa chính trị và sự gián đoạn dịch vụ (như lỗi Google Maps gần đây), việc có một chiến lược chủ quyền kỹ thuật số là bắt buộc.

Việc lựa chọn công nghệ mã nguồn mở cho phép đội ngũ có khả năng di chuyển nền tảng của mình từ các nhà cung cấp đám mây công cộng (hyperscalers) sang đám mây riêng hoặc trung tâm dữ liệu một cách linh hoạt. Chiến lược này không chỉ giúp giảm thiểu rủi ro bị khóa vào nhà cung cấp (vendor lock-in) mà còn tạo ra khả năng tự chủ trong đổi mới sáng tạo.

Bài học chính

  • Đo lường bằng ngôn ngữ kinh doanh: Đừng chỉ dùng thuật ngữ kỹ thuật. Hãy chuyển đổi các khả năng của nền tảng thành các chỉ số KPI mà ban lãnh đạo quan tâm như chi phí, tuân thủ và độ tin cậy.
  • Xây dựng bản sắc đội ngũ: Xác định rõ nguyên tắc và sứ mệnh để xây dựng văn hóa và thu hút nhân tài phù hợp.
  • Đơn giản hóa: Đừng ngại phá bỏ và xây dựng lại kiến trúc nếu nó giúp đơn giản hóa hệ thống và tăng hiệu quả tài chính (FinOps).
  • Chủ quyền đổi mới: Đầu tư vào con người và công nghệ mã nguồn mở để đảm bảo khả năng kiểm soát và thích ứng với các cuộc cách mạng công nghệ tiếp theo như AI.

Bài trình bày của Sergiu Petean là một cẩm nang thực tế cho các nhà lãnh đạo kỹ thuật đang tìm cách chuyển đổi thành công sang Platform Engineering và định vị công nghệ như một đối tác ngang hàng với kinh doanh trong doanh nghiệp.

Chia sẻ:FacebookX
Nội dung tổng hợp bằng AI, mang tính tham khảo. Xem bài gốc ↗