趙成，花名謙益，現在負責蘑菇街運維團隊的管理以及運維體系的建設工作。在運維行業中已經做了7年，之前有過5年左右的業務開發經歷。加入蘑菇街之前在華為一直做電信級業務的開發和運維工作。

2016GOPS上海大會參加完有一些感受和感想，最近一直在思考，再就是前兩天在高效運維的群裡，大家又談到運維苦逼，沒有成就感的事情，也促使我更加的想表達一下運維價值方面的東西，正好跟老王一拍即合，就在老王的貴寶地來一發吧。

首先，說下GOPS上海的感受，我所講的專題是在運維自動化專場，《從0到1：蘑菇街運維技術管理體系建設分享》，應該500人的場地，差不多進了有600多人吧，這是我第一次面對這麼大的場面演講，上場前的壓力也著實不小。後來，我講完後，又去APM專場本來想聽下，沒想到人數寥寥，而且提前很多就散場了，這有點讓我感到意外。第二天，海量運營專場，在我看來，這是非常好的或者最能體驗運維價值的一個專題，而且講師都是非常重量級的，即使聽眾所在的公司達不到海量，但是有很多的思路和方向也是可以借鑑的，我本以為會爆滿，但是場子裡最多的時候也就一半多一點吧，100多人，也讓我有點意外。當然其它的各個專場可能也有獨特的吸引力，也跟聽眾們的需求是強相關的，這一點上不做太多的評論。

不過，後來跟一些講師交流下來，我們共同的感覺是，運維自動化場場爆滿，聽眾們都特別的關注運維自動化，恰恰說明了我們現在運維的現狀是：有太多的公司還沒有自動化或者自動化程度很低，還沒有找到明確的自動化的方向和思路，所以大家才會有這樣的需求。回想起會後，也有很多的同學聯絡到我，說沒想到運維還可以做這麼多的事情，能不能讓我給點建議，運維應該怎麼做起等等，也印證了這一點。那問題到底出在哪兒了？

這裡先不談運維自動化的問題，我想先表達兩個觀點：

1、運維，不僅僅是自動化，還有很多方向值得我們發力

2、運維，技術不是問題，重要的是思路上的轉變

第一個觀點，我前兩天在高效運維群裡，針對運維價值應該怎麼呈現，我們的機會在哪裡，表達了一下自己的觀點，大致意思是：一個公司對於開發這個角色的訴求，永遠是怎麼能更多更快的把業務需求和功能實現，並儘快釋出到線上，從而讓業務能夠實現快速的流量引入和變現。如果一個公司的開發都跑去關注怎麼提升資源分配的效率，怎麼提升釋出效率、怎麼提升線上穩定性、安全，還要額外去考慮下成本問題，這本身就已經脫離了一個公司對開發的訴求。那這個時候暴露出來的，效率、穩定、安全、成本等等問題，誰來解決？

剛才已經提到，開發同學應該不是這些問題解決的主體，那一個技術團隊，還有哪些角色適合？測試 or 專案經理 or運維 or XXX角色，貌似看來看去只有運維最合適，因為運維離線上業務最近，對線上的情況是最熟悉的，其他任何一個角色都很難從端到端的視角是看待這些問題，即使看到了，也很難能夠有效（關鍵是很難有精力）的落地。所以這個時候，我覺得這些問題的解決就是運維同學的機會，而不要把他當成負擔。

從技術團隊和老闆的角度來講，對開發就是期望儘量多儘量快的完成需求開發，而對運維，可能很難提出明確的期望和要求，但並不意味著沒有。那到底是什麼呢？實際就是上面（效率、穩定、成本、安全和體驗）這些隱性的期望，往往可能沒有很顯性地表達出來，運維自己又不能很好的領悟到這些事情的重要性時，一旦出現問題或線上故障，老闆發現我們沒有很好的達到以上期望，一腔的怒火就很容易就發洩到運維同學這裡了。再進而，運維就越發的感覺到自己是背鍋俠，越來越沒有成就感。

所以，正著看，這些事情運維來做最合適，反著看，這些就是老闆對我們的期望啊。正反我們都不跑不掉，那就不如主動做好。

推薦最近朋友圈轉的吳軍的文章《不做偽工作者》，文章最主要表達的一個觀點就是：要做對公司和業務最有價值的事情。運維確實做了很多事情（忙成狗），應急處理了很多線上故障（操著賣白粉的心），重大的變更必須放到凌晨操作（起的比雞早，睡得比豬晚），真的是非常非常辛苦，但是這些事情真正創造了多少價值呢？可能這就需要我們好好思考一下了，這裡我並不是否定我們運維在做的事情，這些事情說沒法避免，肯定是要有人來做，由運維做也是應該的，但是我們千千萬萬不要陷在這些事情裡面，自我感覺良好，自我認為做了很多苦勞的事情，就把這種狀態當做常態了，如果是這個思路就是我們的問題了。我們得要尋求改變，往往這個改變的過程和結果，就是價值呈現的時候了。

通過以上可以看到，自動化只是一個技術手段而已，重要的是我們得要找到方向。下面是我總結的效率、穩定、安全、成本和體驗的一些事情，這些跟GOPS上很多專題都相關，也說明運維可以有很多的方向去發展，期望對大家有用。（以下部分在其他社群也分享過，這裡做個簡要的摘錄，想看原文的直接聯絡我）

(1).效率

這塊跟日常的運維例行工作緊密相關，如資源分配&回收、域名配置、VIP配置、持續整合&釋出、應用部署、應用擴容&縮容等，這塊是運維最基礎的工作，通常提到的運維自動化，大多是集中在這些工作上，因為這些工作偏日常和重複，目前業界的自動化的解決方案也非常完善了，所以可以優先把這些問題解決掉，目標就是解放運維的生產力，提升運維效率，降低人為失誤，讓運維的同學可以有更多的精力去做更有價值的事情。

(2).穩定（質量）

讓業務執行更加穩定，監控、全鏈路、強弱依賴、限流降級、容量評估、預案平臺等，這塊需要有相對比較獨立和專業的監控和穩定性平臺來支援，目標是最大程度的保障系統的穩定和執行質量，即使出現問題，也能夠快速發現、快速響應、快速（自動）恢復。

(3).安全

安全是與運維同等級別的一塊專業領域，但同時又是跟運維緊密相關的，運維同樣要關注安全，因為安全出現導致的問題，往往也會給運維帶來沉重地防護和修復成本。我們經常提到的，各類主機安全、DB安全、Web安全、應用安全等等，與此相關的還有漏洞、DDos、CC等關鍵詞。

(4).體驗

這裡提到的體驗，指的是終端使用者的訪問體驗，非功能或產品使用體驗，對於運維來說就是要關注訪問速度。作為開發的同學來講，可能更多的注意力會放在自己負責的程式碼以及該部分的效能問題，不會關注到端到端全流程的效能和體驗。但是運維可以站在全域性的角度來審視和治理整個端到端全鏈路的效能情況，並給出對應的效能優化建議。

(5).成本

成本問題，也就是技術ROI（投入產出比）的問題，當系統規模和體量變大之後，掌控在運維手中的各類資源，將佔整個研發團隊支出的大頭。如果沒有很好的成本控制意識和策略，資源體量將會持續增大，甚至是翻倍或指數級的增長，對於公司成本會是非常大的負擔和壓力。

第二個觀點，我認為現在對運維來說技術不是問題，重要的是思路上的轉變。

現在各種業務跟中開源工具，比如自動化的puppet、ansible、chef等，監控有nagios、zabbix、cacti等，虛擬化有kvm，openstack，以及等等各種開源技術，各類商業的軟體也同樣百花齊放，可供選擇的餘地非常大。所以，我覺得運維在技術上不是障礙。即使你覺得哪些工具不好使，你做一個比這些工具更牛逼的出來也可以，程式語言python、php、perl，也不是太難上手。

不過問題又來了，這些技術怎麼用起來呢？真是個頭疼的問題，說實話我也不知道該怎麼用起來。但是如果一定要我來回答，我會先問這麼幾個問題：

a、你的技術團隊現在存在的最大或者最讓人頭疼的TOP的問題是什麼（3或5個都可以）？

b、這些問題哪些你認為是運維應該也可以解決的？

c、如果你認為有應該是運維解決的，那你覺得解決這個問題，應該採用什麼樣的方案？至少給出兩個2備選

d、分別從方案的優劣和成本上評估那個方案最佳

e、到了這個問題上，貌似用什麼技術已經不是問題了吧

回到運維自動化建設上，不要拋開實際問題和場景談技術，這樣的技術方案是沒有意義的。一定是從問題和業務的角度出發，找到痛點所在，用合理的技術解決掉，而不是把技術強加到業務上，讓業務來適配技術，這樣出發點就錯了，我聊下來，返現現在有太多的同學和團隊都是因為這個問題跑偏掉了。比如，我舉一個大家經常聽到或見到的一類經驗：《秒級啟動（擴容）千臺（萬臺）機器（容器）》，我試問一下，有幾個公司是需要這種業務場景的？如果真的需要這種業務場景，是效能不行，得用機器來扛得嗎，不做優化早幹嘛去了？如果真的併發太高了，請問下，前面交換機、路由器和防火牆要不要也秒級擴容下？加了這麼多機器，後面的DB扛得住不，是不是也得秒級擴容下?這千臺萬臺的成本好像有點高吧，老闆同意這麼多的預算做buffer？

所以，單純談技術，是沒有意義的，做事方法的思路上一定要轉變過來。

就我個人來講，15年初才接觸網際網路運維（之前是傳統電信級業務的運維），一開始我連CMDB是個啥都搞不清楚，就網際網路運維來說是個門外漢。但是我到新公司後，一直到現在都在做的事情，就是不斷的跟開發和業務團隊去溝通，你們有什麼問題？痛點在哪裡？然後不斷的思考，問題背後的原因是什麼？我們應該怎麼解決？業界是怎麼解決的？什麼樣的方案最適合我們？這些問題想清楚了，討論清楚了，該做什麼也就清晰了，這也是我在GOPS大會上分享的從0到1的內容，其實我們已經做了很多從1到100更有價值的事情。現在我們的運維團隊從來沒有刻意的去證明過什麼，但是我們仍然可以獲得整個技術團隊的尊重，我們的績效也從不比別的團隊差，也從來不會隨意背鍋，是我們沒有做好的，就是我們沒有做好，我們考慮更多的是下次怎麼才能避免和解決，但不是我們的問題，我們也要有理有據的表達出來，為的是促進整個技術團隊的進步和改進，而不是把精力耗費在撕逼扯皮上，運維就是應該要站在這樣的高度上來貢獻價值才對。

以上，根據我個人和團隊一路走來的一些經驗和心路歷程，分享給大家，為運維這個行業貢獻一份力量。

原文來自微信公眾號：網際網路運維雜談