Làm Sao Microsoft Suýt Đánh Mất OpenAI (Và Bốc Hơi Nghìn Tỷ Đổi Lấy Bài Học Quản Trị)

Bạn có lẽ đã nghe đến câu nói "quá lớn để thất bại" (too big to fail). Trong vài năm qua, Microsoft đã chứng minh một sự thật khác: quá lớn để suy nghĩ đúng đắn.

Một bài đăng trên Substack từ một cựu kỹ sư cấp cao của Azure đang lan truyền chóng mặt trên Reddit và Hacker News — và nó vẽ nên một bức tranh về sự rối loạn tổ chức đến mức phi lý, đọc như một tác phẩm châm biếm. Nhưng không, đó là sự thật. Đó là câu chuyện firsthand về cách một tổ chức kỹ thuật gồm 122 người đã dành nhiều tháng để tranh luận nghiêm túc xem có nên port một nửa nhân Windows sang một con chip bằng kích thước đầu ngón tay hay không.

Hãy cùng mổ xẻ những gì thực sự đã xảy ra, tại sao nó lại quan trọng với mọi kỹ sư đang đọc bài này, và bạn có thể làm gì khi công ty của mình bắt đầu trôi dạt theo hướng này.

Vũ khí bí mật của Azure: Azure Boost

Để hiểu thảm họa này, trước hết bạn cần hiểu Azure Boost là gì.

Azure Boost là thẻ tăng tốc chuyển tải (offload accelerator card) của Microsoft — một phần cứng tùy chỉnh nằm trong máy chủ Azure để xử lý các tác vụ mạng, lưu trữ và quản lý máy ảo (VM). Đó là cách Azure cạnh tranh với AWS Nitro và hạ tầng mạng của Google. Nó không hề hào nhoáng, nhưng lại cực kỳ quan trọng.

Thẻ này chạy một stack Linux tối giản và hiệu quả trên một con chip SoC (System-on-a-Chip) nhỏ xíu. Tiêu thụ điện năng thấp. Dung lượng nhỏ. Mỗi byte bộ nhớ và mỗi milliwatt điện năng đều quý giá. Tác giả bài viết này đã giúp thiết kế giao thức truyền thông cho thẻ này, làm việc với các kỹ sư phần cứngwho đã tính toán chính xác 4 kilobyte bộ nhớ FPGA cổng kép cho cơ chế doorbell.

Bốn. Kilobyte.

Bây giờ — hãy tưởng tượng có người bước vào một cuộc họp kế hoạch và đề xuất rằng thẻ này nên chạy... các tác nhân quản lý máy ảo Windows. Với COM. WMI. Performance counters. NTFS. ETW. Toàn bộ stack Enterprise Windows.

Và điều đó đã thực sự xảy ra.

Cuộc họp lẽ ra không bao giờ nên diễn ra

Tác giả đã gia nhập đội ngũ vào ngày đầu tiên. Thậm chí anh ấy chưa kịp lấy thẻ nhân viên khi quản lý yêu cầu tham gia cuộc họp kế hoạch hàng tháng sớm hơn dự kiến.

Anh ấy bước vào một phòng đầy ắp các kỹ sư — team leads, kiến trúc sư, principals, juniors — tất cả đang nhìn chằm chằm vào một slide phủ đầy các viết tắt của Windows. Một Principal Group Engineering Manager đã đi qua kế hoạch port Windows sang thẻ tăng tốc Overlake.

Tác giả đã đặt câu hỏi hiển nhiên: Bạn có định port các tính năng Windows đó sang Overlake không?

Câu trả lời là Có. Hoặc ít nhất là, "một vài dev junior có thể xem xét nó".

Căn phòng chìm vào im lặng.

Hãy nghĩ về ý nghĩa kỹ thuật của điều này. Bạn đang yêu cầu các lập trình viên junior điều tra việc port một hệ thống con hệ điều hành cứng cáp, kết hợp chặt chẽ — được thiết kế cho máy có RAM gigabyte và dung lượng nhiệt hàng trăm watt — sang một con chip chạy với ngân sách năng lượng chỉ bằng "một phần nhỏ" của CPU máy chủ. Một con chip chỉ có 4KB bộ nhớ chia sẻ trên FPGA.

Đây không叫 là tham vọng. Đây là tương đương với việc yêu cầu someone nhồi một con tàu biển vào bồn tắm, rồi bảo rằng, "để mấy thực tập sinh xem sao".

Tại sao chuyện này cứ lặp lại?

Nếu bạn từng làm việc tại một công ty công nghệ lớn, bạn hẳn đã thấy một phiên bản nào đó của chuyện này. Chi tiết thay đổi, nhưng khuôn mẫu thì luôn giống nhau:

1. Lãnh đạo xa rời thực tế kỹ thuật. Principal Engineering Manager trong căn phòng đó từng là một kỹ sư giỏi. Nhưng ở đâu đó trên con đường thăng tiến, khoảng cách giữa "nghe có lý trên slide" và "khả thi về mặt vật lý" đã trở nên quá lớn để nhận ra.
2. Tổ chức quá lớn để có những cuộc trò chuyện trung thực. Một tổ chức 122 người là quá lớn để vận hành dựa trên niềm tin và giao tiếp trực tiếp. Nó vận hành bằng quy trình, thứ bậc và sự tôn trọng. Không ai trong căn phòng muốn là người nói "điều này điên rồ" — đặc biệt là vào ngày đầu tiên đi làm.
3. Junior devs trở thành nguồn lực kỳ diệu. Hãy chú ý cách phất tay: "để mấy dev junior xem xét". Đây là dấu hiệu nhận biết. Khi lãnh đạo không hiểu độ phức tạp kỹ thuật của một nhiệm vụ, họ có xu giao cho người ít kinh nghiệm nhất, coi đó là "công tác khám phá". Thực tế thì junior tốn tuần lễ để chứng minh điều mà một senior khẳng định trong buổi chiều: nó bất khả thi.
4. Thiên kiến uy tín lấn át phán đoán kỹ thuật. Microsoft đã đặt cược lớn vào Azure là tương lai. Azure đặt cược vào Overlake. Overlake buộc phải thành công. Khi một tổ chức đã cam kết sâu sắc với một câu chuyện, việc thách thức câu chuyện đó — ngay cả bằng sự thật kỹ thuật — trở nên tốn kém về mặt chính trị.

Câu hỏi nghìn tỷ đô la

Tiêu đề bài viết là "How Microsoft Vaporized a Trillion Dollars" (Làm sao Microsoft bốc hơi nghìn tỷ đô la) — và trong khi loạt bài này vẫn đang được đăng tải, ý nghĩa tiềm ẩn đã rõ ràng:

Microsoft đã có cơ hội một lần trong thập kỷ với OpenAI. Họ đầu tư 10 tỷ USD. Họ có nhân tài, hạ tầng và thời điểm. Nhưng nội bộ, tổ chức kỹ thuật chịu trách nhiệm về hạ tầng sẽ chạy các workload của OpenAI lại đang... tranh luận xem có nên port Windows sang một con chip nhỏ hơn móng tay hay không.

Trong khi đó, các vấn đề về độ tin cậy và hiệu suất của Azure được tài liệu hóa đầy đủ. OpenAI từng nổi tiếng là vật lộn với hạ tầng Azure trong thời kỳ bùng nổ ChatGPT. Có tin đồn về căng thẳng giữa hai công ty về công suất và độ tin cậy của Azure. OpenAI thậm chí đã tự xây dựng trung tâm dữ liệu của riêng mình.

Microsoft đã không mất OpenAI. Nhưng họ đã đến rất gần điều đó hơn là những bản thông cáo báo chí gợi ý — và khi bạn đọc những câu chuyện firsthand như thế này, bạn bắt đầu hiểu tại sao.

Mỗi giờ nhân lực kỹ thuật dành cho các dự án port bất khả thi là một giờ không dành cho công việc thực tế. Ở quy mô lớn, điều này cộng hưởng. Không phải là hàng triệu. Mà là hàng tỷ.

Giải phẫu sự thất bại của văn hóa kỹ thuật

Hãy chính xác về những gì đã sai, vì những chẩn đoán mơ hồ dẫn đến những giải pháp mơ hồ.

Thất bại #1: Không có an toàn tâm lý cho sự bất đồng kỹ thuật

Tác giả đã đặt câu hỏi đúng. Căn phòng im lặng. Không ai ủng hộ anh ấy. Sự im lặng đó không trung tính — nó là triệu chứng của một tổ chức nơi việc lên tiếng phải trả giá xã hội.

Văn hóa kỹ thuật lành mạnh coi việc "điều này bất khả thi vì X, Y, Z" là một đóng góp, không phải là một cuộc tấn công. Một văn hóa độc hại coi đó là sự bất trung hoặc cản trở.

Thất bại #2: Lập hoạch tách rời thực tế

Lập hoạch tốt bao gồm những người thực sự hiểu các ràng buộc. Các kỹ sư phần cứng who quy định 4KB bộ nhớ FPGA lẽ ra phải có trong cuộc họp đó — hoặc các ràng buộc của họ phải có trong tài liệu kế hoạch. Nếu các kiến trúc sư tạo slide không biết giới hạn phần cứng, bạn đang lập hoạch trong chân không.

Thất bại #3: Chiến thuật "Junior Dev Moonshot"

Giao nhiệm vụ bất khả thi cho junior dev không làm nó trở nên khả thi. Nó làm nó trở nên vô hình. Công việc biến mất vào hàng đợi của junior, không có kết quả nào ra, và tháng sau ai đó phải giải thích tại sao sáng kiến bị đình trệ. Trong khi đó, junior dev đã tiêu tốn chu trình, không học được gì hữu ích, và có thể internalized thông điệp rằng họ thất bại — chứ không phải kế hoạch.

Nếu một nhiệm vụ thực sự mang tính khám phá, hãy xác định phạm vi rõ ràng, giới hạn thời gian, và có một senior engineer hướng dẫn quá trình. Đừng phất tay coi đó là "công việc của junior".

Thất bại #4: Thiếu văn hóa kỹ thuật của chữ "Không"

Amazon nổi tiếng với văn hóa "dây chuyền vàon cord" — bất kỳ nhân viên nào cũng có thể dừng dây chuyền lắp ráp nếu có điều gì đó sai. Microsoft Azure, ít nhất là trong câu chuyện này, dường như có điều ngược lại: một dây chuyền nơi việc nêu quan ngại kỹ thuật trước phòng đầy quản lý cần lòng can đảm phi thường.

Bạn có thể làm gì khi tổ chức của mình đi theo hướng này

Bạn có lẽ không thể tự sửa chữa một tổ chức 122 người. Nhưng bạn có thể bảo vệ bản thân và đội của mình:

1. Tài liệu hóa các ràng buộc kỹ thuật một cách rõ ràng và sớm.

Đừng để các cuộc họp lập hoạch diễn ra dựa trên các giả định mơ hồ. Nếu bạn biết một ràng buộc tồn tại ("thẻ này có 4KB bộ nhớ"), hãy viết nó ra trước cuộc họp. Buộc kế hoạch phải đối mặt với thực tế.

## Ràng buộc phần cứng — Azure Overlake SoC
- RAM: [X] MB có sẵn cho phần mềm khách
- Bộ nhớ chia sẻ FPGA: 4KB cổng kép
- Ngân sách năng lượng: [X]W (phần nhỏ của TDP CPU máy chủ)
- OS: Stack embedded dựa trên Linux
- Hệ quả: KHÔNG có thành phần nhân Windows (COM, WMI, ETW, NTFS) là mục tiêu có thể port được

2. Hỏi "ai sở hữu chữ 'Không'?"

Trong các tổ chức kỹ thuật lành mạnh, ai đó có quyền lực rõ ràng để nói "điều này vi phạm ràng buộc của chúng ta". Nếu không ai làm vậy, các quyết định kỹ thuật sẽ trôi dạt theo bất cứ điều gì nghe hay trong căn phòng. Làm rõ quyền sở hữu.

3. Giao việc thực cho juniors, không phải việc bất khả thi.

Nếu bạn đang dẫn dắt một đội ngũ, hãy trung thực: các nhiệm vụ bạn giao cho junior engineers có thực sự là cơ hội học hỏi tốt, hay chúng là cách lịch sự để trì hoãn các vấn đề bất khả thi? Cái trước xây dựng sự nghiệp. Cái sau hủy hoại nó.

4. Viết bài phân tích hậu sự trước khi thảm họa xảy ra.

Pre-mortems (phân tích trước cái chết) có hiệu quả. Trước khi cam kết với một kế hoạch kỹ thuật lớn, hãy dành 30 phút để hỏi: "Giả sử điều này thất bại. Tại sao nó thất bại?" Trong trường hợp này, câu trả lời sẽ rõ ràng trong chưa đầy 5 phút: bởi vì phần cứng mục tiêu không thể chạy stack chúng ta đang port.

5. Biết khi nào cần leo thang — và khi nào cần rời đi.

Không phải mọi tổ chức đều có thể sửa chữa từ bên trong. Đôi khi nước đi đúng đắn là tài liệu hóa quan ngại của bạn, leo thang chúng một cách rõ ràng — và nếu chúng bị phớt lờ — cập nhật hồ sơ xin việc của bạn. Tác giả cuối cùng đã rời Microsoft. Những câu chuyện anh ấy kể giờ đây cho thấy đó là một lời kêu gọi đúng đắn.

Mẫu hình rộng hơn: Thập kỷ suýt sửa sai của Microsoft

Đây không phải là một sự kiện bất thường. Nó phù hợp với một mô hình.

Những năm 2010, Microsoft suýt giết chính mình với Windows Phone, RT và thương vụ Nokia (một khoản giảm giá khoảng 7,6 tỷ USD). Họ suýt bỏ lỡ hoàn toàn đám mây — Azure đã đến muộn và yếu hơn AWS trong nhiều năm. Họ làm hỏng thương vụ GitHub về mặt văn hóa trước khi cuối cùng làm đúng. Họ đặt cược hàng tỷ vào metaverse (HoloLens) và lặng lẽ lùi lại.

Sau đó Satya Nadella xuất hiện, và một thời gian có vẻ như văn hóa đã thay đổi. Azure tăng trưởng. GitHub phát triển. Teams thống trị Slack. Và thương vụ đầu tư OpenAI trông giống như canh bạc thông minh nhất trong lịch sử công nghệ.

Nhưng những bài đăng như thế này cho thấy sự rối loạn không biến mất — nó chỉ di chuyển sâu hơn vào tổ chức. Các kháng thể văn hóa mà Nadella đưa ra ở cấp cao đã không chạm tới mọi đội 122 người trong mọi tòa nhà ở West Campus.

Đây là bài học thực sự: thay đổi văn hóa ở cấp cao là cần thiết nhưng chưa đủ. Bạn cũng cần những người ở năm cấp thấp hơn có thể nói "điều này vật lý là không thể" trước một phòng đầy các principals, và không cảm thấy sự nghiệp của mình lướt qua trước mắt họ khi làm vậy.

Bài học

Bài viết của Microsoft lan truyền vì một lý do. Không phải vì nó là câu chuyện về Microsoft — mà vì đó là câu chuyện về kỹ thuật. Đó là câu chuyện về một người có chuyên môn kỹ thuật bước vào một phòng và nhìn thấy những người có quyền lực lên kế hoạch cho một điều không thể thực hiện được.

Mọi kỹ sư có kinh nghiệm đều từng ở trong căn phòng đó. Câu hỏi là bạn làm gì khi đến đó.

Bạn có thể im lặng. Bạn có thể đặt câu hỏi và bị phớt lờ. Hoặc — và đây là con đường thực sự thay đổi mọi thứ — bạn có thể tài liệu hóa ràng buộc, đưa vào văn bản, leo thang rõ ràng, và làm cho việc tổ chức sau này không thể nói rằng họ không biết.

Microsoft có những kỹ sư. Họ có tiền. Họ có thời điểm. Việc họ có văn hóa để sử dụng cả ba cùng lúc hay không là điều vẫn đang được viết tiếp.

Tổ chức của bạn trông như thế nào ở 5 cấp dưới CEO? Đó là nơi văn hóa thực sự sinh sống.

Loạt bài đầy đủ của tác giả gốc đang được đăng tải tại isolveproblems.substack.com. Hãy đọc nó — đó là một trong những tài liệu firsthand đáng tin cậy nhất về sự rối loạn của Big Tech mà tôi đã thấy trong nhiều năm.

Bạn đã từng ở trong căn phòng đó chưa? Căn phòng nơi kế hoạch rõ ràng là bất khả thi và không ai muốn nói thành tiếng? Hãy cho tôi biết trong phần bình luận — tôi rất muốn nghe cách bạn xử lý nó.