知識星球來自：36氪（編譯組出品。編輯：郝鵬程、王雅琪）
http://36kr.com/p/5119417.html
編者按：從後來的很多反饋看來，Vista 都是一個超前於時代的作業系統。但這個作業系統在當年卻遭遇了前所未有的失利——究竟為什麼 Vista 會失敗、死亡？當時的專案團隊主管之一 Ben Fathi 在 Medium 發表了文章 What Really Happened with Vista: An Insider’s Retrospective，給我們提供了內部的視角。
Windows 有這麼一個傳統：團隊成員在新的 Windows 系統版本釋出後，會在海報上簽上自己的名字（本圖是一張 DVD）。而當釋出會結束的時候，海報上就會有成百上千個簽名。
經驗是你在需要的時候才會得到的東西。—— Steven Wright
我喜歡讀 Terry Crowley 的部落格（《Vista 到底怎麼了？》）。Terry“運籌帷幄之中”，雖然作為局外人，但卻把涉及到 Windows Vista 專案以及與之相關但已被放棄的 Longhorn 專案的複雜陰謀報道得精彩迭出。
他正確地指出了困擾這個專案的許多問題，不過在此我並不想重覆這些問題。我認為對這種事情，只有從一個內部人士的角度提出看法才不失公允。我也不奢望能夠像 Terry 的文章那樣說服力強，只求大家能對可能的錯誤有所瞭解。從 Windows Vista 的釋出日期算起，到現在，已經 10 年了，但這些教訓在現在比以往任何時候都更有意義。
Windows 團隊是個龐然大物，有成千上萬的開發人員、測試人員、專案經理、安全專家、介面設計人員、架構師等等，還有人力資源人員、招聘人員、銷售人員、律師，當然還有很多經理、董事和副總裁等等。然後還有成千上萬的合作團隊（在微軟內部以及外部）支援這一整個系列的團隊的運作，範圍從底層硬體到裝置驅動程式，再到平臺上的應用程式。
微軟足球場上，Windows 團隊的照片。（航拍）
從組織上來說，Windows 實際上包含了三個團隊：核心、伺服器和客戶端團隊。核心團隊負責操作 Windows 系統所有版本所共享的一切核心元件（核心本身、儲存、安全、網路、裝置驅動程式、安裝和升級模型、Win32 等）。而伺服器團隊則專註於伺服器市場所需的技術（終端服務、叢集和高可用性、企業管理工具等），而客戶端團隊負責與桌面和消費者相關（web 瀏覽器、媒體播放器、圖片等）的技術。
當然還有其他的組織機構，雖然 Windows 越來越受歡迎，團隊的規模也在擴大，但基本結構仍然保持不變。可以說，從文化和組織角度講，核心團隊更接近伺服器團隊而不是客戶端團隊——至少在 Vista 釋出之前是這樣。
我的微軟經歷
我是 1998 年入職微軟的。然後我很幸運，在這頭龐然大物裡獃了十幾年——在 Windows 2000 的全盛時期加入了它，並一直堅持到 Windows 7 的釋出。
在任期的前 7 年裡，我管理負責儲存、檔案系統、高可用性/叢集、檔案級網路協議、分散式檔案系統和相關技術的團隊。這與 Windows 2000、XP、Server 2003 和 Longhorn 大致相同。
後來，我就調到了負責管理安全專案的部門，可能待了有一兩年的時間吧——大概是從 Longhorn 專案重啟到 Vista 釋出。我的職責範圍從 Windows 的安全技術到防毒產品，再到安全營銷的附加解決方案，以及安全補丁等緊急響應。病毒和蠕蟲給 Windows 帶來了巨大的打擊，讓微軟在市場上建立的安全軟體的聲譽毀於一旦。
在 Vista 釋出之後，以及 Windows 7 開發之前的這段時間裡，我管理著 Windows 的所有核心開發事務。這意味著所有技術開發全都在後臺執行，客戶端和伺服器團隊都可以使用。在 Vista 釋出後，Windows 各級團隊由開發、測試和專案管理三方負責組織，所以我最後跟兩人一起負責，我管理開發團隊，他們分別管理測試和專案管理團隊。
Windows 團隊曾經嘗試過許多大規模和有野心的專案，不過這些專案在幾年後往往被放棄或重新規劃。更早的例子是雄心勃勃的 Cairo 專案，它最終失敗了，最後有些殘存的理念傳承至 Windows 2000 中。
問題1：更新迭代的時長過久
在我看來，Windows 最大的問題在於每個版本的時長。平均而言，一個版本從開始到完成大約需要 3 年時間，但“新”程式碼的開發時間只有大約 6 到 9 個月。其餘時間都用於整合、測試之類的——每個階段持續幾個月。
一些專案的核心開發時間要超過 6 個月，所以它們就齊頭併進，最後在準備就緒時與主程式碼庫合併。這意味著主幹幾乎總是支離破碎的，因為大量的功能被整合或替換掉了。在 Windows 7 釋出期間，為了確保有一個持續健康和功能正常的程式碼庫，我們對其進行了更嚴格的控制，但之前釋出的版本都有好幾個月的不穩定期。
開發過程總體來說還是比較混亂的，開發人員會說服自己和他人他們的程式碼優於別的專案，他們最後能及時最佳化僅剩的一些小部分，這樣一來即使是半成品，這也是一個可以釋出的版本。
3 年的釋出週期意味著我們很少知道當我們釋出新版本時，外部的競爭環境會是什麼樣子的。錯過一場釋出意味著專案取消，但一個團隊或高管就是不能讓自己放棄。我個人也負責過一些這樣的專案。
問題2：團隊龐大，進度不一致且最終測試難
考慮到每個團隊都想把自己的東西夾在新版本中，所以他們通常會在與其他元件的整合、使用者介面、端間測試以及升級等繁瑣而乏味的問題上浪費時間，卻忽略了棘手的問題。反過來，這意味著一些團隊很快變成了別人的瓶頸，因為每個人都在為最後一刻完成使用者介面設計或升級測試而努力。
在任何給定的時間點，都有多個主要的版本處於開髮狀態。隨著時間的推移，不同的團隊負責不同情況下的程式碼庫開發導致了馬太效應——由於某種原因落後的團隊往往會更落後。
當一個專案接近完成時，專案經理將開始關註下一個版本的需求，而“健康”（富有）團隊的開發人員將開始執行新的程式碼，但是組織的大部分（窮人）仍然要應用當前版本。特別是測試團隊很少從舊版本中解放出來，直到它釋出，所以新程式碼在專案開始時並沒有經過徹底的測試，因為“不健康”的團隊總是落後，對當前版本進行最後的修改，然後進一步落後。這些團隊通常是士氣最低、耗時最高的團隊，這意味著工程師們接手的是他們沒有編寫過、因而也不理解的程式碼。
問題3：與軟體供應商關於安全問題的矛盾
在 Vista/Longhorn 專案的大部分時間裡，我負責的板塊是儲存和檔案系統技術，也就是說我參與了 WinFS 的工作，儘管它主要是由 SQL 資料庫團隊（Windows 團隊的一個姐妹組織）發起的。比爾·蓋茨甚至親自參與，甚至被戲稱為“WinFS”專案經理。
不過事後看來，顯然谷歌輕鬆地解決了為非結構化資料提供無縫且快速搜尋的問題。不過他們這樣做是為了整個網際網路，而不僅僅是為了你的磁碟容量。
當 Longhorn 專案被取消，Vista 殘存的一鱗半爪匆匆組裝在一起時，WinFS 專案就已經被否決了。SQL 團隊將它作為一個獨立的專案進行了幾年。而那時 Windows 已經有了一個內建的索引引擎，而且完全是在不需要更改變更應用的情況下實現的。因此，WinFS 的相關性變得更加模糊，可專案卻仍在繼續。
Longhorn 專案中大量與安全相關的架構在該專案廢止之後，被儲存為 Windows Vista 專案的一部分。我們在迅速膨脹的網際網路世界中學習了很多安全知識，並希望將所學到的經驗用於作業系統之中，以提高所有客戶的整體安全性。
我們別無選擇。因為 Windows XP 表明瞭我們是自己成功產品的受害者。當面對網際網路時代的現實時，一個設計初衷僅為實用的系統在滿足安全性方面是遠遠不夠的。解決這些安全問題意味著建立一個並行的專案，即 Windows XP Service Pack 2，這是一項巨大的工程，而且從 Longhorn 專案中汲取了數千個資源。
在 Vista 中執行嚴格的管理邊界意味著打破 Windows 系統中的每一個應用程式。部分的解決方案是使用者帳戶控制，但這可以說是 Vista 最令人討厭的特性。當使用者在執行命令時，系統總會詢問使用者是否真的打算提高許可權級別。由於安裝遺留應用幾乎總是需要提升特權，因此使用者在系統上的初體驗就是大量的賬戶控制視窗彈出，毫無疑問這不會給使用者留下什麼好影響。而如果管理許可權從登入使用者中被刪除了，可以毫不誇張地說 99% 的 Windows 應用程式都無法正常安裝。
從各方面來看，Vista 比微軟之前釋出的任何作業系統都要安全得多，但在這個過程中，我們也以前所未有的方式打破了應用程式和裝置驅動程式的相容性，因為我們不再支援臭名昭著的應用了，或者使用像使用者賬戶控制這樣的機制來繞過它們。客戶們討厭它，因為他們的應用程式崩潰了；系統合作伙伴討厭它，因為他們覺得他們沒有足夠的時間更新和認證應用程式，所以 Vista 就這樣被掃地出門。
在許多情況下，這些安全性質的更改意味著需要對第三方解決方案進行深入的系統結構改變。而且大多數系統的供應商都沒有對他們遺留的應用程式進行大量的改進投資。其中一些解決方案採用了非正統的方法來修改資料結構，甚至在核心中使用指令來實現它們的功能，這就經常性地造成嚴重破壞。而大約 70% 的 Windows“藍色畫面”是由這些第三方驅動程式造成的，他們不願意使用支援的介面程式來實現他們的功能。防毒軟體供應商因為使用這種方法所以一向口碑不佳。
在我擔任微軟的安全主管期間，我花了數年時間向防毒軟體廠商解釋為什麼我們將不再允許他們為核心記憶體中的指令和資料結構打補丁、為什麼這是一個安全隱患，以及為什麼他們需要使用我們批准的程式介面，我們將不再支援他們的遺留應用程式與 Windows 核心掛鉤——因為駭客們會用同樣的方法來攻擊消費者。我們的“朋友”——防毒軟體——威脅要起訴我們，聲稱我們是在阻礙他們的生計，濫用我們的壟斷力量！簡直了，有這樣的朋友，誰還需要敵人？即使冒著降低我們共同客戶的安全的風險，他們也不願意改進本就應該改進的方法。
問題4、5、6：新形勢、大型公司創新難、壟斷
計算機行業那些年裡發生了翻天覆地的變化——手機的興起，雲端計算的出現，建立新的廣告業樣式，社交媒體的病毒式增長，64 位計算機的成熟等等，而這些只是 Windows 面臨的攻擊的一小部分。
這很正常，因為這體現出了創新者的困境。我們新增的程式碼越多，專案的複雜度就越高，團隊的規模就越大，系統規模也越大，也就越難跨越競爭。
好像競爭的壓力還不夠似的，工程師們和專案經理們還得花無數個小時和來自司法部以及公司律師的代表們一起研究看是不是違反了反壟斷法律。
更為殘酷的是，產品的生命週期決定了大約需要 3 年時間才能推出一個主要的 Windows 版本，但這對於日新月異的市場來說實在是太慢了。WinFS、安全性和託管程式碼只是 Longhorn 議程上的一些大型專案，除此之外還有數不清的的小賭註。
當你公司上下有成千上萬的人、客戶有數十億的時候，每個人就都有發言權。那些被認為能夠在未來應用到平板和手機的作業系統現在還被要求也能應用到膝上型電腦上、資料中心的伺服器上等等不一而足——更不用說雲端的虛擬機器監控程式。當我們試圖同時在市場的各個環節上取得進展時，這些要求與團隊的努力完全是南轅北轍。
Longhorn 和 Vista 不可能被孤立地看待。它們只有在與之前及之後釋出的版本（Windows 2000 和 XP, Windows Server 2008 和 Windows 7）結合在一起看時才有意義，這樣也能對整個行業有個更全面的瞭解。
問題7：相容性難題
Windows 是它自身成功的受害者。它已經成功地滲透到許多市場，而那些市場業務現在對作業系統的設計產生了一定的影響，使其設計理念常常是互相衝突的。嘗試滿足所有這些不同的需求意味著不能完全滿足其中任何一個需求。
微軟在九十年代取得過巨大成功，但在十年後陷入困境。因為周圍的世界在不斷變化，我們在努力跟上它。說實話，這些趨勢我們都把握到了，也努力地回應它們。
簡而言之，我們其實知道當一個特定的作業系統即將被髮布時，它在三四年前就已經過時了。而我們所能做的最好的事情是為新的雲服務提供增量和無摩擦的服務。但恰恰相反，我們不斷向現有的系統裡新增功能，這就需要在每次釋出之前進行數月的測試，結果就在我們最需要加速的時候速度反而變慢了。當然，我們也沒法刪除舊的功能，這些功能確保了在 Windows 上已經執行的應用程式的相容性。
現在想象一下，在十幾年或更長的時間裡，為數十億的客戶、數百萬的公司、成千上萬的合作伙伴、成百上千的場景和數十種形式提供一種全支援的作業系統，你就會逐漸對相容性的噩夢有所瞭解了。
事後看來，Linux 在這方面更成功。開源社群和軟體開發的方法無疑是解決方案的一部分。在這方面，Unix/Linux 的模組化和可插式架構實現了體系結構的有效改進。
微軟的“作戰室”，後來改成“研討室”
內部組織的動態和個性也很重要。我們都有自己最喜歡的特性，我們合作伙伴推動我們採用新的標準，幫助它們在平臺上認證。我們都有證明我們的技術和想法的野心……只要我們能在下一個 Windows 版本中體現出來並“俘獲”數以百萬計的客戶。
然而開發團隊和測試團隊難以保持一致，因為前者努力鍵入程式碼，後者則致力於發現更複雜和深奧的測試用例。至少可以說，組織內部的動態很複雜。
當然，這一切都不應該被當作藉口。
我們有沒有做錯什麼？當然有，而且錯的不少。
但我們是故意犯錯的嗎？當然不是。
我們能做的更好嗎？當然可以。
換到今天我們能做的更好嗎？當然不，此一時，彼一時。
現在回望過去的時候，應該沮喪還是悔恨呢？我更喜歡把它當成經驗教訓。我敢確定我們沒有人在以後的專案中會犯同樣的錯誤。前事不忘，後事之師。人非聖賢，孰能無過？
●本文編號442，以後想閱讀這篇文章直接輸入442即可
●輸入m獲取到文章目錄
C/C++程式設計
更多推薦《18個技術類公眾微信》
涵蓋：程式人生、演演算法與資料結構、駭客技術與網路安全、大資料技術、前端開發、Java、Python、Web開發、安卓開發、iOS開發、C/C++、.NET、Linux、資料庫、運維等。
