都說互聯網接管傳統產業，傳統企業轉型互聯網+，是必然趨勢。像歐洲航天局（ESA）這樣的政商一體機構，需不需要向互聯網公司學習呢？下面這個事例，高精尖高大上的ESA，在傳統互聯網公司在資深程序猿眼裡，某些方面實在是“外行”，由此造成了嚴重後果…
1996年6月4日，Ariane 5 運載火箭在法屬圭亞那發射，37秒後火箭啟動自動燃爆裝置，連同攜帶的4個價值不菲的科學衛星一同引爆。歐洲航天局（ESA）耗費10年心血，70億美元打造的Ariane 5，轉眼灰飛煙滅。而這一切，不過是由於一個小小的算法錯誤引起的。有多小？如果出現在日常生活裡，這個bug可能只會引起網頁過載崩潰，關閉重新打開網頁就能解決，而出現在箭載計算機上時……畫面太美太暴力，一起來感受一下，
看看Youtube上的網友是如何評價的
滲透到骨子裡的憂傷。。。
平復一下心情，我們來聊聊這場史上最昂貴的bug。
Arinae 5 為什麼會爆炸？來自ESA的調查報告顯示，當Ariane 5攀升到2.5英里時，火箭導航系統突然收到一組數據表明它已偏離軌道，因而下達航線修正指令。可實際情況並非如此，Ariane 5才剛剛上升37秒，方向正確且堅定無比地衝向雲霄。這個錯誤的指令直接導致火箭一不小心“調了個頭”，氣流無情地撕扯掉助推器，爆炸。
那麼錯誤數據從哪來的？
與其把火箭簡單比做是一臺機器，它更像是一個巨大且複雜的“機械有機體”。她有眼睛會衡量自己在空間中的定位，也有大腦進行分析並下達行動指令。其中火箭的慣性導航系統（IRS）就是Ariane5的眼睛。IRS利用測量火箭慣性參考系加速度，對時間進行積分再轉換到導航座標儀中，從而獲得火箭速度、航偏角、位置等信息。問題出在IRS進行數據處理時， 64bit的浮點數轉換到16bit的整數時發生了溢出（overflow）。嗯，bug 在這呢。
計算機中的溢出是代碼編寫中常見的錯誤來源。簡單來說，計算機會有一個長度已知的緩衝區用來存儲用戶輸入數據，當輸入數據超過緩衝區長度時就會發生溢出，而這些溢出的數據會覆蓋在合法的數據上，好像一個杯子裝了超過容積的水，總會溢出來。溢出的數據侵佔著IRS裡的其他空間，“潤物細無聲”地直接讓IRS死機了。
好端端的“一杯”代碼，怎麼就溢出了呢？其實，Ariane5 的慣性導航系統溢出值測量的是火箭的水平速率。Ariane5 的速度實在是太快了，快得遠遠超過了研發人員的預期，它比“姐姐”Ariane4 的速度高出了5倍，瞬間湧向服務器的大量數據直接導致處理器關機，且將錯誤信息發送給了箭載計算機，由此計算機發出了調整航向的指令，最終導致Ariane5的爆炸。
目睹了這樣一場“pretty fireworks”，民眾們都不淡定了。兩個月前還有人在記錄Ariane 5 爆炸的視頻下留言道：
果然是吃瓜群眾的簡單粗暴。
比起叫囂著反對，這個世界更需要我們綜合分析後的理性判斷。
仔細想想，Ariane 5 的爆炸雖然損失慘重，其始作俑者也只是個輕而易舉可以解決掉的小bug。事後，ESA決定不對任何具體部門追究責任，側面說明：這不是一個人的錯誤，這是一個流程的錯誤。
無論是Ariane5箭載計算機中的軟件，還是我們手機裡的App，一個完整的軟件開發大致要經過五個步驟：問題的定義和規劃、需求分析、軟件設計、程序編碼、軟件測試。對於航天火箭這樣複雜的“機械有機體”，其各個功能的需求分析和軟件設計顯然規劃異常嚴密；將軟件設計結果轉化為計算機可運行的程序代碼對於集中了人類智商極值的ESA科學家們也並非難事。問題出在Ariane 5是在沒有充分測試的情況下被推向天空，也瞬間走向毀滅。
如此低級的錯誤，如此簡陋的開發流程，跟互聯網公司是天差地別。即使是手機上的App，移動應用在開發最後一環的測試上，為了保證不出錯保證應用質量，像阿里、三星、小米、360這樣的巨頭除了自僱測試工程師外，還會用像Testin雲測這樣專業的第三方服務：調用16萬線上工程師的智力資源和5萬臺智能手機的終端設備，來測試兼容性和找Bug....反過來看官僚機構如歐洲航天局，後者對待代碼的態度，簡直處在石器時代。
即便是最成熟的代碼，也不得不允許適當的容錯率。而為了將這個出錯率降至最低，最靠譜的辦法就是讓代碼在多種模擬環境下重複運行。所有嚴密的工程裡，測試都應該是其生命週期中重要的一環。作坊式“現做現賣”，對於任何一個技術導向型的複雜程序來說，都是致命的打擊。 Ariane 5 爆炸後劃過的弧線，是其缺少足夠的測試而殘留在天際的悲傷。
我並不願過多強調Ariane5的爆炸在人力財力物力方面的巨大損失以及對所有研究人員情感的打擊。進步總伴隨著失敗，不完美的英雄也是英雄。一架火箭也好，一個App也好，我們竭盡所能的接近完美卻仍要接受意外。欣慰的是，1997年10月30日Ariane 5運載火箭進行第二次發射，終獲得成功。
最後放上那段出錯的代碼吧，一起來聽聽這段悲傷但仍應受到尊重的故事。
閱讀更多 偽geek 的文章
