王關勝
美圖運維總監
我在運維這個領域做了十多年，2011 年我從海南去到了北京新浪微博，2016年從微博離開。
在微博六年多時間裡，我幾乎見證了微博整個發展，當時主要是做微博的運維，微博整個後端服務的建設以及各種運維的經驗都是親身經歷，像微博我剛開始去的時候只有一百多臺服務器，走的時候是幾萬臺服務器，發展還是非常迅猛的。2016年底我就去了美圖，主要負責美圖的運維，例如應用運維、大數據運維，DBA，監控、成本、質量。
我今天分享的主題是“基於DevOps打造高效運維團隊”。分享的主題主要四個方面：
第一，講一下美圖DevOps的實踐；
第二，從關注效能的角度講如何打造高效的運維團隊；
第三，持續集成實踐；
第四，如何做好監控體系建設；
一. 美圖的 DevOps 實踐
我們首先看一些場景，傳統產品交互模式如下圖中所看的這樣，基本上從產品開發、測試、最終上線的整個流程的交互，安全團隊會在開發階段就介入做各種評估，一直到測試上線估，包括安全體系落地等。其實當 DevOps 加入了安全這個領域，整體會變的比較複雜。
1.1 傳統模式的特點
傳統模式如果沒有比較好的高效的方式，這種交付整個過程間的流轉、時間會非常長。它的特點是什麼？
第一個就是非自動化，我們看到部門之間其實是分隔的，很多東西需要相互之間溝通，而且很多標準也不一樣，環境也不一樣，很難打通鏈路上的自動化，這是很大的難點。
第二個就是迭代慢，沒有自動化的流程迭代會比較慢。
第三個是環境一致性差，團隊內部都有很多部署的標準不一樣，現在都往容器化方面去做，我們也建設了整套容器平臺，所有線上交付都通過容器鏡像標準交付。在新浪的時候是一起推進容器平臺 DCP 的建設，它是做整個容器的自動擴容，甚至和公有云打通做混合雲的體系，這些經驗也在美圖做了一些落地。
那麼新的方式我們如何做比較好？剛才說的是傳統模式的交付模式，還有一個配合模式。
從上面可以看到交付會涉及到很多的部門，很多流程和標準都不統一，這個時候就有點像植物大戰殭屍一樣，沒有統一的目標，自己所做的事情很簡單，就朝自己的方向去做，但是整體的目標是一樣的，這樣看起來沒什麼問題，實際上最大的問題就是效率的問題。
它的特點是團隊各自規劃目標，很難達成所有團隊的共識，共識非常重要。很容易存在的結果就是重複建設，這在互聯網公司非常多，幾乎稍微大一點的團隊，超過千人的團隊重複建設會非常得多。
如果不能把偏公共的東西都統一起來，這時候對人力的成本、服務器資源的成本都構成了很大的損失。
所以，公司尤其是技術的管理者有必要看到這些問題並且推進解決。
第三個特點也是非常重要的，也就是團隊之間不夠信任，像區塊鏈它最終解決的就是共識的問題，傳統的團隊也是這樣，團隊之間很難達成大家都認同的共識，這些都是一些很實在的問題。
有些 DevOps 項目，沒有二三十人的團隊是很難落地的，這樣各自來做的話，很容易項目做著做著就夭折了，這些特點在每個公司都是很常見的。
1.2 DevOps 能解決什麼?
如何解決這些核心問題，回到DevOps本身，DevOps能夠解決什麼問題？
兩個維度來看，第一個維度就是關注組織，也就是我們的組織結構。我們的團隊如何協同？如何配合？這個層面如果有比較好的方式，其實是可以提升效率的。
其次就是關注整個軟件交付生命週期，從產品的想法以及線下落地和最終維護，產品如何達到很快、很高效的模式？其實 DevOps 就是解決這兩個問題，這兩個問題也是引入一些思想的關鍵。
但是在整個行業裡，你跟一百個人交流，甚至跟非常熟悉的人交流觀點都是不一樣的，很多人理解的思路、理解的方式，或者所切入的經驗等等都不一樣，所以理解也都是不一樣的。
我也關注 DevOps 很久了，在網上交流的過程中也學到了很多東西，我個人目前來看有兩方面東西是非常好的。
第一方面臺灣有一個人叫陳正瑋，這個人分享了非常多的 DevOps 體系，他的思維和理念都非常超前，大家可以看他對 DevOps 的理解。
國內目前做的比較好的就是 GOPS 大會主辦方，他們在 DevOps 標準這一塊做的比較好，並且很成體系，而且發佈了很多的標準也是在指導整個行業去朝著更高效的方式去做。
那麼美圖到底是怎麼應用 DevOps 的理念讓團隊更高效呢？我們也是從剛才講到的兩個點去做。
第一個點就是從團隊效能。比如說我們同組織結構上如何調整會比較好？什麼樣的組織結構以什麼樣的模式適合推行 DevOps，有運維開發能力的就是 DevOps？肯定不是。
其次就是如何和開發更好的結合。包括測試以及安全團隊，這就是從組織結構和敏捷兩個方面去做。其次我們 DevOps 具體實踐過程中，怎麼在項目中去落地？
二. 打造高效團隊
如何提升團隊的效能，我從三個結構上來講：
第一，組織結構；
-
第二，敏捷團隊；
第三，工程師文化；
2.1 組織結構
組織結構是比較重要的，我看了很多互聯網公司以及傳統公司的組織結構，無外乎是這麼幾種。
第一張圖是層次很清晰的結構，第二張圖是類似於騰訊BG+BU這種，各個團隊都有自己的技術產品線，BG有產品、有測試、有運維。
其實這兩種方式每個公司都有自己所謂的基因，這些基因有時候會決定它所在公司的組織結構，並沒有哪個好哪個不好。
從 DevOps 這一塊，我們覺得比較好的理念就是這種組織結構，就是把不同角色的人聚集在一起做事，這個東西很重要。
第一個強調扁平，很多東西不需要太複雜。其次能把所有人、所有團隊的目標達成一致。這個東西怎麼解決呢？你不可能一下子大變，把所有組織結構調整在一起。
我們有一種方式，就是關注如何提升團隊的執行力，我們從這個維度切入，我們怎麼做呢？可以看一下我們的方式很簡單，就是採用虛擬化的方式去做。
我們把一個大的項目做成、落地並且推進，而且推進的很好，這樣的團隊結構非常重要，就是虛擬化的團隊。
我們很多團隊都是虛擬化團隊在做，你在管理上是隸屬於開發團隊的，但是項目上會有PMO的介入，PMO會把這個團隊打造成虛擬團隊，所有的人相當於在項目上是同等彙報的，既向團隊彙報，也會向項目彙報，而且每週也會有敏捷上的推進。
比如說我們要推進容器化的東西，這時候它涉及到的職能是非常多的，這些職能都拉進團隊在做，而且還會給予預期，以後成果也是共享。所以這個東西也很重要，你在共識上要達到一致的一點是比較好的。
我們現在都在虛擬團隊上做，虛擬團隊我們會有股東的結構，就相當於各個團隊的股東會參與一些決策，剩下就是各個團隊涉及到的非常核心的人員參與進來做一些事情。
從公司層面我們也做了比較大的調整，之前我們的工作組織結構非常簡化，比較散，沒有比較好的結構。
我們在去年的時候也是參考了騰訊的組織結構，把所有的產品從公司戰略上去做BG、BU的模式。從公司實體層面是BG、BU的模式，從公司項目上是虛擬化團隊，基本上由這些維度調整我們公司主力結構，相對來說在這種環境下比較好落地，而且讓我們很多項目能夠高效的運轉。
2.2 敏捷團隊
產品從開發到測試再到運營以及線上都採用敏捷性的管理，我們每個產品都會有PMOGL在做，我們的任務都是採用Kaban管理。
我們海外的項目，它推進項目的就是敏捷化的管理，技術也會參與到產品決策中來，以前更多的是產品提一個需求我就完成了，什麼時候排期就 OK了，這種產品就要求技術前期就探討如何做好這些功能，這裡面有沒有新的思考或者功能點？使用看板可以縮短整個前期的溝通，總結出來產品要做的事情，在一些相關的討論上也都是主要的人在做，每天會形成任務的列表。
根據這樣的方式來做，我們在效率上的提升非常明顯。具體在做的過程中肯定需要配套一些工具，因為光有模式和思路還不行，工具用什麼在做？
我們分為兩類工具，一類是跨大部門的工具，主要是Confluence，所有公司都會用這個，這也是運維來部署、由高層支持。在項目內部我們還會有更輕量級的工具，比如說Slack、Trello。由PMO跟進整體的進度，整體效率就會提升很多。
這些基本能夠解決讓我們之前的項目很高效的運轉，我們從組織結構、敏捷、工具、文化、思路各個方面去切入，去提升我們產品的交付。
2.3 工程師文化
我們要求的不止是運維內部的項目高效，更多是想看技術怎麼樣對產品有幫助，看的層面會更高、更大，從產品的交付流程來看，這個是我覺得非常重要的。這其實也有自己的思路，每個公司有自己的情況。在公司內部有這樣的環境其實也可以按照這樣的方式去做。
另外我們會有各種塑造工程師文化的活動，比如說我們會定期有美圖互聯網沙龍，還有很多人到外面去做分享等，內部有各種獎勵機制，寫文章、寫分享體現你的價值，個人在自己能力的提升上也能為公司去贏得一些東西，這都是雙向的東西。
在公司內部很多技術團，比如說測試、運維、產品、開發，這裡會有很多問題，比如說如何量化？
工程師文化是比較虛的東西，這裡我們提出一個新的東西叫“故障文化”。
產品交付的過程當中永遠高效會產生問題和故障，這時候通過這樣的維度去做是可以的，我們制定了非常詳細的故障管理制度，這個制度可以評估到每一個問題和故障。
每一個問題最終怎麼樣去提前發現問題？解決問題？在問題之後怎麼樣去跟進並且改進，改進有時間點、人，這套體系框住了問題之前、問題之後涉及到的人，怎麼樣去考核和關注。
前面說到我們會定非常詳細的故障制度，故障制度其中有一個點就是評估每一個問題和故障。
怎麼評估？比如說影響維度、影響時長、影響比例、影響用戶數、問題所處的時間段，問題所處的產品是核心功能還是非核心功能等等，我們從五六個維度做核心評估，會有一個公式，比如說會影響什麼，這個公式會對於每個問題和故障上會有一個分值，這個分值出來之後就可以評估，然後所有的東西都可以考核到團隊，它是非常等量化、非常數據化的評估。
每一個問題發生的時候會有故障小組的人員跟進協調故障，在之後會形成詳細的故障報告，這包含了一些要素。不要看非常簡單，實際上它的體系非常豐富，它涵蓋的面都有。
這裡還有一些實際的問題，比如說每個產品評估標準是不是不一樣？這裡也做了通用評估和自定義評估，通用評估提到了通用維度的評估，還有些產品把金錢的維度納入了進來。
所以我們在越來越細的過程中，也會深入每個產品，每個產品都會制定自己的故障評估制度，這個故障之後會有公式，公式計算出分值，所以這套體系制度非常重要，A級故障、B級故障、C級故障多少個，再做月報、半年報的分析。
這是故障制度裡的東西，我們強調的是故障文化，你出問題不用怕，這時候你監控層面做的比較好的話，能提前監控和解決也是OK的。
故障文化我們通過培訓來做，你不用害怕，該發生的問題發生也OK，我們更多強調後面如何改進，比如說這個故障發生了就列出來三個部門要改進什麼樣的東西，隨著改進越來越多，整個服務的體系以及穩定性會得到極大的提升，這整體收益是非常大的，一方面有有效的制度，一方面有故障文化。
三. 持續集成實踐
前面講到了從團隊組織結構包括一些敏捷和文化上，怎麼樣讓我們團隊保持很高效的運轉，而且也有數據化、量化的評估，這些東西非常重要。在這種團隊結構或者氛圍下我們如何做項目落地？
美圖大家熟知的產品就像美顏像機、美圖秀秀、美圖手機。我們的產品是非常多的，從硬件產品、軟件產品、電商、PC端、移動端，我們在海外和國內都有很大的用戶量，以前人們號稱美圖有十億的用戶，整體我們的產品是非常豐富的，覆蓋的國家也是非常廣的。
在這麼多的產品矩陣裡，我們會有一個問題，我們除了核心業務之外，業務非常多，但是量不是非常大。
這個時候會造成一個問題，我們很難用一套持續集成完成所有的需求，所以我們也做了一些退步和思考，我們把業務做了切分，我們物理機基於部署往容器裡遷，但是遷的過程中還有一部分服務還是跑在物理機上，我們從物理機、容器、公有云在做。
物理機是基於Jekins Pipeline，容器基於Gitlab ci。首先看一下物理機，物理機之前有研發基於Jenkins Pipeline 一體化。我們現在要求這些東西都以接口流通，比如說開發代碼、集成測試以及到線上的環境等。
整體對於交付是統一的，這裡我們分為五套環境。
第一個Dev環境，就是開發自己維護的環境。Dev-Common開發的環境可能依賴一些公共的服務，這些公共環境會由運維部署一套Dev公共服務的東西，這個環境需要穩定，就叫Dev-Common。
前面兩個環境解決開發和自測。自測完了之後會跑入Pre 環境，最後就是Beta和Release，我們把五類完全打通通過自動化方式去運轉。支持的發佈模式也就這幾種。
這是傳統基於物理機的模式，我們從2017年開始做了差不多快大半年了，整個平臺基於K8S，容器平臺物理機的模式還是需要的。
第二部分基於容器的模式，我們基於K8S封裝了一套複雜的系統，這套系統也會分這樣的環境。我們所在的事業部叫做美圖雲事業部，我們在內部做私有云的模式，根據K8S做的。它主要就是這樣的結構。
在這裡可以看一下大概的頁面情況，每一個服務所有的部署和功能都是這樣的，容器是基於K8S。容器裡也是可以的，我們把K8S所有的接口都封裝起來，做出來的平臺比K8S自帶的東西好用很多。
在容器這個環境下，怎麼做交付？這一塊要跟測試達成一致的意見，都是基於Gitlab+CI這樣的模式，它也是相對比較成熟的模式。
除了這種我們在海外也有很多的業務量，基本上都是用 DevOps。那麼AWS跟國內的 IDC 如何互通？通過拉通專線互通，然後能用內部IDC的工具棧，直接低成本接入使用；不能用的，我們直接用雲上自己的工具棧，雲上的工具棧是比較豐富的，基本能完成各項DevOps需求。
三. 監控體系建設
最後介紹一下監控體系，因為我們有物理機、容器以及雲和各種各樣的場景，我們的環境非常多，一開始我們哪裡有需求，監控團隊就實現，最後我們會發現有很多套工具出來了，很難統一，並且維護成本也比較高，所以我們設計成了美圖一體化監控。
底層有指標採集層和存儲層。我們根據你的監控需求來看適合哪個層級就用哪個，這些成果要對外去展示，也就是說包括指標的訪問還有數據代理，還有基於指標的數據分析。
這上面的應用畫像怎麼做？智能運維怎麼做？要有一套這樣的設計模式或者設計思路，你在做監控團隊以及開發時，要去思考這樣的東西，整體不能跨過這個東西。具體對接到我們的業務模式，後端的業務API、後端的資源、大數據、存儲等。
美圖我們在用戶端也做了很多，比如說一個APP都是接入CDN的，之前做的過程中會發現CDN的覆蓋過程中經常會有邊緣節點的問題，我們做了非常多的APM去檢測，有了數據之後就可以做融合調度；
一個業務在某個CDN節點覆蓋，某個運營商和地區，當有問題的時候我們可以調度到另外一家CDN，而且要跟CDN廠商溝通好，融合調度之類的模式，避免自動切換失效問題，這樣APP看起來問題會變少很多。這是我們整體很宏觀的結構。
基本是上從用戶端到服務端去看如何做好監控。拆開來看就是用戶端要檢測的數據，像美拍都是短視頻直播類的，它的監控比較多，除了用戶端的監控還要監控流媒體的東西，我們有質量調度還要做CDN監控和打分，這些東西怎麼做？
我們之前用的第三方APM系統，當時博睿和聽雲都有用過，現在完全可以自研。流媒體及CDN打分機制都是自研來做的，APM也是一樣的。
這些維度都可以覆蓋到用戶端的所有問題，這時候團隊可以真正打造成從用戶團隊思考問題，如何提升用戶體驗，這個維度很重要的。
很多運維團隊只是要完成需求的話，沒有太大的價值。當然怎麼樣想做得更多，怎麼樣讓老闆看到你的團隊有更大的價值，是有很多的思路的。
服務端的話業務層監控、服務層監控、基礎資源，它在行業裡都是非常成熟的經驗。
這裡有一個非常重要的點，我前面提到了所有的數據不管是用戶端、服務端都收集起來了，我們指標都可以看了，我們還需要在告警層面做一些事，我們接入的系統越來越多，我們的告警越來越複雜，所以我們專門做了統一的告警平臺，把所有的告警都接入這裡去，發告警都從這裡發，最終也可以發到具體的人和項目，這裡主要實現統一告警平臺，我們內部叫UAP。
它的思路很簡單，從監控的數據出來，包括老的容器和物理機的數據，這些告警信息都到統一的告警平臺裡去，要怎麼告警都有規則，包括做標準化也很重要。
最終再去基於一些用戶組、用戶等，與項目的關聯關係去報給相應的人或者團隊，每個告警還要有相應的平臺，我們要知道告警現在的狀態，告警發生了，持續了多久，告警的事件和機制是要有的，我們目前都是基於這樣的一套結構。
這也是我們借鑑 open-falcon 的思路，然後自研的一套東西。一旦有這樣的工具，就可以在更上層看問題，而且還可以和其他的東西集成，如果要沒有這些東西的話還是原有的模式，各自發各自的，相互之間就沒有關聯關係。
這個邏輯非常簡單，所有的監控告警都有對應的告警接口，所有告警的地方都按照相應的標準去發告警，這個告警會調度到我們的告警庫裡去，這裡會有相應的任務模塊，再加上規則和分析，確認告警如何去報？報給誰？由什麼樣的事件機制去做。而且它有相應的基礎平臺的人與項目關係，就可以幫助我們更好去發送告警，發送到最終的用戶，邏輯非常簡單。
在最終發送告警的時候，它收斂的維度我們會有很多方式，也會涉及到用什麼樣的方式去發。
我們用的是企業微信，這裡有很多有用的東西，比如說我們幾千臺機器都會有磁盤的問題，這個時候我們有相應處理的群在企業微信裡，這個時候作為應用運營、大數據運維都不用關心了，它會有相應的人生成工單。
但是這個東西要服務上下線的時候才會相應管理。我們支持很多告警渠道以及多種模式，最終才能做到比較好的“收斂”。
除了這些維度的收斂還要基於時間維度，這個告警是不是首次發？沒人處理是不是不重要？這時候是不是把它組合在一起？多長時間發送一次？這個主要是講我們怎麼樣去做告警收斂和告警風暴的，相當於所有監控之上做的平臺。
另外一個維度就是可視化，我們前面可以看到我們設計思路里儘量用開源，數據可視化的東西我們儘量以Grafana的指標。
開源的工具大部分都支持，它在數據源上做改造都可以做。不管是前面提到的用戶端等所有維度都可以在上面展示，我們可以做非常多的圖譜來，這裡只是舉了一個物理機的基礎資源監控。
他們都有關心的指標和大屏，所以這些可視化非常重要。這個核心點就是怎麼樣讓這些東西統一起來，因為如果不統一的話，這些問題很難放在一起。
我今天主要分享就是這些，如何打造高效的運維團隊，更好的驅動一些公司項目的交付和落地等。未來以來，預告一下，團隊已逐步轉向 SRE 團隊的工作模式和思維方式，期待明年和大家分享如何在國內打造真正的 SRE 團隊！
說明：本文為 GOPS 全球運維大會 2018 · 上海站分享整理而成。
閱讀更多 高效運維 的文章
