相愛相殺的運維之殤：蘇寧消費金融超大規模 IT 系統 DevOps 實踐

**做者簡介**：顧黃亮，十年研發運維經驗，涵蓋基礎架構、應用架構、數據庫、DevOps，有互聯網，電商，金融從業經歷。

專一於 DevOps 在企業中的應用和落地，致力於企業智慧運維體系的打造。參加多個行業、國家標準的編寫，《開源許可證使用指南（2018）》做者之一，國標《研發運營一體化（DEVOPS）能力成熟度模型》做者之一，《企業IT運維發展白皮書》做者之一，曾供職於航天晨光、上汽集團雲計算中心，現任蘇寧消費金融安全運維部負責人。

今天跟你們分享的一個主題，就是蘇寧消費金融超大規模IT系統DevOps的落地實踐。下面分四個部分：

一、DevOps的年輪記
二、相愛相殺的運維之殤

三、運維生態之旅

四、咱們在落地建成中的一些痛點

1、DevOps的年輪記-我眼中的DevOps

---

其實DevOps這個概念到如今已經有十多年的歷史了，這個概念一開始起源於傳統行業，後來是被IT行業採納，把它的先進理念和方法論引用過來。

伴隨着DevOps理念在中國多年的推動，我從一開始接觸DevOps，到目前DevOps在落地的過程當中，我爲它總結了一句話，總結叫「倍道而進」。這句話是三國演義裏的，它體現出來一個核心的思想，那就是不斷的加快，從DevOps的官方的含義當中，它的核心思想就是提升組織級的效率和質量。

通過十年的發展，到了相對而言比較成熟的階段，準確的說是從三年前到如今，這一個階段，它整個的發展速度是很快的。不少人都在講」雲計算」引爆了這一切，若是沒有云計算技術的加持和助推，其實DevOps的落地推動並不像如今這兩年到三年內咱們所感受到的這麼快速。

我對它的總結，或者更貼近於這兩三年中對DevOps的發展效率來看，那就是很是快。這兩年不管是企業的對於DevOps的理解和DevOps在企業當中的落地，其實跟前面七年八年來比，它實際上是增長了不少倍的。

我眼中的 DevOps 目前有三個。

第一個是 DevOps 是什麼？

「迴歸 DevOps 的本源，跳出三界外」，這一句話的意思是什麼？咱們看 DevOps，並非說咱們經過一篇文章，或者說經過 DevOps 在企業當中的落地某一種方式來造成一種理解。從 DevOps 的本質上來講，無非就是達成研發、運維、測試，更往外延伸一點那就是產品、項目各組織之間的協同合做的目標。

從推動到落地的過程當中來看，真正能幫你助推，幫你把 DevOps 項目來落地，除了 DevOps 涉及的各個組織體系的配合、受衆人羣的擁護之外，咱們要考慮真正最終效益的人是誰？那就是各個組織體系的上司：老闆！

因此，我對第一句迴歸 DevOps 的本源，跳出三界外，其實最根本的一個表達的方式是什麼？你要跳出 DevOps 來看 DevOps，你就會看出你原來對 DevOps 的理解，你會上升到一個新的高度，你就知道在整個的 DevOps 落地的過程當中，你須要哪些資源的一種加持。

第二個就是千人千面的 DevOps，本質是人與信息的聯姻。千人千面，其實這四個字也是從電商行業出來的，它所表達的是你跟人家談需求，尤爲你跟 DevOps 涉及的各個組織體系部門（簡稱業務側部門）談需求的時候，業務部門跟你說我須要這一個東西，經過交流或者基本的溝通給你進行一個簡單的需求畫像，你會根據這個需求去簡單的理解，畫像出來後，你跟業務方進行簡單的需求交付，他跟你說你要的這東西根本不是我想要的東西，哪怕你的功能是知足他的須要，可是他總會跟你挑出各類各樣的瑕疵或者其餘使用體驗的問題。

第三個是 DevOps 的投資回報：格局決定告終局。若是咱們正在進行 DevOps 項目推動，或者說已經具有組織級 DevOps 項目落地經驗的人來看，你作 DevOps 的核心初衷是什麼？你確定會有一個出發點，或者說以這個點做爲橫向和縱向的一個延伸方式，要看承擔 DevOps 項目的這我的的角色是什麼？是否是運維、研發或者說測試，也能夠是管理項目的項目經理、承擔需求設計的產品經理，他是否有清晰的思路，其實我以爲誰作都沒關係，誰作均可以，只要你對 DevOps 方法論有足夠清晰的思路。

以運維爲例，你確定是從CI/CD開始，也可能從CI/CD結束。從個人經驗來看，若是你的思惟僅僅從運維出發，而不從運維延伸，三個月你就作完了，你作完了之後這個項目就結束了，它能表明你的DevOps真正的就結束了嗎？錯，其實它僅僅是一個開始。

第一個咱們繼續往下走，迴歸 DevOps 的本源。

其實根本上來講 DevOps 它是到底是什麼，我相信在運維這個行業裏，對 DevOps 的理解有一種理解上的誤差，不少人對組織級的 DevOps 理解都是我開發一個系統，它具有一個 DevOps 的功能，那我把它命名叫 DevOps 系統，或者 DevOps 平臺，能夠嗎？其實也不是不能夠，可是根據 DevOps 的精神，我以爲並非很合適。

由於從 DevOps 方法論來講，它實際上是一種方法，它是一種理念，它是一種實現，它並非一個系統，並非一個平臺，它不是一類的技術，也沒有相應的一個產品。可是你能夠根據 DevOps 的方法論，開發出具有 DevOps 方法實現的工具，這樣是能夠的。

第二個 DevOps 最直接的價值，在於它可度量的價值、可延伸的價值、可迭代的價值，是基於流水線驅動的交付輸出、基於數據驅動的價值輸出。

我昨天跟牛曉玲老師聊，DevOps 在企業中的落地，它最後體現出來什麼？流程驅動，其實這一個過程是很好作的，尤爲對於傳統企業來講，是一種自然的優點，由於對於傳統企業來講，它更講究是整個流程在企業當中的貫穿。因此說你經過流程來驅動的 DevOps 是流水線，最終也是爲了達到一種交付，它是咱們狹義上理解的流水線的概念，整個的流程到最後，必需要有相應的技術的加持，因此不少人正在講我目前基於DevOps 的流水線實現，個人落地過程是否是已經快結束了？我下一步是否是到了AIOps？能夠這麼說，還早呢。

其實 AIOps 是什麼？我我的對它的理解，AIOps，當你的組織級 DevOps 已經完成落地，發現 DevOps 並不能徹底覆蓋個人需求，或者說運營、研發、測試一體化的需求，我須要對 DevOps 作一些延伸，那作的這些延伸，就是咱們如今所講的 AIOps，它是須要有 DevOps 做爲基礎，從流程驅動的基礎上實現數據驅動的價值，經過對海量數據的分析、匯聚、處理、統計、計算來覆蓋 DevOps 的短板。

想要達到這一個階段，須要什麼？數據！我須要的是海量的數據，因此又回到上面所說的，咱們在整個的流程驅動的過程當中，必然須要數據中臺的支撐，在業務的框架下，讓全部的運維數據流動起來。

經過數據的採集，個人每個節點，每一個環節，都保留不少的數據，這些數據也會反推我在 DevOps 整個的落地過程的核心效益產生，基於一些數據的加工、聚合、統計、計算，乃至後面的數據的預測，DevOps 就有了延伸，會很直接的、很天然的演變爲最後的 AIOps。因此說沒有數據的加持，DevOps和AIOps它中間始終是一個鴻溝，你是徹底是跨不過去的。

咱們繼續再回到前面價值這一塊，終究這個價值是什麼？這個價值是交付，是數據的交付，是過程的交付，是服務的交付。

下一個是千人千面的 DevOps，左邊是西遊記裏面的，師傅跟大師兄、二師兄眼中白骨精其實徹底是不同的。

我想表達的千人千面 DevOps，在領導眼中，他須要提升組織級的效能和質量，其實他不關心這裏的細節，我只要有一個工具，有一種方法，能幫我把整個組織級的效能和質量提高，這是領導所須要的。

運維眼中是什麼？你不要再跟我對接底層的服務，我將個人能力經過服務輸出，提供平臺來給你使用，我將一部分可控的權限下發，由你研發和測試來管理。因此對於我運維來講，經過相關的能力域的輸出，再也不是工程師即服務，個人平臺出了問題你過來再找我，個人服務出了問題你也能夠過來找我。

其實這一個階段我感觸很深，我也是從研發過來的，在我作研發工程師的時候，我對運維的理解什麼？這一塊出了問題，我自己環境是好的，我設置的環境是好的，你生產環境出了問題你本身過去查，不關個人事兒，是你運維的事兒，本質上仍是價值輸出還不夠完美，人與人對接，總歸是有不少的問題。

經過上面的一些案例，你看到運維那種很茫然的眼神，你是否是產生了一種快感？可是對運維來講，確是很苦惱的。我從研發轉到運維之後遇到一件事，研發跟我講，昨天我有某一個系統 CPU 飆升100%，你趕忙給我查，這是你這邊的問題，而後我把整個堆棧殺出來，定位到包、定位到方法，研發傻眼了。

對於互聯網行業來講，運維和測試具有代碼編寫和走讀的技能已經比較常見了，在傳統行業來講這種案例仍是比較少的，其實這種時候運維是揚眉吐氣的。

其實我們剛纔只不過講了一個關於研發和運維的小故事，在研發眼中，他真正想作什麼呢？他說我只想作研發，我只想寫代碼，其它亂七八糟的事兒我沒有也沒有精力，其實這個是真正的研發的寫照，尤爲是初中級的研發工程師，從一開始研發所覆蓋的職責一直到如今，基於權責和組織架構的關係，一直是有這樣的一個問題的，這也是狹義上研發和運維的一些恩怨情仇。

從測試的眼中，那我終於拿質量做爲抓手，其實準確來講，如今不少的企業如今都沒有把質量安全以數據做爲可度量的方式，你們注意，仍是以那種比較偏原始的或者說半自動化的。從一開始功能性的測試，再到安全測試再到各個環節的測試覆蓋率、成功率，跟如今自動化測試來講，它僅僅是達到了半自動化，只是覆蓋到案例的部分，它並無相對全面的數據來落地，以整個度量的方式做爲一種抓手，來提高整個的項目或者說版本的質量。

在項目眼裏，其實項目經理最關心的是這個項目全生命週期的管理，只要我把這個環節控好，映射到整個研發的環節、運維的環節、需求的環節和測試的環節，只要大的問題沒有，小問題無傷大雅，基於項目的管理來講相對而言仍是比較簡單的。

因此，在整個 DevOps 的加持下，把整個全生命週期，各個環節的數據來落地下來，這是項目經理最喜歡看到的。

產品眼中，產品更關心的是什麼？其實產品經理只想把這些需求梳理好、設計好，那下面就是編碼階段。可是你發如今這個過程中，個人需求有多少個？我涉及到提需求的一些干係部門，哪些需求是正常的，哪些是屬於加塞的，哪些是須要調整的，哪些是仍是不肯定的，方便後面考量，針對項目後評價階段針對需求的一些度量。

這些需求跟個人組織，跟我現有研發組織、團隊，研發的人員，更涉及到研發團隊工程師所分配的任務，個人需求所拆分的關聯繫統，經過數據上關聯來串聯數據鏈，其實在不少的組織或者在不少企業是不具有這樣的狀況，因此這種狀況下就須要靠人治，而不是靠系統來治理。

在 DevOps 的負責人眼中，他的感受是什麼？其實領導、測試、運維、研發或者說項目經理、產品經理，都是需求方，我是整個需求來轉化到服務，進而推廣、使用、落地。可是你這麼多，也不能量化的需求，須要造成以項目維度的流水線，有須要足夠的數據支撐來分析決策，讓我來怎麼作？我也不知道怎麼作。

因此說領導講的都是對的，可是我好難。雖然說難還得往下作，因此我就講一開始在整個 DevOps 落地的過程中，要找準一個點，確定要 get 到一個最急迫的點，如何選擇這個點，第一，你考慮到需求提煉，第二領導是否對你的點感興趣。

若是領導說這個事兒你要作，那我就是以領導爲準，可是領導通常講的東西都是很泛，他會告訴你他須要什麼，可是他不會幫你分解，須要你本身來分解，你只能經過研發、運維、測試、產品、項目當中的一個你們都比較關注的一個點，好比提高效率，提升質量，打通團隊的牆，才能繼續以它爲開始，經過橫向、縱向的方式進行擴張。

千人一面仍是千人千面呢？這個圖對於研發來講有很深的感觸，當用戶跟你要一瓶水的時候，他是真的跟要一瓶水嗎？不是，他要的是西瓜，可是他只會跟你說他渴了，其實在咱們作DevOps的過程中，我相信你們也會有相關的一些體會。

如今咱們就回到下一個問題，格局決定結局。

咱們作 DevOps 以前須要思考一些問題，潛在用戶是誰？DevOps 的項目推廣以後，個人 DevOps 的用戶是誰？第二個，他在哪裏，他日常的喜愛是什麼？他討厭什麼？他想要什麼？通常他對個人 DevOps 的產品哪些功能、模塊感興趣，我如今作的產品是否是知足他的需求？

我對接的這些用戶，好比ABCDE，我這五大類的用戶，他天天的工做是什麼，他的理想工做是什麼？我跟他的交集通常是什麼？接下來梳理清楚以後，我須要怎麼作，我要什麼資源，個人資源從哪來？它裏面其實最核心的一個東西，我要找準個人用戶，我不可能把我全部的用戶歸入到我整個的服務體系當中，那我就要在整個的項目進行到一半的時候，選擇項目推廣裂變的方式的時候，把我核心的用戶的需求找準落地，以他做爲延伸，向四周去拓展。

咱們又回到了他是誰，基於整個的用戶體驗的方法論來講，找準這個他，真的是很不容易，因此咱們在找他的時候，儘量在咱們的周圍找這個他，並且必定要找準正確的他。對於咱們整個的 DevOps 在落地開始，或者 DevOps 項目在咱們的需求整理，在即將進入開發，或者說在我找準整個用戶羣，整個用戶覆蓋面這些問題以前，那咱們要思考一下這個他是否可以對DevOps推廣過程當中可以加持。

第一個就是很厲害的，英明神武的領導，這個是他是推廣中最重要的。第二個就是測試路人甲，頭髮稀疏的寫JAVA的，還有一個就是通宵的運維背鍋工程師、得罪不起的項目經理，漂亮的產品經理。因此你只要把這些他所有覆蓋到你整個DevOps的受衆人羣裏去，那你纔有可能經過這些他，映射到相應的環節，在這些環節中落地了關於他的各類各樣的數據，才能貫穿整個全生命週期，而這些數據的整合和處理最終是推進整個環節的優化和提高。

2、相愛相殺的運營之殤

---

我在作這一頁的PPT以前，我跟蕭幫主討論一下，我說能不能這樣，我把個人想法跟你說一下，經過短信的方式，而後你按照個人想法你把這個羅列給我，我要截個圖，作到PPT裏。而後蕭幫主跟我說，說他的角色是什麼，我說你有兩個角色，你第一個角色是研發，第二個角色是運維，蕭幫主說好吧，那就這麼幹吧。

第一個，從研發的角度來講，當你的團隊剛剛歸入整個 DevOps 體系的時候，你確定是被約束的，由於剛開始進入 DevOps 階段你仍是屬於以流程爲驅動的工做方式，在這個環境當中，個人工做老是被流程所左右，我除了寫代碼我還要關注質量測試和發佈環境。

在流程中我要身兼多職，這樣讓個人技術反而不精。其實這一句話是什麼意思？當 DevOps 在落地的過程當中，最剛開始剛落地，或者涉及到整個的研發側的時候，研發的工做量真的是少了嗎？不是，是多了，由於那個時候研發也不知道怎麼辦。

因此，在這一個階段，剛纔賢傑老師也講了，在剛開始剛推的時候，做爲一個研發，第一我要寫個人代碼，第二我還要按照你的規則來作各類各樣的事兒，在這期間出了各類各樣的問題，或者我在某一個環節卡住的時候還要須要其餘團隊或組織的幫助。

第二個，個人價值在於代碼，我還要不斷的充電，我還要跟上 DevOps 龐大的知識領域，我須要在個人流程框架內活動。

其實這一段的話它是上一段話整個的延伸，其實研發的理想化的對於普通的研發工程師來講，對於業務研發，編碼是研發工程師的本職工做，具有一個成熟的編碼環境，具有代碼倉庫，具有相關必需要有的權限，我在個人權限框架以內來活動，而最終的需求僅僅是在編碼的相關權責內，包括編碼、聯調和基本的測試，所以代碼出了問題研發承擔，那其它的問題的歸屬是值得商榷的，這應該是研發工程師最簡單的一種想法。可是出了問題總要有人來承擔。基於運維的出發點，僅僅只提供了資源的輸出，個人資源沒有問題，理論上講我也不會背這些鍋，那最後的鍋應該由誰來背呢？

這一點真的是很關鍵，裏面它有一個詞咱們須要關注一下，就是流程的框架，理論上講流程的框架分爲兩塊，第一種是個人流程的流動，我走到哪一步，哪個節點出了問題，那這就是誰的責任。

第二個節點的邊界，脫離了個人節點，或者即將進入到你的節點，那這一部分出了問題那怎麼辦呢？其實我以爲這一部分問題是共擔的，你們都有責任，因此說咱們的 DevOps 在推動的進程當中，是責任要共享，問題要共享，而KPI是不須要共享的，這個是相關團隊的負責人最須要考慮的一個問題。

接下來，回到運維這個角色。在截這個圖以前，我說蕭老闆，我們到了運維環節，有點傷感，你先發一個紅包，而後蕭老闆還比較給面子，發了一個紅包。

第一句話先不看，咱們再看第二句話，這種狀況我以爲絕大多數的人都會遇到這樣的一個問題。接到產品之後，或者從整個的交付週期來看，交付的環節到了運維的環節，整個的運維部門每一個人的心中都充滿了恐懼，對於項目或者軟件，根本不瞭解即將出現什麼問題，我只負責部署，出了問題我也不知道。

因此這個狀況該怎麼辦，對於項目的整個狀況，項目背景是什麼，開發過程有沒有問題，具體架構是什麼，具有高可靠高可用嗎，都是疑問。對於開發部門來講，須要開發這個新的產品，而這款產品須要很新、很炫的一個技術來保證客戶全部的需求，從而給公司帶來百萬美圓的利潤，而這個產品要求採用最新的技術和運行的平臺，還得立刻進行交付。

其實這種狀況我相信不少公司都遇到了，老闆說我這個項目半個月就要交付，我無論IT部門是什麼樣的狀況，你趕忙給我開發出來，趕忙上線。因此，對於研發的團隊來講，這個項目須要我學習新的的框架、平臺，那我就趕忙學。我學完之後，以代碼的方式來實現，不考慮除了業務之外的需求，好比高可用高可靠的設計，測了沒有問題之後，趕忙交付上線。

因此，通過一段時間之後，如願完成了任務，他們把本身的交付物一股腦的甩給運維部門，後者尚未徹底接手，研發部門已經火燒眉毛的進行了慶功宴，到最後運維人員心中充滿了恐懼。只能祈禱這個項目到最後，給公司帶來必定的利潤之後，我這個產品不會出問題，徹底在賭運氣，一旦出了問題運維徹底是很懵的，又回到救火隊員KPI的平常。

敏捷的開發，頻繁的交付，在這一個階段不少人就說了，你有自動化的迴歸和自動化的交付，這個階段處在咱們沒有DevOps的時候，或者說還處在自動化和平臺化實現以前。

前段時間咱們跟信通院曉玲老師編寫企業IT運維發展白皮書過程當中，討論過這個問題，根據國家統計局的相關數據分析統計，工商註冊的除了小微企業之外的其它企業，互聯網行業和信息化水平較高的企業佔比不到8%，在這8%的企業當中還有一部分才進入的腳本化運維的階段，更多的企業並無達到自動化迴歸和自動化交付的這一個階段。

能夠這麼說，今天參加這個大會的與會者，更多的來自處在信息化水平比較高階段的企業，咱們接觸 DevOps 時間比較長，或者已經進入這個領域。研發、運維、測試相應的水平都處在比較高的水平，其實你發現還有一大半的兄弟尚處於救火的狀態，也時常遇到交付過程當中那種茫然、不自信和恐懼的狀況。

第二個，上線的失敗，快速的回滾。問題來了，你整個的回滾的方案你測過嗎？快速的擴容、快速的響應，你在架構設計的過程當中是否有考慮過服務發現嗎？其實這塊所有是問題。系統的高可用，你的優雅的降級有嗎？整個快速故障的告警，其實目前對於如今的絕大多數企業來講，系統層面的告警有，可是個人接口和業務層面的告警怎麼來實現？

按照我所在的行業來舉例，一般會遇到不少的問題，整個業務方過來跟我說你目前的系統有沒有問題？我看了一個我一個告警沒有，整個系統都是很正常的，可是在業務端，成功率已經下滑到一個比較高的水位了，可能的緣由是業務側的人員他配錯了一個參數鎖致使的。可是對於IT來講，我又想到 IT 的價值這個話題，對於業務驅動的企業來講，IT 的價值僅僅是支撐企業業務的發展。

回到問題自己，我認爲我已經作的很好了，我以爲這個既不是研發的代碼出了問題，也不是系統宕機致使的問題，我都已經交付給你了，業務方在使用過程當中出了問題。對於IT來講你這個問題跟我有關係嗎？徹底是你本身的問題，可是對於業務方和BOSS來講，基於問題的告警是否覆蓋到業務這個環節，由於監控的責任部門是IT部門，出了問題你就得承擔。這個問題就來了，這一塊到底應該怎麼來作呢？確實是很難的一個東西。

接下來是快速故障的定位，其實如今不少的公司已經實現了全鏈路的監控，經過同一個框架和同一個協議，將一個惟一的標識打到請求報文中，從上游到下游，順序的往下走，因此這一塊咱們作到了基於全鏈路的貫穿。我跟不少人溝通交流，說大家在整個的日誌平臺當中，你採集全部日誌嗎？你不對日誌進行分析嗎？基於鏈路的日誌分析怎麼作？他們都說我也不知道怎麼分析，這些零零碎碎的日誌不能有效的貫穿。

當一個系統內部的接口調用或者跨系統的調用，乃至微服務的架構，那須要作不少準備工做，須要作服務調用治理，須要作鏈路的治理，根據梳理的步驟，才能基本達到調用鏈路大概是什麼樣子的，並且在一個很長的調用鏈路中體現核心的調用節點更加困難。因此這個也是目前咱們在整個的 DevOps 推動過程中來遇到的一個很嚴重的問題，耗費了不少的時間。

快速的進行故障的恢復，這一步其實跟運維又是強相關了。根據墨菲定律，當我要作出一個決定的時候，每每是錯的，其實最根本的、最好的一種解決的方式是重啓。我以爲這一段話不少人也一般都遇到了，第一個角色是運維，第二個角色是研發，這款優秀的產品在目前底層的平臺上沒法運行，由於這個平臺太老了，研發說這不是個人錯，個人代碼很是完美，那是你的事兒。

第二個，這款產品的體系結構跟咱們的模型不匹配，研發說大家運維部門比較笨，大家不懂技術，大家爲何不能及時的更新技術，爲何大家這麼落伍，由於對於研發來講，他的職業發展的規劃與運維是不多有關聯的，好比說研發團隊的leader，抑或是架構師，也能夠轉型成爲某個業務線的產品經理，不多有研發轉型作運維。因此不少的研發考慮問題相對而言比較片面，個人理解是南轅北轍，不是異曲同工。

而對於運維來講，我轉研發很難，我要乾的仍是運維，那問題就來了，研發他懂運維嗎？他其實不必定對，可是你運維你要懂研發嗎？你要必須懂，你要是不懂那你就繼續背鍋，當好背鍋俠。

說到這裏 DevOps 終於來了，它從新定義了組織、流程和技術的關係，它從新定義了誰跟誰一塊兒工做，和誰如何共同的工做，它致力於把不一樣的部門召集到一塊兒來共同解決問題，這樣的工做環境實際上是咱們最求之不得的，或者說打破組織和組織之間的牆最佳方式，它就是從組織級來作這些事，而不是從人、從項目或者說從一個階段來開展，它是一種全局解決方案的體現。

3、運維生態之旅

---

下面一個歡迎進入運維生態之旅，其實剛纔講了這麼多跟你們都沒有講技術，更多的是對DevOps理念的一些梳理，在第三大類跟你們講一下，DevOps在咱們企業的整個的落地過程當中，咱們是怎麼作的，其實構建運維生態的有幾種辦法：

第一：以整個項目的生命週期的數據爲基準來構造整個的運維生態。
第二：以資源數據爲基礎，其實這一塊應該變現的一目瞭然，就以CMDB爲基準。
第三：以交付數據爲基準，通俗來講，是以CICD爲出發點。
第四：以監控數據爲基準，基於監控數據的落地、分析、關聯，橫向關聯繫統、業務、基礎架構，縱向關聯團隊、組織、人員、項目。通常來講監控有兩種方式，一個NPM，一個是APM，一個是從報文的方式，一個從日誌的方式，一個是從前日後順，一個是從後往前推。

當你在推動的過程當中，你涉及到各類數據的聚合、數據的延伸，因此說從監控出發也是構成運維生態的方法之一。咱們公司是選擇採用以項目週期爲基準的一個流水線，經過運維行業屢次的討論和溝通，從CICD的角度來推動，從軟件的交付延伸到有價值的項目交付，這個是運維所但願的。

還有一種出發點是基於整個的項目的管理，基於項目數據流動的頂層設計方法，從最開始的需求的管理到最後項目的上線。還有一種方法，若是是研發很迫切，你從哪開始推？那就是環境的準備、代碼的託管，若是是測試很迫切，你確定是從整個的測試的自動化進行推動。針對蘇寧消費金融來講，咱們的出發點有兩個需求，一是提高組織級的效能和質量，而是以項目的維度，貫穿項目的交付環節，不斷的優化和提高。從項目的開始、項目的立項、從需求的管理，基礎架構總體資源的輸出，而後再到編碼過程，聯調後進入CICD階段，再同步到測試的階段，這幾個過程可能會有前後順序，也可能並行，一切以項目的須要，能夠某一個團隊先行，也能夠齊頭並進，都是能夠的。

我前面梳理了不少的一些流程跟組織跟人的關係，上線之後，經過監控的數據，關聯到業務的場景和經營層面的數據，再反推到項目，或反推到某個需求投入的資源，能夠斷定項目上線之後，成功仍是失敗，或者說項目過程當中的管控、項目結果的判斷，有沒有優化的一個空間。靠什麼數據來度量？靠整個基於系統覆蓋業務的監控，涉及到不少系統級的、業務級的監控，我能夠跟項目的需求關聯到一塊兒。

其實這張圖看的也比較多，從整個的以流程的驅動方式轉到以數據驅動的方式，讓整個的數據流動起來。其實這一塊不光是運維的數據，涉及到不少應用的數據、整個資產的數據、整個監控的數據。驅動的模式變得愈來愈有說服力，數據落地和流動，關聯性愈來愈多，覆蓋率和受衆人羣也不斷的在增長，數據使用已經從IT推廣到這個公司，這與DevOps的組織級的定位是不謀而合的。

在咱們的整個的技術運營範疇中，二級到三級它有一個最根本性的區別，那就是數據的訂閱方式，若是我是單一消費的模式，始終停留在二級，若是一份數據我被多個系統訂閱進行數據消費，就跨越到三級，真是一個題外話，對技術運營評估的企業有必定的參考意義。就是咱們對全局數據、數據流動的設計。

下面咱們再講一個更關鍵的東西，咱們在整個的 DevOps 進程中，或者平臺化以前，中間有一個很關鍵的一個步驟，這個步驟被不少人所疏忽了，我就是工具化一切，一切工具化。沒有人把 DevOps 的工具鏈是從底層寫到頂層的，一些技術特別牛的大廠除外。

基於工具化的一些思考，我這邊總結了大概有四個，第一是工具的選擇，第二是工具的價值，第三是工具的賦能，第四是工具的本質。

在當中，有一些心得跟你們分享。1、儘可能不要作到工具的二次開發，以個人經驗來看，二次開發投入的人力和物力過於龐大，並且工具的做者也有相應的優化迭代計劃。

對於工具的使用，只需使用工具的相應功能，如jenkins的交付、Ansible的配置管理、sonar的靜態掃描。採起接口的方式，把每一個工具拋出的數據集中、聚合、分析，造成鏈式報表。2、作到工具集羣的解耦，好比說某些工具具有高可用集羣方案，或者強關聯的一些功能。貿然使用，會致使工具內部出現問題不能快速的解決，須要擴容，須要作更多的配置，不能快速上線。咱們的作法是工具的解耦，工具的使用永遠的最乾淨的。

我選擇工具的時候，第一個，當個人技術沒有徹底hold住它的時候，你選擇一個，哪怕短時間能給你帶來一些比較高的收益，一旦它出問題或者你用得很重的時候，你能hold住嗎？其實你hold不住，到那個時候你受到的影響更大。咱們再舉一個很典型的一個例子，Jenkins 裏面它自身有一個集羣概念，我看到不少人所有在用，若是 Jenkins 它的自己的原生的集羣出了問題之後，你能搞定嗎？我以爲處理這些問題都是比較費勁的。

蘇寧消金這一塊是這麼作的，我既然搞不定，我又不想研究它折騰它，那我就不用它，我本身寫了一個調度的工具，讓個人整個工具進行池化，工具池有別於資源池，其實我更願意將工具當成是資源的一部分。我把工具池化之後，我在使用工具方面，當個人資源同樣過來使用，當我須要擴容的時候，我把一個工具扔到裏面去，發佈的任務就自動分發到這個新工具上面了，這個是咱們對工具的一些思考。

其實工具對於咱們來講在整個的自動化到平臺化這一個階段，或者說咱們在DevOps進行到一個比較深刻階段的時候，平臺化更多的思考是平臺對咱們更可能是一種賦能。

下面到咱們工具鏈的結構，其實工具鏈完整之後，這一塊跟不少的廠商或者大廠的DevOps 產品相比，都是大同小異，異曲同工。咱們惟一不同的是個人客戶有老闆，他們的客戶不必定有老闆。

下面是咱們的整體架構的分層設計，這一塊我以爲你們也就是看看而已，能夠做爲參考，由於你們作的也都是大同小異，異曲同工。

咱們開始作這個事了，咱們有一個原則，咱們要作正確的事。其實這也是把你們召集到一塊兒來進行這個項目，或者說你們一塊兒來分享一塊兒交流的根本緣由。這個事你們都在作，或者我這個項目來開始，我在整個的項目開始的時候，我首先要考慮的什麼？除了個人設計規劃和之後的整個的任務分配之外，我第一個要想到的我這條路我不能走歪，我要想我要作正確的事，那我得要有一個任務，因此說我要有一個目標。

作一個比較好的規劃，第一個就是完成了個人自動化。在推 DevOps 項目的過程當中，首先要在組織內部完成標準化。在有數據支撐的狀況下，完成可視化、數字化一些實現，相應的在整個的中臺的數據層往下，我要完成個人工具化，並造成數據的邏輯整合。

基於一些考量更多的是體如今整個的平衡上，它平衡了整個速度、成本、質量和風險，以及提高了整個創新的能力，其實這個就回到了運維需不須要跑得更快一點。其實有了相應的方法論和技術的加持，其實咱們就能跑的快一點。既然咱們要作正確的事，咱們下一步幹什麼？咱們要正確地作事，因此說咱們得要有方法。在整個的落地的過程中，咱們要從具體到抽象。

在咱們這邊，是準確的將這件事的落地過程分紅幾層，以個人服務對象，受衆人羣，包括咱們以整個的階段性來衡量它的最終效益的實現方式，劃分了以下幾個方面。

第一個，咱們就找準點。第二個是根據最急迫的或者最緊急的一個需求，來找準整個的落地的基點，來逐步的延伸。

第二個，就是如何控制，咱們是打造了端到端的交付能力、可持續可迭代的流水線，從前面的整個需求到架構、到資源、到開發、到構建、到測試、到部署、到交付，其實運維在項目交付中的地位是特殊的，我是貫穿全流程的，可是我在前面只是配合，不顯山不漏水，到了最後方知誰是英雄。

運維是交付後的第一責任團隊，交付後的相關工做都歸我主導，交付以前的我是配合參與，有些事情你主導，有些事我主導。回過頭來看，你們作了這麼可能是爲了是什麼？

對於項目來講，交付後有沒有收益，花了多少資源，用了多少人來開發，我是否是得要考慮？因此說這也是不少的IT部門一直糾結的事，有沒有經過一些方法，經過一些數據來佐證這個項目到底有沒有達到預期，IT的成本投入能不能帶來一些客觀的利潤增加，這也是咱們的流水線以項目的後評價結束，也是跟其餘公司的持續交付流水線不同的地方。

落了這麼多環節數據，又回到一開始的數據驅動的環節，這個項目中老闆是最大的數據輸出受益者。因此說問題來了，老闆想要看看什麼東西？你研發看到的東西、測試看到的東西、運維看到的東西，其實跟你的老闆看的東西不同。好比我是老闆，我首先看我這個項目從開始到最後我花了多長時間，我通過了哪些重要的節點，我每一個節點當中我用了多少的時間，我節點跟節點之間有沒有優化，花了多少資源，帶來了多少收益。

打個比方來講，我在需求階段花了多長時間，有多少需求，這個需求從哪些部門過來的？在研發階段，研發團隊有多少人，每一個人分配了有多少任務，他幹了什麼事？整個的編碼過程到聯調階段，花了多長時間？一直到最後。因此從這一方面過來看，基於全局度量的一些指標，跟有價值的交付指標是息息相關的，包括咱們的整個質量，跟咱們的組織，跟咱們的人所有都串聯到一塊兒了。

相比於流程驅動而言，以任何一個點，以任何一個數據做爲枚舉值，橫向縱向的往前推，日後推，你都能推到版本、需求、人、組織、團隊、任務、質量、資源，所謂的資源不是你用了我多少服務器，或者用了我多少帶寬，這一塊是資源，人員投入自己它他是一種資源，你相應的產出不是個人一個系統的產出，每個工做量其實也是一種考量的方式。

4、落地實踐中的一些痛

---

第一個問題，咱們在某個階段性完成總體項目的50%的時候，其實咱們只完了 30%。第二個咱們在某個階段完成 50% 人員推廣，實際只完成了 30%，因此說不少人就說我作 DevOps，作出來之後我開始推了，往研發、往測試、往運維或者往其餘的組織、往其餘團隊在推，我發現推不動，問題在哪裏？

回頭看多是想的過於複雜了，簡單、聚焦、關注，由於你簡單，你才能體現出問題的本質，你作 DevOps 你不要把它作得過重，你找準一個點，你發現難推進那確定是你找的點有問題，或者說你找的這個對象有問題。

第二個，聚焦，你難推進的時候發現問題在哪裏，你聚焦的可度量的指標是不對的。或者對於研發來來講，你不要先把他的人天的貢獻度先實現，這是研發很反感的，這種單一的評估方式是值得懷疑的，因此說找的點必定要對。

第三個關注，關注哪些數據，哪些數據纔有改善，你必定要關注核心的數據，你的核心的數據在哪裏，那就要看老闆更關注哪些，老闆更願意看到這個項目質量更高一點，能逐步產生效益，仍是這個項目要儘快上線，人天效率更快一些，對於質量能夠稍微包容一點。這是作 DevOps 落地的人須要衡量的，或者說 DevOps 推動過程當中必然會遇到一些數據矛盾的地方，不會那麼十全十美。

第二個問題，其實當初進行PPT審覈的時候，你們對這一句話是很是的讚揚的。就表達一個觀點，你目前的來看，其實缺 DevOps 的人嗎？其實不缺，他缺的是對 DevOps 的有規劃和體系建設的人，這也我本次分享最想表達的意思，全局的思考，有序的規劃，可持續的體系建設很是重要，作任何一件事，要正確的作事，找到正確的方法，找到正確的對象。

第三個咱們談了一些體系和理念，咱們再談談一個跟方法論相關的，有幾個圖，第一個圖，應該玩的人不多，是一種網頁文字的遊戲。下面的是一個很漂亮的遊戲，最右邊是一個腳本。那個人問題來了。你以爲這個腳本是DevOps方法嗎？有人知道嗎？實際上是。爲何不是？按照DevOps的方法論來講可以提高效率和質量，可是並非最佳實踐方式。

回到最後的問題，咱們聊一下，DevOps技術的管理，它實際上是兩塊，我我的進行了總結，縱向能力的增強，橫向能力的打通。

縱向能力的增強，就是研發過程當中各階段的一種管理能力，包括需求、開發、測試、發佈和整個技術能力，包括構建自動化、性能、部署、灰度環境和代碼託管的流水線。其實咱們目前作的最多的，或者說咱們在整個DevOps所達到的效益，它體如今哪裏？其實就體如今整個的縱向能力的服務輸出。而咱們的橫向能力的打造，其實提及來是比較虛的，根本的精髓在哪裏？有價值的進行交付，因此說交付沒有問題，是能夠可度量的，可是你的價值如何來衡量？

其實這個是咱們所思考的，當IT技術變成很核心的生產力的時候，這些非功能性的需求，對於系統來講就變成功能性需求。監控、可用性、可靠性等，這是功能性需求。不能說一個服務只要上線就行了。能監控嗎？生產能看到嗎？可用性能保證嗎？有沒有考慮失敗的時候對業務的影響？它的可靠性怎麼樣？對別人服務的承諾、契約在極端的狀況下會改變嗎？這是蘇寧消費金融，也是全部IT團隊要去考慮和處理的一個問題。因此，橫向打通更關注的是什麼？有價值的監控，有價值的交付，有價值的度量，有價值的反饋，和有價值的優化。

說明：以上爲蘇寧消費金融顧黃亮老師在 GOPS 全球運維大會 2019 · 上海站的分享。眼下，運維還處於救火的狀態，面對繁雜的運維工做，試試用運營的思路來解決運維的問題。