先聲明下，老司機不是自己封的，是老東家新浪的同事給封的，哈哈
萬事皆有道，運維亦然，尋到規律，事辦功倍，今天跟大家分享下應用運維如何高效的接手一個新業務。
很多同學接到新業務時是茫然的，不知道從哪下手，被動等待交接者交接的東西，交接完畢後依然迷糊，究其本質沒有框架和思維結構的接手是茫然的，很多時候就像黑瞎子掰玉米，最後腦袋裏剩的就是最後那個“玉米”和一些碎片化信息，其實完全可以主動點，把握結構和思路，一般而言，拿到一個新業務，要達到能拎起來的地步是要下功夫的，但並不是下了功夫就能拎起來，當中牽涉到一個道，一般而言，要從下面幾個事情做起。
一、知其用
不要以爲這個問題太基礎，很多同學做運維，都不知道自己的產品從用戶角度看是做什麼用的。
知其用就是知道自己的業務叫什麼？做什麼用的？解決了什麼問題？產品的用戶是誰？在整個公司的產品生態裏是什麼位置？只有知道了這些，才知道自己產品的分量，知道什麼用戶報障是跟自己的產品有關係，知道自己的產品有故障時會造成什麼影響。
二、摸家底——1圖、1表、1賬本
知其用後就要摸家底了，此事兒極其重要，摸家底切忌不可眉毛鬍子一把抓，摸之前最重要的是要有模塊化思維，任何一個僱專職運維的產品都不會是個很簡單的產品，而一個有規模的產品定是經過微服務化設計的多模塊產品，這時候一定要先把產品的模塊理清楚，找出獨立的模塊單元，參考“一、知其用”的方法進行簡單瞭解，然後弄清楚模塊間的骨幹邏輯，並畫出模塊間調用的骨幹邏輯圖，這裏切忌不要追求細，要懂得“舍”，剛開始就求細的結局就是勞人煩己，容易被細節帶到溝裏，即使有現成畫好的，也要自己畫一個“骨幹模塊邏輯鳥瞰”，細緻的邏輯等工作過程中慢慢學吧，跟着開發一起迭代升級進步。
這裏有個思維潔癖的問題，一定不要想着把每個點都能一步到位弄清楚，二八原則，抓大放小，先把那80%的重點弄明白即可，後續留着慢慢掰扯，我們有這個追求完美的心是不錯的，但現實中由於人員流動、老代碼、老模塊等原因，確實沒有同學能給你說的十全十美，不能因爲追求完美這個事兒耗費過大精力，導致其它事情停滯不動。
好了到此爲止，我們有了一張圖——“骨幹模塊邏輯鳥瞰”圖，下一步就是要給這張圖添枝加葉了，真正的摸家底可以開始了，這個過程會形成一張表，這張表就是產品分模塊的資源鳥瞰，從我目前經驗看，主要有這麼3個維度的資源：服務器、域名、lb，理的過程中把對應模塊的容量、開發人員做相應瞭解，到此你就有一個產品的工具箱了，例如下面一個簡單的服務器鳥瞰表：
摸家底的過程中會遇到各種歷史包袱，比如前輩留下的坑、老業務、老代碼，這個時候不要怕，也不要發牢騷，哪個公司和產品都會有這個問題，我們就是來解決這些問題的，這裏要遵循一個白名單原則，先把確定的健康的資源標註理出來，正向循環，把剩下的七零八碎的放在一起慢慢收拾，因爲這種收拾往往是擦屁股的活兒，非一己之力就能完成，但要把這些七零八碎的一一當做賬單記下來，形成一個“賬本”，這個賬本的內容視緊急程度和產品團隊工作量飽和情況進行消化，一定記住這些事情是做一件少一件的事情，不可貪全，目前互聯網公司產品迭代的壓力都很大，而且還有個填老坑老闆覺得算不上什麼大貢獻的惡習，開發同學做新業務的動力和優先級一定比填老坑的大，要相互理解。
好了到此爲止我們有了一份家底資料，內容包括1圖、1表、1賬本，產品所有資源鳥瞰都在這裏，做起什麼和聊什麼相對能插上話了，通過摸家底，也知道了很多業務上的事情，可謂收貨頗多。
三、看調用
看調用在摸家底理模塊的時候有所接觸，不過角度和出發點不一樣，摸家底時是爲了記憶，而看調用是爲了深入理解產品、分析產品問題，當然最後的調用圖可以是“骨幹模塊邏輯鳥瞰”圖修飾更改而成，形成一張統一的“業務架構圖”，其中“子模塊的詳細架構圖”也可以畫，視情況而定，另外在一張圖裏不要事無鉅細的加內容，要有主題懂得取捨，因爲太簡單了沒營養，太複雜了畫完後自己都不想看，圖的維護也是要有成本的。
看調用要從用戶的角度出發，看請求的流轉，有兩個層次1是業務模塊邏輯間流轉，2是基礎系統層面流轉，簡單解釋就是服務器、vip、域名等這些資源有了，看調用是把這些資源串起來形成關係，如果不理調用，就像電影大飯局裏的大師言“五行有了，但五行缺串”。
在理調用過程中的同時，要幹3件事情，1是弄清每個模塊提供服務的方式，通過域名還是deamon等並做好記錄，2是要弄清每個點的調用方法，比如說是輪訓、還是哈希......3是要記錄每個模塊依賴的外部產品資源，比如說redis、db等。這些在未來遇到問題分析問題時肯定會派上用場，而且很重要，一個服務一般而言要建議開發做成面向服務的、無狀態的、無單點的，從運維的角度來說這個系統才能健壯運行，否則後期麻煩事兒會很多。
四、抓告警
在圍繞運維數據的工作中，告警是最重要的事情，告警意味着問題和故障，告警本身是對監控的一個收斂，監控可以慢慢理，但告警一定要在這個時候弄清楚，告警裏也是分級的，先把業務的生死告警理清楚，跟交接的同學問清每個模塊都有哪些不得不處理的告警，影響面有多大，當然如果上任做的好，會有梳理好的dashboard監控圖，收到告警後可以通過dashboard看到故障點在哪裏。
梳理出每個模塊對應的生死告警項後，做好記錄，並留心日常的業務告警，形成1張表，其實以後上手了，這個表是打開頻次最少的。
五、管變更
問題和故障都不是無緣無故突然冒出來的，很多是因爲某一個變化造成的，牽涉到產品本身最大的兩個變更就是代碼變更和配置變更，這兩個事情一定要管理起來，如果暫時做不到管理起來起碼要監控起來，每次變更都要做變更通知，最簡單的方式建個QQ羣，這樣在發生告警的瞬間就可以迅速的知道是不是因爲某個變更造成的，幹到現在，覺得想從測試和灰度這兩點把變更類故障徹底解決掉是個天真的想法，人性使然，工程師總有各種理由不去測試和灰度，而有些模塊的業務結構也確實無法支持灰度，僅測試環境測試不放在生產環境灰度很多問題是看不見的，更進一步說有些問題即使灰度了也不見得馬上就會出現。
說明一點，關於解決問題可以從技術和制度兩個手段出發，對於人這個羣體，制度相比技術其實是不靠譜的，就像上面提到的測試和灰度，人性使然，總有各種理由不遵守制度，所以能用技術解決的問題一定用技術解決，技術一時半會解決不了的再用制度約束，制度的建立很多時候是爲技術爭取時間，作爲運維要靈活使用這兩個手段，有的時候既要有技術也要有制度，例如我現在做的一個變更監控（中間多謝李博同學的支持）如下：
六、做導航
這裏說的主要是監控導航，導航的本質是一個思維導圖，可以快速的找到你要的東西，在新浪做時效果很好，所以也拿到了新東家。申請一個簡單好記的域名，把你所有相關的事情都畫到上面，推薦一個工具grafana，既漂亮又實用，監控UI的不二之選，支持的數據源也特別豐富，例如目前的一個導航如下，可以看出需要做的事情還是很多的，同時也可以把公司的系統都畫上去，系統太多如果不集中一下太痛苦了，好了就分享到這兒了，希望對現在的你有所幫助。
查看更多請到博主原創站：運維網咖社（www.net-add.com）