隨著網友的爆料，攜程又一次被推倒了風口浪尖，原因還是疑似“大資料殺熟”問題。

在探討這個問題之前，首先講一個故事。我在2016年的時候參加了一個北京某著名機構組織的技術研討會，參與者大部分都是技術研發人員，有網際網路公司的研發骨幹，也有來自科研機構和高校的研發人員。在技術交流期間我聽到了一段非常有意思的對話，當時一名記者要採訪一名大資料專家，這名大資料專家極力的推辭，並否認自己從事大資料研發，到後來的對話就比較有意思了，這名專家說：我不是搞大資料的，你才是搞大資料的，你們全家都是搞大資料的。記得當時也出現了一次所謂的“大資料殺熟”的報道，這也許是這位專家“倍感焦慮”的原因吧。

回到正題，攜程此次事件的起因很簡單，網友在攜程購買機票之後發現漏填了資訊，退出購票程式並補填資訊之後再次購票突然發展價格漲了而且餘票不足，網友無奈之下透過航空公司的程式完成了購票，而且價格較攜程沒有漲價之前的票價還要低，這讓網友對攜程產品倍感失望。之後攜程立即做出了迴應，表示程式出現了“bug（缺陷）”，隨後也做出了一些具體的補救措施以挽回形象，同時強調並沒有“大資料殺熟”。

作為一名IT行業的從業者（研發人員），我對程式出現“bug”的情況比較熟悉，任何網際網路產品，或者說軟體產品都存在可能出現各種bug的情況，這並不奇怪。但是作為一款執行多年且成熟度較高的網際網路產品出現如此嚴重的bug，還是覺得有點不可思議。不知道此刻攜程的測試團隊是否正在做出深刻的檢討，是否正在加班加點積極檢查是否還有類似的bug沒有被發現，畢竟此次事件的影響還是比較大的。

不論此次攜程是否有“大資料殺熟”的情況，在資訊化高度透明的移動網際網路時代，企業透過“大資料殺熟”的方式來實現利益最大化是非常不明智的，這會對產品的形象造成巨大的損害。另外，大資料也不應該屢次成為“背鍋俠”，現在不少人在談到大資料的時候首先想到的概念就是“殺熟”，這讓不少從事大資料研發的人感到不安。相信未來大資料技術會給人們的生活帶來更多的美好，而不是各種“殺熟”。

每個行業估計都有一些潛規則，攜程被認為是大資料殺熟...什麼！你說又?認為攜程大資料殺熟的人其實不少，只是這次上了微博熱點罷了。

攜程的使用者人群多種多樣，多價敏感度不一樣。那些對於價格不那麼敏感，並且不是很介意攜程的剩餘票數總是顯示只有一兩張的使用者，一般不會意識到這些問題。不過對於價格敏感型消費者來說，付款前總是習慣性的記住下單價格，或者貨比三家。對於這些人，你重新拍下一次訂單，價格多了百分之十，當然是不願意咯。然後有些人不死心，正好拿自己另外的一個手機也註冊了一個新號下單，或者正好跟朋友對比了下價格和票數，這所謂的bug產生的價格差距，被質疑是大資料殺熟其實一點也不冤枉。@小果神的憤怒

確實殺熟，因為和做生意一樣，也是商業規矩，但如果對老會員有傷害，最後只能消失，重要的是有一個良好的競爭環境，不要形成壟斷

作為從業者，我是不相信給出的“bug論”的，接下來我會結合我的工作經驗來說明我為什麼不信。

首先概述過程，某大v在攜程上買機票，個人原因在付款階段取消了訂單，結果之後再看的時候，機票價格突然上漲，比官網還要貴不少。大v靠著自己的影響力，在網上披露了這件事，結合之前就曾經出現過類似的新聞，攜程不得不出面迴應，把鍋甩給了程式設計師，說是程式設計師的bug導致的，攜程並沒有惡意上抬飛機票價格。

我來講一下我的經歷，想證明的是，不要什麼事都甩給程式設計師，我們負責邏輯處理，不負責憑空編造數字。

我目前做的平臺每週都需要出一份報表，為了方便，我自己寫了一個指令碼，每週二凌晨定時觸發，呼叫另外一個服務來拉取我們的資料，我再把這份統計好的資料放到一個數據庫表中。這個指令碼寫好之後，我測過很多次，各種異常情況都能輕鬆carry。

但等到正式執行的下週二上班後，我去看資料庫，發現裡面有個資料不對，應該在60左右的資料，資料庫裡赫然記錄著100，我當時嚇壞了，以為我寫的程式碼有問題了。這種情況下，第一件事是再次呼叫那個服務，拉出正確的資料，然後手動去修改資料庫裡值，修復完數值之後，最後再去看指令碼。於是修改完資料後，我又開始鬱悶的debug模式，一步步執行指令碼，結果發現沒有任何問題，我當時心裡有點納悶，怎麼會出現這種情況，但考慮到目前問題不能復現，我就把這件事暫時擱置了。又等了一週，我發現新的資料還是不對，一些現在看起來是87左右的資料，資料庫裡赫然記錄的是83。

這次我能確認不是我的指令碼問題了，如果說因為某種未知的異常情況，是某個資料變成百分制的的上限，也許還能說得過去，但是任何異常處理都不會吧87變成83，那麼真相只有一個，就是在指令碼執行期間，對方服務的返回值就是83！於是我在腳本里增加了記錄對方服務返回的步驟，拿著這個日誌記錄去找對面介面人，結果人贓並獲，對面才確認是他們的問題。

這個經歷想告訴大家，我們程式設計師只是勤勤懇懇的寫程式碼，只負責邏輯處理，你給我多少資料就是多少資料，照理說，這個查詢航班價格的操作，只要輸入條件（時間，日期等等）一致，那麼執行流程也應該是一致的，不會第一次呼叫查詢的時候是一個價格，第二次查詢的時候，就走到有bug的模組裡偷偷給你加價的，再說你說加的這個差價，又進不到我們的工資卡里，何必呢？

所以，個別出行APP大資料殺熟就是不爭的事實，請不要再往我們不愛說話的程式設計師GG頭上扔黑鍋了。