DevOps 是繼 Agile、Scrum 和 XP 之后衍生出來，延展到運維領域的新興運動。

大家好，我是京東金融負責 PE 團隊的負責人王超，很多人可能還不太了解 PE 這個崗位，PE 這個崗位在雅虎、阿里、Facebook 等多個互聯網公司都有，全稱是 Product Engineer（產品運維工程師），也有一些公司叫應用運維。

可以簡單定義為生產環境的產品的技術運營，在京東金融所有生產環境的業務運維、大數據及中間件的運維都是需要 PE 團隊主導或主要參與。

我過往的經歷是在人人網負責 PE 運維團隊，再早的時候是在一家傳統的大型央企里負責應用運維。

從三個公司的職業發展路線來看，我經歷了從傳統行業到大型互聯網公司，再到互聯網金融的幾次轉變。不同的經歷帶給我不同的思考角度，這也是我希望跟大家分享的內容。

運維體系四象限

運維體系的關注點主要有這四項：速度、質量、成本、安全。

速度

公司里最重要的是如何創造更大的業務價值，產品的發布要快，技術的瓶頸不能成為業務快速迭代、新產品上線推廣的制約因素。

質量

業務的快速交付，線上的質量仍然需要保證。

成本

人員成本和IT運行成本一直是互聯網公司的兩大項支出，對于大規模互聯網公司，服務器規模幾萬幾十萬，對資源的優化，服務性能的提升，合理的評估容量水位線，以及預算制定，成本核算，這些也都是運維需要做的工作。

安全

尤其對于金融行業來說，安全是非常重要的。支付行業有一個名詞叫資損，代表資金受到損失。在交易過程中可能會存在重復發單、營銷活動，比如說給用戶多發了錢，而且用戶提現了，這筆錢追不回來，就造成了資損。

因為技術或業務上的問題可能導致的資金損失會達到上千萬甚至更多，所以作為金融行業的運維人員，一定要重視安全問題。

DevOps介紹

DevOps 是繼 Agile、Scrum 和 XP 之后衍生出來的，延展到運維領域中的新興的運動。

DevOps解決的問題

DevOps 協調開發、QA 測試和技術運維三種角色，加強了相互之間緊密的溝通協作。

從項目規劃、代碼開發、構建、測試，再到發布、部署、運營和監控，DevOp 是一個閉合的環，保持著持續的不中斷的迭代發布部署。

而其中的***幾個環節，運營監控并反饋到需求方，往往是容易被忽視的環境，而 DevOps 強調了反饋（Feedback）的重要性，完成了部署以后一定要通知到需求的提出者，讓業務方進行確認，保證結果得到驗證。

如果參加過 DevOps Mster 沙盤訓練應該會對這一點深有體會，DevOps 對業務最重要的作用就是保證業務戰略快速推進和快速回饋。

開發與運維之間往往會存在部門墻，其中一個原因是，運維注重的是安全穩定，開發注重的上線發布的速度。思考問題的出發點不同，導致了相互之間理解的不同、溝通的不暢。

運維為了保證生產環境的穩定性，可能每周只設定一個上線窗口，在每周三晚上上線一次，可能開發會覺得等不到這么久，因為業務的需求很著急上線。

這不僅僅是技術問題，也涉及到業務和組織結構管理的問題。讓我們先從 DevOps 的思想分析一下問題。

DevOps 認為更小、更頻繁的變更意味著更少的風險

傳統模式的公司 IT 可能一個月或一個季度才發一個版，可對于互聯網公司來說這個周期就太長了。

比如業務上提了一個緊急需求，要周末辦一個推廣活動，網站要上線新頁面，但運維如果說下個月才能上線，業務上就已經沒有價值了。所以技術上需要支持更快更頻繁的變更。

如果把需求切割成更小的粒度，每次變化的代碼量更少了，意味著這部分的測試也更明確，代碼審核起來也比較快，所以風險可以控制的更低，發現問題也可以馬上回退解決。

讓開發人員更多地控制生產環境

讓開發人員更多地控制生產環境，但不是簡單的把運維操作權限交給開發人員，因為操作的風險還是要控制。

以京東金融為例，我們的做法是讓開發人員參與生產和運維，但并不是直接登錄到機器上操作，而是在運維平臺上授權受限制的操作，如應用的創建，發布部署，啟停等。

我們也需要提供相應的監控系統、日志平臺，可以讓開發人員在平臺上進行查看日志、檢測服務狀態等操作，不需要登錄服務器。

以應用程序為中心理解基礎設施

應用程序對底層環境有沒有依賴，發布在物理機還是虛擬機上，根據業務的需求需要部署多大規模的服務節點。

如果做多機房部署，這樣類似的問題我們希望在上線前就跟研發同學做好溝通，制定好整體的技術架構和部署架構，研發同學對基礎設施有更好的理解對整體架構的優化非常有幫助。

設計簡潔明了的流程，盡可能自動化

人、流程和技術，這三者是技術管理中很重要的三個因素。人與人之間都存在差異性，思維角度不一樣，而且互聯網公司人員的流動性也很大，所以人其實是不太好控制的。

而流程雖然重要，但是如果只是靠人的約定去執行的流程，得不到好的落地，效果一定不會好。因此我們的做法是依靠平臺，把流程固化到平臺里，在平臺中規避有風險的操作。

通過引導式的流程，完成應用立項，應用發布，擴容縮容等操作，因為每一步都有較好的提示，很少出現誤操作的情況。

促成開發人員與運營人員的協作

DevOps 的***目標是建立流水線式的準時制（JIT）的業務流程，***化業務產出。業務產出最終的衡量應該以業務交付完成的指標來判斷，也就是說是否準時上線了，以及上線后業務人員是否認可。

康威定律，設計系統的組織，其產生的設計和架構等價于組織間的溝通結構。反過來，如果你的系統設計或架構不支持，那就無法成功建立一個有效的組織。

不同公司的組織架構不一樣，往往導致服務架構也不一樣。DevOps 場景下如何設計合理的組織架構，也是我們需要思考的問題。

組織架構設計的時候，比較有意思的一點就是該如何去打造高效的開發和交付小團隊，就像上圖“雙比薩團隊”說的那樣，如果你不能給一個團隊提供兩個比薩餅，那么這個團隊就太大了。

要想達成組織結構的高效，***層的小團隊在一塊就需要多溝通、多碰撞，所以怎么設計你的更容易溝通的組織結構也很關鍵 。

如上圖所示，上面是開發、產品、測試，下面對應的是 SA、DBA、運維開發、安全、網絡部門，PE 的角色起到了相互銜接的作用。

PE 的角色也有點像特種部隊，特種部隊經常是三人為一組執行外勤任務，這三個人里可能還有一些分工，有的人偏戰略指揮、有的人負責執行任務、有的人負責聯絡通信。

而在這三個人后面，往往還有幾百人在做大后方的支持。后勤人員通過特種部隊的攝像頭等設備，對回傳信息做數據分析，指導特種部隊行動路線，執行計劃等。

作為參考，我覺得我們在運維工作中也需要小而靈活的團隊來跟產品、開發的人進行更直接的溝通，了解需求，根據需求制定解決方案，解決遇到的問題。

所以我負責的 PE 團隊也盡量設定成三四個人一組跟進某些業務線，其中每個人都可以盡量多了解對應的業務，當需要運維的其他部門配合時，再把這些業務需求轉換成運維的術語，傳遞給運維內部的其他部門 。

DevOps 的原則

• DevOps 官方的五大原則：
• 文化（Culture）
• 自動化（Automation）
• 精益（Lean）
• 數據度量（Measurement）
• 分享（Sharing）

重點提一下數據度量（Measurement）。

監控如果做得不到位，小的問題不容易發現，一出問題就是業務中斷的大問題。

大的互聯網公司的監控工具一般都會對時延非常的敏感，如內部廣泛使用的 APM 應用級性能監控工具，如果某個應用的服務接口性能從 100 毫秒變成 120 毫秒，很可能就會觸發報警，報警就會驅動大家去查為什么接口性能慢了、是不是硬件問題、是不是網絡問題，運維會配合開發進行細致的調查。

這些細小的問題驅動了我們在技術上多去分析思考，也會促進我們開發更細粒度的監控和分析工具排查問題。

DevOps 體系建設

應用全生命周期管理

應用從立項到發布上線、不斷的迭代變更、擴容、縮容、遷移以及生命周期結束后的下線，需要一個完整的生命周期的管理。

我們做應用的全生命周期的管理時，結合了內部的流程系統、應用信息管理系統、自動部署系統，并對外提供 API 接口。

應用中心類似 CMDB，但 CMDB 偏底層基礎設施一些，比如管理操作系統、物理機、網絡、數據中心。但是應用生命周期更關心應用本身和周邊關聯的系統。

應用立項時需要做很多工作，確定所用資源的套餐，根據業務容量規劃需要的節點數量、基礎組件的版本、網絡拓撲、網絡申請、網絡權限等，立項以后還會經過很多次的信息變更。

如果僅依賴文檔把每次變更做記錄，很容易在人員交接流轉的過程中信息遺漏丟失，給后續接手的人操作帶來風險。通過在系統間自動化流轉的時候自動記錄下應用信息，保證了應用信息和生產環境的一致。

這些信息也作為服務對外提供接口。舉個例子，應用監控的配置如果脫離應用系統單獨維護，每次應用擴容縮容都需要通知到監控系統進行修改，很容易造成應用擴容或者遷移后監控會有遺漏，造成潛在風險。

但是監控系統以應用中心對外提供的接口數據作為基礎信息，就保證了數據都是實時準確的，也避免了各個系統重新配置的工作。

Infrastructure as Code—DevOps的基礎

應用部署的工作對基礎環境的依賴非常大，比如 Python 程序的部署，對 Python 版本的依賴，再底層的 OpenSSL 等文件庫的依賴，以及對操作系統的依賴。

早期的運維很多都是通過腳本+配置文件的方式來實現批量執行的，判斷需要的依賴環境，再進行依次安裝，每次執行前可能還需要臨時修改腳本或者配置文件的內容，比如要操作的 IP 列表文件。復雜的任務以及多人操作的時候這樣的方式就存在了較大的風險。

Puppet、Ansible、Chef 這些配置管理工具很好的解決了這個問題，這些工具指導我們更多的通過配置管理的方式，如把軟件部署的依賴關系通過 Ansible Playbook 來定義，通過角色分組嚴格的控制執行的目標狀態，操作可以重復執行，哪個環節出現問題也可以準確定位，結果得到了更好的保障。

而容器時期的到來，首先是更好的解決了環境的一致性的問題，通過鏡像封裝的方式將基礎環境打包到了容器鏡像中，保證了從開發、測試、到生產的環境一致性。

Mesos、Kubernetes 等流程編排工具更好的解決了部署的問題，只需要關注應用本身的信息以及部署的規模，平臺已經解決掉了大部分的問題。

熟悉技術架構

運維跟開發人員一樣，需要多了解技術架構和業務架構。

多了解技術架構和業務架構，才能在生產遇到問題時更好的理解和處理問題，在理解研發提出的需求時更好地理解問題，甚至提出更好的解決方案。

Platform as Code

業務架構中主要用的一些基礎組件 ：

• GSLB
• 網關
• 服務化組件
• 消息中間件
• 緩存
• 配置管理平臺
• 分布式調度
• APM
• 日志平臺

未來展望

數據化運維

運維行業也會細分，業務運維的角色會越來越像數據化的運營，從應用的整個生命周期持續的跟進和優化，關注更快的迭代、更高的訪問質量、安全的威脅，關注成本的分析，這些問題也促進我們不斷的深耕技術，為業務提供價值。

為了更好的質量，我們需要做好以下的數據監控：

• 基礎服務監控（網絡、OS、DNS 等）
• 數據服務監控（DB、緩存、消息等）
• 應用性能監控
• 分布式調用跟蹤和監控
• 日志監控
• 業務指標監控

智能運維——AIOps

現在 AIOps 也是很熱門的研究方向，分享幾個主要思考點：

• 采集數據是基礎，事件信息匯總、對數據需要打標簽；
• 報警關聯分析，找根本原因；
• 自動報警降級或升級；
• 容量水位線預估與自動擴容；
• 從人工規則向機器學習過渡。

希望后面再找時間詳細地展開分享。

[[239196]]

王超，京東金融資深技術架構師、應用運維團隊負責人（PE 團隊），也曾負責人人網 PE 團隊。經歷了京東金融運維體系從 0 到 N 的過程、數次 618 和雙十一大促的考驗。目前主要關注 DevOps、運維與架構的融合、業務可用性保障、運維平臺建設和團隊管理。