張曉強
平安銀行
科技營運中心副總經理
大家好！我是來自于平安銀行科技營運中心副總經理的張曉強，今天我給大家分享的為“建構銀行運維SWAT-特殊武器攻擊隊”。
我想問大家，誰知道SWAT？特别對運維來講，SWAT是做什麼的？我先講下SWAT是做什麼的。今天我的PPT做的并不複雜，更多并不是給大家介紹一個具體的工具，更多是一些理念。
我們知道銀行運維最關鍵的兩個名額是非常高要求的，5分鐘内必須要恢複，如何做到？其實是很難的。我們不僅要在工具上，甚至對故障的流程、理念上必須要有思考，做好銀行的運維是一件非常有挑戰性的事情。
我加入銀行的時間不長，一年不到。過去20年我都在網際網路企業，在eBay和攜程都工作過，到銀行後，我把過去在網際網路的經驗帶過來了，大家做的方法都比較類似。
回答一下大家什麼是SWAT，SWAT源自哪裡呢？叫Special Weapons And Tactics，是美國特種部隊。2013年有一部美國大片就叫《SWAT》，是一部很精彩的動作大片，從那天開始我真正知道了代表的是什麼。
SWAT在警察部隊裡是沖在一線的，處理各種緊急情況的團隊，運維也是一樣，運維故障發生的時間都是不可預測的，是以我們需要有這麼一個團隊。這樣的團隊是否需要專職，專門組建呢？也不一定，可以根據實際情況來決定。
對這個團隊最基本的定義，首先團隊裡必須是運維各個領域的專家級，對運維的各個Layer 基礎價格必須要有專家級人工，因為運維有24小時值班的機制，團隊可能不是現場值班，但屬于24小時待命的狀态。跟警察一樣是沖在解決運維故障的第一線。這就是我對運維 SWAT 團隊的定位。
再具體一點，生産運維系統不僅受到銀行的關注，同時還會受到監管的關注。監管對銀行的要求是如果一個事件發生超過了30分鐘，就必須要報到監管那去，要給監管解釋這個事情所有的來龍去脈，甚至監管可以進入銀行做進一步調研。
為什麼要花這麼長時間才能恢複故障？要把處理的過程、流程、故障的日志都要拿去做分析，同時跟你講可能這一塊兒做的不好要整改，給你下一個整改的文。我們更需要沖在第一線幫我們快速恢複生産事件。
常見的生産運維事件都是不可預測的，監控系統就是用來發現這些問題。剛剛王總講了，大機在銀行内部是5分鐘，30分鐘是監管的要求，但事實上5分鐘要做到太難了，5分鐘甚至連問題在哪裡都發現不了。
是以有時候并不是簡單的技術問題，甚至我們做了很多工具有沒有在真正發生故障的時候發揮作用還很難說，是以必須在價值上、團隊流程上保證對生産運維故障的發現是屬于相對比較穩定的，而不是發現故障隻用1分鐘，處理另外一個故障的時候卻花了半個小時到一個小時。
團隊職責大家都懂，我也不具體解釋了。再細分一下需要哪些知識，需要對銀行的應用架構有非常精細的了解，不僅要知道應用的架構，還要知道部署的架構，跟技術架構相關的。
還需要知道一些應用異常時的表現和大概處理的機制，還需要知道銀行的應用關系也是非常複雜，要如何知道應用之間的關系和依賴關系，還要知道最核心的邏輯是如何實作的。對運維最基本的能力就不一一細講了。
關鍵講一下SWAT的“武器”，有一本書叫《七種武器》，總結來講運維SWAT團隊需要7種武器幫我們發現問題，迅速地定位問題做根因分析。不斷地訓練團隊恢複故障，分析運維故障離不開4個戰術。恢複戰術總體來講無非就是用4種方法恢複生産的故障。
稍微具體一點講一下。
這是最重要的。概括來講監控是不太容易做好的事情，大家都知道監控很重要，真正把監控做好和落地不是告訴大家用像普羅米修斯（prometheus）這樣的監控工具就解決了。通常來講會把監控分為三個層次，每個層次可以更細化一點。
（1）業務監控。銀行、網際網路最重要的就是業務，需要知道業務名額是否正常，一定會做業務監控，要知道業務名額在發生故障的時候有什麼異常的表現。
對銀行來講，銀行不在意這方面的名額，像口袋銀行更關注的是轉賬的筆數，這段時間有多少人登陸了口袋銀行。為什麼要關注業務呢？因為接下來我們要做的是關鍵路徑。什麼是關鍵路徑呢？關鍵路徑很多，你怎麼定義什麼是你的關鍵路徑？出發點就來自于你的業務。
如果我要監控使用者的轉帳業務名額是否正常，除了業務要根據此來定義出關鍵路徑，就需要看轉帳從口袋銀行進來以後會經過哪幾個環節，經過哪些應用的調用關系。不然如果你對你的業務了解的不透徹的話，你就很難定義出關鍵路徑。
為什麼需要關鍵路徑呢？因為網際網路金融化以後調用太複雜了，可能是成百上千，但事實上不可能有能力監控到這麼多，是以最最重要的是怎麼找出關鍵路徑是什麼，而且如果我們把關鍵路徑整體掌握的話基本上就解決了大部分重要的問題。因為很多其他非關鍵的名額或多或少都會這條路徑本身。
（2）應用監控，業務監控是告訴我們生産有沒有故障，問題是你要解決故障要知道哪裡有故障，應用監控是告訴我們支援業務的系統、子系統、應用出了問題，不一定出了很嚴重的問題，但如果變慢了也是冒煙的信号。
（3）系統監控，基本所有運維人一開始做的就是基礎架構的監控，但今天資料中心規模基礎架構本身監控每天會帶來一天700、800條，這麼多就處理不過來。是以需要的是上層的監控告訴你基礎架構的緊急度。雖然你會做聚合，可是你還是想知道基礎架構本身的監控告警對業務真正的影響是什麼。
如果對業務沒有非常大的影響，你配置設定和處理的時效就沒有那麼緊急。但如果業務和應用已經明确告訴你同時又有很明顯的指向基礎架構本身，那你很容易知道是哪一個基礎設施給你帶來的問題。
關鍵路徑再給大家細講一下，我們做的大概方法是會把銀行最核心的關鍵路徑，每天大家打開App本身第一個點的按紐是餘額查詢，現在在銀行有這個習慣，每天打開來先察看一下餘額。這就是關鍵路徑，對使用者來講打開APP如果查不到餘額，甚至看不到卡就會慌張，這就是關鍵的業務。
是以這也是我們定義關鍵路徑的切入點。我從口袋銀行、餘額查詢的場景，讓運維和開發者告訴我們使用者要完成餘額查詢場景所經過的各個系統和各個基礎架構的點，要全部定義出來。這是我們判斷的一條關鍵路徑。
有了這條關鍵路徑能做什麼呢？你的監控要以關鍵路徑作為切入點。以前監控是扁平化、比較簡單的層次，但其實監控需要做到的是場景化的監控。以前大家講的比較虛，要做場景化的監控。關鍵是切入點是什麼、場景是什麼，每一個公司都有自己最關鍵的場景，銀行最關鍵的場景是使用者每天能看到卡裡的錢，每天能轉帳，跑到網點可以取錢就是關鍵的路徑。定義好了關鍵路徑以後要把系統的清單和調用的關系弄的清清楚楚，明明白白。
如果你連關鍵路徑都做不準，你怎麼能解決生産上幾千個應用？先不說大的，最差最差的不能那麼快發現，但是業務最重要的場景必須要立馬知道，而且要非常快。首先你要真的列出來，弄的明明白白，不停地演練關鍵路徑本身，如果出現某些問題的時候應該怎麼處理。
你的“武器”是圍繞着這個打造的，而不是為了每一個監控、每一個報警訓練團隊是沒有意義的，因為每一個監控是獨立的，并不會給你帶來實際真正有意義的技能提升。
團隊的技能是圍繞着場景打造的，團隊要非常清晰地知道根據關鍵的業務名額定義出來的關鍵路徑的系統關系。最終可能會轉化成服務的API和IP位址，之後再進行場景化的監控進行實時探測。這樣基本上可以在分鐘級發現問題。
今天所有的東西都要做智能化，智能化能幫到我們什麼呢？因為規模大了以後告警和預值、閥值的設計會給你帶來很大的工作量，是以需要更多智能化的工作。
第一個智能化展現在你的監控怎麼跟其他系統關聯，我到了銀行發現銀行有很多系統、很多流程，但是驅動系統和流程的還是人，不是說不好，當規模小的時候可以做的非常好，但到了一定量的時候根本做不過來。流程本身是沒有問題，每天面對的海量告警的時候就做不了了。
為什麼我們要跟變更系統關聯？因為銀行每天有很多變更很多釋出，如果你不跟報警系統關聯做變更的時候會産生很多大量的告警，通常告警出來了配置設定的時候接到單子會問一下誰在做變更，就可以直接知道因為有誰做變更是以導緻的告警，是以告警不需要做處理。有時候做網絡的變更會給你帶來成百上千個告警，靠人工的話效率非常低。是以需要更智能的告警系統知道你的生産在做變更，看似簡單但需要做很多工作。
以前的變更流程大多是圍繞着ITSM的系統，這套系統沒有辦法主動地告訴你誰在做變更了，你怎麼來建立這種閉環？你怎麼知道誰在什麼時間點做變更，不僅是人要知道，系統也要知道，特别是告警系統更要知道誰在什麼時間做變更，這樣才能把很多的告警真正地和場景進行關聯，達到聚合的目的，這是更智能化的聚合。
有的時候釋出也會帶來大量的告警，持續互動的流水線如果一直在跑的話每天會給你帶來大量的意想不到的變更。過去人工的方法是知道機器要做釋出了自動設定系統變成Offline。我需要系統告訴我出問題了，但一旦設的話你需要知道有法把的系統告訴體在這台系統上釋出了，我國才自動屏蔽，這是最好的辦法。
為了避免大量産生告警，通常的做法是把監控系統給關了。但監控系統關了最大的問題是有時候關不掉，因為是基礎架構的東西沒有辦法根據這個變更單獨關掉某一個，有可能你做的是這方面的，但其他方面有問題還是需要告警出來。更多應該站在智能告警角度，所有的告警都應該告出來，隻是應該知道告警的源頭是什麼，通過智能化的場景關聯屏蔽掉、靜默化。
收斂是幫我們做根因分析很重要的工具，當你應用多的時候一定要知道告警是不是來自于跟同一個應用有關聯的，是以你必須要做到基于應用的收斂。基礎架構一定要知道是不是來自于同一台主機、同一個網絡交換機、同一台機櫃。這些資訊都非常重要。
一個網絡交換機出現故障的時候你可能會收到成百上千個告警，就會被淹沒。如果沒有資料收斂告訴你所有的裝置都是接在了這台交換機上，你馬上歸知道裝置的根因就在這裡。今天我談的是理念方面的東西，因為很多東西并不是靠一個工具就等解決所有的問題，你得設定工具本身，有的可以用開源做改造來達到效果，有的要靠自己來研發。
今天在處理大規模生産故障的時候在溝通方面做的好的團隊并不太多，特别是在大規模故障面前如何有效地進行溝通和協作來處理故障是非常難的課題。因為它會涉及到非常多的團隊、人、内容，是以如何促進有效溝通是生産運維非常重要的一件事情。
現在我們也沒有完全做的非常完美，已經好的工具是電話自動呼叫，舉個例子每天收到幾百個告警，這些告警如果靠人工配置設定會很慢，但如果有自動語音呼叫會好很多。當我收到告警的時候知道告警是某一個應用，這個應用是某一個開發、某一個運維的時候應該通過TTS呼叫自動把告警資訊通過打電話的方式通知他，這是最有效的一種方式。
為什麼呢？用來對付開發是最有效的、最常見的是哪一類告警？就是代碼寫的不好，上線以後帶來性能的各種下降，此類告警運維接到的時候很無奈，也是打電話找開發說讓他們看一下是不是有釋出或者做過什麼變化。開發說去看一下，然後半天也沒有什麼反應。語音呼叫的好處是不需要你去告訴他，隻要是這個相關的可能找他，機關就呼到他那裡，如果不接會一直撥，撥幾次以後一直不接會撥到老闆那裡。
處理的時候必須要進入系統調成已處理的狀态，運維團隊可以大大減輕人工。以前大量的工作是通過人工的工作，我們銀行現在幾百個運維對3000多個開發根本對不過來的，如果每個人要看開發溝通讓他告訴你解決沒解決，效率非常非常低。
短信通知也是告警的一種方式，但是短信通知的場景是當你發生比較大的故障的時候通過短信廣播的方式會不及時。當出現任何故障和對業務産生影響的時候會啟動電話會議系統，電話會議系統會把開發、運維全部拉進來，也可以主動撥入。
當幾十個人的電話會議開起來的時候如果團隊沒有做好很好的電話會議教育訓練的話會是亂哄哄的局面，如果大家有用過應該會有感受，當幾十個人撥進去的時候每個人都想說話都想表達，甚至有人在比較嘈雜的環境裡會帶來很大的噪音。
進來的時候要說你是誰，你做了什麼事情。标準化地第一時間說出有效的資訊。當你不講話的時候一定要靜音，平常開電話會議也是這樣，免得環境的噪音帶來很大的影響。 每周都在做團隊演練，剛才做了很多系統梳理了很多東西，如果不演練的話很難在真正故障的時候會不知道做什麼。
針對每一類場景銀行會梳理上百個方案，但其實在這方面對關鍵性梳理才是核心中的核心。知識庫是服務台最常見會用到的，還有如果有應急的管理系統告訴你在故障發生幾分鐘以後應該通知誰也會幫助你提高應急的響應時間。
當你發現故障的時候如果還是要靠手工做很多恢複故障的，最常見的是需要重新開機幾十台、上百台伺服器，一台資料器伺服器宕了切換到另外一個狀态，最常見的恢複是應用伺服器自己知道是什麼，但通常情況下上去改一個IP，然後應用需要重新開機，如果沒有自動化工具幫助你，哪怕你已經知道怎麼恢複還是要花很長的時間，這是我在銀行看到的比較常見的點。
我已經知道怎麼恢複了，但是我的能力不夠，如果有自動化的工具重新開機100台可能隻需要5分鐘就搞定了。銀行有特殊的一點不能在辦公環境裡做這件事，要跑到操作間才能做，因為隻有操作間是可以連生産系統，其他辦公的電腦一概不行。這時候效率是非常低下的，是以做好自動化運維很重要。
自動化運維涵蓋很多，今天大多數銀行都在學習網際網路，要把日常運維包含在工具裡，包括恢複故障時用到的指令、操作。這樣才能在故障發生的時候有信心用，如果隻是在故障恢複的時候用通常已經不起作用了，因為很多東西在飛速變化中，你配置的東西也在變化的很快。
關于災備銀行是最自豪的，工行、建行基本的配置是“兩地三中心”，同城有一個機房，異地還會有機房。但是要真正做好又是一件很難的事情，很多時候我們經常生産出故障大家還是花時間在恢複故障本身，真正切換到其他資料中心的場景非常非常少。為什麼？因為很難，系統多、配置多，各種關系複雜你很難判斷，切了還可能會導緻最大的問題。
過去我們實踐過很多，如果你的應用是網際網路的話可以比較清晰地分出層次，這樣在你的兩個資料中心裡應該讓應用處于雙活的狀态，這樣就不存在切換的問題，所謂的切換其實是通過内部探測服務本身自動實作切換的，很多的網際網路公司都做了這方面的探索，因為一個平常沒有流量的服務是不敢輕易地接過去的，這個時候你必須把應用和服務、資料庫根據應用緯度實作真正意義深的“雙活”，這樣才能真正地實作資料中心級别的應用切換。
剛開始先同城再異地，對銀行的應用來講，銀行是強一次性應用比較多，是以異地很難實作，但是同城是比較好的選擇。讓你的同城兩個應用都處于有流量的狀态，這是你實作災備切換最基本的要求，如果沒有這個要求你其實是不敢有任何切換的。
遠端運維對普通大多數沒有什麼問題，但是銀行是不允許遠端登陸操作生産系統的，我交流了很多銀行，有些銀行沒辦法但也限制的非常嚴格，VPN很多銀行是不允許的，因為風險是很大的。
你要做的還是要依賴于工具本身，遠端VPN進去如果可以操作任何秘密的話是巨大的風險，但如果有運維平台一都包含在裡面，那風險就相對來說是比較可控的。我們都是通過雲桌面來處理，但很多生産系統隻能看但操作不了。
講完了武器後面講一下恢複的4個大戰術。
包含了代碼的復原和應用技術的復原。最常見的是代碼本身，如果有很好的釋出系統能夠實作代碼快速復原。對于技術架構本身來講，復原就是重新開機服務，恢複到原先的狀态。
服務狀态現在不正常或者有一台伺服器記憶體異常了，應用伺服器重新開機其實就是復原，這是最常見的戰術之一，也是在做運維變更和開發時首先要想到的，任何一個變更肯定會問能復原嗎？能回退嗎？道理是一樣的，狀态要回到你做變更之前，代碼也是同樣的道理。
交換機經常會莫名其妙有些端口出現UP和Down的狀态，這個時候你不可能重新開機交換機，因為它隻有一個端口，唯一的辦法就是把故障端口進行快速格力。技術架構是備援化的，你需要把有問題的隔離出去，例如一台伺服器有問題趕緊把它的拉出來，某一個端口有問題趕緊處理掉，這個端口屬于故障隔離本身。
如果你開發代碼裡有功能的開關，當它釋出完以後打開開關發現功能沒有像它想的那樣工作的時候，這個時候開關快速關閉也是屬于故障格力，不需要做任何的操作就能避免故障進一步擴大、惡化。
站在業務的次元講更合适，拿銀行口袋APP本身，當出現問題時要保障的是什麼？大家想看到的按鈕叫餘額查詢、轉帳，這個時候理财産品收益率看不到沒關系，是以恢複的政策是服務降級，把業務本身非關鍵去掉，不用再給使用者看那些沒關系的，你要保證核心的業務和路徑是什麼。
當你要選擇A或者B到底要斷哪一個的時候隻能選擇之前梳理的邏輯，就是你梳理的關鍵業務和關鍵路徑本身，其他的通過服務降級去掉。這是暫時恢複核心業務，而不是完全治愈的，亂七八糟的各種高階的都可以關掉。
剛才講的是整個災備，但還有很多好的辦法，如果你可以基于應用緯度或者建立起來的一條路徑在某一個節點上都可以實作災備切換的話，那你可以實作同城A應用在兩個資料中心部署，如果在資料中心A釋出了後出現問題可以立馬把它切換到B，這是恢複應用本身最快的辦法。
這種方式叫“藍綠”釋出，也是以前最常見的。你在A資料中心釋出它有問題最快的方法是切換到B資料中心的同一應用，條件是基本需要同城，特别是對異地時間長、距離長的比較難做到的。
當你的資料庫資料中心A出現問題的時候你需要切換到B，你需要不停地訓練團隊。這些東西設計出來不是看，如果大家隻是理念上的要有這些東西是沒用的，這都要通過日常演練過程中不斷地強化團隊在切換這方面的能力、恢複故障能力的提升，你需要建構一個團隊，不停地對它進行演習、戰術的教育訓練。
稍微講一下展望，做運維人哪一天有系統可以直接根因甚至推薦恢複的路徑和辦法，那是最理想的，當然還有很多工作，我們能做的是站在實際的角度需要恢複的關鍵是什麼，你可以在這方面做嘗試。
容量和最好控制量的預測是最好的，像以前普通的硬碟可以告訴你多少時間會壞，如果我們能夠做到容量在這方面更靠前的預測，而不是靠真正發生故障以後的恢複是更理想的，對于運維來講更友好更理想化的狀态。