本文首發於 Forrest隨想錄 訂閱號（ id：forrest_thinking），經作者同意授權轉載

下面我將從架構設計層面談談Dev和Ops的關係，而不是單純從組織架構和協作模式上的Dev和Ops關係。

1、為什麼要起這個話題？

運維性要在架構設計時就要統籌考慮，從一開始就得考慮進去，而不是到了運維這個環節再去考慮，否則就會出現很多的問題。

但實際情況，很多技術團隊在這一點上做得並不夠，而是將全部的精力放到如何進行服務化或微服務的拆分上，放到分散式架構如分散式服務、分散式訊息、分散式DB和快取等設計上，這些更多的是做了一些縱向的架構分解和技術鑽研工作，但是架構的橫向延伸和拉通考慮得明顯不足。

這樣恰恰是忽略了整個軟體生命週期中最長尾的運維環節，也反映出了很多公司對於運維這件事情的重視程度和理解深度不夠。

2、出現的問題

從我個人經歷的過程以及觀察的情況看，通常有這樣幾個現象：

（1）應用這個概念，在資源申請、域名申請、VIP申請、服務註冊、釋出部署、策略下發、監控等這些環節不統一，各自獨立一套；這個就是最典型的架構設計時，只考慮開發一個環節，沒有將架構上拆分後的概念延伸貫穿到整個軟體生命週期的問題。這個也將導致下面一系列的問題產生；

（2）上面做不到，沒有統一的標準和概念，各個平臺之間就很難整合和打通，所謂的持續整合、持續釋出、持續部署、持續交付等這些環節仍然靠大量的人肉動作去做，還談不上持續，效率自然上不去；

（3）穩定性保障無從下手，大量的服務化應用，錯綜複雜的呼叫依賴，海量鏈路日誌，問題排查困難，一個請求下來，到底跑到哪個應用去了都不知道；故障持續時間長，出現流量激增或基礎部件故障，無法快速隔離、降級和恢復；

（4）效率跟不上，還經常出問題，進而團隊協作效率降低，相互信任下降，就開始經常聽到下面的言論：

開發抱怨：“運維做得不到位，申請個機器老半天，釋出效率也提不上去，程式碼都寫好了，上線咋這麼費勁，嚴重降低了我們的工作效率，再有，出了問題還得我們上去定位，運維什麼都幫不上……”

運維抱怨：“開發的架構這麼爛，配置五花八門，還得手工維護，我咋知道這些配置幹嘛的，配錯一個就出故障，讓我怎麼自動化釋出；日誌放哪兒也不知道，一會這裡，一會那裡，出問題你說我咋定位……”

（5）好了，出了問題，就開始撕逼扯皮、相互推諉了，背了責任的一方又開始甩出背鍋言論，感覺沒有被公平對待。團隊的氛圍也開始出現bad smell。

3、問題出在哪兒了呢？

其實從開發和運維單獨的角度來看，雙方的表達都沒有問題，做的事情也都沒有問題。但是雙方都是隻站在了自己的角度表達問題和情緒，恰恰都忽略了很重要的一點：運維和開發不是相互割裂的兩個組織，運維的技術體系和全站整體的技術體系更是不可分割的，越是把它們割裂開看，越是站在各自的角度看問題，上面說的這些情況就越是無解，整個團隊也會限於這種沒完沒了的、毫無意義的糾纏中，從長期看對團隊和個人的發展都是很不利的。

所以，根本原因在於將開發和運維在技術和管理兩個層面給割裂開了，詳細描述如下：

• 運維階段要面臨的問題沒想清楚，從一開始架構設計上就沒有考慮清後續的運維階段要面臨的問題和事情，比如這麼多應用，資源應該如何分配、釋出的效率如何保障等，而都是在考慮開發自身的需求和問題。不考慮運維面臨的問題，這樣實際就是把運維割裂在整個架構設計之外了。（這個責任在誰呢？）

• 運維團隊的職責定位不清晰，整個技術架構朝著服務化的方向演進後，整個組織架構對於運維團隊的定義也是模糊的，也就是運維到底要做什麼，要承擔什麼樣的職責，因為一個合理的架構落地，必然要有合理的組織架構去對應支撐才可以。運維定位不清晰，就相當於將運維團隊給割裂在研發團隊之外了。

第一部分提到一個問題，運維架構和技術架構的脫節這個問題到底出在哪了？到底誰應該承擔這個責任？

一開始，我個人第一反應，承擔這個責任的或許應該是架構師這樣的角色吧，畢竟這不是個單純的技術問題。但仔細考慮過後，我覺得這樣也會有問題。

因為從服務化之後，整個架構就已經是去中心化的了，我們可以看一下自己的周邊，現在架構師的角色已經更多的往垂直領域發展了，如業務架構師（交易、支付、商品、營銷、類目等），或者某個技術領域的專家，如分散式服務、訊息、快取和DB，更大的方向上如大資料、搜尋等方面。我想這也是去中心化之後的必然結果，大家都是朝著某個更加聚焦、更加專業的方向發展。因為每個專業方向的特點又不相同，這時就很難再出現能把全站的架構講清楚的人了。

所以，我們如果只是想當然的認為應該是xxx角色要承擔責任，這樣難免會片面。

1、怎麼解決呢？

現實情況下，既然靠單個人或角色解決不了的問題，那就靠團隊，靠良好的組織協作、靠共同遵守的架構契約來完成。這裡我是從運維的角度來考慮架構契約，可能更多的還有前後端架構契約、介面設計契約等，這個更偏向開發內部自行遵守，就不班門弄斧了。

2、架構契約中的運維部分—架構標準化

上面提到的團隊和團隊協作，這不多說了，組織定期的例會討論，多參加彼此技術方案會議，隨時隨地的交流，這個只要保持開放的心態和合作模式都是可以做到的。

還是想再說一下，千萬不要出現，開發說這個應該是運維考慮的事情，跟我們無關，運維說這個應該是開發的事情，開發想不清楚讓我們怎麼辦？如果都是這種心態就完蛋了，建議雙方都往前走一步，大家要有共贏的心態才可以。

但是溝通討論及會議只是形式，最關鍵和重要的是各方要能制定出共同遵守的架構契約來。簡單來說，就是要遵循統一的標準，並使其橫向延伸到運維階段的平臺中去，一脈相承，比如釋出系統、監控、穩定性等平臺系統，從而使得運維的體系能夠更好地支援業務架構體系。而不是我們之前所說的，每個運維的平臺都是一個個孤島，無法形成體系。

重點談談關於架構標準化，之前提到的標準，更多的還是偏運維層面的標準，比如硬體資源標準、應用標準、部署標準等。但是架構標準就很少有提到了，直觀看上去這一點跟運維並沒有很大的關係。

但事實正好相反，我們可以一起分析下。按照我們自己的經驗，在做業務服務化的早期，我們也沒有意識去關注架構標準，結果就會出現以下幾個場景：

（1）分散式服務化框架，雖然絕大部分團隊用Java，但因為有的團隊對PHP特別熟悉，所以就用PHP去做服務化，後面遇到的問題就是Java的服務化介面和PHP的服務化介面該怎麼相互呼叫，所以到了後來我們的服務化框架還要提供PHP-Proxy來適配PHP的服務化介面；

（2）分散式DB中介軟體，有的團隊覺得我們自研的分散式DB框架不好用，對分庫分表的支援不夠友好，就去自研一套出來，或者去引入其它的開源的框架進來。平時使用沒問題，但是到了後期要做一些統一的策略就很難搞，比如DB訪問策略、賬號密碼管控、路由策略優化、慢SQL統計和優化等；

（3）分散式的快取，有的直接使用Redis，Redis可能還會有主備或者Cluster，有的搞個開源的Codis方案等；

（4）接入層上，有的期望用Nginx直接做7層負載，版本上有期望用TEngine，有的期望用Openresty，還有的期望用LVS有個VIP就夠了；

（5）穩定性上，比如全鏈路，如果要做統一的Trace打點，本來在一套框架上就可以實現的，結果要再多個框架上實現。對於開關、限流、降級這些策略也一樣，很難統一。實際上為後續的體系建設增加了很多額外的工作；

（6）上線後的日誌採集，因為跟其它團隊使用的框架不一樣，自己在搞一套日誌採集的系統，說白了都是ELK，但是因為太個性化不統一，只能自己搞個；

（7）……

以上還不包括之前提到的類似於Java版本、啟停方式、web容器型別、各種部署目錄等。所以到了運維階段，不統一不標準，壓根就沒法玩下去了。這時我們就不難理解，架構的標準對於運維階段的建設其實是有決定性的意義的。

可能有的人會說我們做得low，管理上有問題，我不否認，現在回過頭來看，當時確實是low了，管理上確實無意識沒經驗。不過在當時的情況下，特別是在初期，除非團隊中能有一個技能和經驗非常全面的角色，端到端hold住全域性，否則只能是靠摸爬滾打摸索出來。

現實情況，我之前經歷的多個專案，包括在華為的大型的電信和網際網路專案，以及當前我接觸到的很多的隊也仍然還是這種玩法，必然得走很長一段分久必合的道路才能走到正道上來，而且這種能力超群的牛人，我不敢說沒有，但是我能遇到的真的鳳毛麟角。

根本上，還是經驗意識上的缺失，而且在這一塊，架構的資料中貌似很少有涉及到這一部分的內容。當然，最終期望這樣的經驗能夠給到業界一些幫助和指導。

所以這時，運維必須要有意識參與進去制定架構標準，並強勢地約束，所謂的約束是要體現在技術平臺上的，比如在釋出系統和安裝部署上做約束，以Java舉例，只支援固定1-2個Java版本，目錄都約定好，容器約定好，服務化的框架約定好，這些約定好之後，如果線上要做變更，做釋出，必須接入這套體系，否則堅決不讓你上線，而且到了後面隨著叢集規模的增大，開發想繞都繞不開，因為完全靠手工已經是不可能的事情了，比如下圖，是一個應用單機的釋出部署過程，如果這個應用有100臺機器怎麼辦？

再比如，穩定性上，我們做全鏈路，我們只針對標準的分散式框架做打點（當然精力有限，也不可能支援所有的框架），如果你選擇的不是標準框架，而是自研或自己引入的，抱歉，打點只能自己做。這時遇到效能瓶頸或鏈路上的異常，如果使用的是標準框架，有全鏈路根據平臺的支援，日誌採集、分析和報表呈現就很方便，問題定位過程相對高效一些，如果不是，抱歉，只能手工地去定位了，一個請求分佈那個應用的那臺機器上去了，在這樣一個分散式的環境中，效率可想而知。同樣的，開關、限流、降級策略下發等，一樣會有相同的問題。

作為線上資源的控制者，穩定性的Owner，運維，你有權利Say No！

當然，歷史原因造成的架構標準不統一的問題，是需要Dev和Ops共同合作去改造的，而不是很強勢、單純地去提要求，這個涉及雙方合作方式的問題，後面再單獨寫篇文章。

1、架構實施和架構運維

我們制定或約定了架構標準，接下來就是架構的實施過程，架構實施應該怎麼理解呢？我大致列一下過程應該就比較清晰了：

（1）業務分析過程中，職責明確的業務模組從整體中拆分出來，比如使用者、商品、交易、支付等業務邏輯；

（2）從服務化的角度拆分，這樣一個大的業務邏輯可以拆分出更細的服務化模組，以商品為例，會有商品詳情、庫存、評價、價格、標籤等，如果繼續細分可能還會有各種讀寫邏輯的功能化服務拆出來，拆分的原則我們這裡不細說，這個基本取決於業務架構師的判斷標準；

這個階段拆出來的一個個模組，就是我們所說的應用了，這時就要開始應用名的定義，至此，一個應用的生命週期開始啟動。

（3）應用生命週期啟動後，應用相關的資訊就需要在運維繫統內生成了，也就是我們所說的CMDB和應用配置管理相關的資訊。重要的跟運維相關的如應用對應的Gitlab地址、基礎軟體模板和配置、以及對應的開發、測試和線上的資源需求；

（4）根據上面拆分出來的應用，開發同學就要根據我們之前約定的架構標準，開始選擇標準化的框架了，比如分散式服務化、訊息、快取、DB中介軟體、穩定性和一些第三方的SDK包等；

熟悉開發的同學都很清楚，上面這些框架選定好之後，按照Spring Boot的模式，可以自動生成整套的程式碼框架，就省去了手工引入各種二方包、三方包和一些固定的配置，也就是Spring Boot的“約定大於配置”的思路。這個也是目前絕大部分團隊的選擇的微服務的應用模式。

這樣開發同學可以把更多的精力放到業務邏輯的實現上，而不是各種各樣的框架引入和配置上面。所以，不僅僅是運維自動化，程式碼開發也一樣在朝著更加自動化的方向發展。（再進一步，Spring Cloud的體系則更加完善）

（5）啟動業務程式碼開發後，就該進入到持續交付階段了，不過前提是得先有持續交付的體系；

（6）業務上線後，就進入持續運維和反饋階段，如監控資料的分析、穩定性保障、核心應用和鏈路的容量評估、應急預案的制定和演練、強弱依賴的分析，以及從使用者提交角度的資料分析和保障措施等；

（7）應急事件和故障的響應、處理及回溯機制，因為故障沒有辦法100%的避免（但是應該杜絕低階的人為失誤和重複錯誤），我們要做的是故障的快速甚至是提前發現、業務的快速恢復，以及故障後的回溯和改進。

按照《聊聊架構》書中的架構生命週期的劃分，上述過程，我們認為是架構的實施階段，不過1-4，更多的可以看成是開發為主進行實施的，5-7階段則應該更多的是運維為主的階段（如果持續交付做的好，其實5也是可以以開發為主）。

不過，我的理解應該將5-7這個階段拆分出來，定義成架構運維或架構看護階段。圖示下來，就是如下過程：

從上圖我們就可以看出，運維應該要體現的作用和價值了。

2、運維的角色轉變和價值體現

（1）技術產品

產品是指能夠提供給市場，被人們使用和消費，並能滿足人們某種需求的任何東西，包括有形的物品、無形的服務、組織、觀念和他們的組合。（摘自百度百科）

整個運維過程中，運維一定要轉變被動響應式的工作方式，要主動求變，其中最重要的就是樹立起產品意識，將日常的人肉、繁瑣重複的工作不斷地總結和提煉。

比如，是不是能夠把自己原本靠人工完成的很多工作轉化成需求？是不是能夠把日常工作中運維和開發的痛點轉化成需求？是不是能夠把當前系統存在的問題和隱患找出來，在解決的過程中，經過分析總結提煉成需求？當需求提煉出來之後，是否能夠準確的傳遞給工具開發團隊，並跟工具開發團隊一起把需求真正的落地實現？

以上過程，就是將運維的人肉能力轉化為平臺能力的過程，比如持續釋出，沒有釋出系統之前，完全靠人肉堆，開發、測試和運維一起上，還經常出問題。但有了釋出系統，將人做的事情轉交給平臺自動化去做，最終滿足開發快速將程式碼釋出上線的需求。

結合上面對產品的定義，看看我們上面做的事情，是不是就是一個技術產品的工作呢。當我們具備了這個意識，能有更多的工具做出來，逐步形成體系，我們的工作是不是變得更輕鬆了呢？

（2）技術運營

運營的目的，和產品經理核心的不同是，要實現擴散，爆發，增長，收益等等。(摘自知乎)

通過上面技術產品的工作，如果可以做出一些有針對的工具和平臺來，但是僅僅有工具和平臺就夠了嗎？不過，遠遠不夠，為啥這樣說呢？

（1）推廣落地，工具做出來了是第一步，得要有人用，這就需要去推動落地。（跟業務上做出一個產品來，要去找渠道推廣，要吸引流量過來，並最終產生經濟收益是一個道理。）當然，我們在內部倒不必吸引使用者來用，因為我們的技術產品更多地是標準、流程和規範的載體，既然大家之前都遵守了這套標準體系，那就必須使用（使用之前做些小範圍的試用還是必須的），所以這個過程是可以強勢一點的。比如線上僅保留髮布系統一個變更入口，其它變更許可權全部收回等。

（2）線上執行資料分析，應用上線或者每次變更上線後，線上執行的情況咋樣，容量有沒有降、RT有沒有上漲、監控有沒有異常，業務量上是否有激增、使用者體驗有沒有下降，使用者和客服的反饋如何等。以上這些維度和指標就需要一張張的資料報表呈現出來，通過資料分析來指導我們要做出哪些優化和調整。（想想看，業務運營是不是也非常關注業務資料報表的）

（3）過程改進，工具更多的是一個執行角色，但是工具的使用是要配合大量的標準和流程一起來運作的，比如說持續交付，裡面就會涉及持續整合，再往細裡講，程式碼分支應該如何合併，出現衝突後應該如何解決，自動化測試需要哪些用例，用例等級如何定義，測試驗收的標準是什麼，構建失敗應該怎麼處理，當團隊成員無法達成一致的時候，應該如何決策等；再比如，（2）中提到的遇到的種種上線後的情況，應該對應什麼樣的機制處理下去，這些都是技術運營過程中所面臨的問題。一方面要先有對應的流程機制確認下來，大家共同遵守，另一方面，執行過程中，如果有導致效率下降或者有更好的措施的時候，這個時候就需要過程上的改進。

我們面臨的業務場景再不斷變化，技術趨勢不斷髮展，就決定了技術運營過程一個持續改進的過程。

在騰訊，運維被定義為技術運營，我覺得還是很貼切的。我在很多大會上聽海外的華人工程師分享，Operation這個詞都是被直譯成運營。所以，對於國內也不知道誰，把IT Operation（IT運營）這麼高階的一個詞彙，給硬生生地非翻譯成了運維這麼個意思，確實無奈：）

Anyway，不糾結。因為運維所發揮的技術運營的作用，這個能力其實才是運維的核心價值和轉型的關鍵。

3、技術服務

我覺得兩層含義，一個是一定要有服務的心態；另一個，提供解決方案，還是舉個栗子：

比如，我們在線上運維過程中，發現有一塊相對獨立的業務，體量越來越大，隨著使用者的增多從一個非核心的業務變成了一個核心業務。但是，這個業務是用C++來做的，架構上是分層架構，每層都是通過配置IP的方式進行介面呼叫，還有跨層的呼叫，呼叫邏輯很不清晰。遇到的比較突出的問題就是效率和穩定性：

• 釋出的時候，就沒法做到服務發現，要一臺臺改配置將流量遷移走，然後手工執行釋出指令碼同步程式碼，然後再將配置改回來進行驗證是否成功了，隨著機器數量越來越大，開發就吃不消了，太麻煩；

• 出現故障，唯一的手段就是回滾、重啟、乾瞪眼，類似降級、限流或開關的穩定性手段都沒有；

• 線上容量也沒法評估，釋出個版本發現容量不夠，就擴容，而不是真正去找一下效能下降的原因；

• ……

這個時候發現了問題，我跟團隊一起去做的事情，找到對方的主要負責人和其主管（或者對方來找我們），大家一起坐下來，針對現在的問題和痛點，看如何改進，比如釋出效率低，那釋出的過程步驟是什麼，我們一起看看什麼地方可以改進和提升，比如有寫死IP的情況，那是否可以做到分配從程式碼中分離，或者考慮服務發現的方案（服務發現考慮過，但是實現成本比較高，現在做需求還做不完），那是否可以利用現有的服務化框架，然後給中介軟體團隊提需求儘快支援C++的分散式服務呢？嗯，這個可行，我們一起找！

穩定性有問題，我們現有的穩定性系統支援開關、降級、限流，最近碰到的問題如果有降級措施的話，是可以將故障快速隔離的，然後介紹下現有穩定性的解決方案，評估了下，嗯，可以搞。

最後的結果是，雙方共同配合進行改造，將一個維護效率和穩定性不高的業務大大改進了。

這個時候，運維雖然不是程式碼的實際開發者和改造者，但是通過解決方案和思路上支援，推動了業務架構上的演進。這裡也不是開發同學能力水平不行，而是業務需求量大，實在沒有這麼大的精力去端到端關注全面的東西，但是兩者一旦都向前走一步，擦出基情的火花，事情效果很顯著了。所以我們配合一定要有共贏的心態，而不是你是你、、我是我一定要分得很清楚，當然這個過程中，我建議運維應該向前多走幾步。

作者介紹 趙成

• 現負責美麗聯合集團（原蘑菇街、美麗說和淘世界）運維團隊的管理以及運維體系建設工作，專注於運維創造價值，以及雲端計算時代運維的轉型和突破。

• 曾任職華為，擁有近10年研發和運維經驗，期間積累了非常豐富的電信級和網際網路業務研發和運維經驗。

-END-

從技術產品、技術運營、技術服務這三個角度來做運維，運維還是原來那個運維嗎？這時運維個人的成長空間、承擔的職責以及價值的體現，是不是會大不一樣？

來全球敏捷運維峰會北京站，讓運維大佬為你一一解答！

58到家高階技術總監  |||   京東金融運維負責人

噹噹網架構總監  |||  餓了麼技術總監 

前亞馬遜中國區SDM  |||  新炬網路執行副總裁 

青島航空高階架構師  |||  潤乾高階技術總監 

愛錢進DBA團隊負責人  |||  京東資深架構師

滴滴出行雲架構師  |||  阿里雲資料庫開發負責人

更多大咖在路上

近期熱文：