普惠金融平台的運維發展與運維自動化實踐

經過了互聯網金融野蠻式生長階段，從2015年開始規範發展和普惠金融成為中國互聯網金融發展的主旋律，2016年初由國務院印發的《推進普惠金融發展規劃（2016—2020年）》更成了互聯網金融企業奉行的圭臬。從FinTech金融科技的角度來看，普惠金融就是充分利用互聯網、雲計算、大數據等技術手段，有效降低金融服務的連接、信息和計算成本，進而降低金融門檻，達到人人可參與、人人可用的金融方式。普惠金融的發展不但改變了金融企業傳統的IT架構和服務交付方式，對於越來越複雜的IT系統運維也提出了更高的要求，如何確保部署在雲端的金融平台和業務的穩定、高效運轉，成為IT部門必須直面的一道難題。

諾亞財富是紐約證券交易所上市的獨立財富管理機構，也是中國獨立財富管理行業的開創者和領導者。財富派作為諾亞財富集團旗下專為白領、中產精英等高潛力人群打造的高品質財富管理平台，通過貫徹普惠金融（inclusive financial system）的理念，有效、全方位為中國中產階級提供綜合金融服務，致力成為互聯網私人銀行，全面打造專屬於高潛力人群的綜合金融服務平台。財富派於2014年6月8日上線，次年3月獲得紅杉資本的戰略注資，截止2016年12月底，財富派已經幫助客戶累計管理資產規模已經超過320億。

《監控與性能優化》社群有幸邀請到財富派運維總監褚哲敏先生，為我們帶來他從業多年以來對互聯網金融企業運維發展的一些心得體會，下面就是他的精彩分享：

大家好，我是來自諾亞財富旗下產品財富派的褚哲敏，主要負責財富派的運維工作，今天有幸能夠和大家分享我這些年運維經歷中的一點感想，以及跟大家一起探討下財富派的運維自動化。

本次分享的主題如下：

l 運維1.0 運維2.0 運維3.0

這裡的運維1.0，2.0和3.0是本人根據近十年運維過程總結出來的運維3個階段。

運維1.0：也叫作腳本時代，大家是否對shell，bat記憶猶新？最早做運維的時候，大家為了減少重複的工作，無論Windows還是Linux都會通過腳本來減少重複工作。日積月累，腳本的數量越來越多，對運維人員的專業要求也越來越高。

更好的管理IT系統，逐漸出現了一些運維產品，我們也進入了運維2.0，也就是產品時代。常見的運維監控產品有Nagios，Zabbix；運維管理工具有puppet，saltstack等。運維產品的出現大大提高了運維的效率，同時也降低了一部分運維門檻，即便不懂腳本開發，只要熟悉使用這類運維工具就能快速的上手做運維。

隨著運維產品的增多，運維需要熟悉的產品也越來越多，慢慢進入運維3.0，也就是平台時代。結合ITIL理論，同時融合devops概念，將各個運維產品系統進行集成，運維自動化程度越來越高，運維效率越來越高，運維入門門檻越來越低。

l 核心思想：釋放運維重複勞動力

通過運維的三個階段來看，本人總結最核心的思想就是：釋放運維重複勞動力，讓運維不再做重複繁瑣的工作，運維工作更加高效。而我也一直和團隊傳達這樣的思想，運維要學會「偷懶」，重複的工作要通過工具、平台來完成，釋放自己的勞動力！

l 財富派運維自動化系統ops

財富派的運維自動化是2016年Q2開始開發，結合了ITIL的理論，目前完成了發布模塊、配置模塊、審批模塊，正在進行cmdb模塊的優化。

? 發布模塊：

tt解決了開發從提交代碼到代碼上線的所有過程，並且整個流程運維是不參與的：

n 目前發布系統支持：php，node，js，go，c++，python等語言發布；

n 開發提交代碼到git，隨後提交ops審批和發布任務（後續會將審批和發布打通）；

n 對應測試人員看到相關任務，進行部署測試、預發、上線，在任何一個環節都可以點擊回歸開發；

n 每個操作都會郵件通知相關人員；

n 所有發布都有記錄，方便日後的進行審計；

n 一鍵回滾，支持歷史版本回滾（回滾需運維人員操作）；

n SQL發布結合審批工單，自動創建SQL任務，執行SQL；

? 配置模塊

n Ops所有項目均可配置；

n 產線使用etcd進行配置管理，OPS和etcd進行打通，所有修改在OPS進行，方便日後進行審計（後續會和審批打通，審批通過自動進行相關配置）；

? 審批模塊

n 結合安全規範和審計要求，所有變更都必須有審批記錄，所以我們開發了審批記錄，並且逐步將審批和對應任務進行打通。

l OPS未來規劃：

n CMDB優化的規劃，以cmdb為中心，將各個開源軟體進行打通（包括，堡壘機，監控系統，OPS，公有雲等等）；

n 結合公有雲API，實現快速開機，並且快速部署上線以及後續服務（包括堡壘機，監控，日誌分析系統等等）；

n 組合發布：相信很多公司的業務架構和我們一樣非常的複雜，並且存在多種開發語言混用的情況，一個版本發布可能存在PHP、C++、SQL等等組合類型發布，後期我們會在現有單一發布模塊上封裝組合發布。

l 統一監控平台（規劃）

大家是否和我們一樣，存在共用多套監控系統的情況，每套監控系統的作用還不同，並且存在多個監控系統獨立告警，當一個問題出現時，多個告警同時報警的情況？

我們一共存在三套監控系統：Zabbix，公有雲監控和雲智慧監控寶。通過Zabbix監控伺服器內部性能和應用業務，公有雲監控主要監控公有雲產品相關運行狀態，監控寶主要做網路鏈路的監控，每套監控系統都有自己的告警，會導致告警量很大，因此我們後期會在平台上實現統一監控告警管理、多條件組合告警，為服務自愈提供監控基礎數據。

t金融行業對信息安全的重視程度是最高的，然而安全策略等級越高往往意味著運維效率越低，所以我們更需要不斷提高運維自動化率來解決這一矛盾，在自動化運維的道路上前進！t以上是我的一點心得分享，歡迎大家指正，謝謝！

Q&A

問：你們的主機是自建還是雲服務商的？

答：混合雲，並且是多雲廠商。

問：有沒有碰到過不能有效自動化的任務？

答：目前來說，任務只要細分得當，都是可以自動化，只是自動化的複雜程度不一樣。

問：部署時候針對那些要執行SQL的怎麼統一規劃？

答：使用統一模板提交審批，並且提供回滾SQL語句，並且經過2級人員進行審批，在自動發布時系統進行語法校驗，隨後會進行非同步執行，並把結果返回給前端，如果出現錯誤，立刻郵件簡訊通知開發和運維。

問：業務部門的統計需求如何處理？

答：業務部門的統計需求其實是統計報表功能，更應該在業務報告系統體現。

問：我們的任務需求總是變動，常常被這個拖了時間，自動化項目也因此而暫停了，不知道您是怎麼處理這個問題的？

答：對於運維任務這個問題，首先說一下我們的團隊構成，有一半是運維工程師，一半是運維開發工程師，並且每個運維都需要輪流值班（包括運維開發也需要了解運維日常工作中的需求點）。確實，需求的增加肯定比開發進度快，這其實是項目經理需要考慮的問題，如何進行項目需求優先順序設定。比如我剛到公司的時候沒有運維開發，所有運維都被大量的發布工作佔用了全部工作時間，當時動員大家為了之後有更多時間學習和提高自己的技術，必須立刻進行運維自動化系統的開發，提高發布效率。

問：你們在安全審計這塊是怎麼做的？

答：目前我們每半年會做一次內審，主要是對項目變更，項目許可權等方面的審計，所以後來我們做了審批模塊，發布模塊來讓系統記錄提供數據！至於安全審計，我們使用開源堡壘機（jumpserver）進行運維人員審計，同時使用一些第三方的安全產品進行資料庫，系統等方面審計。

問：能不能透露下用了哪家第三方產品做系統方面審計？

答：這個第三方產品比較多，可以去了解一下雲安全這塊，如果需要在深入了解，可以加我微信。

問：ops這套系統有做備份容災方案嗎？

答：本身做了集群化，並且OPS實現了多機房、多雲廠商的分散式發布。因為目前我們的業務較為複雜，有2個雲廠商機房，一個自建機房（受監管）。

問：運維跟開發是什麼關係？

答：運維和開發是一個產品生命周期中兩個相輔相成的工種，缺一不可。 開發主要是負責產品代碼層面架構以及實現，而運維，更偏向於底層基數設施的架構和優化，基礎設施主要包括網路，伺服器，虛擬化，基礎軟體等等。

推薦閱讀：