作者序：

搞了好多年安全，一不小心掉入運維的“坑”裡。

在摸索運維業務的路上，不斷的踩坑，不斷的爬出來。

我們的團隊在成立公司的初夜解散，隨後各奔東西。

也許，成長，總要經歷過一些事情吧。

坑不斷，踩還亂，離也愁，還是寫點東西壓壓驚吧……

1、開篇寫點什麼呢？

運維，專業一點說叫做“可靠性支援工程師”，方言稱為“背鍋俠”。本篇小文不談大企業，因為 BAT 企業總有專職人員做專職的事情，諸如：資料庫管理員，系統管理員，桌面管理員，網路工程師等諸多崗位……

但在中小型企業裡，“背鍋俠”不光身兼數職，還要面對各種問題。

系統總要持續跟進及優化，“鍋”總要有人背，運維的價值又何在？

話說企業使用了各種雲來解決伺服器運維的需求，是不是就不需要運維了？

作為與我一樣背鍋俠的你，是否也曾想著多考幾個證書，來提升薪資？你的話語權是需要證書來獲取？

還是能力來獲取？

帶著問題，我們來進行拆解和剖析，希望能讓你有所收益。

2、為什麼背鍋俠總是我？

我也曾是小公司的一名“背鍋俠”，從伺服器採購，到揹著伺服器去機房上架；從給老闆 PC 裝系統，到公司內網布線；從軟體效能測試，到寫優化文件；我就是這麼一個角色。

然而，運維的“背鍋”總是相對於開發而言的，你越是在底層，你的技能越少，不能解決業務的痛點，沒有話語權。這“鍋”你不背，難道讓老闆背嗎？

這裡舉個例子：某公司開發使用的技術棧為 Java，開發同學釋出的是 war 包，Tomcat 容器，MySql 資料庫。

需求完成後，上線釋出，開發同學沒有在測試環境測試（偷懶），只是在本機開發環境下功能正常，把 war 包交付給運維同學。運維同學修改配置檔案後釋出上線，奇葩出現了，某個檔案上傳功能呼叫即崩潰。

這時，運維同學在檢查了各種目錄許可權及配置後，把這個問題反饋給開發。這時，開發同學為了避免加班，說：“這是你 Tomcat 容器崩潰，又不是我的應用程式崩潰。”運維同學很無奈，老闆又不懂。這時解決方案是什麼？

運維明知自己加班是徒勞的，可又該怎麼辦？如果運維去和開發吵架扯皮，一定是情商嚴重不足。這時候，老闆信任開發。

運維同學在仔細檢視 log 後，對比內網 git，發現開發同學打包時少了一個元件，運維手動打包，釋出上線，問題解決。老闆卻認為這是運維應該做的。

上面這個例子在中小型IT企業中很常見，並非個例，“背鍋”源於給開發“擦屁股”。如果我們不能扭轉老闆的思維，那就要讓自己變得更有價值。

作為運維，如果你並沒有 Java 技能，那就要學習，讓這個崗位換個人做不了，提升個人技能。到更好的公司，你才有可能擦到更好的“屁股”。

但是，這是否與運維本身背道而馳？

問題與風險始終是存在的，面對問題與風險，我們更需要的是擁抱，而不是逃避。你可以為開發擦一次、兩次、三次，但你並不能做永久的保姆。

3、再談談企業的需求與看法

企業到底需要什麼？運維怎麼做才能讓老闆滿意，讓團隊滿意？剖析這個問題，先學會換位思考。

如果你是老闆，你認為運維應該做什麼？我走訪了一些中小企業老闆，總結出以下幾點：

1. 學習能力，精通企業業務，一聽故障描述就能大致猜出故障所在；
2. 風險可控，這裡的可控來源於3個方面，穩定、效能和安全；
3. 自我認知，找準自己的定位，別天天吵著累，這與自身能力有關；
4. 及時響應，遇到故障第一個衝到前線，這好像就是職責；
5. 優化能力，這一點可以歸納到第一點，說白了還是技能；
6. 溝通能力，學會提升自己的情商，遇到甩鍋淡定面對。

下面不逐一展開說了，只著重說幾點。

3.1 一個運維的學習能力

首先說學習能力，我認為更多源於自我技能與技能提升，在這個技能高於學歷的時代，可是我還是沒有找到合適我的工作（苦笑）。

一個靠譜能出活兒的運維到底需要具備哪些技能？ 首先你得會裝系統（哈哈），系統裝的多了，你才可能去寫自動化的系統安裝指令碼；

好了，寫指令碼，BashShell 也許是我們每天面對的，但並不是全部；有些任務交給 Python 或其他的語言工具似乎更合適；

公司業務出故障了，你要去“擦屁股”，公司業務用什麼開發？什麼？你不會？怎麼可能？至少要懂一點吧，好了，這個時候你可能接觸到 PHP/JAVA 當然還有其他，等等；

開發交付的就有問題，好，問題在哪裡？如何測？要給出應對的解決方案吧！伺服器被攻擊了，你要順藤摸瓜找到應對措施吧？不知道如何攻擊你還談什麼防禦？安全攻防滲透入侵總要懂一點……

好了，你都懂一點，但好像什麼都不專精……等等，誰說的？給我一個星期，練一下增刪改查和公司開發環境配置，我就轉崗去做開發了！OK！沒問題！可是，公司到底是要運維的，學習能力與自身技能似乎本來就不矛盾；

噢對了，還有一句話這麼說，一個靠譜的，能出活兒的運維，一定可以承擔起架構的角色，運維本身就是在搭開源的盒子，就像堆積木一樣，運維當然知道什麼元件用在什麼地方是最合適的。你們猜這句話誰說的？

當然，這是我說的。比如說，某些業務，用到了5臺 apache，我們做過優化，同樣配置的主機，2臺 Nginx 就足夠了，為企業降了3臺伺服器，省了錢。這難道不是具體的運維價值體現嗎？

3.2 運維要有風險可控意識

風險可控：穩定、效能、安全。

• 穩定

穩定可控，舉個例子：某個業務服務每隔3天就要重啟，每天都在夜間23:30重啟，問題的具體現象為，每隔5天就崩潰，但你並不知道為什麼會崩潰。

首先，這並非穩定，如果你能通過合理的配置，把3天重啟改為3周或30天。至少在一定程度上提高了穩定性。

這個例子的原型為：某中介軟體 Bug，記憶體無法自動釋放。起初的現象是每隔5天應用崩潰，後來審計這個開源的中介軟體，一段記憶體垃圾回收機制有問題，遂改之，大併發測試，再後來30天也沒有出現過崩潰，一直穩定運行了2年，直到業務替換。

• 效能

什麼叫效能，企業要你來是提升效能還是降低效能？提升能提升多少？效能如何把控？伺服器硬體我們要留多少冗餘，多少報警？你當真做過思考嗎？還是到點下班，之後撩妹吃飯喝酒睡覺手機關機？

上面提到5臺 apache 的業務，使用2臺 nginx 支撐，還有冗餘，這是由於瓶頸落在了應用程式本身的機制上。

那麼，你也許會說，如果落在了磁碟 IO 或網路 IO，不是照樣不能精簡嗎？對的，有些錢省不掉，但關鍵是，如何讓企業把錢花對，這才是你的價值體現，不是嗎？

• 安全

終於要說一下安全了，我做了十多年的滲透，多少還是有那麼點發言權的。我們結合企業自身來思考一下，安全是否屬於測試的範疇？我想在某些場景下是的。

比如，我們在公司內部，拿到上級部門的授權（比如老闆，技術負責人），公司業務對我們而言，可以做白盒，也可以做黑盒。而滲透，只是一種黑盒測試的方法，僅此而已。

那麼，漏洞又是什麼？漏洞源自於程式設計師寫的 Bug。企業不可能要求所有的開發都是大神，所有的程式設計師也不可能不犯錯。有些環節，還是會疏忽的。

我就遇到過，一個做了6年的 Java 技術經理，公司業務的有些核心元件是他實現的，信誓旦旦拍著胸脯帶著譏諷的語氣告訴我，“你測試也是浪費時間，絕對沒有問題，你要能找到漏洞給你加薪……”

我當時很想抽他的臉，但我還是天真的信了他的話，因為我知道，絕對沒有“絕對”。當我用偵錯程式（Fiddler）改了上傳請求，把 WebShell 扔伺服器上時，拿到的居然是 root 許可權，連提權都省了。

然後轉過頭來給運維團隊的同志們解釋為啥不能怕麻煩，不要用 root 帳戶啟動容器（Tomcat）。那哥們兒傻臉了，但我依然給足了它面子，這點我還是懂的。

雖然最終問題提交併解決了，但加薪不是因為這個，是因為從那之後多了個活兒，就是滲透測試（黑盒），還好白盒部分我們不管，是開發人員自己搞定的。

• 再談：資源配置

當年公司的官網自己買了伺服器掛在 IDC 的機房，兩個官網，用了兩臺。我發現，這兩臺伺服器簡直就是浪費，因為基本沒有流量。

雖說一個用於演示，一個用於生產環境（所謂的生產也是演示）。但有夠扯的，兩臺伺服器，每年託管費用就將近2萬，老闆花錢也是心疼的，因為他的錢也不是天上掉的。

我們後來使用了 RedHat 原生的虛擬化方案 KVM，把開發經理要求的“必須是單獨的主機”的要求給 K.O 掉。下架一臺機器，拉回來，我們做測試機用。

線上機房從原先 100Mbps 的出口降配為 10Mbps，即便這樣，加上遠端備份，加上自身業務，資源的佔用也不到50%，小企業的資源就是這樣省出來的。

當時老闆很高興，為企業省了錢，拉著大家去聚餐，說大家要感謝運維同學云云。當然，具體事情要具體分析，並不能一概而論。

3.3 被逼出來的運維能力

• 甩“雷”的前提，是這個“雷”在你手裡

運維的溝通能力，多半是被逼出來的。運維要面對的是負責人，程式設計師，老闆，以及客戶等等。你能說溝通能力不重要？我想，你不會傻到和程式設計師撕逼的時候來一句，“你就是寫 Bug 的！”，你也不會蹬鼻子上臉衝老闆喊一句“這不歸我管！”。

當然，有些老闆還會要求你去給他家裡的 PC 機裝系統，說“不急不急，抽你的時間”，你能說不去？個人溝通能力的鍛鍊，是你被磨圓的過程，情商有時候大於智商。

雖然我們沒有把別人當傻子，但是有些傻子竟然是天生的，你不是他父母，當然這不能怪你。但有個原則，你要注意：“先別慌著說‘不’，甩雷的前提，是這個雷在你手裡！”。

你總要把問題分析透徹，才可能指出痛點，才能有效應對，才能說清楚，哪些“雷”不歸你管，才能有效甩“雷”。同樣，這個過程也是自身學習與提升的過程，要學習的不全是技術層面，你說是不？

• 老闆的任性

老闆要不要視覺化？我們說難聽一點，視覺化在一定程度上是“裝逼”用的。比如說：老闆看著訂單曲線就很激動。但你能捂著老闆的眼不讓老闆看嗎？老闆不會查 log，不知道各項引數的具體意思，就給他看圖好了，畢竟一圖勝千言嘛。

老闆拿著這個視覺化，還能去和客戶“Tree New Bee”，為什麼？

因為客戶並不關心你的 log，只關心你們的企業能給他帶來什麼，但在這之前，客戶要搞懂你到底在向他說些什麼。

還有些情況，我們需要用到視覺化，我們提交的週報、月報，提交給誰？老闆也看不懂引數，需要開發經理去解釋，但把視覺化實現了，老闆可以檢視到實施的情況，實時的瞭解你的或伺服器的工作狀態，以及一些業務的實時情況，難道老闆不喜歡嗎？還是你不喜歡？

比如說，我們用 Grafana 實現了伺服器的監控外，又實現了業務 API 的視覺化，老闆可以瞭解到，最近10分鐘、或5分鐘內，有多少人線上下單，多少錢進賬，你看到老闆嘴角的口水了嗎？

雖然我做了 Grafana 的漢化併發在了 GitHub（好久沒更新了，說來慚愧），但我們更希望有更多的人可以都去參與一些開源工具的漢化或者修復完善工作。

開源軟體基於社群的更新和維護，如果你看到一個工具很久都沒有更新了，你會選擇嗎？如果你不瞭解的話，我想你不會。

• 頭腦風暴—技術範圍內的“撕逼”

對了，我並不知道你的公司是否定期做分享，也就是內部的“頭腦風暴”，大家可以在技術範圍內盡情的撕逼（記得帶上專案經理和開發同事，但別打人）。

但我會，我帶過的團隊，第一就是要養成定期分享（包括故障反思）和撕逼的好習慣。記得曾有運維同事這樣提到過，“我們現在的虛擬化方案太 low，ZeroVM 就不錯”講了一大堆如何好。

後來在實際測試時發現 Bug 過多，而且很久又沒有更新，這個方案被否掉了。但這個同事後來轉向 Docker，再後來他負責了公司虛擬化方案升級的大部分工作。

說這個例子，就是讓大家知道，在中小型的 IT 企業，同樣需要學習與研究（搭開源的盒子），面向適用自己企業的業務，也只有你最懂。

所以，中小企業的開發者和運維同學們，你們有必要和義務來做內部的定期分享，也就當鍛鍊自己，說不定什麼時候碰到個大會，也能上去“Tree New Bee”，當然，內容乾貨才行。

3.4 補充個重點：日常演練

關於日常演練，據我所知，大多數的IT企業很少去做災難的日常演練。因為“沒時間、太忙”等等等等，可是你知道嗎？如果不做災難演練，當災難來臨，比如“rm –rf /”一個命令下去，雖然是手誤，但多少都會讓你驚慌失措。“我*，我竟然做了什麼？”。

災難演練與災備同樣重要，演練資料庫被黑，所有表都被清空；演練“內網 GitLab 被刪，如何恢復並通過日誌找到線索”等等；演練突如其來的 DDOS，怎麼應對以及做流量清洗。

在糧草豐盛的日子裡，做好“彈盡糧絕”的準備。雖然你不可能把方方面面都做到提前預判，但至少會鍛煉出來你敏銳的嗅探能力，比如在磁碟報警時，你有充足的時間可以更換磁碟。

我們曾遇到，在我們的測試機器（二手的伺服器）上，磁碟（做的Raid 5）嘀嘀嘀響了一個多星期（在另一個辦公室，我們不知道），直到被行政人員提醒，及時更換了硬碟。也就是這時候，才開始實施了監控。

因為在這之前，只是覺得這臺伺服器的磁碟寫速度不如從前，但考慮到機器是舊的，就沒有顧忌太多。但於此同時，某開發負責人“手誤”，把自己 GitLab 的分支全刪了，說來也奇怪，他自己竟然沒發現（後來才知道，這傢伙要離職，提前做好準備），因為我們有備份，及時給找回。

程式碼的壓縮包不大，可以備份很多歷史場景（每日備份），但對此，是因為之前做過演練，但仍然“防不勝防”。

• “日防夜防，家賊難防”

說起防，“日防夜防，家賊難防”，這是真的！看新聞曝光過某大型電商企業內部員工洩露了上億條資料。但我之前的職業生涯卻是遇到過的，公司的開發經理因為太善於內部政治鬥爭，被手下一個想要“上位”的傢伙給害了。

這個想要“上位”的傢伙是一名開發，比較有心，有次因為要使用技術負責人的 GitLab 的許可權，讓開發經理在這名開發的機器上進行登陸和操作，這傢伙悄悄的記錄了對方的密碼（居然還是弱口令）。

在之後的不到一個月時間裡，他使用技術負責人的許可權拷走了公司所有程式碼，並進行了日誌清除。但他的水平確實比較 low，並不知道我們還對日誌進行了二次備份。

在他個人與技術負責人發生正面的“政治鬥爭”時，用開發經理的許可權刪除了公司內網 GitLab 上的所有程式碼，並栽贓我們的開發經理。這時候，開發工作陷入停滯。老闆急了，要求我們立即恢復。

可是，每個開發人員的機器上，都有自己正在擼的程式碼。所以，至少在1個工作日之內，影響並不是很大。我們用了半個小時，就發現了他的具體攻擊過程，先改自己機器網絡卡的 MAC 和 IP（我們路由有記錄，雖然我們在路由上做了 ARP 繫結，但也只是不能上外網），再然後，使用開發經理的帳號密碼登陸 GitLab，刪除所有程式碼，擦掉本機記錄，然後再把網絡卡 MAC 和內網 IP 地址改回去。

我們向老闆反饋，老闆報警，至於後面的事，不用說大家也都明白了。很慶幸我們提前做過演練和對應方案，也很慶幸我們找到了直接的關鍵人，但更重要的是，這種家賊，確實難防。

為什麼不能建立一種“公開、透明、可監控”的機制，來預防“家賊”事件的發生？這是值得很多企業去思考的一個問題。經濟學上有一種叫做“逆向選擇法”，也就是（似乎是行政HR的活兒）“員工的利己行為分析”。

員工具體會發生哪些“利己”行為，哪些才是對公司有傷和無傷的，我想每個不同的企業都有自己的判斷與思考。

但往往，人是最不可靠的，特別是在企業正在迫切需要發展的階段，企業到底需要“靠譜”的人，還是需要“可靠”的人？這個問題，你可以來發郵件找我撕逼，我打算在下一篇內容探討這個問題。

4、結論

總之，一切問題的發生，總有其必然的原因。就是說，一切皆有“因果”。我們要擁抱所有可能發生的問題，在我們的能力的範圍內，做好充足的預判及應對措施。

當然，“能力的範圍”也會隨著你的努力而不斷的擴大。這當然是學習和提升的過程，是自我價值體現的過程，也是運維價值實現的過程！

另外，我要推薦另一篇文章，“網際網路運維雜談”公眾號（waynewang_ops）發過的一篇文章“談談運維的價值和思路”，作者謙益（有興趣的同學可以自己找一下）。

小弟讀的書少，你也許可以騙我，但我不一定會當真。最後，歡迎關於運維業務的探討與撕逼，可以發郵件給我，[email protected]，可以找我好好的撕逼。

原文來自微信公眾號：高效運維