Platform Engineering: Bài học từ sự trỗi dậy và sụp đổ của eBay Velocity

Platform Engineering: Bài học từ sự trỗi dậy và sụp đổ của eBay Velocity

Randy Shoup, cựu Kiến trúc sư trưởng của eBay, đã có một bài thuyết trình đầy cảm xúc về dự án mang tên "Velocity Initiative" — một trong những thành tựu lớn nhất trong sự nghiệp của ông, nhưng cũng là lý do khiến ông bị sa thải. Câu chuyện này không chỉ là một bản kỹ thuật về việc tăng g đôi năng suất của đội ngũ kỹ sư, mà còn là một bài học quản trị đắt giá về mối quan hệ giữa văn hóa tổ chức và sự thành bại của công nghệ.

Trong 10 năm đầu tiên tồn tại, eBay từng là một công ty công nghệ tiên phong, phát minh ra hoặc cùng phát minh ra nhiều khái niệm quan trọng như database sharding (phân mảnh dữ liệu), eventual consistency (nhất quán cuối cùng), distributed tracing (theo dõi phân tán) hay feature flags (cờ tính năng). Tuy nhiên, sau năm 2007, tăng trưởng của eBay bắt đầu chững lại. Trong khi thương mại điện tử tại Mỹ tăng trưởng 8 lần, tổng giá trị giao dịch hàng hóa (GMV) của eBay chỉ tăng 1,5 lần.

Đánh giá hiện trạng và thách thức

Khi quay lại eBay vào năm 2020 với tư cách là Kiến trúc sư trưởng, Randy Shoup đối mặt với một bộ máy khổng lồ nhưng cồng kềnh. Với khoảng 5.000 kỹ sư và 4.500 ứng dụng/dịch vụ đang hoạt động, tần suất triển khai trung bình chỉ là 1-2 lần mỗi tháng. Thời gian từ khi lập trình viên commit code đến khi code đó lên môi trường sản phẩm (lead time) lên tới 10 ngày.

Thông qua việc khảo sát các đội ngũ, ông nhận thấy bốn giai đoạn trong vòng đời phần mềm đều gặp vấn đề:

• Lập kế hoạch: Quá nhiều sự phối hợp giữa các nhóm, phụ thuộc lẫn nhau và quá nhiều công việc đang dang dở (work in progress).
• Phát triển phần mềm: Thời gian build và test lâu, kiến trúc liên kết chặt chẽ (highly coupled), thiếu hợp đồng dịch vụ rõ ràng.
• Giao phần mềm: Pipeline thiếu tự động hóa, môi trường staging không ổn định, thiếu triển khai canary.
• Lặp lại sau phát hành: Giám sát lỗ hổng, thử nghiệm A/B không hiệu quả.

Velocity Initiative: Kết quả ấn tượng

Mục tiêu của Velocity Initiative là tập trung vào khu vực giữa: Phát triển phần mềm và Giao phần mềm. Randy áp dụng triệt để "sách chơi" của DORA và DevOps: xác định và loại bỏ các nút thắt cổ chai.

Kết quả đạt được là cực kỳ ấn tượng:

• Năng suất kỹ thuật: Tăng g đôi số lượng tính năng và bản sửa lỗi mà một đội ngũ có thể thực hiện trong cùng một khoảng thời gian (flow velocity).
• Chỉ số DORA: Tần suất triển khai tăng 10 lần (từ 10 ngày xuống 1-2 ngày). Thời gian chờ (lead time) cải thiện 5 lần. Tỷ lệ thất bại khi thay đổi và thời gian khôi phục đều cải thiện 3 lần.
• eBay đã chuyển từ vị trí "người thực hiện trung bình" (35th percentile) lên "người thực hiện xuất sắc" (75th percentile) theo chuẩn DORA.

Cách thức thực hiện và Văn hóa

Để đạt được điều này, đội ngũ đã thực hiện nhiều biện pháp kỹ thuật như giảm thời gian build/test, đầu tư vào môi trường staging ổn định và tự động hóa quy trình. Tuy nhiên, yếu tố then chốt nằm ở cách làm việc và văn hóa.

Mô hình "nhúng" (embedding model) được sử dụng, nơi các kỹ sư cấp cao từ đội nền tảng (platform) sẽ làm việc trực tiếp với các đội sản phẩm để hiểu vấn đề và hỗ trợ giải quyết. Họ tạo ra sự hợp tác chéo giữa nền tảng và kỹ thuật sản phẩm, thay vì mối quan hệ khách - hàng truyền thống.

Về mặt văn hóa, Randy nhấn mạnh việc tạo ra sự an toàn tâm lý. Thay vì chỉ trích các đội ngũ triển khai chậm, họ coi đó là cơ hội để cải tiến. "Việc triển khai mỗi tháng không có nghĩa bạn là một người tồi, nó chỉ có nghĩa là bạn đang triển khai mỗi tháng. Hãy cùng nhau tìm cách tăng lên hai lần, rồi ba lần", Randy chia sẻ.

Ứng dụng AI và Hiện đại hóa Mobile

Một điểm sáng khác là việc tích hợp AI xuyên suốt vòng đời phát triển phần mềm (SDLC). Từ việc tạo code, tạo dữ liệu test, tóm tắt PR (Pull Request), đến việc phân tích lỗi CI và tự động rollback khi triển khai. Đội ngũ đã sử dụng AI ở khoảng 25-30 khía cạnh khác nhau để hỗ trợ con người.

Đối với di động, eBay đã chuyển từ việc phát hành ứng dụng hàng tháng sang hàng ngày. Ban đầu, người quản lý phát hành cho rằng điều này là không thể, nhưng chỉ sau 7 tháng thử nghiệm, đội ngũ đã tự nguyện chuyển sang phát hành hàng tuần và sau đó là hàng ngày nhờ quy trình tinh gọn hơn.

Tại sao kỹ thuật xuất sắc vẫn không cứu được công ty?

Mặc dù đạt được những thành tựu kỹ thuật rực rỡ, eBay vẫn không thoát khỏi tình trạng kinh doanh ảm đạm. Randy Shoup chỉ ra bốn nguyên nhân cốt lõi:

1. Chiến lược và Lập kế hoạch: eBay mắc phải "nghịch lý của người đổi mới" (Innovator's Dilemma). Việc tự làm thay đổi mô hình kinh doanh thành công của chính mình là cực kỳ khó. Tư duy e ngại rủi ro (risk aversion) tràn lan do nhiều năm kinh tế đi ngang. Quy trình lập kế hoạch theo kiểu thác nước (waterfall) tập trung, kéo dài hàng tháng, khiến các dự án nhỏ phải "bám đuôi" vào các dự án lớn mới được duyệt.

2. Thực thi và Giao hàng: eBay thường xuyên thực hiện các dự án phối hợp quy mô lớn kéo dài nhiều quý. Ví dụ, dự án thanh toán quản lý (Managed Payments) tốn 3 năm và 2.000 người với chi phí nhân sự lên tới 1,5 tỷ USD. Tư duy "Feature factory" (Nhà máy tính năng) đề cao việc hoàn thành cột mốc (milestone) hơn là tạo ra giá trị thực tế cho khách hàng.

3. Ngõ cụt về Công nghệ: Dù từng là tiên phong, eBay lại chậm chuyển đổi sang các công nghệ mới như đám mây công cộng (public cloud), mã nguồn mở, hay microservices. Việc duy trì các khung dữ liệu (framework) độc quyền và trung tâm dữ liệu riêng đã làm chậm tốc độ đổi mới.

4. Văn hóa Tổ chức: Đây là nguyên nhân quan trọng nhất. Theo sách "Accelerate", văn hóa dự đoán hiệu suất phần mềm. eBay bị mô tả là có một "văn hóa bệnh hoạn" (pathological culture) đầy rẫy nỗi sợ hãi và tính chính trị. Việc thừa nhận thất bại bị coi là thô lỗ. Tư duy "not invented here" (không phải do mình tạo ra thì không dùng) phổ biến, và các phương pháp Agile thường chỉ là "Faux Agile" (Giả Agile) — bọc lớp Waterfall bên ngoài lớp Agile bên trong.

Bài học cuối cùng

Randy Shoup kết luận rằng một cuộc chuyển đổi thành công cần sự hỗ trợ từ trên xuống (top-down), sự ủng hộ từ dưới lên (bottom-up), và quan trọng nhất là sự tham gia từ giữa ra (middle-out). Việc chỉ tập trung vào kỹ thuật xuất sắc là chưa đủ; nếu không giải quyết được vấn đề về văn hóa và chiến lược, kỹ thuật tốt nhất cũng sẽ bị lãng phí.

Cuộc hành trình của eBay Velocity là một minh chứng rõ ràng: Công nghệ là động cơ, nhưng văn hóa mới là người lái xe quyết định hướng đi của tổ chức.