關於「運維」的一些思索

一說起運維，很多人通常會將其工作範疇與伺服器維護、網路裝置配置、軟體安裝維護等工作聯絡起來，認為這就是運維；而開發經驗更多、或對開發理解更深的人知道，除此之外，開發所依賴的各種基礎設施的搭建和維護，以及支援規範的開發過程、提高開發效率的各種系統或工具的搭建、管理、維護，甚至一些與此相關的開發工作，也是由運維來承擔的。

這些說法雖然沒做，但是單薄了點，尤其對於新手和外行而言。這放在過去，影響可能不會特別大，但現在微服務架構的背景下，如果不能很好的理解運維，微服務架構的設計和實現也會舉步維艱。

Gevin最近結合自己的工作經驗，參考了一些書籍和運維大牛們的觀點，梳理了我目前對運維的理解，和大家分享一下，歡迎交流。

運維的意義

通俗的說，在系統開發階段，運維要支撐開發、協助提高開發效率和維護研發基礎設施；在系統上線後，運維要保證系統的正常執行。這是大家公認的運維的意義，我最近看大牛的分享，發現從「公司利益」的角度談論運維，是描述運維意義的一個更好角度，也能描述的更加清楚。

一個公司對於研發的訴求通常是全力實現業務需求，並將需求儘快釋出上線以實現商業上的收益。但在開發過程中，開發工作可分為兩類：一類是專注於業務需求的開發和測試工作，另一類是基礎工具或模組的開發，比如中介軟體開發、穩定性開發、工具開發、監控開發、IaaS 或 PaaS 平臺開發等。前者是公司所有人都認同、也會關注的工作，後者是支撐前者乃至整個產品穩定的基石，只要稍加解釋，公司所有人也應該能認同這部分工作量，也應該會支援相關的開發工作（否則就要以產品的不穩定為代價了）。

然後我們再梳理一下研發工作，就會發現，除了業務開發和測試外，其他研發工作都是為軟件開發過程或軟體的執行維護服務的，其作用是提升研發效率和穩定性，進而降低成本。雖然這些工作沒有全部定義在運維角色上，但這些工作職責已經屬於運維了。

關於運維，大牛還有這樣的觀點：

運維能力是整體技術架構能力的體現，運維層面爆發的問題或故障，一定是整體技術架構中存在問題，割裂兩者，單純地看技術架構或運維都是毫無意義的。

但是，我們在絕大多數情況下，忽略了這個隱藏在軟體生命週期中真正的運維範疇，而是簡單直接地從軟體生命週期分段的角度，生硬地給開發和運維劃定了一條界限。

也正是這樣一個簡單直接的界限劃定，讓我們將運維僅僅侷限在了伺服器維護、網路裝置配置、軟體安裝維護這些最末端的職責上，而我們又期望運維這個角色能夠掌控全域性，不要在這個階段出現任何問題。這就很像臨渴而掘井，是不現實的。

運維思路上的轉變，遠比單純提升運維技術更有價值，而運維真正的價值應該跟研發團隊保持一致，真正聚焦到效率、穩定和成本上來。

運維與軟件開發過程

本節從軟體專案開發的角度，對運維如何支撐開發和專案過程，再詳細說明一下。

如上圖，通常一個軟體專案的過程可以分成三個部分：技術、過程和基礎設施。其中，技術這條線上，專案團隊在技術leader的帶領下，明確目標，分解任務，跟進專案過程，把控專案節奏；過程這條線，讓團隊在某一個軟件開發方法的指導下，一步一步把軟體做出來的過程；而基礎設施這條線，列出了支援軟件開發過程必不可少的一些基礎設施。

我在 《如何做出使用者滿意的產品》 一文中，整理過敏捷開發方法的一些思想，其中的「提早整合、頻繁整合」、「提早實現自動化部署」、「使用短迭代，增量釋出」等要求，都是軟件開發中， 基礎設施 這部分要承擔的工作，按上文說法，都是運維。

有一個說法是，軟件開發中，增加一個功能特性的成本，並不單單是為這些功能編碼所花費的時間，還應該包含對將來擴充套件所設定的障礙。如果基礎設施不到位，會給功能開發帶來很多額外的障礙，而大部分這種障礙都能通過加強運維的投入而避免的。

所以，運維不到位，開發也不會順利。

運維與微服務

現在微服務大熱，很多團隊都開始號稱自己採用微服務架構。而微服務架構，對運維提出了更高的要求。

微服務架構使得架構的複雜度大大增加，對運維團隊而言，維護微服務架構的系統，不僅要維護其業務應用，還要維護支撐起業務應用的基礎設施，隨著系統規模的增大，使用者的增加，高併發、高可用等要求提上日程後，這兩方面內容會交織在一起趨於更加複雜，這種複雜度靠人力是難以掌控和管理的，為後續的交付和線上運維帶來了極大的難度和挑戰。 所以，微服務架構要求運維打造一套工具支撐體系來支援相關工作，架構本身也要在支援業務功能之外，包含開發、交付和線上運維階段所需的基礎維護能力。比如服務上下線、路由策略調整、併發數動態調整、功能開關、訪問 ACL 控制、異常熔斷和旁路、呼叫關係和服務質量日誌輸出等等，這些在架構設計時要考慮，而其實現是在運維工具和服務平臺上。

微服務架構模式下，運維已經成為整體技術架構體系中必不可少的一部分，而且與微服務架構相關的體系是緊密相連不可拆分的。

微服務架構模式下的運維思路一定要轉變，一定要將視角轉換到應用這個維度，從一開始就要統一規劃，從一開始就要將架構、開發和運維的工作拉通了去看，這一點是與傳統運維的思路完全不同的。

注

本文的引用內容，均來自極客時間的專欄《趙成的運維體系管理課》。