知識星球
來源：運維軍團
ID：ywjtshare
1. 前言
如何接手一個新業務的運維工作？有些東西我們還是要把話說在前面，以免前期不明確造成後期工作的混亂。
2. 醜話說在前
先跟研發leader溝通，灌輸運維理念，醜話說在前頭，我們不做保姆式運維，我們會致力於線上服務安全、穩定、低成本、快速迭代，從運維視角提高產品力。開發機、測試環境，研發自己搞，我們可以協助幫忙，做專業的諮詢服務，想讓我們直接操刀開發環境的變更，免談！
3. 業務概要瞭解
瞭解業務相關的人，對應的研發同學、研發leader、測試同學、測試leader、產品經理分別是誰，聯絡方式存下來，拉個群，出了問題可以找到對應的人。
瞭解服務是乾啥的，解決了什麼問題，業界有對標的開源產品嗎，方便我們快速認識這個產品。
瞭解服務的上下游，依賴哪些服務，哪些服務依賴我，對應的介面人是誰，這裡先簡單瞭解一下即可。
瞭解服務部署情況，部署在哪些機房，用什麼語言編寫的，基礎網路、專線頻寬、機房出口是否靠譜，是否曾因基礎設施導致過問題，當前主要痛點是什麼。
4.業務串講
要求研發同學（或者上一任運維同學）準備PPT，做一個業務串講，講解一些研發同學希望傳達給運維同學的資訊，講解一些運維同學希望從研發這得到的資訊。比如：詳細部署拓撲、服務整體架構、資料流、提測變更流程、監控方式、部署到了哪些機器、機器登入方式、每個機器上是什麼模組、OS引數是否有調優，考量是什麼、用到了哪些第三方軟體，考量是什麼，比如為啥用了tomcat而不是resin、相關wiki、故障處理預案、常見故障、當前線上問題……等等
如果業務有單點，不接，讓研發改造。如果運維的老闆的老闆強制要求，醜話說前頭：因單點導致的問題，運維不背鍋。
5.資產梳理
正式準備接手，第一步，梳理資產。比如用到了哪些域名，這些域名對應哪些業務、哪些虛IP，分別是提供了什麼服務、哪些機器，分別部署了什麼模組、業務在哪些機房、用了多少頻寬、總頻寬情況、是否有其他業務共用爭搶。
機器需要拿到更詳盡的資訊，比如機器配置、機架位、IP、管理卡IP等等，公司應該有個CMDB供查詢。如果沒有，運維同學，需要你去構建這個CMDB。
後面要考慮機器是否需要有備機、備件，機型是否可以統一。
6.基礎監控
知道有哪些資產了，就可以對這些資產做監控了，比如域名連通性監控/延遲監控、虛IP的連通性監控/延遲監控、機器宕機監控、機器硬體監控、sshd/crond等系統行程監控、系統執行的行程總數監控、系統引數配置監控，可以參看我之前的文章《完備的監控應改寫什麼》。
7.服務梳理
吃透之前串講時給的架構圖、資料流圖、部署拓撲圖。從運維層面，最好還要知道公司網路拓撲圖。
瞭解每個模組的情況，部署在哪些機器上，部署在哪個目錄，用什麼賬號啟動的，日誌打到哪裡了，用什麼語言編寫的，怎麼上線的，主要吃CPU資源還是記憶體還是磁碟還是IO，需要預留多少資源，平時利用率是多少，應該配置多大的閾值做監控，是否需要watchdog自動拉起，日誌裡出現哪些關鍵字需要報警，以及其他各種需要註意的問題。
8.業務監控
基本的行程、埠存活性監控，機器利用率監控、日誌關鍵字監控、日誌不滾動監控、關聯的服務的監控等等，後面會做API粒度的監控，來推動業務最佳化。
9.標準化改造
機器命名方式、作業系統發行版、OS版本、第三方軟體，比如jdk、tomcat、nginx，都要統一，做標準化方案。
服務擴容、變更、下線做一鍵化，每次升級只需要給個版本號即可，此時研發操作還是運維操作效果一樣，故而可以交給研發上線，釋放運維人力，許可權要控制好。
重覆的常規操作也要固化成指令碼，一鍵完成。
梳理故障自愈場景，看平時有哪些故障的處理方式是固定的，抽象為指令碼，報警之後自動觸發，無人值守處理。
公司如果有一些基礎設施，比如名字服務、MQ、日誌平臺，推動研發改造，將新服務接入。如果公司還沒有這些基礎設施，作為運維這個角色，可以著手搞起。
10.SOP梳理
故障預案是一個非常重要的事情，線上沒出故障之前，就應該提前去想，服務可能會出什麼故障，如果真出了，應該如何處理，把處理步驟提前記錄下來。畢竟，線上出故障的時候，人都比較緊張，直接看著預案處理，就踏實不少，不容易出錯。
11.故障演練
光有預案沒有演練，是不靠譜的，沒有經過驗證的預案是不可信任的。所以，搞個放火演習，把模組搞掛試一把，把機器搞掛試一把，對線上穩定性絕對會有提升。
特別是研發說這個模組掛掉，可用性肯定沒影響，OK，搞掛試試先。很可能會打他臉，-_-||
有些場景演練是會有損的。這種場景還要不要演練？這個需要case by case的看，大部分情況都是要做演練會更好，畢竟，人在這盯著的時候出問題，比晚上睡著了出了問題要強太多。當然， 大規模基礎網路故障這種演練，還是算了吧，通常的業務都是不具備機房級容災的，呵呵
上面做完了，基本工作就完成了。上面很多事情都是一次性的，那未來的大把時間運維做啥？
除了再花費部分時間做線上問題處理，我們應該把主要精力來提升業務產品力。做精細化運維，還記得運維九字真言麼？“安全穩定高效低成本”，這就是我們的工作方向。下麵舉幾個例子。
1.再談業務監控
上面談到過一次業務監控，主要是一些通用的監控指標。我們對產品瞭解足夠之後，應該做一些業務特有的監控，推動研發去做也可以，達到效果就好。
比如你運維了一個MQ，訊息堆積量是需要監控滴；比如你運維了一個RPC服務，提供了三個介面，這三個介面的響應時長、成功率是需要監控滴；比如你運維了一個S3服務，每個桶的短期頻寬增量你是需要監控滴；有那麼點感覺了麼？ 🙂
2.API成功率、延遲統計
在流量入口的nginx做所有業務線的所有API的成功率和延遲統計，是非常有必要的。把成功率比較低的TopN找出來，把延遲比較大的TopN找出來，讓業務去最佳化。老闆會喜歡這個的。
3.線上問題梳理
整理線上所有問題，挨個解決，運維可以搞定的運維搞定，運維搞不定的找研發要排期，每週解決了多少問題，還有多少問題待解決，用周報的方式體現出來。
4.成本最佳化
透過服務混部、或者統一的資源排程平臺來節省機器資源，一臺機器便宜的也好幾萬呢，這個事是比較容易有產出的。
5.容量規劃
容量規劃和成本最佳化實際是緊密相關的，容量規劃的重點是根據自然增量和運營需求，提前規劃準備相應的容量，容量可能包括頻寬、專線、網路裝置、機器等等；當業務量下來的時候，可以騰挪相關資源支援其他業務線，讓這些硬體儘量滿負荷運轉，物有所值。
6.關於溝通
最後說一點，接手一個新業務運維，勢必與研發有各種溝通，每次溝通都要寫會議紀要，發郵件出來，跟進人是誰，時間點是啥時候都要寫明白，郵件傳送雙方團隊郵件組，cc各方老大。事後關鍵節點做check，如未完成，線下溝通，達成一致後追此郵件給結論，說明延期原因以及新的時間點。如果溝通不暢，讓老大去協調。
作者：秦曉輝
連結：https://www.jianshu.com/p/65a01b5d61c7
來源：簡書
《Linux雲端計算及運維架構師高薪實戰班》2018年07月16日即將開課中，120天衝擊Linux運維年薪30萬，改變速約~~~~
*宣告：推送內容及圖片來源於網路，部分內容會有所改動，版權歸原作者所有，如來源資訊有誤或侵犯權益，請聯絡我們刪除或授權事宜。
– END –
更多Linux好文請點選【閱讀原文】哦
↓↓↓
