為今年5月冠上多事之夏的名頭已是無可厚非的一件事，自支付寶光纖被挖斷后,攜程又暴出全站癱瘓的風波,從5/28 11:00開始，直到晚上11：29分才全面恢復.互聯網也是謠言四起,紛紛猜測百度騰訊誰會是下一個災難的受害者。暫切拋開這些玩笑言論,就攜程本次事情引發的思考太多,前車之鑒后事之師,如果攜程的事情發生到我們身上,我們該怎么辦，抱著這些問題我們來思考

1       全站癱瘓的原因分析

自攜程全站異常后,整個IT圈像炸了一樣的在瘋傳著各樣YY流言. 前離職高管報復行為;公司高管睡了運維小哥老婆,運維小哥一怒之下物理格式化硬盤;攜程收購藝龍后引發商業對手黑客攻擊入侵代碼;總之眾說紛紜.但簡單分析即可看到所有的分析均是定位破壞性非常大的行為,因為自攜程出事后3h后依舊無法對外提供正常服務,這點對外界的影響非常大,IT互聯網行為是以分鐘計算金錢,以流量衡量價值的行業,3h對于普通行業可能再正常不過,但對互聯網行業而言簡直是一場災難,況且攜程旅游行業的出名度,引發巨大輿論也是再正常不過,大家出于破壞性大的角度考慮也是再正常不過的角度.但最終官方給出的解釋卻讓人大跌眼鏡.運維人員誤發布導致.好吧~黑鍋總是需要有人來背的.從如下幾個方面來分析吧~

1.1     安全問題

1.1.1           人員安全

     這里的人員安全是指什么級別的人在操作,什么樣級別的運維能同時擁有對全業務的權限,攜程發展至今,在外界看來只是一個簡單的入口頁面,其實內嵌的頁面和功能很有可能是成百上千的,這樣龐大的業務體系如果直接交給一個新手來發布或者初級工程師來操作,那其責任更多的需要規究于領導責任,任重道遠,當然,從任何的角度來看,這樣的可能性很小,但如果是資深工程師的誤操作,那會是什么原因導致這樣嚴重的問題的.這樣的問題在dev,test,準生產環境為什么沒有發現呢,即使如上幾個環境均沒有發現,那最后一道保障–灰度環境為什么也沒有發現呢?如此發問下來,最少有一點是可以確認的,攜程沒有灰度環境或者本次發布一定沒有走灰度發布,難道本次發布只是一次小發布,沒有固化流程?

   案例:

   X公司,業務人員變更,主業務維護人在新人沒有完全上手的情況下,疏于協助,致使業務發布項遺漏,導致業務維護延期

1.1.2  固化流程

我們權且認為攜程本次的發布是一次小規模發布所以沒有走灰度,既然操作變更比較小,那是否有固化的操作列表供運維人員發布使用呢,rm –rf /*雖說低級,但不代表類似的錯誤沒有,身邊的例子不勝枚舉.固化的流程和操作列表是一次發布的保護神,所以我個人認為,即使灰度環境已經驗證過了,但依然出現如上的問題,那只有一個解釋,沒有固化的發布列表,運維人員純手工敲打鍵盤所致.如此看來的話,真的是運維小哥的問題了.

案例:

X公司某業務發布頻繁,且時常有凌晨發布狀況發生,致使業務運維和其它各部門疲于應對發布類工作且發布壓力較大,終有一日,業務運維發布過程中發布checklist遺漏,且為極為重要的操作步驟,導致業務數據回檔發布延期且投訴居多,對公司業務聲譽收入造成不可挽回損失.后采用自動化類工具固化后,此類從誤操作從根本上杜絕

1.1.3  灰度問題

如果說運維是生產環境最后一道保障,那灰度環境就是生產線最后一道屏障. 純手工誤操作和無灰度發布發布問題,不管從哪方面講對運維都不是一個好的消息.如果說純手工誤操作那最多說明攜程招人甚,但如果是灰度問題,那攜程的整個業務體系一定是不專業的,浮躁的. 在IT快速發展的國內,整個互聯網都以結果為導向,快速生產利益,快速上市圈錢,雖說互聯網的體系在不斷完善,但大體系中一定有輕有重,利益當道,利益部門的地位和權重一定優于其它部門.

案例:

X公司某業務發展迅速,業務急速擴張,各部門精力及資源嚴重偏向收益類功能開發和新用戶推廣類工作,疏于業務夯實業務基礎類功能開發及現有功能優化和現有業務思考,全業務在規模非常大的情況下依然采用全服發布方式,多次出現bug但無GM類工具挽救,每次均采用回滾或延期發布方式解決問題.后采用灰度發布后影響面和損失縮小不足原來1%

1.1.4  權限安全

從官方后來的解釋來看,沒有因為軟硬件系統后門或安全類原因導致.但內部人員的安全究竟如何我們很難一語評價. 早在剛到現任公司的時候,做的第一件事就是D/O分離,多次的線上文件丟失,數據異常,均因為開發擁有對線上權限過大導致所有的問題以說不清,找不到結束. 此后,項目權限最小化及測試服環境權限最小化,業務虛擬化推廣,此后,妖魔鬼怪類的問題也離我們遠去,再無蹤影,攜程數千人規模是否有類同問題還需要攜程內部自查了.

案例:

X公司某業務發布及程序運行用戶均為root,業務運維同學某次操作過程中因權限過大人誤刪除業務數據,所幸沒有造成災難性后果,這么看下來權限過大的問題是埋在地下的地雷,終究會有爆炸的那天,root權限回收,D/O分離,權限最小化—業務的保護傘

1.2     業務融入

據析攜程業務部門和運維部門完全分開,代碼的管理也只是部分代碼交于運維,開發部能自己維護的代碼一定是自己維護好,導致這種現象最大的問題在于利益切分,業務部門對服務部門依賴越大業務的利潤就要分割的越多,想必公司層面最原始的想法是好的,希望從制度上徹底杜絕資源浪費的情況,各部門自力更生,但導致的直接問題除了各部門資源重復外還有這次的問題應該是所有人難以相像的. 業務最好一道保障傘在對業務不了解的情況下,在問題出現后無法快速調動響應.

案例:

某業務被賦給公司極高期望,各部門及領導均極為關注,壓力隨之分散之業務及各部門,一時之間造成利益部門極為強勢的局面,服務部門均抱極為尷尬應對場面,終因一次不必要事故造成部門間沖突升級并造成極大影響力,各部門高級總監聚集召開緊急會議,甚至部分高層連夜飛回會議中心,終雙方拋開前嫌放下姿態共同支持業務

1.3     回滾時間長

1.3.1  備份問題

代碼拉取,更新,備份,發布,校驗,是一個業務完整的發布流程.看似簡單但技巧良多,其中的業務備份是運維和業務的保護傘,如若攜程本次問題真是rm –rf /類似災難性的操作,本機的備份是一定沒有了,但遠程機器的備份難倒也丟失了嗎?~這實在有些讓人費解. 鏡像或者快照功能也是難得也是做本地的嗎?對于攜程究竟何種技術細心導致本次細節問題至今仍無消息~倒是UC-王總和阿里–智錦的分析實在合理到位且頗具前瞻性。

1.3.2  SOA業務架構形態

阿里資深運維工程師 智錦 早在攜程出官網結論前已神預測到SOA的體系架構是導致攜程災難復建慢的原因.從業務最初形態到至今,早已不是單接口單應用AllInOne的架構,SOA帶來業務隔離性的同時也帶來了業務的靈活性復雜性, 如UC王總所說,隨著業務的越來越大,人員迭代,業務的運維對業務只能增加不敢減少的也是本次恢復慢的主要原因,本次業務代碼全丟失后,本次的問題相當于從零開始,而且是在無數舊人迭代和官網癱瘓的巨大壓力下完全重構業務. SOA體系帶來方便的同時也帶來業務的復雜程度提高,任何武器都是雙刃劍,使的招數則完全看掌握者,既然已經復雜了,但全量備份,異地或者跨主機備份呢？無論從哪種角度解釋都有很多招數可以迅速恢復~到此側面不同程度反應出攜程的虛擬化和備份一定有不足的地方,如此兩點夠攜程運維同學吃好大一鍋了~

2       公關問題

相對攜程來說,阿里的公關不得不說是專業的,在阿里光纖被挖斷分鐘級別已經對外公布問題,但攜程則完全不一樣,時至今日也只有對外一個簡單的說法,宕機后數小時后期間公司公關部門完全無所作為,甚至連阿里挑釁的微博引導流量也完全啞炮狀態,倒有一塊看熱鬧的懷疑,不禁讓人懷疑這公關部門是親生的嗎?實在讓人不以為然.

3       學習處

3.1     靜態有損服務

好了,現在可以來談談攜程本次問題優秀的地方,在業務完全宕機后,作為一家大公司,攜程的靜態有損服務總算給自己留下最后一點尊嚴.

3.2     請求導流到藝龍

    請求導流,攜程對藝龍的收購難道是對未來的預知嗎?開句玩笑話了,攜程在網站全癱瘓后,迅速把流量導向自己剛收購的藝龍,雖然藝龍不能承受隨之而來的并發,但思路最少是值得參考的.