如何接手一個(gè)新業(yè)務(wù)的運(yùn)維工作?有些東西我們還是要把話說在前面，以免前期不明確造成后期工作的混亂。

[[235090]]

1、前期溝通

首先，我們要先跟研發(fā)Leader溝通，灌輸運(yùn)維理念，把丑話說在前頭，我們不做保姆式運(yùn)維，我們要致力于線上服務(wù)安全、穩(wěn)定、低成本、快速迭代，從運(yùn)維視角提高產(chǎn)品力。

開發(fā)機(jī)、測試環(huán)境，研發(fā)自己搞，我們可以協(xié)助幫忙，做專業(yè)的咨詢服務(wù)，但不可能讓我們直接操刀開發(fā)環(huán)境的變更。

2、業(yè)務(wù)概要了解

了解業(yè)務(wù)相關(guān)的人：對(duì)應(yīng)的研發(fā)同學(xué)、研發(fā)Leader、測試同學(xué)、測試Leader、產(chǎn)品經(jīng)理分別是誰，聯(lián)系方式存下來，拉個(gè)群，出了問題可以找到對(duì)應(yīng)的人。

了解服務(wù)是干什么的：解決了什么問題，業(yè)界有對(duì)標(biāo)的開源產(chǎn)品嗎……方便我們快速認(rèn)識(shí)這個(gè)產(chǎn)品。

了解服務(wù)的上下游：依賴哪些服務(wù)、哪些服務(wù)依賴我、對(duì)應(yīng)的接口人是誰……這里先簡單了解一下即可。

了解服務(wù)部署情況：部署在哪些機(jī)房、用什么語言編寫、基礎(chǔ)網(wǎng)絡(luò)、專線帶寬、機(jī)房出口是否靠譜、是否曾因基礎(chǔ)設(shè)施導(dǎo)致過問題，當(dāng)前主要痛點(diǎn)是什么。

3、業(yè)務(wù)串講

要求研發(fā)同學(xué)(或者上一任運(yùn)維同學(xué))準(zhǔn)備PPT，做一個(gè)業(yè)務(wù)串講，講解一些研發(fā)同學(xué)希望傳達(dá)給運(yùn)維同學(xué)的信息，同事也講解一些運(yùn)維同學(xué)希望從研發(fā)這得到的信息。

比如：詳細(xì)部署拓?fù)?、服?wù)整體架構(gòu)、數(shù)據(jù)流、提測變更流程、監(jiān)控方式、部署到了哪些機(jī)器、機(jī)器登錄方式、每個(gè)機(jī)器上是什么模塊、OS參數(shù)是否有調(diào)優(yōu)，考量是什么、用到了哪些第三方軟件，考量是什么，再比如為什么用了Tomcat而不是Resin、相關(guān)Wiki、故障處理預(yù)案、常見故障、當(dāng)前線上問題……

如果業(yè)務(wù)有單點(diǎn)，不接，讓研發(fā)改造。如果運(yùn)維的老板的老板強(qiáng)制要求，丑話說前頭：因單點(diǎn)導(dǎo)致的問題，運(yùn)維不背鍋。

4、資產(chǎn)梳理

正式準(zhǔn)備接手前，第一步，梳理資產(chǎn)。

比如用到了哪些域名，這些域名對(duì)應(yīng)哪些業(yè)務(wù)、哪些虛IP，分別是提供了什么服務(wù)、哪些機(jī)器，分別部署了什么模塊、業(yè)務(wù)在哪些機(jī)房、用了多少帶寬、總帶寬情況、是否有其它業(yè)務(wù)共用爭搶等。

機(jī)器需要拿到更詳盡的信息，比如機(jī)器配置、機(jī)架位、IP、管理卡IP等等，公司應(yīng)該有個(gè)CMDB供查詢。如果沒有，運(yùn)維同學(xué)，需要你去構(gòu)建這個(gè)CMDB。

后面要考慮機(jī)器是否需要有備機(jī)、備件，機(jī)型是否可以統(tǒng)一。

5、基礎(chǔ)監(jiān)控

知道有哪些資產(chǎn)了，就可以對(duì)這些資產(chǎn)做監(jiān)控了，比如域名連通性監(jiān)控/延遲監(jiān)控、虛IP的連通性監(jiān)控/延遲監(jiān)控、機(jī)器宕機(jī)監(jiān)控、機(jī)器硬件監(jiān)控、sshd/crond等系統(tǒng)進(jìn)程監(jiān)控、系統(tǒng)運(yùn)行的進(jìn)程總數(shù)監(jiān)控、系統(tǒng)參數(shù)配置監(jiān)控。

6、服務(wù)梳理

吃透之前串講時(shí)給的架構(gòu)圖、數(shù)據(jù)流圖、部署拓?fù)鋱D。從運(yùn)維層面，最好還要知道公司網(wǎng)絡(luò)拓?fù)鋱D。

了解每個(gè)模塊的情況，部署在哪些機(jī)器上、部署在哪個(gè)目錄，用什么賬號(hào)啟動(dòng)的、日志打到哪里了、用什么語言編寫的、怎么上線的、主要吃CPU資源還是內(nèi)存還是磁盤還是IO、需要預(yù)留多少資源、平時(shí)利用率是多少、應(yīng)該配置多大的閾值做監(jiān)控、是否需要watchdog自動(dòng)拉起、日志里出現(xiàn)哪些關(guān)鍵字需要報(bào)警以及其他各種需要注意的問題。

7、業(yè)務(wù)監(jiān)控

基本的進(jìn)程、端口存活性監(jiān)控，機(jī)器利用率監(jiān)控、日志關(guān)鍵字監(jiān)控、日志不滾動(dòng)監(jiān)控、關(guān)聯(lián)的服務(wù)的監(jiān)控等等，后面會(huì)做API粒度的監(jiān)控，來推動(dòng)業(yè)務(wù)優(yōu)化。

8、標(biāo)準(zhǔn)化改造

機(jī)器命名方式、操作系統(tǒng)發(fā)行版、OS版本、第三方軟件，比如JDK、Tomcat、Nginx，都要統(tǒng)一，要做標(biāo)準(zhǔn)化方案。

服務(wù)擴(kuò)容、變更、下線做一鍵化，每次升級(jí)只需要給個(gè)版本號(hào)即可，此時(shí)研發(fā)操作還是運(yùn)維操作效果一樣，故而可以交給研發(fā)上線，釋放運(yùn)維人力，權(quán)限要控制好。

重復(fù)的常規(guī)操作也要固化成腳本，一鍵完成。

梳理故障自愈場景，看平時(shí)有哪些故障的處理方式是固定的，抽象為腳本，報(bào)警之后自動(dòng)觸發(fā)，無人值守處理。

公司如果有一些基礎(chǔ)設(shè)施，比如名字服務(wù)、MQ、日志平臺(tái)，推動(dòng)研發(fā)改造，將新服務(wù)接入。如果公司還沒有這些基礎(chǔ)設(shè)施，作為運(yùn)維這個(gè)角色，可以著手搞起。

9、SOP梳理

故障預(yù)案是一個(gè)非常重要的事情，線上沒出故障之前，就應(yīng)該提前去想，服務(wù)可能會(huì)出什么故障;如果真出了，應(yīng)該如何處理，要把處理步驟提前記錄下來。畢竟，線上出故障的時(shí)候，人都比較緊張，直接看著預(yù)案處理，就踏實(shí)不少，不容易出錯(cuò)。

10、故障演練

光有預(yù)案沒有演練，是不靠譜的，沒有經(jīng)過驗(yàn)證的預(yù)案是不可信任的。所以，搞個(gè)放火演習(xí)，把模塊搞掛試一把，把機(jī)器搞掛試一把，對(duì)線上穩(wěn)定性絕對(duì)會(huì)有提升。

特別是研發(fā)說這個(gè)模塊掛掉，可用性肯定沒影響，OK，先搞掛試試，結(jié)果很可能會(huì)打他臉。

有些場景演練是會(huì)有損的。那這種場景還要不要演練?

這個(gè)需要case by case地看。大部分情況都是要做演練會(huì)更好，畢竟，人在這盯著的時(shí)候出問題，比晚上睡著了出問題要強(qiáng)太多。當(dāng)然，大規(guī)?；A(chǔ)網(wǎng)絡(luò)故障這種演練，還是算了吧，通常的業(yè)務(wù)都是不具備機(jī)房級(jí)容災(zāi)的。

上面做完了，基本工作就完成了。上面很多事情都是一次性的，那未來的大把時(shí)間運(yùn)維做什么?

除了再花費(fèi)部分時(shí)間做線上問題處理，我們應(yīng)該把主要精力來提升業(yè)務(wù)產(chǎn)品力。做精細(xì)化運(yùn)維，還記得運(yùn)維九字真言么?“安全、穩(wěn)定、高效、低成本”，這就是我們的工作方向。下面會(huì)舉幾個(gè)例子。

11、再談業(yè)務(wù)監(jiān)控

上面談到過一次業(yè)務(wù)監(jiān)控，主要是一些通用的監(jiān)控指標(biāo)。我們對(duì)產(chǎn)品了解足夠之后，應(yīng)該做一些業(yè)務(wù)特有的監(jiān)控，推動(dòng)研發(fā)去做也可以，達(dá)到效果就好。

比如你運(yùn)維了一個(gè)MQ，消息堆積量是需要監(jiān)控的;比如你運(yùn)維了一個(gè)RPC服務(wù)，提供了三個(gè)接口，這三個(gè)接口的響應(yīng)時(shí)長、成功率是需要監(jiān)控的;再比如你運(yùn)維了一個(gè)S3服務(wù)，每個(gè)桶的短期帶寬增量你是需要監(jiān)控的……

現(xiàn)在有那么點(diǎn)感覺了么?

12、API成功率、延遲統(tǒng)計(jì)

在流量入口的Nginx做所有業(yè)務(wù)線的所有API的成功率和延遲統(tǒng)計(jì)是非常有必要的。把成功率比較低的TopN找出來，把延遲比較大的TopN找出來，讓業(yè)務(wù)去優(yōu)化。老板會(huì)喜歡這個(gè)的。

13、線上問題梳理

整理線上所有問題，挨個(gè)解決，運(yùn)維可以搞定的運(yùn)維搞定，運(yùn)維搞不定的找研發(fā)要排期，弄清楚每周解決了多少問題、還有多少問題待解決，用周報(bào)的方式體現(xiàn)出來。

14、成本優(yōu)化

通過服務(wù)混部、或者統(tǒng)一的資源調(diào)度平臺(tái)來節(jié)省機(jī)器資源，一臺(tái)機(jī)器便宜的也要好幾萬，這個(gè)事是比較容易有產(chǎn)出的。

15、容量規(guī)劃

容量規(guī)劃和成本優(yōu)化實(shí)際是緊密相關(guān)的，容量規(guī)劃的重點(diǎn)是根據(jù)自然增量和運(yùn)營需求，提前規(guī)劃準(zhǔn)備相應(yīng)的容量。容量可能包括帶寬、專線、網(wǎng)絡(luò)設(shè)備、機(jī)器等等。當(dāng)業(yè)務(wù)量下來的時(shí)候，可以騰挪相關(guān)資源支持其它業(yè)務(wù)線，讓這些硬件盡量滿負(fù)荷運(yùn)轉(zhuǎn)，物有所值。

業(yè)務(wù)精細(xì)化運(yùn)維可以想出各種事情來搞，除了做這事，另一個(gè)需要長期投入的是構(gòu)建運(yùn)維基礎(chǔ)平臺(tái)，像監(jiān)控系統(tǒng)、部署系統(tǒng)、產(chǎn)品庫、資源利用率平臺(tái)、域名管理、四七層接入配置平臺(tái)、日志平臺(tái)、Trace系統(tǒng)等等……

嗯，其實(shí)運(yùn)維還是挺忙的。

16、關(guān)于溝通

最后說一點(diǎn)，接手一個(gè)新業(yè)務(wù)運(yùn)維，勢必與研發(fā)有各種溝通，每次溝通都要寫會(huì)議紀(jì)要，發(fā)郵件出來，跟進(jìn)人、時(shí)間點(diǎn)等都要寫明白。

郵件發(fā)送雙方團(tuán)隊(duì)郵件組，cc各方老大。事后關(guān)鍵節(jié)點(diǎn)做Check，如未完成，線下溝通，達(dá)成一致后追此郵件給結(jié)論，說明延期原因以及新的時(shí)間點(diǎn)。如果溝通不暢，讓老大去協(xié)調(diào)。

我的看法基本就是這樣，如果大家有其它的觀點(diǎn)或是更好的建議，也歡迎在留言區(qū)一起交流。