老司機告訴你應用運維如何系統高效的接手一個新業務？

先聲明下，老司機不是本身封的，是老東家新浪的同事給封的，哈哈

萬事皆有道，運維亦然，尋到規律，事辦功倍，今天跟你們分享下應用運維如何高效的接手一個新業務。

不少同窗接到新業務時是茫然的，不知道從哪下手，被動等待交接者交接的東西，交接完畢後依然迷糊，究其本質沒有框架和思惟結構的接手是茫然的，不少時候就像黑瞎子掰玉米，最後腦殼裏剩的就是最後那個「玉米」和一些碎片化信息，其實徹底能夠主動點，把握結構和思路，通常而言，拿到一個新業務，要達到能拎起來的地步是要下功夫的，但並非下了功夫就能拎起來，當中牽涉到一個道，通常而言，要從下面幾個事情作起。

1、知其用

不要覺得這個問題太基礎，不少同窗作運維，都不知道本身的產品從用戶角度看是作什麼用的。

知其用就是知道本身的業務叫什麼？作什麼用的？解決了什麼問題？產品的用戶是誰？在整個公司的產品生態裏是什麼位置？只有知道了這些，才知道本身產品的份量，知道什麼用戶報障是跟本身的產品有關係，知道本身的產品有故障時會形成什麼影響。

2、摸家底——1圖、1表、1帳本

知其用後就要摸家底了，此事兒極其重要，摸家底切忌不可眉毛鬍子一把抓，摸以前最重要的是要有模塊化思惟，任何一個僱專職運維的產品都不會是個很簡單的產品，而一個有規模的產品定是通過微服務化設計的多模塊產品，這時候必定要先把產品的模塊理清楚，找出獨立的模塊單元，參考「1、知其用」的方法進行簡單瞭解，而後弄清楚模塊間的骨幹邏輯，並畫出模塊間調用的骨幹邏輯圖，這裏切忌不要追求細，要懂得「舍」，剛開始就求細的結局就是勞人煩己，容易被細節帶到溝裏，即便有現成畫好的，也要本身畫一個「骨幹模塊邏輯鳥瞰」，細緻的邏輯等工做過程當中慢慢學吧，跟着開發一塊兒迭代升級進步。

這裏有個思惟潔癖的問題，必定不要想着把每一個點都能一步到位弄清楚，二八原則，抓大放小，先把那80%的重點弄明白便可，後續留着慢慢掰扯，咱們有這個追求完美的心是不錯的，但現實中因爲人員流動、老代碼、老模塊等緣由，確實沒有同窗能給你說的十全十美，不能由於追求完美這個事兒耗費過大精力，致使其它事情停滯不動。

好了到此爲止，咱們有了一張圖——「骨幹模塊邏輯鳥瞰」圖，下一步就是要給這張圖添枝加葉了，真正的摸家底能夠開始了，這個過程會造成一張表，這張表就是產品分模塊的資源鳥瞰，從我目前經驗看，主要有這麼3個維度的資源：服務器、域名、lb，理的過程當中把對應模塊的容量、開發人員作相應瞭解，到此你就有一個產品的工具箱了，例以下面一個簡單的服務器鳥瞰表：

摸家底的過程當中會遇到各類歷史包袱，好比前輩留下的坑、老業務、老代碼，這個時候不要怕，也不要發牢騷，哪一個公司和產品都會有這個問題，咱們就是來解決這些問題的，這裏要遵循一個白名單原則，先把肯定的健康的資源標註理出來，正向循環，把剩下的七零八碎的放在一塊兒慢慢收拾，由於這種收拾每每是擦屁股的活兒，非一己之力就能完成，但要把這些七零八碎的一一當作帳單記下來，造成一個「帳本」，這個帳本的內容視緊急程度和產品團隊工做量飽和狀況進行消化，必定記住這些事情是作一件少一件的事情，不可貪全，目前互聯網公司產品迭代的壓力都很大，並且還有個填老坑老闆以爲算不上什麼大貢獻的惡習，開發同窗作新業務的動力和優先級必定比填老坑的大，要相互理解。

好了到此爲止咱們有了一份家底資料，內容包括1圖、1表、1帳本，產品全部資源鳥瞰都在這裏，作起什麼和聊什麼相對能插上話了，經過摸家底，也知道了不少業務上的事情，可謂收貨頗多。

3、看調用

看調用在摸家底理模塊的時候有所接觸，不過角度和出發點不同，摸家底時是爲了記憶，而看調用是爲了深刻理解產品、分析產品問題，固然最後的調用圖能夠是「骨幹模塊邏輯鳥瞰」圖修飾更改而成，造成一張統一的「業務架構圖」，其中「子模塊的詳細架構圖」也能夠畫，視狀況而定，另外在一張圖裏不要事無鉅細的加內容，要有主題懂得取捨，由於太簡單了沒養分，太複雜了畫完後本身都不想看，圖的維護也是要有成本的。

看調用要從用戶的角度出發，看請求的流轉，有兩個層次1是業務模塊邏輯間流轉，2是基礎系統層面流轉，簡單解釋就是服務器、vip、域名等這些資源有了，看調用是把這些資源串起來造成關係，若是不理調用，就像電影大飯局裏的大師言「五行有了，但五行缺串」。

在理調用過程當中的同時，要幹3件事情，1是弄清每一個模塊提供服務的方式，經過域名仍是deamon等並作好記錄，2是要弄清每一個點的調用方法，好比說是輪訓、仍是哈希......3是要記錄每一個模塊依賴的外部產品資源，好比說redis、db等。這些在將來遇到問題分析問題時確定會派上用場，並且很重要，一個服務通常而言要建議開發作成面向服務的、無狀態的、無單點的，從運維的角度來講這個系統才能健壯運行，不然後期麻煩事兒會不少。

4、抓告警

在圍繞運維數據的工做中，告警是最重要的事情，告警意味着問題和故障，告警自己是對監控的一個收斂，監控能夠慢慢理，但告警必定要在這個時候弄清楚，告警裏也是分級的，先把業務的生死告警理清楚，跟交接的同窗問清每一個模塊都有哪些不得不處理的告警，影響面有多大，固然若是上任作的好，會有梳理好的dashboard監控圖，收到告警後能夠經過dashboard看到故障點在哪裏。

梳理出每一個模塊對應的生死告警項後，作好記錄，並留心平常的業務告警，造成1張表，其實之後上手了，這個表是打開頻次最少的。

5、管變動

問題和故障都不是平白無故忽然冒出來的，不少是由於某一個變化形成的，牽涉到產品自己最大的兩個變動就是代碼變動和配置變動，這兩個事情必定要管理起來，若是暫時作不到管理起來起碼要監控起來，每次變動都要作變動通知，最簡單的方式建個QQ羣，這樣在發生告警的瞬間就能夠迅速的知道是否是由於某個變動形成的，幹到如今，以爲想從測試和灰度這兩點把變動類故障完全解決掉是個天真的想法，人性使然，工程師總有各類理由不去測試和灰度，而有些模塊的業務結構也確實沒法支持灰度，僅測試環境測試不放在生產環境灰度不少問題是看不見的，更進一步說有些問題即便灰度了也不見得立刻就會出現。

說明一點，關於解決問題能夠從技術和制度兩個手段出發，對於人這個羣體，制度相比技術實際上是不靠譜的，就像上面提到的測試和灰度，人性使然，總有各類理由不遵照制度，因此能用技術解決的問題必定用技術解決，技術一時半會解決不了的再用制度約束，制度的創建不少時候是爲技術爭取時間，做爲運維要靈活使用這兩個手段，有的時候既要有技術也要有制度，例如我如今作的一個變動監控（中間多謝李博同窗的支持）以下：

6、作導航

這裏說的主要是監控導航，導航的本質是一個思惟導圖，能夠快速的找到你要的東西，在新浪作時效果很好，因此也拿到了新東家。申請一個簡單好記的域名，把你全部相關的事情都畫到上面，推薦一個工具grafana，既漂亮又實用，監控UI的不二之選，支持的數據源也特別豐富，例如目前的一個導航以下，能夠看出須要作的事情仍是不少的，同時也能夠把公司的系統都畫上去，系統太多若是不集中一下太痛苦了，好了就分享到這兒了，但願對如今的你有所幫助。

查看更多請到博主原創站：運維網咖社（www.net-add.com）