Tất tần tật về platform engineering: Vì sao cần, xây dựng thế nào và thành công trông ra sao

• Là một bộ môn mang tính tổ chức để xây dựng và vận hành sản phẩm nội bộ với các kỹ sư nội bộ là người dùng, đây về bản chất là một lĩnh vực khác hẳn với việc chỉ đổi tên DevOps hay quản lý cụm Kubernetes
• Theo báo cáo DORA 2025, 90% tổ chức đã triển khai ít nhất một nền tảng nội bộ, và chất lượng nền tảng đang nổi lên như chỉ số dự báo trực tiếp việc công cụ AI có tạo ra giá trị hay không
• Khi cloud và mã nguồn mở cung cấp vô hạn primitive, lý do tồn tại cốt lõi là giải quyết vấn đề "vũng lầy tổng quát hóa quá mức (over-general swamp)", nơi mỗi đội tự xây các pipeline theo cách riêng
• Thành công về mặt cấu trúc đòi hỏi phải đối xử với nền tảng như một sản phẩm thực thụ, đồng thời có các lớp trừu tượng phần mềm, registry metadata và SLO vận hành cho nhà phát triển trung vị
• Một nền tảng tốt vận hành tự nhiên đến mức nhà phát triển quên mất sự tồn tại của nó; nền tảng tệ khiến công cụ AI khuếch đại sự hỗn loạn, trong khi nền tảng tốt khuếch đại thông lượng

---

Vì sao platform engineering tồn tại

• Vũng lầy tổng quát hóa quá mức (Over-General Swamp)

  • Cloud và OSS cung cấp vô hạn primitive như queue, object store, database, CI runner, service mesh..., khiến mỗi đội ứng dụng đưa ra lựa chọn khác nhau
  • Sau 1 năm, mọi dịch vụ biến thành một "vũng lầy glue code" với pipeline triển khai riêng, logic retry riêng, quy ước giám sát riêng và các IAM binding sai lệch một cách tinh vi
  • Hai nguyên nhân tạo ra vũng lầy này là sự bùng nổ lựa chọn và kỳ vọng vận hành ngày càng cao hơn (hoạt động 24/7, bảo mật, compliance, quản lý chi phí)
  • Trong một dự án landing zone thực tế, có trường hợp 20 đội tự tái tạo gần như cùng một Terraform module cho VPC, IAM và cảnh báo ngân sách, nhưng mỗi bên lại mang lỗi khác nhau

• Bốn việc mà platform engineering thực sự làm

  • Giới hạn các primitive mà nhà phát triển nhìn thấy để định hướng họ chỉ dùng theo cách đã được tuyển chọn
  • Hấp thụ các công việc plumbing lặp đi lặp lại vào dịch vụ dùng chung để giảm glue code cho từng ứng dụng
  • Khi primitive nền tảng thay đổi, đội platform chỉ xử lý một lần để tập trung hóa chi phí migration
  • Hỗ trợ để nhà phát triển có thể tự vận hành thứ mình tạo ra mà không cần trở thành chuyên gia Linux kernel
  • DevOps là "hãy để nhà phát triển sở hữu vận hành", còn platform engineering là "chúng tôi sẽ cung cấp các công cụ tốt cho việc vận hành đó như một sản phẩm thực thụ"
  • Trang năng lực DORA 2025 cũng định nghĩa đây là một bộ môn socio-technical chứ không phải một danh mục công cụ

Năm trụ cột (Pillars)

• Cách tiếp cận sản phẩm được tuyển chọn (Curated Product Approach)

  • Chủ đích quyết định nền tảng hỗ trợ gì và không hỗ trợ gì
  • Khi một đội muốn dùng Kafka thay vì Pub/Sub, phản hồi không phải là "đây là link tài liệu" mà là "phạm vi hỗ trợ, lý do và lối thoát nếu không phù hợp"
  • Nói không cũng là một phần công việc

• Trừu tượng hóa dựa trên phần mềm (Software-Based Abstractions)

  • Nền tảng là phần mềm chứ không phải wiki, và giao diện của nó là API, CLI, SDK
  • Chỉ bằng cách viết một tệp khai báo nhỏ, nhà phát triển phải có thể provision một dịch vụ đạt chuẩn production
  • Dự án Score thuộc CNCF là ví dụ tiêu biểu: chỉ với một workload spec, hệ thống tự động provision database, topic, service account và triển khai
    • Nhà phát triển không cần biết bên dưới là Cloud SQL, Pub/Sub hay Cloud Run

• Tùy biến OSS và registry metadata

  • Không dùng nguyên xi Argo CD hay Backstage bản vanilla, mà vận hành với plugin, chính sách mặc định và tích hợp phù hợp với tổ chức
  • Nếu không có registry metadata (service catalog), sẽ không thể nắm được ai sở hữu cái gì, các quan hệ phụ thuộc ra sao và thực tế đang có gì chạy
  • Backstage là framework OSS tiêu chuẩn thực tế cho lớp này, với hơn 270 tổ chức đang vận hành trong production
    • CNCF đã ra mắt các chứng chỉ Certified Backstage Associate và Certified Cloud Native Platform Engineering Associate
    • Dù dùng Backstage, Port hay Cortex, vẫn cần một single source of truth về "những dịch vụ nào tồn tại, ai sở hữu chúng và quan hệ phụ thuộc là gì"

• Phục vụ tập người dùng rộng

  • Nền tảng nội bộ thường có một số ít khách hàng rất ồn ào, nhưng mục tiêu là hỗ trợ tốt công việc trung vị của nhà phát triển trung vị
  • Nếu chỉ xây cho nhóm người dùng tinh hoa, các đội còn lại sẽ lách qua nền tảng và shadow platform sẽ xuất hiện

• Vận hành như một nền móng

  • Nếu nền tảng ngừng hoạt động thì công ty cũng tê liệt, nên nó kéo theo on-call 24/7, SLO thực, quản lý thay đổi thực và gánh nặng hỗ trợ thực
  • Nó không phải là một "công cụ" mà là "mặt sàn", nơi mọi thứ được xây phía trên đều mặc định rằng mặt sàn này sẽ chịu được

Khi nào và bắt đầu bằng cách nào

• Đừng lập đội platform quá sớm

  • Ở quy mô 10 kỹ sư, điều cần thiết không phải là đội platform mà là sự hợp tác (cooperation)
    • Chỉ cần một người quản lý script triển khai, người khác quản lý Terraform và cả nhóm thống nhất quy ước
  • Nếu lập đội quá sớm với 1-2 người, họ sẽ trở thành hàng đợi ticket, còn phần còn lại của tổ chức trở nên thụ động
  • Thông thường, sau mốc 50 kỹ sư, khi có nhiều đích triển khai và không ai còn biết câu trả lời chuẩn cho "triển khai dịch vụ mới bằng cách nào", thì đó là lúc phù hợp để lập đội

• Chuyển đổi tổ chức hạ tầng hiện có

  • Khi chuyển đội hạ tầng/SRE thành tổ chức platform, phần khó nhất không phải công nghệ mà là văn hóa
  • Người làm hạ tầng quen với vai trò gatekeeper của câu "không được", nhưng người làm platform phải trở thành "người đưa ra câu đồng ý dễ dàng"
    • Nói chuyện nhiều với khách hàng
    • Tuyển dụng và nuôi dưỡng các kỹ sư phần mềm thích xây công cụ, không chỉ các operator
    • Cập nhật cơ chế khen thưởng để việc "giúp 200 đội nhanh hơn 5%" được ghi nhận hơn là "triển khai một cụm mới"
  • Một kiểu thất bại phổ biến nhất là rắc PM lên trên rồi coi như xong, và điều đó tạo ra sân khấu (theater) chứ không phải nền tảng

Xây dựng đội platform

• Bốn vai trò

  • Software Engineer: xây dựng bề mặt sản phẩm của nền tảng như API, SDK, portal
  • Systems Engineer: thông thạo các primitive nền tảng như Kubernetes, Linux, networking, cloud control plane
  • Reliability Engineer: tập trung vào chất lượng vận hành, on-call, SLO và observability
  • Systems Specialist: chuyên gia chuyên sâu về các domain như database, bảo mật, networking
  • Nếu quá thiên về phần mềm, bạn sẽ có một portal đẹp nhưng sụp đổ dưới tải thực; nếu quá thiên về hệ thống, bạn sẽ có một cụm vững chắc mà không ai dùng được nếu không mở ticket

• Tuyển dụng

  • Cần tuyển với customer empathy là ưu tiên hàng đầu
  • Một kỹ sư không thể nói chuyện với nhà phát triển ứng dụng đang bực bội rồi bước ra với hiểu biết rõ ràng về vấn đề thì không phù hợp
  • Sự xuất sắc về kỹ thuật mà thiếu đồng cảm sẽ tạo ra một nền tảng chính xác nhưng không ai dùng
  • Với các vai trò phần mềm có thể dùng cùng level matrix, nhưng với system specialist thì do giá trị thị trường và kỹ năng không khớp gọn với ladder của software engineer, nên cần cho phép chức danh linh hoạt

• Quản lý và các vai trò khác

  • Ba đặc điểm chung của một quản lý platform engineering xuất sắc: kinh nghiệm vận hành nền tảng thực tế, kinh nghiệm triển khai các dự án dài hạn kéo qua nhiều quý, và sự ám ảnh với chi tiết
    • Nền tảng tưởng thưởng cho chi tiết, và những trường hợp 1% trông có vẻ hiếm nên bị bỏ qua lại chiếm 80% thời gian hỗ trợ
  • PM, technical writer, developer advocate và support engineer đều quan trọng, nhưng chỉ nên tuyển sau khi đội kỹ thuật đã đủ trưởng thành
  • Một PM được đưa sớm vào đội platform 4 người rốt cuộc chỉ trở thành một chiếc ghế có hình roadmap

Nền tảng như một sản phẩm

• Khách hàng nội bộ còn khó hơn

  • Khách hàng nội bộ là người dùng captive khó rời bỏ, có quan điểm mạnh nhưng cảm quan sản phẩm yếu
  • Họ nói ra điều mình muốn (want), nhưng nhiều khi khác với điều họ thực sự cần (need)
  • Họ yêu cầu nền tảng làm thay công việc của mình, chứ không yêu cầu các công cụ giúp họ làm việc tốt hơn
  • Việc ngồi cạnh họ và quan sát họ phải chuyển ngữ cảnh bao nhiêu lần để triển khai một thay đổi mới chính là backlog thực sự

• Discovery, roadmap, và các failure mode

  • Platform discovery được thực hiện bằng pilot chứ không phải A/B test, cùng với một nhóm thân thiện và đo mức giảm lead time sau triển khai thực tế
  • Bốn chân trời thời gian của roadmap
    • Vision (nhiều năm): hướng đi của nền tảng
    • Strategy (hàng năm): các khoản cược của năm nay
    • Goals and Metrics (theo quý~hàng năm): định nghĩa thành công
    • Milestones (theo quý): các hạng mục thực sự sẽ được triển khai
  • Những failure mode thường xuyên làm gục cả đội
    • Đánh giá thấp chi phí migration (luôn gấp 2~3 lần dự kiến)
    • Đánh giá quá cao ngân sách thay đổi của người dùng dành cho tính năng mới
    • Tập trung vào thêm tính năng khi vấn đề thực sự là độ ổn định
    • Có quá nhiều PM so với quy mô đội ngũ engineering (5 kỹ sư mà có 2 PM là có vấn đề)

Vận hành nền tảng

• On-call không phải là lựa chọn

  • Vì được vận hành như nền móng nên độ phủ 24/7 là điều không thể thương lượng
  • "Người xây thì cũng là người vận hành (you build it, you run it)" cũng áp dụng ở đây, và đây không phải hình phạt mà là một vòng phản hồi
  • Nếu một kỹ sư đơn lẻ bị page quá vài lần mỗi tuần thì cần sửa hệ thống chứ không phải sửa lịch trực
  • Kỹ sư platform bị burnout sẽ triển khai nền tảng tồi

• Hỗ trợ: một nửa công việc bị che giấu

  • Đây là mảng gần như không được nhắc đến ở các hội nghị, nhưng lại là một nửa cốt lõi của platform engineering
  • Khung bốn giai đoạn
    • Giai đoạn 1: chính thức hóa các cấp độ hỗ trợ (P0 vs P3, thời gian phản hồi, v.v.)
    • Giai đoạn 2: tách hỗ trợ không quan trọng khỏi on-call để câu hỏi kiểu "cách thêm CronJob" không làm ai đó phải thức dậy
    • Giai đoạn 3: khi khối lượng đủ lớn để biện minh, tuyển chuyên viên hỗ trợ chuyên trách
    • Giai đoạn 4: xây dựng tổ chức hỗ trợ engineering phù hợp với quy mô
  • Nếu bỏ qua giai đoạn 1, kỹ sư sẽ tiêu nửa thời gian để trả lời Slack DM, và nửa còn lại để than phiền

• Phản hồi vận hành

  • SLO và SLA là bắt buộc, còn error budget hữu ích nhưng không bắt buộc
  • Synthetic monitoring giúp bắt failure mode trước khi người dùng gửi ticket
  • Review vận hành không phải là liếc qua dashboard toàn màu xanh, mà là buộc phải xem xét dữ liệu thực tế
  • Trong dữ liệu DORA 2025, năng lực nền tảng có tương quan cao nhất với trải nghiệm người dùng là phản hồi rõ ràng về kết quả công việc — khi thất bại, người dùng phải biết chính xác cái gì thất bại và phải làm gì

Lập kế hoạch và chuyển giao

• Dự án dài hạn cần tài liệu đề xuất

  • Các dự án nền tảng như migration, re-architecture, control plane mới đều mất theo quý
  • Các thành phần bắt buộc của một bản đề xuất tốt: vấn đề cần giải quyết, người hưởng lợi, phạm vi, những gì rõ ràng nằm ngoài phạm vi, định nghĩa thành công
  • Hãy viết tài liệu trước khi viết code, review nó trước rồi mới chuyển thành kế hoạch thực thi với milestone cụ thể
  • Failure mode kiểu "long slog" — dự án kéo dài nhiều năm và không ai còn nhớ lý do — gần như luôn là kết quả của việc bỏ qua bước này

• Lập kế hoạch roadmap từ dưới lên

  • Bốn loại công việc trong roadmap nền tảng: KTLO (keep-the-lights-on), chỉ thị từ lãnh đạo, cải tiến hệ thống do chính đội tự quyết, và yêu cầu trực tiếp từ khách hàng
  • Không thể xếp hạng chỉ dựa trên nhu cầu khách hàng, và KTLO là ưu tiên số 1, chỉ thị là số 2, còn lại cần thảo luận thẳng thắn với các bên liên quan

• Thành quả và thách thức hai tuần một lần (Biweekly Wins and Challenges)

  • Cứ mỗi 2 tuần viết một tài liệu ngắn: những gì đã triển khai (thành quả), những gì bị chặn (thách thức), ngắn gọn, công khai và không phóng đại
  • Ba hiệu ứng đồng thời: đội diễn đạt rõ tiến độ, giúp các bên liên quan nắm được tình hình thực tế, và phơi bày sớm các thách thức để thu hút hỗ trợ từ lãnh đạo
  • Tài liệu chỉ có thành quả là tài liệu không ai tin, nên đừng bỏ qua phần thách thức

Re-architecture và migration

• Re-architecture thay vì v2

  • Khi nền tảng đã cũ, bản năng "hãy làm v2" gần như luôn là câu trả lời sai
  • Lý do dự án v2 thất bại: đóng băng đầu tư vào v1, thời gian kéo dài hơn dự kiến, và chi phí migration sang v2 còn cao hơn chi phí re-architecture mà ta đã né tránh
  • Hãy re-architecture ngay trong nền tảng hiện có, giữ tương thích nhiều nhất có thể, và tận dụng môi trường cấp dưới, rollout chậm, migration theo từng tranche
  • Bốn bước lập kế hoạch
    • Nghĩ lớn về mục tiêu kiến trúc cuối cùng
    • Tính cả chi phí migration (luôn gấp 2~3 lần)
    • Xác định các kết quả chính trong 12 tháng để biện minh cho đầu tư liên tục
    • Đạt được đồng thuận của lãnh đạo, và sẵn sàng chờ đợi

• Bảo mật là vấn đề kiến trúc

  • Không thể gắn thêm bảo mật sau khi đã xây xong; kiến trúc phải buộc đặc quyền tối thiểu, cô lập và khả năng truy vết ngay từ lúc thiết kế
  • Nếu đó là một nền tảng mà mọi đội đều phải nhớ đúng IAM binding, thì không phải đội có lỗi mà là nền tảng có bug

• Migration: bài toán khó thường bị đánh giá thấp

  • Những anti-pattern phổ biến nhất
    • Đưa cho mọi đội một clipboard và deadline rồi bảo họ tự migration
    • Chỉ ra lệnh mà không có on-ramp hay off-ramp rõ ràng
    • Đánh giá thấp long tail của các use case đặc thù
  • Những cách làm migration engineering dễ hơn
    • Theo dõi metadata sử dụng để xác định chính xác người dùng phiên bản cũ
    • Nếu có 200 đội phải migration thì đội platform viết script, không phải đội ứng dụng
    • Thiết kế kiến trúc migration minh bạch nơi hệ thống mới sử dụng API cũ
    • Tài liệu hóa rõ ràng on-ramp để các đội mới có thể self-service
  • Mandate chỉ hiệu quả một hai lần, sau đó sẽ trở thành tiếng ồn
  • Trong đa số trường hợp, cách tốt nhất là làm cho con đường mới đủ tốt để con đường cũ tự nhiên lụi tàn

• Ngừng dịch vụ (Sunsetting)

  • Đừng sợ loại bỏ sản phẩm
  • 1 hệ thống triển khai vững chắc tốt hơn 7 hệ thống triển khai được hỗ trợ nửa vời, và việc sunset là đặc trưng của một đội ngũ trưởng thành

Quan hệ với các bên liên quan

• Ma trận quyền lực - mức độ quan tâm (Power-Interest Grid)

  • Lập bản đồ các bên liên quan theo hai trục quyền lực (power) và mức độ quan tâm (interest)
    • Quyền lực cao, quan tâm cao: cập nhật định kỳ và tham vấn
    • Quyền lực thấp, quan tâm thấp: chỉ cần trang trạng thái là đủ
  • Đừng lãng phí thời gian của đội bằng cách cung cấp thông tin nâng cấp Kubernetes cho một VP ít quan tâm

• Giao tiếp không chia sẻ quá mức

  • Hãy minh bạch nhưng không quá đà — lãnh đạo cấp cao không cần biết tranh luận về ba chiến lược retry gRPC, mà cần biết đã đạt milestone hay chưa và rủi ro là gì
  • Sử dụng các buổi 1:1 một cách cẩn trọng và theo dõi kỳ vọng cũng như cam kết ở nơi mọi người nhìn thấy

• Từ chối mà không phá hỏng quan hệ

  • Hãy nói rõ tác động kinh doanh như "nếu thêm tính năng này, migration sẽ bị lùi một quý, tương đương chi phí $X cho công ty"
  • "Yes nhưng có thỏa hiệp", "từ chối nhưng chỉ ra con đường", và đôi khi cho phép shadow platform có thể còn tốt hơn chi phí của việc đối đầu
  • Trong mùa lập ngân sách, hãy trình bày theo đơn vị đội và năng lực chứ không phải từng người, và phải có quan điểm rõ ràng về việc cắt gì, giữ gì — nếu không bộ phận tài chính sẽ quyết thay và quyết sai

Thành công trông như thế nào

• Nền tảng được căn chỉnh (Aligned)

  • Cần có sự căn chỉnh về mục đích (vì sao nó tồn tại), căn chỉnh về chiến lược (các khoản đặt cược nhất quán giữa các nhóm), và căn chỉnh về kế hoạch (không xung đột milestone)
  • Khi tất cả các nhóm runtime đều muốn Kubernetes còn nhóm observability lại muốn hỗ trợ mọi framework, sẽ phát sinh lệch căn chỉnh
    • Điều này bộc lộ thành hướng dẫn trái ngược cho khách hàng, công việc trùng lặp và các developer tức giận bị kẹt ở giữa
    • Giải quyết bằng lãnh đạo có nguyên tắc, không phải bằng đồng thuận (consensus)

• Nền tảng được tin cậy (Trusted)

  • Niềm tin được xây chậm rãi và có thể mất chỉ sau một lần migration tệ hại
  • Niềm tin được hình thành từ cách vận hành (giao tiếp khi có sự cố, thực hiện đúng cam kết), cách đầu tư (thực sự triển khai các khoản đặt cược lớn đã bán ra), và ưu tiên trong việc bàn giao
  • Ví dụ về "nền tảng overcoupled": nhồi quá nhiều logic tùy biến vào nền tảng khiến mọi thay đổi đều mất hàng tháng — giải pháp không phải là bổ sung thêm kỹ thuật mà là thách thức các giả định về phạm vi
    • Đôi khi vấn đề niềm tin không phải vì làm quá ít mà vì đang làm quá nhiều

• Nền tảng quản lý được độ phức tạp

  • Độ phức tạp của phần mềm là điều không thể tránh khỏi, nhưng độ phức tạp ngẫu sinh (accidental complexity) thì không
  • Cần phân biệt giữa độ phức tạp cố hữu của bài toán, sự phối hợp kém giữa con người, shadow platform giải cùng một vấn đề hai lần, và độ phức tạp ngẫu sinh do tăng trưởng vô hạn tạo ra
  • Ba đòn bẩy thực tiễn
    • Kiểm soát tăng trưởng: nền tảng cố hỗ trợ mọi thứ thì sẽ không hỗ trợ tốt thứ gì cả, hãy nêu rõ phạm vi
    • Dùng product discovery không chỉ để tìm xem nên thêm gì mà còn để biết nên dừng cái gì
    • Quản lý shadow platform: nếu các nhóm tự tạo giải pháp song song, đó là tín hiệu cho thấy nền tảng đang thiếu thứ gì đó thật sự hoặc có ai đó đang mở rộng phạm vi — cả hai đều cần được xử lý

• Nền tảng được yêu thích (Loved)

  • Có ba dạng
    • Kiểu yêu thích "nó cứ thế mà chạy": phần lớn người dùng không nhận ra sự hiện diện của nền tảng, deploy được, CI pass — nhàm chán là lời khen lớn nhất
    • Kiểu yêu thích "như hack vậy": những niềm vui nhỏ như một lệnh CLI hoạt động đúng theo cách hiển nhiên mà không cần giải thích riêng
    • Kiểu yêu thích "rõ ràng": điểm khảo sát, retention, mức độ adoption tự nhiên, và việc giới thiệu nền tảng cho nhóm khác
  • Khi nền tảng được yêu thích, mọi người sẽ đứng ra đấu tranh thay bạn khi cần xin ngân sách; còn nếu chỉ đơn thuần được chấp nhận, chỉ một incident tệ là đã có thể đứng trước nguy cơ bị thay thế

Ưu tiên thực chiến

• Thứ tự đại khái khi bắt đầu từ số 0 hoặc xây lại
  • Ưu tiên 1: quyết định phạm vi hỗ trợ rồi ghi lại và bảo vệ nó
  • Ưu tiên 2: đầu tư vào abstraction bằng phần mềm thay vì wiki (Score, Crossplane, SDK tự xây và các phần mềm có API thực sự)
  • Ưu tiên 3: xây dựng metadata registry (dùng Backstage chẳng hạn để biết cái gì đang chạy ở đâu và ai sở hữu nó)
  • Ưu tiên 4: xây cho nhóm ở mức trung vị, không phải nhóm ồn ào nhất
  • Ưu tiên 5: coi vận hành như một tính năng hạng nhất với SLO, on-call, tier hỗ trợ...
  • Ưu tiên 6: tuyển người dựa trên năng lực đồng cảm ngang với năng lực hệ thống
  • Ưu tiên 7: giao tiếp không khoan nhượng như cập nhật thành quả/thách thức hai tuần một lần, roadmap minh bạch, và quản lý stakeholder một cách thẳng thắn
  • Ưu tiên 8: dừng, hợp nhất, từ chối những gì không cần thiết
• Phù hợp với dữ liệu DORA, chất lượng nền tảng là bội số của mọi thứ, bao gồm cả mức độ áp dụng AI — nền tảng tệ khiến công cụ AI khuếch đại hỗn loạn, nền tảng tốt khuếch đại throughput
• Phải làm xong mặt sàn trước khi chế tạo tên lửa

[kalista22]

Tôi nghĩ giao tiếp nội bộ là quan trọng hơn bất cứ điều gì khác.