老K使用的是手淘IOS版，今天的心情和手淘App，你永遠不知道哪一個先崩潰？開啟淘寶App的那一刻發現：原來用了幾年的手淘，竟然是個測試版！我不配用正式版嗎？
手機截圖
事故原因還在調查，微信群裡也流傳一些說法：某個IOS開發小哥哥，績效被打了3.25分，於是為了報復，埋下了這個BUG，於是3月25日全網大爆發，還不好說這個傳言有幾分可信度，搬好板凳吃瓜吧。
測試發現，手機時間調到3月28日，手淘App直接閃退，也就是說，留給淘寶團隊的時間不多了，如果3月28日之前，這個BUG沒有修復，全球的使用者將無法登入淘寶，這對於剛剛經歷疫情考驗的淘寶商家來說，無疑雪上加霜。對於淘Bora說，損失更是無法計量啊。
從目前了解的情況來看，可以得到以下資訊：
1、這個BUG出在IOS客戶端，並且埋得比較深。可想而知，這位IOS程式設計師跟公司是有多大仇恨啊，日防夜防，內鬼難防。
2、IOS客戶端技術團隊在code review上，有重大疏漏。這次恐怕手淘IOS客戶端技術團隊要全體3.25了，阿里這樣一個世界級技術公司，研發流程、制度、工具一定是完善的，這次大概率的原因是團隊執行不到位。
3、修復這個問題，需要重新發版，使用者重新安裝App。由於IOS禁止了熱更新機制，所以沒法像安卓那樣，實現熱修復。但是，IOS有靜默更新機制，所以淘寶App重新發版後，使用者在連wi-fi時會自動更新，對使用者來說是無感知的，前提是使用者之前同意靜默更新。
4、目前看來最佳方案是：在3月28日前，釋出強制更新版本。因為靜默更新總有遺漏的，後面造成使用者投訴，甚至刪除APP，影響就大了，索性犧牲一點使用者體驗，一步到位解決根本性問題。
5、敲個警鐘，要有法律意識啊。前有微盟運維員工刪庫，現在淘寶程式設計師埋BUG。奉勸大家要遵紀守法，對法律要有敬畏之心。
下面我們結合淘寶的5張技術架構圖來分析，這個BUG是如何發生的，有沒有機會防範等等話題：
01
從阿里技術架構看，BUG究竟發生在哪裡
下圖是阿里巴巴的技術棧全景圖，從2015年開始，阿里在全集團推行“大中臺小前臺”戰略，從圖中可以看到，移動中臺、業務中臺&資料中臺，支撐著前端的手機淘寶、手機天貓、優酷、菜鳥、高德等業務板塊。
注意一個現象，只有手機淘寶App出現這個問題，手機天貓沒有這個問題，就說明問題不是出在業務中臺和移動中臺，否則手機天貓App也應該出現這個BUG，因為整個生態的App都共享一箇中臺，在下一張圖中可以看到，幾百個業務應用，共享的是一個技術底座。
02
BUG發生，也反映了中臺架構的優勢
中臺的一個好處是，大家的業務邊界劃分得比較清晰，架構上接耦，可用性更高。換句話說，你想搞個整體破壞也比較難。
策劃了這次S1級事故的程式設計師小哥，絕對是個聰明人，只可惜才華用錯了地方，一時氣不過，釀成了大禍，丟工作是小事，搞不好這次要進去蹲幾年了，出來再去找程式的工作，怕是沒有哪家公司敢收了。
03
阿里的績效考核，在組織內部是如何進行的？
從組織架構維度上看，“大中臺小前臺”的組織架構下，淘寶隸屬電商事業群，該事業群裡有完整的技術團隊，包括：開發、產品、測試、運營等職能。績效考核也是從上至下，逐層打下去，比如逍遙子給電商事業群總經理蔣凡打了3.45，那麼蔣凡給淘寶網、天貓、1688這些事業部負責人分別打分，層層打到下面，肯定要有人背3.25的，阿里內部是強制排名，所以那位IOS程式設計師，可能運氣不好，被打了3.25。
04
除了手淘App團隊，還有哪些團隊需要背鍋？
其它部門有沒有責任呢？嚴格說來，支撐部門還是有點關係的，如下圖所示，共享部門有沒有提供好的支撐？比如，工程效能團隊，有沒有提供程式碼安全漏洞掃描工具。但是從這個BUG來看，如果隱含在業務程式碼裡，其實也很難能被自動掃描出來。所以這個鍋，還是負責Code review人背定了，本來就是他的責任所在啊，制度流程肯定都有，你執行得不夠嚴格，怪不得別人了。
05
寫在本文末尾的話
最後來欣賞下，世界一流的電商App手淘的技術架構，這是2017年淘寶架構師在技術大會上的分享，超大型電商平臺的架構都是類似的，感興趣可以看本文下方京東商城的技術架構，老K剛好在上一篇寫過。
阿里的架構勝在，大部分的核心技術元件都是自研，比較可控。比如說使用Flutter，你千萬不要說，人家鹹魚在用，我們也要用，人家有一堆的阿里P7、P8程式設計師，一言不合就改原始碼，你家公司就沒那麼任性吧。
最後，願每個公司都能引以為戒，認真執行每一次Code review，嚴格遵守研發流程制度。對個人來說，遇到跟公司之間的矛盾，不要一時衝動做傻事，尋求合理合法的方式來解決，萬一不行，還可以通過輿論曝光嘛。
願淘寶技術團隊儘快修復這個BUG。
作者簡介：K，知名電商公司技術老K級人物。文出過暢銷書，武做過CTO，若不是生活所迫，誰願意一身才華。