近年來，銀行業(yè)作為金融行業(yè)的支柱行業(yè)，整體IT 投入不斷加大，架構發(fā)生重大變革，系統(tǒng)、網絡和數(shù)據的大集中，使得銀行信息系統(tǒng)的運行效率及穩(wěn)定性亦有巨幅提升。但對比以快速響應、快速發(fā)布、迭代更新為特征的新型“互聯(lián)網+ 金融”，傳統(tǒng)商業(yè)銀行IT 架構的劣勢已逐步顯現(xiàn)，其主要表現(xiàn)如下：
一、環(huán)境準備時間過長 。應用系統(tǒng)運行所需要的硬件、軟件環(huán)境往往需要在上線前一兩個月就要申請、準備，在產品上線前就需要規(guī)劃出產品今后可能用到的資源數(shù)量。
二、系統(tǒng)擴展、擴容難度較大。各應用系統(tǒng)架構不統(tǒng)一，難以用通用且便捷的方式應對基礎資源環(huán)境和應用處理能力橫向擴展的需求。
三、測試環(huán)境與生產環(huán)境差異較大。應用系統(tǒng)的測試環(huán)境和生產環(huán)境存在較大差異，測試案例并不能完全模擬生產環(huán)境。
四、上線過程復雜。上線過程除了開發(fā)人員外，往往需要運維人員、系統(tǒng)人員、DBA 等各個環(huán)節(jié)的人員共同參與，或修改配置、或部署應用、或執(zhí)行數(shù)據庫腳本，加大了上線人力成本的投入，降低了上線投產的效率，增加了手工操作風險。
五、建設周期長、成本高。技術標準遵循不一，軟件定制效率不高，系統(tǒng)間交互接口復雜，實施推廣需要大量的人力完成。同時，硬件設備使用趨于高成本、低效率。
金融云發(fā)展趨勢
金融云是運用云計算技術提供的創(chuàng)新服務。系統(tǒng)上云的訴求背后是，近年來資產回報率走低，加之新興金融業(yè)態(tài)沖擊，銀行業(yè)轉型壓力越來越大，且銀行需要應對的互聯(lián)網金融或者說金融互聯(lián)網應用場景越來越多，小額交易頻發(fā)，交易量不可預知，“秒殺”成為新常態(tài)。
多變的客戶需求和快速的金融產品創(chuàng)新也對IT資源的彈性供給和業(yè)務快速上線提出更高的要求，銀行IT系統(tǒng)峰值處理能力需達到過去的n倍，如果單筆交易IT成本不變，總成本將大幅增長。
而云計算作為新的IT建設、采購、使用模式，通過對標準且相對廉價的服務器、存儲和網絡等硬件資源進行虛擬化，提供便捷、按需獲取、可配置和可度量的IT資源供應，在成本、靈活性上有大優(yōu)勢。
金融云+devOps產品介紹
金融云+devOps，是北京有限元科技輸出的重要組成部分，工具鏈和平臺功能基本涵蓋DevOps的主要流程階段，幫助銀行完成技術、數(shù)據準備，實現(xiàn)統(tǒng)一的移動互聯(lián)網的安全準入及跨平臺發(fā)布標準。建設金融云平臺將作為銀行主動實施向開放架構轉型的關鍵一步，將其建設成為系統(tǒng)架構中重要的基礎性平臺，并作為科技轉型的重要抓手，打通開發(fā)、測試、部署及運維等各個環(huán)節(jié)，完成DevOps 轉型(開發(fā)、運維一體化)。
體系架構
如何建設一個能支撐開發(fā)、運維共同使用，實現(xiàn)價值交付的DevOps研發(fā)運營管理平臺，選擇以CMDB作為資源元數(shù)據平臺，以K8S作為資源管理平臺，支撐交付、變更、監(jiān)控、運營等各種IT運維能力;在交付部分，支撐資源交付和應用交付的自動化能力;在變更部分，產生資源變更事件，觸發(fā)對應變更動作、通知監(jiān)控系統(tǒng);在監(jiān)控部分，支撐監(jiān)控、告警系統(tǒng)，加強數(shù)據消費場景;在運營部分，提供完整數(shù)據支持容量、可用性等分析處理?？傮w架構如下圖：
自助交付平臺各個系統(tǒng)，形成閉環(huán)運維流程：
1. 容器云
以Kubernetes為基礎，打造多機房、多集群管理能力，以自助方式為交付團隊提供平臺能力：
? 多租戶;
? 應用倉庫;
? 提供容器web ssh訪問能力;
? 提供容器日志實時跟蹤能力;
? 應用自助部署及快速訪問能力;
? 應用自動擴縮容能力;
? 環(huán)境資源自助、配置管理能力;
? 環(huán)境腳本化創(chuàng)建能力-基于namespace;
? 環(huán)境凍結及恢復能力-基于namespace;
2.CICD
自助化、自動化和協(xié)作作為核心文化，通過提供便捷的基礎服務，讓交付團隊擁有自動化的交付流水線，并通過更多的溝通協(xié)作，盡可能讓每個交付團隊都能夠獨立自主的調整自己的基礎設施。然后再根據各個交付團隊的實施情況和結果來對流程和服務持續(xù)改進。首先設計一個高效的持續(xù)交付流水線，讓各個團隊都能夠嵌入到流水線中，并以基礎設施即代碼來溝通，通過自動化的方式實現(xiàn)開發(fā)與運維的連接，如下圖。
1) 流水線過程：
? 站在交付團隊的視角，我們將基礎設施構建、代碼構建、部署等活動都代碼化，與應用代碼放在同一個代碼倉庫中;
? 交付團隊通過提交自己代碼到倉庫后，通過Webhook觸發(fā)持續(xù)集成工具創(chuàng)建流水線;
? 接著會進行自動構建，單元測試、代碼質量、安全掃描、依賴庫檢查等任務，最終輸出構建鏡像并推送到鏡像倉庫，并生成測試任務;
? 測試人員選擇測試任務啟動，自動到任務對應環(huán)境中去創(chuàng)建應用(組)實例，然后再進行功能測試、性能測試、接口測試及安全測試等，測試通過后創(chuàng)建發(fā)布任務;
? 運維人員選擇發(fā)布任務，進行最終的部署活動;
2) 平臺能力：
為持續(xù)優(yōu)化交付流程，對許多活動進行數(shù)據收集和分析，以報表的形式去分析展示代碼提交頻率、系統(tǒng)和代碼質量情況、缺陷和構建情況、部署情況等，幫團隊找到瓶頸或問題。
3) 技術選擇：
以開源為主，選擇了一種輕量級、低耦合的技術組合Ansible+Jenkins+Kubernetes,具體工具鏈如下圖 :
考慮到基于yaml語法簡潔且易讀，以其定義交付團隊的公有DSL模板，平臺團隊關注平臺服務是否滿足需求和DSL模板是否易用，而交付團隊只用關注如何基于公有 DSL去定制自己的基礎設施、環(huán)境依賴和部署等。
CMDB
1) 目標：
? 管理所有資源及其拓撲關系，實現(xiàn)資源全生命周期管理
? 通過自動化發(fā)現(xiàn)技術結合變更流程，有效降低資源維護成本
? 作為元數(shù)據平臺，給周邊平臺提供數(shù)據支撐
2) 原則：
? 從應用的角度構建與IT資源的彈性關系
? 提供應用元數(shù)據管理能力，和應用類型無關
? 為應用資源、動作、狀態(tài)的統(tǒng)一管理提供支撐
? 以統(tǒng)一基礎資源層作為基礎，管理底層一切資源
? 變更控制借助運維流程自動化完成
? 資源使用自動發(fā)現(xiàn)，而不是人工維護
? 資源信息必須能為上層應用提供服務
3) 支撐
? 核心訴求是應用生命周期管理
? 核心場景是持續(xù)交付
4) 架構
? 資源模型管理主要為定義配置模型，包括配置項、屬性、關聯(lián)關系
? 資源對象管理分成基礎對象管理、PaaS對象管理及應用管理等
? 拓撲管理是資源對象之間的關聯(lián)關系管理，從部署拓撲、實例拓撲到基礎資源拓撲是一個分層拓撲
? 對于實例和關系的維護有兩個重要的手段，一個是自動發(fā)現(xiàn)，另外一個就是基于運維流程的生命周期管理與場景化的自動化變更管理等
3.FastX統(tǒng)一監(jiān)控
1)監(jiān)控目標
2)監(jiān)控4個黃金指標
? 延遲：業(yè)務的具體處理時長，需區(qū)分成功耗時和失敗耗時;
? 流量：業(yè)務在單位時間內的調用量，如：服務的QPS、每秒訂單筆數(shù)等;
? 錯誤：調用出錯數(shù)量、成功率、錯誤碼;
? 飽和度(負載/容量)：已使用資源的占比;
3)監(jiān)控標準化
? 事件來源-來自CMDB管理的物理及邏輯資源(主機系統(tǒng)、網絡、基礎組件、中間件、應用等)
? 監(jiān)控模板標準化-專人負責制定資源的監(jiān)控設計、閾值設置、模板統(tǒng)一
? 告警規(guī)則標準化-監(jiān)控系統(tǒng)與告警系統(tǒng)分離，各司其責;告警根據設備等級、應用等級、嚴重等級區(qū)分;告警發(fā)送對象統(tǒng)一來源CMDB
4. DBMan
? 數(shù)據查詢工具：支持查詢、審計、脫敏;
? 數(shù)據變更工具：支持DML、DDL;
? 數(shù)據庫運維工具：支持集群管理、用戶管理備份、恢復、巡檢;
有限元科技的金融云+DevOps，一方面，將成熟的開源工具開源技術和企業(yè)內部的云管理平臺相結合，實現(xiàn)了較高程度的開發(fā)測試流程自動化，推動了產品的持續(xù)集成和持續(xù)交付，減少了大量的重復勞動，提高了開發(fā)測試效率。
另一方面，通過使用云管理平臺，將復雜異構的IaaS資源服務化，降低了使用難度;結合業(yè)務部門需求合理劃分資源，減少了資源浪費，加強了資源的有效隔離，避免了誤操作;自服務自運維的模式，也極大地提升了公司整體研發(fā)效率。未來，有限元科技將持續(xù)優(yōu)化自助化持續(xù)交付平臺，使得集中式、審批式、被動響應請求的運維團隊不再是交付流程的依賴和瓶頸，逐漸轉向自助化、審查式、主動優(yōu)化的去中心化交付團隊。
（免責聲明：本網站內容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網站出現(xiàn)的信息，均僅供參考。本網站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。
任何單位或個人認為本網站中的網頁或鏈接內容可能涉嫌侵犯其知識產權或存在不實內容時，應及時向本網站提出書面權利通知或不實情況說明，并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網站在收到上述法律文件后，將會依法盡快聯(lián)系相關文章源頭核實，溝通刪除相關內容或斷開相關鏈接。 ）
