沒有十全十美的技術！攜程事件之后，技術專家們的建議與反思
攜程宕機事件留給業內無數反思。官方最初說法是“部分服務器遭到不明攻擊”，然而“緊急恢復”遲遲不成功，5月 29日凌晨恢復服務后，攜程稱是“員工錯誤操作導致”。而網上流傳的說法，說數據庫數據和備份數據被物理刪除者有之，說各個節點的業務代碼被刪除有之，不一而足。本文根據微信群的專家討論和各公眾號文章整理技術人應該得到的一些啟示。
- 林帆，ThoughtWorks成都辦公室CloudOps小組成員，DevOps愛好者
簡單來說，事故根本問題是服務依賴和啟動依賴管理沒做好，使得局部問題擴大化了。從攜程最后的解釋來看，他們的后端是典型的微服務架構，但是恢復時間這么久，也就是沒意識到微服務會帶來依賴管理的隱患，自己把自己坑進去了。
那么幾百上千個服務相互依賴，如果只是平時在線部署更新，不會停止服務，都看似運行穩定。但是一旦一個服務掛了，就連帶整個系統像多米諾骨牌一樣依次掛掉，這就是為什么一開始只是APP服務出問題，發展到后來整個后端都不運行了。然后恢復這上千個服務的時候，因為復雜的依賴，確定啟動順序以及啟動以后的驗證就非常耗時。說明他們內部服務部署的依賴管理是沒有足夠智能和自動化，摻入了不少手工操作的工作。
所以我覺得攜程這次出現問題，主要還是在微服務架構實踐上的失誤。如果使用了Docker這樣的容器，在后期恢復服務時候能夠獲得不少部署速度上的提升，也許可以減少恢復所需的時間。但并不能從根本上杜絕這種問題的發生。Docker在集群化部署的實踐里面會比較強調依賴管理自動化，比如 Compose就是做這個的。但也不是所有Docker集群工具都有，比如Kubernetes就不包含服務依賴的管理。
使用了容器，比如Docker以后，會讓服務的部署變得簡單，運維人員就可以把注意力更集中在服務層面的調度和管理上，不被細節分心。從這個層面上就更容易從系統全局上關注部署順序和局部故障處理這些事情。
- 智錦，資深運維從業者，自動化運維和云計算倡導者，原支付寶運維團隊創始人（微信公眾號： 數據中心操作系統）
作為運維老兵，智錦第一時間在公眾號也發了一篇深度文章《 深入解析和反思攜程宕機事件》。
從現象上看，確實是攜程的應用程序和數據庫都被刪除。這是一個由運維引發的問題，但真正的根源其實不僅僅在運維，預防和治理更應該從整個企業的治理入手。運維就是需要預防小概率事件，運維制度化是靠產品化去實現的，制度和流程要固化到產品中去。
真正有效的根源解決做法是從黑盒運維（運維人員不斷的去做重復性的操作，不知道應用的依賴關系，哪些配置是有效配置、哪些是無效配置）走向白盒運維。和puppet這樣的運維工具理念一致，運維的核心和難點其實是配置管理，運維人員只有真正的清楚所管理的系統的功能和配置，才能從根源上解決到處救火疲于奔命的情況，也才能真正的杜絕今天攜程這樣的事件重現，從根本上解決運維的問題。
從黑盒運維走向白盒運維，再進一步實現devops（開發運維銜接）和軟件定義數據中心，就是所謂的運維2.0。單靠運維部門自身是做不到的，需要每一個企業的管理者、業務部門、開發部門去思考。
- 郭理靖，京東云平臺開放云事業部與公有云事業部高級總監
在虎嗅發表了一篇文章《攜程可能攤上大事了——崩潰原因分析之「高能技術貼」 》分析的很深刻。
從這次攻擊的事件來看，數據庫整體被攻擊的可能性非常大。雖然黑客有可能把數據從云存儲的應用端刪除，但是服務端這些數據可能還存在。數據是否可以恢復要取決于私有云存儲的架構。從公開的報道來看，攜程內部私有云用的是OpenStack，那么很有可能是使用Swift的存儲，除非黑客也是非常熟悉Swift的架構，把Swift上的三個備份的機器找到，進行物理刪除。否則，數據還是有可能恢復的。如果到備份到存儲一體機，我相信數據還是有可能找的回來的。
最壞的情況是：黑客掌握了攜程大部分機器的root權限,同時進行無差別的毀滅性的攻擊的話（業務節點、數據庫節點、存儲節點），則后果不堪設想。
- 張鑫，ZStack發起者和總架構師，在微信群中提到：
我今天在想，與其運維產品化，是不是運維制度化更加重要，也更容易實現？其次，下面的IaaS層是不是有問題？這個情況下，應該銷毀已出問題的虛擬機，直接重新部署新的。而不是復用以前的，因為你根本不知道以前的里面感染了什么問題。
- 王津銀，資深運維專家，曾參與騰訊、YY、UC運維（微信公眾號：互聯網運維雜談），在微信群中提到：
很多技術層面的東西值得細敲，包括他們的DO分離，權限分級，重大變更的確認，統一的應用管理，灰度等等。灰度是最重要的變更策略，都不遵守。 必須把制度和流程固化 到產品中，把變更灰度作為工具的一部分，實現平臺約束。
把灰度作為變更系統的默認功能，無論是配置管理的變更，還是上層應用的變更，都不會讓運維人員一次對全網進行操作的。
灰度有兩個層面：一個是運維側的機器級灰度；二是應用級別灰度。對于一個變更行為來說，運維需要少量灰度部分機器，確認變更是否達到預期，然后在逐步放量。另外應用級別的灰度，就是根據用戶的信息進行灰度，比如說某個號段，某個區域的用戶才能使用新的功能。進一步確定業務功能正常情況。
運維級別的灰度幾乎是運維規范意識的一部分，需要通過平臺約束，否則腳本型批量變更方式必然有這個后果。常在河邊走沒有不濕腳的。
王津銀隨后還發表了一篇反思文章：《攜程事件：運維債務的深度剖析與解決方案》，從架構、流程規范、工具與平臺、安全，灰度機制、意識、環境管理、數據管理、架構等多個角度，全面分析了我們欠下的運維債務，并給出實踐中的解決方案。
- 胡茂華，多備份聯合創始人& CEO ，曾就職于騰訊、盛大(旅游)、1號店，歷任總監、CTO、技術副總裁
不難理解，攜程做為一個在線海量交易平臺，后端還連接一個3萬人的呼叫中心系統，以及對接國內外的海量的機票和酒店庫存系統，系統的耦合度非常高，應用程序部署在數萬臺服務器上，即使SOA實施的再完美，這些應用程序二次發布無論是自動發布還是半自動維護，二次重新部署時間一定很長，就這些 war包應用程序都有可能把整個內網的流量撐爆，這些應用程序還要分發到不同的IDC，專線肯定都不夠用，恢復時長在所難免，同時交易鏈條越長，整個服務可用性驗證也很艱辛。
要防范此類異常情況，一是應用發布平臺要改造，應用程序動靜態分離，嚴格的工作流審批發布程序；二是核心流程自動化測試，縮短應用上線服務驗證時間；三是所有在線應用程序都要做備份和版本管理，需要一個可視化的集中管理平臺維護最新版本和應用之間的關系；四是重視演練，災難恢復要做到一周一小練，一月一大練。
總之，運維是一個細活慢活，業務發展的再快再好，也要平時累積資源和能力，正所謂養兵千日，用兵一時，關鍵時刻還是得靠自動化工具和流程來約束，而不是人肉維護。
- 王濤，巨杉數據庫聯合創始人兼CTO，曾被CSDN評為 2014 TOP50最具價值CTO。作為原IBM DB2 Lab核心成員，數據庫專家，就本次攜程事件發表文章《 攜程事件反思：是時候重視數據庫災備了！》
主備庫之間的延遲。既然主備庫分別部署在不同的數據中心，互聯網延遲則是必須考慮的因素。主備庫之間的延遲越小，當主庫出現故障時丟失的數據越少。例如如果主備庫之間的延遲可以縮小到一秒鐘以內，當主庫所在的系統出現人為或非可控災難的時候，主備庫切換所造成的數據損失會被限定在一秒鐘內，這樣和整個門戶網站的癱瘓比起來，企業所遭受的損失幾乎可以忽略不計。
占用帶寬小。一般來說，主備數據中心之間的網絡帶寬非常昂貴。由于主備數據中心之間的網絡一般都是跨廣域網的，因此其帶寬的承受能力絕對不能像局域網那樣假設為千兆或萬兆帶寬。因此，在網絡傳輸時數據通道的條數，數據傳輸時的壓縮比率都是非常重要的指標。
安全的傳輸通道。既然數據是跨廣域網的傳輸，如果有人在機房外架設嗅探器，是否可以截獲我們的網絡通訊呢？如果主備節點之間總是以明文通訊，這絕對是一個非常重大的安全隱患。因此，主備數據中心之間的數據通訊是否加密則是第三個重要的安全指標。
除此之外，還有安全領域專家的多篇分析。
攜程目前已經恢復正常，并在5月29日1：30分發布聲明：
5月29日1：30分，經攜程技術排查，確認此次事件是由于員工錯誤操作導致。由于攜程涉及的業務、應用及服務繁多，驗證應用與服務之間的功能是否正常運行，花了較長時間。攜程官方網站及APP已于28日23:29全面恢復正常。對用戶造成的不便，攜程再次深表歉意。
當服務越加互聯網化，技術就越加重要，技術人的責任感和使命感就要越強。沒有十全十美的技術，但可以有更多方案來保障服務的正常運營。留給大家的思考還有很多。